ISO-10746-4-1998.pdf

INTERNATIONAL STANDARD ISO/IEC 10746-4 First edition AMENDMENT 1 1998-12-15 2001 -1 2-1 5 Information technotogy - Open Distributed Processing - Reference Model: Architectural semantics AMENDMENT 1 : Computational formalization Technologies de l'information - Traitement réparti ouvert - Modèle de référence: Sémantique architecturale AMENDEMENT 7 : Formalisation informatique Reference number ISO/IEC 10476-4: 1998/Amd.l :ZOO1 (E) ISO/IEC 2001 Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISOIIEC 10746-4:1998/Amd.l:2001 (E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces 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 Adobe's licensing policy. The IS0 Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe 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 IS0 member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. O ISO/IEC 2001 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IS0 at the address below or ISOs member body in the country of the requester. l IS0 copyright ofice Case postale 56 CH-121 1 Geneva 20 Tel. + 41 22 749 O 1 11 Fax +41227490947 E-mail copyrightiso.ch Web www.iso.ch Published by IS0 in 2002 . . , Printed in Switzerland . . II O ISO/IEC 2001 -All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISOllEC 10746-4:1998/Amd.l:2001(E) 1 CONTENTS Page 1) Introduction 1 2) Clause 1 - Scope 1 . 3) 4) Clause 2 . Normative references . Subclause 3.2 . Definitions from ITU-T Recommendation 2.100 5) Subclause 3.3 - Definitions from the Z-Base Standard 6) Annex A Annex A . Computational Formalization . Formalization of the Computational Viewpoint Language in 2 . A . I A.2 A.3 A.4 Formalization of the Computational Viewpoint Language in LOTOS Formalization of the Computational Viewpoint Language in SDL . Formalization of the Computational Viewpoint Language in ESTELLE 2 2 2 3 3 3 12 20 28 O ISO/IEC 2001 -All rights reserved . 111 Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISOIIEC 10746-4:1998/Amd.I:2001(E) Foreword IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of IS0 or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. IS0 and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also take part in the work. In the field of information technology, IS0 and IEC have established a joint technical committee, ISOAEC JTC 1. International Standards are drafted in accordance with the rules given in the ISOAEC Directives, Part 3. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this Amendment may be the subject of patent rights. IS0 and IEC shall not be held responsible for identifying any or all such patent rights. Amendment 1 to International Standard ISOAEC 10746-4: 1998 was prepared by Joint Technical Committee ISOIIEC JTC 1, information technology, Subcommittee SC 7, Software engineering, in collaboration with ITU-T. The identical text is published as ITU-T Rec. X.904/Amd.l. iv O ISOAEC 2001 -All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISODEC 10746-4:1998iAmd.l:2001 (E) INTERNATIONAL STANDARD ITU-T RECOMMENDATION INFORMATION TECHNOLOGY - OPEN DISTRIBUTED PROCESSING - REFERENCE MODEL: ARCHITECTURAL SEMANTICS AMENDMENT 1 Computational formalization 1) Introduction Replace the Ist paragraph o f the introduction This Recommendation I International Standard is an integral part of the ODP Reference Model. It contains a formalisation of the ODP modelling concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9. The formalisation is achieved by interpreting each concept in terms of the constructs of the different standardised formal description techniques. with This Recommendation I International Standard is an integral part of the ODP Reference Model. It contains a formalization of the ODP modelling concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9 and in ITU-T Rec. X.903 I ISO/IEC 10746-3, clause 7 (Computational Language). The formalization is achieved by interpreting each concept in terms of the constructs of the different standardized formal description techniques. 2) Clause 1 - Scope Replace the fourth bullet under The RM-ODP consists of ITU-T Rec. X.904 I ISO/IEC 10746-4: Architectural Semantics: contains a formalisation of the ODP modelling concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9, and a formalisation of the viewpoint languages of ITU-T Rec. X.903 I ISO/IEC 10746-3. The formalisation is achieved by interpreting each concept in terms of the constructs of the different standardised formal description techniques. This text is normative. with ITU-T Rec. X.904 I ISO/IEC 10746-4: Architectural Semantics: contains a formalization of the ODP modelling concepts defined in ITU-T Rec. X.902 i ISO/IEC 10746-2, clauses 8 and 9, and a formalization of the computational viewpoint language of ITU-T Rec. X.903 I ISO/IEC 10746-3. The formalization is achieved by interpreting each concept in terms of the constructs of the different standardized formal description techniques. This text is normative. Replace the fourth paragraph The purpose of this Recommendation I International Standard is to provide an architectural semantics for ODP. This essentially takes the form of an interpretation of the basic modelling and specification concepts of ITU-T Rec. X.902 I ISO/IEC 10746-2 and the viewpoint languages of ITU-T Rec. X.903 I ISOAEC 10746-3, using the various features of different formal specification languages. An architectural semantics is developed in four different formal specification languages: LOTOS, ESTELLE, SDL and Z. The result is a formalisation of ODPs architecture. Through a process of iterative development and feedback, this has improved the consistency of ITU-T Rec. X.902 I ISO/IEC 107462 and ITU-T Rec. X.903 I ISO/IEC 10746-3. with The purpose of this Recommendation I International Standard is to provide an architectural semantics for ODP. This essentially takes the form of an interpretation of the basic modelling and specification concepts of ITU-T Rec. X.902 I ISO/IEC 10746-2 and the computational viewpoint language of ITU-T Rec. X.903 I ISO/IEC 107463, using the various features of different formal specification languages. An architectural semantics is developed in four different formal ITU-T Rec. X.904/Amd.l (2000 E) 1 Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISO/IEC 10746-4:1998/Amd.l:2001 (E) specification languages: LOTOS, ESTELLE, SDL and Z. The result is a formalization of ODPs architecture. Through a process of iterative development and feedback, this has improved the consistency of ITU-T Rec. x.902 I ISOAEC 10746-2 and ïïU-T Rec. X.903 I ISO/IEc 10746-3. Add the following paragraph at the end of Scope: Annex A shows one way in which the computational viewpoint language of ITU-T Rec. X.903 I TSOIIEC 10746-3 can be represented in the formal languages LOTOS, SDL, Z and Estelle. This Recommendation I International Standard also makes use of the concepts defined in ITU-T Rec. X.902 I ISOíIEC 10746-2. 3) Clause 2 - Normative references Change publication date for ITU-T Recommendation 2.100 from (1993) to (1999). ISOíIEC 13568: Add the following reference: Z Notation, ISOíIEC JTC 1 SC 22 WG 19 Advanced Working Draft 2.C, July 13th 1999. 4) Subclause 3.2 - Definitions from ITU-T Recommendation 2.100 Replace the list with the following terms: active, adding, all, alternative, and, any, as, atleast, axioms, block, call, channel, comment, connect, connection, constant, constants, create, dcl, decision, default, else, endalternative, endblock, endchannel, endconnection, enddecision, endgenerator, endnewtype, endoperator, endpackage, endprocedure, endprocess, endrefinement, endselect, endservice, endstate, endsubstructure, endsyntype, endsystem, env, error, export, exported, external, fi, finalized, for, fpar, from, gate, generator, 8 import, imported, in, inherits, input, intelface, join, literal, literals, map, mod, nameclass, newtype, nextstate, nodelay, noequality, none, not, now, offspring, operator, operators, or, ordering, out, output, package, parent, priori, procedure, process, provided, redefined, referenced, refinement, rem, remote, reset, return, returns, revealed, reverse, save, select, seK sender, service, set, signal, signallist, signalroute, signalset, spelling, start, state, stop, struct, substructure, synonym, syntype, system, task, then, this, timer, to, type, use, via, view, viewed, virtual, with, xor. 5) Change subclause title to: 3.3 - Definitions from the Z Notation. Replace the list with following terms: axiomatic description, data refinement, hiding, operation refinement, overriding, schema (operation, state, framing), schema calculus, schema composition, sequence, type. Subclause 3.3 - Definitions from the Z-Base Standard 2 ITU-T Rec. X.904/Amd.l(2000 E) Copyright International Organization for Standardization Provided by IHS under license with ISO Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/04/2007 23:27:16 MDTNo reproduction or networking permitted without license from IHS -,-,- ISO/IEC 10746-4:1998/Amd.l:2001 (E) 6) Annex A Add a new Annex A as follows: Annex A Computational Formalization A.l A.l.l Concepts The formalization of the computational language in LOTOS uses the concepts defined in the formalization of the basic modelling and structuring rules given in ITU-T Rec. X.902 I ISOAEC 10746-2 clauses 8 and 9. Elementary Structures Associated with Operational and Signal Interfaces To formalize the computational language in LOTOS it is necessary to introduce certain elementary structures. These include parameters that might be associated with certain computational interfaces and a basic model of information that might be used in a stream flow. To formalize parameters it is necessary to introduce two concepts: names for things and types for things. Names are simply labels. As we shall see, the computational viewpoint requires that checks, e.g. for equality, are done on these labels when interfaces are constructed. We may represent names generally by: Formalization of the Computational Viewpoint Language in LOTOS type Name is Boolean sorts Name opns newName: - Name anotherName: Name - Name - eq-,-ne-: Name, Name - Boo1 endtype (* Name *) For brevity sake we omit the equations, which are expected to be obvious. It is possible to be more prescriptive here, e.g. using character strings from the LOTOS library. The only thing we are interested in regarding names is that we can determine their equality or inequality. As discussed in this Recommendation I International Standard, a type in the ODP sense may not be interpreted directly in the process algebra part of LOTOS. It is however possible to model types through the Act One part of LOTOS. Unfortunately, whilst Act One was designed specifically for representing types, it is limited in the ways in which types and types relationships are checked. For example, it is not possible to check subtyping or equivalence up to isomorphism between types due to type equality in Act One being based on name equivalence of sorts. As a basis for reasoning here we introduce an elementary notion of types that allows us to test for equality, inequality and subtyping. type AnyType is Boolean sorts AnyType opns newType: - AnyType anotherType: AnyType - AnyType eq,-isSubtype-: AnyType, AnyType - Bool endtype (* AnyType *) A parameter is a relation between a name and its underlying type representation. Thus a parameter may be represented by: type Param is Name, AnyType sorts Param opns newparam: Name, AnyType - Param eq_,-ne-,-isSubtype-: Param, Param - Bool endtype (* Param *) As previously, we require checks on the equality or inequality of parameters as well as when one parameter is a subtype of another. Two parameters are in a subtype relationship when their types are in a subtype relationship. It is also useful for us to introduce sequences of these parameters. type PList is String actualizedby Param using sortnames PList for String Param for Element Bool for FBool opns -isSubtype-: PList, PList - Boo1 endtype (* PList *) ITU-T Rec. X.904lAmd.l (20Oû E) 3 Copyright International Organization for Standardization