Structured Metrics Metamodel Avatar
  1. OMG Specification

Structured Metrics Metamodel — All Issues

  • Acronym: SMM
  • Issues Count: 144
  • Description: All Issues
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
SMM11-88 In 10.3 Scope::class should not be a String but a proper reference to MOF:Class SMM 1.0 SMM 1.1 Resolved closed
SMM11-87 The UML uses non-standard notation by showing the superclass in top right of a class compartment. SMM 1.0 SMM 1.1 Resolved closed
SMM11-86 The metamodel is missing Properties for important navigable relationships SMM 1.0 SMM 1.1 Resolved closed
SMM11-85 The UML uses ‘string’ lowercase rather than the UML/MOF PromitiveType String (uppercase) SMM 1.0 SMM 1.1 Resolved closed
SMM11-84 8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes SMM 1.0 SMM 1.1 Resolved closed
SMM11-100 Create new root class that attribute and annotation can extend SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-99 Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-103 Add attribute “type” (String) to Observation SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-102 Add relation to Scope Class SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-101 Add missing containment relation from SmmElement to SmmRelationship SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-106 Remove the TimeStamp primitive type SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-105 It is unclear how rescaling is possible from more than 1 simultaneously SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-104 Allow more normative options for language of operation body SMM 1.0 SMM 1.1 Closed; No Change closed
SMM11-107 The metamodel defines MOF operations for derived Properties SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-109 Section 8.6, measureCategory SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-108 What is missing however is any semi-formal description of how the properties are derived – for example OCL SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-110 Change the spec from EMOF to CMOF SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-111 AdditiveMeasure SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-112 Inconsistency between Examples (instance models) and meta-model SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-89 Add a non-normative clause to the SMM doc which demonstrates a SMM library of basic unit conversions SMM 1.0 SMM 1.1 Deferred closed
SMM11-118 Change compliance to use term “must” instead of “can” SMM 1.0 SMM 1.1 Resolved closed
SMM11-90 SMM confuses "To" and "From" SMM 1.0 SMM 1.1 Deferred closed
SMM11-117 Base SMM on CMOF instead of EMOF SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-116 Make all examples shown in the non-normative clauses of the SMM doc compatible with the latest SMM spec SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-115 Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-114 Wrong reference SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-113 RescaledMeasure SMM 1.0 SMM 1.1 Duplicate or Merged closed
SMM11-125 Attributes to be added to Measurement SMM 1.0 SMM 1.1 Resolved closed
SMM11-124 The measurand of Measurement, which references Element (MOF), is owned by Measurement SMM 1.0 SMM 1.1 Resolved closed
SMM11-123 SMM metamodel contains class "MofElement". SMM 1.0 SMM 1.1 Resolved closed
SMM11-122 Scope of a measure should be made optional SMM 1.0 SMM 1.1 Resolved closed
SMM11-121 SMM should use MOF 2.4.1 SMM 1.0 SMM 1.1 Resolved closed
SMM11-120 Fix OCL constraint in CategoryRelationhsip SMM 1.0 SMM 1.1 Resolved closed
SMM11-119 Clarify that XQuery is defined as mapping to XMI with correct version number SMM 1.0 SMM 1.1 Resolved closed
SMM11-126 Allow multiple operations for a direct measure (multiplicity 0..*) SMM 1.0 SMM 1.1 Resolved closed
SMM11-128 Add accumulator value “product”. SMM 1.0 SMM 1.1 Resolved closed
SMM11-127 CollectiveMeasurement class SMM 1.0 SMM 1.1 Resolved closed
SMM11-130 Should a binary measure have a formula next to a functor ? SMM 1.0 SMM 1.1 Resolved closed
SMM11-129 SMM does not allow for a formula, but only has a simple accumulator SMM 1.0 SMM 1.1 Resolved closed
SMM11-134 functor should have an enumeration defined in the spec SMM 1.0 SMM 1.1 Resolved closed
SMM11-133 CollectiveMeasurement attribute wrong SMM 1.0 SMM 1.1 Resolved closed
SMM11-132 RatioMeasurement SMM 1.0 SMM 1.1 Resolved closed
SMM11-131 The class DimensionalMeasure should be abstract SMM 1.0 SMM 1.1 Resolved closed
SMM11-136 Scales of Measurement SMM 1.0 SMM 1.1 Resolved closed
SMM11-135 interval-based mapping SMM 1.0 SMM 1.1 Resolved closed
SMM11-138 New SMM RTF Issue: Need "Opaque" operation body language SMM 1.0 SMM 1.1 Resolved closed
SMM11-137 "Influence" of measure relationship SMM 1.0 SMM 1.1 Resolved closed
SMM11-141 Observation has Arguments associated SMM 1.0 SMM 1.1 Resolved closed
SMM11-140 Unit consistency SMM 1.0 SMM 1.1 Resolved closed
SMM11-139 Typo in Constrains for BinaryMeasurement Class SMM 1.0 SMM 1.1 Resolved closed
SMM11-142 Make all examples shown in the normative clauses of the SMM doc compatible with the latest SMM spec SMM 1.0 SMM 1.1 Resolved closed
SMM11-144 Constraints on aggregating measurement classes SMM 1.0 SMM 1.1 Resolved closed
SMM11-143 Add a re-scaling association to the all base measure relationship SMM 1.0 SMM 1.1 Resolved closed
SMM11-145 Introduce Unit of Measure as a class. SMM 1.0 SMM 1.1 Resolved closed
SMM11-148 Identify the observedMeasure role in the Association sub-clause of the Measurements class SMM 1.0 SMM 1.1 Resolved closed
SMM11-147 Interval Open attributes SMM 1.0 SMM 1.1 Resolved closed
SMM11-146 Remove RecursiveMeasureRelationship and RecursiveMeasurementRelationship classes SMM 1.0 SMM 1.1 Resolved closed
SMM11-149 Remove ownedRelation assocation from SmmElement and SmmRelationship SMM 1.0 SMM 1.1 Resolved closed
SMM11-150 ObservedMeasure should not extend SmmRelationship SMM 1.0 SMM 1.1 Resolved closed
SMM11-156 Minimum and maximum attributes for the Interval class should be optional SMM 1.0 SMM 1.1 Resolved closed
SMM11-155 Provide some non-software non-normative measure examples SMM 1.0 SMM 1.1 Resolved closed
SMM11-154 Remove non-normative Library of Measures clause SMM 1.0 SMM 1.1 Resolved closed
SMM11-153 Old measure(ment) names still persist in the document SMM 1.0 SMM 1.1 Resolved closed
SMM11-152 The Percentage measure(ment) has been replaced by the RatioMeasure(ment) SMM 1.0 SMM 1.1 Resolved closed
SMM11-151 An Operation should be reusable as the operation of multiple measures SMM 1.0 SMM 1.1 Resolved closed
SMM11-157 Generalize Scope to include stereotypes SMM 1.0 SMM 1.1 Resolved closed
SMM11-159 Some Associations and Roles do not have names in SMM SMM 1.0 SMM 1.1 Resolved closed
SMM11-158 Apply Timestamp instead of Date and remove Date SMM 1.0 SMM 1.1 Resolved closed
SMM11-162 A RescaledMeasurement should not rescale more than one DimensionalMeasurement simultaneously SMM 1.0 SMM 1.1 Resolved closed
SMM11-161 Redundant association in Associations table of RescaledMeasure SMM 1.0 SMM 1.1 Resolved closed
SMM11-160 Incorrect types for associations of BinaryMeasure SMM 1.0 SMM 1.1 Resolved closed
SMM11-165 Clarify that Observation.requestedMeasures is of type SmmElement and not AbstractMeasureElement SMM 1.0 SMM 1.1 Resolved closed
SMM11-164 Improve the definition of derived properties SMM 1.0 SMM 1.1 Resolved closed
SMM11-163 Remove getters of properties in the meta-model SMM 1.0 SMM 1.1 Resolved closed
SMM-30 Improve Label format support SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-31 Clarify role of NamedMeasure SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-28 Delete library attribute from Measure SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-27 Add defaultQuery to Measure SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-29 Add additional Accumulator enum value and document Accumulator SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-8 Change meaning of SMM Acronym SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-13 Change to the Scope Class SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-12 Graph corrections SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-9 Correct Naming of Elements SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-11 Correct Category Associations SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-10 Correct SmmRelationship Associations SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-25 Add better support for Operations and OCL code reuse SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-24 Add measurandQuery Operation to MeasureRelationship SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-26 Add support for parameterized measure SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-23 Convert all measure and measurement relationship to use the relationship class SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-20 Improve Model Hierarchy SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-22 Redefine Collective Measures SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-21 Improve Observations SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-16 Improve DirectMeasure Operations SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-15 Redefine Collective Measures SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-14 Change to the Measure Class SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-19 Rename Category class to MeasureCategory SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-18 Add Extensibility to SMM Model SMM 1.0b1 SMM 1.0b2 Resolved closed
SMM-17 Improve Observations SMM 1.0b1 SMM 1.0b2 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

In 10.3 Scope::class should not be a String but a proper reference to MOF:Class

  • Key: SMM11-88
  • Legacy Issue Number: 15484
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 10.3 Scope::class should not be a String but a proper reference to MOF:Class (which will be serialized as a XMI href). Relying on ‘name’ and a linking convention unique to this standard, makes practical linking and resolution unworkable

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace String as type of class attribute with MOF::Class.

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

The UML uses non-standard notation by showing the superclass in top right of a class compartment.

  • Key: SMM11-87
  • Legacy Issue Number: 15483
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML uses non-standard notation by showing the superclass in top right of a class compartment.

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace diagrams to not show superclass

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

The metamodel is missing Properties for important navigable relationships

  • Key: SMM11-86
  • Legacy Issue Number: 15482
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The metamodel is missing Properties for important navigable relationships: for example the owner of a MeasureRelationship, the child of a Characteristic, the Measures for a Characteristic, the applicability of an Operation and more

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Modified model to add names as needed

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

The UML uses ‘string’ lowercase rather than the UML/MOF PromitiveType String (uppercase)

  • Key: SMM11-85
  • Legacy Issue Number: 15480
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML uses ‘string’ lowercase rather than the UML/MOF PromitiveType String (uppercase)

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace UML/MOF PrimitiveType String by string (lowercase) in document

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

8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes

  • Key: SMM11-84
  • Legacy Issue Number: 15479
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add a note to 8.8 and 8.9 that each is a primitive type.

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

Create new root class that attribute and annotation can extend

  • Key: SMM11-100
  • Legacy Issue Number: 15851
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    This issue deals with the fact that the SMM didn’t provide any real root class in its model and that everything started with SmmElement.

    Discussion:
    The architecture board as recommended that we add a new root class that can be used as the direct extension for attribute and annotation. In turn, SmmModel and SmmRelationship also now extends this new Element class.

    Summary of change:
    • Add Element class, a model root class
    • Modify SmmElement class
    o Change from model root class to class being a generalization of Element
    • Modify SmmModel class
    o Change generalization from SmmElement to Element
    • Modify SmmRelationship class
    o Change generalization from SmmElement to Element
    • Modify Attribute class
    o Change generalization from SmmElement to Element
    • Modify Annotation class
    o Change generalization from SmmElement to Element

    • Create new separate diagram for Core

    • Re-arranged content of Chapter 8 and Chapter 9 of Specification
    o Renamed chapter 8 to “Core Base Classes”
    o Move Figure 2 Core Classes Diagram to Figure 3 and rename to Metrics Core Classes
    o Move Figure 3 Core Relationship Classes to Figure 4
    o Insert Core Classes from above to Figure 2
    o Add following description for Element class under 8.1:
    Element Class (Abstract)
    An Element constitutes an atomic constituent of a model. In the meta-model, Element is the top class in the hierarchy. Element is an abstract class.
    Semantics
    Element is the common parent from all meta-model elements of SMM. Most subclasses of Element can own annotations and user-defined attributes through standard extension mechanisms.

    o Added Superclass info to SmmElement
    o Modified Superclass info of SmmModel from SmmElement to Element
    o Modified Superclass info of SmmRelationship from SmmElement to Element
    o In chapter 9, remove the figure that only depicted the extensions, now shown in figure 2 as seen above.
    o Added chapter 10 as “Core Metrics Classes”
    o Moved description of class MeasureLibrary from chapter 8 to 10
    o Moved description of class MeasureCategory from chapter 8 to 10
    o Moved description of class CategoryRelationship from chapter 8 to 10

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    Rejecting keeps SMM more aligned with the design used in KDM and VDML.
    Disposition: Closed, no change

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

Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement

  • Key: SMM11-99
  • Legacy Issue Number: 15481
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement: they will not have or need their own name, description or Attributes/Annotations: in fact the latter is explicitly disallowed – though only informally in the text.

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Rejecting keeps SMM more aligned with the design used in KDM and VDML.
    Disposition: Closed, no change

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

Add attribute “type” (String) to Observation

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

    Add attribute “type” (String) to Observation. Examples of observation type values are “estimated”, “actual”, "simulated", "benchmark".

  • Reported: SMM 1.0 — Fri, 13 Jul 2012 04:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    VDML Analysis Context associates with SMM Observation (e.g. different Observation in different Context). We can consider to close this SMM issue by doing nothing in SMM, and rather have a type attribute on the Context class in VDML.
    Disposition: Closed, no change

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

Add relation to Scope Class

  • Key: SMM11-102
  • Legacy Issue Number: 15857
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    OMG Issue No: 15857
    Title: Add relation to Scope Class
    Source: Frédéric Madiot, MIA Soft,

    Summary:
    This issue addresses a lack of navigability in scopes.

    Discussion:
    Here are our modifications of SMM beta 2 specification:
    Class Scope
    we have added 2 references :
    • a “non containment” reference called 'parent', type Scope (0..1), to link a scope to its parent.
    • a “non containment” reference called 'children', type Scope (0..*), to link a scope to its children.

    Summary of change:
    • Add a new relation to Scope class:

    o In the documentation for Scope, in the Associations sub-section, add the following new element:
    children: Scope[0..*] Specifies the parent scope of this scope.
    parent: Scope [0..*] Specifies the children scopes of this scope.

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    Reason for rejection: Scopes are sets and do not have a single inherent hierarchy.
    Disposition: Closed, no change

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

Add missing containment relation from SmmElement to SmmRelationship

  • Key: SMM11-101
  • Legacy Issue Number: 15854
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: OMG AB

    Summary:
    This issue addresses a relation that in the diagram that was not documented in the specification.

    Discussion:
    The architecture board as recommended that we add the necessary documentation change to describe a missing containment relation in the specification.

    Summary of change:
    • In the documentation for SmmElement, in the Associations sub-section, add the following new element:
    ownedRelation:SmmRelationship[0..*] Primitive SMM relationships that originate from the current SmmElement.

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    Containment at this level of abstraction (SmmElement is so broad, and so is SmmRelationship) is not meaningful. Even when one would want it, it should then be properly defined via properties that are derived unions, based on properties (at specialized level) that are their subsets. The association is very under-defined in the meta-model. It did not even have names for its ends. Hence the inconsistency has better be resolved the other way round: by removing the association from the meta-model also. This is done per resolution of issue 19602.
    Disposition: Closed, no change

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

Remove the TimeStamp primitive type

  • Key: SMM11-106
  • Legacy Issue Number: 19604
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: Remove the TimeStamp primitive type

    The TimeStamp primitive type is not used at any point in SMM and it should be, consequentially, be removed.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    Superseded by issue 19704.
    Disposition: Closed, no change

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

It is unclear how rescaling is possible from more than 1 simultaneously

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

    According to the SMM spec, a RescaledMeasure can rescale from 0..* binary measures, and a RescaledMeasurement can rescale from 0..* binary measurements accordingly.
    This is strange however. It is unclear how rescaling is possible from more than 1 simultaneously. Seems that the multiplicity should be 1 instead of 0..*.

  • Reported: SMM 1.0 — Tue, 17 Jul 2012 04:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    The Summary suggests that not only the “” in the multiplicity of RescaledMeasurement.rescaleFrom is wrong, but the “” in the multiplicity of RescaledMeasure.rescaleFrom as well. This is incorrect. It should still be possible that a RescaledMeasure has multiple rescaleFrom relationships. Hence issue 19718 was created afterwards, superseding 17504.
    Disposition: Closed, no change

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

Allow more normative options for language of operation body

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

    Allow more normative options for language of operation body. Allow at least JSON, to be able to express operations in url format

  • Reported: SMM 1.0 — Fri, 13 Jul 2012 04:00 GMT
  • Disposition: Closed; No Change — SMM 1.1
  • Disposition Summary:

    Discussion:
    Issue 19408 provides a better solution. Also, JSON is not a query language and would be inappropriate in any case.
    Disposition: Closed, no change

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

The metamodel defines MOF operations for derived Properties

  • Key: SMM11-107
  • Legacy Issue Number: 15476
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The metamodel defines MOF operations for derived Properties – this is redundant and as unnecessary as defining getters and setters for normal Properties. For example SmmRelationship::getFrom()

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issue 19721 for disposition

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

Section 8.6, measureCategory

  • Key: SMM11-109
  • Legacy Issue Number: 15478
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 8.6, measureCategory, has an OCL constraint

    context CategoryRelationship inv:

    to.oclIsTypeOf(MeasureCategory) or

    measures.oclIsTypeOf(Measure)

    The last line is incorrect and should be to.oclIsTypeOf(Measure). However this is IMHO bad practice and there should be a more specific association than using AbstractMeasureElement

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issue 15855 for disposition

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

What is missing however is any semi-formal description of how the properties are derived – for example OCL

  • Key: SMM11-108
  • Legacy Issue Number: 15477
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    What is missing however is any semi-formal description of how the properties are derived – for example OCL

  • Reported: SMM 1.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issue 19722 for disposition

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

Change the spec from EMOF to CMOF

  • Key: SMM11-110
  • Legacy Issue Number: 15856
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: OMG AB

    Summary:
    This issue deals with the fact that the SMM didn’t take advantage of some of the provision of CMOF.

    Discussion:
    The architecture board as recommended that we change the SMM specification to be more in-line with CMOF rather than restricting ourselves to the EMOF model.

    Summary of change:
    • Modify SmmElement class
    o Remove operations section from SmmElement
    • Modify SmmRelationship class
    o Remove derived union attribute from the from and to associations.
    o In the documentation, in the Associations sub-section, update the content to remove the reference to derived union:
    from:SmmElement[1] The origin element (also referred to as the from-endpoint of the relationship).
    to:SmmElement[1] The target element (also referred to as the to-endpoint of the relationship).

    • Modify MeasureRelationship class
    o Remove derived union attribute from the from and to associations.
    o In the documentation, in the Associations sub-section, update the content to remove the reference to derived union:
    from:Measure [1] The origin element (also referred to as the from-endpoint of the relationship).
    to:Measure [1] The target element (also referred to as the to-endpoint of the relationship).

    • Modify MeasurementRelationship class
    o Remove derived union attribute from the from and to associations.
    o In the documentation, add the Associations sub-section (was missing), with the following content:
    Associations
    from:Measurement [1] The origin element (also referred to as the from-endpoint of the relationship).
    to:Measurement[1] The target element (also referred to as the to-endpoint of the relationship).

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issue 17212 for disposition

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

AdditiveMeasure

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

    In SMM spec the examples (instance models) have "AdditiveMeasure". But that is not existing in the spec (meta-model). I guess it is an oversight, and it should be CollectiveMeasure?

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

    Disposition: See issues 19450, 19609 and 19610 for disposition

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

Inconsistency between Examples (instance models) and meta-model

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

    Examples (instance models) in SMM spec suggest that rescaled measure has "operation", but the meta-model has "formula". This is probably an oversight ?

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

    Disposition: See issues 19450, 19609 and 19610 for disposition

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

Add a non-normative clause to the SMM doc which demonstrates a SMM library of basic unit conversions

  • Key: SMM11-89
  • Legacy Issue Number: 19453
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Add a non-normative clause to the SMM doc 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.1
  • Disposition Summary:

    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 to a next RTF.

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

Change compliance to use term “must” instead of “can”

  • Key: SMM11-118
  • Legacy Issue Number: 15852
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Summary:
    This issue addresses a wording problem with the compliance requirement.

    Discussion:
    The architecture board as recommended that we change the compliance condition from “can” to “must”.

    Summary of change:
    • In section 2, change “An implementation can provide “ to “An implementation must provide “

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    In Clause 2, change “An implementation can provide “ to “An implementation must provide“. Similar problem is fixed in a few constraints

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

SMM confuses "To" and "From"

  • Key: SMM11-90
  • Legacy Issue Number: 19607
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: 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 from 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.1
  • Disposition Summary:

    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: Wed, 8 Jul 2015 11:44 GMT

Base SMM on CMOF instead of EMOF

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

    SMM 1.0 assumed EMOF, which is limited. CMOF should be used instead. This issue supersedes 15856, because that issue was earlier balloted with a resolution that was irrelevant to “EMOF versus CMOF” and even unwanted.

  • Reported: SMM 1.0 — Wed, 11 Feb 2015 05:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issue 17212 for disposition

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

Make all examples shown in the non-normative clauses of the SMM doc compatible with the latest SMM spec

  • Key: SMM11-116
  • Legacy Issue Number: 19451
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Make all examples shown in the non-normative clauses of the SMM doc compatible with the latest SMM spec

  • Reported: SMM 1.0 — Thu, 5 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — SMM 1.1
  • Disposition Summary:

    Disposition: See issues 19609 and 19610 for disposition

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

Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure

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

    Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure.
    I think that the meta-model suggests that these don't exist (anymore ?), as there's only CollectiveMeasure

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

    Disposition: See issues 19450, 19609 and 19610 for disposition

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

Wrong reference

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

    In examples/instances of rescaled measures in SMM spec, there is sometimes reference (from formula string) to "baseMeasure". But that is wrong, as according to the meta-model, a rescaled measure does not have “base measure”, but “rescale from” ?

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

    Disposition: See issues 19450, 19609 and 19610 for disposition

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

RescaledMeasure

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

    In SMM spec, there's this text, for RescaledMeasure:

    Associations:

    baseMeasure:DimensionalMeasure: Identifies the measure applied to each “contained” entity to determine base measurements.

    rescaleFrom:RescaledMeasureRelationship[0..*]: Specifies the relationship instance that defines the measure rescaled by this rescaled measure.

    However: the meta-model diagram suggests that there is only rescaleFrom. No baseMeasure.

    This is wrong.

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

    Disposition: See issue 19717 for disposition

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

Attributes to be added to Measurement

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

    Add the following attributes to Measurement, to enable expression of measurement precision, and stochastic aspects of measurements: “confidence interval upper bound”, “confidence interval lower bound”, “confidence” (being a probability) and “distribution”(string).

  • 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. The following was considered to further accommodate stochastic measurement:
    • Stochastic measurement (e.g. in the context of simulation) usually comes with large sets of Measurements. SMM does already support that a large set of Measurements is “summarized”. Example: 10000 Measurements are the basis for a CollectiveMeasurement (which expresses the mean or some other accumulation). For scalability reasons there should still be a way to reach out to the large set of Measurements, without populating these Measurements in the model itself. Leaving the base Measurements out of the model is already possible via value “false” for attribute “isBaseSupplied” of a CollectiveMeasurement. Reaching out to the (external) base Measurements can be facilitated by an additional association “baseQuery” (analogous to defaultQuery).
    • To take stochastic Measurements based on SMM, a separate Measure would be defined, whereby stochastic methods may implemented via Operation of the Measure. In SMM, Arguments of an Observation serve as parameters to the Operation. In order to be able to vary stochastic parameters within an Observation, Arguments can, additionally, be associated with ObservedMeasure. This will give a practical and SMM-compliant way to handle Operation parameters, both stochastic parameters and parameters in general.
    Hence, resolution is twofold:
    • Both Observation and ObservedMeasure can have Arguments associated.
    • Add baseQuery to non-direct Measurement, whereby baseQuery is an Operation that specifies a query that can used to determine the base measurements of a non-direct Measurement when isBaseSupplied = false. baseQuery is optional even when isBaseSupplied = false and isBaseSupplied is inapplicable when isBaseSupplied = true. baseQuery and defaultQuery should not create inconsistencies. Directly supplied base Measurements would always have precedence. baseQuery would have secondary precedence and defaultQuery has the lowest precedence. The two queries then present two different ways of cutting off the supplied Measurements. defaultQuery allows a user to cut off base Measurements of Measurements of a given Measure. baseQuery allows a user to cut off the base Measurements of a given non-direct Measurement.

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

The measurand of Measurement, which references Element (MOF), is owned by Measurement

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

    The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself – and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1

    {redefines C2:p2}

    then C2 must be a supertype of C1 (directly or indirectly).

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

    The measurand of Measurement, which references Element (MOF), should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change.
    The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1

    {redefines C2:p2}

    then C2 must be a supertype of C1 (directly or indirectly).

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

SMM metamodel contains class "MofElement".

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

    SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element

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

    SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element

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

Scope of a measure should be made optional

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

    The following changes have been submitted and are pending with the SMM (Structured Metrics
    Metamodel) RTF.

    Scope of a measure should be made optional.

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

    Keep scope required. Add two new attributes, name and description. Add a new constraint that requires that either the class attribute is given or that both the name and description attributes are given. In the spec, give as example: Area of a square; no class named “square”. Binary Measure with “area” as trait (maybe “size” as parent of “area”), “times” as functor, Base Measure1 being Side1 Length and Base Measure2 being Side2 Length. Scope with “Square” as name, and “2 dimensional closed object with 4 equal length sides” as description.

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

SMM should use MOF 2.4.1

  • Key: SMM11-121
  • Legacy Issue Number: 17212
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SMM should use MOF 2.4.1.

    This makes it easier to create the metamodel (the UML model can be used largely as-is) and is required for compatibility with VDML which is dependent on SMM.

  • Reported: SMM 1.0 — Thu, 8 Mar 2012 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Export UML 2.4.1 XMI from Enterprise Architect (the source tool as used for SMM 1.0), which will retain the SMM diagrams going forward and allow inclusion of the other fixes (it covers issue 19720, as SMM 1.1 will use CMOF, and does e.g. enable resolution of issue 17471).
    As part of this, and the correct application of CMOF for meta-modeling, according to MOF 2.4.1, name any unnamed property or association in the model, and for any property that has visibility “private”, change it to visibility “public”. Also, name any unnamed operation return parameter in the model, provide return parameter type where omitted, and for any such parameter that has visibility “private”, change it to visibility “public”.

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

Fix OCL constraint in CategoryRelationhsip

  • Key: SMM11-120
  • Legacy Issue Number: 15855
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: OMG AB

    Summary:
    This issue addresses an incorrect constraint on a relation.

    Discussion:
    The architecture board as recommended that we correct the relation constraint in CategoryRelationship as it did not accurate.

    Summary of change:
    • In the documentation for CategoryRelationship, in the Constraints sub-section, change the content to now read:
    context CategoryRelationship inv:
    to.oclIsTypeOf(MeasureCategory) or
    to.oclIsTypeOf(Measure)

  • Reported: SMM 1.0 — Tue, 30 Nov 2010 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Reference to association end “measures” should be replaced with reference to “to”.

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

Clarify that XQuery is defined as mapping to XMI with correct version number

  • Key: SMM11-119
  • Legacy Issue Number: 15853
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: OMG AB

    Summary:
    This issue deals with the fact that XQuery is not defined and it’s mapping to XMI is also not well defined.

    Discussion:
    The architecture board as recommended that we clarify the mapping of XQuery to XMI and identify the versions in use.

    Summary of change:
    • In section 3, “Normative References”, add the following:
    o OCL 2.2 Specification
    o XQuery 1.0, XPath 2.0 (W3C Recommendation)
    • In section 7, “SMM” at the end of the section add the following:
    In a number of places, SMM supports querying or constraining data of interest by specifying some queries. Such queries can be expressed either with OCL version 2.2 as published by the OMG, or with XQuery 1.0 as published by the W3C. For XQuery, SMM uses a variant of XPath 2.0 (part of XQuery 1.0) and maps it to XMI using the following rules:
    • XPath uses a path expression where each path is a series of steps separated by forward slashes .
    • The steps are evaluated from left to right, and generally decend the model's tree as they do so
    • Each step identifies tree nodes by their classifier name and attributes are specified, just as in XPath with a leading @.
    SMM implementations are encouraged to implement OCL and XQuery by providing a wrapper that exposes their models to 3rd party query engines that implement all of the complexities of those languages.

  • Reported: SMM 1.0 — Wed, 1 Dec 2010 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Resolution given in issue statement

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

Allow multiple operations for a direct measure (multiplicity 0..*)

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

    Allow multiple operations for a direct measure (multiplicity 0..*). In addition add attribute “type” (String) to DirectMeasure. When “type” is filled, it corresponds to observation type

  • 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. The following was considered to further variations of Operation:
    • Instead of one Measure with multiple Operations, it fits SMM better to use multiple Measures, each with one Operation, and all for the same Charactersitic (trait).
    • These multiple Measures might be stored in a MeasureLibrary of structured Measures, and might be the operational counterparts of a less structured or informal Measure (typically a NamedMeasure) in another MeasureLibrary. That informal Measure might be referenced by the others as their “source” (for traceability reasons). A “source” attribute might be added to Measure to support this. This will also generally enable Measure maintenance, whereby e.g. a library of informal Measures, possibly obtained as standard industry Measures, are worked into multiple more structured (and operational) Measures in other MeasureLibraries.
    Hence, the resolution is to add “source” (string) as property to Measure.

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

Add accumulator value “product”.

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

    Assume that you have 5 measurements (according to their measures), and that you just want to multiple the results of all 5: result 1 * result 2 * result 3 * result 4 * result 5.

    This can be done in SMM as follows:
    1) 4 binary measures, with functor "times" , or
    2) 4 rescaled measures, with formula " * baseMeasurement"

    But wouldn't it be very handy to just have 1 collective measure, whereby accumulator would be “product” ?
    Currently the accumulators are just "sum", "max", "min", "avarage" and "stdv".

    Proposal: Add accumulator value “product”.

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

    Add enumeration value “product” to Accumulator

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

CollectiveMeasurement class

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

    In CollectiveMeasurement class:

    Text says:
    Associations:

    baseMeasurement:DimensionalMeasurement[0..*]: Identifies the measurements from which this collective measurement was derived.

    However: the meta-model suggests that there's baseMeasurementTo. Not baseMeasurement.

    So, the associations text is wrong.

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

    In CollectiveMeasurement class, replace Association “baseMeasurement:DimensionalMeasurement [0..*], Identifies the measurements from which this collective measurement was derived”, with “baseMeasurementTo:BaseMeasurementRelationship [0..*], Specifies the relationship instance that defines the accumulation for this measurement”.
    Similar problem should also be fixed in a few other places.

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

Should a binary measure have a formula next to a functor ?

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

    In SMM, a binary measure has a functor.
    Examples in the spec (instance models) suggest functor values like “sum”, “difference”, “times”, “divide”.
    This sounds like functor should have an enumeration defined in the spec, like also accumulator has for a collective measure.
    However, SMM does not do that for functor. Why not? It is rather similar (see also that accumulator has a value “sum” ..).
    On the other hand: an enum can be too rigid, as it is not easily extendable. As Alain Picard has admitted, it would for vendors be more flexible to also allow formula’s (like rescaled measures have), for binary measures, e.g. “A * B” (instead of functor “times” to multiple A and B).
    But that would require that a binary measure should have a formula next to a functor ?

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

    The RTF discussed this issue, along with issues 17483 and 17503 and found a resolution which which is consistent with the resolution of both the other issues.
    Per resolution of issue 17483, a BinaryMeasure, as DimensionalMeasure, has an optional formula.
    Per resolution of issue 17503, a BinaryMeasure has an Operation (as customFunctor), if and only if its functor is custom. For this Operation the context is a measurand and a pair of base measurements.
    Per Resolution of issue 17483, also a RescaledMeasure, as DimensionalMeasure, has an optional formula. Consistent with the resolutions for both CollectiveMeasure (per issue 17483) and BinaryMeasure (per issue 17503), the RTF then proposes to further revise RescaledMeasure, as follows:
    • Add “offset” and “multiplier” to RescaledMeasure. For example, F = (C*9/5)+32. The addend (e.g. 32) is the offset and 9/5 is the multiplier.
    • RescaledMeasure has an operation if and only if its multiplier and offset are not given. The context of it a measurand and a base measurement.

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

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

functor should have an enumeration defined in the spec

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

    In SMM, a binary measure has a functor.

    Examples in the spec (instance models) suggest functor values like “sum”, “difference”, “times”, “divide”.

    This sounds like functor should have an enumeration defined in the spec, like also accumulator has for a collective measure.

    However, SMM does not do that for functor. Why not? It is rather similar (see also that accumulator has a value “sum” ..).

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

    Introduce an Enumeration type for functor, with enumeration values “sum”, “difference”, “times” (or “product”) and “divide”, and also “custom”. In case the BinaryMeasure’s functor has value “custom”, also specify customFunctor, being an association to Operation (with association end name customFunctor).

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

CollectiveMeasurement attribute wrong

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

    The class CollectiveMeasurement has attribute "accumulator". This is wrong, as the CollectiveMeasure class has that attribute. CollectiveMeasurement should not have it therefore.

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

    Remove accumulator from CollectiveMeasurement, as only CollectiveMeasure should have that property

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

RatioMeasurement

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

    In SMM spec there's the class RatioMeasurement.

    However, in the beta2 spec, it is misspelled as RatioMeasurment..

    This should be corrected.

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

    Replace Class name “RatioMeasurment” with “RatioMeasurement” in the specification.

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

The class DimensionalMeasure should be abstract

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

    The class DimensionalMeasure should be abstract. Like also DimensionalMeasurement is abstract.
    This is an inconsistency in the spec.

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

    Both DimensionalMeasure and DimensionalMeasurement should be abstract

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

Scales of Measurement

  • Key: SMM11-136
  • Legacy Issue Number: 17561
  • Status: closed  
  • Source: CAST Software ( Bill Curtis [X] (Inactive))
  • Summary:

    A standard component of measurement theory is 'Scales of Measurement' because they constrain the types of mathematical operations that can be performed on a measure. The base set of scales are 'Nominal', 'Ordinal', 'Interval', and 'Ratio'. The representation of a measure in SMM should contain information about the scale of measurement to indicate how it can be used and the limits of the operations that can be performed. If there is a way to enforce these constraints that would be best, but lacking that it would be useful for the specification of a measure to contain information about its limits for those who would incorporate the measure in their applications.

  • Reported: SMM 1.0 — Wed, 22 Aug 2012 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add scaleOfMeasurement property to Measure, with enumerated type, consisting of the following five enumeration values: the four standard ones, namely “nominal”, “ordinal”, “interval”, and “ratio”, and the fifth being “custom”. In case of “custom”, the Measure has another string property instantiated, representing the custom scale (e.g. Guttman). In addition, add a few constraints, like: allow nominal & ordinal on GradeMeasure, and allow interval & ratio on DimensionalMeasure.

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

interval-based mapping

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

    A ranking in SMM results in a mapping to symbolic value (a string), which is unit-less, and which does not allow to be used as factor in further measure-based computations.
    It is required that similar interval-based mapping can also be used to result in a dimensional measurement, the value of which is numeric.

    Proposed changes:
    Rename SMM Ranking into GradeMeasure
    Rename SMM Grade into GradeMeasurement
    Rename RankingInterval into GradeInterval.
    Add another measure, called RankingMeasure (specialization of DimensionalMeasure); It has associated RankingInterval (very much like the existing ones)
    Ranking intervals of RankingMeasure have a numeric value instead of a symbolic string value.

  • Reported: SMM 1.0 — Wed, 1 Aug 2012 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Rename Ranking into GradeMeasure. Rename Grade into GradeMeasurement. Rename RankingInterval into GradeInterval. Add another Measure, called RankingMeasure (specialization of DimensionalMeasure). It has associated RankingInterval (very much like the existing one). Ranking intervals of RankingMeasure have a numeric value instead of a symbolic string value

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

New SMM RTF Issue: Need "Opaque" operation body language

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

    "Section 10.5 (Operation Class) defines as normative languages "OCL" and "XQuery". This is too restrictive. An implementer should be able to implement Operations differently, without conflicting with the spec. Hence we suggest to add "Opaque" as a valid value as well".

  • Reported: SMM 1.0 — Fri, 9 May 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    In addition to the currently specified ones (OCL, Xquery), allow user-supplied values for language. Which could be “English”, “French”, “SBVR” or whatever language they want to informally express the body in.

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

"Influence" of measure relationship

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

    Though, for MeasureRelationship in SMM, the "real" influence of one measure to other measure(s) is implied by the type of measure, its functors, operations, accumulators, etc., still it is, for business analyst understanding and maintenance sake very useful to add the influence type explicitly (the analyst may even define it before the actual functor or operation is specified). This will also be helpful in diagrammatic understanding in one glance of how measurements are influencing each other.

    Resolution (as agreed with Larry Hines):

    Add optional property "Influence" to MeasureRelationship. This is property with enumeration type "Influence", having 2 enum values: "positive", "negative".
    In addition: a constraint, specifying that this property is not allowed for "EquivalentMeasureRelationship".

  • Reported: SMM 1.0 — Tue, 18 Sep 2012 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add optional property "influence" to MeasureRelationship. This is a property with enumeration type "Influence", having two enumeration values: "positive", "negative".
    In addition, a constraint is added, specifying that this property is not allowed for EquivalentMeasureRelationship (and neither for RefinementMeasureRelationship).

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

Observation has Arguments associated

  • Key: SMM11-141
  • Legacy Issue Number: 19448
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The association list of Observation class fails to include the arguments association to the Argument class.

  • Reported: SMM 1.0 — Wed, 4 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add the arguments association to the Associations table of the Observations Class

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

Unit consistency

  • Key: SMM11-140
  • Legacy Issue Number: 19447
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The semantics section of each collective measure class should discuss unit consistency. For example, the units of measure for the base measures must be equivalent to the unit of measure for the binary measure when the functor is addition.

  • Reported: SMM 1.0 — Wed, 4 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Write some text about unit consistency for all aggregating Measures (CollectiveMeasure, BinaryMeasure, and RescaledMeasure). The text may be at the base relationship level instead of at the Measure level.

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

Typo in Constrains for BinaryMeasurement Class

  • Key: SMM11-139
  • Legacy Issue Number: 19426
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The constraints in Section 14.4 (BinaryMeasurement Class) should have BinaryMeasurement as the context, not RatioMeasurement.”

  • Reported: SMM 1.0 — Wed, 21 May 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace “RatioMeasurement” with “BinaryMeasurement” as context in the constraint of BinaryMeasurement Class.

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

Make all examples shown in the normative clauses of the SMM doc compatible with the latest SMM spec

  • Key: SMM11-142
  • Legacy Issue Number: 19450
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Make all examples shown in the normative clauses of the SMM doc compatible with the latest SMM spec

  • Reported: SMM 1.0 — Thu, 5 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Make all examples (object diagrams) in the normative clauses of the SMM specification compatible with all balloted and accepted resolutions that impact the SMM meta-model.

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

Constraints on aggregating measurement classes

  • Key: SMM11-144
  • Legacy Issue Number: 19456
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Constraints on CollectiveMeasurement, BinaryMeasurement, RatioMeasurement and RescaledMeasurements are wrong. None have been updated to use their base measurement relationships.

  • Reported: SMM 1.0 — Sat, 7 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Constraints updated to reference base measurement relationships

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

Add a re-scaling association to the all base measure relationship

  • Key: SMM11-143
  • Legacy Issue Number: 19452
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Add a re-scaling association to the all base measure relationship which support in-lining re-scaling to the other various collective measures

  • Reported: SMM 1.0 — Thu, 5 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Associate BaseMeasureRelationship with RescaledMeasure, which enables to "transform" the base measurements upon aggregation to e.g. collective or binary measurement. This will make CollectiveMeasures, BinaryMeasures, etc. more powerful, so that users can achieve the same with less Measures.

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

Introduce Unit of Measure as a class.

  • Key: SMM11-145
  • Legacy Issue Number: 19457
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Currently DimensionalMeasure has Unit of measure as an attribute with type string. Unit needs to be treated as a first class object and not just indicated by a name. A class need to be introduced for it and the attribute needs to be replaced with an association relating DimensionalMeasure to a Unit. Indication by name leaves open whether “meter”, “Meter” or “metre”. But the object for each would be the same and the case and internationalization would be left to rendering.

  • Reported: SMM 1.0 — Sat, 7 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace the "unit" property (string) of DimensionalMeasure, by a "unit" association from DimensionalMeasure to UnitOfMeasure. This will greatly improve re-use and consistency of units, across DimensionalMeasures. Unit conversion can be left to rendering.

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

Identify the observedMeasure role in the Association sub-clause of the Measurements class

  • Key: SMM11-148
  • Legacy Issue Number: 19583
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The constraints given in the subclasses of the Measurement class are wrong because there is no way to navigate from a Measurement to its measure without using the observedMeasure property of Measurement. That property needs to be documented. Then the constraints need to be fixed to use observedMeasure.

  • Reported: SMM 1.0 — Tue, 19 Aug 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Document the observedMeasure property of the Measurement class. Fix the OCL constraints of the Measurement sub-classes to use observedMeasure

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

Interval Open attributes

  • Key: SMM11-147
  • Legacy Issue Number: 19565
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The description of the GradeInterval’s attributes maximumOpen and minimumOpen are backwards. It should say true iff the interval excludes the endpoint.

  • Reported: SMM 1.0 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    For attributes maximumOpen and minimumOpen, say true if the interval excludes the endpoint

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

Remove RecursiveMeasureRelationship and RecursiveMeasurementRelationship classes

  • Key: SMM11-146
  • Legacy Issue Number: 19497
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    We have no use cases demonstrating the value of these classes. They, moreover, are likely to introduce confusion about SMM. The classes and their associations should be removes.

  • Reported: SMM 1.0 — Mon, 30 Jun 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Remove RecursiveMeasureRelationship and RecursiveMeasurementRelationship classes.

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

Remove ownedRelation assocation from SmmElement and SmmRelationship

  • Key: SMM11-149
  • Legacy Issue Number: 19602
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The containment association, ownedRelation, between SmmElement and SmmRelationship is inappropriate in that both are abstract classes and unnecessary in that it is defined already between the concrete extensions of SmmElement and SmmRelationship

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Remove the containment association between SmmElement and SmmRelationship

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

ObservedMeasure should not extend SmmRelationship

  • Key: SMM11-150
  • Legacy Issue Number: 19603
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: ObservedMeasure should not extend SmmRelationship

    The “from” and “to” properties of SmmRelationship is not appropriate to ObservedMeasure. ObservedMeasure is a container (of measurements) for a measure and is not a relationship between a measurement and a measure.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    ObservedMeasure to extend SmmElement

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

Minimum and maximum attributes for the Interval class should be optional

  • Key: SMM11-156
  • Legacy Issue Number: 19643
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Minimum and maximum attributes for the Interval class should be optional

    For nominal or for ordinal the base measure and interval mapping are not needed. To make that more convenient, I propose to make the following changes.

    1. The minimum and maximum attributes for the Interval class will be optional

    Attributes
    maximumOpen:Boolean
    True if and only if interval excludes maximum endpoint. Default = false.

    minimumOpen:Boolean
    True if and only if interval excludes minimum endpoint. Default = false.

    maximum:Number[0..1]
    Identifies interval’s maximum endpoint.

    minimum:Number[0..1]
    Identifies interval’s minimum endpoint.

    2. We add constraints to Interval indicating that if either minimum or maximum is defined then both are defined.

    Constraints
    context Interval inv:

    if maximum.isOclDefined

    then minimum.isOclDefined and maximum = minimum and

    (maximumOpen or minimumOpen ? maximum > minimum)

    else not minimum.isOclDefined

    3. We add constraints to RankingInterval requiring a maximum (and implicitly a minimum).

    Constraints
    context RankingInterval inv:

    maximum.isOclDefined

    4. We add constraints to GradeMeasure forbidding the intervals without minimum or maximums if gradeTo is specified.

    Constraints
    context GradeMeasure inv:

    (gradeTo->notEmpty implies

    interval->forall(i | not i.minimum.isOclUndefined() and

    not i.maximum.isOclUndefined())) and

    (interval->exists(i | i.minimum.isOclUndefined() or

    i.maximum.isOclUndefined()) implies

    gradeTo->isEmpty)

  • Reported: SMM 1.0 — Thu, 16 Oct 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    (1) The minimum and maximum attributes for the Interval class will be optional. (2) Add constraints to Interval indicating that if either minimum or maximum is defined then both are defined. (3) Add constraints to RankingInterval requiring a maximum (and implicitly a minimum). (4) Add constraints to GradeMeasure forbidding the intervals without minimum or maximum if gradeTo is specified.

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

Provide some non-software non-normative measure examples

  • Key: SMM11-155
  • Legacy Issue Number: 19610
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: Provide non-software non-normative measure examples

    SMM should provide a few non-normative example measures especially non-software examples. The SEI maintainability measure could be up-dated as a software example and a few non-software examples added.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add a new clause for non-normative examples which should include SEI maintainability and some business examples.

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

Remove non-normative Library of Measures clause

  • Key: SMM11-154
  • Legacy Issue Number: 19609
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: Remove non-normative Library of Measures clause

    The non-normative Library of Measures clause is out-of-date with respect to SMM. It is too focused upon examples of software measures which is confusing now that SMM is applicable outside of software measurement. Also the clause contains no MeasureLibrary, CategoryRelationship or MeasureCategory elements and, thus, is not a demonstration of a library of measures.

    The non-normative Library of Measures clause should be removed.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Remove both non-normative Library of Measures clause and the non-normative Library of Categories clause.
    This resolution also covers what is requested for issue 19451, namely to make non-normative Measure examples that remain, compliant with the revised meta-model

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

Old measure(ment) names still persist in the document

  • Key: SMM11-153
  • Legacy Issue Number: 19608
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add a new issue of the SMM RTF: Old measure(ment) names still persist in the document

    The naming scheme for some measure and measurement classes is not consistent.

    For most measures and their corresponding measurement classes if the measure class is “X”Measure then the measurement class is “X”Measurement. This scheme is followed for all but the Counting measure class and its corresponding Count measurement class. Each should be renamed to CountingMeasure and CountingMeasurement respectively.

    Also, in places the “X”Measure or “X”Measurement is shortened to just “X”. For example in the specification sometimes Ratio is used, and sometimes RatioMeasure. Even the class's section is called "Ratio Class" .. It should be RatioMeasure consistently.

    Regarding Grade: It is, consistently and correctly, GradeMeasure in the model, and often in the document. But not always. There are occurrences in the document where you use Grade, and where it better should be GradeMeasure (or GradeMeasurement, if it is about the measurement side). Sometimes there is just qualitative speak where you can leave it like "grade", but sometimes it is meant as more formal, where it still reads as "grade", e.g. somewhere you talk "grade subclass" (should be GradeMeasure), and sometimes "Grade measure", which should be GradeMeasure, etc. Maybe you find all "grade" occurrences and fix some of them. The same problem might exist wrt Ranking.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Replace "Ratio" as name of the ratio measure class with "RatioMeasure".
    Similarly, replace “Counting” with “CountingMeasure” and “Count” with “CountingMeasurement”.
    The naming consistency problem regarding “Grade” has been fixed by the resolution of issue 17535.

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

The Percentage measure(ment) has been replaced by the RatioMeasure(ment)

  • Key: SMM11-152
  • Legacy Issue Number: 19606
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: The Percentage measure(ment) has been replaced by the RatioMeasure(ment)

    The old name, Percentage, still appears in 2 places in the document.

    The first reference is in the Measurement Class clause. It should be removed entirely. Percentage has been replaced by RatioMeasurement which is a subclass of DimensionalMeasurement. Hence, the phrase “The DimensionalMeasurement and Percentage subclasses” simplifies to “The DimensionalMeasurement subclass”.

    The second reference is in Software Engineering Institute (SEI) Maintainability Index clause. The PercentageMeasure should be replaced with RatioMeasure.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Simplify the phrase “The DimensionalMeasurement and Percentage subclasses” in the text of the sub-clause of Measurement Class to “The DimensionalMeasurement subclass”.
    Note: The part about the second reference is actually resolved by issue 19609, which removed the problematic text.

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

An Operation should be reusable as the operation of multiple measures

  • Key: SMM11-151
  • Legacy Issue Number: 19605
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Please add another issue to the SMM RTF: An Operation should be reusable as the operation of multiple measures

    DirectMeasure may have an operation association with an Operation. That operation could be re-used by other measures as their operation which means to multiplicity should not be 1 for the unnamed role, but should be 0 to many.

    BinaryMeasure, similarly, may have a customFunctor association with an Operation as may a CollectiveMeasure have a customAccumulator association with an Operation. The operations could be re-used by other measures which means to multiplicity should not be 1 for the unnamed role, but should be 0 to many.

  • Reported: SMM 1.0 — Thu, 18 Sep 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Change multiplicity to 0..* for associated Operation as shown in Figures 5,6 and 7.

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

Generalize Scope to include stereotypes

  • Key: SMM11-157
  • Legacy Issue Number: 19646
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Stereotypes, like classes, define sets of objects which can be measured and should be allowed as a way to define the scope of a measure.

  • Reported: SMM 1.0 — Thu, 23 Oct 2014 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Add optional stereotype attribute to Scope class. Make its class attribute optional. Add a constraint to allow the scope to be specified by either the class or the stereotype attribute. Add text in the semantics class about stereotype specifying the scope of a measure.

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

Some Associations and Roles do not have names in SMM

  • Key: SMM11-159
  • Legacy Issue Number: 19711
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    Association from MeasureCategory to MeasureCategory did not have a name. The ends did have names. Named it HasSubCategory. The name is not visible in any diagram and does not appear in the doc.

    The HasCategories association from MeasureLibrary to CategoryRelationship had one unnamed end. Named it libraries. The end is owned by the association. The name is not visible in any diagram and does not appear in the doc.
    The following association end is private, whereas it must be public: in the RescaledMeasure – Operation association, the end of RescaledMeasure (rescalesFor)".

  • Reported: SMM 1.0 — Mon, 19 Jan 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Name association from MeasureLibrary to MeasureLibrary as “HasSubCategory”. Name the unnamed end of the HasCategories association from MeasureLibrary to CategoryRelationship as “libraries”. Change visibility of the rescalesFor end of the association between RescaledMeasure and Operation from private to public. These changes impact the XMI only.

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

Apply Timestamp instead of Date and remove Date

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

    SMM 1.0 had both Date (sub-clause 8.8) and Timestamp (sub-clause 8.9) defined. Timestamp was nowhere used as type. Hence, in a previous ballot, we asked to vote for removing Timestamp (per issue 19604, “Remove the TimeStamp primitive type”). Meanwhile we encountered that Date was only used inconsistently. The meta-model diagrams showed Date as type of Observation.whenObserved, but the attributes table in sub-clause 16.2 just specified "date" (small) as type for that attribute. This is obviously wrong and has to be fixed. But this triggered new discussion, that resulted to the conclusion that Observation.whenObserved should not be typed by Date at all, but rather by TimeStamp, because SMM should enable taking snapshots or samples multiple times a day, and not just once a day. (Another reason why this error is only detected so late is the fact that in the SMM implementation of one of the implementers Date was mapped to java.util.Date which is actually a datetime type ...)

    Â

    Resolution: Change type of Observation.whenObserved from Date to TimeStamp. Update the attributes table in sub-clause 16.2, as well as all diagrams on which the attribute is exposed, accordingly. Remove Date (sub-clause 8.8), as it will no longer be used then. This issue will then also supersede issue 19604 (“Remove the TimeStamp primitive type”). It will also partly supersede the older issue 15479 (“it should be made clear that Date and Timestamp are PrimitiveTypes”). This issue will still impact the Timestamp class, but no longer the Date class, as it will now be removed.Â

  • Reported: SMM 1.0 — Thu, 15 Jan 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Change type of Observation.whenObserved from Date to TimeStamp. Update the attributes table in Sub-clause 16.2, as well as all diagrams on which the attribute is exposed, accordingly. Remove Date (sub-clause 8.8), as it will no longer be used then. This issue will then also supersede issue 19604 (Remove the TimeStamp primitive type). It will also partly supersede the older issue 15479 (it should be made clear that Date and Timestamp are PrimitiveTypes). This issue will still impact the Timestamp class, but no longer the Date class, as it will now be removed.
    Also make the mapping of TimeStamp to dateTime in XSD explicit in the XMI.

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

A RescaledMeasurement should not rescale more than one DimensionalMeasurement simultaneously

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

    Summary: Multiplicity of RescaledMeasurement.rescaleFrom is [0..*]. This is wrong. Because this would imply that it could rescale multiple DimensionalMeasurements simultaneously. It should be [0..1] therefore. This issue supersedes issue 17504. The reason is that issue 17504 suggested that the multiplicity of RescaledMeasure.rescaleFrom being [0..*] was also wrong and that it proposed to change it to [1] as well. That was wrong. Because the RescaledMeasure itself should be kept re-usable. But any application of it, i.e., a related RescaledMeasurement, should not rescale more than one DimensionalMeasurement.

    Resolution: Change multiplicity of RescaledMeasurement.rescaleFrom from [0..*] to [0..1]. Note that this cannot be higher than 1 (for reasons explained in Summary). On the other hand, it should allow "0", to stay consistent with the semantics of the RescaledMeasurement.isBaseSupplied. Multiplicity of RescaledMeasure.rescaleFrom will also change, but from [0..*] to [1..*]. The “*” in this is to keep the possibility of reuse of a RescaledMeasure, and the “1” in this is to make it more consistent with other aggregating Measures, which all aggregate from [1] DimensionalMeasure (instead of [0..1]). This resolution supersedes the resolution of 17504.Â

  • Reported: SMM 1.0 — Fri, 6 Feb 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Change multiplicity of RescaledMeasurement.rescaleFrom from [0..*] to [0..1]. Note that this cannot be higher than 1 (for reasons explained in Summary). On the other hand, it should allow "0", to stay consistent with the semantics of RescaledMeasurement.isBaseSupplied. Multiplicity of RescaledMeasure.rescaleFrom will also change, but from [0..*] to [1..*]. The “*” in this is to keep the possibility of reuse of a RescaledMeasure, and the “1” in this is to make it consistent with other aggregating Measures, which all aggregate from [1] DimensionalMeasure (instead of [0..1]).

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

Redundant association in Associations table of RescaledMeasure

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

    Summary: The SMM spec, in the Associations table of the sub-clause that defines the RescaledMeasure class, two associations are defined: “baseMeasure” and “rescaleFrom”. The meta-model only declares one of them, namely “rescaleFrom”. The other one, “baseMeasure”, is an oversight, and is redundant. It should be removed from the table. This issue supersedes issue 17478. The reason of this new issue, superseding issue 17478 is, that the resolution of 17478 also proposed a fix of the multiplicity of the association end of the other association (rescaleFrom), from [0..*] to [1], which was wrong.)

    Resolution: Remove the "baseMeasure" association from the Associations table of the RescaledMeasure class. This resolution supersedes the resolution of issue 17478.

  • Reported: SMM 1.0 — Fri, 6 Feb 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Remove the "baseMeasure" association from the Associations table of the RescaledMeasure class.

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

Incorrect types for associations of BinaryMeasure

  • Key: SMM11-160
  • Legacy Issue Number: 19712
  • Status: closed  
  • Source: Micro Focus ( Larry Hines)
  • Summary:

    The types of BinaryMeasure.baseMeasure1, BinaryMeasure.baseMeasure2 and BinaryMeasurement.baseMeasurement1To are wrong. The type should be a Measure(ment)Relationship class. Also, the descriptions of BinaryMeasure baseMeasure1, BinaryMeasure.baseMeasure2, BinaryMeasurement.baseMeasurement2 and CollectiveMeasurement.baseMeasurement are unclear

  • Reported: SMM 1.0 — Tue, 20 Jan 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    In Attributes table of BinaryMeasure class: Change the type of BinaryMeasure.baseMeasure1 to Base1MeasureRelationship, and its description to “Specifies the relationship instance that defines the first measure accumulated by this binary measure”. And change the type of BinaryMeasure.baseMeasure2 to Base2MeasureRelationship, and its description to “Specifies the relationship instance that defines the second measure accumulated by this binary”.
    In Attributes table of BinaryMeasurement class: Change the type of BinaryMeasurement.baseMeasurement1 to Base1MeasurementRelationship, and its description to “Specifies the relationship instance that defines the first base measurement accumulated for this measurement”. And change the type of BinaryMeasurement.baseMeasurement2 to Base2MeasurementRelationship, and its description to “Specifies the relationship instance that defines the second base measurement accumulated for this measurement”.
    In Attributes table of CollectiveMeasurement class: Change the type of CollectiveMeasurement.baseMeasurement to BaseNMeasurementRelationship, and its description to “Specifies the relationship instance that defines the accumulation for this measurement”.

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

Clarify that Observation.requestedMeasures is of type SmmElement and not AbstractMeasureElement

  • Key: SMM11-165
  • Legacy Issue Number: 18751
  • Status: closed  
  • Source: gmail.com ( Achraf Belmokadem)
  • Summary:

    It is currently the case that Observation.requestedMeasures is of type SmmElement. Constraints have been added to make sure that one does not pass a e.g. SmmModel instance as a requestedMeasure but only instances of type Measure, MeasureCategory and CategoryRelationship.

    My suggestion is to change the type from SmmElement to AbstractMeasureElement. We would then be able to measure the following:
    MeasureCategory - e.g. Measures that fall in the same category
    Scope - e.g. Measures that use the define the same scope
    Characteristic - e.g. Measures that are characterized by a certain characteristic
    Operation - e.g. Measures that use a certain operation
    OCLOperation - e.g. Measures that use a certain OCLOperation
    Measure

    This would make the metamodel cleaner by having lessing constraints and making it easier to understand. Could it be that this was caused because of the fact that there is no section about AbstractMeasureElement?

  • Reported: SMM 1.0 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Change the type of requestedMeasures to be AbstractMeasureElement

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

Improve the definition of derived properties

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

    There are three problems here: 1) Several derived unions (for from, to, inbound and outbound) are not defined correctly, e.g. at specialized level the properties where they are assumed to be derived from are not defined as their subsets. 2) They are defined as derived unions in the model, but not in the association tables in the specification, and 3) in the Association tables of Measure Class (10.5) and Measurement Class (13.1), the description of inbound and outbound both talk about the “to-endpoint”. But one of these two should be “from-endpoint”. This issue supersedes issue 15477 (because it was originally balloted with a resolution that was incorrect, as the actual problem was overlooked).Â

  • Reported: SMM 1.0 — Wed, 11 Feb 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    The properties that were so-far named “outbound” and “inbound”, of SmmElement and its specializations, should be derived unions (isDerivedUnion = true), but this requires that, the properties of specialized classes, from which they are derived, should be defined as subsets (subsettedProperty being set to the property that is the union). The “derived union” will make it unambiguous how the derivation is done, and in combination with “subsets” we apply it according to the UML rules. There is one problem in this: UML 2.4.1 (and still the same in UML 2.5) does not allow subsetting of property of same name. Hence we rename SmmRelationship.inbound and SmmRelationship.outbound to SmmRelationship.inRelationships and SmmRelationship.outRelationships respectively.
    Furthermore, to avoid that, at specialized level, classes Measure, Measurement, etc. have inherited property “inRelationship” next to “inbound” and “outRelationship” next to “outbound”, we define “inbound” as “redefines inRelationships” and “outbound” as “redefines outRelationships”.
    The properties “to” and “from” of SmmRelationship and its specializations are no longer derived. What is instead needed is that, at specialized levels, “to” “redefines” “to” of a parent level, and “from” “redefines” “from” of a parent level. This way we enforce that for any SmmRelationship there’s always exactly one “to” and one “from”. The changes implied here will impact both the model (and its diagrams) and the association tables in the corresponding sub-clauses of the specification.
    Furthermore, in the Association tables of Measure Class (10.5) and Measurement Class (13.1), the description of inbound and outbound both talk about the “to-endpoint”. But for outbound it should be the “from-endpoint”.

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

Remove getters of properties in the meta-model

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

    “Getters” for properties in the meta-model are redundant and unnecessary. For example SmmRelationship::getFrom(). These operations should be removed. This issue supersedes 15476 (because that issue was balloted originally as “duplicate / merged”, suggesting that the removal of such “getters” was already done as part of migration to CMOF. But that does not make sense.)

  • Reported: SMM 1.0 — Wed, 11 Feb 2015 05:00 GMT
  • Disposition: Resolved — SMM 1.1
  • Disposition Summary:

    Remove Operations tables from Sub-clauses 8.2 and 8.4.

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

Improve Label format support

  • Key: SMM-30
  • Legacy Issue Number: 14607
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    This is a small improvement upon the initial implementation of label format support.

    Discussion:
    The labelFormat attribute was added to the Measure class in issue #14101. Since then it has been noticed that there are actually 2 main use cases for labels. The first one is to provide a label that describes the measure and the other one is to provide a label describing the measurement. This issue addresses this shortcoming.

    Secondly, we are also here expanding the use of the Operation class by changing the specification of the label format in order to have queries simply defined in terms of Operations instead of declaring the query and its language within the label format.

    Summary of change:
    · Add new attribute and change name of existing one.
    o Rename attribute labelFormat:String in Measure class to measureLabelFormat:String
    o Add attribute measurementLabelFormat:String in Measure class.
    · Add new operations and change name of existing ones.
    o Rename operation getLabel():String in Measurement class to getMeasureLabel():String
    o Add operation getMeasurementLabel():String in Measurement class.
    · Change specification of labelFormat to support use of Operation
    o Change wording of standard syntax to the following:
    § The standard syntax, which is always valid, starts by specifying a context object, followed by a literal colon ":", then an operation whose name must be the name of a valid instance in the Operation class.

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add new attribute and change name of existing one.
    o Rename attribute labelFormat:String in Measure class to measureLabelFormat:String
    o Add attribute measurementLabelFormat:String in Measure class.
    • Add new operations and change name of existing ones.
    o Rename operation getLabel():String in Measurement class to getMeasureLabel():String
    o Add operation getMeasurementLabel():String in Measurement class.
    • Change specification of labelFormat to support use of Operation
    o Change wording of standard syntax to the following:
    ? The standard syntax, which is always valid, starts by specifying a context object, followed by a literal colon “:”, then an operation whose name must be the name of a valid instance in the Operation class.

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

Clarify role of NamedMeasure

  • Key: SMM-31
  • Legacy Issue Number: 14609
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Scales of Measurement are a fundamental property of a measure describing the allowable mathematical transformations that can be legitimately applied to it.

    Discussion:
    Attached are some URLs that will give you an overview of Scales of Measurement. They are a fundamental property of a measure describing the allowable mathematical transformations that can be legitimately applied to it. Since they therefore determine the statistical methods that can be applied to the measure, they need to be treated as a first level attribute of a measure.
    http://www.math.sfu.ca/~cschwarz/Stat-301/Handouts/node5.html
    http://en.wikipedia.org/wiki/Scale_of_measurement (not always written in easily understood terms)
    http://www.wadsworth.com/psychology_d/templates/student_resources/workshops/stat_workshp/scale/scale_01.html (tutorial - behavioral science view)

    Summary of change:
    · Add enumeration MeasurementScale
    o Add enu ordinal, nominal, interval and ratio.
    · Add attribute scale:MeasurementScale to Measure class
    o This defines the scale of Measurement for measurements produced by the measure.

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add named relation operation [0..1] from CollectiveMeasure to Operation
    • Add constraint specify that either an Accumulator or an Operation, but not both should be specified for instances of CollectiveMeasure.
    • Add documentation to clearly identify the defined uses of the NamedMeasure class.

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

Delete library attribute from Measure

  • Key: SMM-28
  • Legacy Issue Number: 14605
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    When the MeasureLibrary was introduced, this attribute was inadvertently left behind.

    Discussion:

    Summary of change:
    · Drop library attribute from Measure class

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Drop library attribute from Measure class

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

Add defaultQuery to Measure

  • Key: SMM-27
  • Legacy Issue Number: 14604
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The Measure class lacked a way to provide a default value when some children measure has no measurands. The defaultQuery plays that role.

    Discussion:
    The defaultQuery is simply a small improvement to handle the specific case where a non-direct measure (i.e. a measure that depends on another for its value) happens not to have any available value from what should have been its "base measure". This allows us to specify a default query or value to be returned instead of either null or of failing the measurement. This is a normal situation that can happen when certain optional "children" don't exist.

    Summary of change:
    · Add named relation default [0..1] form Measure to Operation

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add named relation defaultQuery [0..1] from Measure to Operation

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

Add additional Accumulator enum value and document Accumulator

  • Key: SMM-29
  • Legacy Issue Number: 14606
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Need to add Standard Deviation to the Accumulator enumeration.

    Discussion:
    Also need to add missing section documenting Accumulator in the specification. Was missing in document.

    Summary of change:
    · Add documentation for existing Accumulator enumeration
    · Add enum value of standardDeviation to Accumulator enumeration

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add documentation for existing Accumulator enumeration
    • Add enum value of standardDeviation to Accumulator enumeration

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

Change meaning of SMM Acronym

  • Key: SMM-8
  • Legacy Issue Number: 14095
  • Status: closed  
  • Source: Tactical Strategy Group, Inc. ( Mr. William Ulrich)
  • Summary:

    SMM initially stood for Software Metrics Meta-Model, but from its inception, the meta-model was always made to support measuring any MOF based elements. As it became clear in the community that this specification was really applicable to more than software, the meaning of its name started to become an issue and a distraction. As such it has been recommended to change the meaning of the name to Structured Metrics Meta-Model in order to reflect that the metrics apply equally well to any structured model elements. Summary of change:
    · Change title on cover page
    · Change name on Co-submitting companies and supporters
    · Change name on all document footer
    · Changes in Scope section
    · Changes in Conformance section
    · Changes in SMM section
    · And other places as shown in the change bar document

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Change title on cover page
    • Change name on Co-submitting companies and supporters
    • Change name on all document footer
    • Changes in Scope section
    • Changes in Conformance section
    • Changes in SMM section
    • And other places as shown in the change bar document

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

Change to the Scope Class

  • Key: SMM-13
  • Legacy Issue Number: 14100
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    A number of changes were made in the scope class in order to better support library of measures, reduce coupling, support dynamic measures and help clarify and document the format of the class attribute.

    Discussion:

    Summary of change:
    · Remove "enumerated" attribute
    · Remove "element" association
    · Document and define content of "class" attribute
    · Add new "breakValue" attribute and define its allowable content
    · Add new "recursive" attribute
    · Add a new equivalent "breakValue" attribute to the measurement class

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Remove “enumerated” attribute
    • Remove “element” association
    • Document and define content of “class” attribute
    • Add new “breakCondition” attribute and define its allowable content (updated in 14602)

    • Add a new equivalent “breakValue” attribute to the measurement class

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

Graph corrections

  • Key: SMM-12
  • Legacy Issue Number: 14099
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    A number of small corrections were made to some of the graphs, outside of any changes to the specification.

    Discussion:

    Summary of change:
    · Show missing parent Characteristic association in Characteristic
    · Show missing attributes to the SmmElement class
    · Measurement graph didn't show measurand association

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Show missing parent Characteristic association in Characteristic
    • Show missing attributes to the SmmElement class
    • Measurement graph didn’t show measurand association

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

Correct Naming of Elements

  • Key: SMM-9
  • Legacy Issue Number: 14096
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    There are a number of inconsistencies in the SMM specification in regards to naming of classes and elements. This results in various classes being renamed in order to provide a more uniform naming convention, as was also done during the KDM FTF.

    Discussion:

    Summary of change:
    · Change SMM_Model to SmmModel everywhere
    · Change SMM_Element to SmmElement everywhere
    · Change SMM_Relationship to SmmRelationship everywhere
    · Change Category_Relationship to CategoryRelationship everywhere
    · Change SMM_Category to Category (only use SMM for core elements of Model, Element and Relationship)
    · Change short_description to shortDescription

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Change SMM_Model to SmmModel everywhere
    • Change SMM_Element to SmmElement everywhere
    • Change SMM_Relationship to SmmRelationship everywhere
    • Change Category_Relationship to CategoryRelationship everywhere
    • Change SMM_Category to Category (only use SMM for core elements of Model, Element and Relationship)
    • Change short_description to shortDescription

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

Correct Category Associations

  • Key: SMM-11
  • Legacy Issue Number: 14098
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The associations for the Category class were not captured correctly and there was also a name duplication.

    Discussion:

    Summary of change:
    · Add documentation of category association in Category
    · Improve documentation and cardinality of categoryElement association in Category
    · Rename 2nd categoryElement association to categoryMeasure in Category
    · Remove parameter association in Category

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add documentation of category association in Category
    • Improve documentation and cardinality of categoryElement association in Category
    • Rename 2nd categoryElement association to categoryMeasure in Category
    • Remove parameter association in Category

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

Correct SmmRelationship Associations

  • Key: SMM-10
  • Legacy Issue Number: 14097
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Summary:
    The associations for the SmmRelationship class should be marked as derived union and should also have opposites of inbound and outbound as derived unions as well.

    Discussion:

    Summary of change:
    · Add inbound and outbound association in SmmElement
    · Change to and from association in SmmRelationship to indicate derive union

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add inbound and outbound association in SmmElement
    • Change to and from association in SmmRelationship to indicate derive union

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

Add better support for Operations and OCL code reuse

  • Key: SMM-25
  • Legacy Issue Number: 14602
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This issue will help clarify operations that use to be defined only as string and it also introduces a powerful mechanism to support code reuse when dealing with OCL, thus strengthening OCL support in the model.

    Discussion:
    In the original design of the SMM spec, operations were just defined as string, not even mentioning the nature of those strings. An earlier issue (#14103) provide for the initial introduction of the Operation class for use by DirectMeasure. The use of the Operation class is being extended to other operations, such as mapping, breakCondition and recognizer.
    The second part is the introduction of the OCLOperation class. This class allows for the definition and registration of OCL helper methods in the context of specific classifiers. These operations allow for the definition and reuse of often lengthy and complex OCL methods. It is the implementer's responsibility to determine how to best provide for the parsing or execution environment of those methods. Any helper method that is defined with an OCLOperation then becomes available for OCL based operations applied to the proper classifier.

    Summary of change:
    · Change generalization of Operation to AbstractMeasureElement
    o Operation was not correctly sub-classed and that lead to issues of containment
    · Add OCLOperation class, a generalization of AbstractMeasureElement
    o Add attribute context:String
    § Context defines to OCL the classifier for which this operation is defined.
    o Add attribute body:String
    § The OLC helper function code
    · Change type of mapping in EquivalentMeasureRelationship to Operation
    o Drop attribute mapping in class EquivalentMeasureRelationship
    o Add named relation mapping [0..1] form EquivalentMeasureRelationship to Operation
    · Change breakCondition type to Operation
    o Drop attribute breakCondition in class Scope
    o Add named relation breakCondition [0..1] form Scope to Operation
    · Change recognizer type to Operation
    o Drop attribute recognizer in class Scope
    o Add named relation recognizer [0..1] form Scope to Operation

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Change generalization of Operation to AbstractMeasureElement
    o Operation was not correctly sub-classed and that lead to issues of containment
    • Add OCLOperation class, a generalization of AbstractMeasureElement
    o Add attribute context:String
    ? Context defines to OCL the classifier for which this operation is defined.
    o Add attribute body:String
    ? The OLC helper function code
    • Change type of mapping in EquivalentMeasureRelationship to Operation
    o Drop attribute mapping in class EquivalentMeasureRelationship
    o Add named relation mapping [0..1] from EquivalentMeasureRelationship to Operation
    • Change breakCondition type to Operation
    o Drop attribute breakCondition in class Scope
    o Add named relation breakCondition [0..1] from Scope to Operation
    • Change recognizer type to Operation
    o Drop attribute recognizer in class Scope
    o Add named relation recognizer [0..1] from Scope to Operation

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

Add measurandQuery Operation to MeasureRelationship

  • Key: SMM-24
  • Legacy Issue Number: 14601
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Summary:
    The Measure class, through its related scope class, provides support for specifying the class of the measure, but it limited the scope of refinements to be based on containment relations. This new measurandQuery operation removes this limitation.

    Discussion:
    In the original design of the SMM spec, the definition of the refinement relation was not clearly defined or elaborated. This under specification would either lead to non-executable models that could use any refinement relation that they wish, or for executable models being forced to only support and understand containment refinement relations.
    The purpose of the measurandQuery is to allow models to be able to correctly specify the exact refinement relation, when this relation is not the default containment relation. It thus provide for an alternative way of adequately specifying the relation used to retrieve the appropriate measurands.

    Summary of change:
    · Add named relation measurandQuery[0..1] form MeasureRelationship to Operation

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add named relation measurandQuery[0..1] from MeasureRelationship to Operation

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

Add support for parameterized measure

  • Key: SMM-26
  • Legacy Issue Number: 14603
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Summary:
    Provide a mechanism by which measure can define and process replaceable arguments.

    Discussion:
    In the original design of the SMM spec, there is no provision to account for the fact that measures often need some parameter to operate. We often don't want the measure to apply to every possible measurand of a certain class. The original specification addressed this with the recognizer, but it failed to provide any means to supply variable information to those recognizers.
    This new support for parameterized measures, allows an operation to define a placeholder for an incoming argument and replace it at runtime with a specific value, like when dealing with date ranges for example.
    The implementer is responsible, when using the measure library in an executable fashion, to determine base on the requested measures of his observation, what are all of the arguments that should be passed in with the observation in order to properly perform the measurements.

    Summary of change:
    · Add DefaultQuery to Measure (constraint not DirectMeasure)
    o Add attribute type:String
    § This represents the type of the argument as it was defined in the operation. This value is only expected to come from the getXXXArguments() methods on the Measure class.
    o Add attribute value:String
    § This represent the value of the argument either as the default or as supplied with the observation
    o Add containment relation from Observation to Argument
    · Add operation getParamStrings():String[0..*] to Operation class
    o This operation returns the set of String that defines the parameter in use by an operation.
    o The format of a parameter within an operation is as follow:
    § '

    {' [typeName] parameterName [' ="' defaultValue '" '] '}

    '
    · where typeName represents the type of the parameter and is optional
    · where parameterName represents the name of the parameter (required)
    · where defaultValue represents a default value to offer (on getArguments()) or to use if not supplied as Argument to an observation. defaultValue is optional.
    · Add operation getArguments():Argument[0..*] to Measure class
    o This operation returns the set of arguments that the different operations of the measure have defined and got returned by getParamStrings().
    · Add operation getAllArguments():Argument[0..*] to Measure class
    o This operations returns the set of arguments for this measure and any child measure required for the execution of the measure. It should call getArguments() on itself and everyone of its child measures.

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add Argument class, a generalization of SmmElement
    o Add attribute type:String
    ? This represents the type of the argument as it was defined in the operation. This value is only expected to come from the getXXXArguments() methods on the Measure class.
    o Add attribute value:String
    ? This represent the value of the argument either as the default or as supplied with the observation
    o Add containment relation from Observation to Argument
    • Add operation getParamStrings():String[0..*] to Operation class
    o This operation returns the set of String that defines the parameter in use by an operation.
    o The format of a parameter within an operation is as follow:
    ? '

    {' [typeName] parameterName [' =”' defaultValue '” '] '}

    '
    • where typeName represents the type of the parameter and is optional
    • where parameterName represents the name of the parameter (required)
    • where defaultValue represents a default value to offer (on getArguments()) or to use if not supplied as Argument to an observation. defaultValue is optional.
    • Add operation getArguments():Argument[0..*] to Measure class
    o This operation returns the set of arguments that the different operations of the measure have defined and got returned by getParamStrings().
    • Add operation getAllArguments():Argument[0..*] to Measure class
    o This operations returns the set of arguments for this measure and any child measure required for the execution of the measure. It should call getArguments() on itself and everyone of its child measures.

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

Convert all measure and measurement relationship to use the relationship class

  • Key: SMM-23
  • Legacy Issue Number: 14600
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    This issue deals with the conversion of all the various relations around Measure and Measurement into relationship classes extended from SmmRelationship. It continues the standardization and renaming process, while making the model more versatile.

  • Reported: SMM 1.0b1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add all classes for measure and measurement relationships
    o Add RecursiveMeasureRelationship class, a generalization of MeasureRelationship
    ? Drop recursive attribute from Scope class
    o Add RefinementMeasureRelationship class, a generalization of MeasureRelationship
    ? Drop refinement relation from Measure class
    o Add RescaledMeasureRelationship class, a generalization of MeasureRelationship
    ? Drop BaseMeasure relation from RescaledMeasure class
    o Add RankingMeasureRelationship class, a generalization of MeasureRelationship
    ? Drop BaseMeasure relation from Ranking class
    o Add BaseMeasureRelationship class, a generalization of MeasureRelationship
    ? Drop BaseMeasure relation from CollectiveMeasure
    o Add Base1MeasureRelationship class, a generalization of MeasureRelationship
    ? Drop baseMeasure1 relation from BinaryMeasure
    o Add Base2MeasureRelationship class, a generalization of MeasureRelationship
    ? Drop baseMeasure2 relation from BinaryMeasure
    o Add RecursiveMeasurementRelationship class, a generalization of MeasurementRelationship to provide equivalent relation in measurement that exists in measure.
    o Add RefinementMeasurementRelationship class, a generalization of MeasurementRelationship to provide equivalent relation in measurement that exists in measure.
    o Add RankingMeasurementRelationship class, a generalization of MeasurementRelationship
    ? Drop BaseMeasurement relation from Grade class
    o Add RescaledMeasurementRelationship class, a generalization of MeasurementRelationship
    ? Drop BaseMeasurement relation from ReScaledMeasurement class (being renamed in other issue to RescaledMeasurement)
    o Add BaseMeasurementRelationship class, a generalization of MeasurementRelationship
    ? Drop BaseMeasurement relation from CollectiveMeasurement class
    o Add Base1MeasurementRelationship class, a generalization of MeasurementRelationship
    ? Drop BaseMeasurement1 relation from BinaryMeasurement class
    o Add Base2MeasurementRelationship class, a generalization of MeasurementRelationship
    ? Drop BaseMeasurement2 relation from BinaryMeasurement class
    • Rename consistently all XXX (Measure | Measurement) (Relationship)* classes
    o Rename class ReScaledMeasurement to RescaledMeasurement to be consistent with related measure class called RescaledMeasure
    o Rename EquivalentRelationship to EquivalentMeasureRelationship
    • Add missing operations to aggregate union result sets for relations on SmmElement, Measure and Measurement
    o Add operation getFrom():SmmElement[1] in class SmmRelationship
    o Add operation getTo():SmmElement[1] in class SmmRelationship
    o Add operation getInbound():SmmRelationship[0..*] in class SmmElement
    o Add operation getOutbound():SmmRelationship[0..*] in class SmmElement

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

Improve Model Hierarchy

  • Key: SMM-20
  • Legacy Issue Number: 14232
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: Alain Picard, Benchmark Consulting
    Summary:
    As we started to produce ever larger models, it quickly became apparent that a flat model like the SMM is not very appropriate. So we redesigned the model, to better divide it along the line of Measure library and Observation. Then we reclassified all relations to create containment relationships that are much more aligned with the natural structure of the model.

    Discussion:

    Summary of change:
    · Add New MeasureLibrary class, a generalization of SmmElement
    · Add new AbstractMeasureElement class, a generalization of SmmElement
    o Change Characteristic to now be generalize from AbstractMeasureElement
    o Change Measure to now be generalize from AbstractMeasureElement
    o Change MeasureCategory to now be generalize from AbstractMeasureElement
    o Change Scope to now be generalize from AbstractMeasureElement
    · Change model composition:
    o Remove SmmModel containment of SmmElement
    o Add SmmModel containment of MeasureLibrary, with a named relation of libraries [0..*]
    o Add SmmModel containment of Observation, with a named relation of observations [0..*]
    o Add Observation containment of ObservationScope, with a named relation of scopes [0..*]
    o Add Observation containment of ObservedMeasure, with a named relation of observedMeasures [0..*]
    o Add ObservedMeasure containment of Measurement, with a named relation of measurements [0..*]
    o Add MeasureLibrary containment of AbstractMeasureElement, with a named relation of measureElements [0..*]
    o Add MeasureLibrary containment of CategoryRelationship, with a named relation of categoryRelationships [0..*]
    o Add Measure containment of MeasureRelationship, with a named relation of measureRelationships[0..*]

  • Reported: SMM 1.0b1 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add New MeasureLibrary class, a generalization of SmmElement
    • Add new AbstractMeasureElement class, a generalization of SmmElement
    o Change Characteristic to now be generalize from AbstractMeasureElement
    o Change Measure to now be generalize from AbstractMeasureElement
    o Change MeasureCategory to now be generalize from AbstractMeasureElement
    o Change Scope to now be generalize from AbstractMeasureElement
    • Change model composition:
    o Remove SmmModel containment of SmmElement
    o Add SmmModel containment of MeasureLibrary, with a named relation of libraries [0..*]
    o Add SmmModel containment of Observation, with a named relation of observations [0..*]
    o Add Observation containment of ObservationScope, with a named relation of scopes [0..*]
    o Add Observation containment of ObservedMeasure, with a named relation of observedMeasures [0..*]
    o Add ObservedMeasure containment of Measurement, with a named relation of measurements [0..*]
    o Add MeasureLibrary containment of AbstractMeasureElement, with a named relation of measureElements [0..*]
    o Add MeasureLibrary containment of CategoryRelationship, with a named relation of categoryRelationships [0..*]
    o Add Measure containment of MeasureRelationship, with a named relation of measureRelationships[0..*]

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

Redefine Collective Measures

  • Key: SMM-22
  • Legacy Issue Number: 14234
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: Alain Picard, Benchmark Consulting
    Summary:
    The CollectiveMeasure class was modified to allow more flexibility in a more compact model. This is a follow up to the previous issue to remove unneeded artifacts

    Discussion:

    Summary of change:
    · Deleted AggregateMeasure and AggregatedMeasurement classes.

  • Reported: SMM 1.0b1 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Deleted AggregateMeasure and AggregatedMeasurement classes.

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

Improve Observations

  • Key: SMM-21
  • Legacy Issue Number: 14233
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Source: Alain Picard, Benchmark Consulting
    Summary:
    This is a follow-up to continue improving upon the Observation class. In order to allow observation to be the starting point of a request to perform measurement and be the collector of those measurements. The changes here address these short-comings.

    Discussion:

    Summary of change:
    · Added a new "ObservedMeasure" class, a generalization of SmmRelationship, with the following associations:
    o Add named relation of measure[1] from ObservedMeasure to Measure
    o Owning the measurements having been calculated for a specific measure
    · Added a new association to the Observation class
    o observedMeasures, owning the ObservedMeasure instances for an observation
    · Remove relation from Measurement to Measure as it is now being replaced.
    · Add named relation of requestedMeasures[0..*] from Observation to SmmElement (with constraints)

  • Reported: SMM 1.0b1 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Added a new “ObservedMeasure” class, a generalization of SmmRelationship, with the following associations:
    o Add named relation of measure[1] from ObservedMeasure to Measure
    o Owning the measurements having been calculated for a specific measure
    • Added a new association to the Observation class
    o observedMeasures, owning the ObservedMeasure instances for an observation
    • Remove relation from Measurement to Measure as it is now being replaced.
    • Add named relation of requestedMeasures[0..*] from Observation to SmmElement (with constraints)

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

Improve DirectMeasure Operations

  • Key: SMM-16
  • Legacy Issue Number: 14103
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The DirectMeasure class was modified to allow more flexibility in expressing operations. With the new Operation class, operations can be defined in terms of either OCL or XQuery and they can also be re-used.

    Discussion:

    Summary of change:
    · Added a new "Operation" class that defines the following:
    o language
    o body
    · Replace the DirectMeasure class "operation" attribute with an association of the same name pointing to the "Operation" class.

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Added a new “Operation” class that defines the following:
    o language
    o body
    • Replace the DirectMeasure class “operation” attribute with an association of the same name pointing to the “Operation” class.

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

Redefine Collective Measures

  • Key: SMM-15
  • Legacy Issue Number: 14102
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The CollectiveMeasure class was modified to allow more flexibility in a more compact model.

    Discussion:

    Summary of change:
    · Added a new enumeration called Accumulator that defines the following:
    o Sum
    o Maximum
    o Minimum
    o Average
    · Changed the CollectiveMeasure class "accumulator" attribute from a string to an "Accumulator" value.
    · Deleted AdditiveMeasure and MaximalMeasure classes.

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Added a new enumeration called Accumulator that defines the following:
    o Sum
    o Maximum
    o Minimum
    o Average
    • Changed the CollectiveMeasure class “accumulator” attribute from a string to an “Accumulator” value.
    • Deleted AdditiveMeasure and MaximalMeasure classes.

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

Change to the Measure Class

  • Key: SMM-14
  • Legacy Issue Number: 14101
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    A number of changes were made in the Measure class in order to better support library of measures and to align with the creation of a new distinct EquivalentRelationship class to replace the previous association.

    Discussion:

    Summary of change:
    · Add new "labelFormat" attribute and define its allowable content
    · Add new "visible" attribute
    · Added a new EquivalentRelationship class with a "mapping" attribute.
    o Note that the content of the mapping attribute is still not well defined. We are currently using it in a very proprietary way and are looking to better explain and elaborate on this later.
    · Re-scope the definition of equivalent measure
    · Establish the concept of using equivalent measure to derive an otherwise irresolvable measure.
    · Modified the endpoints of the equivalentTo and equivalentFrom associations
    · Clarify the "from" and "to" association in the MeasureRelationship class

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Add new “labelFormat” attribute and define its allowable content
    • Add new “visible” attribute
    • Added a new EquivalentRelationship class with a “mapping” attribute. (updated in 14602)
    o Note that the content of the mapping attribute is still not well defined. We are currently using it in a very proprietary way and are looking to better explain and elaborate on this later.
    • Re-scope the definition of equivalent measure
    • Establish the concept of using equivalent measure to derive an otherwise irresolvable measure.
    • Modified the endpoints of the equivalentTo and equivalentFrom associations
    • Clarify the “from” and “to” association in the MeasureRelationship class

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

Rename Category class to MeasureCategory

  • Key: SMM-19
  • Legacy Issue Number: 14231
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    This is the latest in a series of renaming to help better clarify the scope of the categories that we are referring to. Discussion:

    Summary of change:
    · Change Category to MeasureCategory everywhere

  • Reported: SMM 1.0b1 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Change Category to MeasureCategory everywhere

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

Add Extensibility to SMM Model

  • Key: SMM-18
  • Legacy Issue Number: 14105
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The SMM should support some basic extensibility. This extensibility model should be aligned with the KDM, and as with the KDM the content of those extension is beyond the scope of this specification and tools that don't understand these extensions should just pass this information untouched.

    Discussion:

    Summary of change:
    · Added a new "Attribute" class that defines the following:
    o tag
    o value
    o owner association
    · Added a new "Annotation" class that defines the following:
    o text
    o owner association

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Added a new “Attribute” class that defines the following:
    o tag
    o value
    o owner association
    • Added a new “Annotation” class that defines the following:
    o text
    o owner association

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

Improve Observations

  • Key: SMM-17
  • Legacy Issue Number: 14104
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The Observation class was not sufficient to capture the scope of the models that were part of the observation and also it didn't identify which measures either should be calculated or had been calculated once completely built. The changes here address these short-comings.

    Discussion:

    Summary of change:
    · Added a new "ObservationScope" class that defines the following:
    o scopeUri along with its format and allowable content
    · Added 2 new associations to the Observation class
    o one to ObservationScope
    o and the other to SmmElement, but with a constraint to Category, CategoryRelationship or Measure. This allows to define the "to build" list based not only on specifying measures, but by category or even categoryRelationship.

  • Reported: SMM 1.0b1 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — SMM 1.0b2
  • Disposition Summary:

    • Added a new “ObservationScope” class that defines the following:
    o scopeUri along with its format and allowable content
    • Added 2 new associations to the Observation class
    o one to ObservationScope
    o and the other to SmmElement, but with a constraint to Category, CategoryRelationship or Measure. This allows to define the “to build” list based not only on specifying measures, but by category or even categoryRelationship.

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