Applying Use Cases to Microcontroller Code Development

Chris Gilbert Cypress Semiconductor

Agenda
Why Use Cases Microcontroller Project Development Use Cases Defined Use Cases Composition General Example Embedded Example Conclusion

Why Use Cases

Simple and extensible process Provide a methodical approach to requirements capture and definition Clarify system, subsystem, and component responsibilities Assist in decomposing the design Identify special conditions or error handling Form the spring board from requirements to verification Applicable to object-oriented and functional development
2

Embedded Software Development Lifecycle

Requirements
Statement of work Informal correspondence with the customer System description General and high level

Design is an informal process that maps the requirements to a framework Functional Implementation Verification

Embedded Software Code

Framework
Sequential flow Real-time operating system (RTOS) Interrupt driven State machine Master/slave

Functional Implementation

Small memory footprint Speed efficiency is often optimized due to relatively low speed devices Limited development tool capability C or assembly language

Use Case History

Background
Ivar Jacobson in 1985 Introduced in the Object-Oriented Software Engineering (OOSE) Process Primary element of the Unified Software Development Process Supported in Universal Model Language (UML)

Use Case Definition

Booch, Jacobson, Rumbaugh, The Unified

Software Development Process

Specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to an actor

What is a Use Case

Describes what the systems does A collection of operational scenarios that identify the role played by the system in response to stimulus, and the output produced by the system Provides a value for at least one stakeholder Initiated by external events that precipitate a system action Includes themodel contains all the use cases A Use Case action performed within the system required to completely describe the functionality

of a system
7

What a Use Case Isnt

Description of the internal structure of the system
Data structures Data base

Low level interface Single event or message Event or action internal to the system that is not externally observable or does not produce a result external to the system

Use Case Composition

Name
Summarizes the usage of the system it models Description of goal to be achieved Describe the sequence of interactions between the system and the actors that transpire from the input stimulus to the goal Object outside the system that interact with the system Assumptions, preconditions, and post conditions required for the use case to execute

Description or Sequence of Steps

Actors

Assumptions

Use Case Description

Brief description Relationships Basic flow
Describe the sequence of interactions between the system and the actors that transpire from the input stimulus to the goal May include state charts, sequence diagrams, etc. Relationship between the use case and actors or other use cases

Alternative flow Special requirements

QOS requirements Requirements not naturally included in the flow description

10

Actors
Definition
Represents what interacts with the system Any object outside the system under development that has a significant interaction with the system One or more per use case Not necessarily involved in all use cases Users, other systems, subsystems, hardware or software components, etc. Microcontroller peripherals such as A/D converter, serial interfaces, sensors Hardware components, LCD, push buttons, sensors
11

Characteristics Examples

Actor Example

Carbon Monoxide Monitor Device Microcontroller

Timers LED Display

CO Sensor

Carbon Monoxide Monitor System

Sounder

Test Button Nonvolatile Memory Calibration Jumper

12

Not Actors
Digital interface to the LED display
Display was defined as actor

A/D converter internal to microcontroller Microcontroller interrupt controller

13

Identifying Use Cases

List the primary capabilities of the system, then the actors, then identify specific scenarios within each use case. Identify the actors to the system and their interactions, then group those into use cases. Begin with a system scenario, identify the actors, and combine those into use cases.

14

Use Case Diagram

Carbon Monoxide Monitor System
Report CO Level LED Display Monitor CO Level Timers Issue Alarm
<<include>>
1

CO Sensor

Sounder

<<include>>

Calibration Jumper

Perform Unit Test Test Button

1

Calibrate Unit

Nonvolatile Memory
15

Use Case: Monitor CO Level

Brief Description Basic Flow
This use case is initiated periodically, measures the CO sensor level, and computes the CO PPM value. This use case is initiated every 30 seconds. The raw sensor voltage is measured. A PPM value is computed based on the measured value. The PPM value is averaged using a running average with the last 3 readings.

Requirements

The PPM value is limited to values between 0 to 999 inclusive.

16

Use Case: Perform Unit Test

Brief Description Basic Flow
Perform a self test of the unit and issue the alarm if an abnormal test is encountered. This use case is initiated when the test button is pressed. At a 2 second rate, the CO sensor is placed in test mode, and the sensor is measured by including the Monitor CO Level use case. Display the test CO level by including the Report CO Level use case. If the CO level is within the test alarm window, issue the CO alarm by including the Issue Alarm use case. If the CO level is outside the alarm threshold window, issue the trouble alarm by including the Issue Alarm use case. After 6 seconds of test, reset the unit if the CO alarm was issued.

17

Use Case: Perform Unit Test

Alternate Flow Requirements
If the calibration jumper is present, reset the unit without performing any unit tests. The test alarm window lower and upper bounds are 200 and 400 PPM, respectively.

18

Summary
Use cases Can be documented minimally, but effectively Suitable for customer review Capture functional requirements Drive the system architecture Provide definition for design Are a starting place for verification Assist in identifying unusual or unexpected aspects of the system
19

A complete use case model can be documented on index cards

Questions and Answers

20