Issue 15476: The metamodel defines MOF operations for derived Properties
Issue 15477: What is missing however is any semi-formal description of how the properties are derived – for example OCL
Issue 15478: Section 8.6, measureCategory
Issue 15479: 8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes
Issue 15480: The UML uses ‘string’ lowercase rather than the UML/MOF PromitiveType String (uppercase)
Issue 15481: Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement
Issue 15482: The metamodel is missing Properties for important navigable relationships
Issue 15483: The UML uses non-standard notation by showing the superclass in top right of a class compartment.
Issue 15484: In 10.3 Scope::class should not be a String but a proper reference to MOF:Class
Issue 15851: Create new root class that attribute and annotation can extend
Issue 15852: Change compliance to use term “must” instead of “can”
Issue 15853: Clarify that XQuery is defined as mapping to XMI with correct version number
Issue 15854: Add missing containment relation from SmmElement to SmmRelationship
Issue 15855: Fix OCL constraint in CategoryRelationhsip
Issue 15856: Change the spec from EMOF to CMOF
Issue 15857: Add relation to Scope Class
Issue 17212: SMM should use MOF 2.4.1
Issue 17469: Scope of a measure should be made optional
Issue 17470: SMM metamodel contains class "MofElement".
Issue 17471: The measurand of Measurement, which references Element (MOF), is owned by Measurement
Issue 17472: Attributes to be added to Measurement
Issue 17473: Add attribute “type” (String) to Observation
Issue 17474: Allow multiple operations for a direct measure (multiplicity 0..*)
Issue 17475: Allow more normative options for language of operation body
Issue 17476: AdditiveMeasure
Issue 17477: Inconsistency between Examples (instance models) and meta-model
Issue 17478: RescaledMeasure
Issue 17479: Wrong reference
Issue 17480: CollectiveMeasurement class
Issue 17481: Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure
Issue 17482: Add accumulator value “product”.
Issue 17483: SMM does not allow for a formula, but only has a simple accumulator
Issue 17484: Should a binary measure have a formula next to a functor ?
Issue 17485: The class DimensionalMeasure should be abstract
Issue 17486: RatioMeasurement
Issue 17498: CollectiveMeasurement attribute wrong
Issue 17503: functor should have an enumeration defined in the spec
Issue 17504: It is unclear how rescaling is possible from more than 1 simultaneously
Issue 17535: interval-based mapping
Issue 17561: Scales of Measurement
Issue 17598: "Influence" of measure relationship
Issue 15476: The metamodel defines MOF operations for derived Properties (smm-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
The metamodel defines MOF operations for derived Properties – this is redundant and as unnecessary as defining getters and setters for normal Properties. For example SmmRelationship::getFrom()
What is missing however is any semi-formal description of how the properties are derived – for example OCL
Section 8.6, measureCategory, has an OCL constraint context CategoryRelationship inv: to.oclIsTypeOf(MeasureCategory) or measures.oclIsTypeOf(Measure) The last line is incorrect and should be to.oclIsTypeOf(Measure). However this is IMHO bad practice and there should be a more specific association than using AbstractMeasureElement
8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes
The UML uses ‘string’ lowercase rather than the UML/MOF PromitiveType String (uppercase)
Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement: they will not have or need their own name, description or Attributes/Annotations: in fact the latter is explicitly disallowed – though only informally in the text.
The metamodel is missing Properties for important navigable relationships: for example the owner of a MeasureRelationship, the child of a Characteristic, the Measures for a Characteristic, the applicability of an Operation and more
The UML uses non-standard notation by showing the superclass in top right of a class compartment.
In 10.3 Scope::class should not be a String but a proper reference to MOF:Class (which will be serialized as a XMI href). Relying on ‘name’ and a linking convention unique to this standard, makes practical linking and resolution unworkable
This issue deals with the fact that the SMM didn’t provide any real root class in its model and that everything started with SmmElement. Discussion: The architecture board as recommended that we add a new root class that can be used as the direct extension for attribute and annotation. In turn, SmmModel and SmmRelationship also now extends this new Element class. Summary of change: • Add Element class, a model root class • Modify SmmElement class o Change from model root class to class being a generalization of Element • Modify SmmModel class o Change generalization from SmmElement to Element • Modify SmmRelationship class o Change generalization from SmmElement to Element • Modify Attribute class o Change generalization from SmmElement to Element • Modify Annotation class o Change generalization from SmmElement to Element • Create new separate diagram for Core • Re-arranged content of Chapter 8 and Chapter 9 of Specification o Renamed chapter 8 to “Core Base Classes” o Move Figure 2 Core Classes Diagram to Figure 3 and rename to Metrics Core Classes o Move Figure 3 Core Relationship Classes to Figure 4 o Insert Core Classes from above to Figure 2 o Add following description for Element class under 8.1: Element Class (Abstract) An Element constitutes an atomic constituent of a model. In the meta-model, Element is the top class in the hierarchy. Element is an abstract class. Semantics Element is the common parent from all meta-model elements of SMM. Most subclasses of Element can own annotations and user-defined attributes through standard extension mechanisms. o Added Superclass info to SmmElement o Modified Superclass info of SmmModel from SmmElement to Element o Modified Superclass info of SmmRelationship from SmmElement to Element o In chapter 9, remove the figure that only depicted the extensions, now shown in figure 2 as seen above. o Added chapter 10 as “Core Metrics Classes” o Moved description of class MeasureLibrary from chapter 8 to 10 o Moved description of class MeasureCategory from chapter 8 to 10 o Moved description of class CategoryRelationship from chapter 8 to 10
Summary: This issue addresses a wording problem with the compliance requirement. Discussion: The architecture board as recommended that we change the compliance condition from “can” to “must”. Summary of change: • In section 2, change “An implementation can provide “ to “An implementation must provide “
Source: OMG AB Summary: This issue deals with the fact that XQuery is not defined and it’s mapping to XMI is also not well defined. Discussion: The architecture board as recommended that we clarify the mapping of XQuery to XMI and identify the versions in use. Summary of change: • In section 3, “Normative References”, add the following: o OCL 2.2 Specification o XQuery 1.0, XPath 2.0 (W3C Recommendation) • In section 7, “SMM” at the end of the section add the following: In a number of places, SMM supports querying or constraining data of interest by specifying some queries. Such queries can be expressed either with OCL version 2.2 as published by the OMG, or with XQuery 1.0 as published by the W3C. For XQuery, SMM uses a variant of XPath 2.0 (part of XQuery 1.0) and maps it to XMI using the following rules: • XPath uses a path expression where each path is a series of steps separated by forward slashes (/). • The steps are evaluated from left to right, and generally decend the model's tree as they do so • Each step identifies tree nodes by their classifier name and attributes are specified, just as in XPath with a leading @. SMM implementations are encouraged to implement OCL and XQuery by providing a wrapper that exposes their models to 3rd party query engines that implement all of the complexities of those languages.
Source: OMG AB Summary: This issue addresses a relation that in the diagram that was not documented in the specification. Discussion: The architecture board as recommended that we add the necessary documentation change to describe a missing containment relation in the specification. Summary of change: • In the documentation for SmmElement, in the Associations sub-section, add the following new element: ownedRelation:SmmRelationship[0..*] Primitive SMM relationships that originate from the current SmmElement.
Source: OMG AB Summary: This issue addresses an incorrect constraint on a relation. Discussion: The architecture board as recommended that we correct the relation constraint in CategoryRelationship as it did not accurate. Summary of change: • In the documentation for CategoryRelationship, in the Constraints sub-section, change the content to now read: context CategoryRelationship inv: to.oclIsTypeOf(MeasureCategory) or to.oclIsTypeOf(Measure)
Source: OMG AB Summary: This issue deals with the fact that the SMM didn’t take advantage of some of the provision of CMOF. Discussion: The architecture board as recommended that we change the SMM specification to be more in-line with CMOF rather than restricting ourselves to the EMOF model. Summary of change: • Modify SmmElement class o Remove operations section from SmmElement • Modify SmmRelationship class o Remove derived union attribute from the from and to associations. o In the documentation, in the Associations sub-section, update the content to remove the reference to derived union: from:SmmElement[1] The origin element (also referred to as the from-endpoint of the relationship). to:SmmElement[1] The target element (also referred to as the to-endpoint of the relationship). • Modify MeasureRelationship class o Remove derived union attribute from the from and to associations. o In the documentation, in the Associations sub-section, update the content to remove the reference to derived union: from:Measure [1] The origin element (also referred to as the from-endpoint of the relationship). to:Measure [1] The target element (also referred to as the to-endpoint of the relationship). • Modify MeasurementRelationship class o Remove derived union attribute from the from and to associations. o In the documentation, add the Associations sub-section (was missing), with the following content: Associations from:Measurement [1] The origin element (also referred to as the from-endpoint of the relationship). to:Measurement[1] The target element (also referred to as the to-endpoint of the relationship).
OMG Issue No: 15857 Title: Add relation to Scope Class Source: Frédéric Madiot, MIA Soft, Summary: This issue addresses a lack of navigability in scopes. Discussion: Here are our modifications of SMM beta 2 specification: Class Scope we have added 2 references : • a “non containment” reference called 'parent', type Scope (0..1), to link a scope to its parent. • a “non containment” reference called 'children', type Scope (0..*), to link a scope to its children. Summary of change: • Add a new relation to Scope class: o In the documentation for Scope, in the Associations sub-section, add the following new element: children: Scope[0..*] Specifies the parent scope of this scope. parent: Scope [0..*] Specifies the children scopes of this scope.
SMM should use MOF 2.4.1. This makes it easier to create the metamodel (the UML model can be used largely as-is) and is required for compatibility with VDML which is dependent on SMM.
The following changes have been submitted and are pending with the SMM (Structured Metrics Metamodel) RTF. Scope of a measure should be made optional.
SMM metamodel contains class "MofElement". It's name is not precisely identifying the Element class in MOF (or CMOF), and the XMI file might not contain the precise reference either. SMM should create a small metamodel package "MOF" (or CMOF), containing at least "Element". And refer to it as measurand, from SMM, instead of having the MOF Element class in the SMM package itself. In addition to that, the XMI file should contain the correct reference (href) to Element
The measurand of Measurement, which references Element (MOF), is owned by Measurement. It should instead be owned by the association between Measurement and Element. This means that metamodels, such as VDML, extending SMM are able to create their own more specialized associations to restrict the measurand to be typed by metaclasses in their own metamodel. Otherwise they will need to specialize Measurement (SMM) itself – and, what is so awkward, specialize all the subclasses of Measurement (e.g. via multiple inheritance). By specializing only the association they can reuse the SMM Measurement class and all its SMM subclasses with no change. The root constraint underlying all the above is that MOF/UML requires any redefined property to be owned by a classifier that is a generalization of the one owning the redefining property. Note that both associations and classes are classifiers. More specifically, to be able to state that C1:p1 {redefines C2:p2} then C2 must be a supertype of C1 (directly or indirectly).
Add the following attributes to Measurement, to enable expression of measurement precision, and stochastic aspects of measurements: “confidence interval upper bound”, “confidence interval lower bound”, “confidence” (being a probability) and “distribution”(string).
Add attribute “type” (String) to Observation. Examples of observation type values are “estimated”, “actual”, "simulated", "benchmark".
Allow multiple operations for a direct measure (multiplicity 0..*). In addition add attribute “type” (String) to DirectMeasure. When “type” is filled, it corresponds to observation type
Allow more normative options for language of operation body. Allow at least JSON, to be able to express operations in url format
In SMM spec the examples (instance models) have "AdditiveMeasure". But that is not existing in the spec (meta-model). I guess it is an oversight, and it should be CollectiveMeasure?
Examples (instance models) in SMM spec suggest that rescaled measure has "operation", but the meta-model has "formula". This is probably an oversight ?
In SMM spec, there's this text, for RescaledMeasure: Associations: baseMeasure:DimensionalMeasure: Identifies the measure applied to each “contained” entity to determine base measurements. rescaleFrom:RescaledMeasureRelationship[0..*]: Specifies the relationship instance that defines the measure rescaled by this rescaled measure. However: the meta-model diagram suggests that there is only rescaleFrom. No baseMeasure. This is wrong.
In examples/instances of rescaled measures in SMM spec, there is sometimes reference (from formula string) to "baseMeasure". But that is wrong, as according to the meta-model, a rescaled measure does not have “base measure”, but “rescale from” ?
In CollectiveMeasurement class: Text says: Associations: baseMeasurement:DimensionalMeasurement[0..*]: Identifies the measurements from which this collective measurement was derived. However: the meta-model suggests that there's baseMeasurementTo. Not baseMeasurement. So, the associations text is wrong.
Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure. I think that the meta-model suggests that these don't exist (anymore ?), as there's only CollectiveMeasure
Assume that you have 5 measurements (according to their measures), and that you just want to multiple the results of all 5: result 1 * result 2 * result 3 * result 4 * result 5. This can be done in SMM as follows: 1) 4 binary measures, with functor "times" , or 2) 4 rescaled measures, with formula " * baseMeasurement" But wouldn't it be very handy to just have 1 collective measure, whereby accumulator would be “product” ? Currently the accumulators are just "sum", "max", "min", "avarage" and "stdv". Proposal: Add accumulator value “product”.
In industry, it is common to have composite measures with formulas like “A * (1 + B) / C”, whereby A, B and C are atomic measures. In this example, according to SMM, you would not have 4 measures, but 6, e.g.: • 3 direct measures: A, B, C • A rescaled measure, with formula “1+B” • A binary measure, with functor “times”, to multiple A and the rescaled measure from above. • A ratio measure to divide the previous one by C. Though this is technically OK, it is not always handy, as “given” industry measures would have to be refactored into smaller ones. I see a good reason why SMM measures are structured as they are: You have good grip than on the formula, the functor, etc. Because if you would allow for formula's like "( A * (1 + B) ) / C ", you would have difficulty in reconciling the various associated "sub" measurements with the formula of the measure that relates to the collective measurement. String parsing, etc. SMM in its current form is very structured, but that would make interpretation and implementation also very straightforward. That is a big advantage and I like that. But still I have trouble with e.g. industry-given libraries of VCG, SCOR, KPI LIbrary, etc., that though have composite measures with such more complicated formula's. How to import such measures into an SMM based library? Once imported, you could create more specific SMM measures, and refer to the original one as "equivalent" measure. But the main problem is that it cannot even be imported, as a collective measure in SMM does not allow for a formula, but only has a simple accumulator. How can this be resolved ?
In SMM, a binary measure has a functor. Examples in the spec (instance models) suggest functor values like “sum”, “difference”, “times”, “divide”. This sounds like functor should have an enumeration defined in the spec, like also accumulator has for a collective measure. However, SMM does not do that for functor. Why not? It is rather similar (see also that accumulator has a value “sum” ..). On the other hand: an enum can be too rigid, as it is not easily extendable. As Alain Picard has admitted, it would for vendors be more flexible to also allow formula’s (like rescaled measures have), for binary measures, e.g. “A * B” (instead of functor “times” to multiple A and B). But that would require that a binary measure should have a formula next to a functor ?
The class DimensionalMeasure should be abstract. Like also DimensionalMeasurement is abstract. This is an inconsistency in the spec.
In SMM spec there's the class RatioMeasurement. However, in the beta2 spec, it is misspelled as RatioMeasurment.. This should be corrected.
The class CollectiveMeasurement has attribute "accumulator". This is wrong, as the CollectiveMeasure class has that attribute. CollectiveMeasurement should not have it therefore.
In SMM, a binary measure has a functor. Examples in the spec (instance models) suggest functor values like “sum”, “difference”, “times”, “divide”. This sounds like functor should have an enumeration defined in the spec, like also accumulator has for a collective measure. However, SMM does not do that for functor. Why not? It is rather similar (see also that accumulator has a value “sum” ..).
According to the SMM spec, a RescaledMeasure can rescale from 0..* binary measures, and a RescaledMeasurement can rescale from 0..* binary measurements accordingly. This is strange however. It is unclear how rescaling is possible from more than 1 simultaneously. Seems that the multiplicity should be 1 instead of 0..*.
A ranking in SMM results in a mapping to symbolic value (a string), which is unit-less, and which does not allow to be used as factor in further measure-based computations. It is required that similar interval-based mapping can also be used to result in a dimensional measurement, the value of which is numeric. Proposed changes: Rename SMM Ranking into GradeMeasure Rename SMM Grade into GradeMeasurement Rename RankingInterval into GradeInterval. Add another measure, called RankingMeasure (specialization of DimensionalMeasure); It has associated RankingInterval (very much like the existing ones) Ranking intervals of RankingMeasure have a numeric value instead of a symbolic string value.
A standard component of measurement theory is 'Scales of Measurement' because they constrain the types of mathematical operations that can be performed on a measure. The base set of scales are 'Nominal', 'Ordinal', 'Interval', and 'Ratio'. The representation of a measure in SMM should contain information about the scale of measurement to indicate how it can be used and the limits of the operations that can be performed. If there is a way to enforce these constraints that would be best, but lacking that it would be useful for the specification of a measure to contain information about its limits for those who would incorporate the measure in their applications.
Though, for MeasureRelationship in SMM, the "real" influence of one measure to other measure(s) is implied by the type of measure, its functors, operations, accumulators, etc., still it is, for business analyst understanding and maintenance sake very useful to add the influence type explicitly (the analyst may even define it before the actual functor or operation is specified). This will also be helpful in diagrammatic understanding in one glance of how measurements are influencing each other. Resolution (as agreed with Larry Hines): Add optional property "Influence" to MeasureRelationship. This is property with enumeration type "Influence", having 2 enum values: "positive", "negative". In addition: a constraint, specifying that this property is not allowed for "EquivalentMeasureRelationship".