Requirements Analysis 12. 1 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis

Requirements Analysis 12. 1 Classes & Associations - 2005b510.ppt

© Copyright De Montfort University 2000All Rights Reserved

INFO2005Requirements Analysis

Analysis and Domain Object Models

Department of Information Systems



Learning Objectives

Define Analysis Model Relate to Domain and Design Models How to Develop a Domain Model Relate to RUP Workflows and Actors



What is an Analysis Object Model? Several types of object model One distinction is between:

– Analysis (requirements model)– Domain (business model)– Design (generic software model)– Implementation (specific software model)

These differ in level of abstraction and timing



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



Analysis Model

In RUP (and most methodologies), a picture of requirements for a specific application:

Classically: WHAT the application must do, not HOW it will do it



Analysis Model

E.g:– The system will record student

enrolments on modules; all such records will be persistent

Not:– A Java application will allow office staff to

record student enrolments on modules– persistent storage will be provided by an

Access relational DBMS



Analysis Modelling

Building an analysis model was introduced in an earlier lecture:

Either iterative ‘traditional’ approach Or use case driven approach

– Identify boundary, control, entity classes needed for each use case

– Consolidate into analysis model for application as a whole



Analysis and Domain Models In traditional iterative approach,

analysis model may be:

For use case driven approach:



Domain Model

Purely conceptual model of business domain

Enduring characteristics, behaviour and relationships

Independent of specific applications Common aspects of many applications Note: RUP uses the related idea of

‘Business Model’



Domain Modelling

Several ways to build Top-down model of business

processes & relationships If we know and understand the

business, we can identify: – classes– their data– their behaviour



Domain Modelling

E.g. a university model Don’t need much specialist

knowledge to realise that domain classes include:



Domain Classes

Domain class model fragment for university

StudentnamedateOfBirthaddress

ModuletitlecodedescriptioncreditValuecreditLevel

* 1..28is

registered for

calculateAge()enrolStudent(Student)



Domain Modelling

We can also model bottom-up:– examine business processes– identify participating objects– model data and behaviour– group into classes



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



Domain Objects

Domain object model fragment for university

:student Name= Jez Tailor dateOfBirth=14-04-81address=XXXXXXXXXX

:moduleTitle=Requirements Analysiscode=INFO2005description=XXXXXXXXXXcreditValue=15creditLevel=2



Domain Modelling

From individual objects and links, we can:– identify classes– identify attributes and responsibilities– identify associations– identify cardinality and optionality

constraints



Domain Model

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!)



Domain Model

This reminds us of the ultimate purpose of a domain model:

To lead us to the development of useful systems - almost certainly software

But the domain model is not a model of the software



Domain Modelling

A domain model can also be abstracted (generalised) from use case driven models

Use case driven models are built for a specific application context

Some objects and classes have meaning beyond their immediate context



Domain Modelling

E.g. use case realisation for ‘Enrol a student’ has:

Other use cases will use the classes, and add other attributes / operations:



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



Analysis and Design Models Analysis: abstraction of design model 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



Analysis and Design Models 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



Locating in RUP

Diagram © RUP, 2000



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, 2000Text



Summary

Defined Analysis Model Related to Domain and Design

Models Shown How to Develop a Domain

Model Related to RUP Workflows and

Actors



References

Bennett, S. et. al. “Object-Oriented Systems Analysis & Design using UML” McGraw-Hill 2002 (in particular chap 7)

Rational Unified Process 2000

Documents

Requirements Analysis 12. 1 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis