Real-time systems and the UML

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

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

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

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. Application Some concerns Architecture Performance Concurrency Scheduling Resources Time

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

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

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. Visual modeling • Round-trip engineering • consistency between models, code, and application • maintenance • code is king • Models with code inserted • fragmentation • target language dependent • portability

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

11. Visual software engineering iteration • 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

12. Logical components • 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

13. Customer Keyboard Display Display, Shutdown Operator Log, Verify, Transaction Encapsulation «interface» Display • 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 «interface» Keyboard «interface» Log ATM

14. :ATM Operator Operator C2 C1 Terminal Display Terminal Terminal Log, Transaction Visa:Bank MC:Bank 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 Bank

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

16. Dynamic decomposition aspects Switch • 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 Setup Switch Initiate Phone basic(0..*): Call Phone Control Trigger service(1..1): Library

17. 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 Communication mechanisms // pseudo code: via Port aPort = ...; send sig1 via aPort; aPort.send(sig1); // pseudo code: to Client aClient = ...; send sig1 to aClient; aClient.send(sig1);

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

19. seq init a b c Sequence diagrams • Decomposition • collapsed views • Variations (inline expressions) • parallelism, alternatives • loops, optionality, exceptions • Sequence diagram references • High-level sequence diagrams • organizing sequence diagrams

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. Realization mappings Functions Logical view Engineering view

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. 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. 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. Now it is your turn • Questions