Issues for UML Profile for EDOC Finalization task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5272: EDOC Issue: Document Structure
Issue 5328: Document Model as part of CCA does not align with the UML metamodel
Issue 5410: Editorial issue, restructuring of the specification
Issue 5412: Chapter 3, Figure 46, pg 236
Issue 5413: Chapter 3, Figure 46, pg 236 Role name
Issue 5414: Association Role names "guards" and "guardedBy" are the wrong way around
Issue 5415: Class EventCondition is abstract, and has no concrete subclasses
Issue 5417: Chapter 3, Section 4.2.2.7 "NotificationRule"
Issue 5424: Chapter 3, Section 5.2.1.1 "CompoundTask"
Issue 5436: Chapter 3, Section 3.4.1.1 "ProcessComponent"
Issue 5437: Chapter 3, Section 3.19.1.1, "CompoundTask
Issue 5441: Clarify FCM composition method
Issue 5442: Clarify the relationship between FCMTerminal and FCMParameter
Issue 5443: Clarify the relationship between 'output' FCMTerminals and FCMSink
Issue 5444: Clarify the relationship between FCMTerminal and FCMSource
Issue 5818: adding an illustration
Issue 5823: Ch 3: P 44: 2nd last paragraph
Issue 5824: Ch 3: p 58: Why do we need initiating role and responding role?
Issue 5826: Ch 3: p:59: The wording does not seem right
Issue 5827: Ch 3: p 60
Issue 5828: Ch 3: p 70: Interface
Issue 5829: Ch 3:p 76. Choreography
Issue 5830: Ch 3:p 86. Needs better explanation of "community process"
Issue 5831: Ch 3:p 97: Document model:
Issue 5833: Ch 3: p 113: UML Profile
Issue 5835: Ch 3: p 198: The name "DataManager" is too restrictive
Issue 5836: Ch 3: p 203: Foreign key:
Issue 5837: Ch 3: p 266: ProcessRole

Issue 5272: EDOC Issue: Document Structure (uml-edoc-ftf)

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).

Resolution: 
7 copies of the Final Adopted Specification document are to be made, and edited to remove material not pertinent to the subtopic for that document. The 7 documents titles (and the document numbers where the specific edits are recorded and resulting documents may be seen) are:

ptc-03-09-05.pdf (ECA) 
ptc-03-09-06.pdf (UML Profile for ECA) 
ptc-03-09-07.pdf (UML Profile for Relationships) 
ptc-03-09-08.pdf (UML Profile for Patterns) 
ptc-03-09-09.pdf (EJB and Java Metamodels) 
ptc-03-09-10.pdf (FCM) 
ptc-03-09-11.pdf (UML Profile for MOF)

They are also available as a single ZIP file: ptc/03-09-04.zip

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. 
 

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

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


Suggested Resolution: redraw diagram

In Final Adopted Spec change Figure 3-42 "Complete Metamodel for Event
Modeling" to swap the Rolename "triggers" with "triggeredBy", and swap
the Rolename "describes" with "describedBy". 

Ballot 5:
In addition to the resolution above, Alter Figure 3-40 "Business Process View 
of metamodel" and Figure 3-41 "Entity View of metamodel" and 
Figure 3-44 Diagram of Event Package  to swap the Rolename "triggers" 
with "triggeredBy", and swap the Rolename "describes" with "describedBy".

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.

Change text in 3.13.5.1 "BusinessEvent" [now 3.11.5.1 in new doc structure] , subheading "Related Elements
EventNotice" Sentence: "A business event triggers one or more
event notices."  to "A business event triggers zero or more
event notices."

Chapter 3, Figure 46, pg 236


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


Suggested Resolution: redraw diagram

Ballot 1 Resolution:

In Final Adopted Spec Figure 3-44 "Diagram of Event Package", and
Figure 3-42 "Complete Metamodel for Event Modeling" the Role names
"guards" and "guardedBy" should be swapped to reflect the semantics
in the text in 3.13.5.7 "NotificationRule". [Poor role naming should
be raised as a separate issue.]

Ballot 5 Resolution:

In addition to the edits above, in Figure 3-40 "Business Process View 
of metamodel" the Role names "guards" and "guardedBy" should be swapped

Chapter 3, Figure 46, pg 236


Class EventCondition is abstract, and has no concrete subclasses


Suggested Resolution: make EventCondition concrete

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.

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. 

Add text "or ProcessRoles" to end of constraint 2 of section 3.19.1.1 "CompoundTask" [3.16.1.1 in new ECA document on 3-131] on page 3-226 of the Final Adopted Spec.

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

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

Delete Constraint 3 on CompoundTask in Section 3.19.1.1 on page 3-226 of Final Adopted Spec [3.16.1.1 on page 3-132 of new ECA document].

(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'.

In the FCMCore package:

<!--[if !supportLists]-->·        <!--[endif]-->Make the association between FCMType and FCMCompositionBinding bi-directional to facilitate navigation from an FCMComponent to an underlying FCMComposition.

<!--[if !supportLists]-->·        <!--[endif]-->Add new FCMCompositeNode as a subclass of FCMCommand.  FCMCompositionNode  has a derived association to FCMComposition, to facilitate finding the nodes that it contains.

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

In the FCMCore package:

<!--[if !supportLists]-->·        <!--[endif]-->Add an association from FCMTerminal to FCMParameter to allow the parameters that represent the terminal’s signature to be directly accessible.

<!--[if !supportLists]-->·        <!--[endif]-->In a new FCMTerminals diagram, add an  association from FCMTerminal to FCMOperation to facilitate constraints

Revised Text:

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

In hierarchical composition, some of all the FCMSinks of an FCMComposition become the outbound FCMTerminals of the resulting composite node.  In the new FCMTerminal diagram in the FCMCore package:

<!--[if !supportLists]-->·        <!--[endif]-->Add a derived association from FCMTerminal to FCMSink to make it possible to navigate to the FCMSinks that an FCMTerminal may be derived from.

<!--[if !supportLists]-->·        <!--[endif]-->Add an association from FCMSink to FCMParameter to make it easier to find the sink’s parameters.

(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

In hierarchical composition, one of the FCMSources of an FCMComposition becomes the inbound FCMTerminal of a resulting composite node.  In the new FCMTerminal diagram in the FCMCore package:

<!--[if !supportLists]-->·        <!--[endif]-->Add an association from FCMTerminal to FCMSource to make it possible to navigate to the FCMSources that an FCMTerminal may be derived from.

<!--[if !supportLists]-->·        <!--[endif]-->Add a  association from FCMSource to FCMParameter to make it easier to find the source’s parameters.

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

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

Change From: 
…  The ability to configure a component is essential to making it general and reusable.  We call a configuration point a “property”.

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?

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.

Resolution: Reject

Raionale: Terminology is used consistently throughout the document.

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

Resolution: Reject

Rationale: Introducing new terminology and applying it consistently through the document is outside of the scope of the FTF.  The terminology specified is used consistently

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.

Resolution: Reject

Interfaces may be “stand alone” and used in multiple protocols and components as is allowed by the derivation from protocol.

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

Resolution:  Reject

Rationale: References to Choreography seem to be inclusive of protocols, page reference problems make determination of specific paragraphs difficult.

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

Resolution: Accept
Revised Text: Add Paragraph  (shown underlined below, with existing para in plain text)

Community processes may be thought of as the “top level composition” in a CCA specification, it is a specification of a composition of ProcessComponents that work together for some purpose other than specifying another ProcessComponent.

Components within a community process represent roles that components may play within the process.  These roles are later bound to particular components realizing processes. 

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

Resolution: Reject

Rationale: Data elements may have supertypes as indicated.  The semantics of supertype in this regard is consistent with common usage.

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.

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.

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

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).