All comments below are technical, unless otherwise stated.
a)In current form, the enterprise language concepts do not adequately support language developer and system interoperability support needs. Both the scope of terminology and the advisory text for the use of the terminology are lacking.
b)The last meeting did not finish comments on behaviour modelling.
c)The last meeting did not quite finish discussion on the difference of role and role type, the need of role cardinalities etc.
d) The lack of policy framework and the lack of adequate statements on the structuring of constrants, population/assignment rules, and behavaviour requirements is a severe drawback for the usability of this standard. We regret of being unable to contribute to those areas this time, but are willing to continue work on those areas.
The population process of the communities is not clearly enough presented. Especially clause 7 totally misses the concept of population policy for object to fulfil roles. Role itself defines the behavioural aspects of the selection criteria, but non-behavioural aspects (such as policy parameters) should be present too.
The audience of this document is threefold: language developers, specifiers (i.e. language users), and specification users (users of tools based on the language, laymen).
The language should support system analysis, system design, and system interoperability services at the time of system exploitation.
Yes, one of the usages for enterprise language is to give basis for formal specification. From this, different presentation forms can be derived, or a mapping to existing presentation forms like UML can be given.
Suggested text for the clause:
A key objective of this prescription is to provide the commonly used concepts and underlying principles of system analysis and design and system interoperability services to the modelling framework of the RM-ODP. There are many modelling methods and approaches used for understanding, agreeing and specifying systems in the context of the organisations of which they form a part. Many of these approaches fall into the categories often referred to as analysis or requirements specification. The enterprise language provides the vocabulary and constructs to specify the purpose, scope and policies for an ODP system in terms that are meaningful for the stakeholders of that system, in such a form that the specification can be used either as an introduction of existing services or as a template for creating a new service. An enterprise specification describes the behaviour of the system within the environment with which it interacts. Such an environment can be a technical environment (e.g., the software and hardware environment of a service component) or a social or business organisation (e.g., a group of co-operating companies, a particular service inside a system).
One of the usages for the prescribed ODP enterprise language is to give basis for formal specification. From this, different presentation forms can be derived, or a mapping to existing presentation forms can be given. Many of the current methods can provide useful insights into both the organisation under consideration and the requirements for systems to support it, however many lack the rigour, consistency and completeness needed for formal specification.
An enterprise specification of an ODP system is an abstraction of the system and a larger environment of which the ODP system form a a part, describing those aspects that are relevant to specifying what the system is expected to do in the context of purpose, scope and policies of that environment (technical, organisational). It describes the behaviour assumed by those who interact with the ODP system. It explicitly includes those aspects of that environment that influence the behaviour of the ODP system - environmental constraints are capture as well as usage and management rules.
An enterprise specification aims for supporting agreements on either one or both of the two involved levels: system supply level and system interoperation level. At the system supply level, the enterprise specification supports an agreement (for example, as part of the contract for supply of a system) between the potential clients of the ODP system and the provider of that system. Both parties should be able to write, read and discuss such a specification, the clients to be sure of the expected behaviour of the system that they will get, and the provider to be clear about the behaviour to be realised by the system being provided. Thus, two types of presentation of the enterprise specification may need to be considered for the same system - one to provide a view in terms that are understood by the clients, and a second in terms more directly related to the system realisation. At the interoperation level, the enterprise specification supports a framework that can be used for controlling interoperation and federation of cooperating, autonomous ODP systems. The specifications help in integration of legacy systems and objective-driven building of new cooperative systems.
Suggested phrase: this prescription of ODP enterprise language.
Replace by a normal text sentence: "The group of concepts below is not restrictive."
Add: "These concepts can be used as abstraction tools for specifications
to express the focus of interest and requirements for entities under
discussion."
NOTe: For example, the same entity can be modelled as an actor, as an
artefact or as a resource, depending on the intent and scope of specification.
Replace "< s > community" by "Implicit community".
Replace "system is represented" by "system can be represented".
Add: Whether the specification actually includes that level of
abstraction
is left for the specifier and specification tools to decide.
Community representative object: A composite object, the component objects of which are the members of a community and which object is used to model participation of that community as a whole in the behaviour of another community.
A process specification ...
Replace "participates" by "initiates" or at least "performs".
To our understanding, "initiates" have been accepted at least
in two earlier meetings, and keeps dropping out in spite of
the technical difference.
The style of specification we have used uses actor roles with respect of the community and itemises artefact roles with respect to each individual action.
We suggest that only the terms actor and artefact were defined, and additional sentences are used to explain that there is a need to indicate whether the use is with respect to an action or with respect to a community. Each specification should be consistent in the chosen style, but the choice rests with text organisation decisions within individual tools that help in composing enterprise specifications.
It may be helpful to have this concept. Violation may cause failure, but the contract may also include violation recovery behaviour for the community, in which case a failure (= a state requiring undefined behaviour) is not reached. In addition to defining violation, we should consider concepts of penalties or sanctions.
This clause seems to miss concepts of delegation withdrawal.
Only one of these is needed; delete 6.5.4.
Add title "Role concepts" and collect 6.4.2-6.2.11, 6.4.2 and 6.4.3 under it. Move 6.2.1. to 6.1.
The pair of names agent and principal are good enough and should not cause any confusion.
Replace by "An action involving one or more parties or agents."
Replace "is bound" by "becomes bound".
Add new para:
"A complete ODP system specification is required to indicate
rules for internal consistency in terms of relationships between various
viewpoint specifications. Furthermore, a complete enterprise
specification contains conformance rules that define the
required behaviour of the described ODP system, thus separating out
the parts of the specification included for the purposes of
analyse, understandability and communicatability of the specification."
Rationale:
The document is not clear in describing the possible relationships between communities, nor in describing the possible relationships between roles.
The relationships needing identification must include
Suggestions:
"An enterprise specification can describe several communities.
These communities may form an interaction relationship in various ways:
Note: Partitioning may be done because of readability, reuse of specification fragments or interoperability of enterprise objects.
Note: When the subcommunity representing object populates the role in the larger community, the subcommunity becomes governed by the policy rules of the larger community. NOTE: The population process can be late and dynamic, i.e., a role can be fulfilled by a composite representative object through a match-making process that considers the subcommunity policies, interacting capabilities, interfaces and behaviour description with respect to the requirements stated for the role in the larger community.
Note: For interaction between the communities to be meaningful, there must be some element of shared objective and a common set of policies will apply. This consensus can be formed either at design time and included into the community specifications or left for run-time negotiation or more straightforward testing of acceptability during community population.
Note: The communities involved may have differing policy rules all of which the enterprise object should be able to conform to.
In the production of enterprise specification community and role specifications can be textually partitioned and partitions reused.
NOTE: The role and community specifications, as well as type and template specifications, can be private to a specification and development environment, or they can be stored to a repository that can be shared by a wider audience of several development environments and groups.
Add: "Communities of these types can be specified so that they overlap totally or partially. These basic community types do not imply any hierarchical relationships. A specification may choose to use some or none of these community types.
NOTE: For example, Internet forms a technical domain that is controlled by the standardization organisation responsible for Internet protocols, while the owners of communication connections and computers in Internet each have an ownership community comprising of a set of equipment."
The definition is correct but laborous to read. (Note layout should be corrected.)
Continue: ... for designers.
Add to the end: "< x > controllers may declare their policies amongst themselves and commit their controlled community to some contract but cannot prescribe policies on each other's controlled communities. "
The owner may either prescribe policies of the community or delegate an authorisation to do so to an agent. This authorisation may also be withdrawn.
Replace "assigning by an enterprise objects" by "assigning by enterprise objects".
We would prefer to see that paragraph in clause 7.5.1.
Replace "such changes" by "creation or deletion of roles".
Keep type, may add a note saying template is a special case.
Terminating behaviour in P2 13.2.5 is sufficient.
Add: "The community behaviour includes a termination behaviour that is triggered by some state.
Note: For instance, a violation may be associated with a recovery behaviour, which may be chosen to be the termination of the community."
Correct the inconsistent use of singular and plural forms of "objective".
Delete the sentence.
Replace "An enterprise object fulfilling a role has the objective of the role." by "An enterprise object populating a role adopts and adapts to the objective of the role."
The group has several times agreed on using words initiate an action or perform an action instead of participate in an action. This change keeps popping up without clear (or even written) rationale.
Rewrite:
The behaviour of a community defines what the community should be observed to do and consists of a number of expected activities. The behaviour defines the possible restrictions on ordering of the activities.
Notes 1: The behaviour of the community includes interactions of the community, views as a composite object, with its environment. The behaviour may also include interactions internal for the community.
2: There are many specification styles for the ordering of actions. The modelling language chosen for expressing an enterprise specification may impose certain styles.
The assignment of actions to the enterprise objects that comprise the community is defined in terms of roles. A role identifies a projection of the community behaviour that comprises a set of activities that is assigned to a single enterprise object within the community. Each projection is lagelleed as a role. The emphasis is on at what kind of enterprise objects participate in the particular activities.
Role behaviour decomposes the behaviour of the community into roles that can each be performed by an enterprise object in the community. The enterprise object that performs the role behaviour is said to fulfil that role within the community.
NOTE: In case of an internal interaction within the community, an action is referred to in all roles involved to that piece of collective behaviour.
A process identifies a projection of the collective behaviour of the community that relates to achieving a particular result/purpose/sub-objective within the community. Each projection is labelled with a process name the emphasis is on what the behaviour achieves.
Process behaviour decomposes the collective behaviour of the community into processes, parts ow which can be performed by different enterprise objects in the community. The process naturally enforces partial sequencing of actions.
NOTE: Each process will involve at least part of at least one role behaviour, but can involve parts of may role behaviours.
The choice of which approach to use will depend on the modelling method used and the aim of modelling; it is possible to use combination of both. As a minimum, the roles of the enterprise objects in the community shall be specified. If the process-based approach is used as well, it shall be in accordance with the rules for the specification of processes given in 7.7.4.
delete
Replace:
When an enterprise object is assigned to a role, the types of the object
should not contradict with any of the role types involved, unless the
specification includes mechanisms to determine and resolve such
inconsistencies, for example, by intercepting and transforming or
filtering some of them object features.
delete
Rewrite:
An enterprise specification comprises of a community modelling and ODP system and some additional roles for objects in the environment of that community. Objects of a community typically interact with objects outside the community to achieve the objective of the community. When these external interactions are identified by roles there are two modelling choices. On one hand, the peer roles for these interactions can be specified in another community. In this case the environment roles are not necessarily fully specified, but prescribe only the essential behaviour and policies for interaction with the core community. On the other hand, the community can be modelled at a level of abstraction where the ODP system is represented as a single community representative object and all other roles represent objects in its environment. The community representative object can be further refined as a separate community specification.
On line 40, replace "responsibilities"
by "obligations, prohibitions, permissions and authorisations".
On line 41, replace "complete descriptions of all actions"
by "descriptions of all required actions.
Remove editor's notes.
Replace steps by actions.
In note 2, first sentence change "abstraction of the behaviour" to "abstraction of the collective behaviour".
Add note 3: Action can be an interaction within the community.
In some cases, a relevant spontaneous state change
may need to be modelled as an interaction in the role behaviour
and in the process description involved.
(Rationale: the state change is a requirement for the
object fulfilling that role and thus is not an internal matter only.
Therefore, the modeller does not really have the choice
of using an internal action here.
Allowing internal actions of enterprise objects in the
role descriptions would make the specifications infeasible large
and restrictive.)
Replace "the results of actions" by "The sequence of actions".
There cannot be any relevant interactions within the community or between the community and its environment that are not mentioned in the roles. That does not cover all behaviour of the objects involved with the community; those objects have internal behaviour and additional interactions related to other purposes than to the objective of the community under specification.
No need to have these separately; 7.7.4.2 just repeats things in 7.7.1. Remove 7.7.4.2.
Clause needs restructuring, currently repetitive and non-focused. Compare to material in 7.10.
More detailed suggestions to be provided!
Replace by:
A community specification contains policy rules that express constraints on the behaviour of the objects fulfilling roles. The specification may also contain non-behavioural rules for populating roles with objects.
The community policies can be either explicitly defined (in the simplest form, enumeration of fixed policies) within the community or induced on the community (or community representing object that fulfils a role in a larger community) when joining a larger context to operate in.
The enterprise specification must indicate the possible nesting of communities and thus all the policy rules governing the behaviour of the enterprise objects fulfilling roles in a community.
The enterprise specification must also indicate whether possible dynamic changes in policy rules of the community (for instance, caused by federation negotiations) should be enforced on subcommunities or peer communities.
Thus, the policies that apply to community members are affected by at least the following events:
Remove relinquishing, it is not defined. Remove editors note. Compare with clause 7.4.3.
Remove lines 22-23.
Replace "prohibitions and obligations" by "prohibitions, obligations and authorisations" on line 24.
It would be appropriate to add the suggested style of discussion on other components as well.
Replace "can take part in" by " may take part in".
(Editor suggestion is also better than the current wording.)
The enterprise specification must indicate the possible nesting of communities and thus all the policy rules governing the behaviour of the enterprise objects fulfilling roles in a community. An enterprise object must conform to all policies in all communities it participates.
The enterprise specification must also indicate whether possible dynamic changes in policy rules of the community (for instance, caused by federation negotiations) should be enforced on subcommunities or peer communities. A community may require that the peer communities cooperating with it follow the same method of adopting dynamic changes to policies as it itself follows.
Note: In practice, this currently means static policies in each community, but a composite representative object may inherit its policy requirement from several outer communities.
By default, each community should enforce the policies prescribed within it.
Relabel "Policy violations".
Rewrite in a tone where each breach of a policy is a violation and there either is or is not a recovery procedure for such a violation prescribed for the use within the community.
More importantly, there should be some text with respect to policy violations leading to breach of the contract between the community and its environment.
The spot would also be good to insert something about failures caused in cases where one agent is obliged to do something that is actually prohibited to happen. Such cases appear easily for instance in federations.
Text to be provided!
Replace "An enterprise object is any object in an enterprise specification." by "An enterprise object is any object in an enterprise specification or any object fulfilling the requirements set for an enterprise object by an enterprise specification."
Move to 7.5.2 after the bullet list.
Move either to 7.11 or 8, before "8 compliance".
Relabel "Conformance".
Rationale: Reference points cannot be
defined within one viewpoint only.
Add text:
" a complete enterprise
specification contains conformance rules that define the
required behaviour of the described ODP system, thus separating out
the parts of the specification included for the purposes of
analyse, understandability and communicatability of the specification.
The conformance rules name the set of objectives and policies that form the conformance requirements. These statements are used in establishing reference points (defined in Part 3) and testing of system design or implementation conformance against this viewpoint specification." "
Delete or rewrite to match the prescriptive text. We prefer removal.