Issue 14095: Change meaning of SMM Acronym
Issue 14096: Correct Naming of Elements
Issue 14097: Correct SmmRelationship Associations
Issue 14098: Correct Category Associations
Issue 14099: Graph corrections
Issue 14100: Change to the Scope Class
Issue 14101: Change to the Measure Class
Issue 14102: Redefine Collective Measures
Issue 14103: Improve DirectMeasure Operations
Issue 14104: Improve Observations
Issue 14105: Add Extensibility to SMM Model
Issue 14231: Rename Category class to MeasureCategory
Issue 14232: Improve Model Hierarchy
Issue 14233: Improve Observations
Issue 14234: Redefine Collective Measures
Issue 14600: Convert all measure and measurement relationship to use the relationship class
Issue 14601: Add measurandQuery Operation to MeasureRelationship
Issue 14602: Add better support for Operations and OCL code reuse
Issue 14603: Add support for parameterized measure
Issue 14604: Add defaultQuery to Measure
Issue 14605: Delete library attribute from Measure
Issue 14606: Add additional Accumulator enum value and document Accumulator
Issue 14607: Improve Label format support
Issue 14608: Add support for Scale of Measurement
Issue 14609: Clarify role of NamedMeasure
Issue 15011: operation attribit of direct measure class
Issue 15012: OCL expr. of BinaryMeasurement
Issue 15014: Inconsistency between specification and provided Meta Model
Issue 15015: Modeling names of model elements
Issue 15016: Threshold values for dimensional measures
Issue 15017: Measure audits
Issue 14095: Change meaning of SMM Acronym (smm-ftf)
Click here for this issue's archive.
Source: Model Driven Solutions (Mr. William Ulrich, wmmulrich(at)baymoon.com)
Nature: Uncategorized Issue
Severity:
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
This item was well covered during the last technical meeting in San Antonio and is a key element of extending the scope of the SMM outside of Software Metrics.
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
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
This issue only addresses part of the solution. A new issue will be opened to add the missing operations for union set aggregation.
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
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
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
This solution is being partly superseded by a new upcoming issue that will move the recursive from an attribute to a relation and correctly define the type of breakCondition to be an Operation instead of a String
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
A new upcoming issue will finally define the semantics of the mapping attribute and change its type to Operation
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.
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.
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.
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
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
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..*]
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)
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.
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.
This covers the conversion of all relation in measure and measurands to be base on their corresponding relationship class. This allows for the definition of semantic meaning at the relation level and it also provides for a very convenient way to process all relations as a group, thereby greatly facilitating the implementation of an “executable” model. The issue also addresses a couple of rename to improve naming consistency. Finally it introduces the missing operations for the relationship class, so that the pattern fully matches the one from the KDM where it was derived from
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
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.
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
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:
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.
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.
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
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.
When the MeasureLibrary was introduced, this attribute was inadvertently left behind. Discussion: Summary of change: · Drop library attribute from Measure class
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
Also need to add missing section documenting Accumulator in the specification. Was missing in document.
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.
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: 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.
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 enum 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. Discussion: From Larry Hines: With respect to 14608: First, scale is mostly redundant information. As such it could be an operation defined for Measure, but it should be an attribute. This operation would always return ‘ratio’ for RatioMeasures. It would always return ‘interval’ for DimensionalMeasures. The tricky part is to separate ‘nominal’ and ‘ordinal’ for Ranking measures. We could have an optional attribute for that. It wouldn’t hurt, but it is not needed to convey the meaning of a measurement. From Alain Picard: After reviewing Larry’s comment on his vote, I have to agree that it will be better to defer this issue to the RTF and to better implement a real solution to the issue. Disposition: Deferred
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.
The NamedMeasure class is designed for specifying measures which are well-known and can be specify simply by name. What this means is that it is essentially a special type of measure that is opaque and is mostly designed to play two specific roles. First it can serves as an equivalent measure to some more complex computations, as demonstrated by the McCabe complexity metric. In this case it allows for the reporting of this measure, while allowing the hiding of the complex computations. The other use is to use SMM to easily exchange measurements without having to specify the measure in any detailed way. This makes for an easy way to just exchange measurements by using a simple NamedMeasure as the measure placeholder. The first intent is to clarify the specification and to clearly state the roles of the NamedMeasure. The second intent is to provide a way to define non-direct measures that can apply complex calculations to obtain their results based on one or more base measure component. This can easily be accomplished by extending the CollectiveMeasure class and adding an operation relation to Operation and also adding a constraint to check for either an accumulator or an operation to be present.
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.
The OCL expression related to the BinaryMeasurement class refers to the context RatioMeasurement instead of BinaryMeasurement
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.
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.
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.
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 this 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 a association to the Measure class to model the membership of a measure to a specific audit.