1. OMG Mailing List
  2. Structured Metrics Metamodel (SMM) 1.2 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: smm-rtf
  • Issues Count: 39

Issues Summary

Key Issue Reported Fixed Disposition Status
SMM12-89 Better document rendering aspects of the measureLabelFormat and measurementLabelFormat of Measures. SMM 1.1 open
SMM12-170 Outbound associations wrongly defined SMM 1.1 open
SMM12-160 Fix and improve CollectiveMeasurement examples SMM 1.1 open
SMM12-167 GradeFrom association wrongly named in Figure 10.2 SMM 1.1 open
SMM12-165 Binary measurement, not collective measurement SMM 1.1 open
SMM12-137 Scope clause restricts SMM to software measures. SMM 1.1 open
SMM12-138 SMM Introduction Overview clause is too software measures centric. SMM 1.1 open
SMM12-150 SMM is presumptuous about how measurands must relate SMM 1.1 open
SMM12-91 Move constraint on the “product” accumulator in CollectiveMeasure to CollectiveMeasurement. SMM 1.1 open
SMM12-115 Measure to Scope association missing from Measurable Characteristic and Scope diagram SMM 1.1 open
SMM12-153 Scalar misused in attributes subclause of RescaledMeasure Class SMM 1.1 open
SMM12-141 Superclasses of RankingMeasureRelationship and GradeMeasureRelationship are inconsistent SMM 1.1 open
SMM12-155 GradeMeasurement value attribute identifies a grade, not a rank SMM 1.1 open
SMM12-105 The wording “base measure(ment)” is ambiguous. SMM 1.1 open
SMM12-87 Relax constraint requiring both boundary points of an Interval. SMM 1.1 open
SMM12-149 Querying the BaseMeasureRelationship counterpart SMM 1.1 open
SMM12-146 General text for Scope class (10.4) assumes class attribute is given. SMM 1.1 open
SMM12-151 Description of RescaledMeasurement class is too restrictive SMM 1.1 open
SMM12-158 Unit of Measure definition should refer to Dimension SMM 1.1 open
SMM12-144 Superclass of RatioMeasure should be BinaryMeasure SMM 1.1 open
SMM12-134 ObservationScope Class semantics sub-clause is mostly non-normative SMM 1.1 open
SMM12-133 "From" associations on Dimensional Measure/Measurement are poorly described. SMM 1.1 open
SMM12-140 Wrong superclasses for NamedMeasurement and RescaledMeasurement SMM 1.1 open
SMM12-128 Replace boolean with UML/MOF “Boolean”. SMM 1.1 open
SMM12-127 Bad definition of rescales association in 12.3 RescaledMeasure Class SMM 1.1 open
SMM12-122 Conformance clause restricts SMM to software measures. SMM 1.1 open
SMM12-119 CountingMeasure operation should not be confused with Scope.recognizer SMM 1.1 open
SMM12-97 SMM class for unit of measure of counting measures. SMM 1.1 open
SMM12-94 Replace “accumulate” variants with “combine” concerning binary measures. SMM 1.1 open
SMM12-92 Inconsistent handling of inherited attributes SMM 1.1 open
SMM12-95 Replace SMM “string” with UML/MOF “String”. SMM 1.1 open
SMM12-93 Some classes are shown in some diagrams without purpose. SMM 1.1 open
SMM12-96 Define conformance levels for SMM. SMM 1.1 open
SMM12-90 Allow more flexibility in defining a RescaledMeasure. SMM 1.1 open
SMM12-88 The definition of Formula of DimensionalMeasure should be more generally specified. SMM 1.1 open
SMM12-114 Add more parties to Acknowledgements SMM 1.1 open
SMM12-86 Show the new SMM logo in the specification. SMM 1.1 open
SMM12-78 SMM confuses "To" and "From" SMM 1.0 open
SMM12-77 Add a non-normative Clause to the SMM specification which demonstrates an SMM Library of basic Unit conversions SMM 1.0 open

Issues Descriptions

Better document rendering aspects of the measureLabelFormat and measurementLabelFormat of Measures.

  • Key: SMM12-89
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The documentation of measureLabelFormat and measurementLabelFormat in Measure does not suffice.
    measurementLabelFormat designates a rendering for measurement labels of the given Measure.

    The text needs to be clearer about purpose of these attributes, their syntax and how they work.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:23 GMT
  • Updated: Fri, 22 Sep 2017 00:27 GMT

Outbound associations wrongly defined

  • Key: SMM12-170
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The outbound associations in Measure Class and Measurement Class are incorrectly defined. The definitions refer to the associations' opposite end as "to-endpoints". But, the associations' opposite end is a "from" association.

  • Reported: SMM 1.1 — Sat, 5 Aug 2017 22:11 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

Fix and improve CollectiveMeasurement examples

  • Key: SMM12-160
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    There are issues with some figures in the spec.
    Figure 11.2, CollectiveMeasurement example, appears to assume the multiplicity of the "to" association from BaseNMeasureRelationship to DimensionalMeasurement is 0.*. It isn't. The multiplicity is 1.
    The example needs 3 BaseNMeasureRelationships, one for each base DimensionalMeasurement.

    In Figure 17.6 the accumulator field is missing. For clarity, accumulator=sum should be included. In addition, Figure 17.6 suggests to use one ObservedMeasure per each base Measurement, even when the Measure is the same. This suggests sub-optimal use of the spec and is, hence, misleading. The figure should suggest that the ObservedMeasure object can be shared.

    In both figures, Figure 11.2, as well as Figure 17.6, the by already approved issue SMM12-149 introduced mapsTo relationship is not used, while these figures are the ideal cases to demonstrate its use.

    And this immediately leads to one other, related, issue: Both figures, so, Figure 11.2 and Figure 17.6, demonstrate an important aspect of CollectiveMeasure. Namely: as long as the BaseMeasure can be shared, and as long as no in-lined rescaling parameters of BaseMeasureRelationship require any differentiation, the number of BaseMeasurements that is instantiated does not influence the definition of the BaseMeasure. Which is very important to foster re-use. So that, even while there are multiple BaseMeasurementRelationships, they may all correspond with and refer to one and the same BaseMeasureRelationship. The problem, however, is: though this is the intent of the spec, it is nowhere explicitly stated. And that is very confusing. We better fix that, by making that point very clear in the spec (the more so, as with BinaryMeasure(ment), the correspondence is never N - 1, but is always 1-1).

  • Reported: SMM 1.1 — Mon, 26 Jun 2017 18:01 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

GradeFrom association wrongly named in Figure 10.2

  • Key: SMM12-167
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Figure 10.2 "Measure Class Diagram" wrongly names the association between DimensionalMeasure and GradeMeasureRelationship. The correct name is "gradeFrom".

  • Reported: SMM 1.1 — Mon, 31 Jul 2017 14:08 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT
  • Attachments:

Binary measurement, not collective measurement

  • Key: SMM12-165
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In 11.7 BinaryMeasure class, the following sentence incorrectly references a collective measurement.

    The measurands of the base measurements need not be the same as the measurand of the collective measurement.

    It is not a collective measurement. It is a binary measurement.

  • Reported: SMM 1.1 — Sat, 22 Jul 2017 21:00 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

Scope clause restricts SMM to software measures.

  • Key: SMM12-137
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The Scope clause says "This specification defines a meta-model for representing measurement information related to any model structured information with an initial focus on software, its operation, and its design. Referred to as the Structured Metrics Meta-model (SMM), this specification is an extensible meta-model for exchanging both measures and measurement information concerning artifacts contained or expressed by structured models, such as MOF.".

    This needs to be revised:

    • "any model structured information" should just be "any MOF-based language".
    • "with an initial focus on software, its operation, and its design": This need to be changed indeed. As here it suggests that the spec is dedicated mostly to software, which is no longer correct.
    • The second paragraph of Scope (Clause 1) says "The specification does include a minimal library of software measures". Here also speaks the incorrect exclusive focus on Software measures which should be fixed.
    • Both the 2nd and 3rd paragraph of Scope (Clause 1) talk about Library of measures. However, these are different Libraries. Paragraph 2 talks about the informative Library in the Appendix, whereas paragraph 3 talks about the Library concept (Class) in the meta-model. That is not clear from the text as it currently reads, and may be very confusing to the readers.
    • The 5th paragraph of Scope (Clause 1) again talks about Software measures, as if these are the primary citizens of the spec.
    • Paragraphs 4 and 5 of Scope (Clause 1) position the spec as fully driven by ADM, going hand-in-hand with KDM, etc. That's no longer the case. SMM's scope is much broader.
    • The first paragraph after the 6 bullet points in Scope (Clause 1) talks about "static (or dynamic) code analysis and technical performance to include factors related to information utility and acceptance of the system by the organization(s) participating in an enterprise. To be objective and repeatable, such metrics need to be based on technical characteristics of the system". This suggests total software-centricity of the spec. That should be fixed per this issue. It must be broadened.
    • The second paragraph after the 6 bullet points in Scope (Clause 1) is not much better. As it talks about "the evolutionary nature of system development and the predicate value of metrics with respect to “downstream” problems" as well as "model for system development". This is all exclusively software development-bound. In the context of this issue, this has to be broadened.
  • Reported: SMM 1.1 — Mon, 28 Mar 2016 15:31 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

SMM Introduction Overview clause is too software measures centric.

  • Key: SMM12-138
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The following phrases set too much software emphasis in Clause 7.1.

    • First paragraph in its entirity: "Measurements provide data for disciplined engineering in that engineers and their managers rely on these comparable evaluations in assessing the static and operational qualities of systems."
    • Second paragraph: Totally software-dedicated..
    • Third paragraph of 7.1: here it seems a bit broader than software alone, but it is still about technical architectures, and nobody will think about business architectures here.
    • Fourth paragraph of 7.1: It talks about systems. But who will think about businesses as systems here ? Nobody, unless we give some hints of that. Because all other hints here and elsewhere are only about software
  • Reported: SMM 1.1 — Mon, 28 Mar 2016 15:35 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

SMM is presumptuous about how measurands must relate

  • Key: SMM12-150
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In 11.2, 11.7, 13.2 and 15.3, the base model is presumed to be a MOF model which is too restrictive.

    GradeMeasurement Class (clause 13.7) and RankingMeasurement Class (clause 13.9) have constraints requiring the identity between the measurands for the derived measurement and the input measurement. These constraints are beyond SMM's scope. Note that measurands are typically not defined in SMM, but in some other model. That other model (and not SMM) should, therefore, determine how measurands relate.
    In 16.4, the sentence referencing "same measurand" similarly implies a requirement which is outside SMM's scope.
    Furthermore, in 11.2, 11.7, 13.2 and 15.3, it is stated that measurands are declared in another MOF model, which is too restrictive.

  • Reported: SMM 1.1 — Fri, 9 Sep 2016 19:10 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

Move constraint on the “product” accumulator in CollectiveMeasure to CollectiveMeasurement.

  • Key: SMM12-91
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    When accumulator is "product", there must be one-and-only-one base measurement per measure, unless the units of base and collective are dimensionless. This is a constraint on CollectiveMeasurement, not on CollectiveMeasure.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:24 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT

Measure to Scope association missing from Measurable Characteristic and Scope diagram

  • Key: SMM12-115
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The association between Measure and Scope is fundamental to understanding SMM. Yet, it does not appear in Figure 10.1 (Measurable Characteristic and Scope), which is the reference diagram for illustrating measure, scope and characteristic.

  • Reported: SMM 1.1 — Thu, 3 Dec 2015 15:00 GMT
  • Updated: Thu, 31 Aug 2017 00:39 GMT
  • Attachments:

Scalar misused in attributes subclause of RescaledMeasure Class

  • Key: SMM12-153
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Scalar is used in the attribute description of offset and multiplier. The multiplier is a dimensionless number and should not be called a scalar. The offset has the same dimension as the RescaledMeasure and should not be called a scalar.

  • Reported: SMM 1.1 — Fri, 18 Nov 2016 17:08 GMT
  • Updated: Tue, 16 May 2017 00:37 GMT

Superclasses of RankingMeasureRelationship and GradeMeasureRelationship are inconsistent

  • Key: SMM12-141
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The RankingMeasureRelationship and GradeMeasureRelationship fulfill similar roles in association of a RankingMeasure or GradeMeasure to their input Measure. The superclass of RankingMeasureRelationship is BaseMeasureRelationship which means that inline rescaling can be applied to its base measurements. The superclass of GradeMeasureRelationship is MeasureRelationship which does not provide inline rescaling.

    The superclasses should be the same, either MeasureRelationship for both or BaseMeasureRelationship for both.

    An argument for BaseMeasureRelationship for both can be seen with US temperatures and European temperatures. If one wants both to be graded as COLD, MODERATE or HOT, either the US temperatures (in Fahrenheit) or the European temperatures (in Celsius) would need to be rescaled. That is, the same grading intervals can be used for both Fahrenheit and Celius if the Fahrenheit is first rescaled to Celsius.

  • Reported: SMM 1.1 — Fri, 13 May 2016 15:01 GMT
  • Updated: Tue, 16 May 2017 00:37 GMT

GradeMeasurement value attribute identifies a grade, not a rank

  • Key: SMM12-155
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The description of the value attribute of GradeMeasurement class indicates that the value is a rank. This is wrong, the value should be a grade.

  • Reported: SMM 1.1 — Wed, 23 Nov 2016 15:41 GMT
  • Updated: Tue, 16 May 2017 00:37 GMT

The wording “base measure(ment)” is ambiguous.


Relax constraint requiring both boundary points of an Interval.

  • Key: SMM12-87
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    An interval with neither boundary specified ranges over the entire number line and provides no useful information to its RankingMeasure (and to its GradeMeasure when no gradeTo is specified). But the current constraint is too restrictive in that it requires both boundaries if either is specified. A better constraint would be requiring at least one boundary (but the second is optional).

    The interval boundary properties are described as "endpoints" which is a term used elsewhere in the specification to mean the ends of "from" and "to" association. Describing the minimum and maximum properties of the intervals as boundaries would remove any possible confusion with respect to "endpoint" .

    Also, the boundaries are misidentified in Figure 10.2 and in the semantics clauses of 13.7 and 13.9 as minimumEndPoint and maximumEndPoint. Figure 10.2 is even inconsistent with the definition of the attributes in the Attributes table of Sub-clause 10.15. The semantics clauses of 13.7 and 13.9 contain sentences which start with "A numeric value is in the interval if and only if the it ". "the it" typo needs to be replaced with a reference back to the numeric value.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:22 GMT
  • Updated: Tue, 16 May 2017 00:37 GMT

Querying the BaseMeasureRelationship counterpart

  • Key: SMM12-149
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    CollectiveMeasures may have multiple baseMeasureTo associations where the to associations connect to the same input DimensionalMeasure. The BaseMeasureRelationships may have different rescaleMeasures.

    For CollectiveMeasurements of such a CollectiveMeasure, it's useful to map the baseMeasurementTo (a BaseNMeasurementRelationship) to the corresponding baseMeasureTo (a BaseNMeasureRelationship) of the CollectiveMeasure. Adding an optional association from BaseNMeasurementRelationship to its corresponding BaseNMeasureRelationship would provide this mapping.

  • Reported: SMM 1.1 — Fri, 9 Sep 2016 15:35 GMT
  • Updated: Sat, 1 Apr 2017 00:10 GMT
  • Attachments:

General text for Scope class (10.4) assumes class attribute is given.

  • Key: SMM12-146
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Scope can be specified by a class, a stereotype or a name and description. The introductory text in 10.4 for Scope class only mentions the class attribute. The text needs to be generalized to allow stereotype or name+description use instead.

  • Reported: SMM 1.1 — Thu, 30 Jun 2016 19:25 GMT
  • Updated: Sat, 1 Apr 2017 00:10 GMT

Description of RescaledMeasurement class is too restrictive

  • Key: SMM12-151
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The description of Sub-clause 15.3 (RescaledMeasurement Class) begins with:

    The RescaledMeasurement class represents the measurement results of applying to the base measurement the operation specified by the Measure to rescale the measurement.

    A RescaleMeasure may have a multiplier and offset specified and not have an operation. This opening sentence needs to be generalized to include multiplier and offset.
    Moveover, the first paragraph of Sub-clause 15.3 (RescaledMeasurement Class) suggests that a Rescaled Measure does always convert the Unit of Measure. This assumption is too strict as well.

  • Reported: SMM 1.1 — Thu, 22 Sep 2016 20:26 GMT
  • Updated: Sat, 1 Apr 2017 00:10 GMT

Unit of Measure definition should refer to Dimension

  • Key: SMM12-158
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The definition for Unit of Measure needlessly refers to "total order" when it should more appropriately refer to Dimension. Dimension is already defined in the Terms and Definition clause.

  • Reported: SMM 1.1 — Mon, 5 Dec 2016 14:54 GMT
  • Updated: Sat, 1 Apr 2017 00:10 GMT

Superclass of RatioMeasure should be BinaryMeasure

  • Key: SMM12-144
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    RatioMeasure should be a subclass of BinaryMeasure (as is shown in Fig 11.1). SMM 1.1 document incorrectly lists RatioMeasure's super class as DimensionalMeasure .

  • Reported: SMM 1.1 — Mon, 20 Jun 2016 18:28 GMT
  • Updated: Sat, 1 Apr 2017 00:10 GMT

ObservationScope Class semantics sub-clause is mostly non-normative

  • Key: SMM12-134
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Everything after the first paragraph in the Semantics sub-clause of the ObservationScope Class seems non-normative. It presents example URIs. We could move the first paragraph into the attribute definition for scopeUri and then mark the Semantics clause as non-normative.

  • Reported: SMM 1.1 — Thu, 11 Feb 2016 19:43 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

"From" associations on Dimensional Measure/Measurement are poorly described.

  • Key: SMM12-133
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The rankingFrom, gradeFrom, baseMeasureFrom, baseMeasure1From and baseMeasure2From associations of DimensionalMeasure and the rankingFrom, gradeFrom, baseMeasurementFrom, baseMeasurement1From and baseMeasurement2From associations of DimensionalMeasurement are poorly defined. Each reuse the phrase "for this measure" which is confusing. For example, rankingFrom has

    rankingFrom:RankingMeasureRelationship [0..*] Specifies the relationship instance that defines the rankings for this measure. This property subsets the inbound property of Measure.

    Ranking measures are derived from the DimensionMeasure instance. But the definition above doesn't say that. It, instead, implies some kind of ownership of the rankings by the DimensionMeasure instance. We should also use "ranking measure" or "ranking measurement" instead of "ranking" to avoid any confusion between the two concepts.

    The definitions for baseMeasure1From and baseMeasure2From associations of DimensionalMeasure and the baseMeasurement1From and baseMeasurement2From associations of DimensionalMeasurement have an additional problem. These definitions use the undefined term "comparator". For example,

    baseMeasure1From:Base1MeasureRelationship [0..*] Specifies the relationship instance that defines the 1st part of the binary comparator for this measure. This property subsets the inbound property of Measure.
  • Reported: SMM 1.1 — Mon, 8 Feb 2016 18:19 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Wrong superclasses for NamedMeasurement and RescaledMeasurement

  • Key: SMM12-140
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In the SMM 1.1 document, NamedMeasurement and RescaledMeasurement have the wrong superclass. In both cases it should be DimensionalMeasurement, not DimensionalMeasure.

  • Reported: SMM 1.1 — Fri, 13 May 2016 14:50 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Replace boolean with UML/MOF “Boolean”.

  • Key: SMM12-128
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The normative use of “boolean” in the SMM document specifying the visible attribute of the Measure Class should be the UML/MOF “Boolean” instead.

  • Reported: SMM 1.1 — Fri, 18 Dec 2015 15:09 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Bad definition of rescales association in 12.3 RescaledMeasure Class

  • Key: SMM12-127
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In Associations table of 12.3 it says "specified by rescaleFrom rescaled of this measure." It should be "specified by the rescaleFrom association of this measure."

  • Reported: SMM 1.1 — Fri, 18 Dec 2015 14:37 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Conformance clause restricts SMM to software measures.

  • Key: SMM12-122
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The reference to "software" is incorrect in the first sentence of the conformance clause. It should allow any MOF-based model.

  • Reported: SMM 1.1 — Fri, 11 Dec 2015 20:07 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

CountingMeasure operation should not be confused with Scope.recognizer

  • Key: SMM12-119
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The recognizer of Scope is a boolean operation and should return true or false. Yet the text in CountingMeasure indicates that it has a recognizer which returns 0 or 1. This is wrong and the text should be update to disambiguate the operation of CountingMeasure and the recognizer of Scope.

  • Reported: SMM 1.1 — Thu, 3 Dec 2015 18:50 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

SMM class for unit of measure of counting measures.

  • Key: SMM12-97
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In SMM 1.0, the unit of measure for CountingMeasures was assumed to be their Scope's class. In SMM 1.1, the UnitOfMeasure class was introduced and unit of measure of DimensionalMeasures must be a UnitOfMeasure. These are two different approaches that have not been harmonized in SMM 1.1, but should have been harmonized.

    A subclass of UnitOfMeasure is needed to serve as unit of measure for CountingMeasures. This would be a significant convenience anyway and allow constraints which tie the counting back to counting instances of a class or stereotype.

    The example given in Figure 9 “CountingMeasure Unit of Measure Constraint” will need to be updated too.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:31 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Replace “accumulate” variants with “combine” concerning binary measures.

  • Key: SMM12-94
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Accumulate means to amass a quantity of something. It is an appropriate term for collective measures or collective measurements. For this reason collective measures have an "accumulator" (defined in the meta-model). But it is overly vague with respect to binary measures and binary measurements. Replacing the variants of “accumulate” with “combine” would be better.

    The rescales association in RescaledMeasure class applies to both binary measures and collective measures. In that case, "accumulates or combines" would be better than simply "accumulates".

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:26 GMT
  • Updated: Mon, 4 Jul 2016 00:31 GMT

Inconsistent handling of inherited attributes


Replace SMM “string” with UML/MOF “String”.


Some classes are shown in some diagrams without purpose.

  • Key: SMM12-93
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Figure 10.1 seems to show several Classes that are not relevant to that diagram, and that are already placed on other diagrams where they do serve purpose.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:26 GMT
  • Updated: Wed, 20 Apr 2016 14:14 GMT
  • Attachments:

Define conformance levels for SMM.

  • Key: SMM12-96
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    SMM references Stereotype which is not part of the MOF subset of UML. Conformance with the spec should be possible without support for Stereotype.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:27 GMT
  • Updated: Sat, 16 Apr 2016 00:56 GMT

Allow more flexibility in defining a RescaledMeasure.

  • Key: SMM12-90
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Some rescalings are not strictly linear transformations, but also require a single non-linear operation. For example, the rule of 72 is a common rule of thumb to calculate how long it takes before an investment doubles in value: #years = 72/Interest Rate. This is a rescaling from interest rate to years.
    SMM could directly support such rescaling by removing the constraint which requires that either the operation property is empty or the multiplier/offset properties are empty. SMM would need to indicate whether the operation is applied first or the multiplier and offset are applied first. A new Boolean property, operationFirst, would suffice. Its default can be false. With that this new property has a default value, it is better to then also defined defaults for the existing properties. So, SMM should also specify the defaults multiplier = 1 and offset = 0.
    The rule of 72 would then be a rescaling with multiplier 72, offset 0, operation "reciprocal", and operationFirst set.
    This will also generally improve the expressiveness of a RescaledMeasure.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:24 GMT
  • Updated: Sat, 16 Apr 2016 00:56 GMT
  • Attachments:

The definition of Formula of DimensionalMeasure should be more generally specified.

  • Key: SMM12-88
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Formula is specified with “Describes the measure’s calculation in an algebraic manner”. Specifying it with “Describes the measure’s calculation in an algebraic manner or pseudocode” would broaden its usefulness.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:23 GMT
  • Updated: Sat, 16 Apr 2016 00:56 GMT

Add more parties to Acknowledgements

  • Key: SMM12-114
  • Status: open  
  • Source: VDMbee ( Henk de Man)
  • Summary:

    During second half of SMM 1.1 RTF there were some organizations that contributed to the spec. It would be good to acknowledge these, in Sub-Clause 6.3, by listing their Organization and the person through which the contribution was done. I think about Bill Curtis (CAST), Pete Rivett (Adaptive) and Henk de Man (VDMbee).

  • Reported: SMM 1.1 — Mon, 26 Oct 2015 18:51 GMT
  • Updated: Fri, 1 Jan 2016 05:12 GMT

Show the new SMM logo in the specification.

  • Key: SMM12-86
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    SMM has a new logo. Many OMG specs have a logo in the spec itself. SMM should do likewise.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:21 GMT
  • Updated: Fri, 1 Jan 2016 05:12 GMT
  • Attachments:

SMM confuses "To" and "From"

  • Key: SMM12-78
  • Legacy Issue Number: 19607
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    SMM confuses "To" and "From". There are two points of inconvenience (or even confusion ?) related to measure(ment) relationship: 1) Consider RescaledMeasure(ment) ("RSC") on one hand and BinaryMeasure(ment) ("BIN"), CollectiveMeasure(ment) ("COL"), RankingMeasure(ment) ("RNK") and GradeMeasure(ment) ("GRD") on the other hand. They all aggregate "from" a DimensionalMeasure(ment) ("DIM"). However, RSC looks to DIM as "from", whereas BIN, COL, RNK and GRD all look at DIM as "to". Isn't that confusing ? Is it inconsistent ? Or is there a good reason for it ? 2) When I think of aggregating from DIM (regardless of whether I do that by rescaling, or binary functor or accumulation or grading or ranking), I always think of aggregating "from" a DIM and "to" an aggregated one (RSC, BIN, COL, RNK, GRD). The “from” association of all SmmRelationship is defined as the origin element and the “to” association is defined as the target element which implies that the associations between BIN, COL, RNK and GRD to DIM are backwards. The “from” should in each case be the DIM measure(ment)s and the “to” should be the aggregating measure(ment)s.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Updated: Fri, 1 Jan 2016 05:12 GMT

Add a non-normative Clause to the SMM specification which demonstrates an SMM Library of basic Unit conversions

  • Key: SMM12-77
  • Legacy Issue Number: 19453
  • Status: open  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Add a non-normative clause to the SMM document which demonstrates a SMM library of basic unit conversions including currency conversion.

  • Reported: SMM 1.0 — Thu, 5 Jun 2014 04:00 GMT
  • Updated: Fri, 1 Jan 2016 05:12 GMT