1. K. Ingram1November 2000 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. K. Ingram2November 2000 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. K. Ingram3November 2000 What is OO? Class and Object Generalisation and Specialisation Message-passing Polymorphism

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

5. K. Ingram5November 2000 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. K. Ingram6November 2000 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 1appendix 1 See appendix 2appendix 2

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

8. K. Ingram8November 2000 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. K. Ingram9November 2000 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. K. Ingram10November 2000 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. K. Ingram11November 2000 Use Case Driven lifecycle (as used in OOM module) Use Case Diagrams (UCD) Use Case Scripts (UCS) Class Diagrams And State Diagrams Object Sequence Diagrams (OSD)

12. K. Ingram12November 2000 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. K. Ingram13November 2000 Stages Producers Work UnitsWork Products Languages provide organisation to the perform produce create evaluate iterate maintain are documented using Guidelines help to Components of the OPEN Process Framework

14. K. Ingram14November 2000 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. K. Ingram15November 2000 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. K. Ingram16November 2000 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. K. Ingram17November 2000 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. K. Ingram18November 2000 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/