Using UML for Modeling Complex Real Time System Architectures

Using UML for Modeling Complex Real Time System Architectures Bran Selic VP Advanced Technology ObjecTime Limited bran@objectime.com

Overview • The Unified Modeling Language (UML) • Complex real-time systems • Requirements for modeling architectures of complex RT systems • Approach and method • Architectural modeling constructs • Summary

UML 1.4 1996 OMT (Rumbaugh) Mar. 1999 UML 0.9 UML 1.1 Nov. 1997 OOSE (Jacobson) Booch The Unified Modeling Language • A general purpose OO modeling language • combines a number of proven methods Catalysis ROOM etc.

What is (in) the UML Standard? • Semi-formal semantic meta-model • defines basic modeling concepts • object, class, etc. • includes well-formedness rules expressed as formal constraints in Object Constraint Language (OCL) • Graphical notation for modeling concepts • 8 different diagram types • Two predefined domain extensions

GeneralizeableElement Feature isRoot:Boolean isLeaf:Boolean isAbstract:Boolean visibility:{public, protected, private} * Class isActive:Boolean The UML Meta-Model–Example (Meta)class Generalization association Classifier Compostion association not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op))) OCL constraint

The Unified Modeling Language (UML) • Complex real-time systems • Requirements for modeling architectures of complex RT systems • Approach and method • Architectural modeling constructs • Summary

environment inputs outputs General Real-Time Systems • A system that maintains a continuous timely interaction with its environment Real-TimeSystem (state) outputs = f (inputs, state)

Complex Real-Time Systems • Complex real-time systems characterized by: • extreme dependability (reliability, availability) • diverse and feature-rich functionality • continuous feature upgrades (evolutionary requirements) • physical distribution • Encountered mostly in telecommunications, defense, aerospace, and industrial control

Modeling Requirements for Complex RT Systems • This complexity requires focussed modeling support in at least the following areas: • Architectural modeling • Timeliness and performance modeling • Time-aware communication models • Concurrency management • Resource modeling • Distributed system modeling • Fault-tolerance techniques

Real-Time Software Architectures • Architecture: The organization of significant software components interacting through interfaces, those components being composed of successively smaller components and interfaces • It is the key to success in: • the initial construction of a system • system evolution

A A A Mediator B C B C B C Architectures and Evolution • Two functionally equivalent initial architectures: X X Mediator

Structure Channel1 TerminalA TerminalB Channel2 Behavior Real-Time Architectural Specifications • Example telecom system architecture Application Layer Services Layer

Library Channel1 System1 TerminalA TerminalA Terminal TerminalB TerminalTester TerminalTester Channel2 Channel System2 Architectural Component Design

Channel1 TerminalA TerminalB Channel1 TerminalA TerminalB Channel2 Refining Architectures (Reuse)

Summary: Requirements for Architectural Modeling • The ability to model and enforce: • large-grain (architectural) components and their interfaces • structural compositions of architectural components • dynamic interaction patterns between architectural components • refinement of architectures

Approach and Method • The necessary architectural modeling capabilities can be found in ROOM • Express the architectural modeling concepts of ROOM using standard UML • Domain-specific library of UML “macros” BusinessModelingLibrary Real-TimeModelingLibrary (UML-RT) ... UML Modeling Concepts

Capsule Class <“ports”> isActive:Boolean UML Extensibility Mechanisms • Stereotypes, constraints, tagged values Constraint (OCL) not self.isAbstract implies self.allOperations->forAll(op | self.allMethods->exists(m | m.specification includes (op))) stereotype required tag

Real-Time Object-Oriented Modeling (ROOM) • Domain-specific (real-time) concepts • dynamic high-level structures • reactive behavior (ROOMcharts) • Executable (formal) models • Full automatic code generation • Field proven in a large number (>100) of large-scale industrial projects • Tool support available (ObjecTime Limited and Rational Software)

Phasing • Basic modeling capabilities (UML 1.1) • structural pattern modeling (collaboration diagrams) • state machine modeling • Real-time specific constructs • architectural modeling (March ‘98) • other constructs (-June ‘99) • collaboration: ObjecTime & Rational • OMG standardization (1999/2000) • RT analysis and design WG

Ports Capsules: Architectural Objects • Active objects Encapsulation shell

Capsules: Behavior transitionS1toS2: {int x; x = 0; p2.send(s1); p3.send(s2); … }; S1 S1 S2 S3 • Optional hierarchical state machine (signal handler with run-to-completion semantics) S1 S2

+portB : ProtocolA::master #portC : ProtocolB ports Capsules: UML Modeling • Stereotype of Class concept («capsule») with specialized (executable) semantics • Class diagram representation: «capsule»CapsuleClassX #counter : int#x : char

call number call ack ack transfer talk time Protocols: Contractual Behavior Patterns • Interaction contracts between capsules • e.g., operator-assisted call Caller Operator Callee

Dexter Alice Charlie Bob caller callee protocol state machine callee operator caller significant sequences initial operator connecting connected Protocol Specifications • A special form of collaboration OperatorAssistedCall

Outgoing signals Incoming signals signal signal source target ack transfer call ack number call callee callee caller caller caller caller role state machine caller operator callee significant sequences initial connecting connected Protocol Roles • Specifies one party in a protocol OperatorRole

Outgoing signals Incoming signals Incoming signals OperatorRole signal signal signal source source target ack transfer query number ack ack call transfer ack reply call call number call callee caller caller callee callee caller caller caller caller caller caller callee caller caller Outgoing signals signal target Protocol Refinement • Using inheritance ExtendedOperatorRole

1 ack transfer incoming call number talk outgoing 1 1 Protocols: UML Modeling • Collaboration stereotype: «protocol» • Classifier Role stereotype: «protocolRole» «protocolRole»caller «protocol»OperatorAssistedCall «protocolRole»operator «protocolRole»callee

Ports: Boundary Objects Capsule S1 Environment S2 • Fully isolate a capsule’s implementation from its environment (in both directions) Created and destroyed along with their capsule

+portA : ProtocolA::master #portB : ProtocolB +portC : ProtocolB~ ports Ports and Protocols • Each port realizes a single protocol role (type) • Multiple ports with same type possible «capsule»CapsuleClassX

«port»portA:ProtocolA::master 1 Ports: Collaboration Diagram Notation • Shorthand notation for capsule instances • iconified form «capsule»anX:CapsuleClassX portA : ProtocolA::master portC : ProtocolB~

Combining Capsules «capsule»receiver : Fax remote : FaxProt «capsule»sender : Fax remote : FaxProt • Using connectors Connector • Connectors model communication channels • Each connector supports a single protocol • Static typing rules apply (compatible protocols) • Modeled as association classes in UML

sendCtrl : Control receiveCtrl : Control remote:FaxProt c : Control c : Control «capsule»sender:Fax «capsule»receiver:Fax Remote:FaxProt Composition: Structural Patterns as (Reusable) Dynamic Components Relayport FaxCall • The composite is also a first-class object!

Composite Capsule Semantics • Architectural assertion mechanism: the static elements of the internal structure of a composite capsule are automatically created (and destroyed) along with the capsule • applies recursively down to the innermost leaf capsule level • only explicitly prescribed architectural structures can be instantiated • This also significantly reduces the complexity of the model since all the code used to establish these structures is eliminated

End Ports: Where Structure and Behavior Meet c : SystemControl senderCtrl : Control~ receiveCtrl : Control~ capsule state machine c : Control c : Control initial «capsule»sender:Fax «capsule»receiver:Fax connecting connected • Ports directly connected to the state machine ImplementationEnd Port Public End Port

1 sender 1 receiver Decomposition: Class Diagram View • Alternative representation • More abstract «capsule»Fax «capsule»FaxCall

Summary (1) • Complex real-time systems phenomena require specialized modeling support • The ROOM language has industry-proven support for modeling complex real-time architectures • The benefits of both UML and ROOM are gained by expressing the ROOM constructs as UML stereotypes • UML-RT : a UML extension for the complex real-time domain

Stereotype UML Metaclass «protocol» Collaboration «protocolRole» «port» «capsule» ClassifierRole Class Class Summary (2) • Only four UML stereotypes are sufficient • (include formally defined constraints that ensure consistency/executability) • supplemented by an optional custom notation

Bibliography • Real-time architectural modeling whitepaper by B. Selic and J. Rumbaugh: • http://www.objectime.com • OMG’s UML 1.1 standard • http://www.rational.com • ROOM • B. Selic, G. Gullekson, and P. Ward, “Real-Time Object-Oriented Modeling”, • John Wiley & Sons, NY, 1994.

Using UML for Modeling Complex Real Time System Architectures