1

Requirement Analysis for Embedded System

Nien-Lin Hsueh

2

Outline

Topic 1: Requirements Analysis of Real-Time Systems

Topic 2: Analysis: Object Domain Analysis Topic 3: Analysis: Defining Object Behavior

Reference: – B.P. Douglass,

Real Time UML- Advances in the UML for Real-time Systems (3rd)

, Addison Wesley, 2004

3

編輯說明（薛念林）

主要參考 Douglass 的書籍編輯 目前圖形是暫時劃上去的，將來會換成 Together 的

圖 UML 語法說明部分不在此章說明，而是另外投影片

介紹– Douglass 對 UML 的說明是放在 chapter 2-3

每個 TOPIC 都有 exercise ，以手機與機器人為主 圖片說明用『動畫』呈現，如果自有檔到請用『播放

模式』觀看

4

TOPIC 1: Requirements analysis of real-time systems

Requirements Use cases

– Actors– Use cases and text– Use case relations– Identifying use cases

Detailing the use cases– Scenarios for use cases– Statechart diagrams– Activity diagrams– Timing diagrams

Exercise

5

Rapid Object-Oriented Process for Embedded Systems (ROPES) Process

6

Here we are

7

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– helps us understand the relation of requirements

to the system and its test, as well as understand how requirements tend to be represented.

8

Re

qu

irem

ent T

axo

no

my

in U

ML

2.0

Three types of requirements

9

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

– Functional view of the system– Are implemented by collaborations of classes

Use case exist within a structural context, the context consists of the system and actors

To be a use case– The capability must return a result visible to one or more

actors

10

Use case diagram

Use caseactor

constraint

boundary

Use case relation

11

Conti.

Advantage:– To capture a broad view of the primary functionalit

y 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

12

More about use cases

Use case are not themselves requirements– 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

13

1.2.1 Actor

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

14

Air Traffic Control System Use Cases

only Controller is a human user

legacy systems

15

Decomposition of Deliver Anesthesia Use Case

legacy systems

The system-level use case is decomposed into 12 included use cases

16

1.2.2 Use case and text

Developers too familiar with the "Victorian novel" approach to capturing requirements

– 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

17

Use case and text (conti.)

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

18

Characterization of Use Cases

optional and need only be entered if it is otherwise impossible to disambiguate the use

case in question

provides a location for a high-level statement as to the user purpose for the capability of t

he use case

detailed textual requirements may be state

d.

conditions that must be true before the use

case begins

conditions that are guaranteed to be true by the system after the u

se case is finished

commonly used to hold (QoS requirements

for the use case)

19

1.2.3 Use case relations

The UML defines three distinct relationships among use cases

Generalization– 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.

20

Conti.

«include» is used when the capability described in the client use case uses the capability described in another use case. – 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

21

Conti.

«extend» is used when one use case provides an optional additional capability within a client use case. – This optional capability is inserted at a named

extension point.

22

1.2.3 Use Case Relations

Using <<includes>>: Common capability is required for both these use case

s

Generalization relation

Using <<extend>>: the scheduled downlink can optionally compress images, either using lossy or non-lossy compression algorithms.

23

Conti.

Spacecraft turns in order to achieve two capabilities in the Spacecraft system:

– 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 e

xtracted 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.

24

A caution in building use case diagram

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».

25

1.2.4 Using Use Cases

Phase Application of Use Cases

Analysis Suggest large-scale partitioning of the domainProvide structuring of analysis objectsClarify system and object responsibilitiesCapture and clarify new features as they are added during developmentValidate analysis model

Design Validate the elaboration of analysis models in the presence of design objects

Coding Clarify purpose and role of classes for codersFocus coding efforts

Testing Provide primary and secondary test scenarios for system validation

Deployment Suggest iterative prototypes for spiral development

26

1.2.5 Identifying Use Cases

Four primary approaches to identifying use cases:– 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.

27

Conti.

The analyst can sit with the customer and ask probing questions, such as these:

– 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 analyst must then identify the following for each use case:– 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 sce

narios)

28

Use Cases in Development

Use cases are used primarily during requirements analysis Once the system is broken down into its primary subsystems, u

se 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

30

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– Brief description: the user turns a knob and sets

the amount of mixed breathing gas pumped out per breath for the ventilator

31

Conti.

Problems of the use case “Set Ventilator Tidal Volume”– What is the maximum value that can be selected? What is the minimum val

ue that can be selected?– What is the accuracy of the delivery of tidal volume with respect to its set v

alue? +/- 10 ml? +/- 5%?– Are there different ranges, such as one range for adults, another for pediatr

ics, 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, su

ch as setting patient age or weight?

32

Conti.

Two categories of approaches are possible. – A specification can be written for the requirements.

This specification can be either informal (text) or formal using a formal or semi-formal language such as statecharts or activity diagrams.

– To provide examples of operational usage Three kinds of requirements and their representation

– 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 mo

difiers of the primary requirements.

33

1.3.1 Scenarios for Use Cases

A scenario is a particular actor-system interaction corresponding to a use case

– 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

Each use case will have infinite set of scenarios– but it is only necessary to capture the ones that are

interestingly different

34

Conti.

Use cases are realized by collaborations of objects inside the system working together

In the earlier phase, internal object are skipped– 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

35

Conti.

Three primary scenario representations exist within the UML: Sequence diagrams

– emphasize messages and their sequence– In use case analysis, sequence diagrams are preferred over

communication diagrams. Communication diagrams

– 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– 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

36

1.3.1.1 Sequence Diagrams for Requirements Capture

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.

37

Relating Text and Scenarios Internal «trace» stereotyped dependency relations can provide traceability inside the

model.

38 An example sequence diagram from the anesthesia machine

descriptive note names the sequence diagram, a brief description, and the preconditions and postconditions of t

he secnario

39

Conti.

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

40

Deliver Anesthesia Collaboration

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?"

41

1.3.1.2 Capturing QoS Requirements on Sequence Diagrams

The single most differentiating characteristic of real-time systems is their concern and treatment of time

However, most timing requirements are derived rather than primary requirements

– 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

42

Conti.

A number of time values can be captured.– Time values that are QoS requirements

can be captured as constraints applied against the actions or messages.

– Time values that are estimates, used for the purpose of analysis, can be captured as tagged values

Tagged values are shown as { property = value} pairs in constraints.

43

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:

– 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 req

uirements model is possible The semantics and syntax of statecharts was describ

ed in UML introduction

44 Alarm On Critical Event Requirements

Even the requirements are relatively small, but they are still nonetheless nontrivial

to understand.

45

Alarm On Critical Event Statechart

It is more easier to understand

46

Statechart and text

Statecharts can be related to the text in a straightforward fashio

n

47

Statecharts and Sequence Diagrams

Statecharts can be related to scenarios as well

Different operational scenarios take different paths through the statechart

State

48

1.3.3 Activity Diagrams

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

49

Conti.

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 null-triggered (anonymous) events connecting states although their most common use is with explicit triggering events.

50

Display Waveform Activity Diagram

51

1.3.4 Timing Diagrams

Similar in some ways to sequence diagrams, timing diagrams also represent scenarios

– 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 p

urpose is different Timing diagrams focus on the qualities of service having to do

with time, such as – execution time – jitter – deadlines – periodicity – how they affect the state of the system

52

Use Case Timing Diagram

53

Exercise 1.1

For your mobile phone application, following the guideline of chapter to build the analysis model and documentation

54

Exercise 1.2

For your robot application, following the guideline of chapter to build the analysis model and documentation

55

TOPIC 2: Analysis: Object Domain Analysis

56

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

– Associative classes– Generalization relationships

Exercise

57

Object behavior– Simple behavior– State behavior– Continuous behavior

Defining object state behavior– Cardiac pacemaker example– Calculator example– Event hierarchies

Interactions– Sequence diagrams

Defining operations– Type of operations– Strategies for defining operations

Exercise

TOPIC 3: Analysis: Defining Object Behavior

58

Requirements

//describe the importance of requirement elicitation, analysis and validation

59

Use cases

//introduce the following topics Actors Use case and text Use case relations Using use cases

60

Detailing the use cases

//introduce the following topics Scenarios for use cases Statecharts Activity diagrams Time diagrams (This is special for real time

systems)

61