1 / 28

George Wilkie

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

briddle
Download Presentation

George Wilkie

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Software Engineering - The professional Developer’s Guide(on OMG’s OOA/OOD proposal) George Wilkie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related