1 / 18

Object Orientated Analysis and Design - Contents

Object Orientated Analysis and Design - Contents. When to use OO? What is OO? Unified Modelling Language OO Methodologies: O bject M odelling T echnique (Rumbaugh et al, 1991) Objectory (Jacobson et al, 1992) O bject-oriented P rocess, E nvironment & N otation (Graham et al, 1998)

valdemar-astrid
Download Presentation

Object Orientated Analysis and Design - Contents

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 Orientated Analysis and Design - Contents • When to use OO? • What is OO? • Unified Modelling Language • OO Methodologies: • Object Modelling Technique (Rumbaugh et al, 1991) • Objectory (Jacobson et al, 1992) • Object-oriented Process, Environment & Notation (Graham et al, 1998) • Conclusion

  2. When to use OO? • For complex information systems: • by use of structures which enable the complexity to be split down into subdivisions • by use of structures that map from real situation through to system development. • For reliable, maintainable, modifiable information systems. • Use OO Analysis and Design when development is known to be in an OO language or database. • GUI-based and event-driven systems

  3. What is OO? • Class and Object • Generalisation and Specialisation • Message-passing • Polymorphism

  4. OO Methodology Generations 1st Shlaer and Mellor (1988) 2nd OMT (1991), OOA (Coad and Yourdon 1991, see recommended text), Booch (1991), Objectory (1992) 3rd Fusion, Syntropy 4th Unified Software Development Process (Jacobson et al, 1999) leading to RUP, OPEN (1997)

  5. Object Modelling Technique • A framework for development proposed in 1991 by Rumbaugh et al. • Order of most steps unimportant • Experienced developers may combine steps or perform steps in parallel • Multiple levels of detail for each model

  6. OMT Structure • Analysis Phase – what the system will do in real-world terminology • System Design Phase – High level structure of the system • Object Design Phase – Detailed spec. for practical implementation in computer terminology (but NOT related to a specific language/database) • See appendix 1 • See appendix 2

  7. Objectory Structure Analysis Requirements model Analysis model Construction Testing Design model Construction model Test model • 5 models produced by 3 non-sequential processes

  8. Objectory Analysis • Requirements Model (Functional requirements): • Mainly a Use Case model, • Sometimes an Interface model (prototype screens) • Sometimes a Domain Object model • Analysis Model (gives structure to requirements): • Identify entity objects, control objects, interface objects • Assign attributes, roles, responsibilities, associations • Identify sub-systems dependent on coupling density.

  9. Objectory Construction • Design Model • each analysis object becomes a ‘block’ (i.e. a module, i.e. a UML design class) • Possibly optimise block groupings • Create interaction sequence diagrams for each use case • Construction Model • Add blocks for services related to specific platform to be used Objectory Testing • Test Model • Verify the code

  10. Unified Modelling Language • Core Models: • Requirements capture – Use Case Diagrams and Use Case Scripts • Requirements analysis – Class Diagrams • Models derived from them: • Interaction Diagrams (Sequence or Collaboration) • State or Activity Diagrams

  11. Use Case Driven lifecycle (as used in OOM module) Class Diagrams And State Diagrams Use Case Diagrams (UCD) Object Sequence Diagrams (OSD) Use Case Scripts (UCS)

  12. Object-oriented Process, Environment & Notation • OPEN is a ‘process framework’ – within the framework an organisation selects the processes (Activities, Tasks, Techniques) they require to be used. • The Activities may cover whichever life cycle phases the organisation requires – suggests Project Initiation, Requirements Engineering, Analysis and model refinement, Project Planning, Build, User Review, Consolidation

  13. Components of the OPEN Process Framework Stages help to provide organisation to the Guidelines Producers produce perform create evaluate iterate maintain Work Units Work Products are documented using Languages

  14. OPEN Components • Work Units: Activities, Tasks, Techniques • Producers: the roles of people/tools that created the product or the team(s) that caused production • Work Products: the things (documents, diagrams, models, classes, software) that the producers produce using the techniques and tasks • Stages: phase, life cycle, milestone, …. • Languages: natural (e.g.English), modelling (e.g.UML /OML / other), coding (e.g.Java, SQL)

  15. OPEN Work Units • Activities and Tasks both represent goals (what is to be done, not how). • Tasks are smaller units than activities – the smallest project-manageable unit. • Techniques specify how a task is to be done (e.g.CRC Cards, e.g. aggregation modelling, e.g. module coding)

  16. OPEN Conclusion • OPEN provides • flexibility since it is a process meta-model – usable for large/small, critical/noncritical, long/short term projects. • Support for full life cycle • Embedded project management framework • CMM

  17. Conclusion • New Methodologies are always evolving to suit new circumstances • Not all projects match the newest circumstances Why do most Software Development organisations use their own ‘Special Blend’ of methodologies?

  18. Further reading on Frameworks • Here we are talking about Software Development Frameworks not System (architecture) frameworks • http://www.realsoftwaredevelopment.com/the-complete-list-of-software-development-frameworks-processs-methods-or-philosophies/

More Related