UML Profile for Enterprise Distributed Object Computing Avatar
  1. OMG Specification

UML Profile for Enterprise Distributed Object Computing — All Issues

  • Acronym: EDOC
  • Issues Count: 69
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
EDOC-69 EDOC issue: placement of UML profile for MOF EDOC 1.0b1 open
EDOC-68 The representation/parameter derived association EDOC 1.0b1 open
EDOC-67 The implementingComposition derived association EDOC 1.0b1 open
EDOC-66 Use of Derived Associations EDOC 1.0b1 open
EDOC-65 Document Model as part of CCA does not align with the UML metamodel EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-64 EDOC Issue: Document Structure EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-60 Clarify FCM composition method EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-59 Chapter 3, Section 3.19.1.1, "CompoundTask EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-58 Chapter 3, Section 3.4.1.1 "ProcessComponent" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-62 Clarify the relationship between 'output' FCMTerminals and FCMSink EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-61 Clarify the relationship between FCMTerminal and FCMParameter EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-51 Editorial issue, restructuring of the specification EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-50 Mapping of <> stereotype missing from UML profile for MOF EDOC 1.0b1 open
EDOC-63 Clarify the relationship between FCMTerminal and FCMSource EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-57 Chapter 3, Section 5.2.1.1 "CompoundTask" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-56 Chapter 3, Section 4.2.2.7 "NotificationRule" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-55 Class EventCondition is abstract, and has no concrete subclasses EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-54 Association Role names "guards" and "guardedBy" are the wrong way around EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-53 Chapter 3, Figure 46, pg 236 Role name EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-52 Chapter 3, Figure 46, pg 236 EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-39 Composite nodes and their contents: Rename 'constraints' EDOC 1.0b1 open
EDOC-38 Composite nodes: Derivation of implementingComposition EDOC 1.0b1 open
EDOC-47 Chapter 3, Section 4.1.4.4 "Notification" pg 226, 227 EDOC 1.0b1 open
EDOC-46 Chapter 3, Section 4.2.2.3 "DataEvent" pg 245, 246 EDOC 1.0b1 open
EDOC-43 Chapter 3, Section 4.2.2.7 "NotificationRule EDOC 1.0b1 open
EDOC-42 Association between EventNotice and BusinessEvent EDOC 1.0b1 open
EDOC-45 Chapter 3, Section 4.2.2.7 "Notification Rule" pg 250 - Related to "Node" EDOC 1.0b1 open
EDOC-44 Chapter 3, Figures 46 and 47 (pg 236 & 237) EDOC 1.0b1 open
EDOC-49 Chapter 3, 3.19 "Metamodel", 3.19.1 "Business Process metamodel" EDOC 1.0b1 open
EDOC-48 Chapter 3, Section 4.2 Event Metamodel - throughout EDOC 1.0b1 open
EDOC-37 FCM/Composite nodes: Wording of composite node description EDOC 1.0b1 open
EDOC-36 FCM/Motivation: Why use FCMCommand? EDOC 1.0b1 open
EDOC-33 Ch 3: p 266: ProcessRole EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-32 Ch 3: p 203: Foreign key: EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-35 FCM/Motivation: Avoid introducing constraints on the FCM EDOC 1.0b1 open
EDOC-34 Chapter 3 "ECA", Section 4.2.2.3 "Data Event" - EDOC issue EDOC 1.0b1 open
EDOC-41 Chapter 3, Section 4.2.2.2 "Process Event" EDOC 1.0b1 open
EDOC-40 Define derived relationship between terminal and parameter EDOC 1.0b1 open
EDOC-24 Ch 3: p:59: The wording does not seem right EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-23 Ch 3: p 58: Why do we need initiating role and responding role? EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-31 Ch 3: p 198: The name "DataManager" is too restrictive EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-30 Ch 3: p 113: UML Profile EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-29 Ch 3:p 97: Document model: EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-13 The profile uses documentation tag for MOF annotations EDOC 1.0b1 open
EDOC-12 The profile does not state, which revision of UML it is applicable to EDOC 1.0b1 open
EDOC-11 latest adopted MOF revision is 1.4. However the profile is based on MOF 1.3 EDOC 1.0b1 open
EDOC-18 Tag for multiplicity EDOC 1.0b1 open
EDOC-17 Exception and thus also the raisedSignal reference not supported EDOC 1.0b1 open
EDOC-16 Different element should be used to represent MOF imports EDOC 1.0b1 open
EDOC-22 Ch 3: P 44: 2nd last paragraph EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-21 adding an illustration EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-26 Ch 3: p 70: Interface EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-25 Ch 3: p 60 EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-20 package generalization EDOC 1.0b1 open
EDOC-19 UML Models are not supported by some existing UML tools EDOC 1.0b1 open
EDOC-28 Ch 3:p 86. Needs better explanation of "community process" EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-27 Ch 3:p 76. Choreography EDOC 1.0b1 EDOC 1.0 Resolved closed
EDOC-15 The profile uses UML Exception to represent MOF Exceptions EDOC 1.0b1 open
EDOC-14 There is no way of creating derived associations EDOC 1.0b1 open
EDOC-8 Ch 3: p 267; 311-317 use Patterns Profile to define/apply these patterns EDOC 1.0b1 open
EDOC-7 Ch 3: p 196-197: The Entity model EDOC 1.0b1 open
EDOC-2 Ch 2 p 38: "Interviewpoint Correspondences EDOC 1.0b1 open
EDOC-1 Some name rationalization and consolidation are justifiable EDOC 1.0b1 open
EDOC-10 Ch 3: p 326: EDOC 1.0b1 open
EDOC-9 Ch 3: p 309: Notation EDOC 1.0b1 open
EDOC-5 Ch 3: p 56: paragraph "For example, a protocol "X" EDOC 1.0b1 open
EDOC-4 Ch 3: p 44: 3rd para EDOC 1.0b1 open
EDOC-6 Ch 3: p 110 EDOC 1.0b1 open
EDOC-3 4. Ch 3: p. 43: last paragraph: Appears to be inconsistent use of role Vs. EDOC 1.0b1 open

Issues Descriptions

EDOC issue: placement of UML profile for MOF

  • Key: EDOC-69
  • Legacy Issue Number: 5271
  • Status: open  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Wed, 8 May 2002 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

The representation/parameter derived association

  • Key: EDOC-68
  • Legacy Issue Number: 4867
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    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)

  • Reported: EDOC 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

The implementingComposition derived association

  • Key: EDOC-67
  • Legacy Issue Number: 4866
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Use of Derived Associations

  • Key: EDOC-66
  • Legacy Issue Number: 4865
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • 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.

  • Reported: EDOC 1.0b1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Document Model as part of CCA does not align with the UML metamodel

  • Key: EDOC-65
  • Legacy Issue Number: 5328
  • Status: closed  
  • Source: Edmond Scientific Company ( Tony Mallia)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:14 GMT

EDOC Issue: Document Structure

  • Key: EDOC-64
  • Legacy Issue Number: 5272
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Wed, 8 May 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 23:14 GMT

Clarify FCM composition method

  • Key: EDOC-60
  • Legacy Issue Number: 5441
  • Status: closed  
  • Source: International Business Machines ( Dr. Robert Phippen)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 3.19.1.1, "CompoundTask

  • Key: EDOC-59
  • Legacy Issue Number: 5437
  • Status: closed  
  • Source: DSTC ( Michael Lawley)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 24 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 3.4.1.1 "ProcessComponent"

  • Key: EDOC-58
  • Legacy Issue Number: 5436
  • Status: closed  
  • Source: DSTC ( Michael Lawley)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 24 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and cose

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the relationship between 'output' FCMTerminals and FCMSink

  • Key: EDOC-62
  • Legacy Issue Number: 5443
  • Status: closed  
  • Source: International Business Machines ( Dr. Robert Phippen)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the relationship between FCMTerminal and FCMParameter

  • Key: EDOC-61
  • Legacy Issue Number: 5442
  • Status: closed  
  • Source: International Business Machines ( Dr. Robert Phippen)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 27 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue, restructuring of the specification

  • Key: EDOC-51
  • Legacy Issue Number: 5410
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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
  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    close as duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of <> stereotype missing from UML profile for MOF

  • Key: EDOC-50
  • Legacy Issue Number: 5445
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 1 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the relationship between FCMTerminal and FCMSource

  • Key: EDOC-63
  • Legacy Issue Number: 5444
  • Status: closed  
  • Source: International Business Machines ( Dr. Robert Phippen)
  • Summary:

    (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

  • Reported: EDOC 1.0b1 — Sat, 27 Jul 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 5.2.1.1 "CompoundTask"

  • Key: EDOC-57
  • Legacy Issue Number: 5424
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.7 "NotificationRule"

  • Key: EDOC-56
  • Legacy Issue Number: 5417
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class EventCondition is abstract, and has no concrete subclasses

  • Key: EDOC-55
  • Legacy Issue Number: 5415
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Chapter 3, Figure 46, pg 236

    Class EventCondition is abstract, and has no concrete subclasses

    Suggested Resolution: make EventCondition concrete

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    Motion put in ballot 5 to close with no changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: EDOC-54
  • Legacy Issue Number: 5414
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    Chapter 3, Figure 46, pg 236

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

    Suggested Resolution: redraw diagram

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Figure 46, pg 236 Role name

  • Key: EDOC-53
  • Legacy Issue Number: 5413
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Figure 46, pg 236

  • Key: EDOC-52
  • Legacy Issue Number: 5412
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

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

    Suggested Resolution: redraw diagram

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite nodes and their contents: Rename 'constraints'

  • Key: EDOC-39
  • Legacy Issue Number: 5364
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite nodes: Derivation of implementingComposition

  • Key: EDOC-38
  • Legacy Issue Number: 5363
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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!].

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.1.4.4 "Notification" pg 226, 227

  • Key: EDOC-47
  • Legacy Issue Number: 5422
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.3 "DataEvent" pg 245, 246

  • Key: EDOC-46
  • Legacy Issue Number: 5421
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.7 "NotificationRule

  • Key: EDOC-43
  • Legacy Issue Number: 5418
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association between EventNotice and BusinessEvent

  • Key: EDOC-42
  • Legacy Issue Number: 5416
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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 ????

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.7 "Notification Rule" pg 250 - Related to "Node"

  • Key: EDOC-45
  • Legacy Issue Number: 5420
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Figures 46 and 47 (pg 236 & 237)

  • Key: EDOC-44
  • Legacy Issue Number: 5419
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, 3.19 "Metamodel", 3.19.1 "Business Process metamodel"

  • Key: EDOC-49
  • Legacy Issue Number: 5438
  • Status: open  
  • Source: DSTC ( Michael Lawley)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 24 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2 Event Metamodel - throughout

  • Key: EDOC-48
  • Legacy Issue Number: 5423
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

FCM/Composite nodes: Wording of composite node description

  • Key: EDOC-37
  • Legacy Issue Number: 5362
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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:

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

FCM/Motivation: Why use FCMCommand?

  • Key: EDOC-36
  • Legacy Issue Number: 5361
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 266: ProcessRole

  • Key: EDOC-33
  • Legacy Issue Number: 5837
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject because Composition occurs in the type if the Role

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 203: Foreign key:

  • Key: EDOC-32
  • Legacy Issue Number: 5836
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject as out of scope for FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FCM/Motivation: Avoid introducing constraints on the FCM

  • Key: EDOC-35
  • Legacy Issue Number: 5360
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3 "ECA", Section 4.2.2.3 "Data Event" - EDOC issue

  • Key: EDOC-34
  • Legacy Issue Number: 5341
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    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???

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 3, Section 4.2.2.2 "Process Event"

  • Key: EDOC-41
  • Legacy Issue Number: 5411
  • Status: open  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

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

    Suggested Resolution: ????

  • Reported: EDOC 1.0b1 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define derived relationship between terminal and parameter

  • Key: EDOC-40
  • Legacy Issue Number: 5365
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Wed, 12 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p:59: The wording does not seem right

  • Key: EDOC-24
  • Legacy Issue Number: 5826
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 58: Why do we need initiating role and responding role?

  • Key: EDOC-23
  • Legacy Issue Number: 5824
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    The following removes these classes from the model

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 198: The name "DataManager" is too restrictive

  • Key: EDOC-31
  • Legacy Issue Number: 5835
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 113: UML Profile

  • Key: EDOC-30
  • Legacy Issue Number: 5833
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    accept and close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 97: Document model:

  • Key: EDOC-29
  • Legacy Issue Number: 5831
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The profile uses documentation tag for MOF annotations

  • Key: EDOC-13
  • Legacy Issue Number: 5862
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The profile does not state, which revision of UML it is applicable to

  • Key: EDOC-12
  • Legacy Issue Number: 5861
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

latest adopted MOF revision is 1.4. However the profile is based on MOF 1.3

  • Key: EDOC-11
  • Legacy Issue Number: 5860
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tag for multiplicity

  • Key: EDOC-18
  • Legacy Issue Number: 5867
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception and thus also the raisedSignal reference not supported

  • Key: EDOC-17
  • Legacy Issue Number: 5866
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Different element should be used to represent MOF imports

  • Key: EDOC-16
  • Legacy Issue Number: 5865
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: P 44: 2nd last paragraph

  • Key: EDOC-22
  • Legacy Issue Number: 5823
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

adding an illustration

  • Key: EDOC-21
  • Legacy Issue Number: 5818
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    reject and close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 70: Interface

  • Key: EDOC-26
  • Legacy Issue Number: 5828
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 60

  • Key: EDOC-25
  • Legacy Issue Number: 5827
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

package generalization

  • Key: EDOC-20
  • Legacy Issue Number: 5869
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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)

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Models are not supported by some existing UML tools

  • Key: EDOC-19
  • Legacy Issue Number: 5868
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 86. Needs better explanation of "community process"

  • Key: EDOC-28
  • Legacy Issue Number: 5830
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3:p 76. Choreography

  • Key: EDOC-27
  • Legacy Issue Number: 5829
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Disposition: Resolved — EDOC 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The profile uses UML Exception to represent MOF Exceptions

  • Key: EDOC-15
  • Legacy Issue Number: 5864
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no way of creating derived associations

  • Key: EDOC-14
  • Legacy Issue Number: 5863
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Thu, 13 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 267; 311-317 use Patterns Profile to define/apply these patterns

  • Key: EDOC-8
  • Legacy Issue Number: 5838
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 196-197: The Entity model

  • Key: EDOC-7
  • Legacy Issue Number: 5834
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 2 p 38: "Interviewpoint Correspondences

  • Key: EDOC-2
  • Legacy Issue Number: 5820
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some name rationalization and consolidation are justifiable

  • Key: EDOC-1
  • Legacy Issue Number: 5817
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 326:

  • Key: EDOC-10
  • Legacy Issue Number: 5840
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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.

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 309: Notation

  • Key: EDOC-9
  • Legacy Issue Number: 5839
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 56: paragraph "For example, a protocol "X"

  • Key: EDOC-5
  • Legacy Issue Number: 5825
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 44: 3rd para

  • Key: EDOC-4
  • Legacy Issue Number: 5822
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

    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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ch 3: p 110

  • Key: EDOC-6
  • Legacy Issue Number: 5832
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: EDOC-3
  • Legacy Issue Number: 5821
  • Status: open  
  • Source: Kinetium ( Desmond D'Souza)
  • Summary:

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

  • Reported: EDOC 1.0b1 — Mon, 13 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT