Issues for Structured Metrics Metamodel (SMM) 1.2 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

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

Resolution: Disposition: See issue 19721 for disposition
Revised Text:
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 15477: What is missing however is any semi-formal description of how the properties are derived � for example OCL (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

What is missing however is any semi-formal description of how the properties are derived � for example OCL

Resolution: Disposition: See issue 19722 for disposition
Revised Text:
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 15478: Section 8.6, measureCategory (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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

Resolution: Disposition: See issue 15855 for disposition
Revised Text:
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 15479: 8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

8.7, 8.8: it should be made clear that Date and Timestamp are PrimitiveTypes

Resolution: Add a note to 8.8 and 8.9 that each is a primitive type.
Revised Text: REPLACE heading text of Sub-clause 8.9 (which is Sub-clause 8.8 in the revised specification) WITH ?TimeStamp Primitive Type?. REPLACE the words ?This represents a point in time? in Sub-clause 8.9 (which is Sub-clause 8.8 in the revised specification) WITH ?This primitive type represents a point in time?.
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue

Issue 15480: The UML uses �string� lowercase rather than the UML/MOF PromitiveType String (uppercase) (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 UML uses �string� lowercase rather than the UML/MOF PromitiveType String (uppercase)

Resolution: Replace UML/MOF PrimitiveType String by string (lowercase) in document
Revised Text: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 4 WITH the diagram of Figure d: Replacement meta-model diagram for Figure 4 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams). REPLACE type ?String? WITH type ?string? for the following attributes in Attributes tables: � ?name?, ?shortDescription? and ?description? of SmmElement in Sub-clause 8.2 � ?tag? and ?value? of Attribute in Sub-clause 9.2 � ?text? of Annotation in Sub-clause 9.3 � ?name? of Characteristic in Sub-clause 10.2 (Sub-clause 10.3 in the revised specification) � ?name? and ?description? of Scope in Sub-clause 10.3 (Sub-clause 10.4 in the revised specification) � ?name?, ?measureLabelFormat? and ?measurementLabelFormat? of Measure in Sub-clause 10.4 (Sub-clause 10.5 in the revised specification) � ?language? and ?body? of Operation in Sub-clause 10.5 (Sub-clause 10.7 in the revised specification) � ?context? and ?body? of OCLOperation in Sub-clause 10.6 (Sub-clause 10.8 in the revised specification) � ?name? of MeasureRelationship in Sub-clause 10.7 (Sub-clause 10.9 in the revised specification) � ?name? of NamedMeasure in Sub-clause 12.2 � ?error? and ?breakValue? of Measurement in Sub-clause 13.2 � ?value? of Grade in Sub-clause 13.8 (GradeMeasurement Class in Sub-clause 13.7 in the revised specification) � ?observer? and ?tool? of Observation in Sub-clause 16.2 � ?scopeUri? of ObservationScope in Sub-clause 16.3 � ?name?, ?type? and ?value? of Argument in Sub-clause 16.5 REPLACE type ?String? WITH type ?string? for the following operations in Operations tables: � ?getParamStrings? of Operation in Sub-clause 10.5 (Sub-clause 10.7 in the revised specification) � ?getMeasureLabel? and ?getMeasurementLabel? of Measurement in Sub-clause 13.2
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue

Issue 15481: Section 9: It does not make sense for Attribute or Annotation to inherit from SmmElement (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Rejecting keeps SMM more aligned with the design used in KDM and VDML. Disposition: Closed, no change
Revised Text:
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Discussion:

Rejecting keeps SMM more aligned with the design used in KDM and VDML.  Disposition:	Closed, no change

Issue 15482: The metamodel is missing Properties for important navigable relationships (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 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

Resolution: Modified model to add names as needed
Revised Text: Missing names of associations and association ends have been specified in the meta-model. (As these association and association end names are not shown in the diagrams, there is no change in the specification document itself. As part of resolution of issue 17212 it has been controlled precisely which association ends to be owned by association (and show no name in the diagram) versus which ends to be owned by class (and show name in the diagram).)
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue

Issue 15483: The UML uses non-standard notation by showing the superclass in top right of a class compartment. (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 UML uses non-standard notation by showing the superclass in top right of a class compartment.

Resolution: Replace diagrams to not show superclass
Revised Text: Diagram changes showing the removal of the non-standard superclass notation: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue

Issue 15484: In 10.3 Scope::class should not be a String but a proper reference to MOF:Class (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Replace String as type of class attribute with MOF::Class.
Revised Text: REPLACE type ?String? of attribute ?class? in Attributes table of Sub-clause 10.3 (Scope Class) (Sub-clause 10.4 in the revised specification) WITH type ?MOF::Class?. REMOVE the following text FROM Semantics of Sub-clause 10.3 (Scope Class) (Sub-clause 10.4 in the revised specification): ?The class attribute should be able to provide an unambiguous way to specify a class name. In order to achieve this goal, the string should be formatted according to the following pattern, with all 3 elements being required: Namespace:Package::ClassName This usage of package pathnames is transitive and can also be used for packages within packages: Packagename1::Packagename2::ClassName Where: Namespace represents the model where the class is defined. Namespace can be either one of the pre-defined values (?kdm?, ?astm? or ?smm? at the moment) or be a namespace defined in the XMI where this measure is located. For example a namespace value of ?mykdm? would be valid if the SMM model contains the following XMI namespace definition in its header: ?xmlns:mykdm=[1]http://kdm.somecompany.com/spec/KDM/1.4?. XMI based namespace definition can also be used with the standard namespace to point the class name definition to a specific version of those model specification. Without such a namespace entry, the pre-defined values would point to a ?current? unspecified version. Package represents the package name within the model? ClassName represents the base class name within the specified package. Diagram changes, showing the revised Scope Class: � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). REPLACE the href to Class (CMOF) in the SMM XMI WITH an href that points to [2]http://schema.omg.org/spec/MOF/20110701/cmof.xmi. ---------------------------------------------------------------------------------------- [1] http://kdm.somecompany.com/spec/KDM/1.4 [2] http://schema.omg.org/spec/MOF/20110701/cmof.xmi
Actions taken:
September 9, 2010: received issue
March 26, 2015: closed issue

Issue 15851: Create new root class that attribute and annotation can extend (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Discussion: Rejecting keeps SMM more aligned with the design used in KDM and VDML. Disposition: Closed, no change
Revised Text:
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Discussion:

Issue 15852: Change compliance to use term �must� instead of �can� (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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 �

Resolution: In Clause 2, change ?An implementation can provide ? to ?An implementation must provide?. Similar problem is fixed in a few constraints
Revised Text: REPLACE the words ?An implementation can provide? in Clause 2 (Conformance) WITH ?An implementation must provide?. REPLACE the constraint ?Attribute cannot have further annotations or attributes? in Constraints of Sub-clause 9.2 (Attribute Class) WITH ?Attribute MUST NOT have annotations or attributes?. REPLACE the constraint ?Annotations cannot have further annotations or attributes? in Constraints of Sub-clause 9.3 (Annotation Class) WITH ?Annotations MUST NOT have annotations or attributes?.
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue

Issue 15853: Clarify that XQuery is defined as mapping to XMI with correct version number (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Resolution given in issue statement
Revised Text: ADD the following reference TO Clause 3 (Normative References): ?XQuery 1.0, XPath 2.0 (W3C Recommendation)? ADD the following text TO Sub-clause 7.1 (Overview): SMM supports querying or constraining data of interest by specifying queries which 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 descend 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.
Actions taken:
December 1, 2010: received issue
March 26, 2015: closed issue

Issue 15854: Add missing containment relation from SmmElement to SmmRelationship (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Discussion: Containment at this level of abstraction (SmmElement is so broad, and so is SmmRelationship) is not meaningful. Even when one would want it, it should then be properly defined via properties that are derived unions, based on properties (at specialized level) that are their subsets. The association is very under-defined in the meta-model. It did not even have names for its ends. Hence the inconsistency has better be resolved the other way round: by removing the association from the meta-model also. This is done per resolution of issue 19602. Disposition: Closed, no change
Revised Text:
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Discussion:

Issue 15855: Fix OCL constraint in CategoryRelationhsip (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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)

Resolution: Reference to association end ?measures? should be replaced with reference to ?to?.
Revised Text: REPLACE the constraint in Constraints of Sub-clause 8.7 (CategoryRelationship Class) WITH the following constraint: context CategoryRelationship inv: to.oclIsTypeOf(MeasureCategory) or to.oclIsTypeOf(Measure)
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue

Issue 15856: Change the spec from EMOF to CMOF (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Disposition: See issue 17212 for disposition
Revised Text:
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 15857: Add relation to Scope Class (smm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Discussion: Reason for rejection: Scopes are sets and do not have a single inherent hierarchy. Disposition: Closed, no change
Revised Text:
Actions taken:
November 30, 2010: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Issue 17212: SMM should use MOF 2.4.1 (smm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Export UML 2.4.1 XMI from Enterprise Architect (the source tool as used for SMM 1.0), which will retain the SMM diagrams going forward and allow inclusion of the other fixes (it covers issue 19720, as SMM 1.1 will use CMOF, and does e.g. enable resolution of issue 17471). As part of this, and the correct application of CMOF for meta-modeling, according to MOF 2.4.1, name any unnamed property or association in the model, and for any property that has visibility ?private?, change it to visibility ?public?. Also, name any unnamed operation return parameter in the model, provide return parameter type where omitted, and for any such parameter that has visibility ?private?, change it to visibility ?public?.
Revised Text: Changes in Clause 3 (Normative References): � REPLACE ?UML 2. Infrastructure Specification? WITH ?UML 2.4.1 Infrastructure Specification? � REPLACE ?MOF 2.0 Specification? WITH ?MOF 2.4.1 Specification? Changes due to notation differences (such as the ?dot? notation for association ends in UML 2.4.1) as well as visibility corrections, showing multiplicities that were not shown before, filling (and showing) names of class-owned association ends, and showing operation types: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 4 WITH the diagram of Figure d: Replacement meta-model diagram for Figure 4 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
March 8, 2012: received issue
March 26, 2015: closed issue

Issue 17469: Scope of a measure should be made optional (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

The following changes have been submitted and are pending with the SMM (Structured Metrics  Metamodel) RTF.      Scope of a measure should be made optional.

Resolution: Keep scope required. Add two new attributes, name and description. Add a new constraint that requires that either the class attribute is given or that both the name and description attributes are given. In the spec, give as example: Area of a square; no class named ?square?. Binary Measure with ?area? as trait (maybe ?size? as parent of ?area?), ?times? as functor, Base Measure1 being Side1 Length and Base Measure2 being Side2 Length. Scope with ?Square? as name, and ?2 dimensional closed object with 4 equal length sides? as description.
Revised Text: ADD the following text TO Sub-clause 10.3 (Scope Class) (Sub-clause 10.4 in the revised Specification): ?Alternatively, a scope may be informally specified by a name and a description. An informal scope may be required when no MOF model for the domain is available or may be preferable in the early stages of development. Example: Area of a square where we don?t have a class named square. Binary Measure: Functor: Times Base Measure1: Side1 Length Base Measure2: Side2 Length Scope: Name: Square Description: 2 dimensional closed object with 4 equal length sides. For the measure above, the characteristic trait is likely to be ?area? which could be a child characteristic of the more general ?size?.? REPLACE multiplicity of attribute ?class? WITH [0..1] (making it optional) in Attributes table of Sub-clause 10.3 (Scope Class) (Sub-clause 10.4 in the revised Specification), and REMOVE ?(required)? FROM its description. ADD the (inherited) attributes ?name? and ?description? TO the Attributes table of Sub-clause 10.3 (Scope Class) (Sub-clause 10.4 in the revised Specification), just to articulate the ?optionality? of these attributes, which is important in the context of this issue. ADD the following constraint, which overlaps with the resolution of issue 19646, TO Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): context Scope inv: (class->isEmpty and stereotype->isEmpty implies (!name->isEmpty and !description->isEmpty)) and ((name->isEmpty or description->isEmpty) implies !class->isEmpty or !stereotype->isEmpty) ADD the following sentence, which overlaps with the resolution of issue 19646, TO Semantics of Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): ?The scope is formally specified by the class or stereotype attributes or is informally specified by name and description attributes.? ADD the words ?if measure.scope.class is specified? TO the first paragraph of Semantics of Sub-clause 13.2 (Measurement Class). ADD the sentence ?If neither measure.scope.class nor measure.scope.stereotype is specified, then measurand should match the description specified in measure.scope.description.? TO the first paragraph of Semantics of Sub-clause 13.2 (Measurement Class). Diagram changes, showing the revised Scope Class: � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17470: SMM metamodel contains class "MofElement". (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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

Resolution: 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
Revised Text: REPLACE the words ?measurand must be an instance of the class named in measure. scope.class? in Semantics of Sub-clause 13.2 (Measurement Class) WITH ?measurand must be an instance of Element (CMOF) named in measure.scope.class?. ADD the sentence ?If measure.scope.stereotype is specified then measurand must be an instance of Element (CMOF) named in measure.scope.stereotype?, which overlaps with the resolution of issue 19646, TO Semantics of Sub-clause 13.2 (Measurement Class). ADD the sentence ?The association between Measurement and Element owns measurand which means metamodels extending SMM may create their own specialized associations to restrict measurand to the metaclasses in their own metamodel.?, which overlaps with the resolution of issue 17471, TO Semantics of Sub-clause 13.2 (Measurement Class). Diagram changes, showing the replacement of MofElement (SMM) by Element (CMOF): � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). REPLACE the href to Element (CMOF) in the SMM XMI WITH an href that points to [1]http://schema.omg.org/spec/MOF/20110701/cmof.xmi. ---------------------------------------------------------------------------------------- [1] http://schema.omg.org/spec/MOF/20110701/cmof.xmi
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17471: The measurand of Measurement, which references Element (MOF), is owned by Measurement (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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

Resolution: The measurand of Measurement, which references Element (MOF), 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. 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).
Revised Text: ADD the following sentence TO the description of measurand in the Associations table of Sub-clause 13.2 (Measurement Class): ?This property is owned by the association between Measurement and Element.?. ADD the sentence ?The association between Measurement and Element owns measurand which means metamodels extending SMM may create their own specialized associations to restrict measurand to the metaclasses in their own metamodel.?, which overlaps with the resolution of issue 17470, TO Semantics of Sub-clause 13.2 (Measurement Class). Diagram changes, showing the revision of measurand: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17472: Attributes to be added to Measurement (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The RTF discussed this issue (at length) and found a resolution which addressed the core concern within the issue while preserving the general design pattern of SMM. The following was considered to further accommodate stochastic measurement: � Stochastic measurement (e.g. in the context of simulation) usually comes with large sets of Measurements. SMM does already support that a large set of Measurements is ?summarized?. Example: 10000 Measurements are the basis for a CollectiveMeasurement (which expresses the mean or some other accumulation). For scalability reasons there should still be a way to reach out to the large set of Measurements, without populating these Measurements in the model itself. Leaving the base Measurements out of the model is already possible via value ?false? for attribute ?isBaseSupplied? of a CollectiveMeasurement. Reaching out to the (external) base Measurements can be facilitated by an additional association ?baseQuery? (analogous to defaultQuery). � To take stochastic Measurements based on SMM, a separate Measure would be defined, whereby stochastic methods may implemented via Operation of the Measure. In SMM, Arguments of an Observation serve as parameters to the Operation. In order to be able to vary stochastic parameters within an Observation, Arguments can, additionally, be associated with ObservedMeasure. This will give a practical and SMM-compliant way to handle Operation parameters, both stochastic parameters and parameters in general. Hence, resolution is twofold: � Both Observation and ObservedMeasure can have Arguments associated. � Add baseQuery to non-direct Measurement, whereby baseQuery is an Operation that specifies a query that can used to determine the base measurements of a non-direct Measurement when isBaseSupplied = false. baseQuery is optional even when isBaseSupplied = false and isBaseSupplied is inapplicable when isBaseSupplied = true. baseQuery and defaultQuery should not create inconsistencies. Directly supplied base Measurements would always have precedence. baseQuery would have secondary precedence and defaultQuery has the lowest precedence. The two queries then present two different ways of cutting off the supplied Measurements. defaultQuery allows a user to cut off base Measurements of Measurements of a given Measure. baseQuery allows a user to cut off the base Measurements of a given non-direct Measurement.
Revised Text: ADD the following association TO the Associations table of Sub-clause 13.8 (Grade Class, which is Sub-clause 13.7 (GradeMeasurement Class) in the revised specification): baseQuery:Operation [0..1] Specifies a query that is used to find base measurement when isBaseSupplied = false (its base measurement is not supplied). ADD the following sentence TO Semantics of Sub-clause 13.8 (Grade Class, which is Sub-clause 13.7 (GradeMeasurement Class) in the revised specification): ?Setting isBaseSupplied to false allows the hierarchy of measurements to be elided at any point.?. REPLACE the constraint in Sub-clause 13.8 (Grade Class, which is Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following constraint, which overlaps with the resolution of issues 17535 and 19583: context GradeMeasurement inv: observedMeasure.measure.oclIsTypeOf(GradeMeasure) and error->isEmpty <> value->isEmpty and (isBaseSupplied ?(measurand = baseMeasurement.measurand and gradeTo.to.observedMeasure.measure = observedMeasure.measure.gradeTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) ADD the following text TO Semantics of Sub-clause 13.8 (Grade Class, which is Sub-clause 13.7 (GradeMeasurement Class) in the revised specification): ?If isBaseSupplied is false and baseQuery is supplied then the base measurement can be obtained by executing the baseQuery operation. The value of the measurement then is the symbol found by observedMeasure.measure.interval where base measurement?s value is in the interval.?. ADD the following association TO the Associations table of Sub-clause 13.9 (RankingMeasurement Class, which Sub-clause is added as part of resolution of issue 17535): baseQuery:Operation [0..1] Specifies a query that is used to find base measurement when isBaseSupplied = false (its base measurement is not supplied). ADD the following sentence TO Semantics of Sub-clause 13.9 (RankingMeasurement Class, which Sub-clause is added as part of resolution of issue 17535): ?Setting isBaseSupplied to false allows the hierarchy of measurements to be elided at any point.?. ADD the following constraint TO Sub-clause 13.9 (RankingMeasurement Class, which Sub-clause is added as part of resolution of issue 17535), which overlaps with the resolution of issues 17535 and 19583: context RankingMeasurement inv: observedMeasure.measure.oclIsTypeOf(RankingMeasure) and (isBaseSupplied ?(measurand = baseMeasurement.measurand and rankingTo.to.observedMeasure.measure = observedMeasure.measure. rankingTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) ADD the following text TO Semantics of Sub-clause 13.9 (RankingMeasurement Class, which Sub-clause is added as part of resolution of issue 17535): ?If isBaseSupplied is false and baseQuery is supplied then the base measurement can be obtained by executing the baseQuery operation. The value of the measurement then is found by observedMeasure.measure.interval where base measurement?s value is in the interval.?. ADD the following association TO the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class): baseQuery:Operation [0..1] Specifies a query that is used to find base measurements when isBaseSupplied = false (its base measurements are not supplied). ADD the following sentence TO Semantics of Sub-clause 14.2 (CollectiveMeasurement Class): ?Setting isBaseSupplied to false allows the hierarchy of measurements to be elided at any point.?. REPLACE the constraint in Sub-clause 14.2 (CollectiveMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 19456 and 19583: context CollectiveMeasurement inv: observedMeasure.measure.oclIsTypeOf(CollectiveMeasure) and (isBaseSupplied ? (not baseMeasurementTo->isEmpty and and (baseMeasurementTo.to.observedMeasure.measure = observedMeasure.measure.baseMeasureTo.to) and baseQuery->isEmpty) and (not isBaseSupplied ? baseMeasurementTo->isEmpty) ADD the following text TO Semantics of Sub-clause 14.2 (CollectiveMeasurement Class): ?If isBaseSupplied is false and baseQuery is supplied then the base measurement can be obtained by executing the baseQuery operation. The value of the measurement then equals the result of applying the observedMeasure.measure.accumulator to the found base measurements? values.?. ADD the following association TO the Associations table of Sub-clause 14.5 (BinaryMeasurement Class): baseQuery:Operation [0..1] Specifies a query that is used to find base measurements when isBaseSupplied = false (its base measurements are not supplied). ADD the following sentence TO Semantics of Sub-clause 14.5 (BinaryMeasurement Class): ?Setting isBaseSupplied to false allows the hierarchy of measurements to be elided at any point.?. REPLACE the constraint in Sub-clause 14.5 (BinaryMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 19426, 19456 and 19583: context BinaryMeasurement inv: observedMeasure.measure.oclIsTypeOf(BinaryMeasure) and isBaseSupplied ? (not baseMeasurement1To.isEmpty and not baseMeasurement2To.isEmpty and (not baseMeasurement1To.isEmpty ? (baseMeasurement1To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure1To.to)) and (not baseMeasurement2To.isEmpty ? (baseMeasurement2To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure2To.to))) and baseQuery->isEmpty) and (not isBaseSupplied?baseMeasurement1To->isEmpty and baseMeasurement2To->isEmpty) ADD the following text TO Semantics of Sub-clause 14.5 (BinaryMeasurement Class): ?If isBaseSupplied is false and baseQuery is supplied then the base measurement can be obtained by executing the baseQuery operation. The value of the measurement then equals the result of applying observedMeasure.measure.functor to the found base measurements? values.?. ADD the following association TO the Associations table of Sub-clause 15.3 (RescaledMeasurement Class): baseQuery:Operation [0..1] Specifies a query that is used to find base measurement when isBaseSupplied = false (its base measurement is not supplied). ADD the following sentence TO Semantics of Sub-clause 15.3 (RescaledMeasurement Class): ?Setting isBaseSupplied to false allows the hierarchy of measurements to be elided at any point.?. REPLACE the constraint in Sub-clause 15.3 (RescaledMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 19456 and 19583: context RescaledMeasurement inv: observedMeasure.measure.oclIsTypeOf(RescaledMeasure) and (isBaseSupplied ? not rescaleFrom->isEmpty and (rescaleFrom.from.observedMeasure.measure = observedMeasure.measure.rescaleFrom.from) and baseQuery->isEmpty) and (not isBaseSupplied ? rescaleFrom->isEmpty) ADD the following text TO Semantics of Sub-clause 15.3 (RescaledMeasurement Class): ?If isBaseSupplied is false and baseQuery is supplied then the base measurement can be obtained by executing the baseQuery operation. The value of the measurement then equals the result of applying observedMeasure.measure.operation to the found base measurements? values.?. ADD the following text TO Sub-clause 16.4 (ObservedMeasure Class): ?Both Observation and ObservedMeasure can have associated Argument. Different measurements within a single observation of a same measurand using the same measure can be applied with different arguments. This is a practical way to handle operation parameters, both stochastic parameters and parameters in general. Arguments specified in in a measure?s containing ObservedMeasure take precedence over those specified in the ObservedMeasure?s containing Observation.?. ADD the following association TO the Associations table of Sub-clause 16.4 (ObservedMeasure Class): arguments: Argument [0..*] Specifies the arguments of the observation measure. Changed diagrams, showing baseQuery: � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams). Changed diagram, showing Arguments of ObservedMeasure: � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17473: Add attribute �type� (String) to Observation (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

Add attribute �type� (String) to Observation. Examples of observation type values are �estimated�, �actual�, "simulated", "benchmark".

Resolution: Discussion: VDML Analysis Context associates with SMM Observation (e.g. different Observation in different Context). We can consider to close this SMM issue by doing nothing in SMM, and rather have a type attribute on the Context class in VDML. Disposition: Closed, no change
Revised Text:
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Issue 17474: Allow multiple operations for a direct measure (multiplicity 0..*) (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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

Resolution: The RTF discussed this issue (at length) and found a resolution which addressed the core concern within the issue while preserving the general design pattern of SMM. The following was considered to further variations of Operation: � Instead of one Measure with multiple Operations, it fits SMM better to use multiple Measures, each with one Operation, and all for the same Charactersitic (trait). � These multiple Measures might be stored in a MeasureLibrary of structured Measures, and might be the operational counterparts of a less structured or informal Measure (typically a NamedMeasure) in another MeasureLibrary. That informal Measure might be referenced by the others as their ?source? (for traceability reasons). A ?source? attribute might be added to Measure to support this. This will also generally enable Measure maintenance, whereby e.g. a library of informal Measures, possibly obtained as standard industry Measures, are worked into multiple more structured (and operational) Measures in other MeasureLibraries. Hence, the resolution is to add ?source? (string) as property to Measure.
Revised Text: ADD the following attribute TO the Attributes table of Sub-clause 10.4 (Measure Class) (this is Sub-clause 10.5 in the revised specification): source:string [0..1] Specifies a defined or undefined measure which serves as the source of this measure. Diagram changes, showing the revised Measure Class: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17475: Allow more normative options for language of operation body (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

Allow more normative options for language of operation body. Allow at least JSON, to be able to express operations in url format

Resolution: Discussion: Issue 19408 provides a better solution. Also, JSON is not a query language and would be inappropriate in any case. Disposition: Closed, no change
Revised Text:
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Issue 17476: AdditiveMeasure (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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?

Resolution: Disposition: See issues 19450, 19609 and 19610 for disposition
Revised Text:
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 17477: Inconsistency between Examples (instance models) and meta-model (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity: Significant
Summary:

Examples (instance models) in SMM spec suggest that rescaled measure has "operation", but the meta-model has "formula". This is probably an oversight ?

Issue 17478: RescaledMeasure (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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.

Resolution: Disposition: See issue 19717 for disposition
Revised Text:
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Discussion:

Issue 17479: Wrong reference (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

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� ?

Issue 17480: CollectiveMeasurement class (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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.

Resolution: In CollectiveMeasurement class, replace Association ?baseMeasurement:DimensionalMeasurement [0..*], Identifies the measurements from which this collective measurement was derived?, with ?baseMeasurementTo:BaseMeasurementRelationship [0..*], Specifies the relationship instance that defines the accumulation for this measurement?. Similar problem should also be fixed in a few other places.
Revised Text: REPLACE the association end name ?baseMeasure1? in the first column of the first row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?baseMeasure1To?, and REPLACE its description in second column WITH ?Specifies the relationship instance that defines the first measure accumulated by this binary measure?, which text overlaps with the resolution of issue 19712. REPLACE the association end name ?baseMeasure2? in the first column of the second row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?baseMeasure2To?, and REPLACE its description in second column WITH ?Specifies the relationship instance that defines the second measure accumulated by this binary measure?, which text overlaps with the resolution of issue 19712.. REPLACE description of attribute ?isBaseSupplied? in Attributes table of Sub-clause 14.2 (CollectiveMeasurement Class) WITH ?True if baseMeasurementTo instances are supplied. All are supplied or none is assumed.?. REPLACE the association end name ?baseMeasurement? in the first column of the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class) WITH ?baseMeasurementTo?, and REPLACE its description in second column WITH ?Specifies the relationship instance that defines the accumulation for this measurement?, which text overlaps with the resolution of issue 19712. REPLACE the association end name ?baseMeasurement1? in the first column of the first row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?baseMeasurement1To?, and REPLACE its description in second column WITH ?Specifies the relationship instance that defines the first base measurement accumulated for this measurement.?, which text overlaps with the resolution of issue 19712. REPLACE the association end name ?baseMeasurement2? in the first column of the second row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?baseMeasurement2To?, and REPLACE its description in second column WITH ?Specifies the relationship instance that defines the second base measurement accumulated for this measurement.?, which text overlaps with the resolution of issue 19712.
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17481: Examples (instance diagrams) in SMM spec contain AdditiveMeasure and AggregatedMeasure (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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

Issue 17482: Add accumulator value �product�. (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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

Resolution: Add enumeration value ?product? to Accumulator
Revised Text: ADD literal value ?product? TO Accumulator in Sub-clause 11.3 (Accumulator Data Type). REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams), to show the revised Accumulator Data Type.
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17483: SMM does not allow for a formula, but only has a simple accumulator (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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 ?

Resolution: The RTF discussed this issue (at length) and found a resolution which addressed the core concern within the issue while preserving the general design pattern of SMM. It was agreed to improve the expressiveness of CollectiveMeasure by adding a formula to it, as well as the possibility for a custom accumulator (being an association to Operation). Hence the resolution includes the following: � Add optional formula (string 0..1)) to DimensionalMeasure (every DimensionalMeasure can have one). Formulas are always descriptive and optional. Formula is a comment which briefly presents the Measure?s calculation in an algebraic manner. For example, ?X + Y? or ?Height * Width?. The decision to provide a formula would be entirely up to the SMM library designer. SMM designers can then write SMM libraries in a top down manner by turning DirectMeasures (or NamedMeasures) into CollectiveMeasures, BinaryMeasures and RescaledMeasures as needed. Also, a SMM design tool might fill in the descriptive formula when designer writes libraries bottom up. Unlike formula?s, operations are operational and defined with a coherent program fragment. The programming language must be stated and the fragment is expected to be well formed given the appropriate context. � Add literal value ?custom? to the Accumulator enumeration, and rename ?operation? to ?customAccumulator?. This property is defined as association to Operation. The custom accumulator of CollectiveMeasurement is only defined when its accumulator is ?custom?. In order for the meta-model to remain consistent and for the resolution to be generic, it was also agreed to further improve the expressiveness of some of the other Measures in similar ways, namely of BinaryMeasure per issue 17503 and of RescaledMeasure per issue 17484. So that the resolution of the three issues is consistent with each other.
Revised Text: ADD the following attribute TO Attributes table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): formula:string [0..1] Describes the measure?s calculation in an algebraic manner. This attribute is an optional description of the measure. For example, ?X + Y? or ?Height * Width? are possible formulas. The decision to provide a formula would be entirely up to the SMM library designer. REPLACE association end name ?operation? in first column of second row in Associations table of Sub-clause 11.2 (CollectiveMeasure Class) WITH ?customAccumulator?. REPLACE the constraint in Constraints of Sub-clause 11.2 (CollectiveMeasure Class) WITH the following constraint: Context CollectiveMeasure inv: (accumulator<>Accumulator::custom implies customAccumulator ->isEmpty) and (accumulator=Accumulator::custom implies customAccumulator->notEmpty) ADD the following text TO a newly inserted ?Semantics? header in Sub-clause 11.2 (CollectiveMeasure Class): ?Collective measures have operations (customAccumulator) if and only if their accumulators are custom.?. ADD literal value ?custom? TO Literal Values of Sub-clause 11.3 (Accumulator Data Type (enumeration)). REMOVE attribute ?formula? FROM Attributes table of Sub-clause 12.3 (RescaledMeasure Class). Diagram changes, showing the revised CollectiveMeasure and/or DimensionalMeasure: � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Discussion:

Issue 17484: Should a binary measure have a formula next to a functor ? (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

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 ?

Resolution: The RTF discussed this issue, along with issues 17483 and 17503 and found a resolution which which is consistent with the resolution of both the other issues. Per resolution of issue 17483, a BinaryMeasure, as DimensionalMeasure, has an optional formula. Per resolution of issue 17503, a BinaryMeasure has an Operation (as customFunctor), if and only if its functor is custom. For this Operation the context is a measurand and a pair of base measurements. Per Resolution of issue 17483, also a RescaledMeasure, as DimensionalMeasure, has an optional formula. Consistent with the resolutions for both CollectiveMeasure (per issue 17483) and BinaryMeasure (per issue 17503), the RTF then proposes to further revise RescaledMeasure, as follows: � Add ?offset? and ?multiplier? to RescaledMeasure. For example, F = (C*9/5)+32. The addend (e.g. 32) is the offset and 9/5 is the multiplier. � RescaledMeasure has an operation if and only if its multiplier and offset are not given. The context of it a measurand and a base measurement.
Revised Text: ADD the following attributes TO the Attributes table of Sub-clause 12.3 (RescaledMeasure Class): offset:Real [0..1] Specifies a scalar offset (a) which along with the multiplier (b) defines a linear re-scaling (b*m)+a to obtain an adjusted value from a base measurement (m). multiplier:Real [0..1] Specifies a scalar multiplier (b) which along with the offset (a) defines a linear re-scaling (b*m)+a to obtain an adjusted value from a base measurement (m). ADD the following association TO the Associations table of Sub-clause 12.3 (RescaledMeasure Class): operation:Operation [0..1] Specifies the measurement adjustment operation of this measure. ADD the following constraint, under a new heading ?Constraints? TO sub-clause 12.3 (RescaledMeasure Class): Context RescaledMeasure inv: (offset->notEmpty or multiplier->notEmpty implies operation->isEmpty) and (offset->isEmpty or multiplier->isEmpty implies operation->isEmpty) ADD the following text TO Semantics of sub-clause 12.3 (RescaledMeasure Class): ?Rescaled measures have operations if and only if their multipliers and offsets are not given. For rescaled measure the context is a measurand and a base measurement.?. Diagram changes, showing the revised RescaledMeasure Class: � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17485: The class DimensionalMeasure should be abstract (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

The class DimensionalMeasure should be abstract. Like also DimensionalMeasurement is abstract.   This is an inconsistency in the spec.

Resolution: Both DimensionalMeasure and DimensionalMeasurement should be abstract
Revised Text: Both DimensionalMeasure and DimensionalMeasurement should be abstract. Revised Text: ADD ?(abstract)? TO the heading of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification). ADD ?(abstract)? TO the heading of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification). Diagram changes, showing the revised DimensionalMeasure Class: � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Discussion:

Issue 17486: RatioMeasurement (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

In SMM spec there's the class RatioMeasurement.       However, in the beta2 spec, it is misspelled as RatioMeasurment..      This should be corrected.

Resolution: Replace Class name ?RatioMeasurment? with ?RatioMeasurement? in the specification.
Revised Text: REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams), to correctly show the name of the RatioMeasurement Class.
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17498: CollectiveMeasurement attribute wrong (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Revision
Severity:
Summary:

The class CollectiveMeasurement has attribute "accumulator". This is wrong, as the CollectiveMeasure class has that attribute. CollectiveMeasurement should not have it therefore.

Resolution: Remove accumulator from CollectiveMeasurement, as only CollectiveMeasure should have that property
Revised Text: REMOVE attribute ?accumulator? FROM the Attributes table of Sub-clause 14.2 (CollectiveMeasurement Class). REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams), to show the revised CollectiveMeasurement Class
Actions taken:
July 13, 2012: received issue
March 26, 2015: closed issue

Issue 17503: functor should have an enumeration defined in the spec (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Introduce an Enumeration type for functor, with enumeration values ?sum?, ?difference?, ?times? (or ?product?) and ?divide?, and also ?custom?. In case the BinaryMeasure?s functor has value ?custom?, also specify customFunctor, being an association to Operation (with association end name customFunctor).
Revised Text: ADD Sub-clause 11.4 (BinaryFunctor Data Type (enumeration)) TO the specification, which Sub-clause contains the following text: The BinaryFunctor enumeration defines the binary functor applied to 2 base measurements to compute a binary measurement. Literal Values plus minus multiply divide Custom REPLACE attribute ?functor:String? in first column of Attributes table of sub-clause 11.6 (DimensionalMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?functor:BinaryFunctor [1]?. ADD the following constraint, under a new heading ?Constraints? TO sub-clause 11.6 (DimensionalMeasure) (Sub-clause 11.7 in the revised specification): Context BinaryMeasure inv: (functor <> BinaryFunctor::custom implies customFunctor->isEmpty) and (functor = BinaryFunctor::custom implies customFunctor->isEmpty) ADD the following sentence TO Semantics of sub-clause 11.6 (DimensionalMeasure) (Sub-clause 11.7 in the revised specification): ?A binary measure has an operation if and only if its functor is custom. For a binary measure the context is a measurand and a pair of base measurements.?. REPLACE the constraint in Constraints of Sub-clause11.7 (Ratio Class) (Sub-clause 11.8 (RatioMeasure Class) in the revised specification) WITH the following constraint: context MaximalMeasure inv: functor = ?BinaryFunctor.divide? REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams), to show the BinaryFunctor Enumeration and the revision that relates to the functor attribute.
Actions taken:
July 17, 2012: received issue
March 26, 2015: closed issue

Issue 17504: It is unclear how rescaling is possible from more than 1 simultaneously (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Discussion: The Summary suggests that not only the ?? in the multiplicity of RescaledMeasurement.rescaleFrom is wrong, but the ?? in the multiplicity of RescaledMeasure.rescaleFrom as well. This is incorrect. It should still be possible that a RescaledMeasure has multiple rescaleFrom relationships. Hence issue 19718 was created afterwards, superseding 17504. Disposition: Closed, no change
Revised Text:
Actions taken:
July 17, 2012: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Issue 17535: interval-based mapping (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature:
Severity:
Summary:

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.

Resolution: Rename Ranking into GradeMeasure. Rename Grade into GradeMeasurement. Rename RankingInterval into GradeInterval. Add another Measure, called RankingMeasure (specialization of DimensionalMeasure). It has associated RankingInterval (very much like the existing one). Ranking intervals of RankingMeasure have a numeric value instead of a symbolic string value
Revised Text: REPLACE the text ?The evaluation process may also assign symbolic values demonstrating a ranking that preserve the ordering of underlying base measures. These measures are modeled by the Ranking class. Cyclomatic reliable/unreliable criterion illustrates one such ranking. Reliable is comparably better than unreliable. Comparability is essential here because ranking is not intended to model every possible assignment of measurands.? of Sub-clause 10.1 (General) WITH ?The evaluation process may also assign symbolic values demonstrating a grading which preserve the ordering of underlying base measures. These measures are modeled by the GradeMeasure class. Cyclomatic reliable/unreliable criterion illustrates one such grading. Reliable is comparably better than unreliable. Comparability is essential here because grading is not intended to model every possible assignment of measurands.?. ADD the following association, the description of which overlaps with resolution of issue 19722, TO Associations of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): gradeFrom:GradeMeasureRelationship [0..*] Specifies the relationship instance that defines the grades for this measure. This property subsets the inbound property of Measure. REPLACE ?Ranking? WITH ?GradeMeasure? in the heading of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 in the revised specification). REPLACE the paragraph ?Collectively the ranking intervals may completely cover the base dimension or may leave gaps. A base measurement in such a gap is considered unranked and is not representable as a measurement of the ranking measure.? of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification) WITH the following paragraph: ?Collectively the grade intervals may completely cover the base dimension or may leave gaps. A base measurement in such a gap is considered not graded and is not representable as a measurement of the grade measure.?. REPLACE the sentence ?A ranking resulting in a particular symbol means and only means that the base measure resulted in a value occurring a ranking?s interval which mapped to that symbol.? of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification) WITH the following sentence: ?A grade resulting in a particular symbol means and only means that the base measure resulted in a value occurring a grade?s interval which mapped to that symbol.?. REPLACE the sentence ?Ranking consists of mapping intervals to symbols where the intervals are parts of the underlying measure?s dimension.? of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification) WITH the following sentence: ?A GradeMeasure consists of mapping intervals to symbols where the intervals are parts of the underlying measure?s dimension.?. REPLACE the sentence ?Ranking measure may represent a purely qualitative evaluation with no quantitative base measure.? of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification) WITH the following sentence: ?GradeMeasure may represent a purely qualitative evaluation with no quantitative base measure.?. REPLACE ?RankingMeasureRelationship? WITH ?GradeMeasureRelationship Class? in the heading of Sub-clause 10.13 (RankingMeasureRelationship) (Sub-clause 10.14 (GradeMeasureRelationship) in the revised specification). REPLACE the sentence ?RankingMeasureRelationship is a class representing any relationship of ranking between a ranking measure and a dimensional measure.? in Sub-clause 10.13 (RankingMeasureRelationship) (Sub-clause 10.14 (GradeMeasureRelationship) in the revised specification) WITH ?GradeMeasureRelationship is a class representing any relationship of grading between a grade measure and a dimensional measure.? REPLACE the type of attribute ?from? in the first column of the first row in the Attributes table of Sub-clause 10.13 (RankingMeasureRelationship) (Sub-clause 10.14 (GradeMeasureRelationship) in the revised specification) WITH ?GradeMeasure?, and REPLACE the description of that attribute, in the second column, WITH ?Specifies the grade measure at the from-endpoint of the relationship.?. REPLACE ?RankingInterval Class? WITH ?Interval Class (abstract)? in the heading of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification). REPLACE the text ?This class represents the mapping of an interval to a symbol that serves as a rank.? in Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification) WITH ?This class represents an interval, the range of values from a minimum to a maximum. Either or both end points can be included or excluded.?. REMOVE attribute ?symbol? FROM Attributes table of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification). REPLACE the constraint in Constraints of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification) WITH the following constraint, which overlaps with the resolution of issue 19565: context Interval inv: if maximum.isOclDefined then minimum.isOclDefined and maximum = minimum and (maximumOpen or minimumOpen ? maximum > minimum) else not minimum.isOclDefined ADD Sub-clause 10.16 (GradeInterval Class) TO the specification, which Sub-clause contains the following text: This class represents the mapping of an interval to a symbol that serves as a grade. See Figure 6 Measure Class Diagram. SuperClass Interval Attributes symbol:string Base measurements within this interval are mapped by symbol. ADD Sub-clause 10.17 (RankingMeasure Class) TO the specification, which Sub-clause contains the following text: This class represents (as does the GradeMeasure) simple range-based ranking or classifications based upon already defined dimensional measures. See Figure 6 Measure Class Diagram. It differs from GradeMeasure in that RankingMeasures are DimensionalMeasures. The result of each ranking is a value within a dimension and can be used as such. For example, one might use a RankingMeasure in mapping delivery time to ?satisfaction? units. The delivery time satisfaction measurement can then be combined with other satisfaction measurements to get a customer total satisfaction measurement. The ranking intervals, as with grading intervals, may collectively cover the base dimension or may leave gaps. A base measurement in such a gap is considered not ranked and is not representable as a measurement of the ranking measure. The intervals may overlap. A ranking resulting in a particular numeric value means and only means that the base measure resulted in a value occurring a rank?s interval which mapped to that numeric value. This does not exclude the possibility that the value might occur in another interval. SuperClass DimensionalMeasure Associations rankingTo:RankingMeasureRelationship [1] Specifies the relationship instance that defines the measure ranked by this ranking. interval:RankingInterval [1..*] Identifies intervals within the dimension of the base measure and the symbol to which each interval is mapped. ADD Sub-clause 10.18 (RankingMeasureRelationship Class) TO the specification, which Sub-clause contains the following text: RankingMeasureRelationship is a class representing any relationship of ranking between a ranking measure and a base dimensional measure. SuperClass BaseMeasureRelationship Associations from:RankingMeasure [1] Specifies the ranking measure at the from-endpoint of the relationship. to:DimensionalMeasure [1] Specifies the dimensional measure at the to-endpoint of the relationship. ADD Sub-clause 10.19 (RankingInterval Class) TO the specification, which Sub-clause contains the following text: This class represents the mapping of an interval to a number that serves as a rank. See Figure 6 Measure Class Diagram. SuperClass Interval Attributes value:Number Base measurements within this interval are mapped to this value. REPLACE the sentence ?The Grade subclass has a symbolic value.? in Sub-clause 13.2 (Measurement Class) WITH the following sentence: ?The GradeMeasurement subclass has a symbolic value.? REPLACE the first row in the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification) WITH the following association: gradeFrom:GradeMeasurementRelationship [0..*] Specifies the relationship instances that define the grade for this measurement. ADD the following association TO the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): rankingFrom:RankingMeasurementRelationship [0..*] Specifies the relationship instances that define the ranking for this measurement. REPLACE ?Grade? WITH ?GradeMeasurement? in the heading of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 in the revised specification). REPLACE the text ?The Grade class represents the grade found by Ranking measure. Its ranking scheme mapped the grade?s underlying base measurement to the grade?s symbol.? in Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following text: ?The GradeMeasurement class represents the grade found by GradeMeasure. Its grading scheme mapped the grade?s underlying base measurement to the grade?s symbol.?. REPLACE the description of the ?isBaseSupplied? attribute in the Attributes table of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following description: ?True if gradeTo is specified (base measurement is supplied).?. REPLACE attribute ?rankingTo:RankingMeasurementRelationship [0..1]? WITH ?gradeTo:GradeMeasurementRelationship [0..1]? in the Attributes table of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification). (Its description, in second column remains unchanged.) REPLACE the constraint in Constraints of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following constraint, which overlaps with resolution of issues 19583, 17472 and 19456: context GradeMeasurement inv: observedMeasure.measure.oclIsTypeOf(GradeMeasure) and error->isEmpty <> value->isEmpty and (isBaseSupplied ?(measurand = gradeTo.to.measurand and gradeTo.to.observedMeasure.measure = observedMeasure.measure.gradeTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) REPLACE ?RankingMeasurementRelationship? WITH ?GradeMeasurementRelationship? in the heading of Sub-clause 13.9 (RankingMeasurementRelationship Class) (Sub-clause 13.8 in the revised specification). REPLACE the sentence ?RankingMeasurementRelationship is a class representing any relationship of grading between a grade measurement and a dimensional measurement.? in Sub-clause 13.9 (RankingMeasurementRelationship Class) (Sub-clause 13.8 (GradeMeasurementRelationship Class) in the revised specification) WITH the following sentence: ?GradeMeasurementRelationship is a class representing any relationship of grading between a grade measurement and a dimensional measurement.?. REPLACE attribute ?from:Grade [1]? in the first row of the Attributes table of Sub-clause 13.9 (RankingMeasurementRelationship Class) (Sub-clause 13.8 (GradeMeasurementRelationship Class) in the revised specification) WITH attribute ?from:GradeMeasurement [1]?. (Its description, in second column, remains unchanged.) ADD Sub-clause 13.9 (RankingMeasurement Class) TO the specification, which Sub-clause contains the following text: The RankingMeasurement class represents the grade found by RankingMeasure. Its ranking scheme mapped the ranking?s underlying base measurement to the ranking?s value. The base measurements share its measurand with this derived ranking. See Figure 11 Measurements. SuperClass Measurement Attributes isBaseSupplied:Boolean True if rankingTo is specified (base measurement is supplied). Associations rankingTo:RankingMeasurementRelationship [0..1] Specifies the relationship instance that defines the measurement ranked by this ranking. Constraints context RankingMeasurement inv: observedMeasure.measure.oclIsTypeOf(RankingMeasure) and (isBaseSupplied ?(measurand = rankingTo.to.measurand and rankingTo.to.observedMeasure.measure = observedMeasure.measure.rankingTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) Semantics If isBaseSupplied holds, then value is one of the symbols found by measure.interval where rankTo.to.value is in the interval. A numeric value is in the interval if and only if the it is less than the maximumEndPoint when maximumOpen is false, less than or equal to maximumEndPoint when maximumOpen is true, greater than minimumEndPoint when minimumOpen is false, and greater than or equal to minimumEndPoint when minimumOpen is true. ADD Sub-clause 13.10 (RankingMeasurementRelationship Class) TO the specification, which Sub-clause contains the following text: RankingMeasurementRelationship is a class representing any relationship of ranking between a ranking measurement and a dimensional measurement. SuperClass MeasurementRelationship Associations from:RankingMeasurement [1] Specifies the ranking measurement at the from-endpoint of the relationship. to:DimensionalMeasurement [1] Specifies the dimensional measurement at the to-endpoint of the relationship. Diagram changes, showing the new and revised Classes: � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
August 1, 2012: received issue
March 26, 2015: closed issue

Issue 17561: Scales of Measurement (smm-rtf)

Click here for this issue's archive.
Source: CAST Software (Dr. Bill Curtis, b.curtis(at)castsoftware.com)
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution: Add scaleOfMeasurement property to Measure, with enumerated type, consisting of the following five enumeration values: the four standard ones, namely ?nominal?, ?ordinal?, ?interval?, and ?ratio?, and the fifth being ?custom?. In case of ?custom?, the Measure has another string property instantiated, representing the custom scale (e.g. Guttman). In addition, add a few constraints, like: allow nominal & ordinal on GradeMeasure, and allow interval & ratio on DimensionalMeasure.
Revised Text: REPLACE the sentence ?Simple algebraic change of scales of already defined numeric measures (e.g., the translation to ?choice points? from Cyclomatic complexity).? in Clause 1 (Scope) WITH the following sentence: ?Simple algebraic change of calibration of already defined numeric measures (e.g. the translation to ?choice points? from Cyclomatic complexity).?. ADD the following attribute TO the Attributes table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification): scale:ScaleOfMeasurement [0..1] Specifies the scale of measurement (nominal, ordinal, interval, ratio, or custom). ADD Sub-clause 10.21 (ScaleOfMeasurement Data Type (enumeration)) TO the specification, which Sub-clause contains the following text: The scale of measurement classifies the measure into four levels: nominal, ordinal, interval or ratio. ScaleofMeasurement may be used to develop taxonomy of measures. Literal Values nominal ordinal interval ratio custom Nominal scale measures differentiate measured objects based upon their categorical equivalence. Classification by gender, favorite color, and religion are nominal scales. Ordinal scales provide sorting of the measured objects, but do not allow for relative degree of difference between them. Customer service satisfaction surveys are often ordinal scales with, e.g., values of ?Very Unsatisfied?, ?Somewhat Unsatisfied?, ?Neutral?, ?Satisfied?, and ?Very Satisfied?. The median is meaningful for ordinal scales. Measures at the interval scale or level have units of measure. That is, they are DimensionalMeasures. Sums and differences of interval scale measurements are meaningful as are means and standard deviations. Their zero may not, however, be the lowest value of the scale. Celsius, Fahrenheit, elevation (height above/below sea level), pH, time of day are interval scales. Ratio scale measures are DimensionalMeasures with absolute zeros. Kelvin, net loss and net gain are ratio scales. Scalar multiples are permissible with ratio scales. One can say half as hot or twice as profitable. The coefficient of variation is meaningful for ratio scales as their measurements are always non-negative values. Custom allows measure library designers to extend ScaleOfMeasurement to include other scales. Semantics The four levels are scales of measurement are cumulative. Ordinal implies nominal; interval implies ordinal; and ratio implies interval. All SMM measures are nominal scale measures. Asserting that a measure is an ordinal scale measure implies the existence of a sorting of the measured objects based upon their measurements. All DimensionalMeasures are interval scale measures. Asserting that a DimensionalMeasure is a ratio scale measure implies that the dimension?s zero is absolute. Diagram changes, showing the revised Measure Class and the ScaleOfMeasurement enumeration: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
August 22, 2012: received issue
March 26, 2015: closed issue

Issue 17598: "Influence" of measure relationship (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Add optional property "influence" to MeasureRelationship. This is a property with enumeration type "Influence", having two enumeration values: "positive", "negative". In addition, a constraint is added, specifying that this property is not allowed for EquivalentMeasureRelationship (and neither for RefinementMeasureRelationship).
Revised Text: ADD the following attribute TO the Attributes table of Sub-clause 10.7 (MeasureRelationship Class) (Sub-clause 10.9 in the revised specification): influence:Influence [0..1] Indicates whether the origin Measure positively or negatively influences the target Measure. ADD the following constraint, under a new heading ?Constraints? TO Sub-clause 10.8 (EquivalentMeasureRelationship Class) (Sub-clause 10.10 in the revised specification): context EquivalentMeasureRelationship inv: influence.oclIsTypeOf(OclVoid) ADD the following constraint, under a new heading ?Constraints? TO Sub-clause 10.9 (RefinementMeasureRelationship Class) (Sub-clause 10.11 in the revised specification): context RefinementMeasureRelationship inv: influence.oclIsTypeOf(OclVoid) ADD Sub-clause 10.20 (Influence Data Type (enumeration)) TO the specification, which Sub-clause contains the following text: The Influence enumeration defines Influence � a property of MeasureRelationship. See Figure 6. The Influence property provides a quick understanding of how measures influence each other. Literal Values Positive Negative Diagram changes, showing the revised MeasureRelationship Class and the new Influence enumeration: � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
September 18, 2012: received issue
March 26, 2015: closed issue

Issue 18751: Clarify that Observation.requestedMeasures is of type SmmElement and not AbstractMeasureElement (smm-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

It is currently the case that Observation.requestedMeasures is of type SmmElement. Constraints have been added to make sure that one does not pass a e.g. SmmModel instance as a requestedMeasure but only instances of type Measure, MeasureCategory and CategoryRelationship.      My suggestion is to change the type from SmmElement to AbstractMeasureElement. We would then be able to measure the following:  MeasureCategory - e.g. Measures that fall in the same category  Scope - e.g. Measures that use the define the same scope  Characteristic - e.g. Measures that are characterized by a certain characteristic  Operation - e.g. Measures that use a certain operation  OCLOperation - e.g. Measures that use a certain OCLOperation  Measure      This would make the metamodel cleaner by having lessing constraints and making it easier to understand. Could it be that this was caused because of the fact that there is no section about AbstractMeasureElement?

Resolution: Change the type of requestedMeasures to be AbstractMeasureElement
Revised Text: REPLACE the type of association end ?requestedMeasures? in the first column of the second row in the Associations table of Sub-clause 16.2 (Observation Class) WITH type ?AbstractMeasureElement?. Diagram changes, showing the revised Observation Class: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
June 4, 2013: received issue
March 26, 2015: closed issue

Issue 19408: New SMM RTF Issue: Need "Opaque" operation body language (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Section 10.5 (Operation Class) defines as normative languages "OCL" and "XQuery". This is too restrictive. An implementer should be able to implement Operations differently, without conflicting with the spec. Hence we suggest to add "Opaque" as a valid value as well".

Resolution: In addition to the currently specified ones (OCL, Xquery), allow user-supplied values for language. Which could be ?English?, ?French?, ?SBVR? or whatever language they want to informally express the body in.
Revised Text: REPLACE the sentence ?Valid values are currently ?OCL? and ?XQuery.??, as part of the description of the ?language? attribute in the second column of the first row in the Attributes table of Sub-clause 10.5 (Operation Class) (Sub-clause 10.7 in the revised specification) WITH the following text: ?The language may be a computer language such as ?OCL? or ?XQuery? or a natural language such as ?English?, ?French?, etc.?.
Actions taken:
May 9, 2014: received issue
March 26, 2015: closed issue

Issue 19426: Typo in Constrains for BinaryMeasurement Class (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The constraints in Section 14.4 (BinaryMeasurement Class) should have BinaryMeasurement as the context, not RatioMeasurement.�

Resolution: Replace ?RatioMeasurement? with ?BinaryMeasurement? as context in the constraint of BinaryMeasurement Class.
Revised Text: REPLACE the constraint in Constraints of Sub-clause 14.5 (BinaryMeasurement Class) WITH the following constraint, which overlaps with resolution of issues 17472, 19456 and 19583: context BinaryMeasurement inv: observedMeasure.measure.oclIsTypeOf(BinaryMeasure) and isBaseSupplied ? (not baseMeasurement1To.isEmpty and not baseMeasurement2To.isEmpty and (not baseMeasurement1To.isEmpty ? (baseMeasurement1To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure1To.to)) and (not baseMeasurement2To.isEmpty ? (baseMeasurement2To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure2To.to))) and baseQuery->isEmpty) and (not isBaseSupplied?baseMeasurement1To->isEmpty and baseMeasurement2To->isEmpty)
Actions taken:
May 21, 2014: received issue
March 26, 2015: closed issue

Discussion:

Issue 19447: Unit consistency (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature:
Severity:
Summary:

The semantics section of each collective measure class should discuss unit consistency.   For example, the units of measure for the base measures must be equivalent to the unit of measure for the binary measure when the functor is addition.

Resolution: Write some text about unit consistency for all aggregating Measures (CollectiveMeasure, BinaryMeasure, and RescaledMeasure). The text may be at the base relationship level instead of at the Measure level.
Revised Text: ADD the following text TO Semantics of Sub-clause 10.17 (RankingMeasure Class), which Sub-clause has been added by the resolution of issue 17535: Semantics A central role for RankingMeasure is the translation of a measurement with one unit to a measurement of a different unit. Unit consistency is consequently not enforced by the tool and is the responsibility of the measure library designer. ADD the following text TO Constraints of Sub-clause 11.2 (CollectiveMeasure Class): If the accumulator is sum, maximum, minimum, average or standardDeviation then all of the base measures? units MUST be consistent with the collective measure?s unit. If baseMeasureTo.rescaledMeasure is specified then baseMeasureTo.rescaledMeasure.unit MUST be identical to collective measure?s unit. Otherwise baseMeasureTo.to.unit MUST be identical to the collective measure?s unit. If the accumulator is product, then each of the base measures? units MUST be scalar. If baseMeasureTo.rescaledMeasure is specified then baseMeasureTo.rescaledMeasure.unit MUST be scalar. Otherwise baseMeasureTo.to.unit MUST be scalar. ADD the following text TO Semantics of Sub-clause 11.2 (CollectiveMeasure Class): ?When the accumulator is custom, unit consistency cannot be enforced by the tool and is the responsibility of the measure library designer.?. ADD the following text TO Constraints of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification): If the functor is ?plus? or ?minus?, then both base measures? units MUST be consistent with the binary measure?s unit. If baseMeasure1To.rescaledMeasure is specified then baseMeasure1To.rescaledMeasure.unit MUST be identical to binary measure?s unit. Otherwise baseMeasure1To.to.unit MUST be identical to the binary measure?s unit. If baseMeasure2To.rescaledMeasure is specified then baseMeasure2To.rescaledMeasure.unit MUST be identical to binary measure?s unit. Otherwise baseMeasure2To.to.unit MUST be identical to the binary measure?s unit. If the functor is ?multiply?, then the binary measure?s unit MUST be equivalent to the product of the base measures? units (after re-scaling if present) as shown in the table below. rescaledMeasure specified for baseMeasure1To rescaledMeasure specified for baseMeasure2To Binary measure?s unit equivalent No No baseMeasure1To.to.unit * baseMeasure2To.to.unit No Yes baseMeasure1To.to.unit * baseMeasure2To.rescaledMeasure.unit Yes No baseMeasure1To.rescaledMeasure.unit * baseMeasure2.to.unit Yes Yes baseMeasure1To.rescaledMeasure.unit * baseMeasure2to.rescaledMeasure.unit If the functor is ?divide?, then the binary measure?s unit MUST be equivalent to the unit of the first base measure (after re-scaling if present) divided by the unit of the second base measure (after re-scaling if present) as shown in the table below. rescaledMeasure specified for baseMeasure1To rescaledMeasure specified for baseMeasure2To Binary measure?s unit equivalent No No baseMeasure1To.to.unit / baseMeasure2To.to.unit No Yes baseMeasure1To.to.unit / baseMeasure2To.rescaledMeasure.unit Yes No baseMeasure1To.rescaledMeasure.unit / baseMeasure2To.to.unit Yes Yes baseMeasure1To.rescaledMeasure.unit / baseMeasure2To.rescaledMeasure.unit ADD the following text TO Semantics of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification): ?When the functor is custom, unit consistency cannot be enforced by the tool and is the responsibility of the measure library designer.?. ADD the following text TO Constraints of Sub-clause 12.3 (RescaledMeasure Class): ?All UnitOfMeasures in the collection rescaleFrom.from.unit MUST be the same UnitOfMeasure.?. ADD the following text TO Semantics of Sub-clause 12.3 (RescaledMeasure Class): ?A central role for RescaledMeasure is the translation of a measurement with one unit to a measurement of a different unit. Unit consistency is consequently not enforced by the tool and is the responsibility of the measure library designer.?.
Actions taken:
June 4, 2014: received issue
March 26, 2015: closed issue

Issue 19448: Observation has Arguments associated (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The  association list of Observation class fails to include the arguments association to the Argument class.

Resolution: Add the arguments association to the Associations table of the Observations Class
Revised Text: ADD the following association TO the Associations table of Sub-clause 16.2 (Observation Class): arguments:Argument [0..*] Specifies the arguments of the observation.
Actions taken:
June 4, 2014: received issue
March 26, 2015: closed issue

Issue 19450: Make all examples shown in the normative clauses of the SMM doc compatible with the latest SMM spec (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Make all examples shown in the normative clauses of the SMM doc compatible with the latest SMM spec

Resolution: Make all examples (object diagrams) in the normative clauses of the SMM specification compatible with all balloted and accepted resolutions that impact the SMM meta-model.
Revised Text: see pages 78 - 80 of ptc/2015-03-06 for details
Actions taken:
June 5, 2014: received issue
March 26, 2015: closed issue

Issue 19451: Make all examples shown in the non-normative clauses of the SMM doc compatible with the latest SMM spec (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Make all examples shown in the non-normative clauses of the SMM doc compatible with the latest SMM spec

Resolution: Disposition: See issues 19609 and 19610 for disposition
Revised Text:
Actions taken:
June 5, 2014: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 19452: Add a re-scaling association to the all base measure relationship (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Add a re-scaling association to the all base measure relationship which support in-lining re-scaling to the other various collective measures

Resolution: Associate BaseMeasureRelationship with RescaledMeasure, which enables to "transform" the base measurements upon aggregation to e.g. collective or binary measurement. This will make CollectiveMeasures, BinaryMeasures, etc. more powerful, so that users can achieve the same with less Measures.
Revised Text: REPLACE the type of the association end in the first column of the first row of the Associations table of Sub-clause 11.2 (CollectiveMeasure Class) WITH type ?BaseNMeasureRelationship?. ADD Sub-clause 11.9 (BaseMeasureRelationship Class (abstract)) TO the specification, which Sub-clause contains the following text: BaseMeasureRelationship is a class representing relationship of hierarchy between a derived measure and its base measures. The rescaledMeasure association provides a mechanism for a change in dimension from that of the base measure, to apply a weight factor, to flip the sign, or other linear adjustments. SuperClass MeasureRelationship Associations rescaledMeasure:RescaledMeasure [0..1] Specifies the rescaled measure which defines a linear adjustment which may translate from the base measure?s dimension (unit of measure) to the derived measure?s dimension or apply a weight factor. REPLACE the heading ?BaseMeasureRelationship Class? of Sub-clause 11.8 (Sub-clause 11.10 in the revised specification) WITH ?BaseNMeasureRelationship Class?. REPLACE the sentence ?BaseMeasureRelationship is a class representing relationship of hierarchy between a collective measure and a dimensional measure.? in Sub-clause 11.8 (BaseMeasureRelationship Class) (Sub-clause 11.10 (BaseNMeasureRelationship Class) in the revised specification) WITH the following sentence: ?BaseNMeasureRelationship is a class representing relationship of hierarchy between a collective measure and a dimensional measure.?. REPLACE the Superclass of Sub-clause 11.8 (BaseMeasureRelationship Class) (Sub-clause 11.10 (BaseNMeasureRelationship Class) in the revised specification) in the revised specification) WITH the Class ?BaseMeasureRelationship?. REPLACE the Superclass of Sub-clause 11.9 (Base1MeasureRelationship Class) (Sub-clause 11.11 in the revised specification) WITH the Class ?BaseMeasureRelationship?. REPLACE the Superclass of Sub-clause 11.10 (Base2MeasureRelationship Class) (Sub-clause 11.12 in the revised specification) WITH the Class ?BaseMeasureRelationship?. ADD the following text TO Sub-clause 12.3 (RescaledMeasure Class): ?The RescaledMeasure class can also be used to apply a weight factor, to flip the sign, or make other linear adjustments. Non-linear adjustments may be specified with an Operation.?. ADD the following association TO the Associations table of Sub-clause 12.3 (RescaledMeasure Class): rescales:BaseMeasureRelationship [0..1] Specifies the relationship instance that defines the measure which accumulates the base measure specified by rescaleFrom rescaled of this measure. ADD the following constraint TO Constraints of Sub-clause 12.3 (RescaledMeasure Class): ?If rescales is specified then there MUST exist a rescaledFrom.from that equals rescales.to.?. REPLACE the type of the association end in the first column of the first row of the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class) WITH type ?BaseNMeasurementRelationship?. ADD Sub-clause 14.7 (BaseMeasurementRelationship Class (abstract)) TO the specification, which Sub-clause contains the following text: BaseMeasurementRelationship is a class representing relationship of hierarchy between a derived measurement and a base dimensional measurement. SuperClass MeasurementRelationship REPLACE the heading ?BaseMeasurementRelationship Class? of Sub-clause 14.7 (Sub-clause 14.8 in the revised specification) WITH ?BaseNMeasurementRelationship Class?. REPLACE the sentence ?BaseMeasurementRelationship is a class representing relationship of hierarchy between a collective measurement and a dimensional measurement.? in Sub-clause 14.7 (BaseMeasurementRelationship Class) (Sub-clause 14.8 (BaseNMeasurementRelationship Class) in the revised specification) WITH the following sentence: ?BaseNMeasurementRelationship is a class representing relationship of hierarchy between a collective measurement and a dimensional measurement.?. REPLACE the Superclass of Sub-clause 14.7 (BaseMeasurementRelationship Class) (Sub-clause 14.8 (BaseNMeasurementRelationship Class) in the revised specification) WITH the Class ?BaseMeasurementRelationship?. REPLACE the Superclass of Sub-clause 14.8 (Base1MeasurementRelationship Class) (Sub-clause 14.9 in the revised specification) WITH the Class ?BaseMeasurementRelationship?. REPLACE the Superclass of Sub-clause 14.9 (Base2MeasurementRelationship Class) (Sub-clause 14.10 in the revised specification) WITH the Class ?BaseMeasurementRelationship?. REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams), to show the revised RescaledMeasure Class and the revised BaseMeasureRelationship Class and its specializations. REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams), to show the revised BaseMeasurementRelationship Class and its specializations.
Actions taken:
June 5, 2014: received issue
March 26, 2015: closed issue

Issue 19453: Add a non-normative clause to the SMM doc which demonstrates a SMM library of basic unit conversions (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Defer Library of Unit conversions This will potentially be useful, though it is not critical at this moment. Given the scope of the current RTF, it was agreed to defer it. Possibly to, potentially, SMM 2.0.
Revised Text:
Actions taken:
June 5, 2014: received issue
March 26, 2015: closed issue
April 28, 2015: Deferred

Discussion:

This will potentially be useful, though it is not critical at this moment. Given the scope of the current RTF, it was agreed to defer it to a next RTF.   Disposition:	Deferred

Issue 19456: Constraints on aggregating measurement classes (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Constraints on CollectiveMeasurement, BinaryMeasurement, RatioMeasurement and RescaledMeasurements are wrong.   None have been updated to use their base measurement relationships.

Resolution: Constraints updated to reference base measurement relationships
Revised Text: clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following constraint, which overlaps with resolution of issues 17472 and 19583: context GradeMeasurement inv: observedMeasure.measure.oclIsTypeOf(GradeMeasure) and error->isEmpty <> value->isEmpty and (isBaseSupplied ?(measurand = gradeTo.to.measurand and gradeTo.to.observedMeasure.measure = observedMeasure.measure.gradeTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) REPLACE the sentence ?If isBaseSupplied holds, then value is one of the symbols found by measure.interval where baseMeasurement.value is in the interval.? in Semantics of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following sentence, which overlaps with resolution of issue 19583: ?If isBaseSupplied holds, then value is one of the symbols found by observedMeasure.measure.interval where gradeTo.to.value is in the interval.?. REPLACE the constraint in Constraints of Sub-clause 14.2 (CollectiveMeasurement Class) WITH the following constraint, which overlaps with resolution of issues 17472 and 19583: context CollectiveMeasurement inv: observedMeasure.measure.oclIsTypeOf(CollectiveMeasure) and (isBaseSupplied ? (not baseMeasurementTo->isEmpty and and (baseMeasurementTo.to.observedMeasure.measure = observedMeasure.measure.baseMeasureTo.to) and baseQuery->isEmpty) and (not isBaseSupplied ? baseMeasurementTo->isEmpty) REPLACE the sentence ?If isBaseSupplied holds, then value equals the result of applying measure.accumulator the set of values given by baseMeasurement.value.? in Semantics of Sub-clause 14.2 (CollectiveMeasurement Class) WITH the following sentence, which overlaps with resolution of issue 19583: ?If isBaseSupplied holds, then value equals the result of applying observedMeasure.measure.accumulator to the set of values given by baseMeasurementTo.to.value.?. REPLACE the constraint in Constraints of Sub-clause 14.5 (BinaryMeasurement Class) WITH the following constraint, which overlaps with resolution of issues 17472, 19426 and 19583: context BinaryMeasurement inv: observedMeasure.measure.oclIsTypeOf(BinaryMeasure) and isBaseSupplied ? (not baseMeasurement1To.isEmpty and not baseMeasurement2To.isEmpty and (not baseMeasurement1To.isEmpty ? (baseMeasurement1To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure1To.to)) and (not baseMeasurement2To.isEmpty ? (baseMeasurement2To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure2To.to))) and baseQuery->isEmpty) and (not isBaseSupplied?baseMeasurement1To->isEmpty and baseMeasurement2To->isEmpty) REPLACE the sentence ?If isBaseSupplied holds, then value equals the result of applying measure.functor to baseMeasurement1.value and baseMeasurement2.value.? in Semantics of Sub-clause 14.5 (BinaryMeasurement Class) WITH the following sentence, which overlaps with the resolution of issue 19583: ?If isBaseSupplied holds, then value equals the result of applying observedMeasure.measure.functor to baseMeasurement1To.to.value and baseMeasurement2To.to.value.?. REPLACE the constraint in Constraints of Sub-clause 14.6 (RatioMeasurement Class) WITH the following constraint, which overlaps with resolution of issue 19583: context RatioMeasurement inv: observedMeasure.measure.oclIsTypeOf(RatioMeasure) and isBaseSupplied ? (value = baseMeasurement1To.to.value / baseMeasurement2To.to.value) REPLACE the constraint in Constraints of Sub-clause 15.3 (RescaledMeasurement Class) WITH the following constraint, which overlaps with resolution of issues 17472 and 19583: context RescaledMeasurement inv: observedMeasure.measure.oclIsTypeOf(RescaledMeasure) and (isBaseSupplied ? not rescaleFrom->isEmpty and (rescaleFrom.from.observedMeasure.measure = observedMeasure.measure.rescaleFrom.from) and baseQuery->isEmpty) and (not isBaseSupplied ? rescaleFrom->isEmpty) REPLACE the sentence ?If isBaseSupplied is true then value equals result of applying measure.operation to the baseMeasurements? values.? in Semantics of Sub-clause 15.3 (RescaledMeasurement Class) WITH the following sentence, which overlaps with the resolution of issue 19583: ?If isBaseSupplied is true then value equals result of applying observedMeasure.measure.operation to the rescaleFrom.from.value.?.
Actions taken:
June 7, 2014: received issue
March 26, 2015: closed issue

Issue 19457: Introduce Unit of Measure as a class. (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Currently DimensionalMeasure has Unit of measure as an attribute with type string.   Unit needs to be treated as a first class object and not just indicated by a name.    A class need to be introduced for it and the attribute needs to be replaced with an association relating DimensionalMeasure to a Unit.   Indication by name leaves open whether �meter�, �Meter� or �metre�.    But the object for each would be the same and the case and internationalization would be left to rendering.

Resolution: Replace the "unit" property (string) of DimensionalMeasure, by a "unit" association from DimensionalMeasure to UnitOfMeasure. This will greatly improve re-use and consistency of units, across DimensionalMeasures. Unit conversion can be left to rendering.
Revised Text: ADD Sub-clause 10.6 (UnitOfMeasure Class) TO the specification, which Sub-clause contains the following text: The UnitOfMeasure class provides a representation for units of measure. A unit is a quantity in terms of which the magnitudes of other quantities within the same total order can be stated. Units are expected to be standards which are heavily re-used. The SmmModel may contain a base, shared MeasureLibrary which contains these standard units. For example, one such MeasureLibrary could provide all the units of the British imperial system. SuperClass AbstractMeasureElement REMOVE the ?unit? attribute FROM the Attributes table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification). ADD the following association TO the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): unit: UnitOfMeasure [1] Specifies the unit of measure Diagram changes, showing the revised DimensionalMeasure Class and the new UnitOfMeasure Class: � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
June 7, 2014: received issue
March 26, 2015: closed issue

Discussion:

Issue 19497: Remove RecursiveMeasureRelationship and RecursiveMeasurementRelationship classes (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

We have no use cases demonstrating the value of these classes.    They, moreover, are likely to introduce confusion about SMM.    The classes and their associations should be removes.

Resolution: Remove RecursiveMeasureRelationship and RecursiveMeasurementRelationship classes.
Revised Text: REMOVE the rows for the ?recursiveFrom? and ?recursiveTo? association ends FROM the Associations table of Sub-clause 10.4 (MeasureClass) (Sub-clause 10.5 in the revised specification). REMOVE Sub-clause 10.10 (RecursiveMeasureRelationship Class) FROM the specification. REMOVE the rows for the ?recursiveFrom? and ?recursiveTo? association ends FROM the Associations table of Sub-clause 13.2 (MeasurementClass). REMOVE Sub-clause 13.6 (RecursiveMeasurementRelationship Class) FROM the specification. Diagram changes, to show the result of the removal of the Classes: � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
June 30, 2014: received issue
March 26, 2015: closed issue

Issue 19565: Interval Open attributes (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The description of the GradeInterval�s attributes maximumOpen and minimumOpen are backwards.   It should say true iff the interval excludes the endpoint.

Resolution: For attributes maximumOpen and minimumOpen, say true if the interval excludes the endpoint
Revised Text: REPLACE the sentence ?True if and only if interval include maximum endpoint.? in the description of attribute ?maximumOpen? in the second column of the first row of the Attributes table of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification) WITH the following sentence: ?True if and only if interval excludes maximum endpoint.?. REPLACE the sentence ?True if and only if interval include minimum endpoint.? in the description of attribute ?minimumOpen? in the second column of the second row of the Attributes table of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification) WITH the following sentence: ?True if and only if interval excludes minimum endpoint.?.
Actions taken:
August 1, 2014: received issue
March 26, 2015: closed issue

Issue 19583: Identify the observedMeasure role in the Association sub-clause of the Measurements class (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The constraints given in the subclasses of the Measurement class are wrong because there is no way to navigate from a Measurement to its measure without using the observedMeasure property of Measurement.    That property needs to be documented.   Then the constraints need to be fixed to use observedMeasure.

Resolution: Document the observedMeasure property of the Measurement class. Fix the OCL constraints of the Measurement sub-classes to use observedMeasure
Revised Text: ADD the following row TO the Associations table of Sub-clause 13.2 (Measurement Class): observedMeasure:ObservedMeasure [1] Identifies the ObservedMeasure which contains the measurement. REPLACE the constraint in Constraints of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification) WITH the following constraint: context DimensionalMeasurement inv: observedMeasure.measure.oclIsTypeOf(DimensionalMeasure) and error->isEmpty <> value->isEmpty REPLACE the constraint in Constraints of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following constraint, which overlaps with the resolution of issues 17472 and 19456: context GradeMeasurement inv: observedMeasure.measure.oclIsTypeOf(GradeMeasure) and error->isEmpty <> value->isEmpty and (isBaseSupplied ?(measurand = gradeTo.to.measurand and gradeTo.to.observedMeasure.measure = observedMeasure.measure.gradeTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) REPLACE the sentence ?If isBaseSupplied holds, then value is one of the symbols found by measure.interval where baseMeasurement.value is in the interval.? in Semantics of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification) WITH the following sentence, which overlaps with the resolution of issue 19456: ?If isBaseSupplied holds, then value is one of the symbols found by observedMeasure.measure.interval where gradeTo.to.value is in the interval.?. REPLACE the object diagram in Figure 12, to show instantiation of the ?observedMeasure? property, WITH the same object diagram that the resolution of issue 19450 specifies as replacement of Figure 12. ADD the following constraint TO Sub-clause 13.9 (RankingMeasurement Class, which Sub-clause is added as part of resolution of issue 17535), which overlaps with the resolution of issues 17472 and 17535: context RankingMeasurement inv: observedMeasure.measure.oclIsTypeOf(RankingMeasure) and (isBaseSupplied ?(measurand = baseMeasurement.measurand and rankingTo.to.observedMeasure.measure = observedMeasure.measure. rankingTo.to and baseQuery->isEmpty)) and (baseQuery->notEmpty ?( not isBaseSupplied)) REPLACE the constraint in Constraints of Sub-clause 14.2 (CollectiveMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 17472 and 19456: context CollectiveMeasurement inv: observedMeasure.measure.oclIsTypeOf(CollectiveMeasure) and (isBaseSupplied ? (not baseMeasurementTo->isEmpty and and (baseMeasurementTo.to.observedMeasure.measure = observedMeasure.measure.baseMeasureTo.to) and baseQuery->isEmpty) and (not isBaseSupplied ? baseMeasurementTo->isEmpty) REPLACE the sentence ?If isBaseSupplied holds, then value equals the result of applying measure.accumulator the set of values given by baseMeasurement.value.? in Semantics of Sub-clause 14.2 (CollectiveMeasurement Class) WITH the following sentence, which overlaps with the resolution of issue 19456: ?If isBaseSupplied holds, then value equals the result of applying observedMeasure.measure.accumulator to the set of values given by baseMeasurementTo.to.value.?. REPLACE the constraint in Constraints of Sub-clause 14.3 (DirectMeasurement Class) WITH the following constraint: context DirectMeasurement inv: observedMeasure.measure.oclIsTypeOf (DirectMeasure) REPLACE the constraint in Constraints of Sub-clause 14.4 (Count Class) (CountingMeasurement Class in the revised specification) WITH the following constraint, which overlaps with the resolution of issue 19608: context CountingMeasurement inv: observedMeasure.measure.oclIsTypeOf (CountingMeasure) REPLACE the constraint in Constraints of Sub-clause 14.5 (BinaryMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 17472, 19426 and 19456: context BinaryMeasurement inv: observedMeasure.measure.oclIsTypeOf(BinaryMeasure) and isBaseSupplied ? (not baseMeasurement1To.isEmpty and not baseMeasurement2To.isEmpty and (not baseMeasurement1To.isEmpty ? (baseMeasurement1To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure1To.to)) and (not baseMeasurement2To.isEmpty ? (baseMeasurement2To.to.observedMeasure.measure = observedMeasure.measure.baseMeasure2To.to))) and baseQuery->isEmpty) and (not isBaseSupplied?baseMeasurement1To->isEmpty and baseMeasurement2To->isEmpty) REPLACE the sentence ?If isBaseSupplied holds, then value equals the result of applying measure.functor to baseMeasurement1.value and baseMeasurement2.value.? in Semantics of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?If isBaseSupplied holds, then value equals the result of applying observedMeasure.measure.functor to baseMeasurement1To.to.value and baseMeasurement2To.to.value.?, which text overlaps with the resolution of issue 19456. REPLACE the constraint in Constraints of Sub-clause 14.6 (RatioMeasurement Class) WITH the following constraint, which overlaps with the resolution of issue 19456: context RatioMeasurement inv: observedMeasure.measure.oclIsTypeOf(RatioMeasure) and isBaseSupplied ? (value = baseMeasurement1To.to.value / baseMeasurement2To.to.value) REPLACE the constraint in Constraints of Sub-clause 15.2 (NamedMeasurement Class) WITH the following constraint: context NamedMeasurement inv: observedMeasure.measure.oclIsTypeOf(NamedMeasure). REPLACE the constraint in Constraints of Sub-clause 15.3 (RescaledMeasurement Class) WITH the following constraint, which overlaps with the resolution of issues 17472 and 19456: context RescaledMeasurement inv: observedMeasure.measure.oclIsTypeOf(RescaledMeasure) and (isBaseSupplied ? not rescaleFrom->isEmpty and (rescaleFrom.from.observedMeasure.measure = observedMeasure.measure.rescaleFrom.from) and baseQuery->isEmpty) and (not isBaseSupplied ? rescaleFrom->isEmpty) REPLACE the sentence ?If isBaseSupplied is true then value equals result of applying measure.operation to the baseMeasurements? values.? in Semantics of Sub-clause 15.3 (RescaledMeasurement Class) WITH ?If isBaseSupplied is true then value equals result of applying observedMeasure.measure.operation to the rescaleFrom.from.value.?, which text overlaps with the resolution of issue 19456. Diagram changes, showing the revised Measurement Class: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
August 19, 2014: received issue
March 26, 2015: closed issue

Issue 19602: Remove ownedRelation assocation from SmmElement and SmmRelationship (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The containment association, ownedRelation, between SmmElement and SmmRelationship is inappropriate in that both are abstract classes and unnecessary in that it is defined already between the concrete extensions of SmmElement and SmmRelationship

Resolution: Remove the containment association between SmmElement and SmmRelationship
Revised Text: REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams), to show the result of removing the containment association.
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19603: ObservedMeasure should not extend SmmRelationship (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: ObservedMeasure should not extend SmmRelationship         The �from� and �to� properties of SmmRelationship is not appropriate to ObservedMeasure.   ObservedMeasure is a container (of measurements) for a measure and is not a relationship between a measurement and a measure.

Resolution: ObservedMeasure to extend SmmElement
Revised Text: REPLACE the Superclass of Sub-clause 16.4 (ObservedMeasure Class) WITH the Class ?SmmElement?. REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams), to show the revised ObservedMeasure Class.
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19604: Remove the TimeStamp primitive type (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: Remove the TimeStamp primitive type         The TimeStamp primitive type is not used at any point in SMM and it should be, consequentially, be removed.

Resolution: Discussion: Superseded by issue 19704. Disposition: Closed, no change
Revised Text:
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue; Closed; No Change
July 8, 2015: closed issue

Issue 19605: An Operation should be reusable as the operation of multiple measures (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: An Operation should be reusable as the operation of multiple measures         DirectMeasure may have an operation association with an Operation.   That operation could be re-used by other measures as their operation which means to multiplicity should not be 1 for the unnamed role, but should be 0 to many.         BinaryMeasure, similarly, may have a customFunctor association with an Operation as may a CollectiveMeasure have a customAccumulator association with an Operation.    The operations could be re-used by other measures which means to multiplicity should not be 1 for the unnamed role, but should be 0 to many.

Resolution: Change multiplicity to 0..* for associated Operation as shown in Figures 5,6 and 7.
Revised Text: Diagram changes, showing the now correct multiplicity of association ends, opposite of Operation: � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19606: The Percentage measure(ment) has been replaced by the RatioMeasure(ment) (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: The Percentage measure(ment) has been replaced by the RatioMeasure(ment)         The old name, Percentage, still appears in 2 places in the document.          The first reference is in the Measurement Class clause.   It should be removed entirely.   Percentage has been replaced by RatioMeasurement which is a subclass of DimensionalMeasurement.   Hence, the phrase �The DimensionalMeasurement and Percentage subclasses� simplifies to �The DimensionalMeasurement subclass�.         The second reference is in Software Engineering Institute (SEI) Maintainability Index clause.   The PercentageMeasure should be replaced with RatioMeasure.

Resolution: Simplify the phrase ?The DimensionalMeasurement and Percentage subclasses? in the text of the sub-clause of Measurement Class to ?The DimensionalMeasurement subclass?. Note: The part about the second reference is actually resolved by issue 19609, which removed the problematic text.
Revised Text: REPLACE the sentence ?The DimensionalMeasurement and Percentage subclasses of Measurement defined below have numeric values.? In Sub-clause 13.2 (Measurement Class) WITH the following sentence: ?The DimensionalMeasurement subclass of Measurement, as defined below, has a numeric value.?.
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19607: SMM confuses "To" and "From" (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: SMM confuses "To" and "From"         There are two points of inconvenience (or even confusion ?) related to measure(ment) relationship:         1) Consider RescaledMeasure(ment) ("RSC") on one hand and BinaryMeasure(ment) ("BIN"), CollectiveMeasure(ment) ("COL"), RankingMeasure(ment) ("RNK") and GradeMeasure(ment) ("GRD") on the other hand.    They all aggregate "from" (?) a DimensionalMeasure(ment) ("DIM").    However, RSC looks to DIM as "from", whereas BIN, COL, RNK and GRD all look at DIM as "to".    Isn't that confusing ? Is it inconsistent ? Or is there a good reason for it ?          2) When I think of aggregating from DIM (regardless of whether I do that by rescaling, or binary functor or accumulation or grading or ranking), I always think from aggregating "from" a DIM and "to" an aggregated one (RSC, BIN, COL, RNK, GRD).          The �from� association of all SmmRelationship is defined as the origin element and the �to� association is defined as the target element which implies that the associations between BIN, COL, RNK and GRD to  DIM are backwards.    The �from� should in each case be the DIM measure(ment)s and the �to� should be the aggregating measure(ment)s.

Resolution: Defer changes of "To" and "From" in MeasureRelationships Further discussion learned that there might be good reasons why SMM 1.0 did it the way it was done, and that the deviating ?from/to? naming of RescaledMeasure maybe on purpose. As the final conclusion of this was not reached yet, and as changing this would have quite some impact, it was decided to defer to issue.
Revised Text:
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue
April 28, 2015: Deferred

Discussion:

Further discussion learned that there might be good reasons why SMM 1.0 did it the way it was done, and that the deviating �from/to� naming of RescaledMeasure maybe on purpose. As the final conclusion of this was not reached yet, and as changing this would have quite some impact, it was decided to defer to issue.  Disposition:	Deferred

Issue 19608: Old measure(ment) names still persist in the document (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add a new issue of the SMM RTF: Old measure(ment) names still persist in the document         The naming scheme for some measure and measurement classes is not consistent.         For most measures and their corresponding measurement classes if the measure class is �X�Measure then the measurement class is �X�Measurement.   This scheme is followed for all but the Counting measure class and its corresponding Count measurement class.   Each should be renamed to CountingMeasure and CountingMeasurement respectively.         Also, in places the �X�Measure or �X�Measurement is shortened to just �X�.   For example in the specification sometimes Ratio is used, and sometimes RatioMeasure.  Even the class's section is called "Ratio Class" .. It should be RatioMeasure consistently.         Regarding Grade: It is, consistently and correctly, GradeMeasure in the model, and often in the document. But not always. There are occurrences in the document where you use Grade, and where it better should be GradeMeasure (or GradeMeasurement, if it is about the measurement side). Sometimes there is just qualitative speak where you can leave it like "grade", but sometimes it is meant as more formal, where it still reads as "grade", e.g. somewhere you talk "grade subclass" (should be GradeMeasure), and sometimes "Grade measure", which should be GradeMeasure, etc. Maybe you find all "grade" occurrences and fix some of them. The same problem might exist wrt Ranking.

Resolution: Replace "Ratio" as name of the ratio measure class with "RatioMeasure". Similarly, replace ?Counting? with ?CountingMeasure? and ?Count? with ?CountingMeasurement?. The naming consistency problem regarding ?Grade? has been fixed by the resolution of issue 17535.
Revised Text: REPLACE the sentence ?These measures are modeled by the Ratio class.? in Sub-clause 10.1 (General) WITH the following sentence: ?These measures are modeled by the RatioMeasure class.?. REPLACE ?Counting? WITH ?CountingMeasure? in the heading of Sub-clause 11.5 (Counting Class) (Sub-clause 11.6 (CountingMeasure Class) in the revised specification). REPLACE the sentence ?Counting is a subclass of DirectMeasure where the given operation returns 0 or 1 based upon recognizing the measured entity.? in Sub-clause 11.5 (Counting Class) (Sub-clause 11.6 (CountingMeasure Class) in the revised specification) WITH the sentence ?CountingMeasure is a subclass of DirectMeasure where the given operation returns 0 or 1 based upon recognizing the measured entity.?. REPLACE the constraint in Constraints of Sub-clause 11.5 (Counting Class) (Sub-clause 11.6 (CountingMeasure Class) in the revised specification) WITH the following constraint: context CountingMeasure::self.operation(�):int post: result = 0 or result = 1 REPLACE ?Ratio? WITH ?RatioMeasure? in the heading of Sub-clause 11.7 (Ratio Class) (Sub-clause 11.8 (RatioMeasure Class) in the revised specification). REPLACE the sentence ?A ratio measure and its two base measures frequently characterize three different traits of the same entity.? in Sub-clause 11.7 (Ratio Class) (Sub-clause 11.8 (RatioMeasure Class) in the revised specification) WITH the following sentence: ?A RatioMeasure and its two base measures frequently characterize three different traits of the same entity.?. REPLACE ?Count? WITH ?CountingMeasurement? in the heading of Sub-clause 14.4 (Count Class). REPLACE the constraint in Constraints of Sub-clause 14.4 (Count Class) (CountingMeasurement Class in the revised specification) WITH the following constraint, which overlaps with the resolution of issue 19583: context CountingMeasurement inv: observedMeasure.measure.oclIsTypeOf (CountingMeasure) REPLACE the sentence ?The RatioMeasurement class affords evaluations of a ratio measure of two evaluations of different dimensional measures.? in Sub-clause 14.6 (RatioMeasurement Class) WITH the following sentence: ?The RatioMeasurement class affords evaluations of a RatioMeasure of two evaluations of different dimensional measures.?. REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams), to show the renaming of Counting to CountingMeasure. REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams), to show the renaming of Count to CountingMeasurement.
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19609: Remove non-normative Library of Measures clause (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: Remove non-normative Library of Measures clause         The non-normative Library of Measures clause is out-of-date with respect to SMM.   It is too focused upon examples of software measures which is confusing now that SMM is applicable outside of software measurement.   Also the clause contains no MeasureLibrary, CategoryRelationship or MeasureCategory elements and, thus, is not a demonstration of a library of measures.          The non-normative Library of Measures clause should be removed.

Resolution: Remove both non-normative Library of Measures clause and the non-normative Library of Categories clause. This resolution also covers what is requested for issue 19451, namely to make non-normative Measure examples that remain, compliant with the revised meta-model
Revised Text: see pages 102 - 105 of ptc/2015-03-06 for details
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19610: Provide some non-software non-normative measure examples (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please add another issue to the SMM RTF: Provide non-software non-normative measure examples         SMM should provide a few non-normative example measures especially non-software examples.   The SEI maintainability measure could be up-dated as a software example and a few non-software examples added.

Resolution: Add a new clause for non-normative examples which should include SEI maintainability and some business examples.
Revised Text: see pages 106 - 113 of ptc/2015-03-06 for details
Actions taken:
September 18, 2014: received issue
March 26, 2015: closed issue

Issue 19643: Minimum and maximum attributes for the Interval class should be optional (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Minimum and maximum attributes for the Interval class should be optional         For nominal or for ordinal the base measure and interval mapping are not needed.  To make that more convenient, I propose to make the following changes.         1.        The minimum and maximum attributes for the Interval class will be optional         Attributes  maximumOpen:Boolean   True if and only if interval excludes maximum endpoint. Default = false.     minimumOpen:Boolean   True if and only if interval excludes minimum endpoint. Default = false.     maximum:Number[0..1]   Identifies interval�s maximum endpoint.     minimum:Number[0..1]   Identifies interval�s minimum endpoint.            2.       We add constraints to Interval indicating that if either minimum or maximum is defined then both are defined.    Constraints  context Interval inv:    if maximum.isOclDefined     then minimum.isOclDefined and maximum = minimum and         (maximumOpen or minimumOpen ? maximum > minimum)    else not minimum.isOclDefined         3.       We add constraints to RankingInterval requiring a maximum (and implicitly a minimum).    Constraints  context RankingInterval inv:    maximum.isOclDefined              4.       We add constraints to GradeMeasure forbidding the intervals without minimum or maximums if gradeTo is specified.    Constraints  context GradeMeasure inv:    (gradeTo->notEmpty implies         interval->forall(i | not i.minimum.isOclUndefined() and                              not i.maximum.isOclUndefined())) and    (interval->exists(i | i.minimum.isOclUndefined() or                           i.maximum.isOclUndefined()) implies        gradeTo->isEmpty)

Resolution: (1) The minimum and maximum attributes for the Interval class will be optional. (2) Add constraints to Interval indicating that if either minimum or maximum is defined then both are defined. (3) Add constraints to RankingInterval requiring a maximum (and implicitly a minimum). (4) Add constraints to GradeMeasure forbidding the intervals without minimum or maximum if gradeTo is specified.
Revised Text: ADD the following constraint, under a new heading ?Constraints? TO Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification): context GradeMeasure inv: (gradeTo->notEmpty implies interval->forall(i | not i.minimum.isOclUndefined() and not i.maximum.isOclUndefined())) and (interval->exists(i | i.minimum.isOclUndefined() or i.maximum.isOclUndefined()) implies gradeTo->isEmpty) ADD multiplicity ?[0..1]? TO attributes ?maximum? and ?minimum? in the Attributes table of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification). REPLACE the constraint in Constraints of Sub-clause 10.14 (RankingInterval Class) (Sub-clause 10.15 (Interval Class) in the revised specification) WITH the following constraint: context Interval inv: if maximum.isOclDefined then minimum.isOclDefined and maximum = minimum and (maximumOpen or minimumOpen ? maximum > minimum) else not minimum.isOclDefined ADD the following constraint, under a new heading ?Constraints? TO Sub-clause 10.19 (RankingInterval Class, which Sub-clause was introduced via resolution of issue 17535): context RankingInterval inv: maximum.isOclDefined REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams), to show the revised Interval Class.
Actions taken:
October 16, 2014: received issue
March 26, 2015: closed issue

Issue 19646: Generalize Scope to include stereotypes (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotypes, like classes, define sets of objects which can be measured and should be allowed as a way to define the scope of a measure.

Resolution: Add optional stereotype attribute to Scope class. Make its class attribute optional. Add a constraint to allow the scope to be specified by either the class or the stereotype attribute. Add text in the semantics class about stereotype specifying the scope of a measure.
Revised Text: ADD sentence ?The class or stereotype attributes and recognizer association provide for the formal specification of a measure?s scope.? TO Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification). ADD the following attribute TO the Attributes table of Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): stereotype:UML::Stereotype [0..1] Specifies the stereotype for elements of the set. See Semantics. ADD the following constraint, which overlaps with the resolution of issue 17469, TO Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): context Scope inv: (class->isEmpty and stereotype->isEmpty implies (!name->isEmpty and !description->isEmpty)) and ((name->isEmpty or description->isEmpty) implies !class->isEmpty or !stereotype->isEmpty) ADD the following sentence, which overlaps with the resolution of issue 17469, TO Semantics of Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): ?The scope is formally specified by the class or stereotype attributes or is informally specified by name and description attributes.? ADD the following sentence TO Semantics of Sub-clause 10.3 (Scope Class) (this is Sub-clause 10.4 in the revised specification): ?The stereotype attribute can be used, instead of the class attribute, to indicate that the scope is the members of the classes extended by the stereotype.? ADD the following text, which overlaps with the resolution of issues 17469 and 17470, TO Semantics of Sub-clause 13.2 (Measurement Class): ?If measure.scope.stereotype is specified then measurand must be an instance of Element (CMOF) named in measure.scope.stereotype. If neither measure.scope.class nor measure.scope.stereotype is specified, then measurand should match the description specified in measure.scope.description.? Diagram changes, showing the revised Scope Class: � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
October 23, 2014: received issue
March 26, 2015: closed issue

Issue 19704: Apply Timestamp instead of Date and remove Date (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

SMM 1.0 had both Date (sub-clause 8.8) and Timestamp (sub-clause 8.9) defined. Timestamp was nowhere used as type. Hence, in a previous ballot, we asked to vote for removing Timestamp (per issue 19604, “Remove the TimeStamp primitive type”). Meanwhile we encountered that Date was only used inconsistently. The meta-model diagrams showed Date as type of Observation.whenObserved, but the attributes table in sub-clause 16.2 just specified "date" (small) as type for that attribute. This is obviously wrong and has to be fixed. But this triggered new discussion, that resulted to the conclusion that Observation.whenObserved should not be typed by Date at all, but rather by TimeStamp, because SMM should enable taking snapshots or samples multiple times a day, and not just once a day. (Another reason why this error is only detected so late is the fact that in the SMM implementation of one of the implementers Date was mapped to java.util.Date which is actually a datetime type ...) � Resolution: Change type of Observation.whenObserved from Date to TimeStamp. Update the attributes table in sub-clause 16.2, as well as all diagrams on which the attribute is exposed, accordingly. Remove Date (sub-clause 8.8), as it will no longer be used then. This issue will then also supersede issue 19604 (“Remove the TimeStamp primitive type”). It will also partly supersede the older issue 15479 (“it should be made clear that Date and Timestamp are PrimitiveTypes”). This issue will still impact the Timestamp class, but no longer the Date class, as it will now be removed.�

Resolution: Change type of Observation.whenObserved from Date to TimeStamp. Update the attributes table in Sub-clause 16.2, as well as all diagrams on which the attribute is exposed, accordingly. Remove Date (sub-clause 8.8), as it will no longer be used then. This issue will then also supersede issue 19604 (Remove the TimeStamp primitive type). It will also partly supersede the older issue 15479 (it should be made clear that Date and Timestamp are PrimitiveTypes). This issue will still impact the Timestamp class, but no longer the Date class, as it will now be removed. Also make the mapping of TimeStamp to dateTime in XSD explicit in the XMI.
Revised Text: REMOVE Sub-clause 8.8 (Date) FROM the specification. REPLACE the type of attribute ?whenObserved? in the first column of the first row of the Attributes table of Sub-clause 16.2 (Observation Class) WITH type ?TimeStamp?. Diagram changes, showing the revised Observation Class: � REPLACE the diagram of Figure 1 WITH the diagram of Figure a: Replacement meta-model diagram for Figure 1 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 15 WITH the diagram of Figure l: Replacement meta-model diagram for Figure 15 (see Annex A: Revised Meta-model Diagrams). ADD a MOF tag TO the XMI to specify that the XML schema type for the SMM TimeStamp primitive is dateTime.
Actions taken:
January 15, 2015: received issue
March 26, 2015: closed issue

Issue 19711: Some Associations and Roles do not have names in SMM (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Association from MeasureCategory to MeasureCategory did not have a name.  The ends did have names.  Named it HasSubCategory.   The name is not visible in any diagram and does not appear in the doc.    The HasCategories association from MeasureLibrary to CategoryRelationship had one unnamed end.   Named it libraries.  The end is owned by the association.  The name is not visible in any diagram and does not appear in the doc.  The following association end is private, whereas it must be public: in the RescaledMeasure � Operation association, the end of RescaledMeasure (rescalesFor)".

Resolution: Name association from MeasureLibrary to MeasureLibrary as ?HasSubCategory?. Name the unnamed end of the HasCategories association from MeasureLibrary to CategoryRelationship as ?libraries?. Change visibility of the rescalesFor end of the association between RescaledMeasure and Operation from private to public. These changes impact the XMI only.
Revised Text: ADD ?HasSubCategory? as name, in the XMI, TO the unnamed association from MeasureLibrary to MeasureLibrary. ADD ?libraries? as name, in the XMI, TO the unnamed end of the HasCategories association from MeasureLibrary to CategoryRelationship. REPLACE visibility ?private? WITH visibility ?public?, in the XMI, for the rescalesFor end of the association between RescaledMeasure and Operation.
Actions taken:
January 19, 2015: received issue
March 26, 2015: closed issue

Issue 19712: Incorrect types for associations of BinaryMeasure (smm-rtf)

Click here for this issue's archive.
Source: Micro Focus (Mr. Larry M. Hines, PhD, larry.hines(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

The types of BinaryMeasure.baseMeasure1, BinaryMeasure.baseMeasure2 and BinaryMeasurement.baseMeasurement1To are wrong. The type should be a Measure(ment)Relationship class. Also, the descriptions of BinaryMeasure baseMeasure1, BinaryMeasure.baseMeasure2, BinaryMeasurement.baseMeasurement2 and CollectiveMeasurement.baseMeasurement are unclear

Resolution: In Attributes table of BinaryMeasure class: Change the type of BinaryMeasure.baseMeasure1 to Base1MeasureRelationship, and its description to ?Specifies the relationship instance that defines the first measure accumulated by this binary measure?. And change the type of BinaryMeasure.baseMeasure2 to Base2MeasureRelationship, and its description to ?Specifies the relationship instance that defines the second measure accumulated by this binary?. In Attributes table of BinaryMeasurement class: Change the type of BinaryMeasurement.baseMeasurement1 to Base1MeasurementRelationship, and its description to ?Specifies the relationship instance that defines the first base measurement accumulated for this measurement?. And change the type of BinaryMeasurement.baseMeasurement2 to Base2MeasurementRelationship, and its description to ?Specifies the relationship instance that defines the second base measurement accumulated for this measurement?. In Attributes table of CollectiveMeasurement class: Change the type of CollectiveMeasurement.baseMeasurement to BaseNMeasurementRelationship, and its description to ?Specifies the relationship instance that defines the accumulation for this measurement?.
Revised Text: REPLACE the type of the association end in the first column of the first row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?Base1MeasureRelationship?. REPLACE the description of the association end in the second column of the first row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?Specifies the relationship instance that defines the first measure accumulated by this binary measure.?. REPLACE the type of the association end in the first column of the second row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?Base2MeasureRelationship?. REPLACE the description of the association end in the second column of the second row in the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification) WITH ?Specifies the relationship instance that defines the second measure accumulated by this binary measure.?. REPLACE the type of the association end in the first column of the association in the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class) WITH ?BaseNMeasurementRelationship?. REPLACE the description of the association end in the second column of the association in the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class) WITH ?Specifies the relationship instance that defines the accumulation for this measurement.?. REPLACE the type of the association end in the first column of the first row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?Base1MeasurementRelationship?. REPLACE the description of the association end in the second column of the first row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?Specifies the relationship instance that defines the first base measurement accumulated for this measurement.?. REPLACE the type of the association end in the first column of the second row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?Base2MeasurementRelationship?. REPLACE the description of the association end in the second column of the second row in the Associations table of Sub-clause 14.5 (BinaryMeasurement Class) WITH ?Specifies the relationship instance that defines the second base measurement accumulated for this measurement.?.
Actions taken:
January 20, 2015: received issue
March 26, 2015: closed issue

Issue 19717: Redundant association in Associations table of RescaledMeasure (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The SMM spec, in the Associations table of the sub-clause that defines the RescaledMeasure class, two associations are defined: “baseMeasure” and “rescaleFrom”. The meta-model only declares one of them, namely “rescaleFrom”. The other one, “baseMeasure”, is an oversight, and is redundant. It should be removed from the table. This issue supersedes issue 17478. The reason of this new issue, superseding issue 17478 is, that the resolution of 17478 also proposed a fix of the multiplicity of the association end of the other association (rescaleFrom), from [0..*] to [1], which was wrong.)          Resolution: Remove the "baseMeasure" association from the Associations table of the RescaledMeasure class. This resolution supersedes the resolution of issue 17478.

Resolution: Remove the "baseMeasure" association from the Associations table of the RescaledMeasure class.
Revised Text: REMOVE the ?baseMeasure? association FROM the Associations table (first row in that table) of Sub-clause 12.3 (RescaledMeasure Class).
Actions taken:
February 6, 2015: received issue
March 26, 2015: closed issue

Issue 19718: A RescaledMeasurement should not rescale more than one DimensionalMeasurement simultaneously (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Multiplicity of RescaledMeasurement.rescaleFrom is [0..*]. This is wrong. Because this would imply that it could rescale multiple DimensionalMeasurements simultaneously. It should be [0..1] therefore. This issue supersedes issue 17504. The reason is that issue 17504 suggested that the multiplicity of RescaledMeasure.rescaleFrom being [0..*] was also wrong and that it proposed to change it to [1] as well. That was wrong. Because the RescaledMeasure itself should be kept re-usable. But any application of it, i.e., a related RescaledMeasurement, should not rescale more than one DimensionalMeasurement.           Resolution: Change multiplicity of RescaledMeasurement.rescaleFrom from [0..*] to [0..1]. Note that this cannot be higher than 1 (for reasons explained in Summary). On the other hand, it should allow "0", to stay consistent with the semantics of the RescaledMeasurement.isBaseSupplied. Multiplicity of RescaledMeasure.rescaleFrom will also change, but from [0..*] to [1..*]. The “*” in this is to keep the possibility of reuse of a RescaledMeasure, and the “1” in this is to make it more consistent with other aggregating Measures, which all aggregate from [1] DimensionalMeasure (instead of [0..1]).�  This resolution supersedes the resolution of 17504.�

Resolution: Change multiplicity of RescaledMeasurement.rescaleFrom from [0..*] to [0..1]. Note that this cannot be higher than 1 (for reasons explained in Summary). On the other hand, it should allow "0", to stay consistent with the semantics of RescaledMeasurement.isBaseSupplied. Multiplicity of RescaledMeasure.rescaleFrom will also change, but from [0..*] to [1..*]. The ?*? in this is to keep the possibility of reuse of a RescaledMeasure, and the ?1? in this is to make it consistent with other aggregating Measures, which all aggregate from [1] DimensionalMeasure (instead of [0..1]).
Revised Text: REPLACE the multiplicity of the ?rescaleFrom? association end in the first column of the second row in the Associations table of Sub-clause 12.3 (RescaledMeasure Class) WITH [1..*]. REPLACE the multiplicity of the ?rescaleFrom? association end in the first column of the association in the Associations table of Sub-clause 15.3 (RescaledMeasurement Class) WITH [0..1]. REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams), to show the revised RescaledMeasure Class. REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams), to show the revised RescaledMeasurement Class.
Actions taken:
February 6, 2015: received issue
March 26, 2015: closed issue

Issue 19720: Base SMM on CMOF instead of EMOF (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

SMM 1.0 assumed EMOF, which is limited. CMOF should be used instead. This issue supersedes 15856, because that issue was earlier balloted with a resolution that was irrelevant to “EMOF versus CMOF” and even unwanted.

Resolution: Disposition: See issue 17212 for disposition
Revised Text:
Actions taken:
February 11, 2015: received issue
March 26, 2015: closed issue; Duplicate or Merged
July 8, 2015: closed issue

Issue 19721: Remove getters� of properties in the meta-model (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

“Getters” for properties in the meta-model are redundant and unnecessary. For example SmmRelationship::getFrom(). These operations should be removed. This issue supersedes 15476 (because that issue was balloted originally as “duplicate / merged”, suggesting that the removal of such “getters” was already done as part of migration to CMOF. But that does not make sense.)

Resolution: Remove Operations tables from Sub-clauses 8.2 and 8.4.
Revised Text: REMOVE Operations table FROM Sub-clause 8.2 (SmmElement Class). REMOVE Operations table FROM Sub-clause 8.4 (SmmRelationship Class). REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams), to show the revised SmmRelationship Class.
Actions taken:
February 11, 2015: received issue
March 26, 2015: closed issue

Issue 19722: Improve the definition of derived� properties (smm-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are three problems here: 1) Several derived unions (for from, to, inbound and outbound) are not defined correctly, e.g. at specialized level the properties where they are assumed to be derived from are not defined as their subsets. 2) They are defined as derived unions in the model, but not in the association tables in the specification, and 3) in the Association tables of Measure Class (10.5) and Measurement Class (13.1), the description of inbound and outbound both talk about the “to-endpoint”. But one of these two should be “from-endpoint”. This issue supersedes issue 15477 (because it was originally balloted with a resolution that was incorrect, as the actual problem was overlooked).�

Resolution: The properties that were so-far named ?outbound? and ?inbound?, of SmmElement and its specializations, should be derived unions (isDerivedUnion = true), but this requires that, the properties of specialized classes, from which they are derived, should be defined as subsets (subsettedProperty being set to the property that is the union). The ?derived union? will make it unambiguous how the derivation is done, and in combination with ?subsets? we apply it according to the UML rules. There is one problem in this: UML 2.4.1 (and still the same in UML 2.5) does not allow subsetting of property of same name. Hence we rename SmmRelationship.inbound and SmmRelationship.outbound to SmmRelationship.inRelationships and SmmRelationship.outRelationships respectively. Furthermore, to avoid that, at specialized level, classes Measure, Measurement, etc. have inherited property ?inRelationship? next to ?inbound? and ?outRelationship? next to ?outbound?, we define ?inbound? as ?redefines inRelationships? and ?outbound? as ?redefines outRelationships?. The properties ?to? and ?from? of SmmRelationship and its specializations are no longer derived. What is instead needed is that, at specialized levels, ?to? ?redefines? ?to? of a parent level, and ?from? ?redefines? ?from? of a parent level. This way we enforce that for any SmmRelationship there?s always exactly one ?to? and one ?from?. The changes implied here will impact both the model (and its diagrams) and the association tables in the corresponding sub-clauses of the specification. Furthermore, in the Association tables of Measure Class (10.5) and Measurement Class (13.1), the description of inbound and outbound both talk about the ?to-endpoint?. But for outbound it should be the ?from-endpoint?.
Revised Text: REMOVE the sentence ?This property is a derived union.? FROM the description (second column) of both rows of the Associations table of Sub-clause 8.4 (SmmRelationship Class). ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 8.7 (CategoryRelationship): ?This property redefines the from-endpoint of SmmRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 8.7 (CategoryRelationship): ?This property redefines the to-endpoint of SmmRelationship.?. ADD the following sentence TO the description of the ?equivalentFrom? association end in the second column of the third row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?equivalentTo? association end in the second column of the fourth row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?refinementFrom? association end in the second column of the fifth row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?refinementTo? association end in the second column of the sixth row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification): ?This property subsets the outbound property of Measure.?. ADD ?/? TO ?inbound?(so that it shows as ?/inbound?) in the first column of the ?inbound? association end (11th row) in the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification), to indicate that the property is derived. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?inbound? association end, in the second column of the 11th row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification) WITH the following sentence: ?This property is a derived union, subsets inRelationships and redefines inRelationships of SmmElement.?. ADD ?/? TO ?outbound?(so that it shows as ?/outbound?) in the first column of the ?outbound? association end (12th row) in the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification), to indicate that the property is derived. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?outbound? association end, in the second column of the 12th row of the Associations table of Sub-clause 10.4 (Measure Class) (Sub-clause 10.5 in the revised specification) WITH the following sentence: ?This property is a derived union, subsets outRelationships and redefines outRelationships of SmmElement.?. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?from? association end, in the second column of the first row of the Associations table of Sub-clause 10.7 (MeasureRelationship Class) (Sub-clause 10.9 in the revised specification) WITH the following sentence: ?This property redefines the from-endpoint of SmmRelationship.?. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?to? association end, in the second column of the second row of the Associations table of Sub-clause 10.7 (MeasureRelationship Class) (Sub-clause 10.9 in the revised specification) WITH the following sentence: ?This property redefines the to-endpoint of SmmRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 10.8 (EquivalentMeasureRelationship Class) (Sub-clause 10.10 in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 10.8 (EquivalentMeasureRelationship Class) (Sub-clause 10.10 in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 10.9 (RefinementMeasureRelationship Class) (Sub-clause 10.11 in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 10.9 (RefinementMeasureRelationship Class) (Sub-clause 10.11 in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?rankingFrom? association end in the second column of the first row of the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description (second column) of the ?gradeFrom? association end in Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification), which association end has been added as part of the resolution of issue 17535: ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?baseMeasureFrom? association end in the second column of the second row of the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?baseMeasure1From? association end in the second column of the third row of the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?baseMeasure2From? association end in the second column of the fourth row of the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?rescaleTo? association end in the second column of the fifth row of the Associations table of Sub-clause 10.11 (DimensionalMeasure Class) (Sub-clause 10.12 in the revised specification): ?This property subsets the inbound property of Measure.?. ADD the following sentence TO the description of the ?rankingTo? association end, which is renamed into ?gradeTo? by the resolution of issue 17535, in the second column of the first row of the Associations table of Sub-clause 10.12 (Ranking Class) (Sub-clause 10.13 (GradeMeasure Class) in the revised specification): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 10.13 (RankingMeasureRelationship) (Sub-clause 10.14 (GradeMeasureRelationship Class) in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 10.13 (RankingMeasureRelationship) (Sub-clause 10.14 (GradeMeasureRelationship Class) in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the new Associations table of the new Sub-clause 10.18 (RankingMeasureRelationship Class), which Sub-clause has been added by resolution of issue 17535: ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the new Associations table of the new Sub-clause 10.18 (RankingMeasureRelationship Class), which Sub-clause has been added by resolution of issue 17535: ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?baseMeasureTo? association end in the second column of the first row of the Associations table of Sub-clause 11.2 (CollectiveMeasure Class): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?baseMeasure1? association end, which association end is renamed into ?baseMeasure1To? by resolution of issue 17480, in the second column of the first row of the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?baseMeasure2? association end, which association end is renamed into ?baseMeasure2To? by resolution of issue 17480, in the second column of the second row of the Associations table of Sub-clause 11.6 (BinaryMeasure Class) (Sub-clause 11.7 in the revised specification): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 11.8 (BaseMeasureRelationship Class) (Sub-clause 11.10 (BaseNMeasureRelationship Class) in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 11.8 (BaseMeasureRelationship Class) (Sub-clause 11.10 (BaseNMeasureRelationship Class) in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 11.9 (Base1MeasureRelationship Class) (Sub-clause 11.11 in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 11.9 (Base1MeasureRelationship Class) (Sub-clause 11.11 in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 11.10 (Base2MeasureRelationship Class) (Sub-clause 11.12 in the revised specification): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 11.10 (Base2MeasureRelationship Class) (Sub-clause 11.12 in the revised specification): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?rescaleFrom? association end in the second column of the second row of the Associations table of Sub-clause 12.3 (RescaledMeasure Class): ?This property subsets the outbound property of Measure.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 12.4 (RescaledMeasureRelationship Class): ?This property redefines the from-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 12.4 (RescaledMeasureRelationship Class): ?This property redefines the to-endpoint of MeasureRelationship.?. ADD the following sentence TO the description of the ?equivalentFrom? association end in the second column of the second row of the Associations table of Sub-clause 13.2 (Measurement Class): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?equivalentTo? association end in the second column of the third row of the Associations table of Sub-clause 13.2 (Measurement Class): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?refinementFrom? association end in the second column of the fourth row of the Associations table of Sub-clause 13.2 (Measurement Class): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?refinementTo? association end in the second column of the fifth row of the Associations table of Sub-clause 13.2 (Measurement Class): ?This property subsets the outbound property of Measurement.?. ADD ?/? TO ?inbound?(so that it shows as ?/inbound?) in the first column of the ?inbound? association end (eighth row) in the Associations table of Sub-clause 13.2 (Measurement Class), to indicate that the property is derived. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?inbound? association end, in the second column of the eighth row of the Associations table of Sub-clause 13.2 (Measurement Class) WITH the following sentence: ?This property is a derived union, subsets inRelationships and redefines inRelationships of SmmElement.?. ADD ?/? TO ?outbound?(so that it shows as ?/outbound?) in the first column of the ?outbound? association end (ninth row) in the Associations table of Sub-clause 13.2 (Measurement Class), to indicate that the property is derived. REPLACE the sentence ?This property is a derived union.?, as part of the description of the ?outbound? association end, in the second column of the ninth row of the Associations table of Sub-clause 13.2 (Measurement Class) WITH the following sentence: ?This property is a derived union, subsets outRelationships and redefines outRelationships of SmmElement.?. ADD the following text TO Sub-clause 13.3 (MeasurementRelationship Class): Associations from:Measurement [1] Specifies the measurement at the from-endpoint of the relationship. This property redefines the from-endpoint of SmmRelationship. to:Measurement [1] Specifies the measurement at the to-endpoint of the relationship. This property redefines the to-endpoint of SmmRelationship. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 13.4 (EquivalentMeasurementRelationship): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 13.4 (EquivalentMeasurementRelationship): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 13.5 (RefinementMeasurementRelationship): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 13.5 (RefinementMeasurementRelationship): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?rankingFrom? association end, which is renamed into ?gradeFrom? by the resolution of issue 17535, in the second column of the first row of the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description (second column) of the ?rankingFrom? association end in Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification), which association end has been added as part of the resolution of issue 17535: ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?baseMeasurementFrom? association end in the second column of the second row of the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?baseMeasurement1From? association end in the second column of the third row of the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?baseMeasurement2From? association end in the second column of the fourth row of the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?rescaleTo? association end in the second column of the fifth row of the Associations table of Sub-clause 13.7 (DimensionalMeasurement Class) (Sub-clause 13.6 in the revised specification): ?This property subsets the inbound property of Measurement.?. ADD the following sentence TO the description of the ?rankingTo? association end, which is renamed into ?gradeTo? by the resolution of issue 17535, in the second column of the association in the Associations table of Sub-clause 13.8 (Grade Class) (Sub-clause 13.7 (GradeMeasurement Class) in the revised specification): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 13.9 (RankingMeasurementRelationship Class) (Sub-clause 13.8 (GradeMeasurementRelationship Class) in the revised specification): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 13.9 (RankingMeasurementRelationship Class) (Sub-clause 13.8 (GradeMeasurementRelationship Class) in the revised specification): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description (second column) of the ?rankingTo? association end in Associations table of Sub-clause 13.9 (RankingMeasurement Class), which Sub-clause has been added as part of the resolution of issue 17535: ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 13.10 (RankingMeasurementRelationship Class), which Sub-clause has been added as part of the resolution of issue 17535: ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 13.10 (RankingMeasurementRelationship Class), which Sub-clause has been added as part of the resolution of issue 17535: ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?baseMeasurement? association end, which is renamed into ?baseMeasurementTo? by the resolution of issue 17480, in the second column of the Associations table of Sub-clause 14.2 (CollectiveMeasurement Class): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?baseMeasurement1? association end, which is renamed into ?baseMeasurement1To? by the resolution of issue 17480, in the second column of first row of the Associations table of Sub-clause 14.5 (BinaryMeasurement Class): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?baseMeasurement2? association end, which is renamed into ?baseMeasurement2To? by the resolution of issue 17480, in the second column of second row of the Associations table of Sub-clause 14.5 (BinaryMeasurement Class): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 14.7 (BaseMeasurementRelationship Class) (Sub-clause 14.8 (BaseNMeasurementRelationship Class) in the revised specification): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 14.7 (BaseMeasurementRelationship Class) (Sub-clause 14.8 (BaseNMeasurementRelationship Class) in the revised specification): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 14.8 (Base1MeasurementRelationship Class) (Sub-clause 14.9 in the revised specification): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 14.8 (Base1MeasurementRelationship Class) (Sub-clause 14.9 in the revised specification): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 14.9 (Base2MeasurementRelationship Class) (Sub-clause 14.10 in the revised specification): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 14.9 (Base2MeasurementRelationship Class) (Sub-clause 14.10 in the revised specification): ?This property redefines the to-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?rescaleFrom? association end in the second column of the association in the Associations table of Sub-clause 15.3 (RescaledMeasurement Class): ?This property subsets the outbound property of Measurement.?. ADD the following sentence TO the description of the ?from? association end in the second column of the first row of the Associations table of Sub-clause 15.4 (RescaledMeasurementRelationship Class): ?This property redefines the from-endpoint of MeasurementRelationship.?. ADD the following sentence TO the description of the ?to? association end in the second column of the second row of the Associations table of Sub-clause 15.4 (RescaledMeasurementRelationship Class): ?This property redefines the to-endpoint of MeasurementRelationship.?. Diagram changes, showing revised property definitions (related to derived unions, sub-setting and redefinition): � REPLACE the diagram of Figure 2 WITH the diagram of Figure b: Replacement meta-model diagram for Figure 2 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 3 WITH the diagram of Figure c: Replacement meta-model diagram for Figure 3 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 5 WITH the diagram of Figure e: Replacement meta-model diagram for Figure 5 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 6 WITH the diagram of Figure f: Replacement meta-model diagram for Figure 6 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 7 WITH the diagram of Figure g: Replacement meta-model diagram for Figure 7 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 10 WITH the diagram of Figure h: Replacement meta-model diagram for Figure 10 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 11 WITH the diagram of Figure i: Replacement meta-model diagram for Figure 11 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 13 WITH the diagram of Figure j: Replacement meta-model diagram for Figure 13 (see Annex A: Revised Meta-model Diagrams). � REPLACE the diagram of Figure 14 WITH the diagram of Figure k: Replacement meta-model diagram for Figure 14 (see Annex A: Revised Meta-model Diagrams).
Actions taken:
February 11, 2015: received issue
March 26, 2015: closed issue