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

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

© Copyright De Montfort University 2000All Rights Reserved

INFO2005Requirements Analysis

Identifying Classes & Collaborations

Department of Information Systems



Learning Objectives

Identifying Objects and Classes Boundary, Control & Entity Classes Use Case Realisation Collaborations as Use Case

Realisation Class Diagrams as Use Case

Realisation



Discovering Objects Two main strategies One: “traditional” iterative method

(used by OMT, Coad/Yourdon, etc.)– Identify “archetypal” object types from

various inputs– describe them largely as “standalone”

types– model their behaviour and structure in

terms of logical properties– refine this in the light of the use cases



Discovering Objects Two: Use Case-Driven (RUP favours

this)– Examine each use case in turn– Identify collaboration of objects needed to

deliver its functionality– Describe their responsibilities– Repeat for other use cases, and build

overall analysis model iteratively Actually just as long-established - but

largely in Sweden



Two Strategies for Object Discovery

Use Case Realization

<<realizes>>

Can be successfully combined using archetypes for concept modelling and

use-case realisation for specification

Problem statement

Use case descriptions

General intuitions

Other fact-finding

1

2



Iterative Analysis

Main established method in US and UK Relies on finding objects and classes

from:

Iterate through development cycle Add more knowledge and structure at

each pass



Techniques in Iterative Analysis

Classic “spot the noun” technique:

Combine with “spot the adjective”

“Spot the verb”

Subsequent iterations will change many!



Promotion and Demotion of Classes and Attributes Some classes disappear from model

Other classes emerge later

Some classes turn out to be attributes of others



Promotion and Demotion of Classes and Attributes Some “attributes” reveal significant

behaviour– break out into first-order classes– associate with class that previously

owned them– decision to model any abstraction as

class, association or attribute is usually determined by significance of its behaviour



Promotion of Attribute to Class

Extension Number

Access Rights

Extension

SetPrivileges ( )

Subsequentiteration

Extension

Extension Number

First iteration

Dial ( )



Promotion of Association to Class Some attributes may not fit into

either class participating in an association

These attributes are closely related to the association

Create an association class



Association Class

ModuleStudent * *isRegisteredFor

Assessment

courseworkGradeexamGrade

ModuleStudent * *isRegisteredFor

Problem: where to locate attributes for coursework and examination grades?



Use Case-Driven Development RUP (following Objectory) is “use

case-driven” Use case is basic unit of:

Use cases bind together analysis, design, test, implementation



Use Case-Driven Development Use case is a thread through the project:

Use Case Model

Analysis Model Design

Model

Implementation Model Test

Model<<trace>> <<trace>> <<trace>>

X

X<<trace>>

<<trace>>

<<trace>> dependency shows flow of derivation



Use Case-Driven Development Use case model expresses requirements Progressively realised during analysis,

design and implementation Each stage of realisation expresses more

detail Each stage gets closer to the software

that finally realises the use case i.e. delivers the functional requirements



Use Case Realisation

In analysis, usually a single collaboration diagram

Identifies analysis classes Incrementally becomes the analysis

model, as more use cases are analysed In design, realised as design class

diagram In implementation, realised as

components



Boundary, Control and Entity Jacobson has long held that resilient

maintainable systems comprise:– Boundary (interface) objects:

Established in Objectory for many years Some say every use case should have a

controlling object

– Entity (passive) objects:

– Control objects (handle interactions):



Boundary, Control and Entity

Boundary objects:– handle interaction with actors outside the

system– may represent physical devices or logical I/O– RUP symbol:

Control objects:– manage interacting objects within the

system– usually control a single use case– RUP symbol:



Boundary, Control and Entity Entity objects:

– primarily responsible for storing data– often represent enduring business

concepts– often participate in several use cases– RUP symbol:

Boundary, control and entity objects are identified mainly during analysis stage



Use Case Realisation

Consider an example realisation:

Withdraw Money Use Case

Simplified sequence of actions:

1. Bank customer identifies him / herself.

2. Bank customer chooses which account, and how much money to withdraw.

3. System deducts the amount from the account and dispenses the cash.



Use Case Realisation Identify analysis classes needed to

realise this use caseUse Case

Model

withdraw money

Analysis Model

<<trace>>

withdraw money

Dispenser Cashier interface

Withdrawal Account

participant



Realisation as a Collaboration Next build a collaboration that shows how

these classes could realise the use case

:Cashier interface

1: identify

5: dispense

:Withdrawal

2: request withdrawal

:Account

3: validate and withdraw

:Dispenser

4: authorise dispenseentity object -

also participates in

other transactions

control object for

this transaction

onlyboundary object



Realisation as a Class Diagram

Can also show realisation as class diagram:

Withdrawal Account

Dispenser

Cashier interface

Notes:

1. This diagram uses RUP extensions to UML

2. Association details are suppressed for clarity



Realisation as a Class Diagram Alternative notation for RUP extensions:

Cashier interface

<<boundary>>

Dispenser<<boundary>>

Withdrawal

<<control>>

Account<<entity>>

Note:

Association details suppressed for clarity

Note classic UML

<<stereotype>> notation



Realisation as a Class Diagram

Or, in ‘classic’ UML:

Cashier interface<<boundary>>

Dispenser<<boundary>>

Withdrawal<<control>>

Account<<entity>>

Note:

Association details suppressed for clarity



Building an Analysis Model Analysis model is built:

Control classes usually unique to a use case

Boundary and entity classes:



Summary

Strategies for identifying Objects and Classes

Boundary, Control & Entity Classes RUP extensions to UML Use Case Realisation Realisation with Collaboration

Diagram Realisation with Class Diagram



References

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

Jacobson, I., Booch, G. and Rumbaugh, J. (1999), “The Unified Software Development Process”, Addison Wesley, Reading Mass (especially Ch 3 & Ch 7).

OMG (1999) “Unified Modeling Language Specification,version 1.3”

Rational Unified Process 2000

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

Documents

classes associations

demotion of classes

order classes

iterative analysis v

montfort university

adjective v spot

use case realisation

development cycle v