The document compares structured analysis and design (SAD) and object-oriented analysis and design (OOAD) approaches. For SAD, it discusses phases like requirements analysis using data flow diagrams and entity relationship diagrams, logical design, and physical design. For OOAD, it discusses phases like use case modeling, class diagrams, sequence diagrams, and designing the physical database and system architecture. It provides an outline of key differences and similarities between the two approaches and lists some textbooks on SAD, OOAD and the Unified Modeling Language (UML).

1. Structured vs. Object Orient Analysis and DesignSAD vs. OOSADMotaz K. Saad May 2010

2. Outline Бүтэцлэгдсэн шинжилгээний үеОбьект хандалтат шинжилгээний үеБүтэцлэгдсэн шинжилгээний хөгжүүлэлт болон ОХШЗ-оор програм хангамж хөгжүүлэхАшигласан номуудUML-ийн хэрэглээДүгнэлт & үнэлгээ2

3. TextbooksModern Systems Analysisand Design6th EditionJeffrey Hoffer Joey GeorgeJoseph Valacich3Object Oriented Systems Analysis and Design 2nd edition Joey GeorgeDinesh BatraJoseph ValacichJeffrey HofferSoftware Engineering8th , 9th edition Lan SummervilleLearning UML 2.0, By Kim Hamilton, Russell Miles, O'Reilly, 2006.Visual Modeling with Rational Rose 2002 and UML, 3/E, by Terry Quatrani

4. Key Differences Between Structured and Object-Oriented Analysis and Design4

5. SW Project phases Any project in the world has the following phases:PlanningAnalysis: system requirements are studied and structuredDesign: recommended solution is converted into logical and then physical system specificationsLogical design – all functional features of the system chosen for development in analysis are described independently of any computer platform 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 accomplishedImplementationTesting Maintenance 5

6. Structured Analysis and design (SAD)A. Шинжилгээний үеСистемийн шаардлага тодорхойлохБүтэцлэгдсэн процессийн шаардлага тодорхойлохЛогик шаардлагууд(logical modeling)Бүтэцлэгдсэн системийн өгөгдлийн шаардлагуудB. Зохиомжын үеӨгөгдлийн баазын дизайнФормууд болон тайлангийн загварууд 6

7. Structured Analysis and design (SAD)A. Шинжилгээний үеСистемийн шаардлагуудыг тодорхойлох:Ярилцлага: Ганцаарчилсан эсвэл группээрБүтэцлэгдсэн процессийн шаардлага тодорхойлох:Data Flow Diagram (DFD) – логик процессийн загварDFD levels (процессийн задралууд)Context diagram-ерөнхий диаграмм 4 type of DFDФизик урсгал: элементэд тохирсонЛогик урсгал:системийн урсгалуудыг тодорхойлох7

8. DFD SymbolsComparison of DeMarco and Yourdonand Gane and Sarson DFD symbol sets8Process-процессData store- өгөгдлийн файлSource/sink-эх сурвалжData flow- өгөгдлийн урсгал

9. Өгөгдлийн урсгалын диаграмContext-level data flow diagram showing project scope for Purchasing Fulfillment System (Pine Valley Furniture)9

10. 10Suppliers-нийлүүлэгчидProduction schedulers-бүтээгдэхүүн хуваарилагчидPurchasing fulfillment system- бөөний худалдааны системQuotes-Үнэлгээ, тоо хэмжээShipment-бараа нийлүүлэх

11. Context Diagram-Ерөнхий диаграмContext diagram of Hoosier Burger’s food-ordering system11

12. Developing DFDs (Cont.)Level-0 diagram нь системийн үндсэн процессыг үзүүлдэг ба үүнд өгөгдлийн урсгалууд, өгөгдөл хадгалах дээд түвшний элементүүд байна. Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs.12

13. Level-0 Diagram13Level-0 DFD of Hoosier Burger’s food-ordering system

14. Sold-зарагдсанInventory-бараа материал, нөөцTransform-өөрчлөхDepletion-дууссан14

15. Data Flow Diagramming Rules15ªãºãäëèéíÓðñãàëûíÄèàãðàìì (ªÓÄ) íüîðøèíáóéáîäèòñèñòåìýñâýëøèíýíýâòð¿¿ëýõãýæáóéáîäèòñèñòåìèéíàëèíûõíü÷á¿ðýíòºãñèëýðõèéëýëáîëæ÷àäàõã¿é. Ó÷èðíüçàãâàðò ºãºãäëèéãõàäãàëàõáîëîí 纺õ ôèçèêïðîöåññ, ïðîöåññèéãã¿éöýòãýíèëýðõèéëýõõ¿íìàøèí, ºãºãäºëõàäãàëàõõýðýãñýëáîëîíÿìàðíýãàëäààøàëãàõïðîöåññóóäûãòóñãàäàãã¿é. Ãýòýëáîäèòñèñòåìäýäãýýð õ¿÷èíç¿éë¿¿ä çàéëøã¿éõýðýãòýé. ªãºãäëèéíÓðñãàëûíÄèàãðàìì (ªÓÄ)-èéí ¿ð ä¿íäãàðàõýíýîíöãîéçàãâàðíüçºâõºí ÞÓ õèéãäýõ ¸ñòîéã ¿ç¿¿ëýõýýñáóñ ÕÝÐÕÝÍ õèéõèéãàâ÷ ¿çýõã¿é.

16. Level-1 DFDLevel-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s food-ordering systemLevel-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD.This is a Level-1 DFD for Process 4.0.Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary.16

17. Aggregate-иж бүрдэл, нийт дүн17

18. 18Level-n DFDLevel-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering systemLevel-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD.This is a Level-2 DFD for Process 4.3.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.Format-Хэлбэр, хэмжээ

19. ӨУД-ийн 2 төрөлФизик урсгалПроцессийн түвшинүүд нь тодорхой дараалалтай бөгөөд энэ нь өгөгдлийг боловсруулдаг.Өгөгдлийн урсгалууд болон өгөгдөл хадгалах хэрэгсэлүүдийг физик нэрээр нь тодорхойлж болдог. Логик урсгалӨгөгдөл болон процессуудын мэдээлэл нь системийн урсгалаар тодорхойлогдсон байдаг.19

20. SAD – Analysis phase (Cont.)Логик шаардлагууд (logical modeling)Шийдвэрийн хүснэгт болон шийдвэрийн мод хэрэглэхБүтэцлэгдсэн системийн өгөгдлийн шаардлагуудER diagram-обьектийн холбоосын диаграм20

21. SAD – Analysis phase (Cont.)B. Загварчилгааны үеӨгөгдлийн баазын загвар (DB normalization)Формууд болон тайлангийн загвар (GUI design)21

22. DB Normalization-ӨБ-ийг энгийн хэлбэрт шилжүүлэхªãºãäëèéãýíãèéíõýëáýðòøèëæ¿¿ëýõ - îáúåêòèéíõîëáîîñûíøèíæèëãýý

23. ÎÕ øèíæèëãýýíü ªÑÑ-èéãäýýðýýñäîîøíü (Top-Down) çàäëàæøèíæëýõàðãà

24. ýõëýýäñèñòåìèéíîáúåêò¿¿äèéãòîäîðõîéëäîã

25. äàðààíüîáúåêò¿¿äýýàòðèáóòûíòºâøèíäçàäëàäàã.1-ð ýíãèéíõýëáýðÄàâòàãäñàí á¿ëýã ýëåìåíò ñàëãàõ

26. Òýã óòãàò ýëåìåíòèéã ñàëãàõ

27. Äàâòàãäñàí óòãàòàé ýëåìåíò ñàëãàõ

28. Áàéæ áîëîõ ò¿ëõ¿¿ðèéã òîäîðõîéëîõ2-ð ýíãèéíõýëáýðÝëåìåíòõîîðîíäûí ôóíêöèîíàëü õàìààðëûã òîäîðõîéëîõ

29. Ôóíêöèîíàëü á¿ðýí õàìààðëûã òîäîðõîéëîõ

30. Ôóíêöèîíàëü á¿ðýí áóñ õàìààðàëòàé ýëåìåíòèéã ñàëãàõ3-ð ýíãèéíõýëáýðÄàìæñàíõîëáîîñûãñàëãàõ22

31. Object Oriented Analysis and Design-Обьект хандалтат шинжилгээ ба зохиомжOOAD23

32. Object-Oriented Analysis and Design (OOAD)Обьектууд нь өгөгдөл болон процессуудад үндэслэгддэг.Object: a structure encapsulating attributes and behaviors of a real-world entity24

33. Outline SAD PhasesOOAD PhasesSAD vs. OOAD software development Adopted BooksUML in practice Conclusions & Recommendations 25

34. OOSAD textbookA. Шинжилгээний үеБүтэцлэгдсэн шаардлагууд (Use cases)Схемчилсэн өгөгдлийн загвар (class diagram)Обьектын холбоосын загварClass diagram -> ER diagram Шинжилгээний классуудClass stereotypesSequence diagramCommunication diagram Activity diagramState machine diagram26

35. OOSAD textbookB. Зохиомжын үеФизик ӨБ-ийн загварЗагварчилгааны элементүүдDesign classesDesign components Design system ArchitectureGUI design27

36. Learning UML textbookFocus on 4+1 view architecture 28Системийн логик бүтцийн загварлaл: Classes and Class, Sequence State Machine DiagramsШаардлагын загварчлал:Use CasesСистемийн ажлын урсгалын загварчлал:Activity DiagramsСистемийн хэсгүүдийг удирдах болон дахин ашиглалт: Component, Package, Deployment, Diagrams

37. OOAD project phasesAnalysisШаардлага цуглуулах, шинжилгээ болон загварчлал (Шаардлагын инженерчлэл /Requirement Engineering/Use Case загвар Case-үүдээ илрүүлэх, үйл явдлын урсгал, үйл ажиллагааны диаграмОбьектын загварКлассуудыг илрүүлэх болон холбоосыг тодорхойлохОбьектын харилцан үйлчлэл: Sequence & collaboration Diagram, State Machine Diagram, ОХД байгуулах/Object to ER Mapping/DesignӨгөгдлийн баазын физик загвар Загварын элементүүдСистемийн загварын архитектурКлассуудын загвар: Загварчилгааг шалгах, классуудыг нэгтгэх, классуудыг задлах, классуудыг устгахЗагварчилгааны бүрэлдэхүүн хэсгүүдХэрэглэгчийн интерфейс загвар29

38. Use Case жишээнүүд30

39. Оюутны бүртгэлийн системийн Use case диаграм31

40. Billing system- Тооцооны системRoster-жагсаалтMaintain-хадгалахRegistrar-бүртгэгч

41. Use Case: Эмнэлэгийн системийн жишээ33

42. Appointment-товDefer-сунгах, хойшлуулахExtension pointGeneralization-нэгтгэлClerk-ажилтанTreatment-эмчилгээBoundary- хил хязгаар

43. Use Case: Банкны системийн жишээ35

44. Үйл ажиллагааны диаграмын жишээнүүд36

45. Create curriculumSelect courses to teachCreate Бүртгэлийн системийн үйл ажиллагааны диаграмRegistrarProfessorcatalogMail catalog Place catalog to studentsin bookstoreOpen registration[ Registration time period expired ]SwimlanesClose registration37

46. 38Үйл ажиллагааны диаграм:Банкны систем

47. Notify-мэдүүлэхApproach-хандах39

48. Үйл ажиллагааны диаграм: Бараа нийлүүлэх систем40

49. Fill order-Захиалга бэлтгэхShip order-Захиалга илгээнэSend invoice-нэхэмжлэл явуулнаMake payment-төлбөр хийнэAccept payment-төлбөр хүлээн авах41

50. Finding classes (thinking in objects)(Registration System)42Boundary class (GUI interface)Entity classControl classRegistrationManagerEntity classCourseaddStudent(Course, Student)namenumberCreditsopen()addStudent(Student)

51. Class relations: Удамшил/Inheritance and Multiplicity(Registration System)0..*110..*13..1041..*10..4ScheduleAlgorithmRegistrationFormRegistrationManageraddStudent(Course, Student)CoursenameRegistrationUsernumberCreditsnameStudentopen()addStudent(Student)majorProfessorCourseOfferingtenureStatuslocationopen()addStudent(Student}Tenure-албан тушаал

52. ХолбоосуудГурван төрлийн холбоос байдаг.Association-нэгдэлAggregation-бүрдмэлDependency-хараат44

53. Нэг классын обьектууд бусад классын обьектуудтай харилцан үйлчлэлцэх Нэг классын обьектууд бусад классын обьектуудтай урт хугацааны турш харилцан үйлчлэлцэх Нэг класс нь зарим үед холбоо хамааралаа ашиглах үедНэг класс нь бусад классын обьектийг агуулж байгаа үедНэг класс нь бусад классын төрөл болж байгаа үед45

54. Обьект хандалтат өргөтгөлүүдийн холбоосын загварGeneralization-ЕрөнхийлөлMultivalued attributes (OK to violate atomicity requirement of 1NF)-олон утгатай шинж чанарAggregationObject identifiers-обьект тодорхойлогчидPointers-заагчидBehaviors-шинж чанарRicher set of data types-өгөгдлийн төрлүүдийн олонлогObject-relational Data Model46

55. Үндсэн өгөгдлийн загварыг ОХЗагвар руу хөрвүүлэхКлассуудыг хөрвүүлэхХолбоосуудыг хөрвүүлэхNormalize object relationsОбьектын холбоосуудыг нэгтгэх47

56. Supertype/subtype relationships48

57. Mapping Supertype/subtype relationships to relationsThese are implemented as one-to-one relationships49

58. Sequence Diagramregistration registration math 101 : Studentformmanagermath 101 section 11: fill in info2: submit3: add student to math 1014: add student5: are you open?6: add studentA sequence diagram displays object interactions arranged in a time sequence50

59. 51public class MessageReceiver{public void foo( ) { // Do something inside foo. }}public class MessageCaller{ private MessageReceivermessageReceiver; // Other Methods and Attributes of the class are declared here // The messageRecevier attribute is initialized elsewhere in // the class. public doSomething(String[] args) { // The MessageCaller invokes the foo( ) methodthis.messageReceiver.foo( ); // then waits for the method to return // before carrying on here with the rest of its work }}

60. Collaboration Diagramcourse form : 1: set course infoCourseForm2: process3: add course : RegistrartheManager : aCourse : CurriculumManagerCourse4: new courseA collaboration diagram displays object interactions organized around objects and their links to one another52

61. 53

62. 54

63. Sequence Diagram for Bank System55

64. State Machine Diagram56

65. 57State Machine Diagram

66. 58Showing Components Working Together

67. 59Focusing on the key components and interfaces in your systemFocusing on component dependencies and the manifesting artifacts is useful when you are trying control the configuration or deployment of your system

68. 60Assembly connectors show components working together through interfaces

69. System Architecture 61

70. Key Differences Between Structured and Object-Oriented Analysis and Design62

71. Software Engineering textbookMain topics INTRODUCTIONSocio-technical SystemEmergent propertyREQUIREMENTS ENGINEERINGSystems ModelsDESIGNArchitectural DesignApplication ArchitecturesObject-oriented DesignReal-time SystemsUser Interface DesignSOFTWARE DEVELOPMENTIterative SW DevelopmentSW ReuseCBSECritical Systems DevelopmentSoftware EvolutionVALIDATIONVerification and ValidationSoftware TestingCritical Systems ValidationMANAGEMENTSoftware Cost EstimationQuality Management

72. Software Engineering textbookMain topics (Cont.)EMERGING TECHNOLOGIESSecurity EngineeringService-oriented Software EngineeringAspect-oriented Software Development

73. Software Engineering textbookSystem categoriesTechnical computer-based systemsSystems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware.Socio-technical systemsSystems that include technical systems but also operational processes and peoplewho use and interact with the technical system. Socio-technical systems are governed by organisational policies and rules.

74. Software Engineering textbookSocio-technical system characteristicsEmergent propertiesProperties of the system of a whole that depend on the system components and their relationships.Non-deterministicThey do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators.Complex relationships with organisational objectivesThe extent to which the system supports organisational objectives does not just depend on the system itself.

75. Software Engineering textbookTypes of emergent propertyFunctional properties These appear when all the parts of a system work togetherto achieve some objective. For example, a bicycle has the functional property of being a transportationdevice once it has been assembled from its components.Non-functional emergent propertiesExamples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment.They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.

76. Software Engineering textbookThe systems engineering process

77. Software Engineering textbookInter-disciplinary involvement

78. Software Engineering textbookSystem ModelsContext models Blocks (box diagram of subsystems)DFDs can be usedBehavioural modelsBlocks (box diagram of subsystems)Two types of behavioral model are:Data processing models that show how data is processed as it moves through the system (DFD)State machine models that show the systems response to events.Data models DFDsObject modelsInheritance modelsAggregation modelsInteraction models70

79. Key Differences Between Structured and Object-Oriented Analysis and Design71

80. Papers 72In practice - UML software architecture and design description, IEEE Software, 2006The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.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.

81. Papers 73In practice - UML software architecture and design description, IEEE Software, 2006

82. Practitioner reflections on UML use2+ month period, 80 architects participated. major responsibilities among respondents:analysis (66 %),design (66 %),specification (61 %), andprogramming (52 %).The respondents came from different application domains.Most worked in information systems (61 %)28 % worked in embedded systemsa few worked in tool and operating systems development. 60% worked in projects of more than 5 person-years.74

83. Survey respondents’ use of UML for 4+1 architectural views75

84. Survey respondents’ assessment of their adherence to the UML standard.76

85. Deadline vs. completeness as stopping criteria for different project sizes.77

86. Problems encountered due to incomplete models correlated to respondent demographic data regarding project size.78

87. Problems with UML descriptionsScattered information:Design choices are scattered over multiple views.some dependencies might show up in the logical view, while others appear in the process view.Incompleteness:The architects focus on what they think is important.Inconsistency. UML-based software development is inevitably inconsistent. Industrial systems are typically developed by teams.Different teams can have different understandings of the system as well as different modeling styles, and this can lead to inconsistent models.79

88. Other problem classes include the following:Diagram quality. UML lets architects represent one design in different ways. they can decompose a diagram that contains too many elements into several smaller diagrams. they can influence how easy the model is to understand and how it gets interpreted.Informal use. Architects sometimes use UML in a very sketchy manner. These diagrams deviatefrom official UML syntax, making their meaning ambiguous.Lack of modeling conventions. case studies show that engineers use UML according to individual habits. These habits might include layout conventions, commenting, visibility of methods and operations, and consistency between diagrams.80

89. Defects in industrial UML modelsSubjectiveimpression obtained via the surveyObjectivemeasurements about the quality of industrial UML models. (14 case studies of different sizes from various organizations and application domains)81

90. Defects found in the case studiesMethods that are not called in sequence diagramsClasses not occurring in sequence diagramsObjects without namesMessages not corresponding to methodsClasses without methods82

91. Papers 83The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.

92. It is important to investigate the benefits obtained from modeling. this paper reports on controlled experiments, spanning two locations, that investigate the impact of UML documentation on software maintenance. Results show that: 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.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 maintenance84

93. 85

94. 86

95. Experimental resultsThe goal was to shed some light on the cost effectiveness of model-driven development with UML. focused on whether models help software engineers to make quicker and better changes to existing systems. The results of the two experiments are mostly consistent. When considering only the time required to make code changes, using UML documentation does help to save effort overall. On the other hand, when including the time necessary to modify the diagrams, no savings in effort are visible. in terms of the functional correctness of the changes:using UML has a significant, positive impact on the most complex tasks.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.the above statements apply only with qualifications.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. Furthermore, current tools still need substantial improvements in the way they support changes to models and the checking of consistency.87

96. Papers 88A Realistic Empirical Evaluation of the Costsand Benefitsof UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.

97. The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling.few empirical studies exist which investigate the costsand evaluate the benefitsof using UML in realistic contexts. 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. 89

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. Control Group: had no UML documentationUML Group: had UML documentation.had, on average, a practically and statistically significant 54% increase in the functional correctness of changes (p = 0.03)insignificant 7% overall improvement in design quality (p = 0.22)90

99. 91

100. Selection of SubjectsSubjects 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.Note that the recruitment of all subjects could not be completed before the start of the experiment. This was due to several practical reasons:The market for these skilled professionals is very tight.We could not give the consulting companies definite start and end dates as to when the consultant would be working.The consulting companies could not give us an exact start date for consultantsThe consulting companies often could not guarantee that the consultant would be available.92

101. 9310 no UML10 UML

102. 94

103. 95