Embedded System

Development

Design Methodologies [UML as Design

tool, UML notation, Requirement
Analysis and Use case Modeling]
Design Examples[Telephone PBX,
Inkjet Printer, PDA ,Elevator Control
System, ATM System] Fault-tolerance
Techniques
Reliability Evaluation Techniques.

Model

Model is an iterative process.

It can represent static or dynamic
situations.
Model

Static

Dynamic

Provides a systems
parameters at rest or at a
specific point in time.

Represents a systems behaviors

that, taken together, reflect its
behavior over time.

(e.g.) class diagram

(e.g.) interaction & activity diagrams

Why modeling?
Describing a
abstraction.
Advantages

system

at

high

level

of

Reduces Complexity
Easy to understand systems
Reduces conflicts between customer and designers.

Clarity
Familiarity
Maintenance
Simplification

Advantages of modeling
Easy to express complex ideas
Reduce complexity
Enhance & reinforce learning and
training
Low cost
Easy to change the model

What is Unified Modeling Language

(UML)?
The UML is a graphical / standard
language for visualizing,
specifying, constructing &
documenting the artifacts of a
software system.

UML Diagrams
1.
2.
3.
4.
5.
6.
7.
8.

Class diagram
Use case diagram
Activity diagram
Sequence diagram
Collaboration diagram
State chart diagram
Component diagram
Deployment diagram

UML Concepts

UML can be used to support

your entire life cycle.
1.
2.
3.
4.
5.

The interaction of your application with the

outside world (use case diagram)
Visualize object interaction (sequence &
collaboration diagrams)
The structure of your system (class diagram)
View the system architecture by looking at the
defined package.
The components in your system (component
diagram)

USE CASE Diagram

(used for capturing user requirements)
Introduced by Jacobson

 Use case Diagram:

Graph of actors, set of
usecases enclosed by a system
boundary.
# Communication
between
Actor and use
case
Among use
cases

 Sequence of transactions
Each transaction invoked from
outside the system- Actors
Internal objects interact with one
another and with system surrounding
Defines outside(Actors) and
Inside(usecases)

 An actor represents
anything that interacts
with the system.
A use case defines a set of
use-case instances, where
each instance is a
sequence of actions a
system performs that
yields an observable result
of value to a particular
actor.

Actor

Use Case

Components of Usecase
diagram
Actor: A role that a user plays with respect to the system,
including human users and other systems. e.g.,
inanimate physical objects (e.g. robot); an external
system that needs some information from the current
system.
Usecase: A set of scenarios that describing an
interaction between a user and a system, including
alternatives.
System boundary: rectangle diagram representing the
boundary between the actors and the system.

Use Case Modeling: Core Elements

Construct Description
use case

actor

A sequence of actions, including

variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A coherent set of roles that users
of use cases play when interacting
with these use cases.

Syntax

U seC aseN am e

A c to rN a m e

system
boundary

Represents the boundary between

the physical system and the actors
who interact with the physical
system.

Actors
Anything that interacts with a usecase.
Human user
External hardware
Another system
Category of users rather than
physical
user

Use Case Diagram(core relationship)

Association: communication between an actor and
a use case; Represented by a solid line.
Generalization: relationship between one general
use case and a special use case (used for defining
special alternatives)
Represented by a line with a triangular arrow head
toward the parent use case.

Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include
use case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
include in stead of copying the description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow

toward the base case. The extending use case may add behavior to
the base use case. The base class declares extension points.
<<extend>>

Assosiation
Actor -----------> Usecase
Genaralization
Actor -----------> Actor
Usecase ------------> Usecase
Extend
Base(Usecase) <-----------Spl(Usecase)
Include
base(Usecase) ----------->
Spl(Usecase)

_____

Transactio
n

Transactio
n

Transactio
n

withdraw

Extend

include

Help

Customer
Authentic
ation

Use Case Modeling: Core Relationships

Construct

Description

The participation of an actor in a use

case. i.e., instance of an actor and
instances of a use case communicate
with each other.
extend
A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.

Syntax

association

<<extend>>

Use Case Modeling: Core Relationships

(contd)

<<include>>

 Identify actors from a problem

statement.
Identify use cases from a problem
statement.
Learn how to create a use-case
diagram that accurately models the
system.

Useful Questions in Finding Actors

Who will supply, use, or remove
information?
Who will use this functionality?
Who is interested in a certain
requirement?
Where in the organization is the
system used?
Who will support and maintain the
system?
What are the systems external
resources?
What other systems will need to
interact with this one?

Actor

Medical clinic software

Vending machine
D

M
C

u s t o m

e p o s it

a k e

o n e y

S e le c t io n

e r

C a n c e lla t io n

U p d a t e

a i n t e n a n c e
O p e r a t o r

a t a b a s e

Course Registration Problem Statement

The university will require a new Course Registration system. At
the beginning of each semester, professors at the university will
register the courses that they are going to teach with the system.
The system then will allow students to request a course
catalogue containing a list of course offerings for the coming
semester. Information about each course such as professor,
department and prerequisites are included. The student then can
select four-course offering. Once the registration process is
completed for a student, the registration system sends
information to the billing system so the student can be billed for
the semester. For each semester, there is a period of time that
students can change their schedule through adding or dropping
courses. Professors must be able to access the system to
indicate which courses they will be teaching and to see which
students signed up for their course offerings.

Practice: Solution

Billing
System

The external
system
responsible for
student billing
A person who is
teaching classes
at the University

Professor

Registrar

The person who is

responsible for
the maintenance
of the course
registration
system

Student

Course
Catalog

A person who is
registered to take
courses at the
University
The unabridged
catalog of all
courses offered
by the University

Use Case and Actor Communication

View Report Card

Student
Register for Courses

Course Catalog

Maintain Professor Information

Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor

Close Registration

Submit Grades

Billing
System

Fault Tolerance
A system should be fault-tolerant
Should be able to continue functioning
in the presence of faults

Fault tolerance is related to

dependability

Dependability
Dependability Includes

Availability
Reliability
Safety
Maintainability

Availability & Reliability

Availability: A measurement of
whether a system is ready to be used
immediately
System is up and running at any given
moment

Reliability: A measurement of whether

a system can run continuously without
failure
System continues to function for a long

Availability & Reliability

A system goes down 1ms/hr has
an availability of more than
99.99%, but is unreliable
A system that never crashes but is
shut down for a week once every
year is 100% reliable but only 98%
available

Safety & Maintainability

Safety: A measurement of how safe
failures are
System fails, nothing serious happens
For instance, high degree of safety is required
for systems controlling nuclear power plants

Maintainability: A measurement of how

easy it is to repair a system
A highly maintainable system may also show a
high degree of availability
Failures can be detected and repaired
automatically? Self-healing systems?

Faults

A system fails when it cannot meet its

promises (specifications)
An error is part of a system state that may
lead to a failure
A fault is the cause of the error
Fault-Tolerance: the system can provide
services even in the presence of faults
Faults can be:
Transient (appear once and disappear)
Intermittent (appear-disappear-reappear behavior)
A loose contact on a connector intermittent fault

Permanent (appear and persist until repaired)

Failure Models
Type of failure

Description

Crash failure

A server halts, but is working correctly until it halts

Omission failure
Receive omission
Send omission

A server fails to respond to incoming requests

A server fails to receive incoming messages
A server fails to send messages

Timing failure

A server's response lies outside the specified time interval

Response failure
Value failure
State transition failure

The server's response is incorrect

The value of the response is wrong
The server deviates from the correct flow of control

Arbitrary failure
(Byzantine failure)

A server may produce arbitrary responses at arbitrary times

Failure Masking

Redundancy is key technique for

hiding failures
Redundancy types:
1. Information: add extra (control)
information

Error-correction codes in messages

2. Time: perform an action persistently

until it succeeds:

Transactions

3. Physical: add extra components (S/W