Issue 4865: Use of Derived Associations
Issue 4866: The implementingComposition derived association
Issue 4867: The representation/parameter derived association
Issue 5271: EDOC issue: placement of UML profile for MOF
Issue 5272: EDOC Issue: Document Structure
Issue 5328: Document Model as part of CCA does not align with the UML metamodel
Issue 5341: Chapter 3 "ECA", Section 4.2.2.3 "Data Event" - EDOC issue
Issue 5360: FCM/Motivation: Avoid introducing constraints on the FCM
Issue 5361: FCM/Motivation: Why use FCMCommand?
Issue 5362: FCM/Composite nodes: Wording of composite node description
Issue 5363: Composite nodes: Derivation of implementingComposition
Issue 5364: Composite nodes and their contents: Rename 'constraints'
Issue 5365: Define derived relationship between terminal and parameter
Issue 5410: Editorial issue, restructuring of the specification
Issue 5411: Chapter 3, Section 4.2.2.2 "Process Event"
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 5416: Association between EventNotice and BusinessEvent
Issue 5417: Chapter 3, Section 4.2.2.7 "NotificationRule"
Issue 5418: Chapter 3, Section 4.2.2.7 "NotificationRule
Issue 5419: Chapter 3, Figures 46 and 47 (pg 236 & 237)
Issue 5420: Chapter 3, Section 4.2.2.7 "Notification Rule" pg 250 - Related to "Node"
Issue 5421: Chapter 3, Section 4.2.2.3 "DataEvent" pg 245, 246
Issue 5422: Chapter 3, Section 4.1.4.4 "Notification" pg 226, 227
Issue 5423: Chapter 3, Section 4.2 Event Metamodel - throughout
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 5438: Chapter 3, 3.19 "Metamodel", 3.19.1 "Business Process metamodel"
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 5445: Mapping of <<enumeration>> stereotype missing from UML profile for MOF
Issue 5817: Some name rationalization and consolidation are justifiable
Issue 5818: adding an illustration
Issue 5820: Ch 2 p 38: "Interviewpoint Correspondences
Issue 5821: 4. Ch 3: p. 43: last paragraph: Appears to be inconsistent use of role Vs.
Issue 5822: Ch 3: p 44: 3rd para
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 5825: Ch 3: p 56: paragraph "For example, a protocol "X"
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 5832: Ch 3: p 110
Issue 5833: Ch 3: p 113: UML Profile
Issue 5834: Ch 3: p 196-197: The Entity model
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 5838: Ch 3: p 267; 311-317 use Patterns Profile to define/apply these patterns
Issue 5839: Ch 3: p 309: Notation
Issue 5840: Ch 3: p 326:
Issue 5860: latest adopted MOF revision is 1.4. However the profile is based on MOF 1.3
Issue 5861: The profile does not state, which revision of UML it is applicable to
Issue 5862: The profile uses documentation tag for MOF annotations
Issue 5863: There is no way of creating derived associations
Issue 5864: The profile uses UML Exception to represent MOF Exceptions
Issue 5865: Different element should be used to represent MOF imports
Issue 5866: Exception and thus also the raisedSignal reference not supported
Issue 5867: Tag for multiplicity
Issue 5868: UML Models are not supported by some existing UML tools
Issue 5869: package generalization
Issue 4865: Use of Derived Associations (uml-edoc-ftf)
Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.
This issue (and others relating to FCM derived associations) is transferred to EDOC as EDOC Issues 5441, 5442, 5443 and 5444. These issues require an explanation of the FCM mechanism for recursive composition. The result of this is that the content of section 6.2 of the EAI specification is now covered by revisions to the FCM Model described in the 'UML Profile for EDOC'. Section 6.2 is retained, but its complete text is replaced with a brief description referencing the revised sections of the "UML Profile for for EDOC" (document number adxx-xx-xx.
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).
See discussion for issue 4865
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)
See discussion for issue 4865
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.
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.
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???
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
See discussion for issue 4865
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".
See discussion for issue 4865
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:
See discussion for issue 4865
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!].
See discussion for issue 4865
Section 6.2.4: the Constraints listed are not constraints but definitions of the derivation (which it is useful to have expressed).
See discussion for issue 4865
Section 6.2.5: Should define the derived association via existing references.
See discussion for issue 4865
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
The text is missing a description of the metaattributes in the model diagram: entry: boolean, success: boolean. Also may need some constraints. Suggested Resolution: ????
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, 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 ????
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.
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.
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 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.
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'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.
"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.
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].
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.
(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.
relates to EAI issue: 5367) The UML profile for MOF needs to say how the UML <<enumeration>> maps to a MOF enumeration.
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. 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
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
4. Ch 3: p. 43: last paragraph: Appears to be inconsistent use of role Vs. component
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
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?
8. Ch 3: p 56: paragraph "For example, a protocol "X"…. a simple diagram will clarify
Resolution: Defer Rationale: It is to early in the document to introduce diagrams as the notation has not been introduced
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.
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).
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.
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 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).
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
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
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.
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
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 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.
There is no way of creating derived associations (isDerived tag should be added on Association)
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
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.
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
Tag for multiplicity is introduced for Parameters, however in UML 1.4 multiplicity on parameters is natively supported.
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>>)
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)