Title: ObjectOriented Software Engineering The professional Developers Guideon OMGs OOAOOD proposal
1Object-Oriented Software Engineering - The
professional Developers Guide(on OMGs OOA/OOD
proposal)
2Contents
- Why should I consider OOAD
- OO analysis
- OO design
- A reference model for OOAD
- Summary of some OOAD methods.
- Experience with OOAD
- Choosing an OOAD method
- Summary and conclusion.
34.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 OOAD provide a more
realistic representation, which an end user can
more readily understand. - OOAD provides a consistent approach which maps
cleanly onto a physical design and
implementation. - OOAD provides a framework which supports reuse
and extensibility.
44.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)
54.2.1 Essence of OO analysis
- Class relationship diagrams
- Class inheritance diagrams.
- Object interaction diagrams
- Object state tables.
- User access diagrams.
- Textual specification documents.
64.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.
74.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.
84.3 OO design.
- The difference between OO analysis and design is
not always very clear. - Design considerationsinclude hardware and
software issues.
94.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.
104.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.
114.3.3 Benefits from OO design
- Information hidding.
- Weak coupling
- Strong cohesion
- Exensibility
124.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.
134.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
144.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
154.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.
164.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.
174.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)
184.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.
194.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
204.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.
214.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.
224.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 .
234.5.9 OOSD
- Notationelaborate notations.
- Pragmatic CASE tool (from IDE)
- Discussion Only a notation for OO design.
244.5.10 HOOD method
- Grew out of Ada community
- Map its features directly to Ada concepts.
- Not properly Object-oriented.
254.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.
264.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.
274.7 Choosing a OO analysis and design method
- Conceptual issues.
- General method issues.
- Techniques.
284.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.