The United States proposes that the title of the new work item be changed to:
The United States proposes the adoption of a program of work which proceeds sequentially through each of these steps, as the preceding step is completed:
1.1 Build a repository of technical submissions that covers the work needed for a proposed new international standard; and clarifies and documents all differing opinions.
1.2 Prepare a working document listing the candidate concepts for the enterprise viewpoint language; and making explicit the intuition underlying the concepts.
1.3 Obtain consensus among the delegates of the national bodies on the candidate concepts; and on the intuitive understanding of the concepts.
1.4 Begin preparation of a working document for the committee draft of the proposed new international standard refining or clarifying, if necessary, existing RM-ODP concepts; providing precise definitions of the new concepts; and explaining the relationship of an enterprise specification of a system to other viewpoint specifications of that system.
The following comments are addressed to clause 2. Rationale, of the Outline for Draft New Standard in the KC EL 06 attachment to ISO/IEC JTC 1/SC 21 N 10387 Rev. 1. They are intended not so much as proposed text for this section, but rather as input to the formulation of such text, or as constraints on such text.
There is frequently a tension in specifications between the need for precision (and the corresponding need for technical specification methodology and concepts) on the one hand, and the need for domain experts (rather than specification language experts) to be able to use such specification concepts in developing specifications (and the need for other domain experts to be able to understand specifications produced in this way).
This would appear to be a particular issue in the case of Enterprise Viewpoint specifications. According to RM-ODP Part 1, "The aim of an enterprise specification is to express the objectives and policy constraints on the system of interest." (Clause 8.2 - Enterprise Language). To satisfy this requirement, it is highly desirable that the enterprise specification be developed to the greatest extent possible by business/enterprise experts, rather than by experts in specification techniques. It is even more desirable that the enterprise specification be understandable by business/enterprise experts (particularly those who did not write the specification, but who may need to read it) with a minimum need for translation by specification experts. The following quotations seem to reflect the same general idea:
"The enterprise language new work item addresses three main areas...[the first of which is] refinement of the enterprise language to ensure that its use as a standard will aid mutual comprehension of system specifications by users and implementors." [UK96].
"Business rules are to be specified in a manner understandable to business domain experts, as well as requirements specifiers and system designers and developers." [KI96], p.3.
"Business system users view the Enterprise Framework as a way of defining their key business activities in business terms along with the collaboration of those activities. The framework specifications act as a bridge between the view of the business users and the perspective of provisioners that provide solutions to meet those needs." [TI96], p.6.
If the enterprise viewpoint specification is to be mutually understandable by business domain experts as well as requirements specifiers, a great deal of care must be exercised in the development of the enterprise viewpoint language, for example, to ensure that, to the greatest extent possible:
For example, terms defined in Part 2 and Part 3 must be carefully examined to see that their meanings as defined in those parts do not clash with their ordinarily-understood business meanings (or specialized terms must be developed instead).
This overall goal does not preclude the use of formalism and precision in the enterprise viewpoint language. Business domain experts frequently deal with formalism, precision, and highly specialized language in their own domains (law, accounting, etc.). However, the notation and terminology of the language should be such that it can be learned by a reasonably intelligent business domain expert without a great deal of specialized training, and directly employed by such a domain expert with a minimum amount of specialized assistance, at least at the initial stages of specification. [MA96]
The following comments are addressed to clause 3. Enterprise Language Refinements, of the Outline for Draft New Standard. They list and briefly discuss enterprise language concepts. Some of these are concepts included in RM-ODP Parts 2, 3, and 4, which may benefit from further refinement. Others are new concepts.
One of these new concepts is referred to in this document by the name, business rule. Annex A (Document X3H7-96-07-R2) of this document describes in more detail how business rules may be represented in the specifications of the enterprise viewpoint of RM-ODP, and shows several examples, including an example of a contract. It reuses concepts and constructs from RM-ODP, Parts 2, 3, and 4, as well as from the ISO General Relationship Model [GRM], and from other sources.
Many concepts and constructs reused in Annex A have been specified in existing ISO standards (such as RM-ODP and GRM); nevertheless, they may have to be amplified, refined, and perhaps in come cases explicitly redefined in order to apply to the enterprise viewpoint of RM-ODP. Specifically, a community (RM-ODP Part 3, Clauses 5.1 and 5.2) may be determined by its business rules - most importantly, by the invariant that determines those fundamental properties of this configuration of objects which remain unchanged by any operation (action) applied to this configuration at the same abstraction level. This invariant is preserved during the lifetime of the community (by all existing and possibly new actions). Both the invariant that defines the community, and other properties of the community (such as definitions of operations applicable to the configuration of community objects, as well as definitions of roles and policies) may be considered to be business rules.
The following modelling concepts have been suggested by US contributors as candidates for refinement:
composition of behavior
The following modelling concepts have been suggested by US contributors as additions:
The following modelling concepts have been suggested by US contributors as possibly needing correction:
The following concepts have been suggested by US contributors as additions to the enterprise viewpoint language:
The following concepts have been suggested by US contributors as candidates for refinement:
These additional concepts are discussed in Annex A:
US contributors have asked the US delegates to request suggestions from others for how best to obtain precision in a metamodel. Graphical techniques, while a useful adjunct, do not in themselves constitute a sufficiently precise metamodel.
The following terms are used from ISO/IEC JTC1/SC21, Information Technology - Open Systems Interconnection - Management Information Systems - Structure of Management Information - Part 7: General Relationship Model, ISO/IEC 10165-7, 1995.
general composition relationship
The US believes that the relationship to other viewpoints is an important work area, but has not contribution at this time.
The meeting in Kansas City adopted this statement of work:
"Refine the enterprise language, explicating the relationship of an enterprise specification of a system to other viewpoint specifications of that system, so as to enable the RM-ODP to be used for specification of object-based applications architectures.
"Ensure that the enterprise language together with the other viewpoint languages is suitable for the specification of a concrete application architecture to fill a specific business need.
"The measure of success is a demonstration of the use of the viewpoint languages to specify a concrete application architecture."
The ballot for the new work item says (if the rewording suggested by the United States is applied):
"There exists a clear need to describe how the viewpoint languages are used together for creating application architectures. This description should be based on existing RMODP definitions in IS 10796-2 as refined by IS 10796-3 and the new concepts and constructs defined for the new enterprise viewpoint." [N10387-1]
To ensure a common understanding, it is necessary to define the concept, application architecture.
From RM-ODP we have: "architecture (of a system) a set of rules for the structure of the system, expressed in terms of the parts of the system and their interrelationships." [ODP2]
From a recent work on software architecture we have: "…software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components." [SG96]
If there is general agreement within the Rapporteur Group on the intuitions suggested by these definitions, we should be able to quickly agree on a definition of application architecture.
This section offers another approach to an intuition of application architecture.
1. Determine purpose and scope of system, and the policies that govern it. [enterprise viewpoint]
2. Prepare an object model of the business, or that part relevant to the system. This object model will be organized into subsystems, groups of objects which work together. This model must serve the purpose of, conform to the scope of, and follow the policies that govern the system. [information viewpoint]
The traditional concepts of cohesion and coupling are used to find the best division into subsystems. The difference in object technology is that it is coupling and cohesion among objects of a subsystem that is considered; traditionally a functional decomposition was used.
3. Prepare another model which is composed of subsystems which are sufficiently independent that they are suitable candidates for distribution. Map the subsystems in the object model to subsystems in this distributable model. (The two models may be very similar or quite different. A class in the object model may map to one or more classes in the distribution model; likewise, more than one subsystem in the object model may map to a single system in the distributable model, though this is unlikely.) [computational viewpoint]
Concepts very similar to cohesion and coupling are used here also, but the concern is with patterns of communication among the distributable subsystems. The volume of comm