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 information 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.
Introduction Business users together with business analysts and architects generate the basic characteristics 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, traceability 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. [
However, while several other options are possible beside stereotypes, storing
additional complex information in a metamodel such as the UML [
In our context, the de-facto metamodel on the PIM level is UML [
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 [
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 traceability 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 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 elements (upwards), or from one PIM to multiple other PIM elements (sidewards)). Multiple 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) decision (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 additional 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. [
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 number 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. «Traceablity» or «Quality»). That is, key determines the type/scope of the XML-based metainformation assigned to value.
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 (nonfunctional) 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 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 Maintainability is expected, treatable by applying an Inline Class refactoring.
Furthermore, we distinguish single- from multi-location defects [
A model element’s traceability information comprises one to many traces to
elements, 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,
followed 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 [
As generative model-driven development relies on model transformations between abstraction levels, the information about whether a trace creation or transition between two related elements has been carried out manually, semi-automatically, or automatically is of interest, e.g. for evaluating the quality of model transformations/model generators or for determining the overall level of automation. The XMI serialization of traceability information between an Opportunity data object at the CIM level and its implementation class at the PIM level is exemplified in Figure 3 (PIM-to-CIM) and Figure 4 (CIM-to-PIM). <bpmn:BpmnDiagram> ... <artifacts xmi:type="bpmn:DataObject" xmi:id="_TG7coT3iEd2hQ-HeytPXvA" name="Opportunity"> <eAnnotations source="http://www.iese.fraunhofer.de/ModelMetaInformation"> <details key="TraceabilityInformation" value=" <!-- BEGIN: Embedded Traceability Information XML-string --> <TraceabilityInformation> <Trace urlToElement="http://iese.fhg.de/SalesOpportunity_PIM.uml#_CyIsaF-fEdySHqlLXw_Tew" type="isRealizedBy" rationale="Implementation of Opportunity data object" traceCreation="automatic" transitionAutomation="automatic"/> </TraceabilityInformation> <!-- END: Embedded Traceability Information XML-string --> "/> </eAnnotations> </artifacts> ...
</bpmn:BpmnDiagram> Figure 4 Serialization of Traceability Information Annotation in CIM 3
Visualizing (Defect) Annotations in Modeling Environments
The information stored within the annotations can be used, for example, by the
diagram visualizer to enrich the standard UML diagrams with information about the
defects. As presented in Figure 5, the VIDE Defect Detector (VIDE-DD) extends the
Topcased modeling environment [
In the future, more tools for defect diagnosis and traceability support will be developed and integrated into software development tools that have to overcome the challenges of synchronization and versioning. This is especially important for tools on the model level, as these have to support quality assurance in and traceability between multiple software and transformation models.