Todays Lecture contents

1
Todays Lecture contents
Welcome to IS ZC 424 Software for Embedded
Systems Lecture 3 (19/02/08) Instructor in
charge Virendra S Shekhawat

• Object Behavioral Analysis
• State Charts and Activity Diagrams
• Design Issues and Approaches
• Architectural Design
• Collaboration Diagrams
• System Sub Structuring
• Case Study Elevator Control System

2
Object Behavioral Analysis
3
Process

• Analysis
• Requirements Analysis ?
• Systems Analysis ?
• Object Analysis
• Object Structural Analysis
• Object Behavioral Analysis
• Design
• Implementation

4
Object Behavior

• Behavior (dynamic) vs. Structure (static)
• Behavior binds objects with attributes and
  relationships
• Goal Object must meet responsibilities
• Types of Behavior
• Simple (fixed, no memory/history)
• State-driven (discrete)
• Continuous (history dependent but smooth)
• UML is a discrete modeling language
• State machines ? state charts

5
State Chart Diagrams

• A statechart diagram shows the possible states of
  the object and the transitions that cause a
  change in state.
• States in state chart diagrams can be nested.
  Related states can be grouped together into a
  single composite state. Nesting states is
  necessary when an activity involves concurrent or
  asynchronous subactivities.

6
Activity Diagrams

• An activity diagram is essentially a fancy
  flowchart. Activity diagrams and statechart
  diagrams are related.
• While a state chart diagram focuses attention on
  an object undergoing a process (or on a process
  as an object), an activity diagram focuses on the
  flow of activities involved in a single process.
• The activity diagram shows how those activities
  depend on one another.

7
Sequence Diagrams

• A sequence diagram is an interaction diagram that
  details how operations are carried out -- what
  messages are sent and when.
• Sequence diagrams are organized according to
  time. The time progresses as you go down the
  page.
• The objects involved in the operation are listed
  from left to right according to when they take
  part in the message sequence.

8
Example
9
Events, States and Action

• An event is an occurrence at a point in time
  known as discrete signal or stimulus
• Having conceptually zero duration
• Ex Door closed, request for Up
• They can depend on each other
• Ex open door cannot occur before elevator not
  stopped

10
Events, States and Action

• A state is a recognizable situation that exists
  over an interval of time
• Difference????
• Event? Occurs at point of time
• State? Occurs over an interval of time
• Arrival of an event can change the state!!!
• Null effect events???
• An event is cause of state transition and action
  is the effect of it. Action is a command.
• Ex Stop, Close the door

11
Guide lines for Developing State Charts

• State name must reflect an identifiable situation
  i.e. something is happening. It should not be an
  action or an event
• Ex Elevator moving not elevator moves
• Unique name for each state
• On a flat state chart? One state at a time
• Elevator moving and Elevator at a floor can
  not be at same time
• May have more than one action associated with a
  state transition
• In any order, Interdependencies requires
  intermediate state.

12
Elevator Control System Identify the Objects 1

• The elevator Object is a composite object
• It receives inputs from external objects and
  controls external objects
• Most of them are device interface
  objects-interface to external I/O devices
• Every external device object, there is a
  corresponding software device interface object
• So elevator receives requests via interface
  objects

13
Object Structuring
Elevator Button
Arrival Sensor
Elevator Lamp
Motor
Elevator Control System
Door
Floor Lamp
Directional Lamp
Floor Button
14
Identify the Objects 2

• Additional Objects are needed
• Elevator Status Plan ltEntity Objectgt
• Keeping the information whether elevator is
  moving up or down or idle etc.
• Elevator Control lt Control Objectgt
• Controls elevator motor and door
• Elevator Manager ltCoordinator Objectgt
• Receiving requests and updating the plan
• Scheduler
• When request comes from floor button elevator
  needs to be selected for coordinator

15
Dispatch elevator Use case State Chart for
Elevator Control
Elevator idle
Door Closing to Move Up Close Door Off Up
Floor Lamp
Up Request
Up Request
Elevator Starting Up
Elevator Checking Next Destination
Elevator Moving Departed
Elevator Started
16
Stop Elevator at Floor use case State Chart for
Elevator Control
Elevator Moving
Approaching Floor/ Checking this floor
Elevator Stopping
Elevator Door opening
Elevator At floor
Elevator Idle Update Idle Status
Elevator Checking Next Destination
No request
17
State Chart Model for Elevator Control
Elevator idle
Door Closing to Move Up
Door Closing to Move Down
Down Request
Up Request
Elevator Starting Up
Elevator Starting Down
Elevator Moving
Approaching Floor/ Checking this floor
Elevator Stopping
18
Elevator Door opening
Elevator At floor
Door Closing to move Down Close Door Off Down
floor Lamp
Elevator Idle Update Idle Status
Elevator Checking Next Destination
Down request
No request
Door Closing to move Up Close Door Off Up floor
Lamp
Up request
19
Design Issues Approaches Architectural Design
20
Design1

• Process of identifying and specifying a solution
  that meets requirements identified in the
  analysis phase
• Driven by the set of required QoS properties
• Reusability
• Timeliness
• Schedulability
• Throughput
• Memory Usages
• Safety
• Reliability

21
Design2

• Modern design approaches go for modular
  solutions
• Easy maintenance is the primary goal.
• Often, what is the right set of modules?
  becomes the design issue.
• Modules must
• Support useful abstractions and
• Preserve separation of concerns

22
Design Templates

• Templates are contextual but generic solutions
  that are re-usable with minor adaptations.
• Problem contexts
• Low level design (close to coding) Idioms
• Usually a few lines of code are involved
• Medium level design - Design Patterns
• Usually a few classes/objects are involved
• High level design (close to architecture) -
  Architectural Pattern or Style
• Usually whole systems or sub-systems involved

23
Modular Design

• Criteria for right set of modules
• Reuse, Changeability are recurrent issues in
  software design
• Multiple versions of the same product may be
  released
• But less critical in embedded systems
• Reuse and changeability are likely to be
  co-dependent on hardware.
• Performance (of eventual implementation) is a
  significant criterion
• Particularly in embedded systems.

24
Levels of Design

• Typical division
• high level design (architectural)
• (coarse grained and close to problem domain) and
• low level design (detailed)
• (fine-grained and close to implementation
  systems)
• ROPES process
• Architectural
• Mechanistic
• Detailed

25
Architectural Design1

• Scope
• System wide
• Elements
• Process Distribution and Communication
• Packaging and Deployment
• Concurrency model and communication
• Layering
• Global policies (error handling, event models
  etc.)
• Issues
• Software architecture is part of system
  architecture includes electronics/mechanics of
  the system.

26
Architectural Design2

• System architecture physical architecture
  software architecture
• Physical architecture imposes constraints
• Number of processors and processor speeds
• Memory sizes and restrictions
• Development environment
• Related software (OS, Drivers, Network protocols)
• Software Architecture
• Modern design is pattern oriented

27
What is Architectural Design?

• Tells about the collaborations of packages,
  tasks, or processors
• Two kinds of architecture (ROPES)
• Logical Architecture
• Concerned with how models are themselves
  organized
• Unrelated to the organization of the system at
  run time
• Physical Architecture
• Elements are sub systems, components, and objects

28
Views of Architecture1

• What is view?
• Showing a subset of the system model to allow a
  keener examination of some particular aspect
• Look at parts of the single model that are
  related to each other in specific ways
• Filtered view showing certain aspect at a time

29
Views of Architecture2

• Five Views in ROPES
• Subsystem and Component view
• Common behavioral things comes under one
  subsystem
• Systems at different levels of decomposition
• Concurrency and Resource View
• Management of resources and concurrent aspects of
  the system execution
• Resource sharing
• Distribution View
• How objects find and collaborate with each other
  even though they may be in different address
  spaces

30
Views of Architecture3

• Safety and Reliability View
• How system redundancy is defined and managed?
• Concerned with correct functioning in the
  presence of faults and errors
• Reliability? Availability of the system.
  Estimated with MTBF
• Key for both is redundancy
• Deployment View
• How software architecture maps onto the physical
  devices such as processors, disk drives, displays
  etc

31
Layered Systems

• Characteristics
• Hierarchical organization
• Each layer provides services to layer(s) above
• Each layer acts a client to layer(s) below
• A layer may be partially opaque
• Key Design Issues
• Inter-layer interaction
• Constrained interaction (say, only adjacent
  layers can interact)

32
Layered Systems Basic Model
Core
Basic utility
User
Useful systems
33
Layered Systems Example
ISO-OSI Model
Strengths Weaknesses ?
34
Layered Systems Example
Internet Model
Strengths Weaknesses ?
35
Layered Systems Example
Mobile Robotic System
Strengths and Weaknesses
36
Software Design Principles and Implements /
Processes

• Principles
• Basic Separation of Concerns
• Implied Modularity and Re-use.
• Implements / Processes
• Top-down design
• Language constructs for data abstraction
• User Interface Toolkit

37
Software Design Templates

• Example 1 Iterate over array elements in C or
  Java
• for ( j0 jltN j) Aj

38
Software Design Templates 2

• Example 2 Sets or Collections Operations
• Requirements
• Operations may have to access each element of a
  set / collection
• Different implementations (with different pros
  and cons) are available for collections.
• Design
• Provide a way to enumerate elements of a set.
• Operations use enumerator for accessing elems.

39
Software Design Templates 3

• Example 3 Design an online document publishing
  system for BITS
• Requirements
• Authors submit documents online in different
  formats.
• Publishing system uses different markup languages
  for different displays.
• Documents have to spell-checked before being
  published.

40
Software Design Templates 4

• Example 3 (contd..) - Design

Generic Transducer
XML
PDF Doc.
Spell Checker
Device Transducer
XML
DeviceML
DeviceML
BITS Styler
Display / Blaster
DeviceStyle
41
Software Design Templates 5

• Example 3 (contd..) Design
• Modules are designed as input to output
  transducers.
• That is, they are filters! (recall Unix commands)
• Modules are not sharing any external data or
  other modules.
• So, they can be run concurrently (without
  explicit synchronization).
• That is, they can be piped! (recall Unix pipes)

42
Software Design Templates 6

• Example4 Client server architecture for ATM
  Application for a single bank
• ATMs distributed around the state
• Communicating with the bank server

43
Design Templates 7

• Templates are contextual but generic solutions
  that are re-usable with minor adaptations.
• Problem contexts
• Low level design (close to coding)
• Eg. 1 and 2 Idioms
• Medium level design
• E.g. 3 Design Pattern
• High level design (close to architecture)
• E.g. 4. Architectural Pattern or Style

44

• System Decomposition Issues Collaboration
  Diagrams
• Case Study elevator Control System

45
System Decomposition Issues

• Emphasis is on separation of concerns
• A subsystem should have low coupling with other
  subsystems
• The coupling between the objects with in a
  subsystem should be high
• It can be considered as a composite or aggregate
  object
• The object interaction model (i.e. Collaboration
  Diagram) for a use case forms the basis of a
  subsystem

46
Collaboration Diagrams

• How objects dynamically cooperate with each
  other?
• At analysis level it has been shown through
  message (event data) passing
• Design level it helps in determining the
  operations of the objects, because arrival of
  message at an object usually invokes an operation

47
Subsystems Decomposition Criterion1

• Geographical Distribution
• Ex banking system ATM Client and Bank Server
  subsystems
• Objects that participate in the same use case are
  to be in the same subsystem
• One object participation is in more than one use
  case then???
• High coupling is the criteria
• How to decide the coupling???
• Consolidated Collaboration diagrams for showing
  all objects and their interactions
• Merger of the collaboration diagrams

48
Subsystems Decomposition Criterion2

• Aggregate/ Composite Object
• Objects that are part of the same aggregate or
  composite object should be in the same subsystem
• Particularly composition is stronger form of
  aggregation
• Client and server
• User interface objects
• Interface to external objects
• Entity Objects
• An entity object has stronger cohesion with
  objects that update it than with objects that
  read from it

49
Elevator Control System Use Case Model
50
Object identification
51
Collaboration Diagram for Select Destination use
Case
52
Collaboration Diagram for Request Elevator Use
Case
53
Collaboration Diagram for Stop elevator at floor
use case
54
Collaboration Diagram for Dispatch Elevator use
case
55
Consolidated Collaboration Diagram
56
Sub System Structuring1

• Potentially Distributed application
• Geographical location and aggregation/composition
  take precedence
• All Elevator objects are part of an Elevator
  Subsystem composite object
• Control Sub System
• Door interface, motor Interface, Elevator button
  Interface, Elevator lamp Interface, Elevator
  Control Object etc.

57
Sub System Structuring2

• Floor Sub System
• Data Collection
• Floor lamp Interface, Floor Button interface,
  Direction lamp Interface
• Scheduler Sub System
• Independent to floors and Elevator
• Coordinator
• Objects participating in more than one use case
• Door Interface, motor Interface and elevator
  control are participating in both Stop Elevator
  at Floor and Dispatch Elevator use cases

58
Subsystem Structure
59
Structure of elevator Subsystem
60
Structure of Floor Subsystem