SMM 1.1 RTF Avatar
  1. OMG Issue

SMM11 — SMM does not allow for a formula, but only has a simple accumulator

  • Key: SMM11-129
  • Legacy Issue Number: 17483
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In industry, it is common to have composite measures with formulas like “A * (1 + B) / C”, whereby A, B and C are atomic measures. In this example, according to SMM, you would not have 4 measures, but 6, e.g.:
    • 3 direct measures: A, B, C
    • A rescaled measure, with formula “1+B”
    • A binary measure, with functor “times”, to multiple A and the rescaled measure from above.
    • A ratio measure to divide the previous one by C.
    Though this is technically OK, it is not always handy, as “given” industry measures would have to be refactored into smaller ones.
    I see a good reason why SMM measures are structured as they are: You have good grip than on the formula, the functor, etc. Because if you would allow for formula's like "( A * (1 + B) ) / C ", you would have difficulty in reconciling the various associated "sub" measurements with the formula of the measure that relates to the collective measurement. String parsing, etc.
    SMM in its current form is very structured, but that would make interpretation and implementation also very straightforward. That is a big advantage and I like that.

    But still I have trouble with e.g. industry-given libraries of VCG, SCOR, KPI LIbrary, etc., that though have composite measures with such more complicated formula's.

    How to import such measures into an SMM based library?
    Once imported, you could create more specific SMM measures, and refer to the original one as "equivalent" measure. But the main problem is that it cannot even be imported, as a collective measure in SMM does not allow for a formula, but only has a simple accumulator.

    How can this be resolved ?

  • Reported: SMM 1.0 — Fri, 13 Jul 2012 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    The RTF discussed this issue (at length) and found a resolution which addressed the core concern within the issue while preserving the general design pattern of SMM. It was agreed to improve the expressiveness of CollectiveMeasure by adding a formula to it, as well as the possibility for a custom accumulator (being an association to Operation). Hence the resolution includes the following:
    • Add optional formula (string 0..1)) to DimensionalMeasure (every DimensionalMeasure can have one). Formulas are always descriptive and optional. Formula is a comment which briefly presents the Measure’s calculation in an algebraic manner. For example, “X + Y” or “Height * Width”. The decision to provide a formula would be entirely up to the SMM library designer. SMM designers can then write SMM libraries in a top down manner by turning DirectMeasures (or NamedMeasures) into CollectiveMeasures, BinaryMeasures and RescaledMeasures as needed. Also, a SMM design tool might fill in the descriptive formula when designer writes libraries bottom up. Unlike formula’s, operations are operational and defined with a coherent program fragment. The programming language must be stated and the fragment is expected to be well formed given the appropriate context.
    • Add literal value “custom” to the Accumulator enumeration, and rename “operation” to “customAccumulator”. This property is defined as association to Operation. The custom accumulator of CollectiveMeasurement is only defined when its accumulator is “custom”.
    In order for the meta-model to remain consistent and for the resolution to be generic, it was also agreed to further improve the expressiveness of some of the other Measures in similar ways, namely of BinaryMeasure per issue 17503 and of RescaledMeasure per issue 17484. So that the resolution of the three issues is consistent with each other.

  • Updated: Wed, 8 Jul 2015 11:44 GMT