1

TURNING CLOCKWISE: USING UML in the REAL-TIME DOMAIN

Sahitya Gupta

Wei Xiong

2

Introduction

Physical world is the root cause of the complexity of real-time systems.

Persistent demand for always increasing functionality.

Solution: Modeling. It is simply a form of abstraction that facilitates both problem understanding and problem resolution.

FOR MORE INFO...

3

Real-Time Systems and Object Paradigm

A real time system is a software system that maintains an ongoing and timely interaction with its environment.

In real time systems the dominant feature is the system itself and not its behavior which is changing continuously. This makes it a perfect fit for an object-oriented model.

Misconceptions of object technology have been reduced or eliminated

FOR MORE INFO...

4

Requirements for Modeling Real-Time Systems

Some of the requirements in the real-time systems are deriving accurate predictions of key attributes of actual system like response time, throughput, availability, computing delays and resources as statistical quantities, need to model engineering infrastructure, structure and behavior of software. They are classified as Infrastructure modeling requirements, Behavior modeling requirements and Structure modeling requirements.

Infrastructure modeling requirements.This set of requirements include representing resources by its attributes so as to analyze and make predictions about the system depending on the attributes values. Also individual memory and processing requirements of objects in a system are necessary for performance modeling.

FOR MORE INFO...

5

Requirements for Modeling Real-Time Systems (Cont’d)

Behavior modeling requirements.Unpredictability and Concurrency of real-world event leads to an event-driven (suitable for modeling discrete behaviors in which concurrent events occur asynchronously) and time-driven (suitable for continuous or periodic inputs) styles to specify behavior of the system instead of the sequential paradigm used for procedural programming.

Structure modeling requirements.There is a need for modeling complex high-level runtime structures as well as dynamic runtime structures (in which objects and links are continuously being created and destroyed) in a real-time system.

FOR MORE INFO...

6

Background (UML)

The Unified Modeling Language is a third-generation method for specifying, visualizing, and documenting the artifacts of an object-oriented system under development.

It can be used with many processes, throughout the development life cycle, and across different implementation technologies.

FOR MORE INFO...

7

Background (UML Diagrams)

Static Views Use Case Diagrams Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams

FOR MORE INFO...

8

Use Case Diagrams

Use case

Actor

Actor

SystemFOR MORE INFO...

Box Office

Buy tickets

Buy subscription

Survey sales

Supervisor

Clerk

Kiosk

9

Class Diagram

Reservation Class Name

Date: Date Attributes…

Methods…

Class Class

Association (1:1, 1:*)

Association

FOR MORE INFO...

Customer

Name: StringPhone: String

add(name,phone)

* 1ownerpurchased

Rolenames

10

Component Diagram

Component interfaces

Component

Usage dependency

FOR MORE INFO...

CreditCardCharges

CreditCardCharges

Charge

11

Background (UML Diagrams)

Dynamic Views Sequence Diagrams Collaboration Diagrams Activity Diagrams State-chart Diagrams

FOR MORE INFO...

12

Sequence Diagram

FOR MORE INFO...

Object Object Object

Lifeline (active)

messages

Request(query)

Reply(result)

Request(query)

Request(query)Request(query)

Reply(result)

Reply(result)Reply(result)

13

Collaboration Diagram

FOR MORE INFO...

link

Active Object

Object

Object

messages

kiosk

ticketSeller

1: request(count, performance)

4: offer(seat-list)

5: buy(seats)

8: confirm(seats, cost)

messages

14

Using UML for Modeling Real-Time Systems

UML is a general-purpose modeling language that provides an extensive conceptual base for broad spectrum of application domains. Real-time modeling can be fully accommodated by specializing appropriate base concepts. Any practitioner with general UML background will be able to understand a model based on specializations even without knowledge of added semantics.

FOR MORE INFO...

15

Modeling the Engineering Infrastructure

Modeling resources and system services Most resources can be modeled by appropriate stereotypes of the

general UML concepts of classifier or class Each resource provides some type of specialized functionality required

by the logical elements that it supports A resource may support one or more elements of a logical model while

a model element may require the support of multiple resourcesElement-to-resource mapping A real-time system is frequently designed to run on different hardware

configuration It is convenient to combine a mutually consistent set of element-to-

resource mappings of a given logical model into a single package, called resource-mapping package which relates a logical model to a particular hardware configuration

FOR MORE INFO...

16

Modeling the Engineering Infrastructure (cont’)

Resource-to-value mapping The association of resource attribute values (processor speeds, queue

sizes) to the resources is called resource value package This is required for quantitative analysis of a model

Modeling time and timing facilities A base type, Time, is defined in the standard of UML, but its semantics

are not specified so that applications are free to define different models and representations of time

All timing facilities, suck as clocks, calendars, and timing services can be modeled directly as resources.

A time-driven behavior may cause an event-driven behavior

FOR MORE INFO...

17

Modeling Real-Time Behavior

The fundamental notion of concurrency is modeled using the “active” object concept of UML due to the fact that different situations may be resolved very differently and no single approach can satisfy all possible real-time applicationsAn active object is an object that owns a thread of control and may initiate control activity. A passive object is one that holds data but that does not initiate control.

Processes and tasks are traditional kinds of active objects.

– Event-driven (reactive) behavior modeling– Time-driven behavior modeling– Object interaction modeling

FOR MORE INFO...

18

Event-driven (Reactive) Behavior Modeling

The underlying model is of an entity that performs a transition from one quiescent state to another in reaction to the arrival of an event

FOR MORE INFO...

ReadyToSend A

ReadyToSendB

SendingA SendingB

ackB/

SendingB

ackA/

Send/A

Uninitialized

Initialized

Operational

Error

Reset/

Error/

Data/

Start/Stop/

Reset/ Data/

Functional behavior Control behavior

19

Event-driven (Reactive) Behavior Modeling

A problemTwo different state machines that describe different aspects of the behavior of the same object may cause problems

Solution Compose the two state machines by combining them in two peer

concurrent states Use hierarchical states

FOR MORE INFO...

20

Time-Driven Behavior Modeling

Time-driven behavior is based on periodic activities, it is not suitable for modeling using the object paradigm

But control activities are inherently event-driven (the occurrence of failures, the arrival of operational data, etc.) Even in case of time-driven behavior, it is appropriate to use state machines at the highest level of description of an object

Time-driven can converts to event-driven

FOR MORE INFO...

21

Object Interaction Modeling

It is useful to specify and view the emergent behavior of a set of collaborating objects

The UML provides a number of facilities for this purpose: sequence diagramsprotocolsinteraction diagramsactivity diagrams

FOR MORE INFO...

22

Protocol

A protocol specifies a set of valid behaviors (signal exchanges) between two or more collaborating objects.

To make such a dynamic pattern reusable, protocols are de-coupled from a particular context of collaborating object and are defined instead in terms of abstract entities called protocol roles. A protocol role represents the activities of one participant a protocol. It is defined by a set of incoming signals, a set of outgoing signals, and optional behavior specification.

Protocols are reusable.

FOR MORE INFO...

23

Modeling Real-Time Structure

Runtime structures represent the architectural core of a real-time system.

A well-designed architecture will allow a system to easily accommodate evolutionary growth and prolong its useful lifetime

UML applies collaboration diagrams for specifying architectures

FOR MORE INFO...

24

Architectural Modeling

The central idea is to capture architectural specifications in a formal way

Advantages Architectural models can be formally analyzed for consistency and

completeness The models are executable and allow early and precise assessment of

the validity of different architectural approaches Allows implementations to be derived directly from architectural

specifications using automatic code generation

UML collaboration diagrams are applied for specifying complex real-time architectures

FOR MORE INFO...

25

Capsule, Port and Connector

PortsConnector

Capsule

The central architectural entity is capsule. Capsule are complex, potentially concurrent, and possibly distributed active architectural components.

A port is a physical part of the implementation of a capsule that mediates the interaction of the capsule with the outside world. It is an object that implements a specific interface.

Connectors capture the key communication relationships between capsules.

FOR MORE INFO...

26

Collaboration and Roles

To understand the mechanisms used in a design, it is important to see only the objects and the messages involved in accomplishing a purpose or a related set of purposes. A collaboration is a set of participants and relationships that are meaningful for a given set of purposes.

A collaboration is shown as a graph of class references and association references. Each reference is a role of the collaboration; that is, each entity is playing a role within the context of the collaboration, a role that is only part of its full description.

The names of the objects represent their roles within the collaboration. A collaboration is a prototype; in each use of the collaboration the roles are bound to actual objects.

FOR MORE INFO...

27

Collaboration Diagram

Collaboration diagrams represents a collaboration, which is a set of objects related in a particular context, and an Interaction, which is a set of messages exchanged among the objects within a collaboration to effect a desired operation or result.

FOR MORE INFO...

28

Strengths

This paper highlights that UML, which is a common industry standard, can be easily adopted and used to model a real-time system thus eliminating a need of learning and using a new tool or language.

FOR MORE INFO...

29

Weaknesses

Does not convey the scope and limitations of UML with respect to embedded systems.

FOR MORE INFO...

30

Relevance to Embedded Software

Currently modeling is one of the key issues in the development of any system including an embedded system. It plays a key role in the overall system design. A perfectly modeled system leads to lesser discrepancies in the developed system.

FOR MORE INFO...