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.

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

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.

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

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

Discussion:

Summary of change:
· Drop library attribute from Measure class

• Drop library attribute from Measure class

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

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

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

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

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

• 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

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

• 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

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

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

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

• 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

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

• 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

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

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

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

• 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

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

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

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:
§ '

'
· 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.

• 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:
? '

'
• 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.

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.

• 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

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

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

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.

• Deleted AggregateMeasure and AggregatedMeasurement classes.

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)

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

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.

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

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.

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

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

• 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

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

• Change Category to MeasureCategory everywhere

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

• 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

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.

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