Requirements Analysis Requirements Analysis

Instructor: Roozbeh MehrabadiBased on notes by P.J. Davies

Object Oriented Analysis:1. Object Identification (physical)2. Object Interactions (Behaviours)3. Collaboration (Seq./Comm)

Diagrams

Class Diagrams1. Class Identification2. Class Relationships

• Transactions occur whenever one or more objects interact or collaborate e.g. when one object sends a message to another.

• The result of such a collaboration of objects is sometimes another object, i.e. a transaction object, encapsulating the results of that collaboration.

• Transaction objects frequently only exist for the duration of the collaboration, i.e. they are like arguments passed between functions in C/C++, they are created purely for the purpose of passing data between objects and then they cease, but the information that hold means that we should create a class to represent that object

Object Classification: Identify Transaction Objects

2

Object1 Object2 Interaction Transaction Object & DetailsButton Elevator controller Request Transport Floor Request Object

- Floor Number- Request type (up/down)- Source (inside or outside)

Sensor Data System Generate Sample Temperature Sample Object- Temperature reading- Date and time

Woman Man Marriage Marriage Details Object- Wedding date- Name and occupation of bride and grooms parents- Wedding location- Prenuptial agreement- Witnesses- etc (fill in your own details)

Student Instructor Assessment Assessment Result Object- Student ID- Mark- Pass/Fail Status

Customer Gas Pump Gas request Purchase- Credit card details- Quantity of fuel- Value in $'s

Sample Object Collaboration and Resultant Transaction Objects

3

Object Classification: Identify Physical Objects

• Real-time systems sensors and actuators: A/D converters: sample data from sensors Digital I/O ports: control single bit (switches, relays) Push Buttons Relays

They could be modeled with SW objects Other objects can use these to interact with the

physical devices (the objects act as device drivers).

4

Application

InterfaceObject

Initialise()Calibrate() GetSample()

Application Software Objects

Real WorldSensor

A/DConverter

Real World Physical Objects

From Structural Modeling to Object and Class diagrams

• Structural Models entail:1. The objects from which our system will be composed

2. The role and responsibilities that each objects assumes

3. The collaborations between objects, i.e. which objects communicate with other to implement a use-case.

4. The relationships between objects

5. The classes that implement the objects

6. The number of objects involved in the relationship (multiplicities)

The first 3 are captured on an object interaction diagram

The 2nd set are captured on a class diagram.

5

6

Gas Station Simulation

Question: How does it work? Could you explain how a customer obtains their gas? What objects are involved in this process?

All these questions are answered with an object interaction diagram

UML: Object Interaction Diagrams

• Object collaboration through message passing is captured on: Sequence Diagrams Communication Diagrams

We need at least one type to document object interactions for each use-case.

Complex use-cases may require a hierarchy of diagrams (each showing more details as we descend it)

Interaction diagrams, capture the implementation of a use-case as a set of objects, collaborating through a process of message passing.

7

8

Gas Station Simulation communication diagram (minus messages). It shows the objects involved and which objects collaborate using messaging.

Communication Diagrams

Document message passing (without the timing constraints)

Object layout, makes identifying object relationships easier

Note: in the architecture diagram, objects and their interactions are shown, what is missing?

Sequence Diagrams • Document message passing between objects which

are plotted as a function of time.• The collaborating objects are laid out on a horizontal

line (difficult to observe object collaboration)• We can identify the components, but the structure

and relationship between the objects is hard to identify.

• They contain: At least one actor representing the user initiating the use-

case. A set of objects which were identified using various

techniques A set of messages propagating between those objects which

might also include message arguments and returned data.

9

Interaction Diagrams: Analysis vs. Design stage

• Analysis: capture the essence of the users interactions with the system (use-cases and scenarios)Actual peopleBusiness processes and logic

• Useful to the customer and meaningful for the “domain experts”

• Design: model the implementation of the SWreplace form T4A with a GUILibrarian Database and a barcode scanner

10

Actors initiates 1st message

Object sending message to ‘self’

Object lifeline showing Objects involved in Interaction and their ‘life’ duration

Message 6 sent from one object to another in response to message 4

User sending message to Object

Time

Message 4 may lead to

5 & 6

Simple “Analysis Model” sequence diagram describing the Driving of a Car

Comments

'Bar' shows the duration for which a thread executes within the object (advanced modelling technique)

Note: ALL messages contains verbs in their name as they ask an object to do something

Object Class Identification and Message Arguments

• Objects may include their class name if this is known

• Messages may have arguments and a return type

12

Object name = Shiftys Class name =

BMWGarage

Message Parameter Name = theCar Message Parameter Type =

BMWGarage

Message return data = theCar whose type is BMW

Example: Analysis Model

• Draw an “analysis model” sequence diagram to show how a customer Borrows a book from a library– Real world objects and messages.

• Now refine the diagram to show design aspects.

13

Use Case Example:

14

Use-Case: Borrow Book• The member identifies himself or herself to the librarian using their

membership card.• The member presents one or more books to the Librarian.• The Librarian checks the books to make sure they can be loaned.• The Librarian checks the membership card to make sure it is valid.• The Librarian looks up the member’s records in his/her card

indexing system and checks that the number of loaned books will be less than 6, (the maximum that can be loaned at any time to a library member).

• If acceptable, each book is then stamped with the appropriate return date (2 weeks from today).

• Each book has its identifying card removed from the inside cover.• The Librarian updates the member’s loan details by placing the

identifying cards into that members record maintained by the library.End

Decisions and Iterations on a Sequence Diagram

• First Notice: SD is not a replacement for a flowchart.

• On occasions where modeling loops and decisions is useful, use the following:– Text or Pseudo code annotated onto the diagram (usually in

the left hand field)– Placing ‘stick-it’ notes over the diagram to point out key

decisions or repetition– Enclosing sequences into a frame and showing the specific

circumstances under which they will be executed.

15

Using “Stick-it” notes plus anchors to the messages

16

Using Frames

Q1: Which frame operator is used in UML to show mutual exclusive logic?

A. Opt (Optional)

B. Alt (Alternative)

C. Loop

D. Region (Critical Region)

18

UML: Some Common Frame Operator Meaning

19

Opt Optional fragment that executes if (Condition) is true. (see example in last sheet)

Alt Alternative fragment for mutually exclusive logic based on if-else type decision. (see example in last sheet)

Loop Loop fragment: A sequence of messages that repeats while some Condition is true. (Note: Can also be written as loop(n) to indicate looping n times)

Par Two or more sequences that execute in parallel.

Region Critical region. A sequence of statements that can only be executed by one thread at a time, the implication is that the designer will have to implement some form of mutual exclusion (i.e. a mutex with wait and signal) to protect the code.

UML Message Types, returned values and Object LifeDifferent Message Types

Note arrow type. Right click in VP to set the

type of messageSynchronous message 'GetValue' sent by Object A to Object B.

Synchronous message means that Object A MUST wait for Object B to process the message (i.e. complete) and return the answer.

In this case the returned answer is assigned to the variable ‘x’ within Object A, but see also the ‘explicit’ return notation later

20

UML Message Types, returned values and Object LifeDifferent Message Types

Message sent to oneself. That is, ObjectA sends the message 'ResultValid' to itself.

Ultimately this means that some function running in ObjectA will invoke a second function within ObjectA to implement the message 'ResultValid'.

Note that in this particular case it is a synchronous message

21

UML Message Types, returned values and Object LifeDifferent Message Types

Note arrow type. Right click in VP to set the type of message

Asynchronous message 'Calculate_Y' sent by Object A to Object B.

Semantics of an asynchronous message mean that Object A does NOT have to wait for Object B to complete the Operation.

Implies that Object B is ‘active’ (e.g. has it’s own thread) so that Object A and B can continue to execute in parallel.

22

UML Message Types, returned values and Object LifeDifferent Message Types

Note arrow type. Right click in VP to set the type

of message

Create Message. Used to model the Dynamic creation of objects at run time (implemented using operator ‘new’ in C++)

23

UML Message Types, returned values and Object LifeDifferent Message Types

Destroy Message. Used to Dynamically destroy objects at run time (implemented using operator ‘delete’ in C++)

'X' on timeline shows end of objects life, i.e. point where object ceases to exist.24

When a message is sent from one object to another there is an implied relationship between those objects. The objects who send and receive messages tells us about their multiplicities.

From the diagram below we see that there is a 1:1 relationship between a Car and an Engine object, because, as a car, we only send messages to one single engine and as an engine we receive messages from only the one single car (i.e. there are no other engine or car objects shown).

Implied Relationship between Car and Gearbox and between Car and EngineMultiplicity is 1:1

No Relationship between Engine and Handbrake since neither sends messages to each other

Identifying Object Relationships and Multiplicities

25

Class Diagrams• Class Structure

From Sequence Diagrams to Class Diagrams

• Class Relationships Association Aggregation and Composition Generalisation (Inheritance)

• From Class Diagrams to Code

26

Identifying Class Structure

1. The Classes from which our objects (on the sequence diagram) will be constructed.

2. The Member Functions of those classes (mapped from the messages sent to the objects in the sequence diagram).

3. The Member Variables/items of data that the objects will need in their classes.

4. The Relationships between objects so that message passing can be implemented.

27

Class Diagram In UML Gives an overview of:

Header and Source files Member functions

• UML Class diagram:

28

Class Name is ‘CPU’

Class CPU has 4 member variables

Class CPU has 8 member functions

Accessibility Indicator:‘+’ means public‘-’ means private

‘#’ means protected

Type of variable is ‘string’

Return type of function SetManufacturer() is ‘void’

Function SetModel() takes 1 parameter of type ‘string’

Member Functions (display optional)

Member Variables (display optional)

Right mouse click on a class to add attributes or functions (i.e. member variables/functions) in V.Paradigm

28

Class Identification• Identify each object in your sequence

diagram• For each type of object, create a new

class• For member functions, look at the

messages sent to objects: Each message member function within the class which

implements that object.

The parameters of the message (data sent as part of the message) the parameters in the member function implementing that message.

Any results/data returned by the messages in the sequence diagram map directly to the return type of the member function

29

UML Class Relationships

• The UML provides three important types of class relationships:Association.

Encapsulation in the form of

Aggregation.

Composition.

Generalization.

30

Association Relationships• An association relationship exists where one class

“makes use of” or calls upon the services of another in some way. Think of the two classes having a ‘working relationship’.– A Brake pedal has an association (working relationship) with the brake

lights and servo.– A CPU has an association (working relationship) with the motherboard.

• Look for objects which send messages to others

31

Bi - directional association. Objects of Class1 are able to send messages to Objects of Class2

and vice-versa. Note no arrows on the association.

Uni - directional association. Objects of Class3 are able to send messages to

Objects of Class4 but not the other way around

Mapping of Collaborating Objects to a Class Diagram

32

Section from a Sequence Diagram

Maps to this Class Diagram

Object3 (represented by Class 3) sends a variety of messages to Object4 (Class 4) but not the other way around, implying a uni-directional association

on the class diagram.

Result: Uni-directional Association

Note mapping of message to Fns

Coding an Association• Association implies one class can send a

message to the other• Hence, should have a pointer to address it

33

For example, from the previous class diagram, the implementation of Class ‘Student’ might look like this:

class Student {Course *theCourse ; // each Student object will have a pointer to a Course

Object. . . // it needs initialisation at run time and can be used to send

messages} ;

While Class ‘Course’, would look like this (due to the bi-directional relationship between instances of these two classes).

class Course {Student *theStudent ; // each Course object will have a pointer to a Student

Object. . . // it needs initialisation at run time and can be used to

send messages} ;

class Student { Course *theCourse ; AddCourse( Course *aCourse) { theCourse = aCourse ; theCourse -> theStudent = this ; }} ;

main(){

Student Fred(…..) ;Course EECE314(…) ;

Fred.AddCourse(&EECE314). . .

}

class Course { Student *theStudent ; AddStudent( Student *aStudent) { theStudent = aStudent ; theStudent -> theCourse = this ; }} ;

Course *theCourse ;

Object Fred (Instance of a ‘Student’)

Student *theStudent ;

Object EECE314 (instance of a ‘Course’)

Fred's course pointer points to

EECE314

EECE314's student pointer Points to Fred

Fred can now send messages to EECE314 and EECE314 can send messages to Fred 34

• This brings us to the more general topic of association multiplicity.• At design time (when we are drawing our class diagrams) we cannot always

predict how many courses a student might ‘enrol on’ or how many students enrol on each particular course, the number will vary at run-time and hence the number of objects that may exist at the end of an association could vary.

• We refer to the number of objects at the end of a class association as its ‘multiplicity’ and it is defined for both ends of the association.

• UML class diagrams can capture a variety of different multiplicities as summarised in the table below.

0..1 Could be 0 or 1 objects (caution: could be 0).

0..* Could be 0 or more objects (caution: could be 0).

* Unknown many (caution: could be 0).

1 Guaranteed always to be exactly 1 object.

n Guaranteed always to be exactly ‘n’ objects (e.g. 5).

1..* Unknown many but at least 1 and maybe more objects.

Association: Multiplicity

35

• Capturing Multiplicity on a class Diagram

‘*’ indicates that a Student may be associated with many Courses

‘*’ indicates that a Course may be associated with many

Students

*

*

To set multiplicity in V.Paradigm, 'right-mouse-click' on one end of the association and select 'Multiplicity'

36

Aggregation Relationships

• When one object owns (“has a”) relationship with other

• The ownership does not affect the message passing (either can send a message to the other)

3737

What does aggregation mean from a code perspective?

• Aggregation actually implies the same code as an association, i.e. a pointer in the owner class pointing to the part that it owns. For example

class Car{

Engine *MyEngine ; // pointers to point to the ‘part’Gearbox *MyGearbox;. . .Engine *GetEngine() { return MyEngine ; } // allows for retrieval of the enginevoid AddEngine(Engine *theNewEngine ) { // permits ownership of a engine

MyEngine = theNewEngine ; // point to new engine }Engine *ExchangeEngine(Engine *theNewEngine ) { // swap an engine for a new one

Engine *temp = MyEngine ; // save pointer to current engineMyEngine = theNewEngine; // point car to it’s new enginereturn temp; // return pointer to old engine for

} // re-use or destruction later};

• In this respect aggregation has been described as a modelling placebo that is, “Using it

makes you feel good” but doesn’t alter the fact that aggregation is still implemented in

code exactly like an association, nothing different.

• The Car destructor would be altered so that it does not delete the Engine and Gearbox

objects. Similarly, GetEngine() and GetGearbox() functions would be created to detach

the owned objects and return them back to the caller. 38

Composition• Composition is a stronger form of aggregation where the

life times of the owner and parts are the same, implying that the ‘owner’ is responsible for the creation and destruction of its ‘parts’.

39

Composition Diamond

What Composition Mean?

• Parts cannot be detached from the owner.

• Their lives are the same (one is part of the other); once owner destroyed, the parts are also destroyed.

• Parts cannot be shared amongst owners (i.e. the multiplicity at the owner end is always 1).

40

Composition in Code Perspective

41

Owner responsible for creation of parts

Owner responsible for destruction of parts

Access to Parts is via the Owner (Car) only

class Car{private:

Engine *MyEngine ; // ‘Parts’ created by owner when owner is createdGearbox *MyGearbox; // and destroyed when owner is

destroyed

public:Car(…..) { // constructor takes optional args to initialise Eng/Gearbox

MyEngine = new Engine(…..) ; MyGearbox = new Gearbox(…..) ;}

~Car() { delete MyEngine ; delete MyGearbox ;}// no functions to permit the returning of a pointer to the engine or gearbox

allowed// no function to add or swap the engine or gearbox allowed as this implies

sharing of the part

// all functions to manipulate Engine and Gearbox from outside the Car class

// and must go through the car class e.g.

void ChangeGear( int newGear) { MyGearbox->ChangeGear( newGear); }void StartEngine() { MyEngine -> Start(); }void StopEngine() { MyEngine->Stop(); }

} ;

Generalisation• In UML, this is how we create ‘Kind-of’ relationships which

implies two things:

Inheritance Substitutability.

• Inheritance derived or child classes get it from base/parent

• Substitutability child or derived class could substitute base/parent

42

Generalisation (inheritance). This means that ‘Intel CPU’ is a ‘kind-of’ CPU. It also means that ‘Intel CPU’ is a substitute for a CPU

Generalisation (inheritance). This means that ‘AMD CPU’ is a ‘kind-of’ CPU. It also means that ‘AMD CPU’ is a substitute for a CPU

‘Mobile Athlon 64’ is a ‘kind-of’ AMD CPU. It also means that ‘Mobile Athlon 64’ is a substitute for an ‘AMD CPU’ (but not an Intel CPU) and is also a substitute for a ‘CPU’

Through the process of inheritance, all classes lower in the hierarchy inherit the member functions and variables of all classes higher up, and can add or redefine operations thus an Athlon 64FX can perform Reset(), Run() and Interrupt() or could redefine those operations to work in different ways to the base class CPU

‘Core 2 Duo’ is a ‘kind-of’ Intel CPU. It also means that ‘Core 2 Duo’ is a substitute for an ‘Intel CPU’ (but not an AMD CPU) and is also a substitute for a ‘CPU’

Through the process of inheritance, all classes lower in the hierarchy inherit the member functions and variables of all classes higher up, and can add or redefine operations thus a Core 2 can perform Reset(), Run() and Interrupt() or could redefine those operations to work in different ways to the base class CPU

What does inheritance means in terms of Code

class IntelCPU : public CPU {public:

IntelCPU(…..) : CPU(….) { /* constructor calls base class constructor */ }// new or overridden member functions and/or variables

} ;

class AMDCPU : public CPU {public:

AMDCPU(…..) : CPU(….) { /* constructor calls base class constructor */ }// new or overridden member functions and/or variables

} ;

class IntelCoreDuo : public IntelCPU {public:

IntelCoreDuo(…..) : IntelCPU(….) { /* constructor calls base class constructor */ }// new or overridden member functions and/or variables

} ;

C++ code stating that ‘IntelCPU’ is derived from ‘CPU’, the ‘public’ means that the interfaces of the base class ‘CPU’ are available to the user of an ‘IntelCPU’

Derived class constructor calls base class constructor to initialise base class member variables

44

Now we can create code like this

int main()

{

CPU *theCPU = new IntelCoreDuo(…) ;

theCPU ->reset() ;

theCPU ->run() ;

} ;

Exercise: Identify as many components as you can to make up a desktop PC

and identify the relationships between them and where relevant their multiplicities, don’t forget to include things like different kinds of CPU, cases, disk drives motherboards etc.

Now draw a class diagram to represent them and show how those relationships would be mapped to code (ignore member variables and functions – just capture the code to represent the relationships.

Base class pointer can point to a derived class object because the derived class object is a valid substitute for the base class

45

What Is Next?

• Best practices for software development projects http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html

• Data and Analysis Center for Software: http://www.thedacs.com/Agile Development, Scrum, RUP.

• Michael Cook PhD student at Imperial College http://www.gamesbyangelina.org/

• Dr Sid Fels, http://hct.ece.ubc.ca/

46