1. Real-time systems and the UML Morgan Björkander (mbj@telelogic.com)

2. 2 Outline Setting the stage UML 2.0 –RFPs –Influences –Issues Real-time UML On the horizon

3. 3 Application domains Soft real-time systems –event-driven –asynchronous –concurrent –distributed Application areas –telecom –automotive –aerospace

4. 4 The Unified Modeling Language™ UML is managed by the Object Management Group (OMG) –the language makes no provisions for real-time The real-time analysis and design working group –promotes real-time issues for UML –uses profiles to tailor the capabilities of UML standardization work

5. 5 Application Some concerns Architecture Performance Concurrency Scheduling Time Resources

6. 6 Real-time profiles of the UML UML Performance Scheduling Time Fault tolerance QoS Large-scale systems UML 2.0 - SDL - UML-RT (ROOM)

7. 7 UML 2.0 Infrastructure OCL Diagram Interchange - Kernel language (core) - Extensions (profiles) Superstructure - Architecture (scalability and component-based-development) - Workflow (state machines and activity graphs) - Interaction (augmentation with Message Sequence Charts) - Action semantics (integration) - Collaboration (simplification) - Relationships

8. 8 Inspiration sources for UML 2.0 SDL (Specification and Description Language) –architecture –state machines –executability MSC (Message Sequence Charts) –decomposition –variations (inline expressions) –references –organization ROOM (Real-time Object- Oriented Modeling) –architecture (UML-RT) UML 2.0 SDL MSC

9. 9 Visual modeling 1. Round-trip engineering –consistency between models, code, and application –maintenance code is king 2. Models with code inserted –fragmentation –target language dependent portability

10. 10 Add executability 3. Executable models Visual modeling Behavioral modeling –action language –data model Run-time semantics Configuration –build scripts –realization mappings deployment

11. 11 Visual software engineering Express functionality in the model –check the correctness of the model validation simulation verification testing Transform the model into code –forward engineering round-trip superfluous reverse engineering required to capture legacy and integrations –automatic and complete configurable –target language independent transport mechanisms selectable –the documentation is the model is the code iteration

12. 12 A logical component (agent, capsule) –is an active class –provides encapsulation a ”black box” hierarchical decomposition internal structure behavior –has interfaces Used as building blocks –top down divide and conquer –bottom up like lego Logical components

13. 13 Encapsulation Logical components use connection points (gate, port) –to provide bi-directional access points without exposing the internal structure –each connection point provides its own view of the logical component The connection points specify contracts in the form of interfaces (interface, protocol, protocol role) –implemented interfaces services that are realized by the logical component –required interfaces services that others must implement ATM «interface» Display «interface» Keyboard «interface» Log Display Customer Keyboard Operator Log, Verify, Transaction Display, Shutdown

14. 14 Connection requirements Connection points specify how instances of logical components may be connected to each other (channel, connector) –it it only possible to connect logical components that have matching required and implemented interfaces The connections describe communication paths :ATM Operator Visa:Bank Terminal C1 Bank Terminal Log, Transaction Display MC:Bank Operator Terminal C2

15. 15 Internal structure and behavior Bank S1 S2 e2 e3 e1 Terminal Log, Transaction Display Bank Terminal Log, Transaction Display ctrl(1..1): Controller db(1..1): DataBase LogATM Log

16. 16 Dynamic decomposition aspects A state machine controls the internal structure –may be implicit –interacts with contained logical components as well as external logical components Initialization of internal structure –start configuration Life-cycle dependencies –creation –termination Multiplicity constraints Switch basic(0..*): Call service(1..1): Library Initiate Trigger Control Setup Phone

17. 17 Communication mechanisms To-based communication –relies on object-references –interfaces provide typed object references to logical components –object references may be obtained through creation of logical components parameters of received messages naming service (or similar) Via-based communication –relies on structure –usually via connection points // pseudo code: to Client aClient =...; send sig1 to aClient; aClient.send(sig1); // pseudo code: via Port aPort =...; send sig1 via aPort; aPort.send(sig1);

18. 18 Transition-centric state machines Dummy S1 S2 e2 e3 e1 state-centric view S1 S2 e1e2 S2 e3 S1 i = i + 1 e1 Dummy e2 i = 0 e3 i [5][else]

19. 19 Sequence diagrams Decomposition –collapsed views Variations (inline expressions) –parallelism, alternatives –loops, optionality, exceptions Sequence diagram references High-level sequence diagrams –organizing sequence diagrams seqinit abc

20. 20 Performance, scheduling, and time The first of the real-time UML profiles –Initial submission August 2000 –Revised (final) submissions due this summer Major areas of concern –Schedulability analysis the ability of a system to meet its deadlines –Performance analysis the response of the system under different conditions –Time –Concurrency –Realization mappings deployment

21. 21 Realization mappings Functions Logical view Engineering view

22. 22 Quantitative aspects There are many quantitative concerns when a logical viewpoint is mapped on top of an engineering viewpoint –Will we get the right performance? –How much memory can we afford to use? –Is the throughput sufficient? –Do we need additional resources? Should we add resources or cut functionality? These quantitive aspects are captured as Quality of Service (QoS)

23. 23 On the horizon: Embedded UML A UML profile for hardware and software co-design Delay implementation decisions –virtual integration by focusing on functionality Several system-level design languages could be brought together by UML –SystemC, SpecC, etc. These languages primarily provide abstractions of existing programming languages to model ports, interfaces, channels, state machines, etc. –require additions/modifications to the UML abstractions communication mechanisms (buses, broadcasts, synchronization) realization mappings (deployment) non-functional requirements ($) Visual Systems Engineering

24. 24 On the horizon: Testing A UML profile for testing –UML notation (primarily sequence diagrams) strong relationship to TTCN-3, which is a language dedicated to testing conformance, robustness, regression, system, and integration testing –Verification of functionality of object-oriented/component- based systems, primarily from a conformance point of view –Definition of test cases, and how they are collected in test suites –Setting up, executing, and evaluating tests

25. 25 Now it is your turn Questions