1. 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.

2. 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.

3. 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. 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.

5. 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.

6. 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.

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

8. 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.

9. 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.

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

11. 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.

12. 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

13. 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.

14. 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.

15. 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)

16. 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.

17. 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

18. 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.

19. 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 classes.
Discussion: Truely OO approach to analysis. In RDD the analysis phase is part of design.

20. 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 .

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

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

23. 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.

24. 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.

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

26. 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.