ISO/IEC 15414:2002

Information technology - Open distributed processing - Reference model - Enterprise language

Technologies de l'information — Traitement réparti ouvert — Modèle de référence — Langage d'entreprise

L'ISO/CEI 15414:2002 offre un langage (d'entreprise) composé de concepts, de structures et de règles permettant de développer, de représenter et d'analyser une spécification du système de traitement réparti ouvert (ODP) du point de vue d'une entreprise (comme défini dans la Rec. UIT-T X.903 | ISO/CEI 10746-3); des règles établissant des correspondances entre le langage d'entreprise et les autres langages de point de vue (définis dans la Rec. UIT-T X.903 | ISO/CEI 10746-3) afin d'assurer la cohérence globale d'une spécification.

General Information

• Status: Withdrawn
• Publication Date: 16-Oct-2002
• Withdrawal Date: 16-Oct-2002
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 19-Jun-2006
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15414:2006 - Information technology - Open distributed processing - Reference model - Enterprise language
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15414
First edition
2002-10-15
Information technology — Open distributed
processing — Reference model —
Enterprise language
Technologies de l'information — Traitement distribué ouvert — Modèle de
référence — Langage d'entreprise

Reference number
©
ISO/IEC 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading
this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in
this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the
unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved

CONTENTS
Page
1 Scope . 1
2 Normative references. 1
3 Definitions . 1
3.1 Definitions from ODP standards . 1
3.2 Definitions from ODP standards extended in this specification. 3
4 Abbreviations. 3
5 Conventions . 3
6 Concepts . 3
6.1 System concepts . 4
6.2 Community concepts. 4
6.3 Behaviour concepts . 4
6.4 Policy concepts. 4
6.5 Accountability concepts . 5
7 Structuring rules . 5
7.1 Overall structure of an enterprise specification . 5
7.2 Contents of an enterprise specification. 6
7.3 Community rules . 7
7.4 Enterprise object rules . 8
7.5 Common community types. 9
7.6 Lifecycle of a community. 9
7.7 Objective rules. 10
7.8 Behaviour rules. 10
7.9 Policy rules. 12
7.10 Accountability rules. 14
8 Compliance, completeness and field of application. 15
8.1 Compliance. 15
8.2 Completeness. 15
8.3 Field of application. 15
9 Enterprise language compliance . 16
10 Conformance and reference points . 16
11 Consistency rules. 16
11.1 Viewpoint correspondences. 16
11.2 Enterprise and information specification correspondences . 17
11.3 Enterprise and computational specification correspondences . 18
11.4 Enterprise and engineering specification correspondences . 18
Index . 20

© ISO/IEC 2002 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in
the work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of the joint technical committee is to prepare International Standards. Draft International Standards
adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 15414 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 7, Software and system engineering, in collaboration with ITU-T. The identical text is published as ITU-T
Rec. X.911.
iv © ISO/IEC 2002 – All rights reserved

Introduction
The rapid growth of distributed processing has led to the adoption of the Reference Model of Open Distributed
Processing (RM-ODP). This Reference Model provides a co-ordinating framework for the standardization of open
distributed processing (ODP). It creates an architecture within which support of distribution, interworking, and
portability can be integrated. This architecture provides a framework for the specification of ODP systems.
The Reference Model of Open Distributed Processing is based on precise concepts derived from current distributed

processing developments and, as far as possible, on the use of formal description techniques for specification of the
architecture.
This Recommendation | International Standard refines and extends the definition of how ODP systems are specified from
the enterprise viewpoint, and is intended for the development or use of enterprise specifications of ODP systems.
0.1 RM-ODP
The RM-ODP consists of:
– Part 1: ITU-T Rec. X.901 | ISO/IEC 10746-1: Overview: which contains a motivational overview of
ODP, giving scoping, justification and explanation of key concepts, and an outline of the ODP
architecture. It contains explanatory material on how the RM-ODP is to be interpreted and applied by its
users, who may include standards writers and architects of ODP systems. It also contains a categorization
of required areas of standardization expressed in terms of the reference points for conformance identified
in ITU-T Rec. X.903 | ISO/IEC 10746-3. This part is not normative.
– Part 2: ITU-T Rec. X.902 | ISO/IEC 10746-2: Foundations: which contains the definition of the concepts
and analytical framework for normalized description of (arbitrary) distributed processing systems. It
introduces the principles of conformance to ODP standards and the way in which they are applied. This is
only to a level of detail sufficient to support ITU-T Rec. X.903 | ISO/IEC 10746-3 and to establish
requirements for new specification techniques. This part is normative.
– Part 3: ITU-T Rec. X.903 | ISO/IEC 10746-3: Architecture: which contains the specification of the
required characteristics that qualify distributed processing as open. These are the constraints to which
ODP standards must conform. It uses the descriptive techniques from ITU-T Rec. X.902 |
ISO/IEC 10746-2. This part is normative.
– Part 4: ITU-T Rec. X.904 | ISO/IEC 10746-4: Architectural semantics: which contains a formalization
of the ODP modelling concepts defined in ITU-T Rec. X.902 | ISO/IEC 10746-2 clauses 8 and 9. The
formalization is achieved by interpreting each concept in terms of the constructs of one or more of the
different standardized formal description techniques. This part is normative.
– ITU-T Rec. X.911 | ISO/IEC 15414: Enterprise language: this Recommendation | International Standard.
0.2 This Recommendation | International Standard
Part 3 of the Reference Model, ITU-T Rec. X.903 | ISO/IEC 10746-3, defines a framework for the specification of ODP
systems comprising:
1) five viewpoints, called enterprise, information, computational, engineering and technology, which provide
a basis for the specification of ODP systems;
2) a viewpoint language for each viewpoint, defining concepts and rules for specifying ODP systems from
the corresponding viewpoint.
The purpose of this Recommendation | International Standard is to:
– Refine and extend the enterprise language defined in ITU-T Rec. X.903 |ISO/IEC 10746-3 to enable full
enterprise viewpoint specification of an ODP system;
– Explain the correspondences of an enterprise viewpoint specification of an ODP system to other
viewpoint specifications of that system; and
– Ensure that the enterprise language when used together with the other viewpoint languages is suitable for
the specification of a concrete application architecture to fill a specific business need.
This Recommendation | International Standard uses concepts taken from ITU-T Recommendations X.902 and X.903 |
ISO/IEC 10746-2 and 10746-3 and structuring rules taken from clause 5 of ITU-T Rec. X.903 | ISO/IEC 10746-3; it
introduces refinements of those concepts, additional viewpoint-specific concepts, and prescriptive structuring rules for
enterprise viewpoint specifications. The additional viewpoint-specific concepts are defined using concepts from ITU-T
Recommendations X.902 and X.903 | ISO/IEC 10746-2 and 10746-3.
© ISO/IEC 2002 – All rights reserved v

0.3 Overview and motivation
The purpose of this Recommendation | International Standard is to provide a common language (a set of terms and
structuring rules) to be used in the preparation of an enterprise specification capturing the purpose, scope and policies for

an ODP system. Such an enterprise specification forms part of the specification of an ODP system in terms of the set of

viewpoints defined by ITU-T Rec. X.903 | ISO/IEC 10746-3. The primary audience for this Recommendation |
International Standard consists of those who prepare and use such specifications.
An enterprise specification is part of an ODP system specification. It can describe any or all of:
• an existing system;
• an anticipated future structure or behaviour of that existing system;
• a system to be created within some environment.
The motivation for a standard enterprise language is to support standardized techniques for specification in order to
improve communication and help create specifications that are consistent overall. The enterprise language provides the
terms and structuring rules to specify the purpose, scope and policies for an ODP system in a manner that is meaningful
for the stakeholders for that system, including the owners, the users, the developers and the maintainers.
An enterprise specification describes the structure and behaviour of the system within its environment. It explicitly
includes those aspects of the environment that influence the behaviour of the ODP system – environmental constraints
are captured as well as usage and management rules. Policies about potential changes in the system that may rule its
future evolution may also be included. Such an environment can be a technical environment (e.g. the software and
hardware environment of a service component) or a social or business organization (e.g. a group of co-operating
companies, a particular service inside a company).
When preparing a specification, there are many approaches that are used for understanding, reaching agreement about,
and specifying systems in the context of the organizations of which they form a part. Many of these approaches fall into
the categories often referred to as analysis or requirements specification. They can provide useful insights into both the
organization under consideration and the requirements for systems to support it, but they often lack the rigour,
consistency and completeness needed for thorough specification. It is a key objective of this Recommendation |
International Standard to provide a way of relating the commonly used concepts and underlying principles of such
approaches to the modelling framework of the RM-ODP.
An important objective of an enterprise specification is to support an agreement (for example, as part of the contract for
the supply of a system) between the potential owners and users of an ODP system and the provider of that system. Both
parties should be able to write, read and discuss such a specification, the owners and users to be sure of the expected
structure and behaviour of the system that they will get, and the provider to be clear about the structure and behaviour of
the system being provided.
Enterprise specifications can also be used at other phases of the system life-cycle. The specification can, for example, be
used at system run-time to control agreements between the system and its users, to establish new agreements according
to the same contract structure and to establish federations.
Finally, in the context of the current trend to integrate existing systems into global networks, where the functionality of
interest spans multiple organizations, the enterprise language provides means to specify the joint agreement regarding the
structure and behaviour of the ODP systems within and between these organizations.
The concepts and structuring rules this Recommendation | International Standard provides may be used for development
of software engineering methodologies and tools exploiting ODP viewpoint languages, and for development of textual or
graphical notations for the ODP enterprise language itself. For these purposes, this Recommendation | International
Standard provides rules for the information content of an enterprise specification and the grouping of that information.
Further requirements on the relationships between enterprise language concepts and their correspondences to concepts in
other viewpoints are specific to the methodologies, tools or notations to be developed.

vi © ISO/IEC 2002 – All rights reserved

INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Open distributed processing –
Reference model – Enterprise language
1 Scope
This Recommendation | International Standard provides:
a) a language (the enterprise language) comprising concepts, structures, and rules for developing,
representing, and reasoning about a specification of an ODP system from the enterprise viewpoint (as
defined in ITU-T Rec. X.903 | ISO/IEC 10746-3);
b) rules which establish correspondences between the enterprise language and the other viewpoint languages
(defined in ITU-T Rec. X.903 | ISO/IEC 10746-3) to ensure the overall consistency of a specification.
The language is specified to a level of detail sufficient to enable the determination of the compliance of any modelling
language to this Recommendation | International Standard and to establish requirements for new specification
techniques.
This Recommendation | International Standard is a refinement and extension of ITU-T Rec. X.903 | ISO/IEC 10746-3,
clauses 5 and 10, but does not replace them.
This Recommendation | International Standard is intended for use in preparing enterprise viewpoint specifications of
ODP systems, and in developing notations and tools to support such specifications.
As specified in clause 5 of ITU-T Rec. X.903 | ISO/IEC 10746-3, an enterprise viewpoint specification defines the
purpose, scope and policies of an ODP system. [see also 3-5.0]
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of the
currently valid ITU-T Recommendations.
Identical ITU-T Recommendations | International Standards
– ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information technology – Open
Distributed Processing – Reference Model: Foundations.
– ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information technology – Open
Distributed Processing – Reference Model: Architecture.
– ITU-T Recommendation X.904 (1997) | ISO/IEC 10746-4:1998, Information technology – Open
Distributed Processing – Reference Model: Architectural semantics.
3 Definitions
3.1 Definitions from ODP standards
3.1.1 Modelling concept definitions
This Recommendation | International Standard makes use of the following terms as defined in ITU-T Rec. X.902 |
ISO/IEC 10746-2.
– action;
– behaviour (of an object);
ITU-T Rec. X.911 (10/2001) 1
– composite object;
– composition;
– configuration (of objects);
– conformance;
– conformance point;
– contract;
– domain;
– entity;
– environment contract;
– environment (of an object);
– epoch;
– establishing behaviour;
– instance (of a type);
– instantiation (of an template);
– interface;
– internal action;
– invariant;
– liaison;
– location in time;
– object;
– obligation;
– ODP standards;
– ODP system;
– permission;
– prohibition;
– proposition;
– reference point;
– refinement;
– role;
– state (of an object);
– subtype;
– system;
– template;
– terminating behaviour;
– type (of an );
– viewpoint (on a system).
3.1.2 Viewpoint language definitions
This Recommendation | International Standard makes use of the following terms as defined in ITU-T Rec. X.903 |
ISO/IEC 10746-3.
– binder;
– channel;
– community;
– computational behaviour;
– computational binding object;
– computational object;
2 ITU-T Rec. X.911 (10/2001)
– computational interface;
– computational viewpoint;
– correspondence;
– dynamic schema;
– engineering viewpoint;
– enterprise viewpoint;
– federation;
– information object;
– information viewpoint;
– interceptor;
– invariant schemaError! Bookmark not defined.;
– node;
– protocol object;
– static schema;
– stub;
– technology viewpoint;
– language.
3.2 Definitions from ODP standards extended in this Specification
This Recommendation | International Standard extends the definition of the following term originally defined in ITU-T
Rec. X.902 | ISO/IEC 10746-2. [2-11.2.7]:
– policy.
The extended definition is in clause 6.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply.
ODP Open distributed processing
RM-ODP Reference Model of Open Distributed Processing
(ITU-T Recommendations X.901 to X.904 | ISO/IEC 10746 Parts 1-4)
5 Conventions
This Recommendation | International Standard contains references to Parts 2 and 3 of RM-ODP. For example, [2-9.4] is a
reference to Part 2, (ITU-T Rec. X.902 | ISO/IEC 10746-2), subclause 9.4. These references are for the convenience of
the reader.
This Recommendation | International Standard also contains some text which is a modification of text from Part 3,
ITU-T Rec. X.903 | ISO/IEC 10746-3. Such text is marked by a reference like this: [see also 3-5.0]. The modifications are
authoritative with respect to the enterprise language.
6 Concepts
The concepts of the enterprise language defined in this Recommendation | International Standard comprise:
– the concepts identified in 3.1.1 and 3.1.2 as they are defined in ITU-T Rec. X.902 | ISO/IEC 10746-2 and
in ITU-T X.903 | ISO/IEC 10746-3;
– the concepts defined in this clause.
This clause defines new concepts and refines the definition of policy from ITU-T Rec. X.902 | ISO/IEC 10746-2.
[2-11.2.7] The grouping into subclauses and the headings of the subclauses of this clause are not normative.
ITU-T Rec. X.911 (10/2001) 3
6.1 System concepts
6.1.1 scope (of a system): The behaviour that system is expected to exhibit.
6.1.2 field of application (of a specification): The properties the environment of the ODP system must have for the
specification of that system to be used.
6.2 Community concepts
6.2.1 objective (of an ): Practical advantage or intended effect, expressed as preferences about future states.
NOTE 1 – Some objectives are ongoing, some are achieved once met.
NOTE 2 – In the text of ITU-T Rec. X.903 | ISO/IEC 10746-3 [3-5] the terms, purpose and objective, are synonymous. The
enterprise language systematically uses the term, objective, and emphasizes the need of expressing objective in measurable terms.
6.2.2 community object: A composite enterprise object that represents a community. Components of a community
object are objects of the community represented.
6.3 Behaviour concepts
6.3.1 actor (with respect to an action): An enterprise object that participates in the action.
NOTE – It may be of interest to specify which actor initiate that action.
6.3.2 artefact (with respect to an action): An enterprise object that is referenced in the action.
NOTE – An enterprise object that is an artefact in one action can be an actor in another action.
6.3.3 resource: An enterprise object which is essential to some behaviour and which requires allocation or may
become unavailable.
NOTE 1 – Allocation of a resource may constrain other behaviours for which that resource is essential.
NOTE 2 – A consumable resource may become unavailable after some amount of use or after some amount of time (in case a
duration or expiry has been specified for the resource).
6.3.4 interface role: A role of a community identifying behaviour which takes place with the participation of objects
that are not a members of that community.
6.3.5 process: A collection of steps taking place in a prescribed manner and leading to an objective.
NOTE 1 – A process may have multiple starting points and multiple end points.
NOTE 2 – The prescribed manner may be a partially ordered sequence.
NOTE 3 – A process specification can be a workflow specification.
NOTE 4 – The activity structure concepts provided in 13.1 of ITU-T Rec. X.902 | ISO/IEC 10746-2 may be used, after
substitution of 'step' for 'action' and 'process' for 'activity', to specify the structure of a process.
NOTE 5 – An enterprise specification may define types of processes and may define process templates.
6.3.6 step: An abstraction of an action, used in a process, that may leave unspecified objects that participate in that
action.
6.4 Policy concepts
6.4.1 policy: A set of rules related to a particular purpose. A rule can be expressed as an obligation, an authorisation,
a permission or a prohibition.
NOTE 1 – Not every policy is a constraint. Some policies represent an empowerment.
NOTE 2 – This definition refines 2-11.2.7 by adding authorization.
6.4.2 authorization: A prescription that a particular behaviour must not be prevented.
NOTE – Unlike a permission, an authorization is an empowerment.
6.4.3 violation: An action contrary to a rule.
NOTE – A rule or policy may provide behaviour to occur upon violation of that or some other rule or policy.
4 ITU-T Rec. X.911 (10/2001)
6.5 Accountability concepts
6.5.1 party: An enterprise object modelling a natural person or any other entity considered to have some of the
rights, powers and duties of a natural person.
NOTE 1 – Examples of parties include enterprise objects representing natural persons, legal entities, governments and their parts,
and other associations or groups of natural persons.
NOTE 2 – Parties are responsible for their actions and the actions of their agents.
The following concepts are used to identify actions which involve the accountability of a party.
6.5.2 commitment: An action resulting in an obligation by one or more of the participants in the act to comply with
a rule or perform a contract.
NOTE – The enterprise object(s) participating in an action of commitment may be parties or agents acting on behalf of a party or
parties. In the case of an action of commitment by an agent, the principal becomes obligated.
6.5.3 declaration: An action that establishes a state of affairs in the environment of the object making the
declaration.
NOTE – The essence of a declaration is that, by virtue of the act of declaration itself and the authority of the object or its principal,
it causes a state of affairs to come into existence outside the object making the declaration.
6.5.4 delegation: The action that assigns authority, responsibility or a function to another object.
NOTE – A delegation, once made, may later be withdrawn.
6.5.5 evaluation: An action that assesses the value of something.
NOTE 1 – For example, the act by which an ODP system assigns a relative status to some thing, according to estimation by the
system.
NOTE 2 – Value can be considered in terms of usefulness, importance, preference, acceptability etc; the evaluated target may be,
for example, a credit rating, a system state, a potential behaviour, etc.
6.5.6 prescription: An action that establishes a rule.
6.5.7 agent: An enterprise object that has been delegated (authority, responsibility, a function, etc.) by and acts for
another enterprise object (in exercising the authority, carrying out the responsibility, performing the function, etc.).
NOTE 1 – An agent may be a party or may be the ODP system or one of its components. Another system in the environment of
the ODP system may also be an agent.
NOTE 2 – The delegation may have been direct, by a party, or indirect, by an agent of the party having authorization from the
party to so delegate.
6.5.8 principal: A party that has delegated (authority, a function, etc.) to another.
6.5.9 contracting party (with respect to a contract): A party that agrees to that contract.
7 Structuring rules
This clause refines and extends the structuring rules defined in subclause 5.2 of ITU-T Rec. X.903 | ISO/IEC 10746-3, as
they apply to the concepts of community, enterprise object, objective, behaviour and policy. It defines structuring rules
for the accountability concepts defined in 6.5. It uses the concepts defined in ITU-T Rec. X.902 | ISO/IEC 10746-2, in
subclause 5.1 of ITU-T Rec. X.903 | ISO/IEC 10746-3 and in clause 6.
7.1 Overall structure of an enterprise specification
An enterprise specification of an ODP system is a description of that system and relevant parts of its environment. The
enterprise specification focuses on the scope and purpose of that system and the policies that apply to it in the context of
its environment.
NOTE 1 – The environment of an ODP system and the ODP system itself may span multiple organizations.
A fundamental structuring concept for enterprise specifications is that of community. A community is a configuration of
enterprise objects that describes a collection of entities (e.g. human beings, information processing systems, resources of
various kinds and collections of these) that is formed to meet an objective. These entities are subject to an agreement
governing their collective behaviour. The assignment of actions to the enterprise objects that comprise a community is
defined in terms of roles. (See 7.8.1 and 7.8.2.)
ITU-T Rec. X.911 (10/2001) 5
The ODP system may play a role in more than one community. Thus, the enterprise specification describes, within the
areas of interest of the specification users:
– roles fulfilled by the ODP system and enterprise objects in its environment;
– steps within processes in which the ODP system and enterprise objects in its environment participate;
– policies for the system, including those of environment contracts.
An enterprise specification of an ODP system includes at least the community in which that system may be represented
as a single enterprise object interacting with its environment. Whether the specification actually includes that level of
abstraction is left for the specifier to decide.
NOTE 2 – This minimal enterprise specification describes the objective and scope of the ODP system; this description is necessary
for completeness of the enterprise specification.
Where necessary for clarity or completeness of description of the behaviour of the ODP system, the enterprise
specification can include any other communities of which the ODP system or its components are members, and other
communities of which enterprise objects in the environment of the ODP system are members.
NOTE 3 – The set of communities in an enterprise specification may include, for example, communities at both more abstract and
more detailed levels than the minimal enterprise specification, as well as communities relating to functional decomposition of the
ODP system and to ownership of the ODP system and its parts.
The enterprise specification can also be structured in terms of a number of communities interacting with each other.
NOTE 4 – Such structuring may represent, for example, a federation.
The interaction of communities may be represented in several ways:
– The communities concerned may be viewed as composite objects (c-objects), and a new community
formed of those composite objects. That community may be described explicitly or may be left implicit.
– A new community may be formed of one or more objects of each community, with roles in the new
community specifying interactions of the communities.
– A new community may be formed of one or more objects of each community, by an assignment of roles
in different communities to the same object, and a correspondence of each of those roles to a role in the
new community.
– Interface objects of the communities may interact, forming a new community.
The scope of the system is defined in terms of its intended behaviour; in the enterprise language this is expressed in
terms of roles or processes or both, policies, and the relationships of these.
NOTE 5 – It may be meaningful to discuss the intended, delivered or expected scope of a system in various phases of planning,
development or deployment. When so, the term ''scope'' should be appropriately qualified.
A complete ODP system specification indicates rules for internal consistency in terms of relationships between various
viewpoint specifications and a complete enterprise specification contains conformance rules that define the required
behaviour of the described ODP system
This clause defines how the concepts identified in clause 3 or defined in clause 6 are used in an enterprise specification.
7.2 Contents of an enterprise specification
An enterprise specification is structured in terms of the elements explained in 7.1 (communities, enterprise objects,
contracts, roles, interactions, activities, behaviour, the ODP system and policies) and the other concepts identified in
clause 10, as well as the relationships between them.
For each of these elements, depending on the specifier's choice and desired level of detail, the enterprise specification
provides:
– the characteristics of the element; or
– the type or types of the element; or
– a template for the element.
An enterprise specification provides a pattern for realization of an ODP system in its environment. As such it may be
realized once, never, or many times, depending upon the objective of the specifier. This means that the behaviour defined
may also be observable any number of times, depending on when and where the specification is realized. It is therefore
necessary to take care of the context when interpreting statements about the occurrence of the concepts in an enterprise
specification.
6 ITU-T Rec. X.911 (10/2001)
In particular, when distinguishing type and occurrence in a specification, the objective is normally to distinguish between
multiple occurrences of a single type within the specification, and not to imply a constraint on how often the
specification can be realized in the world. The definitions in this Recommendation | International Standard should be
interpreted in the context of specification, without constraining when and where the specification should be realized.
The enterprise language makes no prescription about the specification process nor about the level of abstraction to be
used in an enterprise specification.
NOTE 1 – No recommendations are made about the relative merits of modelling from top-down or bottom-up. Nor is there a
recommended sequencing of the development of viewpoint specifications.
NOTE 2 – It is a design choice whether a specification deals with a specific implementation by, for example, identifying
individual enterprise objects, or deals with a more flexible architecture by identifying types and rules for assigning enterprise
objects to roles.
NOTE 3 – A specification may be partitioned because of readability, reuse of specification fragments in other specifications or
interoperability of enterprise objects.
NOTE 4 – Roles and communities, as well as types and templates, can be private to a specification and development environment,
or they can be stored in a repository that can be shared by a wider audience of several development environments and groups.
7.3 Community rules
7.3.1 Community
An enterprise specification states the objective of a community, how it is structured, what it does, and what objects
comprise it. The objective of the community is expressed in a contract that specifies how the objective can be met. This
contract:
– states the objective for which the community exists;
– governs the structure, the behaviour and the policies of the community;
– constrains the behaviour of the members of the community;
– states the rules for the assignment of enterprise objects to roles.
The contract for the community specifies constraints that govern the existence or behaviour of the collection of entities
described by the community. When a collection of entities is represented as a community, there may already be some
implicit or explicit agreement about those entities. Terms of that agreement may appear in the community contract. An
enterprise specification may include all or part of that agreement by reference. Such references relate the elements of the
specification to terms of that agreement. In particular, commitments of enterprise objects may be subject to that
agreement.
The behaviour of the community is such that meets its objective. The objects of a community are constrained by the rules
of the community contract.
The contract can be put in place by a defined behaviour carried out by enterprise objects or the contract may be
prescribed to exist by the enterprise specification.
The collective behaviour of the community is specified in terms of one or more of the following elements:
– the roles of the community (including those roles which define how a community interacts with its
environment);
– the processes that take place in the community;
– the assignment of roles to steps in processes;
– policies that apply to the roles and processes; and
– identification of those actions for which parties are accountable.
This collective behaviour is constrained by the policies associated with roles and processes and by the community
contract.
The behaviours of objects in a community are subject to the contract of that community and to the constraints specified
in relationships between those objects.
The structure of the community is defined in terms of the following elements:
– roles;
– policies for assignment of enterprise objects to roles;
– relationships between roles;
ITU-T Rec. X.911 (10/2001) 7
– relationships of roles to processes;
– policies that apply to roles and to relationships between roles;
– policies that apply to relationships between enterprise objects in the community;
– behaviour that changes the structure or the members of the community during the lifetime of that
community.
NOTE 1 – Types of communities or a community template may be used in the specification of a community.
NOTE 2 – Types of communities may be related by refinement.
NOTE 3 – A family of related contracts may be generated from a contract template. Some aspects of the contract (e.g.
membership) may only apply to particular instantiations of the contract template, while other aspects may apply to all
instantiations of the contract template. For example, assignment rules and policies can be considered as parameters in a contract
template. The style of contract specification determines the method of community establishment, as well as other aspects of the
community life-cycle.
7.3.2 Relationships between communities
An enterprise specification can include one or more communities. Interactions between enterprise objects fulfilling
appropriate roles within different communities can be considered as interactions between those communities.
Communities may interact in the following ways:
– a community object fulfils one or more roles in other communities;
– two or more community objects interact in fulfilling roles in some other community;
– the enterprise specification requires the same object to fulfil specific roles in more than one community;
– a community includes behaviour for creating new communities.
NOTE 1 – For example, federation establishment means creation of a new community involving the definition of an appropriate
policy framework, the structure for that community and the community contract.
NOTE 2 – For interactions involving community objects and the communities they represent see 7.8.3 – Interface Roles.
For each of these ways of interacting there is an invariant that determines the constraints on the collective behaviour of
the communities concerned.
These invariants include:
– where a community object fulfils one or more roles in another community, the community that the community
object represents is governed by the policies of the other community;
– where two or more community objects interact in fulfilling roles in some other community, the communities
that the community objects represent are related by those interactions;
– where the same object is required to fill specific roles in more than one community, an invariant specifies how
the actions of that object affect those communities;
– where the same object is required to fill specific roles in more than one community, that object becomes
governed by the policies of all those communities;
– where two or more communities interact, there is a set of policies common to those communities.
NOTE 3 – Where two communities interact, an implicit community may be considered, such that the community objects
representing both communities are members of and are governed by the policies of that community. The element of shared
objective and the common set of policies can be formed either at design time and included in the specifications of the communities
or left for run-time negotiation or testing of acceptability during community population.
NOTE 4 – The communities involved may have differing policy rules to all of which the enterprise object should be able to
conform.
7.4 Enterprise object rules
An enterprise specification will include enterprise objects; an enterprise object is any object in an enterprise
specification. Any enterprise objects and the entities they model are those felt to be necessary or desirable to specify the
system from the enterprise viewpoint or to understand the enterprise specification.
NOTE 1 – An enterprise object may be a model of a human being, a legal entity, an information processing system, a resource or a
collection or part of any o
...

NORME ISO/CEI
INTERNATIONALE 15414
Première édition
2002-10-15
Technologies de l'information —
Traitement réparti ouvert — Modèle de
référence — Langage d'entreprise
Information technology — Open distributed processing — Reference
model — Enterprise language
Numéro de référence
ISO/CEI 15414:2002(F)
©
ISO/CEI 2002
ISO/CEI 15414:2002(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 2002
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Version française parue en 2003
Publié en Suisse
ii © ISO/CEI 2002 — Tous droits réservés

ISO/CEI 15414:2002(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application. 1
2 Références normatives. 1
3 Définitions. 2
3.1 Définitions issues de normes de traitement ODP . 2
3.2 Définitions issues de normes de traitement ODP étendues dans la présente norme. 3
4 Abréviations . 3
5 Conventions. 3
6 Concepts. 4
6.1 Concepts de système . 4
6.2 Concepts de communauté. 4
6.3 Concepts de comportement . 4
6.4 Concepts de politique. 5
6.5 Concepts de responsabilité. 5
7 Règles de structuration . 5
7.1 Structure globale d'une spécification d'entreprise . 6
7.2 Contenu d'une spécification d'entreprise . 7
7.3 Règles de communauté . 7
7.4 Règles d'objet d'entreprise. 9
7.5 Types courants de communauté . 9
7.6 Cycle de vie d'une communauté. 10
7.7 Règles objectives. 11
7.8 Règles de comportement . 11
7.9 Règles de politique. 13
7.10 Règles de responsabilité. 15
8 Conformité, complétude et domaine d'application . 16
8.1 Conformité . 16
8.2 Complétude . 16
8.3 Domaine d'application. 17
9 Conformité du langage d'entreprise. 17
10 Conformité et points de référence . 17
11 Règles de cohérence . 18
11.1 Correspondances entre points de vue . 18
11.2 Correspondances entre spécifications d'entreprise et d'information. 19
11.3 Correspondances entre spécification d'entreprise et de traitement. 19
11.4 Correspondances entre spécifications d'entreprise et d'ingénierie. 20
Index . 21

© ISO/CEI 2002 — Tous droits réservés iii

ISO/CEI 15414:2002(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou
de la CEI participent au développement de Normes internationales par l'intermédiaire des comités techniques
créés par l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique. Les
comités techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres
organisations internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI
participent également aux travaux. Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé
un comité technique mixte, l'ISO/CEI JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de
Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des
organismes nationaux votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO et la CEI ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO/CEI 15414 a été élaborée par le comité technique mixte ISO/CEI JTC 1, Technologies de l'information,
sous-comité SC 7, Ingénierie du logiciel et du système, en collaboration avec l'UIT-T. Le texte identique est
publié en tant que Rec. UIT-T X.911.
iv © ISO/CEI 2002 — Tous droits réservés

ISO/CEI 15414:2002(F)
Introduction
La croissance rapide des applications réparties a conduit à l'adoption du modèle de référence pour le traitement réparti
ouvert (RM-ODP, reference model of open distributed processing). Ce modèle de référence ODP offre un cadre de
coordination pour la normalisation du traitement réparti ouvert (ODP). Il crée une architecture permettant d'y intégrer la
prise en compte de la répartition, de l'interfonctionnement et de la portabilité. Cette architecture offre un cadre pour la
spécification des systèmes de traitement ODP.
Le modèle de référence pour le traitement réparti ouvert (RM-ODP) repose sur des concepts précis issus des

développements récents dans le domaine des traitements répartis et s'appuie, dans la mesure du possible, sur l'utilisation
des techniques de description formelle pour la spécification de l'architecture.
La présente Recommandation | Norme internationale affine et élargit la définition de la façon dont les systèmes de
traitement ODP sont spécifiés du point de vue de l'entreprise. Elle est destinée à l'élaboration ou à l'utilisation de
spécifications de systèmes ODP en langage d'entreprise.
0.1 Modèle RM-ODP
Le modèle de référence ODP se compose des parties suivantes:
– Partie 1: Rec. UIT-T X.901 | ISO/CEI 10746-1: aperçu général: qui contient un apercu général du
modèle de référence ODP, en précise les finalités, le domaine d'application et la justification, et propose
une explication des concepts clés, ainsi qu'une présentation de l'architecture ODP. Cette
Recommandation contient des explications sur la façon d'interpréter et d'appliquer le modèle de référence
ODP: ses utilisateurs peuvent être des rédacteurs de norme et des architectes de systèmes ODP. Elle
contient également une classification des domaines de normalisation en termes de points de référence de
conformité identifiés dans la Rec. UIT-T X.903 | ISO/CEI 10746-3. Cette partie n'est pas normative;
– Partie 2: Rec. UIT-T X.902 | ISO/CEI 10746-2: fondements: qui contient la définition des concepts et le
cadre analytique à utiliser pour la description normalisée de systèmes de traitement répartis (arbitraires).
Cette Recommandation introduit les principes de la conformité aux normes ODP et la manière dont elles
s'appliquent. Elle s'en tient à un niveau de détail suffisant pour étayer la Rec. UIT-T X.903 |
ISO/CEI 10746-3 et pour établir les exigences de nouvelles techniques de spécification. Cette partie est
normative;
– Partie 3: Rec. UIT-T X.903 | ISO/CEI 10746-3: architecture: qui contient la spécification des
caractéristiques nécessaires pour qualifier un traitement réparti comme étant ouvert: ce sont les
contraintes auxquelles les normes ODP doivent se soumettre. Elle utilise les techniques descriptives de la
Rec. UIT-T X.902 | ISO/CEI 10746-2. Cette partie est normative;
– Partie 4: Rec. UIT-T X.904 | ISO/CEI 10746-4: sémantique architecturale: qui contient une
formalisation des concepts de modélisation ODP définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2,
articles 8 et 9. La formalisation s'obtient en interprétant chaque concept à partir d'éléments des
différentes techniques normalisées de description formelle. Cette partie est normative;
– Rec. UIT-T X.911 | ISO/CEI 15414: langage d'entreprise (la présente Recommandation | Norme
internationale).
0.2 Objet de la présente Recommandation | Norme internationale
La partie 3 du modèle de référence, Rec. UIT-T X.903 | ISO/CEI 10746-3, définit un cadre pour la spécification des
systèmes ODP. Ce cadre se compose des éléments suivants:
1) cinq points de vue: entreprise, information, traitement, ingénierie et technologie, qui forment une base
pour la spécification de systèmes ODP;
2) cinq langages de point de vue, définissant les concepts et les règles de spécification des systèmes ODP
du point de vue correspondant.
L'objet de la présente Recommandation | Norme internationale est:
– d'affiner et d'étendre le langage d'entreprise défini dans la Rec. UIT-T X.903 | ISO/CEI 10746-3 afin de
permettre une spécification totale d'un système ODP du point de vue entreprise;
– d'expliquer les correspondances d'une spécification de système ODP du point de vue entreprise avec
d'autres spécifications de point de vue pour ce système;
– de faire en sorte que le langage d'entreprise, utilisé de concert avec les autres langages de point de vue,
permette à la spécification d'une architecture d'application concrète de répondre à un besoin commercial
spécifique.
© ISO/CEI 2002 — Tous droits réservés v

ISO/CEI 15414:2002(F)
La présente Recommandation utilise des concepts repris des Rec. UIT-T X.902 et X.903 | ISO/CEI 10746-2 et 10746-3,
ainsi que des règles extraites de l'article 5 de la Rec. UIT-T X.903 | ISO/CEI 10746-3. Elle apporte des raffinements de
ces concepts, de nouveaux concepts spécifiques de point de vue, ainsi que des règles de structuration normatives pour

les spécifications du point de vue entreprise. Les nouveaux concepts spécifiques de point de vue sont définis au moyen
de concepts extraits des Recommandations UIT-T X.902 et X.903 | ISO/CEI 10746-2 et 10746-3.
0.3 Aperçu général et finalité
La présente Recommandation | Norme internationale vise à offrir un langage commun (c'est-à-dire un ensemble de
termes et des règles syntaxiques) à utiliser lors de l'élaboration d'une spécification d'entreprise reprenant les objectifs, le
domaine d'application et les politiques d'un système de traitement ODP. Une telle spécification d'entreprise fait partie de
la spécification d'un système ODP en tant qu'ensemble de points de vue définis par la Rec. UIT-T X.903 |
ISO/CEI 10746-3. Le lectorat principal de la présente Recommandation | Norme internationale se compose de ceux qui
élaborent et utilisent de telles spécifications.
Une spécification d'entreprise appartient à une spécification de système ODP. Elle permet de décrire tout ou partie des
points suivants:
• un système existant;
• une future structure envisagée ou le comportement de ce système existant;
• un système à créer dans un environnement donné.
La finalité d'un langage d'entreprise type est de prendre en charge des techniques de spécification normalisées afin
d'améliorer la communication et de faciliter la création de spécifications globalement cohérentes. Le langage
d'entreprise fournit les termes et les règles de structuration permettant de spécifier les objectifs, le domaine d'application
et les politiques d'un système ODP d'une façon qui soit explicite pour les intervenants dans ce système, y compris les
détenteurs, les utilisateurs, les développeurs et les mainteneurs.
Une spécification d'entreprise décrit la structure et le comportement du système à l'intérieur de son environnement. Elle
explicite les aspects de l'environnement qui exercent une influence sur le comportement du système ODP: les
contraintes environnantes sont saisies ainsi que le taux d'utilisation et les règles de gestion. Les politiques relatives aux
éventuelles modifications du système, pouvant régir son évolution future, peuvent aussi être incluses. Un tel
environnement peut être de nature technique (par exemple, l'environnement logiciel et matériel d'un composant de
service) ou être de nature sociale ou commerciale (comme un groupe de coentreprises ou un service particulier à
l'intérieur d'une entreprise).
Lors de l'élaboration d'une spécification, de nombreuses méthodes peuvent être suivies afin de comprendre, d'adopter et
de spécifier des systèmes dans le contexte des organisations dont ils font partie. Un grand nombre de ces méthodes
s'inscrivent dans les catégories qui sont souvent désignées comme étant une spécification d'analyse ou d'exigences. Ces
méthodes peuvent fournir d'utiles ouvertures sur l'organisation considérée comme sur les exigences auxquelles les
systèmes doivent satisfaire afin de prendre en charge ces méthodes. Mais celles-ci manquent souvent de la rigueur, de la
cohérence et de la complétude nécessaires à une spécification approfondie. Un des objectifs clés de la présente
Recommandation | Norme internationale est d'offrir le moyen d'associer les concepts couramment utilisés et les
principes sous-tendant de telles méthodes au cadre de modélisation du modèle RM-ODP.
Un important objectif d'une spécification d'entreprise est la prise en charge d'un accord (par exemple dans le cadre du
contrat de fourniture d'un système) entre les détenteurs et utilisateurs possibles d'un système ODP et le fournisseur de ce
système. Il convient que les deux parties soient en mesure de rédiger, de lire et d'analyser une telle spécification; que les
détenteurs et utilisateurs soient assurés de la structure et du comportement à attendre du système qu'ils obtiendront; et
que le fournisseur soit clair concernant la structure et le comportement du système qui va être fourni.
La spécification d'entreprise peut aussi être utilisée à d'autres phases du cycle de vie du système. Elle peut par exemple
être utilisée lors du fonctionnement du système afin de contrôler les accords passés entre le système et ses utilisateurs,
de conclure de nouveaux accords selon la même structure contractuelle, et de constituer des fédérations.
Finalement, dans le sens de la tendance actuelle à l'intégration des systèmes existants en réseaux mondiaux dans
lesquels la fonctionnalité considérée couvre de multiples organisations, le langage d'entreprise permet de spécifier
l'accord conclu au sujet de la structure et du comportement des systèmes ODP à l'intérieur de ces organisations et entre
elles.
Les concepts et les règles de structuration contenus dans la présente Recommandation | Norme internationale peuvent
servir à la mise au point de méthodes et d'outils d'ingénierie logicielle exploitant les langages de point de vue ODP,
ainsi qu'à la mise au point de notations textuelles ou graphiques pour le langage d'entreprise ODP proprement dit. C'est
à ces fins que la présente Recommandation | Norme internationale fournit des règles concernant le contenu
informationnel d'une spécification d'entreprise et concernant le groupage de ces informations. Les méthodes, outils ou
notations à mettre au point contiendront spécifiquement d'autres exigences relatives aux relations entre les concepts
linguistiques d'entreprise et à leurs correspondances avec les concepts relevant d'autres points de vue.
vi © ISO/CEI 2002 — Tous droits réservés

ISO/CEI 15414:2002 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Traitement réparti ouvert –
Modèle de référence – Langage d'entreprise
1 Domaine d'application
La présente Recommandation | Norme internationale offre:
a) un langage (d'entreprise) composé de concepts, de structures et de règles permettant de développer, de
représenter et d'analyser une spécification du système de traitement réparti ouvert (ODP du point de vue
d'une entreprise (comme défini dans la Rec. UIT-T X.903 | ISO/CEI 10746-3);
b) des règles établissant des correspondances entre le langage d'entreprise et les autres langages de point de
vue (définis dans la Rec. UIT-T X.903 | ISO/CEI 10746-3) afin d'assurer la cohérence globale d'une
spécification.
Ce langage est spécifié à un niveau de détail suffisant pour permettre de déterminer la conformité de tout langage de
modélisation à la présente Recommandation | Norme internationale et d'établir des exigences pour de nouvelles
techniques de spécification.
La présente Recommandation | Norme internationale est un affinement et une extension des articles 5 et 10 de la
Rec. UIT-T X.903 | ISO/CEI 10746-3 mais elle ne les remplace pas.
La présente Recommandation | Norme internationale est destinée à servir à l'élaboration de spécifications de systèmes
ODP par point de vue et à la mise au point de notations et d'outils afin de prendre en charge de telles spécifications.
Comme indiqué dans l'article 5 de la Rec. UIT-T X.903 | ISO/CEI 10746-3, une spécification de point de vue entreprise
définit les objectifs, le domaine d'application et les politiques d'un système ODP. [voir également 3-5.0]
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation | Norme internationale. Au moment de
la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision et
les parties prenantes aux accords fondés sur la présente Recommandation | Norme internationale sont invitées à
rechercher la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de l'UIT tient à jour une liste des Recommandations de l'UIT-T en vigueur.
Recommandations UIT-T | Normes internationales identiques
– Recommandation UIT-T X.902 (1995) | ISO/CEI 10746-2:1996, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: fondements.
– Recommandation UIT-T X.903 (1995) | ISO/CEI 10746-3:1996, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: architecture.
– Recommandation UIT-T X.904 (1997) | ISO/CEI 10746-4:1998, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: sémantique architecturale.
Rec. UIT-T X.911 (10/2001) 1
ISO/CEI 15414 : 2002 (F)
3 Définitions
3.1 Définitions issues de normes de traitement ODP
3.1.1 Définitions relevant du concept de modélisation
La présente Recommandation | Norme internationale emploie les termes suivants, qui sont définis dans la
Rec. UIT-T X.902 | ISO/CEI 10746-2:
– action
– comportement (d'un objet)
– objet composite
– composition
– configuration (d'objets)
– conformité
– point de conformité
– contrat
– domaine de
– entité
– contrat d'environnement
– environnement (d'un objet)
– phase
– comportement d'établissement
– instance (d'un type)
– instanciation (d'un gabarit )
– interface
– action interne
– invariant
– liaison
– instant
– objet
– obligation
– normes ODP
– système ODP
– permission
– interdiction
– proposition
– point de référence
– raffinement
– rôle
– état (d'un objet)
– sous-type
– système
– gabarit
– comportement terminal
– type (d'un )
– point de vue (relatif à un système)
2 Rec. UIT-T X.911 (10/2001)
ISO/CEI 15414:2002 (F)
3.1.2 Définitions relevant du langage de point de vue
La présente Recommandation | Norme internationale emploie les termes suivants, qui sont définis dans la
Rec. UIT-T X.903 | ISO/CEI 10746-3:
– objet lieur
– canal
– communauté
– comportement de traitement
– objet lieur de traitement
– objet de traitement
– interface de traitement
– point de vue traitement
– correspondance
– schéma dynamique
– point de vue ingénierie
– point de vue entreprise
– fédération de
– objet d'information
– point de vue information
– intercepteur
– schéma d'invariant
– nœud
– objet de protocole
– schéma statique
– talon
– point de vue technologie
– langage de
3.2 Définitions issues de normes de traitement ODP étendues dans la présente spécification
La présente Recommandation | Norme internationale étend la définition du terme suivant, initialement défini dans la
Rec. UIT-T X.902 | ISO/CEI 10746-2 [2-11.2.7]:
− politique
La définition étendue est reproduite dans l'article 6.
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale les abréviations suivantes sont utilisées:
ODP Traitement réparti ouvert (open distributed processing)
RM-ODP Modèle de référence du traitement réparti ouvert (reference model of open distributed processing)
(Recommandations UIT-T X.901 à X.904 | ISO/CEI 10746, parties 1 à 4)
5 Conventions
La présente Recommandation | Norme internationale contient des références aux parties 2 et 3 du modèle RM-ODP. Par
exemple, [2-9.4] est une référence au § 9.4 de la partie 2 (Rec. UIT-T X.902 | ISO/CEI 10746-2). Ces références visent à
faciliter la lecture.
Rec. UIT-T X.911 (10/2001) 3
ISO/CEI 15414 : 2002 (F)
La présente Recommandation | Norme internationale contient également une modification d'un texte extrait de la partie 3
de la Rec. UIT-T X.903 | ISO/CEI 10746-3. Ce texte est annoté par une référence du type: [voir également 3-5.0]. Ces
modifications font autorité par rapport au langage d'entreprise.
6 Concepts
Les concepts du langage d'entreprise défini dans la présente Recommandation | Norme internationale sont les suivants:
– les concepts indiqués dans les § 3.1.1 et 3.1.2, tels que définis dans la Rec. UIT-T X.902 |
ISO/CEI 10746-2 et dans la Rec. UIT-T X.903 | ISO/CEI 10746-3;
– les concepts définis dans le présent article.
Le présent article définit de nouveaux concepts et affine la définition de politique figurant dans la Rec. UIT-T X.902 |
ISO/CEI 10746-2 [2-11.2.7]. Dans le présent article, le groupement en paragraphes et les titres de ces derniers ne sont
pas normatifs.
6.1 Concepts de système
6.1.1 portée (d'un système): comportement qu'un système est censé manifester.
6.1.2 domaine d'application (d'une spécification): propriétés que l'environnement du système de traitement ODP
doit posséder pour que la spécification de ce système soit utilisée.
6.2 Concepts de communauté
6.2.1 objectif: avantage pratique ou effet prévu, exprimé par des préférences quant aux états futurs.
NOTE 1 – Certains objectifs sont permanents tandis que d'autres sont réalisés une fois atteints.
NOTE 2 – Dans le texte de la Rec. UIT-T X.903 | ISO/CEI 10746-3 [3-5], les termes objet et objectif sont synonymes. Le langage
d'entreprise utilise systématiquement le terme objectif et souligne la nécessité d'exprimer un objectif en termes mesurables.
6.2.2 objet communautaire: objet d'entreprise composite qui représente une communauté. Les éléments
constituants d'un objet communautaire sont les objets de la communauté représentée.
6.3 Concepts de comportement
6.3.1 acteur (par rapport à une action): objet d'entreprise qui participe à l'action.
NOTE – Il peut être utile de spécifier l'acteur qui déclenche cette action.
6.3.2 artéfact (par rapport à une action): objet d'entreprise auquel il est fait référence dans l'action.
NOTE – Un objet d'entreprise qui est un artéfact dans une action donnée peut être un acteur dans une autre action.
6.3.3 ressource: objet d'entreprise essentiel à un comportement donné qui nécessite une attribution ou qui peut
devenir indisponible.
NOTE 1 – L'attribution d'une ressource peut contraindre d'autres comportements pour lesquels cette ressource est essentielle.
NOTE 2 – Une ressource consommable peut devenir indisponible après un certain nombre d'utilisations ou après un certaine durée
(si une durée ou une temporisation a été spécifiée pour la ressource).
6.3.4 rôle d'interface: rôle d'une communauté indiquant le comportement qui intervient avec la participation
d'objets qui ne sont pas membres de cette communauté.
6.3.5 processus: série d'étapes intervenant d'une façon prescrite et conduisant à un objectif.
NOTE 1 – Un processus peut avoir plusieurs points de départ et plusieurs points d'arrivée.
NOTE 2 – La façon prescrite peut être une séquence partiellement ordonnée.
NOTE 3 – Une spécification de processus peut être une spécification de gestion de processus.
NOTE 4 – Les concepts de structure d'activité présentés dans le § 13.1 de la Rec. UIT-T X.902 | ISO/CEI 10746-2 peuvent être
utilisés après remplacement du terme 'action' par 'étape' et du terme 'activité' par 'processus' afin de spécifier la structure d'un
processus.
NOTE 5 – Une spécification d'entreprise peut définir des types et gabarits de processus.
6.3.6 étape: vue abstraite d'une action, utilisée dans un processus et pouvant laisser des objets non spécifiés qui
participent à cette action.
4 Rec. UIT-T X.911 (10/2001)
ISO/CEI 15414:2002 (F)
6.4 Concepts de politique
6.4.1 politique: ensemble de règles relatives à un objectif particulier. Une règle peut être exprimée sous la forme
d'une obligation, d'une autorisation, d'une permission ou d'une interdiction.
NOTE 1 – Toutes les politiques ne sont pas des contraintes. Certaines politiques représentent une habilitation.
NOTE 2 – Cette définition affine le § 2-11.2.7 en ajoutant l'autorisation.
6.4.2 autorisation: prescription qu'un comportement particulier ne doit pas être empêché.
NOTE – A la différence d'une permission, une autorisation est une habilitation.
6.4.3 violation: action contraire à une règle.
NOTE – Une règle ou une politique peut déclencher un comportement lors d'une violation de cette règle ou politique ou d'une
autre règle ou politique.
6.5 Concepts de responsabilité
6.5.1 partie: objet d'entreprise modélisant une personne physique ou une autre entité considérée comme possédant
certains des droits, pouvoirs et devoirs d'une personne physique.
NOTE 1 – Les objets d'entreprise représentant des personnes physiques, des entités juridiques, des administrations d'Etat et leurs
services, ainsi que d'autres associations ou groupes de personnes physiques sont des exemples de parties.
NOTE 2 – Les parties sont responsables de leurs actions et de celles de leurs agents.
Les concepts ci-après permettent d'identifier les actions qui impliquent la responsabilité d'une partie.
6.5.2 engagement: action résultant de l'obligation, incombant à un ou plusieurs des participants à un processus, de se
conformer à une règle ou d'exécuter un contrat.
NOTE – L'objet ou les objets d'entreprise participant à une action d'engagement peut ou peuvent être des parties, ou des agents
agissant pour le compte d'une ou de plusieurs parties. Dans le cas d'une action d'engagement par un agent, le mandant devient
l'obligé.
6.5.3 déclaration: action qui établit un état de choses dans l'environnement de l'objet qui formule la déclaration.
NOTE – L'essence d'une déclaration est que, par l'action qu'elle représente et l'autorité de l'objet qui la formule ou de son mandant,
elle fait apparaître un état de choses extérieur à cet objet.
6.5.4 délégation: action qui attribue une autorité, une responsabilité ou une fonction à un autre objet.
NOTE – Une fois conférée, une délégation peut ensuite être retirée.
6.5.5 évaluation: action d'estimation de la valeur d'un élément.
NOTE 1 – Par exemple, l'acte par lequel un système ODP attribue un état relatif à un élément, conformément à l'estimation
effectuée par le système.
NOTE 2 – La valeur peut être exprimée en termes d'utilité, d'importance, de préférence, d'acceptabilité, etc. La cible évaluée peut
être, par exemple, une cote de solvabilité, un état du système, un comportement éventuel, etc.
6.5.6 prescription: acte d'établissement d'une règle.
6.5.7 agent: objet d'entreprise qui a été délégué (autorité, responsabilité, fonction, etc.) par un autre objet d'entreprise
et qui agit pour lui (lors de l'exercice de l'autorité, de la prise de la responsabilité, de l'exécution de la fonction, etc.).
NOTE 1 – Un agent peut être une partie ou être le système ODP ou un de ses éléments. Un autre système situé dans
l'environnement du système ODP peut également être un agent.
NOTE 2 – La délégation peut avoir été concédée directement par une partie, ou indirectement par un agent de la partie dont il a
reçu l'autorisation de représentation.
6.5.8 mandant: partie qui a délégué (son autorité, une fonction, etc.) à une autre partie.
6.5.9 partie contractante; contractant (dans le cadre d'un contrat): partie qui se conforme à ce contrat.
7 Règles de structuration
Le présent article affine et étend les règles de structuration définies au § 5.2 de la Rec. UIT-T X.903 | ISO/CEI 10746-3
dans la mesure où elles s'appliquent aux concepts de communauté, d'objet d'entreprise, d'objectif, de comportement et de
politique. Il définit les règles de structuration pour les concepts de responsabilité définis au § 6.5 ci-dessus. Il utilise les
concepts définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2, dans le § 5.1 de la Rec. UIT-T X.903 | ISO/CEI 10746-3
et dans l'article 6.
Rec. UIT-T X.911 (10/2001) 5
ISO/CEI 15414 : 2002 (F)
7.1 Structure globale d'une spécification d'entreprise
Une spécification d'entreprise de système ODP est une description de ce système et des parties correspondantes de son
environnement. La spécification d'entreprise est centrée sur la portée et sur l'objectif de ce système ainsi que sur les
politiques qui s'y appliquent dans le contexte de son environnement.
NOTE 1 – Un système ODP et son environnement peuvent s'étendre sur plusieurs organisations.
Un concept de structuration fondamental pour les spécifications d'entreprise est celui de la communauté. Celle-ci est une
configuration d'objets d'entreprise qui décrit un ensemble d'entités formé afin d'atteindre un objectif (par exemple, des
êtres humains, des systèmes de traitement de l'information, des ressources de diverses sortes et des ensembles de telles
ressources). Ces entités font l'objet d'un accord régissant leur comportement collectif. L'attribution d'actions aux objets
d'entreprise composant une communauté est définie en termes de rôles (voir § 7.8.1 et 7.8.2).
Le système ODP peut remplir un rôle dans plusieurs communautés. La spécification d'entreprise décrit donc, dans les
domaines d'intérêt des utilisateurs de spécification:
– les rôles joués par le système ODP et par les objets d'entreprise dans son environnement;
– les étapes à l'intérieur des processus auxquelles participent le système ODP et les objets d'entreprise
contenus dans son environnement;
– la politique du système, y compris les politiques des contrats d'environnement.
Une spécification d'entreprise de système ODP comporte au moins la communauté dans laquelle ce système peut être
représenté en tant qu'objet d'entreprise distinct, interagissant avec son environnement. Le soin est laissé au spécificateur
de déterminer si la spécification comporte réellement ce niveau d'abstraction.
NOTE 2 – Cette spécification minimale d'entreprise décrit l'objectif et la portée du système ODP. Cette description est nécessaire
afin que la spécification d'entreprise soit complète.
Si la clarté ou l'exhaustivité de la description du comportement du système ODP l'exige, la spécification d'entreprise peut
comporter toute autre communauté dont le système ODP ou ses composants sont membres et toute autre communauté
dont des objets d'entreprise contenus dans l'environnement du système ODP sont membres.
NOTE 3 – L'ensemble des communautés contenues dans une spécification d'entreprise peut comprendre, par exemple, des
communautés de niveau aussi bien plus abstrait que plus détaillé que la spécification minimale d'entreprise, ainsi que des
communautés relatives à la décomposition fonctionnelle du système ODP ainsi qu'à la propriété de celui-ci et de ses parties.
La spécification d'entreprise peut aussi être structurée en termes de nombre de communauté interagissant les unes avec
les autres.
NOTE 4 – Une telle structuration peut représenter, par exemple, une fédération.
L'interaction de communautés peut être représentée de différentes façons:
– les communautés concernées peuvent être vues comme des objets composites (objets c) et comme une
nouvelle communauté composée de ces objets composites. Cette communauté peut être décrite
explicitement ou peut rester implicite;
– une nouvelle communauté peut être formée d'un ou de plusieurs objets de chaque communauté, avec des
rôles dans la nouvelle communauté spécifiant les interactions entre communautés;
– une nouvelle communauté peut être formée d'un ou de plusieurs objets de chaque communauté, par
attribution de rôles au même objet dans différentes communautés et par attribution d'une correspondance
entre chacun de ces rôles avec un rôle contenu dans la nouvelle communauté;
– les objets d'interface des communautés peuvent interagir afin de former une nouvelle communauté.
La portée du système est définie dans les termes de son comportement prévu. En langage d'entreprise, cette définition est
exprimée en termes de rôles ou de processus ou des deux, de politiques et de relations entre celles-ci.
NOTE 5 – Il peut être utile d'analyser la portée prévue, communiquée ou attendue d'un système à diverses phases de planification,
de développement ou de déploiement. Dans ce cas, il convient de qualifier le terme de "portée" en conséquence.
Une spécification de système ODP complète indique des règles pour assurer la cohérence interne en termes de relations
entre diverses spécifications de point de vue. Une spécification d'entreprise complète contient des règles de conformité
qui définissent le comportement requis du système ODP décrit.
Le présent article définit la façon dont les concepts désignés à l'article 3 ou définis à l'article 6 de la présente
Recommandation | Norme internationale sont utilisés dans une spécification d'entreprise.
6 Rec. UIT-T X.911 (10/2001)
ISO/CEI 15414:2002 (F)
7.2 Contenu d'une spécification d'entreprise
Une spécification d'entreprise est structurée en fonction des éléments expliqués au § 7.1 (communautés, objets
d'entreprise, contrats, rôles, interactions, activités, comportement, système ODP et politiques) et en fonction des autres
concepts indiqués à l'article 10, ainsi que des relations entre ces éléments.
Pour chacun de ces éléments, la spécification d'entreprise fournit, en fonction du choix du spécificateur et du niveau de
détail recherché:
– les caractéristiques de l'élément;
– le type ou les types de l'élément;
– un gabarit pour l'élément.
Une spécification d'entreprise fournit un schéma permettant de réaliser un système ODP dans son environnement. En tant
que tel, celui-ci peut être réalisé une fois, jamais ou souvent, selon l'objectif du spécificateur. En d'autres termes, le
comportement défini peut donc être observé un nombre quelconque de fois, selon le moment et le lieu où la spécification
est réalisée. Il est donc nécessaire de veiller au contexte lors de l'interprétation de déclarations relatives à l'occurrence des
concepts dans une spécification d'entreprise.
En particulier, lors de la distinction du type et de l'occurrence dans une spécification, l'objectif consiste normalement à
distinguer entre de multiples occurrences d'un même type à l'intérieur de la spécification et non pas à imposer une
contrainte sur le nombre de réalisations possibles de la spécification dans le monde. Les définitions contenues dans la
présente Recommandation | Norme internationale doivent être interprétées dans le contexte de la spécification sans
imposer de contrainte quand au moment et au lieu où il convient de la réaliser.
Le langage d'entreprise ne formule aucune prescription au sujet du processus de spécification ou du niveau d'abstraction
à utiliser dans une spécification d'entreprise.
NOTE 1 – Aucune recommandation n'est formulée au sujet des avantages relatifs de la modélisation à partir du haut ou à partir du
bas. Aucun séquencement n'est non plus recommandé concernant l'élaboration de spécifications de point de vue.
NOTE 2 – La question de savoir si une implémentation traite d'une implémentation spécifique en identifiant par exemple des
objets d'entreprise particuliers ou traite d'une architecture plus flexible en identifiant des types et des règles d'attribution d'objets
d'entreprise à des rôles relève d'un choix de conception.
NOTE 3 – Une spécification peut être partitionnée pour des raisons de lisibilité, de réutilisation de fragments de spécification dans
d'autres spécifications ou pour des raisons d'interopérabilité d'objets d'entreprise.
NOTE 4 – Les rôles et les communautés, ainsi que les types et les modèles, peuvent être propres à une spécification et à un
environnement de développement ou bien peuvent être mémorisés dans un répertoire pouvant être partagé par une plus grande
population, constituée de plusieurs environnements et groupes de développement.
7.3 Règles de communauté
7.3.1 Communauté
Une spécification d'entreprise indique l'objectif d'une communauté, la façon dont elle est structurée, ce qu'elle fait et
quels objets la composent. L'objectif de la communauté est exprimé dans un contrat qui spécifie la façon dont l'objectif
peut être atteint. Ce contrat:
– indique l'objectif sur lequel l'existence de la communauté est fondée;
– régit la structure, le comportement et les politiques de la communauté;
– contraint le comportement des membres de la communauté;
– indique les règles d'attribution d'objets d'entreprise à des rôles.
Le contrat relatif à la communauté spécifie des contraintes qui régissent l'existence ou le comportement de l'ensemble
d'entités décrit par cette communauté. Lorsqu'un ensemble d'entités est représenté par une communauté, il peut y avoir
déjà un certain accord implicite ou explicite au sujet de ces entités. Des termes de cet accord peuvent apparaître dans le
contrat de communauté. Une spécification d'entreprise peut comporter, par référence, tout ou partie de cet accord. De
telles références associent les éléments de la spécification aux termes de cet accord. Des engagements d'objets
d'entreprise peuvent en particulier être soumis à cet accord.
Le comportement de la communauté est tel que son objectif est atteint. Les objets d'une communauté sont contraints par
les règles du contrat de communauté.
Le contrat peut être mis en place par un comportement défini qui est manifesté par des objets d'entreprise. Son existence
peut également être prescrite par la spécification d'entreprise.
Rec. UIT-T X.911 (10/2001) 7
ISO/CEI 15414 : 2002 (F)
Le comportement collectif de la communauté est spécifié dans les termes d'un ou de plusieurs des éléments suivants:
– les rôles de la communauté (y compris les rôles qui définissent la façon dont une communauté interagit
avec son environnement);
– les processus qui se déroulent dans la communauté;
– l'attribution de rôles à des étapes dans les processus;
– les politiques qui s'appliquent aux rôles et aux processus;
– et l'identification des actions dont les parties sont responsables.
Ce comportement collectif est contraint par les politiques associées aux rôles et aux processus ainsi que par le contrat de
communauté.
Les comportements des objets dans une communauté sont soumis au contrat de celle-ci ainsi qu'aux contraintes
spécifiées dans les re
...