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

2. Overview
Rose RealTime is a software development environment tailored to the demands of real-time software.
Developers use Rose RealTime 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.

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

4. UML Views Use-Case View: Logical View:
describes system functionality as perceived by external actors which interact with the system (users or other systems)
Logical View:
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.

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

6. Rational Rose Real Time – User Interface

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

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

9. Capsules
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:
Capsule can have attributes.
Capsules may also participate in dependency, generalization, and association relationships.
Differences between capsules and classes:
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.

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

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

12. Capsules: Active Objects
Ports

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

14. Classification of ports
Visibility
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
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
Wired - Wired ports must be connected via a connector to other ports in order to send messages.
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.

15. Classification of ports (Cont’d)
Termination
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).

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

17. Capsules: Behavior Optional hierarchical state machine S1 S1 S1 S2 S2
transitionS1toS2: {
port2.send(m1); port3.send(m2); … };
message arrival
on port1 triggers transition S1 to S2 S1 S1 S1 S2 S2 S3

18. State Diagram
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
States
Transitions

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

20. Transitions A transition has the following parts:
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.

21. 3. Component View
A component diagram shows the dependencies among software components.
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.
A component diagram has only a type form, not an instance form.

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

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

24. 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.
Node
Task
Component
Package
Connection
Task
Active Object

25. A Demo System TomJerry
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.
SITE, University of Ottawa

26. A Demo System TomJerry (Cont’d)
The system behaviour is as follows:
Initially, Tom sends message RUCat to Jerry
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.

27. A Demo System TomJerry (Cont’d)
We consider the simple communication system consisting two entities.
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:
Tom->Jerry: RUCat and RUMouse
Jerry->Tom: Yes and No

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

29. A Demo System TomJerry Top level capsule contents
TomJerry Structure Diagram

30. A Demo System TomJerry Tom’s State Diagram
Initial:
timer.informIn(RTTimespec(2,0));
Tom’s State Diagram

31. A Demo System TomJerry Jerry’s State Diagram

32. A Demo System TomJerry Execution Result
Running the Model

33. References CIS721 – Lecture 6 PPT – Dr. Neilsen
Example borrowed from SITE, University of Ottawa