Fr 5 January 22th-26th, 2007, Munich/Germany Real Time UML Bruce Powel Douglass Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com RealReal--TimeTime UMLUML Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division www.telelogic.com/modeling groups.yahoo.com/group/RT-UML 1 Real-Time UML © Telelogic AB Basics of UML • What is UML? – How do we capture requirements using UML? – How do we describe structure using UML? – How do we model communication using UML? – How do we describe behavior using UML? • The “Real-Time UML” Profile • The Harmony Process 2 Real-Time UML © Telelogic AB What is UML? 3 Real-Time UML © Telelogic AB What is UML? • Unified Modeling Language • Comprehensive full life-cycle 3rd Generation modeling language – Standardized in 1997 by the OMG – Created by a consortium of 12 companies from various domains – Telelogic/I-Logix a key contributor to the UML including the definition of behavioral modeling • Incorporates state of the art Software and Systems A&D concepts • Matches the growing complexity of real-time systems – Large scale systems, Networking, Web enabling, Data management • Extensible and configurable • Unprecedented inter-disciplinary market penetration – Used for both software and systems engineering • UML 2.0 is latest version (2.1 in process…) 4 Real-Time UML © Telelogic AB UML supports Key Technologies for Development Iterative Development Real-Time Frameworks Visual Modeling Automated Requirements- Based Testing Model Execution Model-Code Associativity 5 Real-Time UML © Telelogic AB UML 2 Diagrams Structure Activity Class Diagrams Diagrams Diagrams Statechart Diagrams Object Behavioral Diagrams Diagrams Structural Info Flow Diagrams Functional Diagrams Deployment Diagrams Diagrams Interaction Diagrams Use Case Component Diagrams Diagrams Timing Communication Diagrams Diagrams Sequence Diagrams 6 Real-Time UML © Telelogic AB How does UML apply to Real-Time? • Real-Time UML is standard UML – “UML is adequate for real-time systems” Grady Booch 1997 – “Although there have been a number of calls to extend UML for the real-time domain … experience had proven this is not necessary.” Bran Selic, 1999 (Communications of the ACM, Oct 1999) • Real-time and embedded applications – Special concerns about quality of service (QoS) – Special concerns about low-level programming – Special concerns about safety and reliability • Real-Time UML is about applying the UML to meet the specialized concerns of the real-time and embedded domains 7 Real-Time UML © Telelogic AB How do we capture requirements using UML? Use Case Modeling 8 Real-Time UML © Telelogic AB Why Use Case Modeling? • Use Case modeling is all about describing WHAT the system will do, – At a high level – Analysis NOT Design – From the perspective of the USER • Use Cases Scope the System – The developers need to minimally develop the functionality described by the use cases. – Users should not expect more/less/different functionality than is described by the use cases • Use Cases organize requirements • Provide a means to map requirements into interactions of the structural pieces of the system called collaborations • Can be used for project planning 9 Real-Time UML © Telelogic AB Association Basic Use Case Syntax Use Case { optical images 640x480 res at 30 fps} Constraint Actor 10 Real-Time UML © Telelogic AB An Actor ... • Is an object outside the scope of the system of concern that interacts with the system – May be a hardware device – May be a legacy system – May be a human user • May be generalized 11 Real-Time UML © Telelogic AB A Use Case … • Is a named operational capability of a system – Why the user interacts with the system • Returns a result visible to one or more actors • Does not reveal or imply internal structure of the system 12 Real-Time UML © Telelogic AB A Use Case Is Used to • Capture requirements of a system – Functional requirements Functional • What the system does requirements – Quality of Service (QoS) are modeled • How well the system does it: as use cases, – Worst-case execution time sequence diagrams, – Average execution time activity diagrams or – Throughput statecharts – Predictability – Capacity – Safety QoS Requirements are – Reliability modeled as constraints 13 Real-Time UML © Telelogic AB System Use Cases 14 Real-Time UML © Telelogic AB Identifying Use Cases • Answer questions such as: – What are the primary and secondary operational functions of the system? – With what must the system interface? – Why is the system being built? If it is replacing something else, why? • Play each actor in turn and ask – What do I want out of this system? – What do I want to do to this system? • Identify: – Capabilities (use cases) – Other context participants (actors) 15 Real-Time UML © Telelogic AB Use Cases Are Not .. • A functional decomposition model of the system internals – that’s HOW – They do not capture HOW in any way – They do not capture anything the Actor does outside of the System – How do I capture HOW? • Use Object Model Diagrams to capture Static Structure • Use Sequence Diagrams and State Diagrams (or Activity Diagrams) to capture Dynamic Behavior 16 Real-Time UML © Telelogic AB Good Example: Cardionada 17 Real-Time UML © Telelogic AB Bad Example: Cardionada-NADA Wrong Actors Not primary capabilities Assumes a design 18 Real-Time UML © Telelogic AB Things to avoid • Single messages are not use cases! – Use cases represent a large number of different scenarios – Each scenario has many (possibly hundreds) of messages • Low-level interfaces are not use cases – Low-level interfaces are means to realize use cases – LLI’s are subsumed within actual use cases – A use case should map to a reason for the user to interact with the system, not the means by which it occurs 19 Real-Time UML © Telelogic AB Use Cases Lead To Object Discovery • Use cases define requirements – functional –QoS • Use case are detailed – sequence diagrams – text and text annotations – statecharts • Use cases are “black box” • Use cases are realized by collaborations A collaboration is a set of object roles working together to achieve a higher-level function 20 Real-Time UML © Telelogic AB Use Case Relations • Generalization – One use case is a more specialized or refined version of another • «includes» – One use case includes another • «extends» – One use case provides an optional extension of another The point is to capture requirements not functionally decompose the system internals! 21 Real-Time UML © Telelogic AB Detailing Use Cases • By operational example – Use scenarios captured via sequence diagrams • Each scenario capture a specific path through the use case – Partially constructive – Infinite set, so you must select which are interestingly different – Non-technical users can understand scenarios • By specification – Use an informal (e.g. English) and/or formal (e.g. statechart) to represent all possible paths – Fully constructive – Non-technical readers might not understand formal specs 22 Real-Time UML © Telelogic AB Use Case Description • Use Case Description Structure –Name – Purpose • May be written informally (“The purpose of the capability is to…”) – Description • May be written semi-formally (“The system shall…”) • May be a hyperlink to a textual document – Preconditions • What is true prior to the execution of the capability? – Postconditions • What does the system guarantee to be true after the execution of the use case? – Constraints • Additional QoS requirements or other rules for the use case 23 Real-Time UML © Telelogic AB Description Example 24 Real-Time UML © Telelogic AB Information Flow Requirements • As part of analysis, it is common to want to understand information flow and processing required. – Information Flow diagrams (UML 2) show info flows between elements, but no sequence is shown • Similar to de Marco-style DFDs • Can be done for entire system or per use case – Activity diagrams show sequence of information processing within a system • Usually done per use case 25 Real-Time UML © Telelogic AB Information Flow Requirements 26 Real-Time UML © Telelogic AB Relating to Textual Requirements • Use cases and related notations are an alternative to text-based requirements • Restating text-based requirements – When the text requirements are vague – When they need to be validated with the customer – When the risk or cost of incorrect, inaccurate, or inconsistent requirements is high – When there is a high need to perform validation tests against the requirements – When the requirements are complex Traceability is best achieved through the use of traceability tools such as DOORS or Gateway 27 Real-Time UML © Telelogic AB Detailing Use Cases: Scenarios • A typical system has one dozen to a few dozen use case • Each use case typically has a few to several dozen scenarios of interest • Scenarios capture a specific actor-system interaction – protocols of interaction – permitted sequences of message flow – collaboration of structural elements – show typical or exceptional paths through the use case 28 Real-Time UML © Telelogic AB Example Sequence Diagram 29 Real-Time UML © Telelogic AB Detailing Use Cases: Statecharts 30 Real-Time UML © Telelogic AB Detailing Use Cases: Statecharts Alarm on Critical Event 31 Real-Time UML © Telelogic AB How do we describe structure using UML? 32 Real-Time UML © Telelogic AB Objects, Classes and Interfaces • An object is a run-time entity that occupies memory at some specific point in time – Has behavior (methods) – Has data (attributes) • A class is a design-time specification that defines the structure and behavior for a set of objects to be created at run-time. – Specifies behavior implementation (methods) – Specifies data (attributes) • An interface is a design time concept that specifies the messages a class receives (“provided”) or uses (“required”) – Specifies behavior only (operation implementation) – May have virtual attributes (no implementation) – May have a protocol state machine (no actions) 33 Real-Time UML © Telelogic AB What is an Object ? • An object is one of the common building blocks in a UML model.