The UML Profile for Communicating Systems DRAFT October 18, 2004
Total Page:16
File Type:pdf, Size:1020Kb
The UML Profile for Communicating Systems DRAFT October 18, 2004 Copyright © 1997-2003 ETSI. IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSIÂSRÂ000Â314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). All published ETSI deliverables shall include information which directs the reader to the above source of information. This Technical Specification (TS) has been produced by ETSI Technical Committee. How to Read this Specification 2 Acknowledgements 2 Overview 5 Methodological Aspects 5 Class Diagram 6 State Machine Diagram 7 Composite Structure Diagram 8 Relationship Between Diagrams 9 Overview 5 Active Class 5 Description 5 Attributes 5 Constraints 5 Semantics 5 Notation 5 Passive Class 5 Description 5 Attributes 5 Constraints 6 Semantics 6 Notation 6 Interface 6 Description 6 Constraints 6 Semantics 6 Notation 6 Signal 6 Description 6 Attributes 6 Semantics 6 Notation 7 Directed Association 7 Description 7 Attributes 7 Constraints 7 Semantics 7 Notation 7 Composition 7 Description 7 Attributes 7 xxx 7 Constraints 7 Semantics 8 UML Profile for Communicating Systems 1 Notation 8 Generalisation 8 Description 8 Attributes 8 Constraints 8 Semantics 8 Notation 8 Operation 8 Description 8 Attributes 8 Semantics 8 Notation 8 Attribute 9 Description 9 Attributes 9 Semantics 9 Notation 9 Port 9 Description 9 Attributes 9 Semantics 9 Notation 9 Provided Interface 10 Description 10 Attributes 10 Semantics 10 Notation 10 Required Interface 10 Description 10 Attributes 10 Semantics 10 Notation 10 State 10 Description 10 Constraints 10 Semantics 10 Notation 11 Transition 11 Description 11 Attributes 11 Semantics 11 Notation 11 Guard 11 2 UML Profile for Communicating Systems Description 11 Attributes 11 Semantics 11 Notation 12 Event 12 Description 12 Attributes 12 Semantics 12 Notation 12 Start States 12 Description 12 Constraints 12 Semantics 12 Notation 12 Stop States 13 Description 13 Constraints 13 Semantics 13 Notation 13 Entry Action 13 Description 13 Attributes 13 Semantics 13 Notation 13 Exit action 14 Description 14 Attributes 14 Semantics 14 Notation 14 Objects (instances of both active and passive classes) 14 Description 14 Attributes 14 Constraints 14 Same PC cannot be linked to two or more different AC objects simultaniously, i.e PC ob- jects are not allowed to use to shared communication .... 14 Semantics 14 Notation 15 instances of ports 15 Description 15 Attributes 15 Constraints 15 Semantics 15 Notation 15 UML Profile for Communicating Systems 3 Link (between passive objects) 15 Description 15 Attributes 15 Semantics 15 Notation 15 Connector (between instances of ports) 15 Description 15 Attributes 16 Semantics 16 Notation 16 Link (instances of associations between active and passive classes) 16 Description 16 Attributes 16 Constrains 16 Semantics 16 Notation 16 object multiplicity 16 Description 16 Attributes 16 Semantics 16 Notation 16 4 UML Profile for Communicating Systems 1Scope This document describes the UML Profile for Communicating Systems (UML-CS). The profile is intended as an easy to use and descriptive language that can also be used to specify systems formally and informally at different levels of abstractions, and which gives the ability to perform functional verification and generate executable applications. It draws on experiences with using SDL and UML for standardization purposes. In UML 2.0, a framework for dealing with actions has been defined. As no textual or graphical notation has been defined for this framework, it is one of the primary goals of this profile to define a syntax for actions in a manner that is similar to most programming languages. The semantics of UML 2.0 is quite flexible to be applicable to a large number of platforms and domains. In some cases, this means that semantics have been left unspecified, while in other cases there are different options specified through semantic variation points. As part of this profile, we close the semantic variation points as applicable, and define semantics where necessary. There are no standard data types defined in UML. For this reason, a set of primitive data types are defined as part of the profile. While UML covers several concepts that are required for communicating systems, there are still a few missing concepts that have to be added. This include for example the definition of timers, and the ability to handle time.An important goal of the profile is to make UML smaller and easier to use. This is done by focusing on the commonly used concepts and defining a self-consistent subset of the language to be used in the specification of communicating systems 2Conformance This specification defines three conformance points. Implementations must support at least one of these. 3Normative References The following documents contain provisions which, through reference in this text, constitute provisions of the present document.References are either specific (identified by date of publication and/or edition number or version number) or nonâ\200\221specific.For a specific reference, subsequent revisions do not apply.For a non-specific reference, the latest version applies.Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference. • ITU-T Recommendation Z.100: Specification and Description Language (SDL) • ITU-T Recommendation Z.105: • ITU-T Recommendation Z.106: • ITU-T Recommendation Z.109: UML Combined with SDL • OMG UML 2.0 Superstructure specification • ETSI EG 201 872: Methodological approach to the use of object-orientation in the standards making process • ETSI EG 201 383: Use of SDL in ETSI deliverable OMG Working Template 1 • ETSI EG 202 106: Guidelines for use of SDL as a descriptive tool • ETSI MI/MTS-00073: SDL Concepts Check-list • 36TD10: UML 2.0 Action Syntaxâ\200\224Feasibility Study Other references pertain to documents produced by the Object Management Group and may be found via their web site at http://www.omg.org • UML 2.0 Infrastructure Specification • UML 2.0 Superstructure Specification • UML Profile for Schedulability, Performance and Time 4 Terms and Definitions For the purposes of this specification, the terms and definitions given in the normative reference and the following apply. • UML-CS The UML Profile for Communicating Systems • SDL Specification and Description Language • UML Unified Modeling Language • BNF Backus Naur Form 5 Additional Information 5.1 How to Read this Specification The rest of this document contains the technical content of this specification. As background for this specification, readers may wish to refer to the UML: Infrastructure and UML: Superstructure specifications produced by the Object Management Group. Although the chapters are organized in a logical manner and can be read sequentially, this is a reference specification is intended to be read in a non-sequential manner. Consequently, extensive cross-references are provided to facilitate browsing and search. 5.2 Acknowledgements The following companies submitted and/or supported parts of this specification: • Dr Ian Oliver, Nokia • Mr. Antti Huima, Comformiq • Mr. Juha Pärssinen, VTT 2 OMG Working Template • Mr. Rick Reed, TSE • Mr. Darcy, TSE OMG Working Template 3 4 OMG Working Template 6Diagrams 6.1 Overview This chapter outlines the graphic elements that may be shown in the various diagrams that are admitted by the UML Profile for Communicating Systems. We aksi describe certain principles behind the language and implies methodological issues. 6.2 Methodological Aspects Active classes are used to present the components of the system, while passive classes are used to represent datastructures that are manipulated by those active classes. Active classes can have their behaviour described by that class’ state machine. Composite active classes - those that contain further active classes have their behaviour defined as the composition of all active classes that form the composition. Composite active classes do not in addition provide additional behaviour. That is, the structure of composite active classes forms a tree structure, with those active classes existing as leaf nodes having their behaviour described using their particular state machines. Those active classes that are not leaf nodes do not have their behaviour described using their own state machines but rather act as containers for the leaf nodes and further composite active classes. Passive classes do not contain behaviour other than that described by their operations and attributes. That is passive classes do not have a thread of control, do not react to external stimuli other than a direct method invocation by another passive class or their owning active class. Passive classes do not contain state machines explicitly. All communication between active classes is made via active class ports. No communication between active classes is made by way of shared pass ive classes or direct method invocation between passive or active classes. The profile does not allow passive classe instances to be shared between active classe instances Passive class operations (or methods) are solely used to manipulate the data