Transcript Requirement_Analysis_for_Embedded_System

Requirement Analysis for
Embedded System
Nien-Lin Hsueh
1
Outline

Topic 1: Requirements Analysis of Real-Time
Systems
Topic 2: Analysis: Object Domain Analysis
Topic 3: Analysis: Defining Object Behavior

Reference:


–
2
B.P. Douglass, Real Time UML- Advances in the UML for Realtime Systems (3rd), Addison Wesley, 2004
編輯說明（薛念林）



主要參考 Douglass 的書籍編輯
目前圖形是暫時劃上去的，將來會換成 Together 的圖
UML 語法說明部分不在此章說明，而是另外投影片介
紹
–


3
Douglass 對UML的說明是放在 chapter 2-3
每個 TOPIC 都有 exercise，以手機與機器人為主
圖片說明用『動畫』呈現，如果自有檔到請用『播放
模式』觀看
TOPIC 1: Requirements analysis of
real-time systems


Requirements
Use cases
–
–
–
–

Detailing the use cases
–
–
–
–

4
Actors
Use cases and text
Use case relations
Identifying use cases
Scenarios for use cases
Statechart diagrams
Activity diagrams
Timing diagrams
Exercise
Rapid Object-Oriented Process for
Embedded Systems (ROPES) Process
5
Here we are
6
1.1 Requirements



Specifications of what a system must do
independently of how the system is designed
Specified in UML profile for system
engineering
Requirement taxonomy
–
7
helps us understand the relation of requirements
to the system and its test, as well as understand
how requirements tend to be represented.
Requirement Taxonomy in UML
Three types of
requirements
.
2
0
8
1.2 Use Cases


A named capability of a structural entity in a model
Use case define a system-level capability without
revealing or implying any particular implementation
or design of that capability
–
–


Use case exist within a structural context, the context
consists of the system and actors
To be a use case
–
9
Functional view of the system
Are implemented by collaborations of classes
The capability must return a result visible to one or more
actors
Use case diagram
constraint
actor
Use case
boundary
Use case
relation
10
Conti.

Advantage:
–
–
11
To capture a broad view of the primary
functionality of the system in a manner easily
grasped by non-technical users
Become a centralized roadmap of the system
usage scenarios for people specifying the
requirements of the system
More about use cases

Use case are not themselves requirements
–


12
They organize requirements into chunks, based on the
organizational principle of common operational capability
They organize requirements into chunks, based on
the organizational principle of common operational
capability
This principle can be used regardless of the more
detailed representation of the requirements
themselves, whether it is text, sequence diagrams,
state machines, or activity diagrams
1.2.1 Actor


13
An actor is an object outside that scope of
the system under consideration that has
significant interactions with it
Mis-concept: an actor must be human users
of the system
Air Traffic Control System Use Cases
only Controller is a
human user
legacy systems
14
Decomposition of Deliver Anesthesia
Use Case
The system-level
use case is
decomposed into
12 included use
cases
legacy systems
15
1.2.2 Use case and text

Developers too familiar with the "Victorian novel" approach to
capturing requirements
–
–
–
–

16
the generation of hundreds or thousands of pages of text
specifying requirements
Using text alone to capture requirements is problematic because
text is difficult to make simultaneously precise, unambiguous, and
understandable
Textural requirements have different interpretations to arise
Textural requirements documents are often conflicting, having
requirements mismatched in different parts of large documents
It is possible to employ a use case approach and specify
requirements entirely in text
Use case and text (conti.)



17
UML provides more formal languages
(statecharts, activity diagrams, and sequence
diagrams) for capturing the details of
requirements
text is still useful in conjunction with these
more formal approaches
Different authors have defined different
contents and formats for such textual
characterizations
optional and need only
be entered if it is
otherwise impossible
to disambiguate the
use case in question
Characterization of Use Cases
provides a location for
a high-level statement
as to the user purpose
for the capability of
the use case
conditions that must
be true before the use
case begins
18
detailed textual
requirements may be
stated.
conditions that are
guaranteed to be true
by the system after
the use case is
finished
commonly used to
hold (QoS
requirements for the
use case)
1.2.3 Use case relations


The UML defines three distinct relationships
among use cases
Generalization
–
–
19
one use case is a more specialized or refined
version of another.
For example, the Validate User use case can be
specialized into Check Password, Check
Fingerprint Scan, and Check Retinal Scan use
cases.
Conti.

«include» is used when the capability
described in the client use case uses the
capability described in another use case.
–
–
20
only be used when the behavior is shared among
two or more use cases or
is mapping the "part" use case to a system
architectural component and is required for all of
the client use case scenarios
Conti.

«extend» is used when one use case
provides an optional additional capability
within a client use case.
–
21
This optional capability is inserted at a named
extension point.
1.2.3 Use Case Relations
Using <<extend>>:
the scheduled
downlink can
optionally
compress images,
either using lossy
or non-lossy
compression
algorithms.
Using
<<includes>>:
Common capability
is required for both
these use cases
22
Generalization
relation
Conti.

Spacecraft turns in order to achieve two capabilities in the
Spacecraft system:
–
–
–

23
taking a picture (under the premise that you must point at
something to take its picture) and
executing a scheduled downlink of information.
This common capability is required for both these use cases, it is
extracted out and put into its own use case. The two means by
which the spacecraft can be turned are specialized use cases of
the Adjust Attitude base use case.
In one case, rockets can be fired to turn the spacecraft, and in
the other, reaction wheels are activated. Finally, the scheduled
downlink can optionally compress images, either using lossy or
non-lossy compression algorithms. Because this is an option, it
is shown as an «extends» relation.
A caution in building use case diagram


24
Too often, beginners overuse the use case
relations and use them to capture the wrong
things.
Remember that you can model the
requirements of systems without using
generalization, «extends», or «includes».
1.2.4 Using Use Cases
25
Phase
Application of Use Cases
Analysis
Suggest
Design
Validate the elaboration of analysis models in the presence of design objects
Coding
Clarify
Testing
Provide primary and secondary test scenarios for system validation
Deployment
Suggest iterative prototypes for spiral development
large-scale partitioning of the domain
Provide structuring of analysis objects
Clarify system and object responsibilities
Capture and clarify new features as they are added during development
Validate analysis model
purpose and role of classes for coders
Focus coding efforts
1.2.5 Identifying Use Cases

Four primary approaches to identifying use cases:
–
–
–
–
26
List the primary capabilities of the system, then identify
the actors and scenarios within each use case.
Identify the actors to the system and the messages they
send or receive (the scenarios), and then group them into
use cases.
Start with system scenarios, identify the actors that
participate in them, and then lump them into use cases.
Identify a system workflow with an activity diagram at the
highest level and from there determine how these might be
mapped into use cases.
Conti.

The analyst can sit with the customer and ask probing
questions, such as these:
–
–
–

The analyst must then identify the following for each use case:
–
–
–
–
27
What are the primary functions of the system?
What are the secondary functions of the system?
Why is this system being built? What is it replacing and why?
The role the actors and system play in each scenario
The interactions (flows) necessary to complete the scenario
The sequence of events and data needed to realize the scenario
The variations on the scenario that are possible (other related
scenarios)
Use Cases in Development





28
Use cases are used primarily during requirements analysis
Once the system is broken down into its primary subsystems,
use cases may be applied to each of the subsystems in turn to
define its requirements with respect to the other elements of the
system
As the object model becomes fleshed out, the system- and
subsystem- level use cases may be refined in more detail,
replacing the system with the objects collaborating within the
system to realize the specific use case
The need for additional use cases having to do with the
concurrency and component models is normally uncovered
during architectural design as well
In testing, the use cases and their associated scenarios form
the key set of tests to be applied to the system.
29
Use Cases in Development
1.3 Detailing the Use Cases


A name alone isn't enough to understand
what a use case means
Use case “Set Ventilator Tidal Volume” is not
clear
–
30
Brief description: the user turns a knob and sets
the amount of mixed breathing gas pumped out
per breath for the ventilator
Conti.

Problems of the use case “Set Ventilator Tidal Volume”
–
–
–
–
–
–
–
–
31
What is the maximum value that can be selected? What is the minimum
value that can be selected?
What is the accuracy of the delivery of tidal volume with respect to its set
value? +/- 10 ml? +/- 5%?
Are there different ranges, such as one range for adults, another for
pediatrics, and another for neonates?
What happens if the knob is turned accidentally—does tidal volume change
directly or is an explicit confirmation required?
If there is a confirmation, can the user cancel the operation?
What happens if the user tries to set a different value, say respiration rate,
before confirmation?
How does the user know whether a value is currently being set (waiting for
confirmation)?
Does anything have to either precede or come after setting tidal volume,
such as setting patient age or weight?
Conti.

Two categories of approaches are possible.
–
A specification can be written for the requirements.

–

To provide examples of operational usage
Three kinds of requirements and their representation
–
–
–
32
This specification can be either informal (text) or formal using a
formal or semi-formal language such as statecharts or activity
diagrams.
Functional requirements are best captured in specifications.
Operational requirements are best captured in scenarios or
activity diagram workflows.
QoS requirements are added to both representations as
modifiers of the primary requirements.
1.3.1 Scenarios for Use Cases

A scenario is a particular actor-system interaction
corresponding to a use case
–
–

Each use case will have infinite set of scenarios
–
33
it is a specific example of a use case execution in the
system's operational environment
it models order-dependent message sequences among
object roles collaborating to produce system behavior in its
operational environment
but it is only necessary to capture the ones that are
interestingly different
Conti.


Use cases are realized by collaborations of objects
inside the system working together
In the earlier phase, internal object are skipped
–


34
if the use case diagram has two actors and the system, only
three objects can appear in the scenario
Later, once the system is opened up and is under
design, internal objects are identified
Building and analyzing scenarios is a creative
process of discovery
Conti.


Three primary scenario representations exist within the UML:
Sequence diagrams
–
–

Communication diagrams
–
–

–
35
are less popular and tend to stress the system object structure
Communication diagrams are not used until the object model of
the system stabilizes (and even then, many people prefer
sequence diagrams anyway).
Timing diagrams
–

emphasize messages and their sequence
In use case analysis, sequence diagrams are preferred over
communication diagrams.
are best applied when the requirements are highly time-sensitive
less applied, but are useful when timing is crucial.
We will primarily focus on sequence diagrams in this chapter
1.3.1.1 Sequence Diagrams for
Requirements Capture

36
Even after adopting the UML, many
organizations continue using text as an
adjunct to scenarios and statecharts to
capture requirements in a more formal way.
Relating Text and Scenarios
37
Internal «trace»
stereotyped
dependency relations
can provide
traceability inside the
model.
descriptive note
names the sequence
diagram, a brief
description, and the
preconditions and
postconditions of the
secnario
38
An example sequence diagram from the anesthesia machine
Conti.


39
A measure of goodness of the architecture or
object model is that the design can realize
the operational scenarios defined at the
system level
If it can realize all of the scenarios defined at
the system level, then the architecture or
object model is good
Deliver Anesthesia Collaboration


40
Shows three
subsystems working
together to realize the
Deliver Anesthesia use
case
A very relevant question
to ask of this
collaboration is "Is this
good?" That is the same
as asking, "Does this
collaboration meet its
requirements?"
1.3.1.2 Capturing QoS Requirements
on Sequence Diagrams


The single most differentiating characteristic of realtime systems is their concern and treatment of time
However, most timing requirements are derived
rather than primary requirements
–

41
Because these requirements are derived, it is all too
common for them to be missed by systems designers,
leading to unstable system performance.
It is vital that these time constraints be captured as
part of the system model so that they can be treated
appropriately
Conti.

A number of time values can be captured.
–
Time values that are QoS requirements

–
Time values that are estimates, used for the
purpose of analysis, can be captured as tagged
values

42
can be captured as constraints applied against the
actions or messages.
Tagged values are shown as { property = value} pairs in
constraints.
1.3.2 Statecharts


Statecharts are a formal behavioral language that
lends itself to the specification of use case behavior
The use case formal language has a number of
advantages over text:
–
–
–

43
It is verifiable, through mathematical analysis or execution.
It is precise, and not nearly as likely to be misinterpreted.
It is generative, meaning that creation of an executable
requirements model is possible
The semantics and syntax of statecharts was
described in UML introduction
Even the requirements are
relatively small, but they are
still nonetheless nontrivial to
understand.
44
Alarm On Critical Event Requirements
Alarm On Critical Event Statechart
It is more easier to
understand
45
Statechart and text
Statecharts can be related to the
text in a straightforward fashion
46
Statecharts and Sequence Diagrams

State

47
Statecharts can be
related to scenarios
as well
Different
operational
scenarios take
different paths
through the
statechart
1.3.3 Activity Diagrams


48
In UML 1.x, activity diagrams are isomorphic
with statecharts.
In UML 2.0 they are a superset, since their
semantic basis is now token flow semantics,
which represent Turing machines
Conti.




49
The most common use of activity diagrams in the development
of real-time and embedded systems will still most likely be in
their use as concurrent flowcharts
Activity diagrams are most commonly used when a behavior
can be specified as a set of control flows with operators
(sequence, alternative, loop, fork, and join)
Activity diagrams are most commonly used to represent
algorithms that, once initiated, proceed inexorably to their
conclusion
Statecharts can represent algorithms as well by using nulltriggered (anonymous) events connecting states although their
most common use is with explicit triggering events.
Display Waveform Activity Diagram
50
1.3.4 Timing Diagrams

Similar in some ways to sequence diagrams, timing diagrams
also represent scenarios
–
–
–

Timing diagrams focus on the qualities of service having to do
with time, such as
–
–
–
–
–
51
Timing diagram: emphasize change in value or state over time
Sequence diagram: emphasize sequences of message exchange
isomorphic and able to represent the same information, but their
purpose is different
execution time
jitter
deadlines
periodicity
how they affect the state of the system
Use Case Timing Diagram
52
Exercise 1.1

53
For your mobile phone application, following
the guideline of chapter to build the analysis
model and documentation
Exercise 1.2

54
For your robot application, following the
guideline of chapter to build the analysis
model and documentation
TOPIC 2: Analysis: Object Domain
Analysis
55







The object discovery process
Connecting the object model with the use case model
Key strategies for object identification
Identify object association
Object attributes
Discovering candidate classes
Class diagram
–
–

56
Associative classes
Generalization relationships
Exercise
TOPIC 3: Analysis: Defining Object
Behavior

Object behavior
–
–
–

Defining object state behavior
–
–
–

–
57
Sequence diagrams
Defining operations
–

Cardiac pacemaker example
Calculator example
Event hierarchies
Interactions
–

Simple behavior
State behavior
Continuous behavior
Type of operations
Strategies for defining operations
Exercise
Requirements

58
//describe the importance of requirement
elicitation, analysis and validation
Use cases





59
//introduce the following topics
Actors
Use case and text
Use case relations
Using use cases
Detailing the use cases





60
//introduce the following topics
Scenarios for use cases
Statecharts
Activity diagrams
Time diagrams (This is special for real time
systems)
61