Structured vs. Object Orient Analysis and DesignSAD vs. OOSAD<br />Motaz K. Saad <br />May 2010<br />
Outline <br />Бүтэцлэгдсэн шинжилгээний үе<br />Обьект хандалтат шинжилгээний үе<br />Бүтэцлэгдсэн шинжилгээний хөгжүүлэлт...
Textbooks<br />Modern Systems Analysisand Design6th Edition<br />Jeffrey Hoffer Joey GeorgeJoseph Valacich<br />3<br />Obj...
Key Differences Between Structured and Object-Oriented Analysis and Design<br />4<br />
SW Project phases	<br />Any project in the world has the following phases:<br />Planning<br />Analysis: system requirement...
Structured Analysis and design (SAD)<br />A. Шинжилгээний үе<br />Системийн шаардлага тодорхойлох<br />Бүтэцлэгдсэн процес...
Structured Analysis and design (SAD)<br />A. Шинжилгээний үе<br />Системийн шаардлагуудыг тодорхойлох:<br />Ярилцлага: Ган...
DFD Symbols<br />Comparison of DeMarco and Yourdon<br />and Gane and Sarson DFD symbol sets<br />8<br />Process-процесс<br...
Өгөгдлийн урсгалын диаграм<br />Context-level data flow diagram showing project scope for Purchasing Fulfillment System (P...
10<br />Suppliers-нийлүүлэгчид<br />Production schedulers-бүтээгдэхүүн хуваарилагчид<br />Purchasing fulfillment system- б...
Context Diagram-Ерөнхий диаграм<br />Context diagram of Hoosier Burger’s food-ordering system<br />11<br />
Developing DFDs (Cont.)<br />Level-0 diagram нь системийн үндсэн процессыг үзүүлдэг ба үүнд өгөгдлийн урсгалууд, өгөгдөл х...
Level-0 Diagram<br />13<br />Level-0 DFD of Hoosier Burger’s food-ordering system<br />
Sold-зарагдсан<br />Inventory-бараа материал, нөөц<br />Transform-өөрчлөх<br />Depletion-дууссан<br />14<br />
Data Flow Diagramming Rules<br />15<br />ªãºãäëèéíÓðñãàëûíÄèàãðàìì (ªÓÄ) íüîðøèíáóéáîäèòñèñòåìýñâýëøèíýíýâòð¿¿ëýõãýæáóéáîä...
Level-1 DFD<br />Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s fo...
Aggregate-иж бүрдэл, нийт дүн<br />17<br />
18<br />Level-n DFD<br />Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0...
ӨУД-ийн 2 төрөл<br />Физик урсгал<br />Процессийн түвшинүүд нь  тодорхой дараалалтай бөгөөд энэ нь өгөгдлийг боловсруулдаг...
SAD – Analysis phase (Cont.)<br />Логик шаардлагууд (logical modeling)<br />Шийдвэрийн хүснэгт болон шийдвэрийн мод хэрэгл...
SAD – Analysis phase (Cont.)<br />B. Загварчилгааны үе<br />Өгөгдлийн баазын загвар (DB normalization)<br />Формууд болон ...
DB Normalization-ӨБ-ийг энгийн хэлбэрт шилжүүлэх<br /><ul><li>ªãºãäëèéãýíãèéíõýëáýðòøèëæ¿¿ëýõ - îáúåêòèéíõîëáîîñûíøèíæèëãýý
ÎÕ øèíæèëãýýíü ªÑÑ-èéãäýýðýýñäîîøíü (Top-Down) çàäëàæøèíæëýõàðãà
ýõëýýäñèñòåìèéíîáúåêò¿¿äèéãòîäîðõîéëäîã
äàðààíüîáúåêò¿¿äýýàòðèáóòûíòºâøèíäçàäëàäàã.</li></ul>1-ð ýíãèéíõýëáýð<br /><ul><li>Äàâòàãäñàí á¿ëýã ýëåìåíò ñàëãàõ
Òýã óòãàò ýëåìåíòèéã ñàëãàõ
Äàâòàãäñàí óòãàòàé ýëåìåíò ñàëãàõ
Áàéæ áîëîõ ò¿ëõ¿¿ðèéã òîäîðõîéëîõ</li></ul>2-ð ýíãèéíõýëáýð<br /><ul><li>Ýëåìåíòõîîðîíäûí ôóíêöèîíàëü õàìààðëûã òîäîðõîéëîõ
Ôóíêöèîíàëü á¿ðýí õàìààðëûã òîäîðõîéëîõ
Ôóíêöèîíàëü á¿ðýí áóñ õàìààðàëòàé ýëåìåíòèéã ñàëãàõ</li></ul>3-ð ýíãèéíõýëáýð<br /><ul><li>Äàìæñàíõîëáîîñûãñàëãàõ</li></ul...
Object Oriented Analysis and Design-Обьект хандалтат шинжилгээ ба зохиомж<br />OOAD<br />23<br />
Object-Oriented Analysis and Design (OOAD)<br />Обьектууд нь өгөгдөл болон процессуудад үндэслэгддэг.<br />Object: a struc...
Outline <br />SAD Phases<br />OOAD Phases<br />SAD vs. OOAD software development <br />Adopted Books<br />UML in practice ...
OOSAD textbook<br />A. Шинжилгээний үе<br />Бүтэцлэгдсэн шаардлагууд (Use cases)<br />Схемчилсэн өгөгдлийн загвар (class d...
OOSAD textbook<br />B. Зохиомжын үе<br />Физик ӨБ-ийн загвар<br />Загварчилгааны элементүүд<br />Design classes<br />Desig...
Learning UML textbook<br />Focus on 4+1 view architecture <br />28<br />Системийн логик бүтцийн загварлaл:  Classes and Cl...
OOAD project phases<br />Analysis<br />Шаардлага цуглуулах, шинжилгээ болон загварчлал (Шаардлагын инженерчлэл /Requiremen...
Use Case жишээнүүд<br />30<br />
Оюутны бүртгэлийн системийн Use case диаграм<br />31<br />
Billing system- Тооцооны систем<br />Roster-жагсаалт<br />Maintain-хадгалах<br />Registrar-бүртгэгч<br />
Use Case: Эмнэлэгийн системийн жишээ<br />33<br />
Appointment-тов<br />Defer-сунгах, хойшлуулах<br />Extension point<br />Generalization-нэгтгэл<br />Clerk-ажилтан<br />Tre...
Use Case: Банкны системийн жишээ<br />35<br />
Үйл ажиллагааны диаграмын жишээнүүд<br />36<br />
Create <br />curriculum<br />Select courses <br />to teach<br />Create <br />Бүртгэлийн системийн үйл ажиллагааны диаграм<...
38<br />Үйл ажиллагааны диаграм:Банкны систем<br />
Notify-мэдүүлэх<br />Approach-хандах<br />39<br />
Үйл ажиллагааны диаграм: Бараа нийлүүлэх систем<br />40<br />
Fill order-Захиалга бэлтгэх<br />Ship order-Захиалга илгээнэ<br />Send invoice-нэхэмжлэл явуулна<br />Make payment-төлбөр ...
Finding classes (thinking in objects)(Registration System)<br />42<br />Boundary class (GUI interface)<br />Entity class<b...
Class relations: Удамшил/Inheritance and Multiplicity(Registration System)<br />0..*<br />1<br />1<br />0..*<br />1<br />3...
Холбоосууд<br />Гурван төрлийн холбоос байдаг.<br />Association-нэгдэл<br />Aggregation-бүрдмэл<br />Dependency-хараат<br ...
Нэг классын обьектууд бусад классын обьектуудтай харилцан үйлчлэлцэх <br />Нэг классын обьектууд бусад классын обьектуудта...
Обьект хандалтат өргөтгөлүүдийн холбоосын загвар<br />Generalization-Ерөнхийлөл<br />Multivalued attributes (OK to violate...
Үндсэн өгөгдлийн загварыг ОХЗагвар руу хөрвүүлэх<br />Классуудыг хөрвүүлэх<br />Холбоосуудыг хөрвүүлэх<br />Normalize obje...
Supertype/subtype relationships<br />48<br />
Mapping Supertype/subtype relationships to relations<br />These are implemented as one-to-one relationships<br />49<br />
Sequence Diagram<br />registration <br />registration <br />math 101<br /> : Student<br />form<br />manager<br />math 101 ...
51<br />public class MessageReceiver<br />{<br />public void foo(  )<br />   {<br />      // Do something inside foo.<br /...
Collaboration Diagram<br />course form : <br />1: set course info<br />CourseForm<br />2: process<br />3: add course<br />...
53<br />
54<br />
Sequence Diagram for Bank System<br />55<br />
State Machine Diagram<br />56<br />
57<br />State Machine Diagram<br />
58<br />Showing Components Working Together<br />
59<br />Focusing on the key components and interfaces in your system<br />Focusing on component dependencies and the manif...
60<br />Assembly connectors show components working together through interfaces<br />
System Architecture <br />61<br />
Key Differences Between Structured and Object-Oriented Analysis and Design<br />62<br />
Software Engineering textbookMain topics <br />INTRODUCTION<br />Socio-technical System<br />Emergent property<br />REQUIR...
Software Engineering textbookMain topics (Cont.)<br />EMERGING TECHNOLOGIES<br />Security Engineering<br />Service-oriente...
Software Engineering textbookSystem categories<br />Technical computer-based systems<br />Systems that include hardware an...
Software Engineering textbookSocio-technical system characteristics<br />Emergent properties<br />Properties of the system...
Software Engineering textbookTypes of emergent property<br />Functional properties <br />These appear when all the parts o...
Software Engineering textbookThe systems engineering process<br />
Software Engineering textbookInter-disciplinary involvement<br />
Software Engineering textbookSystem Models<br />Context models <br />Blocks (box diagram of subsystems)<br />DFDs can be u...
Key Differences Between Structured and Object-Oriented Analysis and Design<br />71<br />
Papers <br />72<br />In practice - UML software architecture and design description, IEEE Software, 2006<br />The Impact o...
Papers <br />73<br />In practice - UML software architecture and design description, IEEE Software, 2006<br />
Practitioner reflections on UML use<br />2+ month period, 80 architects participated. <br />major responsibilities among r...
Survey respondents’ use of UML for 4+1 architectural views<br />75<br />
Survey respondents’ assessment of their adherence to the UML standard.<br />76<br />
Deadline vs. completeness as stopping criteria for different project sizes.<br />77<br />
Problems encountered due to incomplete models correlated to respondent demographic data regarding project size.<br />78<br />
Problems with UML descriptions<br />Scattered information:Design choices are scattered over multiple views.<br />some depe...
Other problem classes include the following:<br />Diagram quality. UML lets architects represent one design in different w...
Defects in industrial UML models<br />Subjectiveimpression obtained via the survey<br />Objectivemeasurements about the qu...
Defects found in the case studies<br />Methods that are not called in sequence diagrams<br />Classes not occurring in sequ...
Papers <br />83<br />The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIO...
It is important to investigate the benefits obtained from modeling. <br />this paper reports on controlled experiments, sp...
85<br />
86<br />
Experimental results<br />The goal was to shed some light on the cost effectiveness of model-driven development with UML. ...
Papers <br />88<br />A Realistic Empirical Evaluation of the Costsand Benefitsof UML in Software Maintenance, IEEE TRANSAC...
The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling.<br...
This is the first controlled experiment that investigates the costs of  maintaining and the benefits of using UML document...
91<br />
Selection of Subjects<br />Subjects were recruited via a request for consultants being sent to Norwegian consulting compan...
93<br />10 no UML<br />10 UML<br />
94<br />
95<br />
Upcoming SlideShare
Loading in...5
×

Ood lesson3

2,376

Published on

m

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,376
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
78
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • е
  • топ
  • г
  • Problems with incomplete modelsGiven that the practitioners report completenessto be the primary criterion for deciding tostop modeling, we investigated the effects ofmoving to the next project phase without acomplete model.
  • 1. The subject is given an introductory session explainingthe manner in which he would be working.2. The subject answers an initial questionnaire capturingthe subject’s background and experience (seeTable 2).3. If the subject is in the UML group, the subjectreceives a UML refresher/tool training session.4. The subject receives the first task.5. The subject submits an estimate of the amount oftime that he/she thinks the task will take him/her.6. The subject implements the task.7. Upon completion, the task is sent in for acceptancetesting. The system is then tested by an experimenterbased on a system acceptance test plan.a. If the test fails, the subject is told about theproblem and is asked to fix it to submit thesolution again.b. If the test passes, the subject receives the nexttask and repeats the process from Step 4.8. Upon the completion of all five tasks, debriefingtakes place.
  • Ood lesson3

    1. 1. Structured vs. Object Orient Analysis and DesignSAD vs. OOSAD<br />Motaz K. Saad <br />May 2010<br />
    2. 2. Outline <br />Бүтэцлэгдсэн шинжилгээний үе<br />Обьект хандалтат шинжилгээний үе<br />Бүтэцлэгдсэн шинжилгээний хөгжүүлэлт болон ОХШЗ-оор програм хангамж хөгжүүлэх<br />Ашигласан номууд<br />UML-ийн хэрэглээ<br />Дүгнэлт & үнэлгээ<br />2<br />
    3. 3. Textbooks<br />Modern Systems Analysisand Design6th Edition<br />Jeffrey Hoffer Joey GeorgeJoseph Valacich<br />3<br />Object Oriented Systems Analysis and Design <br />2nd edition <br />Joey George<br />Dinesh Batra<br />Joseph Valacich<br />Jeffrey Hoffer<br />Software Engineering<br />8th , 9th edition <br />Lan Summerville<br />Learning UML 2.0, <br />By Kim Hamilton, Russell Miles, O'Reilly, 2006.<br />Visual Modeling with Rational Rose 2002 and UML, 3/E, by Terry Quatrani<br />
    4. 4. Key Differences Between Structured and Object-Oriented Analysis and Design<br />4<br />
    5. 5. SW Project phases <br />Any project in the world has the following phases:<br />Planning<br />Analysis: system requirements are studied and structured<br />Design: recommended solution is converted into logical and then physical system specifications<br />Logical design – all functional features of the system chosen for development in analysis are described independently of any computer platform <br />Physical design – the logical specifications of the system from logical design are transformed into the technology-specific details from which all programming and system construction can be accomplished<br />Implementation<br />Testing <br />Maintenance <br />5<br />
    6. 6. Structured Analysis and design (SAD)<br />A. Шинжилгээний үе<br />Системийн шаардлага тодорхойлох<br />Бүтэцлэгдсэн процессийн шаардлага тодорхойлох<br />Логик шаардлагууд(logical modeling)<br />Бүтэцлэгдсэн системийн өгөгдлийн шаардлагууд<br />B. Зохиомжын үе<br />Өгөгдлийн баазын дизайн<br />Формууд болон тайлангийн загварууд <br />6<br />
    7. 7. Structured Analysis and design (SAD)<br />A. Шинжилгээний үе<br />Системийн шаардлагуудыг тодорхойлох:<br />Ярилцлага: Ганцаарчилсан эсвэл группээр<br />Бүтэцлэгдсэн процессийн шаардлага тодорхойлох:<br />Data Flow Diagram (DFD) – логик процессийн загвар<br />DFD levels (процессийн задралууд)<br />Context diagram-ерөнхий диаграмм <br />4 type of DFD<br />Физик урсгал: элементэд тохирсон<br />Логик урсгал:системийн урсгалуудыг тодорхойлох<br />7<br />
    8. 8. DFD Symbols<br />Comparison of DeMarco and Yourdon<br />and Gane and Sarson DFD symbol sets<br />8<br />Process-процесс<br />Data store- өгөгдлийн файл<br />Source/sink-эх сурвалж<br />Data flow- өгөгдлийн урсгал<br />
    9. 9. Өгөгдлийн урсгалын диаграм<br />Context-level data flow diagram showing project scope for Purchasing Fulfillment System (Pine Valley Furniture)<br />9<br />
    10. 10. 10<br />Suppliers-нийлүүлэгчид<br />Production schedulers-бүтээгдэхүүн хуваарилагчид<br />Purchasing fulfillment system- бөөний худалдааны систем<br />Quotes-Үнэлгээ, тоо хэмжээ<br />Shipment-бараа нийлүүлэх<br />
    11. 11. Context Diagram-Ерөнхий диаграм<br />Context diagram of Hoosier Burger’s food-ordering system<br />11<br />
    12. 12. Developing DFDs (Cont.)<br />Level-0 diagram нь системийн үндсэн процессыг үзүүлдэг ба үүнд өгөгдлийн урсгалууд, өгөгдөл хадгалах дээд түвшний элементүүд байна. <br />Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs.<br />12<br />
    13. 13. Level-0 Diagram<br />13<br />Level-0 DFD of Hoosier Burger’s food-ordering system<br />
    14. 14. Sold-зарагдсан<br />Inventory-бараа материал, нөөц<br />Transform-өөрчлөх<br />Depletion-дууссан<br />14<br />
    15. 15. Data Flow Diagramming Rules<br />15<br />ªãºãäëèéíÓðñãàëûíÄèàãðàìì (ªÓÄ) íüîðøèíáóéáîäèòñèñòåìýñâýëøèíýíýâòð¿¿ëýõãýæáóéáîäèòñèñòåìèéíàëèíûõíü÷á¿ðýíòºãñèëýðõèéëýëáîëæ÷àäàõã¿é. Ó÷èðíüçàãâàðò ºãºãäëèéãõàäãàëàõáîëîí 纺õ ôèçèêïðîöåññ, ïðîöåññèéãã¿éöýòãýíèëýðõèéëýõõ¿íìàøèí, ºãºãäºëõàäãàëàõõýðýãñýëáîëîíÿìàðíýãàëäààøàëãàõïðîöåññóóäûãòóñãàäàãã¿é. Ãýòýëáîäèòñèñòåìäýäãýýð õ¿÷èíç¿éë¿¿ä çàéëøã¿éõýðýãòýé. ªãºãäëèéíÓðñãàëûíÄèàãðàìì (ªÓÄ)-èéí ¿ð ä¿íäãàðàõýíýîíöãîéçàãâàðíüçºâõºí ÞÓ õèéãäýõ ¸ñòîéã ¿ç¿¿ëýõýýñáóñ ÕÝÐÕÝÍ õèéõèéãàâ÷ ¿çýõã¿é. <br />
    16. 16. Level-1 DFD<br />Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s food-ordering system<br />Level-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD.<br />This is a Level-1 DFD for Process 4.0.<br />Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary.<br />16<br />
    17. 17. Aggregate-иж бүрдэл, нийт дүн<br />17<br />
    18. 18. 18<br />Level-n DFD<br />Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering system<br />Level-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD.<br />This is a Level-2 DFD for Process 4.3.<br />Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest level of the hierarchy, it is called a primitive DFD.<br />Format-Хэлбэр, хэмжээ<br />
    19. 19. ӨУД-ийн 2 төрөл<br />Физик урсгал<br />Процессийн түвшинүүд нь тодорхой дараалалтай бөгөөд энэ нь өгөгдлийг боловсруулдаг.<br />Өгөгдлийн урсгалууд болон өгөгдөл хадгалах хэрэгсэлүүдийг физик нэрээр нь тодорхойлж болдог. <br />Логик урсгал<br />Өгөгдөл болон процессуудын мэдээлэл нь системийн урсгалаар тодорхойлогдсон байдаг.<br />19<br />
    20. 20. SAD – Analysis phase (Cont.)<br />Логик шаардлагууд (logical modeling)<br />Шийдвэрийн хүснэгт болон шийдвэрийн мод хэрэглэх<br />Бүтэцлэгдсэн системийн өгөгдлийн шаардлагууд<br />ER diagram-обьектийн холбоосын диаграм<br />20<br />
    21. 21. SAD – Analysis phase (Cont.)<br />B. Загварчилгааны үе<br />Өгөгдлийн баазын загвар (DB normalization)<br />Формууд болон тайлангийн загвар (GUI design)<br />21<br />
    22. 22. DB Normalization-ӨБ-ийг энгийн хэлбэрт шилжүүлэх<br /><ul><li>ªãºãäëèéãýíãèéíõýëáýðòøèëæ¿¿ëýõ - îáúåêòèéíõîëáîîñûíøèíæèëãýý
    23. 23. ÎÕ øèíæèëãýýíü ªÑÑ-èéãäýýðýýñäîîøíü (Top-Down) çàäëàæøèíæëýõàðãà
    24. 24. ýõëýýäñèñòåìèéíîáúåêò¿¿äèéãòîäîðõîéëäîã
    25. 25. äàðààíüîáúåêò¿¿äýýàòðèáóòûíòºâøèíäçàäëàäàã.</li></ul>1-ð ýíãèéíõýëáýð<br /><ul><li>Äàâòàãäñàí á¿ëýã ýëåìåíò ñàëãàõ
    26. 26. Òýã óòãàò ýëåìåíòèéã ñàëãàõ
    27. 27. Äàâòàãäñàí óòãàòàé ýëåìåíò ñàëãàõ
    28. 28. Áàéæ áîëîõ ò¿ëõ¿¿ðèéã òîäîðõîéëîõ</li></ul>2-ð ýíãèéíõýëáýð<br /><ul><li>Ýëåìåíòõîîðîíäûí ôóíêöèîíàëü õàìààðëûã òîäîðõîéëîõ
    29. 29. Ôóíêöèîíàëü á¿ðýí õàìààðëûã òîäîðõîéëîõ
    30. 30. Ôóíêöèîíàëü á¿ðýí áóñ õàìààðàëòàé ýëåìåíòèéã ñàëãàõ</li></ul>3-ð ýíãèéíõýëáýð<br /><ul><li>Äàìæñàíõîëáîîñûãñàëãàõ</li></ul>22<br />
    31. 31. Object Oriented Analysis and Design-Обьект хандалтат шинжилгээ ба зохиомж<br />OOAD<br />23<br />
    32. 32. Object-Oriented Analysis and Design (OOAD)<br />Обьектууд нь өгөгдөл болон процессуудад үндэслэгддэг.<br />Object: a structure encapsulating attributes and behaviors of a real-world entity<br />24<br />
    33. 33. Outline <br />SAD Phases<br />OOAD Phases<br />SAD vs. OOAD software development <br />Adopted Books<br />UML in practice <br />Conclusions & Recommendations <br />25<br />
    34. 34. OOSAD textbook<br />A. Шинжилгээний үе<br />Бүтэцлэгдсэн шаардлагууд (Use cases)<br />Схемчилсэн өгөгдлийн загвар (class diagram)<br />Обьектын холбоосын загвар<br />Class diagram -> ER diagram <br />Шинжилгээний классууд<br />Class stereotypes<br />Sequence diagram<br />Communication diagram <br /> Activity diagram<br />State machine diagram<br />26<br />
    35. 35. OOSAD textbook<br />B. Зохиомжын үе<br />Физик ӨБ-ийн загвар<br />Загварчилгааны элементүүд<br />Design classes<br />Design components <br />Design system Architecture<br />GUI design<br />27<br />
    36. 36. Learning UML textbook<br />Focus on 4+1 view architecture <br />28<br />Системийн логик бүтцийн загварлaл: Classes and Class, Sequence State Machine Diagrams<br />Шаардлагын загварчлал:<br />Use Cases<br />Системийн ажлын урсгалын загварчлал:<br />Activity Diagrams<br />Системийн хэсгүүдийг удирдах болон дахин ашиглалт: Component, Package, Deployment, Diagrams<br />
    37. 37. OOAD project phases<br />Analysis<br />Шаардлага цуглуулах, шинжилгээ болон загварчлал (Шаардлагын инженерчлэл /Requirement Engineering/<br />Use Case загвар Case-үүдээ илрүүлэх, үйл явдлын урсгал, үйл ажиллагааны диаграм<br />Обьектын загвар<br />Классуудыг илрүүлэх болон холбоосыг тодорхойлох<br />Обьектын харилцан үйлчлэл: Sequence & collaboration Diagram, State Machine Diagram, <br />ОХД байгуулах/Object to ER Mapping/<br />Design<br />Өгөгдлийн баазын физик загвар <br />Загварын элементүүд<br />Системийн загварын архитектур<br />Классуудын загвар: Загварчилгааг шалгах, классуудыг нэгтгэх, классуудыг задлах, классуудыг устгах<br />Загварчилгааны бүрэлдэхүүн хэсгүүд<br />Хэрэглэгчийн интерфейс загвар<br />29<br />
    38. 38. Use Case жишээнүүд<br />30<br />
    39. 39. Оюутны бүртгэлийн системийн Use case диаграм<br />31<br />
    40. 40. Billing system- Тооцооны систем<br />Roster-жагсаалт<br />Maintain-хадгалах<br />Registrar-бүртгэгч<br />
    41. 41. Use Case: Эмнэлэгийн системийн жишээ<br />33<br />
    42. 42. Appointment-тов<br />Defer-сунгах, хойшлуулах<br />Extension point<br />Generalization-нэгтгэл<br />Clerk-ажилтан<br />Treatment-эмчилгээ<br />Boundary- хил хязгаар<br />
    43. 43. Use Case: Банкны системийн жишээ<br />35<br />
    44. 44. Үйл ажиллагааны диаграмын жишээнүүд<br />36<br />
    45. 45. Create <br />curriculum<br />Select courses <br />to teach<br />Create <br />Бүртгэлийн системийн үйл ажиллагааны диаграм<br />Registrar<br />Professor<br />catalog<br />Mail catalog <br />Place catalog <br />to students<br />in bookstore<br />Open <br />registration<br />[ Registration time period expired ]<br />Swimlanes<br />Close <br />registration<br />37<br />
    46. 46. 38<br />Үйл ажиллагааны диаграм:Банкны систем<br />
    47. 47. Notify-мэдүүлэх<br />Approach-хандах<br />39<br />
    48. 48. Үйл ажиллагааны диаграм: Бараа нийлүүлэх систем<br />40<br />
    49. 49. Fill order-Захиалга бэлтгэх<br />Ship order-Захиалга илгээнэ<br />Send invoice-нэхэмжлэл явуулна<br />Make payment-төлбөр хийнэ<br />Accept payment-төлбөр хүлээн авах<br />41<br />
    50. 50. Finding classes (thinking in objects)(Registration System)<br />42<br />Boundary class (GUI interface)<br />Entity class<br />Control class<br />RegistrationManager<br />Entity class<br />Course<br />addStudent(Course, Student)<br />name<br />numberCredits<br />open()<br />addStudent(Student)<br />
    51. 51. Class relations: Удамшил/Inheritance and Multiplicity(Registration System)<br />0..*<br />1<br />1<br />0..*<br />1<br />3..10<br />4<br />1..*<br />1<br />0..4<br />ScheduleAlgorithm<br />RegistrationForm<br />RegistrationManager<br />addStudent(Course, Student)<br />Course<br />name<br />RegistrationUser<br />numberCredits<br />name<br />Student<br />open()<br />addStudent(Student)<br />major<br />Professor<br />CourseOffering<br />tenureStatus<br />location<br />open()<br />addStudent(Student}<br />Tenure-албан тушаал<br />
    52. 52. Холбоосууд<br />Гурван төрлийн холбоос байдаг.<br />Association-нэгдэл<br />Aggregation-бүрдмэл<br />Dependency-хараат<br />44<br />
    53. 53. Нэг классын обьектууд бусад классын обьектуудтай харилцан үйлчлэлцэх <br />Нэг классын обьектууд бусад классын обьектуудтай урт хугацааны турш харилцан үйлчлэлцэх <br />Нэг класс нь зарим үед холбоо хамааралаа ашиглах үед<br />Нэг класс нь бусад классын обьектийг агуулж байгаа үед<br />Нэг класс нь бусад классын төрөл болж байгаа үед<br />45<br />
    54. 54. Обьект хандалтат өргөтгөлүүдийн холбоосын загвар<br />Generalization-Ерөнхийлөл<br />Multivalued attributes (OK to violate atomicity requirement of 1NF)-олон утгатай шинж чанар<br />Aggregation<br />Object identifiers-обьект тодорхойлогчид<br />Pointers-заагчид<br />Behaviors-шинж чанар<br />Richer set of data types-өгөгдлийн төрлүүдийн олонлог<br />Object-relational Data Model<br />46<br />
    55. 55. Үндсэн өгөгдлийн загварыг ОХЗагвар руу хөрвүүлэх<br />Классуудыг хөрвүүлэх<br />Холбоосуудыг хөрвүүлэх<br />Normalize object relations<br />Обьектын холбоосуудыг нэгтгэх<br />47<br />
    56. 56. Supertype/subtype relationships<br />48<br />
    57. 57. Mapping Supertype/subtype relationships to relations<br />These are implemented as one-to-one relationships<br />49<br />
    58. 58. Sequence Diagram<br />registration <br />registration <br />math 101<br /> : Student<br />form<br />manager<br />math 101 <br />section 1<br />1: fill in info<br />2: submit<br />3: add student to math 101<br />4: add student<br />5: are you open?<br />6: add student<br />A sequence diagram displays object interactions arranged in a time sequence<br />50<br />
    59. 59. 51<br />public class MessageReceiver<br />{<br />public void foo( )<br /> {<br /> // Do something inside foo.<br /> }<br />}<br />public class MessageCaller<br />{<br /> private MessageReceivermessageReceiver;<br /> // Other Methods and Attributes of the class are declared here<br /> // The messageRecevier attribute is initialized elsewhere in<br /> // the class.<br /> public doSomething(String[] args)<br /> {<br /> // The MessageCaller invokes the foo( ) method<br />this.messageReceiver.foo( ); // then waits for the method to return<br /> // before carrying on here with the rest of its work<br /> }<br />}<br />
    60. 60. Collaboration Diagram<br />course form : <br />1: set course info<br />CourseForm<br />2: process<br />3: add course<br /> : Registrar<br />theManager : <br />aCourse : <br />CurriculumManager<br />Course<br />4: new course<br />A collaboration diagram displays object interactions organized around objects and their links to one another<br />52<br />
    61. 61. 53<br />
    62. 62. 54<br />
    63. 63. Sequence Diagram for Bank System<br />55<br />
    64. 64. State Machine Diagram<br />56<br />
    65. 65. 57<br />State Machine Diagram<br />
    66. 66. 58<br />Showing Components Working Together<br />
    67. 67. 59<br />Focusing on the key components and interfaces in your system<br />Focusing on component dependencies and the manifesting artifacts is useful when you are trying control the configuration or deployment of your system<br />
    68. 68. 60<br />Assembly connectors show components working together through interfaces<br />
    69. 69. System Architecture <br />61<br />
    70. 70. Key Differences Between Structured and Object-Oriented Analysis and Design<br />62<br />
    71. 71. Software Engineering textbookMain topics <br />INTRODUCTION<br />Socio-technical System<br />Emergent property<br />REQUIREMENTS ENGINEERING<br />Systems Models<br />DESIGN<br />Architectural Design<br />Application Architectures<br />Object-oriented Design<br />Real-time Systems<br />User Interface Design<br />SOFTWARE DEVELOPMENT<br />Iterative SW Development<br />SW Reuse<br />CBSE<br />Critical Systems Development<br />Software Evolution<br />VALIDATION<br />Verification and Validation<br />Software Testing<br />Critical Systems Validation<br />MANAGEMENT<br />Software Cost Estimation<br />Quality Management<br />
    72. 72. Software Engineering textbookMain topics (Cont.)<br />EMERGING TECHNOLOGIES<br />Security Engineering<br />Service-oriented Software Engineering<br />Aspect-oriented Software Development<br />
    73. 73. Software Engineering textbookSystem categories<br />Technical computer-based systems<br />Systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. <br />The system is not self-aware.<br />Socio-technical systems<br />Systems that include technical systems but also operational processes and peoplewho use and interact with the technical system. <br />Socio-technical systems are governed by organisational policies and rules.<br />
    74. 74. Software Engineering textbookSocio-technical system characteristics<br />Emergent properties<br />Properties of the system of a whole that depend on the system components and their relationships.<br />Non-deterministic<br />They do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators.<br />Complex relationships with organisational objectives<br />The extent to which the system supports organisational objectives does not just depend on the system itself.<br />
    75. 75. Software Engineering textbookTypes of emergent property<br />Functional properties <br />These appear when all the parts of a system work togetherto achieve some objective. <br />For example, a bicycle has the functional property of being a transportationdevice once it has been assembled from its components.<br />Non-functional emergent properties<br />Examples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment.<br />They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.<br />
    76. 76. Software Engineering textbookThe systems engineering process<br />
    77. 77. Software Engineering textbookInter-disciplinary involvement<br />
    78. 78. Software Engineering textbookSystem Models<br />Context models <br />Blocks (box diagram of subsystems)<br />DFDs can be used<br />Behavioural models<br />Blocks (box diagram of subsystems)<br />Two types of behavioral model are:<br />Data processing models that show how data is processed as it moves through the system (DFD)<br />State machine models that show the systems response to events.<br />Data models DFDs<br />Object models<br />Inheritance models<br />Aggregation models<br />Interaction models<br />70<br />
    79. 79. Key Differences Between Structured and Object-Oriented Analysis and Design<br />71<br />
    80. 80. Papers <br />72<br />In practice - UML software architecture and design description, IEEE Software, 2006<br />The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.<br />A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.<br />
    81. 81. Papers <br />73<br />In practice - UML software architecture and design description, IEEE Software, 2006<br />
    82. 82. Practitioner reflections on UML use<br />2+ month period, 80 architects participated. <br />major responsibilities among respondents:<br />analysis (66 %),<br />design (66 %),<br />specification (61 %), and<br />programming (52 %).<br />The respondents came from different application domains.<br />Most worked in information systems (61 %)<br />28 % worked in embedded systems<br />a few worked in tool and operating systems development. <br />60% worked in projects of more than 5 person-years.<br />74<br />
    83. 83. Survey respondents’ use of UML for 4+1 architectural views<br />75<br />
    84. 84. Survey respondents’ assessment of their adherence to the UML standard.<br />76<br />
    85. 85. Deadline vs. completeness as stopping criteria for different project sizes.<br />77<br />
    86. 86. Problems encountered due to incomplete models correlated to respondent demographic data regarding project size.<br />78<br />
    87. 87. Problems with UML descriptions<br />Scattered information:Design choices are scattered over multiple views.<br />some dependencies might show up in the logical view, while others appear in the process view.<br />Incompleteness:The architects focus on what they think is important.<br />Inconsistency. <br />UML-based software development is inevitably inconsistent. <br />Industrial systems are typically developed by teams.<br />Different teams can have different understandings of the system as well as different modeling styles, and this can lead to inconsistent models.<br />79<br />
    88. 88. Other problem classes include the following:<br />Diagram quality. UML lets architects represent one design in different ways. <br />they can decompose a diagram that contains too many elements into several smaller diagrams. <br />they can influence how easy the model is to understand and how it gets interpreted.<br />Informal use. <br />Architects sometimes use UML in a very sketchy manner. <br />These diagrams deviatefrom official UML syntax, making their meaning ambiguous.<br />Lack of modeling conventions. <br />case studies show that engineers use UML according to individual habits. <br />These habits might include layout conventions, commenting, visibility of methods and operations, and consistency between diagrams.<br />80<br />
    89. 89. Defects in industrial UML models<br />Subjectiveimpression obtained via the survey<br />Objectivemeasurements about the quality of industrial UML models. (14 case studies of different sizes from various organizations and application domains)<br />81<br />
    90. 90. Defects found in the case studies<br />Methods that are not called in sequence diagrams<br />Classes not occurring in sequence diagrams<br />Objects without names<br />Messages not corresponding to methods<br />Classes without methods<br />82<br />
    91. 91. Papers <br />83<br />The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006. <br />
    92. 92. It is important to investigate the benefits obtained from modeling. <br />this paper reports on controlled experiments, spanning two locations, that investigate the impact of UML documentation on software maintenance. <br />Results show that: <br />for complex tasks and past a certain learning curve, the availability of UML documentation may result in significant improvements in the functional correctness of changes as well as the quality of their design.<br />there does not seem to be any saving of time. For simpler tasks, the time needed to update the UML documentation may be substantialcompared with the potential benefits, thus motivating the need for UML tools with better support for software maintenance<br />84<br />
    93. 93. 85<br />
    94. 94. 86<br />
    95. 95. Experimental results<br />The goal was to shed some light on the cost effectiveness of model-driven development with UML. <br />focused on whether models help software engineers to make quicker and better changes to existing systems. <br />The results of the two experiments are mostly consistent. <br />When considering only the time required to make code changes, using UML documentation does help to save effort overall. <br />On the other hand, when including the time necessary to modify the diagrams, no savings in effort are visible. <br />in terms of the functional correctness of the changes:<br />using UML has a significant, positive impact on the most complex tasks.<br />In the Ottawa experiment, which also investigated the design of the changes, using UML helped to achieve changes with superior design quality, which would then be expected to facilitate future, subsequent changes.<br />the above statements apply only with qualifications.<br />Benefits are not likely to be derived if the tasks to be performed lie belowa certain level of complexityor if software engineers have not reached a certain level of skill regarding the use of UML models for analyzing the effects of changes, in addition to having received substantial training in UML modeling. <br />Furthermore, current tools still need substantial improvements in the way they support changes to models and the checking of consistency.<br />87<br />
    96. 96. Papers <br />88<br />A Realistic Empirical Evaluation of the Costsand Benefitsof UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.<br />
    97. 97. The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling.<br />few empirical studies exist which investigate the costsand evaluate the benefitsof using UML in realistic contexts. <br />Such studies are needed so that the software industry can make informed decisions regarding the extent to which they should adopt UML in their development practices. <br />89<br />
    98. 98. This is the first controlled experiment that investigates the costs of maintaining and the benefits of using UML documentation during the maintenance and evolution of a real nontrivial system, using professionaldevelopersas subjects, working with a state-of-the-art UML tool during an extended period of time. <br />Control Group: had no UML documentation<br />UML Group: had UML documentation.<br />had, on average, a practically and statistically significant 54% increase in the functional correctness of changes (p = 0.03)<br />insignificant 7% overall improvement in design quality (p = 0.22)<br />90<br />
    99. 99. 91<br />
    100. 100. Selection of Subjects<br />Subjects were recruited via a request for consultants being sent to Norwegian consulting companies. The request specified a flexible range of time, for which the consultants would be needed, along with the required education and expertise. Companies replied with resume of potential candidates and these were then screened to verify that they indeed complied with the requirements. The subjects were required to at least have a bachelor’s degree in informatics (or its equivalent), some familiarity with UML (use case, class, sequence, and state diagrams), and some project experience with the following technologies: Struts, JavaServerPages (JSP), Java 2, HTML, the Eclipse IDE, and MySQL.<br />Note that the recruitment of all subjects could not be completed before the start of the experiment. This was due to several practical reasons:<br />The market for these skilled professionals is very tight.<br />We could not give the consulting companies definite start and end dates as to when the consultant would be working.<br />The consulting companies could not give us an exact start date for consultants<br />The consulting companies often could not guarantee that the consultant would be available.<br />92<br />
    101. 101. 93<br />10 no UML<br />10 UML<br />
    102. 102. 94<br />
    103. 103. 95<br />
    104. 104. 96<br />
    105. 105. Experimental results <br />97<br />
    106. 106. In terms of time, the UML subjects used more time if the UML docs was to be updated (though slightly less if it were not). <br />With the total time T that the subjects spent on the five tasks, we see that <br /><ul><li>the UML group completed the tasks slightly faster (1.4%) than the no-UML group.
    107. 107. This difference is not practically or statistically significant. </li></ul>Taking the time that it takes to update the UML docs into account:<br /><ul><li>UML group spent 14.5% more time on the five tasks, though this difference is not statistically significant either and may therefore be due to chance. </li></ul>On average, the UML subjects spent 14.8% of the total time reading the UML docs and 13.2% updating the docs.<br />98<br />
    108. 108. UML was always beneficial in terms of functional correctness (introducing fewer faults into the sw).<br />The subjects in the UML group had, on average, a practically and statistically significant 54% increase in the functional correctness of changes (p= 0.03)<br />UML also helped produce code of better quality when the developers were not yet familiar with the system. <br />A significant difference was found for Task 1, where the UML group’s design quality score was 56.2% higher (p= 0.0025) though, across all the tasks, there was an insignificant % improvement in design quality p = (0.22)<br />99<br />
    109. 109. All of the qualitative evidence suggests that the observed impact of UML on change quality and productivity is probably very conservative in this experiment. <br />The UML subjects were at a disadvantage when it came to Struts experience and familiarity with Java. <br />We also observed that half of the subjects only used two diagram types, with the use case and sequence diagrams being, by far, the most used. <br />Four of the subjects did not use the UML to the extent that they could have due to concern that UML would make them less efficient and out of habit (not being used to using UML). <br />The subjects also experienced severe problems when dealing with the tool and in understanding the large sequence and class diagrams. However, the qualitative evidence also explains the observed benefits of UML. <br />The no-UML group had more problems in understanding a complex part of the system.<br />100<br />
    110. 110. All subjects found the UML to be generally useful: The largest benefits were the traceability of use cases to code and the ability to quickly get an overview of the system.<br />The results of this experiment, both qualitative and quantitative, can also be used to guide industrial adoption with respect to, at the very least, applications with similar properties (e.g., Web applications). <br />In the case of developers who are not very experienced in using UML and who will perform maintenance tasks on a system that they are not familiar with, the use case diagram and the sequence diagrams seem to be the most cost-efficient parts of UML. This appears to be the case for two reasons. <br />First, developers inexperienced with UML are overwhelmed by too many diagram types and will only use those that are easy to use. <br />Next, these two diagrams help them quickly identify the relevant code for the specific functionality needed to perform the maintenance tasks. Given these advantages, these two types of diagrams can also be considered a cost-efficient starting point for introducing UML into the organization.<br />101<br />
    111. 111. What is the situation of swdev many companies?<br />No diagrams or models or even ER diagram at all !!<br />Why?!!!:<br />It is time consuming !!!! <br />1 developer performs all tasks (analysis, design, implementation) <br />What are artifacts that delivered to developers:<br />Psuedocode (can be consider as structured English)<br />Screens <br />Steps for sw developments:<br />Create DB with required information<br />Map tables to forms (GUI) / web pages<br />102<br />
    112. 112. Conclusions & Recommendations <br />103<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×