Requirements Analysis with UML: Effective Use cases for RealTime Systems Development

1
Requirements Analysis with UMLEffective Use
cases for Real-Time Systems Development
2
Requirements Analysis
3
Requirements Analysis Activities

• Construct requirements models
• Functional Requirements
• Quality of Service Requirements
• Safety
• Reliability
• Performance
• Throughput
• Timeliness
• Capture use cases
• Determine actor participation

4
Requirements Analysis Artifacts
prototype
requirements spec
requirements defects
Requirements Analysis
hazard analysis
scenarios
use case model
5
A Use Case ...

• is a capability of a system
• why the user interacts with the system
• returns a result visible to one or more actors
• does not reveal or imply internal structure of
  the system
• is independent of other use cases and may be
  concurrent with them

ATM System
use case
Withdraw Money
Check Balance
customer
6
A Use Case is used to

• Capture requirements of a system
• Functional requirements
• What the system does
• Quality of service (QoS)
• How well the system does it
• speed
• throughput
• predictability
• capacity
• safety
• reliability

Functional requirements are modeled as use case,
message sequences, or statecharts
Qos Requirements are modeled as constraints
7
System Use Cases
Anesthesia Machine
Display Patient Status
Anesthesiologist
ECG Monitor
Ventilate Patient
Alarm on Critical Event
Deliver Anesthesia
Patient
Chart Recorder
8
System Use case scenario
Anesthesiologist
Chart Recorder
ECG Monitor
Anesthesia Machine
select monitored params
enable params
set lead pair
numeric params
numeric params
500 ms
enable recording
enable
numeric params
numeric params
numeric params
9
Example Cardionada

• Cardiac pacemaker can pace the heart in different
  operational modes, Off, AAI, VVI, AAT, VVT, and
  AVI
• (pace chambersense chamberaction on sense)
• Pacemaker can be commanded by the external
  programmer to
• Set pacing mode
• Set pacing parameters (rate, pulse width, pulse
  amplitude)
• Return pacemaker status

10
Example Cardionada QoS

• Pacing
• Pacing rate may be set in units of 1 ppm from
  30..120 inclusive. Accuracy of pacing shall be lt
  100 ms.
• Pulse width may be set in units of ms from 1..15.
  Accuracy of pulse width shall be within 0.25ms.
• Pulse amplitude may be set in units of mV from
  10..100. Accuracy shall be within 2 mV.
• Communications
• between the programmer and Cardionada shall be
  reliable with an MTBF of 0.01 in an electrically
  noisy environment.
• Single and dual bit errors shall be caught with
  an reliability of at least 0.0001. Errors
  detected by the pacemaker shall be reported to
  the programmer. The programmer shall not assume
  successful transmission without explicit
  acknowledgement.

11
Example Cardionada

• Who are the actors?
• Programmer
• Heart
• What are the visible behaviors?
• Set pacing mode
• Set parameters
• Get pacemaker status
• Pace the heart

12
Example Cardionada
13
Detailing Use Cases

• By example
• Use scenarios captured via sequence diagrams
• Each scenario capture a specific path through the
  use case
• Partially constructive
• Infinite set, so you must select which are
  interestingly different
• Non-technical users can understand scenarios
• By definition
• Use a statechart to represent all possible paths
• Fully constructive
• Non-technical readers may not understand it

14
Detailing Use Cases Scenarios

• A typical system has one dozen to a few dozen use
  case
• Each use case typically has a few to several
  dozen scenarios of interest
• Scenarios capture a specific actor-system
  interaction
• protocols of interaction
• permitted sequences of message flow
• collaboration of structural elements
• show typical or exceptional paths through the use
  case

Dont show system internal behavior or
structure on a sequence diagram
!
15
Detailing Use Cases Scenarios
16
Example CardionadaQoS on Sequence Diagram
17
Detailing Use Cases Statecharts

• Statecharts are fully constructive descriptions
  that represent all possible scenarios on a single
  diagram
• Useful for elaborate and complex protocols of
  actor-system interaction
• Represent actor system messages as
• triggering events (edge triggered)
• conditions (guards) (level-triggered)
• Represent system actor messages as actions

18
Detailing Use Cases Statecharts

• States represent conditions of existence of an
  object (e.g. the system) that persist for
  significant periods of time
• States are distinguishable in one or more of the
  following
• messages (events) accepted
• actions or activities performed
• reachability graph of subsequent states

19
Statecharts and Scenarios

• When a statechart is defined for a use case the
  scenario is a path through the statechart

uc
uc
a
b
s1
s1
s2
d
a
b
T
s2
c
c
s3
s4
s3
d
T
20
Use Cases Object Analysis and Design

• Use cases define requirements
• functional
• QoS
• Use case are detailed
• sequence diagrams
• text and text annotations
• statecharts
• Use cases are black box (i.e. do not reveal
  design or implementation)
• Use cases are realized by collaborations

A collaboration is a set of object roles working
together to achieve a higher-level function
21
Scenarios and the ROPES
Refined scenarios as test vectors
System-level use cases test vectors
Translation
Testing
Integration
Unit
Testing
Testing
Coding
Validation
Testing
Detailed
Iterative
Design
Prototypes
Refined scenarios
Party!
Mechanistic
Design
Requirements
Design
Analysis
Architectural
System-level use cases
Design
Systems Analysis
Object Analysis
Expanded use cases
Subsystem use cases
Refined scenarios
22
Systems Analysis with UMLRecursive Object
Decomposition with the UML
23
Systems Analysis
24
Systems Analysis Activities

• Elaborate requirements models
• Construct high-level architectural model
• Physical architecture
• Software/Hardware tradeoffs
• Logical architecture
• Software domain architecture
• Refine complex algorithms
• Construct executable specification

Not all systems have a significant
systems engineering effort.
25
Systems Analysis Artifacts
scenarios
use case model
interface specification
hazard analysis
Systems Analysis
logical architecture
test vectors
architectural defects
physical architecture
executable specification
26
Artifact Use Cases

• With a complex system use cases can be applied in
  a specialized way

Identify subsystem collaborations that realize
use cases
Identify use cases
Identify high level architecture
Done in requirements analysis
Decompose use cases with extends and
includes until the leaf use cases map to a
single subsystem
Object analysis for each subsystem identifies
objects collaborating to achieve leaf use cases
Detail leaf use cases
Done in object analysis
27
System Use Cases
Anesthesia Machine
Display Patient Status
Anesthesiologist
ECG Monitor
Ventilate Patient
Alarm on Critical Event
Deliver Anesthesia
Patient
Chart Recorder
28
System Use case scenario
Anesthesiologist
Chart Recorder
ECG Monitor
Anesthesia Machine
select monitored params
enable params
set lead pair
numeric params
numeric params
500 ms
enable recording
enable
numeric params
numeric params
numeric params
29
Drilling Down Subsystem Use Cases
Anesthesia Machine
User Interface
Chart Recorder
Anesthesiologist
SpO2 Monitor
subsystems
CO2 Monitor
Ventilator
Vaporizer
Patient
ECG Monitor
Breathing Circuit
30
Drilling Down UI Use Cases
User Interface
Display Patient Status
Chart Recorder
Anesthesiologist
Display Alarm
actor
SpO2 Monitor
ECG Monitor
Set Device Params
actor
Ventilator
Set Alarm Limits
actor
Set Ventilator
CO2 Monitor
actor
Vaporizer
Set Vaporizer
31
UI Subsystem Use Case Scenario
actor
Anesthesiologist
Ventilator
UI Subsystem
Set Tidal Volume(500)
enable
Set Ventilator
Set Tidal Volume(500)
Confirmed
Confirmed Tidal Volume(500)
Set Resp Rate(10)
Set Resp Rate(10)
Confirmed
Confirmed Resp Rate (10)
Set Minute Volume(8000)
Set Minute Volume(8000)
external actor
Rejected(incomp. settings)
Setting Error(Incomp. Setting)
internal actor
Set Minute Volume(5000)
Set Minute Volume(5000)
Confirmed
Confirmed Min Volume (5000)
32
Artifact Logical Architecture

• Includes
• class specifications
• class relations
• class organization

Domains are organized around subject matter and
vocabulary. Domains are not predefined in the
UML.
Closed Loop Control
User Interface
Alarm Management
Data Transport
Abstract HW
33
Domains

• Domains organize class specifications
• Use domain as a stereotype of package
• A domain is an independent subject matter.
• Domains are themselves organized into one-way
  dependencies in which more abstract domains
  depend upon the more concrete domains

34
Domains have Dependencies
more abstract
more concrete
35
Collaborations Span Domains
36
Object Analysis with the UMLA use-case based
approach for real-time systems
37
Object Analysis
38
Object Analysis Activities

• Object Structural Analysis
• Apply object identification strategies to
  identify essential classes and their relations
• If system analysis was performed
• Refine collaborations by adding lower-level
  objects
• Else
• Identify objects collaborating for each use case

39
Object Analysis Activities

• Object Behavioral Analysis
• Refine use case scenarios to include objects
• For objects with interesting behavior
• Simple Add activity diagram
• Reactive Add statechart
• Continuous Define continuous model
• Differential equations
• PID Control loop
• Neural Network
• Fuzzy state

40
Object Analysis Artifacts
hazard analysis
analysis patterns
analysis object model defects
Object Analysis
scenarios
Object Structural Analysis
Object Behavioral Analysis
interface specification
logical architecture
object structure
object behavior
physical architecture
analysis object model
41
Object Identification Approaches

• Approach 1 Identify classes for each
  collaboration using object identification
  strategies

For each use case
physical architecture defined
Identify use case
define collaboration of subsystems
apply object identification strategies
else
else
refine collaboration
refine scenarios
test collaboration
looks ok
T
42
Object Identification Approaches

• Approach 2 Identify classes in domains using
  object identification strategies
• useful when domains require highly specialized
  knowledge

For each domain
for all collaborations relevant to the domain
Identify domains
add objects into collaborations
apply object identification strategies
else
refine collaboration
refine scenarios
test collaboration
looks ok
T
43
Domain abstractions
44
Identify object relations
aggregation
A
B
sonOfA
attr 1 attr 2 attr 3
attr 1
association
Primary Radar
Composite
Part 1
sonOfA
generalization
Part 2
composition
45
Example Relations