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 14609: Clarify role of NamedMeasure
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.
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.