Contents Why should I consider OOA&D OO analysis OO design A reference model for OOA&D Summary of some OOA&D methods. Experience with OOA&D Choosing an OOA&D method Summary and conclusion.

4.1 Why should I consider OO analysis and design OO approaches are seeking to resolve some problems that tranditional structured analysis and design. The Objects model in OOA&D provide a more realistic representation, which an end user can more readily understand. OOA&D provides a consistent approach which maps cleanly onto a physical design and implementation. OOA&D provides a framework which supports reuse and extensibility.

4.2 OO analysis The result of analysis are requirements specifications which clearly describe what the software external behavior should be, without any prejudgement about how the software will produce this exact behaviour. Phases of analysis and design. (P74 figure 4.2)

4.2.1 Essence of OO analysis Class relationship diagrams Class inheritance diagrams. Object interaction diagrams Object state tables. User access diagrams. Textual specification documents.

4.2.2 OO analysis vs Structured analysis OO technique provides a more consistent approach to system modelling. OO view more closely reflects the real world where humans are used to thinking in terms of things which possess both attributes and behaviours. OO provides reuse possibility from the class hierarchy views of the system. OO analysis is able to model the user interface to a system.

4.2.3 Shortcomings of OOA OO analysis techniques are still the subject of much debate and research. The mixing of analysis and design methods is a problem with OO techniques.

4.3 OO design. The difference between OO analysis and design is not always very clear. Design considerationsinclude hardware and software issues.

4.3.1 Problem with traditional structured design It fails to take the evolutionary nature of software systems into accounts. Often the data structure aspect is neglected. Working top-down does not promote reusability.

4.3.2 Class and application design Class design Identify classes. Identify subclass within each class. Identify abstract behaviour of each class Identify common behavior Identify specific types of behavior Application design is a top-down adn bottom-up process, designing teh application from the existign building blocks.

4.3.3 Benefits from OO design Information hidding. Weak coupling Strong cohesion Exensibility

4.3.4 Shortcomings of OOD Identifying class. Blurred boundaries between design and both analysis and implemetation. Variable degrees of OO support in existing CASE tools. Elaborate and complex notations.

4.5 Summary of some OO analysis and design methods Booch method OOSE OSMOSYS OO systems analysis OMT RDD OORASS HOOD OOSD Object-Oriented software development

4.5.1 OO analysis and design (Coad and Yourdon) Analysis process: five layers P108 notation Design process: four components Pragramtics: CASE tool support Discussion: Simplcity of notation, design phase is sketchy and need evlove.

4.5.2 Booch method Design process: Incremental design, a spiral development model. Notation: rich in symbols. Pragmatics: Rational Rose. Discussion: complicated notation, a set of techniques without a well-defined process.

4.5.3 OOSE The method encompass analysis and design. From requirements models to implementation models. Notation: P122 P123 Pragmatic: CASE tool, documentation and published text. Discussion: Two stage analysis procedure provides a more robust model.(use-case, analysis model)

4.5.4 OSMOSYS A propretary method The process: Two development apporaches: Functional approach and OO approach. Notation: 8 main diagrams. Pragmatic: A toolset. Discussion: well-documented process and the tool support. Concentrated on teh techniques and overall process.

4.5.5 Object-oriented systems analysis An adaptation of traditional structured methods using entity modelling. The analysis process: three steps. Notation: different diagrams at different stages. Discussion: most applicable to real-time systems. Lack design procedure and process

4.5.6 OMT The process: three phase (analysis, system design and object design) Notation: P134 Fig 4.30 Pragmatic: OMTool. Published text. Discussion: place more emphasis on specifying what an object is rather than how it is used.

4.5.7 RDD A revolutionary approach. The process: The process requires that a written specificaton existes and concentrates on analysing these requirements. Notation: CRC (class, responsibility and collaboration) Pragmatic: CRC is limited in use to about 20-30 classes. Discussion: Truely OO approach to analysis. In RDD the analysis phase is part of design.

4.5.8 OORASS The concepts and techniques used in OORASS is quite different from others. Concepts: Role and role modelling. Role models focus on describing patterns of interaction without connecting the interactionto particular objects. Process: Iterative, 6 steps. Notation: P141 Fig 4.33 , text notation exists. Pragmatic: published articles. CASE tool, courses. Discussion: A proprietary method. Using roles to view analysis .

4.5.9 OOSD Notation:elaborate notations. Pragmatic: CASE tool (from IDE) Discussion: Only a notation for OO design.

4.5.10 HOOD method Grew out of Ada community Map its features directly to Ada concepts. Not properly Object-oriented.

4.5.11 The Object-oriented software development method The process: requirement analysis, preliminary design and detailed design. Notation: interaction, hierarchy and class diagrams, P148 Fig 4.34 Pragmatic: a highly extensible CASE tool Discussion: well suited to the development of real time applications.Object interaction diagrams are the best feature, while class diagrams are not well defined.

4.6 Experience with OO analysis and design A foundamental objective of OO analysis and design is to derive a good class hierarchy. Four basic kind of class can be identified during the developement . Foundation class. Application framework classes. Business classes. Application classes.

4.7 Choosing a OO analysis and design method Conceptual issues. General method issues. Techniques.

4.8 summary Introduced techniques adn tools to support OO analysis and design. Discussed the relative merits and problems with OO compared to structured techniques. Some methods are strong on process adn techniques but weak on notation while other others are strong on notation but the process is almost non-existent.