Why we analyze requirements Technical terms used with ... · IS352 © Peter Lo 2005 1 Requirements...
Transcript of Why we analyze requirements Technical terms used with ... · IS352 © Peter Lo 2005 1 Requirements...
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