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).

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.

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

Fix Figure 10.2

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

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.

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".

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Add association to diagram

Show the association between Measure and Scope in Figure 10.1.

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.

Replace collective measurement with binary measurement.

Replace the wrong term with the correct term.

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.

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.

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.

Remove "scalar"

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

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.

Replace rank with grade

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

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.

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.

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.

Add mapsTo association to the BaseNMeasurementRelationship

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

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 .

Change super class of RatioMeasure

Change super class of RatioMeasure to be BinaryMeasure.

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.

*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.

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

*Fix super classes of NamedMeasurement and RescaledMeasurement *

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

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.

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.

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.

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.

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.

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

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

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.

Relax restrictive description

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

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

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,

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".

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

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.

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.

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.

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.

Disambiguate "recognizer" by using "counter"

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

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.

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.

Each normative use of “string” in the SMM document and model should be the UML/MOF “String” instead.

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

Each normative use of “string” in the SMM document and model is replaced with the UML/MOF “String”.

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".

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.

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.

Remove classes from diagram

Remove EquivalentMeasureRelationship, RefinementMeasureRelationship and DirectMeasure from Figure 10.1.

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

Define 2 levels of conformance

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

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."

Revise definition of rescales

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

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

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

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

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).

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.

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.

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.

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.

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

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

Add Logo to title page

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

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

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).

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.

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.

Scales of Measurement are a fundamental property of a Measure describing the allowable mathematical transformations that can be legitimately applied to it.
Attached are some URLs that will give you an overview of Scales of Measurement. 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)
It is proposed to introduce an Enumeration to define the possible Scales of Measurement: ordinal, nominal, interval and ratio. Also to add an attribute to Measure, to define its scale.

Scale of Measurement was implemented already

Scale of Measurement has already been implemented in SMM 1.1.

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.

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.

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.

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.

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.

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.

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

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.

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.

Issue is subsumed in issue SMM12-92

This issue is subsumed in issue SMM12-92

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.

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;".