An Introduction to Rational Rose RealTime Abhishekh Padmanabhan

An Introduction to Rational Rose Real-Time Abhishekh Padmanabhan CIS 798 Presentation 2

Overview l l Rose Real. Time is a software development environment tailored to the demands of realtime software. Developers use Rose Real. Time to create models of the software system based on the Unified Modeling Language constructs, to generate the implementation code, compile, then run and debug the application.

Rose Real. Time Software Development Lifecycle What dose user need? Use Case Views in Rational Rose Real-Time How to design system? Logical View Component View How to build system? Views in Real World How to deploy the products? Deployment View

UML Views l Use-Case View: l l describes system functionality as perceived by external actors which interact with the system (users or other systems) Logical View: l l describes how system functionality is provided within the system - mostly used by developers describe the static structure and dynamic behavior and other properties such as persistence and concurrency. static structure: described by class (object) diagrams dynamic behavior: described by state, sequence, collaboration and activity diagrams.

UML Views l Component View: l l l description of the implementation modules and their dependencies (used mainly by developers) contains component, package diagrams Deployment View: l l shows the physical deployment of the system (processors, devices) and their interconnections contains deployment diagrams.

Rational Rose Real Time – User Interface

1. Use Case l Describe System functionality in horizontal way l l Actors System Use Cases (Services) Relationships

2. Logical View l Logical View involves various capsules, classes, and protocols to make up the design solution for the problem l l l Capsules Classes Protocols Notes: In this slide, we only introduce capsules.

Capsules l l Capsules are the fundamental modeling element of real-time systems. A capsule represents an independent flow of control in a system. Similarities of capsules to classes: n n l Capsule can have attributes. Capsules may also participate in dependency, generalization, and association relationships. Differences between capsules and classes: n n Capsule structure: represented as a network of collaborating capsules (a specialized UML collaboration diagram). Capsule behavior: triggered by the receipt of a signal event, not by the invocation of an operation.

Real-Time UML Constructs l For Modeling Structure l l capsules (capsule classes) ports connectors For Modeling Behavior l l l protocols state machines time service

Capsules (Cont’d) l Two viewpoints on capsules? l Structure Diagram l l The structure diagram captures the interface and internal structure of the capsule in terms of its contained capsules and ports. State Diagram l The state diagram captures the high-level behavior of the capsule. (States can be hierarchical and nested).

Capsules: Active Objects Ports

Structure Diagram l Three main elements in a structure diagram l l Capsules Ports - l Public | Protected Wired | Not-wired Relay | End Connectors

Classification of ports l l Visibility l Public - Public ports are ports that are part of a capsule's interface. These ports may be visible both from outside the capsule and inside, e. g. interface ports l Protected - Protected ports are used to connect capsules to contained capsule roles. These ports are not visible from the outside of a capsule since they are not part of the capsule's interface, e. g. Timer Ports. Connector type l Wired - Wired ports must be connected via a connector to other ports in order to send messages. l Non-wired - Non-wired ports are used to model dynamic communication channels. These ports cannot be connected with connectors to other ports. For example, in client/server models, some ports may be declared but only activated when needed.

Classification of ports (Cont’d) l Termination l l Relay - Relay ports are by nature implicitly public and wired. They are used to model connections that funnel signal events directly to protected capsule components without being processed by the capsule itself. End - End ports can be public or protected, wired or non-wired. Messages sent to an end port can be processed directly by the capsule's behavior (state machine).

Connectors l Connectors really capture the key communication relationships between capsule roles.

Capsules: Behavior l Optional hierarchical state machine message arrival on port 1 triggers transition S 1 to S 2 transition. S 1 to. S 2: { port 2. send(m 1); port 3. send(m 2); … }; S 1 S 2 S 3

State Diagram l l l A state diagram shows the sequence of states that an object or an interaction goes through during its life in response to received messages, together with its responses and actions. State diagrams use state machines. A state machine is a graph of states and transitions l l States Transitions

States l A state has the following parts: l l Name Entry/Exit actions - Actions that are executed on entering and exiting the state.

Transitions l A transition has the following parts: l l l Trigger - With the exception of the initial transition all behavior in a state machine is triggered by the arrival of events on one of an object's interfaces. Therefore, a trigger defines which events from which interfaces will cause the transition to be taken. Guard Condition - Each trigger can have a boolean expression associated with it which will be evaluated before the transition is triggered. This is referred to as a guard condition. Actions - The actions in a behavior are where an object does work.

3. Component View l A component diagram shows the dependencies among software components. l Some components exist at compile time, some exist at link time, some exist at run time, and some exist at more than one time. The run-time component in this case would be an executable program. l A component diagram has only a type form, not an instance form.

Component Diagram Billing. exe Billing System KATS. exe User. dll Course. dll User Course Student Course Offering Professor

4. Deployment View l Nodes may contain component instances, which indicates that the component runs on the node. l The deployment diagram provides a basis for understanding the physical distribution of the run-time processes across a set of processing nodes.

Deployment Diagram Notation Nodes are of primary importance on a deployment diagram because they represent processors, sensors, actuators, displays, or any other physical object of importance to the software. Task Package Connection Task Active Object Component

A Demo System Tom. Jerry l Tom is a cat and Jerry is a mouse. They meet one day on Internet. Tom wants to know whether Jerry is a cat or not by asking him/her some questions. Example from online resource. cpeng@site. uotawa. ca SITE, University of Ottawa

A Demo System Tom. Jerry (Cont’d) l The system behaviour is as follows: l l l Initially, Tom sends message RUCat to Jerry replies with message No to Tom on receiving RUCat. Tom then sends message RUMouse to Jerry having received No. Jerry replies with message Yes to Tom having received RUMouse. Then Tom knows whether or not Jerry is a cat.

A Demo System Tom. Jerry (Cont’d) l We consider the simple communication system consisting two entities. l l l Entity 1 is named as Tom. Entity 2 is named as Jerry. The signals used in the common communication protocol between Tom and Jerry are: l l Tom->Jerry: RUCat and RUMouse Jerry->Tom: Yes and No

A Demo System Tom. Jerry (Cont’d) Top Level Capsule Second Level Capsule Communication Protocol Overall Logical View

A Demo System Tom. Jerry Top level capsule contents Tom. Jerry Structure Diagram

A Demo System Tom. Jerry Tom’s State Diagram Initial: timer. inform. In(RTTimespec(2, 0)); Tom’s State Diagram

A Demo System Tom. Jerry’s State Diagram

A Demo System Tom. Jerry Execution Result Running the Model

References l CIS 721 – Lecture 6 PPT – Dr. Neilsen l Example borrowed from SITE, University of Ottawa