${taskforce.name} Avatar
  1. OMG Task Force

Structured Metrics Metamodel 1.2 RTF — All Issues

  • Key: SMM12
  • Issues Count: 46
Open Closed All
All Issues

Issues Summary

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

Issues Descriptions

Fix and improve CollectiveMeasurement examples

  • Key: SMM12-160
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Update figures and add text for mapsTo

    • Fix Figure 11.2 by adding 2 more BaseNMeasurementRelationship instance and moving 2 of the "to" associations from the original BaseNMeasurementRelationship instance to the new instances.
    • Include mapsTo link in Figure 17.6
    • Modify Figure 11.2 to have 2 base measures for collective measure. The first base measure maps to one base measurement in the collective measurement and the second base measure maps to 2 base measurements in the collective measurement. Make this clear by showing the mapsTo links.
    • Add text in Semantics clause of 14.2 CollectiveMeasurement Class which clarifies that each BaseNMeasureRelationship instance there may be multiple BaseNMeasurementRelationship instances.
  • Updated: Mon, 2 Apr 2018 18:08 GMT

GradeFrom association wrongly named in Figure 10.2

  • Key: SMM12-167
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Fix Figure 10.2

    Replace "gradingFrom" with "gradeFrom" in Figure 10.2.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

Outbound associations wrongly defined

  • Key: SMM12-170
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replace to with from

    In the descriptions of the outbound associations in 10.5 Measure Class and 13.2 Measurement Class, replace "to-endpoint" with "from-endpoint".

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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

  • Key: SMM12-89
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Rewrite Semantics and Attributes

    Modify the attribute descriptions of measureLabelFormat and measurementLabelFormat to clearly state that they specify how labels are generated for measures and measurements.

    Rewrite Semantics sub-clause to clarify the syntax of the attributes and how labels are generated from them.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

SMM class for unit of measure of counting measures.

  • Key: SMM12-97
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add CountingUnit Class

    Enable that counts can be expressed in terms of Unit of Measure, and for that purpose extend Unit of Measure to create a new class Counting Unit of Measure which has Class and Stereotype attributes just as Scope has.

    The counting constraint, then, requires that the Unit is a Counting Unit of Measure. If the unit has a Class then the Scope does and the two Classes must match. Otherwise, the Unit has a Stereotype implying the Scope has a Stereotype and the two Stereotypes must match.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Relax constraint requiring both boundary points of an Interval.

  • Key: SMM12-87
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Relax constraint requiring both boundary points of an Interval

    Loosen constraint to require only one end point, but not both. Use proper terminology for boundaries of intervals.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

SMM Introduction Overview clause is too software measures centric.

  • Key: SMM12-138
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Generalize introduction beyond software measures

    Integral revision of Overview, by:

    • Rewriting first paragraph to refer to a very broad range of measurements.
    • Removing second, third and fourth paragraphs.
    • Removing last sentence (starting with "All initial depictions") from seventh paragraph.
  • Updated: Mon, 2 Apr 2018 18:08 GMT

Scope clause restricts SMM to software measures.

  • Key: SMM12-137
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Generalize scope beyond software measures

    Integral revision of the Scope Clause by:

    • Inclusion of non-software examples in place of some software examples.
    • Reference to models outside of ADM.
    • Inclusion of structured models, not just MOF or OMG models.
    • Rewrite as needed.
  • Updated: Mon, 2 Apr 2018 18:08 GMT

Measure to Scope association missing from Measurable Characteristic and Scope diagram

  • Key: SMM12-115
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add association to diagram

    Show the association between Measure and Scope in Figure 10.1.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

Binary measurement, not collective measurement

  • Key: SMM12-165
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replace collective measurement with binary measurement.

    Replace the wrong term with the correct term.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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

  • Key: SMM12-91
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Move constraint.

    Strictly spoken, the constraint is too strict. Therefore, we move it indeed from Subclause 11.2 to Sub-clause 14.2, but not as constraint, but, in softer form, as a part of Semantics, meant as a possible idea or suggestion to implementers, but not strictly enforced by the spec.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Scalar misused in attributes subclause of RescaledMeasure Class

  • Key: SMM12-153
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Remove "scalar"

    Rewrite the sentences where wrong use of the word "scalar" occurs.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

GradeMeasurement value attribute identifies a grade, not a rank

  • Key: SMM12-155
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replace rank with grade

    Use the proper term, i.e., "grade" instead of "rank".

  • Updated: Mon, 2 Apr 2018 18:08 GMT

SMM is presumptuous about how measurands must relate

  • Key: SMM12-150
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Remove constraints and include text discussing measurand sameness

    Relax constraints about sameness of measurand of input measurement and derived measurement. Rewrite and complement text that is about sameness of these measurands.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Querying the BaseMeasureRelationship counterpart

  • Key: SMM12-149
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add mapsTo association to the BaseNMeasurementRelationship

    Define a mapsTo association for the BaseNMeasurementRelationship with multiplicity 0..1, and which identifies the corresponding BaseNMeasureRelationship.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

Superclass of RatioMeasure should be BinaryMeasure

  • Key: SMM12-144
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Change super class of RatioMeasure

    Change super class of RatioMeasure to be BinaryMeasure.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Superclasses of RankingMeasureRelationship and GradeMeasureRelationship are inconsistent

  • Key: SMM12-141
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — SMM 1.2
  • Disposition Summary:

    *Change super class of GradeMeasureRelationship *

    Set the super class of GradeMeasureRelationship to be BaseMeasureRelationship. Modify Diagram 10.2 to include the generalization relation between GradeMeasureRelationship and BaseMeasureRelationship.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Wrong superclasses for NamedMeasurement and RescaledMeasurement

  • Key: SMM12-140
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    *Fix super classes of NamedMeasurement and RescaledMeasurement *

    Set the super classes of NamedMeasurement and RescaledMeasurement to be DimensionalMeasurement.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

ObservationScope Class semantics sub-clause is mostly non-normative

  • Key: SMM12-134
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Make the Semantics sub-clause non-normative

    Move the first paragraph of the Semantics sub-clause of ObservationScope Class into the attribute definition for scopeUri and mark the Semantics clause as non-normative.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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

  • Key: SMM12-105
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    By base measure(ment) we mean the measure(ment)s which are input to a (derived) measure(ment). But "base" is a normative word, that the meta-model uses in a much narrower scope than the spec does. This is confusing. Also: The term "derived measure" is used in quite several places in the spec, but nowhere defined.

  • Reported: SMM 1.1 — Mon, 12 Oct 2015 18:44 GMT
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Make the specification consistent with respect to the use of the term "base measure(ment)"

    We apply several minor changes to the text, and a few to the meta-model, to ensure that the text and the meta-model of the specification are well-aligned with respect to using the terms "Base Measure" and "Base Measurement". In particular we make sure that, where-ever a derived Measure(ment) is derived from an input Measure(ment), this derivation is always achieved by a Base Measure(ment) Relationship, so that the use of the term "base" is always founded in the meta-model.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Unit of Measure definition should refer to Dimension

  • Key: SMM12-158
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replaced “total order” with “dimension” in the definition of unit of measure

    Replace "total order" with "dimension" in the definition of Unit of Measure.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Description of RescaledMeasurement class is too restrictive

  • Key: SMM12-151
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Relax restrictive description

    The restrictions as suggested by the descriptions, as referred to in the issue's Description, will be relaxed.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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

  • Key: SMM12-133
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replace "for" with "derived from" and remove use of comparator

    Fix rankingFrom, gradeFrom, baseMeasureFrom, baseMeasure1From, and baseMeasure2From associations in DimensionalMeasure by replacing "for" with "derived from".

    Replace "aggregations" with "collective measures" and "collective measurements" in 10.12 and 13.6 respectively.

    Fix rankingFrom, gradeFrom and baseMeasurementFrom associations in DimensionalMeasurement by replacing "for" with "derived from".

    Fix baseMeasure1From, and baseMeasure2From associations in DimensionalMeasurement by replacing "comparator for" with "derived from".

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Replace boolean with UML/MOF “Boolean”.

  • Key: SMM12-128
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Use Boolean as type of "visible" attribute of Measure class

    Revise attribute "visible" in Attributes table of the Measure Class, such that it uses the proper Boolean type.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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

  • Key: SMM12-146
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Generalize 10.4 introduction to include stereotypes and informal scopes

    Generalize "class" to "class, stereotype or name/description".

    Modify discussion about informal scope to include the situation where the measure designer understands the semantics of the measure's domain, but does not know the details of the MOF model for the domain.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

CountingMeasure operation should not be confused with Scope.recognizer

  • Key: SMM12-119
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Disambiguate "recognizer" by using "counter"

    Disambiguate "recognizer" by using "counter", in Sub-clauses 11.6 and 14.4.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Inconsistent handling of inherited attributes

  • Key: SMM12-92
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    In SMM, inherited attributes are usually not shown in the document's diagram nor discussed in the document's text unless some feature (such as multiplicity) is overridden in the subclass. In some classes, however, we show unmodified inherited attributes. For clarity we should consistently not show unmodified inherited attributes.

    Unmodified inherited attributes appear in the Scope, MeasureRelationship, and NamedMeasure classes.

    Furthermore, the multiplicities of both name and description attributes in SmmElement in the diagrams (and model) differ from those listed in the specification's text in Sub-clause 8.2. What's in the text seems to be correct, and what is in the diagrams is wrong.

  • Reported: SMM 1.1 — Fri, 2 Oct 2015 15:25 GMT
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Remove or redefine inherited attributes

    Change the multiplicities of both name and description attributes in SmmElement in the diagrams (and model) to [0..1] to make them match the multiplicities given in the document's text.

    Remove the attributes name and description in the Scope class. The attributes are inherited from AbstractMeasureElement without any change.

    Also, remove the attribute name in the NamedMeasure and MeasureRelationship classes. NamedMeasure inherits name from Measure without any change. The name attribute should not be required on MeasureRelationship; hence, it inherits name from SmmElement without any change.

    Mark the name attribute in the following classes as redefining the attributes name of the SmmElement class: Characteristic, Measure, and Argument. In each name is required. These attributes need to be marked in the model, diagrams and document.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

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


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

  • Key: SMM12-94
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Replace accumulate with combine for binary measure(ment)

    Replace "accumulate" variant (other than "accumulator"), when used in relation to a binary measure(ment), with "combine". Accumulator is left unchanged.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Some classes are shown in some diagrams without purpose.

  • Key: SMM12-93
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Remove classes from diagram

    Remove EquivalentMeasureRelationship, RefinementMeasureRelationship and DirectMeasure from Figure 10.1.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

Define conformance levels for SMM.

  • Key: SMM12-96
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Define 2 levels of conformance

    Specify two levels of conformance, only the second of which requires support for Stereotype.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Bad definition of rescales association in 12.3 RescaledMeasure Class

  • Key: SMM12-127
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Revise definition of rescales

    Revise the definition in the Association sub-clause of the RescaledMeasure Class.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Conformance clause restricts SMM to software measures.

  • Key: SMM12-122
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Generalize "software" to "any MOF-based model".

    Make the sentence in the Conformance Clause less software measurement-biased.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Add more parties to Acknowledgements

  • Key: SMM12-114
  • Status: closed  
  • Source: VDMbee ( Mr. 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add names and companies

    Add the following organizations to the list of submitting or supporting organizations in Sub-clause 6.3 (Acknowledgements): Adaptive, CAST, VDMbee.
    And add the following persons, representing these organizations, to the same Sub-clause: Pete Rivett, Bill Curtis, Henk de Man.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Allow more flexibility in defining a RescaledMeasure.

  • Key: SMM12-90
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Introduce operationFirst Boolean

    Enable that, for a Rescaled Measure, operation, offset and multiplier can be applied in combination, whereby it can also be specified in which order they are applied. Next to this, default values are specified for the attributes.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

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

  • Key: SMM12-88
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add pseudocode

    Add to the description of "formula" that it may be specified by pseudocode, and make it explicit that formulas are not about executable expressions

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Show the new SMM logo in the specification.

  • Key: SMM12-86
  • Status: closed  
  • 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
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Add Logo to title page

    Add the SMM Logo to the title page of the SMM specification.

  • Updated: Mon, 2 Apr 2018 18:08 GMT
  • Attachments:

OCL expr. of BinaryMeasurement

  • Key: SMM12-82
  • Legacy Issue Number: 15012
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    The OCL expression related to the BinaryMeasurement Class refers to the context RatioMeasurement instead of BinaryMeasurement.

  • Reported: SMM 1.0b2 — Sun, 31 Jan 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.2
  • Disposition Summary:

    Context of OCL expression of BinnaryMeasurement was fixed already

    The context of the OCL expression of BinaryMeasurement was already fixed in SMM 1.1, due to resolution of other issue(s).

  • Updated: Mon, 2 Apr 2018 18:08 GMT

operation attribute of DirectMeasure class

  • Key: SMM12-85
  • Legacy Issue Number: 15011
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    The operation attribute is declared to be of type Operation while this type is not specified in the document. Moreover, e.g. in Figure 5, it is declared to be of type string.

  • Reported: SMM 1.0b2 — Sun, 31 Jan 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.2
  • Disposition Summary:

    Operation association has been fixed in SMM 1.1 already

    Section 10.7 of SMM 1.1 defines Operation Class. Figure 5 and other references to Operation have been fixed too. These fixes have been applied due to resolution of other issues at that time.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Add support for Scale of Measurement


Inconsistency between specification and provided Meta Model

  • Key: SMM12-84
  • Legacy Issue Number: 15014
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    Comparing the specification and the provided meta model, numerous inconsistencies between both appear. For example:
    • Naming differentials: Most of the meta classes with an underscore in their name mentioned in the specification document are named differently without the underscore.
    • Some association ends are missing in the provided model, e.g. categoryElement for the association between SMMCategory and Measure. (In our opinion, this association should be called measureElement to separate from the reflexive Association of the SMMCategory class having the same name.)
    • Numerous multiplicity values in the meta model differ from the specification. For example, the association between the SMMModell class and the SMMElement class has the upper bound value 1.
    • The subclasses of CollectiveMeasure (AdditiveMeasure and MaximumMeasure) mentioned in the specification do not occur in the meta model.

  • Reported: SMM 1.0b2 — Sun, 31 Jan 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.2
  • Disposition Summary:

    Inconsistencies between meta-model and specification have been fixed in SMM 1.1

    These inconsistencies between meta-model and specification have already been fixed in SMM 1.1, due to resolution of other issues. E.g., in SMM 1.1, names no longer have underscores, all association ends are provided in the model, and multiplicity issues have been fixed. All classes and sub-classes appear in the model.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Measure audits

  • Key: SMM12-81
  • Legacy Issue Number: 15017
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    In some cases, it is helpful to compose several measures to a single audit to run these measures at once without the necessity to select the individual measures manually prior to each computation. Although it would be possible to model such as relationship using a subclass of the MeasureRelationship class, we recommend to introduce a class Audit that simply has an association to the Measure class to model the membership of a measure to a specific audit.

  • Reported: SMM 1.0b2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.2
  • Disposition Summary:

    No change needed

    The ObservedMeasure Class was introduced to SMM after publication of ptc/09-03-03 and that Class composes a collection of Measurements of one or more Measures, but of a single Observation. The ObservedMeasure Class, as such, fulfills the features of the requested Audit Class.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

SMM confuses "To" and "From"

  • Key: SMM12-78
  • Legacy Issue Number: 19607
  • Status: closed  
  • 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
  • Disposition: Deferred — SMM 1.2
  • Disposition Summary:

    Defer changes of "To" and "From" in MeasureRelationships

    Further discussion learned that there might be good reasons why SMM 1.0 did it the way it was done, and that the deviating “from/to” naming of RescaledMeasure maybe on purpose. As the final conclusion of this was not reached yet, and as changing this would have quite some impact, it was decided to defer to issue.

  • Updated: Mon, 2 Apr 2018 18:08 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: closed  
  • 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
  • Disposition: Deferred — SMM 1.2
  • Disposition Summary:

    Defer Library of Unit conversions

    This will potentially be useful, though it is not critical at this moment. Given the scope of the current RTF, it was agreed to defer it. Possibly to, potentially, SMM 2.0.

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Modeling names of model elements

  • Key: SMM12-79
  • Legacy Issue Number: 15015
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    The chosen way of modeling names for model elements is not done straightforward and hampers the practical usage of the meta model. The SMM meta model contains several classes having an attribute called name. Moreover, all meta classes are derived from the abstract meta class SMM_Element, which should possess such an attribute according to the specification. Hence, this attribute can be considered of being modeled redundantly.
    Regarding the provided EMOF model, the SMM_Element does not have any attribute so that the specified attributes name, short_description and description are missing.

    According to best practices, we recommend to introduce a new class called SMM_NamedElement as a subclass of SMM_Element and as the base class of all meta classes having a name attribute. This facilitates to determine the name of a model element.

  • Reported: SMM 1.0b2 — Sun, 31 Jan 2010 05:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.2
  • Disposition Summary:

    Issue is subsumed in issue SMM12-92

    This issue is subsumed in issue SMM12-92

  • Updated: Mon, 2 Apr 2018 18:08 GMT

Threshold values for dimensional measures

  • Key: SMM12-80
  • Legacy Issue Number: 15016
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marcus Engelhardt)
  • Summary:

    It is not stated clear how to assign threshold values to dimensional measures. On page 9 of the specification document, it is mentioned that a measure has a range which can be interpreted as “the set of possible measurement results”. However, there is no corresponding attribute mentioned in the specification or meta model.

    We suggest to add two attributes lowerThreshold and upperThreshold to the DimensionalMeasure meta class to model a measure’s range.

  • Reported: SMM 1.0b2 — Sun, 31 Jan 2010 05:00 GMT
  • Disposition: Resolved — SMM 1.2
  • Disposition Summary:

    Remove "range"

    Modify the third paragraph of Sub-clause 10.1 (General) of Clause 10 (Measures), to delete the phrase "; a range, the set of possible measurement results;".

  • Updated: Mon, 2 Apr 2018 18:08 GMT