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

Status
Published
Publication Date
19-Dec-1998
Current Stage
6060 - International Standard published
Start Date
20-Dec-1998
Completion Date
20-Dec-1998
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC 10165-4:1992/Amd 3:1998 - 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 Released:12/20/1998
English language
19 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 10165-4:1992/Amd 3:1998 - Guidelines for the use of Z in formalizing the behaviour of managed objects
English language
19 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 10165-4:1992/Amd 3:1998 - 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 Released:2/10/2000
French language
20 pages
sale 15% off
Preview
sale 15% off
Preview

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
---------------------- 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
– ISO/IEC 13568: , Information technology – Z specification language.
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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .........“.............~..............

Subclause 2.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..............................

New subclause 2.3

New Annex B ,............................................................................................................................................................,

- 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
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
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
Add a new subclause as follows:
23 . Additional references
ISOLIEC 13568: l), Information technology - Z specification language.
Presently at the stage of draft.
New Annex B
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:
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.
[ 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)
---------------------- 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
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

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
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.
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
– ISO/CEI 13568: , 4ECHNOLOGIES�DE�L�INFORMATION� �,ANGAGE�DE�SP'CIFICATION�:.
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.