Business Architecture Core Metamodel Avatar
  1. OMG Specification

Business Architecture Core Metamodel — Closed Issues

  • Acronym: BACM
  • Issues Count: 61
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
BACM-9 Dispose of the content from Annex B BACM 1.0a1 BACM 1.0b2 Deferred closed
BACM-38 Entry- and Exit-Criteria missing BACM 1.0b1 BACM 1.0b2 Deferred closed
BACM-66 Dispose of content from Section 9 BACM 1.0a1 BACM 1.0b2 Deferred closed
BACM-13 Abstract Process missing from Diagram 7.3.7.3 and following text BACM 1.0a1 BACM 1.0b2 Deferred closed
BACM-68 The BACM metamodel does not have a domain of individuals BACM 1.0a1 BACM 1.0b2 Deferred closed
BACM-116 Concept of participating stakeholder missing from metamodel BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-114 Issue BACM-73 and resolution BACM-80 incorrectly stated BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-122 Generalization relations missing from 7.3.7.1 BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-120 Classes missing from 7.3.7.4 ValueModel diagram BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-83 Review uses of "owns" and "aggregates" for consistency BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-84 Beta specification ambiguous with respect to SMOF BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-97 Update Conformance section of the document BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-76 "owns" and "generalizes" associations missing from ProductOffering BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-55 Determine compliance requirement for MEF BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-26 Compliance statements for shortcuts and touchpoints hard to evaluate BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-15 Incomplete Symbols and Abbreviations - section 5 BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-85 Revise the definition of shortcut to eliminate virtual associations BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-98 Eliminate duplicate association names in EA model BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-100 Eliminate same named association with common src transformation rule BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-112 Replace IRI uml:Class in BACM_Model with IRI uml:DataType BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-118 Diagram 7.3.6.5 Service Offering - overlapping associations BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-79 Regenerate the specification document from the EA model BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-74 Inconsistent ownedEnd quantification in special associations (owns, ...) BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-89 Entry- and Exit-Criteria missing BACM 1.0b1 BACM 1.0b2 Duplicate or Merged closed
BACM-75 The BACM specification does not document XML for interoperability BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-71 Can other property names in this specification be “modified”? BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-91 Incorrect shortcut specification of Capability supports ValueStreamStage BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-14 Import SMM and specialize some SMM classes for integration BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-72 Remove category and categorization from the specification BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-81 ValueProposition aggregates ValueProposition - owns vs aggregates BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-21 Provide an OWL 2 ontology as a machine readable file BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-25 Material in Section 0.6 that should be in the specification BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-20 Failure to meet RFP requirement 6.5.2.4 regarding specification alignment BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-28 Section 3 reference to SIMF BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-34 The term "user" is imprecise BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-27 Mix of version specific and non-specific references BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-77 Corrections to EA model to fix definitions and glossary BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-1 Make changes to the spec to enable the production of MOF compliant XMI BACM 1.0b1 BACM 1.0b2 Resolved closed
BACM-2 Replace diagram 7.3.1.1.3 and following text BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-45 Rewrite section 7.2.2 for clarification BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-17 Remove or replace mentions of category and categorization BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-6 Remove Section 9 and republish as a separate, informative adjunct document BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-30 Use of term "parent" confusing BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-23 Touchpoint notion does not require query capability BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-29 Metamodel level terminology obsolete BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-73 ResourceRole AssignTo association in Organization diagram 7.3.4.1 reversed BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-36 Meaning of "generalization" of instances BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-37 Semantic treatment of n-ary associations as tuples BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-18 Beta document does not address all the RFP perspectives BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-19 No glossary in the package descriptions BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-22 Section 1 - Scope should describe the submission, not the RFP BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-24 The term "class association" is an improper use BACM 1.0a1 BACM 1.0b2 Closed; No Change closed
BACM-31 BACM semantic specification unclear BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-5 Remove Annex B from the specification document BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-32 Use of "leg" terminology to describe relationships BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-41 Rewrite the second paragraph of section 7.2.1 to clarify the relationship between the specification document and the normative XMI BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-43 The 3rd paragraph of 7.2 is unclear BACM 1.0a1 BACM 1.0b2 Resolved closed
BACM-35 Unclear specification of instantiation of variable arity relationships BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-11 Deliver MOF compliant XMI for specification BACM 1.0b1 BACM 1.0b2 Resolved closed
BACM-33 Usage of "leg target" terminology unclear BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed
BACM-16 Incomplete description of association reification BACM 1.0a1 BACM 1.0b2 Duplicate or Merged closed

Issues Descriptions

Dispose of the content from Annex B

  • Key: BACM-9
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This issue depends on acceptance of the proposal BACM_5 to remove Annex B from the specification document. It seeks proposals to dispose of this content.

  • Reported: BACM 1.0a1 — Wed, 22 Jun 2022 17:00 GMT
  • Disposition: Deferred — BACM 1.0b2
  • Disposition Summary:

    Defer to Revision Task Force

    This Annex provided an example of the external model query facility. This facility was replaced with an adaptation of the SysML V2 external reference in order to gain approva of the OMG Architecture Board.
    The annex was removed from the specification in a prior FTF vote.
    The example in the annex uses XQuery to access information from the XML serialization of a BPMN process model.
    It is a valuable work that is not incompatible with the external reference model as it could become a query part of a de-referenceable URL or it could also be the content of an HTTP POST operation. It can probably survive as an adjunct, non-normative document with some editing to show how to use it with the external reference facility.

  • Updated: Mon, 9 Oct 2023 15:16 GMT

Entry- and Exit-Criteria missing

  • Key: BACM-38
  • Status: closed  
  • Source: Business Architecture Guild ( Mr. Hermann Schlamann)
  • Summary:

    Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationships are missing in the BACM.

  • Reported: BACM 1.0b1 — Sun, 30 Oct 2022 09:13 GMT
  • Disposition: Deferred — BACM 1.0b2
  • Disposition Summary:

    Defer to Revision Task Force

    These relationships did not appear in any version of the submission and constitute a material change to the beta specification. Recommend that this issue be deferred. Entry and exit criteria can also be determined by analysis of the outcomes of capabilities supporting the value stream stages and selecting specified outcomes to serve as entry and exit criteria. An architect following the BIZBoK Guide(tm) would be able to perform this analysis based on information in a BACM model.

  • Updated: Mon, 9 Oct 2023 15:16 GMT

Dispose of content from Section 9

  • Key: BACM-66
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    A prior vote of the FTF approved the removal of this content from the specification. The FTF must now decide what to do with this content.

  • Reported: BACM 1.0a1 — Tue, 6 Dec 2022 17:21 GMT
  • Disposition: Deferred — BACM 1.0b2
  • Disposition Summary:

    Defer to Revision Task Force

    The content of this part of the submission would need substantial revision and it is not material to the completion of the specification document and to the submission of MOF compliant XMI.

  • Updated: Mon, 9 Oct 2023 15:16 GMT

Abstract Process missing from Diagram 7.3.7.3 and following text

  • Key: BACM-13
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This diagram represents the capabilities that would be required to carry out a means or initiative. Often, these capabilities are not a part of the organization and must be added, e.g. by contract. The issue is that abstract process should be included because it represents a perspective that abstractly represents the operations of the business that is distinct from the capability perspective but at the same level of abstraction.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 16:30 GMT
  • Disposition: Deferred — BACM 1.0b2
  • Disposition Summary:

    Defer to RTF

    The changes to the specification are material. See Jim Rhyne comment on the issue, reproduced below:
    Diagram 7.3.7.3 adds Means and Initiatives "require" AbstractCapability. This represents capabilities that may be needed to carry out the Means and/or Initiatives; these may not be a part of the steady state model of the business. The issue to be resolved is whether AbstractProcess can also be "required" by Means and/or Initiatives. This would represent processes and activities that would be needed to carry out the Means and/or Initiatives. It is unclear whether this new relationship is primary or can be derived from other relationships (e.g. via required capabilities).
    It also adds "implements" from CapabilityImplementation to Initiative. CapabilityImplementation represents an abstract specification of resources and performers. The "implements" association should be a shortcut, as it is supported by role assignments of the Resources and Performers to the Roles of AbstractCapability which is "required" by Initiative.
    CapabilityImplementation Resources and Performers can also be assigned to Roles of AbstractProcess. There is no shortcut association "implements" between CapabilityImplementation and AbstractProcess. This should be added to avoid having to specify the details of such assignment as individual Role assignments.
    Once the "implements" shortcut association between CapabilityImplementation and AbstractProcess is added, the "implements" shortcut association can be added between AbstractProcess and Initiative.

  • Updated: Mon, 9 Oct 2023 15:16 GMT

The BACM metamodel does not have a domain of individuals

  • Key: BACM-68
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This issue arises from the resolution of BACM-45 and BACM-43. Taken together these proposals create an interpretation of the BACM model elements that does not syntactically distinguish elements representing sets from elements representing individuals. Rather, it represents individuals by an OCL constraint that allows only a single model element to have a given metaclass. This solution works for the only case in the current BACM spec, but does not resolve the underlying issue of the inability to represent individuals and make assertions about them.

  • Reported: BACM 1.0a1 — Thu, 8 Dec 2022 21:14 GMT
  • Disposition: Deferred — BACM 1.0b2
  • Disposition Summary:

    Resolution requires substantial change to the BACM metamodel

    Implementing a domain of individuals and assertions (e.g. OWL 2) would require adding many more classes and associations to the metamodel with consequences unanalyzed at this time.

  • Updated: Mon, 9 Oct 2023 15:16 GMT

Concept of participating stakeholder missing from metamodel

  • Key: BACM-116
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    A participating stakeholder in a value stream is a Performer role in a Capability that produces an Outcome that is valued by a ValueItem produced by a ValueStreamStage. This relationship is missing from the metamodel

  • Reported: BACM 1.0a1 — Mon, 8 May 2023 21:18 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Add the participate association as a shortcut

    Add the participate association as a shortcut. Define OCL 2 expression of the shortcut function. Create new diagram "Participant" to show the metamodel elements referenced in the OCL expression.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Issue BACM-73 and resolution BACM-80 incorrectly stated

  • Key: BACM-114
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    On investigation and after Ballot #7, it was discovered that the issue was incorrectly stated. The source to destination of both assignTo associations are correct. However, the text label direction arrowhead for PerformerRole assignTo Performer is reversed.

  • Reported: BACM 1.0a1 — Fri, 5 May 2023 16:58 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Edit the EA model to reverse the text arrowhead direction

    Edit the EA model to change the direction of the text label arrowhead.
    Generate the SVG version of the diagram. Generate the replacement RTF for 7.3.4

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Generalization relations missing from 7.3.7.1

  • Key: BACM-122
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Two generalization relations are missing from this diagram between Organization::Resource and Organization::Performer as less general and Strategy::AbstractOperatingModel as more general

  • Reported: BACM 1.0a1 — Mon, 8 May 2023 22:15 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Add the missing generalization relations to the 7.3.7.1 OperatingModel

    Add the missing generalization relations to the 7.3.7.1 OperatingModel

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Classes missing from 7.3.7.4 ValueModel diagram

  • Key: BACM-120
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    CustomerJourney, CustomerJourneyStage and Touchpoint are missing from this diagram

  • Reported: BACM 1.0a1 — Mon, 8 May 2023 22:06 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Add the missing classes and the generalization relations

    Add the missing classes and the generalization relations

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Review uses of "owns" and "aggregates" for consistency

  • Key: BACM-83
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The "owns" association denotes strict composition at the model instance level. Business architecture methodology disallows non-strict composition for capabilities and value stream stages and value streams, but makes no statement about other cases. Business architecture methodology also disallows specialization of capabilities, value stream stages and value streams. The metamodel needs a "does it make sense" review to determine if "owns", "agggregates" and "generalizes" are properly expressed in the model.

  • Reported: BACM 1.0a1 — Thu, 16 Feb 2023 17:41 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Revision to generally allow generalizes, owns and aggregates between BusinessElements

    The EA metamodel is revised to allow generalizes, aggregates and owns associations between BusinessElement concrete subtypes, subject to the constraint that the participating instances must be of the same concrete type. This is enforced by a set of OCL 2 constraints associated with the BusinessElement.
    In addition, OCL 2 constraints on Capability disallow generalizes and aggregates links between Capability instances.
    In addition, OCL 2 constraints on ValueStream disallow generalizes, owns, or aggregates links between ValueStream instances.
    In addition, OCL 2 constraints on ValueStreamStage disallow generalizes and aggregates links between ValueStreamStage instances.
    In addition, OCL 2 constraints on CustomerJourney disallow generalizes, aggregates or owns links between instances of CustomerJourney.
    In addition, OCL 2 constraints on CustomerJourneyStage disallow generalizes and aggregates links between instances of CustomerJourneyStage.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Beta specification ambiguous with respect to SMOF

  • Key: BACM-84
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The beta specification states that SMOF is a requirement for implementors. However, SMOF lifts the MOF restriction that each instance have one and only one metaclass/meta-association. Consequently, the specification is ambiguous about what elements should be disjoint. Some meta-classes should be disjoint (e.g. business objects and capabilities).
    This omission also affects the issues raised in BACM-83.

  • Reported: BACM 1.0a1 — Tue, 21 Feb 2023 06:11 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Clarify the SMOF requirement and provide additional diagrams

    The changes affect all of section 7.3.1 which is to be replaced by the attached Word file. Prose changes clarify that SMOF allows multiple metaclasses and eliminates the MOF requirement of classifier disjointness. Consequently, additional diagrams are introduced to explicitly specify disjoint constraints. These disjoint constraints also appear in the MOF compliant XMI as OpaqueConstraints specified in the SMOF language. The consistency of the resulting model is tested by translating it into OWL and using a reasoner to determine any inconsistencies.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Update Conformance section of the document

  • Key: BACM-97
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Conformance statements are incomplete and distributed through section 7. Provide an updated Conformance section that addresses conformance requirements, This issue resolution also resolves BACM-26, BACM-55 and partly resolves BACM-84 (with respect to conforming with the requirement to implement SMOF).

  • Reported: BACM 1.0a1 — Thu, 20 Apr 2023 01:39 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Section 2 of the document is replaced

    Section 2 of the document is rewritten to establish conformance levels in four independent aspects: content completeness, SMOF capability, Shortcut capability, MOF extension [MEF] capability.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

"owns" and "generalizes" associations missing from ProductOffering

  • Key: BACM-76
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    ProductOfferings can be aggregated by not contained or generalized. This appears to be an omission that would compromise the usefulness of the specification. It would be a minor change to the Product diagram.

  • Reported: BACM 1.0a1 — Wed, 11 Jan 2023 22:24 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Merge this issue with BACM-83

    This issue is resolved by the proposal to resolve BACM-83

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Determine compliance requirement for MEF

  • Key: BACM-55
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    MEF replaced the categorization mechanism per request from the AB reviewers. The beta specification document does not define the compliance requirement for MEF.

  • Reported: BACM 1.0a1 — Mon, 5 Dec 2022 18:54 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This issue duplicates issue BACM-97

    This issue duplicates BACM-97

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Compliance statements for shortcuts and touchpoints hard to evaluate

  • Key: BACM-26
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Compliance statements for shortcuts and touchpoints, while these are optional compliance points, seem hard to evaluate.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:40 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This issue should be merged with BACM-97

    This issue should be merged with issue BACM-97

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Incomplete Symbols and Abbreviations - section 5

  • Key: BACM-15
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Section 5 Symbols and Abbreviations is largely empty. There are, however, a number of acronyms used within the submission that should be specified there. The acronyms present in the listing of Normative References is fine as is, but “SPARQL”, “OWL” or “OWL 2” perhaps, and “RDF” (RDF* is listed in the normative references, but the citation does not spell out the acronym).

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 16:46 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    RDF, OWL, SPARQL and RDF are references, not symbols or abbreviations*

    Change the places where these abbreviations are used to make it clear that they are references. Update the Non-normative references to be the current versions of each specification

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Revise the definition of shortcut to eliminate virtual associations

  • Key: BACM-85
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The definition of shortcut does not match its expression in the MOF translation.

  • Reported: BACM 1.0a1 — Mon, 27 Feb 2023 02:12 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Changes to 7.2.1 and 8.1 to clarify the interpretation of <<shortcut>>

    Changes to 7.2.1 adopted in BACM-44 and BACM-39 clarify that <<shortcut>> stereotypes are treated as <<class>> stereotypes with the addition of specializing BACMShortcut. No changes are proposed in this resolution.
    Changes to 8.1.1 clarify how <<shortcut>> associations are represented in the MOF compliant XMI and how the OCL constraints representing the shortcut semantic are structurally specified and how they should be implemented by a modeling tool.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Eliminate duplicate association names in EA model

  • Key: BACM-98
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    There are duplicate association names in the EA model. Because nearly all of these associations are stereotyped with <<class>> or <<shortcut>>, they are transformed into a class association pattern in MOF and duplicate names for classes are not allowed. The transformation program de-duplicates these names, but coherence is lost between the UML model of the specification (and the specification document generated from the UML model) and the generated MOF XMI.

  • Reported: BACM 1.0a1 — Thu, 27 Apr 2023 16:13 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Rename duplicate named association in the UML model

    Rename the duplicate named associations by suffixing them with an underscore and a number. Add prose to section 7.2 of the document to describe the effective interpretation.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Eliminate same named association with common src transformation rule

  • Key: BACM-100
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Section 7.2 identifies a case where same named associations with identical src end types are to be treated as a single association with dst end types that are a union of the end types of the designated associations. This can be eliminated by substituting an abstract class that is a superclass of the class to be unioned and having the dst type be this superclass. This change simplifies the transformation program and eliminates possible misunderstanding of the specification.

  • Reported: BACM 1.0a1 — Thu, 27 Apr 2023 17:52 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Add abstract superclass and terminate single association in superclass

    UML does not provide a way to specify multiple types for association ownedEnds or a semantic that would interpret this case as a union. Change the UML model to add an abstract superclass in the three cases where this occurs in the model and terminate a single association at this superclass. Add generalization arrows from the classes to be unioned to this superclass. Then delete 7.2.6 from the specification document. The new superclasses are JSTP in the ValueFit diagram, APCICB in the OutsourcedServiceOfferingDiagram and VSVSS in the Process diagram.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Replace IRI uml:Class in BACM_Model with IRI uml:DataType

  • Key: BACM-112
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    IRI is not a primitive type in UML. In the beta document, a class with the name IRI was used to represent an IRI type. But, the IRI type is better represented in UML as a DataType.

  • Reported: BACM 1.0a1 — Tue, 2 May 2023 01:07 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Replace class named IRI with datatpe named IRI

    Delete the class named IRI. Create a datatype named IRI. Change the type of the resourceIdentifier ownedAttribute to refer to the datatype named IRI. Change the pkgele.py module to handle uml:DataType elements.
    Change the BACMMOF2OWL.py program to recognize the IRI datatype and map to xsd:anyURI.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Diagram 7.3.6.5 Service Offering - overlapping associations

  • Key: BACM-118
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The "recordedAs" and "stateOf" associations between Outcome and AbstractBusinessObject overlap.

  • Reported: BACM 1.0a1 — Mon, 8 May 2023 21:40 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Edit model to separate affected associations

    Edit model to separate affected associations and republish

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Regenerate the specification document from the EA model

  • Key: BACM-79
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Following vote #3, the specification document was not completely updated as the result of an editing mistake. Consequently, some elements that were deleted in the BACM_Model package are referenced in the diagrams and prose of other packages.

  • Reported: BACM 1.0a1 — Thu, 2 Feb 2023 16:53 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    This issue is about the process of producing the specification and not its content

    N/A

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Inconsistent ownedEnd quantification in special associations (owns, ...)

  • Key: BACM-74
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The quantification patterns for the special associations (owns, generalizes, aggregates) are inconsistent in the specification and the MOF XMI file.

  • Reported: BACM 1.0a1 — Thu, 5 Jan 2023 18:21 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This issue is covered by BACM-83 that is resolved by BACM-90

    The resolution of BACM-83 by BACM-90 was adopted by the FTF in Ballot #8

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Entry- and Exit-Criteria missing

  • Key: BACM-89
  • Status: closed  
  • Source: Business Architecture Guild ( Mr. Hermann Schlamann)
  • Summary:

    Metamodel of Business Architecture Guild defines two relationships between Value Stream Stages and Value Item labeled as Entry Criteria and Exit Criteria. These relationship are missing in the BACM.

  • Reported: BACM 1.0b1 — Sun, 30 Oct 2022 08:56 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This duplicates BACM-38

    This duplicates BACM-38 which has been approved

  • Updated: Mon, 2 Oct 2023 12:56 GMT

The BACM specification does not document XML for interoperability

  • Key: BACM-75
  • Status: closed   Implementation work Blocked
  • Source: Agile Enterprise Design ( Mr. Fred A. Cummins)
  • Summary:

    The BACM specification, diagrams and text, specifies the BACM model using stereotypes that are not consistent with MOF. Consequently, the XML of the specified model is translated to a MOF-compliant XML as required by the RFP and interoperability of implementations. Both XML models are unnecessarily complex since there is no need to use stereotypes. MOF associations are sufficient, and the model would be more straightforward. The implementation Intent can be adequately specified in text with constraints, if necessary. The intent appears to be an effort to over-specify the expected method for development of an application of the model.

  • Reported: BACM 1.0a1 — Mon, 9 Jan 2023 01:04 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    No changes are made to the specification

    As noted in the comment of 2/16/2023, the submitters decided to resolve the conflict between visual and descriptive complexity in the specification document by using stereotypes in a UML model that is transformed into a MOF model. The issue author feels that the specification document should actually use the MOF model and not the UML model. It is not an OMG requirement to do this and other specifications have taken this path prior to BACM. Addressing this issue would require months of work in creating a new document that would be very different from that approved by the AB and the DTC and would likely require re-approval. It is not clear that this degree of change would comply with the P&P policies for FTFs. Consequently, this proposal recommends rejection of the issue.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Can other property names in this specification be “modified”?

  • Key: BACM-71
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The issue refers to the metamodel schema for instancing n-ary associations that are represented in the metamodel by an association stereotyped class and a single association named "related". The specification text states that when an instance is created, the legs of the instance instantiate the "related" meta-association but may be assigned distinct (role) names. The UML specification uses a similar device to allow n-ary associations from its MOF metamodel. In BACM, such n-ary associations are typically restricted to instances of a specific meta-class (e.g. AbstractBusinessObject). NOTE: this issue was accidentally combined with BACM-34 and is separated with this issue.

  • Reported: BACM 1.0a1 — Wed, 28 Dec 2022 18:01 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    Changing of names is allowed in instancing

    When an instance is created of an association, the instance becomes a member of the association type. When instances can be named, there are no restrictions on the names that can be used. When an association instance is created, the link ends become instances of the owned ends and member ends of the association and must satisfy the semantics of those owned ends and member ends with respect to instance types and quantification. These instances are reinterpreted as MOF associations, creating a new MOF model that is consistent with the MOF metamodel.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Incorrect shortcut specification of Capability supports ValueStreamStage

  • Key: BACM-91
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The beta document describes ValueStreamStage produces ValueItem as a shortcut association and also describes Capability supports ValueStreamStage as a shortcut association, creating an unresolvable mutual dependency. In addition, the prose describes ValueStream produces ValueProposition as a shortcut association, but this is missing from the EA model

  • Reported: BACM 1.0a1 — Thu, 6 Apr 2023 19:28 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Change EA model and regenerate diagrams and prose

    Change the stereotype of ValueStream produces ValueProposition to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueProposition aggregating some ValueItems produced by ValueStreamStages owned by the ValueStream..
    Change the stereotype of ValueStreamStage produces ValueItem to <<shortcut>> and add PathSpecifications tagged value to the produces association to implement the constraint that this association is consistent with the ValueItem valuing some Outcomes produced by Capabilities that support the ValueStreamStage.
    Change the stereotype of Capability supports ValueStreamStage to <<class>> and delete the PathSpecifications tagged value.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Import SMM and specialize some SMM classes for integration

  • Key: BACM-14
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The specification displays classes with SMM:: namespace designations, but the model does not explicitly import SMM and it does not explicitly specialize the corresponding SMM metaclasses. By formally importing SMM, the BACM metamodel would be coupled with a particular version of SMM and would have to be revised to accommodate integration with other versions of SMM. On the other hand, the current normative text may not be sufficiently precise to allow an implementer to create a conforming implementation of this integration.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 16:42 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    The beta specification is clear and unambiguous about inclusion of SMM

    The beta specification defines specializations of SMM classes and associations in the SMM subpackage. Adding an import of the SMM metamodel to the BACM metamodel, along with the specializations explained in the BACM specification would not add any new information to the specification.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Remove category and categorization from the specification

  • Key: BACM-72
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This issue was originally raised in BACM-17 which was proposed to be closed by BACM-54. However, the specification still references meta-classes no longer in the model (e.g. ValueCategory in 7.2.3.1). These references should be replaced.

  • Reported: BACM 1.0a1 — Wed, 28 Dec 2022 18:26 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Makes changes to document shell docx and the EA model to eliminate the terms and concept

    Change the document shell docx to eliminate mentions of ValueCategory and categorizes. Regenerate the text documentation from the model and replace the affected sections of the document (Capability and Customer) with the new sections.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

ValueProposition aggregates ValueProposition - owns vs aggregates

  • Key: BACM-81
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The specification has this as an aggregates association but the quantification suggests ownership. Resolve whether owns or aggregates and change owned end quantification to match.

  • Reported: BACM 1.0a1 — Fri, 3 Feb 2023 18:55 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Merge this issue with BACM-83

    The proposal to resolve BACM-83 is able to address this issue. A convincing argument to restrict the associations between ValuePropositions to being only that of owning was not found. The default model will allow generalizes, owns and aggregates at the discretion of the business architecture modeler.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Provide an OWL 2 ontology as a machine readable file

  • Key: BACM-21
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Section 0.5 - It would be nice to have the OWL 2 ontology provided as a machine readable file, even if only informative. Did the generation use MOF2RDF?

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 20:50 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    The OWL 2 Turtle draft ontology made available as informative adjunct

    On approval, an OMG document number will be obtained for the attached OWL2 Turtle file (or its revision).

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Material in Section 0.6 that should be in the specification

  • Key: BACM-25
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Section 0.6 has a very useful description that would be better in the body of the spec - section 0 will get stripped off after adoption.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:35 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Duplicated by issue BACM-21

    BACM-21 requests the addition of an OWL 2 ontology as an informative document. There is a proposal to provide this document. When that proposal is approved, this issue should be resolved as a duplicate of BACM-21.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Failure to meet RFP requirement 6.5.2.4 regarding specification alignment

  • Key: BACM-20
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    There seems no attempt to meet requirement 6.5.2.4 “Submitters shall identify shared terms and clarify any differences in definitions in UPDM/UAF, VDML, ArchiMate™, TOGAF Content Metamodel, BPMN, DMN, and CMMN.“

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 17:31 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This issue should be merged with BACM-6

    BACM-7 (a proposal to resolve BACM-6) which has been adopted by vote, proposes to remove Section 9 from the specification. Another issue has been recorded to publish the Section 9 content and other material as informative guidance. There are no proposals at this time to resolve this issue.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Section 3 reference to SIMF


The term "user" is imprecise

  • Key: BACM-34
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    It’s not clear who “the user” is at the end of para 4 and elsewhere. Can other property names in this specification be “modified”?

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 17:14 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Replace ambiguous uses of "user" in section 7 with "business architecture modeler'

    Replace 6 occurrences of "user" in 7.2.1 with the term "business architecture modeler".
    Replace 2 occurrences of "user" in 8.1.2 with the term "business architecture modeler".

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Mix of version specific and non-specific references

  • Key: BACM-27
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    It’s odd that some references are version-specific, others are not - was that intentional?

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:49 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Revise the reference section

    Replace all version specific URLs with the generics.
    Move references to the non-normative subsection.
    Delete RDF-star and OpenCypher references

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Corrections to EA model to fix definitions and glossary

  • Key: BACM-77
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Element notes fields for BACMEntity, BACMRelation, BACMPlainEntity and BACMShortcut have Usage Notes: instead of Usage:. This causes the glossary generation tool to operate incorrectly.
    IRI notes lack the Definition: bold prefix

  • Reported: BACM 1.0a1 — Wed, 1 Feb 2023 19:52 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Fix the notes in EA then regenerate the document.

    N/A

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Make changes to the spec to enable the production of MOF compliant XMI

  • Key: BACM-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    As a condition of acceptance by the Architecture Board, the FTF is required to produce a MOF compliant XMI file. MOF does not allow profiles or association classes. To allow a faithful translation of the EA model, some new classes were introduced that translate stereotyped associations into a pattern of a class and two associations. To facilitate this, some new classes were added to the BusinessElement diagram and some redundant classes and generalizations were removed. Prose explanations should be added following the new BusinessElement diagram

  • Reported: BACM 1.0b1 — Mon, 20 Jun 2022 22:17 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Replace 7.3.1.1

    This proposal incorporates model changes to support the generation of MOF-compliant XMI by transforming the XMI generated from the source model according to the normative specifications in section 7.2. It also incorporates editing changes that were made in the BACM_Model package to remedy a failure to update the text associated with changes to the diagrams published in BACM 1.0b1 (dtc-22-06-01).
    Because the diagrams and text of section 7.3 are generated from the UML model, the number of editing changes would be very large. Consequently this proposal replaces 7.3.1.1 in its entirety. These changes do not effect the remainder of the specification.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Replace diagram 7.3.1.1.3 and following text

  • Key: BACM-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    During the AB approval process, the BACM_Model package diagram was changed to eliminate imports of the other packages. The submitters failed to include these changes in the final document that was sent to the OMG publications team for re-publication as dtc-22-06-01.

  • Reported: BACM 1.0a1 — Tue, 21 Jun 2022 16:46 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Close this issue as it duplicates an issue already in ballot

    Duplicate of ballot #1 Issue #1

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Rewrite section 7.2.2 for clarification

  • Key: BACM-45
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The prose of this section is difficult to understand. It needs to explain how an instance of a class can be a class and how individuals are represented as singleton sets. It is unclear that the singleton set interpretation can be imposed in the MOF model without a change to the metamodel to add an Individual abstract metaclass that is specialized by the MOF classes resulting from the translation of <<individual>> stereotyped EA classes.

  • Reported: BACM 1.0a1 — Thu, 17 Nov 2022 21:03 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Section 7.2.2 is replaced and Section 7.2.3 is deleted

    The attached Word document replaces section 7.2.2.
    Section 7.2.3 is to be deleted in entirety and the following parts of 7.2 are to be renumbered accordingly.

  • Updated: Mon, 2 Oct 2023 12:56 GMT
  • Attachments:

Remove or replace mentions of category and categorization

  • Key: BACM-17
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The categorization mechanism was removed from the specification draft and replaced by requiring MEF, which effectively allows the specification of stereotypes in a conforming tool. As in UML, these stereotypes may carry properties not present in the model instances. Mentions of category and categorization remain present in the beta specification document.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 17:00 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    This issue was resolved prior to publication of the beta specification

    The categorization mechanism was replaced prior to AB approval of the beta specification. The issue was recorded to preserve the history of changes. The beta specification requires MEF, which can be used to create profiles allowing for the categorization of BACM model elements by the definition of stereotypes and application of these stereotypes to model elements.
    An issue has been created to address compliance requirements for MEF

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Remove Section 9 and republish as a separate, informative adjunct document

  • Key: BACM-6
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Section 9 consisted of responses to RFP requirements to address alignment with other OMG specifications. This information should probably have been placed in Section 0 of the submission and be deleted prior to publication as a beta specification. Moreover, the information in this section is informative and is expected to evolve rapidly as the BACM specification is used by architects. Consequently, the recommended action is to delete Section 9 and republish it as an informative adjunct to the normative specification.

  • Reported: BACM 1.0a1 — Tue, 21 Jun 2022 20:08 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Remove Section 9 from the specification document

    Section 9 consisted of non-normative responses to non-mandatory requirements in the RFP about alignment of BACM with other OMG specifications and with IT architectures. This material is provided as guidance to architects and organizations wishing to use BACM in conjunction with other OMG and non-OMG specifications. The material is expected to change rapidly. The proposal is to remove Section 9 from the specification and publish it as an informative adjunct document.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Use of term "parent" confusing

  • Key: BACM-30
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The use of “parent” to mean not a superclass but the class of an instance is unconventional and likely to confuse.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:57 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Replace "parent" with more specific terms

    Replace use of the term "parent" with more precise terms such as "meta-class", "aggregator", "owner", "generalizing"

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Touchpoint notion does not require query capability

  • Key: BACM-23
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The notion of Touchpoint as defined in the RFP does not IMO require the open-ended query capability included here. Which is completely under-specified. On the other hand it does not seem to provide the Though it does say (in 8.2) “2) the modeling tool can integrate the BACM model with another model using a supplementary metamodel to join the concepts in the BACM metamodel to the concepts in the other model;” it does not provide that metamodel or any more details. It seems to me that this is what the RFP was looking for.specific links between classes in different metamodels that the RFP seemed to have in mind. Rather than allowing modelers to link specific elements from different models, it requires them to formulate some sort of query.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:21 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    The issue is moot as the query mechanism is not present in the beta specification

    This issue was addressed prior to the release of the beta specification as the query mechanism in the submission was replaced by the external reference mechanism adopted from SysML V2. This change was approved by the AB.
    However, an example was presented in Annex B of the beta specification, and this example has been removed in Ballot #1 of this FTF. So there is no longer any substance to this issue.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Metamodel level terminology obsolete

  • Key: BACM-29
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    There is extensive use of “M1” which is terminology that is no longer part of MOF (it was dropped at MOF 2.0). “M1” should therefore be explained/included in the Terms.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:54 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Define M1 in section 4 of the specification

    The document uses the term "M1" to designate models that are derived from the BACM metamodel. The OMG has dropped this terminology, so its continued use in the specification must be supported by a definition. This proposal provides such a definition in section 4 of the specification.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

ResourceRole AssignTo association in Organization diagram 7.3.4.1 reversed

  • Key: BACM-73
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The text definition of the AssignTo association between Resource and ResourceRole clearly states that the Resource is AssignedTo the ResourceRole, defining the direction of the association as being from Resource to ResourceRole. However, in the diagram and the generated test, the direction of this association is reversed.

  • Reported: BACM 1.0a1 — Wed, 4 Jan 2023 17:55 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Edit the diagram in the EA model to reverse the direction of the association

    Edit the EA model to change the association direction.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Meaning of "generalization" of instances

  • Key: BACM-36
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    Likewise “The user may also indicate that one instance generalizes another, but the implementation is not obligated to determine that the instance model is consistent.“ - what does generalization even mean between instances and won’t it depend on the metaclass? E.g. what would it mean to be a generalization of LegalEntity IBM Corp?

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 17:39 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Rewrite and consolidate prose description of instancing

    This proposal is mostly resolved by the proposal attached to BACM_44 (to resolve issue BACM-43) and a proposal (BACM-67) to resolve issue BACM-45.
    The remaining part of this issue, that the BACM metamodel does not have a distinct domain of individuals (viz. the domain of classes and object properties as distinct from the domain of individuals and assertions) is unresolved. This proposal creates a separate issue (BACM-68) with a proposal to defer.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Semantic treatment of n-ary associations as tuples

  • Key: BACM-37
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The treatment of n-ary associations as a set of distinct tuples seems unnecessary and logically suspect.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 17:53 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    Substance of the issue is unclear

    As noted in the comments, the use of tuples to define semantics of n-ary associations is well-defined in the literature and is neither unclear nor "logically suspect".
    The use of "tuples" occurs in 7.2.1, which is rewritten in proposal BACM-44 (to resolve issue BACM-43).
    It also occurs in 7.2.5. This section was reviewed and found to be both clear and logically sound.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Beta document does not address all the RFP perspectives

  • Key: BACM-18
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The RFP says “This RFP defines scope in terms of a collection of perspectives”, however the submission only seems to be addressing 6 of the 10 perspectives in the RFP (Policy, Information, Initiatives, Value seem to be missing) in addition to the declared omission of an IT alignment.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 17:08 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    The RFP only requires a Capability perspective

    The RFP only requires a Capability perspective. The submission includes that and other perspectives deemed as very desirable in the RFP.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

No glossary in the package descriptions

  • Key: BACM-19
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    There is no Glossary in the perspectives as required in 6.5.2.2 of the RFP: only a combined glossary of camelcased metaclass names.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 17:25 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    The Glossary in Annex A is deemed sufficient

    It is possible to read the RFP as requiring a glossary for each domain of the metamodel. However, this was not the understanding of the RFP writers and no issue was raised during the RFP issuance. The specification provides a required glossary in Annex A.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

Section 1 - Scope should describe the submission, not the RFP

  • Key: BACM-22
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This important Scope section should describe the spec in its own right and not reference the RFP. Nor, indeed, what other OMG models may or may not exist.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 21:00 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    The issue appears inapplicable to the beta specification

    This issue appears to address a prior submission, not the specification as approved by the AB and issued as dtc-22-06-01.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

The term "class association" is an improper use

  • Key: BACM-24
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The term “class association” is used in several places - it should be “association class”.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 15:27 GMT
  • Disposition: Closed; No Change — BACM 1.0b2
  • Disposition Summary:

    Both class association and association classed are used in OMG specifications

    A review of OMG documents and Policies and Procedures was unable to determine that this was an improper use.

  • Updated: Mon, 2 Oct 2023 12:56 GMT

BACM semantic specification unclear

  • Key: BACM-31
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    7.2.1 states the following “UML visual modeling is used in this specification as a visual notation for an underlying graphical predicate model. The underlying model can be given a concrete form in RDF* (https://arxiv.org/pdf/1406.3399.pdf) or a property graph language (e.g. Cypher openCypher_V9). Most of the semantics of the metamodel (except for shortcuts and co-occurrence constraints) can be specified in OWL 2.” Which is not really true since those forms are not actually provided and what is specified is a MOF metamodel, which has different semantics than UML. Though the ODM specification does provide an interpretation and a profile for use of UML for RDF, this has not been referenced in this specification.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 16:20 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Duplicates BACM-44 a proposal to resolve BACM_43

    This issue duplicates part of BACM-43 and is resolved by the revision of 7.2.1 proposed in BACM-44.

  • Updated: Mon, 2 Oct 2023 12:55 GMT

Remove Annex B from the specification document

  • Key: BACM-5
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The first part of Annex B (B1) is irrelevant given the changes made to the implementation of the <<shortcut>> stereotype in both the model and the MOF-compliant XMI. These changes were approved by the Architecture Board and accepted by the DTC. But the required changes to the specification were not made prior to publication.
    The second part of Annex B (B2) while technically correct, does not match the model shown in the diagrams. It is planned that this part will be rewritten and submitted as an informative document associated with the specification.
    The recommendation is to remove Annex B in its entirety

  • Reported: BACM 1.0a1 — Tue, 21 Jun 2022 19:58 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Remove Annex B from the specification document

    Remove Annex B from the specification document. An issue is created to determine the disposition of the Annex B content.

  • Updated: Mon, 2 Oct 2023 12:55 GMT

Use of "leg" terminology to describe relationships

  • Key: BACM-32
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    It’s not clear why the “leg” construct is introduced when association classes already exist in UML and have properties instead of legs. As do n-ary associations. Though neither are part of MOF officially, I don’t see the justification of the “leg” terminology.

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 16:32 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    The term leg is defined in BACM-44 the proposal to resolve BACM-43

    The term "leg" is justified because this section of the specification is defining the translation from the UML-based diagrams in the specification to MOF-compliant XMI. Since n-ary associations and association classes are not part of MOF, these forms are translated (reified) into classes and generated associations. The term "leg" designates the generated associations to distinguish them from other associations.
    If BACM-44 is approved, this issue should also be resolved

  • Updated: Mon, 2 Oct 2023 12:55 GMT

Rewrite the second paragraph of section 7.2.1 to clarify the relationship between the specification document and the normative XMI

  • Key: BACM-41
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The paragraph state:
    For an implementation of the metamodel, the normative XMI that is part of this specification is intended to be an unambiguous and precise way to create an implementation that is equivalent to the underlying graphical predicate model. The non-normative XMI that is provided with the specification must be interpreted according to a set of rules to create a conforming implementation that is not based on MOF.
    This paragraph is unclear and refers to a non-normative XMI that is NOT part of the specification.

  • Reported: BACM 1.0a1 — Thu, 17 Nov 2022 18:16 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Replace the second paragraph of 7.2 in its entirety

    Replace the second paragraph of 7.2 -
    "For an implementation of the metamodel, the normative XMI that is part of this specification is intended to be an unambiguous and precise way to create an implementation that is equivalent to the underlying graphical predicate model. The non-normative XMI that is provided with the specification must be interpreted according to a set of rules to create a conforming implementation that is not based on MOF."
    with
    "An implementation of the specification must conform to the metamodel expressed in the normative XMI file that is part of the specification. The diagrams in this document make use of stereotypes to eliminate detail that is present in the normative XMI file and make the diagrams more readable. The following paragraphs and subsections in this document explain how to interpret these stereotypes and how they are translated in the MOF-compliant, normative XMI file. In any case where the diagram and the interpretation rules appear to disagree with the normative XMI, the normative XMI is the authoritative source."

  • Updated: Mon, 2 Oct 2023 12:55 GMT

The 3rd paragraph of 7.2 is unclear

  • Key: BACM-43
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    This paragraph states:
    "In general, metamodel classes in the diagrams in this document will become meta-classes (class prototypes or templates) in an implementation. However, classes stereotyped as “association” will become associationclasses. These entities are binary or n-ary associations that can be specialized (from other meta-associationclasses), have features, and participate in other associations. UML binary associations with a <<class>> stereotype should be implemented as binary meta-associationclasses."
    This description is unclear. It mentions association classes that are not part of MOF. It does not adequately describe how to interpret the stereotypes <<class>>, <<association>>, <<shortcut>> and <<individual>>

  • Reported: BACM 1.0a1 — Thu, 17 Nov 2022 18:59 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    Attached file replaces 7.2.1 para3 et seq

    The description of the translation to MOF is completely rewritten and all paragraphs of section 7.2.1 starting with paragraph 3 are replaced by the attached Word document content.

  • Updated: Mon, 2 Oct 2023 12:55 GMT
  • Attachments:

Unclear specification of instantiation of variable arity relationships

  • Key: BACM-35
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The last para says “In this case, instances may be created with an arity specified by the user and with instance leg names specified by the user.” but no indication as to how this might be done (such dynamic meta-level property renaming or multiplicity changing is not even part of SMOF).

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 17:19 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Add a reference to revised section 7.2.2 in the paragraph of 7.2.4.2

    A revision to section 7.2.3 is proposed in BACM-44. This revision explain that some model elements that are instances of metaclasses represent collections of things with identical or similar characteristics (i.e. they are sets defined by the structural properties of the model element). This association allows the modeler to create semantic hierarchies of such model elements.

  • Updated: Mon, 2 Oct 2023 12:55 GMT

Deliver MOF compliant XMI for specification

  • Key: BACM-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    The XMI file exported from the EA model is not MOF compliant. It includes class-associations and a profile with stereotypes that effectively define cass associations. Additionally, the semantics of "shortcut" stereotypes on associations must be expressed in OCL.

  • Reported: BACM 1.0b1 — Sun, 2 Oct 2022 16:46 GMT
  • Disposition: Resolved — BACM 1.0b2
  • Disposition Summary:

    A MOF-compliant XMI file is produced by a transformation program

    A Python 3 program was written to input the exported EA XMI file, perform the transformations defined in section 7.2 of the beta specification, and output a MOF-compliant XMI file. This file has been subjected to automated and hand checks for correctness. It has also been analyzed by the OMG XMI compliance tester, producing some minor errors.

  • Updated: Mon, 2 Oct 2023 12:55 GMT
  • Attachments:

Usage of "leg target" terminology unclear

  • Key: BACM-33
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    It gets further confusing in “the target end of a leg” when early it says that a leg itself can be a “target” (or source).

  • Reported: BACM 1.0a1 — Thu, 20 Oct 2022 16:56 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    This issue is resolved by proposal BACM-44 to issue BACM-43

    The revisions proposed in BACM-44 explain the "leg" as designating associations generated in the transformation to MOF-compliant XMI that reifies n-ary associations and association classes. The term "leg target" refers to a model element that is at the opposite end of a "leg" association from the metaclass that is generated to represent the n-ary association or class association. A "leg target" may be a generated class resulting from this transformation process. The abstract syntax for this is in Diagram 7.3.1.6 and the transformation description in the proposal BACM-44

  • Updated: Mon, 2 Oct 2023 12:55 GMT

Incomplete description of association reification

  • Key: BACM-16
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James Rhyne)
  • Summary:

    · Section 7.2.1 Interpreting… “src” and “tgt” are introduced, but not defined. Relatively trivial as they are not referenced again, but specifying what they stand for in the first instance is a best practice.

  • Reported: BACM 1.0a1 — Wed, 19 Oct 2022 16:53 GMT
  • Disposition: Duplicate or Merged — BACM 1.0b2
  • Disposition Summary:

    Issue duplicated by BACM-43

    This issue duplicates the issue in BACM-43 that is resolved by an existing proposal BACM-44.

  • Updated: Mon, 2 Oct 2023 12:55 GMT