Applying Use Cases to Microcontroller Code Development. Chris Gilbert Cypress Semiconductor

Transcription

1 Applying Use Cases to Microcontroller Code Development Chris Gilbert Cypress Semiconductor

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

3 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 oriented and functional development 2

4 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 3

5 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 4

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

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

8 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 the action performed within the system A Use Case model contains all the use cases required to completely describe the functionality of a system 7

9 What a Use Case Isn t 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 8

10 Use Case Composition Name Summarizes the usage of the system it models Description or Sequence of Steps 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 Actors Object outside the system that interact with the system Assumptions Assumptions, preconditions, and post conditions required for the use case to execute 9

11 Use Case Description Brief description Relationships Relationship between the use case and actors or other use cases 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. Alternative flow Special requirements QOS requirements Requirements not naturally included in the flow description 10

12 Actors Definition Represents what interacts with the system Any object outside the system under development that has a significant interaction with the system Characteristics One or more per use case Not necessarily involved in all use cases Examples 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

13 Actor Example Carbon Monoxide Monitor Device Microcontroller LED Display Timers Carbon Monoxide Monitor System CO Sensor Sounder Test Button Nonvolatile Memory Calibration Jumper 12

14 Not Actors Digital interface to the LED display Display was defined as actor A/D converter internal to microcontroller Microcontroller interrupt controller 13

15 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

16 Use Case Diagram Carbon Monoxide Monitor System Report CO Level 1 CO Sensor LED Display Monitor CO Level Sounder Timers Test Button <<include>> 1 Perform Unit Test Issue Alarm <<include>> Calibrate Unit Calibration Jumper Nonvolatile Memory 15

17 Use Case: Monitor CO Level Brief Description This use case is initiated periodically, measures the CO sensor level, and computes the CO PPM value. Basic Flow 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

18 Use Case: Perform Unit Test Brief Description Perform a self test of the unit and issue the alarm if an abnormal test is encountered. Basic Flow 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

19 Use Case: Perform Unit Test Alternate Flow If the calibration jumper is present, reset the unit without performing any unit tests. Requirements The test alarm window lower and upper bounds are 200 and 400 PPM, respectively. 18

20 Summary Use cases Can be documented minimally, but effectively A complete use case model can be documented on index cards 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

21 Questions and Answers 20