8.7.7 Tips on Creating Metrics and Rules for Profile Extensions

• option 1: using regular model elements
• option 2: using extension references without inheritance
• option 3: using extension references with inheritance

• How often do you need to distinguish elements to which the stereotype is applied from elements of the same type to which the stereotype is not applied?

  If, for example, the distinction between SysML FlowPorts and plain UML ports is only relevant for a few of your metrics and rules, and you can treat them equally as plain UML ports most of the time, option 1 or 2 is appropriate.

• Do you need to identify the extension elements in the metric, rule, or relation matrix data tables?

  If so, you have to choose option 2 or 3.

• How much does the stereotype application change the "character" or "nature" of the extended model element?

  In case of SysML requirements, for example, the characteristic of the "class" element changes considerably. Unlike regular classes, requirements can't have operations or attributes, do not participate in associations, can't be generalized, and are usually not instantiated. They are actually not much like classes at all.

  In such situations, option 3 is appropriate, because it eliminates the "class" element representing the requirement from the model, and existing metrics and rules that involve classes will ignore the extended element.

• How important or central is the concept of the extension in the profile?

  Like requirements, a SysML block extends UML meta-class "class". Unlike requirements, however, SysML blocks maintain most of the class features from UML. Yet, as blocks are the central modular structure units of the SysML, the set of metrics and rules to calculate for blocks will probably be quite different from the set of class metrics and rules. Option 3 is therefore the best choice for the central concepts of the profile.

• How many meta-classes does the stereotype extend?

  If the stereotype extends two or more meta-classes (for example, SysML TestCase can extend "operation" or "behavior"), you can use option 3 for at most one of the extension, and must use option 1 or 2 for all others. This is because SDMetrics' metamodeling facility does not support multiple inheritance.

• inheritance of metric, set, and rule definitions to pass selected metrics, sets, and rules on to descended types (see e.g. Section 8.1 "Definition of Metrics" for metric inheritance)
• metrics or sets involving recursion or nesting extend their recursion to compatible super- and subclasses (see e.g. Section 8.1.1.8 "Attribute "recurse"")
• filtering for subtypes with the "target" and "eltype" filter attributes (see Section 8.1.1.3 "Filter Attribute "target"").
• new function "instanceof" (see Section 8.5.4.2 "Boolean Functions")

On the SDMetrics web site, you can download a set of project files for SysML 1.2, with metrics and rules that cover block definition diagrams, internal block diagrams, parametric diagrams, and requirement diagrams.