ISO/IEC 10746-4:1998/Amd 1:2001
(Amendment)Information technology — Open Distributed Processing — Reference Model: Architectural semantics — Part 4: — Amendment 1: Computational formalization
Information technology — Open Distributed Processing — Reference Model: Architectural semantics — Part 4: — Amendment 1: Computational formalization
Technologies de l'information — Traitement réparti ouvert — Modèle de référence: Sémantique architecturale — Partie 4: — Amendement 1: Formalisation de traitement
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 10746-4
First edition
1998-12-15
AMENDMENT 1
2001-12-15
Information technology — 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 1: Formalisation informatique
Reference number
ISO/IEC 10476-4:1998/Amd.1:2001(E)
©
ISO/IEC 2001
---------------------- Page: 1 ----------------------
ISO/IEC 10746-4:1998/Amd.1: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 ISO 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 ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© 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 ISO at the address below or ISO's 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 copyright@iso.ch
Web www.iso.ch
Published by ISO in 2002
Printed in Switzerland
ii © ISO/IEC 2001 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001(E)
CONTENTS
Page
1) Introduction. 1
2) Clause 1 – Scope . 1
3) Clause 2 – Normative references . 2
4) Subclause 3.2 – Definitions from ITU-T Recommendation Z.100. 2
5) Subclause 3.3 – Definitions from the Z-Base Standard. 2
6) Annex A. 3
Annex A – Computational Formalization. 3
A.1 Formalization of the Computational Viewpoint Language in LOTOS. 3
A.2 Formalization of the Computational Viewpoint Language in SDL. 12
A.3 Formalization of the Computational Viewpoint Language in Z . 20
A.4 Formalization of the Computational Viewpoint Language in ESTELLE. 28
© ISO/IEC 2001 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO 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. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have
established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC 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. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to International Standard ISO/IEC 10746-4:1998 was prepared by Joint Technical Committee
ISO/IEC 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.1.
iv © ISO/IEC 2001 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
INTERNATIONAL STANDARD
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
ITU-T Rec. X.904/Amd.1 (2000 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – OPEN DISTRIBUTED PROCESSING –
REFERENCE MODEL: ARCHITECTURAL SEMANTICS
AMENDMENT 1
Computational formalization
1) Introduction
Replace the lst paragraph of the introduction
This Recommendation | 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 | 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 | 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 | ISO/IEC 10746-2, clauses 8 and 9 and in
ITU-T Rec. X.903 | 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 | ISO/IEC 10746-4: Architectural Semantics: contains a formalisation of the ODP modelling
concepts defined in ITU-T Rec. X.902 | ISO/IEC 10746-2, clauses 8 and 9, and a formalisation of the viewpoint
languages of ITU-T Rec. X.903 | 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 | ISO/IEC 10746-4: Architectural Semantics: contains a formalization of the ODP modelling
concepts defined in ITU-T Rec. X.902 | ISO/IEC 10746-2, clauses 8 and 9, and a formalization of the computational
viewpoint language of ITU-T Rec. X.903 | 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 | 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 |
ISO/IEC 10746-2 and the viewpoint languages of ITU-T Rec. X.903 | ISO/IEC 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 ODP's architecture. Through a process of
iterative development and feedback, this has improved the consistency of ITU-T Rec. X.902 | ISO/IEC 10746-2 and
ITU-T Rec. X.903 | ISO/IEC 10746-3.
with
The purpose of this Recommendation | 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 |
ISO/IEC 10746-2 and the computational viewpoint language of ITU-T Rec. X.903 | ISO/IEC 10746-3, using the various
features of different formal specification languages. An architectural semantics is developed in four different formal
ITU-T Rec. X.904/Amd.1 (2000 E) 1
---------------------- Page: 5 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
specification languages: LOTOS, ESTELLE, SDL and Z. The result is a formalization of ODP's architecture. Through a
process of iterative development and feedback, this has improved the consistency of ITU-T Rec. X.902 |
ISO/IEC 10746-2 and ITU-T Rec. X.903 | 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 | ISO/IEC 10746-3 can be
represented in the formal languages LOTOS, SDL, Z and Estelle. This Recommendation | International Standard also
makes use of the concepts defined in ITU-T Rec. X.902 | ISO/IEC 10746-2.
3) Clause 2 – Normative references
Change publication date for ITU-T Recommendation Z.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 Z.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, if, import, imported, in, inherits, input, interface, join, literal, literals, map, mod, nameclass,
newtype, nextstate, nodelay, noequality, none, not, now, offspring, operator, operators, or, ordering, out, output,
package, parent, priority, procedure, process, provided, redefined, referenced, refinement, rem, remote, reset, return,
returns, revealed, reverse, save, select, self, 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) Subclause 3.3 – Definitions from the Z-Base Standard
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.
2 ITU-T Rec. X.904/Amd.1 (2000 E)
---------------------- Page: 6 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
6) Annex A
Add a new Annex A as follows:
Annex A
Computational Formalization
A.1 Formalization of the Computational Viewpoint Language in LOTOS
A.1.1 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 | ISO/IEC 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:
type Name is Boolean
sorts Name
opns newName: -> Name
anotherName: Name -> Name
_eq_,_ne_: Name, Name -> Bool
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 | 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 -> Bool
endtype (* PList *)
ITU-T Rec. X.904/Amd.1 (2000 E) 3
---------------------- Page: 7 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
Here we use the type String from the LOTOS library actualised with the type Param defined previously. We also include
an operation here isSubtype that can check whether one sequence of parameters is a subtype of another. One parameter
list is a subtype of a second when all of the parameters it contains are subtypes of those found in the first. In addition the
parameters should be in the same position in their respective lists. It should be noted that these parameters might contain
references to interfaces used to restrict the interactions that can take place. Whilst it is quite possible to model an
interface in the process algebra, it is not possible to model a reference to that interface in the process algebra that, loosely
speaking, captures the functionality of that interface. To overcome this, we model interface references in Act One. Given
that an interface reference captures, amongst other things, the signature of the interface, we provide an Act One model of
signatures for operations. Operations consist of a name, a sequence of inputs and possibly a sequence of outputs. For
simplicity’s sake, we do not consider here whether the operation is of infix, prefix or suffix notation. This may be
represented by:
type Op is Name, PList
sorts Op
opns makeOp: Name, PList -> Op
makeOp: Name, PList, PList -> Op
getName: Op -> Name
getInps: Op -> PList
getOuts: Op -> PList
_eq_: Op, Op -> Bool
eqns forall op1,op2: Op, n: Name; pl1, pl2: PList
ofsort Name getName(makeOp(n,pl1,pl2)) = n;
ofsort PList getInps(makeOp(n,pl1)) = pl1;
getInps(makeOp(n,pl1,pl2)) = pl1;
getOuts(makeOp(n,pl1)) = <>;
getOuts(makeOp(n,pl1,pl2)) = pl2;
ofsort Bool op1 eq op2 = ((getName(op1) eq getName(op2)) and
(getInps(op1) isSubtype getInps(op2)) and
(getOuts(op2) isSubtype getOuts(op1)));
endtype (* Op *)
Having a method of determining whether two operations are the same reduces the problem of subtyping between abstract
data types to a set comparison, where set elements are the created operations. Thus a server is a subtype of a second
server if it supports all operations of the second server. We note here that we model two forms of operations: those that
do not expect results and those that do expect results. We also introduce sets of these operations:
type OpSet is Set actualizedby Op
using sortnames OpSet for Set Op for Element Bool for FBool
endtype (* OpSet *)
Now an interface reference may be represented by the following LOTOS fragment:
type IRef is OpSet
sorts IRef
opns makeIRef : OpSet -> IRef
NULL : -> IRef
getOps :IRef->OpSet
_eq_ : IRef, IRef -> Bool
eqns forall o: OpSet; ir1, ir2: IRef
ofsort OpSet getOps(makeIRef(o)) = o;
ofsort Bool ir1 eq ir2 = getOps(ir1) eq getOps(ir2) ;
endtype (* IRef *)
Here we note that equality of interface references is based only on the operations contained in that reference. It might
well be extended to cover other aspects, e.g. the location of the interface or constraints on its usage. We also introduce
sets of these interface references.
type IRefSet is Set actualizedby IRef
using sortnames IRefSet for Set IRef for Element Bool for FBool
endtype (* IRefSet *)
Elementary Structures Associated with Stream Interfaces
The computational viewpoint of ITU-T Rec. X.903 | ISO/IEC 10746-3 also considers interfaces concerned with the
continuous flow of data, e.g. multimedia. These interfaces are termed stream interfaces. Stream interfaces contain finite
sets of flows. These flows may be from the interface (produced) or to the interface (consumed). Each flow is modelled
through an action template. Each action template contains the name of the flow, the type of the flow, and an indication of
causality for the flow.
The computational viewpoint abstracts away from the contents of the flow of information itself. We consider here a
generic idea of information flow where the flow of information is represented by a sequence of flow elements. A flow
4 ITU-T Rec. X.904/Amd.1 (2000 E)
---------------------- Page: 8 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
element may be regarded as a particular item in the flow of information. We note here that flows are regarded in the
computational viewpoint as continuous actions. In our model here we represent streams as sequences of discrete timed
events. On the one hand this allows us to deal with the timing issues of information flows but we achieve this at the cost
of losing the continuous nature of the flows.
Each flow element in an information flow can be considered as a unit consisting of data (this may be compressed) which
we represent by Data. This model might include how the information was compressed, what information was
compressed, etc. As such it is not considered further here. Flow elements also contain a time stamp used for modelling
the time at which the particular flow element was sent or received. It is also often the case in multimedia flows that
particular flow elements are required for synchronisation, e.g. synchronisation of audio with video for example.
Therefore we associate a particular Name with each flow element. This can then be used for selecting a particular flow
element from the flow as required. From this, we may model a flow element as:
type FlowElement is Name, NaturalNumber, Data, Param
sorts FlowElement
opns makeFlowElement: Data, Nat, Name -> FlowElement
nullFlowElement : -> FlowElement
getData : FlowElement -> Data
getTime : FlowElement -> Nat
getName : FlowElement -> Name
toParam : FlowElement -> Param
setTime : Nat, FlowElement -> FlowElement
eqns forall d: Data, s,t: Nat, n: Name
ofsort Data getData(makeFlowElement(d,t,n)) = d;
ofsort Nat getTime(makeFlowElement(d,t,n)) = t;
ofsort Name getName(makeFlowElement(d,t,n)) = n;
ofsort FlowElement setTime(s,makeFlowElement(d,t,n)) = makeFlowElement(d,s,n);
endtype (* FlowElement *)
It should be noted here that we model time as a natural number however it might well be the case that real (dense) time
could be used, or time intervals. For simplicity here though, we restrict ourselves to discrete time represented as a natural
number. We also introduce an operation that converts a flow element into a parameter. For simplicity we omit the
associated equations. We also introduce sequences of these flow elements:
type FlowElementSeq is FlowElement
sorts FlowElementSeq
opns makeFlowElementSeq: -> FlowElementSeq
addFlowElement: FlowElement, FlowElementSeq -> FlowElementSeq
remFlowElement: FlowElement, FlowElementSeq -> FlowElementSeq
getFlowElement: Name, FlowElementSeq -> FlowElement
timeDiff: FlowElement, FlowElement -> Nat
eqns forall f1, f2: FlowElement, fs: FlowElementSeq, n1,n2: Name
ofsort FlowElementSeq
getTime(f1) le getTime(f2) =>
addFlowElement(f1,addFlowElement(f2,makeFlowElementSeq)) =
addFlowElement(f2,makeFlowElementSeq);
ofsort FlowElement
getFlowElement(n1,makeFlowElementSeq) = nullFlowElement;
n1 ne n2 =>
getFlowElement(n1,addFlowElement(makeFlowElement(d,t,n2),fs)) =
getFlowElement(n1,fs);
n1 eq n2 =>
getFlowElement(n1,addFlowElement(makeFlowElement(d,t,n2),fs)) =
makeFlowElement(d,t,n2);
endtype (* FlowElementSeq *)
For brevity we do not supply all of the equations. Flow elements are added to the sequence provided they have increasing
timestamps. An operation is provided for traversing a sequence of flow elements to find a named flow element. We also
introduce an operation to get the time difference between time stamps of two flow elements. It is possible using this
operation to specify, for example, that all flow elements in a sequence are separated by equal time stamps. In this case
we have an isochronous flow. We also introduce sets of these sequences of flow elements:
type FlowElementSeqSet is Set actualizedby FlowElementSeq
using sortnames FlowElementSeqSet for Set FlowElementSeq for Element Bool for FBool
endtype (* FlowElementSeqSet *)
A.1.1.1 Signal
There is no inherent feature of LOTOS which can be used to distinguish between a signal, a stream flow and an
operation. It may be the case, however, that a style of LOTOS can be used to distinguish between signals, streams and
ITU-T Rec. X.904/Amd.1 (2000 E) 5
---------------------- Page: 9 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
operations. For example, all signals might have similar formats for their event offers. An example of one possible format
for the server side of a signal is shown in the following LOTOS fragment.
? ! ?;
Here and in the rest of A.1, we adopt the notation that represents a placeholder for an X,i.e. g, sigName, myRef and
inArgs represent placeholders for the gate, the name of the signal, the interface reference associated with the server
offering this signal and the parameters associated with the signal respectively.
An example of one possible format for the client side of a signal is shown in the following LOTOS fragment:
! ! !;
Here the client side of the signal contains a gate (g), a label for the signal name (sigName), a reference to the object the
signal is to be sent to (SomeIRef) and the parameters associated with the signal (inArgs). We shall see in A.1.1.11 how
these event offers may be used to construct signal interface signatures.
A.1.1.2 Operation
The occurrence of an interrogation or announcement.
A.1.1.3 Announcement
An interaction that consists of one invocation only. Due to the reasons given in A.1.1.1, only an informal modelling
convention can be used to model announcements. One example of this for the client side of an announcement might be
represented by:
! ! !;
The server side of an announcement might be represented by:
? ! ?;
The data structures here are similar to those in A.1.1.1. We shall see in A.1.1.12 how these event offers may be used to
construct parts of operation interface signatures.
A.1.1.4 Interrogation
An invocation from a client to a server followed by one of the possible terminations from that server to that client.
However, due to the reasons given in A.1.1.1, only an informal modelling convention can be used to model
interrogations. One example of this for the client side of an interrogation might be represented by:
! ! ! !;
( ? ! ?; (* . other behaviour *)
[ ] (* . other terminations *))
Here termName represents the termination names and outArgs represents the output parameters. The server side of an
interrogation might be represented by:
? ! ? ?;
( ! ! !; (* . other behaviour *)
[ ] (* . other terminations *))
The other data structures here are similar to those in A.1.1.1. We shall see in A.1.1.12 how these event offers may be
used to construct parts of operation interface signatures.
A.1.1.5 Flow
An abstraction of a sequence of interactions between a producer and a consumer object that result in the conveyance of
information. Due to the reasons given in A.1.1.1, flows may only be represented in LOTOS through informal modelling
conventions. It is often the case that flows have strict temporal requirements placed on them. One example of how this
might be achieved for flow production is through a process that is parameterised by a sequence of data structures to be
sent, e.g. flow elements that can be timestamped when they are sent. A simple example of how this might be modelled in
LOTOS is:
process ProduceAction[ g, .](. toSend: FlowElementSeq, tnow: Nat, rate: Nat .):noexit:=
g ! ! !;
(*. other behaviour and recurse with FlowElement removed from toSend *)
endproc (* ProduceAction *)
Here flow elements are sent together with the current (local) time plus the rate at which the flow elements should be
produced.
6 ITU-T Rec. X.904/Amd.1 (2000 E)
---------------------- Page: 10 ----------------------
ISO/IEC 10746-4:1998/Amd.1:2001 (E)
Consumption of flow elements typically has different requirements placed upon it. The need to continually monitor the
time stamps of the incoming flow of information is of particular importance. A simple representation of the consumption
of an information flow may be represented by:
process ConsumeAction[ g,.](myRef: IRef, recFlowElements: FlowElementSeq, tnow, rate: Nat.) :noexit:=
g ? !myRef ?;
(* check temporal requirements of inFlowElement are satisfied then *)
(* display FlowElement and recurse with time incremented *)
(* or recurse with FlowElement added to received FlowElements and time incremented *)
endproc (* ConsumeAction *)
A.1.1.6 Signal Interface
As there is no direct means in LOTOS to distinguish formally between a signal and any other LOTOS event, establishing
a given interface as being a signal interface is only possible informally by modelling the LOTOS events used to represent
signals differently to any other event. An example of how a signal interface signature might be modelled in LOTOS is
given in A.1.1.11.
A.1.1.7 Operational Interface
As there is no direct means in LOTOS to distinguish formally between an operation and any other LOTOS event,
establishing a given interface as being an operational interface is only possible informally by modelling the LOTOS
events used to represent operations differently to any other event. An example of how an operation interface signature
might be modelled in LOTOS is given in A.1.1.12.
A.1.1.8 Stream Interface
As there is no direct means in LOTOS to distinguish formally between a flow and any other LOTOS event, establishing a
given interface as being a stream interface is only possible informally by modelling the LOTOS events used to represent
flows differently to any other event. An example of how a stream interface signature might be modelled in LOTOS is
given in A.1.1.13.
A.1.1.9 Computational Object Template
In LOTOS a computational object template is represented by a process definition which has associated with it a set of
computational interface templates which the object can instantiate; a behaviour specification, i.e. a behaviour expression
that is not composed of events modelled as signal signatures, flow signatures or operation signatures. There should also
be some form of environmental contract modelled as part of the process definition, however, LOTOS does not possess
all of the necessary features to model environmental contracts fully. It may be possible to model some features in an
environmental contract through an Act One data type. This should be given as a formal parameter in the value parameter
list of the process definition.
A.1.1.10 Computational Interface Template
A signal interface template, a stream interface template or an operational interface template.
A.1.1.11 Signal Interface Signature
A signal interface signature is represented in LOTOS by a process definition, such that all event offers which require
synchronisation with the environment in order to occur are modelled as signal signatures. The occurrence of these event
offers result in a one-way communication from an initiating to a responding object. Structurally, a signal signature is
similar to an invocation for an announcement (or a termination associated with an interrogation), i.e. it consists of a name
(for the signal), a sequence of param
...
NORME ISO/CEI
INTERNATIONALE 10746-4
Première édition
1998-12-15
AMENDEMENT 1
2001-12-15
Technologies de l'information — Traitement
réparti ouvert — Modèle de référence:
Sémantique architecturale
AMENDEMENT 1: Formalisation de traitement
Information technology — Open Distributed Processing — Reference
Model: Architectural semantics
AMENDMENT 1: Computational formalization
Numéro de référence
ISO/CEI 10746-4:1998/Amd.1:2001(F)
©
ISO/CEI 2001
---------------------- Page: 1 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO/CEI 2001
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2002
Imprimé en Suisse
ii © ISO/CEI 2001 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001(F)
TABLE DES MATIÈRES
Page
1) Avant-propos . 1
2) Article 0 – Introduction . 1
3) Article 1 – Domaine d'application . 2
4) Article 2 – Références normatives. 2
5) Paragraphe 3.2 – Termes définis dans la Recommandation UIT-T Z.100. 2
6) Paragraphe 3.3 – Termes définis dans "The Z Base Standard". 2
7) Annexe A. 3
Annexe A – Formalisation de traitement . 3
A.1 Formalisation du langage de point de vue traitement en LOTOS. 3
A.2 Formalisation du langage de point de vue traitement en SDL. 13
A.3 Formalisation du langage de point de vue traitement en Z. 22
A.4 Formalisation du langage de point de vue traitement en ESTELLE. 30
© ISO/CEI 2001 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou de la
CEI participent au développement de Normes internationales par l'intermédiaire des comités techniques créés par
l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique. Les comités
techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI participent également
aux travaux. Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé un comité technique mixte,
l'ISO/CEI JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des organismes nationaux
votants.
L'attention est appelée sur le fait que certains des éléments du présent Amendement peuvent faire l'objet de droits
de propriété intellectuelle ou de droits analogues. L'ISO et la CEI ne sauraient être tenues pour responsables de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'Amendement 1 à la Norme internationale ISO/CEI 10746-4:1998 a été élaboré par le comité technique mixte
ISO/CEI JTC 1, Technologies de l'information, sous-comité SC 7, Ingénierie du logiciel, en collaboration avec
l'UIT-T. Le texte identique est publié en tant que Rec. UIT-T X.904/Amd.1.
iv © ISO/CEI 2001 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
NORME INTERNATIONALE
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
Rec. UIT-T X.904/Amd.1 (2000 F)
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION – TRAITEMENT RÉPARTI OUVERT –
MODÈLE DE RÉFÉRENCE: SÉMANTIQUE ARCHITECTURALE
AMENDEMENT 1
Formalisation de traitement
1) Avant-propos
er
Remplacer le 1 paragraphe de l'avant-propos
La présente Recommandation | Norme internationale fait partie intégrante du modèle de référence du traitement réparti
ouvert (ODP, open distributed processing). Elle contient une formalisation des concepts de modélisation ODP définis
dans les articles 8 et 9 de la Rec. UIT-T X.902 | ISO/CEI 10746-2. La formalisation est obtenue par l'interprétation de
chaque concept en fonction des constructions des différentes techniques de description formelle normalisées.
par:
La présente Recommandation | Norme internationale fait partie intégrante du modèle de référence du traitement réparti
ouvert (ODP, open distributed processing). Elle contient une formalisation des concepts de modélisation ODP définis
dans les articles 8 et 9 de la Rec. UIT-T X.902 | ISO/CEI 10746-2 et dans l'article 7 (Language de traitement) de la Rec.
UIT-T X.903 | ISO/CEI 10746-3. La formalisation est obtenue par l'interprétation de chaque concept en fonction des
constructions des différentes techniques de description formelle normalisées.
2) Article 0 – Introduction
e
Remplacer la 4 énumération sous "Le modèle RM-ODP se compose"
– de la Rec. UIT-T X.904 | ISO/CEI 10746-4: Sémantique architecturale: elle contient une formalisation
des concepts de modélisation ODP définis dans les articles 8 et 9 de la Rec. UIT-T X.902 |
ISO/CEI 10746-2 et une formalisation des langages de point de vue définis dans la Rec. UIT-T X.903 |
ISO/CEI 10746-3. La formalisation est obtenue par l'interprétation de chaque concept en fonction des
constructions des différentes techniques de description formelle normalisées. Ce texte est normatif.
par
– de la Rec. UIT-T X.904 | ISO/CEI 10746-4: Sémantique architecturale: elle contient une formalisation
des concepts de modélisation ODP définis dans les articles 8 et 9 de la Rec. UIT-T X.902 |
ISO/CEI 10746-2 et une formalisation des langages de point de vue traitement définis dans la Rec. UIT-T
X.903 | ISO/CEI 10746-3. La formalisation est obtenue par l'interprétation de chaque concept en fonction
des constructions des différentes techniques de description formelle normalisées. Ce texte est normatif.
e
Remplacer le 4 paragraphe:
La présente Recommandation | Norme internationale a pour objet de fournir une sémantique architecturale pour les
systèmes ODP, ce qui se traduit par une interprétation des concepts de modélisation de base et de spécification définis
dans la Rec. UIT-T X.902 | ISO/CEI 10746-2 et des langages de point de vue définis dans la Rec. UIT-T X.903 |
ISO/CEI 10746-3; elle utilise les diverses caractéristiques de différents langages de spécification formelle. Une
sémantique architecturale est élaborée pour quatre différents langages de spécification formelle: LOTOS, ESTELLE,
SDL et Z, ce qui conduit à une formalisation de l'architecture des systèmes ODP. Un processus d'élaboration itérative et
de retour a permis d'améliorer la cohérence des Rec. UIT-T X.902 | ISO/CEI 10746-2 et UIT-T X.903 |
ISO/CEI 10746-3.
Rec. UIT-T X.904/Amd.1 (2000 F) 1
---------------------- Page: 5 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
par
La présente Recommandation | Norme internationale a pour objet de fournir une sémantique architecturale pour les
systèmes ODP, ce qui se traduit par une interprétation des concepts de modélisation de base et de spécification définis
dans la Rec. UIT-T X.902 | ISO/CEI 10746-2 et des langages de point de vue traitement définis dans la Rec. UIT-T
X.903 | ISO/CEI 10746-3; elle utilise les diverses caractéristiques de différents langages de spécification formelle. Une
sémantique architecturale est élaborée pour quatre différents langages de spécification formelle: LOTOS, ESTELLE,
SDL et Z, ce qui conduit à une formalisation de l'architecture des systèmes ODP. Un processus d'élaboration itérative et
de retour a permis d'améliorer la cohérence des Rec. UIT-T X.902 | ISO/CEI 10746-2 et UIT-T X.903 |
ISO/CEI 10746-3.
3) Article 1 – Domaine d'application
Ajouter le paragraphe suivant à la fin du Domaine d'application
L'Annexe A indique une manière selon laquelle le langage de point de vue traitement de la Rec. UIT-T X.903 | ISO/CEI
10746-3 peut-être représenté dans les langages formels LOTOS, SDL, Z et Estelle. La présente Recommandation |
Norme internationale fait également appel aux concepts définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2.
4) Article 2 – Références normatives
Changer la date de publication pour la Recommandation UIT-T Z.100 de (1993) en (1999).
ISO/CEI 13568:
Ajouter la référence suivante:
Z Notation, ISO/CEI JTC 1 SC 22 GT 19, Advanced Working Draft 2.C, 13 juillet 1999.
5) Paragraphe 3.2 – Termes définis dans la Recommandation UIT-T Z.100
Remplacer la liste des termes par la suivante:
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, if, import, imported, in, inherits, input, interface, join, literal, literals, map, mod, nameclass,
newtype, nextstate, nodelay, noequality, none, not, now, offspring, operator, operators, or, ordering, out, output,
package, parent, priority, procedure, process, provided, redefined, referenced, refinement, rem, remote, reset, return,
returns, revealed, reverse, save, select, self, 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.
6) Paragraphe 3.3 – Termes définis dans "The Z Base Standard"
Changer le titre du paragraphe par:
3.3 – Termes définis dans "The Z Notation"
Remplacer la liste des termes par la suivante:
affinement de données, affinement d'opération, théorie des schémas, composition de schéma, description axiomatique,
occultation, remplacement, schéma (opération, état, encadrement), séquence, type.
2 Rec. UIT-T X.904/Amd.1 (2000 F)
---------------------- Page: 6 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
7) Annexe A
Ajouter une nouvelle Annexe A comme suit:
Annexe A
Formalisation de traitement
A.1 Formalisation du langage de point de vue traitement en LOTOS
A.1.1 Concepts
La formalisation du langage de traitement en LOTOS utilise les concepts définis dans la formalisation des règles de
modélisation et de structuration de base indiquées aux articles 8 et 9 de la Rec. UIT-T X.902 | ISO/CEI 10746–2.
Structures élémentaires associées aux interfaces opération et signal
Pour formaliser le langage de traitement en LOTOS, il est nécessaire d'introduire certaines structures élémentaires.
Celles-ci comportent des paramètres susceptibles d'être associés à certaines interfaces de traitement ainsi qu'un modèle
d'information de base susceptible d'être utilisé dans un flux.
Pour formaliser des paramètres il est nécessaire d'adopter deux concepts, à savoir celui de noms d'objets et celui de types
d'objets. Les noms sont simplement des étiquettes. Comme nous allons le voir, du point de vue traitement, ces étiquettes
doivent faire l'objet de contrôles, visant par exemple à en vérifier l'égalité, au moment où les interfaces sont créées. En
règle générale, nous pouvons représenter les noms comme suit:
type Name is Boolean
sorts Name
opns newName: -> Name
anotherName: Name -> Name
_eq_,_ne_: Name, Name -> Bool
endtype (* Name *)
Par souci de concision, nous faisons l'impasse sur les équations, qui ne sont pas censées poser de problème particulier. Il
est possible d'être ici plus normatif, par exemple en utilisant des chaînes de caractères de la bibliothèque LOTOS. La
seule chose qui nous intéresse en ce qui concerne les noms est que nous puissions en déterminer l'égalité ou l'inégalité.
Comme indiqué dans la présente Recommandation | Norme internationale, un type selon la terminologie ODP ne peut
pas être interprété directement dans la partie "algèbre de processus" du langage LOTOS. Il est toutefois possible de
modéliser des types à l'aide de la partie "Act One" du LOTOS. Bien qu'elle ait été expressément conçue pour représenter
des types, la partie Act One est malheureusement limitée dans ses modalités de vérification des types et des relations
entre les types. Par exemple, il est impossible de vérifier le sous-typage ou l'équivalence, voire l'isomorphisme entre les
types, du fait que l'égalité de types en Act One est fondée sur l'équivalence de noms de sortes. A l'appui de notre
raisonnement, nous introduisons ici une notion élémentaire de types qui nous permet de tester l'égalité, l'inégalité et le
sous-typage.
type AnyType is Boolean
sorts AnyType
opns newType: -> AnyType
anotherType: AnyType -> AnyType
_eq_,_isSubtype_: AnyType, AnyType -> Bool
endtype (* AnyType *)
Un paramètre est une relation entre un nom et sa représentation de type sous-jacente. Un paramètre peut donc être
représenté comme suit:
type Param is Name, AnyType
sorts Param
opns newParam: Name, AnyType -> Param
_eq_,_ne_,_isSubtype_: Param, Param -> Bool
endtype (* Param *)
Comme précédemment, nous devons procéder à des contrôles de l'égalité ou de l'inégalité des paramètres ainsi que dans
le cas où un paramètre est un sous-type d'un autre paramètre. Deux paramètres ont une relation de sous-typage lorsque
leurs types ont une relation de sous-typage. Il est par ailleurs utile pour nous d'introduire des séquences de ces
paramètres.
Rec. UIT-T X.904/Amd.1 (2000 F) 3
---------------------- Page: 7 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
type PList is String actualizedby Param
using sortnames PList for String Param for Element Bool for FBool
opns _isSubtype_: PList, PList -> Bool
endtype (* PList *)
Nous utilisons ici le type String de la bibliothèque LOTOS, actualisé avec le type Param défini précédemment. En outre,
nous incluons ici une opération isSubtype permettant de vérifier si une séquence de paramètres est un sous-type d'une
autre. Une liste de paramètres est un sous-type d'une autre liste lorsque tous les paramètres qu'elle contient sont des sous-
types de ceux qui figurent dans la première liste. En outre, les paramètres devraient occuper la même position dans leurs
listes respectives. Il convient de noter que ces paramètres sont susceptibles de contenir des références aux interfaces
utilisées pour limiter les interactions qui peuvent se produire. Alors qu'il est tout à fait possible de modéliser une
interface dans l'algèbre de processus, il est impossible de modéliser une référence à cette interface dans l'algèbre de
processus qui, pour ainsi dire, s'approprie la fonctionnalité de cette interface. Pour surmonter cette difficulté, nous
modélisons les références d'interface en Act One. Etant donné qu'une référence d'interface reproduit, entre autres choses,
la signature de l'interface, nous fournissons un modèle de signatures en Act One pour les opérations. Les opérations se
composent d'un nom, d'une séquence d'entrées et éventuellement d'une séquence de sorties. Pour simplifier les choses,
nous ne nous soucions pas ici de savoir si l'opération est en notation infixée, préfixée ou suffixée. Cela peut-être
représenté par le fragment LOTOS suivant:
type Op is Name, PList
sorts Op
opns makeOp: Name, PList -> Op
makeOp: Name, PList, PList -> Op
getName: Op -> Name
getInps: Op -> PList
getOuts: Op -> PList
_eq_: Op, Op -> Bool
eqns forall op1,op2: Op, n: Name; pl1, pl2: PList
ofsort Name getName(makeOp(n,pl1,pl2)) = n;
ofsort PList getInps(makeOp(n,pl1)) = pl1;
getInps(makeOp(n,pl1,pl2)) = pl1;
getOuts(makeOp(n,pl1)) = <>;
getOuts(makeOp(n,pl1,pl2)) = pl2;
ofsort Bool op1 eq op2 = ((getName(op1) eq getName(op2)) and
(getInps(op1) isSubtype getInps(op2)) and
(getOuts(op2) isSubtype getOuts(op1)));
endtype (* Op *)
Le fait de disposer d'une méthode permettant de déterminer si deux opérations sont identiques ramène le problème du
sous-typage entre types abstraits de données à une comparaison d'ensembles, dont les éléments sont les opérations
créées. Ainsi, un serveur est un sous-type d'un autre serveur s'il prend en charge toutes les opérations de cet autre
serveur. A noter ici que nous modélisons deux formes d'opérations: celle dont on n'attend pas de résultats et celle dont on
en attend. En outre, nous introduisons des ensembles de ces opérations.
type OpSet is Set actualizedby Op
using sortnames OpSet for Set Op for Element Bool for FBool
endtype (* OpSet *)
Cela étant, une référence d'interface peut être représentée par le fragment LOTOS suivant:
type IRef is OpSet
sorts IRef
opns makeIRef : OpSet -> IRef
NULL : -> IRef
getOps : IRef -> OpSet
_eq_ : IRef, IRef -> Bool
eqns forall o: OpSet; ir1, ir2: IRef
ofsort OpSet getOps(makeIRef(o)) = o;
ofsort Bool ir1 eq ir2 = getOps(ir1) eq getOps(ir2) ;
endtype (* IRef *)
Nous constatons ici que l'égalité des références d'interface est fondée uniquement sur les opérations contenues dans la
référence considérée. Elle pourrait parfaitement être étendue à d'autres aspects, tels que l'emplacement de l'interface ou
les contraintes qui en restreignent l'utilisation. En outre, nous introduisons des ensembles de ces références d'interface.
type IRefSet is Set actualizedby IRef
using sortnames IRefSet for Set IRef for Element Bool for FBool
endtype (* IRefSet *)
4 Rec. UIT-T X.904/Amd.1 (2000 F)
---------------------- Page: 8 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
Structures élémentaires associées aux interfaces flux
Le langage de point de vue traitement de la Recommandation UIT-T X.903 | ISO/CEI 10746–3 examine en outre les
interfaces relatives au flux continu de données, par exemple multimédias. Ces interfaces sont appelées interfaces flux.
Les interfaces flux contiennent des ensembles finis de flux. Ces flux peuvent provenir de l'interface (flux producteur) ou
se diriger vers l'interface (flux consommateur). Chaque flux est modélisé au moyen d'un modèle d'action. Chaque modèle
d'action contient le nom du flux, le type du flux ainsi qu'une indication de causalité pour ce flux.
Le point de vue traitement s'éloigne du contenu du flux d'informations proprement dit. Nous retenons ici un principe
générique du flux d'informations selon lequel ce flux est représenté par une séquence d'éléments de flux. Un élément de
flux peut être considéré comme un élément particulier du flux d'informations. Nous constatons ici que les flux sont
considérés du point de vue traitement comme des actions continues. Dans le modèle que nous présentons ici, les flux sont
représentés comme des séquences d'événements temporels discrets. D'un côté cela nous permet de remédier aux
problèmes de synchronisation des flux d'informations, même si cela se traduit par la perte du caractère continu des flux.
Chaque élément d'un flux d'information peut être considéré comme une unité composée de données (qui peuvent être
comprimées) et que nous représentons par Données. Ce modèle peut indiquer comment les informations ont été
comprimées, quelles informations ont été comprimées, etc. En tant que tel, ce modèle n'est pas examiné plus avant ici.
De plus, les éléments de flux contiennent un champ d'indication horaire servant à modéliser l'heure à laquelle l'élément
de flux considéré a été envoyé ou reçu. En outre, il arrive souvent, dans le cas de flux multimédias, que des éléments de
flux de synchronisation soient nécessaires, par exemple pour synchroniser le son avec l'image. C'est pourquoi nous
associons un nom donné (Name) à chaque élément de flux. Ce nom peut ensuite servir à sélectionner un élément de flux
donné, selon les besoins. Il en découle que nous pouvons modéliser un élément de flux comme suit:
type FlowElement is Name, NaturalNumber, Data, Param
sorts FlowElement
opns makeFlowElement: Data, Nat, Name -> FlowElement
nullFlowElement : -> FlowElement
getData : FlowElement -> Data
getTime : FlowElement -> Nat
getName : FlowElement -> Name
toParam : FlowElement -> Param
setTime : Nat, FlowElement -> FlowElement
eqns forall d: Data, s,t: Nat, n: Name
ofsort Data getData(makeFlowElement(d,t,n)) = d;
ofsort Nat getTime(makeFlowElement(d,t,n)) = t;
ofsort Name getName(makeFlowElement(d,t,n)) = n;
ofsort FlowElement setTime(s,makeFlowElement(d,t,n)) = makeFlowElement(d,s,n);
endtype (* FlowElement *)
Il convient de noter ici que nous modélisons le temps sous la forme d'un nombre naturel. Toutefois, les valeurs de
modélisation retenues pourraient très bien aussi être exprimées en temps réel (continu) ou en intervalles de temps. Pour
simplifier les choses, nous nous bornons ici à représenter le temps discret sous la forme d'un nombre naturel. Par ailleurs,
nous introduisons une opération permettant de convertir un élément de flux en un paramètre. Pour simplifier les choses,
nous faisons l'impasse sur les équations associées. En outre, nous introduisons des séquences de ces éléments de flux:
type FlowElementSeq is FlowElement
sorts FlowElementSeq
opns makeFlowElementSeq: -> FlowElementSeq
addFlowElement: FlowElement, FlowElementSeq -> FlowElementSeq
remFlowElement: FlowElement, FlowElementSeq -> FlowElementSeq
getFlowElement: Name, FlowElementSeq -> FlowElement
timeDiff: FlowElement, FlowElement -> Nat
eqns forall f1, f2: FlowElement, fs: FlowElementSeq, n1,n2: Name
ofsort FlowElementSeq
getTime(f1) le getTime(f2) =>
addFlowElement(f1,addFlowElement(f2,makeFlowElementSeq)) =
addFlowElement(f2,makeFlowElementSeq);
ofsort FlowElement
getFlowElement(n1,makeFlowElementSeq) = nullFlowElement;
n1 ne n2 =>
getFlowElement(n1,addFlowElement(makeFlowElement(d,t,n2),fs)) =
getFlowElement(n1,fs);
n1 eq n2 =>
getFlowElement(n1,addFlowElement(makeFlowElement(d,t,n2),fs)) =
makeFlowElement(d,t,n2);
endtype (* FlowElementSeq *)
Rec. UIT-T X.904/Amd.1 (2000 F) 5
---------------------- Page: 9 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
Par souci de concision, nous ne reproduisons pas toutes les équations. Les éléments de flux sont ajoutés à la séquence
pour autant qu'ils présentent des valeurs de champ d'indication horaire croissantes. Une opération permettant de traverser
une séquence d'éléments de flux pour trouver un élément de flux nommé est prévue. En outre, nous introduisons une
opération permettant de calculer les différences horaires entre les champs d'indication horaire de deux éléments de flux.
Le recours à cette opération permet de préciser, par exemple, que tous les éléments de flux d'une séquence sont séparés
par des champs d'indication horaire égaux. Nous sommes alors en présence d'un flux isochrone. En outre, nous
introduisons des ensembles de ces séquences d'éléments de flux:
type FlowElementSeqSet is Set actualizedby FlowElementSeq
using sortnames FlowElementSeqSet for Set FlowElementSeq for Element Bool for FBool
endtype (* FlowElementSeqSet *)
A.1.1.1 Signal
Aucun élément propre au LOTOS ne permet de faire la distinction entre un signal, un flux et une opération. Il peut
arriver, toutefois, qu'un style de LOTOS permette de faire la distinction entre des signaux, des flux et des opérations. Par
exemple, tous les signaux pourraient avoir des formats analogues pour leurs offres d'événement. Un exemple d'un format
possible côté serveur d'un signal est représenté dans le fragment LOTOS suivant:
? ! ?;
Ici et dans le reste du paragraphe A.1, nous adoptons la notation selon laquelle tient lieu de paramètre fictif pour un
X, c'est-à-dire que g, sigName, myRef et inArgs tiennent lieu respectivement de paramètres fictifs pour la porte, le nom du
signal, la référence d'interface associée au serveur offrant ce signal et les paramètres associés au signal.
Un exemple de format possible côté client d'un signal est représenté dans le fragment LOTOS suivant:
! ! !;
Ici le côté client du signal contient une porte (g), une étiquette pour le nom du signal (sigName), une référence désignant
l'objet auquel le signal est envoyé (SomeIRef) et les paramètres associés au signal (inArgs). Nous verrons au § A.1.1.11
comment ces offres d'événement peuvent être utilisées pour créer des signatures d'interface signal.
A.1.1.2 Opération
Occurrence d'une interrogation ou d'une annonce.
A.1.1.3 Annonce
Interaction consistant en une seule invocation. Pour les raisons indiquées au § A.1.1.1, on ne peut utiliser qu'une
convention de modélisation informelle pour modéliser des annonces. Un exemple de cette règle pour le côté client d'une
annonce pourrait être représenté comme suit:
! ! !;
Le côté serveur d'une annonce pourrait être représenté comme suit:
? ! ?;
Les structures de données sont ici analogues à celles qui sont décrites au § A.1.1.1. Nous verrons au § A.1.1.12 comment
ces offres d'événement peuvent être utilisées pour créer des parties de signature d'interface opération.
A.1.1.4 Interrogation
Invocation entre un client et un serveur, suivie d'une ou plusieurs terminaisons entre ce serveur et ce client. Toutefois,
pour les raisons indiquées au § A.1.1.1, on ne peut utiliser qu'une convention de modélisation informelle pour modéliser
les interrogations. Un exemple de cette règle pour le côté client d'une interrogation pourrait être représenté comme suit:
! ! ! !;
( ? ! ?; (* . other behaviour *)
[ ] (* . other terminations *))
Ici termName représente les noms de terminaison et outArgs représente les paramètres de sortie. Le côté serveur d'une
interrogation pourrait être représenté comme suit:
? ! ? ?;
( ! ! !; (* . other behaviour *)
[ ] (* . other terminations *))
Les autres structures de données considérées ici sont analogues à celles qui sont décrites au § A.1.1.1. Nous verrons au
§ A.1.1.12 comment ces offres d'événement peuvent être utilisées pour créer des parties de signatures d'interface
opération.
6 Rec. UIT-T X.904/Amd.1 (2000 F)
---------------------- Page: 10 ----------------------
ISO/CEI 10746-4:1998/Amd.1:2001 (F)
A.1.1.
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.