From reading the Adopted Specification, it appears that the UML
Profile For MOF (chapter 6) is meant to be published as part of the
EDOC specification.

I believe that this is a mistake: since it defines a notation of MOF
metamodels, it should be part of the MOF specification.

Document: UML Profile and Interchange Models for EAI
Section: 6.2.5 (EAITerminal)

Description:
The representation/parameter association is marked as <<derived>> in Figure 6-6, however no clear description is given on how it is derived.

Recommendation:
I think the intent is that the terminal represents an FCMParameter of an operation associated with the FCMNode to which the terminal is attached. However, given the associations and navigabilities shown in Figure 6-2, this really cannot be done as a single constraint. Instead, it needs to be done as separate constraints on each kind of FCMNode:

FCMFunction:
An FCMFunction has FCMTerminals that represent each of the parameters of the FCMOperation invoked by the FCMFunction.
(self.interface->select(terminalKind = #in).parameter = self.invokes.inputs) and
(self.interface->select(terminalKind = #out).parameter = self.invokes.outputs) and
(self.interface->select(terminalKind = #fault).parameter = self.invokes.faults)

FCMSource:
An FCMSource has a output terminals that represents the input parameters of the operation implemented by the FCMSource. (Note that a source has OUTPUT terminals, but these terminals represent the INPUT parameters within the composition that implements the operation.)

(self.interface->forAll(terminalKind = #out)) and
(self.interface.parameter = self.implements.inputs)

FCMSink:
An FCMSink has a single input terminal that represents a single output (or fault) parameter of the operation implemented by the FCMSource associated with the FCMSink. (Note that a source has an INPUT terminal, but this terminal represents an OUTPUT parameter within the composition that implements the operation.)

(self.interface->size() = 1) and (self.interface.terminalKind = #in) and
self.source.implements.outputs->union(self.source.implements.faults)->includesAll(self.interface)

Document: UML Profile and Interchange Models for EAI
Section: 6.2.3 (Composite nodes)

Description:
The constraints seem to imply that the implementingComposition association is computed by navigating from FCMCommand to its "performedBy" FCMComponent, then from that to the "instanceOf" FCMType, then from that to an FCMCompositionBinding, and, finally, from that to the FCMComposition. Unfortunately, the association between an FCMCompositionBinding and an FCMType is unidirectional and not navigable from the FCMType back to the FCMCompositionBinding (see Figure 6-1). Further, there may be multiple FCMCompositionBindings for any FCMType (each FCMCompositionBinding is between one FCMType and one FCMComposition, but the model allows more than one binding), so it is not possible to identify a unique, single implementingComposition for an FCMCommand anyway. (Note that this problem becomes immediately apparent if you try to write the constraint in OCL.)

Recommendation:
If you really want to require each FCMCommand to have an optional "implementingComposition", then I don't think this can be a derived association. And even if you want to constrain the "implementingComposition" to be selected from SOME relevant composition binding, then you need to provide the context for the set of composition bindings to search (or you could use FCMCompositionBindings.allInstances, but this is ugly).

Document: UML Profile and Interchange Models for EAI
Section: 6.2.1 (Motivation)

Description:
The last paragraph of this section (beginning "Note that these derived associations...") is not entirely clear to me. I believe that the intent is the following:

Derived associations are included in the metamodel and result in corresponding generated elements in the DTD. However, derived associations can always be computed from other information in the metamodel. Therefore, a tool would not necessarily need to store derived associations internally, though it would effectively have to compute them if it generated XML for interchange.

Recommendation:
Reword the paragraph along the lines of what I wrote above. Also, be sure, to include the appropriate constraint for every derived association to define how it can be computed.

relates to EAI issue: 5367)
The UML profile for MOF needs to say how the UML <<enumeration>> maps to a
MOF enumeration.

Section 6.2.4: the Constraints listed are not constraints but definitions of the derivation (which it is useful to have expressed).

Summary: Figure 6-4: The diagram is misleading and the actual derivation needed (which is hinted at under Constraint but should be more formally defined as in 6.2.4) would seem to rely on non-navigable references in the FCM metamodel: the new derived 'implementingComposition' association would not be based on the 'nodes' association shown between FCMComposition and FCMNode: this is already inherited by FCMCommand and shows where it is included into other 'larger' compositions. The new 'implementingComposition' reference to FCMComposition can, as far as I can see looking at FCM, only be derived from the following list of reference navigations: FCMCommand.performedBy (giving FCMComponent); FCMComponent.instanceOf (giving FCMType); FCMType.compositionBinding (giving FCMCompositionBinding - however this is not navigable!); FCMCompositionBinding.composition (finally giving FCMComposition). An alternative route is to follow FCMCommand.invokes (giving FCMOperation); FCMOperation.type (giving FCMType though this is not navigable) and then navigating from FCMType as above. [One would hope that both navigation routes would give the same FCMType though this constraint is not documented in FCM, nor is any description provided there for FCMType!].

It's not explained clearly what is in the PubSubNotice and what is in
the EventNotice. i.e. a bullet list of data to be included in an
EventNotice is given on page 227, but some of this may be included in
every PubSubNotice (EventNotice's supertype). Both of these types are
simply Attribute collections (CompositeData). 4.2.2.4 "EventNotice"
gives no information about how this information is transmitted.

Also: 4.2.2.4 "Related Elements" also wrongly includes inheritance.

Suggested Resolution: Clarify what data is included in a PubSub notice,
and what is only in its subtype, EventNotice, and how. (In 4.2.2.4)
Perhaps we even need some specific attributes to standardise the names
and types of the data that are given in the bullet list of pg 227.

To make DataEvent useful we need a relationship to the Attribute within
the CompositeData that changes to create this event.

Also: under "Related Elements" Business Event is listed - which is a
base Class - not related via association, which is what this section is
for. Conversely the "lifeCyle" association to EventBasedDataManager shown
in Fig 46 is not documented.

Suggested Resolution: Add an association to Attribute which indicates
which Attribute value change caused the DataEvent.

Also: Explain the lifeCycle relationship to EventBasedDataManager. I
imagine that this means that a DataEvent is generated when an
EventBasedDataManager is created or destroyed.

It is not clear whether the EventCondition guarding a NotificationRule
needs to be satisfied before or after the NotificationRule Condition
Expression, or whether it is simply an AND relationship with no ordering.

Also, as the guardedBy association has 0..n multiplicity at the
EventCondition end, there needs to be text explaining how multiple
guards are treated. The text currently says that "one or more
EventConditions calling for the receipt of additional events before
this NotificationRule will 'fire' successfully". Are there time bounds
on the receipt of these additional event notifications? Do all guards
'reset' once the NotificationRule'fires'?

Suggested Resolution: Guard(s) should be satisfied first. Add text to
Section 4.2.2.7 "Related Elements - EventCondition" stating that the
EventCondition(s) associated with the NotificationRule by the guardedBy
Association must be satisfied before the NotificationRule's Condition
is evaluated.

Also: some text suggesting a timeout mechanism that could be included
in the condition expression of the guarding EventCondition.

Chapter 3, Figure 46, pg 236

Association between EventNotice and BusinessEvent labelled "describes/
describedBy" is not explained in the text, and insufficiently explained
in the BusinessEvent Class desciption.

Suggested Resolution: add text to explain this Association. text should
say ????

The text says "A NotificationRule governs the entry into or exit from
one Node (or the exit from one and entry into another, i.e. 2 Nodes)"
How is one to dertermine which of these 3 options is to be used? The
multiplicity on the Node end of the governs association is 1..2, so we
can assume that the 3rd option applies when there are 2 links... but
when there is only 1 link, which is it?

Suggested Resolution: Add a new association with roles "governsExit/
exitGovernedBy" with multiplicity 1 at the Node end, and 0..1 at the
NotificationRule end. Change the existing governs/governedBy
association to be "governsEntry/entryGoverenedBy" with multiplicity 1
at the Node end, and 0..1 at the NotificationRule end. The 3rd case
should be modelled as a NotificationRule governing a Transition between
Nodes.

There is a black diamond (containment) association in each diagram that
has a 0..n multiplicity at the diamond end (they depict the same
offers/offeredBy association between Publishers and Publications in each
case). This is a contradiction as no object can have n containers.

Suggested Resolution: Remove the diamond, as it should be possible to
share a Publication between Publishers.

The use of ProcessRoles is under-specified.

1. Specifically, there is no description of how data received by
ProcessPortConnectors is made available to a ProcessComponent instance
bound to a Performer ProcessRole. This is especially problematic for
Performer ProcessRoles since this is where the model should "bottom
out".

2. Additionally, there is no description of how a ProcessComponent
instance bound to an Artifact or ResponsibleParty ProcessRole is made
available to its Activity's ProcessComponent instance.

Suggested Resolution:

1. Add text describing how one can use a Connection to connect a
ProcessPortConnector of an Activity to a PortUsage of a (Performer)
ProcessRole.

2. Add text describing how a PropertyValue can be attached to an
Activity with a "value" Expression referencing an associated Artifact
or ResponsibleParty ProcessRole and its "fills" association pointing
at an appropriate PropertyDefinition of the Activity's ProcessComponent.

"Related Elements" wrongly includes inheritance (it is inconsistent
with how the rest of ECA is documented).

Suggested Resolution: This should be removed in all subsections of 4.2.

Section 6.2.3, figure 4: The initial statement "the composition method in the FCM is to construct an FCMCommand from an FCMComposition" would be better worded "the hierarchical composition method". FCM does not require that FCMCommands will themselves be defined through compositions.
Resolution:

Section 6.2.1: the Motivation should state why FCMCommand has been chosen as the primary 'composite node' element from FCM (as opposed to FCMComponent for example which seems a more obvious match). According to EDOC "An FCMCommand is a special kind of FCMNode that represents the invocation of a particular FCMOperation on an FCMComponent. An FCMCommand can be thought of as being analogous to a programming language statement that invokes a method on an object".

Section 6.2.1 claims that no additional constraints are introduced to FCM. This is not true: such a constraint is introduced in 6.1.3 (it in effect constrains certain instances of FCMType to have only one FCMCompositionBinding which is not required by FCM

Chapter 3 "ECA", Section 4.2.2.3 "Data Event"

How does one denote which attribute in the Data the event is related
to, and when it was triggered?

Suggested Resolution: Need an association to Attribute???

The text is missing a description of the metaattributes in the model
diagram: entry: boolean, success: boolean. Also may need some
constraints.

Suggested Resolution: ????

Section 6.2.5: Should define the derived association via existing references.

The profile uses documentation tag for MOF annotations - it would be
more straightforward to use instances of Comment class for that purpose
(or allow both), as that's what most UML tools I know of uses.

The profile does not state, which revision of UML it is applicable to.
It seems that it can be used with UML 1.3 (since in AssociationEnd
mapping, "type" reference is used - this reference was renamed in UML
1.4 to "participant"). I think it would be better to support newer
revisions of UML (1.4 and 1.5).

The latest adopted MOF revision is 1.4. However the profile is based
on MOF 1.3 and thus it does not define a straighforward mapping for
CollectionTypes, EnumerationTypes, PrimitiveTypes, etc

Tag for multiplicity is introduced for Parameters, however in UML 1.4
multiplicity on parameters is natively supported.

Raised exceptions are supposed to be linked via raisedSignal reference
to operation. However, as I already wrote in one of the previous
issues, Exception and thus also the raisedSignal reference is not
supported in Class diagrams by most of the tools. Different way of
modeling raised exceptions would make it usable

MOF Import can be represented by UML ElementImport. Again, I was not
able to use ElementImport in UML tools I know of. Different element
should be used to represent MOF imports.

Package subtyping is handled by a standard generalization.parent
reference however many UML tools do not support package generalization -
it should be modeled differently (e.g. using a stereotyped dependency)

While the profile allows MOF Packages to be represented by UML Models
only, UML Models are not supported by some existing UML tools -
representation using UML Package would be better. Also
org.omg.uml2mof.clusteredImport tag is introduced for clustered imports
declarations. This can be solved more nicely without introducing a new
tag (e.g. by a dependency stereotyped <<clustering>>)

The profile uses UML Exception to represent MOF Exceptions. From my
experience, modeling exceptions in class diagrams is not supported by
tools that I know of - mapping to a different element should be considered

There is no way of creating derived associations (isDerived tag should
be added on Association)

2. Ch 3: p 267; 311-317: This is a good example of use of patterns to express convenient new constructs in a modeling language without bloating the meta-model with new classes / subclasses. Recommendation: use the Patterns Profile to define and apply these patterns

2. Ch 3: p 196-197: The Entity model in the Information Viewpoint, like any primarily structural model, has its most valuable information in the static invariants across attributes of entities. When partitioned across components (page 197), these static invariants get transformed into protocols on connections between those components to maintain those invariants. Standard patterns of these invariants should be defined (using the Patterns Profile, Chapter 4), and standard transformation of those should be defined as well

3. Ch 2 p 38: "Interviewpoint Correspondences". This discusses an issue of major importance to MDA. The approach outlined is too simplistic. For example, models of legacy systems will map to the enterprise specification in ways less obvious than those discussed here

1. Some name rationalization and consolidation are justifiable:
· ProcessComponent is not a good name; Component Composition does not highlight the encapsulation aspects. Perhaps "ComponentSpecification" for the former; and "ComponentRealization" for the latter.
· Protocols almost act as specifications for Connections. As with the previous case, it may be worth naming Protocol to ConnectorPattern

2. Ch 3: p 326: These generic relationships are described as patterns, like the patterns of process models (Ch 3: p 267; 311-317), and the BFOP patterns (Ch 4, p 98). Hence, these generic relationship constructs should be expressed using the Pattern Profile defined in Chapter 4.

3. Ch 3: p 309: Notation: The notation for associating ProcessRoles, Performers, and
Overall: it would be good to include an example of an instance of CCA which combines BusinessProcess components with other non-process components of CCA. This will also illustrate the value of ports/connectors to de-couple adaptors between the different styles

8. Ch 3: p 56: paragraph "For example, a protocol "X"…. a simple diagram will clarify

5. Ch 3: p 44: 3rd para: This discussed "drill down" into component structures. MDA will require drill down on both components and interactions. The latter has not been addressed as thoroughly as the former for non-process components

15. Ch 3: p 110: Before introducing the custom CCA notation, it would be worthwhile to show how standard UML 1.4 tools which permit iconic representation of stereotypes can be used to provide reasonable notational support for CCA. This has been done in real application architecture projects, and is much easier on the eyes than the stereotyped version described later (Ch 3: p 174).

4. Ch 3: p. 43: last paragraph: Appears to be inconsistent use of role Vs. component