1. Requirements Analysis 12. 1 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Analysis and Domain Object Models Department of Information Systems

2. Requirements Analysis 12. 2 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Learning Objectives v Define Analysis Model v Relate to Domain and Design Models v How to Develop a Domain Model v Relate to RUP Workflows and Actors

3. Requirements Analysis 12. 3 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved What is an Analysis Object Model? v Several types of object model v One distinction is between: –Analysis (requirements model) –Domain (business model) –Design (generic software model) –Implementation (specific software model) v These differ in level of abstraction and timing

4. Requirements Analysis 12. 4 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis Model “An object model describing the realisation of use cases... “...an abstraction of the Design Model... “...contains the results of use case analysis, instances of Analysis Class... “...an optional artefact” RUP, 2000

5. Requirements Analysis 12. 5 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis Model v In RUP (and most methodologies), a picture of requirements for a specific application: v Classically: WHAT the application must do, not HOW it will do it

6. Requirements Analysis 12. 6 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis Model v E.g: –The system will record student enrolments on modules; all such records will be persistent v Not: –A Java application will allow office staff to record student enrolments on modules –persistent storage will be provided by an Access relational DBMS

7. Requirements Analysis 12. 7 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis Modelling v Building an analysis model was introduced in an earlier lecture: v Either iterative ‘traditional’ approach v Or use case driven approach –Identify boundary, control, entity classes needed for each use case –Consolidate into analysis model for application as a whole

8. Requirements Analysis 12. 8 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis and Domain Models v In traditional iterative approach, analysis model may be: v For use case driven approach:

9. Requirements Analysis 12. 9 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Model v Purely conceptual model of business domain v Enduring characteristics, behaviour and relationships v Independent of specific applications v Common aspects of many applications v Note: RUP uses the related idea of ‘Business Model’

10. Requirements Analysis 12. 10 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v Several ways to build v Top-down model of business processes & relationships v If we know and understand the business, we can identify: –classes –their data –their behaviour

11. Requirements Analysis 12. 11 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v E.g. a university model v Don’t need much specialist knowledge to realise that domain classes include:

12. Requirements Analysis 12. 12 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Classes Domain class model fragment for university Student name dateOfBirth address Module title code description creditValue creditLevel *1..28 is registered for calculateAge () enrolStudent(Student)

13. Requirements Analysis 12. 13 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v We can also model bottom-up: –examine business processes –identify participating objects –model data and behaviour –group into classes

14. Requirements Analysis 12. 14 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Objects & Classes Possible Classes “Jez Tailor is 19. She has just enrolled for her second year as a student at DMU. This semester she is taking four modules: INFO2005, HRMG2001,...etc. ” Objects

15. Requirements Analysis 12. 15 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Objects Domain object model fragment for university :student Name= Jez Tailor dateOfBirth=14-04-81 address=XXXXXXXXXX :module Title=Requirements Analysis code=INFO2005 description=XXXXXXXXXX creditValue=15 creditLevel=2

16. Requirements Analysis 12. 16 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v From individual objects and links, we can: –identify classes –identify attributes and responsibilities –identify associations –identify cardinality and optionality constraints

17. Requirements Analysis 12. 17 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Model v In at least one way, a domain model is not true to life: –Jez may ‘own’ her data, e.g. date of birth –But when we need to know her age, we don’t get Jez to calculate it –Nor does a module ‘personally’ enrol students –(Heather in the Faculty Office does this!)

18. Requirements Analysis 12. 18 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Model v This reminds us of the ultimate purpose of a domain model: v To lead us to the development of useful systems - almost certainly software v But the domain model is not a model of the software

19. Requirements Analysis 12. 19 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v A domain model can also be abstracted (generalised) from use case driven models v Use case driven models are built for a specific application context v Some objects and classes have meaning beyond their immediate context

20. Requirements Analysis 12. 20 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Domain Modelling v E.g. use case realisation for ‘Enrol a student’ has: v Other use cases will use the classes, and add other attributes / operations:

21. Requirements Analysis 12. 21 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis and Design Models “Analysis classes handle primarily functional requirements, and model objects from the "problem" domain... “Design classes handle non-functional requirements, and model objects from the "solution" domain” RUP, 2000

22. Requirements Analysis 12. 22 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis and Design Models v Analysis: abstraction of design model v Analysis classes map to design as: –a single design class –part of a design class –an aggregate design class (i.e. parts of the aggregate not explicit in analysis model) –a group of design classes that inherit from the same class

23. Requirements Analysis 12. 23 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Analysis and Design Models v Other analysis class mappings: –a group of functionally related design classes –a design package (i.e. a component) –a design relationship –a relationship between analysis classes can become a class in the design model

24. Requirements Analysis 12. 24 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Locating in RUP Diagram © RUP, 2000

25. Requirements Analysis 12. 25 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Actors in RUP In RUP, a Systems Architect is responsible for developing and maintaining the overall analysis and design models... …while a Designer is responsible for specifying analysis and design classes that are capable of realising the use cases Diagrams © RUP, 2000 Text

26. Requirements Analysis 12. 26 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Summary v Defined Analysis Model v Related to Domain and Design Models v Shown How to Develop a Domain Model v Related to RUP Workflows and Actors

27. Requirements Analysis 12. 27 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved References v Bennett, S. et. al. “Object-Oriented Systems Analysis & Design using UML” McGraw-Hill 2002 (in particular chap 7) v Rational Unified Process 2000