Working through the EDOC profile ptc/02-02-05 the following issues came to light:

The Document Model as part of CCA does not align with the UML metamodel - the CompositeData looks as if it can have a feature (Attribute) which is not "byValue" indicating that the aggregation might not be a composite. The Document Model is critical in that it must be able to map to the platform message including Java serailized objects, XML schema and DOM.

The base Element for Key, Key Element and Key Attribute is Class. It seems more appropriate not to force the class to be stereotyped but rather the AssociationEnd or AttributeLink where the element type is used as a Key. If the class is stereotyped, then all its occurences are stereotyped and it may not be used in every case as a key.

No Data Available

Issue: The EDOC Document is not well structured for the user. The document
contains multiple sub-specifications that are of interest to different
people at different parts of the development process and supply chain. In
addition, the paragraph numbering is not unified across the document. The
result of this is that someone interested in, say, events will have a very
hard time finding it and will probably be confused by the other viewpoints.

Suggested Resolution: Each section of the MDA document should be a separate
document, the first document (Currently chapter 2) already talks about how
these sections relate and could easily be altered to reference stand-alone
documents using URL pointers. The formal response section (Chapter one) is
not of interest to a user and should be excluded.

The suggested document list is;

EDOC Profile (Current Chapter 2 plus glossary and references)

The Enterprise Collaboration Architecture overview (3.1)
ECA Component Collaboration Architecture (3.2)
ECA Entity Profile (3.3.)
ECA Events Profile (3.4)
ECA Business Process Profile (3.5)
ECA Relationships Profile (3.6)
ECA Patterns Profile (4)

EDOC Technology Profile overview
EJB and Java Metamodels (5.1)
Flow Composition Model (5.2)

UML Profile for MOF (This may be moved to MOF).

see above

(Relates to EAI Issues 5362, 4866)
Clarify how the FCM achieves nested composition, describing the
relationship between the 'composite' node, and the nodes it 'contains'.

see above

Constraint 3 is too strong.
A CompoundTask must also own the PortUsages for the ProcessFlowPorts
that its ProcessMultiPorts contain as well as the PortUsages belonging
to the "extent" of the ComponentUsages (both Activities and ProcessRoles)
that are owned by the CompoundTask.

Suggested Resolution:

Remove the constraint completely since ProcessRoles require that a more
complete range of Ports be "useable

see above

ProcessComponent is correctly identified as extending UsageContext,
but the inherited association to PortUsage is not documented in the
"Related elements" part

reject and cose

relates to EAI Issues 5365, 4898)
For a 'composite' node, clarify the relationship (multiplicity etc) between
an FCMTerminal (on the composite node) and, for FCMSinks in the relevant
FCMComposition,
FCMSink itself
FCMSink.source.implements.outputs
FCMSink.source.implements.faults

see above

(relates to EAI Issue 5365, 4867)
For an FCMFunction or an FCMCommand, clarify the relationship between
FCMTerminal and FCMParameter. What is its multiplicity?

see above

I have an editorial issue with the "UML Profile for EDOC"
specification: It needs some restructuring to make it usable:

The title is misleading, as the specification contains a number if
chapters that have UML profiles, and a number that have MOF
models. Some have both.

Chapters 2 and 3 of "UML Profile for EDOC" - loosely - "ECA" are
difficult to read, as they intersperse MOF models with UML profiles
for each sub-package of ECA. In addition, Section 6 of chapter 3
is the "Relationships Profile", which is unrelated, and should be
a separate chapter. Also, Chapter 5 of the EDOC spec contains 2
separate models.

Suggested resolution - each chapter (and some sections) become
contiguous chapters in the OMG modelling specifications with
appropriate titles.

"UML Profile for EDOC" specification should become 6 contiguous
chapters of OMG Modelling specifications:

• Chapter N "Enterprise Collaboration Architecture Metamodel"
  comprises:
  . EDOC Chapter 2, Section 3 as a preamble
  . EDOC Chapter 3 Sections 1, 2.0-2.3, 2.5, 3.0-3.3, 4.0-4.2,
  4.4-4.6, 5.0-5.2, 5.4-5.6

• Chapter N+1 "UML Profile for Enterprise Collaboration
  Architecture" comprises:
  . EDOC Chapter 3 Sections 2.4, 3.4, 4.3, 5.3

• Chapter N+2 "UML Profile for Relationships" comprises:
  . EDOC Chapter 3 Section 6

• Chapter N+3 "UML Profile for Patterns" == EDOC Chapter 4

• Chapter N+4 "EJB and Java Metamodels" == EDOC Chapter 5 Section 1

• Chapter N+5 "Flow Composition Metamodel" == EDOC Chapter 5 Section 2

close as duplicate

(relates to EAI Issues 5365, 5384, 4898)
For a 'composite' node, clarify the relationship between FCMTerminal (on
the composite) and, for FCMSources in the relevant FCMComposition
FCMSource itself
FCMSource.implements.inputs

see above

Constraint number 2 is too strong. It precludes ProcessRoles from being
contained.

Suggested Resolution: Add text "or ProcessRoles" to end of constraint 2
on page 272.

see above

Chapter 3, Section 4.2.2.7 "NotificationRule"

It is not clear whether the EventCondition guarding a NotificationRule
needs to be satisfied before or after the NotificationRule Condition
Expression

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

change and close issue

Chapter 3, Figure 46, pg 236

Class EventCondition is abstract, and has no concrete subclasses

Suggested Resolution: make EventCondition concrete

Motion put in ballot 5 to close with no changes

Chapter 3, Figure 46, pg 236

Association Role names "guards" and "guardedBy" are the wrong way around

Suggested Resolution: redraw diagram

see above

Cardinality of triggers (EventNotice end of Association) is 0..n in
figure and 1..n in desciptive text.

Suggested Resolution: change to 0..n in text, as not every EventNotice
must be send due to a trigger.

see above

Role names "triggers/triggeredBy" and "describes/describedBy" are at
the wrong ends of the associations.

Suggested Resolution: redraw diagram

see above

1. Ch 3: p 266: ProcessRole should be subject to composition from other ProcessRoles just as Business Process and Compound Task can be composed from sub-parts (p. 263, by inheritance from Process Component).

reject because Composition occurs in the type if the Role

4. Ch 3: p 203: Foreign key: This is an example of a concept that crosses many profiles and domains. MDA will be greatly helped if such patterns can be abstracted and shared. Note that this requires improved support in UML 2.0 for patterns that can generate context-specific models

reject as out of scope for FTF

9. Ch 3: p:59: The wording does not seem right. "Protocols are defined in terms of the set of ports they realize". Protocols do not realize ports, they require ports; components realize ports. This also explains the inversion of direction. A protocol is like a connector's view of some set of ports.

see above

7. Ch 3: p 58: Why do we need initiating role and responding role? They seem to just define a name, whose main purpose seems to be to designate one of the ports of that protocol as being initiator. Why not just have 2 associations to two distinguished ports?

The following removes these classes from the model

3. Ch 3: p 198: The name "DataManager" is too restrictive. Even though centered around entities, these components can have highly intelligent behavioral interfaces, such as computation of complex derived attributes and queries, or "writable" views.

reject and close

16. Ch 3: p 113: UML Profile. It was helpful to see the simpler MOF-based meta-model before the complex UML profile version. In fact, in our experience meta-modeling activity should not start out as a UML profile definition, as this obscures the shape of the meta-model based on the capabilities of the "platform" (the facilities of Profiles); a cleaner meta-model can be separately realized as a UML Profile.

accept and close no change

14. Ch 3 97: Document model: The name "supertype" does not fit the recursive relation on CompositeData

see above

6. Ch 3: P 44: 2nd last paragraph: configuration point is not just "property", but includes "contextual bindings

see above

2. The main technical ideas could be clarified by adding an illustration similar to the one below after some notational tweaks, showing the primary CCA concepts early in Ch 3

reject and close

11. Ch 3: p 70: Interface: Interface should be specialized from Port. You can have an corresponding protocol to include the client end of that interface as the second port.

see above

10. Ch 3: p 60: "The behavior of a process component may be further specified by its composition". It may be better to call this the "internal design" of the component, rather than a "specification". CCA supports a recursive black-box / white-box model, where the black box view of a component is a component spec, and its white box view is an assembly of sub-components (each with a spec) and their customizations and interconnections

see above

13. Ch 3 86. Needs better explanation of "community process". Is unclear about whether a community can consist of roles, components, entities, etc.

see above

12. Ch 3 76. Choreography: explanation should also include how choreography is used by protocols

see above