Upload
sheena-mohammed
View
235
Download
0
Embed Size (px)
Citation preview
7/30/2019 Req Modeling
1/78
Use Case Modeling
7/30/2019 Req Modeling
2/78
Commonly Used UML Diagrams
The most commonly used UML diagrams are:
Use case diagram, describing how the system is
used.
The starting point for UML modeling.
Use case (not a diagram).
Activity diagram.
Each use case may create one activity diagram.
7/30/2019 Req Modeling
3/78
Commonly Used UML Diagrams
The most commonly used UML diagrams
(continued):
Sequence diagram, showing the sequence of
activities and class relationships. Each use case may create one or more sequence
diagrams.
A collaboration diagram is an alternative to a sequence
diagram.
7/30/2019 Req Modeling
4/78
Commonly Used UML Diagrams
The most commonly used UML diagrams
(continued):
Class diagram, showing classes and relationships.
Sequence diagrams and CRC cards are used todetermine classes.
Statechart diagram.
Each class may create a statechart diagram, useful for
determining class methods.
7/30/2019 Req Modeling
5/78
Kendall & Kendall 2005 Pearson Prentice Hall 18-5
Overview of UML Diagrams
7/30/2019 Req Modeling
6/78
Use Cases
Depiction of a systems behavior or
functionality under various conditions as the
system responds to requests from users
Full functioning for a specific business purpose
7/30/2019 Req Modeling
7/78
Use Case Diagram
A use (yoos) case describes what the system does,
not how it does the work.
The use case model reflects the view of the system of
the user outside of the system. Symbols are:
Actor, a stick figure.
Use case, an oval.
Connecting lines.
7/30/2019 Req Modeling
8/78
UML Use Case Diagram Symbols
Use Case
Actor
Boundary
Connection
Include relationship
Extend relationship
7/30/2019 Req Modeling
9/78
Actors
Represent role played by one or more users
Exist outside of the system
May be a person, another system, a device, such as a
keyboard or Web connection
Can initiate an instance of a use case
May interact with one or more use cases and a use
case may involve one or more actors
7/30/2019 Req Modeling
10/78
Actors (Continued)
Actors may be divided into two groups:
Primary actors supply data or receive
information from the system
Secondary actors help to keep the system
running or provide help
Help desk, analysts, programmers, etc.
7/30/2019 Req Modeling
11/78
What is a Boundary?
A boundary is the dividing line between the
system and its environment.
Use cases are within the boundary.
Actors are outside of the boundary.
7/30/2019 Req Modeling
12/78
Use Case
Consists of three things:
An actor (user) that initiates an event.
An event that triggers a use case.
The use case that performs the actions triggered
by the event.
7/30/2019 Req Modeling
13/78
Use Case (Continued)
Better to create fewer use cases
20 use cases for a large system
50 use cases would be the maximum for alarge system
Can nest use cases, if needed
7/30/2019 Req Modeling
14/78
What is a Connection?
A connection is an association between an
actor and a use case.
Depicts a usage relationship
Connection does not indicate data flow
7/30/2019 Req Modeling
15/78
Use Case Relationships
Communicates
Connect an actor to a use case
Includes
Use case contains a behavior that is common tomore than one use case.
The common use case is included in other usecases.
Dotted arrow points toward common use case.
7/30/2019 Req Modeling
16/78
What is an Relationship?
A connection between two use cases
Indicates a use case that is used (invoked) byanother use case
Links to general purpose functions, used bymany other use cases
7/30/2019 Req Modeling
17/78
Use Case Relationships (Continued)
Extends
A different use case handles variations orexceptions from the basic use case.
Arrow goes from extended to basic use case. Generalizes
One thing is more general than another thing.
Arrow points to the general thing.
7/30/2019 Req Modeling
18/78
What is an Relationship?
A connection between two use cases
Extends a use case by adding new behavior oractions
Specialized use case extends the general usecase
7/30/2019 Req Modeling
19/78
2005 Pearson Prentice Hall
Use Case Relationships
7/30/2019 Req Modeling
20/78
7/30/2019 Req Modeling
21/78
7/30/2019 Req Modeling
22/78
Steps for Creating a
Use Case Model
The steps required to create a use case model
are:
Review the business specifications and identify
the actors within the problem domain.
Identify the high-level events and develop the
primary use cases that describe the events and
how actors initiate them.
7/30/2019 Req Modeling
23/78
Steps for Creating a
Use Case Model
The steps required to create a use case model
are (continued):
Review each primary use case to determine
possible variations of flow through the use case.
Develop the use case documents for all primary
use cases and all important use case scenarios.
7/30/2019 Req Modeling
24/78
Data Flow Diagrams
7/30/2019 Req Modeling
25/78
Introduction
What is a Data Flow Diagram?
Why do we use DFDs?
Levelling
Conventions
Decomposition and Abstraction
The Elements
Process and Data Stores
Outside Entity
DataFlow
The LevelsRules
The Procedure for Constructing DFDs
The Document Flow Diagram
7/30/2019 Req Modeling
26/78
What is a Data Flow Diagram?
Known as DFDs
A way to model a real world situation
They are the interface between the realworld activities and an understanding
of how this can be converted into a
computer system.
7/30/2019 Req Modeling
27/78
Why do we use DFDs?
It is a way of taking the physical viewand converting it into a logical view.
The physical view - all documents
involved
The logical view - the data they
contain
Their main purpose is tocommunicate with the user, the
analysts understanding of the scope
of the required system
7/30/2019 Req Modeling
28/78
Levelling
DFDs are expanded or decomposedinto levels.
Separating each process into sub
processes Uncovers more and more detail
7/30/2019 Req Modeling
29/78
ConventionsBalancing
Process at lower level should have identicaldata flows if they flow out of a process
Modelling Data Stores
Only use DATA STORES used within thisprocess on the diagram
Numbering
1 - 1.1 - 1.1.1
1.2 - 1.2.1
Labels
Should carry as much meaning as possible
7/30/2019 Req Modeling
30/78
Decomposition and Abstraction
Decomposition - Divide and
subdivide into manageable size
problems
Abstraction - Concentrate on the
important issues and ignore the
irrelevant
7/30/2019 Req Modeling
31/78
The ElementsThe four main elements of DFDs
notationData Flows, with a label to
indicate what data is flowing
Processes, that handle the data
Data stores, within the system
(diary, filing cabinet or computer
file)Outside entities, outside sources
of data
7/30/2019 Req Modeling
32/78
Process and Data Stores
A process is made up of
Data Stores
Process Number
Destination (Place
or Name)
Process description
Should be descriptive,
starting with a verb.
M1Can be M for manual or D
for computer base data
stores.
Name of Store
7/30/2019 Req Modeling
33/78
Outside Entity
Is anything outside the system that isof interest to the system. Can be a
person, a company or anothersystem.
Outside entity shows the Name
and a lowercase alpha character
is used to uniquely identify it.
If an outside entity isrepeated for the purpose of
neat layout a line is added
across the top.
Customer
a
Customer
a
7/30/2019 Req Modeling
34/78
DataFlow
Is shown by a line with an arrowhead,indicating the direction of the flow of
data. Each data flow should be
named to indicate what data is being
passed. Nouns or adjectives only no
verbs are permitted.
7/30/2019 Req Modeling
35/78
The Levels
Context - Overview - contains onlyone process
Level 1 - Utilises all four elements
Level 2 - A breakdown of a level 1process
Level 3 - A breakdown of a level 2
process There is no rule as to how many
levels of DFD that can be used.
7/30/2019 Req Modeling
36/78
RulesSequence not important - getting the Process correct is
Context or Level 0 - Identifies the system/boundary/External Links
Level 1 - Overview of function
Level 2 - Breakdown to UnderstandHard to know where to stop
Rule of Thumb
If there are more than 8 data flows break itProcess of Identifying major Processes
7/30/2019 Req Modeling
37/78
The Procedure for
Constructing DFDs
Draw a document flow diagramof the current situation
Draw a systems boundaryaround the agencies that are
part of the system Draw a Context Diagram
Identify processes in the system
Complete the level 1 Current
Physical DFD
7/30/2019 Req Modeling
38/78
The Document Flow Diagram
The task of modelling a businesssituation can be daunting at first. It is
best to start with something simplesuch as a document flow diagram.
Production
Planning
Stock Control
FactoryDesign
Purchasing
Supplier
Stock
NoteWithdrawal
Production
Plan PurchaseOrder
Delivery Note
Material Requirements List
Bill ofMaterials
Supplier Details Update Form
DeliveryNote
7/30/2019 Req Modeling
39/78
The Context Diagram
You decide which agencies are to bepart of the system that you areexamining.
These agencies fall inside the systemboundary and are reduced to one box inthe centre.
This is a Context Diagram
ProductionPlanning
Stock Control
Factory
Design Purchasing
Supplier
Stock
NoteWithdrawal
ProductionPlan
Delivery Note
Material Requirements List
Bil l of Materials
Supplier Details Update Form
DeliveryNote
MaintainStock System
a b
c
d
e
(Lejk & Deeks)
7/30/2019 Req Modeling
40/78
All data flows going into thesystem must be received by aprocess.
All data flows going out of thesystem must be generated byprocess.
The first task is therefore toidentify these processes:
Stock clerk
Maintain
1
2
3
Stock clerk
Stock clerk
planned call-off
Maintainstock cards
Preparematerial reqmnts
list
7/30/2019 Req Modeling
41/78
Draw the external entities and
data stores.
Production
Stock clerk
Maintain
aBill of materialsM1
1
2
3
Stock clerk
Stock cardsM2
Stock clerk
planned call-off
Maintainstock cards
Preparematerial reqmnts
list
Planning
Supplier
b
Factory
c
Purchasing
d
7/30/2019 Req Modeling
42/78
State Transition Diagrams
Dynamic Modelling
7/30/2019 Req Modeling
43/78
An objects state and behaviour can be
affected by:
Changes to attribute values
Results of operations
Changes of links with other objects
Internal events
External events
7/30/2019 Req Modeling
44/78
Three models
Object model:
Static structure of objects in a system and their
relationships.
Contains class diagrams.
dynamic model;
describes aspects that change over time: state transition
diagrams
functional model; Use Case diagrams
7/30/2019 Req Modeling
45/78
Dynamic modelling
Events
states
state diagrams
conditions
operations
7/30/2019 Req Modeling
46/78
Events
Something that happens at a point in time
Mouse button clicked / Signal changes
Logically ordered events - causally related
Concurrent events - causally unrelated do not effect each other
there is no order between them
1-way transmission of information from one object
to another
7/30/2019 Req Modeling
47/78
Event classes
Event occurrences are grouped into event classes
Flight 123 departs from Chicago / Flight 456 departs from
Rome
Event class is Flight Departs
Attributes of event classes
Departure origin of flight
Flight number
Data values are Attributes
7/30/2019 Req Modeling
48/78
Event Classes and Attributes
Aeroplane flight departs (airline, flight no,
city)
Mouse button pushed (button, location)
Input string entered (text)
phone receiver lifted
digit dialled (digit)
engine speed enters danger zone
7/30/2019 Req Modeling
49/78
States
A state is an abstraction of the attribute values and links of an
object. Sets of values are grouped together into a state
according to properties that affect the gross behaviour of the
object.
E.G.. A bank is solvent or insolvent depending on whether itsassets exceed its liabilities.
A state corresponds to the interval between 2 events received
by an object.
A state separates 2 events.
An event separates 2 states.
7/30/2019 Req Modeling
50/78
Characterisations of a state
State: Alarm ringing
Description: alarm on watch is ringing to indicate
target time
Event sequence that produces the state: set alarm (target time)
any sequence not including clear alarm
current time = target time
7/30/2019 Req Modeling
51/78
Condition that characterises the state:
alarm = on,
and
target time
7/30/2019 Req Modeling
52/78
Events accepted in the state:
event action next state
current time = target time + 20s reset alarm normal
button pushed (any button) reset alarm normal
7/30/2019 Req Modeling
53/78
State Diagrams
Relates to a specific object
Relate states and events
A change of state is called a transition
All transitions leaving a state must correspond todifferent events
The transition fires
An event that has no transition is ignored
A sequence of events corresponds to a path throughthe graph
7/30/2019 Req Modeling
54/78
State Transition DiagramIdle
Dial tone
do : Sound dial tonedo : Sound dial tone
Connecting
do : f ind connectiondo : f ind connection
ringing
do : ring belldo : ring bell
Connected
Disconnected
Busy tone
do : slow busy tonedo : slow busy tone
Fast busy tone
do : play fast busy tonedo : play fast busy tone
Time out
do : sound loud beepdo : sound loud beep
Recorded message
do : Play messagedo : Play message
Dialling
off-hook
routed
called phone answ ers/connect line
called phone hangs up/disconnect line
on-hook
time-out
digit (n)time-out
message done
digit (n)
valid numberinvalid number
trunk busy
on-hook/disconnect line
number busy
7/30/2019 Req Modeling
55/78
Initial/final States
The previous example is a continuous loop
Most situations will have an initial and final state
Chess game
White's turn
Black's turn
white wins
Black wins
Draw
Start
Whitemoves
Blackmoves
checkmate
stalemate
stalemate
Checkmate
7/30/2019 Req Modeling
56/78
Conditions
Used as guards on transitions.
A guarded transition only fires when the condition
is true e.g.
When you go out in the morning (event), If the temperature is below freezing (condition).
Put on your gloves (next state).
State Transition Diagram With
7/30/2019 Req Modeling
57/78
Traffic light
North/south may go straight
East/west may turn right
North/south may turn right
East/west may go straight
time-out[no carsin N/S right lanes]
time-out[no carsin E/W right lanes]
time-out
time-out[cars in N/S right lanes]
Time out[cars in E/W
right lanes]
Time-out
State Transition Diagram With
Conditions
7/30/2019 Req Modeling
58/78
Operations
Attached to state
Performed in response to the state
Attached to a transition
Performed in response to the event
7/30/2019 Req Modeling
59/78
Activities and Actions
An activity is an operation that takes time.
E.G.. Display a picture on a screen.
Do:a indicates that activity A occurs throughout the
lifetime of the state to which it is attached.
An action is an instantaneous operation.
E.G.. Disconnect phone line.
An action is shown on a transition as action / event.
e
ep
oneca
7/30/2019 Req Modeling
60/78
Idle
Dialtone
do:Sounddialtone
Connecting
do:findconnection
ringing
do:ringbell
Connected
Disconnected
Busytone
do:slowbusytone
Fastbusytone
do:fastbusytone
i
:l
d:l
Dialling
off-hook
routed
calledphoneans/connectline
calledphonehan/disconnectline
on-hook
tie-out
digit(n)
time-out
digit(n)
validnumber
invalidnuber
trunkbusy
on-hook/disconnectline
numberbusy
7/30/2019 Req Modeling
61/78
Constructing The Object Model
Diagram
The Object Model Diagram is a graphical
representation of the classes within a system and the
static or underlying relationships between them.
7/30/2019 Req Modeling
62/78
The Class Diagram
Class name
Attributes
methods
May be completed
during design
phase
Completed during
the design phase
7/30/2019 Req Modeling
63/78
Associations Between
Classes
Student
name
ID
major
GPA
credit_hr
Course
name
number
credits
prereqs
takes+
All Course objects participate
One or more Student in a Course
7/30/2019 Req Modeling
64/78
Cardinality Constraints
* Zero or more
+One or more
Zero or one
1..4
All objects of the class participate in the
association (total)
Explicit cardinality
7/30/2019 Req Modeling
65/78
Examples
Course
Student
Professor
takes
teaches
All Course objects have aprofessor and at least 1
student
+
1*
In any semester a professor
will teach zero or more
courses
0..
6
Students may take up to 6 courses
7/30/2019 Req Modeling
66/78
Professor Course
Student
takes
teaches
Examples
1
+
0..
6
and top to bottom
Associations read from left to right
7/30/2019 Req Modeling
67/78
Relationship Attributes
Employee
name
ss_num
salary
Company
name
works for
+
Bad salary as an attribute precludes the possibility
of an employee working for more than one company
works for
salary
+
Better model salary as a relationship attribute
7/30/2019 Req Modeling
68/78
Role
Relationships
Person
name
ss_num
address
child of
child
parent
Role
identifiers
2
*
Every person has 2 parents
and zero or more children
7/30/2019 Req Modeling
69/78
Ternary Relationships
Project Programmer
Language
assigned
+
1
*
Every project is
assigned a team of 1or more programmers
and written in 1
language
7/30/2019 Req Modeling
70/78
Aggregation
Colemans Notation
Aggregate Class Name
Component
1
Component
2
Component
3
* + 3
Multiplicity of each
component
Aggregation models the has-a
relationship
7/30/2019 Req Modeling
71/78
Aggregation
UML Notation
Aggregate Class
Component
1
Component
2
Component
3
*+
3
7/30/2019 Req Modeling
72/78
Example of Aggregation
Consider the Ternary Relationship Project-Programmer-Language
Project
Language
Programmer
uses*
assigned+
*
A project has-a language and
a team of one or more
programmers assigned to it
7/30/2019 Req Modeling
73/78
Q lifi ti
7/30/2019 Req Modeling
74/78
Qualification
Example
Directory File
contains
*
A directory contains zero or more files
Multiplicity can be removed by the qualifierfile name which
uniquely identifies a single file.
Q lifi ti
7/30/2019 Req Modeling
75/78
Qualification
Directory FileFilename
Multiplicity is removed by the qualifier
Generalization and
7/30/2019 Req Modeling
76/78
Generalization and
Specialization
Circle
areaperimeter
Rectangle
area
perimeter
Shape
area
perimeter
Classes having the same attributes may be generalized to a common
ancestor class
7/30/2019 Req Modeling
77/78
Generalization and Specialization
Vehicle
Land Vehicle Air VehicleWater Vehicle
A sea plane travels in the air and on water
7/30/2019 Req Modeling
78/78
Generalization and Specialization
An empty triangle indicates that someobjects belong to more than one of the
subclasses (subclasses overlap)
A filled triangle indicates that all objects
of the parent class belong to distinct
subclasses