Object-Oriented Software Engineering - The professional Developer’s Guide(on OMG’s
OOA/OOD proposal)
George Wilkie
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.4 A reference Model for analysis and design
• A reference model is defined in order to compare OO analysis and design methods.
• P99 Figure 4.12
• P100 Figure 4.13
4.5 Summary of some OO analysis and design methods
• OO analysis and design• 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.
Top Related