CAPITULO III: DISEÑO Y CONSTRUCCIÓN DE LA TARJETA
3.3 Conectividad eléctrica del banco de electro dirección asistida
As already explained in Section 7.2 the traceability concept includes the linkage of ontology terms. Ontologies are semantic networks of related terms and can be uti- lized to connect terms of different artifacts of the development process. In this way an ontology can be utilized to provide the ability for modeling additional dependen- cies between different models of the goal-oriented design method. The ontology is only used to facilitate the explicit expression of dependencies and not for the com- plete representation of other design models. For example, an ontology can comprise terms, such as known quality goals, architectural principles, or solution instruments, and their dependencies. In the traceability concept of this thesis an ontology espe- cially is used to interrelate terms of the textual descriptions, for example, of factor tables and issue cards, with each other and with further model elements. This of course demands for the existence of an appropriate ontology. For this reason next to the activities of the goal-oriented design method an additional activity to model
an ontology was performed for the case study from Chapter 6.
For the establishment of an ontology several methods can be found in the litera- ture [UK95, GF95, BLC96, SPKR97, LGPSS99, SSSS01, NM01]. However, because ontology engineering is out of scope of this thesis a pragmatic approach to estab- lish an ontology was followed for the case study. The ontology was established in parallel to the other design activities. As a first step, the specifications of the dif- ferent artifacts (factor tables, issue cards, as well as the goal model) were manually scanned for terms that seemed to be of special importance for the case study sys- tem. Then, as a second step, these terms were modeled in an ontology with the Web Ontology Language (OWL) using the tool Protégé1. The knowledge integrated
in the ontology was structured akin to the architect’s toolbox. The ontology of the case study is depicted in Figure 7.5. It contains important architectural concerns, solution templates, such as patterns, as well as tools, quality goals, and terms of ba- sic hardware and software technology. The structuring according to the architect’s toolbox enables the reuse and extension of the ontology for other software projects. The benefits of the ontology integration in the traceability concept are: a) the facilitation of additional traceability links especially in combination with the hyper- text concept for textual descriptions and b) the possible treatment of synonyms or homonyms. For example, synonyms can be expressed as equivalent classes in the class hierarchy of terms in the ontology. The ontology also contains general design knowledge in form of relationships. For example, the influence of the patterns on certain quality goals can be expressed by object properties of the OWL classes. In this way relationship types as partOf or influencedBy can be modeled inside the ontology. The ontology of the case study can be found in OWL/XML syntax in Appendix B.2.
1
Tool Support by EMFTrace
This chapter describes a prototype tool called EMFTrace1, which is based on Eclipse Modeling Framework (EMF) technology. EMFTrace implements and supports the traceability concept introduced in Chapter 7. It provides capabilities to integrate the models of the goal-oriented architectural design method from Chapter 6 into a centralized repository for identifying dependencies between these models and record- ing them as traceability links. EMFTrace is accompanied by a tool called EMFfit, which allows to model factor tables and issue cards of the Global Analysis approach. Section 8.1 describes the requirements for EMFTrace and its core concept. Sec- tion 8.2 provides information about the architecture and its components and how EMFTrace together with EMFfit realizes the traceability concept. Section 8.3 goes more into detail regarding the technological aspects of the model integration. Sec- tion 8.4 describes a typical usage scenario for EMFTrace. Parts of the ideas of this chapter were already published in [BLR11].
8.1
Requirements and Core Concept
The goal of the tool support by EMFTrace is to implement this thesis’ concept for rule-based traceability in combination with information retrieval techniques and a centralized repository. EMFTrace shall provide comprehensive traceability for the artifacts of the goal-oriented design method with high values for precision and recall. It is conceived as an extensible platform enabling dependency analysis and trace- ability link establishment across model boundaries as well as goal-oriented decision
1
support as a basis for further analyses, such as change impact analysis, or validation and consistency checks. According to this some important functional requirements for EMFTrace were:
1. Integrate metamodels complying to URN, UML, OWL as well as for Global Analysis into the repository.
2. Enable the import of corresponding models from CASE tools into the reposi- tory via adapters to enable dependency analysis.
3. Provide export capabilities of the models out of the repository to enable their editing with the original CASE tools.
4. Enable to edit, store, and maintain traceability rules organized in catalogs in the repository with a separate metamodel.
5. Store and maintain traceability links in the repository with a separate meta- model.
6. Support the validation of traceability rules and their import into the repository. 7. Store and maintain traceability link types organized in a catalog in the repos-
itory.
8. Support (semi-) automatic traceability link establishment through processing traceability rules enhanced with information retrieval techniques.
9. Support the analyses of traceability links regarding transitivity to combine chains of links as traces.
Some quality requirements were to provide a flexible and extensible platform to support further research activities. Therefore, Eclipse was chosen as the basic tech- nology because its plug-in concept enables the easy exchange of certain components. The core concept of EMFTrace is illustrated in Figure 8.1. As the basic repos- itory for EMFTrace, EMFStore [KH10] was chosen because it was evaluated the most suitable, available model repository regarding criteria as maturity, supported features, usability, and documentation [BLR11, Leh10]. EMFStore is based on the Eclipse Modeling Framework (EMF) and provides capabilities for managing and versioning EMF-based models in a client-server fashion. By using this technology
EMFTrace EMFStore Repository jUCMNav URN EMFfit FTIC UML2Tools/ Visual Paradigm UML Protégé OWL Requirements Global Analysis Design Ontology
Integration of arbitrary models and CASE tools XML Trace Links Models Trace Rules Rule Engine Link Manager
Integrated, existing parts Newly developed parts
Figure 8.1: Overview of the core concept of EMFTrace
every kind of model can be treated in a unified manner if an EMF-based Ecore metamodel is available for it. Therefore, the metamodels for the traceability links and rules as well as the models for the various development artifacts were created using EMF.
The idea for the comprehensive traceability support was to rely on standardized modeling languages, such as URN, UML, and OWL, as far as possible, instead of creating a customized metamodel for all artifacts of the goal-oriented design method. Standardized modeling languages have the advantage to be relatively stable and seldom subject of changes. Moreover, in this way ordinary and established CASE tools can be used for modeling. Consequently, the CASE tools jUCMNav2 for URN
models, UML2Tools3 and Visual Paradigm4for UML models, as well as Protégé5for
OWL ontologies were integrated. Additionally, a customized tool called EMFfit was developed for Global Analysis artifacts, because no standardized model or any tool
2http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome 3 http://www.eclipse.org/modeling/mdt/?project=uml2tools 4http://www.visual-paradigm.com/ 5 http://protege.stanford.edu/
does exist. These tools can provide their models in an XML representation. Besides, the EMFStore repository is based on XML. Hence, XML is the basic integration technology. This core concept is easily extendable for further modeling languages, such as BPMN, and other tools, as long as they provide access to their models via XML. More details on the model integration are discussed in Section 8.3. But first the architecture of EMFTrace and its components such as the rule engine and the link manager are described.