1. OMG Issue

BMMF2 — Section: 7, ,8, 9 - pages 16, 40-42, and 51

  • Key: BMMF2-5
  • Legacy Issue Number: 10114
  • Status: closed  
  • Source: Rule ML Initiative ( John Hall)
  • Summary:

    Assessment In BMM 1.2, as published by the BRG and adopted by the OMG, “Assessment” is defined as: “a judgement that an Influencer affects the employment of Means or the achievement of Ends” Each Assessment: - Is a judgment about at least one Influencer - Is about the effect on least one End or Means (but not necessarily both) The UML class model submitted with the RFC shows both an End and a Means being required for an Assessment. What is the best way to represent Assessment in a MOF-compliant class model for BMM so that the constraint is correctly modeled, and BMM-compliant tools will support “End or Means or both - but not neither”?

  • Reported: BMM 1.0b2 — Tue, 22 Aug 2006 04:00 GMT
  • Disposition: Resolved — BMM 1.0
  • Disposition Summary:

    In the BMM as published, "Assessment" is an objectified ternary fact type with roles played by Influencer, Means and End, and the constraint that at least one Influencer and at least one End or Means must participate in a fact of this type - there might be no participating Ends or no participating Means, but no participation from either is not allowed. This cannot be handled in a MOF model.
    The proposed resolution is:
    In the overview UML diagram in Ch 7 and Figure 8.13 in Ch 8, represent Assessment as a class with binary associations with Influencer, End and Means (as well as Potential Impact)
    Specify these associations as:
    · Assessment is judgment of Influencer (one to many) [This would resolve Issue 10592]
    · Assessment affects achievement of Ends (many to many) [This would resolve Issue 10593]
    · Assessment affects employment of Means (many to many)
    State the constraint "at least one End or Means but not necessarily both" in the concepts catalog in Ch 9.
    Note: if you do not like the names suggested, please suggest alternatives. There are no names for them in the BMM as published.
    The changes to the UML model are illustrated in the fragment:

    This diagram illustrates the structure. Class names are shown in CamelCase, and association names include class names. Depending on what is agreed for resolution of Issue 10090 (UML Associations), the names might change, but the structure would be the one proposed.

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