object oriented software engineering the professional developer s guide on omg s ooa ood proposal
Download
Skip this Video
Download Presentation
George Wilkie

Loading in 2 Seconds...

play fullscreen
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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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
  • Information hidding.
  • Weak coupling
  • Strong cohesion
  • Exensibility
4 3 4 shortcomings of ood
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
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
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
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
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
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
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
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
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
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
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
4.5.9 OOSD
  • 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
  • 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
  • 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
  • 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
  • Conceptual issues.
  • General method issues.
  • Techniques.
4 8 summary
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.
ad