Towards an Ontology-Based Approach for Reusing Non-Functional Requirements Knowledge

Requirements Engineering play a crucial role during the software development process. Many works have pointed out that Non-Functional Requirements (NFR) are currently more important than Functional Requirements. NFRs can be very complicated to understand due to its diversity and subjective nature. The NDR Framework has been proposed to fill some of the existing gaps to facilitate NFR elicitation and modeling. In this thesis, we introduce a tool that plays a major role in the NDR Framework allowing software engineers to store and reuse NFR knowledge. The NDR Tool converts the knowledge contained in Softgoal Interdependency Graphs (SIGs) into a machine-readable format that follows the NFR and Design Rationale (NDR) Ontology. It also provides mechanisms to query the knowledge base and produces graphical representation for the results obtained. To evaluate whether our approach aids eliciting NFRs, we conducted an experiment performing a software development scenario

Reasoning of Competitive Non-Functional Requirements in Agent-Based Models

During the decision-making process in real-time competitive environments, there is a need to perform concurrent optimisation of multiple competitive objectives to select an optimal design decision for interdependent stakeholders. To handle such issues, this thesis successfully assimilates the goal-oriented requirements-engineering knowledge with analytical decision-making approaches to facilitate reasoning and analysis by encouraging stakeholders’ involvement. This leads to optimal decisions with domain knowledge improvement in the agent-based i*-goal model by balancing multiple conflicting non-functional requirements reciprocally

Viewpoints and goals: towards an integrated approach

Dissertação de Mestrado em Engenharia InformáticaRequirements elicitation and analysis have been studied according to several approaches that differ mostly on their "orientation", in this case relying on goals or viewpoints. Goal-Oriented approaches such as KAOS rely on goals to direct their process of eliciting requirements: a goal is an objective the system under consideration should achieve and represents a system property that may reflect either a functional (e.g. a service provided by the system) or a non-functional (e.g. security, performance) requirement; its satisfaction may imply the participation of several agents and the resolution of possible obstacles that may arise. The KAOS approach offers an unambiguous method for requirement decomposition and may provide a set of heuristics to approaches where one does not exist. Viewpoint-Oriented approaches such as PREview focus on gathering information pertaining to the problem from several agents that may have different, often equally valid, and incomplete perspectives on the problem. These partial intakes reflect their different responsibilities, roles, goals, or interpretations of the information sources; hence the combination of the agent and its input on the system is called a viewpoint. PREview benefits from a particularly lightweight approach to requirements encapsulation, but fails to provide a set of heuristics for the process of identifying the system's requirements. Considering the issues identified in each approach, it is verifiable that both approaches are complementary: on the one hand, KAOS offers a set of requirements elicitation heuristics through goal decomposition; on the other hand, PREview is a lightweight approach to viewpoint oriented requirements engineering, tailored especially for integration, however lacks a more systematic mechanism to guide the requirements elicitation process. The objective of this dissertation is therefore to propose a hybrid approach that builds on the PREview approach and brings together the benefits of the KAOS approach. The result is synergetic where, for example, completion is better addressed by providing a set of heuristics for requirement elicitation

Traceability of Requirements and Software Architecture for Change Management

At the present day, software systems get more and more complex. The requirements of software systems change continuously and new requirements emerge frequently. New and/or modified requirements are integrated with the existing ones, and adaptations to the architecture and source code of the system are made. The process of integration of the new/modified requirements and adaptations to the software system is called change management. The size and complexity of software systems make change management costly and time consuming. To reduce the cost of changes, it is important to apply change management as early as possible in the software development cycle. Requirements traceability is considered crucial in change management for establishing and maintaining consistency between software development artifacts. It is the ability to link requirements back to stakeholders’ rationales and forward to corresponding design artifacts, code, and test cases. When changes for the requirements of the software system are proposed, the impact of these changes on other requirements, design elements and source code should be traced in order to determine parts of the software system to be changed. Determining the impact of changes on the parts of development artifacts is called change impact analysis. Change impact analysis is applicable to many development artifacts like requirements documents, detailed design, source code and test cases. Our focus is change impact analysis in requirements and software architecture. The need for change impact analysis is observed in both requirements and software architecture. When a change is introduced to a requirement, the requirements engineer needs to find out if any other requirement related to the changed requirement is impacted. After determining the impacted requirements, the software architect needs to identify the impacted architectural elements by tracing the changed requirements to software architecture. It is hard, expensive and error prone to manually trace impacted requirements and architectural elements from the changed requirements. There are tools and approaches that automate change impact analysis like IBM Rational RequisitePro and DOORS. In most of these tools, traces are just simple relations and their semantics is not considered. Due to the lack of semantics of traces in these tools, all requirements and architectural elements directly or indirectly traced from the changed requirement are candidate impacted. The requirements engineer has to inspect all these candidate impacted requirements and architectural elements to identify changes if there are any. In this thesis we address the following problems which arise in performing change impact analysis for requirements and software architecture. Explosion of impacts in requirements after a change in requirements. In practice, requirements documents are often textual artifacts with implicit structure. Most of the relations among requirements are not given explicitly. There is a lack of precise definition of relations among requirements in most tools and approaches. Due to the lack of semantics of requirements relations, change impact analysis may produce high number of false positive and false negative impacted requirements. A requirements engineer may have to analyze all requirements in the requirements document for a single change. This may result in neglecting the actual impact of a change. Manual, expensive and error prone trace establishment. Considerable research has been devoted to relating requirements and design artifacts with source code. Less attention has been paid to relating Requirements (R) with Architecture (A) by using well-defined semantics of traces. Designing architecture based on requirements is a problem solving process that relies on human experience and creativity, and is mainly manual. The software architect may need to manually assign traces between R&A. Manual trace assignment is time-consuming, expensive and error prone. The assigned traces might be incomplete and invalid. Explosion of impacts in software architecture after a change in requirements. Due to the lack of semantics of traces between R&A, change impact analysis may produce high number of false positive and false negative impacted architectural elements. A software architect may have to analyze all architectural elements in the architecture for a single requirements change. In this thesis we propose an approach that reduces the explosion of impacts in R&A. The approach employs semantic information of traces and is supported by tools. We consider that every relation between software development artifacts or between elements in these artifacts can play the role of a trace for a certain traceability purpose like change impact analysis. We choose Model Driven Engineering (MDE) as a solution platform for our approach. MDE provides a uniform treatment of software artifacts (e.g. requirements documents, software design and test documents) as models. It also enables using different formalisms to reason about development artifacts described as models. To give an explicit structure to requirements documents and treat requirements, architecture and traces in a uniform way, we use metamodels and models with formally defined semantics. The thesis provides the following contributions: A modeling language for definition of requirements models with formal semantics. The language is defined according to the MDE principles by defining a metamodel. It is based on a survey about the most commonly found requirements types and relation types. With this language, the requirements engineer can explicitly specify the requirements and the relations among them. The semantics of these entities is given in First Order Logic (FOL) and allows two activities. First, new relations among requirements can be inferred from the initial set of relations. Second, requirements models can be automatically checked for consistency of the relations. Tool for Requirements Inferencing and Consistency Checking (TRIC) is developed to support both activities. The defined semantics is used in a technique for change impact analysis in requirements models. A change impact analysis technique for requirements using semantics of requirements relations and requirements change types. The technique aims at solving the problem of explosion of impacts in requirements when semantics of requirements relations is missing. The technique uses formal semantics of requirements relations and requirements change types. A classification of requirements changes based on the structure of a textual requirement is given and formalized. The semantics of requirements change types is based on FOL. We support three activities for impact analysis. First, the requirements engineer proposes changes according to the change classification before implementing the actual changes. Second, the requirements engineer indentifies the propagation of the changes to related requirements. The change alternatives in the propagation are determined based on the semantics of change types and requirements relations. Third, possible contradicting changes are identified. We extend TRIC with a support for these activities. The tool automatically determines the change propagation paths, checks the consistency of the changes, and suggests alternatives for implementing the change. A technique that provides trace establishment between R&A by using architecture verification and semantics of traces. It is hard, expensive and error prone to manually establish traces between R&A. We present an approach that provides trace establishment by using architecture verification together with semantics of requirements relations and traces. We use a trace metamodel with commonly used trace types. The semantics of traces is formalized in FOL. Software architectures are expressed in the Architecture Analysis and Design Language (AADL). AADL is provided with a formal semantics expressed in Maude. The Maude tool set allows simulation and verification of architectures. The first way to establish traces is to use architecture verification techniques. A given requirement is reformulated as a property in terms of the architecture. The architecture is executed and a state space is produced. This execution simulates the behavior of the system on the architectural level. The property derived from the requirement is checked by the Maude model checker. Traces are generated between the requirement and the architectural components used in the verification of the property. The second way to establish traces is to use the requirements relations together with the semantics of traces. Requirements relations are reflected in the connections among the traced architectural elements based on the semantics of traces. Therefore, new traces are inferred from existing traces by using requirements relations. We use semantics of requirements relations and traces to both generate/validate traces and generate/validate requirements relations. There is a tool support for our approach. The tool provides the following: (1) generation/validation of traces by using requirements relations and/or verification of architecture, (2) generation/validation of requirements relations by using traces. A change impact analysis technique for software architecture using architecture verification and semantics of traces between R&A. The software architect needs to identify the impacted architectural elements after requirements change. We present a change impact analysis technique for software architecture using architecture verification and semantics of traces. The technique is semi-automatic and requires participation of the software architect. Our technique has two parts. The first part is to identify the architectural elements that implement the system properties to which proposed requirements changes are introduced. By having the formal semantics of requirements relations and traces, we identify which parts of software architecture are impacted by a proposed change in requirements. We have extended TRIC for determining candidate impacted architectural elements. The second part of our technique is to propose possible changes for software architecture when the software architecture does not satisfy the new and/or changed requirements. The technique is based on architecture verification. The output of verification is a counter example if the requirements are not satisfied. The counter example is used with a classification of architectural changes in order to propose changes in the software architecture. These changes produce a new version of the architecture that possibly satisfies the new or the changed requirements

A Novel System-Theoretic Matrix-Based Approach to Analysing Safety and Security of Cyber-Physical Systems

Cyber-Physical Systems (CPSs) are getting increasingly complex and interconnected. Consequently, their inherent safety risks and security risks are so intertwined that the conventional analysis approaches which address them separately may be rendered inadequate. STPA (Systems-Theoretic Process Analysis) is a top-down hazard analysis technique that has been incorporated into several recently proposed integrated Safety and Security (S&S) analysis methods. This paper presents a novel methodology that leverages not only STPA, but also custom matrices to ensure a more comprehensive S&S analysis. The proposed methodology is demonstrated using a case study of particular commercial cloud-based monitoring and control system for residential energy storage systems

Evaluasi Kombinasi Hipernin dan Sinonim untuk Klasifikasi Kebutuhan Non-Functional Berbasis ISO/IEC 25010

Kebutuhan non-fungsional dianggap mampu mendukung keberhasilan pengembangan perangkat lunak. Namun, kebutuhan non-fungsional sering diabaikan selama proses pengembangan perangkat lunak. Hal ini dikarenakan kebutuhan non-fungsional sering tercampur dengan kebutuhan fungsional. Disamping itu, standar kualitas yang beragam menyebabkan kebingungan dalam menentukan aspek kualitas. Pendekataan yang ada menggunakan ISO/IEC 9126 sebagai referensi untuk mengukur aspek kualitas. ISO/IEC 9126 merupakan standar lama yang dirilis pada tahun 2001. Peneliti sebelumnya mengungkapkan ambiguitas dalam enam sub-atribut pada struktur hirarkis ISO/IEC 9126. Hal ini menimbulkan keraguan serius tentang validitas standar secara keseluruhan. Oleh karena itu, standar kualitas yang digunakan sebagai referensi untuk mengukur aspek kualitas pada penelitian ini adalah ISO/IEC 25010. Selain itu, penelitian ini juga mengusulkan suatu sistem untuk mengidentifikasi aspek kualitas kebutuhan non-fungsional dengan menggunakan 1 level hipernim dan 20 sinonim yang disebut skenario 1. Skenario ini akan dibandingkan dengan 2 level hipernim dan 9 sinonim pada masing-masing sinonim yang disebut skenario 2. Kedua skenario tersebut akan menghasilkan dua data latih berbeda. Kedua data latih tersebut akan dibandingkan menggunakan dua model pengujian yaitu berdasarkan ground truth pakar dan sistem dengan menggunakan metode klasifikasi KNN dan SVM. Hasil pengujian menunjukkan skenario 1 terbukti memberikan nilai lebih baik dibandingkan skenario 2 pada kedua model pengujian, dimana nilai precision dari ground truth pakar, KNN, dan SVM masing-masing 49.3%, 81.0%, dan 74.6%.Abstract Non-Functional requirements are considered capable of supporting the success of software development. However, non-functional requirements are often ignored during the software development process. This is because the quality aspects of non-functional requirements are often mixed with functional requirements. in addition, the number of diverse quality standards causes confusion in determining quality aspects. The existing approach uses ISO / IEC 9126 as a reference to measure quality aspects. ISO / IEC 9126 is an old standard released in 2001. Previous researchers revealed ambiguity in six sub-attributes on the hierarchical structure of ISO / IEC 9126. This raises serious doubts about the validity of the overall standard. Therefore, the quality standard used as a reference to measure the quality aspects of this study is ISO / IEC 25010. In addition, this study also proposes a system to identify aspects of the quality of non-functional requirements using 1 hypernym level and 20 synonyms called scenario 1. This scenario will be compared with 2 hypernym levels and 9 synonyms in each synonym called scenario 2. Both scenarios will produce two different training data. The two training data will be compared using two testing models ie based on expert ground truth and systems using the KNN and SVM classification methods. The test results showed scenario 1 is proven to provide a better value than scenario 2 in both testing models, where the precision values of expert ground truth, KNN, and SVM  respectively 49.3%, 81.0%, and 74.6%

Integrating requirements prioritization and selection into goal models

Requirements engineering is the first main activity in software development process. It must address the individual goals of the organization. The inadequate, inconsistent, incomplete and ambiguous requirements are main obstacles on the quality of software systems. Goal Oriented Requirements Engineering (GORE) starts with abstracts high level goals. These goals are refined to lower levels until they are assignable to agents. During GORE analysis, decisions need to be made among alternatives at various positions. Decisions involve different stakeholders which may contradict with each other based on certain criteria. In the context of GORE, the support for identifying and managing the criteria for requirements selection process is required. The criteria are based on stakeholders needs and preferences and therefore stakeholders opinions need to be involved in selection process. It helps to identify the importance of requirement according to stakeholders understandings and needs. It also helps in the understanding of interaction between system and stakeholders (stakeholders involvement in making important decisions) and by documenting the stakeholder preferences early in GORE, helps to identify inconsistencies early in the requirements engineering. Software quality requirements are essential part for the success of software development. Defined and guaranteed quality in software development requires identifying, refining, and predicting quality properties by appropriate means. Goal models and quality models are useful for modelling of functional goals as well as for quality goals. This thesis presents the integration of goal models with quality models, which helps to involve stakeholders opinions and the representation of dependencies among goals and quality models. The integration of goal models and quality models helps in the derivation of customized quality models. The integrated goal-quality model representing the functional requirements and quality requirements is used to rank each functional requirement arising from functional goals and quality requirement arising from quality goals. Triangular Fuzzy Numbers (TFN) are used to represent stakeholder opinions for prioritizing requirements. By defuzzification process on TFN, stakeholders opinions are quantified. TFN and defuzzification process is also used to prioritize the identified relationships among functional and non-functional requirements. In the last step development constraints are used to re-prioritize the requirements. After final prioritization, a selection algorithm helps to select the requirements based on benefit over cost ratio. The algorithm makes sure that maximum number of requirements are selected while fulfilling the upper cost limit. Thus the whole process helps in the selection of requirements based on stakeholders opinions, goal-quality models interaction and development constraints. The thesis also presents an integrative model of influence factors to tailor product line development processes according to different project needs, organizational goals, individual goals of the developers or constraints of the environment. Tailoring is realized with prioritized attributes, with which the resulting elements of the product, process and project analysed are ranked. An integrative model for the description of stakeholder needs and goals in relation to the development process artefacts and the development environment specifics is needed, to be able to analyse potential influences of changing goals early in the project development. The proposed tailoring meta-model includes goal models, SPEM models and requirements to development processes. With this model stakeholder specific goals can be used to support binding a variable part of the development process. This support addresses soft factors as well as concrete requirements.Requirements Engineering ist der erste Schritt im Softwareentwicklungsprozess. Er dient zur Aufnahme organisationsabhängiger Ziele und Anforderungen. Unangemessene, inkonsistente, unvollständige oder mehrdeutige Anforderungen können die Qualität von Softwaresystem stark negativ beeinflussen. Goal Oriented Requirements Engineering (GORE) beginnt mit der Entwicklung von übergeordneter Zielen, welche in weiteren Entwicklungsstufen verfeinert werden, bis sie einer verantwortlichen Person zugewiesen werden können. Während einer GORE Analyse werden an verschiedenen Stellen Entscheidungen über Alternativen getroffen. Diese Entscheidungen betreffen unterschiedliche Akteure, die sich in ihren Ansichten widersprechen können. Im Rahmen von GORE wird die Unterstützung zur Identifizierung und Verwaltung von Kriterien zur Auswahl von Anforderungen benötigt. Diese Kriterien basieren auf den Vorstellungen und Vorlieben von Stakeholdern, daher ist eine Integration aller Stakeholder in den Auswahlprozess erforderlich. Dies soll dabei helfen, die Bedeutung bestimmter Anforderungen auf Basis der betroffenen Personen zu identifizieren und aufzuarbeiten. Darüber hinaus hilft GORE bei der Kommunikation zwischen System und Akteuren durch ihren Einbezug in wichtige Entscheidungen. Durch frühzeitige Dokumentation des tatsächlichen Stakholderbedarfs können Inkonsistenzen im Requirements Engineering frühzeitig ermittelt werden. Die Bestimmung von Software Qualitätsmerkmalen ist wesentlicher Erfolgsfaktor in der Software Entwicklung. Zur Gewährleistung einer qualitativen Softwareentwicklung und eines entsprechenden Produktes sind die Identifizierung, die Verfeinerung und die Vorhersage von Qualitätseigenschaften jederzeit durch geeignete Maßnahmen erforderlich. Goal Models und Quality Models sind wertvolle Werkzeuge zur Ermittlung und Modellierung funktionaler und nicht-funktionaler Anforderungen und Ziele. Diese Arbeit enthält einen Lösungsansatz zur Integration von Goal Models und Quality Models, der dazu beitragen soll, Stakeholder und Abhängigkeiten zwischen Goal und Quality Models einzubeziehen und sichtbar zu machen. Die Integration von Goal Models und Quality Models soll zur Ableitung spezifischer Quality Models beitragen. Somit kann das integrierte Goal-Quality Model, welches die funktionalen Anforderungen und die Qualitätsanforderungen vereint, zur Priorisierung aller funktionalen Anforderung, die sich aus den funktionalen Zielen ergeben, und aller Qualitätsanforderungen, die aus Qualitätszielen resultieren, dienen. Zur Priorisierung der Anforderung auf Basis der Stakeholderbedarfe werden Triangular Fuzzy Numbers (TFN) verwendet. Nach der endgültigen Priorisierung dient ein spezieller Algorithmus zur Einschätzung und Auswahl der Anforderungen auf Basis einer Kosten-Nutzen-Analyse. Dieser Algorithmus stellt sicher, dass unter Einhaltung einer von der Organisation gewählten Kostenobergrenze die maximale Anzahl der Anforderungen umgesetzt werden kann. Der gesamte Prozess dient demnach zur Anforderungsanalyse unter Berücksichtigung verschiedener Interessengruppen, Abhängigkeiten, sowie durch den Einbezug von Grenzen, die sich beim Zusammenspiel von Goal-Quality Models und der Softwareentwicklung ergeben können. Darüber hinaus enthält die Arbeit ein integratives Modell, um Entwicklungsprozesse während der Erstellung von Produktlinien an Einflussfaktoren, wie Projektbedürfnisse, Organisationsziele, individuelle Ziele von Entwicklern oder an Umweltbedingungen anzupassen. Dieses sogenannte Tailoring wird durch Priorisierung von Attributen erreicht, welche verschiedene Elemente des zu erzeugende Produktes, des Prozesses oder des Projektes analysieren und nach Bedeutung sortieren. Ein integratives Modell zur Beschreibung von Stakeholderbedürfnissen und -zielen in Bezug auf die Artefakte des Entwicklungsprozesses und die Besonderheiten einer Entwicklungsumgebung wird benötigt, um potenzielle Einflüsse sich verändernder Ziele frühzeitig während der Projektentwicklung zu analysieren. Das hier vorgestellte Tailoring-Meta-Model beinhaltet Goal-Models, SPEM Models und Requirements hinsichtlich Entwicklungsprozesse. Mithilfe dieses Modells können stakeholderspezifische Ziele dazu verwendet werden, um einen variablen Teil eines Entwicklungsprozesses projektbezogen zu gestalten. Auf diese Weise können weiche Faktoren genauso integriert werden, wie konkrete Anforderungen

Quality Goal Oriented Architectural Design and Traceability for Evolvable Software Systems

Softwaresysteme werden heute z.B. aufgrund sich ändernder Geschäftsprozesse oder Technologien mit häufigen Veränderungen konfrontiert. Die Software und speziell ihre Architektur muss diese Änderungen zur dauerhaften Nutzbarkeit ermöglichen.Während der Software-Evolution können Änderungen zu einer Verschlechterung der Architektur führen, der Architekturerosion. Dies erschwert oder verhindert weitere Änderungen wegen Inkonsistenz oder fehlendem Programmverstehen. Zur Erosionsvermeidung müssen Qualitätsziele wie Weiterentwickelbarkeit, Performanz oder Usability sowie die Nachvollziehbarkeit von Architekturentwurfsentscheidungen berücksichtigt werden. Dies wird jedoch oft vernachlässigt.Existierende Entwurfsmethoden unterstützen den Übergang von Qualitätzielen zu geeigneten Architekturlösungen nur unzureichend aufgrund einer Lücke zwischen Methoden des Requirements Engineering und des Architekturentwurfs. Insbesondere gilt dies für Weiterentwickelbarkeit und die Nachvollziehbarkeit von Entwurfsentscheidungen durch explizite Modellabhängigkeiten.Diese Arbeit präsentiert ein neues Konzept, genannt Goal Solution Scheme, das Qualitätsziele über Architekturprinzipien auf Lösungsinstrumente durch explizite Abhängigkeiten abbildet. Es hilft somit, Architekturlösungen entsprechend ihrem Einfluss auf Qualitätsziele auszuwählen. Das Schema wird speziell hinsichtlich Weiterentwickelbarkeit diskutiert und ist in ein zielorientiertes Vorgehen eingebettet, das etablierte Methoden und Konzepte des Requirements Engineering und Architekturentwurfs verbessert und integriert. Dies wird ergänzt durch ein Traceability-Konzept, welches einen regelbasierten Ansatz mit Techniken des Information Retrieval verbindet. Dies ermöglicht eine (halb-) automatische Erstellung von Traceability Links mit spezifischen Linktypen und Attributen für eine reichhaltige Semantik sowie mit hoher Genauigkeit und Trefferquote.Die Realisierbarkeit des Ansatzes wird an einer Fallstudie einer Software für mobile Serviceroboter gezeigt. Das Werkzeug EMFTrace wurde als eine erweiterbare Plattform basierend auf Eclipse-Technologie implementiert, um die Anwendbarkeit der Konzepte zu zeigen. Es integriert Entwurfsmodelle von externen CASE-Tools mittels XML-Technologie in einem gemeinsamen Modell-Repository, wendet Regeln zur Linkerstellung an und bietet Validierungsfunktionen für Regeln und Links.Today software systems are frequently faced with demands for changes, for example, due to changing business processes or technologies. The software and especially its architecture has to cope with those frequent changes to permanently remain usable.During software evolution changes can lead to a deterioration of the structure of software architectures called architectural erosion, which hampers or even inhibits further changes because of inconsistencies or lacking program comprehension. To support changes and avoid erosion, especially quality goals, such as evolvability, performance, or usability, and the traceability of design decisions have to be considered during architectural design. This however often is neglected.Existing design methods do not sufficiently support the transition from the quality goals to appropriate architectural solutions because there is still a gap between requirements engineering and architectural design methods. Particularly support is lacking for the goal evolvability and for the traceability of design decisions by explicit model dependencies.This thesis presents a new concept called Goal Solution Scheme, which provides a mapping from goals via architectural principles to solution instruments by explicit dependencies. Thus it helps to select appropriate architectural solutions according to their influence on quality goals. The scheme is discussed especially regarding evolvability, and it is embedded in a goal-oriented architectural design method, which enhances and integrates established methods and concepts from requirements engineering as well as architectural design. This is supplemented by a traceability concept, which combines a rule-based approach with information retrieval techniques for a (semi-) automated establishment of links with specific link types and attributes for rich semantics and a high precision and recall.The feasibility of the design approach has been evaluated in a case study of a software platform for mobile robots. A prototype tool suite called EMFTrace was implemented as an extensible platform based on Eclipse technology to show the practicability of the thesis' concept. It integrates design models from external CASE tools in a joint model repository by means of XML technology, applies rules for link establishment, and provides validation capabilities for rules and links