requirements analysis 10. 1 classes & associations - 2005b510.ppt © copyright de montfort...
Post on 20-Dec-2015
213 views
TRANSCRIPT
Requirements Analysis 10. 1 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
INFO2005Requirements Analysis
Identifying Classes & Collaborations
Department of Information Systems
Requirements Analysis 10. 2 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Learning Objectives
Identifying Objects and Classes Boundary, Control & Entity Classes Use Case Realisation Collaborations as Use Case
Realisation Class Diagrams as Use Case
Realisation
Requirements Analysis 10. 3 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 4 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 5 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 6 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 7 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Techniques in Iterative Analysis
Classic “spot the noun” technique:
Combine with “spot the adjective”
“Spot the verb”
Subsequent iterations will change many!
Requirements Analysis 10. 8 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 9 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 10 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Promotion of Attribute to Class
Extension Number
Access Rights
Extension
SetPrivileges ( )
Subsequentiteration
Extension
Extension Number
First iteration
Dial ( )
Requirements Analysis 10. 11 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 12 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Association Class
ModuleStudent * *isRegisteredFor
Assessment
courseworkGradeexamGrade
ModuleStudent * *isRegisteredFor
Problem: where to locate attributes for coursework and examination grades?
Requirements Analysis 10. 13 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 14 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 15 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 16 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 17 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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):
Requirements Analysis 10. 18 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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:
Requirements Analysis 10. 19 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 20 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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.
Requirements Analysis 10. 21 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 22 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 23 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 24 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 25 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Realisation as a Class Diagram
Or, in ‘classic’ UML:
Cashier interface<<boundary>>
Dispenser<<boundary>>
Withdrawal<<control>>
Account<<entity>>
Note:
Association details suppressed for clarity
Requirements Analysis 10. 26 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
Building an Analysis Model Analysis model is built:
Control classes usually unique to a use case
Boundary and entity classes:
Requirements Analysis 10. 27 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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
Requirements Analysis 10. 28 Classes & Associations - 2005b510.ppt
© Copyright De Montfort University 2000All Rights Reserved
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