Post on 17-Sep-2018
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
MTAT.03.094
Software Engineering
Lecture 03:
Requirements Engineering
– Part 2
Dietmar Pfahl
email: dietmar.pfahl@ut.ee Fall 2014
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Labs Next Week
Make sure you submit your
Lab Task 1 solution
on time via GitHub!
(double-check submission deadlines: it’s at midnight before your lab takes place)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Schedule of Lectures
Week 01: Introduction to SE
Week 02: Requirements Engineering I
Week 03: Requirements Engineering II
Week 04: Analysis
Week 05: Development Infrastructure I
Week 06: Development Infrastructure II
Week 07: Architecture and Design
Week 08: Refactoring
Week 09: Verification and Validation I
Week 10: Verification and Validation II
Week 11: Software Quality
Management
Week 12: Agile/Lean Methods
Week 13: Measurement & Process
Improvement
Week 14: Course wrap-up, review and
exam preparation
Week 15: no lecture
Week 16: no lecture
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Acknowledgements
Textbooks/Slides:
• Ian Sommerville: Software Engineering, 9th edition, 2010 (http://www.softwareengineering-9.com/)
• Ivan Marsic: Software Engineering, 2012 (http://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Goal of this Lecture:
To give answers to the following questions …
What is ‘Requirements
Engineering’?
Why is RE important?
Why is RE difficult?
Who is involved in RE?
What are ‘Requirements’?
What types of requirements exist?
What levels of requirements exist?
What process steps are involved in
RE?
How to get started with RE?
How to elicit requirements?
How to represent/document
requirements?
How to use requirements for
project planning?
How to model the Application
Domain?
(new)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Representation Styles
• Natural language (plus supporting tables and graphs)
• Structured natural language / Scenarios
• e.g., use case descriptions, user stories, CRC cards, ...
• Semi-formal notations
• e.g., UML diagrams (use case diagrams, class diagrams, state diagram, sequence charts, etc.)
• Formal notations (with formal semantics)
• e.g., abstract model-based (Z, VDM, Larch, B, ...) or algebraic (Clear, OBJ, ACT-ONE, ...)
Not covered in this course
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example: Home Access Control
Objective: Design an electronic system for:
• Home access control
• Locks and lighting operation
• Intrusion detection and warning
System
Lock Photosensor Switch
Light bulb
Alarm bell
1
2
3
4
5
X
Y
1
2
3
4
5
X
Y
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example NL Requirements
Identifier Priority Requirement
REQ1 5
The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When
the lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically
armed (if still disarmed).
REQ2 2 The system shall lock the door when commanded by pressing a dedicated button.
REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices.
REQ4 4
The system should allow mistakes while entering the key code. However, to resist “dictionary attacks,” the
number of allowed failed attempts shall be small, say three, after which the system will block and the alarm
bell shall be sounded.
REQ5 2 The system shall maintain a history log of all attempted accesses for later review.
REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones.
REQ7 2 The system shall allow configuring the preferences for device activation when the user provides a valid key
code, as well as when a burglary attempt is detected.
REQ8 1
The system should allow searching the history log by specifying one or more of these parameters: the time
frame, the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function
shall be available over the Web by pointing a browser to a specified URL.
REQ9 1 The system should allow filing inquiries about “suspicious” accesses. This function shall be available over
the Web.
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
NL Requirements vs. User Stories
Traditional requirement – “shall” statements:
• “The system shall provide a user configurable interface for all user and system manager functions”
• “The user interface shall be configurable in the areas of:
• Screen layout
• Font
• Background and text color
Corresponding “User Story”:
• “As a system user or system manager, …
• … I want to be able to configure the user interface for screen layout, font, background color, and text color, …
• … so that I can use the system in the most efficient manner”
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example User Stories
Identifier User Story
ST-1 As an authorized person (tenant or landlord), I can keep the doors locked at all times.
ST-2 As an authorized person (tenant or landlord), I can lock the doors on demand.
ST-3 As an authorized person (tenant or landlord), I want the lock be automatically locked after a defined period of time.
ST-4 As an authorized person (tenant or landlord), I can unlock the doors. (Test: Allow a small number of mistakes, say three.)
ST-5 As a landlord, I can at runtime manage authorized persons.
ST-6 As an authorized person (tenant or landlord), I can view past accesses.
ST-7 As a tenant, I can configure the preferences for activation of various devices.
ST-8 As a tenant, I can file complaint about “suspicious” accesses.
Note: ’Why’ part is missing in the examples above.
REQ1
REQ2
REQ3
REQ4
...
etc.
REQ8
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Effort Estimation with User Story Points
• Points assigned to individual user stories
• Total work size estimate:
Total size = points-for-story i (i = 1..N)
• Velocity (= Productivity) estimated from experience
• Estimate the work duration:
Project duration = [time unit] Total size
Velocity
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example User Stories
Identifier User Story Size
ST-1 As an authorized person (tenant or landlord), I can keep the doors locked at all times. 4 points
ST-2 As an authorized person (tenant or landlord), I can lock the doors on demand. 3 pts
ST-3 The lock should be automatically locked after a defined period of time. 6 pts
ST-4 As an authorized person (tenant or landlord), I can unlock the doors. (Test: Allow a small number of mistakes, say three.)
9 points
ST-5 As a landlord, I can at runtime manage authorized persons. 10 pts
ST-6 As an authorized person (tenant or landlord), I can view past accesses. 6 pts
ST-7 As a tenant, I can configure the preferences for activation of various devices. 6 pts
ST-8 As a tenant, I can file complaint about “suspicious” accesses. 6 pts
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example Effort Estimation
• Points assigned to individual user stories
• Total work size estimate:
Total size = points-for-story i (i = 1..N)
• Velocity (= Productivity) estimated from experience
• Estimate the work duration:
Project duration = [time unit] Total size
Velocity
8 User Stories
50 US Points
Average Team Size: 6 persons Average Project Size: 600 USPs Average Project Duration: 60 days Average Velocity (6 pers): 10 USP/day = 1.25 USP/h
50 US Points & 4 Pers. Team: Duration: 50/(10*4/6) = 7.5 days
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Agile Project Effort Estimation
?
assumes that 1 person works fulltime on this task without interruption
Time
2nd iteration n - th iteration
Estimated completion date
Items pulled by the team into an iteration
1) ST - 4: Unlock 15 hours (9pts )
Work backlog
2) ST - 2: Lock 5 hours (3pts )
3) ST - 5: Manage Users 16 hours (10pts)
4) ST - 7: Preferences 10 hours (6pts )
1st iteration
5) ST - 6: View History 10 hours (6pts)
6) ST - …
Work items
20 days
5 days (40 hours) List prioritized by the customer
Estimated work duration
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Cases
• For Functional Requirements Analysis and Specification
• A use case is a description of how a user will use the system-to-be to accomplish business goals
• Detailed use cases are usually written as usage scenarios or scripts, listing a specific sequence of actions and interactions between the actors and the system
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Types of Actors
• Initiating actor (also called primary actor or “user”): initiates the use case to realize a goal
• Participating actor (also called secondary actor): participates in the use case but does not initiate it:
• Supporting actor: helps the system-to-be to complete the use case
• Offstage actor: passively participates in the use case, i.e., neither initiates nor helps complete the use case, but may be notified about some aspect of it (e.g., for keeping records)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Finding Use Cases
• For each actor, ask the following questions:
• Which functions does the actor require from the system?
• What does the actor need to do?
• Does the actor need to read, create, destroy, modify, or store some kinds of information in the system?
• Does the actor have to be notified about events in the system?
• Does the actor need to notify the system about something?
• What do those events require in terms of system functionality?
• Could the actor’s daily work be simplified or made more efficient through new functions provided by the system?
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Deriving Use Cases from System Requirements
REQ1: Keep door locked and auto-lock REQ2: Lock when “LOCK” pressed REQ3: Unlock when valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring the device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries
( Actors are often given, if working from user stories instead of ‘shall/should’-statements.)
1
2
3
4
5
X
Y
1
2
3
4
5
X
Y
Actor Actor’s Goal (what the actor intends to accomplish) Use Case Name
Landlord To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Landlord To lock the door & shut the lights (sometimes?). Lock (UC-2)
Landlord To create a new user account and allow access to home. AddUser (UC-3)
Landlord To retire an existing user account and disable access. RemoveUser (UC-4)
Tenant To find out who accessed the home in a given interval of time and potentially file complaints.
InspectAccessHistory (UC-5)
Tenant To disarm the lock and enter, and get space lighted up. Unlock (UC-1)
Tenant To lock the door & shut the lights (sometimes?). Lock (UC-2)
Tenant To configure the device activation preferences. SetDevicePrefs (UC-6)
LockDevice To control the physical lock mechanism. UC-1, UC-2
LightSwitch To control the lightbulb. UC-1, UC-2
[to be identified]
To auto-lock the door if it is left unlocked for a given interval of time.
AutoLock (UC-2)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Traceability Matrix Mapping: System requirements to Use cases
UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login
REQ1: Keep door locked and auto-lock REQ2: Lock when “LOCK” pressed REQ3: Unlock when valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring the device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries
5 2 2 2 1 5 2 1
UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8
REQ1
REQ2
REQ3
REQ4
REQ5
REQ6
REQ7
REQ8
REQ9
5
2
5
4
2
1
2
1
1
Req’t PW
Max PW
15 3 2 2 3 9 2 3Total PW
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X X
X
X
5 5 1 1 1 2 5 2
16 9 1 1 2 2 9 5 PW = Priority Weight
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Traceability Matrix Purpose
• To check that all requirements are covered by the use cases
• To check that none of the use cases is introduced without a reason (i.e., created not in response to any requirement)
• To prioritize the work on use cases
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Diagrams and Descriptions
Use Case Description:
Name of Use Case
Actors associated with Use Case
Pre-conditions
Post-conditions
Normal Flow of Events (Basic Scenario)
Alternative Flow of Events (Alternative Scenarios)
…
Use-Case Descriptions
...
Use Case Model
Actors
Use Cases
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Schema for Detailed Use Cases Use Case UC-#: Name / Identifier [verb phrase]
Related Requirements: List of the requirements that are addressed by this use case
Initiating Actor: Actor who initiates interaction with the system to accomplish a goal
Actor’s Goal: Informal description of the initiating actor’s goal
Participating Actors: Actors that will help achieve the goal or need to know about the outcome
Preconditions: What is assumed about the state of the system before the interaction starts
Postconditions: What are the results after the goal is achieved or abandoned; i.e., what must be true about the system at the time the execution of this use case is completed
Flow of Events for Main Success Scenario:
1. The initiating actor delivers an action or stimulus to the system (the arrow indicates the direction of interaction, to- or from the system)
2. The system’s reaction or response to the stimulus; the system can also send a message to a participating actor, if any
3. …
Flow of Events for Extensions (Alternate Scenarios): What could go wrong? List the exceptions to the routine and describe how they are handled
1a. For example, actor enters invalid data
2a. For example, power outage, network failure, or requested data unavailable
…
The arrows on the left indicate the direction of interaction: Actor’s action; System’s reaction
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case 1: Unlock
Use Case UC-1: Unlock
Related Requirem’ts:
REQ1, REQ3, REQ4, and REQ5
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.
Participating Actors: LockDevice, LightSwitch, Timer
Preconditions: • The set of valid keys stored in the system database is non-empty.
• The system displays the menu of available functions; at the door keypad the menu choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.
Flow of Events for Main Success Scenario: 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock” 2. include::AuthenticateUser (UC-7)
3. System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
4. System signals to the Timer to start the auto-lock timer countdown
5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Subroutine «include» UC-7 Use Case UC-7: AuthenticateUser (sub-use case)
Related Requirements:
REQ3, REQ4
Initiating Actor: Any of: Tenant, Landlord
Actor’s Goal: To be positively identified by the system (at the door interface).
Participating Actors:
AlarmBell, Police
Preconditions: • The set of valid keys stored in the system database is non-empty.
• The counter of authentication attempts equals zero.
Postconditions: None worth mentioning.
Flow of Events for Main Success Scenario: 1. System prompts the actor for identification, e.g., alphanumeric key
2. Tenant/Landlord supplies a valid identification key
3. System (a) verifies that the key is valid, and (b) signals to the actor the key validity
Flow of Events for Extensions (Alternate Scenarios):
2a. Tenant/Landlord enters an invalid identification key
1. System (a) detects error, (b) marks a failed attempt, and (c) signals to the actor
1a. System (a) detects that the count of failed attempts exceeds the maximum allowed number, (b) signals to sound AlarmBell, and (c) notifies the Police actor of a possible break-in
2. Tenant/Landlord supplies a valid identification key
3. Same as in Step 3 above
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Diagram: Device Control UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login
«participate»
«initiate + participate»
«participate»
«participate»
«participate»
«participate»
First tier use cases Second tier use casessystem
boundary
communication
«include»
use case
«initiate»
«initiate»
Timer
LightSwitch
LockDevice
«initiate
»Tenant
Landlord
actor
«initiate»
UC1: Unlock
UC2: Lock
UC7: AuthenticateUser
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Diagram: Account Management UC1: Unlock
UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login
Account Management Subsystem
«initiate»
Tenant
Landlord«include»
«include»«particip
ate»
«initiate»«i
nclu
de»
«include»
«initiate»
«initiate»
UC8: Login
UC4: RemoveUser
UC6: SetDevicePrefs
UC3: AddUser
UC5: InspectAccessHistory
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
‘Login’ Use Case?
AddUser
SetDevicePrefs Landlord
Login Landlord
AddUser
SetDevicePrefs
Login
BAD: GOOD:
A novice developer frequently identifies user login as a use case. On the other hand, expert developers argue that login is not a use case in its own right. Recall that use case is motivated by user’s goal; The user initiates interaction with the system to achieve a certain goal. You are not logging in for the sake of logging in—you are logging in to do some work, and this work is your use case.
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Optional Use Cases: «extend»
Example optional use cases:
UC6: SetDevicePrefs
UC5: InspectAccessHistory
ManageAccount
UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login
Key differences between «include» and «extend» relationships
Is this use case optional?
Is the base use case complete without this use case?
Is the execution of this use case conditional?
Does this use case change the behavior of the base use case?
Included use case Extending use case
No Yes
No Yes
No Yes
No Yes
[ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Points
For the sum of all Use Cases:
UCP equation is composed of four variables:
- Unadjusted Use Case Point (UUCP)
- The Technical Complexity Factor (TCF)
- The Environment Complexity Factor (ECF)
- The Productivity Factor (PF)
UCP = UUCP * TCF * ECF * PF
UUCP is the sum of Unadjusted Actor Weight (UAW) and Unadjusted Use Case Weight (UUCW).
UUCP = UAW + UUCW
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Unadjusted Actor Weight
Actor Type Description Weight
Simple
Communicates to system through API
1
Average
Interacts with the system through some protocol (HTTP, FTP, or probably some user defined protocol), or
Are data stores (Files, DBMS)
2
Complex
Interacts through HCI (GUI) 3
UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No. Complex actors x 3)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Unadjusted Use Case Weight
Use Case Type Description Weight
Simple 1 to 3 transactions 5
Average 4 to 7 transactions 10
Complex 8 or more transactions 15
UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Case x 10) + (Total No. Complex Use Cases x 15)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Technical Complexity Factor – TCF
Technical Factor Description Weight
TF(1) Distributed System 2
TF(2) Performance 1
TF(3) End User Efficiency 1
TF(4) Complex Internal Processing 1
TF(5) Reusability 1
TF(6) Installability 0.5
TF(7) Usability 0.5
TF(8) Portability 2
TF(9) Modifiability 1
TF(10) Concurrency 1
TF(11) Includes special security requirements 1
TF(12) Provides direct access by third parties 1
TF(13) Special User training facilities are required 1
Each TF(i) can have a value from 0 (factor is irrelevant) to 5 (factor is essential)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Environmental Complexity Factor - ECF
Factor
Number
Description Weight
EF(1) Familiarity with system development
process in use
1.5
EF(2) Application experience 0.5
EF(3) Object-oriented experience 1.0
EF(4) Lead analyst capability 0.5
EF(5) Motivation 1.0
EF(6) Requirements stability 2.0
EF(7) Part time staff -1.0
EF(8) Difficulty of programming language -1.0
Each EF(i) can have a value from 0 (no experience) to 5 (expert)
Complexity increases, the smaller EF(1) to EF(6) and the greater EF(7) & EF(8)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Points
For the sum of all Use Cases:
UCP equation is composed of four variables:
- Unadjusted Use Case Point (UUCP)
- The Technical Complexity Factor (TCF)
- The Environment Complexity Factor (ECF)
- The Productivity Factor (PF)
UCP = UUCP * TCF * ECF * PF
UUCP is the sum of Unadjusted Actor Weight (UAW) and Unadjusted Use Case Weight (UUCW).
UUCP = UAW + UUCW
Effort Estimation
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Case Points: Project Effort
For the sum of all Use Cases:
UCP equation is composed of four variables:
- Unadjusted Use Case Point (UUCP)
- The Technical Complexity Factor (TCF)
- The Environment Complexity Factor (ECF)
- The Productivity Factor (PF)
UCP = UUCP * TCF * ECF * PF [person-hours]
UUCP is the sum of Unadjusted Actor Weight (UAW) and Unadjusted Use Case Weight (UUCW).
UUCP = UAW + UUCW
Either 20 person-hours/UCP or 28 person-hours/UCP
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Productivity Factor - PF
If sum of [(number of factors E1 through E6 assigned value < 3)
and (number of factors E7 and E8 assigned value > 3)] ≤ 2
PF = 20 ph/UCP
Else
If sum of [(number of factors E1 through E6 assigned value < 3)
and (number of factors E7 and E8 assigned value > 3)] = 3 or 4
PF = 28 ph/UCP
Else: Rethink project; it has too high a risk of failure
Example: http://en.wikipedia.org/wiki/Use_Case_Points
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Goal of this Lecture:
To give answers to the following questions …
What is ‘Requirements
Engineering’?
Why is RE important?
Why is RE difficult?
Who is involved in RE?
What are ‘Requirements’?
What types of requirements exist?
What levels of requirements exist?
What process steps are involved in
RE?
How to get started with RE?
How to elicit requirements?
How to represent/document
requirements?
How to use requirements for
project planning?
How to model the Application
Domain?
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
RE Activities: Iteration & Concurrency
Model
Model
Mo
de
l Mo
de
l
Initial information Scope Constraints
Requirements traced back
to their source
+ Requirements Management
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Use Cases vs. Domain Model
(b) (a)
In use case analysis, we consider the system as a “black box”
Use Case 1
Use Case 2
Use Case NActor
System
Actors
Use Case 1
Use Case 2
Use Case NActor
System
Actors
Actor
Domain Model
Actors
Actor
Domain Model
Actors
In domain analysis, we consider the system as a “transparent box”
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example: ATM Machine
(b)
(a)
12
345
67
890
12
345
67
890
Actor(Bank
customer)
System
Actor(Remote
datacenter)
(ATM machine)
Concept 2
Concept 1
Actor
Concept 3
Concept n
Domain Model
Actor
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Building a Domain Model
Step 1: Identifying the boundary concepts
Step 2: Identifying the internal concepts
Actor A
Actor B Actor D
Actor C
Boundary concepts
Concept 2Concept 2
Concept 3Concept 3
Concept 4Concept 4
Concept 1Concept 1
Actor A
Actor B
Actor C
Actor D
Concept 1Concept 1
Concept 2Concept 2
Internal
concepts
Concept 3Concept 3
Concept 5Concept 5
Concept 4Concept 4
Concept 6Concept 6
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Object-Oriented (OO) Analysis
• OO analysis is (claimed to be) ‘natural’
• As a system evolves, the functions it performs need to be changed more often than the objects on which they operate…
• …a model based on objects (rather than functions) will be more stable over time…
• …hence the claim that object-oriented designs are more maintainable
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Object Interface
• Interface defines method “signatures”
• Method signature: name, parameters, parameter types, return type
method-1
method-2
method-3
Interface
Object hides its state (=attributes). The attributes are accessible only through the interface.
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Clients, Servers, Messages
Client ObjectClient Object Server
Object
Server
Object
Message
• Objects send messages by calling methods
• Client object: sends message and asks for service
• Server object: provides “service” and returns result
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Analysis versus Design
• During Analysis
• we want to know about the application domain and the requirements
• …so we develop a coarse-grained model to show where responsibilities are, and how objects interact
• Our models show a message being passed, but we don’t worry too much about the contents of each message
• To keep things clear, use icons to represent external objects and actors, and boxes to represent system objects
• During Design
• we want to say how the software should work
• … so we develop fine-grained models to show exactly what will happen when the system runs
• e.g. show the precise details of each method call
What vs. How
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Representation Styles
• Natural language (plus supporting tables and graphs)
• Structured natural language / Scenarios
• e.g., use case descriptions, user stories, CRC cards, ...
• Semi-formal notations
• e.g., UML diagrams (use case diagrams, class diagrams, state charts, sequence charts, etc.)
• Formal notations (with formal semantics)
• e.g., abstract model-based (Z, VDM, Larch, B, ...) or algebraic (Clear, OBJ, ACT-ONE, ...)
Not covered in this course
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Classes • A class describes a group of
objects with
• similar properties (attributes),
• common behaviour (operations),
• common relationships to other objects,
• and common meaning (“semantics”).
• Example
employee:
• has a name, employee# and department;
• an employee is hired, and fired; an employee works in one or more projects
:employee
name employee# department
hire() fire() assignproject()
Name (mandatory)
Attributes (optional)
Operations (optional)
Class Obj1
Obj2
Obj3
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Objects vs. Classes • The instances of a class are called objects
• Two different objects may have identical attribute values (like two people with identical name and address)
• Objects have associations with other objects
• E.g. Fred_Bloggs:employee is associated with the KillerApp:project object
• But we will capture these relationships at the class level (why?)
Fred_Bloggs:employee
name: Fred Bloggs
Employee #: 234609234
Department: Marketing
In diagrams, write :employee in the name field to distinguish object from class (we will see this later, e.g. in Sequence Charts)
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Finding Classes
• Finding classes from primary sources
• Look for nouns and noun phrases in stakeholders’ descriptions of the problem
• include in the model if they explain the nature or structure of information in the application
• Finding classes from other sources
• Reviewing background information
• Users and other stakeholders
• Analysis patterns
• It’s better to include many candidate classes at first
• You can always eliminate them later if they turn out not to be useful
• Explicitly deciding to discard classes is better than just not thinking about them
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Associations
:StaffMember
staffName staff# staffStartDate
:Client
companyAddress companyEmail companyFax companyName companyTelephone
1 0..* liaises with
contact person
ClientList
Name of the
association
Multiplicity A staff member has
zero or more clients on His/her clientList
Multiplicity A client has
exactly one staffmember as a contact person
Direction The “liaises with”
association should be read in this direction
Role The clients’ role
in this association is as a clientList
Role The staffmember’s
role in this association is as a contact person
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Multiplicity
• Optional (0 or 1) 0..1
• Exactly one 1 (alternative: 1..1)
• Zero or more 0..* (alternative: *)
• One or more 1..*
• A range of values 1..6
• A set of ranges 1..3, 7..10, 15, 19..*
73
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Aggregation and Composition • Aggregation
• This is the “Has-a” or “Whole/part” relationship
• Composition
• Strong form of aggregation that implies ownership:
• if the whole is removed from the model, so is the part
• the whole is responsible for the disposition of its parts
78
composition
aggregation
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Generalisation A superclass
Two subclasses
Superclass associations are inherited by subclasses • Sub-classes inherit attributes,
associations, & operations from the superclass
• A sub-class may override an inherited aspect
• Super-classes may be declared {abstract}, meaning they have no instances
• Implies that the sub-classes cover all possibilities
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Class diagram
81
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Example: Domain Model (snippet) Domain model for UC-1: Unlock
« control »
Controller
numOfAttempts
maxNumOfAttempts
« entity »
KeyChecker
« entity »
Key
userIdentityCode
timestamp
doorLocation
« entity »
KeyStorage
conveys
requests
verifies
retrieves valid keys
“ Reading direction arrow. ”
Has no meaning; it only helps reading
the association label, and is often left out.
« boundary »
KeycodeEntry
« boundary »
StatusDisplay
Resident
LockDevice
LightSwitch
Association
name
conveys requests « boundary »
HouseholdDeviceOperator
deviceStatuses
obtains Attributes
« control »
Controller
numOfAttempts
maxNumOfAttempts
« control »
Controller
numOfAttempts
maxNumOfAttempts
« entity »
KeyChecker
« entity »
KeyChecker
« entity »
Key
userIdentityCode
timestamp
doorLocation
« entity »
KeyStorage
« entity »
KeyStorage
conveys
requests
verifies
retrieves valid keys
“ Reading direction arrow. ”
Has no meaning; it only helps reading
the association label, and is often left out.
“ Reading direction arrow. ”
Has no meaning; it only helps reading
the association label, and is often left out.
« boundary »
KeycodeEntry
« boundary »
StatusDisplay
Resident
LockDevice
LightSwitch
Association
name
conveys requests « boundary »
HouseholdDeviceOperator
deviceStatuses
obtains Attributes
MTAT.03.094 / Lecture 03 / © Dietmar Pfahl 2014
Next Lecture
• Date/Time:
• Friday, 26 Sep, 14:15-16:00
• Topic:
• Analysis
• For you to do:
• Make sure you submit your Lab Task1 solution
on time (double-check submission deadlines!)
• Use next week’s lab time for consultation