ISO/IEC 10165-4:1992/Amd 3:1998
(Amendment)Information technology — Open Systems Interconnection — Structure of management information — Part 4: Guidelines for the definition of managed objects — Amendment 3: Guidelines for the use of Z in formalizing the behaviour of managed objects
Information technology — Open Systems Interconnection — Structure of management information — Part 4: Guidelines for the definition of managed objects — Amendment 3: Guidelines for the use of Z in formalizing the behaviour of managed objects
Technologies de l'information — Interconnexion de systèmes ouverts — Structure des informations de gestion — Partie 4: Directives pour la définition des objets gérés — Amendement 3: Directives pour l'utilisation du langage Z dans la formalisation du comportement des objets gérés.
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 10165-4
First edition
1992-09-01
AMENDMENT 3
1998-12-15
Information technology — Open Systems
Interconnection — Structure of
management information: Guidelines for
the definition of managed objects
AMENDMENT 3: Guidelines for the use of Z in
formalizing the behaviour of managed objects
Technologies de l'information — Interconnexion de systèmes ouverts —
Structures des informations de gestion: Partie 4: Principes directeurs pour
la définition des objets gérés
AMENDEMENT 3: Principes directeurs pour l'utilisation de Z dans la
formalisation du comportement de l'objet géré
B C Reference number
ISO/IEC 10165-4:1992/Amd.3:1998(E)
---------------------- Page: 1 ----------------------
ISO/IEC 10165-4:1992/Amd.3:1998(E)
Contents
Page
1) Table of contents . 1
2) Subclause 2.1. 1
3) New subclause 2.3 . 1
4) New Annex B. 1
Annex B – Guidelines for the use of Z in formalizing the behaviour of Managed Objects. 2
© ISO/IEC 1998
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 the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
©
ISO/IEC ISO/IEC 10165-4:1992/Amd.3:1998(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. 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.
Amendment 3 to ISO/IEC 10165-4:1992 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 33, Distributed application services, in collaboration with ITU-T. The identical text is published as ITU-T
Rec. X.722/Amd.3.
iii
---------------------- Page: 3 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
INTERNATIONAL STANDARD
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – OPEN SYSTEMS INTERCONNECTION –
STRUCTURE OF MANAGEMENT INFORMATION: GUIDELINES FOR
THE DEFINITION OF MANAGED OBJECTS
AMENDMENT 3
Guidelines for the use of Z in formalizing the behaviour of managed objects
1) Table of contents
Add the following reference to the table of contents:
Annex B – Guidelines for the use of Z in formalizing the behaviour of managed objects
2) Subclause 2.1
Add the following reference to 2.1:
– CCITT Recommendation X.731 (1992) | ISO/IEC 10164-2:1992, Information technology – Open Systems
Interconnection – Systems Management: State management function.
3) New subclause 2.3
Add a new subclause as follows:
2.3 Additional references
1)
– ISO/IEC 13568: , Information technology – Z specification language.
1)
Presently at the stage of draft.
4) New Annex B
Add a new Annex B, as follows:
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 1
---------------------- Page: 4 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
Annex B
Guidelines for the use of Z in formalizing the behaviour of Managed Objects
(This annex does not form an integral part of this Recommendation | International Standard)
B.1 Introduction
This annex contains a technical guide on the use of the Z language for defining the behaviour of managed objects which
support OSI management interworking. It is informative and not normative. It does not require Formal Definition
Techniques (FDTs) to be used to specify MO behaviour. If FDTs are to be used, it does not require Z to be used; other
languages such as SDL are also suitable. Even if Z is to be used, other ways of specifying MO behaviour are possible.
Formal specifications of MO behaviour can be directly valuable because they are clear and unambiguous. The act of
producing a formal specification forces the details of the behaviour to be analysed closely. Thus, it can also be used as a
tool to identify and correct ambiguities which might go undetected in a specification relying solely on natural language.
For these reasons formal specification can be useful to improve behaviour specification.
This annex contains an illustrative example that demonstrates current best practice. It aims to establish a common basis
and understanding of this particular formal approach which will help achieve consistency in similar developments. It
should provide a useful starting point for GDMO users wishing to use Z to improve their behaviour specifications.
It is aimed at an audience familiar with the basic concepts of managed object specification using the GDMO templates,
and the Z language.
For the remainder of this annex, the terms “managed object” and “MO” will be used to refer to a managed object class
definition given using the GDMO templates.
B.2 Language issues
The Z notation is a formal specification notation based on set theory and predicate calculus. It possesses sufficient
expressive power to be able to describe single classes of managed objects.
However, there exists no notion of encapsulation in Z. A Z specification typically consists of a model of some state and a
collection of operations to modify the state. There is no method built into Z to parcel the state and its operations up into a
single module and re-use it in another specification. The consequence of this becomes apparent when it becomes
necessary to describe managed objects which inherit variables and behaviour from other managed object class definitions.
The effect of inheritance can be achieved by the technique of schema inclusion at the expense of some clarity. In all other
respects Z is suitable for expressing single classes of managed objects.
B.3 What needs to be translated
The behaviour definitions, or parts there of, need to be translated from the informal description into Z. The extent to
which the remaining parts of the GDMO templates need to be formalized depends largely on the needs of the specifier.
The GDMO templates already include a semi-formal definition of data types in ASN.1. It is possible to write a
Z specification using these ASN.1 definitions as a basis for types used in the Z specification, and this saves a significant
amount of work.
However, if a specification is written in this way, then it makes it a greater task for the specifier to ensure that it is
syntactically correct. Without Z specifications of the ASN.1 definitions, it is not possible to use existing Z tools which
provide support for checking the syntax and static semantics of a Z specification.
In summary, it is possible to improve the behaviour definitions by using Z without re-writing the ASN.1 data types, but
there is a significant benefit to be gained by a full translation of the ASN.1 data types into Z. Examples of how to convert
ASN.1 Basic Types into Z are provided in B.7.1.
2 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 5 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.3.1 From GDMO templates to Z
This subclause contains general guidelines of how to go about translating a managed object from its informal description
as given in this Recommendation | International Standard into Z. It should be stressed at the outset that such a translation
can only be carried out informally since a formal translation would require, as a minimum, that both the source and target
languages be formal.
Moreover, as with any mapping between two distinct languages, there is bound to be some mismatch between their
constructs. The problem multiplies when one of the languages happens to be informal or to include informal components.
In this subclause some of the main features of the templates defined in this Recommendation | International Standard are
listed together with the ways in which they differ from or correspond to constructs in Z. In the process, general ways of
resolving the mismatch or advice on how they may be tackled individually on an ad-hoc basis is offered.
This annex will concentrate on what is necessary to describe the behaviour of a managed object. Additional information
on how to convert ASN.1 types is provided in B.6.
B.3.2 Datatypes
The first step is to rewrite the datatypes from this Recommendation | International Standard as Z types. ASN.1 provides
the usual facilities of datatyping but its constructors are biased towards the description of datastreams communicated
between systems.
In ASN.1, the type constructors are defined as forms of list. In Z, types are sets. Although it is possible to model the
ASN.1 type constructors as sequences in Z, it is sometimes more natural to consider the operations available on the
ASN.1 types and to map them to Z types which more clearly describe their structure. The ASN.1 sequence and set types
can be mapped to Z tuples. The ASN.1 sequence-of type can be mapped to a Z sequence. The ASN.1 set-of type can be
mapped to a Z set.
ASN.1 includes special support for encoding, such as type labels and default values. This does not need to be represented
in Z since it doesn’t affect the behaviour definition.
Subclause B.6.2 provides additional information on how to convert ASN.1 types.
B.3.3 MO Attributes
Managed objects are defined to have certain management attributes. These attributes have a datatype defined in ASN.1.
They are assigned object identifiers. They also may have a matches-for property. Two ways to model such attributes have
been proposed:
• simple attribute types; and
• attribute types as schemas.
The simplest is to represent the MO attribute within the MO as a Z variable with the appropriate datatype. Then
separately we will need a constant definition which represents the object identifier of that attribute. This constant will be
related to the actual attribute by convention only. We can use the actual fixed matches-for property when matching
operations are defined for that attribute. An example of this is given in B.6.3.
It is also possible to encapsulate all these properties of an attribute in a single schema type which will then be the type of
the Z variable modelling the MO attribute. Thus, the schema will include the value of the attribute as well as the object
identifier and the matches-for property if any. An example of this is given in B.6.4. Where matching rules other than
equality are required, it is possible to define the matches-for parameter as a Z relation over the type of the value of the
attribute. This allows the formal representation of arbitrary ad-hoc matching rules, which may be important for scoping,
filtering and object selection.
It is difficult to model ASN.1 type ANY in Z. One case where this is common is to give lists of attribute values. Thus, a
fully formal model will probably require a Z free type combining the attribute types already defined. An example of this
can be found in B.6.1 and B.6.5.
Object identifiers are formally modelled by a given set.
[OBJECTID]
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 3
---------------------- Page: 6 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.3.4 Other Object Identifiers
Many things besides attributes also have an Object Identifier. It is convenient to introduce them all as constants in
axiomatic definitions. The convention of suffixing them with “Oid” will be used. Typically such constants will be needed
for classes, packages and notifications.
An example is:
packagesPackageOid : OBJECTID
allomorphsPackageOid : OBJECTID
topClassOid : OBJECTID
B.3.5 Inheritance and Compatibility
Z can be used to build inheritance hierarchies of MOs by using schema inclusion to model inheritance and specialization.
This does correctly model the behaviour of an MO class and its sub-types but it fails to make explicit the strong sub-
typing relationship that is really present. For that, a language that models inheritance explicitly is needed.
Thus Z can be used to define individual MOs satisfactorily, but to be able to talk about inheritance and compatibility, the
additional power of a language that models inheritance explicitly is needed.
Inheritance is not supported by Z. It can be modelled by simple schema inclusion of state schemas.
The definition of MO inheritance requires sub-classes to be compatible. Unfortunately this does not require the
sub-classes to be sub-types in Z. Thus, typically an MO can report its actual class. Since the actual class attribute always
reports an object’s actual class, a sub-class cannot report the class of a super-class. Therefore a sub-class cannot exhibit
the same behaviour as its super-class in returning the value of its actual class attribute (i.e. it is not substitutable), even if
it is behaving allomorphically. Therefore managed object class sub-classing is not equivalent to Z sub-types, where a sub-
type would exhibit the same behaviour as its super-type. However, a sub-class exhibits very little “unsubstitutable”
behaviour.
In this way it can be seen that MO inheritance as defined in this Recommendation | International Standard allows specific
behaviour in a parent which is inconsistent with the behaviour of its children. Since there is a very limited amount of this
non-substitutable behaviour, an MO class can be represented by two class specifications. One captures the behaviour that
any instance and also any extended MO must exhibit. The other is a specialization and captures that behaviour exhibited
only by instances of the compatible class and not by any extensions. It is this latter specification that is instantiated to
give the complete behaviour of an actual MO instance.
B.3.6 Packages
Many parts of the functionality of a class may be present in some individual MOs and not in others. This
Recommendation | International Standard describes this process by grouping functionality into conditional packages.
Then, each MO instantiates appropriate packages. In Z functionality cannot be provided in this conditional way but it is
possible to make the behaviour of the MO depend on which packages are instantiated. This is straightforward because the
MO must contain a management attribute called packages which lists the object identifiers of the packages actually
instantiated. Thus, to model behaviour in a conditional package, the behaviour itself becomes conditional on the presence
of the package identifier in the packages attribute.
B.3.7 The Class
To define an MO class it is necessary to represent its attributes and its operations. Attributes become part of the Z state
schema and operations become Z operation schemas.
B.3.7.1 Attributes
The attributes of the managed object are declared in a state schema. Each attribute is given a type, which may be of a type
declared in the ASN.1 part of the GDMO template, or which may use types declared in Z in a fully formal model.
4 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 7 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.3.7.2 The Get operation
The manager may request a Get operation to be performed on an MO. The CMISE definition of M-Get has many
parameters but most of these are concerned with access control and object selection and so on. In this instance Get may
be modelled at the Managed Object Boundary ignoring these issues and replacing the single Get operation by a number
of Get operations, where is a single attribute.
B.3.7.3 The GetAll operation
A GetAll operation, which has no input, is also modelled. It returns a non-empty set of Attribute Values.
B.3.7.4 Replace operations
Set on an individual MO is requested by the CMISE M-Set operation. This specification models the Replace Operations
as seen at the MO Boundary instead. In this specification, Replace Operations refers to the attribute operations set, set to
default, add and remove.
The consequence of this is that a Z schema to represent each modification is specified.
B.3.7.5 Notifications
Notifications are unrequested messages sent by the MO to report events within it. However they are not modelled as
operations. Instead they are modelled as outputs from operations that happen on the MO. Thus, any operation (whether
invoked by the manager or internally by the resource) can generate output and if it causes a notification that notification
should be part of that operation’s output.
This means that the output of a Z operation schema that can cause notifications should be a set of notifications. Then
those occasions on which it does not emit a notification can be represented by giving an empty set as output.
The data in a notification consists of an EventType which is the object identifier of its standard definition. This is
followed by various information relevant to that particular notification. The object identifier can typically be defined as a
constant and the particular data as a schema-type. The behaviour of the notification is included in any object which can
generate the notification.
B.3.7.6 Actions
Actions are operations performed by the manager on the MO. They are very naturally represented by Z operations.
B.3.8 Specification of the system of objects
The rest of the annex describes how to represent the behaviour of a single object. When considering object
creation/deletion, name bindings, containment and naming, it is necessary to describe the state of the system where the
objects reside. Object creation and deletion can be represented by a change of state of this system. Name binding and
containment can be represented by a relation over the set of objects. Naming can then be defined in terms of this relation.
B.4 An example
In this subclause, example definitions for the MO class top and State Management attributes are given. Since the main
concern of this guide is the modelling of behaviour, the creation of Z types from ASN.1 types is not presented in this
subclause. A full formal definition is given in B.7.
B.4.1 top
The first class to be defined is top, which is the ultimate parent (in the inheritance hierarchy) of all MOs.
top has four management attributes, objectClass, packages, allomorphs and nameBinding. objectClass holds the object
identifier of the class, while packages holds the object identifiers of the packages it instantiates. nameBinding holds the
object identifier of the name binding used to instantiate the object and allomorphs holds the object identifiers of the
classes to which the object can be allomorphic. Since management attributes can be in packages, the attributes present in
MOs of a given class can vary. This is modelled by including an additional modelling attribute called attributes, which
holds the object identifiers of the attributes that are actually instantiated in the individual MO. Note that all the attributes
present in top are fixed for the lifetime of any individual MO.
Z does not explicitly model interfaces, and so it is not possible to formally define which operations are invoked internally
or externally by the manager.
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 5
---------------------- Page: 8 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
TopState
allomorphs: � OBJECTID
objectClass: OBJECTID
nameBinding: OBJECTID
packages: � OBJECTID
attributes: � OBJECTID
{objectClassOid, nameBindingOid} ˝ attributes
allomorphsPackageOid ˛ packages � allomorphsOid ˛ attributes
packagesPackageOid ˇ packages
packages „ ˘ � packagesOid ˛ attributes
attributes is not an MO attribute but a new state component defined for convenience. It lists the MO attributes an MO
includes. Thus, the invariant enforces that it must contain the object identifiers of the appropriate attributes as described
in B.3.3 (and defined in B.7.4). objectClass and nameBinding are mandatory. packages is present if any registered
package is instantiated apart from packagesPackage. In this case this means allomorphsPackage.
The operation TopGetNameBinding interrogates the MO and returns the value of the nameBinding attribute, without
changing TopState. TopGetNameBinding is invoked by the manager.
TopGetNameBinding
X TopState
result!: OBJECTID
result! = nameBinding
The operations TopGetAllomorphs, TopGetObjectClass and TopGetPackages have not been defined here. Note that there
is no operation to get attributes, since attributes is not a real MO attribute as specified in the GDMO template.
TopGetAll gets all the attribute values of an object. It always returns values for objectClass and nameBinding. If
conditional packages or allomorphs are present, then it gets those too. TopGetAll is invoked by the manager.
TopGetAll
X TopState
result!: ¿AttributeValues
# attributes = # result!
ObjectClassValue objectClass ˛ result!
NameBindingValue nameBinding ˛ result!
PackagesOid ˛ attributes � packagesValue packages ˛ result!
AllomorphsOid ˛ attributes � allomorphsValue allomorphs ˛ result!
TopEventReport is a way to model notifications. TopEventReport occurs spontaneously and represents the way event
reports are not controlled by the manager.
TopEventReport
X TopState
notification!: EventInfo
6 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 9 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.4.2 StateManagement class
This class does not reflect any specific MO class. Instead it reflects the behaviour of any object which includes any of
certain standard attributes: administrativeState, operationalState, and usageState. It is more convenient within this
framework to understand this inclusion as inheritance and it does serve as a useful example.
The state schema includes the TopState definitions and predicates, and defines some additional variables and predicate
conjunctions.
StateManagementState
TopState
administrativeState:
AdministrativeState
operationalState: OperationalState
usageState: UsageState
operationalState = disabled � usageState = idle
administrativeState = locked � usageState = idle
usageState = idle � administrativeState „ shuttingDown
State Management inherits the operations from Top. Although there is no mechanism built into Z to inherit operations, it
is straightforward to redefine the operations in terms of the new state. The predicate part of StateManagementState
follows from the definition of the State Management function in CCITT Rec. X.721 (1992) | ISO/IEC 10165-2:1992 and
CCITT Rec. X.731 (1992) | ISO/IEC 10164-2:1992.
The operation SMGetNameBinding can be easily defined, since it has no effect upon the new state variables declared in
StateManagementState. The definition of TopGetNameBinding can be re-used:
SMGetNameBinding
TopGetNameBinding
X StateManagementState
Definitions for operations to get the other attributes of StateManagementState have also been omitted from this example.
The operations SMGetAllomorphs, SMGetObjectClass and SMGetPackages can re-use the definitions from Top as for
SMGetNameBinding. New operations will need to be defined for GetSMAdministrativeState, GetSMOperationalState and
SMGetUsageState. SMEventReport may also be re-used.
The SMGetAll schema also makes use of an operation defined on TopState. It includes the definition of TopGetAll and
strengthens the postcondition.
SMGetAll
X StateManagementState
TopGetAll
administrativeStateOid ˛ attributes
� administrativeStateValue administrativeState ˛ result!
OperationalStateOid ˛ attributes
� operationalStateValue operationalState ˛ result!
UsageStateOid ˛ attributes
� usageStateValue usageState ˛ result!
The SMReplaceAdministrativeState operation describes behaviour specific to the State Management class whereby the
administrative state is replaced by another value supplied as an input. Depending on the state of the object when the
operation is carried out, the usage state may also be changed. The operational state is not altered by the operation.
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 7
---------------------- Page: 10 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
SMReplaceAdministrativeState
DStateManagementState
XTopState
input?: AdministrativeState
administrativeState' ˛
IF usageState „ idle
THEN { unlocked � unlocked,locked �locked,
shuttingDown �locked,locked �shuttingDown,
shuttingDown � shuttingDown} ' { input?} “
ELSE {unlocked � unlocked, locked � locked,
shuttingDown � locked} ' { input?} “
administrativeState' = locked � usageState' = idle
administrativeState' „ locked � usageState' = usageState
operationalState' = operationalState
The behaviour specified in the predicate part of the schema is a formalization of the informal description in
CCITT Rec. X.731 | ISO/IEC 10164-2. For completeness, operations to replace the operational state and the usage state
should also be defined.
Finally there are a number of other operations which describe behaviour specific to the State Management class. These
operations are not listed here, although they may be found in B.7. These operations include SMCapacityDecrease,
SMCapacityIncrease, SMDisable, SMEnable, SMNewUser and SMUserQuit.
B.4.3 Instantiable classes
Neither of the classes described above can be instantiated. The procedure that has been followed can be continued.
StateManagement can be re-used to define a class called CIRCUIT, which in turn can be used to define ECIRCUIT and
hence the instantiable class ActualECircuit.
This has been omitted from the guide, since the procedures are exactly the same as those that have outlined and repetition
adds nothing.
B.5 Outstanding Issues
In this subclause, the main issues encountered in the course of the translation from GDMO-based managed objects
specifications to Z are listed. Where an issue relates to Z not having a corresponding construct for a particular feature of
managed objects specification, the proposed informal treatment used in this annex will also be included.
B.5.1 Behaviour Definition in Managed Objects
In the templates, the term ‘behaviour definition’ is used for almost all entities whether they are data or processes. In the
latter case, it may include information about the actual behaviour (in the strict sense), or just static information about the
entity such as its intended use, or both. When translating, one needs to analyse the text which comes under this heading,
and extract the relevant behavioural information for the entity concerned. This behavioural information will be used in the
formal translation, while the actual text may be included as a comment inside the Z specification.
B.5.2 Internal operations in Z
An internal operation in a managed object represents the case where a notification is emitted spontaneously (with no
management invocation involved). Internal operations are also a desired feature of many other systems. Currently, in Z,
this feature is represented informally by a comment in the natural language text which is an important feature of any well-
written Z specification.
B.5.3 Abstract classes in Z
Sometimes it is useful to identify abstract classes: i.e. classes with no instantiations of their own. Some MO classes (like
top) cannot be instantiated. It would be helpful to be able to show which parts of the corresponding Z specifications
represent classes that can be instantiated. This is taken care of by informal annotation at present.
B.5.4 PARAMETER semantics
The incorporation of PARAMETER semantics into objects is not considered in this Recommendation | International
Standard.
8 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 11 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.6 Converting ASN.1 Datatypes to Z
Issues for translation will be described for each ASN.1 constructor in turn.
B.6.1 Simple types
ASN.1 includes some simple types which are built-in. These do have a standardized structure but it is usually not
interesting in the context of these specifications and so they can mostly be represented as given sets. There are a wide
variety of character string types:
[NUMERICSTRING, PRINTABLESTRING, TELETEXSTRING,
VIDEOTEXSTRING,VISIBLESTRING, IA5STRING,
GRAPHICSTRING, GENERALSTRING]
Two of these have synonyms:
T61STRING == TELETEXSTRING
ISO64STRING == VISIBLESTRING
Of the other simple types, Integer can be represented by �, Boolean and Null by free types:
Boolean ::= btrue | bfalse
Null ::= null
Note that these free types also define the value notation for these types.
Real, Bit String, and Octet String, can usually be taken to be given sets (though it may sometimes be necessary to
structure the Bit and Octet String types).
[REAL,BITSTRING,OCTET
...
INTERNATIONAL
STANDARD 101654
First edition
1992-09-O 1
AMENDMENT 3
19984245
Information technology - Open Systems
Interconnection - Structure of
management information: Guidelines for
the definition of managed objects
AMENDMENT 3: Guidelines for the use of Z in
formalizing the behaviour of managed objects
Technologies de I’informa tion - lnterconnexion de syst&mes owe& -
Structures des informations de gestion: Partie 4: Principes directeurs pour
la dgfinition des objets g&k
AMENDEMENT 3: Principes directeurs pour I’utilisation de 2 dans la
formalisation du comporlement de l’objet g&6
Reference number
ISO/I EC 10165-4: 1992iAmd.3: 1998( E)
---------------------- Page: 1 ----------------------
ISO/IEC 101654:1992/Amd.3:1998(E)
Contents
Page
..,.........................................................-...........................................................................................
Table of contents
1)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .“.~.
Subclause 2.1
2)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New subclause 2.3
3)
New Annex B ,.,
4)
- Guidelines for the use of 2 in formalizing the behaviour of Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex B
0 ISO/IEC 1998
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 the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH- I2 1 I Geneve 20 l Switzerland
Printed in Switzerland
---------------------- Page: 2 ----------------------
ISO/IEC 101654:1992/Amd.3:1998(E)
0 ISO/IEC
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, ISO/IEC JTC 1. 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.
Amendment 3 to ISO/IEC 10 165-4: 1992 was prepared by Joint Technical Committee ISO/IEC JTC I, Information technology,
Subcommittee SC 33, Distributed application services, in collaboration with ITU-T. The identical text is published as ITU-T
Rec. X.722/Amd.3.
---------------------- Page: 3 ----------------------
This page intentionally left blank
---------------------- Page: 4 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
STRUCTURE OF MANAGEMENT INFORMATION: GUIDELINES FOR
THE DEFINITION OF MANAGED OBJECTS
AMENDMENT 3
Guidelines for the use of Z in formalizing the behaviour of managed objects
Table of contents
1)
Add the following reference to the table of contents:
Annex B - Guidelines for the use of 2 in formalizing the behaviour of managed objects
Subclause 2.1
2)
Add the following reference to 2.1:
-
CCITT Recommendation X.73 1 (1992) I ISOIIEC 10164-2: 1992, Information technology - Open Systems
- Systems Management: State management function.
Interconnection
New subclause 2.3
3)
Add a new subclause as follows:
23 . Additional references
-
ISOLIEC 13568: l), Information technology - Z specification language.
1)
Presently at the stage of draft.
New Annex B
4)
Add a new Annex B, as follows:
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 1
---------------------- Page: 5 ----------------------
ISO/IEC 101654 : 1992/Amd.3 : 1998 (E)
Annex B
Guidelines for the use of Z in formalizing the behaviour of Managed Objects
(This annex does not form an integral part of this Recommendation I International Standard)
Bl . Introduction
This annex contains a technical guide on the use of the 2 language for defining the behaviour of managed objects which
support OS1 management interworking. It is informative and not normative. It does not require Formal Definition
Techniques (FDTs) to be used to specify MO behaviour. If FDTs are to be used, it does not require 2 to be used; other
languages such as SDL are also suitable. Even if 2 is to be used, other ways of specifying MO behaviour are possible.
Formal specifications of MO behaviour can be directly valuable because they are clear and unambiguous. The act of
producing a formal specification forces the details of the behaviour to be analysed closely. Thus, it can also be used as a
tool to identify and correct ambiguities which might go undetected in a specification relying solely on natural language.
For these reasons formal specification can be useful to improve behaviour specification.
This annex contains an illustrative example that demonstrates current best practice. It aims to establish a common basis
and understanding of this particular formal approach which will help achieve consistency in similar developments. It
should provide a useful starting point for GDMO users wishing to use Z to improve their behaviour specifications.
concepts of managed object specification using the GDMO templates,
It is aimed at an audience familiar with the basic
and the Z language.
For the remainder of this annex, the terms “managed object” and “MO” will be used to refer to a managed object class
definition given using the GDMO templates.
B.2 Language issues
and predicate calculus. It sufficient
The Z notation is a formal specificati on notation based on set theory possesses
express ive power to be able to describe single classes of managed objects.
However, there exists no notion of encapsulation in Z. A Z specification typically consists of a model of some state and a
collection of operations to modify the state. There is no method built into Z to parcel the state and its operations up into a
single module and re-use it in another specification. The consequence of this becomes apparent when it becomes
necessary to describe managed objects which inherit variables and behaviour from other managed object class definitions.
The effect of inheritance can be ach ieved by the technique of schema inclusion at the expense of some clarity. In all other
is suitable for
respects Z expressing single cl asses of managed objects
B.3 What needs to be translated
The behaviour definitions, or parts there of, need to be translated from the informal description into Z. The extent to
which the remaining parts of the GDMO templates depends large ly on the needs of the specifier.
need to be formalized
The GDMO templates already include a semi-formal definition of data types in ASN. 1. It is possible to write a
Z specification using these ASN. 1 definitions as a basis for types used in the Z specification, and this saves a significant
amount of work.
However, if a specification is written in this way, then it makes it a greater task for the specifier to ensure that it is
syntactically correct. Without Z specifications of the ASN.1 definitions, it is not possible to use existing Z tools which
provide support for checking the syntax and static semantics of a Z specification.
In summary, it is possible to improve the behaviour definitions by using Z without re-writing the ASN. 1 data types, but
there is a significant benefit to be gained by a full translation of the ASN.l data types into Z. Examples of how to convert
ASN. 1 Basic Types into Z are provided in B.7.1.
2 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 6 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.3.1 From GDMO templates to Z
This subclause contains general guidelines of how to go about translating a managed object from its informal description
as given in this Recommendation I International Standard into Z. It should be stressed at the outset that such a translation
can only be carried out informally since a formal translation would require, as a minimum, that both the source and target
languages be formal.
.
Moreover, as with anv mapping between two distinct languages, there bound to be some mismatch between their
bl: informal or to include informal
constructs. The problem multiplies when one of the languages happens to components.
In this subclause some of the main features of the templates defined in this Recommendation I International Standard are
listed together with the ways in which they differ from or correspond to constructs in Z. In the process, general ways of
resolving the mismatch or advice on how they may be tackled individually on an ad-hoc basis is offered.
This annex wi 11 concentrate on what is necessary to describe the behaviour of a managed object. Additional information
on how to con vert ASN. 1 types is provided in B.6.
B.3.2 Datatypes
The first step is to rewrite the datatypes from this Recommendation I International Standard as Z types. ASN.l provides
the usual facilities of datatyping but its constructors are biased towards the description of datastreams communicated
between systems.
In ASN.1, the type constructors are defined as forms of list. In Z, types are sets. Although it is possible to model the
ASN.l type constructors as sequences in Z, it is sometimes more natural to consider the operations available on the
ASN. 1 types and to map them to Z types which more clearly describe their structure. The ASN.l sequence and set types
can be mapped to Z tuples. The ASN. 1 sequence-of type can be mapped to a Z sequence. The ASN. 1 set-of type can be
mapped to a Z set.
as type labels and default values. This does not need to be represented
ASN. 1 incl udes special support for encoding, such
in Z s lince i t doesn’t affect the behaviour defin ition.
Subclause B.6.2 provides additional information on how to convert ASN.l types.
B.3.3 MO Attributes
Managed objects are defined to have certain management attributes. These attributes have a datatype defined in ASN.1.
They are assigned object identifiers. They also may have a matches-for property. Two ways to model such attributes have
been proposed:
0
simple attribute types; and
0
attribute types as schemas.
The simplest is to represent the MO attribute within the MO as a Z variable with the appropriate datatype. Then
separately we will need a constant definition which represents the object identifier of that attribute. This constant will be
related to the actual attribute by convention only. We can use the actual fixed matches-for property when matching
operations are defined for that attribute. An example of this is given in B.6.3.
It is also possible to encapsulate all these properties of an attribute in a single schema type which will then be the type of
the Z variable modelling the MO attribute. Thus, the schema will include the value of the attribute as well as the object
identifier and the matches-for property if any. An example of this is given in B.6.4. Where matching rules other than
equality are required, it is possible to define the matches-for parameter as a Z relation over the type of the value of the
attribute. This allows the formal representation of arbitrary ad-hoc matching rules, which may be important for scoping,
filtering and object selection.
It is difficult to model ASN.1 type ANY in Z. One case where this is common is to give lists of attribute values. Thus, a
fully formal model will probably require a Z free type combining the attribute types already defined. An example of this
can be found in B.6.1 and B.6.5.
Object identifiers are formally modelled by a given set.
[ OB JECTID]
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 3
---------------------- Page: 7 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.3.4 Other Object Identifiers
Many things besides attributes also have an Object Identifier. It is convenient to introduce them all as constants in
axiomatic definitions. The convention of suffixing them with “Oid” will be used. Typically such constants will be needed
for classes, packages and notifications.
An example is:
packagesPackageOid : OBJECTID
allomorphsPackageOid : OBJECTID
topClassOid : OBJECTID
B.3.5 Inheritance and Compatibility
Z can be used to build inheritance hierarchies of MOs by using schema inclusion to model inheritance and specialization.
This does correctly model the behaviour of an MO class and its sub-types but it fails to make explicit the strong sub-
typing relationship that is really present. For that, a language that models inheritance explicitly is needed.
Thus Z can be used to define individual MOs satisfactorily, but to be able to talk about inheritance and compatibility, the
additional power of a language that models inheritance explicitly is needed.
Inheritance is not supported by Z. It can be modelled by simple schema inclusion of state schcmas.
The definition of MO inheritance requires sub-classes to be compatible- Unfortunately this does not require the
sub-classes to be sub-types in Z. Thus, typically an MO can report its actual class. Since t,he actual class attribute always
reports an object’s actual class, a sub-class cannot report the class of a super-class. Therefore, a sub-class cannot exhibi:
the same behaviour as its super-class in returning the value of its actual class attribute (i.e. it is not substitutable), even. iC
it is behaving allomorphically. Therefore managed object class sub-classing is not equivalent to Z sub-types? where a sub-
type would exhibit the same behaviour as its super-type. However, a sub-dass exhibits very Me “‘ear~sarbstm.rugablc”
behaviour.
In this way it can be seen that MO inheritance as defined in this Recommendation I International Standard allows specific
behaviour in a parent which is inconsistent with the behaviour of its children. Since there is a very limited amount of this
non-substitutable behaviour, an MO class can be represented by two class specifications. One captures the behaviour that
any instance and also any extended MO must exhibit, The other is a specialization and captures that behaviour exhibited
only by instances of the compatible class and not by any extensions” It is this latter specification that is instantiated to
give the complete behaviour of an actual MO instance.
B.3.6 Packages
Many parts of the functionality of a class may be present in some individual MOs and not in others. This
Recommendation I International Standard describes this process by grouping functionality into conditional packages.
Then, each MO instantiates appropriate packages” In Z functionality cannot be provided in this conditional way but it is
possible to make the behaviour of the MO depend on which packages are instantiated. This is straightforward because the
MO must contain a management attribute called packages which lists the object identifiers of the packages actually
instantiated. Thus, to model behaviour in a conditional package, the behaviour itself becomes conditional on the presence
of the package identifier in the packages attribute.
B.3.7 The Class
To define an MO class it is necessary to re present its attributes and its operations. Attributes become part of the Z state
sch ema and opera tions become Z operation schemas.
B.3.7.1 Attributes
The attributes of the managed object are declared in a state schema. Each attribute is given a type, which may be of a type
declared in the ASN. 1 part of the GDMO template, or which may use types declared in Z in a fully formal model.
4 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 8 ----------------------
ISO/IEC 101654 : 1992/Amd.3 : 1998 (E)
B.3.7.2 The Get operation
The manager may request a Get operation to be performed on an MO. The CMISE definition of M-Get has many
parameters but most of these are concerned with access control and object selection and so on. In this instance Get may
be modelled at the Managed Object Boundary ignoring these issues and replacing the single Get operation by a number
of Get operations, where is a single attribute.
B.3.7.3 The GetAll operation
A GetAll operation, which has no input, is also modelled. It returns a non-empty set of Attribute Values.
B.3.7.4 Replace operations
Set on an individual MO is requested by the CMISE M-Set operation. This specification models the Replace Operations
as seen at the MO Boundary instead. In this specification, Replace Operations refers to the attribute operations set, set to
default, add and remove.
The consequence of this is that a 2 schema to represent each modification is specified.
B.3.7.5 Notifications
Notifications are unrequested messages sent by the MO to report events within it. However they are not modelled as
operations. Instead they are modelled as outputs from operations that happen on the MO. Thus, any operation (whether
invoked by the manager or internally by the resource) can generate output and if it causes a notification that notification
should be part of that operation’s output.
This means that the output of a 2 operation schema that can cause notifi cations shou Id be a set of notificati ons. Then
those occasions on which it does not emit a notification can be represented by giving an empt .y set as 0 utput.
The data in a notification consists of an EventType which is the object identifier of its standard definition. This is
followed by various information relevant to that particular notification. The object identifier can typically be defined as a
constant and the particular data as a schema-type. The behaviour of the notification is included in any object which can
generate the notification.
B.3.7.6 Actions
Actions are operations performed by the manager on the MO. They are very naturally represented by 2 operations.
B.3.8 Specification of the system of objects
The rest of the annex describes how to represent the behaviour of a single object. When considering object
creation/deletion, name bindings, containment and naming, it is necessary to describe the state of the system where the
objects reside. Object creation and deletion can be represented by a change of state of this system. Name binding and
containment can be represented by a relation over the set of objects. Naming can then be defined in terms of this relation.
B.4 An example
In this subclause, example definitions for the MO class top and State Management attributes are given. Since the main
concern of this guide is the modelling of behaviour, the creation of 2 types from ASN.l types is not presented in this
subclause. A full formal definition is given in B.7.
B.4.1
top
The first class to be defined is top, which is the ultimate parent (in the inheritance hierarchy) of all MOs.
top has four management attributes, objectclass, packages, allomorphs and nameBinding. objectclass holds the object
identifier of the class, while packages holds the object identifiers of the packages it instantiates. nameBinding holds the
object identifier of the name binding used to instantiate the object and allomorphs holds the object identifiers of the
classes to which the object can be allomorphic. Since management attributes can be in packages, the attributes present in
MOs of a given class can vary. This is modelled by including an additional modelling attribute called attributes, which
holds the object identifiers of the attributes that are actually instantiated in the individual MO. Note that all the attributes
present in top are fixed for the lifetime of any individual MO.
possible to formally define which operations are invoked internally
Z does not explicit1 y model in terfaces, and so it is not
or external ly by the manager.
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
5
---------------------- Page: 9 ----------------------
ISO/IEC 101654 : 1992/Amd.3 : 1998 (E)
TopState
allomorphs: FOBJECTID
objectclass: OBJECTID
nameBinding: OBJECTID
packages: FOBJECTID
attributes: F OBJECTID
{objectClassOid, nameBindingOid} cattributes
-
allomorphsPackageOid E packages 3 allomorphsOid Eattributes
packagesPackageOid gpackages
packages # 0 a packagesoid Eattributes
attributes is not an MO attribute but a new state component defined for convenience. It lists the MO attributes an MO
includes. Thus, the invariant enforces that it must contain the object identifiers of the appropriate attributes as described
in B.3.3 (and defined in B.7.4). objectCEass and nameBinding are mandatory. packages is present if any registered
package is instantiated apart from packagespackage. In this case this means allomorphsPackage.
The operation TopGetNameBinding interrogates the MO and returns the value of the nameBinding attribute, without
changing TopState. TopGetNameBinding is invoked by the manager.
TopGetNameBinding
.Z TopSta te
result!: OBJECTID
result! = nameBinding
The operations TopGetAlZomorphs, TopGetObjectClass and TopGetPackages have not been defined here. Note that there
is no operation to get attributes, since attributes is not a real MO attribute as specified in the GDMO template.
TopGetAIE gets all the attribute values of an object. It always returns values for objectClass and nameBinding. If
conditional packages or allomorphs are present, then it gets those too. TopGetAZZ is invoked by the manager.
TopGetAll
ETopState
result!: PA ttributevalues
# attributes = # result!
ObjectClassValue objectClass E result!
NameBindingValue nameBinding E result!
PackagesOid Eattributes 3 packagesvalue packages E result!
AllomorphsOid Eattributes q allomorphsValue allomorphs E result!
TopEventReport is a way to model notifications. TopEventReport occurs spontaneously and represents the way event
reports are not controlled by the manager.
TopEventReport
.F TopSta te
notification !: Even tlnfo
r
6 ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 10 ----------------------
ISO/IEC 101654 : 1992/Amd.3 : 1998 (E)
B.4.2 StateManagement class
This class does not reflect any specific MO class. Instead it reflects the behaviour of any object which includes any of
certain standard attributes: administrativestate, operationalState, and usagestate. It is more convenient within this
framework to understand this inclusion as inheritance and it does serve as a useful example.
The state schema includes the TopState definitions and predicates, and defines some additional variables and predicate
conjunctions.
StateManagementState
TopSta te
administrativestate:
Administrativestate
operationalstate: OperationalState
usageSta te: UsageSta te
operationalstate = disabled q usagestate = idle
administrativestate = locked 3 usagestate = idle
usagestate = idle 3 administrativestate # shuttingDown
State Management inherits the operations from Top. Although there is no mechanism built into Z to inherit operations, it
is straightforward to redefine the operations in terms of the new state. The predicate part of StateManagementState
follows from the definition of the State Management function in CCITT Rec. X.721 (1992) I ISO/IEC 10165-2: 1992 and
CCITT Rec. X.73 1 (1992) I ISOJIEC 10164-2: 1992.
The operation SMGetNameBinding can be easily defined, since it has no effect upon the new state variables declared in
StateManagementState. The definition of TopGetNameBinding can be re-used:
SMGetNameBinding
TopGetNameBinding
.ZSta teManagementSta te
r
Definitions for operations to get the other attributes of StateManagementState have also been omitted from this example.
The operations SMGetAllomorphs, SMGetObjectCZass and SMGetPackages can re-use the definitions from Top as for
SMGetNameBinding. New operations will need to be defined for GetSMAdministrativeState, GetSMOperationalState and
SMGetUsageState. SMEventReport may also be re-used.
The SMGetAZZ schema also makes use of an operation defined on TopState. It includes the definition of TopGetAZZ and
strengthens the postcondition.
SMGetAU
ESta teManagemen tSta te
TopGetAZl
r
administrativestateoid Eattributes
q administrativestatevalue administrativestate ~result!
OperationalStateOid Eattributes
3 0perationalStateValue operationalstate Eresult!
UsageStateOid Eattributes
* usageStateValue usagestate E result!
The SMReplaceAdministrativeState operation describes behaviour specific to the State Management class whereby the
administrative state is replaced by another value supplied as an input. Depending on the state of the object when the
operation is carried out, the usage state may also be changed. The operational state is not altered by the operation.
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E) 7
---------------------- Page: 11 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
SMReplaceAdministrativeState
AStateManagementState
ZopState
input?: Administrativestate
administrativestate’ E
IF usagestate # idle
THEN / unlocked - unlocked,locked ++locked,
shuttingDown &ocked,locked -shuttingDown,
shuttingDown ++ shuttingDown} 4{ input?] 1
ELSE {unlocked I-+ unlocked, locked - locked,
shuttingDown - locked} t ( input?} D
administrativestate’ = locked * usagestate’ = idle
administrativestate’ # locked q usagestate’ = usagestate
operationalstate’ = operationalstate
The behaviour specified in the predicate part of the schema is a formalization of the informal description in
CCITT Rec. X.73 1 I ISO/IEC 10164-2. For completeness, operations to replace the operational state and the usage state
should also be defined.
Finally there are a number of other operations which describe behaviour specific to the State Management class. These
operations are not listed here, although they may be found in B.7. These operations include SMCapacityDecrease,
SMCapacityIncrease, SMDisable, SMEnable, SMNewUser and SMUserQuit.
B.4.3 Instantiable classes
Neither of the classes described above can be instantiated. The procedure that has been followed can be continued.
StateManagement can be re-used to define a class called CIRCUIT, which in turn can be used to define ECIRCWT and
hence the instantiable class ActualECircuit.
This has been omitted from the guide, since the procedures are exactly the same as those that have outlined and repetition
adds nothing.
B.5 Outstanding Issues
In this subclause, the main issues encountered in the course of the translation from GDMO-based managed objects
specifications to Z are listed. Where an issue relates to 2 not having a corresponding construct for a particular feature of
managed objects specification, the proposed informal treatment used in this annex will also be included.
B.51
Behaviour Definition in Managed Objects
In the templates, the term ‘behaviour definition’ is used for almost all entities whether they are data or processes. In the
latter case, it may include information about the actual behaviour (in the strict sense), or just static information about the
entity such as its intended use, or both. When translating, one needs to analyse the text which comes under this heading,
and extract the relevant behavioural information for the entity concerned. This behavioural information will be used in the
formal translation, while the actual text may be included as a comment inside the Z specification.
B.5.2 Internal operations in Z
An internal operation in a managed object represents the case where a notification is emitted spontaneously (with no
management invocation involved). Internal operations are also a desired feature of many other systems. Currently, in Z,
this feature is represented informally by a comment in the natural language text which is an important feature of any well-
written Z specification.
B.5.3
Abstract classes in Z
Sometimes it is useful to identify abstract classes: i.e. classes with no instantiations of their own. Some MO classes (like
top) cannot be instantiated. It would be helpful to be able to show which parts of the corresponding Z specifications
represent classes that can be instantiated. This is taken care of by informal annotation at present.
B.5.4 PARAMETER semantics
The incorporation of PARAMETER semantics into objects is not considered in this Recommendation I International
Standard.
8
ITU-T Rec. X.722 (1992)/Amd.3 (1997 E)
---------------------- Page: 12 ----------------------
ISO/IEC 10165-4 : 1992/Amd.3 : 1998 (E)
B.6 Converting ASN.1 Datatypes to Z
Issues for translation will be described for each ASN. 1 constructor in turn.
B.6.1 Simple types
ASN.1 includes some simple types which are built-in. These do have a standardized structure but it is usually not
interesting in the context of these specifications and so they can mostly be represented as given sets. There are a wide
variety of c
...
NORME ISO/CEI
INTERNATIONALE 10165-4
Première édition
1992-09-01
AMENDEMENT 3
1998-12-15
Technologies de l'information —
Interconnexion de systèmes ouverts —
Structure des informations de gestion:
Directives pour la définition des objets
gérés
AMENDEMENT 3: Directives pour l'utilisation
du langage Z dans la formalisation du
comportement des objets gérés
Information technology — Open Systems Interconnection — Structure of
management information: Guidelines for the definition of managed objects
AMENDMENT 3: Guidelines for the use of Z in formalizing the behaviour of
managed objects
Numéro de référence
ISO/CEI 10165-4:1992/Amd.3:1998(F)
©
ISO/CEI 1998
---------------------- Page: 1 ----------------------
ISO/CEI 10165-4:1992/Amd.3:1998(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 1998
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 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2000
ImpriméenSuisse
ii © ISO/CEI 1998 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/CEI 10165-4:1992/Amd.3:1998(F)
Sommaire
0AGE
1) Table des matières. 1
2) Paragraphe 2.1. 1
3) Nouveau paragraphe 2.3. 1
4) Nouvelle Annexe B . 1
Annexe B – Directives pour l'utilisation du langage Z dans la formalisation du comportement des objets gérés 2
© ISO/CEI 1998 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/CEI 10165-4:1992/Amd.3:1998(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 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’Amendement 3 à l'ISO/CEI 10165-4:1992 a été élaboré par le comité technique mixte ISO/CEI JTC 1,
Technologies de l'information, sous-comité SC 33, Services d'applications distribuées, en collaboration avec
l'UIT-T. Le texte identique est publié en tant que Rec. UIT-T X.722/Amd.3.
iv © ISO/CEI 1998 – Tous droits réservés
---------------------- Page: 4 ----------------------
)3/�#%)����������������!MD�����������&�
./2-%��).4%2.!4)/.!,%
ISO/CEI 10165-4 : 1992/Amd.3 : 1998 (F)
Rec. UIT-T X.722 (1992)/Amd.3 (1997 F)
2%#/--!.$!4)/.��5)4�4
4%#(./,/’)%3��$%��,�).&/2-!4)/.�� ��).4%2#/.%8)/.��$%��3934�-%3
/56%243�� ��3425#452%��$%3��).&/2-!4)/.3��$%��’%34)/.���$)2%#4)6%3
0/52��,!��$�&).)4)/.��$%3��/"*%43��’�2�3
!-%.$%-%.4���
$IRECTIVES�POUR�L�UTILISATION�DU�LANGAGE�:�DANS�LA�FORMALISATION
DU�COMPORTEMENT�DES�OBJETS�G'R'S
�� 4ABLE�DES�MATI¤RES
!JOUTER���LA�TABLE�DES�MATI¤RES�LA�R'F'RENCE�SUIVANTE�
Annexe B – Directives pour l'utilisation du langage Z dans la formalisation du comportement des objets gérés
�� 0ARAGRAPHE����
!JOUTER�LA�R'F'RENCE�SUIVANTE�
– Recommandation X.731 du CCITT (1992) | ISO/CEI 10164-2:1992, 4ECHNOLOGIES�DE�L�INFORMATION�
)NTERCONNEXION�DES�SYST¤MES�OUVERTS� �’ESTION�SYST¤MES��FONCTION�DE�GESTION�D�'TATS.
�� .OUVEAU�PARAGRAPHE����
!JOUTER�UN�NOUVEAU�PARAGRAPHE�COMME�SUIT:
��� !UTRES�2'F'RENCES
1)
– ISO/CEI 13568: , 4ECHNOLOGIES�DE�L�INFORMATION� �,ANGAGE�DE�SP'CIFICATION�:.
1)
Actuellement à l'état de projet.
�� .OUVELLE�!NNEXE�"
!JOUTER�UNE�NOUVELLE�!NNEXE�"�COMME�SUIT�
2EC��5)4�4�8������������!MD���������&� 1
---------------------- Page: 5 ----------------------
)3/�#%)����������������!MD�����������&�
!NNEXE�"
$IRECTIVES�POUR�L�UTILISATION�DU�LANGAGE�:�DANS�LA�FORMALISATION
DU�COMPORTEMENT�DES�OBJETS�G'R'S
(Cette annexe ne fait pas partie intégrante de la présente Recommandation | Norme internationale)
"�� )NTRODUCTION
La présente annexe est un guide technique d'application du langage Z dans la définition du comportement des objets
gérés utilisés pour l'interfonctionnement de la gestion OSI. De nature descriptive, elle n'est pas normative. Elle ne
requiert pas de techniques de définition formelles (FDT, FORMAL�DEFINITION�TECHNIQUES) pour spécifier le comportement
des objets gérés. Si les techniques FDT doivent être employées, il n'est pas nécessaire d'utiliser le langage Z; d'autres
langages, tels que le SDL, conviennent également. Même s'il est indiqué d'utiliser le langage Z, on peut spécifier le
comportement des objets gérés par d'autres moyens.
La spécification formelle du comportement des objets gérés a une utilité évidente car elle est claire et univoque. Comme
elle oblige à examiner de près le détail des comportements, elle peut aussi servir d'outil pour déceler des imprécisions
qui auraient pu passer inaperçues dans une spécification faisant uniquement usage du langage naturel, et pour y
remédier. C'est pourquoi elle permet d'améliorer la spécification des comportements.
La présente annexe contient, à titre indicatif, un exemple montrant la meilleure manière de procéder actuelle. Elle vise à
établir une base et une compréhension communes de cette approche formelle particulière qui contribuera à l'uniformité
dans les réalisations similaires. Elle sera un point de départ utile pour les utilisateurs des directives GDMO qui
souhaitent utiliser le langage Z pour améliorer la spécification des comportements.
Elle est destinée aux utilisateurs qui sont familiarisés avec les concepts de base de la spécification des objets gérés au
moyen des modèles GDMO et du langage Z.
Dans la suite de la présente annexe, les expressions «objet géré» et «MO» seront utilisées pour désigner une définition
de classe d'objets gérés faite au moyen des modèles GDMO.
"�� 1UESTIONS�DE�LANGAGE
Le langage Z est une notation de spécification formelle fondée sur la théorie des ensembles et des calculs fonctionnels.
Sa capacité d'expression est suffisante pour décrire des classes uniques d'objets gérés.
Toutefois, elle ne contient aucune notion d'encapsulage. Une spécification en langage Z est généralement constituée d'un
modèle d'un certain état et d'une suite d'opérations pour modifier cet état. Le langage Z n'incorpore aucune méthode
permettant de réunir l'état et ses opérations dans un module unique pouvant être réutilisé dans une autre spécification. La
conséquence de cela apparaît quand il faut décrire des objets gérés qui ont des variables et un comportement hérités
d'autres définitions de classe d'objets gérés.
Cet effet d'héritage peut être obtenu par la technique de l'inclusion de schémas, au prix d'un peu de clarté. A tout autre
égard, le langage Z convient pour exprimer des classes particulières d'objets gérés.
"�� #E�QU�IL�Y�A�LIEU�DE�TRADUIRE
Les définitions d'un comportement ou de parties de celui-ci doivent être traduites en langage Z à partir de leur
description informelle. La mesure dans laquelle les parties restantes des modèles GDMO doivent être formalisées dépend
dans une large mesure des besoins du spécificateur.
Les modèles GDMO contiennent une définition semi-formelle des types de données en ASN.1. Il est possible d'écrire
une spécification en langage Z en utilisant ces définitions en ASN.1 comme base pour les types utilisés dans la
spécification en langage Z, ce qui permet d'économiser beaucoup de travail.
Toutefois, si une spécification est écrite de cette manière, le spécificateur aura davantage de travail pour s'assurer qu'elle
est syntaxiquement correcte. Sans spécification en langage Z des définitions en ASN.1, on ne peut pas utiliser les outils
en Z existants, qui permettent de contrôler la syntaxe et la sémantique statique d'une spécification en Z.
En résumé, on peut améliorer les définitions de comportement en utilisant le langage Z sans récrire les types de données
ASN.1, mais on peut obtenir un avantage significatif en traduisant entièrement en langage Z les types de données
en ASN.1. Le paragraphe B.7.1 donne des exemples de la manière de convertir en langage Z les types de base écrits
en ASN.1.
2 2EC��5)4�4�8������������!MD���������&�
---------------------- Page: 6 ----------------------
)3/�#%)����������������!MD�����������&�
"���� $ES�MOD¤LES�’$-/�AU�LANGAGE�:
Le présent paragraphe contient les directives générales sur la manière de traduire un objet géré en langage Z à partir de
sa description informelle, telle qu'elle est donnée dans la présente Recommandation | Norme internationale. Il convient
de souligner d'emblée qu'une telle traduction ne peut être faite qu'informellement étant donné qu'une traduction formelle
nécessiterait, pour le moins, que les langages source et cible soient tous deux formels.
De plus, comme c'est invariablement le cas lorsque l'on met en correspondance deux langages distincts, il y a
inévitablement une certaine discordance entre leurs structures. Le problème s'aggrave lorsque l'un des langages est
informel ou qu'il comporte des composantes informelles.
Le présent paragraphe contient la liste de quelques-unes des principales caractéristiques des modèles définis dans la
présente Recommandation | Norme internationale, avec les points sur lesquels ils diffèrent des structures en langage Z ou
y correspondent. Elles sont accompagnées de méthodes générales pour résoudre les discordances ou de conseils sur la
manière de les traiter individuellement suivant les circonstances.
La présente annexe est orientée sur ce qui est nécessaire pour décrire le comportement d'un objet géré. Des informations
supplémentaires sur la manière de convertir des types ASN.1 sont données au paragraphe B.6.
"���� 4YPES�DE�DONN'ES
La première étape consiste à récrire sous la forme de types en langage Z les types de données de la présente
Recommandation | Norme internationale. L'ASN.1 fournit les moyens habituels de typage des données mais ses
constructeurs sont orientés vers la description des flux de données communiqués entre les systèmes.
En ASN.1, les constructeurs de types sont définis comme des formes de liste. En Z, les types sont des ensembles. Bien
qu'il soit possible de modéliser les constructeurs de types ASN.1 comme des séquences Z, il est parfois plus simple
d'envisager les opérations disponibles sur les types ASN.1 et de les mettre en correspondance avec les types Z qui
décrivent plus clairement leur structure. Les types séquence ASN.1 et les types ensemble peuvent être représentés par
des nuplets Z. Le type séquence-de ASN.1 peut être représenté par une séquence Z. Le type ensemble-de ASN.1 peut
être représenté par un ensemble Z.
L'ASN.1 inclut une prise en charge particulière du codage, comme les étiquettes de types et les valeurs par défaut. Elles
n'ont pas à être représentées en Z, n'ayant pas d'incidence sur la définition du comportement.
Le paragraphe B.6.2 offre des informations supplémentaires sur la conversion des types ASN.1.
"���� !TTRIBUTS�D�OBJETS�G'R'S
Par définition, les objets gérés ont certains attributs de gestion; ceux-ci ont un type de données défini en ASN.1 et des
identificateurs d'objet leur sont attribués. Ils peuvent en outre avoir une propriété de correspondance. Deux manières de
modéliser de tels attributs ont été proposées:
• les types d'attribut simples;
• les types d'attribut ayant la forme de schémas.
La solution la plus simple consiste à représenter l'attribut d'objet géré dans l'objet géré sous forme de variable Z avec le
type de données approprié. Parallèlement, il faut définir une constante qui représente l'identificateur d'objet de cet
attribut. Cette constante sera liée à l'attribut en question par convention seulement. On peut recourir à la propriété de
correspondance en question si des opérations de mise en correspondance pour cet attribut ont été définies. Un exemple
en est donné au B.6.3.
On peut aussi encapsuler toutes les propriétés de l'attribut dans un type de schéma unique qui sera alors le type de la
variable Z modélisant l'attribut d'objet géré. Le schéma inclura alors la valeur de l'attribut aussi bien que l'identificateur
d'objet et la propriété de correspondance éventuelle. Un exemple en est donné au B.6.4. Là où d'autres règles de
correspondance que l'égalité sont requises, on peut définir le paramètre de correspondance (MATCHES�FOR) comme une
relation Z sur le type de la valeur de l'attribut. Cela permet la représentation formelle de règles de correspondance
particulières arbitraires, qui peut être importante dans la validité, le filtrage et la sélection d'objets.
Il est difficile de modéliser en langage Z le type ANY de l'ASN.1. Un cas où le problème est fréquent est celui dans
lequel il faut donner une liste de valeurs d'attribut. En conséquence, un modèle entièrement formel nécessitera sans doute
un type exempt de langage Z réunissant les types d'attribut qui sont déjà définis. On en trouvera un exemple au B.6.1 et
au B.6.5.
Les identificateurs d'objet sont formellement modélisés par un ensemble donné.
[OBJECTID]
2EC��5)4�4�8������������!MD���������&� 3
---------------------- Page: 7 ----------------------
)3/�#%)����������������!MD�����������&�
"���� !UTRES�IDENTIFICATEURS�D�OBJET
Beaucoup d'éléments autres que les attributs ont également un identificateur d'objet. Il est utile de les introduire tous
sous la forme de constantes dans des définitions axiomatiques. On leur attribuera par convention le suffixe «Oid».
Généralement, de telles constantes seront nécessaires pour les classes, pour les lots de propriétés (paquetages) et pour les
notifications.
Exemple:
PACKAGES0ACKAGE/ID���/"*%#4)$
ALLOMORPHS0ACKAGE/ID���/"*%#4)$
TOP#LASS/ID���/"*%#4)$
"���� ('RITAGE�ET�COMPATIBILIT'
On peut utiliser le langage Z pour construire des hiérarchies d'héritage d'objets gérés en introduisant des schémas pour
modéliser l'héritage et la spécialisation. Cela modélise correctement le comportement d'une classe d'objets gérés et de ses
sous-types mais ne rend pas explicite la forte relation de sous-typage qui est effectivement présente. A cet effet, il faut
un langage qui modélise l'héritage de manière explicite.
La langage Z peut donc être utilisé pour définir de manière satisfaisante les objets gérés individuels; mais, pour être en
mesure de traiter de l'héritage et de la compatibilité, il faut disposer de la puissance additionnelle d'un langage pouvant
modéliser l'héritage de manière explicite.
L'héritage n'est pas pris en compte dans le langage Z. Il peut être modélisé simplement par l'introduction de schémas
d'état.
La définition de l'héritage d'objets gérés nécessite que les sous-classes soient compatibles; mais, en langage Z, il n'est pas
indispensable que les sous-classes soient des sous-types, ce qui est regrettable. Donc, généralement, un objet géré peut
annoncer sa classe réelle. Etant donné que l'attribut de classe réelle signale toujours la classe réelle de l'objet, une
sous-classe ne peut signaler la classe d'une superclasse. Pour cette raison, une sous-classe ne peut pas afficher le même
comportement que sa superclasse par le renvoi de la valeur de son attribut de classe réelle (c'est-à-dire qu'elle n'est pas
substituable), même si son comportement est allomorphique. Pour cette raison, la sous-répartition des classes d'objets
gérés n'est pas équivalente aux sous-types du langage Z, dans lequel un sous-type afficherait le même comportement que
son supertype. Néanmoins, une sous-classe affiche très peu de comportements «non substituables».
On constate ainsi que l'héritage d'objets gérés, tel qu'il est défini dans la présente Recommandation | Norme
internationale, permet à un parent d'avoir un comportement spécifique qui ne concorde pas avec le comportement de ses
descendants. Etant donné qu'un tel comportement non substituable est très rare, on peut représenter une classe d'objets
gérés par deux spécifications de classe. L'une est le comportement que toute instance ou objet géré étendu doit afficher;
l'autre est une spécialisation qui capture le comportement affiché uniquement par des instances de la classe compatible et
non par une quelconque extension. C'est cette dernière spécification qui est instanciée pour donner le comportement
complet d'une instance d'objet géré réelle.
"���� ,OTS��DE�PROPRI'T'S�
De nombreuses parties de la fonctionnalité d'une classe peuvent être présentes dans certains objets gérés individuels et
non dans d'autres. La présente Recommandation | Norme internationale décrit ce processus en groupant les
fonctionnalités dans des lots conditionnels. Ensuite, chaque objet géré instancie les lots appropriés. En langage Z, on ne
peut pas donner la fonctionnalité de cette manière conditionnelle, mais on peut faire en sorte que le comportement de
l'objet géré dépende de la nature des lots instanciés. Cela est logique vu qu'un objet géré doit contenir un lot appelé par
un attribut de gestion qui énumère les identificateurs d'objet des lots effectivement instanciés. Donc, en modélisant le
comportement dans un lot conditionnel, ce comportement lui-même devient conditionnel par la présence de
l'identificateur de lot dans l'attribut de lots.
"���� #LASSE
Pour définir une classe d'objets gérés, il faut représenter ses attributs et ses opérations. Les attributions deviennent des
parties du schéma d'état Z et les opérations deviennent des schémas d'opération Z.
4 2EC��5)4�4�8������������!MD���������&�
---------------------- Page: 8 ----------------------
)3/�#%)����������������!MD�����������&�
"������ !TTRIBUTS
Les attributs d'un objet géré sont déclarés dans un schéma d'état. On donne à chaque attribut un type, qui peut être un
type déclaré dans la partie ASN.1 du modèle GDMO ou un type déclaré en langage Z dans un modèle entièrement
formel.
"������ ,�OP'RATION�’ET��OBTENIR�
Le gestionnaire peut demander qu'une opération Get soit effectuée sur un objet géré. La définition des éléments CMISE
d'une opération M-Get a de nombreux paramètres dont la plupart concernent toutefois la commande d'accès, la sélection
d'objet et ainsi de suite. Dans ce cas, l'opération Get pourra être modélisée à la limite de l'objet géré, sans tenir compte de
ces questions et en remplaçant l'opération Get unique par une série d'opérations Get, où est un attribut
unique.
"������ ,�OP'RATION�’ET!LL
L'opération GetAll, qui est dépourvue d'entrée, est également modélisée. Elle renvoie un ensemble non vide de valeurs
d'attribut.
"������ ,ES�OP'RATIONS�2EPLACE��REMPLACER�
L'opération CMISE M-Set demande une opération Set sur un objet géré individuel. Cette spécification modélise les
opérations Replace telles qu'elles sont vues à la limite de l'objet géré. Dans cette spécification, les opérations Replace se
réfèrent aux attributs «operations set», «set to default», «add» et «remove».
La conséquence de ce qui précède est la spécification d'un schéma Z pour représenter chaque modification.
"������ .OTIFICATIONS
Les notifications sont des messages non sollicités qui sont envoyés par un objet géré pour rendre compte d'événements
internes. Elles ne sont toutefois pas modélisées comme des opérations mais comme des résultats d'opérations sur l'objet
géré. Donc, toute opération (qu'elle soit invoquée par le gestionnaire ou, de manière interne, par la ressource) peut
produire un résultat. Si celui-ci entraîne une notification, celle-ci doit faire partie du résultat de l'opération.
Cela signifie que le résultat d'un schéma d'opération Z pouvant entraîner des notifications doit être un ENSEMBLE de
notifications. Dès lors, on peut représenter les cas dans lesquels il n'émet pas de notification en donnant pour résultat un
ensemble vide.
Les données contenues dans une notification sont constituées d'un type EventType qui est l'identificateur d'objet de sa
définition standard. Celui-ci est suivi de diverses informations s'appliquant à cette notification particulière.
L'identificateur d'objet peut généralement être défini comme une constante et les données particulières comme un type de
schéma. Le comportement de la notification est inclus dans tout objet qui a la capacité de produire la notification.
"������ !CTIONS
Les actions sont des opérations effectuées par le gestionnaire sur l'objet géré. En langage Z, elles sont représentées tout
naturellement par des opérations.
"���� 3P'CIFICATION�DU�SYST¤ME�D�OBJETS
Le reste de la présente annexe décrit la manière de représenter le comportement d'un objet unique. Lorsqu'on aborde la
création ou la suppression d'objets, les corrélations de leur nom, leur inclusion et leur dénomination, il faut décrire l'état
du système où réside l'objet. On peut représenter la création ou la suppression d'un objet par un changement d'état de ce
système. On peut représenter la corrélation des noms et l'inclusion par une relation avec l'ensemble d'objets. La
dénomination peut alors être définie à partir de cette relation.
"�� %XEMPLE
Dans le présent paragraphe, on trouvera des exemples de définitions des attributs «top» et «State Management» d'une
classe d'objets gérés. Etant donné que le principal objectif du présent guide est de modéliser le comportement, la création
de types Z à partir de types ASN.1 n'est pas présentée dans le présent paragraphe. Une définition formelle complète est
donnée au B.7.
2EC��5)4�4�8������������!MD���������&� 5
---------------------- Page: 9 ----------------------
)3/�#%)����������������!MD�����������&�
"���� TOP��SOMMET�
La première classe qu'il y a lieu de définir est TOP, qui est l'ascendant ultime (le sommet de la hiérarchie d'héritage) de
tous les objets gérés.
La classe TOP a quatre attributs de gestion, à savoir OBJECT#LASS��PACKAGES��ALLOMORPHS�et�NAME"INDING. L'attribut
OBJECT#LASS contient l'identificateur d'objet de la classe, l'attribut PACKAGES contient les identificateurs d'objet des blocs
qu'il instancie, l'attribut NAME"INDING contient l'identificateur d'objet de la correspondance de noms utilisée pour
instancier l'objet et l'attribut ALLOMORPHS contient les identificateurs d'objet des classes pour lesquelles l'objet peut être
allomorphique. Etant donné que les attributs de gestion peuvent former des blocs, les attributs présents dans les objets
gérés d'une classe donnée peuvent varier. Cela est modélisé par l'inclusion d'un attribut de modélisation additionnel
appelé ATTRIBUTES, qui contient des identificateurs d'objet des attributs qui sont réellement instanciés dans l'objet géré
individuel. On notera que tous les attributs présents dans la classe TOP sont fixes pendant la durée de vie de tout objet
géré individuel.
Le langage Z ne modélise pas explicitement les interfaces et pour cette raison il n'est pas possible de définir
formellement celles des opérations qui sont invoquées de manière interne et celles qui le sont de manière externe, par le
gestionnaire.
4OP3TATE
ALLOMORPHS���¤�/"*%#4)$
OBJECT#LASS��/"*%#4)$
NAME"INDING��/"*%#4)$
PACKAGES��¤�/"*%#4)$
ATTRIBUTES��¤��/"*%#4)$
[OBJECT#LASS/ID��NAME"INDING/ID]���ATTRIBUTES
ALLOMORPHS0ACKAGE/ID�¶��PACKAGES�˘��ALLOMORPHS/ID�¶�ATTRIBUTES
PACKAGES0ACKAGE/ID�•�PACKAGES
PACKAGES�¡�fi�˘�PACKAGES/ID�¶�ATTRIBUTES
L'élément ATTRIBUTES n'est pas un attribut d'objet géré mais une nouvelle composante d'état, définie pour des raisons de
commodité, qui énumère les attributs d'objet géré contenus dans cet objet géré. Donc l'invariant l'oblige à contenir les
identificateurs d'objet des attributs appropriés décrits au B.3.3 (et définis au B.7.4). Les attributs OBJECT#LASs et
NAME"INDING�sont obligatoires; l'attribut PACKAGES est présent si un lot enregistré donné est instancié séparément de
PACKAGES0ACKAGE. Dans ce cas, cela signifie ALLOMORPHS0ACKAGE.
L'opération 4OP’ET.AME"INDING interroge l'objet géré et retourne la valeur de l'attribut NAME"INDING sans changer l'état
4OP3TATE. L'opération 4OP’ET.AME"INDING est invoquée par le gestionnaire.
4OP’ET.AME"INDING
X�4OP3TATE
RESULT���/"*%#4)$
RESULT����NAME"INDING
Les opérations 4OP’ET!LLOMORPHS, 4OP’ET/BJECT#LASS et 4OP’ET0ACKAGES n'ont pas été définies ici. On notera qu'il n'y
a pas d'opération pour obtenir ATTRIBUTES étant donné que ce n'est pas un attribut réel d'objet géré tel que spécifié dans le
modèle GDMO.
L'opération 4OP’ET!LL obtient toutes les valeurs d'attribut d'un objet. Elle retourne toujours des valeurs pour OBJECT#LASS
et NAME"INDING. En cas de présence de lots conditionnels ou d'allomorphismes, il les obtient aussi. L'opération
4OP’ET!LL est invoquée par le gestionnaire.
6 2EC��5)4�4�8������������!MD���������&�
---------------------- Page: 10 ----------------------
)3/�#%)����������������!MD�����������&�
4OP’ET!LL
X�4OP3TATE
RESULT���§!TTRIBUTE6ALUES
��ATTRIBUTES������RESULT�
/BJECT#LASS6ALUE�OBJECT#LASS�¶��RESULT�
.AME"INDING6ALUE�NAME"INDING�¶��RESULT�
0ACKAGES/ID�¶�ATTRIBUTES�˘��PACKAGES6ALUE�PACKAGES�¶��RESULT�
!LLOMORPHS/ID�¶�ATTRIBUTES�˘�ALLOMORPHS6ALUE�ALLOMORPHS�¶��RESULT�
L'opération 4OP%VENT2EPORT est une façon de modéliser les notifications qui survient spontanément et représente la
manière dont les rapports d'événement ne sont pas sous le contrôle du gestionnaire.
4OP%VENT2EPORT
X�4OP3TATE
NOTIFICATION���%VENT)NFO
"���� 3TATE-ANAGEMENT�#LASS
Cette classe ne reflète aucune classe d'objets gérés spécifique mais le comportement de tout objet qui inclut un certain
attribut standard tel que ADMINISTRATIVE3TATE, OPERATIONAL3TATE�ou USAGE3TATE. Il est plus pratique, dans ce contexte, de
considérer cette inclusion comme un héritage; elle n'est pas un exemple utile.
Le schéma d'état inclut les définitions 4OP3TATE et les prédicats. Il définit quelques variables et conjonctions de prédicats
additionnelles.
3TATE-ANAGEMENT3TATE
4OP3TATE
ADMINISTRATIVE3TATE�
!DMINISTRATIVE3TATE
OPERATIONAL3TATE��/PERATIONAL3TATE
USAGE3TATE��5SAGE3TATE
OPERATIONAL3TATE���DISABLED��˘����USAGE3TATE���IDLE
ADMINISTRATIVE3TATE���LOCKED��˘����USAGE3TATE���IDLE
USAGE3TATE���IDLE�˘����ADMINISTRATIVE3TATE�¡��SHUTTING$OWN
La gestion d'état hérite des opérations depuis le sommet 4OP. Bien que le langage Z n'ait pas de mécanisme pour les
opérations d'héritage, il est très simple de redéfinir les opérations en termes de nouvel état. La partie prédicat de l'état
3TATE-ANAGEMENT3TATE découle de la définition de la fonction de gestion d'état donnée dans les Rec. X.721 du CCITT
(1992) | ISO/CEI 10165-2:1992 et X.731 du CCITT (1992) | ISO/CEI 10164-2:1992.
On peut aisément définir l'opération 3-’ET.AME"INDING étant donné qu'elle n'a pas d'effet sur les nouvelles variables
d'état déclarées dans l'état 3TATE-ANAGEMENT3TATE. On peut réutiliser la définition de l'opération 4OP’ET.AME"INDING:
3-’ET.AME"INDING
4OP’ET.AME"INDING
X�3TATE-ANAGEMENT3TATE
2EC��5)4�4�8������������!MD���������&� 7
---------------------- Page: 11 ----------------------
)3/�#%)����������������!MD�����������&�
Les définitions des opérations visant à obtenir d'autres attributs de l'état 3TATE-ANAGEMENT3TATE�ont également été omises
dans cet exemple. Les opérations 3-’ET!LLOMORPHS, 3-’ET/BJECT#LASS et 3-’ET0ACKAGES peuvent réutiliser les
définitions du sommet 4OP, comme pour l'opération 3-’ET.AME"INDING. Il sera nécessaire de définir de nouvelles
opérations relatives aux états ’ET3-!DMINISTRATIVE3TATE, ’ET3-/PERATIONAL3TATE et 3-’ET5SAGE3TATE. On peut
également réutiliser l'opération 3-%VENT2EPORT.
Le schéma 3-’ET!LL utilise également une opération définie sur la base de 4OP3TATE. Elle inclut la définition de
4OP’ET!LL et renforce la condition postérieure.
3-’ET!LL
X�3TATE-ANAGEMENT3TATE
4OP’ET!LL
ADMINISTRATIVE3TATE/ID�¶�ATTRIBUTES
�������˘�ADMINISTRATIVE3TA
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.