ISO/IEC 15414:2015 情報技術—オープン分散処理—参照モデル—エンタープライズ言語 | ページ 7

6.1.1

スコープ（システムの）

システムが示すと予想される動作。

6.1.2

適用分野（仕様の）

ODP システムの環境のプロパティは、使用するシステムの仕様を持たなければならない。

6.2.1

objective (of an <X>)

Practical advantage or intended effect, expressed as preferences about future states.

Note 1 to entry: Some objectives are ongoing, some are achieved once met.

Note 2 to entry: In the text of Rec. ITU-T X.903 | ISO/IEC 10746-3 [Part 3-5] the terms purpose and objective are synonymous. The enterprise language emphasizes the term objective and emphasizes the need to express an objective in measurable terms.

6.2.2

community object

A composite enterprise object that represents a community. The components of a community object are objects of the community represented.

6.3.1

active enterprise object

An enterprise object that is able to fill an action role. In other words, it is an enterprise object that can be involved in some behaviour.

Note 1 to entry: The behaviour of active enterprise objects is constrained by deontic and accountability concepts, defined in clauses 6.4 and 6.6. The deontic tokens defined in clause 6.4 are not themselves active enterprise objects.

6.3.2

actor (with respect to an action)

A role (with respect to that action) in which the enterprise object fulfilling the role participates in the action. That object may be called an actor.

Note 1 to entry: It may be of interest to specify which actor initiates that action.

6.3.3

artefact (with respect to an action)

A role (with respect to that action) in which the enterprise object fulfilling the role is referenced in the action. That object may be called an artefact.

Note 1 to entry: An enterprise object that is an artefact in one action can be an actor in another action.

Note 2 to entry: The object filling an artefact role in an action is an active enterprise object being referenced in the action and this should not be confused with the way a deontic token held by an object involved in the action constrains its performance.

6.3.4

resource (with respect to an action):

A role (with respect to that action) in which the enterprise object fulfilling the role is essential to the action, requires allocation, or may become unavailable. That object may be called a resource.

Note 1 to entry: Allocation of a resource object may constrain other behaviours for which that resource is essential.

Note 2 to entry: A consumable resource object may become unavailable after some amount of use. Any resource object may become unavailable after some amount of time (for example, if a duration or expiry time has been specified for the resource).

6.3.5

interface role

A role in a community, identifying behaviour which takes place with the participation of objects that are not members of that community.

6.3.6

process

A collection of steps taking place in a prescribed manner.

Note 1 to entry: The prescribed manner may be a partially ordered sequence of steps.

Note 2 to entry: The activity structure concepts provided in clause 13.1 of Rec. ITU-T 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 3 to entry: A process may have multiple end points.

Note 4 to entry: An enterprise specification may define types of process and may define process templates.

Note 5 to entry: A process is an abstraction of a behaviour, and so shares any objectives defined for that behaviour.

Note 6 to entry: A process specification can be a workflow specification.

6.3.7

step

An abstraction of an action, used in a process, that may leave unspecified some or all of the objects that participate in that action.

6.3.8

violation

A behaviour contrary to that required by a rule.

Note 1 to entry: A rule or policy may provide behaviour which is to occur upon violation of that, or some other, rule or policy.

6.4.1

deontic token

An enterprise object which expresses a constraint on the ability of an active enterprise object holding it to perform certain actions. An active enterprise object carries a set of deontic tokens, which control the occurrence of conditional actions within its behaviour. These tokens are either permits, burdens or embargos. A deontic token is not itself an active enterprise object; it is held by exactly one active enterprise object.

Note 1 to entry: The constraint is expressed by a rule forming part of the token; an appropriate notation for expressing this rule will be selected by the specifier. The notation allows the declaration of the active enterprise object and conditional action to which it applies, and requirements on other enterprise objects fulfilling roles in the conditional action controlled. For example, the rule may control the performance of a purchase action by a consumer, and place restrictions on the supplier and the artefact being purchased. The notation may also declare periods of validity or deadlines for performance of the action. The kind of associated information allowed will depend on whether the token is a permit, a burden or an embargo.

6.4.2

token group

A group of tokens named so that it can be referred to as a whole.

Note 1 to entry: A notation for expressing deontic rules will provide the means for declaring and naming groups of deontic tokens. Changes that result, for example, from the performance of speech acts can then be applied to complete groups of tokens without the need to reference all the group members individually.

6.4.3

burden

A deontic token encapsulating the statement of an obligation on the active enterprise object holding it, thereby modifying the urgency of the active enterprise object in performing associated conditional actions within its behaviour.

6.4.4

embargo

A deontic token encapsulating the statement of a prohibition on the active enterprise object holding it, thereby modifying the ability of the active enterprise object to perform associated conditional actions within its behaviour.

6.4.5

permit

A deontic token encapsulating the statement of a permission on the active enterprise object holding it, thereby modifying the ability of the active enterprise object to perform associated conditional actions within its behaviour.

6.4.6

conditional action

An action which has associated preconditions based on the sets of burdens, permits and embargos carried by the active enterprise objects filling its various action roles. The specification of the conditional action states what permits are required for, what burdens favour, and what embargos inhibit performance of the action.

6.4.7

speech act

An action whose performance results in a change to the sets of deontic tokens (permits, embargos and burdens) carried by the active enterprise objects filling its various action roles. A speech act may result in the addition of new tokens to the performer of an action role, or in the removal of tokens from the performer of an action role, or the transfer of tokens from the performer of one action role to the performer of another action role in the same interaction.

Note 1 to entry: Many actions for which parties are accountable are speech acts; examples are prescription and commitment.

Note 2 to entry: Although we speak informally of a speech act as changing or transferring a token, it is more precise to describe this process as the destruction of one of the token existing before the act occurred and the construction of a new token based on the information available when the act is performed. The definition of the speech act type includes the formal rules governing the content and location of the token that is generated. Transfer of a token by a speech act is therefore the process of destruction of a token held by one of the participating objects followed by construction of a new token with the same contents at its destination.

6.5.1

policy

A constraint on a system specification foreseen at design time, but whose detail is determined subsequent to the original design, and capable of being modified from time to time in order to manage the system in changing circumstances. A policy is expressed as a rule, which may, in turn, be a composition of several sub-rules. A policy is introduced into a specification by a policy declaration. At any point in time it has a particular policy value, but the policy value can be changed by a defined policy setting behaviour, so long as it remains within a defined policy envelope. [See 2-11.2.8 to 2-11.2.12]

Note 1 to entry: A rule can be expressed as an obligation, an authorization, a permission or a prohibition. Not all the constraints involved restrict the behaviour; for example, some policies may represent an empowerment.

6.5.2

affected behaviour

A fragment of behaviour (including an action, step or process) that is constrained by the current policy value.

6.6.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 to entry: 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 to entry: Parties are responsible for their actions and the actions of their agents.

6.6.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 1 to entry: The enterprise objects 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 responsible for the agent becomes obligated.

Note 2 to entry: The fact that an enterprise object is obligated is expressed by associating with it a burden describing the obligation.

6.6.3

prescription

An action that establishes a rule.

6.6.4

authorization

An action indicating that a particular behaviour shall not be prevented.

Note 1 to entry: Unlike a permission, an authorization is an empowerment.

Note 2 to entry: The fact that an enterprise object has performed an authorization is expressed by it issuing a required permit and itself undertaking a burden describing its obligation to facilitate the behaviour.

6.6.5

declaration

An action that establishes a state of affairs in the environment of the object making the declaration.

Note 1 to entry: The essence of a declaration is that, by virtue of the act of declaration itself and the authorization of the object making the declaration or its principal, the declaration action causes a state of affairs to come into existence outside that object.

6.6.6

delegation

The action that assigns something, such as authorization, responsibility or provision of a service to another object.

Note 1 to entry: A delegation, once made, may later be withdrawn.

6.6.7

evaluation

An action that assesses the value of something.

Note 1 to entry: For example, the action by which an ODP system assigns a relative status to a thing, according to estimation by the system.

Note 2 to entry: 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.6.8

agent

An active enterprise object that has been delegated something (authorization, responsibility, provisionof a service, etc.) by, and acts for, a party (in exercising the authorization, carrying out the responsibility, providing the service, etc.).

Note 1 to entry: 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 of a party.

Note 2 to entry: 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.

Note 3 to entry: A specification may state that, in its initial state, an active enterprise object is an agent of a party.

6.6.9

principal

A party that has delegated something (authorization, provision of a service, etc.) to another.