System Design

1
sysc-4800 Software Engineering
Part VII Real Time Aspects, Concurrency and UML
2
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

3
Real-Time Systems

• System needs to perform (some of) its functions
  within specified time limits deadlines must be
  met
• System is responding to events from the external
  environment reactive
• System is composed of concurrently executing
  threads of control (Tasks) one or several
  processors
• Usually high requirements regarding reliability,
  fault tolerance, and performance
• Hard versus Soft Real-Time systems

4
Context, System Components, and Impact

• Specifications for time requirements
• Often distributed
• Most affected models Interaction diagrams where
  concurrency and time specifications are added

5
Concurrent Processing

• A task (process, thread) is a sequential
  component of a concurrent system
• Several tasks execute in parallel
• They execute asynchronously
• They need to communicate and synchronize their
  operations
• Many advantages but additional complexity and
  communication overhead

6
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

7
RT Modeling Issues

• Concurrency Definition of Active class (thread,
  process)
• Communication Message exchanges among active and
  passive objects, different communication modes
  (Asynchronous, Synchronous)
• Synchronization Integrity preserving mechanisms
  for shared data and task synchronization between
  active objects

8
Synchronization Issues

• Passive objects may be shared between active
  objects and there can be problems if they access
  them concurrently
• Threads may need to order their execution as,
  e.g., one thread might depend on another thread
  to make some preparation of the data it is using
• A deadlock may occur if a number of threads all
  are waiting for each other, e.g, two threads may
  need two communication ports and have managed to
  reserve one each
• Starvation A thread never gets to run due to the
  way thread priorities are set up

9
Active Classes and Objects

• Active versus passive objects
• Passive classes are normal classes
• An active object executes in parallel with other
  active objects and initiates actions by itself
• Active objects are the unit of concurrency
• Model the concurrent behavior of the real world
• Use the system resources as efficiently as
  possible
• Introduce all the issues related to concurrency,
  communication, synchronization

10
Active Objects in UML
ltltThreadgtgt Communication Supervisor
AnInstance Communication Supervisor

• Sometimes a package (subsystem) is controlled
  through an active object that makes the package
  run concurrently with other packages (processes)
• Active object often changes its behavior based on
  some internal state modeled with statechart

11
Sensors
12
Alarms
13
Internal Structure of Active Objects
14
Justifications for Active Classes

• Asynchronous events in the environment
• Periodic handling
• Time-critical functions
• Computational tasks in background

15
Using UML Tagged Values

• Explicit definition of a property as a name-value
  pair
• Define properties of models elements, e.g.,
  classes, associations.
• Add information about model elements, which will
  not be handled in the final system
• E.g., abstract for a class with virtual
  operations, recall their use in design patterns
• Can be used to define active object properties
  such as priority, concurrency properties, etc.

16
Tagged Values (II)

• Graphically a string enclosed with brackets
• nameOfTagged valueOfTag
• valueOfTag

17
Concurrency Property

• Definition of property through tagged value for
  concurrency
• Sequential
• The class/operation is intended only for use in a
  single thread of control
• Guarded
• The class/operation will work in the presence of
  multiple threads of control, but it needs an
  active collaboration of the threads to achieve
  mutual exclusion.
• Synchronized
• The class/operation will work in the presence of
  multiple threads of control the class itself
  handles this. This feature is being built in more
  modern programming languages, e.g., Java

18
Communication Between Active Objects

• Passive objects operation invocation,
  synchronous, data passed as parameters
• Active objects communicate through
• Method invocation
• Signal object queues
• Shared memory, e.g., monitor
• Rendezvous
• Remote method invocations (RMIs)
• Those are implementation techniques chosen in
  the object design phase
• During analysis and system design, when modeling,
  active objects communicate through events,
  signals, messages.

19
Events

• Events are drivers of RT system activity
• Occur in system or environment
• All events and the corresponding system reactions
  (behavior) must be defined (e.g., in statecharts,
  interaction diagrams)
• Events can be
• A condition becoming true (when() clause)
• The receipt of an explicit signal object
• The receipt of a method invocation
• Passage of time (e.g., sleep() call, time out
  event tm() form external timer, e.g., OS clock)

20
Signals

• UML named event that can be raised
• Signals have properties (i.e, priority, time
  handling requirements) gt modeled as objects,
  attributes
• Passed synchronously or asynchronously between
  objects
• Messages passing a signal object, instance of a
  ltltsignalgtgt class.
• All the signals in a real-time system are modeled
  in a class hierarchy
• Typical signal attributes are priority, time sent

21
Signal Class Hierarchy
22
Messages

• Communication between among passive and active
  objects
• Four different types of messages in a sequence
  diagram
• Synchronous
• Return
• Asynchronous
• Simple (flat)
• Used when we do not want to specify
  asynchronous/synchronous (for instance during the
  analysis)

23
Messages (II)

• Definitions
• Synchronous broadcast the transmitter is blocked
  and waits until the called object has finished
  processing the message
• Asynchronous broadcast the sender is not blocked
  and can continue executing
• During Analysis, a message is realized by an
  event (if the transition guard is true)
• During design, decisions will have to be made
  about how the dispatch of events is implemented
• Synchronous Simple method invocation may become
  a remote method invocation
• Asynchronous Signal object may be transmitted
  through a mailbox or FIFO queue

24
Conditional Messages
Reminder
obj1 Class1
obj2 Class2
condition event1

• The guard condition can be expressed (in OCL)
  using
• Source class attributes
• Parameters of previous messages
• Results from previous messages

25
Mutually Exclusive Conditional Messages
Reminder
Solution 1
Solution 2
26
Delay in Sequence Diagram
Reminder

• Non-negligible delay with respect with the
  overall dynamics of the application

A
B
A message
27
Timing Marks
Reminder
Phone
Exchange
lift receiver
a
b -a lt 1 sec.
dial tone
b
c - b lt 1 sec.
dial digit
c
.....
d
route
d - d lt 5 sec.
d
28
Summary

• Active and passive classes
• Internal Structure of active classes
• Tagged values and Stereotypes
• Event, signals, messages
• Delay, timing marks in sequence diagrams

29
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

30
Mutual Exclusion

• Context Requires exclusive access to a resource
  such as physical device or shared data (static
  object)
• Mechanism to ensure access is mutually exclusive
  get permission, use, release
• Semaphore objects in design aggregated with
  shared static objects
• Example shared sensor data repository
• Acceptable to have several reader tasks without
  mutual exclusion

31
Information Hiding Classes

• Semaphores are error-prone
• Synchronization is a global problem that concerns
  every task
• Solution one information hiding object that
  hides the details of synchronizing concurrent
  access to data
• Referred to as Monitor objects

32
Monitor Objects
write(in data)
read(out data)
aWriter
aReader
aMonitor
33
Thread Synchronization Issue

• Event synchronization Active objects synchronize
  operations without communicating data,
  asynchronous communication

34
Example Concurrent Robot Systems

• System of two robots pick-and-place, drilling
• Event synchronization collision, deposit part
  before drilling, drilling must be finished before
  part is removed
• The pick-and-place robot moves the part to the
  work location, moves out of the collision zone
  and then signals the event part ready
• This awakens the drilling robot which moves to
  work location and drills the holes
• After completion, it moves out of collision zone
  and then signals the event part completed
• After being awakened, the pick-and-place robot
  removes the part

35
Example UML Representation
36
Producer/Consumer Issue

• Active objects must synchronize their operations
  to exchange data
• A producer object must produce data before a
  consumer object can consume it
• If producer has produced data before consumer
  ready, producer has to held up data or buffered
  it
• Message communication serves two purposes
• Transfer data from producer to consumer
• Synchronization
• Asynchronous and synchronous communication

37
Asynchronous Communication

• Producer sends a message to consumer and
  continues execution
• As producer and consumer typically proceed at
  different speeds FIFO message queue can be used
• If no message in queue, consumer is suspended
• If queue is bounded and full, producer is
  suspended

38
Synchronous Communication

• With or without reply
• With producer sends a message to consumer and
  waits for reply
• Without producer waits for acceptance of
  message from consumer, then both the consumer and
  producer continue
• Consumer suspended when no message (no message
  queue)

39
Example

• Vision system has to inform a robot system of the
  type of part coming down a conveyor (e.g., car
  body frame)
• When robot finished its task (e.g., welding), it
  sends a doneReply to the vision system which can
  then check for the next part

40
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

41
Runtime Support for Concurrency

• Sequential languages, e.g., C, C, Fortran
• Concurrent languages, e.g., Ada, Java. Support
  constructs for task communication and
  synchronization
• With sequential languages, it is necessary to use
  the services of the OS kernel
• Typically priority preemption scheduling,
  inter-task communication, mutual exclusion, event
  synchronization using signals, interrupt
  handling, memory management

42
Built-in Support for Threads

• Pre-defined Thread class (java.lang.Thread) to
  inherit from
• Class MyThread extends Thread
• Superclass inherited by all active classes and
  contains process/thread operations run, start,
  stop, suspend, resume, interrupt, priority
  handling, etc.
• Mapping to operating system calls that implement
  these functions
• Abstract run operation implemented by subclass
• Typically implemented as an eternal loop reading
  input signals, interacting with other active
  classes, and performing necessary tasks

43
run()

• public void run()
• try
• for ()
• catch (InterruptedException e)
• Some eternal loop where synchronous and
  asynchronous messages are sent
• Signal and message queue classes (buffers) must
  be defined not pre-defined in Java

44
Thread life-cycle in Java
start() causes the thread to call its run()
method.
new Thread()
start()
Created
Alive
stop(), or run() returns
stop()
Terminated
The predicate isAlive() can be used to test if a
thread has been started but not terminated. Once
terminated, it cannot be restarted
45
Alive Substates
wait() also makes a Thread Non-Runnable, and
notify() Runnable
46
Thread Priority and Scheduling

• Each thread contains a priority attribute
• It is assigned an integer value when created
• By default it has the same priority value as the
  one that creates it
• The priority may be changed during the threads
  lifetime
• JVM will select the thread with the highest
  priority for execution
• If more than one to select from, then the
  selection is arbitrary (no guarantee of fairness)
• A thread will relinquish control when it yields,
  it is blocked (non-runnable) , or a thread with
  higher priority becomes runnable, or its time
  slice has expired

47
Java Monitors

• An easy way to ensure mutual exclusion, avoid
  race hazards
• Synchronized key word for methods and statement
  blocks
• A lock is associated with every object the Java
  compiler inserts code to acquire the lock before
  execution and release it afterwards
• If several methods can access an objects, they
  must be all synchronized to ensure mutually
  exclusive access to the object state -gt Monitor
• The lock implementation is embedded in the object
  itself

48
Usage of Synchronized

• class MyClass
• synchronized void aMethod()
• // do something
• class MyClass
• void aMethod()
• Synchronized(this)
• // do something

49
Condition Synchronization

• Java provides a thread wait queue per monitor
  object
• Class Object provides wait(), notify(),
  notifyAll() methods
• A thread calling wait()exits the monitor (becomes
  non-runnable) and allows other (runnable) threads
  to enter
• It should be used when a thread is temporarily
  unable to continue and let other threads proceed
• These threads eventually call notify() or
  notifyAll()to let other threads know they may
  proceed
• If, in these threads, the guard condition
  associated with the wait()while loop is false,
  the threads become runnable again

50
Guarded Action

• Java
• public synchronized void act() throws
  InterruptedException
• while (!cond) wait()
• // modify monitor data
• notifyAll()
• The while loop is necessary to retest the
  condition cond to ensure that cond is indeed
  satisfied when it re-enters the monitor.
• notifyall() is necessary to awaken other
  thread(s) that may be waiting to enter the
  monitor now that the monitor data has been
  changed.

51
Example

• A controller is required for a carpark, which
  only permits cars to enter when the carpark is
  not full and does not permit cars to leave when
  there are no cars in the carpark. Car arrival and
  departure are simulated by separate threads.

52
Arrivals and Departures Threads

• class Arrivals implements Runnable
• CarParkControl carpark
• Arrivals(CarParkControl c)
• carpark c
• public void run()
• try
• while(true)
• carpark.arrive()
• catch (InterruptedException e)

Similarly Departures which calls carpark.depart().
53
CarParkControl Monitor

• class CarParkControl
• protected int spaces
• protected int capacity
• CarParkControl(int n)
• capacity spaces n
• synchronized void arrive() throws
  InterruptedException
• while (spaces0) wait()
• --spaces
• notifyAll()
• synchronized void depart() throws
  InterruptedException
• while (spacescapacity) wait()
• spaces
• notifyAll()

54
Bounded Buffers

• Buffers are frequently used in concurrent systems
  to smooth out information transfer rates between
  a producer and a consumer
• Synchronized buffer
• Example keyboard interface object (driver) that
  supplies characters types at a keyboard to an
  editor program
• Some characters take longer than others to
  process, e.g., one that causes the screen to
  scroll or a keyboard command that invokes a
  formatting command
• It may be necessary to buffer characters from the
  keyboard to avoid loosing them (type-ahead buffer)

55
Typical Usage
56
Buffer Monitor (I)

• public class BufferImpl implements Buffer
• protected Object buf
• protected int in 0
• protected int out 0
• protected int count 0
• protected int size
• public BufferImpl(int size)
• this.size size
• buf new Objectsize
• public synchronized void put(Object o) throws
  InterruptedException
• // see next slide
• public synchronized Object get() throws
  InterruptedException
• // see next slide

57
Buffer Monitor (II)

• public synchronized void put(Object o) throws
  InterruptedException
• while (countsize) wait()
• bufin o
• count
• in(in1) size
• notify()
• public synchronized Object get() throws
  InterruptedException
• while (count0) wait()
• Object o bufout
• bufoutnull
• --count
• out(out1) size
• notify()
• return (o)

58
Producer/Consumer Threads

• class Producer implements Runnable
• Buffer buf
• String alphabet "abcdefghijklmnopqrstuvwxyz"
• Producer(Buffer b)
• buf b
• public void run()
• try
• int ai 0
• while(true)
• buf.put(new Character(alphabet.charAt(ai)))
• ai(ai1) alphabet.length()
• catch (InterruptedException e)

Similarly, Consumer calls buf.get().
59
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

60
Goals

• The system is structured into concurrent tasks
• The task interfaces and interconnections are
  defined
• We need systematic rules to map the objects of
  the system to a concurrent tasking architecture
• This is an essential part of design for RT,
  concurrent systems
• We discuss here some guidelines

61
I/O Devices

• An Asynchronous Input device generates an
  interrupt when it has produced some inputs that
  requires processing by the system
• An Asynchronous Output device generates an
  interrupt when it has finished processing an
  output operation and is ready to perform new some
  output.
• Passive I/O devices do not generate interrupts.
  I/O are either read/provided on a polled /
  periodic basis or on demand.
• I/O devices communicate with the system through
  communication links and protocols

62
Asynchronous I/O Devices

• For each asynchronous I/O device, an interface
  task (active object) is needed to interact
• The task is activated by an interrupt from the
  device (controller)
• Each interface object (from Analysis) to an
  asynchronous I/O device is mapped to an aperiodic
  task
• When activated, the task often has to respond to
  a subsequent interrupt within a constrained time
  to avoid any loss of data
• Input data may be processes by another task

63
Example
64
Periodic I/O Devices

• Periodic I/O device interface task
• Input device is polled on a regular basis
• Activated by a timer event, performs an I/O
  operation, waits for the next timer event
• Often used for passive sensors that need to be
  sampled periodically, e.g., temperature sensors
• Frequency of task samples depends on frequency of
  change in sensors value, e.g., brake sensor
  might need to be polled every 100 milliseconds

65
Example
66
Internal Periodic Tasks

• Activities that need to be executed on periodic
  basis
• Mapped as separate periodic task
• E.g., compute the distance traveled by the car or
  the current speed of the car in a cruise control
  system
• Similar to I/O periodic tasks

67
Internal Asynchronous Tasks

• Activities that need to be executed on demand
• Handled by asynchronous internal tasks
• Activated by the arrival of internal message from
  requesting task (instead of interrupts for I/O)
• E.g., Cruise control system Calculate
  adjustments of throttle based on desired and
  current car speed

68
Example
69
Control Tasks

• For state dependent and coordinator control
  objects
• Assuming a control object is modeled by a
  statechart with no concurrency, a task can
  perform the control activity
• This is referred as a control task
• E.g., a state dependent control object Cruise
  Control is structured as a task

70
Example
71
User Interface Tasks

• The users interaction with the system is a
  sequential activity and is handled by a user
  interface task.
• A user interface object in Analysis is mapped to
  a user interface task
• Such a task usually interfaces with various I/O
  devices (their controller), e.g., keyboards,
  output display, mouse, that are typically handled
  by the operating system.
• In modern, windows operating systems, users are
  involved in several sequential activities There
  is one user task for each window and each of them
  can spawn other tasks (e.g., printing)

72
Example
73
Task Priorities

• A time-critical task is a task that needs to meet
  hard deadlines
• Such tasks need to run at a high priority
• They are needed in most real-time systems
• Asynchronous I/O interrupt handling is usually
  time critical we do not want to miss interrupts
• E.g., Furnace Temperature Control object that
  makes sure the furnace does not go over 100 C
  (Switch off). Must execute within pre-defined
  time if the furnace content is not to be damaged
• It is important that low and high priority
  activities not be merged into common tasks

74
Task Clustering

• The above strategy may lead to a large number of
  tasks, potentially resulting in increased system
  complexity and execution overhead
• We use task clustering criteria to reduce the
  number of tasks
• Temporal clustering
• Sequential clustering
• Control clustering
• Mutually exclusive clustering

75
Temporal Clustering

• Tasks may be activated by the same event, e.g.,
  timer
• If there is no sequential dependency between
  them, they can be executed in any arbitrary order
  within the same task
• Tasks activated by the same periodic event, with
  the same frequency, can often be grouped into the
  same task

76
Example (1)
77
Example (2)
78
Sequential Clustering

• Certain candidate tasks may need to be carried
  out in a sequential order
• The first task in the sequence is triggered by an
  asynchronous event or periodic event
• The other candidate tasks are then executed
  sequentially after it
• Sequentially dependent tasks may be grouped into
  a task

79
Example (1)
80
Example (2)
81
Control Clustering

• A control object which executes a sequential
  statechart is mapped to a control task
• The control task may be combined with other
  objects that execute actions triggered by or
  activities enabled by the statechart
• State-dependent actions
• State-dependent activities

82
Example (1)
83
Example (2)
84
Mutually Exclusive Clustering

• When there is a group of tasks where, because of
  constraints in the application, only one of the
  tasks is eligible to be executed at any one time
• These tasks may be grouped into one task

85
Example (1)
86
Example (2)
87
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example (House Alarm System)
• Summary

88
House Alarm System CD
89
Sequence Diagram
90
Collaboration Diagram
91
State Diagram with Concurrency
92
Part VIII Real Time Aspects, Concurrency and UML

• Basic Definitions (reminder)
• UML Modeling Concepts for Concurrent, Real-Time
  (RT) Aspects
• Design mechanisms to address concurrency
• and Java implementation
• Task Architecture
• Example
• Summary

93
Summary of RT Modeling in UML

• Time
• Time specifications and constraints are best
  defined in sequence diagrams, where time is the
  primary aspect
• Concurrency
• Described as active classes, whose properties
  (e.g., priority for scheduling) are described by
  tagged values. Concurrent transitions in
  statecharts.
• Asynchronous events
• Asynchronous messages in interaction diagrams
  (sequence or collaboration)
• Synchronization
• Property of class or operation (e.g., concurrency
  property) or classes defining mechanisms of
  semaphores, monitor, etc. (e.g., information
  hiding object)