An Introduction to Rational Rose Real-Time

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: • 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: • description of the implementation modules and their dependencies (used mainly by developers) • contains component, package diagrams • Deployment View: • shows the physical deployment ofthe 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 • System • 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 • Capsulesare 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. Ports Capsules: Active Objects

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 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 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. Package Node Component 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 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. cpeng@site.uotawa.ca SITE, University of Ottawa

26. A Demo System TomJerry (Cont’d) • The system behaviour is as follows: • Initially, Tom sends message RUCat to Jerry • Jerryreplieswithmessage No to Tom on receiving RUCat. • Tom then sends message RUMouse to Jerry having received No. • Jerryreplieswithmessage 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 TomJerryTop level capsule contents TomJerry Structure Diagram

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

31. A Demo System TomJerryJerry’s State Diagram Jerry’s State Diagram

32. A Demo System TomJerryExecution Result Running the Model

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