|Prev - Next - Down||SDMetrics - the UML design measurement tool|
<metric name="NumCls" domain="package"> <projection relation="context" target="class" /> </metric>Applied to our sample package with four requirements, this metric will include the class elements to represent the requirements in its class count. Depending on our measurement goals, this may not be what we want. We could of course adjust the definition of the metric to only count classes that do not represent requirements:
<metric name="NumClsExceptRequirements" domain="package"> <projection relation="context" target="class" condition="Reqmt=''"/> </metric>This approach is possible, but ugly. If we add support for SysML blocks or other types that also extend "class", we would need to adjust the definition of metric again to exclude classes representing blocks, etc.
To better deal with these issues, SDMetrics provides a mechanism to merge the extended element with its extending element to form a single model element that combines all the information from both elements. To enable this mechanism, we have to define the type of the extending element as a subtype of the extended element.
In our SysML requirements example, we therefore change the definition of type "requirement" by declaring its parent to be type "class":
<modelelement name="requirement" parent="class"> <attribute name="base" type="extref" /> <attribute name="text" /> <attribute name="reqid" /> </modelelement>If SDMetrics finds a model element of type t ("requirement" in our example) with an extension reference, and the type of the extended element is a supertype of t ("class" in our example), then SDMetrics will merge the two elements into one element of type t. The merged element copies all attribute values of the extended element, and the extended element is removed from the model. We are left with one element of type t that assumes the place of the extended element.
Applied to our sample model and XMI file, we end up with a model that contains four requirement elements, no classes, and maintains the expected containment hierarchy:
Model "Sample" Package "Specifications" Requirement "XZY" with Id "R1" Requirement "ABC" with Id "R2" Requirement "A" with Id "R2.1" Requirement "B" with Id "R2.2"The package "Specification" no longer contains elements of type "class", and metric NumCls will yield 0. Model element type "requirement" has become a full, first-class citizen. We can identify requirements simply by the type of the model element, the need for helper metrics is eliminated.
Using reference extensions with inheritance, it is very easy to define metrics that take more complex relationships into account. For example, the SysML defines a relationship "satisfy" to identify the model elements that fulfill a given requirement. The more elements are needed to satisfy a requirement, the more difficult the requirement will be to change. We are therefore going to define a metric that counts the number of elements that satisfy a requirement.
Technically, the SysML defines the "satisfy" relationship as a stereotype that extends the meta-class "abstraction". We therefore create a new model element type "satisfy" with an extension reference as a subtype of "abstraction" (see Appendix A.2 "Metamodel for UML 2.x"):
<modelelement name="satisfy" parent="abstraction"> <attribute name="base" type="extref" /> </modelelement>The type "satisfy" inherits the multi-valued reference attributes "client" and "supplier" from "abstraction". For the XMI transformation, we only have to provide a trigger for the new extension reference "base":
<xmitransformation modelelement="satisfy" xmipattern="sysml:Satisfy"> <trigger name="base" type="attrval" attr="base_Abstraction" /> </xmitransformation>We can then define our metric to count the number of elements that satisfy a requirement:
<metric name="Satisfiers" domain="requirement" category="Coupling (export)"> <description>The number of elements that satisfy this requirement.</description> <projection relation="supplier" target="satisfy" sum="size(client)"/> </metric>
|Section 8.7.5 "Extension References without Inheritance"||Contents||Section 8.7.7 "Tips on Creating Metrics and Rules for Profile Extensions"|