Topics for week 3

1
Embedded Systems Software Modeling and
Programming-- The Object-oriented
Paradigm and The Unified Modeling Language (UML)
2
Problems of software development

• "problems" of software development (review)
• conceptual integrity
• incremental build, progressive refinement
• large projects "differ" from small ones
• programming paradigms (1950s-present) attempts
  to deal effectively with these problems, make
  software easier to develop and to maintain

3
A Brief History Computer Hardware, Computer
Languages, Design Techniques
1950'sunstructured, 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 1990s encapsulation,
information-hiding, reuse, hardware/software
codesign (from simulation languages developed
much earlier, e.g., Modula, simula) --C,
Java 2000s info hiding web languages
environments encapsulating multiple languages,
styles --.NET, C, Python, Perl, MATLAB,
Mathematica, Labview,
Early machineslarge, central (Eniac) Supercom
puters, 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
http//en.wikipedia.org/wiki/PIC _microcontroller
History
techxav.com
cse.mtu.edu
visual.merriam-webster.com
http//www.amd.com/us-en/assets/content_type/Addit
ional/ 43494A_QuadCore_Opt_Die_BLK_HRes.jpg
textually.org
http//t0.gstatic.com/images?qtbnANd9GcS3J9yAV0Y
ibC4keB8M_6hc0xh3sZYbbGKZUK-pHLzx7Lkek74w
4
OO class
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)
5
Record/class
traditional record (struct) functions to use
or modify this record can be anywhere
in the program OO class concept supports
encapsulation, information hiding
OO Prog.
DATA
DATA
DATA
DATA
DATA
DATA
DATA
Procedural Prog.
6
Inheritance
Ex Object data structures A. Base class B.
Derived class
X Y Z W
X Y Z
A.
B.
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 animal animal 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 plant the 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
7
Polymorphism and overloading
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) Overload
ing ex cin gtgt num1 gtgt 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
8
Templates
Templates example template ltclass Tgt T
method1 (T x) .. can be specialized int
method1 (int x) float method1 (float
y) usertype method1 (usertype a) templates
promote reuse
9
Separate compilation

• 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

10
Misuse of object-oriented paradigm
Note no paradigm is misuse-proof
11
Using OO (a subset of) UML in a project
design design for testability
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 diagrams state
diagrams sequence diagrams individual class
functions white box or glass box tests
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
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
14
Example use case
Example cellular network place and receive calls
use case (based on Booch, Rumbaugh, and
Jacobson, The Unified Modeling Language User
Guide)
Text description --Use case name (cellular
network place and receive calls) --Participat
ing 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)
System boundary
Use case diagramsummarizes, provides system
overview
Text descriptiongives important details
15
use case
Text description Use case name Participating
actors Flow of events Entry condition(s) Exit
condition(s) Quality requirements
16
Use casedetailed 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) )

Homeowner
Accesses system via internet
Sensors
System administrator
Reconfigures sensors and related system
features
Pressman, p. 163, Figure 7.3
17
Use casedetailed 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
recognizedmust 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 casedetailed 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 additionssimplifications of use case
descriptions

• A. Include one use case includes another in its
  flow of events (cases A and B both include case
  C)
• Extend extend one use case to include
  additional behavior (cases D and E are extensions
  of case F)

ltltincludegtgt
A
C
B
ltltincludegtgt
ltltextendgtgt
D
F
E
ltltextendgtgt
21
Use case additions
C. Inheritance one use case specializes the
more general behavior of another G and H
specialize behavior of J)
G
J
Authenticate with password
authenticate
H
Authenticate with card
22
Use case continued
Examples what would be a use case for
vending machine traffic light
Use case name Participating actors Flow of
events Entry condition Exit condition Quality
requirements
23
System Tests

• 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)

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
Review use case Graphical description
Text description Use case
name Participating actors Flow of events Entry
condition(s) Exit condition(s) Quality
requirements
Homeowner
Accesses system via internet
Sensors
System administrator
Reconfigures sensors and related system
features
Pressman, p. 163, Figure 7.3
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 longuse extends, includes
instead --as you develop use cases, develop
associated tests
28
Class and object diagrams Identify Objects from
Use Case Specifications USE ENDUSERs 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,Customer
  Arrival
• 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
processes asynchronous 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 objects 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
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 (11, 1n, 10m 1, i.e., any number gt
0, 11, i.e., any number gt 1)
tire car can exist independentlyshared
aggregation
person
arm is part of the person composition aggregation
arm
1 2
36
ER diagram--uses
uses or association there are many ways to
represent this relationship, e.g.,
employs
1
company
car
gasstation



n
employee
1
works for
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
Queue of new messages Queue of kept
messages Greeting Extension number Passcode
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)
start
/get first item
not all items checked /get next item
all items checked all items available
Dispatching
Checking
initiate delivery
check item
all items checked some items not in stock
delivered
item received all items in stock
Delivered
Waiting
item received some items not in stock
42
Examplebank simulation (Horstmann)
Horstmann, Mastering Object-Oriented Design in
C, Wiley, 1995
Teller 1
Teller 2
Customer 1
Customer 3
Customer 2
Teller 3
Teller 4
43
Examplebank simulation (Horstmann), cont.
An initial solution (Horstmann, p. 388)
44
Examplebank simulation (Horstmann), cont.
An improved solution (Horstmann, p. 391)
45
Comparison
What simplifications have been made? Why?
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 controlmodels sequential execution
  of a set of instructions embedded system may
  have several concurrent threads operating
  simultaneously
• --persistencehow 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
table_05_00
50
fig_05_00
UML Use case diagram (graphical)
fig_05_00
51
fig_05_01
UML Use case diagram--example
fig_05_01
52
fig_05_02
UML Use case diagram (text) note exceptions
fig_05_02
53

• UMLstatic modeling

54
fig_05_03
UML Class diagram (CRC card) Class
name data Methods (responsibilities and colla
borators)
( collaborators)
fig_05_03
55
fig_05_04
UML class relationships inheritance
fig_05_04
56
fig_05_05
UML interfacesimilar to inheritance but
different public appearance Hidde
n operation
fig_05_05
57
fig_05_06
UML containment of one class within
another Type 1 aggregationstatistical analysis
has a number of algorithm parts
fig_05_06
58
fig_05_07
UML containment of one class within
another Type 2 compositionhere the intervals
are meaningless outside the schedule ( local
variables)
fig_05_07
59

• UMLdynamic modeling

60
fig_05_08
UML interaction diagramcall and return
fig_05_08
61
fig_05_09
UML interaction diagramcreate and destroy
fig_05_09
62
fig_05_10
UML interaction diagramsend (no response
expected)
fig_05_10
63
fig_05_11
UML sequence diagram sequence of actions
carries out a use case
fig_05_11
64
fig_05_12
UML sequence diagram--example
fig_05_12
65
fig_05_13
UML concurrent behavior. Example fork and
join
fig_05_13
66
fig_05_14
UML concurrent behavior. Example branch and
merge
fig_05_14
67
fig_05_15
UML activity diagramcaptures all actions and
control flows within a task
fig_05_15
68
fig_05_16
UML state machine models--4 types of
events UML state chart is a
directed graph
fig_05_16
69
fig_05_18
UML state chart types of transitions
initial state
final state
fig_05_18
70
fig_05_19
UML state chart actions and guard conditions If
guard condition is false, transition does not
happen
fig_05_19
71
fig_05_20
UML can decompose state into sequential substates
fig_05_20
72
fig_05_21
UML can define a history state (e.g., for an
interrupt)system will probably eventually return
to this state
fig_05_21
73
fig_05_22
UML can have concurrent substates
fig_05_22
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

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

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)
fig_05_23
77
fig_05_24
Control and data flow diagrams tasks (with
hierarchy levels)
fig_05_24
78
fig_05_25
Control and data flow diagrams Data sources
and sinks
fig_05_25
79
fig_05_26
Control and data flow diagrams Data stores
fig_05_26
80
fig_05_27
Control and data flow diagrams Example
fig_05_27
81
fig_05_28
Control and data flow diagrams Hierarchical
view of an input / output task
fig_05_28