Embedding Defect and Traceability Information in CIM-
and PIM-Level Software Models
Jörg Rech and Mario Schmitt
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
+49 (0) 631 6800 2210, Joerg.Rech@iese.fraunhofer.de
+49 (0) 631 6800 2215, Mario.Schmitt@iese.fraunhofer.de
Abstract. Additional information about software models comes in different
forms such as defects detected, design patterns used, traceability information to
other abstraction levels, etc. In this paper, we present how additional informa-
tion about defects, context, traceability, etc. can be embedded into UML- and
BPMN-based PIM- and CIM-level software models. Furthermore, we present a
tool that uses the information about quality defects within a PIM to visualize
defects directly in the diagrams of a software model.
Keywords: Quality Defects, PIM, CIM, Traceability, Defect Annotation,
Traceability Annotation, Embedded Information, Software Models, MDSD
1 Introduction
Business users together with business analysts and architects generate the basic char-
acteristics of a software system that result in computation independent models (CIM),
including, e.g., role, product, or process models. In order to support the traceability of
elements and of decisions made on the CIM-level to the PIM-level as well as the
traceability of problems identified at the PIM-level to the CIM-level, we have to store
additional information about the software model along with the software model.
Additional information about elements in a software model such as a PIM or CIM
comes in different forms such as quality defects detected, patterns (roles) used, trace-
ability information to other abstraction levels, etc. This information is documented by
users or automated mechanisms and has to be visualized in standard or special views
of a modeling tool, made available to other systems for further analysis (e.g. impact
analyses), or persisted over a long period of time.
Kolovos et al. [7] differentiate between external and embedded traceability infor-
mation and decided on using an external approach. They argue against the embedded
approach (based on stereotypes), as it does not support inter-model relations, pollutes
the models, and degrades uniformity.
However, while several other options are possible beside stereotypes, storing addi-
tional complex information in a metamodel such as the UML [11] for PIM level is not
straightforward. An extension of the UML metamodel would result in non-standard
models that are not exchangeable between tools. Besides, in order to apply similar
mechanisms to models at different abstraction levels based on different (or previously
unknown) metamodels, we need a generic approach that can be easily adapted to and
complies with a broad range of metamodels.
In our context, the de-facto metamodel on the PIM level is UML [11], which is
built using the OMG’s Meta Object Facility (MOF) meta-metamodel. MOF is a com-
mon modeling language kernel providing a unified basis for all OMG metamodels.
On the CIM level, modeling focuses on business process modeling using mostly the
Business Process Modeling Notation BPMN [2] and the Business Process Definition
Metamodel BPDM [1]. While BPMN provides just a graphical notation for process
orchestration, BPDM is a CIM-level metamodel for business process modeling, using
BPMN as the graphical notation. Similar to UML, BPDM is based on the MOF [8]
meta-metamodel.
Several solutions to the abovementioned problem of embedding information into
software models are possible. In order to store the information in an Eclipse-based
IME for PIMs, such as Topcased [10], and for CIMs, such as the BPMN-Editor of the
SOA Tools Platform (STP) [4], we can persist information as:
• Markers/Properties in/of the software model that are managed and stored by the
tool, but cannot easily be shared between users or across a versioning system (e.g.,
CVS)
• MOF Tag, a construct in MOF that enables the multiple “tagging” of MOF model
elements with attribute-value pairs and can be shared across a versioning system,
• Comment, a construct of MOF and many other metamodels (e.g., “Text Annota-
tions” in BPMN) similar to MOF Tag for storing a single additional information
item (i.e., text field) per element, but, typically, is used for developer documenta-
tion,
• UML Profile/Stereotype, an extension mechanism in UML that can be used to
integrate additional elements into the UML. However, the information might be
confused with, domain-specific stereotypes for example and could flood the user
with too much information, not necessary in day-to-day work,
• External files, similar to diagram interchange [3] files in Topcased, which use a
semantic bridge to refer to elements of the software model(s). However, these files
need to be used by the tools at work in order to synchronize changes to the model
elements.
In order to enable the annotation of elements in a MOF-based software model, with
respect to providing easily synchronizable and versionable information, we selected
MOF Tags to persist information about defects detected, context factors, and trace-
ability information. Furthermore, the tagging mechanism allows embedding complex
information within a software model using an XML schema to describe and structure
the specific content for every specific annotation. The XML schema represents a
metamodel that allows us to define the substructures for the information on defects,
traceability, etc.
2 A Metamodel for Defect and Traceability Annotations
While traceability and context information has to be annotated manually (for now),
defects are identified by diagnostic mechanisms that analyze the system and find
2
typical recurring problems, that have a negative effect on internal quality aspects
(e.g., maintainability, portability, or usability).
The five types of defect-related embedded information are: Defect Annotations
(with information about the diagnosed quality defects), Context Annotations (with
context information on design patterns and roles applied or on special stereotypes,
used to differentiate the diagnosis), Decision Annotations (with decisions such as
“ignore” for individually diagnosed quality defects in case they are wrongly
diagnosed or not removable in this specific location), Symptom Annotations (with
information on the identified symptoms), and Treatment Annotations (which are used
to store the treatments applicable for removing the diagnosed quality defects).
Traceability information uses just one type of annotation (Trace Annotations) that
realizes traces from one element to one or more other elements (e.g., from one CIM
element to multiple PIM elements (downwards), from one PIM to multiple CIM ele-
ments (upwards), or from one PIM to multiple other PIM elements (sidewards)). Mul-
tiple types of references can be used between abstractions and within abstractions.
Furthermore, while single-location defects are enclosed within one abstraction at
one element, multi-location defects refer to other elements (resp. annotations) within
the same model, and all defects might refer to elements on another abstraction level to
document rationales for not removing a defect or to pinpoint a cause or (design) deci-
sion (e.g., in a CIM).
Figure 1 shows different aspects. On the OMG-specification-side (right), it outlines
the generic approach as proposed by MOF for annotating model elements with addi-
tional information (metainformation) using the Tag entity. It introduces the base
model elements of BPMN-based CIMs (BPDM::Element) and UML-based PIMs
(UML::Element) both deriving from MOF::Element, which acts as common model
element abstraction. Eclipse provides for these concepts either an OMG-conformant
implementation or analog concepts that can be easily mapped (center of Figure 1) to
OMG. For MOF, the element MOF::Element is mapped to the Ecore element
Ecore::EModelElement of the Eclipse Modeling Framework (EMF) and MOF::Tag is
mapped to Ecore::EAnnotation. Similarily, for CIM-modeling, the BPMN element
BPDM::Element is mapped to the SOA Tools Platform (STP) project object
STP::BPMN::NamedBpmnObjects. Finally, the element UML::Element of OMG’s
UML is implemented (as a one-to-one representation) by the Model Development
Tools (MDT) project’s UML2 MDT::UML2::Element.
Furthermore, Figure 1 presents an XML-based metamodel (left) for defect- and
traceability-oriented model metainformation and shows how actual metainformation
is embedded using the tagging mechanism/within annotations. A metamodel similar
to the traceability information metamodel is used by Feng et al. [6] for external trace-
ability models.
A model element may have multiple annotations (EAnnotations) associated with it,
each consisting of a source URI denoting an annotation’s type and an arbitrary num-
ber of key/value pairs. Following the structure of annotations, we bundle all model
metainformation in a single annotation element, but internally distribute information
to multiple key/value pairs according to the information’s scope/type (e.g. «Traceab-
lity» or «Quality»). That is, key determines the type/scope of the XML-based metain-
formation assigned to value.
3
Figure 1 Metamodel for Quality and Traceability Information in CIM and PIM Models
Figure 2 gives a simplified, exemplary XMI serialization of a UML-based PIM
model with a model element annotated with quality information. Quality information
consists of quality model and defect detection information. According to the (non-
functional) requirements a software system has to meet, a quality model defines and
prioritizes mandatory quality aspects and thus, is the basis for interpreting/verifying
the quality of a software model. In the context of VIDE-DD, determining the quality
of a software model focuses on detecting quality defects. A quality defect represents a
system-independent defect at one or more model elements with a negative impact on
certain quality aspects. Defects are diagnosed on the basis of one or more quantifiable
characteristics of a model or its model elements, so-called symptoms. The intensity
with which symptoms promote related defects differs and amongst other things,
largely depends on the characteristic’s deviation from previously defined threshold(s).
For removing a defect or mitigating a defect’s (negative) impact on certain quality
aspects, treatments refer to available techniques (e.g. refactorings). The exemplary
annotation in Figure 2 illustrates the concept of defect detection information: A Lazy
4
Class defect has been diagnosed for the PIM-level class Opportunity based on the
Number of Operations. Hence, a negative impact on the declared quality aspect Main-
tainability is expected, treatable by applying an Inline Class refactoring.
...
"/>
...
Figure 2 Serialization of Quality Information Annotation
Furthermore, we distinguish single- from multi-location defects [9]. A single-
location defect (e.g. Lazy Class) affects one model element (e.g., a class), whereas
5
multi-location defects apply to more than one element within the same model. For
example, a Shotgun Surgery defect is present when, due to strong coupling of classes,
a change in one class requires many subsequent changes in other classes. As each
concerned class is annotated with defect information, it is necessary to interrelate this
information, e.g. in order to elicit and apply adequate treatments. Thus, urlToDefects
(cf. Figure 1) allows for referencing related defects in other model elements.
A model element’s traceability information comprises one to many traces to ele-
ments, both at different and at same abstraction levels. As presented in Figure 3, the
key component of a trace is urlToElement for identifying related elements using a
URL reference. The URL syntax is a path to the containing model repository, fol-
lowed by a model identifier (the model’s name) and the XMI-id of the model element.
To qualify the relation of two elements linked by a trace, different types of references
can be assigned to a) traces between abstractions, such as “realizes / is realized by”,
“refines / is refined by”, “specifies / is specified by“, “requires / is required by”, etc.
and b) traces within abstractions, such as “includes / is part of”, “verifies / is verified
by”, “defines / is defined by”, “constrains / is constrained by”, etc. (see [12] or [5]).
...