1、 Reference number ISO/TR 24529:2008(E) ISO 2008TECHNICAL REPORT ISO/TR 24529 First edition 2008-04-15 Intelligent transport systems Systems architecture Use of unified modelling language (UML) in ITS International Standards and deliverables Systmes intelligents de transport Architecture de systmes E
2、mploi du langage de modlisation unifi (UML) dans les Normes internationales ITS et produits livrables ISO/TR 24529:2008(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the ty
3、pefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe
4、 Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unli
5、kely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. COPYRIGHT PROTECTED DOCUMENT ISO 2008 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electroni
6、c or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org W
7、eb www.iso.org Published in Switzerland ii ISO 2008 All rights reservedISO/TR 24529:2008(E) ISO 2008 All rights reserved iiiContents Page Foreword iv Introduction.v 1 Scope1 2 Normative references1 3 Terms and definitions .1 4 Abbreviated terms.3 5 Background3 5.1 TC 204 working group 1 (WG 1).3 5.2
8、 UML as a standard.4 5.3 Modelling for ITS architecture4 6 Discussion .5 6.1 Scope of the discussion .5 6.2 What is systems architecture? 5 6.3 Why is architecture relevant? 6 6.4 How is interoperability defined and realised?6 6.5 What are the desired levels of interaction with ITS architecture .7 6
9、.6 What are use cases and why apply them? .7 6.7 What is the “Unified Modelling Language” (UML) and why does it seem so daunting?.9 6.8 Where do International Standards fit into the equation?9 6.9 ITS Data registries and UML.10 6.10 User acceptance of the logical architecture (example).10 7 Implicat
10、ions (of user acceptance) for the use of UML.11 7.1 General comments 11 7.2 Adoption of profiles 11 7.3 Modelling tools 11 7.4 Sufficiency of UML 12 Bibliography13 ISO/TR 24529:2008(E) iv ISO 2008 All rights reservedForeword ISO (the International Organization for Standardization) is a worldwide fed
11、eration of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that comm
12、ittee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accorda
13、nce with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires
14、 approval by at least 75 % of the member bodies casting a vote. In exceptional circumstances, when a technical committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example), it may decide by a simple majority vot
15、e of its participating members to publish a Technical Report. A Technical Report is entirely informative in nature and does not have to be reviewed until the data it provides are considered to be no longer valid or useful. Attention is drawn to the possibility that some of the elements of this docum
16、ent may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO/TR 24529 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems. ISO/TR 24529:2008(E) ISO 2008 All rights reserved vIntroduction The objective of this
17、Technical Report is to provide guidance on the use of the “Unified Modeling Language” UML in the development of standards for “Intelligent Transport Systems” ITS. The advantages of applying UML to the development of ITS include the following: UML provides an Internationally Standardized form of syst
18、em model that should be readily interpreted anywhere world-wide; UML enables cohesive description from multiple user views; There is available extensive training and tool support for UML; UML is capable of manipulation by a metadata registry for ITS; UML tools enable conversion directly to computer
19、coding; UML is very widely used in the architecture, design and development of software-intensive systems. The disadvantages of using UML include the following: UML is not understood by many stakeholders who are not also software developers; UML uses a larger amount of unfamiliar language and jargon
20、 which, while it may be necessary for precision, is daunting and off-putting to the non specialist and lay reader; UML is not yet developed enough to support the full scope of systems engineering; UML is still under active development and therefore the compatibility of UML models may be an issue. Th
21、ere are therefore some risks in using UML but nevertheless the benefits are widely judged as exceeding the disadvantages. This document is intended to provide guidance to stakeholders who are considering the use of UML for ITS. TECHNICAL REPORT ISO/TR 24529:2008(E) ISO 2008 All rights reserved 1Inte
22、lligent transport systems Systems architecture Use of unified modelling language (UML) in ITS International Standards and deliverables 1 Scope The scope of this Technical Report is the use of UML within International Standards Technical Specifications and Technical Reports and related documents. Thi
23、s Technical Report discusses the application of the “Unified Modelling Language” UML to the development of standards within the context of “Intelligent Transport Systems” ITS. 2 Normative references ISO 14813 (all parts), Transport information and control systems Reference model architecture(s) for
24、the TICS sector (Parts 1 to 6) ISO 14817, Transport information and control systems Requirements for an ITS/TICS central Data Registry and ITS/TICS Data Dictionaries ISO/TR 17452, Intelligent transport systems Using UML for defining and documenting ITS/TICS interfaces ISO/IEC 19501, Information tech
25、nology Open Distributed Processing Unified Modeling Language (UML) Version 1.4.2 ISO/TR 25102, Intelligent transport systems System architecture Use Case pro-forma template 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 actor coherent set of
26、 roles that users of an entity can play when interacting with the entity. NOTE An actor may be considered to play a separate role with regard to each use case with which it communicates. In the metamodel, Actor is a subclass of Classifier. An Actor has a Name and may communicate with a set of UseCas
27、es, and, at realization level, with Classifiers taking part in the realization of these UseCases. An Actor may also have a set of Interfaces, each describing how other elements may communicate with the Actor. An Actor may have generalization relationships to other Actors. This means that the child A
28、ctor will be able to play the same roles as the parent Actor, that is, communicate with the same set of UseCases, as the parent Actor. 3.2 architecture ITS set of concepts and rules for an intelligent transport system describing the inter-relationship between entities in the entire system, independe
29、nt of the hardware and software environment NOTE Architecture is described through a series of viewpoints that may be at varying levels of generality/specificity, abstraction/concretion, totality/component and so on. See also communications architecture, logical architecture, organizational architec
30、ture, physical architecture, reference architecture and system architecture definitions below. ISO/TR 24529:2008(E) 2 ISO 2008 All rights reserved3.3 communications architecture framework that tells designers how elements of hardware and software are to operate in harmony using common protocols and
31、air interface techniques (where applicable) 3.4 logical architecture definition of the processes (the activities and functions) that are required to provide the required User Services 3.5 model representation of an entity from which the important elements have been abstracted by removing unimportant
32、 detail while at the same time retaining the interrelationship between the key elements of the whole NOTE A model may be made more or less abstract by the successive suppression of detail such that the concepts and relationships come into enhanced focus and become more readily understood. However th
33、e process can be taken too far when the simplification has exceeded the threshold where a necessary understanding may be achieved. Thus the process of modelling is one of going only far enough to achieve the optimum understanding and insight and no further. NOTE A model is a way of representing some
34、thing, other than in its natural state. (See Models of ITS documents at http:/www.frame- 3.6 organizational architecture framework into which business processes are deployed and ensures that the organizations core qualities are realised across the business processes deployed within the organization
35、NOTE In this way organizations aim to consistently realise their core qualities across the services they offer to their clients. 3.7 physical architecture high-level structure around the processes and data flows in the logical architecture NOTE The physical architecture defines the physical entities
36、 (subsystems and terminators) that make up a system. 3.8 reference architecture list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture 3.9 relation relationship nature of how t
37、wo entities affect each other including dependencies 3.10 requirement statement of user need, typically expressed in a single-sentence form to assist with later verification of compliance 3.11 scenario sequence of steps that are taken to change the state from that before the scenario to that immedia
38、tely after the scenario 3.12 system architecture system architecture is a framework for ITS deployments; it is a single, high-level description of the major elements or objects and the interconnections among them NOTE System architecture provides the framework around which the interfaces, specificat
39、ions and detailed system designs can be defined. An architecture is not a product design, nor a detailed specification for physical deployment. Mil4 ISO/TR 24529:2008(E) ISO 2008 All rights reserved 33.13 template framework that may be used repeatedly to meet requirements that are similar to some ex
40、tent 3.14 use case representation of a series of interactions between an outside entity and the system, which ends by providing business value NOTE A use case is a sequence of actions that an actor (usually a person, but perhaps an external entity, such as another system) performs within a system to
41、 achieve a particular goal Rosenberg. 4 Abbreviated terms ITS intelligent transport system KAREN keystone architecture required for European networks MDD model driven developments OMG object management group POM process oriented methodology SEI software engineering institute TICS transport informati
42、on and control systems TR technical report UML unified modelling language 5 Background 5.1 TC 204 working group 1 (WG 1) This Technical Report arose from work by WG 1 on the elaboration of ITS architecture in the ISO 14813 series of International Standards and Technical Reports. It had become appare
43、nt that there was concerted opposition from some sources to the uniform use of UML for ITS architecture. While WG 1 has never mandated the sole use of UML above other architecture methodologies, and the 14813 series focuses on consistency and interoperability rather than preferring any one modelling
44、 technique, UML is seen as an increasingly useful tool in a developing and changing sector because of its ability to change and adapt without abandoning previous work and having to start again. Additionally, the ability to present a cohesive model from different perspectives (views) is seen by many
45、to be useful in many situations. Finally, UML is an ISO International Standard and therefore one of the modelling techniques that should be supported. WG 1 therefore agreed the need for a Technical Report TR to discuss the applicability, strengths and weaknesses and recommended best practice for the
46、 use of UML in ITS standards. ISO/TR 24529:2008(E) 4 ISO 2008 All rights reserved5.2 UML as a standard UML is very widely used as a specification and modelling language for software-intensive systems. This wide use of UML is recognised in the publication of the ISO/IEC standard 19501 that addresses
47、UML. The development of UML is continuing and has now reached version 2.0 with added features and the prospect of increasing support for model-based development (also known as model-driven development or MDD). This progress towards greater automation, particularly with the development of web service
48、s, is important for ITS standards. 5.3 Modelling for ITS architecture The need for multiple viewpoints in architecture models has been widely recognised The similar need for a layered architecture reflecting differing levels of abstraction and encapsulation is also widely agreed. What is not agreed
49、yet is the preferred manner in which these complementary model artefacts should be expressed. The heterogeneous result is a proliferation of ITS architectural models expressed in a mixture of notations and formats. This has been considered acceptable for human comprehension up to the point where complexity, confusion and misinterpretation can arise. However this approach is acceptable when only manual modelling and interpr
