COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Intro to Systems Requirements Lecture 4 Identifying Classes

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Learning Objectives v Identifying Objects and Classes v Use Case Realisation v Class Diagrams as Use Case Realisation

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Iterative Analysis v Main established method in US and UK v Relies on finding objects and classes from: –problem statement –interviews –prototyping, etc v Iterate through development cycle v Add more knowledge and structure at each pass

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Techniques in Iterative Analysis v Classic “spot the noun” technique: –Identify candidate objects from problem statement –Or better, from use case descriptions v Combine with “spot the adjective” –May identify some candidate attributes v “Spot the verb” –May identify some candidate associations v Subsequent iterations will change many!

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Promotion and Demotion of Classes and Attributes v Some classes disappear from model –no significant behaviour revealed –synonyms revealed v Other classes emerge later –iterations reveal “hidden” abstractions –homonyms revealed v Some classes turn out to be attributes of others

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Promotion of Attribute to Class Extension Number Access Rights Extension SetPrivileges ( ) Subsequent iteration Extension Extension Number First iteration Dial ( )

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Association Class Module Student ** isRegisteredFor Problem: where to locate attributes for coursework and examination grades?

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Use Case-Driven Development v RUP (following Objectory) is “use case- driven” v Use case is basic unit of: –user functional requirements –project iterations –software architecture –increments of delivered software v Use cases bind together analysis, design, test, implementation

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Use Case-Driven Development v Use case is a thread through the project: Use Case Model Analysis Model Design Model Implementatio n Model Test Model > X X  > dependency shows flow of derivation

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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):

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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:

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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.

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Realisation as a Class Diagram v Or, in ‘classic’ UML: Cashier interface > Dispenser > Withdrawal > Account > Note: Association details suppressed for clarity

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved Building an Analysis Model v Analysis model is built: –use case by use case –over several iterations v Control classes usually unique to a use case v Boundary and entity classes: –Often participate in more than one use case –Search for reuse opportunities among classes that already exist

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 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

COMP1007 Intro to Systems Requirements © Copyright De Montfort University 2002 All Rights Reserved References v Bennett, S. et. al. (1999)“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