SWESD Consolidated

Software for Embedded Systems
IS ZC424
S. S. Samant
surender.samant@hyderabad.bits-pilani.ac.in
IS ZC424 (Software for Embedded System) 16
th
Jan, 2014
Objective
To introduce embedded and real-time nature of
systems and educate in methodologies, tools and
techniques for designing such software.
th
Jan, 2014
Prerequisites
Basic computer architecture
Programming concepts in OOP (C++)
Operating system concepts
th
Jan, 2014
Course modules
Module Title No of
classes
1
Introduction to Real-Time and Embedded Systems
1
2
Object Orientation with UML 2.0 Structural
Aspects
1
3
Object Orientation with UML 2.0 Dynamic
Aspects
2
4
UML Profile for Schedulability, Performance and
Time.
1
5
Requirements Analysis of Real Time Systems
2
6
Analysis: Object Domain Analysis
1
Review
1
7
Analysis: Defining Object Behavior
2
8
Architectural Design
2
9
Mechanistic Design
2
10
Detailed Design
2
Review
1
th
Jan, 2014
Instructor
E-Mail: surender.samant@hyderabad.bits-pilani.ac.in
th
Jan, 2014
Text book
Real-Time UML, Third Edition, 2004
by
Bruce Powel Douglass, Pearson Education
th
Jan, 2014
Reference books
Douglass, Real-Time UML Workshop for
Embedded Systems, Elsevier, 1
st
Edition, 2011
You may consult any other book related to
Embedded systems
th
Jan, 2014
Evaluation
Evaluation
Component
Type Duration Weight
EC-1 Quiz 3 * (5% each) 15%
EC-2 Mid-Semester Test
(Closed Book)
2 hours 35%
EC-3 Comprehensive Exam
(Open Book)
3 hours 50%
th
Jan, 2014
Motivation
A world of embedded systems
Need formal design and development
techniques
Need focus on certain design criteria
Reliability
Safety
Real-Time
A foundation course for
Solutions development
Real-Time system concepts
th
Jan, 2014
Scope
Study distinct characteristics of Embedded &
Real-Time systems
Focus on
Real-Time system issues
Specification, modeling, and design methodologies
for embedded systems
Case studies
th
Jan, 2014
Embedded System Overview
th
Jan, 2014
Overview
Computing systems are everywhere
Most of us think of computers as
?
th
Jan, 2014
Overview
PCs, Laptops/tablets, Mainframes
th
Jan, 2014
Overview
PCs, Laptops/tablets, Mainframes
But theres another type of computing system
?
th
Jan, 2014
Overview..
Embedded computing
systems
Computing systems embedded
within electronic devices
Hard to define. Nearly any
computing system other than a
general-purpose computer
Billions of units produced yearly,
versus millions of desktop units
Perhaps more than a dozen per
household and per automobile
Computers are in
here...
and here...
and even here...
Lots more of these,
though they cost a lot
less each.
th
Jan, 2014
A short list of embedded
systems
And the list goes on and on
Anti-lock brakes
Auto-focus cameras
Automatic teller machines
Automatic toll systems
Automatic transmission
Avionic systems
Battery chargers
Camcorders
Cell phones
Cell-phone base stations
Cordless phones
Cruise control
Curbside check-in systems
Digital cameras
Disk drives
Electronic card readers
Electronic instruments
Electronic toys/games
Factory control
Fax machines
Fingerprint identifiers
Home security systems
Life-support systems
Medical testing systems
Modems
MPEG decoders
Network cards
Network switches/routers
On-board navigation
Pagers
Photocopiers
Point-of-sale systems
Portable video games
Printers
Satellite phones
Scanners
Smart ovens/dishwashers
Speech recognizers
Stereo systems
Teleconferencing systems
Temperature controllers
Theft tracking systems
TV set-top boxes
DVD players
Video game consoles
Washers and dryers
th
Jan, 2014
Common characteristics
Single-functioned
Mostly execute a single program, repeatedly
th
Jan, 2014
Single-functioned
while(1)
{
Embedded system code
}
th
Jan, 2014
Single-functioned
Tightly-constrained
Low cost, low power, small
th
Jan, 2014
Single-functioned
Tightly-constrained
Reactive, Real-time
th
Jan, 2014
Single-functioned
Tightly-constrained
Reactive, Real-time
Often run continuously for a long period
th
Jan, 2014
Contains a computer as part of a larger system
Primary job is not to provide standard computing
services
Often work in hazardous conditions, remotely
Watchdog Timers are used
Numerous examples Microwave ovens,
Washing machines, MP3 player, Digital camera,
Space probes, ABS, etc.
th
Jan, 2014
An example -- a digital camera
Microcontroller
CCD preprocessor Pixel coprocessor
A2D
D2A
JPEG codec
DMA controller
Memory controller ISA bus interface UART LCD ctrl
Display ctrl
Multiplier/Accum
Digital camera chip
lens
CCD
Single-functioned -- always a digital camera
Tightly-constrained -- Low cost, low power, small, fast
Reactive and real-time -- only to a small extent
th
Jan, 2014
Another example - Mobile phone
Single-functioned -- always a mobile phone
Tightly-constrained -- Low cost, low power, small, fast
Reactive and real-time -- only to a small extent
Image courtesy: Embedded Systems by
James Peckol
th
Jan, 2014
Combination of h/w and s/w parts, a system
within another system, that we bring together
into products
What is an Embedded System?
th
Jan, 2014
into products
Embedded systems allow us to make products
that are smaller, faster, more reliable, and
cheaper
th
Jan, 2014
into products
cheaper
Allow us to bring powerful features and
capabilities into everyday things
th
Jan, 2014
into products
cheaper
Allow us to bring powerful features and
capabilities into everyday things
Intended to do intended job quietly, reliably, out
of sight inside some larger system
we become aware when they fail
th
Jan, 2014
Real-Time System - Definition
Coarse definition
A system which is required to complete its work
and deliver its services on a timely basis
Ex:
Digital control
Signaling
Radar systems
Guided missiles
Multimedia applications
Alarm management
th
Jan, 2014
Real-Time systems
Timing constraints:
Hard dead lines
Soft dead lines
Tardiness
Measured in deterministic or probabilistic terms
th
Jan, 2014
Examples
Hard real-time:
Flight control
Railway signaling
Anti-lock brakes
Etc.
Soft real-time:
Stock trading system
DVD player
Mobile phone
Etc
th
Jan, 2014
Jobs and tasks
A job is a unit of work that is scheduled and executed by
a system
computation of a control-law
computation of an FFT on sensor data,
transmission of a data packet,
retrieval of a file
A task is a set of related jobs which jointly provide some
function
keeping an airplane flying at a constant altitude
th
Jan, 2014
Processors and Resources
A job executes or is executed by the operating system
on a processor and may depend on some resources
Processor (P):
active resource: computers, hard disks, database
servers, etc.
have speed as attribute
Resource (R):
a passive entity that a job may need: memory,
mutexes, locks, etc.
th
Jan, 2014
Execution Time
A job J
i
will execute for time e
i
Amount of time required to complete the execution
of J
i
when it executes alone and has all the resources
it needs
th
Jan, 2014
Release and Response Time
Release time
The instant in time when a job becomes
available for execution
Response time
The length of time from the release time of the
job to the time instant when it completes
th
Jan, 2014
Deadlines and Timing Constraints
Completion time the instant at which a job completes execution
Relative deadline the maximum allowable job response time
Absolute deadline the instant of time by which a job is required
to be completed (often called simply the deadline)
absolute deadline = release time + relative deadline
Feasible interval for a job J
i
is the interval (r
i
, d
i
]
th
Jan, 2014
Example Control law computation
A system to monitor and control a heating furnace
Every 100 ms,
Samples, reads temperature
Computes the control-law,
Adjusts flow rates
First control-law computation begins at 20 ms (Job J
0
)
th
Jan, 2014
Every 100 ms,
Adjusts flow rates
0
)
The release time of J
k
is 20 + (k 100) ms, for k=0, 1, 2,
th
Jan, 2014
Every 100 ms,
Adjusts flow rates
0
)
k
is 20 + (k 100) ms, for k=0, 1, 2,
The computation must finish before the subsequent job is released
The deadline are ?
th
Jan, 2014
Every 100 ms,
Adjusts flow rates
0
)
k
is 20 + (k 100) ms, for k=0, 1, 2,
The computation must finish before the subsequent job is released
The deadline are 120 ms, 220ms, 320 ms,
th
Jan, 2014
Example..
th
Jan, 2014
Every 100 ms,
Adjusts flow rates
0
)
k
is 20 + (k 100) ms, for k=0, 1, 2,
If the computation must finish 50 ms before the

subsequent job is released, what are the deadlines?
th
Jan, 2014
Every 100 ms,
Adjusts flow rates
0
)
k
is 20 + (k 100) ms, for k=0, 1, 2,
If the computation must finish 50 ms before the

subsequent job is released, the deadlines are 70 ms,
170ms, 270 ms,
th
Jan, 2014
Types of Tasks
Types:
Periodic
Aperiodic
Sporadic
th
Jan, 2014
Modeling Periodic Tasks..
U
i
(utilization of task T
i
)= e
i
/ p
i
Total utilization= U = U
i
Usually assume the relative deadline for the
jobs in a task is equal to the period of the task
For example, if there are 3 tasks with execution time of 1, 1, 3;
period 3, 4, 10, respectively, then
Utilizations are respectively 0.33, 0.25, and 0.3
Total utilization = 0.88.
Total utilization means what percentage of time
the tasks can keep the processor busy
th
Jan, 2014
Designing Embedded systems require complex
hardware and software models
UML simplifies modelling software for
embedded systems with graphical
representations and notations
th
Jan, 2014
Summary
Embedded systems are ubiquitous
Work quietly, out of sight within other systems
Often time and life-critical jobs
Most are Real-time systems
We need some tools to simplify our study of
embedded system
UML provides graphical way of simplifying the
complexity of embedded system
th
Jan, 2014
Thank You!
Object Orientation with UML Structural Aspects
IS ZC424
Recap
th
Jan, 2014
Unified Modeling Language (UML )
What it is:
Standardized, general-purpose modeling language
Flexible and extendable
Is used to specify, visualize, modify, construct and
document the artifacts of an object-oriented software
system
What it is not:
Not a prescriptive process
Does not supply a method or process
th
Jan, 2014
Structural Aspects
UML allows to:
specify organization of elements that exist at
runtime, their internal organization
specify how elements are organized in interaction
identify design-time types of run-time elements
identify relations among types and instances of
those types
th
Jan, 2014
Suitability for Embedded systems
Well-defined object model for defining system structure
Strong dynamic modeling - both collaborative and
individual behavior
Straightforward representation of concurrency aspects
Models of physical topology (deployment)
Support for object-oriented patterns to facilitate design
reuse
th
Jan, 2014
Objects
An object
is a cohesive entity that has attributes, behavior, and
(optionally) state
Represent anything(real or conceptual) that has
state and behavior
Fundamental unit of decomposition in OOP
th
Jan, 2014
Example- Sensor object
Identity
Instance for robot arm joint
Responsibility
Provide information for the precise location of the
end of the robot arm with respect to some reference
coordinate frame
Attributes
Linear value, Rate of change (RoC)
Behavior
Acquire, Report, Reset, Zero, Enable, Disable
th
Jan, 2014
Object abstraction
Process of identifying the
key aspects of something
and ignoring the rest
th
Jan, 2014
Classes
Main Features
Attributes, that is data specified within a class
Methods and operations
Methods vs. Operations?
th
Jan, 2014
Classes
Main Features
Operation is a service that an instance of the class is
requested to perform; it has formal parameter list and
return value
constructor and destructor
Method is implementation of an operation; conversely an
operation specifies a method
Abstract classes?
th
Jan, 2014
Classes
Main Features
return value
Abstract classes?
Abstract classes cant be instantiated. Why?
th
Jan, 2014
Classes
Main Features
return value
Abstract classes?
Abstract classes cant be instantiated because their
specification is incomplete; they define an operation
without the corresponding method
th
Jan, 2014
Classes and Objects
th
Jan, 2014
Classes and Objects
The objects depict a
"snapshot
Class notation : canonical
form has simple named
rectangle; detailed form as
shown in the right with
different compartments for
attributes and methods
Object notation: Like class
but the name of object is
followed by a colon and
name of its class type
th
Jan, 2014
Notations: Objects and Classes
Lines connecting
objects/classes show
association between
classes and objects
Visibility of a
feature(attribute,
method or operation):
1. Public +
2. Protected #
3. Private -
4. Package ~
th
Jan, 2014
Interface
Specification of named contract (set
of operations) offered by a class
Cannot be instantiated
A class can realize the Interface
specification i.e. provide method for
each operation specified in the
interface
Notation: interface or lollipop
notation ; the former is called
stereotype in UML(guillemets)
----------> means depends on
th
Jan, 2014
Mapping objects to code
class SensorClient {
protected:
iSensor* myISensor;
public:
void displayValue(void) {
int sensedValue = myISensor.getValue();
cout << value << endl;
}
};
class iSensor { // abstract class
public :
virtual int acquire(void)=0; // pure virtual
virtual int getValue(void)=0; // pure virtual
virtual void setCalibrationConstant(long
newCalibrationConstant)=0;
};
class Sensor : public iSensor {
protected :
iFilter* myIFilter;
int value;
long calibrationConstant;
public :
int acquire(void){}
int getValue(void){
return myIFilter->filterValue(value);
}
void setCalibrationConstant(long newCalibrationConstant){ }
};
class iFilter {
public :virtual int filterValue(int value)=0; // pure virtual
};
class Filter : public iFilter {
int lowPassValue, highPassValue;
void setFilterParameters((int newLowPass, int newHighPass){
lowPassValue = newLowPass;
highPassValue = newHighPass;
}
int filterValue(int value) {
return (value==0) ? lowPassValue : highPassValue;
}
};
th
Jan, 2014
Messaging
Action: low-level unit of behavior of an object
A message is an abstraction of data and/or control information
passed from one object to another
Possible implementations:
A function call
Mail via a real-time operating system (RTOS)
An event via a RTOS
An interrupt,
etc.
th
Jan, 2014
Messaging
th
Jan, 2014
Relations
Classes can work together by relating to each other in three ways:
Association
Generalization
Dependency
Association are of three distinct kinds:
Association shown with a line between classes with open
arrowhead at one end, or no arrowhead(or arrowheads at both
ends)
Aggregation shown with a white diamond at one end(the
whole part)
Composition shown with a filled diamond at one end(the whole
part)
th
Jan, 2014
Association
Multiplicity indicates the
possible instances that
can participate in the
association
Multiplicity at an
association end is
represented as
numbers, comma-
separated list, range,
asterisk, etc.
th
Jan, 2014
Aggregation & Composition
Aggregation indicates
whole-part relationship
between two classes
Composition is a stronger
form of aggregation
Whole/composite part is
responsible for the
creation/destruction of part
objects
Composite/whole owns the
part object
th
Jan, 2014
Composition
Two common presentations of
composition:
1. filled-in diamond shows
relation between classes
2. Nested class: within the
composite classes, these
are object; additional
constraints like specifying
multiplicity more precisely
as in the example
th
Jan, 2014
Generalization
Used to
indicate
inheritance.
"is a type of
relation.
one class
defines a set
of features,
which are
either
specialized or
extended in
another.
used as a
th
Jan, 2014
Dependency
All relations other than
Association and
Generalization
Most useful stereotypes
of dependencies
1. bind
2. usage
3. friend
All dependencies are
shown as a dashed line
with a open arrowhead,
as in the figure on the
right side
th
Jan, 2014
Large-scale Structures
Small-scale structures we have seen are small-scale that
collaborate to achieve the behavior of the system
Systems are developed & managed using large-scale structures
which are based on small-scale structures
These large structures handle two common scalability
problems in real systems:
1. Organizing model; keeping track of hundreds/thousands of
classes and sharing work among developers - handled with
Packages
2. Keeping track of large runtime things - handled with components
and subsystems
th
Jan, 2014
Package diagram
1. Packages: design-time
model elements that can
contain other model
elements
2. Package define a
namespace for the model
elements
3. Here domain means
the classes have a
common subject or
vocabulary
th
Jan, 2014
Components
Components are
primary replaceable
units of software
Provides a coherent
set of services
th
Jan, 2014
Subsystems
Decompose physical
organization of large-
scale systems
Highest level of
abstraction
th
Jan, 2014
Subsystems (contd)
Decompose physical
organization of large-
scale systems
Highest level of
abstraction
th
Jan, 2014
Deployments: Nodes
Artifacts are files that implement
software elements such as
classes/components
Node is the thing onto which an
artifact is deployed; it executes the
artifacts
Artifacts are nested within nodes
Two common type of nodes are:
devices and execution environments
Devices can further be divided into
processors and simple devices
Processors are stereotyped as
processor while simple devices are
commonly represented by iconic
stereotypes
Node has a 3-D icon
Artifact is represented as artifact or
icon (rectangle with a folded corner)
Components implemented by artifacts
are shown within a constraint
th
Jan, 2014
More Notations
A text note is a
diagrammatic
element to
provide textual
annotations to
diagrams in order
to improve
understanding
Represented as a
rectangle with
upper righthand
corner folded
down
Constraints are
th
Jan, 2014
Summary
In this lecture, we studied
Structural aspects of using UML for object oriented design of
large systems
Various notations and representations in UML
Some examples of large system and their structural
representation
How large system can be decomposed into smaller subsystems
and components
In the next couple of lectures, behavioral aspects of the design in
UML will be studied
How the change of state of a system in response to an event is
represented using UML
th
Jan, 2014
Thank You!
Software for Embedded System
IS ZC424
Object Orientation with UML 2.0
Dynamic Aspects
th
Jan, 2014
Recap
Last session was about structural aspects in UML
Classes, objects, interfaces, packages, subsystems, components,
etc. were discussed
We also saw how associations and links among different entities
are represented in UML (notations)
Inheritance
Interfaces
Aggregation
Composition
Etc.
th
Jan, 2014
Deployments: Nodes
Artifacts are files
that implement
software elements
such as
classes/component
s
th
Jan, 2014
Deployments: Nodes
Artifacts are files
that implement
software elements
such as
classes/component
s
Node is the thing
onto which an
artifact is
deployed; it
executes the
artifacts
th
Jan, 2014
Deployments: Nodes
Artifacts are files
that implement
software elements
such as
classes/component
s
Node is the thing
onto which an
artifact is
deployed; it
executes the
artifacts
Processors are
th
Jan, 2014
Deployments: Nodes
Artifacts are files
that implement
software elements
such as
classes/component
s
Node is the thing
onto which an
artifact is
deployed; it
executes the
artifacts
Processors are
th
Jan, 2014
Deployments: Nodes
Artifacts are files
that implement
software elements
such as
classes/component
s
Node is the thing
onto which an
artifact is
deployed; it
executes the
artifacts
Processors are
th
Jan, 2014
More Notations
A text note is a
diagrammatic
element to
provide textual
annotations to
diagrams in order
to improve
understanding
Constraints are
additional
restriction; inside
curly brackets
th
Jan, 2014
Behavior in UML
How values or states of objects change over time
UML allows:
specify behaviors of individual objects
interactions among many objects
Behavior binds the structure of objects with their attributes and
relationships so that objects can meet their responsibilities
Actions implement an objects behavior
Actions are put in the functions/methods of classes in C++, Java,
etc.
th
Jan, 2014
Types of behavior
Three distinct types of behavior
Simple behavior
State behavior
Continuous Behavior
th
Jan, 2014
Simple behavior
Object performs services on request and keeps no memory of
previous services
Each action is atomic and complete
Always responds to a given input in exactly the same way,
regardless of its history.
Ex: Simple mathematical functions
search operation of a static data structure
Add
th
Jan, 2014
State behavior
Treats the object as a finite state machine
Object possesses a bounded (finite) set of conditions of existence
(state)
Incoming events can induce transitions between object states in
some predefined manner
Such objects are also called reactive objects
Ex: Lift control
We will mostly study state behavior in this course.
th
Jan, 2014
Continuous behavior
Has an infinite, or at least unbounded, set of existence conditions
Current behavior is dependent on past behavior and inputs
Ex: Low Pass Filter, and Moving Average in statistics
Low pass filter Input bit stream Output bit stream
th
Jan, 2014
Actions and Activities
Activity is a kind of behavior - consists of actions; activities
provide execution context for actions
An action takes a set of inputs and produces a set of outputs
Actions have "run-to-completion" semantics objects, while
executing an action dont accept events until completion
Activities(except entry, exit & transition) do not have run-to-
completion semantics so, are interruptible
th
Jan, 2014
Statechart (or State diagram/machine)
Two fundamental concepts:
State: condition of existence of an instance
distinguishable from other such conditions
th
Jan, 2014
Transition: changing of state from source to target
th
Jan, 2014
Transition: changing of state from source to target
th
Jan, 2014
Statechart: State Features
Actions may get executed
when:
state is entered or
exited
th
Jan, 2014
when:
state is entered or
exited
a transition is taken
th
Jan, 2014
when:
state is entered or
exited
Self transition: entry
and exit action are
taken
Internal transition: no
entry or exit action;
some event is
processed without
changing state
th
Jan, 2014
when:
state is entered or
exited
and exit action are
taken
some event is
processed without
changing state
do activities: events
are processed;
interruptible
th
Jan, 2014
when:
state is entered or
exited
and exit action are
taken
some event is
processed without
changing state
do activities: events
are processed;
interruptible
Defer clauses: list of
events to be deferred
but remembered
th
Jan, 2014
Statecharts
Transition has named event triggers optionally followed by
actions
Event signature is of the form
event-name ( parameter-list ) [ guard-expression ] / action-
list
All fields are optional
Guard expression is a boolean expression within [ ]
Guards shouldnt have side-effects; are simple way to
ensure preconditions are met
th
Jan, 2014
Statecharts
th
Jan, 2014
And-States
States that are simultaneously true and independent, separated with dashed-line,
called regions or orthogonal regions, always sub-states of a composite state
Multiple and-states may process the same event as they receive a personal copy of
any event received by the object
th
Jan, 2014
Pseudo-States
Abstraction for various types of
transient vertices used in State
Machine diagrams
Used to express complex
transition paths.
Initial or default
Conditional
Junction
History
Final
Fork
Join
Entry Point
Exit Point
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Initial or default
Conditional
Junction
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths:
History
Shallow or Deep
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Fork
Join
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Fork
Join
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Fork
Join
th
Jan, 2014
Pseudo-States
Entry Point
Exit Point
th
Jan, 2014
Pseudo-States
th
Jan, 2014
Summary
Discussed Components of state diagrams such as states,
transitions, and various pseudo-states in UML
In the next session, well discuss diagrams that show
collaborative behaviour of multiple entities
th
Jan, 2014
Thank You!
IS ZC424
Object Orientation with UML 2.0Dynamic Aspects
(contd)
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Initial or default
Conditional
Junction
History
Terminate
Final
Fork
Join
Entry Point
Exit Point
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Initial or default
Conditional
Junction
th
Jan, 2014
Pseudo-States
History
Shallow or Deep
Shallow history example:
MP3 player /STB remote
remembers the last track
/mode(TV/AV1)
Deep history example: MP3
player also remembers the
duration into the track
/channel in AV mode
STB remembers the
channel that was on
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Fork
Join
th
Jan, 2014
Pseudo-States
Machine diagrams
transition paths.
Entry Point
Exit Point
th
Jan, 2014
Ill-formed Statechart
th
Jan, 2014
Activity diagram
Used to model behaviors of
activities on states
Common use in embedded
& real-time domain is to
show computational
algorithms
Classifier progresses from
state to state when the
actions done in the
predecessor state have
completed (token execution
semantics)
In short, Activity diagrams
show:
Sequence of activities
Workflow from start
point to finish point
detailing the decision
paths
th
Jan, 2014
Activity diagram
Used to model behaviors of
activities on states
Common use in embedded
& real-time domain is to
show computational
algorithms
Classifier progresses from
state to state when the
actions done in the
predecessor state have
completed (token execution
semantics)
In short, Activity diagrams
show:
Sequence of activities
Workflow from start
point to finish point
detailing the decision
paths
The Activity Diagram on the
right shows a customer
withdrawing money from an
ATM machine
th
Jan, 2014
Activity diagram
right shows Activity Diagram
for DistrubuteSchedule
pin
Parameter
signal
th
Jan, 2014
Activity diagram
for positioning a Robot arm
to grasp an object
th
Jan, 2014
Activity diagram
for positioning a Robot arm
to grasp an object
Notations: Interruptible
section, event
reception/signal, and
interrupting edge
th
Jan, 2014
Activity diagram
th
Jan, 2014
Interactions
Collaborative behavior of multiple entities working together.
Sequenced exchange of messages among large set of interacting objects.
In Interaction diagrams we will study:
Sequence Diagrams: show the order of messages over time (top-down
progress); sequence diagrams is where we will focus on
Timing diagrams: shows change in state or value over time
th
Jan, 2014
Sequence diagram
Structured
representatio
n of behavior
as a series of
sequential
steps over
time
Depict work
flow,
message
passing and
how elements
in general
cooperate
Active instance
th
Jan, 2014
Sequence diagram
SD for
Scenario2 :
When bad
PIN from
client
results in
failure to
withdraw
money from
ATM
th
Jan, 2014
Elevator Scenario
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Elevator Scenario
th
Jan, 2014
Sequence diagram: Partial Order
th
Jan, 2014
Interaction Operators
alt guard controlled, dash-line
separated alternatives
opt Optional fragment
loop loop the specified number
of times or until {constraint}
th
Jan, 2014
par parallel regions; concurrent
execution
criticalRegion cant be interleaved
consider messages shouldnt be
ignored
assert must be true
th
Jan, 2014
consider not to be ignored
ignore - to be ignored
assert must be true
th
Jan, 2014
Timing diagram
Defines the behavior of
different objects within a
time-scale
Provides a visual
representation of objects
changing state and
interacting over time
time along the horizontal
axis and object state or
attribute value along the
vertical axis
th
Jan, 2014
Timing diagram
time-scale
Provides a visual
changing state and
vertical axis
Timing Diagram - Multiple Lifelines
th
Jan, 2014
Thank You!
IS ZC424
Lecture 5
UML Interactions (Contd), Real-time Profile,
AND
Safety &Reliability
th
Jan, 2014
Elevator Scenario
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Reference in a SD
th
Jan, 2014
Sequence diagram: Partial Order
th
Jan, 2014
alt guard controlled, dash-line
separated alternatives
opt Optional fragment
loop loop the specified number
of times or until {constraint}
th
Jan, 2014
par parallel regions; concurrent
execution
criticalRegion cant be interleaved
consider messages shouldnt be
ignored
assert must be true
th
Jan, 2014
consider not to be ignored
ignore - to be ignored
assert must be true
th
Jan, 2014
Timing diagram
time-scale
Provides a visual
changing state and
vertical axis
th
Jan, 2014
Timing diagram
time-scale
Provides a visual
changing state and
vertical axis
Timing Diagram - Multiple Lifelines
th
Jan, 2014
UML Profile
Variant of UML that is specialized
UML Profile contains:
specialized versions of models called stereotypes
user-defined values called tag-value pairs
well-formedness rules called constraints
Profile is not allowed to break existing semantics
Advantages:
Standardized idioms and design patterns for a particular
domain
allows tools to exchange models that use the profile
th
Jan, 2014
Stereotypes
Stereotypes:
Processor
MessageQu
eue
Motor
Semaphore
Active
Exist to allow
adding
domain
specific
concepts to
modeling
th
Jan, 2014
Tagged values
Stereotypes are
customized by
adding a tagged
value or property
Provides the
definition of the
kind of information
added to the
stereotype
Constraint is a
user-defined rule
or rule of
th
Jan, 2014
RTP (Real-Time Profile)
Also known as RT UML profile
Full name is:
UML profile for Schedulability, Performance, and Time
Allows users to use special stereotypes as part of the basic
modelling language
More closely aligned to the Real-Time and Embedded domain
th
Jan, 2014
Time Modeling Subprofile
Stereotype Tag
RTaction RTstart,
RTend,
RTduration
RTevent RTat
RTstimulus RTstart,
RTend
RTtimer RTduration,
RTperiodic
And many more
th
Jan, 2014
Performance Modeling Subprofile
Stereotype Tag
PAOpenLoad PArespTime,
PAPriority,
PAOccurence
PAStep PArespTime
And many more.
th
Jan, 2014
Stereotype Tag
PAPriority,
PAOccurence
PAStep PArespTime
And many more.
th
Jan, 2014
Stereotype Tag
PAPriority,
PAOccurence
PAStep PArespTime
And many more.
th
Jan, 2014
Stereotype Tag
PAPriority,
PAOccurence
PAStep PArespTime
And many more.
th
Jan, 2014
Stereotype Tag
PAPriority,
PAOccurence
PAStep PArespTime
And many more.
th
Jan, 2014
Safety and Reliability
Risk : undesirable event or condition
Safety : ideally, about safe systems free from risk
Reliability
th
Jan, 2014
Risk = probability of failure * severity
Increased risk decreased safety
th
Jan, 2014
Increased risk decreased safety
Reliability affects the probability of failure
th
Jan, 2014
e.g. building a new nuclear plant
th
Jan, 2014
Reliability
Measured by availability of up time of system
Increasingly important
embedded systems are finding ways into areas where typical
user knows little about operation of products they buy
th
Jan, 2014
Reliability
+ Think of a technically challenged person
th
Jan, 2014
Reliability
+ Think of a technically challenged person
o To make it easy, you could think of your Grandma
th
Jan, 2014
Reliability
poor operating environment conditions
often used remotely
complexity
th
Jan, 2014
Reliability
poor operating environment conditions
often used remotely
complexity
Think of cellphones
+ More components = more components that could fail
th
Jan, 2014
Reliability
How to make reliable systems?
reliable system begins at specification and design state
identify all faults before production
Ideal, but not done
+ think of known bugs in released system
th
Jan, 2014
Reliability
In practice, reliability is often described as
meeting performance constraints
th
Jan, 2014
Reliability
MTBF is long
th
Jan, 2014
Reliability
MTBF is long
the system responds in a deterministic way
every time it is used
th
Jan, 2014
Reliability
MTBF is long
the system responds in a deterministic way
every time it is used
graceful & safe failure in response to
unexpected inputs; recovers if possible
th
Jan, 2014
Reliability - definition
What is reliability?
th
Jan, 2014
Reliability means the probability of system failure is less than some
threshold.
th
Jan, 2014
Reliability means the probability of system failure is less than some
threshold.
But Internet is reliable from a users point of view, even
though failure occurs in its individual pieces ( packet
transmission failures)
Why is it so?
th
Jan, 2014
Reliability means the probability of system failure is less than
some threshold.
though failure occurs in its individual pieces ( packet
Why is it so?
+ Fault tolerant/error correction
th
Jan, 2014
Reliability means the probability of system failure is less than
some threshold.
though failure occurs in its individual pieces (packet
Why is it so?
Reliability definition: The probability that a failure is
detected by the user is less than a specified threshold.
th
Jan, 2014
Reliability
Foundations for developing a safe and reliable
embedded system:
understanding system requirements
good specification
well executed design
Comprehensive testing is also equally important.
th
Jan, 2014
Case study
Ariane-5
Designed over 10 yr. period
cost $7 billion
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
Fate of first test flight: Within 40 secs, it was destroyed
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
Reason: assertions turned off; register overflow
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
Guidance system used 16-bit words
Sensors produced 64-bit word data
th
Jan, 2014
Case study 2
Mars Pathfinder
1997
nearly perfect mission
system reset problem in Sojourner rover after a few
days
th
Jan, 2014
Case study 2
Mars Pathfinder
1997
days
Reason: scheduling issue (Priority inversion)
High-priority bus manager task, middle-priority
communication task, low-priority meteorological task
th
Jan, 2014
Summary
Enriching UML models with time and scheduling related
information
Profiles can be used to provide a precise semantics for
real-time and embedded systems
Safety and reliability in embedded systems is very
important
th
Jan, 2014
IS ZC424
Case Study(contd) &
Requirements Analysis of Real-Time Systems
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
th
Jan, 2014
Case study
Ariane-5
cost $7 billion
Guidance system used 16-bit words
Sensors produced 64-bit word data
th
Jan, 2014
Case study 2
Mars Pathfinder
1997
days
th
Jan, 2014
Case study 2
Mars Pathfinder
1997
days
Reason: scheduling issue (Priority inversion)
High-priority bus manager task, middle-priority
communication task, low-priority meteorological task
th
Jan, 2014
Requirement Analysis
th
Jan, 2014
Requirements
Interaction of real-time systems with external environment is
captured by the Use case model as requirements
th
Jan, 2014
Requirements
Use cases are system capabilities; detailed using various UML
elements such as scenarios, statecharts, and text-notes
th
Jan, 2014
Requirements
Use cases are system capabilities; detailed using various UML
elements such as scenarios, statecharts, and text-notes
Specifications of what a system must do; independent of system
design
th
Jan, 2014
Use Cases
Named capability of a structural entity
th
Jan, 2014
Use Cases
Can be applied to any structural entity such as a system,
subsystem, or a class
th
Jan, 2014
Use Cases
A way to capture and model known functional requirements
th
Jan, 2014
Use Cases
A way to capture and model known functional requirements
Define a capability without revealing any particular implementation
th
Jan, 2014
Use Case diagram - example
Use cases exist in a structural context of system
and its associated actors
An actor is an object outside the system that
interacts with it
A capability must be visible to at least one of the
actors to become a use case
th
Jan, 2014
th
Jan, 2014
Use Case Relationships
th
Jan, 2014
Use Case Relationships
th
Jan, 2014
Use Case diagram include, extend
th
Jan, 2014
th
Jan, 2014
Use Case diagram - Example
Older notation -
same as
<<includes>>
Older notation -
same as
<<includes>>
th
Jan, 2014
Restaurant use cases
th
Jan, 2014
th
Jan, 2014
Use Case Relationship- Generalisation
Specialized
use cases
th
Jan, 2014
th
Jan, 2014
th
Jan, 2014
Example: Pacemaker
th
Jan, 2014
Example: Pacemaker
th
Jan, 2014
Example: Pacemaker
th
Jan, 2014
Example: Pacemaker
th
Jan, 2014
SleepyTime Anesthesia system
This system delivers inhalant anesthetic drugs, mixes gases,
delivers gas/drug mixture to the patient via ventilation, scavenges
exhaled CO
2
, and monitors both patient and machine status,
including blood O
2
saturation (SpO
2
), inspiratory limb O
2
concentration, expiratory limb CO
2
concentration, inspiratory limb
agent (drug) concentration, gas flow, and breathing circuit gas
pressures.
th
Jan, 2014
Gas supplies - these may be wall
supplies or tanks but supply medically
certified gases (O
2
, N
2
, N
2
O, He, or Air)
Gas Mixer - formally a part of the
ventilator, this device mixes the input
gases from the gas supplies as directed
and outputs a mixed gas to the
breathing Circuit
Ventilator - this device shapes the
breath delivered to the patient. It's
primary parameters include the
respiration rate (breaths/minute), tidal
volume (volume per breath), I:E ratio
(Inspiration time:Expiration time ratio),
Inspiratory Time (seconds), and an
optional inspiratory pause (delay
between breaths).
Vaporizer - this device vaporizes an
anesthetic drug, such as Suprane,
Halothane, or Enflourane, and delivers
it to the breathing circuit in the
concentration demanded.
th
Jan, 2014
Use Case
th
Jan, 2014
Detailing a Use case
th
Jan, 2014
Use Case what it is NOT!
Is not a single message or event
many textual requirements in a single use case
an event/message such as openGasO2() is not a use case
Is not a low level interface
low level interfaces help in realizing use cases
e.g. if disk is an actor, move head and spin up are interfaces
helping to realize the use case that maybe
Store files
why(yes) vs. how(not)?
Is not a functional decomposition of the system design
provides description of capabilities of the system, not design that can
be implemented (it is in the problem domain)
(Refer Figure 5.15 in the textbook for a bad use case example)
th
Jan, 2014
Bad Use Case Modeling
th
Jan, 2014
A Use Case can have several Requirements
th
Jan, 2014
th
Jan, 2014
Courtesy: Many figures have been taken from various sites on the
Internet
th
Jan, 2014
ISZ C424
Requirements analysis of Real time systems
th
Jan, 2014
Recap
th
Jan, 2014
Recap
Use case diagrams capability
th
Jan, 2014
Recap
Detailing the use case diagrams
th
Jan, 2014
Recap
Detailing the use case diagrams
State charts
Text notes
Sequence diagrams, etc.
th
Jan, 2014
Recap
Lets review a use case diagram from last session.
th
Jan, 2014
th
Jan, 2014
Use Case diagrams
More examples follow
Use-Case Diagrams (POST)
Customer Cashier
Buy Item
Log In
Refund a Purchased Item
POST
Use Case
System Boundary
Adapted from Larman Applying UML and Patterns
POST: Point of Sale Terminal
Salesperson
Trader
Accounting System
Trading Manager
Set Limits
Update Accounts
Analyze Risk
Price Deal
Capture Deal
Limit Exceeded
Valuation
includes
includes
extends
Another Example
Adapted from Fowler UML Distilled
Fuel Valve
90
80
70
60
50
On
Off
Controller
Burner
Water Pump
Hot Water
Fuel
Temp Sensor
Water Valve
Control Panel
Home
The Home Heating System
Temp Sensor
Fuel Valve
90
80
70
60
50
On
Off
Controller
Burner
Water Pump
Hot Water
Fuel
Temp Sensor
Water Valve
Control Panel
Home
Temp Sensor
Fuel Valve
90
80
70
60
50
On
Off
Controller
Burner
Water Pump
Hot Water
Fuel
Temp Sensor
Water Valve
Control Panel
Home
Temp Sensor
Fuel Valve
90
80
70
60
50
On
Off
Controller
Burner
Water Pump
Hot Water
Fuel
Temp Sensor
Water Valve
Control Panel
Home
Temp Sensor
Home Heating Use-Case Diagram
Home Heating Use-Cases
Use case: Power Up
Actors: Home Owner (initiator)
Type: Primary and essential
Description: The Home Owner turns the power on. Each room is temperature
checked. If a room is below the desired temperature the valve for
the room is opened, the water pump started. If the water temp falls
below threshold, the fuel valve is opened, and the burner ignited.
If the temperature in all rooms is above the desired temperature, no
actions are taken.
Modified Home Heating (incorrect)
Home Owner
Power Up
Power Down
Change Temp.
Home Heating
Adjust Temp
Temp. High
Temp. Low
includes
includes
includes
includes
Home Owner
Power Up
Power Down
Change Temp.
Home Heating
Adjust Temp
Temp. High
Temp. Low
includes
includes
includes
includes
th
Jan, 2014
Use Cases
Use case are not themselves requirements
They organize requirements into chunks, based on
the organizational principle of common
operational capability
This principle can be used regardless of the more
detailed representation of the requirements
themselves, whether it is text, sequence diagrams,
state machines, or activity diagrams
th
Jan, 2014
Need for Text
UML provides more formal languages (statecharts,
activity diagrams, and sequence diagrams) for capturing
the details of requirements
Text is still useful in conjunction with these more formal
approaches
Different authors have defined different contents and
formats for such textual characterizations
th
Jan, 2014
An example of Requirements Text
Continued in next slide
th
Jan, 2014
An example of Requirements Text
Continued (scrolled down)two lines overlap
th
Jan, 2014
Identifying Use Cases
Four primary approaches to identifying use cases:
1. List the primary capabilities of the system, then identify the actors
and scenarios within each use case.
2. Identify the actors to the system and the messages they send or
receive (the scenarios), and then group them into use cases.
3. Start with system scenarios, identify the actors that participate in
them, and then lump them into use cases.
4. Identify a system workflow with an activity diagram at the highest
level and from there determine how these might be mapped into
use cases.
th
Jan, 2014
Detailing the Use Cases
A name alone isn't enough to understand
what a use case means. Use case Set
Ventilator Tidal Volume is not clear
th
Jan, 2014
A name alone isn't enough to understand
what a use case means. Use case Set
Ventilator Tidal Volume is not clear
Brief description: the user turns a knob and sets the
amount of mixed breathing gas pumped out per
breath for the ventilator
th
Jan, 2014
Problems of the use case Set Ventilator
Tidal Volume
What is the maximum value that can be selected? What is the
minimum value that can be selected?
th
Jan, 2014
Tidal Volume
What is the accuracy of the delivery of tidal volume with respect to
its set value? +/- 10 ml? +/- 5%?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
Are there different ranges, such as one range for adults, another for
pediatrics, and another for neonates?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
What happens if the knob is turned accidentallydoes tidal volume
change directly or is an explicit confirmation required?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
If there is a confirmation, can the user cancel the operation?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
What happens if the user tries to set a different value, say
respiration rate, before confirmation?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
How does the user know whether a value is currently being set
(waiting for confirmation)?
th
Jan, 2014
Tidal Volume
its set value? +/- 10 ml? +/- 5%?
How does the user know whether a value is currently being set
(waiting for confirmation)?
Does anything have to either precede or come after setting tidal
volume, such as setting patient age or weight?
th
Jan, 2014
Scenarios for Use Cases
A scenario is a particular actor-system
interaction corresponding to a use case
it is a specific example of a use case execution in the
system's operational environment
it models order-dependent message sequences
among object roles collaborating to produce system
behavior in its operational environment
Each use case will have infinite set of scenarios
but it is only necessary to capture the ones that are
interestingly different
th
Jan, 2014
Scenario and States
th
Jan, 2014
Use-case diagrams and description for a Home
Assignment and Collection System
th
Jan, 2014
Home Assignment and Collection System
Homework assignment and collection are an integral part of any
educational system. Today, this task is performed manually. What we want
the homework assignment distribution and collection system (HACS for
short) to do is to automate this process.
HACS will be used by the instructor to distribute the homework
assignments, review the students solutions, distribute suggested solution,
and distribute student grades on each assignment.
HACS shall also help the students by automatically distributing the
assignments to the students, provide a facility where the students can
submit their solutions, remind the students when an assignment is almost
due, remind the students when an assignment is overdue.
1. Draw a use-case diagram of HACS
2. Provide a description of use-case Distribute Assignments
HACS Use-Case Diagram
HACS Use-Cases
Use case: Distribute Assignments
Actors: Instructor (initiator)
Description: The Instructor completes an assignment and submits
it to the system. The instructor will also submit the
due date and the class the assignment is assigned for.
Precondition: Configure HACS must be done before any user
(Instructor or Student) can use HACS
Alternate HACS
Alternate HACS Use-Cases
Use case: Distribute Assignments
Actors: Instructor (initiator), Student
Description: The Instructor completes an assignment and submits
it to the system. The instructor will also submit the
delivery date, due date, and the class the assignment
is assigned for. The system will at the due date mail
the assignment to the student.
Precondition: Configure HACS must be done before any user
(Instructor or Student) can use HACS
th
Jan, 2014
When to use Use-Cases
When to use Use-Cases?
In short, always!
th
Jan, 2014
Requirements is the toughest part of software
development
Use-Cases is a powerful tool to understand
Who your users are (including interacting systems)
What functions the system shall provide
How these functions work at a high level
th
Jan, 2014
Requirements is the toughest part of software
development
Use-Cases is a powerful tool to understand
Who your users are (including interacting systems)
What functions the system shall provide
How these functions work at a high level
Spend adequate time on requirements and in the
elaboration phase
Courtesy: Many figures have been taken from various sites on the Internet.
Thermostat picture in the diagram for Home Heating System is from 1408 (film).
th
Jan, 2014
IS ZC424
Object Domain Analysis
th
Jan, 2014
Recap: Requirement analysis
Use cases capture capabilities
th
Jan, 2014
Recap: We have studied about What
Detailed requirements can be captured in scenarios and other diagrams,
and text
th
Jan, 2014
and text
It tells what system is to be built - its capabilities and required
characteristics
th
Jan, 2014
and text
It tells what system is to be built - its capabilities and required
characteristics
Next step is identifying objects
th
Jan, 2014
How do we build the actual system?
Use cases are realized by collaborations of objects
th
Jan, 2014
How to go from a set of requirements and use cases to a set of objects
th
Jan, 2014
First you have to identify the objects
th
Jan, 2014
First phase is Object analysis
Identify key objects
th
Jan, 2014
Second phase is design (optimization)
th
Jan, 2014
This session deals with the first phase Object analysis
th
Jan, 2014
This session deals with the first phase Object analysis
You identify a small number of objects and
validate each portion of the collaboration before
we move on to the next
th
Jan, 2014
Strategies to identify Objects & Classes
Use case model drives the object model
Each use case will be realized by a set of
objects working together called collaboration
th
Jan, 2014
Use Cases, Collaborations, and Objects
Use case model drives the object
model
Each use case will be realized by
a set of objects working together.
(Collaboration in UML)
A use case at a time
th
Jan, 2014
Make sure each object corresponds to
a Use case
th
Jan, 2014
a Use case
Dont add features not mentioned in
Use case
th
Jan, 2014
a Use case
Use case
Dont ignore requirements as
presented in use case model
th
Jan, 2014
a Use case
Use case
Identify objects for one use case at a
time
th
Jan, 2014
a Use case
Use case
Identify objects for one use case at a
time
Refine system level use cases taking
into account the identified objects
th
Jan, 2014
In this way all the use cases will be
covered by objects
It also illustrates how the requirements
will be met by objects collaborating
together
th
Jan, 2014
Avoid Design at this stage!
Avoid introducing design
th
Jan, 2014
How many threads?
Mutex or spinlocks?
th
Jan, 2014
How many threads?
Mutex or spinlocks?
Concentrate only on the essential
concepts of the use case
Model of underlying application
domain
e.g. users of deliver anesthesia
use case are doctors/nurses.
They dont care about
threads or mutex!
Object domain analysis should
be about application domain
th
Jan, 2014
How many threads?
Mutex or spinlocks?
Concentrate only on the essential
concepts of the use case
Model of underlying application
domain
e.g. users of deliver anesthesia
use case are doctors/nurses.
They dont care about
threads or mutex!
Object domain analysis should
be about application domain
Later, during design phase, we
can refine the domain model into
design model
th
Jan, 2014
Object Discovery Strategies
Potential objects can be identified by the following strategies:
Underline the noun
Identify causal objects
Identify services
Identify messages and information flow
Identify real-world items
Identify physical devices
Identify key concepts
Identify transactions
Identify persistent information
Identify visual elements
Identify control elements
Apply scenarios
th
Jan, 2014
Potential objects can be identified by the following strategies:
Underline the noun
Identify services.
Identify real-world items.
Identify physical devices.
Identify key concepts.
Identify transactions.
Identify persistent information.
Identify visual elements.
Identify control elements.
Apply scenarios
th
Jan, 2014
Underline the noun
A software system must control a set of eight Acme elevators for a building with 20 floors.
Each elevator contains a set of buttons, each corresponding to a desired floor. These are
called floor request buttons, since they indicate a request to go to a specific floor. Each
elevator as well has a current floor indicator above the door. Each floor has two buttons
for requesting elevators called elevator request buttons, because they request an
elevator.
Each floor has a sliding door for each shaft arranged so that two door halves meet in the
center when closed. When the elevator arrives at the floor, the door opens at the same
time the door on the elevator opens. The floor does have both pressure and optical
sensors to prevent closing when an obstacle is between the two door halves. If an
obstruction is detected by either sensor, the door shall open . The door shall
automatically close after a timeout period of 5 seconds after the door opens. The
detection of an obstruction shall restart the door closure time after an obstruction is
removed. There is a speaker on each floor that pings in response to the arrival of an
elevator.
On each floor (except the highest and lowest ), there are two elevator request buttons,
one for UP and one for DOWN. On each floor, above each elevator door, there is an
indicator specifying the floor that the elevator is currently at and another indicator for its
current direction. The system shall respond to an elevator request by sending the nearest
elevator that is either idle or already going in the requested direction. If no elevators are
currently available, the request shall pend until an elevator meets the above-mentioned
criterion. Once pressed, the request buttons are backlit to indicate that a request is
pending. Pressing an elevator request button when a request for that direction is already
pending shall have no effect. When an elevator arrives to handle the request, the
backlight shall be removed. If the button is pressed when an elevator is on the floor to
handle the request (i.e., it is slated to go in the selected direction ), then the door shall
stop closing and the door closure timer shall be reset.
To enhance safety, a cable tension sensor monitors the tension on the cable controlling
the elevator. In the event of a failure in which the measured tension falls below a critical
value, then four external locking clamps connected to running tracks in the shaft stop the
elevator and hold it in place.
th
Jan, 2014
Underline the Noun
Identify potential objects
Objects thus discovered fall into
four categories:
1. Objects of interest or their
classes
2. Actors
3. Uninteresting objects
4. Attributes of objects
elevator.
elevator.
th
Jan, 2014
Underline the Noun
Identify potential objects
Objects thus discovered fall into
four categories:
1. Objects of interest or their
classes
2. Actors
3. Uninteresting objects
4. Attributes of objects
Goal: find objects that fall in
category 1
elevator.
elevator.
th
Jan, 2014
elevator.
elevator.
Object Attribute
Elevator Direction
Status
Location
Button Backlight
Alarm Status
Cable-
tensor-
sensor
Cable tension
Critical
tension
th
Jan, 2014
elevator.
elevator.
Identify Causal Objects
Behaviorally active
Produce or control actions
Produce or analyze data
Provide interfaces to people
or devices
Store information
Provide services to people
or devices
Contain other types of
fundamental objects
th
Jan, 2014
elevator.
elevator.
Identify Causal Objects
Floor
Elevator
Door
Button
Request
Indicator
Cable tension sensor
Mechanical locking clamp
th
Jan, 2014
elevator.
elevator.
Identify passive objects
Less obvious than causal objects
May provide passive control, data
storage, or both
Provides a service to the causal
objects
Does not initiate actions by itself
Also known as servers because
they provide services to client
objects
e.g. switch in elevator to turn on fan,
or a simple sensor
th
Jan, 2014
Identify messages and Information flows
For each message, there is an object that sends it, an object that receives it, and
potentially , another object that processes it
Messages are the realization of information flows
Information flows are drawn on class diagrams
These will become associations among the classes of those objects
th
Jan, 2014
Identify Real-World Items
Embedded systems need to model the
information or behavior of real-world objects
even though they are not part of the system.
Ex: an anesthesia system must model the
relevant properties of patients. such as
Name
Social Security number
Address
Phone number
Insurance reference
Weight
Sex
Height
th
Jan, 2014
Identify Physical Devices
Real-time systems interact with their
environment using sensors and actuators in a
hardware domain
The system controls and monitors these
physical devices
These are modeled as objects
Device information and state must be
maintained through object attributes and
operations
Example: Stepper motor
Attributes: Position
Operations: Step, Get position, Zero
th
Jan, 2014
Identify Key Concepts
Key concepts are important abstractions within
the domain that have interesting attributes and
behaviors
They are modeled by the system
They have no physical manifestation
Example:
Account in banking application
Window in user interface
th
Jan, 2014
Identify Transactions
Transactions are objects that must persist for
a finite period of time and that represent the
interactions of other objects
Object 1 Object 2 Association Transaction
Controller Actuator Controls Control message over bus
Alarming Class Alarm Manager Issues alarms Silence Alarm
Customer Store Buys things at Order Return
Display System Sensor Displays values for Alarm Error
Elevator Request
Button
Elevator Issues request to Request for elevator
Floor Request Button Elevator Issues request to Request for floor
Task Plan Robot Arm Controls Command
th
Jan, 2014
Identify Persistent Information
Typically held within passive objects
Either volatile memory (RAM or
SRAM) or long-term storage (FLASH,
EPROM, ..or disk) may store persistent
data
Example:
Task plan for a robot
Security access database for entry into a
place
th
Jan, 2014
Identify Visual Elements
Common visual elements:
Window
Rectangle
Rounded panel
Horizontal scroll bar
Scroll button (left, right, up, down)
Button
Menu bar
Menu selection
Drop-down menu
Menu item
List box
Text
Icon (for alarm silence)
th
Jan, 2014
Identify Control Elements
Control elements are entities that control other
objects
Orchestrate the behaviors of their part objects
Some control elements are physical interface
devices
Button
Switch
Keyboard for central station
th
Jan, 2014
Apply Scenarios
Application of use case scenarios is another
strategy to identify missing objects.
Refine the use case scenario from identified
objects.
th
Jan, 2014
Identify object associations
Objects never live alone
Objects send messages to other objects and
every message implies an association
Some techniques:
Identify messages
Identify message sources
Identify message storage depots
Identify message handlers
Identify whole/part structures
Identify more/less abstract structures
Apply scenarios
th
Jan, 2014
Object attributes
A named property
of a type
Primitive attributes
Have primitive
structure
Modeling non-
primitive attributes
Modeling non-primitive attributes
th
Jan, 2014
Object attributes
A named property
of a type
Primitive attributes
Have primitive
structure
Modeling non-
primitive attributes
Modeling non-primitive attributes
th
Jan, 2014
Object attributes
Sometimes the primary attributes of an object
are not obvious
To identify the primary attributes, some key
questions may be asked, such as:
What information defines the object?
On what information do the object's operations act?
What does the object know?
Are the identified attributes rich in either structure or
behavior? (If so, they are probably objects in their
own right rather than simple attributes.)
What are the responsibilities of the object? What
information is necessary to fulfill these
th
Jan, 2014
Object attributes
Let's ask these questions about the elevator:
th
Jan, 2014
Object attributes
th
Jan, 2014
Object attributes
The Elevator is a physical thing that must be
controlled. To fulfill its function it must know where it
is, where it is going (destination list), its current
direction, its operational status, and its error history.
th
Jan, 2014
Object attributes
On what information do the object's operations
act?
th
Jan, 2014
Object attributes
act?
It has a goto() operation, which must act on where it
is, its current direction, and its state (moving, stopped
, etc.).
th
Jan, 2014
Object attributes
act?
, etc.).
th
Jan, 2014
Object attributes
act?
, etc.).
It knows where it is, where it is going, and what it is
doing right now.
th
Jan, 2014
Object attributes
act?
, etc.).
doing right now.
th
Jan, 2014
Object attributes
act?
, etc.).
doing right now.
th
Jan, 2014
Object attributes
act?
, etc.).
doing right now.
th
Jan, 2014
Object attributes
act?
, etc.).
doing right now.
th
Jan, 2014
Discovering Candidate Classes
Many of the identified objects are structurally
identical
Classes are abstractions of objects
Objects that are identical in type are abstracted
into a class
th
Jan, 2014
Class Diagrams
Primary road map of the system and its object
oriented decomposition
Need criteria for dividing up their class
structures into different diagrams that make the
system understandable
Class diagram:
Show the parts within a structured class
Component diagram:
Show the architectural elements within a system and
how they relate.
Deployment diagram:
Show how the architectural or collaborating elements
distribute across multiple address spaces
th
Jan, 2014
Associative Classes
An associative class
is used when
information does not
seem to belong to
either object in the
association or
belongs to both
equally
Ex: Marriage is an
association between
two people objects.
Attributes of marriage
(association class)
Date of marriage
th
Jan, 2014
Identify Generalization
Class higher in the taxonomic
hierarchy is parent/base/superclass
To be specialized along the lines of
behavior or structure
Subclass is free to both specialize
and extend the inherited properties
Specialization means that the
subclass may polymorphically
redefine an operation
Extension means that the subclass
may add new attributes, operations,
associations, and so on
th
Jan, 2014
Identify generalization..
Constructing generalization hierarchies can be from the leaves of the inheritance
tree
Examine siblings subclassed from the same parent attributes and behaviors in
common
If all siblings have the same property, it belongs to the parent.
If the characteristic is common to some, but not all of the siblings, then it may
indicate a class is needed between the parent and the similar siblings
th
Jan, 2014
Identify generalization..
Constructing generalization hierarchies can be from the leaves of the inheritance
tree
Examine siblings subclassed from the same parent attributes and behaviors in
common
If all siblings have the same property, it belongs to the parent.
If the characteristic is common to some, but not all of the siblings, then it may
indicate a class is needed between the parent and the similar siblings
th
Jan, 2014
Summary
Discussed strategies to identify objects, classes,
and relationships
Underlining the nouns, identifying the physical
devices, looking for persistent data, and so on...
Collaboration of objects through relationships
among classes
th
Jan, 2014
IS ZC424
Examples
th
Jan, 2014
Example 1
We wish to implement a Finite State Machine (FSM) that recognizes two
specific sequences of applied input symbols, namely four consecutive 1s or
four consecutive 0s. There is an input w and an output z. Whenever w=1 or
w=1 for four consecutive clock pulses (sensed at raising edge) the value of z
has to be 1; otherwise, z = 0. Overlapping sequences are allowed, so that if
w=1 for five consecutive clock pulses the output z will be equal to 1 after the
fourth and fifth pulses.
th
Jan, 2014
Example 1
We wish to implement a Finite State Machine (FSM) that recognizes two
specific sequences of applied input symbols, namely four consecutive 1s or
four consecutive 0s. There is an input w and an output z. Whenever w=1 or
w=1 for four consecutive clock pulses (sensed at raising edge) the value of z
has to be 1; otherwise, z = 0. Overlapping sequences are allowed, so that if
w=1 for five consecutive clock pulses the output z will be equal to 1 after the
fourth and fifth pulses.
Represent the state machine as a state diagram.
th
Jan, 2014
Solution 1
th
Jan, 2014
Example 2
A normal PC keyboard can be used to type either in Lower case or Upper
case. By default it is in lower case typing mode. There is a Caps Lock key on
the keyboard to toggle between the two modes. Draw state diagram showing
states of a keyboard and transitions between lower and upper case modes.
th
Jan, 2014
Solution 2
th
Jan, 2014
Example 3
Now, suppose the keyboard has an additional mode that can be entered by
pressing a Num Lock key. This mode enables the numeric keypad on the
keyboard to become active. The Caps Lock and Num Lock modes run
simultaneously. Add state NumLock On and Off to the Statechart using
regions.
th
Jan, 2014
Solution 3
Now, suppose the keyboard has an additional mode that can be entered by
pressing a Num Lock key. This mode enables the numeric keypad on the
keyboard to become active. The Caps Lock and Num Lock modes run
simultaneously. Add state NumLock On and Off to the Statechart using
regions.
th
Jan, 2014
Example 4
A system has to be designed to monitor the temperatures of an industrial
process. Detailed specifications are as below:
The temperature sensors (TS) are intelligent devices installed close to the
physical location of each process.
Each TS reads the temperature at set sampling rate (Each TS has its own
rate) and sends data to processing station (PS) serially. There is no
acknowledgement from PS for each data sent.
PS sends control messages serially to the TS when ever its operating
parameters have to be set.
The only operating parameter of the TS to be set is the sampling rate.
PS reads the serial data from each TS and computes the average of last 100
samples for each TS.
PS monitors the upper limits for each TS and raises an alarm, if high. The alarm
has to be reset by the operator by pressing a push button switch.
Assume there is no other user interface except a push button switch to reset the
alarm.
The number of TS can be any arbitrary value.
All the activities go concurrently in real time.
th
Jan, 2014
Example 4 ..
Questions:
1. Draw use cases from above description of the problem and represent
diagrammatically.
2. Show the sequence diagram of a scenario when an alarm is raised.
th
Jan, 2014
Solution 4(1)
uc Use Case Model
TS
Sense temprature
periodically
Send data to PS
PS
Send control
messages to TS
Receive data from TS
stations
Compute history and
raise alaram
Operator
Reset Alaram
th
Jan, 2014
Solution 4(2)
sd Interaction
Operator
Al aramProcessor Control l er Hi story Processor TS
SendSampl e()
:l ong
Readsampl e() :l ong
Transmi t()
EvdataRecei ved()
ReadDatafromTS(l ong) :l ong
StoreSampl e(l ong)
ComputeAverage() :l ong
Rai seAl aram()
ResetAl aram()
th
Jan, 2014
Problem 5
Below is the interface of an electronic voting machine (EVM).
The EVM has 5 buttons and 4 LEDs to glow.
When the system resets or is ready to accept a vote, the Place thumb here
LED glows.
Voter has to press it for minimum 5 seconds.
EVM senses and analyses the finger print and generates a 16 bit signature.
Processor compares it with internal data . If the signature is valid and the person
has not yet voted , the next light select one from right glows.
Voter has to press one of C1 to C4 for 5 seconds.
If it is valid, Done! lamp glows for 15 seconds and voter selection is registered.
System goes back to ready state again.
Invalid button glows when the signature could not be generated or buttons are
pressed for shorter duration or for any abnormal operation. System resets back
to acceptance state after Invalid is on for 15 seconds.
C1
C3
C3
C4
Place thumb
here
Select one
from right Done!
Invalid!
1. Create a top level state chart for the
EVM.
2. Expand Thumb processing state into
its own statechart.
th
Jan, 2014
Solution 5(1)
stm Domain Model
Ini ti al
Accept thumb
Thumb processing
candidate select
Invalid
display operation
completed
Thumb pl aced
[val i d si gnature]
[Inval i d]
[Inval i d]
[Ti meOut]
[Val i d sel ecti on]
[ti meout]
th
Jan, 2014
Solution 5(2)
stm StateMachine
Thumb
processi ng
Thumb placed
processing
signature verification
Invalid
Valid
thumb pl aced
Image acqui red
i gnature acqui red
Thumb removed
Processi ng faul t
Inval i d si gnature
Val i d si gnature
th
Jan, 2014
Problem 6
An Internet-TV broadcasting system has three kind of users - visitor/guest user,
general members and premium members. A guest can register to take membership
and a general member can upgrade to premier membership. Premier members can
watch live TV, participate in discussion & subscribe to newsletter, while general
members can only watch archived programs. The administrator is responsible for
updating timetable, uploading & archiving TV programs, and delivering newsletters.
Draw Use case diagram for such broadcasting system.
th
Jan, 2014
Solution 6
th
Jan, 2014
Problem 7
A hand held digital sound recorder is a consumer electronic appliance designed to record
and play back speech. The messages are recorded using a built-in microphone and they
are stored in a digital memory. The user can quickly play back any message at any
moment trough a speaker placed in the front of the device. It should be small, light, easy
to use, and battery operated. The main requirements are:
The main features of the product that we are going to consider in our design are:
Capacity for ten different messages. The length of each message is limited by the
available memory.
Easy to use with on screen menus.
Direct access to any message.
Alarm clock. The user can set a daily alarm. The alarm beeps until the user presses a
key, or after 60 seconds.
Full Function LCD Display. The current date and time is always shown in the display.
The display also shows clear directions about how to use it and what it is doing.
Battery-level indicator. The system beeps when the battery is low.
Stand-by mode. It saves the battery power. The system switches off the peripherals
when they are not in use. The normal operation is resumed when the user presses a key.
Good sound quality. Sound is processed at 6Khz using eight bits per sample.
th
Jan, 2014
Problem 7a
Here is how it looks like:
Draw the use case diagram of the sound recorder.
th
Jan, 2014
Solution 7a
th
Jan, 2014
Solution 7b
Draw a scenario when the user plays message and stops the
recorder after playing the message for a while.
th
Jan, 2014
Solution 7b
th
Jan, 2014
Solution 7c
Draw a scenario when the alarm sounds while the recorder is
playing message. Here, alarm has higher priority.
th
Jan, 2014
Solution 7c
th
Jan, 2014
Solution 7d
Draw a scenario when the recorder goes to stand-by mode after
a duration of inactivity, and wakes up by alarm but soon goes to
stand-by while sounding alarm as the battery becomes low.
th
Jan, 2014
Solution 7d
th
Jan, 2014
IS ZC424
Lecture 10
Analysis: Defining Object Behavior
th
Jan, 2014
In previous sessions, we studied about identifying objects
and their relationships:
Underline the noun
Identify services.
Identify real-world items.
Identify physical devices.
Identify key concepts.
Identify transactions.
Identify persistent information.
Identify visual elements.
Identify control elements.
Apply scenarios
th
Jan, 2014
Identifying objects
Identify object associations & attributes
Discover candidate classes for similar objects
Identify associative classes & generalization
among classes
th
Jan, 2014
Dynamic Behaviour
Next step is to specify dynamic behaviour
It binds structure of objects to their attributes and relationships
Operations in object specify its behaviour
Finite state diagrams are used to define the object behaviour
Other important means are sequence diagrams
th
Jan, 2014
Behaviour types
Main type of behaviors we study fall into these types:
Simple behavior
Performs services on request
No memory of previous services
Response to a given input is always same
E.g. mathematical functions, search operation on
static data structures like arrays
State behavior
Also called reactive behaviour
Finite existence conditions, called state
System behaviour within a state is identical
System changes state in well defined ways
(transitions)
th
Jan, 2014
Simple Behavior (Computing Net Worth)
th
Jan, 2014
Defining Object State Behaviour
Example 1: Simple, retriggerable, one-shot timer
Two Possible states: idle and counting
On timeout, issue an event to client object, reset
implicitly, and return to counting down state
th
Jan, 2014
th
Jan, 2014
th
Jan, 2014
Example 2: Communicating objects can send/receive messages; they
know how to construct/extract messages to send/receive
Communicator class can actually send/receive
messages; is associated with communicating object
For reliable message send event, a temporary
transaction object is created; it exists until the
message receipt is verified by the receiver
th
Jan, 2014
Example 2: Communicating objects can send/receive messages; they
know how to construct/extract messages to send/receive
Communicator class can actually send/receive
messages; is associated with communicating object
For reliable message send event, a temporary
transaction object is created; it exists until the
message receipt is verified by the receiver
th
Jan, 2014
Message transaction
Example 2: (contd..) transactional object behavior statechart
th
Jan, 2014
Calculator
Example 3: Calculator
th
Jan, 2014
Example 3: Calculator classes
th
Jan, 2014
CharParser:
Takes the input string and reads out a character at a time,
identifies the type of the character (number, operator, or white
space), then sends an appropriate event (along with the
character) to the Tokenizer.
th
Jan, 2014
Character parser
th
Jan, 2014
Tokenizer
Tokenizer:
Takes the input characters and constructs tokenseither operators or
numbersto be evaluated. Once a token is parsed, the token is sent
to the Evaluator for evaluation.
th
Jan, 2014
Tokenizer
th
Jan, 2014
Example 4: Microwave Oven
In cooking mode, the user may (optionally) set
the power level, and (must) set the cooking
time.
The oven turns on the light, fan, and rotisserie
motor and cooks the food for the specified
period of time
Power level is implemented by cycling the
microwave emitter on and off. Power level 10
means that the emitter is on all the time, while
power level one means that the emitter is on
1/10 of the time. If not set, the default power
level is 10 in cooking mode
th
Jan, 2014
Cooking Engine statechart
th
Jan, 2014
Emitter statechart
th
Jan, 2014
Cook Timer statechart
th
Jan, 2014
Door Sensor statechart
th
Jan, 2014
Event Hierarchies
Some events may be specialized versions of other
events, it is possible to build event-class
generalization hierarchies
th
Jan, 2014
Event Hierarchies
They allow polymorphic event receptions; different
objects (or states within the same object) can
accept events at different levels in the hierarchy
th
Jan, 2014
Event Hierarchies
th
Jan, 2014
Event Hierarchies
th
Jan, 2014
IS ZC424
Object behavioral analysis
(Contd...)
th
Jan, 2014
Door Sensor statechart
th
Jan, 2014
Event Hierarchies
Some events may be specialized versions of other events, it is possible to build
event-class generalization hierarchies
th
Jan, 2014
Event Hierarchies
They allow polymorphic event receptions; different objects (or states within the
same object) can accept events at different levels in the hierarchy
th
Jan, 2014
Event Hierarchies
th
Jan, 2014
Event Hierarchies
th
Jan, 2014
Calculator example cont
CharParser
Tokenizer
Evaluator
th
Jan, 2014
CharParser sends typed characters one at a
time to Tokenizer
boolean isDigit(char c) {
return (c>='0' && c<='9');
}
boolean isDot(char c) {
return c == '.';
}
boolean isOp(char c) {
return (c=='-' || c=='+' || c=='*' || c=='/' || c == '^' || c == '(' || c == ')');
}
boolean isWhiteSpace(char c) {
return (c==' ' || c== '/t');
}
CharParser
th
Jan, 2014
CharParser Statechart
th
Jan, 2014
Tokenizer constructs arithmetic tokens
Tokenizer
th
Jan, 2014
Tokenizer Statechart
th
Jan, 2014
Evaluator gets tokens from Tokenizer
Tokens operators (+, -, /, *), numbers, EOS
Expressions that can be evaluated
[signed number operator signed number]+
Following are valid expressions
-16
+8-45/89+19-1
Whitespace is discarded by Tokenizer
How Evaluator works
th
Jan, 2014
Evaluator
th
Jan, 2014
Evaluator
th
Jan, 2014
Evaluate -2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
Operator stack Number stack
th
Jan, 2014
Evaluate -2+3+(4*5+6)
Operator stack Number stack
th
Jan, 2014
Evaluate -2+3+(4*5+6)
-
-2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
- 2
-2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
void Evaluator::reduceUnary() {
char opToApply;
double num;
OMBoolean done = FALSE;
// reduce all leading signs as in
// 1 - - - - - -6 to 1 + 6
while (!done) {
if (itsOperatorStack->getTop()>0) {
if (itsOperatorStack->elementAtTop() == '#') {
opToApply = itsOperatorStack->pop();
num = itsNumberStack->pop();
result = -num;
itsNumberStack->push(result);
} // end if
else
done = TRUE;
} // end if
else
done = TRUE;
} // end while
}
th
Jan, 2014
Evaluate -2+3+(4*5+6)
-2
-2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
-2
-2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
void Evaluator::reduce() {
boolean done = FALSE;
while (!done) {
if (itsNumberStack->getTopOfStack()>1)
if ((ch = itsOperatorStack->elementAtTop()) != '( && ch != NULL) reduceFactor();
else done = TRUE; // done if left parenthesis
else
done = TRUE; // done if no numbers are left or no operator on stack
} // end while
}
void Evaluator::reduceFactor() {
char opToApply;
double num1,num2;
if (itsOperatorStack->elementAtTop() != '(') {
opToApply = itsOperatorStack->pop();
num1 = itsNumberStack->pop();
num2 = itsNumberStack->pop();
switch (opToApply) {
case '+': result = num1 + num2; break;
case '-': result = num2 - num1; break;
case '/': if (num1 == 0) throw "Divide by Zero"; else result = num2 / num1; break;
case '*': result = num2 * num1; break;
case '(': throw "Unmatched Left Parenthesis";
case ')': throw "Parsing Error: Found Right Parenthesis";
}
itsNumberStack->push(result); };
}
}
th
Jan, 2014
Evaluate -2+3+(4*5+6)
-2
-2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
3
-2
-2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
3
-2
-2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
3
-2
-2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
1 -2+3+(4*5+6)
th
Jan, 2014
Evaluate -2+3+(4*5+6)
1 -2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
1 -2+3+(4*5+6) +
th
Jan, 2014
Evaluate -2+3+(4*5+6)
1 -2+3+(4*5+6)
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
1 -2+3+(4*5+6)
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
4
1
-2+3+(4*5+6)
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
4
1
-2+3+(4*5+6)
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
4
1
-2+3+(4*5+6)
*
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
4
1
-2+3+(4*5+6)
*
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
5
4
1
-2+3+(4*5+6)
*
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
20
1
-2+3+(4*5+6) (
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
20
1
-2+3+(4*5+6) (
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
20
1
-2+3+(4*5+6) (
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
20
1
-2+3+(4*5+6)
+
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
20
1
-2+3+(4*5+6)
+
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
6
20
1
-2+3+(4*5+6)
+
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
6
20
1
-2+3+(4*5+6)
+
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
void Evaluator::reduceSubExpr() {
char op;
boolean done = FALSE; // reduce stack until left parenthesis found
while (!done) {
if (itsOperatorStack->getTopOfStack()>0) {
op=itsOperatorStack->elementAtTop();
switch (op) {
case '#': reduceUnary(); break;
case '(': op = itsOperatorStack->pop(); done = TRUE; break;
case '+':
case '-':
case '*':
case '/': reduceFactor(); break;
}
} else { // didn't find matching left parenthesis
throw "Unmatched Right parenthesis"; };
} //endif
} //end while
th
Jan, 2014
Evaluate -2+3+(4*5+6)
6
20
1
-2+3+(4*5+6)
+
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
26
1
-2+3+(4*5+6)
(
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
26
1
-2+3+(4*5+6)
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
26
1
-2+3+(4*5+6)
+
th
Jan, 2014
Evaluate -2+3+(4*5+6)
27
-2+3+(4*5+6)
th
Jan, 2014
Evaluate *2+3 (Incorrect
expression)
*2+3
th
Jan, 2014
Evaluate *2+3
*2+3
th
Jan, 2014
Evaluate 2+*3(Incorrect
expression)
2+*3
th
Jan, 2014
Evaluate 2+*3
2+*3 2
th
Jan, 2014
Evaluate 2+*3
2+*3 2
th
Jan, 2014
Evaluate 2+*3
2+*3 2 +
th
Jan, 2014
Evaluate 2+*3
2+*3 2 +
th
Jan, 2014
Evaluate 2+*3
2+*3 2 +
th
Jan, 2014
Evaluate 2+*3
2+*3 2 +
th
Jan, 2014
Evaluate 2+-3
2+-3
th
Jan, 2014
Evaluate 2+-3
2+-3
th
Jan, 2014
Evaluate 2+-3
2+-3 2
th
Jan, 2014
Evaluate 2+-3
2+-3 2 +
th
Jan, 2014
Evaluate 2+-3
2+-3 2 +
th
Jan, 2014
Evaluate 2+-3
2+-3 2 -
+
th
Jan, 2014
Evaluate 2+-3
2+-3 2 -
+
th
Jan, 2014
Evaluate 2+-3
2+-3 3
2
-
+
th
Jan, 2014
Evaluate 2+-3
2+-3 -3
2
+
th
Jan, 2014
Evaluate 2+-3
2+-3 -3
2
+
th
Jan, 2014
Evaluate 2+-3
2+-3 -3
2
+
th
Jan, 2014
Evaluate 2+-3
2+-3 -1
th
Jan, 2014
Evaluate 2+-3
2+-3 -1
th
Jan, 2014
Evaluate (2)
(2)
th
Jan, 2014
Evaluate (2)
(2)
(
th
Jan, 2014
Evaluate (2)
(2) ( 2
th
Jan, 2014
Evaluate (2)
(2) ( 2
th
Jan, 2014
Evaluate (2)
(2) ( 2
th
Jan, 2014
Evaluate (2)
(2) 2
th
Jan, 2014
Evaluate (2)
(2) 2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
(
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) ( 2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) ( 2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) +
(
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) +
(
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) +
(
3
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5) +
(
3
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
*
+
(
3
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
*
+
(
3
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
*
+
(
5
3
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
+
(
15
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
+
(
15
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
+
(
15
2
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
(
17
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
17
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
17
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
17
th
Jan, 2014
Evaluate (2+3*5)
(2+3*5)
17
th
Jan, 2014
Scenarios
Statecharts vs. Scenarios
Statecharts are constructive
can be used to fully generate code as the entire state space
of a system is provided
Scenarios are semi-constructive
They provide typical paths through the state space as the
system is used
They can add operations and event handling to a state
model
Diagrams for scenarios
Sequence diagrams
Timing diagrams
th
Jan, 2014
Calculator scenario 2*(3+4)
th
Jan, 2014
th
Jan, 2014
th
Jan, 2014
th
Jan, 2014
th
Jan, 2014
Coming up next:
Design
Architectural
Mechanistic
Detailed
th
Jan, 2014
IS ZC424
Lecture 12
th
Jan, 2014
Scheduling Algorithms
Clock driven scheduling
Cyclic scheduler
Priority driven scheduling
Rate Monotonic (RM)
Deadline Monotonic (DM)
th
Jan, 2014
Cyclic Scheduler
Store pre-computed schedule as table
Each entry (t
k
, T(t
k
)) in table gives a decision
time t
k
at which a scheduling decision is
made
T(t
k
) can either be a task whose jobs should
start at t
k,
or I (idle, no periodic task
scheduled)
Idle time can be used for aperiodic jobs
th
Jan, 2014
T1 = (4,1), T2 = (5, 1.8), T3 = (20, 1), T4 = (20, 2)
Cyclic Scheduler
th
Jan, 2014
Input: Stored schedule (t
k
, T(t
k
)) for k = 0, 1, N-1.
Task SCHEDULER:
set the next decision point i and table entry k to 0;
set the timer to expire at t
k
;
DO forever;
accept timer interrupt;
if an aperiodic job is executing, preempt the job;
current task T = T(t
k
); increment i by 1;
compute the next table entry k = i mod N;
set the timer to expire at i/N*H + t
k
;
if the current task T is I
let the job at the head of the aperiodic job queue to run;
else, let the task T execute;
sleep;
end DO
End SCHEDULER
Cyclic Scheduler - Algorithm
th
Jan, 2014
Rate Monotonic (RM) Algorithm
Most used and studied fixed-priority algorithm
Priority of tasks is assigned based on their
periods
The shorter the period the higher the priority
Rate is inverse of period
Algorithm is called Rate-Monotonic (RM)
algorithm and a schedule produced by the
algorithm is Rate-Monotonic schedule
th
Jan, 2014
Example Rate Monotonic
Algorithm
Three tasks T
1
= (4, 1), T
2
= (5, 2), T
3
= (20,
5)
Priorities: T
1
> T
2
> T
3
Hyperperiod: 20
th
Jan, 2014
Deadline Monotonic (DM)
Algorithm
Another well-known fixed-priority algorithm
Tasks are assigned priorities according to their
relative deadline
Shortest relative deadline has highest priority
th
Jan, 2014
Example - Deadline Monotonic
Algorithm
Three tasks where T
i
= (
i
, p
i
, e
i
, D
i
)
T
1
= (50, 50, 25, 100)
T
2
= (0, 62.5, 10, 20)
T
3
= (0, 125, 25, 50)
Priorities: T
2
> T
3
> T
1
(Relative Deadline)
LCM of periods = 250 (=Hyperperiod)
th
Jan, 2014
Example Deadline Monotonic
Algorithm
T
1
= (50, 50, 25, 100)
T
2
= (0, 62.5, 10, 20)
T
3
= (0, 125, 25, 50)
Priorities: T
2
> T
3
> T
1
(Relative Deadline)
th
Jan, 2014
Example Rate Monotonic
Algorithm
T
1
= (50, 50, 25, 100)
T
2
= (0, 62.5, 10, 20)
T
3
= (0, 125, 25, 50)
Priorities: T
1
> T
2
> T
3
(inverse of Period)
th
Jan, 2014
RM vs. DM
If relative deadline of every task is proportional
to its period, RM and DM algorithm are identical
When relative deadlines are arbitrary, DM may
produce a feasible schedule when RM fails, but
not vice versa
th
Jan, 2014
th
Jan, 2014
Analysis looks at key concepts and structures in
the system
Design
th
Jan, 2014
the system
Analysis is independent of how the solution is
implemented
Design
th
Jan, 2014
the system
implemented
Design specifies a particular solution
Design
th
Jan, 2014
the system
implemented
Design specifies a particular solution
Based on the analysis model in a way that
optimizes the system
Design
th
Jan, 2014
Three main categories of design
Architectural
Mechanistic
Detailed
Design
th
Jan, 2014
Three levels of design
th
Jan, 2014
Design phases
Process Step Purpose Generated
Artifacts
Architectural
Design
Details the largest software
structures, such as
subsystems, packages, and
tasks.
Subsystem model
Concurrency model
Distribution model
Safety/reliability model
Deployment model
Mechanistic
Design
Includes classes working
together to achieve common
goals.
Collaboration
model
Detailed Design Specifies the internal
primitive data structures and
algorithms within individual
classes.
Class details
th
Jan, 2014
Scope
Design phase Scope What is specified?
Architectural System-wide Subsystems and components
Processor-wide Concurrency and resource
management
Distribution across multiple
address spaces
Safety and reliability
management
Deployment of software onto
hardware elements
th
Jan, 2014
What is architectural design?
th
Jan, 2014
What is architectural design?
Architectural design identifies the key
strategies for the large-scale organization of
the system under development
th
Jan, 2014
Five important views of architecture are
subsystem and component
concurrency and resource
distribution
safety and reliability
deployment
Views of Architecture
th
Jan, 2014
Two fundamental kinds of architecture:
Logical: organization of things that exist only
at design time i.e. the organization of classes
and data types
Physical: organization of the system at
runtime
th
Jan, 2014
th
Jan, 2014
Logical architecture can be organized based on the
concept of domains
A domain is an independent subject area that
generally has its own vocabulary
Domains provide a means by which model can be organized or
partitioned into its various subjects, such as User Interface,
Hardware, Alarm Management, Communications, Operating
System, Data Management, Medical Diagnostics, Guidance and
Navigation, Avionics, Image Reconstruction, Task Planning, and
so on.
Logical Architecture
th
Jan, 2014
A domain is represented as a domain stereotyped
package that includes a mission, specifically "hold
classes and types around the common subject matter
Domain does not dictate how objects will be organized
and deployed at runtime
Logical Architecture
th
Jan, 2014
Domain diagram example
th
Jan, 2014
Is concerned with the organization of things that
exist at runtime
Typical elements are subsystems, components,
channels etc
Domain structure usually does not completely
reflect the physical architecture (next slide)
Physical architecture
th
Jan, 2014
Domain structure usually does not completely reflect the physical
architecture. Example: Power Subsystem is constructed from instances of
the classes defined in different domains
th
Jan, 2014
Physical architecture refers to the large-scale
organization elements
th
Jan, 2014
These large-scale organizational elements don't do
much, in and of themselves
th
Jan, 2014
They organize the more primitive instances that do the
real work
th
Jan, 2014
real work
th
Jan, 2014
real work
They provide management oversight and delegation of
requests and messages to the appropriate objects
th
Jan, 2014
real work
They allow us to view and understand the system at
different levels of abstraction
crucial for the construction and understanding of large complex
systems
th
Jan, 2014
real work
systems
We need to look at assemblies of parts and refer to
them as a single, albeit more abstract, element
th
Jan, 2014
Thank You!
IS ZC424
Lecture 13
th
Jan, 2014
organization elements at runtime
real work
systems
We need to look at assemblies of parts and refer to
them as a single, albeit more abstract, element
th
Jan, 2014
Levels of architectural
abstraction
Complete system
Mars Return Mission
th
Jan, 2014
abstraction
Complete system
Systems engineering
Mars Return Mission
Attitude control subsystem
th
Jan, 2014
abstraction
Complete system
Systems engineering
Engg. disciplines
Mars Return Mission
Processors, relays, s/w
th
Jan, 2014
abstraction
Complete system
Systems engineering
Engg. disciplines
Architectural units
Mars Return Mission
Math library, TCP stack,
fuel management
component
th
Jan, 2014
abstraction
Complete system
Systems engineering
Engg. disciplines
Architectural units
Concurrency
Math library, TCP stack,
fuel management
component
Design-level active objects,
process, threads
Mars Return Mission
th
Jan, 2014
Focus on independent aspects of the large-scale
runtime structure of a single system
Subset of the system model to allow a keener
examination of some particular aspect
Looks at related parts of the single model
Do not conflict with one another
Views of architecture
th
Jan, 2014
Views capture structural aspects
Captured with
Class Diagrams
Package Diagrams
Subsystem Diagrams
Task Diagrams
Deployment Diagrams
Views of architecture
th
Jan, 2014
Subsystem and component
Concurrency and resource
Distribution
Deployment
Five Views of architecture
th
Jan, 2014
Concurrency and resource
Distribution
Deployment
th
Jan, 2014
A component is the basic reusable element of
software
organizes objects together into cohesive run-time units that
are replaced together
A subsystem is a large object that achieves its
functionality through delegation to objects that it owns
internally
contains components and objects on the basis of common
run-time functional purpose
th
Jan, 2014
System
th
Jan, 2014
System
th
Jan, 2014
Component diagram of display Subsystem
th
Jan, 2014
Distribution
Distribution model refers to how objects in different
address spaces find and collaborate with each other
Policies for objects communication among multiple
processors and communication links, e.g.
Asymmetric distribution (dedicated links to objects with a priori
known location)
Policies for managing communication links
Communication protocols
Communication quality of service management
th
Jan, 2014
Broker architecture in
distribution view
th
Jan, 2014
Safety and reliability model refers to the structures and
policies in place to ensure
Safety
Freedom from accidents or losses
Reliability
High Mean Time Between Failure(MTBF)
Fault tolerance
Safety and reliability view examines how system
redundancy is defined and managed
th
Jan, 2014
Two Radars Safety and
Reliability View
th
Jan, 2014
Two Radars Safety and Reliability View
th
Jan, 2014
Redundancy Key to safety and reliability
th
Jan, 2014
Concurrency view
Refers to:
Identification of task threads and their properties
Mapping of passive classes to task threads
Identification of synchronization policies
Task scheduling policies
Unit of concurrency in UML is the active object
active objects are added in architectural design to organize
passive objects into threads
active objects contain passive semantic objects via
composition and delegate asynchronous messages to them
th
Jan, 2014
Concurrency model using Task
diagram
th
Jan, 2014
Concurrency model using Task
diagram
th
Jan, 2014
Deployment
Maps software components and subsystems to
hardware
Represents a device as a node
Iconic stereotypes are common
Identifies physical connections among devices
May be buses, networks, serial lines, etc.
th
Jan, 2014
Deployment
th
Jan, 2014
Thank You!
IS ZC424
Mechanistic Design
th
Jan, 2014
Mechanistic Design
Medium Level Design
Deals with how collaborations can be optimized
Organized around discovery and use of patterns
of object collaboration
th
Jan, 2014
Mechanistic Design
Design patterns:
Solutions to structurally similar problems
Simplifies the system's design and allows
reuse on a grander scale than the reuse of
individual objects and classes
th
Jan, 2014
Three aspects:
Common problem, context of problem
A general approach to a solution
Consequences of the pattern
Mechanistic Design Patterns
th
Jan, 2014
Three aspects:
Common problem, context of problem
When exception handling is used, raw pointers can lead to
memory leaks when exceptions are thrown. The use of
temporary pointers within normal C++ functions or class
member functions may not be properly cleaned up if an
exception is thrown because the inline delete operator may
be bypassed
th
Jan, 2014
Three aspects:
A general approach to a solution
Rather than use a raw pointer, a "smart" pointer object can
be used when a temporary pointer is needed. The smart
pointer is responsible for identifying whether a memory must
be deallocated when the pointer is destroyed
th
Jan, 2014
Three aspects:
Consequences of the pattern
The smart pointer makes the design more robust, but it
increases the code complexity and requires an additional
level of indirection for each pointer reference. It involves a
small runtime overhead.
th
Jan, 2014
Problem:
How to notify some number of clients, in a
timely fashion, of a data value according to
some abstract policy
Problem
th
Jan, 2014
Problem:
How to notify some number of clients, in a
timely fashion, of a data value according to
some abstract policy
Solution:
Clients are dynamically coupled to the server
with a subscription mechanism
Server looks up all the registered clients and
sends them the data
Observer Pattern
th
Jan, 2014
Observer Pattern
th
Jan, 2014
Observer Pattern Example
Structure
th
Jan, 2014
Structure
Callbacklist::getFirst
CallbackList::getNext()
Returns pointer to client
Use it to call accept() method of client
th
Jan, 2014
Scenario
th
Jan, 2014
Embedded systems often deployed across multiple
address spaces
Details are subject to change during the design process
Clients and servers may be redeployed in other physical
architectures using different communication media
Clients need not concern themselves with how to
contact the true server
clients need not be aware of design details of server, or
location details of the server
Problem
th
Jan, 2014
Hide some particular implementation properties
of servers from the clients
Hide from its client the fact that a server may be
actually located in another address space
this is called Remote proxy pattern that we will study
Proxy Pattern
th
Jan, 2014
Proxy Pattern
th
Jan, 2014
Proxy Pattern
Concrete Clients subscribe
to Client-side proxy and
send their accept method()
th
Jan, 2014
Proxy Pattern
Client-side Proxies
subscribe to the Server-side
Proxies
th
Jan, 2014
Proxy Pattern
Client-side Proxies
Proxies
Concrete Server sends data
to server-side proxy by
using its send() method
th
Jan, 2014
Proxy Pattern
Client-side Proxies
Proxies
The Server-side proxy uses
the Remote Notification
handle to notify all
subscribed Client-side
proxies of the new data
(it may change the format
to network format. Marshall
data, etc)
th
Jan, 2014
Proxy Pattern
Client-side Proxies
Proxies
The Server-side proxy uses
the Remote Notification
handle to notify all
subscribed Client-side
proxies of the new data
The Client-side proxy uses
the Local Notification
handle to notify all concrete
clients
must rely on
the
underlying
transport
protocol for
message
delivery
th
Jan, 2014
Example
th
Jan, 2014
Proxy Example Scenario
th
Jan, 2014
How to codify a collaboration structure that allows any
arbitrary set of precondition invariants to be met for thread
synchronization?
Problem
th
Jan, 2014
Used to synchronize a set of threads or permit data
sharing among a set of threads
Synchronizes two threads as an object itself
May simply provide a means for threads to synchronize
at a point with some synchronization policy or
precondition
e.g. check if a certain number of threads have registered at
their synchronization points
Thread barrier pattern
Concerned with modeling the preconditions for
synchronization or rendezvous of threads
Rendezvous Pattern
th
Jan, 2014
How it works?
When any thread becomes ready to rendezvous, it
registers with the Rendezvous class and blocks
Once the set of preconditions is met, the registered
tasks are released to run
Rendezvous Pattern
th
Jan, 2014
Rendezvous Pattern Structure
th
Jan, 2014
Rendezvous Pattern - Thread
Barrier
th
Jan, 2014
Rendezvous Pattern Example
th
Jan, 2014
Rendezvous Pattern Example -
scenario
th
Jan, 2014
Used in cases:
When communication reliability is required over
unreliable media
When extraordinary reliability is required
For example, suppose the system needs three distinct
levels of communications reliability:
1. At Most Once (AMO): A message is transmitted only once. If
the message is lost or corrupted, it is lost
2. At Least Once (ALO): A message is transmitted repeatedly
until acknowledgement is received or a maximum retry count is
exceeded
3. Exactly Once (EO): A message is treated as an ALO
transaction except that, should a message be received more
than once due to retries, only the first message instance will be
acted on
Reliable Transaction Pattern
th
Jan, 2014
Suited to real-time systems when different levels of
reliability of message transfer are required
Allows the application designers flexibility in their choice
of communications method so that they may optimize for
speed or reliability
The basic problem addressed by this pattern is to
support three levels of reliability in the transmission of
messages over unreliable communications media:
AMO, ALO, EO
th
Jan, 2014
Structure
AMO, ALO, EO?
th
Jan, 2014
Structure
Sender Transaction statechart
th
Jan, 2014
Structure
Receiver Transaction statechart
th
Jan, 2014
Reliable Transaction Example
Structure
In a medical device, the AnesthesiaController is remote from the
Vaporizer.
It needs to send an Increment Dose command to the Vaporizer.
Because an "increment" style command should be sent with EO
semantics, it creates the message with the transactionType attribute
set to EO.
th
Jan, 2014
Structure
Vaporizer.
set to EO.
th
Jan, 2014
Scenario
th
Jan, 2014
Mechanistic design
object collaboration
design patterns
The following design patterns were covered:
Observer pattern
Proxy pattern
example: remote proxy pattern
Rendezvous pattern
example: thread barrier pattern
Reliable Transaction pattern
More patterns to follow
Summary
th
Jan, 2014
IS ZC424
Lecture 15
Mechanistic Design (cont)r
th
Jan, 2014
Used in cases:
When communication reliability is required over unreliable
media
When extraordinary reliability is required
For example, suppose the system needs three distinct
levels of communications reliability:
1. At Most Once (AMO): A message is transmitted only once. If
the message is lost or corrupted, it is lost
2. At Least Once (ALO): A message is transmitted repeatedly
until acknowledgement is received or a maximum retry count is
exceeded
3. Exactly Once (EO): A message is treated as an ALO
transaction except that, should a message be received more
than once due to retries, only the first message instance will be
acted on
th
Jan, 2014
Suited to real-time systems when different levels of
reliability of message transfer are required
Allows the application designers flexibility in their choice
of communications method so that they may optimize for
speed or reliability
The basic problem addressed by this pattern is to
support three levels of reliability in the transmission of
messages over unreliable communications media:
AMO, ALO, EO
th
Jan, 2014
Structure
AMO, ALO, EO?
th
Jan, 2014
Structure
Sender Transaction statechart
th
Jan, 2014
Structure
Receiver Transaction statechart
th
Jan, 2014
Structure
Vaporizer.
set to EO.
th
Jan, 2014
Structure
Vaporizer.
set to EO.
th
Jan, 2014
Scenario
th
Jan, 2014
Useful when timely response is
needed across a thread boundary
Means by which services may be
safely provided across a thread
boundary
Uses a semaphore to guard
access to the resource across the
thread boundary
If another thread attempts to
access the resource while it is
locked, the latter thread is blocked
Guarded Call Pattern
th
Jan, 2014
Guarded Call Pattern Example
th
Jan, 2014
Guarded Call Pattern Scenario
th
Jan, 2014
Pointers are the most common way to realize an
association between objects
Pointer problems are the most common and hardest to
identify kinds of defects
Smart Pointer Pattern
th
Jan, 2014
Pointers are the most common way to realize an
association between objects
Pointer problems are the most common and hardest to
identify kinds of defects
Commonly occurring problems with programs using
pointers:
a pointer is destroyed without freeing memory (a memory leak)
memory is released but nevertheless pointer is accessed
(dangling pointer)
Exception safety (next slide)
th
Jan, 2014
void foo()
{
MyClass *p(new MyClass);
p->DoSomething();
delete p;
}
th
Jan, 2014
void foo()
{
MyClass *p(new MyClass);
p->DoSomething();
delete p;
}
What happens if DoSomething() throws an exception?
p will never get deleted! If we're lucky, this leads only to
memory leaks; but if unlucky:
MyClass may free some other resources in its destructor
(file handles, threads, transactions, COM references,
mutexes)
th
Jan, 2014
th
Jan, 2014
Smart Pointer - Reference count
example
Two clients of the HR Sensor object
One object that displays the values
another that tracks values to do trending analysis.
When the HR Display object runs, it creates an HR Sensor object via a Wrapped
Sensor object. The HR Display object also notifies the HR Trend object to begin
tracking the heart rate information.
th
Jan, 2014
Smart Pointer Pattern Scenario
th
Jan, 2014
Priority Inversion
Bounded
Unbounded
Priority Inheritance Pattern
th
Jan, 2014
Priority Inversion
Bounded
th
Jan, 2014
Priority Inversion
Unbounded
th
Jan, 2014
Priority Inheritance (simple case)
th
Jan, 2014
Priority Inheritance (more complex case)
th
Jan, 2014
Useful in remote embedded systems such as space
probes
These remote systems could become permanently
disabled if they were unable to autonomously recover
from faults.
Watchdog pattern
th
Jan, 2014
A hardware assistant called a watchdog that must be
stroked within a certain timeframe
The watchdog would otherwise cause some failure
recovery activity to take place, such as a system reset.
A watchdog can detect a timebase failure (too fast
and/or too slow, depending on its implementation), and
a CPU halt, but not much else.
The scope of the corrective actions that it can take is
usually limited to a system halt or reset.
Watchdog pattern
th
Jan, 2014
Watchdog pattern
th
Jan, 2014
Container-Iterator pattern
Faade (fusaad) pattern
program to interface, not to implementation
Strategy pattern (algorithms)
different algorithms for different clients
Ex. Depending upon data at runtime, the validation algorithm may be decided
Cyclic-Executive pattern (clock-driven)
deterministic schedule known a priori
More Patterns in Embedded
Systems
th
Jan, 2014
Next
Detailed design
Follows Architectural and Mechanistic Design
phases
Details of each class/object (operations and their
design)
Details of collaborations
Support classes/objects
th
Jan, 2014
Mechanistic design is concerned with specifying the
details of inter-object collaboration
Small groups of objects acting together within
collaborations are referred to as mechanisms
Mechanistic design takes the collaborative groups of
objects identified in analysis and adds design-level
objects to facilitate and optimize their implementation
Summary
th
Jan, 2014
Thank You!
th
Jan, 2014
Container Iterator pattern
example
Back
th
Jan, 2014
Container Iterator pattern
example
Back
th
Jan, 2014
Faade pattern example
Back
th
Jan, 2014
Strategy pattern example
Back
IS ZC424
Lecture 16
Detailed Design
th
Jan, 2014
Design
Mechanistic design deals with mechanisms
Group of collaborating objects
Architectural design is concerned with
Domains tasks and subsystems
The root of it all remains the object itself
Detailed design : How to design internal structure of an
object?
The detailed design allows
The objects to be correctly implemented
Permits designers to make tradeoff decisions to
optimize the system
It considers both the structure of the information and
its manipulation
th
Jan, 2014
Design Specifics
Detailed design specifies the following:
The storage format used for attributes
The implementation of associations
The set of operations the object provides
The selection of internal algorithms
The specification of exception handling within the object
th
Jan, 2014
Decisions
Object : Data tightly bound to its operations forming a cohesive
entity.
Detailed design must consider
Structure of information
Manipulation of information
Important decisions during detailed design:
Data Structure
Class refactoring (derived attributes)
Implementation of Associations
Set of operations defined on the data
Visibility of data and Operations
Algorithms used to implement those operations
Exceptions handled and thrown
th
Jan, 2014
Data Structures
Data format is generally simple
The following are also needed to be specified
Valid range of data
Mutator operations should ensure that the values are within range
ex. In UML constraint syntax is : { range 0..15}
Accuracy
Example: Use more significant digits for better accuracy
Change algorithm to equivalent forms e.g. use trigonometric
relation to avoid round-off errors
Preconditions should be met
array indices shouldn't be negative
ECG patients rarely weigh 500 Kg
automobiles don't go 500 kmph
Initial Values must be specified
The above is called Design by contract
th
Jan, 2014
Derived Attributes
To optimize performance, detailed design may add
derived attributes in addition to normal ones
Constructed from other attributes in the class
Indicated by derived stereotype in class diagrams; define the
derivation formula within an associated constraint e.g. {age =
currentDate - startDate}
For example, a sensor class may provide a 10-sample
history and a function to calculate the average of last 10
samples
th
Jan, 2014
Derived Attributes - Example
class sensor
{
float value[10];
int nMeasurements, currentMeasurment;
public:
sensor(void): nMeasurements(0), currentMeasurement(0) {
for (int j = 0; j<10; j++)
value[j] = 0;
}
void accept(float tValue)
{
value[currentMeasurement] = tValue;
currentMeasurement = (currentMeasurement+1) % 10;
if (nMeasurements < 10)
++nMeasurements;
}
float get(int index=0) {
int cIndex;
if (nMeasurements > index) {
cIndex = currentMeasurement-index-1;
if (cIndex < 0)
cIndex += 10;
return value[cIndex];
} else throw "No valid measurement at that index";
}
float average(void) {
float sum = 0.0;
if (nMeasurements > 0) {
for (int j=0; j < nMeasurements; j++)
sum += value[j];
return sum / nMeasurements;
} else throw "No measurements to average";
}
}; //end class sensor
th
Jan, 2014
class sensor
{
float value[10];
int nMeasurements, currentMeasurment;
public:
sensor(void): nMeasurements(0), currentMeasurement(0) {
for (int j = 0; j<10; j++)
value[j] = 0;
}
void accept(float tValue)
{
value[currentMeasurement] = tValue;
++nMeasurements;
}
int cIndex;
if (cIndex < 0)
cIndex += 10;
}
float sum = 0.0;
for (int j=0; j < nMeasurements; j++)
sum += value[j];
return sum / nMeasurements;
}
If this average() operation is used frequently, the above function keeps calculating
average even though it may just have calculated it
th
Jan, 2014
class sensor
{
float value[10];
float averageValue;
int nMeasurements, currentMeasurement;
public:
sensor(void): averageValue (0), nMeasurements(0),
currentMeasurement (0)
{
for (int j = 0; j<10; j++)
value[j] = 0;
}
void accept(float tValue) {
value [currentMeasurement] = tValue;
++nMeasurements;
averageValue = 0;
for (int j=0; j < nMeasurements-1; j++)
averageValue += value[j];
averageValue /= nMeasurements;
}
int cIndex;
if (cIndex < 0)
cIndex += 10;
}
float sum = 0.0;
return averageValue;
}
If the average value was needed more frequently than the data was monitored, the
average could be computed as the data was read
th
Jan, 2014
Collections
constraints
{ordered} Collection is maintained in a sorted
manner
{bag} Collection may have multiple copies
of a single item
{set} Collection may have at most a single
copy of a given item
{hashed} Collection is referenced via a keyed
hash
Some constraints above maybe combined e.g. {ordered set}
Selection of a collection structure depends on what characteristics
should be optimized
Balanced trees, for example, can be searched quickly, but inserting
new elements is complex
Linked lists are simple to maintain, but searching takes relatively long
UML provides role constraints, e.g.
th
Jan, 2014
Qualified Associations & Constraints
Using a key value to retrieve an
item from a collection is called
qualified association
th
Jan, 2014
The association between Patron
and Airline is qualified with Frequent
Flyer Num
This qualifier will be ultimately
implemented as an attribute within
the Patron class
Patron has a qualified association
with Library using the qualifier
Library Card Num
th
Jan, 2014
The association between Patron
and Airline is qualified with Frequent
Flyer Num
This qualifier will be ultimately
implemented as an attribute within
the Patron class
Patron has a qualified association
with Library using the qualifier
Library Card Num
Also see derived attribute age
constrained in text note
th
Jan, 2014
Associations
Allows client objects to invoke the operations provided
by the server objects
One to one
Can be implemented with a reference as in C++
One to (0,1)
Pointer to a server object implementation
Multi valued roles should be implemented by container iterator
pattern
Associations crossing thread boundary must be protected with
guarded call pattern
th
Jan, 2014
class testAssoc
{
T myT; // appropriate only for 1-to-1 composition
T* myT2; // ok for 1-to-1 or 1-to-(0,1) association
or composition
T& myT3; // ok for 1-1 association or composition
};
Associations
th
Jan, 2014
In a composition, we typically add our subclasses to the
composition using either normal variables or pointers where the
allocation and de-allocation process is handled by the composition
class
In an aggregation, these member variables are typically either
references or pointers that are used to point at objects that have
been created outside the scope of the class
Consequently, an aggregate class usually either takes the objects it
is going to point to as constructor parameters, or it begins empty
and the sub-objects are added later via access functions or
operators
An example of aggregation follows:
Aggregation
th
Jan, 2014
Consider the CS department of a college, which is made up of one
or more teachers.
When the department is destroyed, the teachers should still exist
independently (they can go get jobs in other depts.)
Because aggregations are just a special type of compositions, they
are implemented almost identical to compositions
Aggregation
th
Jan, 2014
class Teacher
{
private:
string cs_strName;
public:
Teacher(string strName)
: cs_strName(strName)
{
}
string GetName() { return cs_strName; }
};
class Department
{
private:
Teacher *cs_pcTeacher;
public:
Department(Teacher *pcTeacher=NULL)
: cs_pcTeacher(pcTeacher)
{
}
};
Aggregation
int main()
{
Teacher *pTeacher = new Teacher("Bob");
{
Department csDept(pTeacher);
} // csDept goes out of scope here and is destroyed
// pTeacher still exists here because cDept did not destroy it
delete pTeacher;
}
th
Jan, 2014
class EmbeddedSystem
{
private:
CPU m_cCPU;
Motherboard m_cMotherboard;
RAM m_cRAM;
};
EmbeddedSystem:: EmbeddedSystem(int nCPUSpeed,
char *strMotherboardModel,
int nRAMSize)
:m_cCPU(nCPUSpeed), m_cMotherboard(strMotherboardModel),
m_cRAM(nRAMSize){}
Composition example
th
Jan, 2014
class Point2D
{
private:
int m_nX;
int m_nY;
public:
// A default constructor
Point2D(): m_nX(0), m_nY(0) {}
// A specific constructor
Point2D(int nX, int nY) : m_nX(nX), m_nY(nY) {}
// An overloaded output operator
friend std::ostream& operator<<(std::ostream& out,
const Point2D &cPoint) {
out << "(" << cPoint.GetX() << ", "
<< cPoint.GetY() << ")";
return out;
}
// Access functions
void SetPoint(int nX, int nY)
{
m_nX = nX;
m_nY = nY;
}
int GetX() const { return m_nX; }
int GetY() const { return m_nY; }
};
Composition another example
class Creature
{
private:
std::string m_strName;
Point2D m_cLocation;
// We don't want people to create Creatures with no name or
location
// so our default constructor is private
Creature() { }
public:
Creature(std::string strName, const Point2D &cLocation)
: m_strName(strName), m_cLocation(cLocation)
{
}
friend std::ostream& operator<<(std::ostream& out, const
Creature &cCreature)
{
out << cCreature.m_strName.c_str() << " is at " <<
cCreature.m_cLocation;
return out;
}
void MoveTo(int nX, int nY)
{
m_cLocation.SetPoint(nX, nY);
}
};
th
Jan, 2014
Most often resolved using the
container pattern
Multi-valued roles
th
Jan, 2014
Operations
Defines how data may be manipulated
Complete set of primitive operations maximize reusability
May be useful for next application
Early design models specify only the public operations
Detailed design adds more internal operations (within
class)
Most messages in UML diagrams are implemented as
operations in the receiver class
th
Jan, 2014
Example: Queue
Analysis and early design models only specify the public operations
Detailed design often adds operations that are only used internally
These operations are due to the functional decomposition of the public
operations
th
Jan, 2014
Example: Queue
operations
template <class T, int size>
class queue
{
protected:
T q[size];
int head, tail;
public:
queue(void): head(0), tail(0);
virtual void put(T myT);
virtual T get(void);
};
th
Jan, 2014
Example: Queue
A cached queue caches data locally but stores most of it on a more
remote, but larger data store, such as a hard disk.
Operations can be added to implement the caching so that it is invisible
to the client.
class cachedQueue : public queue<T, size>
{
protected:
void writeToDisk(void);
void readFromDisk(void);
public:
cachedQueue(void): head(0), tail(0);
virtual void put(T myT); // new version of put
// uses writeToDisk
// when cache fills
virtual T get(void); // new version of get
// uses readFromDisk
// when data is not cached
};
th
Jan, 2014
Visibility
Accessibility of internal objects elements by other objects
Four General Guidelines
If client needs it then only make it visible
Make only semantically appropriate operations visible
GetLeft() and GetRight() or Prev() and Next()?
Attributes should not be directly visible to client
Avoiding tight coupling between objects
Accessor and mutator operations applied to that attribute can ensure that
preconditions are met, such as valid ranges
Direct access to the attribute circumvents these safeguards
Use interface pattern to supply different sets of
interfaces for different levels of visibility/access to
different clients
th
Jan, 2014
Visibility
# Private accessible only within the class itself
-
Protected accessible only by the class and its
subclasses
+ Public generally accessible by other classes
~
Package accessible to other member of the
same package
th
Jan, 2014
Visibility C++ friend classes
Friend classes also provide a different level of access
Can access the "private" and "protected" members of the
class in which it is declared as a friend
Often used for iterators in the container pattern
Another use is the facilitation of unit testing by making unit
testing objects friends of the class under test
th
Jan, 2014
Example - C++ friend classes
#include <iostream>
class B {
friend class A;
private:
void privatePrint() {
std::cout << "hello, world" << std::endl;
}
};
class A {
public:
A() {
B b;
b.privatePrint();
}
};
int main()
{
A a;
return 0;
}
th
Jan, 2014
#include <iostream>
using namespace std;
class CSquare;
class CRectangle
{
int width, height;
public:
int area () {
return (width * height);
}
void convert (CSquare a);
};
class CSquare {
private:
int side;
public:
void set_side (int a) {
side=a;
}
friend class CRectangle;
};
void CRectangle::convert (CSquare a) {
width = a.side;
height = a.side;
}
int main ()
{
CSquare sqr;
CRectangle rect;
sqr.set_side(4);
rect.convert(sqr);
cout << rect.area();
return 0;
}
th
Jan, 2014
Example - Collection
Identify a design problem with the following collection class:
class Bunch_O_Objects {
node* p;
node* current_node;
public:
void insert(node n);
node* go_left(void);
node* go_right(void);
};
th
Jan, 2014
node* p;
node* current_node;
public:
};
Sol: User of this class is exposed to its internal tree-implementation!
th
Jan, 2014
A possible solution:
node* p;
node* current_node;
public:
node* next(void);
node* previous(void);
};
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
};
Still it has a problem! It works fine provided that marching through the objects in the
collection will always be in a sequential manner. What if the client wants to go to first or
last object in the collection, or search for an object?
th
Jan, 2014
The class below fixes the problem. Now the client can go to first, or last object,
and also search for an object.
node* p;
node* current_node;
public:
node* next(void);
node* first(void);
node* last(void);
node* find(node &n);
};
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
node* first(void);
node* last(void);
};
Problem: If two readers march through the list using next() at the same time,
neither will get the entire list; some items will go to the first reader, while others
will go to the second.
th
Jan, 2014
Example - C++ iterator friend
class
Sol: Let each reader get a separate copy of iterator object
node* p;
public:
node *next(node *p);
node *previous(node *p);
friend class BOO_Iterator;
};
class BOO_Iterator {
node *current_node;
Bunch_O_Objects &BOO;
public:
BOO_Iterator (Bunch_O_Objects &B) : BOO(B) {
current_node = BOO.p;
}
node *next(void);
node *previous(void);
node *first(void);
node *last(void);
node *find(node &n);
};
th
Jan, 2014
Thank You!
IS ZC424
Detailed Design (contd.)
th
Jan, 2014
Operations
Defines how data may be manipulated
Complete set of primitive operations maximize reusability
May be useful for next application
Early design models specify only the public operations
Detailed design adds more internal operations (within
class)
Most messages in UML diagrams are implemented as
operations in the receiver class
th
Jan, 2014
Example: Queue
operations
th
Jan, 2014
Example: Queue
operations
class queue
{
protected:
T q[size];
int head, tail;
public:
queue(void): head(0), tail(0);
virtual void put(T myT);
virtual T get(void);
};
th
Jan, 2014
Example: Queue
A cached queue caches data locally but stores most of it on a more
remote, but larger data store, such as a hard disk.
Operations can be added to implement the caching so that it is invisible
to the client.
class cachedQueue : public queue<T, size>
{
protected:
void writeToDisk(void);
void readFromDisk(void);
public:
cachedQueue(void): head(0), tail(0);
virtual void put(T myT); // new version of put
// uses writeToDisk
// when cache fills
virtual T get(void); // new version of get
// uses readFromDisk
// when data is not cached
};
th
Jan, 2014
Visibility
Accessibility of internal objects elements by other objects
Four General Guidelines for visibility
If client needs it then only make it visible
Make only semantically appropriate operations visible
GetLeft() and GetRight() or Prev() and Next()?
Attributes should not be directly visible to client
Avoiding tight coupling between objects
Accessor and mutator operations applied to that attribute can ensure that
preconditions are met, such as valid ranges
Direct access to the attribute circumvents these safeguards
Use interface pattern to supply different sets of
interfaces for different levels of visibility/access to
different clients
th
Jan, 2014
Visibility C++ friend classes
Friend classes also provide a different level of access
Can access the "private" and "protected" members of the
class in which it is declared as a friend
Often used for iterators in the container pattern
Another use is the facilitation of unit testing by making unit
testing objects friends of the class under test
th
Jan, 2014
#include <iostream>
class B {
friend class A;
private:
void privatePrint() {
std::cout << "hello, world" << std::endl;
}
};
class A {
public:
A() {
B b;
b.privatePrint();
}
};
int main()
{
A a;
return 0;
}
th
Jan, 2014
#include <iostream>
class CSquare;
class CRectangle
{
int width, height;
public:
int area () {
return (width * height);
}
void convert (CSquare a);
};
class CSquare {
private:
int side;
public:
void set_side (int a) {
side=a;
}
friend class CRectangle;
};
void CRectangle::convert (CSquare a) {
width = a.side;
height = a.side;
}
int main ()
{
CSquare sqr;
CRectangle rect;
sqr.set_side(4);
rect.convert(sqr);
cout << rect.area();
return 0;
}
th
Jan, 2014
node* p;
node* current_node;
public:
};
th
Jan, 2014
node* p;
node* current_node;
public:
};
Sol: User of this class is exposed to its internal tree-implementation!
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
};
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
};
Still it has a problem! It works fine provided that marching through the objects in the
collection will always be in a sequential manner. What if the client wants to go to first or
last object in the collection, or search for an object?
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
node* first(void);
node* last(void);
};
th
Jan, 2014
node* p;
node* current_node;
public:
node* next(void);
node* first(void);
node* last(void);
};
Problem: If two readers march through the list using next() at the same time,
neither will get the entire list; some items will go to the first reader, while others
will go to the second.
th
Jan, 2014
Example - C++ iterator friend
class
Sol: Let each reader get a separate copy of iterator object
node* p;
public:
node *next(node *p);
node *previous(node *p);
friend class BOO_Iterator;
};
class BOO_Iterator {
node *current_node;
Bunch_O_Objects &BOO;
public:
BOO_Iterator (Bunch_O_Objects &B) : BOO(B) {
current_node = BOO.p;
}
node *next(void);
node *previous(void);
node *first(void);
node *last(void);
node *find(node &n);
};
th
Jan, 2014
Algorithms
Execution time is measured through its
complexity
Ex. O(1), O(n), O(log n), O(n log n), O(n
2
) etc.
th
Jan, 2014
Algorithms
complexity
2
) etc.
Algorithms with the same complexity can differ from
each other by multiplicative and additive constant
th
Jan, 2014
Algorithms
complexity
2
) etc.
each other by multiplicative and additive constant.
Ex.
Running time of Algorithm A=T
A
(N)=1000000 N =O(n)
Running time of Algorithm B=T
B
(N)=N
2
=O(n
2
)
th
Jan, 2014
Algorithms
complexity
2
) etc.
each other by multiplicative and additive constant.
Ex.
Running time of Algorithm A=T
A
(N)=1000000 N =O(n)
Running time of Algorithm B=T
B
(N)=N
2
=O(n
2
)
Most useful when input data set is large
th
Jan, 2014
Algorithms
complexity
2
) etc.
each other by multiplicative and additive constant
This is not the only optimization criterion!
th
Jan, 2014
Algorithms: Performance Criteria
Runtime performance
Average case
Worst case
Deterministic (predictable) performance
Runtime Memory Requirements
Simplicity
Reusability & Extensibility
Reliability, Safety and Security
Development time and Effort
th
Jan, 2014
Exception Handling
Indicates a serious fault has occurred that requires
explicit handling
th
Jan, 2014
Exception Handling
explicit handling
For example, in C, return values are used to check for
errors, but it is optional and usually ignored by clients of
the service.
th
Jan, 2014
Exception Handling
explicit handling
For example, in C, return values are used to check for
errors, but it is optional and usually ignored by clients of
the service.
An example of proper use of return values:
FILE *fp;
if ((fp = fopen("filename", "w")) == NULL) {
/* do some corrective action */
exit(1); /* pass error indicator up a level */
}
th
Jan, 2014
Exception Handling
Language based exception-handling provides two main
benefits:
th
Jan, 2014
Exception Handling
benefits:
1. The error conditions cannot be ignored
th
Jan, 2014
Exception Handling
benefits:
1. The error conditions cannot be ignored
2. It separate the exception handling code path from the normal
execution path and simplifies both the paths
th
Jan, 2014
C code
if ( (fp = ftest1(x,y,z))) == NULL) {
printf("Failure on ftest1");
}
if (!ftest2()) {
printf("failure on ftest2");
exit(1);
}
if (ftest3() == 0) {
exit(1);
}
Example
th
Jan, 2014
C code
if ( (fp = ftest1(x,y,z))) == NULL) {
printf("Failure on ftest1");
}
if (!ftest2()) {
exit(1);
}
if (ftest3() == 0) {
exit(1);
}
Example
C++ code
try
{
ftest1(x,y,z);
ftest2();
ftest3();
}
catch (test1Failure& t1)
{
cout << "Failure on test1";
throw; // rethrow same exception as code
// above
}
{
cout << "Failure on test2";
throw;
}
{
cout << Failure on test3";
throw;
}
th
Jan, 2014
Example divide by zero
exception
#include <iostream>
double division(int a, int b)
{
if( b == 0 ) {
throw "Division by zero condition!";
}
return (a/b);
}
int main ()
{
int x = 50;
int y = 0;
double z = 0;
try
{
z = division(x, y);
cout << z << endl;
}
catch (const char* msg)
{
cerr << msg << endl;
}
return 0;
}
th
Jan, 2014
Exceptions
Exceptions can be explicitly shown as events on either
statecharts or activity diagrams
At some global level, an exception policy must be
implemented depending upon severity of the exception.
e.g. in some systems there is a fail-safe state
robotic assembly systems normally shut down in the presence of faults
because that is their fail-safe state. Other systems, such as medical
monitoring systems, may continue by providing diminished
functionality or reset and retry, because that is their safest course of
action
th
Jan, 2014
Exceptions in activity diagram
Exceptions are modeled as interrupting edges applied to
an interruptible segment of an activity diagram
th
Jan, 2014
Exceptions in activity diagram
Exceptions are modeled as interrupting edges applied to
an interruptible segment of an activity diagram
th
Jan, 2014
Slack
End of Detailed design
A final topic on scheduling
th
Jan, 2014
Slack Stealing for Aperiodic
Jobs
In the previous session, we have discussed a
few real-time scheduling methods such as
Cyclic executive, Deadline Monotonic (DM),
Rate Monotonic (RM)
Lets look at one interesting variation of the
algorithms for aperiodic and sporadic jobs
th
Jan, 2014
Jobs
Idea: Use slack to schedule aperiodic jobs
before periodic jobs whenever possible!
Implementation: Cyclic executive keeps track
of slack and lets periodic task server execute
aperiodic jobs as long as there is slack
available
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
th
Jan, 2014
Scheduling Sporadic Jobs
Sporadic jobs have hard deadlines
Release times and maximum execution times are
unknown a priori
Impossible to guarantee deadlines for sporadic jobs
Acceptance test (at start of frame):
Sporadic job is only accepted , if it can be feasibly scheduled
along with all the other jobs (both periodic and sporadic)
Otherwise it is rejected soon after its release
Accepted sporadic jobs can be scheduled using
EDF(Earliest Deadline First)
th
Jan, 2014
Example: Scheduling Sporadic
Jobs
Off-line schedule
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
Job rejected: Not sufficient slack (Slack =
4)!
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
Job S
2
accepted, put into sporadic job queue
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
Job S
3
accepted, put before S
2
into sporadic job
th
Jan, 2014
Jobs
th
Jan, 2014
Jobs
Job S
4
rejected: not enough slack!
th
Jan, 2014
Jobs
th
Jan, 2014
Summary
Detailed design looks into detailing at the class
level such as data and algorithms, and how the
coding techniques could improve the efficiency
of system
Slacks in real-time systems are used to
schedule aperiodic and sporadic jobs
th
Jan, 2014
Thank You!
IS ZC424
Review
th
Jan, 2014
Review of some topics
Classes & objects
Deployment diagrams
Statecharts
Pseudostates
Sequence diagrams
Use case diagrams
Object analysis
Design
Architectural
Mechanistic
Detailed
Case study (ATM)
Requirements
Object domain analysis
Use cases
Sequence diagrams
Agenda
th
Jan, 2014
Embedded & Real-Time Systems
Object, Classes, and Interfaces
Relations: associations, generalization, dependencies
Components, Subsystems, Deployments
Text-notes and constraints within {}
State (reactive) behavior
Review
th
Jan, 2014
Deployment Diagram
Hardware/Software Mapping
th
Jan, 2014
States, transitions, guards, actions
AND state
Pseudostates: branch, history, junction, fork, join,
default, final
Statechart Diagram
th
Jan, 2014
States, transitions, guards, actions
event-name '(' parameter-list ')' '[' guard-expression ']' '/' action-list
Statechart Diagram
th
Jan, 2014
AND state
Statechart Diagram
th
Jan, 2014
Pseudo-states
Statechart Diagram
th
Jan, 2014
Sequence diagram
th
Jan, 2014
Use Cases
th
Jan, 2014
Object domain analysis
Architectural design
Mechanistic design
Detailed design
Object domain analysis &
Design
th
Jan, 2014
Requirements Statement
The software to be designed will control a simulated automated teller machine (ATM) having a
magnetic stripe reader for reading an ATM card, a customer console (keyboard and display)
for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in
multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow
an operator to start or stop the machine. The ATM will communicate with the bank's computer
over an appropriate communication link. (The software on the latter is not part of the
requirements for this problem.)
The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identification number (PIN) - both of which will be sent to the bank
for validation as part of each transaction. The customer will then be able to perform one or
more transactions. The card will be retained in the machine until the customer indicates that
he/she desires no further transactions, at which point it will be returned - except as noted
below.
The ATM must be able to provide the following services to the customer:
1. A customer must be able to make a cash withdrawal from any suitable account linked
to the card, in multiples of $20. Approval must be obtained from the bank before cash
is dispensed.
2. A customer must be able to make a deposit to any account linked to the card,
consisting of cash and/or cheques in an envelope. The customer will enter the
amount of the deposit into the ATM, subject to manual verification when the envelope
is removed from the machine by an operator. Approval must be obtained from the
bank before physically accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts
linked to the card.
ATM System
th
Jan, 2014
The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it
has been approved. In the case of a deposit, a second message will be sent to the bank
indicating that the customer has deposited the envelope. (If the customer fails to deposit the
envelope within the timeout period, or presses cancel instead, no second message will be sent
to the bank and the deposit will not be credited to the customer.)
If the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN before a transaction can proceed. If the customer is unable to successfully enter
the PIN after three tries, the card will be permanently retained by the machine, and the
customer will have to contact the bank to get it back.
If a transaction fails for any reason other than an invalid PIN, the ATM will display an
explanation of the problem, and will then ask the customer whether he/she wants to do
another transaction.
The ATM will provide the customer with a printed receipt for each successful transaction,
showing the date, time, machine location, type of transaction, account(s), amount, and ending
and available balance(s) of the affected account ("to" account for transfers).
The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing of customers. After turning the switch to the "on" position, the operator will be
required to verify and enter the total cash on hand. The machine can only be turned off when it
is not servicing a customer. When the switch is moved to the "off" position, the machine will
shut down, so that the operator may remove deposit envelopes and reload the machine with
cash, blank receipts, etc.
ATM System
th
Jan, 2014
The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities
arising from a hardware failure in the middle of a transaction. Entries will be made in the log
when the ATM is started up and shut down, for each message sent to the Bank (along with the
response back, if one is expected), for the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and dollar amounts, but for security will
never contain a PIN.
ATM System
th
Jan, 2014
Use Case Diagram
th
Jan, 2014
Use Case Diagram
th
Jan, 2014
System Startup Use Case
The system is started up
when the operator turns the
operator switch to the "on"
position. The operator will
be asked to enter the
amount of money currently
in the cash dispenser, and a
connection to the bank will
be established. Then the
servicing of customers can
begin.
th
Jan, 2014
System Shutdown Use Case
The system is shut down
when the operator makes
sure that no customer is
using the machine, and then
turns the operator switch to
the "off" position. The
connection to the bank will
be shut down. Then the
operator is free to remove
deposited envelopes,
replenish cash and paper,
etc.
th
Jan, 2014
Session Use Case
A session is started when a
customer inserts an ATM
card into the card reader slot
of the machine. The ATM
pulls the card into the
machine and reads it. (If the
reader cannot read the card
due to improper insertion or
a damaged stripe, the card
is ejected, an error screen is
displayed, and the session
is aborted.) The customer is
asked to enter his/her PIN,
and is then allowed to
perform one or more
transactions, choosing from
a menu of possible types of
transaction in each case.
th
Jan, 2014
Session Use Case cont
After each transaction, the
customer is asked whether
he/she would like to perform
another. When the customer
is through performing
transactions, the card is
ejected from the machine
and the session ends. If a
transaction is aborted due to
too many invalid PIN
entries, the session is also
aborted, with the card being
retained in the machine.
The customer may abort the
session by pressing the
Cancel key when entering a
PIN or choosing a
transaction type.
th
Jan, 2014
Transaction Use Case
Transaction is an abstract
generalization. Each specific
concrete type of transaction
implements certain
operations in the appropriate
way. The flow of events
given here describes the
behavior common to all
types of transaction. The
flows of events for the
individual types of
transaction (withdrawal,
deposit, transfer, inquiry)
give the features that are
specific to that type of
transaction
th
Jan, 2014
A transaction use case is
started within a session
when the customer chooses
a transaction type from a
menu of options. The
customer will be asked to
furnish appropriate details
(e.g. account(s) involved,
amount). The transaction
will then be sent to the bank,
along with information from
the customer's card and the
PIN the customer entered.
th
Jan, 2014
If the bank approves the
transaction, any steps
needed to complete the
transaction (e.g. dispensing
cash or accepting an
envelope) will be performed,
and then a receipt will be
printed. Then the customer
will be asked whether
he/she wishes to do another
transaction.
If the bank reports that the
customer's PIN is invalid,
the Invalid PIN extension
will be performed and then
an attempt will be made to
continue the transaction. If
the customer's card is
retained due to too many
invalid PINs, the transaction
will be aborted, and the
customer will not be offered
the option of doing another.
th
Jan, 2014
If a transaction is cancelled
by the customer, or fails for
any reason other than
repeated entries of an
invalid PIN, a screen will be
displayed informing the
customer of the reason for
the failure of the transaction,
and then the customer will
be offered the opportunity to
do another.
The customer may cancel a
transaction by pressing the
Cancel key.
All messages to the bank
and responses back are
recorded in the ATM's log.
th
Jan, 2014
Withdrawal Transaction Use
Case
A withdrawal transaction
asks the customer to
choose a type of account to
withdraw from (e.g.
checking) from a menu of
possible accounts, and to
choose a dollar amount from
a menu of possible
amounts. The system
verifies that it has sufficient
money on hand to satisfy
the request before sending
the transaction to the bank.
(If not, the customer is
informed and asked to enter
a different amount.) If the
transaction is approved by
the bank, the appropriate
amount of cash is dispensed
by the machine before it
issues a receipt. (The
dispensing of cash is also
recorded in the ATM's log.)
th
Jan, 2014
Withdrawal Transaction Use
Case
A withdrawal transaction can
be cancelled by the
customer pressing the
Cancel key any time prior to
choosing the dollar amount.
th
Jan, 2014
Deposit Transaction Use Case
A deposit transaction asks
the customer to choose a
type of account to deposit to
(e.g. checking) from a menu
of possible accounts, and to
type in a dollar amount on
the keyboard. The
transaction is initially sent to
the bank to verify that the
ATM can accept a deposit
from this customer to this
account. If the transaction is
approved, the machine
accepts an envelope from
the customer containing
cash and/or cheques before
it issues a receipt.
th
Jan, 2014
Once the envelope has
been received, a second
message is sent to the
bank, to confirm that the
bank can credit the
customer's account -
contingent on manual
verification of the deposit
envelope contents by an
operator later. (The receipt
of an envelope is also
recorded in the ATM's log)
th
Jan, 2014
A deposit transaction can be
cancelled by the customer
pressing the Cancel key any
time prior to inserting the
envelope containing the
deposit. The transaction is
automatically cancelled if
the customer fails to insert
the envelope containing the
deposit within a reasonable
period of time after being
asked to do so.
th
Jan, 2014
Transfer Transaction Use Case
A transfer transaction asks
type of account to transfer
from (e.g. checking) from a
menu of possible accounts,
to choose a different
account to transfer to, and to
type in a dollar amount on
the keyboard. No further
action is required once the
transaction is approved by
the bank before printing the
receipt.
A transfer transaction can
be cancelled by the
entering a dollar amount.
th
Jan, 2014
Inquiry Transaction Use Case
An inquiry transaction asks
type of account to inquire
about from a menu of
possible accounts. No
further action is required
once the transaction is
approved by the bank before
printing the receipt.
An inquiry transaction can
be cancelled by the
choosing the account to
inquire about.
th
Jan, 2014
Invalid PIN extension
An invalid PIN extension is
started from within a
transaction when the bank
reports that the customer's
transaction is disapproved
due to an invalid PIN. The
customer is required to re-
enter the PIN and the
original request is sent to
the bank again. If the bank
now approves the
transaction, or disapproves
it for some other reason, the
original use case is
continued; otherwise the
process of re-entering the
PIN is repeated. Once the
PIN is successfully re-
entered, it is used for both
the current transaction and
all subsequent transactions
in the session.
th
Jan, 2014
ATM System
If the customer fails three
times to enter the correct
PIN, the card is permanently
retained, a screen is
displayed informing the
customer of this and
suggesting he/she contact
the bank, and the entire
customer session is
aborted.
If the customer presses
Cancel instead of re-
entering a PIN, the original
transaction is cancelled.
th
Jan, 2014
An initial reading of the use cases suggests that the following will be part of the system.:
A controller object representing the ATM itself (managing the boundary objects listed
below.)
Objects representing the individual component parts of the ATM:
Operator panel.
Card reader.
Customer console, consisting of a display and keyboard.
Network connection to the bank.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Objects corresponding to use cases.
Session
Transaction (abstract generalization, responsible for common features, with concrete
specializations responsible for type-specific portions)
An entity object representing the information encoded on the ATM card inserted by
customer.
An entity object representing the log of transactions maintained by the machine.
Object Analysis
th
Jan, 2014
ATM System - Class Diagram
Note:
Dependency indicates that one class
depends on another because it uses it at
some point in time. One class depends
on another if the independent class is a
parameter variable or local variable of a
method of the dependent class
In association, an attribute of the
dependent class is an instance of the
independent class
e.g. CustomerConsole depends on
Money class as Money is a local variable
of a method of CustomerConsole
ATM is associated with CardReader by
composition as an instance of the latter
is an attribute of ATM
th
Jan, 2014
ATM Statechart
th
Jan, 2014
Session Statechart
th
Jan, 2014
Transaction Statechart
th
Jan, 2014
Sequence Diagram System
Startup
th
Jan, 2014
Sequence Diagram System
Shutdown
th
Jan, 2014
Sequence Diagram Session
th
Jan, 2014
Sequence Diagram
Transaction
th
Jan, 2014
Attributes?
Methods?
Details can be accessed from:
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/
ATM System Detailed Design
th
Jan, 2014
Queries?
th
Jan, 2014
Thank You & Good Luck!

SWESD Consolidated

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SWESD Consolidated

Diunggah oleh

Hak Cipta:

Format Tersedia

Software for Embedded Systems

If the computation must finish 50 ms before the

If the computation must finish 50 ms before the

Anda mungkin juga menyukai