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.