Software modeling for embedded systems: static and dynamic behavior

Important concepts in embedded systems:

--concurrency: the system can handle multiple active independent or cooperating objects at the same time

--thread [of control]—models sequential execution of a set of instructions; embedded system may have several concurrent threads operating simultaneously

--persistence—how long does a software object last?

Examples:

Temporary variable

Global variable

Software module

table_05_00

Recall: “UML” syntax can vary among implementations;

Previously we looked at one implementation, here we consider examples from the text

fig_05_00

UML: Use case diagram (graphical)

fig_05_01

UML Use case diagram--example

fig_05_02

UML: Use case diagram (text); note exceptions

UML—static modeling

fig_05_03

UML: Class diagram (“CRC card”)

Class name

data

Methods (responsibilitiesandcollaborators)

(+ collaborators)

fig_05_04

UML: class relationships: inheritance

fig_05_05

UML: “interface”—similar to inheritance but different

public appearance

Hidden operation

fig_05_06

UML: containment of one class within another

Type 1: aggregation—statistical analysis has a number of algorithm “parts”

fig_05_07

UML: containment of one class within another

Type 2: composition—here the intervals are meaningless outside the schedule (~ “local variables”)

UML—dynamic modeling

fig_05_08

UML: interaction diagram—call and return

fig_05_09

UML: interaction diagram—create and destroy

fig_05_10

UML: interaction diagram—send (no response expected)

fig_05_11

UML: sequence diagram:sequence of actions; carries out a use case

fig_05_12

UML sequence diagram--example

fig_05_13

UML: concurrent behavior. Example: fork and join

fig_05_14

UML: concurrent behavior. Example: branch and merge

fig_05_15

UML activity diagram—captures all actions and control flows within a task

fig_05_16

UML state machine models--4 types of events:

UML state chart is a directed graph

fig_05_18

UML state chart: types of transitions

initial state

final state

fig_05_19

UML state chart: actions and guard conditionsIf guard condition is false, transition does not happen

fig_05_20

UML: can decompose state into sequential substates

fig_05_21

UML: can define a “history” state (e.g., for an interrupt)—system will probably eventually return to this state

fig_05_22

UML: can have concurrent substates

UML is a tool for a structured design methodology

It helps manage the design and development process

We can also look at modifying / refining the PROCESS itself

"hardware / software life cycle": easier specify requirements (cheaper) (levels:1. functional to fix 2. performance mistakes (time/space) 3. implementation 4. use 5. maintenance)

analyze requirements design implement harder to fix test mistakes maintain

CMM : capability maturity model--defines level of the development process itself

1. Initial: ad hoc

2. Repeatable: basic project management processes in place

3. Defined: documented process integrated into an organization-wide software process

4. Managed: detailed measures are collected

5. Optimizing--desired level: Continuous process improvement from quantitative feedback

UML is a tool for a structured design methodology

It helps manage the design and development process

We can also look at modifying / refining the PROCESS itself

"hardware / software life cycle": easier specify requirements (cheaper) (levels:1. functional to fix 2. performance mistakes (time/space) 3. implementation 4. use 5. maintenance)

analyze requirements design implement harder to fix test mistakes maintain

CMM : capability maturity model--defines level of the development process itself

1. Initial: ad hoc

2. Repeatable: basic project management processes in place

3. Defined: documented process integrated into an organization-wide software process

4. Managed: detailed measures are collected

5. Optimizing--desired level: Continuous process improvement from quantitative feedback

fig_05_23

Another methodology: control flow and data flow diagrams(Note: in a processor we usually have a data path and a control path)

fig_05_24

Control and data flow diagrams: tasks (with hierarchy levels)

fig_05_25

Control and data flow diagrams: Data sources and sinks

fig_05_26

Control and data flow diagrams: Data stores

fig_05_27

Control and data flow diagrams: Example

fig_05_28

Control and data flow diagrams: Hierarchical view of an input / output task