Object oriented software engineering the professional developer s guide on omg s ooa ood proposal
Download
1 / 28

George Wilkie - PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' George Wilkie' - sabin


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Object oriented software engineering the professional developer s guide on omg s ooa ood proposal

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

George Wilkie


Contents
Contents Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.1 Why should I consider OO analysis and design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.2 OO analysis Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.2.1 Essence of OO analysis Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.2.2 OO analysis vs Structured analysis Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.2.3 Shortcomings of OOA Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.3 OO design. Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.3.1 Problem with traditional structured design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.3.2 Class and application design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.3.3 Benefits from OO design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • Information hidding.

  • Weak coupling

  • Strong cohesion

  • Exensibility


4 3 4 shortcomings of ood
4.3.4 Shortcomings of OOD Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.4 A reference Model for analysis and design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5 Summary of some OO analysis and design methods Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.1 OO analysis and design (Coad and Yourdon) Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.2 Booch method Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.3 OOSE Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.4 OSMOSYS Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.5 Object-oriented systems analysis Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.6 OMT Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.7 RDD Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.8 OORASS Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.9 OOSD Developer’s Guide(on OMG’s OOA/OOD proposal)

  • Notation:elaborate notations.

  • Pragmatic: CASE tool (from IDE)

  • Discussion: Only a notation for OO design.


4 5 10 hood method
4.5.10 HOOD method Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.5.11 The Object-oriented software development method Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.6 Experience with OO analysis and design Developer’s Guide(on OMG’s OOA/OOD proposal)

  • 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
4.7 Choosing a OO analysis and design method Developer’s Guide(on OMG’s OOA/OOD proposal)

  • Conceptual issues.

  • General method issues.

  • Techniques.


4 8 summary
4.8 summary Developer’s Guide(on OMG’s OOA/OOD proposal)

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


ad