1、 Collection of SANS standards in electronic format (PDF) 1. Copyright This standard is available to staff members of companies that have subscribed to the complete collection of SANS standards in accordance with a formal copyright agreement. This document may reside on a CENTRAL FILE SERVER or INTRA
2、NET SYSTEM only. Unless specific permission has been granted, this document MAY NOT be sent or given to staff members from other companies or organizations. Doing so would constitute a VIOLATION of SABS copyright rules. 2. Indemnity The South African Bureau of Standards accepts no liability for any
3、damage whatsoever than may result from the use of this material or the information contain therein, irrespective of the cause and quantum thereof. ICS 35.100.01 ISBN 0-626-14688-7 SANS 10746-2:2003 Edition 1 ISO/IEC 10746-2:1996 Edition 1 SOUTH AFRICAN NATIONAL STANDARD Information technology Open d
4、istributed processing Reference model: Foundations This national standard is the identical implementation of ISO/IEC 10746-2:1996 and is adopted with the permission of the International Organization for Standardization and the International Electrotechnical Commission. Published by Standards South A
5、frica 1 dr lategan road groenkloof private bag x191 pretoria 0001 tel: 012 428 7911 fax: 012 344 1568 international code + 27 12 www.stansa.co.za Standards South Africa 2003 SANS 10746-2:2003 Edition 1 ISO/IEC 10746-2:1996 Edition 1 Table of changes Change No. Date Scope National foreword This South
6、 African standard was approved by National Committee STANSA SC 71C, ICT software and systems engineering, in accordance with procedures of Standards South Africa, in compliance with annex 3 of the WTO/TBT agreement. INTERNATIONAL STANDARD ISO/IEC 10746-2 First edition 1996-09-I 5 Information technol
7、ogy - Open Distributed Processing - Reference Model: Foundations Technologies de /information - Traitement distribue ouvert - Mod b) the structure of distributed systems which claim compliance with the Reference Model (the configuration of the systems); Cl the concepts needed to express the combined
8、 use of the various standards supported; d) the basic concepts to be used in the specifications of the various components which make up the open distributed system. 2 Normative references The following Recommendations and International Standards contain provisions which, through reference in this te
9、xt, constitute provisions of this Recommendation I 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 I International Standard are encouraged to inves
10、tigate the possibility of applying the most recent edition of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recomm
11、endations. 21 . Identical Recommendations I International Standards - ITU-T Recommendation X.903 (1995) I ISO/IEC 10746-3: 1996, Infomzation technology - en distributed processing - Reference Model: Architecture. 3 Definitions For the purposes of this Recommendation I International Standard, the fol
12、lowing definitions apply. 31 0 Definitions from other Recommendations I International Standards There are no definitions from other Recommendations I International Standards in this Recommendation I International Standard. 32 . Background definitions 3.2.1 distributed processing: Information process
13、ing in which discrete components may be located in different places, and where communication between components may suffer delay or may fail. 3.2.2 ODP standards: This Reference Model and those standards that comply with it, directly or indirectly. 3.2.3 open distributed processing: Distributed proc
14、essing designed to conform to ODP standards. 3.2.4 ODP system: A system (see 6.5) which conforms to the requirements of ODP standards. IT the grammar of any language for the ODP Architecture must be described in terms of these concepts. These concepts are described in clause 7. Basic modelZing conce
15、pts: Concepts for building the ODP Architecture; the modelling constructs of any language must be based on these concepts. These concepts are described in clause 8. Specification concepts: Concepts related to the requirements of the chosen specification languages used in ODP. These concepts are not
16、intrinsic to distribution and distributed systems, but they are requirements to be considered in these specification languages. These concepts are described in clause 9. Structuring concepts: Concepts that emerge from considering different issues in distribution and distributed systems. They may or
17、may not be directly supported by specification languages adequate for dealing with the problem area. Specification of objects and functions that directly support these concepts must be made possible by the use of the chosen specification languages. These concepts are described in clauses 10 to 14. C
18、onformance concepts: Concepts necessary to explain the notions of conformance to ODP standards and of conformance testing. These concepts are defined in clause 15. IT b) one or more pertinent levels of abstraction The elements of the universe of discourse are entities and propositions. 61 Entity: An
19、y concrete or abstract thing of interest. While in general the word entity can be used to refer to anything, in the context of modelling it is reserved to refer to things in the universe of discourse being modelled. 62 . Proposition: An observable fact or state of affairs involving one or more entit
20、ies, of which it is possible to assert or deny that it holds for those entities. 63 piocess. Abstraction: The process of suppressing irrelevant detail to establish a simplified model, or the result of that 64 . Atomicity: An entity is atomic at a given level of abstraction if it cannot be subdivided
21、 at that level of abstraction. Fixing a given level of abstraction may involve identifying which elements are atomic. 65 . System: Something of interest as a whole or as comprised of parts. Therefore a system may be referred to as an entity. A component of a system may itself be a system, in which c
22、ase it may be called a subsystem. NOTE - For modelling purposes, the concept of system is understood in its general, system-theoretic sense. The term “system” can refer to an information processing system but can also be applied more generally. 66 Architecture (of a system): A set of rules to define
23、 the structure of a system and the interrelationships between its parts. 7 Basic linguistic concepts Whatever the concepts or semantics of a modelling language for the ODP Architecture, it will be expressed in some syntax, which may include linear text or graphical conventions. It is assumed that an
24、y suitable language will have a grammar defining the valid set of symbols and well-formed linguistic constructs of the language. The following concepts provide a common framework for relating the syntax of any language used for the ODP Architecture to the interpretation concepts. 7.1 Term: A linguis
25、tic construct which may be used to refer to an entity. The reference may be to any kind of entity including a model of an entity or another linguistic construct. 7.2 Sentence: A linguistic construct containing one or more terms and predicates; a sentence may be used to express a proposition about th
26、e entities to which the terms refer. A predicate in a sentence may be considered to refer to a relationship between the entities referred to by the terms linked. 8 Basic modelling concepts The detailed interpretation of the concepts defined in this clause will depend on the specification language co
27、ncerned, but these general statements of concept are made in a language-independent way to allow the statements in different languages to be interrelated. The basic concepts are concerned with existence and activity: the expression of what exists, where it is and what it does. 81 Object: A model of
28、an entity. An object is characterized by its behaviour (see 8.6) and, dually, by its state (ice 8.7). An object is distinct from any other object. An object is encapsulated, i.e. any change in its state can only occur as a result of an internal action or as a result of an interaction (see 8.3) with
29、its environment (see 8.2). An object interacts with its environment at its interaction points (see 8.11). Depending on the viewpoint, the emphasis may be placed on behaviour or on state. When the emphasis is placed on behaviour, an object is informally said to perform functions and offer services (a
30、n object which makes a function available is said to offer a service). For modelling purposes, these functions and services are specified in terms of the behaviour of the object and of its interfaces (see 8.4). An object can perform more than one function. A function can be performed by the cooperat
31、ion of several objects. ITU-T Rec. X.902 (1995 E) 3 ISO/IEC 10746-2 : 1996 (E) NOTES 1 The concepts of service and function are used informally to express the purpose of a piece of standardization. In the ODP family of standards, function and service are expressed formally in terms of the specificat
32、ion of the behaviour of objects and of the interfaces which they support. A “service” is a particular abstraction of behaviour expressing the guarantees offered by a service provider. 2 The expression “use of a function” is a shorthand for the interaction with an object which performs the function.
33、82 . Environment (of an object): The part of the model which is not part of that object. NOTE - In many specification languages, the environment can be considered to include at least one object which is able to participate without constraint in all possible interactions (see 8.3), representing the p
34、rocess of observation. 83 . Action: Something which happens. Every action of interest for modelling purposes is associated with at least one object. The set of actions associated with an object is partitioned into internal actions and interactions. An intern always takes place without the participat
35、ion of the environment of the object. An interaction takes place participation of the environment of the object. NOTES 1 “Action” means “action occurrence”. Depending on context, a specification may express that an action has is occurring or may occur. 2 The granularity of actions is a design choice
36、. An action need not be instantaneous. Actions may overlap in ti .me. al action with the occurred, 3 Interactions may be labelled in terms of cause and effect relationships between the participating objects. The concepts that support this are discussed in 13.3. 4 An object may interact with itself,
37、in which case it is considered to play at least two roles in the interaction, and may be considered, in this context, as being a part of its own environment. 5 Involvement of the environment represents observability. Thus, interactions are observable whereas internal actions are not observable, beca
38、use of object encapsulation. 84 . object Interface: An abstraction of together with a set of constraints the behaviour of an object that on when they may occur. consists of a subset of the interactions of that Each interaction of an object belongs to a unique interface. Thus, the interfaces of an ob
39、ject form a partition of the interactions of that object. NOTES 1 An interface constitutes the part of an object behaviour that is obtained by considering only the interactions of that interface and by hiding all other interactions. Hiding interactions of other interfaces will generally introduce no
40、n-determinism as far as the interface being considered is concerned. 2 The phrase “an interface between objects” is used to refer to the binding (see 13.4.2) between interfaces of the objects concerned. 85 . Activity: A single-headed directed acyclic graph of actions, where occurrence of each action
41、 in the graph is made possible by the occurrence of all immediately preceding actions (i.e. by all adjacent actions which are closer to the head). 86 . Behaviour (of an object): A collection of actions with a set of constraints on when they may occur. The specification language in use determines the
42、 constraints which may be example sequentiality, non-determinism, concurrency or real-time constraints. expressed. Constraints may include for A behaviour may include internal actions. The actions that actually take place are restricted by the environment in which the object is placed. NOTES 1 The c
43、omposition (see 9.1) of a collection of objects implicitly yields an equivalent object representing the composition. The behaviour of this object is often referred to simply as the behaviour of the collection of objects. 2 Action and activity are degenerate cases of behaviour. 3 In general, several
44、sequences of interactions are consistent with a given behaviour. 87 State (of an object): At a given instant in time, the condition of an object that determines the set of all sequences of actions in which the object can take part. Since, in general, behaviour includes many possible series of action
45、s in which the object might take state does not necessarily allow the prediction of the sequence of actions which will actual ly occur. knowledge of 4 ITU-T Rec. X.902 (1995 E) ISO/IEC 10746-2 : 1996 (E) State changes took part. Since an object is encapsulated, its state cannot be changed of the int
46、eractions in which the object takes part. are effected by actions; hence a state is partially determined by the previous directly from the environment, but only indirectly as a result in which the object 88 Communication: The conveyance of information between two or more objects as a result of one o
47、r more iiteractions, possibly involving some intermediate objects. NOTES 1 Communications may be labelled in terms of a cause and effect relationship between the participating objects. Concepts to support this are discussed in 13.3. 2 Every interaction is an instance of a communication. 89 . Locatio
48、n in space: An interval of arbitrary size in space at which an action can occur. 8.10 Location in time: An interval of arbitrary size in time at which an action can occur. NOTES 1 The extent of the interval in time or space is chosen to reflect the requirements of a particular specification task and
49、 the properties of a particular specification language. A single location in one specification may be subdivided in either time or space (or both) in another specification. In a particular specification, a location in space or time is defined relative to some suitable coordinate system. 2 By extension, the location of an object is the union of the locations of the actions in which the object may take part. 8.11 Interaction point: A location at which there exists a set of interfaces. At any given location in time, an interaction point is associated with a location in space, within the
