1. Requirements Analysis 10. 1 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Identifying Classes & Collaborations Department of Information Systems

2. Requirements Analysis 10. 2 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Learning Objectives v Identifying Objects and Classes v Boundary, Control & Entity Classes v Use Case Realisation v Collaborations as Use Case Realisation v Class Diagrams as Use Case Realisation

3. Requirements Analysis 10. 3 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Discovering Objects v Two main strategies v 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

4. Requirements Analysis 10. 4 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Discovering Objects v 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 v Actually just as long-established - but largely in Sweden

5. Requirements Analysis 10. 5 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Two Strategies for Object Discovery Use Case Realization > 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 12

6. Requirements Analysis 10. 6 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Iterative Analysis v Main established method in US and UK v Relies on finding objects and classes from: v Iterate through development cycle v Add more knowledge and structure at each pass

7. Requirements Analysis 10. 7 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Techniques in Iterative Analysis v Classic “spot the noun” technique: v Combine with “spot the adjective” v “Spot the verb” v Subsequent iterations will change many!

8. Requirements Analysis 10. 8 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Promotion and Demotion of Classes and Attributes v Some classes disappear from model v Other classes emerge later v Some classes turn out to be attributes of others

9. Requirements Analysis 10. 9 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Promotion and Demotion of Classes and Attributes v 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

10. Requirements Analysis 10. 10 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Promotion of Attribute to Class Extension Number Access Rights Extension SetPrivileges ( ) Subsequent iteration Extension Extension Number First iteration Dial ( )

11. Requirements Analysis 10. 11 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Promotion of Association to Class v Some attributes may not fit into either class participating in an association v These attributes are closely related to the association v Create an association class

12. Requirements Analysis 10. 12 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Class Module Student ** isRegisteredFor Problem: where to locate attributes for coursework and examination grades?

13. Requirements Analysis 10. 13 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case-Driven Development v RUP (following Objectory) is “use case- driven” v Use case is basic unit of: v Use cases bind together analysis, design, test, implementation

14. Requirements Analysis 10. 14 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case-Driven Development v Use case is a thread through the project: Use Case Model Analysis Model Design Model Implementati on Model Test Model > X X  > dependency shows flow of derivation

15. Requirements Analysis 10. 15 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case-Driven Development v Use case model expresses requirements v Progressively realised during analysis, design and implementation v Each stage of realisation expresses more detail v Each stage gets closer to the software that finally realises the use case v i.e. delivers the functional requirements

16. Requirements Analysis 10. 16 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case Realisation v In analysis, usually a single collaboration diagram v Identifies analysis classes v Incrementally becomes the analysis model, as more use cases are analysed v In design, realised as design class diagram v In implementation, realised as components

17. Requirements Analysis 10. 17 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Boundary, Control and Entity v Jacobson has long held that resilient maintainable systems comprise: – Boundary (interface) objects: v Established in Objectory for many years v Some say every use case should have a controlling object – Entity (passive) objects: – Control objects (handle interactions):

18. Requirements Analysis 10. 18 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Boundary, Control and Entity v Boundary objects: –handle interaction with actors outside the system –may represent physical devices or logical I/O –RUP symbol: v Control objects: –manage interacting objects within the system –usually control a single use case –RUP symbol:

19. Requirements Analysis 10. 19 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Boundary, Control and Entity v Entity objects: –primarily responsible for storing data –often represent enduring business concepts –often participate in several use cases –RUP symbol: v Boundary, control and entity objects are identified mainly during analysis stage

20. Requirements Analysis 10. 20 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case Realisation v 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.

21. Requirements Analysis 10. 21 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Use Case Realisation v Identify analysis classes needed to realise this use case Use Case Model withdraw money Analysis Model > withdraw money Dispenser Cashier interface Withdrawal Account participant

22. Requirements Analysis 10. 22 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Realisation as a Collaboration v 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 dispense entity object - also participates in other transactions control object for this transaction only boundary object

23. Requirements Analysis 10. 23 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Realisation as a Class Diagram v 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

24. Requirements Analysis 10. 24 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Realisation as a Class Diagram v Alternative notation for RUP extensions: Cashier interface > Dispenser > Withdrawal > Account > Note: Association details suppressed for clarity Note classic UML > notation

25. Requirements Analysis 10. 25 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Realisation as a Class Diagram v Or, in ‘classic’ UML: Cashier interface > Dispenser > Withdrawal > Account > Note: Association details suppressed for clarity

26. Requirements Analysis 10. 26 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Building an Analysis Model v Analysis model is built: v Control classes usually unique to a use case v Boundary and entity classes:

27. Requirements Analysis 10. 27 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved Summary v Strategies for identifying Objects and Classes v Boundary, Control & Entity Classes v RUP extensions to UML v Use Case Realisation v Realisation with Collaboration Diagram v Realisation with Class Diagram

28. Requirements Analysis 10. 28 Classes & Associations - 2005b510.ppt © Copyright De Montfort University 2000 All Rights Reserved References v Bennett, S. et. al. (2002)“Object-Oriented Systems Analysis & Design using UML” McGraw-Hill, Maidenhead. v Jacobson, I., Booch, G. and Rumbaugh, J. (1999), “The Unified Software Development Process”, Addison Wesley, Reading Mass (especially Ch 3 & Ch 7). v OMG (1999) “Unified Modeling Language Specification,version 1.3” v Rational Unified Process 2000