IS352 © Peter Lo 2005 1

Requirements Analysis

IS352 © Peter Lo 2005 2

In this Lecture you will Learn:

Why we analyze requirementsTechnical terms used with class diagramsHow the UML class diagram expresses a detailed model of user requirementsHow to realize use cases with collaboration diagrams and class diagramsHow the (Class-Responsibility Collaboration) CRC technique helps identify classes and allocate responsibilities

IS352 © Peter Lo 2005 3

Why Analyse Requirements?

Use case model alone is not enoughThere may be repetitionSome parts may already exist as standard components

Analysis aims to identifyCommon elementsPre-existing elementsInteraction between different requirements

IS352 © Peter Lo 2005 4

What a Requirements Model must do?

A requirements model meets two main needs:Confirms what users want a new system to do

Must be understandable for usersMust be correct and complete

Specifies what designers must designMust be unambiguous

IS352 © Peter Lo 2005 5

What a Requirements Model must do?

Describes what the software should doRepresents people, things and concepts important to understand what is going onShows connections and interactions among these people, things and conceptsShows the business situation in enough detail to evaluate possible designsIs organized so as to be useful for designing the software

IS352 © Peter Lo 2005 6

How we Model the Analysis?

The main tool used for analysing requirements is the class diagramTwo main ways to produce this:

Directly based on knowledge of the application domain (Domain Model)By producing a separate class diagram for each use case, then assembling them into a single model (Analysis Class Model)

IS352 © Peter Lo 2005 7

Class Exercise

Why are requirements models in Information System development neither entirely graphical nor entirely textual?

IS352 © Peter Lo 2005 8

Use Case Realization

An activity that moves by stages from a use case to the implementation of a set of software classes that adequately fulfills the requirements of the use case.

IS352 © Peter Lo 2005 9

Collaboration

A set of objects (and their relationships) that are collectively capable of interacting to deliver the functionality of a use case. The UML specification gives other definitions that are much more abstract and general. The definition given here expresses the essentials of the concept in this context.

IS352 © Peter Lo 2005 10

Use Case Realization: An Example

Use Case Diagram for “Add a new advert to a campaign”.

IS352 © Peter Lo 2005 11

Use Case Realization: An Example

Collaboration for “Add a new advert to a campaign”.

IS352 © Peter Lo 2005 12

Use Case Realization: An Example

A Collaboration realizes a specific use case

IS352 © Peter Lo 2005 13

Use Case Realization: An Example

Collaboration Diagram for “Add a new advert to a campaign”

IS352 © Peter Lo 2005 14

Use Case Realization: An Example

Object Instance Diagram for “Add a new advert to a campaign”

IS352 © Peter Lo 2005 15

Use Case Realization: An Example

Analysis Class Diagram for “Add a new advert to a campaign”

IS352 © Peter Lo 2005 16

Class Diagram: Stereotypes

Analysis class stereotypes differentiate the roles objects can play:

Boundary Objects model interaction between the system and actors (and other systems)Entity Objects represent information and behaviour in the application domainControl Objects co-ordinate and control other objects

IS352 © Peter Lo 2005 17

Class Diagram: Stereotypes

Alternative Notations for Boundary Class

IS352 © Peter Lo 2005 18

Class Diagram: Stereotypes

Alternative Notations for Entity Class

IS352 © Peter Lo 2005 19

Class Diagram: Stereotypes

Alternative Notations for Control Class

IS352 © Peter Lo 2005 20

Class Diagram: Class SymbolClass name compartment

Attributes compartment

Operations compartment

IS352 © Peter Lo 2005 21

Class Diagram: Instance Symbol

Object name compartment

Attribute values

Instances do not have operationsIS352 © Peter Lo 2005 22

Class Exercise

In what sense are classes generally more stable than their instances, and why is this usually the case?

IS352 © Peter Lo 2005 23

Class Diagram: Attributes

Attributes are:Part of the essential description of a classThe common structure of what the class can ‘know’Each object has its own value for each attribute in its class

IS352 © Peter Lo 2005 24

Class Exercise

What is an attribute?

IS352 © Peter Lo 2005 25

Class Exercise

Distinguish between Attribute and Value

IS352 © Peter Lo 2005 26

Class Diagram: Associations

Associations represent:The possibility of a logical relationship or connection between objects of one class and objects of anotherIf two objects can be linked, their classes have an association

IS352 © Peter Lo 2005 27

Class Diagram: Associations

Association role

Association

Association name Direction in which name should be read

IS352 © Peter Lo 2005 28

Link

A link expresses a logical connection between instances/objects

IS352 © Peter Lo 2005 29

Class Diagram: Links

A link is a logical connection between two objects

IS352 © Peter Lo 2005 30

Class Exercise

Distinguish between Link and Association

IS352 © Peter Lo 2005 31

Class Diagram: Multiplicity

Associations have multiplicityMultiplicity is the range of permitted cardinalities of an associationRepresent enterprise (or business) rulesFor example:

Any bank customer may have one or more accountsEvery account is for one, and only one, customer

IS352 © Peter Lo 2005 32

Class Diagram: Multiplicity

Multiplicities

IS352 © Peter Lo 2005 33

Class Diagram: Multiplicity Example

A Campaign is conducted by zero or more Adverts while each Advert belongs to exactly one Campaign

IS352 © Peter Lo 2005 34

Class Diagram: Multiplicity Example

Every StaffMember must be allocated to one or more Grades, while a Grade may have zero, one or more staff allocated to it.

IS352 © Peter Lo 2005 35

Class Diagram: Multiplicity Example

A Poker Hand contains up to 7 cards. Each card dealt must be in only one hand (although a card may still be undealt in the pack). This assumes no cheating.

IS352 © Peter Lo 2005 36

Class Exercise

What is multiplicity, and why can it be called a constraint?

IS352 © Peter Lo 2005 37

Class Diagram: Operations

Operations are:An essential part of the description of a classThe common behaviour shared by all objects of the classServices that objects of a class can provide to other objects

IS352 © Peter Lo 2005 38

Class Diagram: Operations

Operations describe what instances of a class can do:

Set or reveal attribute valuesPerform calculationsSend messages to other objectsCreate or destroy links

Campaign

actualCostcampaignFinishDatecampaignStartDatecompletionDatedatePaidestimatedCosttitlecheckCampaignBudget ( )getCampaignContribution ( )recordPayment ( )setCompleted ( )

IS352 © Peter Lo 2005 39

Class Diagram: Operations

IS352 © Peter Lo 2005 40

Class Exercise

What is an operation?

IS352 © Peter Lo 2005 41

Class Exercise

How are operations related to messages?

IS352 © Peter Lo 2005 42

From Requirements to Classes

Campaign Manager

Add a new advert to a campaign

Add a new advert to a campaign

:Client

:Campaign :Advert

Advert

setCompleted()createNewAdvert()

<<entity>>

User Interface::AddAdvertUI

startInterface()createNewAdvert()selectClient()selectCampaign()

<<boundary>>

CampaigntitlecampaignStartDatecampaignFinishDate

getCampaignAdverts()addNewAdvert()

<<entity>>

1 0..*

conducted by

ClientcompanyAddresscompanyNamecompanyTelephonecompanyFaxcompanyEmail

getClientCampaigns()getClients()

<<entity>>

1 0..*

places

Control::AddAdvert

showClientCampaigns()showCampaignAdverts()createNewAdvert()

<<control>>

CampaignManager

3.1.2: *getCampaignDetails()

5.1.1.1: createAdvert()

4.1.2: *getAdvertDetails()

5.1.1: addNewAdvert()

:AddAdvertUI :AddAdvert

:Client :Campaign

:Advert

3.1: showClientCampaigns()3: selectClient()

4: selectCampaign() 4.1: showCampaignAdverts()

4.1.1: listAdverts()

5: createNewAdvert() 5.1: addNewAdvert()

newAd:Advert

2: startInterface()

3.1.1: listCampaigns()

1:*getClient()

1

2

3

4

IS352 © Peter Lo 2005 43

From Requirements to Classes

Start with one use caseIdentify the likely classes involved (the use case collaboration)Draw a collaboration diagram that fulfils the needs of the use caseTranslate this collaboration into a class diagramRepeat for other use cases

IS352 © Peter Lo 2005 44

Reasonability Checks for Candidate Classes

A number of tests help to check whether a candidate class is reasonable

Is it beyond the scope of the system?Does it refer to the system as a whole?Does it duplicate another class?Is it too vague?Is it too tied up with physical inputs and outputs?Is it really an attribute?Is it really an operation?Is it really an association?

IS352 © Peter Lo 2005 45

Reasonability Checks for Candidate Classes (cont’d)

If any answer is ‘Yes’, consider modelling the potential class in some other way (or do not model it at all)

IS352 © Peter Lo 2005 46

Example: Drawing a Class Diagram

IS352 © Peter Lo 2005 47

Example: Drawing a Class Diagram

Initial collaboration diagram for “Assign staff to work on a campaign”

IS352 © Peter Lo 2005 48

Example: Drawing a Class Diagram

Boundary and control objects added, giving a different view on how the object interaction might work

IS352 © Peter Lo 2005 49

Example: Drawing a Class Diagram

Alternative notation for essentially the previous diagram

IS352 © Peter Lo 2005 50

Example: Drawing a Class Diagram

Further refinement has introduced links between some entity objects

IS352 © Peter Lo 2005 51

Example: Drawing a Class Diagram

Near-final collaboration diagram for Assign staff to work on a campaign.

IS352 © Peter Lo 2005 52

Example: Drawing a Class Diagram

Class Diagram for the use case Assign staff to work on a campaign.

IS352 © Peter Lo 2005 53

Collaboration Diagram vs. Class Diagram

A collaboration diagram typically shows instances and links, while a class diagram typically shows only classes and their associations. A collaboration diagram shows only those objects that participate in a specific interaction, while a class diagram typically shows a structure that may be capable of supporting different interactions. A collaboration diagram shows messages between objects, while a class diagram does not.

IS352 © Peter Lo 2005 54

Example: Adding and Locating Attributes

Partially completed Agate class diagram

IS352 © Peter Lo 2005 55

Example: Adding and Locating Attributes

An association class gives a home to attributes that properly belong to a link between two objects

IS352 © Peter Lo 2005 56

CRC Cards

Class–Responsibility–Collaboration cards help to model interaction between objectsFor a given scenario (or use case):

Brainstorm the objectsAllocate to team membersRole play the interaction

IS352 © Peter Lo 2005 57

CRC Cards

Effective role play depends on an explicit strategy for distributing responsibility among classesFor example:

Each role player tries to be lazyPersuades other players their class should accept responsibility for a given task

May use ‘Paper CASE’ to document the associations and links

IS352 © Peter Lo 2005 58

Format for a CRC Cards

IS352 © Peter Lo 2005 59

Example: CRC Cards

CRC card for the use case “Assign staff to work on a campaign”

IS352 © Peter Lo 2005 60

Assembling the Analysis Class Diagram