1

Embedded Systems Software: Modeling and Programming--The Object-oriented Paradigm

andThe Unified Modeling Language (UML)

2

"problems" of software development (review):

**conceptual integrity

**incremental build, progressive refinement

**large projects "differ" from small ones

programming paradigms (1950’s-present): attempts to deal effectively with these problems, make software easier to develop and to maintain

Problems of software development

3

1950's:unstructured, no information hiding--”spaghetti” code, GOTO, flowcharts--machine code--assembly lang. --FORTRAN, LISP (Algol; COBOL)

1970s,1980s: structured, top-down design (“3 basic control structures, no GOTO”), modularity--Pascal, C, PL/I, Ada

1990’s: encapsulation, information-hiding, reuse, hardware/software codesign (from simulation languages developed much earlier, e.g., Modula, simula)--C++, Java

2000’s: info hiding; web languages; environments encapsulating multiple languages, styles--.NET, C#, Python, Perl, MATLAB, Mathematica, Labview, …

A Brief History: Computer Hardware, Computer Languages, Design Techniques

Early machines—large, central (Eniac)

Supercomputers, “Minicomputers”, PCs, multiuser machines, PICs

Beowulf clusters, Spread of the Internet

“Ubiquitous computing”, laptops,.Personal communication devices, multicore processors, GPUs

wpclipart.com

chilton-computing.org.uk

techxav.com

http://en.wikipedia.org/wiki/PIC_microcontroller#History

cse.mtu.edu

visual.merriam-webster.com

http://t0.gstatic.com/images?q=tbn:ANd9GcS3J9yAV0YibC4keB8M_6hc0xh3sZYbbGKZUK-pHLzx7Lkek74w

http://www.amd.com/us-en/assets/content_type/Additional/43494A_QuadCore_Opt_Die_BLK_HRes.jpg textually.org

4

Important basic OO concepts:

class: encapsulates data structure (object) and associated methods (functions) these may be declared public / private / protected

appropriate uses:

public: pass info to object or request info about object(use "messages") (can be used by anyone)

private: modify object (can be used in class or by “friends”)

protected: for descendants (in class or by derived class and “friends”)

OO class

5

traditional: record (struct): functions to use or modify this record can be anywhere in the program

OO: class concept supports encapsulation, information hiding

Record/class

DATA

DATA

DATA

DATA

DATA

DATA

DATA

Procedural Prog.

OO Prog.

6

Useful OO techniques:

Inheritance:ex: in a program modeling an ecosystem, we might have the relationships:

wolf is carnivore; sheep is herbivore; grass is plant carnivore is animal; herbivore is animalanimal is organism; plant is organism

here the base class “organism” holds data fields which apply to all organisms, e.g., amount of water needed to survive two derived classes, plant and animal, hold information specific to each of these types of organisms, e.g., kind of soil preferred by plantthe animal class also has two derived classes, wolf and sheep

Inheritance allows the collection of common attributes and methods in "base" class and inclusion of more specific attributes and methods in derived classes

Inheritance

A. B.Ex: Object data

structures:

A. Base class

B. Derived class

X

Y

Z

X

Y

Z

W

7

Polymorphism:

base class can define a “virtual” function; appropriate versions of this function can be instantiated in each derived class (e.g., "draw" in the base class of graphical objects can have its own specific meaning for rectangles, lines, ellipses)

Overloading:

ex: cin >> num1;>> is overloaded "shift”

ex: “+” can be overloaded to allow the addition of two vectors

ex: a function name can be overloaded to apply to more than one situation; e.g., a constructor can be defined one way if initial values are given and a different way if initial values are not given

Polymorphism and overloading

8

Templates:

example:

template <class T> T method1 (T x) …..

can be specialized: int method1 (int x)

float method1 (float y)

usertype method1 (usertype a)

templates promote reuse

Templates

9

Separate compilation:

Typically, an object-oriented program can be broken into three sets of components:

definitions and prototypes (text files, “header files”)

implementations (compiled--source code need not be available to user)

application program--uses the classes defined in header files and supported by the implementation files

This strategy promotes reuse and information hiding

Separate compilation

10

Note: no paradigm is misuse-proof

Misuse of object-oriented paradigm

11

Design: “top-down”; Test: “bottom-up” : “Design for testability”

determine specifications: use cases system tests

determine classes and connections (static behavior): ER or class diagrams; CRC cards module (“black box”) tests

model dynamic behavior:interaction (object message) diagrams activity diagramsstate diagramssequence diagrams

[ individual class functions “white box” or “glass box” tests]

Using OO & (a subset of) UML in a project: design; design for testability

dynamic module interactions / “boundary” behavior

12

UML: a language for specifying and designing an OO project

UML: stands for "unified modeling language”

unifies methods of Booch, Rumbaugh (OMT or Object Modeling Technique), and Jacobson (OOSE or Object-Oriented Software Engineering)

mainly a modeling language, not a complete development method

Early versions -- second half of the 90's

Not all methods we will use are officially part of the UML description

13

USE CASES: a part of the ”Unified Modeling Language" (UML) which we will use for requirements analysis and specification

each identifies a way the system will be used and the "actors" (people or devices) that will use it (an interaction between the user and the system)

each use case should capture some user-visible function and achieve some discrete goal for the user

an actual user can have many actor roles in these use cases

an instance of a use case is usually called a "scenario”

Use case will typically have graphical & verbal forms

Use cases

14

Example: cellular network place and receive calls use case (based on Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide)

Place call

Receive call

Use scheduler

Receive additional

call

Place conference

call

Cellular network

User

Use Case (Example) Key: Use Case Actor “Extends” “Uses”

Validate user

Example use case

System boundary

Text description

--Use case name (cellular network place and receive calls)

--Participating actors (cellular network and human user)

--Flow of events (network or user accesses network to use its functionality)

--Entry condition(s) (user accesses network using device or password) --Exit condition(s) (call completed lost or network busy)

--Quality requirements (speed, service quality)

Text description—gives important details

Use case diagram—summarizes, provides system overview

15

use case

Text description:

Use case name

Participating actors

Flow of events

Entry condition(s)

Exit condition(s)

Quality requirements

16

Use case—detailed example (Pressman)

Example: “SAFEHOME” system (Pressman)

Use case: InitiateMonitoring

(Pressman text categories:•Primary actor (1)

•Goal in context (2)

•Preconditions (3)

•Trigger (4)

•Scenario (5)

•Exceptions (6)

•Priority (system development) (7)

•When available (8)

•Frequency of use (9)

•Channel to actor (10)

•Secondary actors (11)

•Channels to secondary actors (12)

•Open issues (13) )

Arms/disarms system

Accesses system via internet

Responds to alarm event

Encounters an error condition

Reconfigures sensors

and related system features

Homeowner

System administrator

Sensors

Pressman, p. 163, Figure 7.3

17

Use case—detailed example (Pressman)

Example: “SAFEHOME” system (Pressman)

Use case name: InitiateMonitoring

Participating actors: homeowner, technicians, sensors

Flow of events (homeowner):--Homeowner wants to set the system when the homeowner leaves house or remains in house--Homeowner observes control panel--Homeowner enters password--Homeowner selects “stay” or “away”--Homeowner observes that read alarm light has come on, indicating the system is armed

18

Use detailed example (Pressman)--continued

Entry condition(s)

Homeowner decides to set control panel

Exit condition(s)

Control panel is not ready; homeowner must check all sensors and reset them if necessary

Control panel indicates incorrect password (one beep)—homeowner enters correct password

Password not recognized—must contact monitoring and response subsystem to reprogram password

Stay selected: control panel beeps twice and lights stay light; perimeter sensors are activated

Away selected: control panel beeps three times and lights away light; all sensors are activated

19

Use case—detailed example (Pressman)

Quality requirements:

Control panel may display additional text messages

time the homeowner has to enter the password from the time the first key is pressed

Ability to activate the system without the use of a password or with an abbreviated password

Ability to deactivate the system before it actually activates

20

Use case additions—simplifications of use case descriptions

A. Include: one use case includes another in its flow of events (cases A and B both include case C)

B. Extend: extend one use case to include additional behavior (cases D and E are extensions of case F)

A

B

C<<include>>

<<include>>

FE

D

<<extend>>

<<extend>>

21

Use case additions

C. Inheritance: one use case specializes the more general behavior of another G and H specialize behavior of J)

H

J

authenticate

Authenticate with card

Authenticate with password

G

22

Use case continued

Examples: what would be a use case for: vending machine traffic light

Use case nameParticipating actorsFlow of eventsEntry conditionExit conditionQuality requirements

23

Note:

Use cases can form a basis for system acceptance tests

For each use case:• Develop one or more system tests to confirm that the use case requirements will be satisfied• Add explicit test values as soon as possible during design phase• These tests are now specifically tied to the use case and will be used as the top level acceptance tests

Do not forget use cases / tests for performance and usability requirements (these may be qualitative as well as quantitative)

System Tests

24

Analysis model (UML version):

--functional model (use cases and scenarios)

--analysis object model (static: class and object diagrams)

--dynamic model (state and sequence diagrams)

As system is analyzed, specifications are refined and made more explicit; if necessary, requirements are also updated

25

Example: an activity diagram for analyzing a system you are building:

26

Arms/disarms system

Accesses system via internet

Responds to alarm event

Encounters an error condition

Reconfigures sensors

and related system features

Homeowner

System administrator

Sensors

Pressman, p. 163, Figure 7.3

“Review”: use case: Graphical description:

Text description: Use case name

Participating actors

Flow of events

Entry condition(s)

Exit condition(s)

Quality requirements

27

“Review”: Use case writing guide:

--each use case should be traceable to requirements

--name should be a verb phrase to indicate user goal

--actor names should be noun phrases

--system boundary needs to be clearly defined

--use active voice in describing flow of events, to make clear who does what

--make sure the flow of events describes a complete user transaction

---if there is a dependence among steps, this needs to be made clear

--describe exceptions separately

--DO NOT describe the user interface to the system, only functions

--DO NOT make the use case too long—use extends, includes instead

--as you develop use cases, develop associated tests

28

Class and object diagrams:Identify Objects from Use Case Specifications:USE ENDUSER’s TERMS AS MUCH AS POSSIBLE

Entity objects: “things”, for example:--nouns (customer, hospital, infection)--real-world entities (resource, dispatcher)--real-world activities to be tracked (evacuation_plan)--data sources or sinks (printer)

Boundary objects: system interfaces, for example:--controls (report(emergencybutton)--forms (savings_deposit_form)--messages (notify_of_error)

Control objects: usually one per use case--coordinate boundary and entity objects in the use case

Use the identified objects in a sequence diagram to carry out the use case

29

Common classes

Other common types of classes which the developer can look for include:

•tangible things, e.g., Mailbox, Document

•system interfaces and devices, e.g., DisplayWindow, Input Reader

•agents, e.g., Paginator, which computes document page breaks, or InputReader

•events and transactions, e.g., MouseEvent,CustomerArrival

•users and roles, e.g., Administrator, User

•systems, e.g., mailsystem (overall), InitializationSystem (initializes)

•containers, e.g., Mailbox, Invoice, Event

•foundation classes, e.g., String, Date, Vector, etc.

30

Sequence Diagram

Sequence Diagram:

a sequence diagram also models dynamic behavior

typically a sequence diagram shows how objects act together to implement a single use case

messages passed between the objects are also shown

sequence diagrams help to show the overall flow of control in the part of the program being modeled

they can also be used to show:concurrent processesasynchronous behavior

31

Sequence Diagram--Syntax

Objects in the sequence diagram are shown as boxes at the top

below each object is a dashed vertical line--the object’s “lifeline”

an arrow between two lifelines represents each message

arrows are labeled with message names and can also include information on arguments and control information

two types of control:condition, e.g., [is greaterthan zero]iteration, e.g., *[for all array items]

“return” arrows can also be included

32

Sequence Diagram Example

33

ER diagrams

Useful object relationships

These diagrams represent the relationships between the classes in the system. These represent a static view of the system.

There are three basic types of relationship:

•inheritance ("is-a")

•aggregation ("has-a”)

•association ("uses")

These are commonly diagrammed as follows:

34

ER diagram: is-a

is-a: draw an arrow from the derived to the base class:

manager employee

35

ER diagram--has-a

has-a: draw a line with a diamond on the end at the "container" class. Cardinalities may also be shown (1:1, 1:n, 1:0…m; 1:*, i.e., any number > 0, 1:1…*, i.e., any number > 1):

car tire1 4tire & car can exist independently—shared aggregation

person arm1 2arm is part of the person– composition aggregation

36

ER diagram--uses

uses or association: there are many ways to represent this relationship, e.g.,

car gasstationcompany

employee

employs

works for

*

1

*

n

1

*

37

CRC cards

CRC cards: class--responsibilities--collaborators cards

"responsibilities" = operators, methods

"collaborators" = related classes (for a particular operator or method)

Make one actual card for each discovered class, with responsibilities and collaborators on the front, data fields on the back. CRC cards are not really part of UML, but are often used in conjunction with it.

38

CRC card--example

Example (based on Horstmann, Practical Object-Oriented Development in C++ and Java):

front back

Class Mailbox

Operations Relationships(Responsibilities) (Collaborators)

get current message Message, Messagequeue

play greeting -----------

Queue of new messagesQueue of kept messagesGreetingExtension numberPasscode

Class Mailbox

39

State Diagram

State Diagram:

another way of adding detail to the design--models dynamic behavior

describes all the possible states a particular object can be in and how that object's state changes as a result of events that affect that object

usually drawn for a single class to show behavior of a single object

used to clarify dynamic behavior within the system, as needed

40

State Diagram--Properties

A state diagram contains a "start" point, states, and transitions from one state to another.

Each state is labeled by its name and by the activities which occur when in that state.

Transitions can have three optional labels: Event [Guard] / Action.

A transition is triggered by an Event.

If there is no Event, then the transition is triggered as soon as the state activities are completed.

A Guard can be true or false. If the Guard is false, the transition is not taken.

An Action is completed during the transition.

41

State Diagram--Example

Example: this state diagram example for an "order" in an order-processing system is from Fowler and Scott, UML Distilled (Addison-Wesley, 1997):

Checking

check item

Dispatching

initiate delivery

Waiting Delivered

start/get first item

[not all items checked]/get next item

[all items checked && all items available]

[all items checked && some items not instock]

item received[some items not in stock]

item received[all items in stock]

delivered

42

Example—bank simulation (Horstmann)

Teller 1

Teller 2

Teller 3

Teller 4

Customer 1Customer 3 Customer 2

Horstmann, Mastering Object-Oriented Design in C++, Wiley, 1995

43

Example—bank simulation (Horstmann), cont.

An initial solution (Horstmann, p. 388):

Event

Departure

Arrival

Customer Bank

EventQueue

Application

Bank Statistics

44

Example—bank simulation (Horstmann), cont.

An improved solution (Horstmann, p. 391):

Event

Departure

Arrival

Customer Bank

EventQueue

Simulation

Bank Statistics

45

Comparison

What simplifications

have been made?

Why?

Event

Departure

Arrival

Customer Bank

EventQueue

Application

Bank Statistics

Event

Departure

Arrival

Customer Bank

EventQueue

Simulation

Bank Statistics

46

Example:

How would we use the tools described so far to design a “smart” vending machine? How would we develop test cases at each stage?

Use cases?

Class diagram?

Sequence diagram?

Classes / CRC cards?

47

Software modeling for embedded systems: static and dynamic behavior

48

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

49

table_05_00

Recall: “UML” syntax can vary among implementations;

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

50

fig_05_00

UML: Use case diagram (graphical)

51

fig_05_01

UML Use case diagram--example

52

fig_05_02

UML: Use case diagram (text); note exceptions

53

UML—static modeling

54fig_05_03

UML: Class diagram (“CRC card”)

Class name

data

Methods (responsibilitiesandcollaborators)

(+ collaborators)

55

fig_05_04

UML: class relationships: inheritance

56

fig_05_05

UML: “interface”—similar to inheritance but different

public appearance

Hidden operation

57

fig_05_06

UML: containment of one class within another

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

58

fig_05_07

UML: containment of one class within another

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

59

UML—dynamic modeling

60

fig_05_08

UML: interaction diagram—call and return

61

fig_05_09

UML: interaction diagram—create and destroy

62

fig_05_10

UML: interaction diagram—send (no response expected)

63

fig_05_11

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

64

fig_05_12

UML sequence diagram--example

65

fig_05_13

UML: concurrent behavior. Example: fork and join

66

fig_05_14

UML: concurrent behavior. Example: branch and merge

67

fig_05_15

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

68

fig_05_16

UML state machine models--4 types of events:

UML state chart is a directed graph

69

fig_05_18

UML state chart: types of transitions

initial state

final state

70

fig_05_19

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

71

fig_05_20

UML: can decompose state into sequential substates

72

fig_05_21

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

73

fig_05_22

UML: can have concurrent substates

74

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

75

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

76

fig_05_23

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

77

fig_05_24

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

78

fig_05_25

Control and data flow diagrams: Data sources and sinks

79

fig_05_26

Control and data flow diagrams: Data stores

80

fig_05_27

Control and data flow diagrams: Example

81

fig_05_28

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