Supporting Model Evolution in Model-Driven Development of Automotive Embedded Systems
MATTHIAS BIEHL
Licentiate Thesis Stockholm, Sweden, 2010
TRITA-MMK 2010:08 ISSN 1400-1179 ISRN/KTH/MMK/R-10/08-SE ISBN 978-91-7415-723-9
KTH School of Industrial Engineering and Management 10044 Stockholm Sweden
Academic thesis, which with the approval of the Royal Institute of Technology, will be presented for public review in fulfillment of the requirements for a Licentiate of Technology in Machine Design. The public review is held in Room A325, Department for Machine Design, Royal Institute of Technology, Brinellv¨agen 83, Stockholm on 2010-11-25 9:15. c Matthias Biehl, 2010, Version 20101102165300
Print: US-AB
iii Abstract Innovative functions in cars, such as active safety systems and advanced driver assistance systems, are realized as embedded systems. The development of such automotive embedded systems is challenging in several respects: the product typically has several crosscutting system properties, experts of diverse disciplines need to cooperate and appropriate processes and tools are required to improve the efficiency and the complexity management of development. Model-driven development captures the architecture of the embedded system in the form of models with well-defined metamodels. Model-driven development provides a partial solution to some of the challenges of embedded systems development, but it also introduces new challenges. Models do not remain static, but they change over time and evolve. Evolution can change models in two ways: (1) by making design decisions and adding, deleting or changing model elements, or (2) by reusing models in different tools. We propose support for both aspects of model evolution. (1) When models are changed, the design decisions and the justification for the change are usually neither captured nor documented in a systematic way. As a result, important information about the model is lost, making the model more difficult to understand, which hampers model evolution and maintenance. To support model evolution, design decisions need to be captured explicitly using an appropriate representation. This representation reduces the overhead of capturing design decisions, keeps the model and the design decision documentation consistent and links the design decision documentation to the model. As a result, the captured design decisions provide a record of the model evolution and the rationale of the evolution. (2) Several models and views are used to describe an embedded system in different life cycle stages and from the viewpoints of the involved disciplines. To create the various models, a number of specialized development tools are used. These tools are usually disconnected, so the models cannot be transferred between different tools. Thus, models may become inconsistent, which hampers understandability of the models and increases the cost of development. We present a model-based tool integration approach that uses a common metamodel in combination with model transformation technology to build bridges between different development tools. We apply this approach in a case study and integrate several tools for automotive embedded systems development: A systems engineering tool, a safety engineering tool and a simulation tool. As a part of future work, we plan to extend the tool integration approach to exchange not only models but also the attached documentation of design decisions. As a result, the design decision documentation is linked consistently to corresponding model elements of the various tool-specific models, supporting model evolution across several development tools.
Acknowledgements Many people have been involved in the work behind the thesis. I would like to thank: • Martin T¨ orngren for the opportunity to work towards the licentiate thesis and for providing advise, feedback, encouragement and enthusiasm throughout the work! • De-Jiu Chen and Carl-Johan Sj¨ ostedt for the teamwork in the ATESST2 project and for the contributions and feedback on the co-authored publications. • Jad El-khoury for providing detailed feedback on the papers. • Tahir Naseer Qureshi, Magnus Persson, Lei Feng, Sagar Behere, Fredrik Asplund, Alex Schenkman, Begashaw Gezu Kirsie and Kristian Gustafsson for the great working atmosphere and discussions. • All other colleagues in the department of machine design and in the research projects ATESST2, CESAR and iFEST. • My parents, sisters and friends for their support.
Matthias Biehl Stockholm, November 2010
v
Contents Acknowledgements
v
Contents
vii
List of Appended Publications
xi
List of Other Publications
xiii
1 Introduction 1.1 Automotive Embedded Systems Development . . . . 1.1.1 Product: Embedded Systems . . . . . . . . . 1.1.2 People and Organization: Multidisciplinarity 1.1.3 Process and Tools . . . . . . . . . . . . . . . 1.1.4 Summary . . . . . . . . . . . . . . . . . . . . 1.2 Problem Formulation . . . . . . . . . . . . . . . . . . 1.2.1 Illustrative Example . . . . . . . . . . . . . . 1.3 Objectives and Assumptions . . . . . . . . . . . . . . 1.4 Research Questions . . . . . . . . . . . . . . . . . . . 1.5 Summary of Contributions . . . . . . . . . . . . . . . 1.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
2 State of the Art and State of Practice 2.1 Model-Based and Model-Driven Approaches . . . . . . . . 2.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . 2.1.2 Model Evolution . . . . . . . . . . . . . . . . . . . 2.1.3 State of Practice . . . . . . . . . . . . . . . . . . . 2.2 Software Architecture Description . . . . . . . . . . . . . . 2.2.1 Views, Aspects and Consistency Checking . . . . . 2.2.2 Architecture Description Languages . . . . . . . . 2.2.3 EAST-ADL2 - An ADL for Automotive Embedded 2.2.4 State of Practice . . . . . . . . . . . . . . . . . . . 2.3 Model-Based Tool Integration . . . . . . . . . . . . . . . . 2.3.1 Approaches for Data Integration . . . . . . . . . . vii
. . . . . . . . . . .
. . . . . . . . . . .
1 1 1 2 3 3 4 5 6 7 8 8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Systems . . . . . . . . . . . . . . .
. . . . . . . . . . .
11 12 12 15 16 16 17 17 18 20 20 21
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
viii
CONTENTS . . . .
. . . .
. . . .
24 25 26 27
3 Research Methods 3.1 A Methodological Framework for Software Engineering Research 3.2 A Methodological Framework for Engineering Design Research . 3.3 Research Methods in this Thesis . . . . . . . . . . . . . . . . . . 3.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
29 29 30 31 33
2.4 2.5
2.3.2 State of Practice . . . . Design Decision Documentation 2.4.1 State of Practice . . . . Chapter Summary . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 Approach and Results 4.1 Two Dimensions of Model Evolution . . . . . . . . . . . . . . . . . . 4.2 Horizontal Model Evolution: Tool Integration in Automotive Embedded Systems Development . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Requirements and Analysis . . . . . . . . . . . . . . . . . . . 4.2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Vertical Model Evolution: Design Decision Documentation for Models 4.3.1 Requirements and Analysis . . . . . . . . . . . . . . . . . . . 4.3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35 39 42 42 44 46 47 47 48 51 52
5 Discussion 53 5.1 Horizontal Model Evolution . . . . . . . . . . . . . . . . . . . . . . . 53 5.2 Vertical Model Evolution . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6 Future Work 6.1 Design Decision Documentation in Multi-Tool Environments 6.2 Design Decision Patterns . . . . . . . . . . . . . . . . . . . . 6.3 Design Decision Reconstruction from Model Differences . . . 6.4 Design Decision Management . . . . . . . . . . . . . . . . . . 6.5 Research Questions . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
59 60 60 61 61 61
7 Concluding Remarks
63
Bibliography
65
A Literature Study on the State of the Art in Model Transformation Technology
85
B Integrating Safety Analysis into the Model-based Development Tool Chain of Automotive Embedded Systems
113
CONTENTS
ix
C A Modular Tool Integration Approach - Experiences from two Case Studies
123
D Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions
137
E An Executable Design Decision Representation using Model Transformations 177 F Documenting Stepwise Model Refinement using Executable Design Decisions 183
List of Appended Publications This thesis is based on six papers that are appended to this thesis. An overview of the contents of these papers is presented in chapter 4. • Matthias Biehl, “Literature Study on Model Transformations,” Technical Report, Royal Institute of Technology, ISSN 1400-1179, ISRN/KTH/MMK/R10/07-SE, Stockholm, Sweden, July 2010. Included as Paper A. • Matthias Biehl, Chen De-Jiu, and Martin T¨orngren, “Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), April 2010, pp. 125+. Included as Paper B. Chen developed the EAST-ADL2 metamodel for error modeling, Matthias developed the concepts and implementation for tool integration, performed the case-study and wrote the paper, Chen and Martin provided essential feedback. • Matthias Biehl, Carl-Johan Sj¨ ostedt, and Martin T¨orngren, “A Modular Tool Integration Approach - Experiences from two Case Studies,” in 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI2010), June 2010. Included as Paper C. Carl-Johan performed the case study on integrating Simulink and wrote section 4.2, Matthias performed the case study on integrating the safety analysis tool HiP-HOPS and wrote the rest of the paper, Martin provided essential feedback. • Matthias Biehl, “Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions,” Technical Report, ISSN 14001179, ISRN/KTH/MMK/R-10/06-SE, Royal Institute of Technology, Stockholm, Sweden, July 2010. Included as Paper D. • Matthias Biehl and Martin T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference xi
xii
LIST OF APPENDED PUBLICATIONS on Software Engineering and Advanced Applications (SEAA2010), September 2010. Included as paper E. Matthias developed the concepts and prototypes, performed the case-study and wrote the paper, Martin provided essential feedback. • Matthias Biehl, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in International Workshop on Models and Evolution (ME 2010), October 2010. Included as paper F.
List of Other Publications • Matthias Biehl and Welf L¨ owe, “Automated Architecture Consistency Checking for Model Driven Software Development,” in Proceedings of the Fifth International Conference on the Quality of Software Architectures (QoSA 2009), June 2009, pp. 36-51. [Online]. Available: http://dx.doi.org/10.1007/ 978-3-642-02351-4_3. • Ulf Sellgren, Martin T¨ orngren, Diana Malvius, and Matthias Biehl, “PLM for Mechatronics Integration,” in Proceedings of the 6th International Product Lifecycle Management Conference (PLM 2009), July 2009. [Online]. Available: http://www.md.kth.se/~ulfs/Publications/PLMForMechatronics. pdf. • Olaf Seng, Markus Bauer, Matthias Biehl, and Gert Pache, “Search-based Improvement of Subsystem Decompositions,” in Proceedings of the 2005 ACM Conference on Genetic and Evolutionary Computation (GECCO 2005), 2005, pp. 1045-1051. [Online]. Available: http://dx.doi.org/10.1145/1068009. 1068186. • ATESST2 Project Deliverables D2.1, D3.1, D3.2, D3.5, D4.3.1 [Online]. Available: http://www.atesst.org. • iFEST Project Deliverable D2.1 [Online]. Available: http://www.artemis-ifest.eu.
xiii
Chapter 1
Introduction 1.1
Automotive Embedded Systems Development
Innovative functions in cars, such as active safety systems and advanced driver assistance systems, are realized as automotive embedded systems. On the one hand, automotive embedded systems have a great potential. On the other hand, the development of automotive embedded systems is complex. This thesis focuses on methods and tools that aim to support dealing with this complexity. A number of factors contribute to the complexity of development: the product, the people and their organization and the processes and tools [75]. The embedded system as a product is complex, as it needs to be integrated into a larger system and fulfill a large number of non-functional cross-cutting system requirements [144]. Embedded systems development is multidisciplinary [30], as people with expertise in several disciplines are required. Processes, methods and tools structure the development work. We will examine how these factors influence the complexity of development.
1.1.1
Product: Embedded Systems
The IEEE Glossary defines an embedded computer system as a “computer system that is part of a larger system and performs some of the requirements of that system” [109]. Embedded systems are often classified according to the domains of these larger systems they are part of, for example automotive, automation, aerospace or rail. In this thesis we focus on automotive embedded systems. According to the IEEE definition, an embedded system is tightly integrated into a larger system. The integration results typically in many non-functional requirements for embedded systems that go beyond those of IT systems [144, 69]: • Real-time constraints: embedded systems must deliver results within a maximum time under all circumstances. 1
2
CHAPTER 1. INTRODUCTION • Reliability: embedded systems run for a long time without service and unexpected behavior of the embedded system might damage the environment. • Safety criticality: embedded systems impact people and constitute potential safety hazards. • Security: embedded systems are increasingly interconnected with each other, but also with sensors and actuators. Security protection is a major issue. • Limited resources: embedded systems often need to be low cost devices, which entails limited resources. This imposes constraints on the computation power, available memory and consumable electrical power. • Long lifetime: embedded systems are built into mechanical products that have a long expected lifetime. • Heterogeneity: embedded systems need to support different types of hardware, so they need to be flexible, adaptable and portable to new hardware.
Requirements, such as security and safety, cannot be realized as system properties in an isolated way, but the interactions among these system properties need to be considered [68]. Out of several such relatively simple interactions, complex patterns arise. This phenomenon is called emergence [210], where new structures or behaviors of the system arise that cannot be reduced to those of the isolated parts. These factors contribute to the complexity of developing embedded systems.
1.1.2
People and Organization: Multidisciplinarity
The development of embedded systems is multidisciplinary1 , as the embedded system is influenced by the surrounding system and also itself influences the surrounding system [68]. The surrounding system might be a mechanical, electrical or electronic system. People of different educational backgrounds i.e. control engineers, mechanical engineers, electrical engineers and software engineers work together on creating one product that must meet the needs of the users [30]. Often the people of one discipline do not understand the specialties of the other disciplines any more [164]. Each of these disciplines has its separate and dedicated set of tools, models and views that support development, communication, analysis and simulation [39]. The different aspects of the system, its mechanical, electrical and software parts need to fit together, when they are integrated into one product. The foundations for this integration are already laid in the early stages of system development, when the architecture of the system is specified. The complexity of this integration is further aggravated by a number of non-functional requirements and important crosscutting system properties such as safety. A crosscutting system property cannot be resolved 1 In interdisciplinary areas the disciplines are integrated, while in multidisciplinary areas the cooperation is not interactive and disciplines remain separate [7].
1.1. AUTOMOTIVE EMBEDDED SYSTEMS DEVELOPMENT
3
for each system aspect such as mechanics, software or electronics separately, but interactions between these different disciplines need to be considered and resolved. Despite the differences the engineers need to communicate their design and architecture effectively across the disciplines. A boundary object [193] is a description of information that is a common reference for different disciplines. Boundary objects have a bridging function and serve as a basis for communication between the members of different disciplines.
1.1.3
Process and Tools
Processes and tools are proposed both by academia and by industry. Academic processes usually provide a reference and clean terminology, but are often difficult to apply in practice. Industrial processes describe the current state of practice in development, but sometimes the terminology is not unambiguously defined. Many academic process models for general engineering design and development have been proposed. They have their roots in mechanical engineering, systems engineering and mathematics. Examples are Konstruktionslehre by Pahl/Beitz [172], Product Development by Ulrich and Eppinger [211], Axiomatic Design by Suh [195, 196], Function-Behavior-Structure Model by Gero [89], Theory of Technical Systems by Hubka/Eder [106, 107], Concept-Knowledge Theory [97] and VDI 2222 [212]. Specifically relevant for embedded systems is the Y-chart invented Gajski and Kuhn [86, 90]. The model defines five abstraction levels, each of them can be specified by three models describing behavior, structure and geometry. Industrially applied development processes for embedded systems typically follow the V-Model described in VDI 2206 [213]. In addition, approaches for complexity management [205] are used, such as model-based/model-driven development [164] and component-based development [54]. Model-based and model-driven development is introduced in section 2.1. Processes, methods and tools are closely related and dependent [164]. Processes can be decomposed into tasks. Methods describe how the tasks of a process are implemented. Methods can be supported by development tools, for example to improve the efficiency of a method. A list of commonly used development tools for embedded software development is provided in [68]. In the context of this work we use the term tool synonymously to a development tool, which is a software program that supports the development process.
1.1.4
Summary
The complexity of the development of embedded systems is determined by the complexity of the factors product, organization, processes and tools. We can distinguish between the essential and accidental complexity of development [33]. Essential complexity is the complexity that lies in the nature of the problem and the complexity cannot be influenced without changing the problem. Accidental complexity is the
4
CHAPTER 1. INTRODUCTION
complexity that is introduced due to imperfect choices in any of the factors and it can be improved upon. In this thesis we assume that a model-driven development approach for embedded systems is applied and we study and develop tools that are intended to reduce the accidental complexity. We focus on tools for automotive embedded software development as a means for increasing the efficiency and reducing the cost of development.
1.2
Problem Formulation
Model-driven development is an approach for managing the complexity of development. Some, but not all of the issues for managing the complexity of embedded systems development identified in the previous section are addressed by a modeldriven development approach. • Product: Model-driven development creates models, which allows analyzing and simulating the embedded system early in the development process, when corrective changes are relatively straightforward and cheap. • People: The multidisciplinary aspects of embedded systems development is reflected in model-driven development by multiple views and models of the same system. However independent changes of these models during development and maintenance often lead to inconsistencies between the models. • Process and Tools: There is no established industrial development process for model-driven development. Also, the available development tools are often immature: The tools do not interoperate well; it is often not possible to change the development tool and load an existing model in another development tool. The development tools do not capture and document all relevant metadata, such as the reasons and design decisions associated with changes in the model. In summary, model-driven approaches promise a partial solution to some of the challenges of embedded systems development, but it brings up new challenges. One of these challenges is the handling of changes in model-driven development: models do not remain static, but they change over time and evolve. In a development process, the change can affect the content, nature, structure or representation of models. Here we present the challenge of model evolution in more depth: • Evolution of multiple views: The models of different views are changed independently during development and maintenance tasks, leading to inconsistencies between the models. As a result, the system becomes harder to understand, making further maintenance and integration more complicated and costly. Perry and Wolf discuss this problem of views that drift apart as architectural drift, which may lead to a deterioration and erosion of the model [175, 206].
1.2. PROBLEM FORMULATION
5
• Evolution of models in multi-tool environments: Each engineering discipline prefers a different set of COTS (commercial off the shelf) development tools that excel in that particular discipline [73] or life cycle stage. However, these tools do not interoperate well and models created in one tool cannot be readily used in another, similar tool. This is, however, desirable for the evolution of models representing multiple views of the system. The lack of tool interoperability leads to gaps in the development process, manual translations of models and, in the end, to inefficiency and high development costs [185]. Models need to be adapted in such a way that they can be developed using several tools, even if these tools expect the model to conform to different tool-specific metamodels. Reusing a model in another development tool than the model was originally developed in, is just another step in the evolution of the model. The model needs to evolve by adapting its metamodel to the tool-specific metamodel of the new tool. • Documentation of design decisions to capture model evolution: When models are changed, the design decisions and the justification for the change are usually not captured or documented in a systematic way. As a result, important information about the model is lost, making the model more difficult to understand, which hampers maintenance tasks. To support the model evolution, design decisions need to be made explicit, and an appropriate representation for design decisions needs to be found that represents design decisions explicitly, reduces the overhead of capturing design decisions, keeps the model and the design decision documentation consistent and links the design decision to the model. • Consistent documentation of design decisions in multi view models: If models are available in multiple views, not only the models but also the documentation of the models needs to be consistent between the views. If a model is created automatically based on information from another model, a documentation might not be available for the newly created model and might need to be created manually.
1.2.1
Illustrative Example
Let us examine the problem in a simplified development scenario (see figure 1.1). A model of a new automotive brake-by-wire system is developed in MATLAB/Simulink (c.f. figure 1.2). Several design decisions are made while the Simulink model is refined, among them is the decision to replicate a subsystem to increase its reliability. After successful simulation of the model, a team of software developers will develop the corresponding source code. From the structure of the existing Simulink model they may generate source code directly or create a UML model. Tool integration technology translates the Simulink model into a corresponding UML model [23]. When the software engineers receive the UML model (see figure 1.2), they do not find any explanation for the duplicated PedalSensor elements, which have been
6
CHAPTER 1. INTRODUCTION
introduced intentionally into the Simulink model to improve the reliability of the brake system. However, this information is not expressed in the automatically generated UML model. Consequently the software engineers might remove one of the PedalSensors from the model, as they perceive it as an unnecessary redundancy.
Figure 1.1: Model exchange without design decision documentation (notation used: UML sequence diagram) The design decisions that were made and documented in the Simulink tool are not available when working with the automatically translated UML model. As a consequence, inconsistencies between models in multi-tool environments might be created, when models are translated automatically. The example illustrates that there is a need for supporting the integration of development tools, as well as for documenting the design decisions made during development.
Figure 1.2: Simplified brake-by-wire system with double redundancy
1.3
Objectives and Assumptions
The goal of this work is evaluating and improving the evolution of models in the context of model-driven development of automotive embedded systems. We focus on two aspects of model evolution:
1.4. RESEARCH QUESTIONS
7
• A model can evolve by changing the metamodel it conforms to. We study this aspect of model evolution in the context of tool integration. • A model can evolve by adding, deleting or changing model elements. We study this aspect of model evolution in the context of design decision documentation. We distinguish the following objectives: 1. Models need to be automatically adapted to tool-specific metamodel. This allows using models seamlessly in other tools than the model was originally created in. Both concepts and tools realizing tool-integration targeted for the domain of automotive embedded systems need to be developed. 2. The design decisions leading to changes in models need to be documented and linked to the model in a consistent manner. Both concepts and tools for supporting design decision documentation need to be developed. Besides the assumption of model-driven development to improve complexity management and development efficiency, we share the following assumptions with the involved research communities. The assumption of the tool integration research community is that the integration of development tools leads to increased productivity of heterogeneous engineering teams and higher quality of the developed products [221]. It is assumed that design decision documentation will help to manage evolution and improve the quality of the developed products.
1.4
Research Questions
The research question motivating this thesis is: How can we improve support for model evolution in model-driven development of automotive embedded systems? In the following we present two main research questions that focus on a certain aspects of the motivating question above. We decompose these questions further to direct and focus the work. 1. How can development tools used for the development of automotive embedded systems be integrated and exchange tool data? a) How can models be exchanged seamlessly between different tools? b) How can the data integration in a model-based tool integration solution be modularized and decomposed? c) What is the state of the art in model transformation technology? d) How can appropriate model transformation technology be selected and applied effectively in a model-based tool integration solution? 2. How can design decisions be documented in model-driven development?
8
CHAPTER 1. INTRODUCTION a) What is the state of the art in design rationale and design decision documentation? b) How can design decisions be represented in model-driven development? c) How can the documentation of design decisions be linked to the model elements affected by this decision? d) How can the double effort of both documenting design decisions and changing the model be reduced? e) How can design decisions be documented in models conforming to an arbitrary metamodel, without changing the metamodel?
1.5
Summary of Contributions
In this section we summarize the contributions of this thesis according to the research questions raised in section 1.4. RQ 1: How can development tools used for the development of automotive embedded systems be integrated and exchange tool data? We describe a method for modular, model-based data integration. We identify the different concerns addressed by data integration and use the principle of separation of concerns to decompose the data integration into separate modules: the technical space bridge and the structural bridge. For each bridge we select an appropriate model transformation technology. The basis for this selection is the survey of model transformation technologies. We apply this approach by integrating three development tools for automotive embedded systems: A systems engineering tool, a safety engineering tool and a simulation tool. RQ 2: How can design decisions be documented in model-driven development? We systematically survey and classify current approaches for design rationale and design decision documentation. We propose a design decision representation that is targeted to model-driven development. The design decision representation links documentation and model, lowers capture overhead through partial automation, ensures consistency between model and documentation through automation and is independent of a particular metamodel. We show in a case study how this representation can be used to document the stepwise refinement of models.
1.6
Thesis Outline
The rest of this document is structured as follows. Chapter 2 provides a brief overview of the state of the art in model-based and model-driven approaches, software architecture description, model-based tool integration and design decision documentation. Chapter 3 presents the research approach we took in this work, structured according to the two methodological research frameworks. Chapter 4 provides a summary of the approach and results of this work. In chapter 5 we discuss the
1.6. THESIS OUTLINE
9
implications of this work and review the work. Chapter 6 presents a plan for future work. Chapter 7 concludes this document with a summary.
Chapter 2
State of the Art and State of Practice The thematic map in figure 2.1 visualizes the areas of relevance for this work. For each of these areas, we provide an overview of the state of the art and the state of practice. In the later chapters of this thesis, we will use this map to place our work.
Figure 2.1: Thematic map
11
12
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
2.1
Model-Based and Model-Driven Approaches
Model-based and model-driven approaches use explicitly represented models as primary artifacts for describing a system [164]. During development, a series of such models is created, specified, refined and transformed. The models support various development activities, such as requirements engineering, architecture design, detailed design, analysis, simulation, implementation, testing and verification. The goals of these approaches are the management of complexity, the reduction of the risks of development, the improvement of the quality of the developed system and the improvement of the development efficiency. Model-based and model-driven development appear in the literature under multiple names [161]: • Model-based approaches focus on models as important artifacts for describing a system. Model-based engineering (MBE) and model-based systems engineering (MBSE) employ models for various engineering activities. Modelbased development (MBD) is a specialization of MBE with a focus on development activities. • Model-driven approaches are a specialization of model-based approaches. Models are the central artifacts that drive the development. This means that models are not just descriptive documentation, but they are used as construction tools. Model-driven approaches are commonly referred to as model-driven engineering (MDE), model-driven development (MDD) and model-driven software development (MDSD). • Model Driven Architecture (MDA) is a recommended practice for MDD proposed by the Object Management Group (OMG) [165], where a Platform Independent Model (PIM) is transformed into a Platform Specific Model (PSM). A PSM contains information about the chosen platform, a PIM is independent of a particular platform and describes the system in more general terms. A platform is a relative concept and can be used on several levels.
2.1.1
Terminology
Model: “A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system” [17]. Several kinds of models exist [161]: • Mental models are used by individuals for understanding and sense making. • Conceptual models are used for documenting and communicating.
• Formal/mathematical/analytical models are used to clarify and solve engineering problems and to make predictions of system properties.
2.1. MODEL-BASED AND MODEL-DRIVEN APPROACHES
13
• Constructive/executable models are used to specify detailed solutions, allowing partial automation. The models used in model-driven development are usually conceptual and constructive, since they serve both as documentation and specification. Different approaches for representing models exist [84]: • Domain-Specific Modeling Languages (DSML) capture the concepts in a certain domain and typically have a narrow scope [122, 153]. • General purpose modeling languages have a broad scope and are often standardized. An example is the Unified Modeling Language (UML) [170]. • Customizations of a general purpose modeling language are a compromise between the above options. An example is the UML profile mechanism, a lightweight extension for UML [170]. Model Elements: Models consist of several related model elements. Metamodel: A metamodel of a model X describes the abstract syntax that model X must follow to be valid. A metamodel can be compared to a grammar in language design. Precisely defined metamodels are a prerequisite for model transformations [151]. Metametamodel: A metametamodel of model X is the model describing the metamodel of model X [80]. It can be compared to the grammar of the language that is used to describe the syntax of the language X (e.g. BNF [129]). Standards and established implementations for metametamodels exist, such as MOF [166] and Ecore [194]. Metamodeling Levels M0-M3: The metamodeling levels are defined by the OMG [166]. They describe the conformance relation between objects of the real world (M0), models (M1), metamodels (M2) and metametamodels (M3), as depicted in figure 2.2: a model conforms to a metamodel and a metamodel conforms to a metametamodel. Metametamodels can be used for their own definition, a concept called meta-circularity [92]. Model Transformation: Model transformation is the “automatic generation of one or multiple target models from one or multiple source models, according to a transformation description” [152]. The model transformation description is expressed in a model transformation language, such as QVT [168] or ATL [116]. To produce the target model, the model transformation description is interpreted by a model transformation engine. A model transformation description can be modeled as well, so the model transformation description is conform to a model transformation metamodel (see figure 2.2). In the appended paper A we review the state of the art in model transformation, including the terminology, usage scenarios, a classification scheme of the
14
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
Figure 2.2: The metalevels of models and model transformations
problems that are solved by model transformations, a classification scheme of model transformation languages and an overview of several model transformation languages and engines. Syntax: The syntax describes how model elements may be composed to form valid models. We can distinguish between abstract and concrete syntax. The abstract syntax is a description of the structure that is independent of any particular representation or encoding. The concrete syntax is a mapping of an abstract syntax onto a particular representation or encoding. Semantics: The semantics defines the meaning of metamodel elements. Meaning is usually defined by mapping metamodel elements to concepts that already have a defined meaning. Technical Space: The technical space (also called technological space) of a model concerns the technology used for representation of the model [152, 137, 80]. Examples for technical spaces are EMF (Eclipse Modeling Framework) [194] or XML (Extensible Markup Language) [32]. Each technical space defines a metametamodel and a set of tools and technologies to work with models, metamodels and metametamodels. Level of Abstraction: A level of abstraction is a property of a model describing the amount of information contained in the model. While every model is an abstraction of the real world, a level of abstraction is defined by the amount of different questions that can be answered by a model. A model of a high level of abstraction answers less questions than a model of a low level of abstraction. Support for models of several levels of abstraction provides a mechanism for dealing with complexity. The term level of abstraction suggests that abstraction is discretized into several levels or steps (see section 2.2.3 for an example).
2.1. MODEL-BASED AND MODEL-DRIVEN APPROACHES
2.1.2
15
Model Evolution
Software evolution is a part of the software development life cycle [139] and deals with changes in software. The changes performed during software evolution have been classified into perfective, adaptive and corrective changes [143]. This classification has later been refined into evaluative, consultive, training, updative, reformative, adaptive, performance, preventive, groomative, enhancive, corrective and reductive changes [45]. Model evolution is a specialization of general software evolution; in the following we describe the aspects that are particular to the evolution of models. We classify model evolution by two orthogonal dimensions with each two categories and present the resulting 4 classes in table 2.1. Models can be described by their information content and their syntax, which is defined by a metamodel. Model evolution describes and manages changes in both aspects: • Content-related model evolution: The information content of models is changed, when model elements are added, modified or deleted. • Syntactic model evolution: The metamodel (or abstract syntax) of a model is changed, when metamodel elements are added, modified or deleted. Changes may affect the whole model or only a small part of the model. Model evolution can capture changes of different extent: • Local model evolution: A subset of the model is affected by the change. • Systemic model evolution: The whole model is affected by the change. Local
Systemic
Content-related (1) Adding/deleting/modifying of model elements e.g. [3]
Syntactic (2) Co-evolution of metamodels and models e.g. [182]
(3) Differencing/merging of models e.g. [47]
(4) Translation/synchronization of models to conform to other metamodels e.g. [4]
Table 2.1: Classification of model evolution In the following we provide some examples for using the characterization above: • Local content-related model evolution: A new model element is added to a model. • Local syntactic model evolution: The co-evolution of models and metamodels deals with the automatic evolution of models to cope with a given change in the metamodel [102, 100, 101, 218, 158].
16
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE • Systemic syntactic model evolution: A complete model is translated to conform to another metamodel.
2.1.3
State of Practice
The complexity of embedded systems puts heavy requirements on the development process that is used to build these systems. In addition, the improvement of efficiency and reduction of the cost of embedded systems development is a major concern for industrial practice [5, 6, 68]. In the industrial development of automotive embedded systems, documentbased approaches dominate and model-driven approaches are locally adopted in well-delimited projects, forming islands of model-driven development. A recent study claims that 37 % of embedded systems are developed model-based [26]. Model-driven and model-based approaches promise to manage the complexity inherent in the development of embedded systems, to improve efficiency, improve quality and to provide an early analysis and simulation of various system properties [69]. There is still no generalizable evidence that model-driven development fulfills the promises it makes in large-scale industrial applications [155]. Experiences with industrial case studies in the MODELWARE project report mixed results: While some projects report an improvement of efficiency, other projects report decreased efficiency due to insufficient tool support [154]. Support for long-term model evolution is especially relevant, when models have along lifetime. Automotive embedded systems have a development phase of 4-6 years, production phase of 5-6 years and an aftermarket support and service phase of 10-15 years. In a timespan of over 20 years the models of the embedded system change and evolve, a process which is not well supported today [35, 178, 184]. The four classes of model evolution identified in the previous section impose challenges on the use of model-driven development in practice. Dedicated model management systems are rarely applied, instead generic version management systems are used for modeling data.
2.2
Software Architecture Description
The architecture of a software-intensive system, such as an embedded system, is defined as “the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution” [110]. The architecture captures the early and important design decisions of the system under development [64]. The terminology and best practices regarding software and systems architecture are specified in the two standards for architectural description of software-intensive systems (IEEE/ANSI 1471-2000) [110] and ISO/IEC 42010:2007 [111].
2.2. SOFTWARE ARCHITECTURE DESCRIPTION
2.2.1
17
Views, Aspects and Consistency Checking
An architectural view is a representation of the system from the perspective of a related set of concerns [49, 110]. An architectural view provides a coherent selection and projection of the architecture according to the interests of a specific stakeholder. Views are intended to reduce the perceived complexity for a specific stakeholder. A viewpoint establishes the purpose of a view and the techniques or methods used for constructing the view [183, 110]. The viewpoint also specifies the conventions for interpreting, constructing and using an architectural view. The concept of aspect-orientation is related to the concept of views. Aspect orientation was first introduced as Aspect-Oriented Programming (AOP) [128] and has been extended to Aspect-Oriented Modeling (AOM) [83] to consider aspects on a higher level of abstraction than programming. Aspect-orientation applies the principle of separation of concerns to identify, isolate and localize crosscutting solutions. These crosscutting solutions are described separately in aspect models and a primary model. An integrated system model is created by weaving, i.e. composing selected aspects with the primary model. Views and aspects are both approaches to reduce the complexity of a complete system model by limiting or filtering the presented information. Views are usually only loosely related, whereas aspects are explicitly coupled and woven with each other. Different views describing the same system need to be consistent. If inconsistencies between views exist, they need to be detected and resolved. Consistency between two descriptions is defined as the coexistence of the two descriptions without contradiction. We can differentiate two types of consistency checking: (1) Consistency checking between artifacts of the same stage of the development process might for example check the consistency between UML state machines and UML sequence diagrams [150, 27]. (2) Consistency checking of artifacts from different stages of the development process might for example check the consistency between a class diagram (design stage) and source code (implementation stage) [156, 131, 46, 22, 177, 70, 71, 162, 157]. Instead of checking for consistency, other approaches have the goal of enforcing consistency, such as tool and data integration approaches (c.f. section 2.3).
2.2.2
Architecture Description Languages
Architectural Description Languages (ADLs) describe and formalize a high-level decomposition of a system in terms of structure and behavior. The essential elements of an architecture described by ADLs include components, connectors, interfaces, and their behavior [148]. ADLs can be used to perform analysis, verification, reasoning and quality assessment (e.g. completeness, consistency, performance, safety) early in the development process, when changes are comparably simple and cheap. A large number of ADLs have been introduced in the 90s, such as AADL/MetaH (by SAE and SEI), C2 (by UCI), Wright (by CMU), ACME (by CMU), Koala/-
18
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
Darwin (by Imperial College and Philips) and Rapide (by Stanford). Clements [50] describes the languages in an early survey. Medvidovic et al. [148] compare the language constructs provided by ADLs. El-khoury et al. [74] compare architecture description languages specifically for embedded systems. Hill et al. [105] compare the languages by their different levels of expressiveness. Some of the before mentioned ADLs are not in use any longer. Medvidovic explains the short lifetime of some ADLs with their focus on technological aspects and with their lack of consideration of the application domain, business context and development context. As a result, Medvidovic proposes domain-specific ADLs [147] focusing on a particular domain and business. Another report on the use of ADLs in practice stresses that ADLs need to align more closely with industrial software architecture practice [224]. The ADL approach can be combined with model-based and model-driven approaches. In this case, ADLs can be implemented as domain specific modeling languages (DSMLs) [122] or as profiles of the Unified Modeling Language (UML) [170].
2.2.3
EAST-ADL2 - An ADL for Automotive Embedded Systems
Problems in interdisciplinary communication often arise from the lack of a shared terminology [2]. A language with well-defined semantics that several disciplines can relate to establishes a common ground for interdisciplinary communication. EAST-ADL2 is an architecture description language for the domain of automotive embedded systems [59, 57]. In comparison to earlier architecture description languages (c.f. section 2.2.2), EAST-ADL is specific to one domain, the automotive domain, and is aligned with industrial practices and standards such as AUTOSAR and ISO 26262. EAST-ADL2 can be used to describe high-level abstract functions and both the computer hardware and the software architecture of an automotive embedded system. An EAST-ADL2 model comprises four levels that describe the same system from different viewpoints and on different levels of abstraction (see figure 2.3). • The Vehicle Level describes the system on high level of abstraction and contains a model of the electronic features of a car. A product line architecture can be realized using a hierarchical variability mechanism, feature modeling and feature configuration [179]. • The Analysis Level contains the Functional Design Architecture, which describes the system in terms of functions and their connection to the environment through sensors and actuators. • The Design Level contains the Functional Design Architecture and the Hardware Design Architecture. The Functional Design Architecture describes the software functions as a decomposition of the functions on analysis level. The
2.2. SOFTWARE ARCHITECTURE DESCRIPTION
19
Hardware Design Architecture describes the topology of the hardware. In addition, the allocation of software functions to hardware components is described. • The Implementation Level contains an AUTOSAR-conform implementation, where the functions of EAST-ADL2 are mapped to AUTOSAR Runnables.
Figure 2.3: EAST-ADL2 abstraction levels
Each involved discipline traditionally has its own view on the architecture and may prefer to work with a specific abstraction level of EAST-ADL2. Control engineers may prefer to work with a functional view of the system, provided by the analysis level, whereas software engineers may prefer the component-oriented view provided by design level and implementation level. Several language extensions for EAST-ADL2 exist, focusing on timing [203], environment modeling, behavior modeling, variability modeling, error modeling and requirement modeling. The EAST-ADL2 metamodel is implemented as a UML profile based on constructs inherited from UML [170], SysML [169] and AUTOSAR. Using the EAST-ADL2 profile for UML, it is possible to create and edit EASTADL2 models in UML design tools. EAST-ADL2 complements AUTOSAR (Automotive Open Software Architecture) [8] by providing a metamodel for describing the system at a higher level of abstraction. EAST-ADL2 has been developed collaboratively between industry and academia in the European research projects EAST-EEA, ATESST and ATESST2. In this work, EAST-ADL2 is used as the basis for our case-studies.
20
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
2.2.4
State of Practice
The software architecture in automotive embedded systems is growing in size and complexity, about 80% of all new functions introduced in cars today are softwarebased [184]. At a high-level of abstraction, reference architectures are used to describe the strategic and technical aspects of a vehicle, including product line strategies for reuse and the high-level decomposition of software and hardware of a vehicle, such as ECUs (Electronic Control Unit), communication buses and logic partitioning of functionality [178]. Reference architectures are usually provided in the form of text and schematic drawings. Functionality is decomposed and modularized into components. However, there is no traceability between the highlevel reference architecture and the low-level component implementation. AUTOSAR (Automotive Open System Architecture) [8] is an industry initiative to create a standard framework for the automotive software architecture including a component model and middleware platform. AUTOSAR decouples hardware and software through several abstraction layers and also standardizes the interfaces between different software components. As the interfaces are restricted to ensure interoperability, competitors can differentiate in functionality and implementation. In industrial practice, AUTOSAR is currently introduced in some components, partly for newly developed functionality, partly for migrated, existing legacy software [135].
2.3
Model-Based Tool Integration
The models used in model-driven approaches can be diverse, as they represent different views of the system with respect to the involved domains or lifecycle phases. The different models are supported by dedicated tools for editing, analyzing, simulating, report generation or code generation. These tools are often isolated and do not interact or exchange information. Tool integration is concerned with the relationships among tools, the properties of the relationship and the degree to which tools agree [201]. The goal of tool integration is building an engineering environment of several development tools [34]. The assumption of the research community is that an engineering environment with several integrated tools increases productivity and product quality [221]. A broad overview of the literature on tool integration is provided in the annotated bibliographies of Brown [34] and Wicks [222]. The scope of tool integration needs to be separated from the mechanisms used. We introduce the mechanisms for model-based tool integration in section 2.3.1. The scope of tool integration is defined using the following dimensions [219, 201]: • Data integration shares the data produced by different tools and manages the relationship between the data objects. • Control integration allows tools to notify and activate other tools.
2.3. MODEL-BASED TOOL INTEGRATION
21
• Presentation integration provides a common user interface with a common look-and-feel. • Process integration provides process management tools with data from development tools. • Platform integration provides a virtual operating environment for heterogeneous hardware and software. A specific kind of tool integration approach is model-based tool integration, which uses modeling technology, such as metamodels and model transformations, to realize data integration solutions. The tool data is stored in tool-specific models, which correspond to tool-specific metamodels. Model-based tool integration provides means for specifying and mappings between tool-specific metamodels to overcome semantic, syntactic and technical heterogeneities between the tools [119]. Tool integration technology is applied to build tool chains. A tool chain is a collection of tools that are integrated and interoperate seamlessly, so the output of one tool becomes the input of the next tool in the tool chain.
2.3.1
Approaches for Data Integration
In the following we focus on the dimension of data integration. Several mechanisms for realizing data integration using modeling technology have been proposed [119]. In this section we will introduce them briefly. Tool Integration Architectures There are two high-level architectures for data integration, as identified by Karsai et al. [120]. The first approach is based on point-to-point bridges between tools. The challenge is the number of bridges required for integrating multiple tools, as each tool needs to connect to each other tool. The second approach is based on a central repository and a common metamodel. Each tool requires only a single bridge to connect to the repository. The challenge of this approach is defining the information contained in the common metamodel. Ontologies and Information Models An ontology is defined as a ”formal, explicit specification of a shared conceptualization” [95]. This shared conceptualization provides a common reference for several tools [163, 217]. An example of a model-based tool integration approach using ontologies is the ModelCVS project. It maps tool-specific metamodels to an ontology and defines relationships between the tool-specific ontology elements [118, 117, 132]. Related approaches establish a common information metamodel for a specific domain, such as EAST-ADL2 [57] for the automotive embedded systems domain
22
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
and the CESAR Common Metamodel [13] for the embedded systems domain. Herzog [104] proposes a related approach for the exchange of systems engineering data using a common information model. Model Weaving and Aspect Orientation Composition based approaches focus on combining aspects from different models [16, 48]. Aspect oriented approaches weave aspect models that focus on a specific concern into a comprehensive model [83]. Aspects models are combined according to a weaving model, which specifies how models can be combined. Technologies for model weaving are XWeave [94] and AMW [61, 62, 60]. Model Transformations Model transformations have a central role in model-based and model-driven engineering, as they can be used to automate the creation and adaptation of models. Model transformation technology can be used for data integration, where model transformations describe mappings between tool-specific metamodels [208]. Several approaches explore the use of model transformation languages for data integration, for example the MOFLON language [4] and Eclipse-based languages [72]. Model synchronization approaches are a subgroup of model transformation approaches that have been used for data integration. Model synchronization enforces consistency between two or more models [93]. A change in either of the models triggers an appropriate, incremental update of the other model. Integration Languages When mappings between metamodels are defined, patterns of mapping rules can be identified that recur frequently. Integration languages leverage this knowledge by providing specialized language constructs for each integration pattern [88]. The CAR mapping language [180] is an example for an integration language based on patterns. Automated Mapping Generation using Heuristics Mappings between two metamodels can be computed automatically under the assumption that the metamodels are similar. So called matching algorithms compute mappings between two given metamodels. The approaches are heuristics, i. e. follow a best-effort strategy using metrics. Relevant metrics are structural similarity of the metamodels [79], naming similarities between metamodel elements or a combination of different metrics [63]. A domain specific language for specifying matching algorithms has been proposed [88].
2.3. MODEL-BASED TOOL INTEGRATION
23
Model Exchange Formats Several standards for model exchange formats have been proposed. There is the format XMI (XML Metadata Interchange) [167] defined by the OMG and the STEP Standard (ISO 10303) [113] with several application protocols. A relatively new initiative are the Open Services for Lifecycle Collaboration (OSLC or Open Services) [171, 223]. The initiative proposes standardized definitions for resource and interface descriptions for sharing engineering artifacts such as requirements. These standards and initiatives define the low-level structure of the elements to be exchanged, however, they do not define the mapping of data to existing tools. The standards are quite general and do not take domain-specific information into account. Data Management Approaches Data Management approaches provide a framework for data integration. However, they do not define how the data between specific tools is actually mapped. Also, each of the different classes of data management approaches are growing increasingly comprehensive in both scope and functionality. This results in an assimilation of the traditionally separate approaches, where a clear distinction is no longer apparent in all cases. In the following we present different types of data management approaches. • Model Management Platforms manage data in the form of models. They provide a model repository, model registry, model transformation tools, editing tools and browsing tools. Model management also provides operations on models, for example match, diff, copy, merge, compose, invert [14]. A model registry is provided for identifying, storing and retrieving both models and metamodels. An example of an early model management platform is Rondo [149]. It is increasingly recognized that not only the model, but also the mapping between different models needs to be managed by these platforms [15], resulting in an assimilation of model management platforms and integration platforms. • Integration Platforms provide a central data repository and several tool adapters. ModelBus [98] and Jazz [85] are examples of service-oriented integration platforms that provide storage and version management. They use web services, which can be orchestrated. The web services implemented in Jazz use a RESTful (Representational State Transfer) [81] architecture and conform to the specification of the OSLC initiative (Open Services for Lifecycle Collaboration) [171, 223]. • Software Change and Configuration Management (SCM) tracks and controls the changes in software source code that is developed in distributed settings [10]. In general, the integration aspects of SCM are limited to a common
24
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE database or repository for software artifacts and operations such as diff and merge. Examples of SCM systems are the Concurrent Versioning System (CVS) [214] and Subversion (SVN) [176]. • Product Data Management (PDM) integrates product-related data of mechanical products and associated work-flow processes. It serves as a central repository for the creation, management and publication of process and product history. It provides version management, change management and configuration management. An integration of PDM and SCM systems has been studied [55]. • Product Lifecycle Management (PLM) manages the product-related data for the entire life cycle from the conception of the product, through design and manufacturing, to service and disposal. • Application Lifecycle Management (ALM) integrates data from different software development activities and life cycle activities such as requirements management, architecture, coding, testing, tracking, and release management.
2.3.2
State of Practice
The development of embedded systems is a multi-disciplinary engineering effort. Engineers of a number of different disciplines need to contribute with their expertise in the development of automotive embedded system. Each of the disciplines uses its own set of tools, languages and metamodels to describe the embedded system from a disciplinary perspective [73, 127]. The views created by the different tools might contain redundant and inconsistent information. Manual translation, synchronization and updating of views lead to development inefficiencies. The lack of interoperability leads to gaps in the development process, high development costs and reduced product quality [185]. Especially the maturity of tool environments for model driven development and the lack of interoperability among tools are perceived as a hindrance for largescale industrial adoption of model-driven development [11]. A recent survey on the industrial use of tools in embedded systems development shows the lack of tool integration, traceability and documentation [112]. Islands of tool integration exist, for example between modeling tools and source code tools: UML modeling tools allow round trip engineering between models and source code. MATLAB/Simulink allows automatic code generation from models. In addition, a number of ad-hoc integration solutions for specific tools exist, often custom-created out of necessity for a specific company. A systematic integration of tools is desirable to reduce inconsistencies and increase the efficiency of development. However, the tools do not interoperate well and are often not designed to interoperate. There is a lack of systematic approaches for tool integration [204].
2.4. DESIGN DECISION DOCUMENTATION
2.4
25
Design Decision Documentation
Design decisions are the far reaching decisions that have an impact on the architecture and its description. Design decisions are usually made in the early phases of development and are hard to change later. Design rationale captures the reasoning underlying the creation and use of artifacts, such as models and model elements, and the reasoning underlying the design decisions [38]. Whereas the software architecture models focus on the “what”, design rationale and design decision documentation focus on the “why”. A number of approaches for representing design decisions exist. These different representations have varying degrees of formality and rigor. Informal representations document design decisions in the form of free text, use cases and videos [43]. Template-based approaches provide a guideline for textual descriptions of design decisions. An example is the template by Tyree and Akermann [209]. The majority of approaches structure design decisions according to a metamodel. These approaches explicitly represent the design deliberation process, including alternatives and arguments. Early approaches for design rationale and design decision representation are IBIS (Issue-Based Information Systems) [136], PHI (Procedural Hierarchy of Issues) [146], DRL (Decision Representation Language) [138] and QOC (Questions Options and Criteria) [145]. A number of web-based approaches for architectural knowledge management have been proposed for capturing design decisions. Examples are PAKME [9], ADkwik [186] and ADDSS [41]. These tools capture information about design decisions in web-forms and store them in a database. Approaches for representing design decisions that were developed in recent years focus on linking design decisions with the architecture description. The architecture and its design decisions are shown in the same environment. The SEURAT approach links design rationale to specific lines in the source code [37]. AREL is a UML profile that can be used to annotate architectural models with design decisions and rationale [199]. The Archium approach associates design decisions with modifications of the architecture [115]. These models provide descriptions, traceability and linking to other modeling elements. Rationale provides information both to the rationale author and to other stakeholders [190, 191]. Rationale provides a memory aid for the rationale author and it is also a means for communicating architectural knowledge to other stakeholders [52, 51, 99]. Rationale can be used for change management to predict the impact of a change in the architecture [38, 200]. Rationale improves both efficiency and correctness of the change impact analysis [31]. Rationale can improve maintenance activities, as it improves the understanding of the system and reduces the time needed for maintenance tasks [121, 40]. Rationale can document the assumptions of system components, this allows the safe reuse of the components in new systems [142, 220, 96]. Falessi et al. [77, 78] investigate empirically, in which cases rationale is useful for developers. They design a controlled experiment to test the perceived value of design decisions for performing different software engineering activities.
26
CHAPTER 2. STATE OF THE ART AND STATE OF PRACTICE
One of their findings is that there are big differences in perceived value, depending on which architectural element the rationale is associated with. The documentation of design decisions for safety-critical embedded systems systems has been investigated by Wu and Kelly [225] and by Leveson [141]. The lack of documentation of design decisions for embedded systems can lead to development delays, cost overruns, disruptions, upgrades and system evolution [140]. The documentation of safety-critical design decisions is on one hand intended to support the developers, on the other hand it is intended to be used for the certification of the product by authorities. The safety case concept of Kelly is targeted towards authorities and certification [123]. The intent specification [142] by Leveson is targeted towards developers. It organizes the information in a number of hierarchical views: the management view, customer view, system engineering view, component designer view, component implementer view and operations view. The views represent different levels of intent. Intent specifications have been used to document assumptions, rationale and traceability of software components to enable their safe reuse [220, 160]. Paper D provides an extended overview of the state of the art in design decision documentation.
2.4.1
State of Practice
Tang et al. [198, 197] study empirically how software professionals work with design rationale and design decision documentation. He found that software professionals recognize the importance of rationale for their work; however, they do not use dedicated tools for capturing and retrieving them. He also found that architects often omit to document their design decisions due to the involved overhead in time and effort. As a result, this knowledge about the architectural model is lost, a phenomenon known as knowledge vaporization [114]. While some dedicated representations and tool support for capturing design decisions have been proposed by academia, the capturing of design decisions and their rationale still creates additional overhead. The overhead caused by capturing design decisions is the main hindrance for consistent design decision documentation in practice [134]. The quality of documentation has a large effect on the quality of software [215]. Empirical studies have shown that inconsistent, outdated or missing documentation is a major cause of defects in development and maintenance [42, 174, 181, 53]. Documentation and architecture are often kept separate and evolve separately, so if the architecture changes, the technical documentation is not updated appropriately. The resulting separate documentation is an unreliable source of information [216]. This may result in inconsistencies, design erosion and architectural drift [207, 173, 175]. Maintenance accounts for 67 - 90 percent of the total cost of the software system [76, 108, 67, 226]. Maintainers spend most of their time understanding the existing system before they are able to change it. Design rationale and decision
2.5. CHAPTER SUMMARY
27
documentation has the potential to improve the maintainer’s understanding of the system [40]. The models used in model-driven development capture the outcome of the design process. The models do not explicitly capture the design decisions and reasoning behind the models. Currently, it is most common to complement the models with separate text or spreadsheet documents [112] that provide additional information regarding the models such as design decisions and design rationale. It is desirable that model-based development also supports metadata aspects such as design decisions [1] and to link the design decision documentation consistently with the model.
2.5
Chapter Summary
In this chapter we provided a brief overview of the state of the art in model-based and model-driven approaches, software and systems architecture, model-based tool integration and design decision documentation. Additional in-depth state of the art surveys can be found in appended paper A on model transformation technology and in appended paper D on design rationale and design decision documentation.
Chapter 3
Research Methods In the natural sciences, the research method usually comprises proposing a hypothesis, performing a controlled experiment and accepting or rejecting the hypothesis based on the outcome of the experiment [44]. Embedded systems development is a relatively young, multi-disciplinary field. Researchers use a number of research methods, for example case studies [82], field studies, literature studies, simulations, action research, proofs [65, 227], surveys, empirical studies, controlled experiments [202, 227, 12, 66]. Methodological frameworks are used to provide a high-level structure for the chosen research approach. Since research in embedded systems is multidisciplinary, we present two methodological frameworks from different fields relevant for research in embedded systems development: Shaw’s framework for software engineering research and Blessing’s framework for engineering design research. We apply both of the frameworks to structure the research approach presented in this thesis.
3.1
A Methodological Framework for Software Engineering Research
In general, software engineering seeks better ways to develop and evaluate software, motivated by practical problems, with key objectives being quality, cost and timeliness. Shaw [189] proposes a framework for describing a research approach in software engineering. She decomposes the research approach into research questions, research results and research validation. She then defines a classification for the different techniques that can be used to implement these components. • Research Question: To establish what is interesting to be researched, research questions are put forward. Typical research questions in software engineering can be classified according to their topic into methods of development, methods for analysis, design and evaluation of a particular instance, generalization or characterization schemes and feasibility studies. 29
30
CHAPTER 3. RESEARCH METHODS • Research Results: The answers to research questions are research results. Typical research results in software engineering can be classified into procedures or techniques (new or better ways to solve a problem), qualitative or descriptive models (taxonomy for a problem area, checklist), empirical models, analytic models (structural models for formal analysis and automatic manipulation), notations or tools (formal language and tool support for this language), specific solutions, judgments and reports. • Research Validation: The research results need to be validated. Validation can be accomplished through experience with the newly developed program or through systematic analysis [189]. The list of validation techniques used in software engineering includes case studies, formal analysis, empirical models, experiments and experience (the program is used by someone else and deemed correct, useful or effective). We add to Shaw’s framework the distinction between internal and external validation. Internal validation, also called verification, checks that the proposed solution fulfills the requirements, whereas external validation checks that the proposed solution fulfills the expectations.
3.2
A Methodological Framework for Engineering Design Research
Engineering design research has two objectives, the development of models and theories of design and providing tool support [28]. Blessing [28] proposes a design research methodology (DRM) as a framework to provide methods and guidelines for doing research in design. The DRM framework is composed of the following stages: • Research Clarification: The goal of this stage is to identify the topics of relevance and contribution, clarify the current understanding, clarify the research questions and create a research plan. • Descriptive Study 1: The goal of this stage is to gain an in-depth understanding of the existing situation, e.g. by a literature survey. • Prescriptive Study: The goal of this stage is to create support for improving the existing situation. • Descriptive Study 2: The goal of this stage is to evaluate the support developed in the prescriptive study.
31
3.3. RESEARCH METHODS IN THIS THESIS
3.3
Research Methods in this Thesis
In the previous sections, methodological frameworks for research in software engineering and engineering design have been introduced. In this section we apply these frameworks to describe the research work presented in this thesis. Table 3.1 presents the research in this thesis according to the framework proposed by Shaw [189]. For each tackled research question, we identify the type of research question, the type of research result and the type of research validation. Research Question RQ 1 RQ 2
Type of Research Question
Type of Result
Type of Validation
Method of Development and Particular Instance Method of Development and Feasibility Study
Method and Tool
Case Study
Descriptive Model, Notation and Tool
Case Study
Table 3.1: Classification of research questions, results and validation in this thesis according to section 3.1 In the following we apply the design research methodology introduced in section 3.2 to describe the research in this thesis. • Research Clarification: The research questions are refined into several more precise and more concrete questions. • Descriptive Study 1: The study of the existing situation and related approaches is done by literature study. • Prescriptive Study: The proposed improvements include a tool integration solution and a representation for documenting design decisions. • Descriptive Study 2: The proposed improvements are evaluated by examples and case studies by coming back to the research question. We arrange the steps in a circular way (see figure 3.1), to illustrate that several versions are developed and with each version we apply the learning from previous experiences. There are three such circles in this work. The first circle describes our approach for tool integration. The second circle describes the approach for design decision documentation. The third circle describes future work (see chapter 6). It uses the previous two circles as a foundation and combines the areas of tool integration and design decision documentation into an approach for exchanging models together with their documentation between different tools. In figure 3.1 we provide a reference to the section that describes the respective step.
32
CHAPTER 3. RESEARCH METHODS
Figure 3.1: Overview of the research approach
3.4. CHAPTER SUMMARY
3.4
33
Chapter Summary
To cover the scope of the multidisciplinary topic of research in embedded systems development, two methodological frameworks are presented in this chapter, one for software engineering research and another for engineering design research. We use these frameworks for structuring the research approach presented in this thesis.
Chapter 4
Approach and Results In this chapter we present the approach and results of this work, structured according to the research plan outlined in figure 3.1 on page 32. In the following we summarize the work for each research question and relate it to the appended publications. The publications appended to this thesis are in the fields of model-driven development, tool integration and the documentation of design decisions. Figure 4.1 visualizes the placement of the appended publications on the thematic map. In the following we briefly present the main points of each paper.
Figure 4.1: Appended publications on the thematic map
35
36
CHAPTER 4. APPROACH AND RESULTS
Paper A Matthias Biehl, “Literature Study on Model Transformations,” Technical Report, Royal Institute of Technology, ISSN 1400-1179, ISRN/KTH/MMK/R-10/07-SE, Stockholm, Sweden, July 2010. Paper A surveys the state of the art in model transformation technology. Model transformation is a central concept in model-driven development approaches, as it provides a mechanism for automating the manipulation of models. In this document we survey and classify existing model transformation technology. The classification differentiates between the problem space, i.e. characteristics of the problem to be solved by model transformation technology, and the mechanism, i.e. characteristics of the model transformation languages and engines. We show typical usage scenarios for model transformations and identify characteristics of the problems that can be solved with the help of model transformations. We synthesize a unifying classification scheme for model transformation languages based on several existing classification schemes. We introduce a selection of model transformation tools available today and compare them using our classification scheme.
Paper B Matthias Biehl, Chen De-Jiu, and Martin T¨ orngren, “Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), April 2010, pp. 125+. Paper B presents a tool integration approach for safety analysis using model transformations. The automotive industry has a growing demand for the seamless integration of safety analysis tools into the model-based development tool chain for embedded systems. This requires translating concepts of the automotive domain to the safety domain. We automate such a translation between the automotive architecture description language EAST-ADL2 and the safety analysis tool HiP-HOPS by leveraging the advantages of different model transformation techniques. By means of this integration, the safety analysis can be conducted early in the development process, when the system can be redesigned to fulfill safety goals with relatively low effort and cost.
Paper C Matthias Biehl, Carl-Johan Sj¨ ostedt, and Martin T¨orngren, “A Modular Tool Integration Approach - Experiences from two Case Studies,” in 3rd Workshop on
37 Model-Driven Tool & Process Integration (MDTPI2010), June 2010. Paper C reports the lessons learned from two tool integration approaches using model transformations. In the model-driven development process of automotive embedded systems a number of specialized tools are used to support various development tasks. Each tool needs to work seamlessly with artifacts created by other tools to increase the efficiency of development. We identify desirable properties for integrating the data of different tools. We then propose an approach for decomposing the data integration into modular steps that fulfill these properties. We report our experiences from applying this approach to integrate simulation capabilities and functionality for safety analysis into a model-based development environment.
Paper D Matthias Biehl, “Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions,” Technical Report, ISSN 1400-1179, ISRN/KTH/MMK/R-10/06-SE, Royal Institute of Technology, Stockholm, Sweden, July 2010. Paper D surveys the state of the art in design decision documentation and design rationale. In this document we provide an overview of the state of the art in documentation of design rationale and design decisions for architecture descriptions. We define the terminology of the area and compare the concept of rationale to similar concepts. We provide an overview of areas of contemporary research in design rationale. For each of the identified areas, we describe both the challenge and proposed solutions. Based on the findings from the literature we present benefits and inhibitors for using rationale and design decision documentation.
Paper E Matthias Biehl and Martin T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA2010), September 2010. Paper E proposes a representation for the purpose of documenting design decisions in model-driven development using model transformation technology. Design decisions are often tacit knowledge of an architecture and consequently they are easily lost during software evolution, a phenomenon known as knowledge vaporization. As a countermeasure, design decisions can be documented explic-
38
CHAPTER 4. APPROACH AND RESULTS
itly. However, documenting design decisions is expensive because they need to be captured in addition to the changes in the architecture. We propose an executable representation for design decisions using model transformations, which is independent of a particular component model or architectural description language. As a result, this provides the possibility to reduce knowledge vaporization. At the same time we prevent the high capturing cost, since the corresponding architectural change can be computed automatically.
Paper F Matthias Biehl, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in International Workshop on Models and Evolution (ME 2010), October 2010. Paper F applies executable design decisions in a case study to document the stepwise refinement of a model. During model refinement a wealth of knowledge about the model under development is accumulated that is only partly represented by the model itself. Design decisions and the considered modeling alternatives are neither represented by the model nor are they documented. During later lifecycle stages this information is often not available any more, which reduces the understandability of the model and potentially leads to inconsistencies and erosion of the model. We propose an approach to capture and store the design decisions in model-driven development. We represent design decisions as model transformations and propose tool support that applies this representation to capture design decisions with low effort. The captured design decisions provide a record of the model evolution and the rationale of the evolution.
4.1. TWO DIMENSIONS OF MODEL EVOLUTION
4.1
39
Two Dimensions of Model Evolution
In section 2.1.2 we introduced model evolution and characterized it. To support the evolution of models, we need to consider how models are created1 and changed. We visualize two different ways in which models can evolve in diagram 4.1. • A model Ma,0 can evolve by adding, deleting or modifying model elements, resulting in Ma,1 . This is depicted by the vertical arrow da,1 in equation 4.1. Both Ma,0 and Ma,1 correspond to the same metamodel Na . • A model Ma,0 can evolve by changing the metamodel it conforms to, resulting in Mb,0 . This is depicted by the horizontal arrow tab in equation 4.1. Both Ma,0 and Mb,0 correspond to different metamodels Na and Nb respectively. t
ab Ma,0 −−− −→ Mb,0 d y a,1
(4.1)
Ma,1 We will examine the two dimensions of model evolution in more detail. • The horizontal dimension of model evolution captures the systemic syntactical model evolution, according to the terminology introduced in section 2.1.2. It involves changing the metamodel that the model conforms to, while at the same time preserving the semantics of the model. This aspect of model evolution is also called model migration [192] and in the area of tool integration it is represented by the dimension of data integration [219]. Horizontal model evolution is often found in model-based tool integration scenarios and can be practically realized as a tool chain, where different tools exchange the information contained in tool-specific models. We use tool bridges involving model transformations to describe this dimension. They allow us to compute a model for a certain tool-specific metamodel from a model corresponding to another tool-specific metamodel. • The vertical dimension of model evolution captures the content-related model evolution, according to the terminology introduced in section 2.1.2. This includes operations on models, such as adding, deleting or changing of model elements. A design decision is made up of several such elementary operations. A sequence of several design decisions forms a decision chain. We use executable design decisions to describe this dimension of evolution. They allow us to establish a functional relationship between sequential versions of a model, and they allow us to compute a certain version of the model from a 1 Model creation can be considered to be a special case of model change, where the initial model is empty.
40
CHAPTER 4. APPROACH AND RESULTS previous version of the model. All versions of the model correspond to the same metamodel.
To clarify the two dimensions of model evolution, we describe them mathematically using algebra. Let metamodel Na be the tool-specific metamodel of tool Ta . Let Ma,i ∈ Na , i ∈ N be a model corresponding to metamodel Na . The index i is the refinement number of the model resulting from applying design decision da,i . Let da,i : Na → Na be a design decision for a model of type Na with Ma,i = da,i (Ma,i−1 ). Analogous definitions are made for tool Tb : Let Mb,i ∈ Nb , i ∈ N and db,i : Nb → Nb with Mb,i = db,i (Mb,i−1 ). We can now express any refinement j ∈ N of model Ma,j and Mb,j : Ma,j = (da,j ◦ da,j−1 ◦ ... ◦ da,1 )(Ma,0 )
(4.2)
Mb,j = (db,j ◦ db,j−1 ◦ ... ◦ db,1 )(Mb,0 )
(4.3)
and Let tab : Na → Nb be a tool bridge between the tools Ta and Tb . For a given version j of model Ma,j we can calculate the corresponding model Mb,j for tool Tb , as Mb,j = tab (Ma,j ). Diagram 4.4 provides a graphical representation of the relationship between models realizing different design decisions and models corresponding to different tool metamodels. On the left hand side is the refinement of model Ma using tool Ta , on the right hand side is the corresponding refinement of model Mb in tool Tb , where for any j the model Ma,j and Mb,j contain the same information. The concept is independent of the number of tools; in diagram 4.4 we exemplify the concept for two tools. t
ab Ma,0 −−− −→ Mb,0 d d y a,1 y b,1
t
ab . . . −−− −→ . . . d d y a,k y b,k
t
ab Ma,k −−− −→ Mb,k d d y a,k+1 y b,k+1
(4.4)
t
ab . . . −−− −→ . . . d d y a,j y b,j
t
ab Ma,j −−− −→ Mb,j
Diagram 4.4 visualizes the possible evolution paths of model Ma,0 into model Mb,j . In the following we describe one of the possible paths: An initial model Ma,0 ,
4.1. TWO DIMENSIONS OF MODEL EVOLUTION
41
which might be empty, is developed in tool Ta . It is refined by making design decisions da,1 , .., da,k , resulting in model Ma,k . To develop model Ma,k further, tool Tb has to be used; thus model Ma,k needs to evolve into model Mb,k . The tool bridge tab is used to evolve Ma,k into Mb,k . Further design decisions db,k+1 , .., db,j are made in tool Tb , resulting in model Mb,j , the final model of development. An example of a real-world evolution scenario matching the formal description above, is described in section 1.2.1. A model of a new automotive brake-by-wire system is developed in MATLAB/Simulink (c.f. figure 1.2). Several design decisions are made while the Simulink model is refined (da,1 , .., da,k ), among them is the decision to replicate a subsystem to increase its reliability. From the structure of the existing Simulink model either source code or a UML model might be generated. Tool integration technology (tab ) translates the Simulink model into a corresponding UML model [23]. Afterwards the UML model is refined (db,k+1 , .., db,j ). In this scenario both horizontal and vertical model evolution occur. In the following sections we describe work on supporting both horizontal and vertical model evolution. In section 4.2 we present work on horizontal model evolution, which was performed in the context of tool integration for automotive embedded systems development with the architecture description language EAST-ADL2. Horizontal model evolution changes the abstract or concrete syntax of a model, but keeps the information contained in the model unchanged. In section 4.3 we present work on vertical model evolution, which was done in the context of design decision documentation. Vertical model evolution changes the information contained in a model, but keeps the abstract and concrete syntax of the information unchanged. In this work both the horizontal and the vertical dimension of model evolution are described by model transformations. The dimension of horizontal model evolution is realized by tool bridges using exogenous model transformations. The dimension of vertical model evolution is realized by executable design decisions using endogenous model transformations.
42
CHAPTER 4. APPROACH AND RESULTS
4.2
Horizontal Model Evolution: Tool Integration in Automotive Embedded Systems Development
This section addresses RQ 1 : How can development tools used for the development of automotive embedded systems be integrated and exchange tool data?
Figure 4.2: Approach for RQ 1 We use model-based tool integration mechanisms in order to realize support for early verification and analysis in model-driven development of automotive embedded systems with EAST-ADL2. In the following we focus on data integration, which is one of the five dimensions of tool integration [219]. To realize data integration in our case, a design-oriented EAST-ADL2 model has to evolve into an analysis-oriented model, involving a change of the metamodel. This allows the analysis of EAST-ADL2 models without requiring extensive knowledge of analysis methodologies, languages and tools. As a result, the tools for design and for analysis are integrated into a partial tool chain.
4.2.1
Requirements and Analysis
In this section, we first describe the requirements for data integration and introduce an architecture for data integration that is based on model transformation. We then describe how we use this architecture to realize partial tool chains for the early analysis of EAST-ADL2 models using the tool HiP-HOPS for safety analysis and the tool MATLAB/Simulink for simulation. Desirable properties and requirements of data integration are: • Automation of the integration to improve the efficiency and correctness of the data integration. • Transparency of the integration to the user. • Evolvability of the integration to deal with the evolution of the integrated tools.
4.2. HORIZONTAL MODEL EVOLUTION: TOOL INTEGRATION IN AUTOMOTIVE EMBEDDED SYSTEMS DEVELOPMENT
43
We work under the assumption that the tools themselves cannot be changed to accomplish the data integration. Instead we use an adapter to make the data of tool B available to tool A. The adapter expresses the data of tool B in such a way that it can be used by tool A. In this case, tool A is the target tool and tool B is the source tool. In some cases, the bidirectional exchange of tool data is of interest, where both tools need to work with the tool data of the respective other tool. During data integration some properties of the data need to be changed, while other properties need to be preserved. The following properties of the data might need to be changed by data integration: • Change of the abstract syntax: The structure or syntax of the data might need to be adapted to the target tool. The information of the source tool needs to be rearranged and reinterpreted to adhere to the structure expected by the target tool. This step is independent of the technical space used by the target tool. • Change of the technical space: Models can be represented using different technical spaces, such as XML, EMF or text-based grammars. The information needs to be represented by the technical space expected by the target tool. The above mentioned properties are orthogonal to each other and can be changed independently. It is for example possible to change the technical space, while preserving the abstract syntax of a model. The following properties of the data might need to be preserved for data integration: • Preservation of the graphical layout: Models are often presented to the user in a graphical form. The user can convey information by the graphical placement of model elements. For this reason the graphical layout should be preserved by data integration. • Preservation of the semantics: To preserve the semantics of a model in tool integration, there needs to be an overlap of the semantics between source and target metamodel. A data integration is semantics preserving if the meaning of source and target models is the same, even though it is represented in a different technical space or using a different abstract syntax. If the integrated tools are similar, the overlap in semantics of the metamodels is usually given and a semantics preserving data integration can be found. If the integrated tools are so different that there is little overlap in semantics between source and target metamodel, the mapping between the tools might only approximate a preservation of the meaning of the model. If the integrated tools are fundamentally different, there is no overlap in semantics and a preservation of the semantics might be impossible.
44
CHAPTER 4. APPROACH AND RESULTS
4.2.2
Solution
We use technology of model-based tool integration to realize data integration. We describe tool data with metamodels and express the correspondence between tool data of different tools in the form of model transformations. In our solution we use the principle of separation of concerns to structure the data integration in such a way that the independence of the two issues for changing the data is ensured. We propose an approach for decomposing the data integration into two bridges, connected by an intermediate model (see figure 4.3). • The technical space for integration is chosen as a platform for the integration. The technical space for integration is independent of the technical space of any particular tool. • The intermediate model is the tool-specific model that representS tool data in the technical space for integration. For each integrated tool we define an intermediate model. The structure of the intermediate model is similar to the structure of the tool data. Intermediate models correspond to intermediate metamodels. • The technical space bridge changes the technical space. It has the purpose of translating data between the technical space of the tool and the technical space of the intermediate model. Technical space bridges can be realized for example by model-to-text transformations and text-to-model transformations (parsers); a list of the different mechanisms is provided in paper C. Since the intermediate model is defined to have a structure similar to the tool data, technical space bridges preserve the structure of the tool data. • The structural bridge maps corresponding elements of the intermediate model of one tool to the intermediate model of another tool in a semantics-preserving way. To establish the semantics-preserving correspondence, an understanding of the semantics of both intermediate metamodels and their corresponding tools is required. Model-to-model transformations are used as a mechanism for realizing structural bridges. For structural bridges we assume: – the semantics of source and target metamodel overlap, so a semanticspreserving mapping can be found. – relevant tool data is available as an intermediate model in a common technical space for integration. In figure 4.3 we visualize how we use these concepts to realize a partial tool chain involving the simulation tool MATLAB/Simulink, the systems engineering language EAST-ADL2 and the safety analysis tool HiP-HOPS. In this tool chain, the data of Simulink is first translated into an intermediate model using a technical space bridge, then a structural bridge maps concepts to EAST-ADL2. No technical space bridge is required for EAST-ADL2, as the data of EAST-ADL2 is natively
4.2. HORIZONTAL MODEL EVOLUTION: TOOL INTEGRATION IN AUTOMOTIVE EMBEDDED SYSTEMS DEVELOPMENT
45
represented in the technical space of integration. To integrate EAST-ADL2 with HiP-HOPS, a structural bridge maps the data of EAST-ADL2 to the intermediate model of HiP-HOPS. A technical space bridge maps the concept to the tool-specific format of HiP-HOPS.
Figure 4.3: Technical Space Bridges and Structural Bridges To implement the bridges, we select model transformation technology that suits each of the bridges individually. A large number of model transformation languages, engines and tools are available, which have different characteristics that can be relevant for certain transformation tasks. An overview and a classification of model transformation technology is presented in the appended paper A. Important factors in the selection of a model transformation tool are the support of the technical spaces involved and the properties of the transformation tool. To validate the presented tool integration approach, we perform two case studies that connect EAST-ADL2 to MATLAB/Simulink and to the safety and reliability analysis tool HiP-HOPS. We report on the common experiences from these integration approaches in appended paper C. The automotive industry has a growing demand for the seamless integration of safety analysis tools into the model-based development tool chain for embedded systems. This requires translating concepts of the automotive domain to the safety domain. We automate such a translation between the automotive architecture description language EAST-ADL2 and the safety analysis tool HiP-HOPS by using model transformations and by leveraging the advantages of different model transformation techniques. By means of this integration, safety analysis can be conducted early in the development process, when the system can be redesigned to fulfill safety goals with relatively low effort and cost. We study the tool integration approach between EAST-ADL2 and HiP-HOPS in depth in appended paper B.
46
CHAPTER 4. APPROACH AND RESULTS
The latest version of the integration between HiP-HOPS and EAST-ADL2 considers the crosscutting nature of safety in embedded systems (see section 1.1.1). Embedded systems consist of both hardware and software components and a description of the allocation of software components to hardware components. The system as a whole needs to be safe and reliable, so both software and hardware aspects need to be considered by a safety analysis. Since safety is a crosscutting system property, it is not sufficient to analyze the safety for software and hardware components separately. On the contrary, we need to consider the interaction and relationship between software and hardware components for a safety analysis of the system. This comprehensive view is relevant for the accuracy of safety analysis, as the software may be able to detect and mitigate hardware problems. We use the architecture description of EAST-ADL2, which describes software components, hardware components and the allocation of software to hardware components. We export this crosscutting view of the system including software and hardware to HiP-HOPS using structural and technical space bridges. As a result, the safety analysis tool HiP-HOPS can analyze the system as a whole, considering software aspects, hardware aspects and their interaction.
4.2.3
Related Work
Data integration in the context of model-based tool integration can be realized by a number of mechanisms, as introduced in section 2.3.1. When model transformations are used as a mechanism for data integration, a usual assumption is that both source and target models are represented in the same technical space. Thus, many approaches focus only on the structural bridge [72, 130, 60]. The MOFLON tool integration approach [4], however, is similar to our approach, as it differentiates between tool adapters, which correspond to technical space bridges, and transformation rules, which are comparable to structural bridges. The MOFLON approach uses model transformations with triple graph grammars and MOF as the technical space for integration. A tool integration approach for the automotive domain with a similar architecture integrates SysML and AUTOSAR using bidirectional model synchronization [91]. It translates between two design models of different level of abstraction to support the synthesis process. Thus, it has a different goal than our approach. Our approach translates between a design model in EAST-ADL2 and analysis models in Simulink and HiP-HOPS to allow early verification through simulation and safety analysis. Our approach defines mappings for data integration on metamodel (M2) level. Approaches for metametamodel (M3) level bridges provide a high degree of automation, as both metamodels and transformation rules for structural bridges can be generated automatically from a mapping of concepts on metametamodel level [126, 125, 124, 36]. However, to achieve the high level of automation, some assumptions have to be made: (1) The target metamodel cannot be user-defined, but needs to be generated automatically as part of the approach. (2) This approach
4.3. VERTICAL MODEL EVOLUTION: DESIGN DECISION DOCUMENTATION FOR MODELS
47
only considers homogeneous tools from the same domain with only structural differences and cannot be used for heterogeneous tools where semantics-preserving mappings need to be specified based on domain knowledge. (3) The approach does not consider technical space bridges. These three assumptions are not fulfilled in the case of the data integration of EAST-ADL2, HiP-HOPS and Simulink.
4.3
Vertical Model Evolution: Design Decision Documentation for Models
This section addresses RQ 2 : How can design decisions be documented in modeldriven development?
Figure 4.4: Approach for RQ 2 Models are developed by making a number of design decisions and subsequently updating the model to reflect the design decisions. The effect, which the design decision has on the model, is captured by the model. However, the knowledge about the design decision itself, such as the fact that a design decision was made, why it was made and what the decision was, is usually not made explicit. Thus, this knowledge is easily lost, a phenomenon known as knowledge vaporization [29]. However, this knowledge is often critical for continued development and maintenance. As a countermeasure, design decisions can be documented explicitly. The main inhibitors are the overhead induced by capturing design decisions and the lack of proper tool support [198, 197]. Model-driven development follows the paradigm of using models to represent, store, analyze and simulate architectural knowledge. However, design decisions do not have an explicit representation in model-driven development, yet.
4.3.1
Requirements and Analysis
Desirable properties and requirements of design decision documentation for models are:
48
CHAPTER 4. APPROACH AND RESULTS • Explicit documentation of the design decision, for example by a textual description. • Applicability for an arbitrary metamodel: it should not be necessary to change existing metamodels to document design decisions. • Low capture overhead: the effort for linking the documentation to the model should be low. • Link between the design decision documentation and the model: a link between the design decision documentation, the context of the design decision and the model elements affected by the design decision. • Consistency between the design decision documentation and the model: the change described by the design decision documentation should be consistently realized in the model.
Oliver [164] stresses the importance of executable models, i.e. models that can be interpreted by engineers as well as by computers. It is the basis for automating engineering activities and can support the decision making of the engineer, both in terms of quality and efficiency. We thus propose an executable representation of design decisions in this work, called Executable Design Decisions. To achieve executability of a design decision representation, a couple of things have to be in place: The design decisions need to be described with sufficient detail, so they can be executed. An interpreter needs to be available that can execute the description of design decisions and can produce a modified architecture as output. Using a generative approach, the representation of design decisions has a double function: it can be used both for synthesis and for documentation of the model.
4.3.2
Solution
We propose to use model transformations as an executable representation of design decisions. Model transformations can be executed, the result of the execution is the changed architectural model. This has the advantage that design decisions only need to be captured in the form of a model transformation and the change in the architecture is merely a cause of the execution of the transformation. Model transformations can be used for models conforming to different metamodels. Thus, this approach is not bound to a specific notation. It can be applied to architectural models that are described using existing metamodels or architecture description languages. Model transformations provide a mechanism for representing important parts of the design decisions. Figure 4.5 illustrates the correspondence between the concepts of model transformation and the concepts of design decisions. In order to identify to what extent design decisions can be represented by model transformations, we examine which information is required for the representation of design decisions. As an orientation, we use the ontology of architectural design decisions by Kruchten [133]. According to this ontology, the description of a design
4.3. VERTICAL MODEL EVOLUTION: DESIGN DECISION DOCUMENTATION FOR MODELS
49
Figure 4.5: Model transformation as a mechanism for representing parts of a design decision decision comprises a description of the decision, the scope of the decision, the rationale of the decision, cost, risk, author, timestamp and state. We found that the elements of the design decision ontology can be partly represented by model transformations: • The scope of the decision describes the context, in which the decision is defined. In the ontology, Kruchten lists different interpretations of the scope, such as system scope, time scope and organization scope. We focus here on the system scope. The context is the precondition under which the design decision can be applied and executed. The context corresponds to the matching patterns or the left-hand side of the model transformation rule. • The outcome of the decision can be expressed by the right hand-side of a model transformation rule. The outcome describes the added, changed or deleted model elements. The outcome of a decision can also be regarded as the postcondition of the decision. In summary, the core of the design decision, consisting of the decision itself and its application context, can be described by model transformations. The model transformation as a representation of design decisions fulfills two functions simultaneously: documenting the design decision and changing the architecture by executing the transformation. The design decision representation is compatible with existing metamodels, as long as they can be processed by model transformation tools. The additional elements mentioned in the ontology of design decisions, can be regarded as an extension to the core of the decision. We store them textually in a separate data structure called Design Decision Management Container (DDMC). This container is used for managing the metadata of each design decision in textual form, such as rationale, cost, risk, author, timestamp and state. Furthermore, the DDMC points to the model transformation realizing the decision.
50
CHAPTER 4. APPROACH AND RESULTS
In the following we present some of the properties of the proposed executable representation of design decisions: • We explicitly represent technical design decisions that have an effect on the model. • Design decisions are represented independently of a certain modeling language. Model transformations can be specified for any metamodel without needing to change the metamodel. • In stepwise model refinement the capturing of design decisions comprises four steps: 1. Performing an update of the model, so it reflects the new design decision 2. Documenting where in the model the change applies and what is changed 3. Documenting the rationale of the change 4. Linking the documentation to the model elements affected by the change The overhead of these steps is one of the main reasons why design decisions are not documented [134]. Tools can help to reduce the overhead for the modeler, by exploiting the intrinsic relation between steps (1), (2) and (4). A model transformation has a precondition and a postcondition that can be used for documenting where in the model the change applies and what is changed (2). When the model transformation is executed on the initial model, the outcome is the updated model (1). The precondition of the model transformation links the design decision documentation to the model before the change and the postcondition links the design decision documentation to the model after the change (4); this link can even be automatically documented by the transformation engine in the form of trace links. In summary, a model transformation is capable of capturing steps (1), (2) and (4) by a single representation and only step (3) needs to be captured separately. • The documentation of design decisions is linked to the model elements affected by the decision. The core of the executable design decision is a model transformation, which describes both the context in which the design decision can be made and the effect that the design decision will have on the model. The executable design decision is thus linked to the model elements that are affected by the decision. • Document-based approaches separate documentation from the system model. Due to this separation, the model and the documentation can evolve separately. Over time, the documentation is prone to become inconsistent with the model and may contain contradictions, inconsistency, incompleteness, redundancy and incorrectness. In document-based approaches, information is not traceable, so the origin and effect of the information cannot be easily
4.3. VERTICAL MODEL EVOLUTION: DESIGN DECISION DOCUMENTATION FOR MODELS
51
retrieved. On the contrary, the proposed documentation of design decisions ensures consistency with the architectural model. Since we use model transformations to represent design decisions, we can execute the design decision representation and inspect the effect the design decision has on the model. As a consequence of this automation, the model and the design decision representation are automatically synchronized and consistent. We evaluate the approach by a case study in the context of models for automotive embedded systems. We demonstrate that it is feasible to express design decisions using different model transformation formalisms. The design decision can be described using endogenous, in-place model-to-model transformations. We used both ATL [116] and Tiger EMF [25] in the case study.
4.3.3
Related Work
A number of different approaches for representing design decisions have been proposed by academia. They can be split into informal representations, templatebased approaches and structural approaches, as introduced in section 2.4. These approaches are targeted towards general software development and can be applied for model-driven development as well. However, they do not take the properties of model-driven development into account and do not use the possibilities of modeldriven development, such as the enforcement of consistency and possibilities for automation. Thus, these approaches do not fulfill all requirements for design decision documentation for models put forth in the previous section: • Explicit documentation of the design decision: The approaches for design decision documentation introduced in section 2.4 fulfill this requirement. • Applicability for an arbitrary metamodel: The Archium [115] approach associates design decisions with modifications of the architecture. However, it requires that the Archium metamodel is used. Navarro et al. propose the ATRIUM metamodel for model-driven development [159]. The important metaclasses have text attributes for design decision and design rationale. Specific metamodels can provide the possibility for specifying design rationale together with the model. However, the approach requires a change in the metamodel, which might not be possible, when a given metamodel or language needs to be used. • Low capture overhead: AREL is a UML profile that can be used to annotate architectural models with design decisions and rationale [199]. However, the links between models and design decision documentation need to be established and maintained manually. Thus, the capture overhead is relatively high. • Link between the design decision documentation and the model: Approaches for representing design decisions that were developed in recent years focus on
52
CHAPTER 4. APPROACH AND RESULTS linking design decisions with the architectural model. Older approaches, such as IBIS, PHI and QOC do not link decisions with affected model elements. • Consistency between the design decision documentation and the model: The SEURAT approach links rationale to specific lines in the source code [37]. If source code lines are added, the link to the source code is inconsistent. Comments in UML diagrams do not enforce the consistency between the change in a model and a design decision documented in the UML comment [170].
4.4
Chapter Summary
In this chapter we presented the approach and results of this work. We identified two dimensions of model evolution that handle different types of changes in models: • Horizontal model evolution: We presented an approach for data integration, using a common metamodel to connect specialized tools and their models. We decomposed data integration into modular bridges for adapting both the structure and the technical space. We applied this approach to build a partial tool chain for automotive embedded systems development involving a systems engineering tool, a safety analysis tool and a simulation tool. • Vertical model evolution: We proposed a representation for design decision documentation in model-driven development. We first identified a number of requirements for the representation. We then showed to which extent these requirements are met by our proposed executable design decision representation for models and compared it to related work.
Chapter 5
Discussion In this chapter we discuss the limitations, open issues and additional possibilities for application of the concepts in a different context.
5.1
Horizontal Model Evolution
Graphical Information Models are often presented to the user in a graphical form. In graphical modeling, meaning can be conveyed by the graphical placement of model elements. The graphical layout can convey that certain elements belong together by placing them close to each other on the drawing canvas. When translating the model to another formalism or tool, this layout information might need to be preserved. One possible thread of future work could be the consideration of layout information for data integration of models.
Combination with other Tool Integration Technology In section 2.3 we introduced a number of approaches for tool integration, among them the tool integration platforms ModelBus and Jazz. These approaches provide a repository with access control and mechanisms for control integration, but are not concerned with the tool-specific mapping of tool data. Our approach is focused on defining metamodels and data integration through model transformation, so it could be synergistic to combine both approaches. Common metamodels for data integration are defined both in a domain-specific way, such as EAST-ADL or the CESAR Common Metamodel and in a domainindependent way, for example by the OSLC initiative or the STEP standard. It might be useful to compare the domain-specific metamodels EAST-ADL and the CESAR Common Metamodel with the generic resource definitions of OSLC [223]. 53
54
CHAPTER 5. DISCUSSION
Choice of Model Transformation Technology If two tools in a tool integration solution need to access data of the respective other tool, bidirectional model transformations can be used for realizing the structural bridge. Bidirectional model transformation languages allow the expression of mappings between two metamodels that can be executed in both directions, from A to B and from B to A. As only one model transformation description is sufficient to express the mapping of both execution directions, the mapping between the languages could be expressed more concisely by a bidirectional transformation. The integration of MATLAB/Simulink and EAST-ADL2 is bidirectional, thus a bidirectional transformation language could be used. However, for technical reasons a bidirectional model transformation language could not be used, since the tools available at that time did not natively support the UML profile of EAST-ADL2. For the integration between HiP-HOPS and EAST-ADL2, only a unidirectional mapping is required.
Modularization of Model Transformation by Separation of Concerns In paper A we show that the model transformation language needs to be appropriate to the problem we intend to solve by means of model transformation technology. In paper C we show how a complex tool integration problem can be solved by decomposing it into several simpler problems first. We use the principle of separation of concerns for decomposing the transformation and then choose an appropriate technology for each partial problem. This modularization approach may also be applicable to reduce the complexity of other model transformation problems. The approach can be summarized as follows: • Identification of the different concerns handled by the transformation. • Decomposition of the model transformation problem into a set of partial problems using the principle of separation of concerns. • Selection of appropriate model transformation languages and technologies for each partial problem. • Definition of an intermediate metamodel that serves as an interface between the transformations of partial problems. • Usage of external composition [56], which is used to combine the partial transformations to a transformation chain. The decomposition allows both using the advantages of different model transformation technologies and prepares the solution for evolution. The identified concerns may evolve separately without affecting each other, so only a partial transformation is affected by changes. The decomposition supports evolvability and the use of appropriate technology.
5.2. VERTICAL MODEL EVOLUTION
55
Model Transformation Co-Evolution The definition of metamodels is central to model-driven development. The models and the model transformations are dependent on the definition of the metamodels and need to be adapted if the metamodel changes. The co-evolution of models and metamodels has been studied widely and solutions exist for adapting models automatically to cope with metamodel changes [102, 100, 101, 218, 158]. In a data integration solution, not only the model, but also the model transformations used for data integration need to co-evolve with the metamodel. The proposed model transformation solution with separation of concerns simplifies the co-evolution with the metamodel, as concerns can evolve separately without necessarily affecting other concerns. From our experiences, the decomposition of the model transformation supports the co-evolution of the model transformation with the metamodel, when the metamodel changes frequently. The model transformation between EAST-ADL2 and HiP-HOPS, described in the appended papers B and C, needed to co-evolve with several changes in both the EAST-ADL2 and HiP-HOPS metamodels. After an initial tool integration was built, the HiP-HOPS language changed from a text-based representation to an XML representation, so the data integration solution needed to be adapted. Due to the modular organization of our model transformation, the necessary changes affected only the technical space bridge, leaving the structural bridge unaffected. Thus, the decomposition supported the co-evolution of model transformations.
Practical Evaluation The tool integration approach has been evaluated by creating tool support for the integration of three different development tools: MATLAB/Simulink, HiP-HOPS, PapyrusUML with the EAST-ADL profile. We have evaluated the tool support for integration with small case studies. This can be complimented with an additional evaluation using industrial sized case studies.
5.2
Vertical Model Evolution
Limitations The classification scheme for design rationale described in paper D differentiates between technical and non-technical rationale and between the different levels of justification (R0 - Artifact Level, R1 - Decision Level, R2 - Decision Rationale Level, R3 - Rationale Rationale Level). In this work, we focus on the first level of justification provided by design decisions, also called the R1-level. Rationale on R2 and R3 level include decision rationale and trade-off decisions and are not considered in this work. We also focus on technical design decisions that can be linked to the
56
CHAPTER 5. DISCUSSION
architectural model. Non-technical design decisions, such as managerial decisions about staffing or project management are not considered in this work.
Comparison to Version Management There are three basic approaches for capturing model evolution: state-based, changebased and operation-based approaches [103]. • State-based approaches save snapshots of the model as versions or states. They are used widely today in the form of version management and software configuration management systems, such as CVS or SVN. A survey on model versioning [3] provides a list of criteria and a comparison of state of the art state-based approaches for model versioning. • Change-based approaches represent the differences between two models. • Operation-based approaches record the operations that transfer one version of a model into another one. These approaches can be differentiated by the precision of the tracked changes. State-based approaches may use data mining techniques to extract trace links from the history of the versioning system [58]. Since the used data mining approaches for extracting the traces are heuristics, they can only provide an approximation. Operation based approaches can track the changes in models with a higher precision than the other approaches [103], due to precise trace links. The documentation of design decisions with our approach for Executable Design Decisions is an operationbased approach, as it is based on capturing change by operations in the form of model transformations. The traces generated by a model transformation are a more reliable source of information than the traces extracted by heuristics.
Practical Evaluation In our case studies we have shown that it is feasible to represent design decisions using model-transformations and that the approach is usable. The next step is an evaluation of the usefulness of this representation. More descriptive work can be done to practically evaluate the proposed methods and tools. • A larger academic or industrial case study can be performed to learn about potential challenges in the practical application. • An industrial case study can show if design decision documentation using model transformations can be used in current industrial practices or which changes to current practices would be necessary. • An empirical study can examine if design decision documentation actually improves maintenance tasks and by how much. Other empirical studies on design decision documentation support these claims [77, 78]. Bratthall et al.
5.3. GENERAL
57
[31] studied the impact of design rationale on maintenance work in an empirical study. When design rationale was present, the time spent on maintenance tasks was reduced and the correctness was improved compared to the case without design decision documentation. Another independently performed empirical study [121] supports these findings.
5.3
General
Model-Driven Development Model-driven and model-based approaches promise to manage the complexity inherent in the development of embedded systems, to improve efficiency, improve quality and to provide an early analysis and simulation of various system properties [69]. However, there is still no generalizable evidence that model-driven development fulfills the promises it makes in large-scale industrial applications [155]. This thesis does not provide generalizable evidence, but shows possibilities how model-driven development can contribute to issues that are insufficiently addressed in general, such as tool integration and the consistent documentation of design decisions. The technology and methodology of model-driven development enable the proposed solutions.
Scope and Applicability The work on tool integration and design decision documentation has been performed in the context of model-driven development of automotive embedded systems. The developed methods and concepts are independent of the automotive domain. The proposed methods and concepts can be transferred to other domains that use model-driven development.
Chapter 6
Future Work In this chapter we provide a plan for future work, including a list of research questions guiding the work. Figure 6.1 visualizes the placement of the future work in the overlap of the areas of relevance. In future work we would like to address: • Documenting design decisions in multi-tool environments. • Reusing design decisions as design decision patterns. • Reconstructing design decisions from model differences. • Supporting management and evaluation of design decisions.
Figure 6.1: Future work on the thematic map
59
60
6.1
CHAPTER 6. FUTURE WORK
Design Decision Documentation in Multi-Tool Environments
With the current approach of adopting model-based tool integration technology, the focus is on exchanging models between tools. In this process, important meta-data of the models, such as rationale and design decisions, may be lost. This makes the models hard to understand and may lead to model inconsistencies, model erosion and maintenance problems. We propose an integrated approach for documenting design decisions during model refinement and automatically transferring not only models but also the associated design decision documentation between different tools. As a result, design decision documentation can be linked consistently to corresponding model elements of the various tool-specific models, easing model evolution across several development tools. So far, the documentation of design decisions is not a major concern in tool chain approaches. Model-based tool integration approaches focus on translating tool-specific models, not the associated design decisions. If a design decision documentation exists for a tool-specific model A, and the model is translated into another tool-specific model B, the design decision documentation of A is not automatically translated and linked to model B. Documented design decisions in model A are lost when continuing development with the automatically translated model B. We would like to find out if it is possible to transfer a design decision documentation from tool A to tool B in such a way that the design decision documentation will be linked to corresponding model elements in both tools. We would also like to automate this transfer of the design decision documentation. We propose to combine ideas from design decision documentation and from model-based tool integration.
6.2
Design Decision Patterns
Our representation of design decisions explicitly documents the context and the outcome of the design decision, where the context is specific to one particular location in the associated model. For a given executable design decision we can modify the description of the context to make the design decision applicable in another context. By widening the context and introducing parameters into the context description, the design decision becomes a design decision pattern. Using the representation of executable design decisions, design decision patterns can be represented as model transformations with parameters and organized in a catalog of design decision patterns. The patterns of this catalog can potentially be reused in different projects. Design decision patterns also provide a way to formally represent design pattern [87], which are typically described textually.
6.3. DESIGN DECISION RECONSTRUCTION FROM MODEL DIFFERENCES
6.3
61
Design Decision Reconstruction from Model Differences
New design decisions can be entered into the system in three ways: (1) creating a new executable design decisions manually, this involves writing a model transformation to describe the change, (2) reusing an existing executable design decision by instantiating a design decision pattern and binding its parameters to specific values, (3) calculating an executable design decision from the model difference to a previous version. The last options allows designers to work with the model as usual and retrospectively extract the executable design decision from the model difference. This retrospective analysis of design decisions can also be used for extracting design decisions from a version management system. This can be used for assessing commonly used design decisions in embedded systems and for eliciting decision patterns.
6.4
Design Decision Management
The design decision documentation needs to be stored, archived and managed, especially for large projects with many design decisions. To achieve this, our representation for a design decision documentation can be embedded into an information structure for managing several design decisions and their relations. Such a management infrastructure can also represent additional information, such as design alternatives and trade-offs. We envision a decision management system similar to CVS that stores sequences of executable design decisions. It allows storing several design decisions as sequences of executable design decisions. Thus, the model corresponding to the design decisions up to any chosen point in the sequence can be calculated. In addition, it is possible to add, change or remove a design decision at an arbitrary point in the sequence. The subsequent design decisions in the sequence can take this change into account. This can be used as a tool for change impact analysis, since the impact of a modified or newly introduced design decision on the system and on other design decisions can be assessed. The management infrastructure also allows expressing alternative options for each design decision. A design decision can be evaluated and compared against its alternatives by automatically analyzing the model produced by it. The effect a design decision has on certain system property can be evaluated immediately using the analysis described in section 4.2. This allows making an analysis-based assessment of the design decisions using what-if-scenarios.
6.5
Research Questions
The research questions for guiding the future work are: How can design decision documentation be managed and used in scenarios with multiple integrated tools?
62
CHAPTER 6. FUTURE WORK 1. How can a model-based tool integration approach be extended to exchange the design decision documentation in addition to the tool-specific model? In which engineering scenarios does the transfer of design decision documentation make sense? 2. How can design decisions be captured and stored as reusable design decision patterns? 3. How can executable design decisions be reconstructed from model differences or from a model version history? 4. How can design decisions be managed? How can we evaluate and compare alternative design decisions using automated analysis of system properties?
Chapter 7
Concluding Remarks This thesis is an intermediate milestone, many open issues and areas of future work exist. In this chapter we summarize the main contributions of this work. This thesis has the goal to support model evolution in model-driven development of automotive embedded systems. To support model evolution, we first identify two dimensions of model evolution that handle different types of changes in models, as illustrated in diagram 7.1. • A model Ma,0 can evolve by changing the metamodel it conforms to, resulting in Mb,0 . This is depicted by the horizontal arrow tab in equation 4.1. This type of evolution is called horizontal model evolution. • A model Ma,0 can evolve by adding, deleting or changing model elements, resulting in Ma,1 . This is depicted by the vertical arrow da,1 in equation 4.1. This type of evolution is called vertical model evolution. t
ab Ma,0 −−− −→ Mb,0 d y a,1
(7.1)
Ma,1 In this thesis we propose support for both horizontal and vertical model evolution: • RQ 1: How can development tools used for the development of automotive embedded systems be integrated and exchange tool data? This question addresses horizontal model evolution, where models evolve by being translated. Models are adapted to conform to other metamodels and thus become accessible in other tools. We present an approach for tool integration that focuses on the dimension of data integration. The approach uses a common metamodel to connect specialized tools and their models. We 63
64
CHAPTER 7. CONCLUDING REMARKS identify the separate concerns addressed by a data integration approach and use the principle of separation of concerns to decompose the data integration into separate modules: the technical space bridge and the structural bridge. For each bridge we select an appropriate model transformation technology. The basis for this selection is a systematic survey of model transformation technologies. We apply this approach in a case study and integrate several tools for automotive embedded systems development: A systems engineering tool, a safety engineering tool and a simulation tool. • RQ 2: How can design decisions be documented in model-driven development? This question addresses vertical model evolution, where models evolve by adding, deleting or changing model elements. We systematically survey approaches for design rationale and design decision documentation as a means for manging and documenting vertical evolution. We propose a design decision representation that is targeted to model-driven development. This design decision representation links documentation and model, lowers capture overhead through partial automation, ensures consistency between model and documentation through automation and is independent of a particular metamodel. We show in a case study how this representation can be used to document the stepwise refinement of models.
For future work, we plan to combine approaches for horizontal and vertical model evolution to support model evolution in multi-tool environments. We extend the tool integration approaches (horizontal dimension) to not only transfer models between different tools, but to also transfer design decision documentation (vertical dimension). Consistent design decision documentation can thus be made available across corresponding models in the tool chain.
Bibliography [1]
Adamsson, Niklas, “Model-based Development of Mechatronic Systems - Reducing the Gaps between the Competencies?” in Proc. of the TCME, April 2004.
[2]
Adler, Terry, Black, Janice A., and Loveland, John P., “Complex Systems: Boundary-Spanning Training Techniques,” Journal of European Industrial Training, vol. 27, pp. 111–124, 2004.
[3]
Altmanninger, Kerstin, Seidl, Martina, and Wimmer, Manuel, “A Survey on Model Versioning Approaches,” Johannes Kepler University Linz, Tech. Rep., 2009. [Online]. Available: http://smover.tk.uni-linz.ac.at/docs/IJWIS09 paper Altmanninger.pdf
[4]
Amelunxen, C., Klar, F., A. K¨ onigs, T. R¨ otschke, and A. Sch¨ urr, “Metamodel-based tool integration with MOFLON,” in ICSE ’08, 2008, pp. 807–810. [Online]. Available: http://dx.doi.org/10.1145/1368088.1368206
[5]
ARTEMIS Industry Association, “ARTEMIS strategic research agenda,” ARTEMIS, Tech. Rep., 2006. [Online]. Available: https://www. artemisia-association.org/downloads/SRA MARS 2006.pdf
[6]
——, “ARTEMIS strategic research agenda - design methods and tools,” ARTEMIS, Tech. Rep., 2006. [Online]. Available: https://www.artemisia-association.org/ downloads/RAPPORT DMT.pdf
[7]
Augsburg, Tanya, Becoming Interdisciplinary: An Introduction to Interdisciplinary Studies. Kendall/Hunt Publishing Company, January 2005. [Online]. Available: http://www.worldcat.org/isbn/0757515614
[8]
AUTOSAR Consortium. Automotive open software architecture (AUTOSAR). [Online]. Available: http://autosar.org/
[9]
Babar, Muhammad A., Northway, Andrew, Gorton, Ian, Heuer, Paul, and Nguyen, Thong, “Introducing Tool Support for Managing Architectural Knowledge: An Experience Report,” in IEEE International Conference on the Engineering of Computer-Based Systems, vol. 1. Los Alamitos, CA, USA: IEEE, 2008, pp. 105–113. [Online]. Available: http://dx.doi.org/10.1109/ECBS.2008.27
[10]
Babich, Wayne A., Software Configuration Management: Coordination for Team Productivity. Addison Wesley Longman, February 1986. [Online]. Available: http://www.worldcat.org/isbn/0201101610
65
66
BIBLIOGRAPHY
[11]
Baker, Paul, Loh, Shiou, and Weil, Frank, “Model-Driven Engineering in a Large Industrial Context - Motorola Case Study,” in Model Driven Engineering Languages and Systems, ser. Lecture Notes in Computer Science, Briand, Lionel and Williams, Clay, Eds., vol. 3713. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2005, pp. 476–491. [Online]. Available: http://dx.doi.org/10.1007/11557432 36
[12]
Basili, Victor R., “The role of experimentation in software engineering: past, current, and future,” in ICSE ’96: Proceedings of the 18th international conference on Software engineering. Washington, DC, USA: IEEE Computer Society, 1996, pp. 442–449. [Online]. Available: http://portal.acm.org/citation.cfm?id=227818
[13]
Baumgart, Andreas, “A common meta-model for the interoperation of tools with heterogeneous data models,” in 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI2010) at the European Conference on Modelling Foundations and Applications (ECMFA2010), June 2010.
[14]
Bernstein, P., “Applying model management to classical meta data problems,” 2003. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10. 1.1.12.772
[15]
Bernstein, Philip A. and Melnik, Sergey, “Model management 2.0: manipulating richer mappings,” in SIGMOD ’07: Proceedings of the 2007 ACM SIGMOD international conference on Management of data. New York, NY, USA: ACM, 2007, pp. 1–12. [Online]. Available: http://dx.doi.org/http://doi.acm.org/10.1145/ 1247480.1247482
[16]
J. B´ezivin, Bouzitouna, Salim, Del Fabro, Marcos, Gervais, Marie P., F. Jouault, Kolovos, Dimitrios, Kurtev, Ivan, and Paige, Richard F., “A Canonical Scheme for Model Composition,” in Model Driven Architecture Foundations and Applications, 2006, pp. 346–360. [Online]. Available: http://dx.doi.org/10.1007/11787044 26
[17]
J. B´ezivin and O. Gerb´e, “Towards a Precise Definition of the OMG/MDA Framework,” in ASE ’01: Proceedings of the 16th IEEE international conference on Automated software engineering. Washington, DC, USA: IEEE Computer Society, 2001, p. 273.
[18]
Biehl, Matthias, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in Proceedings of the International Workshop on Models and Evolution (ME 2010), October 2010.
[19]
——, “Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions,” Royal Institute of Technology, Tech. Rep. ISRN/KTH/MMK/R-10/06-SE, July 2010.
[20]
——, “Literature Study on Model Transformations,” Royal Institute of Technology, Tech. Rep. ISRN/KTH/MMK/R-10/07-SE, July 2010.
[21]
Biehl, Matthias, DeJiu, Chen, and M. T¨ orngren, “Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), April 2010, pp. 125+.
BIBLIOGRAPHY
67
[22]
Biehl, Matthias and W. L¨ owe, “Automated Architecture Consistency Checking for Model Driven Software Development,” in Proceedings of the Fifth International Conference on the Quality of Software Architectures (QoSA 2009), June 2009, pp. 36–51. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02351-4 3
[23]
Biehl, Matthias, C.-J. Sj¨ ostedt, and M. T¨ orngren, “A Modular Tool Integration Approach - Experiences from two Case Studies,” in 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI 2010) at the European Conference on Modeling Foundations and Applications (ECMFA 2010), June 2010.
[24]
Biehl, Matthias and M. T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2010), September 2010.
[25]
Biermann, E., Ehrig, K., C. K¨ ohler, Kuhns, G., Taentzer, G., and Weiss, E., “Graphical definition of in-place transformations in the Eclipse Modeling Framework,” in MODELS 2006, vol. 4199, 2006, pp. 425–439. [Online]. Available: http://dx.doi.org/10.1007/11880240 30
[26]
BITKOM, “Studie zur Bedeutung des Sektors Embedded-Systeme in Deutschland,” BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V., Tech. Rep., November 2008. [Online]. Available: http://www.bitkom. org/files/documents/Studie BITKOM Embedded-Systeme 11 11 2008.pdf
[27]
Blanc, Xavier, Mounier, Isabelle, Mougenot, Alix, and Mens, Tom, “Detecting model inconsistency through operation-based model construction,” in ICSE 2008. New York, NY, USA: ACM, 2008, pp. 511–520. [Online]. Available: http://dx.doi.org/http://doi.acm.org/10.1145/1368088.1368158
[28]
Blessing, Lucienne T. M. and Chakrabarti, Amaresh, DRM, a Design Research Methodology, 1st ed. Springer, June 2009. [Online]. Available: http://www.worldcat.org/isbn/1848825862
[29]
Bosch, Jan, “Software Architecture: The Next Step,” Software Architecture, vol. 3047, pp. 194–199–199, 2004. [Online]. Available: http://dx.doi.org/10.1007/ 978-3-540-24769-2 14
[30]
Bradley, D. A., “The what, why and how of mechatronics,” Engineering Science and Education Journal, vol. 6, no. 2, pp. 81+, 1997. [Online]. Available: http://dx.doi.org/10.1049/esej:19970210
[31]
Bratthall, Lars, Johansson, Enrico, and B. Regnell, “Is a Design Rationale Vital when Predicting Change Impact? A Controlled Experiment on Software Architecture Evolution,” in PROFES ’00: Proceedings of the Second International Conference on Product Focused Software Process Improvement. London, UK: Springer-Verlag, 2000, pp. 126–139. [Online]. Available: http: //portal.acm.org/citation.cfm?id=713240
[32]
Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M., Maler, Eve, and F. Yergeau, “Extensible markup language (XML) 1.0 (fifth edition),” W3C, Tech. Rep., November 2008. [Online]. Available: http://www.w3.org/TR/REC-xml
68
BIBLIOGRAPHY
[33]
Brooks, “No Silver Bullet Essence and Accidents of Software Engineering,” Computer, vol. 20, no. 4, pp. 10–19, April 1987. [Online]. Available: http://dx.doi.org/10.1109/MC.1987.1663532
[34]
Brown, Alan W. and Penedo, Maria H., “An annotated bibliography on integration in software engineering environments,” SIGSOFT Softw. Eng. Notes, vol. 17, no. 3, pp. 47–55, 1992. [Online]. Available: http://dx.doi.org/10.1145/140938.140944
[35]
Broy, Manfred, “Challenges in automotive software engineering,” in ICSE ’06: Proceedings of the 28th international conference on Software engineering. New York, NY, USA: ACM, 2006, pp. 33–42. [Online]. Available: http: //dx.doi.org/10.1145/1134285.1134292
[36]
H. Bruneli`ere, Cabot, Jordi, C. Clasen, F. Jouault, and J. B´ezivin, “Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools,” in Modelling Foundations and Applications, ser. Lecture Notes in Computer Science, T. K¨ uhne, Selic,, Bran, Gervais,, Marie-Pierre, and F. Terrier, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2010, vol. 6138, ch. 5, pp. 32–47. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-13595-8 5
[37]
Burge, J. E. and Brown, D. C., “An Integrated Approach for Software Design Checking Using Rationale,” in Proc. Design Computing and Cognition Conference, Cambridge, MA, 2004.
[38]
Burge, Janet E., Carroll, John M., McCall, Raymond, and I. Mistr´ık, RationaleBased Software Engineering, 1st ed. Springer, May 2008. [Online]. Available: http://www.worldcat.org/isbn/354077582X
[39]
Buur, J., “A theoretical approach to mechatronics design,” Ph.D. dissertation, Technical University of Denmark, 1990.
[40]
Capilla, Rafael, Nava, Francisco, and J. C. Due˜ nas, “Modeling and Documenting the Evolution of Architectural Design Decisions,” in SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007, p. 9. [Online]. Available: http://dx.doi.org/http: //dx.doi.org/10.1109/SHARK-ADI.2007.9
[41]
Capilla, Rafael, Nava, Francisco, S. P´erez, and J. C. Due˜ nas, “A web-based tool for managing architectural design decisions,” Sw. Eng. Notes, vol. 31, no. 5, pp. 4+, 2006. [Online]. Available: http://dx.doi.org/10.1145/1163514.1178644
[42]
Card, D. N., McGarry, F. E., and Page, G. T., “Evaluating Software Engineering Technologies,” IEEE Trans. Softw. Eng., vol. 13, no. 7, pp. 845–851, 1987. [Online]. Available: http://dx.doi.org/10.1109/TSE.1987.233495
[43]
Carroll, John M., Alpert, Sherman R., Karat, John, Van Deusen, Mary, and Rosson, Mary B., “Raison d’Etre: capturing design history and rationale in multimedia narratives,” in CHI ’94, 1994, pp. 192–197. [Online]. Available: http://dx.doi.org/10.1145/191666.191741
[44]
Chalmers, A. F., What Is This Thing Called Science?, 3rd ed. Hackett Pub Co, January 1999. [Online]. Available: http://www.worldcat.org/isbn/0702230936
BIBLIOGRAPHY
69
[45]
Chapin, Ned, Hale, Joanne E., Khaled Md, Ramil, Juan F., and Tan, Wui G., “Types of software evolution and software maintenance,” Journal of Software Maintenance, vol. 13, no. 1, pp. 3–30, January 2001. [Online]. Available: http://portal.acm.org/citation.cfm?id=371701
[46]
Christl, Andreas, Koschke, Rainer, and Margaret Anne, “Automated clustering to support the reflexion method,” Information & Software Technology, vol. 49, no. 3, pp. 255–274, 2007. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2006.10. 015
[47]
Cicchetti, Antonio, Di Ruscio, Davide, and Pierantonio, Alfonso, “A Metamodel Independent Approach to Difference Representation,” JOT: Journal of Object Technology, October 2007. [Online]. Available: http://www.jot.fm/issues/ issue 2007 10/paper9/index.html
[48]
S. Clarke, “Extending standard UML with model composition semantics,” Sci. Comput. Program., vol. 44, no. 1, pp. 71–100, July 2002. [Online]. Available: http://dx.doi.org/10.1016/S0167-6423(02)00030-8
[49]
Clements, Paul, Bachmann, Felix, Bass, Len, Garlan, David, Ivers, James, Little, Reed, Nord, Robert, and Stafford, Judith, Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional, September 2002. [Online]. Available: http://www.worldcat.org/isbn/0201703726
[50]
Clements, Paul C., “A Survey of Architecture Description Languages,” in IWSSD ’96: Proceedings of the 8th International Workshop on Software Specification and Design. Washington, DC, USA: IEEE Computer Society, 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=858261
[51]
Clerc, Viktor, Lago, Patricia, and van Vliet, Hans, “Global Software Development: Are Architectural Rules the Answer?” Global Software Engineering, International Conference on, vol. 0, pp. 225–234, 2007. [Online]. Available: http://dx.doi.org/10.1109/ICGSE.2007.21
[52]
Conklin, E. Jeffrey and Yakemovic, K. C. Burgess, “A process-oriented approach to design rationale,” Hum.-Comput. Interact., vol. 6, no. 3, pp. 357–391, 1991. [Online]. Available: http://dx.doi.org/10.1207/s15327051hci0603%5C&4 6
[53]
Cook, C. and Visconti, M., “Documentation is important,” CrossTalk, vol. 7, no. 11, pp. 26–30, 1994.
[54]
Crnkovic, Ivica, “Component-based Software Engineering - New Challenges in Software Development,” in Proceedings of the 25th International Conference on Information Technology Interfaces 2003 (ITI 2003), vol. 2, 2001, pp. 127–133. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29. 2203
[55]
Crnkovic, Ivica, Asklund, Ulf, and Dahlqvist, Annita P., Implementing and integrating product data management and software configuration management, ser. Artech House computing library. Artech House, 2003. [Online]. Available: http://www.worldcat.org/isbn/1580534988
70
BIBLIOGRAPHY
[56]
J. Cuadrado and J. Molina, “Modularization of model transformations through a phasing mechanism,” Software and Systems Modeling, 2009. [Online]. Available: http://dx.doi.org/10.1007/s10270-008-0093-0
[57]
Cuenot, Philippe, Frey, Patrik, Johansson, Rolf, H. L¨ onn, Papadopoulos, Yiannis, Reiser, Mark-Oliver, Sandberg, Anders, Servat, David, Kolagari, Ramin T., M. T¨ orngren, and Weber, Matthias, “The EAST-ADL Architecture Description Language for Automotive Embedded Software,” Model-Based Engineering of Embedded Real-Time Systems, 2010.
[58]
Dantas, Cristine R., Murta, Leonardo G. P., and Werner, Claudia M. L., “Consistent Evolution of UML Models by Automatic Detection of Change Traces,” in IWPSE ’05: Proceedings of the Eighth International Workshop on Principles of Software Evolution. Washington, DC, USA: IEEE Computer Society, 2005, pp. 14–147. [Online]. Available: http://dx.doi.org/10.1109/IWPSE.2005.10
[59]
Debruyne, Vincent, F. Simonot-Lion, and Trinquet, Yvon, “EAST-ADL: An architecture description language,” in Architecture Description Languages, ser. IFIP The International Federation for Information Processing. Springer Boston, 2005, ch. 12, pp. 181–195. [Online]. Available: http://dx.doi.org/10.1007/ 0-387-24590-1 12
[60]
Del Fabro, Marcos, J. B´ezivin, and Valduriez, Patrick, “Model-Driven Tool Interoperability: An Application in Bug Tracking,” in On the Move to Meaningful Internet Systems 2006: CoopIS, DOA, GADA, and ODBASE , ser. Lecture Notes in Computer Science, Meersman, Robert and Tari, Zahir, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2006, vol. 4275, ch. 53, pp. 863–881. [Online]. Available: http://dx.doi.org/10.1007/11914853 53
[61]
Del Fabro, Marcos D., J. B´ezivin, F. Jouault, and Breton, Erwan, “AMW: A generic model weaver,” in Premiered Journees sur l’Ingenierie Dirigee par les Modeles, July 2005. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.108.1294
[62]
Del Fabro, Marcos D., J. B´ezivin, and Valduriez, Patrick, “Weaving models with the Eclipse AMW plugin,” in In Eclipse Modeling Symposium, Eclipse Summit Europe, 2006. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.100.7255
[63]
Del Fabro, Marcos D. and Valduriez, Patrick, “Towards the efficient development of model transformations using model weaving and matching transformations,” Software and Systems Modeling, vol. 8, no. 3, pp. 305–324, July 2009. [Online]. Available: http://dx.doi.org/10.1007/s10270-008-0094-z
[64]
T. Dingsøyr and van Vliet, Hans, “Introduction to Software Architecture and Knowledge Management,” in Software Architecture Knowledge Management, Ali Babar, Muhammad, T. Dingsøyr, Lago, Patricia, and Vliet, Hans, Eds. Berlin, Heidelberg: Springer-Verlag, 2009, ch. 1, pp. 1–17. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 1
[65]
Dodig-Crnkovic, Gordana, “Scientific methods in computer science,” in Conference for the promotion of research in IT. Department of Computer Science, 2002. [Online]. Available: http://gordana.se/work/cs method.pdf
BIBLIOGRAPHY
71
[66]
Easterbrook, Steve, Singer, Janice, Storey, Margaret-Anne, and Damian, Daniela, “Selecting Empirical Methods for Software Engineering Research,” in Guide to Advanced Empirical Software Engineering, Shull, Forrest and Singer, Janice, Eds. London: Springer London, 2008, ch. 11, pp. 285–311–311. [Online]. Available: http://dx.doi.org/10.1007/978-1-84800-044-5 11
[67]
Eastwood, A., “Firm fires shots at legacy systems,” Computing Canada, vol. 19, no. 2, p. 17, 1993.
[68]
Ebert, Christof and Jones, Capers, “Embedded Software: Facts, Figures, and Future,” Computer, vol. 42, no. 4, pp. 42–52, April 2009. [Online]. Available: http://dx.doi.org/10.1109/MC.2009.118
[69]
Ebert, Christof and Salecker, Juergen, “Embedded Software Technologies and Trends,” IEEE Software, vol. 26, no. 3, pp. 14–18, 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.70
[70]
Egyed, Alexander, “Validating Consistency between Architecture and Design Descriptions,” March 2002.
[71]
Egyed, Alexander and Medvidovic, Nenad, “Consistent Architectural Refinement and Evolution using the Unified Modeling Language,” March 2001.
[72]
Ehrig, Karsten, Taentzer, Gabriele, and Varro, Daniel, “Tool integration by model transformations based on the Eclipse Modeling Framework,” in EASST Newsletter, vol. 12, 2006. [Online]. Available: http://mycite.omikk.bme.hu/doc/16597.pdf
[73]
El-khoury, J., Redell, O., and M. T¨ orngren, “A Tool Integration Platform for Multi-Disciplinary Development,” in 31st EUROMICRO Conference on Software Engineering and Advanced Applications. IEEE, 2005, pp. 442–450. [Online]. Available: http://dx.doi.org/10.1109/EUROMICRO.2005.10
[74]
El-khoury, Jad, Chen, DeJiu, and M. T¨ orngren, “A Survey of Modelling Approaches for Embedded Computer Control Systems,” Royal Institute of Technology, KTH, Stockholm, Sweden, Tech. Rep., 2003.
[75]
Eppinger, Steven and Salminen, Vesa, “Patterns of Product Development Interactions,” in INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01, 2001. [Online]. Available: http://dspace.mit.edu/bitstream/ handle/1721.1/3808/Eppinger-Salminen Patterns WkgPpr 2001.pdf?sequence=2
[76]
Erlikh, Len, “Leveraging Legacy System Dollars for E-Business,” IT Professional, vol. 2, no. 3, pp. 17–23, 2000. [Online]. Available: http://dx.doi.org/http: //dx.doi.org/10.1109/6294.846201
[77]
Falessi, Davide, Cantone, Giovanni, and Kruchten, Philippe, “Value-Based Design Decision Rationale Documentation: Principles and Empirical Feasibility Study,” in WICSA ’08: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008). Washington, DC, USA: IEEE Computer Society, 2008, pp. 189–198. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2008.8
[78]
Falessi, Davide, Capilla, Rafael, and Cantone, Giovanni, “A value-based approach for documenting design decisions rationale: a replicated experiment,” in SHARK
72
BIBLIOGRAPHY ’08: Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge. New York, NY, USA: ACM, 2008, pp. 63–70. [Online]. Available: http://doi.acm.org/10.1145/1370062.1370079
[79]
J.-R. Falleri, Huchard, Marianne, Lafourcade, Mathieu, and C. Nebut, “Metamodel Matching for Automatic Model Transformation Generation,” in Model Driven Engineering Languages and Systems, ser. Lecture Notes in Computer Science, Czarnecki, Krzysztof, Ober, Ileana, Bruel, Jean-Michel, Uhl, Axel, and Voelter, Markus, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, vol. 5301, ch. 24, pp. 326–340. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-87875-9 24
[80]
Favre, Jean M., “Towards a basic theory to model model driven engineering,” in In Workshop on Software Model Engineering, WISME 2004, joint event with UML2004, 2004.
[81]
Fielding, Roy T., “Architectural Styles and the Design of Network-based Software Architectures,” Ph.D. dissertation, University of California, Irvine, 2000.
[82]
Flyvbjerg, Bent, “Five Misunderstandings About Case-Study Research,” Qualitative Inquiry, vol. 12, no. 2, pp. 219–245, April 2006. [Online]. Available: http://dx.doi.org/10.1177/1077800405284363
[83]
France, R., Ray, I., Georg, G., and Ghosh, S., “An aspect-oriented approach to early design modeling,” in IEE Proceedings Software, vol. 151, no. 4, 2004, pp. 173–185.
[84]
France, Robert and Rumpe, Bernhard, “Model-driven Development of Complex Software: A Research Roadmap,” in FOSE ’07: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer Society, May 2007, pp. 37–54. [Online]. Available: http://dx.doi.org/10.1109/FOSE.2007.14
[85]
Frost, Randall, “Jazz and the Eclipse way of collaboration,” IEEE Software, vol. 24, no. 6, pp. 114–117, November 2007. [Online]. Available: http: //dx.doi.org/10.1109/MS.2007.170
[86]
Gajski, Daniel D., Vahid, Frank, Narayan, Sanjiv, and Gong, Jie, Specification and Design of Embedded Systems. Prentice Hall PTR, July 1994. [Online]. Available: http://www.worldcat.org/isbn/0131507311
[87]
Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns. Wesley, 1996.
[88]
K. Garc´es, F. Jouault, Cointe, Pierre, and J. B´ezivin, “A Domain Specific Language for Expressing Model Matching,” in Proceedings of the 5`ere Journ´ee sur l’Ing´enierie Dirig´ee par les Mod`eles (IDM09), 2009.
[89]
Gero, John S., “Design prototypes: a knowledge representation schema for design,” AI Mag., vol. 11, no. 4, pp. 26–36, 1990. [Online]. Available: http://portal.acm.org/citation.cfm?id=95793
[90]
Gerstlauer, Andreas and Gajski, Daniel D., “System-Level Abstraction Semantics,” in Proceedings of the International Symposium on System Synthesis, vol. 15, 2002, pp. 231–236. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.12.9504
Addison-
BIBLIOGRAPHY
73
[91]
Giese, Holger, Hildebrandt, Stephan, and Neumann, Stefan, “Towards Integrating SysML and AUTOSAR Modeling via Bidirectional Model Synchronization,” in MBEES, 2009, pp. 155–164.
[92]
Giese, Holger, Levendovszky, Tihamer, and Vangheluwe, Hans, “Summary of the Workshop on Multi-Paradigm Modeling: Concepts and Tools,” in MoDELS Workshops, ser. Lecture Notes in Computer Science, T. K¨ uhne, Ed., vol. 4364. Springer, 2006, pp. 252–262. [Online]. Available: http: //dx.doi.org/10.1007/978-3-540-69489-2 31
[93]
Giese, Holger and Wagner, Robert, “From model transformation to incremental bidirectional model synchronization,” Software and Systems Modeling, vol. 8, no. 1, pp. 21–43–43, February 2009. [Online]. Available: http://dx.doi.org/10. 1007/s10270-008-0089-9
[94]
Groher, Iris and Voelter, Markus, “XWeave: models and aspects in concert,” in AOM ’07: Proceedings of the 10th international workshop on Aspect-oriented modeling. New York, NY, USA: ACM, 2007, pp. 35–40. [Online]. Available: http://dx.doi.org/10.1145/1229375.1229381
[95]
Gruber, T., “A translation approach to portable ontology specifications,” Knowledge Acquisition, vol. 5, no. 2, pp. 199–220, June 1993. [Online]. Available: http://dx.doi.org/10.1006/knac.1993.1008
[96]
Habli, Ibrahim and Kelly, Tim, “Capturing and Replaying Architectural Knowledge through Derivational Analogy,” in SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007, pp. 4+. [Online]. Available: http://dx.doi.org/10.1109/SHARK-ADI.2007.6
[97]
Hatchuel, Armand and B. Weil, “A New Approach of Innovative Design: An Introduction to C-K Theory,” in International Conference on Engineering Design (ICED), Stockholm, August 2003.
[98]
Hein, C., Ritter, T., and Wagner, M., “Model-Driven Tool Integration with ModelBus,” in Workshop Future Trends of Model-Driven Development, 2009.
[99]
Herbsleb, J. D., Paulish, D. J., and Bass, M., “Global software development at Siemens: experience from nine projects,” in Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 524–533. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=1553598
[100] Herrmannsdoerfer, M., “Operation-based versioning of metamodels with COPE,” in CVSM ’09: Proceedings of the 2009 ICSE Workshop on Comparison and Versioning of Software Models. Washington, DC, USA: IEEE Computer Society, 2009, pp. 49–54. [Online]. Available: http://dx.doi.org/10.1109/CVSM.2009.5071722 [101] Herrmannsdoerfer, Markus, Benz, Sebastian, and Juergens, Elmar, “Automatability of Coupled Evolution of Metamodels and Models in Practice,” in MoDELS ’08: Proceedings of the 11th international conference on Model Driven Engineering Languages and Systems. Berlin, Heidelberg: Springer-Verlag, 2008, pp. 645–659. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-87875-9 45
74
BIBLIOGRAPHY
[102] ——, “COPE - automating coupled evolution of metamodels and models,” in ECOOP 2009, ser. Lecture Notes in Computer Science, Drossopoulou, Sophia, Ed., vol. 5653. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2009, pp. 52–76. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-03013-0 4 [103] Herrmannsdoerfer, Markus and Koegel, Maximilian, “Towards a generic operation recorder for model evolution,” in IWMCP ’10: Proceedings of the 1st International Workshop on Model Comparison in Practice. New York, NY, USA: ACM, 2010, pp. 76–81. [Online]. Available: http://dx.doi.org/10.1145/1826147.1826161 [104] Herzog, Erik, “An Approach to Systems Engineering Tool Data Representaton and Exchange,” Ph.D. dissertation, Link¨ oping University, 2004. [105] Hilliard, Rich and Rice, Tim, “Expressiveness in architecture description languages,” in ISAW ’98: Proceedings of the third international workshop on Software architecture. New York, NY, USA: ACM Press, 1998, pp. 65–68. [Online]. Available: http://dx.doi.org/10.1145/288408.288425 [106] Hubka, Vladimir and Eder, W. Ernst, Theory of Technical Systems: A Total Concept Theory for Engineering Design. Springer, 1988. [Online]. Available: http://www.worldcat.org/isbn/0387174516 [107] Hubka, Vladimir and Ernst, Design Science: Introduction to the Needs, Scope and Organization of Organization of Engineering Design Knowledge, 1st ed. Springer, December 1995. [Online]. Available: http://www.worldcat.org/isbn/3540199977 [108] Huff, S., “Information systems maintenance,” The Business Quarterly, vol. 50, 1990. [109] IEEE, “IEEE Standard Glossary of Software Engineering Terminology,” IEEE, Tech. Rep., 1990. [Online]. Available: http://dx.doi.org/10.1109/IEEESTD.1990. 101064 [110] ——, “Recommended practice for architectural description of software-intensive systems (IEEE Std 1471-2000),” IEEE, Tech. Rep., 2000. [111] IEEE and ISO/IEC, “Systems and software engineering - Recommended practice for architectural description of software-intensive systems (ISO/IEC 42010 IEEE Std 1471-2000),” ISO, Tech. Rep., July 2007. [Online]. Available: http://dx.doi.org/10.1109/IEEESTD.2007.386501 [112] iFEST Project Partners, “iFEST Project Deliverable D2.2: Requirements for an Integration Platform,” ARTEMIS, Tech. Rep., 2010. [113] ISO, “Industrial automation systems and integration – product data representation and exchange (ISO 10303),” ISO, Tech. Rep., 1994. [Online]. Available: http:// www.iso.org/iso/iso catalogue/catalogue tc/catalogue detail.htm?csnumber=20579 [114] Jansen, A. and Bosch, J., “Software Architecture as a Set of Architectural Design Decisions,” in Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on. Washington, DC, USA: IEEE, 2005, pp. 109–120. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2005.61
BIBLIOGRAPHY
75
[115] Jansen, Anton, van der Ven, Jan, Avgeriou, Paris, and Hammer, Dieter K., “Tool Support for Architectural Decisions,” Software Architecture, Working IEEE/IFIP Conference on, vol. 0, pp. 4+, 2007. [Online]. Available: http: //dx.doi.org/10.1109/WICSA.2007.47 [116] Jouault, F., Allilaire, F., J. B´ezivin, and Kurtev, I., “ATL: a model transformation tool,” Science of Computer Programming, vol. 72, pp. 31–39, June 2008. [117] Kappel, Gerti, Kapsammer, Elisabeth, Kargl, Horst, Kramler, Gerhard, Reiter, Thomas, Retschitzegger, Werner, Schwinger, Wieland, and Wimmer, Manuel, “Lifting Metamodels to Ontologies: A Step to the Semantic Integration of Modeling Languages,” Model Driven Engineering Languages and Systems, vol. 4199, pp. 528–542, 2006. [Online]. Available: http://dx.doi.org/10.1007/11880240 37 [118] Kapsammer, Elisabeth, Kargl, Horst, Kramler, Gerhard, Reiter, Thomas, Retschitzegger, Werner, and Wimmer, Manuel, “On Models and Ontologies - A Layered Approach for Model-based Tool Integration,” in in Proceedings of the Modellierung 2006 (MOD2006, 2006, pp. 11–27. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.3053 [119] Kapsammer, Elisabeth and Reiter, Thomas. Model-Based Tool Integration- State of the Art and Future Perspectives. [Online]. Available: http://citeseerx.ist.psu. edu/viewdoc/summary?doi=10.1.1.90.1751 [120] Karsai, Gabor, Lang, Andras, and Neema, Sandeep, “Design patterns for open tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 157–170, May 2005. [Online]. Available: http://dx.doi.org/10.1007/s10270-004-0073-y [121] Karsenty, Laurent, “An empirical evaluation of design rationale documents,” in CHI ’96: Proceedings of the SIGCHI conference on Human factors in computing systems. New York, NY, USA: ACM, 1996, pp. 150–156. [Online]. Available: http://doi.acm.org/10.1145/238386.238462 [122] Kelly, Steven and Tolvanen, Juha-Pekka, Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, March 2008. [Online]. Available: http://www.worldcat.org/isbn/0470036664 [123] Kelly, T. P., “Arguing safety – a systematic approach to managing safety cases,” Ph.D. dissertation, Department of Computer Science, University of York, 1999. [124] Kern, Heiko, “The Interchange of (Meta)Models between MetaEdit+ and Eclipse EMF Using M3-Level-Based Bridges,” in 8th OOPSLA Workshop on DomainSpecific Modeling at OOPSLA 2008, Gray, Jeff, Sprinkle, Jonathan, Tolvanen, JuhaPekka, and Rossi, Matti, Eds. University of Alabama at Birmingham, 2008, pp. 14–19. [125] Kern, Heiko and S. K¨ uhne, “Model Interchange between ARIS and Eclipse EMF,” in Proceedings of the 7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07), ser. Computer Science and Information System Reports, Technical Reports, Tolvanen, Juha-Pekka, Gray, Jeff, Rossi, Matti, and Sprinkle, Jonathan, Eds., no. TR-38. Finland: University of Jyv¨ askyl¨ a, 2007, pp. 105–114.
76
BIBLIOGRAPHY
[126] Kern, Heiko and Kuhne, Stefan, “Integration of Microsoft Visio and EclipseModeling Framework Using M3-Level-Based Bridges,” in 2nd Workshop on Model-Driven Tool & Process Integration (MDTPI 2009) at the European Conference on Modeling Foundations and Applications (ECMFA 2009), June 2009. [127] Khoury, Jad E., “A Model Management and Integration Platform for Mechatronics Product Development,” Ph.D. dissertation, KTH, 2006. [128] Kiczales, Gregor, Lamping, John, Menhdhekar, Anurag, Maeda, Chris, Lopes, Cristina, Loingtier, Jean M., and Irwin, John, “Aspect-Oriented Programming,” in Proceedings European Conference on Object-Oriented Programming, M. Ak¸sit and Matsuoka, Satoshi, Eds. Berlin, Heidelberg, and New York: SpringerVerlag, 1997, vol. 1241, pp. 220–242. [Online]. Available: citeseer.ist.psu.edu/ kiczales97aspectoriented.html [129] Knuth, Donald E., “backus normal form vs. Backus Naur form,” Commun. ACM, vol. 7, no. 12, pp. 735–736, 1964. [Online]. Available: http: //dx.doi.org/10.1145/355588.365140 [130] A. K¨ onigs and A. Sch¨ urr, “Tool Integration with Triple Graph Grammars - A Survey,” Electron. Notes Theor. Comput. Sci., vol. 148, no. 1, pp. 113–150, February 2006. [Online]. Available: http://dx.doi.org/10.1016/j.entcs.2005.12.015 [131] Koschke, Rainer and Simon, Daniel, “Hierarchical Reflexion Models,” in Working Conference on Reverse Engineering. IEEE Computer Society Press, November 2003, pp. 36–45. [132] Kramler, G., Kappel, G., Reiter, T., Kapsammer, E., Retschitzegger, W., and Schwinger, W., “Towards a semantic infrastructure supporting model-based tool integration,” in GaMMa ’06: Proceedings of the 2006 international workshop on Global integrated model management. New York, NY, USA: ACM, 2006, pp. 43–46. [Online]. Available: http://dx.doi.org/10.1145/1138304.1138314 [133] Kruchten, Philippe, “An Ontology of Architectural Design Decisions in Software Intensive Systems,” in 2nd Groningen Workshop Software Variability, October 2004, pp. 54–61. [134] Kruchten, Philippe, Capilla, Rafael, and J. C. Due˜ nas, “The Decision View’s Role in Software Architecture Practice,” IEEE Softw., vol. 26, no. 2, pp. 36–42, 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.52 [135] Kum, Daehyun, Park, Gwang-Min, Lee, Seonghun, and Jung, Wooyoung, “AUTOSAR migration from existing automotive software,” in Control, Automation and Systems, 2008. ICCAS 2008. International Conference on, October 2008, pp. 558–562. [Online]. Available: http://dx.doi.org/10.1109/ICCAS.2008.4694565 [136] Kunz, W. and Rittel, H. W. J., “Issues as Elements of Information Systems,” Univ. Calif. at Berkeley, Tech. Rep., 1970. [137] Kurtev, Ivan, J. B´ezivin, and Aksit, Mehmet, “Technological spaces: An initial appraisal,” in CoopIS, DOA 2002 Federated Conferences, Industrial track, 2002. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109. 332
BIBLIOGRAPHY
77
[138] Lee, Jintae, “Decision representation language (DRL) and its support environment,” MIT Artificial Intelligence Laboratory, Tech. Rep., August 1989. [Online]. Available: http://hdl.handle.net/1721.1/41499 [139] Lehman, M. M. and Belady, L. A., Eds., Program evolution: processes of software change. San Diego, CA, USA: Academic Press Professional, Inc., 1985. [140] Leveson, Nancy, Safeware : System Safety and Computers. Addison-Wesley, April 1995. [Online]. Available: http://www.worldcat.org/isbn/0201119722 [141] Leveson, Nancy G., “Intent Specifications: An Approach to Building HumanCentered Specifications,” IEEE Transactions on Sw. Eng., vol. 26, no. 1, pp. 15–35, January 2000. [142] Leveson, Nancy G. and Weiss, Kathryn A., “Making embedded software reuse practical and safe,” in SIGSOFT ’04/FSE-12: Proceedings of the 12th ACM SIGSOFT twelfth international symposium on Foundations of software engineering. New York, NY, USA: ACM Press, 2004, pp. 171–178. [Online]. Available: http://dx.doi.org/10.1145/1029894.1029897 [143] Lientz, Bennet P., Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations. Addison-Wesley Pub (Sd), 1980. [Online]. Available: http: //www.worldcat.org/isbn/0201042053 [144] Liggesmeyer, Peter and Trapp, Mario, “Trends in Embedded Software Engineering,” Software, IEEE, vol. 26, no. 3, pp. 19–25, April 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.80 [145] MacLean, Allan, Young, Richard M., Bellotti, Victoria M. E., and Moran, Thomas P., “Questions, options, and criteria: elements of design space analysis,” Human-Computer Interaction, vol. 6, no. 3, pp. 53–105, 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=261707 [146] McCall, R., “PHI: a conceptual foundation for design hypermedia,” Design Studies, vol. 12, no. 1, pp. 30–41, January 1991. [Online]. Available: http://dx.doi.org/10.1016/0142-694X(91)90006-I [147] Medvidovic, Nenad, Dashofy, Eric M., and Taylor, Richard N., “Moving architectural description from under the technology lamppost,” Information and Software Technology, vol. 49, no. 1, pp. 12–31, January 2007. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2006.08.006 [148] Medvidovic, Nenad and Taylor, Richard N., “A Classification and Comparison Framework for Software Architecture Description Languages,” IEEE Transactions on Software Engineering, vol. 26, no. 1, pp. 70–93, 2000. [Online]. Available: http://dx.doi.org/10.1109/32.825767 [149] Melnik, Sergey, Rahm, Erhard, and Bernstein, Philip A., “Rondo: a programming platform for generic model management,” in SIGMOD ’03: Proceedings of the 2003 ACM SIGMOD international conference on Management of data. New York, NY, USA: ACM, 2003, pp. 193–204. [Online]. Available: http://dx.doi.org/10.1145/872757.872782
78
BIBLIOGRAPHY
[150] Mens, Tom, R. Van Der Straeten, and D’Hondt, Maja, “Detecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis,” in Proc. Int’l Conf. MoDELS 2006, ser. LNCS, vol. 4199. Springer-Verlag, October 2006, pp. 200–214. [151] Mens, Tom and Van Gorp, Pieter, “A Taxonomy of Model Transformation,” Electr. Notes Theor. Comput. Sci, vol. 152, pp. 125–142, 2006. [152] ——, “A Taxonomy of Model Transformation,” Electr. Notes Theor. Comput. Sci, vol. 152, pp. 125–142, 2006. [153] Mernik, Marjan, Heering, Jan, and Sloane, Anthony M., “When and how to develop domain-specific languages,” ACM Comput. Surv., vol. 37, no. 4, pp. 316–344, December 2005. [Online]. Available: http://dx.doi.org/10.1145/1118890.1118892 [154] MODELWARE Project, “MODELWARE D5.3-1 Industrial ROI, Assessment, and Feedback- Master Document.” MODELWARE, http://www.modelware-ist.org, Tech. Rep., 2006. [155] Mohagheghi, Parastoo and Dehlen, Vegard, “Where Is the Proof? - A Review of Experiences from Applying MDE in Industry,” in Model Driven Architecture - Foundations and Applications, ser. Lecture Notes in Computer Science, Schieferdecker, Ina and Hartman, Alan, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2010, vol. 5095, ch. 31, pp. 432–443. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69100-6 31 [156] Murphy, G. C., Notkin, D., and Sullivan, K. J., “Software reflexion models: bridging the gap between design and implementation,” IEEE Transactions on Software Engineering, vol. 27, no. 4, 2001. [157] Muskens, J., Bril, R. J., and Chaudron, M. R. V., “Generalizing Consistency Checking between Software Views,” Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, pp. 169–180, 2005. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2005.37 [158] Narayanan, Anantha, Levendovszky, Tihamer, Balasubramanian, Daniel, and Karsai, Gabor, “Automatic Domain Model Migration to Manage Metamodel Evolution,” in Model Driven Engineering Languages and Systems, 2009, pp. 706–711. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-04425-0 57 [159] Navarro, Elena and Cuesta, Carlos, “Automating the Trace of Architectural Design Decisions and Rationales Using a MDD Approach,” in Software Architecture, ser. Lecture Notes in Computer Science, Morrison, Ron, Balasubramaniam, Dharini, and Falkner, Katrina, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2008, vol. 5292, ch. 10, pp. 114–130–130. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-88030-1 10 [160] Navarro, Israel, Lundqvist, Kristina, and Leveson, Nancy. An Intent Specification Model for a Robotic Software Control System. [Online]. Available: http: //citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.7351 [161] Navet, Nicolas and Simonot-Lion, Francoise, Eds., Automotive Embedded Systems Handbook. CRC Press, 2008.
BIBLIOGRAPHY
79
[162] Nentwich, Christian, Emmerich, Wolfgang, and Finkelstein, Anthony, “Flexible Consistency Checking,” ACM Transactions on Software Engineering and Methodology, vol. 12, no. 1, pp. 28–63, January 2003. [Online]. Available: citeseer.ist.psu.edu/nentwich01flexible.html [163] Noy, Natalya F., “Semantic integration: a survey of ontology-based approaches,” SIGMOD Rec., vol. 33, no. 4, pp. 65–70, December 2004. [Online]. Available: http://dx.doi.org/10.1145/1041410.1041421 [164] Oliver, David W., Kelliher, Timothy P., and James, Engineering Complex Systems With Models and Objects. McGraw-Hill Companies, 1997. [Online]. Available: http://www.worldcat.org/isbn/0070481881 [165] OMG, “Model Driven Architecture (MDA) Guide,” OMG, Tech. Rep., 2003. [Online]. Available: http://www.omg.org/mda/ [166] ——, “Meta Object Facility (MOF), v2.0,” OMG, Tech. Rep., January 2006. [Online]. Available: http://www.omg.org/spec/MOF/2.0/ [167] ——, “MOF 2.0 / XMI Mapping Specification, v2.1.1,” OMG, Tech. Rep., December 2007. [Online]. Available: http://www.omg.org/technology/documents/ formal/xmi.htm [168] ——, “MOF 2.0 Query / View / Transformation,” OMG, Tech. Rep., December 2009. [Online]. Available: http://www.omg.org/spec/QVT [169] ——, “Systems Modeling Language (SysML),” OMG, Tech. Rep., 2010. [Online]. Available: http://www.omgsysml.org/ [170] ——. (2010) Unified Modeling Language (UML). [Online]. Available: //www.omg.com/uml/
http:
[171] OSLC Core Specification Workgroup, “OSLC core specification version 2.0,” Open Services for Lifecycle Collaboration, Tech. Rep., August 2010. [172] Pahl, G., Beitz, W., Feldhusen, J., and Grote, K. H., Engineering Design: A Systematic Approach. Springer, January 2007. [Online]. Available: http://www.worldcat.org/isbn/1846283183 [173] Parnas, David L., “Software Aging,” in ICSE, 1994, pp. 279–287. [Online]. Available: http://portal.acm.org/citation.cfm?id=257734.257788 [174] Pence, J. and Hon III, “Building software quality into telecommunications network systems,” Quality Progress, pp. 95–97, October 1993. [175] Perry, D. and Wolf, A., “Foundations for the Study of Software Architecture,” ACM SIGSOFT Software Engineering Notes, vol. 17, no. 4, pp. 40–52, October 1992. [176] Pilato, C. Michael, Collins-Sussman, Ben, and Fitzpatrick, Brian W., Version Control with Subversion, 1st ed. O’Reilly Media, June 2004. [Online]. Available: http://www.worldcat.org/isbn/0596004486 [177] A. Postma, “A method for module architecture verification and its application on a large component-based system,” Information & Software Technology, vol. 45, no. 4, pp. 171–194, 2003.
80
BIBLIOGRAPHY
[178] Pretschner, Alexander, Broy, Manfred, Kruger, Ingolf H., and Stauner, Thomas, “Software Engineering for Automotive Systems: A Roadmap,” in FOSE ’07: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007, pp. 55–71. [Online]. Available: http://dx.doi.org/10.1109/FOSE.2007.22 [179] Reiser, M. O., “Managing Complex Variability in Automotive Software Product Lines with Subscoping and Configuration Links,” Ph.D. dissertation, TU Berlin, 2008. [180] Reiter, Thomas, Altmanninger, Kerstin, and Retschitzegger, Werner, “Think Global, Act Local: Implementing Model Management with Domain-Specific Integration Languages,” in Models in Software Engineering, ser. Lecture Notes in Computer Science, T. K¨ uhne, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2007, vol. 4364, ch. 32, pp. 263–276. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69489-2 32 [181] Rombach, H. and Basili, V., “Quantitative assessment of maintenance: an industrial case study,” in Proceedings of the IEEE Conference on Software Maintenance, September 1987, pp. 134–144. [Online]. Available: http://www.cs.umd.edu/users/basili/publications/proceedings/P40.pdf [182] Rose, Louis M., Paige, Richard F., Kolovos, Dimitrios S., and Polack, Fiona A. C., “An Analysis of Approaches to Model Migration,” in Proc. Models and Evolution (MoDSE-MCCM) Workshop, 12th ACM/IEEE International Conference on Model Driven Engineering, Languages and Systems, October 2009. [183] Rozanski, Nick and Woods, Eoin, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, April 2005. [Online]. Available: http://www.worldcat.org/isbn/0321112296 [184] Salzmann, Christian and Stauner, Thomas, “Automotive Software Engineering,” in Languages for System Specification, Grimm,, Christoph, Ed. Boston: Springer US, 2004, ch. 21, pp. 333–347. [Online]. Available: http://dx.doi.org/10.1007/ 1-4020-7991-5 21 [185] A. Sch¨ urr and H. D¨ orr, “Introductory paper,” Software and Systems Modeling, vol. 4, no. 2, pp. 109–111, May 2005. [Online]. Available: http://dx.doi.org/10. 1007/s10270-004-0069-7 [186] Schuster, N., Zimmermann, O., and Pautasso, C., “ADkwik: Web 2.0 Collaboration System for Architectural Decision Engineering,” in SEKE, 2007, pp. 255–260. [187] Sellgren, Ulf, M. T¨ orngren, Malvius, Diana, and Biehl, Matthias, “PLM for Mechatronics Integration,” in Proceedings of the 6th International Product Lifecycle Management Conference (PLM 2009), July 2009. [188] Seng, Olaf, Bauer, Markus, Biehl, Matthias, and Pache, Gert, “Search-based Improvement of Subsystem Decompositions,” in Proceedings of the 2005 ACM Conference on Genetic and Evolutionary Computation (GECCO 2005), 2005, pp. 1045–1051. [Online]. Available: http://dx.doi.org/10.1145/1068009.1068186 [189] Shaw, Mary, “What makes good research in software engineering?” International Journal on Software Tools for Technology Transfer (STTT), vol. 4, no. 1, pp. 1–7–7, October 2002. [Online]. Available: http://dx.doi.org/10.1007/s10009-002-0083-4
BIBLIOGRAPHY
81
[190] Shum, S. J., “A Cognitive Analysis of Design Rationale Representation,” Ph.D. dissertation, University of York, 1991. [Online]. Available: http: //people.kmi.open.ac.uk/sbs/research/phd/phd.html [191] Shum, Simon B., “Analyzing the Usability of a Design Rationale Notation,” in in Design Rationale: Concepts, Techniques, and, 1996, pp. 185–215. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.5956 [192] Sprinkle, Jonathan M., “Metamodel driven model migration,” Ph.D. dissertation, Vanderbilt University, 2003. [Online]. Available: http://citeseerx.ist.psu.edu/ viewdoc/download?doi=10.1.1.102.2044&rep=rep1&type=pdf [193] Star, Susan L. and Griesemer, James R., “Institutional Ecology, ’Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39,” Social Studies of Science, vol. 19, no. 3, pp. 387–420, 1989. [Online]. Available: http://dx.doi.org/10.2307/285080 [194] Steinberg, David, Budinsky, Frank, Paternostro, Marcelo, and Merks, Ed, EMF: Eclipse Modeling Framework (2nd Edition), 2nd ed. Addison-Wesley Professional, January 2008. [Online]. Available: http://www.worldcat.org/isbn/0321331885 [195] Suh, Nam P., The Principles of Design (Oxford Series on Advanced Manufacturing). Oxford University Press, March 1990. [Online]. Available: http://www.worldcat.org/isbn/0195043456 [196] ——, Axiomatic Design: Advances and Applications (The Oxford Series on Advanced Manufacturing). Oxford University Press, May 2001. [Online]. Available: http://www.worldcat.org/isbn/0195134664 [197] Tang, Antony, Babar, Muhammad A., Gorton, Ian, and Han, Jun, “A Survey of the Use and Documentation of Architecture Design Rationale,” in WICSA ’05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA: IEEE Computer Society, 2005, pp. 89–98. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2005.7 [198] ——, “A survey of architecture design rationale,” J. Syst. Softw., vol. 79, no. 12, pp. 1792–1804, December 2006. [Online]. Available: http://dx.doi.org/10.1016/j. jss.2006.04.029 [199] Tang, Antony, Jin, Yan, and Han, Jun, “A rationale-based architecture model for design traceability and reasoning,” Journal of Systems and Software, vol. 80, no. 6, pp. 918–934, June 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2006.08.040 [200] Tang, Antony, Nicholson, Ann, Jin, Yan, and Han, Jun, “Using Bayesian belief networks for change impact analysis in architecture design,” Journal of Systems and Software, vol. 80, no. 1, pp. 127–148, January 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2006.04.004 [201] Thomas, Ian and Nejmeh, Brian A., “Definitions of Tool Integration for Environments,” IEEE Softw., vol. 9, no. 2, pp. 29–35, 1992. [Online]. Available: http://dx.doi.org/10.1109/52.120599
82
BIBLIOGRAPHY
[202] Tichy, W. F., “Should computer scientists experiment more?” Computer, vol. 31, no. 5, pp. 32–40, May 1998. [Online]. Available: http://dx.doi.org/10.1109/2.675631 [203] TIMMO Project. (2009) Timing model (TIMMO). [Online]. Available: //www.timmo.org
http:
[204] M. T¨ orngren, “Towards an industrial Framework for Embedded systems tools,” in First Workshop on Hands-on Platforms and tools for model-based engineering of Embedded Systems (HoPES’10), June 2010. [205] M. T¨ orngren, Chen, DeJiu, and Crnkovic, Ivica, “Component-based vs. Modelbased Development: A Comparison in the Context of Vehicular Embedded Systems,” in EUROMICRO ’05: Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications. Washington, DC, USA: IEEE Computer Society, 2005, pp. 432–441. [Online]. Available: http://dx.doi.org/10.1109/EUROMICRO.2005.18 [206] Tran, John B., Godfrey, Michael W., Lee, Eric H. S., and Holt, Richard C., “Architectural Repair of Open Source Software,” in In Proceedings of International Workshop on Program Comprehension, 2000, pp. 48–59. [207] ——, “Architectural Repair of Open Source Software,” in In Proceedings of International Workshop on Program Comprehension, 2000, pp. 48–59. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.9245 [208] Tratt, Laurence, “Model transformations and tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 112–122, May 2005. [Online]. Available: http://dx.doi.org/10.1007/s10270-004-0070-1 [209] Tyree, Jeff and Akerman, Art, “Architecture Decisions: Demystifying Architecture,” IEEE Software, vol. 22, no. 2, pp. 19–27, 2005. [Online]. Available: http://dx.doi.org/10.1109/MS.2005.27 [210] Ueda, K., “Synthesis and emergence - research overview,” Artificial Intelligence in Engineering, vol. 15, no. 4, pp. 321–327, October 2001. [Online]. Available: http://dx.doi.org/10.1016/S0954-1810(01)00022-X [211] Ulrich, Karl and Eppinger, Steven, Product Design and Development, 3rd ed. McGraw-Hill/Irwin, July 2003. [Online]. Available: http://www.worldcat.org/isbn/ 0072471468 [212] VDI, “Methodic development of solution principles (VDI 2222),” VDI, Tech. Rep., 1997. [213] ——, “Design methodology for mechatronic systems (VDI 2206),” VDI, Tech. Rep., 2004. [214] Vesperman, Jennifer, Essential CVS, 1st ed. O’Reilly Media, June 2003. [Online]. Available: http://www.worldcat.org/isbn/0596004591 [215] Visconti, Marcello and Cook, Curtis R., “Assessing the State of Software Documentation Practices,” in Product Focused Software Process Improvement, 2004, pp. 485–496. [Online]. Available: http://www.springerlink.com/content/ 6dv8y2xgp5n31x0q
BIBLIOGRAPHY
83
[216] Vliet, Hans, Avgeriou, Paris, Boer, Remco C., Clerc, Viktor, Farenhorst, Rik, Jansen, Anton, and Lago, Patricia, “The GRIFFIN Project: Lessons Learned,” in Software Architecture Knowledge Management, 2009, ch. 8, pp. 137–154. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 8 [217] Wache, H., T. V¨ ogele, Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H., and S. H¨ ubner, “Ontology-Based Information Integration: A Survey.” [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.7857 [218] Wachsmuth, Guido, “Metamodel Adaptation and Model Co-adaptation,” in ECOOP 2007 Object-Oriented Programming, 2007, pp. 600–624. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-73589-2 28 [219] Wasserman, Anthony I., “Tool Integration in Software Engineering Environments,” in Software Engineering Environments, International Workshop on Environments Proceedings, ser. Lecture Notes in Computer Science, Long, Fred, Ed. Springer-Verlag, September 1989, pp. 137–149. [Online]. Available: http: //www.springerlink.com/content/p582q2n825k87nl5/ [220] Weiss, Kathryn A., Ong, Elwin C., and Leveson, Nancy G., “Reusable specification components for model-driven development,” in In Proceedings of the International Conference on System Engineering, INCOSE, 2003. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.7488 [221] Wicks, M. and Dewar, R., “A new research agenda for tool integration,” Journal of Systems and Software, vol. 80, no. 9, pp. 1569–1585, September 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2007.03.089 [222] Wicks, M. N., “Tool Integration within Software Engineering Environments: An Annotated Bibliography,” Heriot-Watt University, Tech. Rep., 2006. [Online]. Available: http://www.macs.hw.ac.uk:8080/techreps/docs/files/HW-MACS-TR-0041. pdf [223] Wiegand, John, “The Case for Open Services,” IBM Rational Software, Tech. Rep., May 2009. [224] Woods, Eoin and Hilliard, Rich, “Architecture Description Languages in Practice Session Report,” in WICSA ’05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05). Washington, DC, USA: IEEE Computer Society, 2005, pp. 243–246. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2005.15 [225] Wu, Weihang and Kelly, Tim, “Managing Architectural Design Decisions for Safety-Critical Software Systems,” in Quality of Software Architectures , ser. Lecture Notes in Computer Science, Hofmeister, Christine, Crnkovic, Ivica, and Reussner, Ralf, Eds. Springer Berlin Heidelberg, 2006, vol. 4214, ch. 9, pp. 59–77. [Online]. Available: http://dx.doi.org/10.1007/11921998 9 [226] Zelkowitz, Marvin, Principles of Software Engineering and Design (Prentice-Hall software series). Prentice Hall, 1979. [Online]. Available: http://www.worldcat. org/isbn/013710202X
84
BIBLIOGRAPHY
[227] ——, “An update to experimental models for validating computer technology,” Journal of Systems and Software, vol. 82, no. 3, pp. 373–376, March 2009. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2008.06.040
Appendix A
Literature Study on the State of the Art in Model Transformation Technology Matthias Biehl, “Literature Study on Model Transformations,” Technical Report, Royal Institute of Technology, ISSN 1400-1179, ISRN/KTH/MMK/R-10/07-SE, Stockholm, Sweden, July 2010.
Abstract Model transformation is a central concept in model-driven development approaches, as it provides a mechanism for automating the manipulation of models. In this document we survey and classify existing model transformation technology. The classification differentiates between the problem space, i.e. characteristics of the problem to be solved by model transformation technology, and the mechanism, i.e. characteristics of the model transformation language. We show typical usage scenarios for model transformations and identify characteristics of the problems that can be solved with the help of model transformations. We synthesize a unifying classification scheme for model transformation languages based on several existing classification schemes. We introduce a selection of model transformation tools available today and compare them using our classification scheme.
3
Contents 1 Introduction 1.1 Related Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Overview of this Document . . . . . . . . . . . . . . . . . . . . .
6 6 7
2 Terminology 2.1 Definition of Model Transformation . . . . . . . . . . . . . . . . . 2.2 Auxiliary Terminology . . . . . . . . . . . . . . . . . . . . . . . .
7 7 7
3 Typical Uses of Model Transformation 3.1 Synthesis . . . . . . . . . . . . . . . . 3.2 Integration . . . . . . . . . . . . . . . 3.2.1 Tool Integration . . . . . . . . 3.2.2 Model Merging . . . . . . . . . 3.3 Analysis, Simulation and Optimization
. . . . .
. . . . .
. . . . .
10 11 11 11 11 12
Transformation Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
12 13 13 13 13 14 14 14 15 15
5 Classification Scheme for Model Transformation Languages 5.1 Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Imperative/Operational . . . . . . . . . . . . . . . . . . 5.1.2 Declarative/Relational . . . . . . . . . . . . . . . . . . . 5.1.3 Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Graph Transformation . . . . . . . . . . . . . . . . . . . 5.1.5 Template-Based . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Direct Manipulation . . . . . . . . . . . . . . . . . . . . 5.2 Rule Application Control . . . . . . . . . . . . . . . . . . . . . 5.3 Rule Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Rule Organization . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Directionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Incremental Model Transformation . . . . . . . . . . . . . . . . 5.8 Representation of the Transformation . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
15 15 16 16 16 16 16 17 17 17 17 18 18 18 19
6 Model Transformation Languages, Tools and 6.1 EMF Henshin . . . . . . . . . . . . . . . . . . 6.2 ATL . . . . . . . . . . . . . . . . . . . . . . . 6.3 Query/View/Transformation (QVT) . . . . . 6.4 SmartQVT . . . . . . . . . . . . . . . . . . . 6.5 ModelMorf . . . . . . . . . . . . . . . . . . .
. . . . .
19 19 19 20 20 21
4 Classification Scheme for Model 4.1 Change of Abstraction . . . . . 4.2 Change of Metamodels . . . . . 4.3 Supported Technical Spaces . . 4.4 Supported Number of Models . 4.5 Supported Target Type . . . . 4.6 Preservation of Properties . . . 4.6.1 Semantics-preserving . . 4.6.2 Behavior-preserving . . 4.6.3 Syntax-preserving . . .
4
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
6.6 6.7 6.8 6.9 6.10
OpenArchitecureWare (OAW) . . . . . . . . . . . . . Kermeta . . . . . . . . . . . . . . . . . . . . . . . . . ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . XML Stylesheet Language Transformations (XSLT) More... . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
21 21 21 22 22
7 Conclusion
22
References
24
5
1
Introduction
In model-driven development a series of models is created, refined and maintained. Models are the primary artifacts of the development and contain information that supports the various stages of the development process. Models can capture information of different lifecycle stages and development activities, such as requirements, design, implementation, testing, quality analysis, simulation, verification. In addition, models can represent different views of the system and represent the system on different levels of abstraction. Model transformations provide a mechanism for automatically creating or updating target models based on information contained in existing source models, e.g. the creation of code from a design model or the translation of a UML Class Diagram into an Entity Relationship Diagram. The automatic creation of models through model transformations provides a mechanism for the systematic reuse of information. Assuming that the model transformation is correctly defined, it can be used to ensure consistency between different models.
1.1
Related Fields
The theoretical foundations of model transformation are rewrite systems and semi-Thue systems [16] from theoretical computer science. The practical foundations of model transformation techniques are laid by compiler construction [1]. Compilers translate programs written in a higher programming language (such as C++) to assembly language or representations that are close to the executable instructions of the processor. Model transformations solve a wider range of problems, including integration, analysis and simulation. Thus model transformation techniques are more universally applicable than a compiler. A compiler can even be viewed as a special application of a model transformation. Many of the techniques used in model transformation have a corresponding technique in compiler construction, with a slightly different name. For example the metamodel of model transformation corresponds to a grammar in compiler construction. Compilers typically have a pipeline architecture of lexical analysis, syntax analysis, semantic analysis, intermediate code generation and code generation. The same steps are performed by a model transformation engine. There is a high level of automation in compiler construction. There are several specific tools to support each phase of compiler construction, such as a parser generator, scanner generator and code generator. An example is the special-purpose language Lex/YACC that is used for create parsers. Compiler generators create a compiler based on a specification and are comparable to a higher-order model transformation. The research field of program transformation is related to model transformation, as it also uses techniques from compiler construction [58]. Program transformations are usually applied for analysis or optimization of certain quality attributes. Program transformations are typically unidirectional and are based on mathematically oriented concepts such as term rewriting, functional programming and attributed grammars. Refactoring is a well known program transformation technique used to improve the maintainability of source code without changing its behavior [23]. Generative programming is a software engineering paradigm based on describing software system families. Given a particular requirements specification, 6
a highly customized and optimized product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge [20]. Generative programming is closely related to model-driven development.
1.2
Overview of this Document
This document is structured as follows. In chapter 2 we define model transformation and introduce the terminology we use in this document. In chapter 3 we describe typical scenarios for the application of model transformations and provide examples. We proceed to identify the significant characteristics of problems that can be solved by model transformation and classify them in chapter 4. In chapter 5 we identify the properties of model transformation languages. These properties can be used to classify existing approaches and discuss a specific subsets of approaches. We introduce some state-of-the-art tools for model transformation in chapter 6 and use the classification scheme developed in chapter 5 to compare them. We conclude this report in chapter 7 with a discussion of the advantages and disadvantages of model transformations.
2 2.1
Terminology Definition of Model Transformation
Model transformation is a young field and there are several competing, yet partly overlapping definitions of the terms. Tratt [55] defines model transformation very widely as ”a program that mutates one model into another”. The Object Management Group (OMG), an industry association for standardization within software engineering, defines model transformation in the context of the model-driven architecture (MDA) as ”the process of converting a model into another model of the same system” [42]. Kleppe et al. [32] define model transformation as the ”automatic generation of a target model from a source model, according to a transformation description”. Mens et al. [39] extend this definition by also allowing several models as input or output and define model transformation as the ”automatic generation of one or multiple target models from one or multiple source models, according to a transformation description”. This is the definition we will use in this document. Figure 1 illustrates the components of a model transformation.
2.2
Auxiliary Terminology
Model: A model is a simplified representation of a system that helps to gain a better understanding of the system [50, 7]. Models are often expressed in dedicated domain-specific languages or general purpose modeling languages such as UML [49]. Models are often represented graphically, but do not need to be. Metamodel: A metamodel of a model X describes the structure that model X must follow to be valid. A metamodel can be compared to a grammar in language design. Precisely defined metamodels are a prerequisite for
7
Figure 1: The components of a model transformation. model transformations [40]. Figure 2 illustrates the metalevels of a model transformation. Metametamodel: A metametamodel of model X is the metamodel used to describe the metamodel of model X [22]. It can be compared to the grammar of the language that is used to describe the grammar of the language X (e.g. EBNF). Standards and well established frameworks for metametamodels exist, such as MOF or Ecore. MOF is a standard for defining metamodels that is defined by the OMG [45]. MOF comes in two versions: Complete MOF (CMOF) and Essential MOF (EMOF). A commonly used implementation of EMOF is Ecore, defined by the Eclipse Modeling Framework (EMF) [52]. Model Transformation Paradigm/Approach: A model transformation paradigm or approach is the design principle on which the model transformation language is built, e.g. imperative, operational, functional, declarative or relational. Model Transformation Language: A model transformation language is a vocabulary and a grammar with well-defined semantics for performing model transformations. The language is based on a certain model transformation paradigm. Model Transformation Description: A model transformation description expresses how one or more source models are transformed into one or more target models. It is written in a model transformation language. If the language of a transformation description is rule-based, the transformation description is a set of model transformation rules [33]. A model transformation description is sometimes also called model transformation definition, model transformation code or model transformation program. Model Transformation Rule: A model transformation rule in a description is the smallest entity within a model transformation. It describes how a fragment of the source model can be transformed into a fragment of the target model [33]. A rule contains a source pattern and a target pattern. For each occurrence of the source pattern in the source model, a target pattern is created in the target model. In the context of graph
8
transformation the source pattern is also called the left-hand side (LHS) and the target pattern is called right hand-side (RHS). Model Transformation Engine/Tool: A model transformation engine or tool executes or interprets the model transformation description. It applies the model transformation description on the source model to produce the target model. Transformation engines are also called rewrite engines. Examples for model transformation engines are SmartQVT (cf. section 6.4) or ATL (cf. section 6.2). For executing a model transformation an engine/tool typically needs to perform the following steps [55]. • identify elements in the source model that need to be transformed
• for each of the identified elements produce the associated target elements • produce tracing information that links the source and target elements affected by this rule Source Model: In the context of a model transformation, a model can take on the role of a source model, if it is an input to the transformation. The source model conforms to the source metamodel. One or more source models are the input of a model transformation. Target Model: In the context of a model transformation, a model can take on the role of a target model, if it is an output of the transformation. The target model conforms to the target metamodel. A model transformation can have one or more target models. The term target model is only used for transformations that are model-to-model transformations. Transformation Models: The transformation description can be represented using a model [6]. This allows the transformation model to be the source model or target model of another model transformation. Figure 2 illustrates a transformation model and its relation to elements on other metalevels. Higher-order Transformation (HOT): A model transformation description having a transformation model as source or target model [54]. Model Driven Architecture (MDA): Standard [44] for Model-driven development by the Object Management Group (OMG), where Platform Independent Models (see below) are transformed to Platform Specific Models (see below). Platform Independent Model (PIM): A PIM is a part of the standard for the Model-driven Architecture (MDA). PIM is a role that a model can take, where the model does not contain information about the platform used. Note that the term platform is not very concise. Note also that a model can be independent of one platform and dependent on another platform at the same time [44]. Platform Specific Model (PSM): A PSM is a part of the standard for the Modeldriven Architecture (MDA). PSM is a role that a model can take, where the model does contain information about the platform used. 9
Technical Space: The term technical space or technological space is the technology used to represent models [37, 8]. The technology includes file formats, data structures, parsers, and facilities to manipulate the data. Examples for technical spaces are XML (Extensible Markup Language) [13], XMI (XML for Metadata Interchange) [46] or EMF (Eclipse Modeling Framework) [52].
Figure 2: The metalevels of a model transformation.
3
Typical Uses of Model Transformation
Model transformations can be used for various tasks in model-driven development, e.g. for modifying, creating, adapting, merging, weaving or filtering models. The reuse of information captured in models is common to all of these tasks. Instead of creating artifacts from scratch, model transformations enable the use of information that was once captured as a model and build on it. In this chapter we will look at some specific use cases for model transformation throughout the development process. Model transformations can be used in different phases of the development process. The V-model development process [56] is depicted in figure 3. The left leg of the V depicts the process of creating a solution by incremental refinement. This refinement starts with the requirements elicited from the user, proceeds with the development of a concept and design until an implementation is created. The right leg of the V depicts verification and validation. In the following sections we study how model transformations can be used to support the different development tasks in the V-model. In figure 3 the use of model transformations is depicted by an arrow.
10
Figure 3: The V-model development process depicted as a grey V, the artifacts produced during this process are depicted by black circles. The use of model transformation the different development tasks is depicted by an arrow.
3.1
Synthesis
A transformation for synthesis is a refinement that adds details to the model. Source and target models can have the same metamodel or different ones. The level of detail is increased and it usually involves moving from a higher abstraction level to a lower one. In figure 3 synthesis can cover any stretch on the left leg of the V-cycle. Usually there is a chain of several model-to-model transformations and a final model-to-code transformation. Code generation is a special case of a synthesis transformation, where source code is produced from models of a higher level of abstraction. A synthesis transformation can refine a model in several ways: decomposition of concepts of a higher level, choice of algorithm, specialization of abstractions for a certain usage context and concretization [20].
3.2 3.2.1
Integration Tool Integration
A number of different development tools are available to create, manipulate, analyze and simulate models. The models created are usually tool-specific, i.e. each tool expects a model that corresponds to a different metamodel and uses different technical spaces for representation. This is the reason why it is not always possible for theses tools to exchange data, hampering tool interoperability. Tool integration technology bridges the semantic and syntactic gaps between different metamodels and their tools. In a tool integration context, model transformations can be used to translate between two different metamodels or to keep two models synchronized and consistent. Model transformations can be used to establish a mapping between the metamodels of the different tools, allowing a translation between valid instances of the metamodels. 3.2.2
Model Merging
Information from two or more models might need to be merged into a common model. In the simplest case, all involved models correspond to the same metamodel. Even merging models corresponding to different metamodels is possible. Model merging is used in aspect oriented modeling [24] or model weaving [5].
11
3.3
Analysis, Simulation and Optimization
Model transformations can support simple and more complex analysis activities. Simple analysis can be performed by the transformation, such as model metric calculation. An example is the computation of a metric for similarity [17], which uses a model transformation written in ATL. More complex analysis or simulations can be supported by model transformation as well, by tool integration of external analysis technology. In the latter approach, input models for external analysis tools are created, as shown for example in [9, 10]. Optimization transformations are usually endogenous transformations, which focus on improving one or several non-functional properties. For example optimizations performed by a compiler are usually targeted towards performance enhancements. The optimization of models can focus on different properties such as evolvability, dependability or modularity. A refactoring is an example of an optimization transformation; it improves maintainability, evolvability and understandability.
4
Classification Scheme for Model Transformation Problems
In earlier research mainly tools and languages for model transformation have been classified and evaluated. Model transformation languages have been classified by Czarnecki et al. [15] and by Mens et al. [39]. Different model transformation tools have been evaluated by Huber [27]. The study concluded that no model transformation tool is absolutely better than another one. Instead a suitable model transformation tool exists for almost every kind of model transformation problem. This is why we propose a classification scheme for model transformation problems. In this document we define the term model transformation problem as a problem that we would like to solve using a model transformation. A model transformation problem is a specific instance of the typical scenarios for model transformation described in section 3. In the following we identify the characteristic properties of model transformation problems forming a classification. Such a classification can be helpful when deciding which model transformation language and engine is suited for solving the problem. This is useful as a large number of different alternative model transformation languages and engines is available. We have identified the following properties of model transformation problems: • Change of Abstraction • Change of Metamodels • Supported Technical Spaces • Supported Number of Models • Supported Target Type • Preservation of Properties
12
4.1
Change of Abstraction
Model transformations can change the level of abstraction between source and target model. The level of abstraction is a measure of the amount of details in a model. Model transformations either introduce new detail, reduce the amount of detail or leave it unchanged. This property is independent of the change in the metamodel (c.f. section 4.2); source and target metamodel can be the same or different. • A vertical transformation changes the level of abstraction. The level of abstraction can be increased by a refinement transformation or it can be decreased by an abstraction transformation. – A refinement transformation produces the target model by adding details to the source model. A change in the metamodel might be necessary for this step. In the MDA, this type of model transformation is used to transform a platform independent model into a platform specific model. – An abstraction transformation produces the target model by reducing the amount of detail. • A horizontal transformation changes the representation of the model and does not change the level of abstraction of the model. Examples are prettyprinting, improving the graphical layout, refactoring, and translating the model to a similar metamodel. Translation transformations produce the target model by expressing the same information found in the source model in a different metamodel, where the degree of detail remains the same.
4.2
Change of Metamodels
We can differentiate whether source and target metamodels are the same or different [39]. • The source and target metamodels of endogenous transformations are the same. When producing the target model, the transformation usually also changes only a specific part of the source model, to the largest extent source and target model are the same. This type of transformation is also called rephrasing transformation [57]. • Exogenous transformations map concepts between different metamodels. This type of transformation is also called translation transformation [57].
4.3
Supported Technical Spaces
Models are represented using different technical spaces [8]. The technical space of the models limits the set of transformation engines that can be used. Crossing the boundaries of technical spaces is not supported by all transformation tools.
4.4
Supported Number of Models
A model transformation can have several source models and several target models [39]. 13
• The minimum number of models involved is one, where source and target model are the same. In this case the target model is created by modifying specific parts in the existing source model. The transformation assumes that source and target model are identical, except for the parts mentioned in the transformation description. The transformation is called in-place transformation. • Most transformations involve two models, with distinct source and target models. The transformation assumes that the target model is empty and if it contains information, the information is overwritten. After execution of the transformation, the target model only contains information that is explicitly generated. • A transformation can involve several source models and combine the information found in them into the target model. A transformation can also produce several target models, which often - but not necessarily - reference each other.
4.5
Supported Target Type
We can distinguish model transformations with respect to the type of the target. The target can be model or text. • Model-to-model transformations create elements of the target model. Elements in the source model are mapped to elements in the target model. • Model-to-text transformations create arbitrary text. Elements in the source model map to arbitrary fragment of text. Since the text lacks structure, model-to-text transformations are much harder to analyze. If the text produced by the transformation is source code, the transformation is also called model-to-code transformation or code transformation.
4.6
Preservation of Properties
Transformations can be built in such a way that source model and target model have a common property, which is not changed by the transformation [39]. 4.6.1
Semantics-preserving
If the source and target metamodels are similar, a mapping can be found that is semantics preserving, i.e. the meaning of the two models is the same, even though it is represented in a different technical space or using a different abstract syntax. Semantics-preserving program transformations are defined as changing the way computations are performed without changing the values computed [61]. Examples of semantics-preserving transformations are performance improvements or refactorings. In both cases the transformation does not change the outcome of the computation, but improves quality attributes. In the case of performance improvements the required resources and the time to output are reduced, thereby improving execution time and performance. Refactoring is the process of changing the internal structure of a model without simultaneously
14
changing the externally observable behavior or functionality of the corresponding program. Refactoring transformations are semantics-preserving, since they do not change the meaning of the model, but improve the structure and quality of the model. If source and target metamodels contain fundamentally different assumptions, it might be difficult to completely preserve the semantics. A model transformation can approximate a preservation of the meaning of the model. Approximation can preserve the essential properties of the model. An example is the mapping from a complex state machine to a simplified state machine or the mapping between a nonlinear mathematical function and a linear mathematical function. 4.6.2
Behavior-preserving
A transformation is behavior-preserving if the explicit or implicit constraints of the behavior in the source model remain fulfilled in the target model after the transformation has been executed. An example is a transformation from a model to code, where the code produces output values that are slightly different from those predicted by the corresponding simulation of the model. Even though the transformation from model to code is not semantics-preserving, it is behaviorpreserving. 4.6.3
Syntax-preserving
A syntax preserving transformation is usually an endogenous horizontal transformation that does not change the abstract syntax of the model. An example is a transformation for improving the graphical layout which preserves the abstract syntax but changes the concrete syntax, e.g. by placing graphical model elements in a new layout on the drawing canvas.
5
Classification Scheme for Model Transformation Languages
In this chapter we introduce the characteristics and properties of model transformation languages. The purpose of this listing is to create a classification framework for exploring and evaluating how model transformation languages differ from each other. Together with the problem classification introduced in section 4, this can be used for selecting a tool with appropriate properties for the task. The framework proposed in this chapter is based on the classification by Czarnecki et al. [15] and on the taxonomy by Mens et al. [39]. Mens has applied his classification on graph transformations [41] and Koch has used the classification for studying transformation technology for web engineering [34].
5.1
Paradigm
Model transformation languages follow different language paradigms. We introduce the different paradigms in the following sections.
15
5.1.1
Imperative/Operational
Imperative languages specify a sequential control flow and provide means to describe how the transformation language is supposed to be executed. The constructs and language concepts of imperative model transformation languages are similar to those of general purpose programming languages such as Java or C/C++. The languages offer a high level of control to the programmer. This provides flexibility and allows for efficient implementations. The transformation is described as a sequence of actions, which is especially useful if the order of a set of transformation rules needs to be controlled explicitly [39]. 5.1.2
Declarative/Relational
Declarative languages do not offer explicit control flow. Instead of how the transformation should be executed, the focus is on what should be mapped by the transformation. Declarative model transformations describe the relationship between the source and the target metamodels and this relationship can be interpreted bidirectional. For a declarative transformation between the models A and B, the transformation description can be executed in both directions: A 7→ B and B 7→ A. Graph transformation is a subcategory of declarative languages, see section 5.1.4. Declarative languages are in general compact and transformation descriptions are generally short and concise. 5.1.3
Hybrid
Hybrid transformation languages offer both imperative language constructs and declarative language constructs. They leave it up to the user whether to use imperative or declarative language constructs. 5.1.4
Graph Transformation
Graph transformation languages build on theoretical foundations of algebraic graph grammars and are a subcategory of declarative languages. Graph transformations have interesting theoretical properties and are often used in formal approaches and proofs. Models are interpreted as graphs, and graph transformations manipulate subgraphs. Triple Graph Grammars (TGG) are a way of describing graph transformations. They have rules that are specified by three graphs: • Left-hand side graph: subgraph of the source graph • Right-hand side graph: subgraph of the target graph • Correspondence graph: describes the mapping between elements of the left-hand side graph and elements of the right-hand side graph. The left-hand side describes the precondition for the application of the rule, the right-hand side describes the postcondition of the rule. 5.1.5
Template-Based
Template-based languages are used for model-to-text transformations. Templates contain fragments of the target text and a metaprogram that can access 16
the source model. Usually template-based languages are combined with the visitor pattern [25] to traverse the internal structure of a model. 5.1.6
Direct Manipulation
General purpose programming languages can be used to implement model transformations. Libraries to read and write model data can be used. As an advantage, programmers do not need to learn a new language. On the other side, the implementations tend to become large and unmaintainable.
5.2
Rule Application Control
Transformation languages offer different mechanisms for determining when and where a transformation rule is applied. • Implicit control does not allows specifying direct control of the order of rule application. • Explicit control specifies the execution order together with the rules. • External control specifies the order separately from the rules. • Rule application scoping restricts the transformation to affect only parts of the model. The restriction can be either on the source model or on the target model.
5.3
Rule Scheduling
Rule scheduling determines the order of rule application. • Rule Selection controls when a rule is applied. Rule selection can be either deterministic (interactive, explicit, control resolution) or non-deterministic. • Rule Iteration uses recursion, looping or fixpoint operation. • Phasing determines that in a certain phase only certain rules can be executed.
5.4
Rule Organization
Large model transformations contain a number of rules that need to be organized. Model transformation languages offer different ways to group, compose and reuse rules. Rules can be grouped according to the source model, the target model or independently. Different techniques for modularizing rules exist, e.g. [38]. It is desirable to reuse transformations and transformation rules, due to the potential efficiency and quality improvements. One way of reuse is composition of simple rules to build more complex rules [26, 60, 14]. • Transformations can be composed internally. Composition needs to be supported by the transformation language. • Transformations can be composed externally. Composition of transformations of different languages can be combined. 17
5.5
Traceability
A trace may be produced as a side effect of the transformation. It provides a log of the execution of the transformation. It maps elements of the source model that were matched by a transformation rule to the elements of the target model that were produced by the transformation rule. Tracing functionality can be built-in into the tool, or it can be implemented as part of the transformation description. The traces can be stored in the source model, in the target model or in a separate place. Traces can be captured as separate models, i.e. trace models, corresponding to a trace metamodel. The model transformation language QVT (see section 6.3) defines such a trace metamodel. Traces can be used as a basis for synchronization or incremental execution of model transformations.
5.6
Directionality
Transformations are used for mapping source models to target models. Transformation languages allow interpreting the mapping unidirectionally or multidirectionally. • Unidirectional languages allow a mapping from source to target model. • Multidirectional languages allow an interpretation of the rule in several directions. The same rule can be applied from source to target and from target to source. If a single source and a single target model are used, the mapping is called bidirectional.
5.7
Incremental Model Transformation
When a source model is changed and a transformation has previously generated a corresponding target model, some model transformation engines allow incremental updates of the target model. That way, the target model does not need to be regenerated completely, but just the part affected by the change. This is especially relevant if large models are involved. Tratt differentiates in [55] between statefull and persistent transformations. • Non-incremental or statefull transitions regenerate the complete model, incremental updates are not possible. • Incremental or persistent transformations on the other hand allow updates in the source model and propagate the changes to the target model. Traces can be used as a foundation for realizing incremental model transformations. Note that in-place transformations (c.f. section 4.4) are inherently incremental. An incremental model transformation can be incremental regarding the source or the target model. • A target-incremental model transformation updates the target without rebuilding complete target. • A source-incremental model transformation minimizes the number of sourceelements that need to be rechecked on an incremental model transformation. 18
Another aspect of incremental model transformation is the preservation of user edits in the target model. Manual additions made by the user in the target model are preserved even when the target is regenerated.
5.8
Representation of the Transformation
Model transformations can be represented as text or as a model. If model transformations are models [6], it is possible to use model transformations to manipulate other model transformations, so called higher-order transformations.
6
Model Transformation Languages, Tools and Standards
In this section we briefly introduce different model transformation languages and tools.
6.1
EMF Henshin
EMF Henshin [12] is a continuation of the EMF Tiger [11] transformation language. It is an in-place model-to-model transformation language using triple graph grammars (TGG). It is based on the Eclipse Modeling Framework EMF [52]. The transformation description is a transformation model consisting of a left-hand-side graph, a right-hand-side and a list of correspondence mappings. The graph nodes are model element instances of the source metamodel and the target metamodel, respectively. It is thus possible to create higher-order transformations with EMF Henshin. There is no built-in support for creating traces, no support for multi-directionality or incremental model transformation.
6.2
ATL
The ATLAS Transformation Language (ATL) [29] is a hybrid model-to-model transformation language. ATL supports both declarative and imperative constructs. The preferred style is declarative, which allows a cleaner and simpler implementation for simple mappings. However, imperative constructs are provided so that some mappings that are too complex to be handled declaratively can still be specified. An ATL transformation program is composed of rules that describe how to create and initialize the elements of the target models. The language is specified both as a metamodel and as a textual concrete syntax. ATL is integrated in the Eclipse development environment and can handle models based on EMF. ATL also provides support for models using EMF-based UML profiles. ATL-code is compiled and then executed by the ATL transformation engine. ATL supports only unidirectional transformations. ATL offers dedicated support for tracing. The order of the rule execution is determined automatically, with the exception of lazy rules, which need to be called explicitly. Helper functions provide imperative constructs. ATL does not support incremental model transformation, so a complete source model is read and complete target model is created. Manual changes in the target model are not preserved. ATL supports 19
a mode for in-place transformation, called the refining mode. It has limitations and cannot be used in combination with certain constructs, e.g. with lazy rules.
6.3
Query/View/Transformation (QVT)
Query/View/Transformation (QVT) is a standardized language for model transformation [47, 36] established by the Object Management Group (OMG). QVT uses the Object Constraint Language (OCL) [48], Meta Object Facility (MOF) [45] and is aligned with the Model Driven Architecture (MDA) [44]. QVT defines three languages for model-to-model transformations. QVT defines both a textual concrete syntax and a XMI-based metamodel for creating model representations of QVT transformations. QVT has a blackbox mechanism that allows calling external code from within the transformation. For the tool implementation of each of the three languages QVT defines four conformance classes for interoperability: syntax executable (ability to execute QVT in the concrete syntax), XMI executable (ability to execute QVT in a serialized XMI model), syntax exportable (ability to export QVT into the concrete syntax), XMI exportable (ability to export QVT into a serialized XMI model). QVT defines three transformation languages: • QVT Relational is a high-level declarative transformation language. Both a graphical and a textual syntax are defined for QVT. The language supports the specification of bidirectional transformations. When a bidirectional transformation is executed, the execution direction needs to be specified. A transformation is specified as a set of relations between the source and target metamodel that must hold true. This transformation can be used to check two models for consistency, to enforce consistency by modifying the target model, to synchronize two models and for in-place transformations. It supports complex pattern matching using OCL. Trace models are created implicitly. The semantics is defined by a mapping to QVT Core. • QVT Core is a simple, low-level declarative model transformation language. It serves as a foundation for QVT Relational and is equally expressive. It supports pattern matching over a flat set of variables, where the variables of source, target and trace models are treated symmetrically. Trace models must be defined explicitly. • QVT Operational is an imperative model transformation language that extends QVT Relational with imperative constructs. The transformations are unidirectional. It uses implicit trace models. Model transformation engines that are conform to the QVT standard include for example SmartQVT (cf. section 6.4) and ModelMorf (cf. section 6.5).
6.4
SmartQVT
SmartQVT [2] is an implementation of a transformation engine for Operational QVT. It is an imperative language for model-to-model transformation for EMFbased models. The transformation description is compiled into Java code and supports the QVT blackbox mechanism to call external code.
20
It offers built-in tracing support, in addition it offers reflection to access tracing information, such as the target object corresponding to a source object or the source object corresponding to a target object. There is support for control parameters and higher order rules. Incremental model transformation is not supported, as the complete source model is read and the complete target model is created. There is currently no support for multi-directionality.
6.5
ModelMorf
ModelMorf [53] is an implementation of the OMG standard QVT Relational. It is a declarative model-to-model transformation. It supports multi-directionality, so the same rule can be used to map in both directions. It supports targetincremental model transformation (called change propagation semantics), so if the source model changes only the changed part of the model is transformed. It provides built-in functionality to create traces. It is possible to create in-place transformations. Furthermore, it is possible to compose model transformations to build and extend complex transformations from simpler ones. There is currently no support for aspect-orientation, reflexion or sourceincremental model transformation.
6.6
OpenArchitecureWare (OAW)
OAW [18] integrates a number of tools for model transformations into a coherent framework. OAW provides a workflow specification language and the transformation language Xpand. The workflow language is used to control the transformation process and to specify the sequence of transformations between the different models. The Xpand transformation language is a template-based, imperative language for model-to-text transformations. OAW is distributed as a plugin of the Eclipse platform and is able to handle EMF models (Eclipse Modeling Framework).
6.7
Kermeta
Kermeta [21, 43] is a general purpose modeling and imperative programming language, also able to perform transformations. It offers EMF-based metamodeling, constraints, checks, transformation and behavior support. Models and metamodels need to be explicitly loaded and stored. Target elements need to be explicitly instantiated and added to the target model, which requires more code. Rule application control and rule scheduling needs to be specified explicitly by the user. Kermeta supports reflection, exception handling and aspect-orientation. There is no built-in support for traceability and multi-directionality. Incremental model transformation is not supported, so the complete source model is read and complete target model is created when the transformation is executed.
6.8
ETL
The Epsilon Transformation Language (ETL) [35] is a hybrid model-to-model transformation language. It is part of the Epsilon model management infras-
21
tructure. It can handle several source and several target models. It offers rule scheduling functionality: lazy rules are only executed, when they are explicitly called, guarded rules are only executed if their guard evaluates to true, greedy rules are executed whenever possible. Rules can be reused and extended through rule inheritance. External code can be executed from within the transformation rule.
6.9
XML Stylesheet Language Transformations (XSLT)
XSLT [59] is a functional transformation language for manipulating XML data. Being a functional language, rules have to be called explicitly. There is no built-in traceability support and rules are strictly unidirectional. Transformations are stateful, so there is no support for incremental transformation. XSLT transformation descriptions are themselves XML documents, so higher-order transformations can be realized. Due to the fact the XSLT was initially developed to transform XML documents into HTML documents, XSLT is limited to simple transformations [4].
6.10
More...
Many more model transformation languages exist, we list some names and references here, without claiming to be complete: Moflon [3], mediniQVT [28], Textual Concrete Syntax (TCS) [30], XText [19], Tefkat [51], MOLA [31], MT, SiTra, MofLog, GreAT, GenGen, Beanbag, UMT, UMLX, ATOM, VIATRA, BOTL, XDE Transformations, Codagen Architect Transformations, b+m Generator Framework, OptimaJ Transformations, ArcStyler Transformations, MPS Transformation, Microsoft DSL Tool Transformations, Metaedit+ Transformations, AndroMDA, JET, FUUT-je, GMT, Jamda, Fujaba Transformations, TXL, Stratego
7
Conclusion
Model transformations can be used for different tasks throughout the development process for manipulating models. Model transformation descriptions are expressed in model transformation languages. We clarified the terminology of model transformations and showed potential usage scenarios for model transformations. We first identified some characteristics of the problems that can be solved with the help of model transformations. We then synthesized a classification scheme for model transformations from existing classifications. Several languages, tools and a standard for model transformations have been developed in recent years. We used the classification scheme to classify model transformation languages, to compare the properties the languages can offer. The field of model transformation is an active research field, and the latest approaches could not be covered in this report. More information can be found in relevant conference proceedings and journals: International Conference on Model Transformation (ICMT), International Conference on Model Driven Engineering Languages and Systems (MODELS), Journal for Software and Systems Modeling, Journal of Systems and Software.
22
Acknowledgements This work has been partially funded by the FP7 project ATESST2 and the ARTEMIS projects CESAR and iFEST. The author would like to thank Jad El-khoury for reviewing this document.
23
References [1] A. V. Aho, R. Sethi, and J. D. Ullman, Compilers: Principles, Techniques, and Tools. Addison Wesley, January 1986. [Online]. Available: http://www.worldcat.org/isbn/0201100886 [2] F. Alizon, M. Belaunde, G. DuPre, B. Nicolas, S. Poivre, and J. Simonin, “Les mod`eles dans l’action `a france t´el´ecom avec smartqvt,” in G´enie logiciel: Congr`es Journ´ees Neptune No5, 2007. [Online]. Available: http://smartqvt.elibel.tm.fr [3] C. Amelunxen, A. K¨onigs, T. R¨otschke, and A. Sch¨ urr, “Metamodeling with MOFLON,” Applications of Graph Transformations with Industrial Relevance, pp. 573–574, 2008. [Online]. Available: http://dx.doi.org/10. 1007/978-3-540-89020-1 40 [4] G. J. Bex, S. Maneth, and F. Neven, “A formal model for an expressive fragment of xslt,” Inf. Syst., vol. 27, no. 1, pp. 21–39, March 2002. [Online]. Available: http://dx.doi.org/10.1016/S0306-4379(01)00033-3 [5] J. B´ezivin, S. Bouzitouna, M. Del Fabro, M. P. Gervais, F. Jouault, D. Kolovos, I. Kurtev, and R. F. Paige, “A canonical scheme for model composition,” in Model Driven Architecture Foundations and Applications, 2006, pp. 346–360. [Online]. Available: http: //dx.doi.org/10.1007/11787044 26 [6] J. B´ezivin, F. B¨ uttner, M. Gogolla, F. Jouault, I. Kurtev, and A. Lindow, “Model transformations? transformation models!” in in Proceedings of Model Driven Engineering Languages and Systems (MODELS2006), 2006, pp. 440–453. [Online]. Available: http://dx.doi.org/10.1007/11880240 31 [7] J. B´ezivin and O. Gerb´e, “Towards a precise definition of the omg/mda framework,” in ASE ’01: Proceedings of the 16th IEEE international conference on Automated software engineering. Washington, DC, USA: IEEE Computer Society, 2001, p. 273. [8] J. B´ezivin, F. Jouault, and P. Valduriez, “On the need for megamodels,” in Proceedings of Workshop on Best Practices for ModelDriven Software Development at the 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications., Vancouver, British Columbia, Canada, October 2004. [Online]. Available: http://www.softmetaware.com/oopsla2004/mdsd-workshop.html [9] M. Biehl, C. DeJiu, and M. T¨orngren, “Integrating safety analysis into the model-based development toolchain of automotive embedded systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), April 2010, pp. 125+. [10] M. Biehl, C.-J. Sj¨ostedt, and M. T¨orngren, “A modular tool integration approach - experiences from two case studies,” in 3rd Workshop on ModelDriven Tool & Process Integration (MDTPI 2010) at the European Conference on Modeling Foundations and Applications (ECMFA 2010), June 2010. 24
[11] E. Biermann, K. Ehrig, C. K¨ohler, G. Kuhns, G. Taentzer, and E. Weiss, “Graphical definition of in-place transformations in the Eclipse Modeling Framework,” in MODELS 2006, vol. 4199, 2006, pp. 425–439. [Online]. Available: http://dx.doi.org/10.1007/11880240 30 [12] E. Biermann, S. Jurack, C. Krause, T. Arendt, and G. Taentzer, “Henshin: Advanced concepts and tools for in-place EMF model transformations,” in MODELS 2010, October 2010. [Online]. Available: http://www.eclipse.org/modeling/emft/henshin [13] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, “Extensible markup language (XML) 1.0 (fifth edition),” W3C, Tech. Rep., November 2008. [Online]. Available: http://www.w3.org/TR/REC-xml [14] J. Cuadrado and J. Molina, “Modularization of model transformations through a phasing mechanism,” Software and Systems Modeling, 2009. [Online]. Available: http://dx.doi.org/10.1007/s10270-008-0093-0 [15] K. Czarnecki and S. Helsen, “Feature-based survey of model transformation approaches,” IBM Systems Journal, vol. 45, no. 3, pp. 621–645, 2006. [16] M. Davis, R. Sigal, and E. J. Weyuker, Computability, Complexity, and Languages, Second Edition: Fundamentals of Theoretical Computer Science (Computer Science and Scientific Computing), 2nd ed. Morgan Kaufmann, February 1994. [Online]. Available: http://www.worldcat.org/ isbn/0122063821 [17] M. D. Del Fabro and P. Valduriez, “Semi-automatic model integration using matching transformations and weaving models,” in SAC ’07: Proceedings of the 2007 ACM symposium on Applied computing. New York, NY, USA: ACM Press, 2007, pp. 963–970. [Online]. Available: http://dx.doi.org/10.1145/1244002.1244215 [18] S. Efftinge, P. Friese, A. Haase, C. Kadura, B. Kolb, D. Moroff, K. Thoms, and M. Voelter, “openarchitectureware user guide,” openArchitectureWare Community, Tech. Rep., 2007. [19] S. Efftinge and M. V¨olter, “oaw xtext: A framework for textual dsls,” in Eclipsecon Summit Europe 2006, November 2006. [Online]. Available: http://www.eclipse.org/Xtext [20] U. W. Eisenecker and K. Czarnecki, Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000. [21] J.-r. Falleri, M. Huchard, and C. Nebut, “Towards a traceability framework for model transformations in kermeta,” in In: ECMDA-TW Workshop, 2006. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.99.6894 [22] J. M. Favre, “Towards a basic theory to model model driven engineering,” in In Workshop on Software Model Engineering, WISME 2004, joint event with UML2004, 2004.
25
[23] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: improving the design of existing code, ser. Object Technology Series. Addison-Wesley, 1999. [24] R. France, I. Ray, G. Georg, and S. Ghosh, “An aspect-oriented approach to early design modeling,” in IEE Proceedings Software, vol. 151, no. 4, 2004, pp. 173–185. [25] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Addison-Wesley, 1996. [26] S. Hidaka, Z. Hu, H. Kato, and K. Nakano, “Towards a compositional approach to model transformation for software development,” in SAC ’09: Proceedings of the 2009 ACM symposium on Applied Computing. New York, NY, USA: ACM, 2009, pp. 468–475. [Online]. Available: http://dx.doi.org/http://doi.acm.org/10.1145/1529282.1529383 [27] P. Huber, “The model transformation language jungle - an evaluation and extension of existing approaches,” Master’s thesis, Technische Universit¨at Wien, May 2008. [Online]. Available: http://www.big.tuwien.ac.at/ teaching/theses/ma/huber.pdf [28] IKV++ Technologies. mediniQVT. [Online]. Available: http://projects. ikv.de/qvt [29] F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev, “ATL: a model transformation tool,” Science of Computer Programming, vol. 72, pp. 31–39, June 2008. [30] F. Jouault, J. B´ezivin, and I. Kurtev, “Tcs: A dsl for the specification of textual concrete syntaxes in model engineering,” in GPCE 2006, 2006. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi= 10.1.1.103.1929 [31] E. Kalnina, A. Kalnins, E. Celms, and A. Sostaks, “Graphical template language for transformation synthesis,” in Proceedings of Second International Conference SLE 2009, 2009, pp. 244–253. [Online]. Available: http://mola.mii.lu.lv/ [32] A. Kleppe, J. Warmer, and W. Bast, MDA Explained: The Model Driven Architecture—Practice and Promise. Addison-Wesley, 2003. [33] ——, MDA Explained: The Model Driven Architecture—Practice and Promise. Addison-Wesley, 2003. [34] N. Koch, “Classification of model transformation techniques used in uml-based web engineering,” Software, IET, vol. 1, no. 3, pp. 98–111, 2007. [Online]. Available: http://dx.doi.org/10.1049/iet-sen:20060063 [35] D. Kolovos, R. Paige, and F. Polack, “The epsilon transformation language,” in Theory and Practice of Model Transformations, ser. Lecture Notes in Computer Science, A. Vallecillo, J. Gray, and A. Pierantonio, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, vol. 5063, ch. 4, pp. 46–60. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69927-9 4 26
[36] I. Kurtev, “State of the art of qvt: A model transformation language standard,” Applications of Graph Transformations, pp. 377– 393, 2008. [Online]. Available: http://www.springerlink.com/content/ 2g55gw5260q2740h/fulltext.pdf [37] I. Kurtev, J. B´ezivin, and M. Aksit, “Technological spaces: An initial appraisal,” in CoopIS, DOA 2002 Federated Conferences, Industrial track, 2002. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.109.332 [38] I. Kurtev, K. van den Berg, and F. Jouault, “Rule-based modularization in model transformation languages illustrated with atl,” Sci. Comput. Program., vol. 68, no. 3, pp. 138–154, October 2007. [Online]. Available: http://dx.doi.org/10.1016/j.scico.2007.05.006 [39] T. Mens and P. Van Gorp, “A taxonomy of model transformation,” Electr. Notes Theor. Comput. Sci, vol. 152, pp. 125–142, 2006. [40] ——, “A taxonomy of model transformation,” Electr. Notes Theor. Comput. Sci, vol. 152, pp. 125–142, 2006. [41] T. Mens, P. Van Gorp, D. Varr´o, and G. Karsai, “Applying a model transformation taxonomy to graph transformation technology,” in Proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005), vol. 152, 2006, pp. 143–159. [Online]. Available: http://dx.doi.org/10.1016/j.entcs.2005.10.022 [42] J. Miller and J. Mukerji, “Mda guide version 1.0,” Mai 2003. [43] N. Moha, S. Sen, C. Faucher, O. Barais, and J.-M. J´ez´equel, “Evaluation of kermeta for solving graph-based problems,” International Journal on Software Tools for Technology Transfer (STTT), April 2010. [Online]. Available: http://dx.doi.org/10.1007/s10009-010-0150-1 [44] OMG, “Model Driven Architecture (MDA) Guide,” OMG, Tech. Rep., 2003. [Online]. Available: http://www.omg.org/mda/ [45] ——, “Meta Object Facility (MOF), v2.0,” OMG, Tech. Rep., January 2006. [Online]. Available: http://www.omg.org/spec/MOF/2.0/ [46] ——, “MOF 2.0 / XMI Mapping Specification, v2.1.1,” OMG, Tech. Rep., December 2007. [Online]. Available: http://www.omg.org/technology/ documents/formal/xmi.htm [47] ——, “MOF 2.0 Query / View / Transformation,” OMG, Tech. Rep., December 2009. [Online]. Available: http://www.omg.org/spec/QVT [48] ——, “Object Constraint Language (OCL),” OMG, Tech. Rep., 2010. [Online]. Available: http://www.omg.org/spec/OCL/2.2 [49] ——. (2010) Unified Modeling Language (UML). [Online]. Available: http://www.omg.com/uml/
27
[50] E. Seidewitz, “What models mean,” IEEE Softw., vol. 20, no. 5, pp. 26–32, 2003. [Online]. Available: http://dx.doi.org/http://dx.doi.org/10. 1109/MS.2003.1231147 [51] J. Steel and M. Lawley, “Model-based test driven development of the tefkat model-transformation engine,” Software Reliability Engineering, International Symposium on, vol. 0, pp. 151–160, 2004. [Online]. Available: http://dx.doi.org/10.1109/ISSRE.2004.23 [52] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse Modeling Framework (2nd Edition), 2nd ed. Addison-Wesley Professional, January 2008. [Online]. Available: http://www.worldcat.org/ isbn/0321331885 [53] Tata Consultancy Services. ModelMorf. [Online]. Available: //121.241.184.234:8000/ModelMorf/ModelMorf.htm
http:
[54] M. Tisi, F. Jouault, P. Fraternali, S. Ceri, and J. B´ezivin, “On the use of higher-order model transformations,” in Model Driven Architecture Foundations and Applications, R. F. Paige, A. Hartman, and A. Rensink, Eds., vol. 5562. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp. 18–33. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02674-4 3 [55] L. Tratt, “Model transformations and tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 112–122, May 2005. [Online]. Available: http://dx.doi.org/10.1007/s10270-004-0070-1 [56] VDI, “Design methodology for mechatronic systems (VDI 2206),” VDI, Tech. Rep., 2004. [57] E. Visser, “A survey of rewriting strategies in program transformation systems,” in 1st International Workshop on Reduction Strategies in Rewriting and Programming, November 2001. [58] ——, “A survey of strategies in program transformation systems,” Electronic Notes in Theoretical Computer Science, vol. 57, 2001. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28. 4289 [59] W3c, “Xsl transformations (xslt),” W3C, Tech. Rep., November 1999. [Online]. Available: http://www.w3.org/TR/xslt [60] D. Wagelaar, “Composition techniques for rule-based model transformation languages,” Theory and Practice of Model Transformations, pp. 152– 167, 2008. [Online]. Available: http://www.springerlink.com/content/ 761ru4426u037255/fulltext.pdf [61] W. Yang, S. Horwitz, and T. Reps, “A program integration algorithm that accommodates semantics-preserving transformations,” ACM Trans. Softw. Eng. Methodol., vol. 1, no. 3, pp. 310–354, 1992. [Online]. Available: http://dx.doi.org/10.1145/131736.131756
28
Appendix B
Integrating Safety Analysis into the Model-based Development Tool Chain of Automotive Embedded Systems Matthias Biehl, Chen De-Jiu, and Martin T¨ orngren, “Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), April 2010, pp. 125+. c
2010 ACM. Reprinted, with permission.
Integrating Safety Analysis into the Model-based Development Tool Chain of Automotive Embedded Systems Matthias Biehl
Chen DeJiu
Martin T¨orngren
Embedded Control Systems, Royal Institute of Technology (KTH), Stockholm, Sweden {biehl,chen,martin}@md.kth.se
Abstract The automotive industry has a growing demand for the seamless integration of safety analysis tools into the model-based development tool chain for embedded systems. This requires translating concepts of the automotive domain to the safety domain. We automate such a translation between the automotive architecture description language EAST-ADL2 and the safety analysis tool HiPHOPS by using model transformations and by leveraging the advantages of different model transformation techniques. By means of this integration, the safety analysis can be conducted early in the development process, when the system can be redesigned to fulfill safety goals with relatively low effort and cost. Categories and Subject Descriptors D.2.6 [Programming Environments]: Integrated Environments General Terms Design, Reliability, Languages Keywords Safety Analysis, Model-based Development, Architecture Description Language, Tool Integration
1. Introduction An increasing number of industrial systems are provided with new functionalities and enhanced performance enabled by embedded systems. In many cases, the corresponding applications are increasingly safety related, exemplified by automotive driver assistance systems and industrial robots operating without safety barriers. Facing the challenge of developing increasingly advanced safetycritical systems, the automotive industry has a growing demand for the seamless integration of safety analysis tools into the modelbased development tool chain for embedded systems. Such an integrated solution will allow iterative and incremental development of safety critical systems and is a step towards fulfilling the demands of the upcoming standard for safety-critical road vehicles, ISO-CD-26262. Safety is a cross-cutting system property that has to be considered from the start and throughout the development of the system. Safety engineering is an iterative process. It starts with determining safety-critical aspects, proceeds with identifying the causes of failures and deriving the safety requirements and concludes with developing safety solutions.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. LCTES’10, April 13–15, 2010, Stockholm, Sweden. c 2010 ACM 978-1-60558-953-4/10/04. . . $10.00 Copyright
Integrating safety analysis into the development of automotive embedded systems requires translating concepts of the automotive domain to the generic safety and error analysis domain. We assume a model-based development process where automotive concepts are represented by the EAST-ADL2 architecture description language, which supports system design on multiple levels of abstraction. The concepts of the error analysis domain are represented by the safety analysis tool HiP-HOPS. We automate the translation from EAST-ADL2 to HiP-HOPS by using model transformations. We leverage the advantages of different model transformation techniques by decomposing the translation into two distinct phases, and using an appropriate technique for each phase: A phase for conceptual mapping between the domains followed by a phase for representing the output in the desired concrete syntax. With the resulting tight integration of the safety analysis tool and the model-based development environment, the automotive safety engineer can perform the safety analysis repeatedly on refined models with minimal effort. This is compliant with the iterative design activities requiring to invoke the analysis after each change in the system design. The remainder of this work is organized as follows. Section 2 introduces the technology we use in our approach. Section 3 explains our approach for safety analysis tool integration. Section 4 focuses on the model transformation of the approach. By means of a comprehensible case study we demonstrate in section 5 how the integrated safety analysis can be used. We present related work in section 6 before we conclude in section 7.
2.
Technology
In this section we introduce the technology we depend on when integrating tool-based safety analysis into an automotive modelbased development process. 2.1
Model Transformations
Model transformations play a key role in model-based software development. Model transformations describe the relationship between models, more specifically the mapping of information from one model to another one. These model transformation descriptions are interpreted by a model transformation engine. The model transformation engine produces the output model, based on the transformation description and information from the input model. A model transformation involves two models: a source model and a target model, where source and target model can have the same or different metamodels. Model transformations use concepts of the metamodels in their descriptions. Thus they are general enough to describe the mapping for any model specified with the same metamodel. Model transformations are also used in generative programming [4], where they are called generators.
In the following we introduce a classification scheme for model transformations. We can distinguish model transformations with respect to the creation of the target: Model-to-model transformations directly create elements of the target model. Each element in the source model maps to a specific element in the target model. Model-to-text transformations on the other hand create arbitrary, unstructured text. Each source element maps to an arbitrary fragment of text. This kind of transformation is also called model-to-code transformation or code transformation. Model transformations can change the amount of detail presented in the model. They either introduce new details, reduce the amount of detail or leave it unchanged: Refinement transformations (vertical transformations) produce the target model by adding details to the source model. A change in the metamodel might be necessary for this step. This kind of transformation is the most common form. Abstraction transformations (vertical transformations) produce the target model by reducing the amount of detail. Translation transformations (horizontal transformations) produce the target model by expressing the same information found in the source model in a different language. The degree of detail stays the same. Translations are also called horizontal transformations. We can differentiate model transformations according to the metamodels used in the transformation. Endogenous transformations map between the same metamodel. Exogenous transformations map between different metamodels. Model transformations can be written using different languages. We can classify transformations according to the type of model transformation languages they use. Declarative transformation languages describe preconditions of the transformation and the according change with a postcondition. Graph transformations are described in this way, where a left-hand-side is the precondition and the right-hand-side is the postcondition. Operational transformation languages describe the transformation as a sequence of actions. 2.1.1
Model Transformation Engine openArchitecureWare (OAW)
OAW integrates a number of tools for model transformations into a coherent framework [7]. Among other tools, the OAW provides a workflow specification language and the transformation language Xpand. The workflow language is used to control the transformation process and to specify the sequence of transformations between the different models. The Xpand transformation language is a template-based, imperative language for model-to-text transformations. OAW is distributed as a plugin of the Eclipse platform and is able to process models that are conform to the EMF (Eclipse Modeling Framework) [14]. 2.1.2
Model Transformation Engine ATL
The ATLAS Transformation Language (ATL) is a hybrid model transformation language [8]. It includes both declarative and imperative constructs and supports both programming styles. However, the preferred style is declarative, which allows a cleaner and simpler implementation for simple mappings. However, imperative constructs are provided so that some mappings that are too complex to be handled declaratively can still be specified. An ATL transformation program is composed of rules that describe how to create and initialize the elements of the target models. The language is specified both as a metamodel and as a textual concrete syntax. ATL is integrated in the Eclipse development environment and can handle models based on EMF. In this project we chose ATL for its ability to process UML models which are annotated with the UML extension mechanism for profiles, so we are able to process models that are conform to the EAST-ADL2 profile.
2.2
EAST-ADL2
EAST-ADL2 is an architecture description language for the development of automotive embedded systems [3]. It can be used to describe hardware (electronics), software and the environment (mechanics) of an embedded system. The goals of modeling with EAST-ADL2 are to handle complexity and improve safety, reliability, cost, and development efficiency through model-based development. A primary feature of EAST-ADL2 is its capability to structure a model into different abstraction levels. All these levels describe the same system, but on different levels of abstraction and from different viewpoints. Each level is associated with a different stage of the development process. EAST-ADL2 is an information model, connecting different views of the system. The views are influenced by the different engineering traditions and backgrounds in automotive industry. Control engineers focus on the functional view, the design view is often preferred by software engineers. This concept allows functional decomposition, supports analysis activities, design activities, implementation of software and hardware components and variability management. EAST-ADL2 specifies a domain model, which is implemented as a UML profile depending on UML and SysML. Using the EASTADL2 profile for UML, it is possible to create EAST-ADL2 models in any UML design tool, i.e. the Eclipse-based Papyrus UML tool. 2.3
HiP-HOPS
Creating the FMEA (Failure Modes and Effects Analysis) and the FTA (Fault Tree Analysis) by hand is a very laborious and errorprone task, hindering the safety design process. However, safety considerations should be built into the design right from the start and an iterative safety analysis needs to be performed during the design. HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies) can support such an iterative safety design by automating FTA and FMEA and even combining the results. This analysis data can also be the basis for an optimization of the security and reliability of the system. HiP-HOPS expects a model describing the topology of the system (components and their subcomponents) including information about how individual components can fail as well as how failures are propagated. Among other functionalities, HiP-HOPS creates local fault trees, combines them to a system fault tree and calculates a minimum cutset [10].
3.
Tool Integration
To establish the link between EAST-ADL2 system modeling tools and safety analysis tools, they have to be integrated. In his seminal work, Wasserman identifies five different aspects of tool integration [15]: • control integration: tools can inter-operate • data integration: tools can exchange data
• presentation integration: tools have a unified GUI
• platform integration: a common platform provides services as a
basis for integration
• process integration: the SW development processes can be in-
tegrated
In the following we evaluate how these five aspects can be realized for the integration of safety analysis into model-based development. Process integration cannot be done by software itself, but depends on personal preferences, company culture and development organization. Automation of safety analysis has several advantages: It makes safety analysis easy, it is readily available and allows the engineers to obtain a thorough and quick analysis of their design. This fast feedback based on analysis results allows engineers to
perform more micro iterations in the development process, where each iteration refines and improves the previously built model. The safety analysis is integrated in a the development and more specifically in the safety analysis process. This process is aligned to upcoming ISO-CD-26262 standard and described in an EPF (Eclipse Process Framework) model for EAST-ADL2. The Eclipse platform provides a framework for platform and presentation integration. We use it by implementing our tool as an Eclipse plugin. We extend the graphical user interface of Eclipse by adding menus to invoke safety analysis for a given EAST-ADL2 model. This ensures seamless integration in the UML modeling environment and keeps the overhead for safety analysis experienced by the user as low as possible and thus allows for an iterative safety development process. Control integration is realized by parameterizing and executing the model transformation engines and the safety analysis tool from within the developed plugin. Data integration in this context is concerned with the transformation of modeling data. We transform from an EAST-ADL2 representation to a HiP-HOPS representation, while preserving the semantics. State of the art data integration for model-based development is supported by powerful model transformation engines and languages. Different transformation languages and engines are available, each of them solving a particular problem especially well. This is why the next section is dedicated to choosing the right model transformation language.
4.
Translation from EAST-ADL2 to HiP-HOPS
Integrating safety analysis into the development of automotive embedded systems requires data integration. This can be achieved by translating concepts of the automotive domain to the error analysis domain. In the context of this work the automotive concepts are represented by the architecture description language EAST-ADL2 including its dependability model and the concepts of the error analysis domain are represented by the safety analysis tool HiP-HOPS. We need to expose the information of the EAST-ADL2 error models to HiP-HOPS in its native input format. 4.1
Model Transformation
We automate the translation between EAST-ADL2 and HiP-HOPS using model transformations. Model transformation languages are domain specific languages for extracting information from models, for building and for manipulating models. Model transformation languages, paradigms and engines have been classified in [5] and [9]. Different model transformation languages have their strengths and weaknesses in solving particular types of tasks [5]. A challenge is choosing the right tool for the model transformation task at hand. We have identified the following fundamental requirements for the model transformation engine used in our solution. • Needs to be able to process UML models which have a UML
profile applied, in our case this is the EAST-ADL2 profile
• Needs to produce text output, not a model
• Needs to be maintainable, the source code needs to be compact
and reusable, since both EAST-ADL2 and HiP-HOPS evolve
• Needs to integrate as a plugin into the modeling environment
The model transformations we have looked at, do not fulfill all requirements at once. For instance we could not find an engine that allows us to produce text output and process the EAST-ADL2 profile. For this reason, we decompose the model transformation into two specialized transformations. Each of the two transformations fulfills the requirements partially, but the two transformations together fulfill all requirements.
4.2
Transformation Design
We leverage the advantages of different model transformation techniques by splitting the translation into two distinct phases and using an appropriate model transformation technique for each phase. Each phase has a distinct purpose and tackles a different concern.
Figure 1. Transformation Design (1) Semantic Mapping Transformation: The first transformation step is a model-to-model transformation and is called M2M Trafo in figure 1. It transforms an EAST-ADL2 model that was created in the Papyrus UML modeling environment into an intermediate model. The structure of the intermediate model resembles the HiPHOPS grammar, so it is close to the structure of the desired output. This stage performs the semantic mapping between the domains of EAST-ADL2 and that of HiP-HOPS. However, this stage is not concerned with the actual representation of the data. (2) Representation Transformation: The second transformation step, called M2T Trafo in figure 1, takes the intermediate model and creates the input file for the HiP-HOPS program. This step is mainly concerned with the representation of the information according to the concrete syntax required by HiP-HOPS. We will discuss both transformations in more detail in sections 4.4 and 4.5. There we use the scheme for classifying model transformation introduced in section 2.1 to determine the type of each of the two transformations and to choose a transformation engine fitting the properties of that particular transformation. 4.3
Involved Models and Metamodels
Three different models are involved in this model transformation. An EAST-ADL2 model, an intermediate HiP-HOPS model and the final HiP-HOPS file. The EAST-ADL2 model serves as the initial source model, and is conform to the EAST-ADL2 metamodel. The HiP-HOPS file is the final outcome of the transformation and conforms to the HiP-HOPS grammar. We discuss the metamodels separately in the following sections. 4.3.1
EAST-ADL2 Error Model
EAST-ADL2 models created in the Eclipse-based Papyrus UML tool have a metamodel that is a composition of several separate metamodels. This metamodel consists of the UML metamodel and the EAST-ADL2 profile definition. These artifacts are combined by the Eclipse framework to the EAST-ADL2 metamodel. However, this combined metamodel is not an autonomous entity or file. This complicates the model transformation and limits the choice of model transformation engines. The EAST-ADL2 domain model contains concepts for modeling the anomalies of a system in a so called error model, which describes the failure semantics of a system by relating the occurrences of internal errors and the propagations of such errors [3]. These error modeling constructs are separated from the constructs used for the nominal system definition, to clearly separate their different natures: error models are purely descriptive while nominal models are prescriptive and may be used for code generation. The domain model of the EAST-ADL2 error modeling concepts is illustrated in figure 2. In the following we introduce the core con-
cepts. The ErrorModelType metaclass represents the container for maintaining the information relating to the anomalies of a system, function, software component, or hardware device. The ErrorModelPrototype metaclass describes an instance of an ErrorModelType. Even though these concepts are similar to the concepts for nominal behavior, the decomposition of the system into ErrorModelTypes is kept separate from the nominal decomposition into FunctionTypes. This makes it possible to have either totally aligned or separate topologies in error modeling than in the targeted nominal architecture, depending on the needs for error analysis. An ErrorPropagationLink describes how failures in one component can propagate to other components. 4.3.2
HiP-HOPS Ecore Metamodel
Due to the decomposition into two separate transformations we introduced an intermediate model which connects the two transformations (see figure 1). The intermediate model is conform to a HiPHOPS Ecore metamodel that is aligned to the HiP-HOPS grammar. It is conform to the Ecore metametamodel. The HiP-HOPS Ecore metamodel is depicted in figure 3. At its core, the HiP-HOPS Ecore metamodel is a hierarchical decomposition into systems and components, where a system can contain components, which contain an implementation, which can contain another system. Thus hierarchical systems of any depths can be built recursively. Components and systems can be annotated with failure data, i.e. how failures propagate through the systems and where they originate from. 4.4
Semantic Mapping Transformation
The purpose of the semantic mapping transformation is to map concepts from EAST-ADL2 to HiP-HOPS in a way that preserves the semantics of the original model, even though the structure of the model must be changed heavily. EAST-ADL2 models and HiPHOPS models are structurally different. This can be demonstrated by the following example. EAST-ADL2 follows the concepts of declaring types first and referencing to the declaration from each point of use. In HiP-HOPS on the other hand, the declaration and usage of a type is coupled, types are declared at the same point as they are used. Thus the declarations have to be inlined into every point of usage, when transforming from EAST-ADL2 to HiPHOPS. Table 1 lists the detailed mapping between EAST-ADL2 concepts and HiP-HOPS concepts. In Figure 4 we show the part of this transformation that maps ErrorModelPrototypes of EASTADL2 to Components of the HiP-HOPS Ecore Metamodel. According to the classification scheme introduced in section 2.1 the representation transformation can be classified as an exogenous, horizontal, model-to-model transformation. Model-to-model transformations are well suited for our semantic mapping transformation, because both input and output are models. Mapping patterns can be described by relational and declarative transformation languages in a concise manner. Our solution leads to relatively short source code for the solution. We selected the ATLAS Transformation Language (ATL), a language that allows a choice of relational and imperative constructs. It furthermore allows processing of models that have a profiled metamodel, i.e. a metamodel that consists of a metamodel and a profile description. In our case the EAST-ADL2 metamodel consists of the UML metamodel and the EAST-ADL2 profile. 4.5
Figure 3. HiP-HOPS Ecore metamodel
Representation Transformation
The purpose of the representation transformation is the generation of a textual description based on the intermediate model. According to section 2.1 the representation transformation can be classified as an endogenous, horizontal, model-to-text transformation.
Figure 4. Example: part of the semantic mapping transformation in ATL
EAST-ADL2 Pattern (Source) ErrorModelType ErrorModelType.errorConnector ErrorModelType.parts ErrorModelPrototype.type.errorPort ErrorModelPrototype ErrorModelPrototype.type. errorBehaviorDescription.internalErrorEvent ErrorModelPrototype.type. errorBehaviorDescription.faulureLogic ErrorModelPrototype.type
EAST-ADL2 Type ErrorModelType ErrorPropagationLink ErrorModelPrototype ErrorPort ErrorModelPrototype ErrorEvent String ErrorModelType
HiP-HOPS Pattern (Target) System System.Lines System.Component System.Component.Ports System.Component.Implementation System.Component. Implementation.FData.basicEvent System.Component. Implementation.FData.outputDeviation System.Component. Implementation.System (recursion)
Table 1. Semantic mapping between EAST-ADL2 and HiP-HOPS Textual representations can be generated particularly well with model-to-text transformation languages. We choose the Xpand language of OpenArchitectureWare. Xpand is a template-based model transformation language, which incorporates the output in the form of templates into the control structure. Figure 5 shows a part of this transformation that creates a textual representation of the intermediate model that can serve as input to HiP-HOPS. The intermediate model is designed to have structure which is aligned to HiP-HOPS. No structural changes are required in this transformation. The focus is on serializing the model as text. When serializing a graph structure to text, as done here, the choice of exploration strategy is important, as it dictates the order of the output. We explore the intermediate model using a depth first exploration strategy to ensure the correct serialization of the HiPHOPS format.
• Since we chose appropriate tools for each steps, the resulting
model transformation source code is very concise, resulting in a maintainable codebase.
5.
Case Study
To demonstrate how the safety plugin works, we have created a hierarchical system model in EAST-ADL2 with a focus on the system’s comprehensibility. The model is depicted in figure 6 and contains three functions. While F1 and F3 are atomic functions, F2 contains two subcomponents, a primary component F21 and a standby component F22, where the later takes over if the primary fails.
Figure 5. Example: part of the representation transformation in OAW Xpand 4.6
Benefits of the Chosen Decomposition
In this section we discuss the benefits of this solution. • Our solution separates two different concerns of the transforma-
tion from EAST-ADL2 to HiP-HOPS: (1) the semantic mapping between the domains of EAST-ADL2 and that of HiPHOPS and the (2) details of the concrete syntax of the HiPHOPS input file.
• Each transformation is a separate, self-contained module, which
can be developed, changed and tested independently. This decomposition into two separate transformations allows us to parallelize the work on the two transformations and reduce development time. It also allows the two transformations to evolve independently without affecting each other, e.g. a change in the HiP-HOPS grammar will only affect the representation transformation.
• As discussed in the section on data integration, different trans-
formation engines have different strengths which can be played out for different concerns. The solution allows us to select an appropriate tool for each concern.
Figure 7. Fault tree of the hot standby system of figure 6 This pattern is called hot standby. It consists of a primary component and a standby component that is ready to take over if the primary fails. The pattern is applied in reliability engineering as a failover mechanism to improve the reliability and safety of a system. The result of the safety analysis shows, how this pattern affects the outcome of the safety analysis. We run our automated model transformation for the model depicted in figure 6. The EAST-ADL2 model is transformed into the HiP-HOPS language, as described in section 4.2. HiP-HOPS subsequently performs the analysis based on the transformed data and presents the results in various ways. The results can be represented as minimal cutsets, FMEA tables or fault trees. A fault tree of the system in figure 6 is depicted in figure 7. The results of the safety analysis need to be interpreted by a safety engineer. Depending on the current stage of development, the engineer can use this information either to create and refine safety requirements or to adjust his design. He can do this e.g. by
Figure 2. Domain Model of the EAST-ADL2 Error Modeling Concepts
Figure 6. EAST-ADL2 model describing the failure propagation in a hot standby system
increasing redundancy, if a higher level of reliability is desired, or reducing the cost by removing unnecessary redundancy.
6.
Related Work
The need to bridge the gap between the safety and system design disciplines has been identified in several domains. Integration in general covers the need to align processes, tools and the competences of the developers. The focus here is on model and tool integration between system design models (which may refer to structure and/or behavior at different abstraction levels) and safety analysis models such as failure modes and effects analysis and fault tree analysis models. Earlier work that has addressed this gap includes: • As part of the SETTA project, Papadopoulos et al. annotate
Matlab/Simulink models with FMEA information and provide an export for fault-tree generation [11].
• In the ESACS project and its follow up project ISAAC this
gap was identified and addressed by providing tools, such as Statemate Magnum and Scade, to perform automated safety analysis starting from a system design model.
• Dumas et al. [6] perform model transformations between
AADL, the Architecture and Analysis Description Language, and the analysis tool AltaRica [1].
• Price et al. [12] focus on safety analysis of electrical systems for
cars. They explain the tradeoff between numerical and qualitative analysis and point out the importance of continuous safety analysis as opposed to snapshot analysis. While this work focuses mainly on electrical system, our approach can be used for electrical systems, software systems, or a combination of the two.
• The integration of HiP-HOPS and EAST-ADL2 has been at-
tempted in the ATESST research project [13]. This resulted in a monolithic Java program where the code for data integration, control integration and presentation integration was mixed, resulting in low maintainability. In this work we specifically addressed these shortcomings by separating the different integration issues and by designing a transformation that leverages state-of-the-art model transformation technology and at the same time separates mapping concerns from representation concerns.
• A recent project that is based on all these advances and that has
the ambition to provide multi-domain solutions, is the CESAR project [2].
7.
Conclusion and Future Work
In this work we have shown how we integrated the safety analysis tool HiP-HOPS into the automotive model-based development tool chain based on EAST-ADL2. We used different model transformation techniques to translate the relevant information from the automotive domain to the safety analysis domain. This link enables early safety analysis. Currently our analysis supports fault tree analysis for models of either hardware or software. We work on supporting fault tree analysis that considers the propagation of failures between hardware and software. This will allow us to analyze e.g. the effects of hardware failures on the software and how the software can handle them. Acknowledgments The research presented in this article was supported by funding from the 7th Framework Programme of the European Community under grant agreement no. 224442.
References [1] M. Boiteau, Y. Dutuit, A. Rauzy, and J. P. Signoret. The altarica dataflow language in use: modeling of production availability of a multistate system. Reliability Engineering & System Safety, 91(7), 2006. [2] CESAR Project. Cost-efficient methods and for safety relevant embedded systems, 2010. http://www.cesarproject.eu.
processes URL
[3] D. Chen, R. Johansson, H. L¨onn, Y. Papadopoulos, A. Sandberg, F. T¨orner, and M. T¨orngren. Modelling support for design of safetycritical automotive embedded systems. In Computer Safety, Reliability, and Security, Lecture Notes in Computer Science SAFECOMP2008, 2008. [4] K. Czarnecki and U. W. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, Boston, 2000. [5] K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, 45(3):621–645, 2006. [6] X. Dumas, C. Pagetti, L. Sagaspe, P. Bieber, and P. Dhaussy. Vers la g´en´eration de mod`eles de sˆuret´e de fonctionnement. Revue des Nouvelles Technologies de l’Information, RNTI-L-2:157–172, 2008. [7] S. Efftinge, P. Friese, A. Haase, C. Kadura, B. Kolb, D. Moroff, K. Thoms, and M. Voelter. openarchitectureware user guide. Technical report, openArchitectureWare Community, 2007. [8] F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev. ATL: a model transformation tool. Science of Computer Programming, 72:31–39, June 2008. [9] T. Mens and P. Van Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci, 152:125–142, 2006. [10] Y. Papadopoulos and J. A. McDermid. Hierarchically performed hazard origin and propagation studies. In M. Felici, K. Kanoun, and A. Pasquini, editors, SAFECOMP, volume 1698 of Lecture Notes in Computer Science, pages 139–152. Springer, 1999. [11] Y. Papadopoulos, J. A. McDermid, R. Sasse, and G. Heiner. Analysis and synthesis of the behaviour of complex programmable electronic systems in conditions of failure. Reliability Engineering and System Safety, 71(3):229–247, 2001. [12] C. J. Price, N. A. Snooke, and S. D. Lewis. A layered approach to automated electrical safety analysis in automotive environments. Computers in Industry, 57(5):451– 461, 2006. doi: 10.1016/j.compind.2006.02.001. URL http://dx.doi.org/10.1016/j.compind.2006.02.001. [13] J. Shi, D. Chen, and M. T¨orngren. Case studies on integrating simulink, uml and safety analysis through model transformations. Technical report, KTH, Mechatronics Lab, 2007. [14] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks. EMF: Eclipse Modeling Framework (2nd Edition) (Eclipse). Addison-Wesley Longman, Amsterdam, 2nd revised edition (rev). edition, January 2009. ISBN 0321331885. URL http://www.worldcat.org/isbn/0321331885. [15] A. I. Wasserman. Tool integration in software engineering environments. In F. Long, editor, Software Engineering Environments, International Workshop on Environments Proceedings, number 467 in Lecture Notes in Computer Science, pages 137–149. Springer-Verlag, September 1989. URL http://www.springerlink.com/content/p582q2n825k87nl5/.
Appendix C
A Modular Tool Integration Approach - Experiences from two Case Studies Matthias Biehl, Carl-Johan Sj¨ ostedt, and Martin T¨ orngren, “A Modular Tool Integration Approach - Experiences from two Case Studies,” in 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI2010), June 2010.
A Modular Tool Integration Approach Experiences from two Case Studies Matthias Biehl, Carl-Johan Sj¨ostedt, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,carlj,martin}@md.kth.se
Abstract. In the model-driven development process of automotive embedded systems a number of specialized tools are used to support various development tasks. Each tool needs to work seamlessly with artifacts created by other tools to increase the efficiency of development. We identify desirable properties for integrating the data of different tools. We then propose an approach for decomposing the data integration into modular steps that fulfill these properties. We report our experiences from applying this approach to integrate simulation capabilities and functionality for safety analysis into a model-based development environment. Key words: Tool Integration, Model Transformation
1
Introduction
Model-based development is an approach that uses models as primary artifacts for describing a system. During development a series of different models is created, refined, analyzed and transformed. The tools that are used to manipulate and develop the models are highly specialized and have their strength in supporting a particular development task or phase. Different tools are used to work with the modeling data, and often the output created by one tool needs to be the input to another tool. The tools need to be aligned in such a way that they form a tool chain. Not only tools for creating and designing models need to be integrated, but also tools for analysis and simulation. Some of the tools are proprietary and closed, thus they cannot be modified to support a particular integration scenario. The tools and their modeling data need to be integrated to realize the vision of a seamless model-based development approach. While it is possible to achieve an ad-hoc integration between two tools with some manual work, the focus of this paper is on working towards a systematic solution for model-based tool integration. In this work we extract a modular tool integration approach from the commonalities we have identified based on the experiences from several point-to-point integration approaches. This work has been carried out in the context of developing EAST-ADL [3], a modeling language for automotive embedded systems. We report on experiences from two case studies involving tool integration between EAST-ADL and the simulation
tool MATLAB/Simulink [11] as well as between EAST-ADL and a reliability analysis tool HiP-HOPS [13]. The remainder of this document is structured as follows. In section 1.1 we introduce some basic terms and technology. Section 2 describes the requirements for data integration. Section 3 introduces our modular approach for data integration fulfilling the previously identified requirements. In section 4 we describe two case studies using our proposed approach. In section 5 we introduce related work and conclude in section 6.
1.1
Terms and Technology
The technical space of a model concerns the technology used for representation of the model [12]. Typical technical spaces are EMF (Eclipse Modeling Framework) or XML. The technical space comprises all modeling levels M0-M3 by the OMG. Each technical space has its own metametamodel and its own set of tools and technologies to interact with the models. Model transformations describe the relationship between models, more specifically the mapping of information from one model to another one. A model transformation involves two models: a source model and a target model, where source and target models can have the same or different metamodels. A model transformation description is written in a special purpose language, a model transformation language. The transformation description is usually given by a set of model transformation rules, describing how a model in the source language can be transformed into a model in the target language [10]. The model transformation descriptions are interpreted by a model transformation engine which produces the target model-based on the transformation description and information from the source model. Model transformations are based on concepts of the metamodels, thus they can map any model that corresponds to the metamodel. In this work we use two different model transformation engines, a model-to-text and a model-to-model transformation engine. In the following paragraphs we introduce these engines. OpenArchitecureWare (OAW) integrates a number of tools for model transformations into a coherent framework [5]. OAW provides a workflow specification language and the transformation language Xpand. The Xpand transformation language is a template-based, imperative language for model-to-text transformations. The ATLAS Transformation Language (ATL) is a hybrid model transformation language [8]. It includes both declarative and imperative constructs and supports both programming styles. However, the preferred style is declarative, which allows a cleaner and simpler implementation for simple mappings. ATL is integrated in the Eclipse development environment and can handle models based on EMF.
2
Needs for Data Integration
There are several dimensions of tool integration, Wassermann [15] classifies them into the dimensions of data integration, control integration, process integration, platform integration and presentation integration. In this paper we mainly focus on one dimension of tool integration, which is data integration. The data of model-based tools is represented by models. However, these models adhere to different metamodels which determine the structure of the data and the models are represented using different technical spaces. Goals and desired properties for the integration solution are simplicity and understandability, maintainability and evolvability (i.e. if tools change their interface, the tool integration to change the interface as well), exploiting advantages of different model transformation paradigms. When data needs to be integrated between Tool A and Tool B, the data of Tool A has to be expressed in such a way that it can be used by Tool B. In this process, some properties of the data need to be changed, while other properties need to be preserved. In the following sections we identify these properties. 2.1
Changes of Properties for Data Integration
The following properties of the data might need to be changed for data integration: – Change of the abstract syntax: The structure or syntax of the data might need to be adapted to the target tool. The information of the source tool needs to be rearranged to adhere to the structure expected by the target tool. For example one tool might represent data in a nested tree structure, while another represents the same information as a list. Syntactic changes or restructuring of the information is the domain of model transformations. This part deals with the selection of appropriate information from the source model and restructuring it appropriately. The mapping is based on the information in the metamodel of both source and target model. This step is independent of the technical space used by the target tool. – Change of the technical space: Models can be represented using different technical spaces. The information needs to be represented by the technical space expected by the target tool. Even if the information is structured as expected by the target tool, it can be represented using different technical spaces. The same structure can be represented using e.g. XML, an EMF model, a text-based format or a proprietary format. The above mentioned properties are orthogonal to each other and can be changed independently. It is for example possible to change the technical space while preserving the abstract syntax. 2.2
Preservation of Properties for Data Integration
The following properties of the data might need to be preserved for data integration:
– Preservation of the concrete syntax and graphical layout: Models are often presented to the user in a graphical form. The user can convey information by the graphical placement of model elements. It can e.g. be expressed that certain elements belong together by placing them close to each other on the drawing canvas. In a textual concrete syntax, similar grouping can be expressed e.g. by the proximity of variable declarations. – Preservation of the semantics: If the integrated tools are similar, a mapping can be found that is semantics preserving, i.e. the meaning of the two models is the same, even though it is represented in a different technical space or using a different abstract syntax. Semantics-preserving transformations change the way computations are performed without changing the values computed. – Approximation of the semantics: If the integrated tools have fundamentally different assumptions, it might be difficult to completely preserve the semantics when bridging the gap between tools. Instead the mapping between the tools can approximate a preservation of the meaning of the model. Approximation can preserve the essential properties of the model. An example is the mapping from a complex state machine to a simplified state machine or the mapping between a nonlinear mathematical function and a linear mathematical function.
3
A Modular Approach for Data Integration
In our solution we use the principle of separation of concerns to structure the data integration in such a way that the two issues identified in section 2.1 remain independent. That way we achieve a modular solution, having advantages for maintenance, evolution, understandability and reuse.
Fig. 1. Technical Space Bridges and Structural Bridges
Fig. 1 presents our approach for data integration of three different tools. Each of Tool A and Tool B use different metamodels to represent their data and different technical spaces. Neither tool uses EMF as their technical space. EMF is the adopted technical space for integration. This requires that each tool represents the relevant data in the technical space of EMF. A third tool - Tool C - already represents its data using EMF-models and hence does not require an intermediate model or technical space bridge. Its data can be mapped using a structural bridge. This can for example be the EMF-based modeling environment Papyrus. For both Tool A and Tool B there is an associated intermediate model (see section 3.1), that stores the relevant tool data in EMF, the adopted technical space for integration. A technical space bridge (see section 3.2) crosses the technical space between the tools and EMF to import or export the relevant data. A structural bridge (see section 3.3) links the elements of the intermediate models and changes the abstract syntax so that the semantics is preserved (or approximated). 3.1
Intermediate Model
Intermediate models are the tool-specific models that represent tool data in the technical space for integration. These intermediate models are syntactically aligned with the tool data, meaning that the intermediate data is structured in the same way. The difference between the intermediate model and the tool data is the technical space. In a tool chain, the tool data is first represented as an intermediate model using a technical space bridge, then a structural bridge is used to map concepts to the intermediate model of the target tool, finally the technical space bridge of the target tool represents the concept in a tool specific way. The intermediate model usually focuses on a certain subset of the tool data that is considered relevant in the context of integration. Thus the intermediate model is a simplification of the tool data. In Fig. 1 this is illustrated by a smaller circle for the intermediate metamodel. Irrelevant data, such as certain parameters, details or redundant data are left out. The amount of data that needs to be included in the intermediate model depends on the use case. If complete roundtrip integration is required, the intermediate model needs to be complete. However the limitation on a relevant subset of the tool data allows the transformation to stay small and maintainable. 3.2
Technical Space Bridge
Technical space bridges have the purpose of transitioning data between the external representation of the tool and the intermediate model in the technical space chosen for integration. Technical space bridges can be used in two directions, as extractors and as injectors. Extractors read proprietary tool-specific data and represent this data in the technical space of integration. Injectors deal with representing model data in a tool specific way. Since we propose that the
intermediate model is as small as possible, the extractor leaves out irrelevant data, whereas a injector adds missing information in the form of default values. Technical space bridges are trivial when the tool already processes models of the adopted technical space for integration. Otherwise, technical space bridges are specific to each tool that is integrated. They are hard to generalize and hence we survey the different mechanisms for injecting or extracting data from proprietary tools: – Reading and writing files are the usual way to exchange data. Parsers can be used as extractors and model-to-text transformations can be used as injectors. – For injection of data into legacy tools we can use program parameters and stdin when calling the tool, for extraction we can use stdout. – An application programming interface (API) can be used to inject and extract data from the tool. – A component infrastructure (e.g. CORBA, DCOM) or web service can be used for bidirectional data exchange, if the tool provides these facilities. – The scripting language or macro inside the target tool can be used for injection or extraction of tool data. The first few mechanisms are similar, as all of them use external means to get hold of the data, while the last mechanism uses the internal capabilities of the tool to make the information available. 3.3
Structural Bridge
Structural bridges map corresponding data elements of different tools. Model transformations describe the relationship between models and thus they can be used as a mechanism for structural bridges. Structural bridges can assume that relevant tool data is available as an intermediate model in a common technical space for integration, which is EMF in our solution. However, a large number of model transformation languages, engines and tools exist, which have different characteristics that can be relevant for certain integration tasks. An overview and a classification of the transformation tools is provided in [12, 4]. Picking the right model transformation tool for the task at hand is a challenge. The selection of the model transformation tools is dependent on the technical space that is involved and on other properties offered by the transformation tool, such as bidirectionality, traces and programming paradigms. In the case of a common technical space, a declarative language such as ATL can express the mappings in a simple and concise way [7].
4
Case Studies
To validate our integration architecture, we performed two case studies. Both case studies are based on the architecture description language EAST-ADL [3], a language for modeling the architecture of automotive embedded systems.
4.1
Integration of a Reliability Analysis Tool
During the model-based development in EAST-ADL, the reliability of the developed system has to be determined. We chose HiP-HOPS as a tool for reliability analysis, as it supports fault tree analysis and failure modes and effects analysis [13]. We integrated HiP-HOPS with EAST-ADL as described in earlier work [1]. This integration is unidirectional and the data from EAST-ADL is exported to HiP-HOPS for analysis.
Fig. 2. Export from EAST-ADL to HiP-HOPS
The tool for developing EAST-ADL models, the Papyrus UML editor, does not require a specific technical space bridge, as it produces compatible EMF models in the technical space of integration already. In this case, the intermediate model is equal to the tool data. The reliability analysis tool HiP-HOPS expects textual input, which can be synthesized from the EAST-ADL model by a technical space bridge and a structural bridge. We used the integration architecture described in section 3. Intermediate Model As shown in Fig. 2 we introduce an intermediate model which serves as the interface between technical space bridge and a structural bridge. The intermediate model conforms to a HiP-HOPS Ecore metamodel that is aligned with the HiP-HOPS grammar. Structural Bridge The structural bridge transforms an EAST-ADL model that was created in the Papyrus UML modeling environment into an intermediate model. The transformation is called M2M Trafo in Fig. 2. The structure of the intermediate model resembles the HiP-HOPS grammar, so it is close to the structure of the desired output. This stage performs a semantics-preserving mapping between the domains of EAST-ADL and that of HiP-HOPS. However, this stage is not concerned with the actual representation of the data. The purpose of the structural bridge is to map concepts from EAST-ADL to HiP-HOPS in a way that preserves the semantics of the original model, even though the structure of the model must be changed heavily. EAST-ADL models and HiP-HOPS
models are structurally different. This can be demonstrated by the following example. EAST-ADL follows the concepts of declaring types first and referencing to the declaration from each point of use. In HiP-HOPS on the other hand, the declaration and usage of a type is coupled, types are declared at the same point as they are used. Thus the declarations have to be inlined into every point of usage, when transforming from EAST-ADL to HiP-HOPS. Technical Space Bridge The purpose of the technical space bridge for HiPHOPS is the generation of a textual description based on the intermediate model. The technical space bridge takes the intermediate model as input and creates the tool-specific file for the HiP-HOPS program. This step is mainly concerned with the representation of the information according to the concrete syntax required by HiP-HOPS. No structural changes are required in this transformation. The focus is on serializing the model as text. The technical space bridge is realized as a model-to-text transformation and can be classified as an endogenous, horizontal, model-to-text transformation. We choose the Xpand language of OpenArchitectureWare to implement the technical space bridge. Xpand is a template-based model transformation language, which incorporates the output in the form of templates into the control structure. 4.2
Integration of a Simulation Tool
The tool-suite MATLAB/Simulink is a simulation tool used at various stages of automotive product development for different purposes, e.g. control design, code generation, hardware-in-the-loop testing, etc.. We have developed a bidirectional tool integration between Simulink and EAST-ADL. The first version of the tool was presented in [14]. The current version presented here follows the same approach to separate the technical space bridge from the structural bridge. The integration is bidirectional and supports import from Simulink to EAST-ADL (see Fig. 3) and export from EAST-ADL to Simulink (see Fig. 4).
Fig. 3. Import from Simulink to EAST-ADL
Fig. 4. Export from EAST-ADL to Simulink
Intermediate Model Simulink has an extensive set of tool data using a large number of different element types and parameters. Not all of the details contained in the tool data are relevant for the integration with EAST-ADL. A large intermediate model would make the structural bridge more complicated and harder to maintain. That is why we create an intermediate model from only the relevant subset of the tool data (see Fig. 5)
Structural Bridge The purpose of the structural bridge is to map concepts between EAST-ADL and Simulink in such a way that the semantics of the original model is preserved. For example, Simulink Lines correspond to EASTADL FunctionConnectors; Simulink Inports and Outports both correspond to the same concept FunctionFlowPorts in EAST-ADL, only differentiated by the value of the direction attribute. We use ATL for implementing the structural bridge.
Technical Space Bridge We have evaluated two ways of accessing Simulink model data, first by parsing the .mdl files using a metamodel of the Simulink data file (as presented in [14]), and second by using the MATLAB API. Using the MATLAB API more data is available but the downside is that it provides too much information: A regular Simulink block has more than 120 blockparameters, of which many of them are rarely used. The large number of exceptions for certain parameters and block-types resulted in an unmaintainable and inefficient solution. Hence, the current solution is a combination of using the API and .mdl files. We store all modeling elements inside .mdl files, so they can be used in model reference blocks. The Simulink library mechanism works in a similar way and could possibly also be used in a future version of the technical space bridge. By using Simulink’s native .mdl format for storing the system containment, it is ensured that valid models are produced, and most Simulink constructs can be used. The ports and connections between these model reference blocks are translated so it is possible for model reference blocks to contain other model reference blocks.
Fig. 5. Intermediate Metamodel for Simulink
5
Related Work
Karsai et al. identify two patterns for tool integration [9], one with an integrated data model and a second pattern based on process flows. Our approach is similar to the second pattern, however it does not require the extensive backplane solution. While Karsai describes a pattern, our approach is a concrete solution for the automotive domain. ModelBus is an integration infrastructure [6], providing services such as model storage and version management. Tool adapters are connected using web services. Since the ModelBus infrastructure does not constrain the modularization of the connected services, the approach proposed in this paper is orthogonal to the ModelBus infrastructure, allowing both approaches to be combined. Cuadrado et al. survey different techniques for the modularization of model transformations. The work differentiates between internal and external composition of model transformations and proposes a phasing mechanism for internal composition [2]. Our approach uses external composition as it allows us to use different model transformation languages and engines that are fit for the particular purpose.
6
Conclusion
In this work we have analyzed the needs for exchanging data for tool integration. Whereas some aspects of the data need to be changed such as technical space and the abstract syntax, other aspects need to be preserved such as semantics and layout. We present a modular tool integration approach that uses separation of concerns to modularize and separate the identified changes in technical space and abstract syntax. Technical space bridges bring tool data into the technical space of models and represent the data as an intermediate model. The tool-specific
intermediate metamodel is a simplification of the tool data. The intermediate metamodel is designed to comprise only the subset of the tool data that is relevant for the integration. Structural bridges translate between concepts of different intermediate models. We applied this approach for integrating two external tools within a development environment for EAST-ADL and identified the following properties of our solution: – Our solution separates two different concerns of the tool integration: (1) the structural bridge between the domains of EAST-ADL and that of HiPHOPS/Simulink and the (2) technical space bridge for representation in the technical space of the tool. – Each part is a separate, self-contained module, which can be developed, changed and tested independently. This decomposition into two separate modules allows us to parallelize the work on the two transformations and reduce development time. It also allows the two transformations to evolve independently without affecting each other. – As the HiP-HOPS tool is evolving, it is being updated and with it its external data representation. The tool introduced an XML representation of its input data. When integrating this new version of HiP-HOPS we needed to adapt our transformation. Due to the modular organization of our model transformation the necessary changes could be localized to the technical space bridge only, leaving the structural bridge unaffected, thus ensuring maintainability and evolvability. – The solution allows us to select an appropriate tool for each concern. A declarative model-to-model transformation language was chosen for the structural bridge and a model-to-text transformation languages for the technical space bridge. – Due to the intermediate metamodel, which is a subset of the tool data, the transformation is comparably simple. Since we chose appropriate tools for each steps, the resulting model transformation source code is simple and concise. When we compare these properties to the goals put forward in section 2, our approach is able to fulfill them. 6.1
Future Work
We plan to connect the transformations described in our case study with tool integration infrastructure such as ModelBus. Also, we would like to create a tool chain, in which we can replace a specific tool by another tool. The reduce the dependence on a particular tool and mitigates the risk of vendor lock-in. Acknowledgements We would like to thank Jad El-Khoury for his comments on earlier versions and Alex Schenkman for his programming efforts. This work has been funded by the European Commission under grant agreement no. 224442.
References 1. Matthias Biehl, Chen DeJiu, and Martin T¨ orngren. Integrating safety analysis into the model-based development toolchain of automotive embedded systems. In Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), pages 125+, April 2010. 2. Jes´ us Cuadrado and Jes´ us Molina. Modularization of model transformations through a phasing mechanism. Software and Systems Modeling, 2009. 3. Philippe Cuenot, Patrik Frey, Rolf Johansson, Henrik L¨ onn, Yiannis Papadopoulos, Mark-Oliver Reiser, Anders Sandberg, David Servat, Ramin T. Kolagari, Martin T¨ orngren, and Matthias Weber. The east-adl architecture description language for automotive embedded software. Model-Based Engineering of Embedded Real-Time Systems, 2010. 4. K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, 45(3):621–645, 2006. 5. Sven Efftinge, Peter Friese, Arno Haase, Clemens Kadura, Bernd Kolb, Dieter Moroff, Karsten Thoms, and Markus Voelter. openarchitectureware user guide. Technical report, openArchitectureWare Community, 2007. 6. C. Hein, T. Ritter, and M. Wagner. Model-driven tool integration with modelbus. In Workshop Future Trends of Model-Driven Development, 2009. 7. Philipp Huber. The model transformation language jungle - an evaluation and extension of existing approaches. Master’s thesis, Technische Universit¨ at Wien, May 2008. 8. F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev. ATL: a model transformation tool. Science of Computer Programming, 72:31–39, June 2008. 9. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 10. Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture—Practice and Promise. Addison-Wesley, 2003. 11. Mathworks. Introducing matlab 7 and simulink 6. Signal Processing Magazine, IEEE, 21(5):122, September 2004. 12. Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci, 152:125–142, 2006. 13. Yiannis Papadopoulos and John A. McDermid. Hierarchically performed hazard origin and propagation studies. In Massimo Felici, Karama Kanoun, and Alberto Pasquini, editors, SAFECOMP, volume 1698 of Lecture Notes in Computer Science, pages 139–152. Springer, 1999. 14. Carl-Johan Sj¨ ostedt, Jianlin Shi, Martin T¨ orngren, David Servat, DeJiu Chen, Viktor Ahlsten, and Henrik L¨ onn. Mapping simulink to uml in the design of embedded systems: Investigating scenarios and structural and behavioral mapping. In OMER 4 Post Workshop Proceedings, April 2008. 15. Anthony I. Wasserman. Tool integration in software engineering environments. In Fred Long, editor, Software Engineering Environments, International Workshop on Environments Proceedings, Lecture Notes in Computer Science, pages 137–149. Springer-Verlag, September 1989.
Appendix D
Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions Matthias Biehl, “Literature Study on Design Rationale and Design Decision Documentation for Architecture Descriptions,” Technical Report, ISSN 1400-1179, ISRN/KTH/MMK/R10/06-SE, Royal Institute of Technology, Stockholm, Sweden, July 2010.
Abstract In this document we provide an overview of the state of the art in documentation of design rationale and design decisions for architecture descriptions. We define the terminology of the area and compare the concept of rationale to similar concepts. We provide an overview of areas of contemporary research in design rationale. For each of the identified areas, we describe both the challenge and proposed solutions. Based on the findings from the literature we present evaluations of rationale and design decision documentation. The findings from this survey are promising and many open research questions with respect to rationale and design decision documentation need to be addressed. In the literature reviewed in this document it is for example not addressed how design decisions and design rationale should be represented, captured and used in model-based and model-driven development approaches. A need for further research in this area exists.
3
Contents 1 Introduction 1.1 Other surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Overview over this Document . . . . . . . . . . . . . . . . . . . .
6 6 6
2 Terminology 2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Architectural Views . . . . . . . . . . . . . . . 2.1.2 Architectural Patterns . . . . . . . . . . . . . . 2.1.3 Architectural Knowledge . . . . . . . . . . . . . 2.1.4 Classification of Architectural Knowledge . . . 2.2 Design Rationale . . . . . . . . . . . . . . . . . . . . . 2.2.1 Metamodel for Rationale . . . . . . . . . . . . 2.2.2 Characterization Scheme for Design Rationale . 2.3 Design Decision . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
7 7 7 7 8 8 9 9 10 11
3 Comparison of Rationale with Similar Concepts 3.1 Versions . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Variability and Variants . . . . . . . . . . . . . . . 3.3 Safety Case . . . . . . . . . . . . . . . . . . . . . . 3.4 Traces . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
12 12 12 13 13
. . . .
. . . .
4 Overview of Research on Rationale 13 4.1 Research Communities . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Classification of Research on Design Rationale . . . . . . . . . . 15 5 Identifying and Representing Rationale 16 5.1 Metamodels for Rationale . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Ordering Rationale Elements . . . . . . . . . . . . . . . . . . . . 18 6 Capturing Rationale 19 6.1 Point of Time for Capturing . . . . . . . . . . . . . . . . . . . . . 19 6.2 The Capture Problem . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3 Reducing the Capture Problem . . . . . . . . . . . . . . . . . . . 20 7 Tools for Rationale Management 8 Using Rationale 8.1 Memory Aid and Communication Support . . . . . . . . . . 8.2 Traceability and Consistency Checking . . . . . . . . . . . . 8.3 Design Space Analysis, Exploration and Trade-off Analysis 8.4 Change Management and Change Impact Analysis . . . . . 8.5 Evolution and Maintenance . . . . . . . . . . . . . . . . . . 8.6 Teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20 . . . . . . .
. . . . . . .
. . . . . . .
21 21 22 22 22 23 23 23
9 Benefits and Inhibitors 24 9.1 Benefits of Using Rationale . . . . . . . . . . . . . . . . . . . . . 24 9.2 Inhibitors for Using Rationale . . . . . . . . . . . . . . . . . . . . 25
4
10 Conclusion
26
References
27
5
1
Introduction
“When car developers at Ford Motor Company wanted to learn why the original Taurus design team was so successful, no one could tell them. No one remembered or had recorded what made that effort so special; the knowledge gained in the Taurus project was lost forever. The most valuable asset in any company is probably also its most elusive and difficult to manage: knowledge.” [31] The knowledge gained throughout a design process is a valuable asset and is important during the design itself, during the subsequent evolution and maintenance phase and for similar, new products. It is good practice to manage the knowledge of all kinds of engineered products, including the knowledge of intangible products, such as software. The knowledge can be classified into knowledge about the product (the “what”) and knowledge about its justification, rationale and decision (the “why”). The “what” is usually documented in the form of models and source code. The “why” is usually not documented or represented explicitly, it is tacit and shared between individuals. Individuals might forget this knowledge or leave the organization and take the knowledge with them. This phenomenon of disappearing architectural knowledge is called architectural knowledge vaporization [12]. Typical problems resulting from architectural knowledge vaporization are unawareness of previous design decisions and a lack of understanding of the artifacts such as the architecture descriptions, models and source code [36]. In this document we describe approaches for documenting the “why” in the form of design rationale, design decisions and architectural knowledge.
1.1
Other surveys
Early work on design rationale is summarized in [95, 82, 108]. The use of rationale in different software engineering activities is surveyed by Burge et al. [16] and by Dutoit et al. [38]. Barbar et al. [4] provide a survey focusing on the use of knowledge management for software architecture. Kruchten et al. [77] provide a survey with a historical perspective on architectural descriptions and design decisions.
1.2
Overview over this Document
The rest of this document is structured as follows. Section 2 introduces the terminology used in this document. In section 3 we compare the concept of rationale to similar concepts for modeling and managing metadata. In section 4 we give a brief overview of the different research communities involved and categorize contemporary research issues. The different research issues are presented in a section of their own: representing rationale in section 5, capturing rationale in section 6, managing rationale in section 7 and an overview of how rationale information can be used in section 8. In section 9 we present how the use of design rationale is evaluated in the literature. We summarize our findings in section 10.
6
2
Terminology
In this chapter the terminology is introduced, taking into account the terms related to rationale.
2.1
Architecture
The architecture of a software-intensive system is defined as “the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution” [65]. The architecture is a means for communication, analysis and synthesis. The terminology and best practices regarding software and systems architecture are specified in the two standards for architectural description of software-intensive systems (IEEE/ANSI 1471-2000) [65] and ISO/IEC 42010:2007 [66]. 2.1.1
Architectural Views
An architectural view is a representation of the system from the perspective of a related set of concerns [26, 65]. The goal of views is to reduce the perceived complexity for a specific stakeholder. An architectural view provides a coherent selection, projection, abstraction or simplification of the architecture according to the interests of a specific stakeholder. A selection of several views and concerns forms an architecture framework. In [10] a set of default viewpoints is proposed, such as a module viewpoint, a component&connector viewpoint and an allocation viewpoint. A set of predefined views is proposed by Kruchten as the 4+1 model [74]. The 4+1 model comprises a logical view describing the functionality of the end-user, an implementation view for programmers, a process view for system integrators focusing on quality attributes, a deployment view for delivery and a use-case view connecting all of them. A viewpoint establishes the purpose for a view and the techniques or methods used for constructing the view [110, 65]. The viewpoint also specifies the conventions for interpreting, constructing and using an architectural view. 2.1.2
Architectural Patterns
Patterns offer reusable knowledge for recurring problems that is verified and proven through multiple uses in practice. Architectural patterns are also called architectural styles. Examples of patterns are the pipes and filters pattern and the model view controller pattern [50]. Pattern languages and pattern catalogs document common patterns that provide means for systematic reuse. In order to reuse architectural knowledge it is desirable to store, categorize and catalog it. Once this catalog is built and mined from the experience of several architects, it can be taught to novice architects. Architects can use the patterns from the catalog as verified building blocks. General pattern catalog are design patterns for object oriented programming [50] and the series of pattern-oriented software architecture by Buschmann et al. [19, 112, 92, 17, 18].
7
2.1.3
Architectural Knowledge
The development of an architecture is knowledge-intensive work, as it requires a deep technical understanding of several specific domains, human processes and how the product is used. Architecture knowledge (AK) comprises the knowledge that is essential to the construction of the architecture. The boundaries of architectural knowledge are not clearly defined. Several proposals have been made: • AK = design decisions and design [78, 68] • AK = drivers, decisions, analysis [56] • AK = process, products, people, tools [32] In this document we use the first definition of architectural knowledge as design decisions and design. In addition we provide a scheme for the characterization of architectural knowledge. 2.1.4
Classification of Architectural Knowledge
Architectural knowledge can be classified by four criteria [68, 46]. The criteria are the generality of the knowledge, the degree of formalization, the roles of the involved actors and the knowledge management strategy. • Generality of Architectural Knowledge: Architectural knowledge can be specific to an application or it can be generic. Generic architectural knowledge can be applied in several applications [80]. Application-specific knowledge is also called episodic knowledge, application-generic knowledge is also called library knowledge [109]. An example of application-generic knowledge are design patterns (see section 2.1.2). • Architectural Knowledge Type: Knowledge can be formalized to different degrees from implicit on the one end of the spectrum to explicit on the other end [46]. An example for implicit knowledge is the experience of the architect. Explicit knowledge on the other hand is written down and codified and thus independent of the person originally holding that knowledge. Explicit knowledge can be further divided into textual and formal knowledge. • Architectural Knowledge Management Roles: The people interacting with architectural knowledge can take different roles, such as the role of a producer or the role of a consumer of architectural knowledge [46]. The producer captures and shares AK, the consumer assesses AK, learns from it and reuses it. • Architectural Knowledge Management Strategies: To manage architectural knowledge, different strategies can be employed, such as personalization, codification, or a mix of the two [59]. There is a relation between the architectural knowledge management strategy and the preferred architectural knowledge type [68]: Using the personalization strategy, knowledge is shared from person to person through socialization. The focus is on knowing “who knows what”. This strategy depends largely on
8
implicit knowledge, which can be shared effectively through personal interaction with the right person. The codification strategy on the other hand relies on sharing explicit knowledge. Once the knowledge is codified, it can be communicated and shared independently of the persons involved. A hybrid knowledge management strategy shares defined parts of architectural knowledge through the codification strategy, other parts through the personalization strategy.
2.2
Design Rationale
The dictionary defines the term rationale as the fundamental reason or the underlying principle. In engineering the design rationale captures the reasoning underlying the creation and use of artifacts [16], it subsumes the design decision, alternatives and the design decision rationale. Tang et al. [128] characterize design rationale as the reasons for making a decision and choosing a solution and explaining the relationships between the solution and the context of the solution. The design decision rationale is the reasoning attached to a particular design decision and captures the justification for a particular design decision. The term rationale is linked to the architecture of a system. According to IEEE 1471 [65] an architectural description needs to provide the rationale for the choice of architectural concepts, including the alternative concepts that have been considered. While architecture is concerned with the finished artifact (the “what”), rationale is the description/documentation of the relevant decisions that lead to the architecture (the “why”). 2.2.1
Metamodel for Rationale
Using the wide definition of design rationale, a rationale description contains the information relevant for making design decisions [82]. Rationale usually comprises the following elements: • Issue: the design issue to be solved • Alternatives: possible solutions to the issue • Decision: the selected alternative to resolve the issue • Affected Artifact: the manifestation of the decision in the architecture • Design Decision Rationale: providing justification, reasoning and arguments for the design decision and its alternatives • Architecturally Significant Requirement: a requirement that influence the alternatives and issues, can serve as an argument In addition to the above elements, rationale can also comprise architectural constraints and architectural rules, which constitute previous architectural decisions that limit the solution space of the following design decisions. Rationale also provides traceability to the requirements and architectural elements, which can range from a simple pointer to a requirement to a complex trade-off analysis. An important part of the rationale are the links between related design decisions, between design decisions and requirements, and the links between design decisions and architectural elements [76]. Another addition to the metamodel 9
for rationale is a documentation of the assumptions under which a design decision is made [136, 81]. Further discussions on the metamodel and an overview of metamodels reported in the literature can be found in section 5. 2.2.2
Characterization Scheme for Design Rationale
We have identified a scheme for characterizing design rationale and its relation to design decisions and architectural models. This characterization is independent of the representation of design rationale. Depth of Justification: Justification provides reasons for the nature of an artifact and gives an answer to the question “Why is a certain artifact the way it is?”. This question can be asked recursively, so the number of recursions defines the depth of the justification. We define rationale levels (R0, R1, R2, R3) to capture the depth of justification. In this context an artifact can be a model, a system, subsystem, an architecture or a model element. • R0 - Artifact Level: On the lowest level, there is no (= zero) rationale, but just the artifact that the rationale is attached to. The artifact is the foundation for the other levels to relate to. The artifact describes the “what”. • R1 - Decision Level: The information on R1 level provides an answer to the question, why the artifact is the way it is. R1 answers this question by listing the design decisions and possible alternatives. R1 information justifies R0 information by providing the decisions that resulted in the creation of the artifacts. • R2 - Decision Rationale Level: Decision rationale provides an answer to the question, why the decision was made. Decision rationale justifies the decision (R1) by providing reasons for the decision. Decision rationale can be of quantitative or qualitative nature. Quantitative rationale is e.g. the result of one or more quality analyses. Qualitative rationale is made up of arguments. • R3 - Rationale Rationale Level: Rationale rationale provides a justification for the quality analysis, quality models, metrics and trade-off analysis that have been selected as criteria for making a decision. The levels R0-R3 for the depth of justification have been inspired by the metamodeling levels M0-M3 by the OMG [101]. Subject of Justification: The subject of the justification defines what the rationale justifies. • Existence: Rationale may justify the existence of a certain architectural element. • Non-existence: Rationale may justify the non-existence of a certain architectural element. • Property: Rationale may justify an attribute or property of the architectural model or the system, such as modularity or performance.
10
Type of Justification: There are different types of reasons that can be conveyed by design rationale. • Technical: Rationale may provide reasons that are rooted in the product, its requirements or the development process. • Executive: Rationale may provide non-technical reasons, for example finances, management, politics or culture. Granularity of the Affected Artifact: Rationale information can be attached to model artifacts of different granularity. • Architecture/Model: Coarse grained rationale provides justification for the model as a whole. • Model Element: Fine grained rationale provides justification for a set of model elements that are part of a model.
2.3
Design Decision
Design decisions are decisions that directly influence the design of a system. When a software artifact is created, design decisions need to be made. Ideally decisions are made by the process of deliberation, pertaining a careful weighing of the alternatives. An architecture is the result of many design decisions, some of which have a larger impact than others. Decisions can be narrow in their scope or far reaching and affecting the complete system. Far reaching decisions have an impact on the architecture and are called architectural design decisions [68]. It is difficult to determine a priori which of the many design decisions are most important. Often it is only possible to find out about the importance of specific design decisions in retrospect, when trying to change an existing architecture [49]. Kruchten proposes an ontology of architectural design decisions [75]. The components of a design decision are introduced as: • Design Decision is a textual description of the decision. • Design Decision Rationale provides a justification for the decision. • Scope or Context of the design decision can be either local (affecting only a specific part of the model), or crosscutting (affecting several parts of the model). Design decisions are made in a specific context and their validity and relevance depends on this context. Thus modeling a design decision entails modeling a context as well. Further there is information for managing the decision such as state (e.g. preliminary or decided), cost associated with it, risk it deals with, category, author and timestamp. Design decisions do not exist by themselves, but depend on previous decisions and affect later decisions. Thus there are relationships between design decisions such as constrains, forbids, enables, subsumes (a wider specified design decision subsumes a tighter design decision), conflicts with, overrides, comprises, bound to, is an alternative to, is related to and dependencies. The traditional view of architecture as components and connectors does not provide a notation for decisions. As a consequence of not recording the design decisions the information of design decisions is lost. In his position paper Bosch 11
proposes to describe the architecture using an explicit record of design decisions [67, 12]. The motivation is that explicit records of design decisions will reduce the effort necessary for changing the architecture and reduce design erosion. According to Bosch an architectural design decision consists of a restructuring effect (add components, split components, merge components, remove components, restructure components, add requirements, impose functionality), design rules (defines a particular way of performing a task), design constraints (defines what the system may not do) and a design decision rationale [12].
3
Comparison of Rationale with Similar Concepts
In this section we compare the rationale concept to similar concepts for managing and modeling metadata. With this study we can find out if similar concepts already provide what rationale can offer, or if a separate concept for rationale is justified.
3.1
Versions
Version management captures the evolution of an artifact over time and in distributed settings [7]. It allows retrieving earlier versions and developing alternative versions in parallel, known as branching. Examples of SCM systems are the Concurrent Versioning System (CVS) [133] and Subversion (SVN) [106]. In addition, version management systems specifically for models exist [3]. Version management is a state-based approach, which is focused on describing different versions as new states of an artifact instead of explicitly documenting the decision or change operations applied on the model [62]. The focus of rationale management is keeping track of the changes and the reasons for the changes (the “why”), whereas version management keeps track of the changed artifacts (the “what”).
3.2
Variability and Variants
Variability is the ability of a software system to be efficiently extended, changed, customized or configured in a particular context. Decisions about binding time are managed by variability management and configuration management which describe the commonalities and variabilities of products. Software product lines or product families exploit the commonalities and variabilities of products by modeling an architecture with optional, alternative and reusable parts [27, 99]. Alternatives are called variants in variability modeling. To derive a product, a selection between the variants have to be made. Both rationale and variability capture alternative options and the selection that has been made between them. Sinnema et al. [122] use variability modeling to capture rationale. The approach is based on the observation that the alternatives and choices of rationale management are similar to variants and variation points of variability management. Thurimella et al. [129] identify similarities between rationale management and variability management and unify it to their approach on issue-based variability modeling. The provide a mapping between concepts of rationale management and variability management, similar 12
to the approach by Sinnema et al. Variability focuses on what can be varied, but not on the reasons and justification for the variation. Variability usually describes alternatives that are intended to be realized. In variability management each allowed configuration represents a product. This means that every valid configuration is reasonable to build. On the other hand not every alternative design decision expressed by rationale concepts should be realized. There can be design decisions that are rejected and will not be built. Rationale is used for design space exploration, exploring different options and getting a feedback regarding the quality of the design alternatives.
3.3
Safety Case
Before safety critical systems can be delivered, authorities often require a certification. Certification is intended to show that the system is safe enough, e.g. by showing that the engineering was done according to current industry standards and practices. It might also be required to show the safety-related decisions and reasoning. The safety case concept [73] can be used to describe the reasoning. A safety case can be considered to be a specialized rationale focusing on safety. A safety case is similar to a design rationale, as it focuses on capturing the reasoning of a design. However, a safety case is created in retrospect, after the design is finished [130]. A safety case focuses on legal aspects, its purpose is satisfying authorities, and thus the description of design decisions needs to be simplified. The scope of rationale is wider, it does not just focus on safety, but on other technical aspects as well. The purpose of design rationale is supporting design and thus design rationale and design decisions are captured as they are actually made. The documentation of design decisions for safety critical systems has been investigated by Wu et al. [137] and by Leveson [86].
3.4
Traces
Traces provide the ability to determine the origin and relation between model elements [104]. Traces can be created manually, or automatically by model transformations. Traces link source elements to target elements and optionally the transformation rule that established the link. Traces can also be used to check the consistency of a solution and whether the solution is actually solving the problem [52]. The ability to trace the origin and relation between model elements is one aspect of design rationale. However, traces do not provide the possibility to express alternatives, decisions and their justification.
4
Overview of Research on Rationale
In this chapter we give a short overview of the work in rationale research. In section 4.1 we identify the different research communities working on rationale. In section 4.2 we group and organize the current research areas. Sections 5 – 8 are organized according to this classification and introduce the respective areas in detail.
13
4.1
Research Communities
Several communities work on the topic of design rationale, spanning software engineering, mechanical engineering, economics, philosophy and psychology. These communities use different terminologies, have a different perspective, focus on different aspects of the problem and propose their own set of solutions. • Rationale Management: The goals of rationale management are the refinement and the externalization of architectural knowledge [95, 82]. The approaches differ in the way they define, structure and elicit the rationale information. • Knowledge Management: The tools and mechanisms of general knowledge management can be applied to support software engineering and software architecture [4]. Knowledge management is defined as the process that deals with systematically eliciting, structuring and facilitating the efficient retrieval and effective use of knowledge [41]. The goal of architectural knowledge management is to improve the business processes and practices by utilizing individual and organizational business resources, including skills, capabilities, experiences, routines, cultural norms and technologies. It involves tacit knowledge of experts and explicit knowledge, codified in procedures, processes and tools. Three basic approaches for knowledge management exist: (1) codification, which aims at making all knowledge explicit, (2) personalization, which aims at promoting “who knows what” and (3) the hybrid approach, which realizes that different types of knowledge can be better represented using codification or personalization. • Architecture Description: Design rationale is an important part of an architecture description [65]. The architecture community is interested in describing rationale and design decisions and linking them to existing architectural concepts such as ADLs, views, patterns, frameworks, architecture quality analysis and trade-off analysis. • Pattern Languages: The goals of the pattern community are the categorization of architectural knowledge into pattern languages and catalogs and the utilization of the patterns (cf. section 2.1.2). Rationale is used to provide reasoning and guidance for the selection between similar patterns [60]. • Software Evolution and Maintenance: Most problems of maintenance and evolution arise from the difficulties of understanding existing systems that were created by other people [42, 64, 40, 141]. Rationale is used to improve the understanding of the architecture, for example by change impact analysis. Rationale may thus improve the efficiency and accuracy of evolution and maintenance [21]. • Engineering Design: Engineering Design provides methods and tools to support the mechanical engineer. Design rationale is used as a tool for improving the understanding of the design and for the reuse of experience [1, 2].
14
• Cognition and Psychology: Design rationale is a means to enhance the understanding of artifacts. Thus design rationale is a support tool for the humans working with the artifacts. This is why psychologists have examined how rationale supports cognitive processes in design and understanding. The psychological aspects of design rationale have been studied by Shum [118]. • Philosophy: The field of rationale argumentation has been studied in philosophy, which provides the concepts used for representing rationale information [131]. • Economics: Decision-making has been studied extensively in the field of economic sciences. Simon [121] studied the behavioral and cognitive processes of making rational human choices. Simon identified three steps of decision making: (1) the identification and listing of all the alternatives; (2) the determination of all the consequences resulting from each of the alternatives; and (3) the comparison of the accuracy and efficiency of each of these sets of consequences. He primarily considers decision making under uncertainty, since in practice it is impossible to have perfect and complete information at any given time to make a decision.
4.2
Classification of Research on Design Rationale
In order to present an overview of the research done on rationale in a structured way, we propose a classification scheme that is based on the different tasks involved when working with design rationale. The architectural knowledge management community has identified the tasks: (1) architectural knowledge identification, (2) architectural knowledge acquisition, (3) architectural knowledge development, (4) architectural knowledge distribution, (5) architectural knowledge preservation and (6) architectural knowledge use. The rationale management community has identified similar tasks: (a) elicitation of rationale, (b) recording of rationale, (c) structuring and indexing of rationale, (d) retrieval of rationale, (e) delivery of rationale, (f) use of rationale. We group the tasks identified by the architectural knowledge management community and the rationale management community and get four areas of research in rationale: • Identifying and Representing Rationale is the topic of chapter 5 In order to represent and structure rationale documentation, the aspects of architectural knowledge worth documenting need to be identified. (Tasks 1, c). • Capturing Rationale is the topic of chapter 6 Capturing of rationale subsumes the tasks elicitation, acquisition and recording of rationale (Tasks 2, a, b). • Managing Rationale is the topic of chapter 7 Rationale management uses methods and tools for developing, preserving, distributing, delivering and retrieving of rationale (Tasks 3, 4, 5, d, e).
15
• Using Rationale is the topic of chapter 8 Rationale can be used to support a variety of engineering activities (Tasks 6, f). The areas of research are discussed in the following sections.
5
Identifying and Representing Rationale
When design rationale and design decisions are documented, it needs to be identified which aspects of architectural knowledge are important and how they should be represented.
5.1
Metamodels for Rationale
Design decisions are usually not represented explicitly, even though a number of different approaches for representing design decisions exist. These different representations have varying degrees of formality and rigor. Informal representations document design decisions in the form of free text, use cases and videos [23]. Programming languages employ comments to explain the intention of several lines of code. UML [103] and SysML [102] also provide a notation for comments, depicted by a box and a dashed line. However, the comments are merely graphical elements and not connected to the identity of a model element. Template-based approaches provide a guideline for textual descriptions of design decisions such as the template by Tyree and Akermann [132]. The majority of approaches represent design decisions that are modeled according to a metamodel. These approaches explicitly represent the design deliberation process, including alternatives and arguments, the earliest being IBIS. Approaches for representing design decisions that were developed in recent years focus on linking design decisions with the architecture [77]. Some approaches propose a separate view for design decisions [37], others present the architecture and its design decisions in the same environment, as for example the AREL approach. AREL is a UML profile that can be used to annotate architectural models with design decisions and rationale [124]. The SEURAT approach links rationale to specific lines in the source code [15]. These models provide descriptions, traces and links to the artifacts affected by rationale. Many different metamodels for rationale and design decisions exist and in the following we present some of them. • IBIS (Issue-Based Information Systems) [79] is the first metamodel for rationale support and most rationale tools are based on this approach. It models rationale using the following concepts: – Issue: a question that needs to be resolved – Position: alternatives – Argument: support or counter of a position or other arguments • gIBIS [30] is a hypertext-based version of IBIS. • PHI (Procedural Hierarchy of Issues) [93] is based on IBIS and adds relationships between issues, resulting in a hierarchical structure of issues.
16
• Potts and Bruns [107] is the first system to integrate both artifacts and their rationale. It is based on IBIS with a slightly changed metamodel, where all arguments for a decision are merged into one justification element. • DRL (Decision Representation Language) [83] is based on the Potts and Burns model, arguments are called claims and are decomposed in a similar way as in IBIS. It uses the concepts of claims and arguments. DRL is mainly used for design space analysis, but is expressive enough to be applied in other contexts as well. • QOC (Questions Options and Criteria) [91] is focused on retrospective rationale documentation of the design space. Its metamodel contains the following concepts: – Question: a design issue that needs to be resolved – Option: corresponds to a decision or position – Criterion: a metric used for the evaluation of an option • Scenario-Claims Analysis (SCA) [24] represents system features, criteria and evaluation of the features against the criteria. It does not provide an explicit representation of the argumentation or of design decisions. • RATspeak [15, 14] is based on DRL. In addition to the concepts of DRL, the metamodel comprises requirements, assumptions and dependencies between alternatives. RATspeak defines an ontology for software engineering rationale that allows automated reasoning with the rationale information, for example for change impact analysis. • AREL (Architecture Rationale and Element Linkage) [124] focuses on representing the factors that influence the design decision and on linking rationale to the architecture. – – – – –
Design Concerns: model the context of the decision Environmental Factors: external constraints of the design Functional and Non-functional Requirements: motivate the design Purposes and Goals: provide a context to guide the design Design Options: comprise both the chosen design and alternative design
• Archium [70] is capable of describing both an architecture and the design decisions inherent in the architecture. It interprets design decisions as functions that change the architecture. It is based on ArchJava and assumes that the architecture is implemented in Java. • Intent Specifications [86, 87] by Leveson focus on the documentation of reasoning for safety critical software. The representation language attempts to balance formal and informal specification. The intent is documented according to several views: the management view, customer view, system engineering view, component designer view, component implementer view and operations view. Intent specifications have been used to document assumptions of software components to enable their safe reuse in spacecrafts [136] and mobile robots [98]. 17
• The Template by Tyree and Akermann [132] is the basis for many metamodels for rationale. It has the major concepts decision, constraint, issue, solution and rationale. Minor elements are the category, status, dependency, associated artifact, consequence and the affected stakeholder. • Kruchten’s Ontology of architectural design decisions [75] includes four major classes of design decisions: existence decisions, non-existence decisions, property decisions and executive decisions. An existence decision states that an element exists in the architecture, whereas a non-existence decision states that a particular element is not in the architecture on purpose. Property decisions target a specific attribute or property of the system, thus they are cross-cutting and affect multiple elements. Executive decisions are motivated by finances, methodology, politics, culture, or the people. The components of a design decision are introduced as the decision itself, the rationale, the scope of the decision, the cost associated with it and the risk it deals with. Further there is information for managing the decision such as state (e.g. preliminary or decided), category, author and timestamp. Design decisions do not exist by themselves, but depend on previous decisions and affect later decisions. Thus there are relationships between design decisions such as constrains, forbids, enables, subsumes (a wider specified design decision subsumes a tighter design decision), conflicts with, overrides, comprises, bound to, is an alternative to, is related to and dependencies. • SOAD [144, 143] aims to build a library of domain specific design patterns and their rationale for the domain of service oriented architectures. Based on this library a tool can create a todo-list to guide engineers in the selection of design patterns from the library. • Design Constraints [127] are used to describe how design decisions are formed based on external constraints. • DPRG (Design Pattern Rationale Graph) [9] uses graphs to link design rationale with a model of the source code. • ATRIUM [97] metamodel describes rationale by a text attribute for design decision and design rationale that is defined for each metaclass. They describe a model-driven development approach creates trace links between different model elements. The survey [115] reviews a number of metamodels for capturing design decisions. They find that most metamodels have a consensus on the major modeling concepts and there are small divergences on the minor modeling concepts. They provide a table listing similar modeling elements of different tools, by mapping them to the template by Tyree and Akermann. A similar approach is taken by Liang et al. [89] to map rationale captured using different metamodels.
5.2
Ordering Rationale Elements
The rationale of an architecture consists of several rationale elements. In this section we investigate how several rationale elements are structured and ordered. In the literature two criteria for ordering rationale information are discussed. 18
• Chronological approaches order rationale according to a timeline. Rationale thus represent the history of the architecture. • Structure-oriented approaches order rationale according to the architectural model. Rationale information is linked to the artifact being designed. The main advantage of this ordering principle is the traceability between rationale and architecture or between rationale and source code [15, 113]. To be able to manage the complexity of this information, a specific architectural view for design decisions is proposed, the “decision view” [37].
6
Capturing Rationale
To be able to use rationale information, the rationale has to be first externalized and captured. In this section we show at which point in time rationale can be captured. We discuss the problems encountered when capturing design rationale as well as approaches aiming to reduce these problems.
6.1
Point of Time for Capturing
Design rationale can be captured before the architecture is built or after the architecture has been built [20]. • Rationale captured after the architecture has been built is called retrospective design rationale [118]. The goal of retrospective rationale is supporting the maintainer during the evolution of the system. Rationale has an explanatory role, and does not need be historically complete. Information that is not relevant in retrospect can be simplified or left out. • Rationale that is captured before the architecture is designed is called prospective design rationale. Its goal is to support problem formulation, design space analysis and decision making. Rationale focuses on ongoing issues, positions and arguments. Most of the powerful approaches found in the literature employ a prospective design rationale. In this document we will assume a prospective design rationale, unless otherwise noted.
6.2
The Capture Problem
The different hindrances for capturing rationale are summarized as the capture problem. The main reason for not capturing rationale is the overhead it entails. Further reasons are the disruption of creativity caused by documentation and the loss of individual power. Tang et al. [123] studied empirically how software professionals document and use design rationale. He found that software professionals recognize the importance of design rationale for their work, however, they often omit to provide the “why” in the form of rationale and justification and focus only on the “what” in the form of architecture, models and source code. In case studies it was found that designers usually do not want to capture rationale and there are only a few individuals in a large team that capture the rationale [29]. Rationale capture is time consuming and perceived as an overhead. It is also argued 19
that rationale capture is intrusive to the design activity [48], thus hindering and blocking creativity and flow, especially if it is captured in a formal way. In addition, there is a conflict of interests, since the individuals capturing the rationale are not the beneficiary [54]. The individuals capturing the rationale will not profit from codifying their knowledge. On the contrary, employers make themselves exchangeable by capturing rationale, since codified knowledge reduces the companies dependence on the individual designer.
6.3
Reducing the Capture Problem
The overall goal of current work in rationale capture is the reduction of the amount of work required for capturing design decisions. In the following we present some of these approaches. • Goal-oriented approaches limit the amount of information that needs to be captured by design decisions and to capture only the design decisions that are most important for reaching a certain goal. However, it is difficult to know beforehand, which information will be important later [43]. • Methodological approaches devise a method for reducing the amount of captured design decisions. One such method is the ’flag, filter and form’ method [85]. Each design decision is flagged by setting a marker to remember the location of the design decision, then design decisions are filtered, to find the ones that are worth documenting. Lastly the selected design decisions are documented and more descriptive details are added to them. • Indirect capturing of design rationale as a by-product has been explored. Data mining algorithms have been used to to capture rationale from email traffic among designers [72]. • Pattern-based approaches promise the reuse of generic rationale parts from a rationale library [57, 94]. • Generative approaches separate capturing from formalization [53]. Rationale is captured in a raw format and later formalized when needed [116]. It has also been proposed to automate the collection of decisions and rationale [96] to solve the capture problem. For example, the algorithm of latent semantic analysis is used [33] to extract knowledge from existing documents, e.g. word documents. Other generative approaches use incremental formalization [117] or differential description [48] of rationale to minimize the impact of the capture problem.
7
Tools for Rationale Management
In this section we introduce tools that support the management of design rationale. Rationale management tools provide design support, maintenance support, learning support and documentation support. • ADDSS (Architecture Design Decision Support System) [22] is a webbased tool for capturing design decisions. It focuses on capturing and visualizing the evolution of the architecture, thus supporting iterative development. It also supports capturing and reusing architectural patterns. 20
• Archium [70] is a tool for representing both the architecture and the architectural design decisions. The tool makes it easy to see the relation between the design decisions and their effect on the architecture. • AREL (Architecture Rationale and Element Linkage) [124] focuses on connecting design concerns in the problem space to design outcomes in the solution space using design decisions as connection points. AREL is implemented as UML profile. • Knowledge Architect is a repository for architectural knowledge [90]. The repository can be accessed using different clients such as Word and Excel and has facilities to translate the architectural knowledge. It is based on semantic web technology. • SEURAT (Software Engineering using RATionale system) [15] is an Eclipse plug-in for documenting design decisions, alternatives, reasons, arguments and for tracing requirements to code. The tool supports the maintenance process of software. • EAGLE (Environment for Architects to Gain and Leverage Expertise) [47] supports both codified and personalized knowledge and can be tailored to the needs of different stakeholders using notifications and search mechanisms. • PAKME (Process-based Architecture Knowledge Management Environment) [6] is a web-based tool that supports both codified and personalized knowledge. • SIBYL [84] has a special focus on managing group design rationale, where several architects can contribute to the knowledge of the group. • ADkwik [114] is a wiki platform with an underlying data model for rationale. • SEI-ADWiki [8] is a wiki platform with a focus on communication and collaboration of rationale. It allows free text comments without a specific metamodel. Lian et al. have conducted a study to compare some existing tools for rationale management [88] based on the use-cases that the tools support.
8
Using Rationale
In this chapter we explore how rationale can support the different activities throughout the life cycle. Additional information on the usage of rationale with respect to the different phases of software engineering is provided by Burge et al. [16].
8.1
Memory Aid and Communication Support
Rationale provides information both to the rationale author and to other stakeholders. 21
• Rationale can be used as a memory aid for the rationale author, to remember what was decided and why. • Rationale is also a means for communicating architectural knowledge to other stakeholders such as team members, other teams, clients or maintainers. Rationale has e.g. been used to capture discussions in meetings [29]. In global software development virtual teams develop software without the possibility for face-to-face meetings. They need to efficiently exchange externalized architectural knowledge. Documentation of design decisions and design rationale has been found useful in global software development [135, 28, 61].
8.2
Traceability and Consistency Checking
Traces can be used to check the consistency of a solution. We can for example check, whether the recorded rationale is consistent with the decision taken. The AREL [124] approach allows consistency checking between rationale and architecture elements. Several approaches have explored using rationale information as the link between requirements and architecture, linking problem space and solution space [34, 46, 58, 55].
8.3
Design Space Analysis, Exploration and Trade-off Analysis
The activity of decision making comprises generating alternatives, evaluating them and selecting the best alternative, as it is recommended by the Capability Maturity Model Integration (CMMI) [25]. Which alternative is the best is measured by the criteria used. The criteria can be constraints, assumptions, risks, functional requirements and non-functional requirements. If design decisions and their alternatives are documented, the alternatives can be evaluated. The evaluation can be automated to varying degrees [134, 111], from evaluation, to design space exploration and design optimization. While the alternatives (R1 level) are the input to the evaluation, the design decision rationale (R2 level) records the justification of the evaluation and trade-off decision [69, 5]. In this sense, design rationale is both a source of information used for analysis and a way to store analysis results.
8.4
Change Management and Change Impact Analysis
Changes to an architecture can be made at different times in the life cycle. Before the change is performed, it needs to be understood how a proposed change will impact the system. The impact of the change can be predicted by change analysis techniques [16]. Tang et al. [125] use design rationale as the basis for their automated tool support using Bayesian belief networks for change impact analysis. Bratthall et al. [13] examine in a controlled experiment if design rationale improves the correctness and the efficiency of change impact analysis. The participants were split in two groups, a study group that received a design rationale with the change requests and a control group that received the same change requests, but without design rationale. The results showed that
22
both efficiency and correctness of the change impact analysis were significantly improved when design rationale is available.
8.5
Evolution and Maintenance
Maintenance accounts for 67 - 90 percent of the total cost of the software system [42, 64, 40, 141]. Maintainers spend most of their time understanding the existing system before they are able to change it. Design rationale documentation has the potential to improve the maintainer’s understanding of the system [21]. However, the documentation of design rationale is often kept separate from the architecture. Thus the architecture often evolves and the documentation is not updated appropriately. As a result, separate documentation is often an unreliable source of information [135]. Rationale description coupled to the architectural description can help to keep the architecture and its rationale synchronized and improve the trustworthiness of the documentation. Karsenty [71] shows empirically that the time needed for maintenance tasks can be reduced considerably if design rationale and design decisions are documented.
8.6
Teaching
Rationale can provide a framework for articulating and teaching architectural knowledge [128], as it provides insight into how others have solved problems in similar situations [16]. We can differentiate between teaching applicationspecific knowledge and application-generic knowledge (cf. section 2.1.4). • Application-generic knowledge, is independent of a particular application and can be taught to students, so they can reuse the knowledge in other applications. • Application-specific knowledge is mainly to be shared among the team members working on the same project [1].
8.7
Reuse
Reuse promises that software systems can be built from tested and verified components, resulting in fewer defects and higher quality in less time. Reusable components make assumptions about the context they are used in. If a component is reused in a new context, it needs to be checked if the assumptions of the component can be met by the new context. The assumptions about the context can be stated as the design rationale. Weiss et al. [87, 136] use Intent Specifications [86] for documenting assumptions of spacecraft components. The explicit documentation of assumptions enables the safe reuse of the components. Habli and Kelly [56] experiment with an approach, in which design decisions are captured in one project and subsequently replayed in another project. Design decisions are made in a context, so the context needs to be captured in the form of assumptions and justifications, design dependencies and rationale for selection among alternatives. When replaying the design decisions in another project, the applicability of the design decision needs to be checked for the new context. Mismatches need to be detected and the design might need 23
to be adapted. Due to the possibility of such an approach to violate the design assumptions and dependencies, they conclude that reusing an architecture without rationale or reasoning is very risky. Design patterns are generalized solutions and thus incorporate several design decisions. Patterns are independent of a particular context, they capture generic architectural knowledge. Patterns provide application-generic, explicit architectural knowledge and are technology independent. Design decisions on the other hand are specific to a particular context and application. Patterns need to be adapted to the context, when they are applied in a specific architecture. Harrison et al. [60] propose to use patterns to capture architectural design decisions and work out in detail the difference between architectural patterns and design decisions. Zdun works on the relationship between patterns and design decisions [60, 105]. He describes how design decisions can be derived from general pattern specification. He proposes a pattern-based architecture approach based on patterns and design decisions [140, 139]. Zimmermann et al. [144, 142] describe the concept of reusable design decisions. They combine ideas from design patterns with design decisions and build a domain specific catalog of design decisions for SOA systems.
9
Benefits and Inhibitors
In this section we present, how the documentation of design decisions and design rationale is evaluated in the literature. In section 9.1 some of the benefits of using design rationale and in section 9.2 some of the inhibitors for using rationale are presented.
9.1
Benefits of Using Rationale
Falessi et al. [44, 45] investigate empirically, when rationale is deemed useful by developers. They designed a controlled experiment to test the perceived value of design decisions for performing different software engineering activities. One of their findings is that there are big differences in perceived value, depending on which element the rationale is associated to. To strengthen their results, they first performed this experiment at a university in Spain and later replicated that experiment in Rome with similar results. Empirical studies by Bratthall et al. [13]and Karsenty [71] showed that both change impact analysis and maintenance tasks can be improved if design rationale and design decisions are documented. Shum [118, 119] has studied the people-related, psychological and cognitive effects of rationale documentation. Rationale can improve different aspects of communication: • Rationale can support an individual engineer or a team of engineers • Rationale can be a means to systematically explore the design space, analyze alternatives and trade-offs. • Rationale can be the basis for a focused discussion on the design decisions, including their advantages, disadvantages and interrelations. Rationale is intended to support communication, reflection and analysis in design [63].
24
• During maintenance activities the existing system needs to be understood before it is changed. Rationale can reduce the time to change the system [13]. • Rationale can foster learning from the design of others and creates possibilities to learn from successes and failures from the past [1]. Rationale can improve design reuse, design communication and design verification [138]. Records of explicitly represented architectural knowledge are a support for the engineer when maintaining and evolving systems [78]. If the designers needs to justify their design decisions, the quality increases, which has been shown independently in several controlled experiments [126, 13]. For a company, rationale can be seen as the corporate technical knowledge of this company [11, 35]. The technical knowledge is independent of individual persons [138]. This ’corporate knowledge’ is a strategic factor for any business [138]. Learning organizations [39] consciously manage their knowledge and treat it as a valuable asset. The effective application of knowledge management is claimed to be one of the important success factors of japanese companies [100].
9.2
Inhibitors for Using Rationale
Even though there are advantages of explicitly captured rationale, a number of inhibitors for the use of rationale exist. • Capture Problem: Capturing rationale is expensive and timeconsuming. Thus the documentation of rationale creates overhead for the decision maker [43, 120]. The benefits of rationale need to be worth the additional effort and overhead of capturing [63]. The capture problem and possible solutions are discussed in section 6.2. • Means - Ends Uncertainty: Rationale documents important knowledge, a part of which will be potentially very useful during later evolution of the system. However, it is unknown which part of the knowledge will be needed in the future, since it is unknown which issues will come up and will need to be resolved in the future [39]. • Trust Problem: A general problem of knowledge management systems is the amount of trust that people have in the system. There may be a lack of trust both on the side of the provider and on the side of the consumer of the knowledge [51]. • Power Issue: The codification of rationale can expose the lack of knowledge [51, 43]. Some developers do not like to capture their architectural knowledge because they want to avoid that potential weaknesses of their design are exposed [123, 63]. If employees keep the rationale knowledge to themselves, they can benefit from it individually [43], as colleagues depend on their specific knowledge [1]. Engineers might not be willing to give up this power they hold through their internal knowledge. • Beneficiary Problem: Capturing rationale is expensive and timeconsuming for the rationale provider, the person capturing the rationale. However, the rationale provider does not benefit from captured rationale, as he already internalized this knowledge. Instead, other individuals are the beneficiaries. 25
10
Conclusion
In this document we provided an overview of the state of the art in the area of design rationale and design decision documentation. We defined the terminology and provided a classification scheme for design rationale. We compared the rationale concept to several similar concepts for modeling and managing meta data. The concept of rationale shares several aspects with a number of similar concepts, however these concepts provide a different scope, coverage or focus, so a separate concept for design rationale seems justified. Research in rationale is multidisciplinary and contributions are made in different research communities. We provided an overview of the research communities and classified areas of contemporary research. For each of the identified areas, we gave an overview of problem descriptions and proposed solutions with references to publications. From the literature we collected both the benefits and inhibitors of using rationale and design decisions. The findings from this survey are promising and many open research questions with respect to rationale and design decision documentation need to be addressed. In the literature reviewed in this document it is for example not addressed how design decisions and design rationale should be represented, captured and used in model-based and model-driven development approaches. A need for further research in this area exists.
Acknowledgements This work has been partially funded by the ARTEMIS projects CESAR and iFEST. The author would like to thank Martin T¨orngren for reviewing this document.
26
References [1] Ahmed, S., “Understanding the knowledge needs of novice designers in the aerospace industry,” Design Studies, vol. 25, no. 2, pp. 155–173, March 2004. [Online]. Available: http://dx.doi.org/10.1016/j.destud.2003.10.006 [2] Ahmed, Saeema, “Understanding the use and reuse of experience in engineering design,” Ph.D. dissertation, Cambridge University Engineering Department, 2001. [3] Altmanninger, Kerstin, Seidl, Martina, and Wimmer, Manuel, “A Survey on Model Versioning Approaches,” Johannes Kepler University Linz, Tech. Rep., 2009. [Online]. Available: http://smover.tk.uni-linz.ac.at/ docs/IJWIS09 paper Altmanninger.pdf [4] Babar, Muhammad A., T. Dingsøyr, Lago, Patricia, and van Vliet, Hans, Eds., Software Architecture Knowledge Management: Theory and Practice, 1st ed. Springer, August 2009. [Online]. Available: http://www.worldcat.org/isbn/3642023738 [5] Babar, Muhammad A. and Gorton, Ian, “A Tool for Managing Software Architecture Knowledge,” in SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007, pp. 11+. [Online]. Available: http://dx.doi.org/10.1109/SHARK-ADI.2007.1 [6] Babar, Muhammad A., Northway, Andrew, Gorton, Ian, Heuer, Paul, and Nguyen, Thong, “Introducing Tool Support for Managing Architectural Knowledge: An Experience Report,” in IEEE International Conference on the Engineering of Computer-Based Systems, vol. 1. Los Alamitos, CA, USA: IEEE, 2008, pp. 105–113. [Online]. Available: http://dx.doi.org/10.1109/ECBS.2008.27 [7] Babich, Wayne A., Software Configuration Management: Coordination for Team Productivity. Addison Wesley Longman, February 1986. [Online]. Available: http://www.worldcat.org/isbn/0201101610 [8] Bachmann, Felix and Merson, Paulo, “Experience Using the Web-Based Tool Wiki for Architecture Documentation,” SEI, Tech. Rep., 1998. [9] Baniassad, E. L. A., Murphy, G. C., and Schwanninger, C., “Design pattern rationale graphs: linking design to source,” in Proceedings of the 25th International Conference on Software Engineering, 2003, 2003, pp. 352–362. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp? arnumber=1201214 [10] Bass, Len, Clements, Paul, and Kazman, Rick, Software Architecture in Practice (2nd Edition), 2nd ed. Addison-Wesley Professional, April 2003. [Online]. Available: http://www.worldcat.org/isbn/0321154959 [11] Bjornson, F. and Dingsoyr, T., “Knowledge management in software engineering: A systematic review of studied concepts, findings
27
and research methods used,” Information and Software Technology, vol. 50, no. 11, pp. 1055–1068, October 2008. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2008.03.006 [12] Bosch, Jan, “Software Architecture: The Next Step,” Software Architecture, vol. 3047, pp. 194–199–199, 2004. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-24769-2 14 [13] Bratthall, Lars, Johansson, Enrico, and B. Regnell, “Is a Design Rationale Vital when Predicting Change Impact? A Controlled Experiment on Software Architecture Evolution,” in PROFES ’00: Proceedings of the Second International Conference on Product Focused Software Process Improvement. London, UK: Springer-Verlag, 2000, pp. 126–139. [Online]. Available: http://portal.acm.org/citation.cfm?id=713240 [14] Burge, J. and Brown, D. C., “Reasoning With Design Rationale,” in Artificial Intelligence in Design, 2000, pp. 611–629. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.8817 [15] Burge, J. E. and Brown, D. C., “An Integrated Approach for Software Design Checking Using Rationale,” in Proc. Design Computing and Cognition Conference, Cambridge, MA, 2004. [16] Burge, Janet E., Carroll, John M., McCall, Raymond, and I. Mistr´ık, Rationale-Based Software Engineering, 1st ed. Springer, May 2008. [Online]. Available: http://www.worldcat.org/isbn/354077582X [17] Buschmann, Frank, Henney, Kevlin, and Schmidt, Douglas C., Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. Wiley, May 2007. [Online]. Available: http://www.worldcat.org/isbn/0470059028 [18] ——, Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages. Wiley, June 2007. [Online]. Available: http://www.worldcat.org/isbn/0471486485 [19] Buschmann, Frank, Meunier, Regine, Rohnert, Hans, Sommerlad, Peter, and Stal, Michael, Pattern-Oriented Software Architecture Volume 1: A System of Patterns, 1st ed. Wiley, August 1996. [Online]. Available: http://www.worldcat.org/isbn/0471958697 [20] Capilla, Rafael, “Embedded Design Rationale in Software Architecture,” in Proceedings of the WICSA 2009, 2009. [Online]. Available: http: //wwwp.dnsalias.org/w/images/8/84/EmbeddedDesignRationale100.pdf [21] Capilla, Rafael, Nava, Francisco, and J. C. Due˜ nas, “Modeling and Documenting the Evolution of Architectural Design Decisions,” in SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007, p. 9. [Online]. Available: http://dx.doi.org/http://dx.doi.org/10.1109/ SHARK-ADI.2007.9
28
[22] Capilla, Rafael, Nava, Francisco, S. P´erez, and J. C. Due˜ nas, “A web-based tool for managing architectural design decisions,” Sw. Eng. Notes, vol. 31, no. 5, pp. 4+, 2006. [Online]. Available: http://dx.doi.org/10.1145/1163514.1178644 [23] Carroll, John M., Alpert, Sherman R., Karat, John, Van Deusen, Mary, and Rosson, Mary B., “Raison d’Etre: capturing design history and rationale in multimedia narratives,” in CHI ’94, 1994, pp. 192–197. [Online]. Available: http://dx.doi.org/10.1145/191666.191741 [24] Carroll, John M. and Rosson, Mary B., “Deliberated evolution: stalking the view matcher in design space,” Hum.-Comput. Interact., vol. 6, no. 3, pp. 281–318, 1991. [Online]. Available: http: //dx.doi.org/10.1207/s15327051hci0603%5C&4 4 [25] Chrissis, Mary B., Konrad, Mike, and Shrum, Sandy, CMMI: Guidelines for Process Integration and Product Improvement (Sei Series in Software Engineering), 2nd ed. ed. Addison-Wesley Longman, Amsterdam, November 2006. [Online]. Available: http://www.worldcat.org/isbn/ 0321279670 [26] Clements, Paul, Bachmann, Felix, Bass, Len, Garlan, David, Ivers, James, Little, Reed, Nord, Robert, and Stafford, Judith, Documenting Software Architectures: Views and Beyond. AddisonWesley Professional, September 2002. [Online]. Available: http: //www.worldcat.org/isbn/0201703726 [27] Clements, Paul and Northrop, Linda, Software Product Lines: Practices and Patterns, 3rd ed. Addison-Wesley Professional, August 2001. [Online]. Available: http://www.worldcat.org/isbn/0201703327 [28] Clerc, Viktor, Lago, Patricia, and van Vliet, Hans, “Global Software Development: Are Architectural Rules the Answer?” Global Software Engineering, International Conference on, vol. 0, pp. 225–234, 2007. [Online]. Available: http://dx.doi.org/10.1109/ICGSE.2007.21 [29] Conklin, E. Jeffrey and Yakemovic, K. C. Burgess, “A processoriented approach to design rationale,” Hum.-Comput. Interact., vol. 6, no. 3, pp. 357–391, 1991. [Online]. Available: http: //dx.doi.org/10.1207/s15327051hci0603%5C&4 6 [30] Conklin, Jeff and Begeman, Michael L., “gIBIS: a hypertext tool for exploratory policy discussion,” ACM Trans. Inf. Syst., vol. 6, no. 4, pp. 303–331, October 1988. [Online]. Available: http://dx.doi.org/10.1145/58566.59297 [31] Davenport, Thomas H. and Prusak, Laurence, Working Knowledge: How Organizations Manage What They Know. Project Management Institute, December 1997. [Online]. Available: http://www.worldcat.org/ isbn/0875846556 [32] de Boer, Remco, Farenhorst, Rik, Lago, Patricia, van Vliet, Hans, Clerc, Viktor, and Jansen, Anton, “Architectural Knowledge: Getting to the 29
Core,” in Software Architectures, Components, and Applications , ser. Lecture Notes in Computer Science, Overhage, Sven, Szyperski, Clemens A., Reussner, Ralf, and Stafford, Judith A., Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, vol. 4880, ch. 12, pp. 197–214. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-77619-2 12 [33] de Boer, Remco C. and van Vliet, Hans, “Architectural knowledge discovery with latent semantic analysis: Constructing a reading guide for software product audits,” J. Syst. Softw., vol. 81, no. 9, pp. 1456–1469, 2008. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2007.12.815 [34] Dick, Jeremy, “Design Traceability,” IEEE Softw., vol. 22, no. 6, pp. 14–16, 2005. [Online]. Available: http://dx.doi.org/10.1109/MS.2005.150 [35] T. Dingsøyr and Conradi, Reidar, “A Survey of Case Studies of the Use of Knowledge Management in Software Engineering,” International Journal of Software Engineering and Knowledge Engineering, vol. 12, no. 4, pp. 391–414, 2002. [36] T. Dingsøyr and van Vliet, Hans, “Introduction to Software Architecture and Knowledge Management,” in Software Architecture Knowledge Management, Ali Babar, Muhammad, T. Dingsøyr, Lago, Patricia, and Vliet, Hans, Eds. Berlin, Heidelberg: Springer-Verlag, 2009, ch. 1, pp. 1–17. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 1 [37] J. C. Due˜ nas and Capilla, Rafael, “The Decision View of Software Architecture,” Software Architecture, pp. 222–230, 2005. [Online]. Available: http://dx.doi.org/10.1007/11494713 15 [38] Dutoit, Allen H., McCall, Raymond, Mistrik, Ivan, and Paech, Barbara, Eds., Rationale Management in Software Engineering. Springer, 2006. [39] Easterby-Smith, Mark and Lyles, Marjorie A., Eds., The Blackwell Handbook of Organizational Learning and Knowledge Management. Wiley-Blackwell, August 2005. [Online]. Available: http://www.worldcat. org/isbn/140513304X [40] Eastwood, A., “Firm fires shots at legacy systems,” Computing Canada, vol. 19, no. 2, p. 17, 1993. [41] Ebert, Christof and De Man, Jozef, “Effectively utilizing project, product and process knowledge,” Inf. Softw. Technol., vol. 50, no. 6, pp. 579–594, 2008. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2007.06.007 [42] Erlikh, Len, “Leveraging Legacy System Dollars for E-Business,” IT Professional, vol. 2, no. 3, pp. 17–23, 2000. [Online]. Available: http://dx.doi.org/http://dx.doi.org/10.1109/6294.846201 [43] Falessi, Davide, Becker, Martin, and Cantone, Giovanni, “Design decision rationale: experiences and steps ahead towards systematic use,” SIGSOFT Softw. Eng. Notes, vol. 31, no. 5, p. 2, 2006. [Online]. Available: http://doi.acm.org/10.1145/1163514.1178642
30
[44] Falessi, Davide, Cantone, Giovanni, and Kruchten, Philippe, “ValueBased Design Decision Rationale Documentation: Principles and Empirical Feasibility Study,” in WICSA ’08: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008). Washington, DC, USA: IEEE Computer Society, 2008, pp. 189–198. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2008.8 [45] Falessi, Davide, Capilla, Rafael, and Cantone, Giovanni, “A valuebased approach for documenting design decisions rationale: a replicated experiment,” in SHARK ’08: Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge. New York, NY, USA: ACM, 2008, pp. 63–70. [Online]. Available: http://doi.acm.org/10.1145/1370062.1370079 [46] Farenhorst, Rik and Boer, Remco C., “Knowledge Management in Software Architecture: State of the Art,” in Software Architecture Knowledge Management , Ali Babar, Muhammad, T. Dingsøyr, Lago, Patricia, and Vliet, Hans, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, ch. 2, pp. 21–38. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 2 [47] Farenhorst, Rik, Lago, Patricia, and van Vliet, Hans, “Eagle: Effective Tool Support for Sharing Architectural Knowledge,” Int. J. Cooperative Inf. Syst., vol. 16, no. 3/4, pp. 413–437, 2007. [48] Fischer, Gerhard, Lemke, Andreas C., McCall, Raymond, and Morch, Anders I., “Making argumentation serve design,” Human-Computer Interaction, vol. 6, no. 3, pp. 267–293, 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=261723 [49] Fowler, M., “Design - Who needs an architect?” Software, IEEE, vol. 20, no. 5, pp. 11–13, 2003. [Online]. Available: http: //ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=1231144 [50] Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns. Addison-Wesley, 1996. [51] Ghosh, T., “Creating incentives for knowledge sharing,” MIT Sloan School, Tech. Rep., 2004. [52] Goknil, Arda, Kurtev, Ivan, and van den Berg, Klaas, “Tool support for generation and validation of traces between requirements and architecture,” in ECMFA-TW ’10: Proceedings of the 6th ECMFA Traceability Workshop. New York, NY, USA: ACM, 2010, pp. 39–46. [Online]. Available: http://dx.doi.org/10.1145/1814392.1814398 [53] Gruber, Thomas R. and Russell, Daniel M., “Generative design rationale: Beyond the record and replay paradigm,” in Design Rationale, Moran, T. and Carroll, J. H., Eds. Lawrence Erlbaum, 1992. [54] Grudin, Jonathan, “Why CSCW applications fail: problems in the design and evaluationof organizational interfaces,” in CSCW ’88: Proceedings of the 1988 ACM conference on Computer-supported cooperative work. 31
New York, NY, USA: ACM, 1988, pp. 85–93. [Online]. Available: http://dx.doi.org/10.1145/62266.62273 [55] Grunbacher, P., Egyed, A., and Medvidovic, N., “Reconciling software requirements and architectures: the CBSP approach,” in Proceedings of the Fifth IEEE International Symposium on Requirements Engineering, 2001, pp. 202–211. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=948560 [56] Habli, Ibrahim and Kelly, Tim, “Capturing and Replaying Architectural Knowledge through Derivational Analogy,” in SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007, pp. 4+. [Online]. Available: http://dx.doi.org/10.1109/SHARK-ADI.2007.6 [57] Hagge, Lars and Lappe, Kathrin, “Sharing Requirements Engineering Experience Using Patterns,” IEEE Software, vol. 22, no. 1, pp. 24–31, 2005. [Online]. Available: http://doi.ieeecomputersociety.org/10.1109/ MS.2005.17 [58] Hall, J. G., Jackson, M., Laney, R. C., Nuseibeh, B., and Rapanotti, L., “Relating software requirements and architectures using problem frames,” in RE ’02: Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering. Washington, DC, USA: IEEE Computer Society, 2002, pp. 137–144. [Online]. Available: http://dx.doi.org/10.1109/ICRE.2002.1048516 [59] Hansen, M. T., Nohria, N., and Tierney, T., “What’s your strategy for managing knowledge?” Harvard Business Review, vol. 77, no. 2, 1999. [60] Harrison, Neil B., Avgeriou, Paris, and Zdun, Uwe, “Using Patterns to Capture Architectural Decisions,” IEEE Software, vol. 24, no. 4, pp. 38–45, 2007. [Online]. Available: http://dx.doi.org/10.1109/MS.2007.124 [61] Herbsleb, J. D., Paulish, D. J., and Bass, M., “Global software development at Siemens: experience from nine projects,” in Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 524–533. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp? arnumber=1553598 [62] Herrmannsdoerfer, Markus and Koegel, Maximilian, “Towards a generic operation recorder for model evolution,” in IWMCP ’10: Proceedings of the 1st International Workshop on Model Comparison in Practice. New York, NY, USA: ACM, 2010, pp. 76–81. [Online]. Available: http://dx.doi.org/10.1145/1826147.1826161 [63] Horner, John and Atwood, Michael E., “Design rationale: the rationale and the barriers,” in NordiCHI ’06: Proceedings of the 4th Nordic conference on Human-computer interaction. New York, NY, USA: ACM Press, 2006, pp. 341–350. [Online]. Available: http://dx.doi.org/10.1145/1182475.1182511
32
[64] Huff, S., “Information systems maintenance,” The Business Quarterly, vol. 50, 1990. [65] IEEE, “Recommended practice for architectural description of softwareintensive systems (IEEE Std 1471-2000),” IEEE, Tech. Rep., 2000. [66] IEEE and ISO/IEC, “Systems and software engineering - Recommended practice for architectural description of software-intensive systems (ISO/IEC 42010 IEEE Std 1471-2000),” ISO, Tech. Rep., July 2007. [Online]. Available: http://dx.doi.org/10.1109/IEEESTD.2007.386501 [67] Jansen, A. and Bosch, J., “Software Architecture as a Set of Architectural Design Decisions,” in Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on. Washington, DC, USA: IEEE, 2005, pp. 109–120. [Online]. Available: http: //dx.doi.org/10.1109/WICSA.2005.61 [68] Jansen, Anton, “Architectural design decisions,” Ph.D. dissertation, University of Groeningen, August 2008. [Online]. Available: http: //gradius.home.fmf.nl/research/thesis/Thesis-internet.pdf [69] Jansen, Anton, de Vries, Tjaard, Avgeriou, Paris, and van Veelen, Martijn, “Sharing the Architectural Knowledge of Quantitative Analysis,” in Quality of Software Architectures. Models and Architectures, 2008, pp. 220–234. [Online]. Available: http://dx.doi.org/10.1007/ 978-3-540-87879-7 14 [70] Jansen, Anton, van der Ven, Jan, Avgeriou, Paris, and Hammer, Dieter K., “Tool Support for Architectural Decisions,” Software Architecture, Working IEEE/IFIP Conference on, vol. 0, pp. 4+, 2007. [Online]. Available: http://dx.doi.org/10.1109/WICSA.2007.47 [71] Karsenty, Laurent, “An empirical evaluation of design rationale documents,” in CHI ’96: Proceedings of the SIGCHI conference on Human factors in computing systems. New York, NY, USA: ACM, 1996, pp. 150–156. [Online]. Available: http://doi.acm.org/10.1145/238386.238462 [72] Kato, Yoshikiyo, Hori, Koichi, and Taketa, Kohei, “Capturing Design Rationale by Annotating E-mails,” 2002. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.3291 [73] Kelly, T. P., “Arguing safety – a systematic approach to managing safety cases,” Ph.D. dissertation, Department of Computer Science, University of York, 1999. [74] Kruchten, Philippe, “The 4+1 View Model of Architecture,” IEEE Softw., vol. 12, no. 6, pp. 42–50, November 1995. [Online]. Available: http://dx.doi.org/10.1109/52.469759 [75] ——, “An Ontology of Architectural Design Decisions in Software Intensive Systems,” in 2nd Groningen Workshop Software Variability, October 2004, pp. 54–61.
33
[76] ——, “Documentation of Software Architecture from a Knowledge Management Perspective,” in Software Architecture Knowledge Management, Ali Babar, Muhammad, Dingsoyr, Torgeir, Lago, Patricia, and Vliet, Hans, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, ch. 3, pp. 39–57. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 3 [77] Kruchten, Philippe, Capilla, Rafael, and J. C. Due˜ nas, “The Decision View’s Role in Software Architecture Practice,” IEEE Softw., vol. 26, no. 2, pp. 36–42, 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.52 [78] Kruchten, Philippe, Lago, Patricia, and van Vliet, Hans, “Building Up and Reasoning About Architectural Knowledge,” in Quality of Software Architectures, 2006, pp. 43–58. [Online]. Available: http://dx.doi.org/10.1007/11921998 8 [79] Kunz, W. and Rittel, H. W. J., “Issues as Elements of Information Systems,” Univ. Calif. at Berkeley, Tech. Rep., 1970. [80] Lago, Patricia and Avgeriou, Paris, “First workshop on sharing and reusing architectural knowledge,” SIGSOFT Softw. Eng. Notes, vol. 31, no. 5, pp. 32–36, 2006. [Online]. Available: http://dx.doi.org/10.1145/ 1163514.1163526 [81] Lago, Patricia and van Vliet, Hans, “Explicit assumptions enrich architectural models,” in ICSE ’05: Proceedings of the 27th international conference on Software engineering. New York, NY, USA: ACM, 2005, pp. 206–214. [Online]. Available: http://dx.doi.org/10.1145/1062455.1062503 [82] Lee, J., “Design rationale systems: understanding the issues,” Expert, IEEE [see also IEEE Intelligent Systems and Their Applications], vol. 12, no. 3, pp. 78–85, 1997. [Online]. Available: http://ieeexplore.ieee.org/ search/wrapper.jsp?arnumber=592267 [83] Lee, Jintae, “Decision representation language (DRL) and its support environment,” MIT Artificial Intelligence Laboratory, Tech. Rep., August 1989. [Online]. Available: http://hdl.handle.net/1721.1/41499 [84] ——, “SIBYL: a tool for managing group design rationale,” in CSCW ’90: Proceedings of the 1990 ACM conference on Computer-supported cooperative work. New York, NY, USA: ACM Press, 1990, pp. 79–92. [Online]. Available: http://dx.doi.org/10.1145/99332.99344 [85] Lee, Larix and Kruchten, Philippe, “Capturing Software Architectural Design Decisions,” in Electrical and Computer Engineering, 2007. CCECE 2007. Canadian Conference on, 2007, pp. 686–689. [Online]. Available: http://dx.doi.org/10.1109/CCECE.2007.176 [86] Leveson, Nancy G., “Intent Specifications: An Approach to Building Human-Centered Specifications,” IEEE Transactions on Sw. Eng., vol. 26, no. 1, pp. 15–35, January 2000.
34
[87] Leveson, Nancy G. and Weiss, Kathryn A., “Making embedded software reuse practical and safe,” in SIGSOFT ’04/FSE-12: Proceedings of the 12th ACM SIGSOFT twelfth international symposium on Foundations of software engineering. New York, NY, USA: ACM Press, 2004, pp. 171–178. [Online]. Available: http://dx.doi.org/10.1145/1029894.1029897 [88] Liang, Peng and Avgeriou, Paris, “Tools and Technologies for Architecture Knowledge Management,” in Software Architecture Knowledge Management , 2009, ch. 6, pp. 91–111. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 6 [89] Liang, Peng, Jansen, Anton, and Avgeriou, Paris, “Sharing architecture knowledge through models: Quality and cost,” Knowl. Eng. Rev., vol. 24, no. 3, pp. 225–244, 2009. [Online]. Available: http: //dx.doi.org/10.1017/S0269888909990038 [90] ——, “Collaborative Software Architecting through Knowledge Sharing,” in Collaborative Software Engineering. Springer, 2010. [Online]. Available: http://www.cs.rug.nl/∼{}liangp/download/liang2009csa.pdf [91] MacLean, Allan, Young, Richard M., Bellotti, Victoria M. E., and Moran, Thomas P., “Questions, options, and criteria: elements of design space analysis,” Human-Computer Interaction, vol. 6, no. 3, pp. 53–105, 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=261707 [92] Martin, Robert C., Riehle, Dirk, and Buschmann, Frank, Pattern Languages of Program Design 3 (Software Patterns Series). AddisonWesley Professional, October 1997. [Online]. Available: http://www. worldcat.org/isbn/0201310112 [93] McCall, R., “PHI: a conceptual foundation for design hypermedia,” Design Studies, vol. 12, no. 1, pp. 30–41, January 1991. [Online]. Available: http://dx.doi.org/10.1016/0142-694X(91)90006-I [94] McCall, Raymond J., Bennett, Patrick R., D’Oronzio, Peter S., Oswald, Jonathan L., Shipman, Frank M., and Wallace, Nathan F., “PHIDIAS: integrating CAD graphics into dynamic hypertext,” in ECHT 90. New York, NY, USA: Cambridge University Press, 1992, pp. 152–165. [Online]. Available: http://portal.acm.org/citation.cfm?id=129667 [95] Moran, Thomas P. and Carroll, John M., Eds., Design Rationale: Concepts, Techniques, and Use (Computers, Cognition, and Work), 1st ed. CRC, January 1996. [Online]. Available: http://www.worldcat. org/isbn/0805815678 [96] Myers, Karen L., Zumel, Nina B., and Garcia, Pablo, “Acquiring design rationale automatically,” Artif. Intell. Eng. Des. Anal. Manuf., vol. 14, no. 2, pp. 115–135, 2000. [Online]. Available: http: //dx.doi.org/10.1017/S0890060400142027 [97] Navarro, Elena and Cuesta, Carlos, “Automating the Trace of Architectural Design Decisions and Rationales Using a MDD Approach,” in Software Architecture, ser. Lecture Notes in Computer Science, 35
Morrison, Ron, Balasubramaniam, Dharini, and Falkner, Katrina, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2008, vol. 5292, ch. 10, pp. 114–130–130. [Online]. Available: http: //dx.doi.org/10.1007/978-3-540-88030-1 10 [98] Navarro, Israel, Lundqvist, Kristina, and Leveson, Nancy. An Intent Specification Model for a Robotic Software Control System. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70. 7351 [99] Neighbors, James M., “Software construction using components,” Ph.D. dissertation, University of California, Irvine, 1980. [Online]. Available: http://portal.acm.org/citation.cfm?id=909597 [100] Nonaka, Ikujiro and Takeuchi, Hirotaka, The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, USA, May 1995. [Online]. Available: http://www.worldcat.org/isbn/0195092694 [101] OMG, “Meta Object Facility (MOF), v2.0,” OMG, Tech. Rep., January 2006. [Online]. Available: http://www.omg.org/spec/MOF/2.0/ [102] ——, “Systems Modeling Language (SysML),” OMG, Tech. Rep., 2010. [Online]. Available: http://www.omgsysml.org/ [103] ——. (2010) Unified Modeling Language (UML). [Online]. Available: http://www.omg.com/uml/ [104] Paige, Richard F., “Traceability in model-driven safety critical software engineering,” in ECMFA-TW ’10: Proceedings of the 6th ECMFA Traceability Workshop. New York, NY, USA: ACM, 2010, p. 5. [Online]. Available: http://dx.doi.org/10.1145/1814392.1814393 [105] Pena-Mora, F. and Vadhavkar, S., “Augmenting design patterns with design rationale,” Artificial Intelligence Eng Des, vol. 11, no. 2, pp. 93–108, 1997. [106] Pilato, C. Michael, Collins-Sussman, Ben, and Fitzpatrick, Brian W., Version Control with Subversion, 1st ed. O’Reilly Media, June 2004. [Online]. Available: http://www.worldcat.org/isbn/0596004486 [107] Potts, C. and Bruns, G., “Recording the reasons for design decisions,” in ICSE ’88: Proceedings of the 10th international conference on Software engineering. Los Alamitos, CA, USA: IEEE Computer Society Press, 1988, pp. 418–427. [Online]. Available: http://portal.acm.org/citation.cfm?id=55863 [108] Regli, W. C., Hu, X., Atwood, M., and Sun, W., “A Survey of Design Rationale Systems: Approaches, Representation, Capture and Retrieval,” Engineering with Computers, vol. 16, no. 3 - 4, pp. 209–235, December 2000. [Online]. Available: http://dx.doi.org/10.1007/PL00013715 [109] Robillard, Pierre N., “The role of knowledge in software development,” Communications of the ACM, vol. 42, no. 1, pp. 87–92, January 1999. [Online]. Available: http://dx.doi.org/10.1145/291469.291476 36
[110] Rozanski, Nick and Woods, Eoin, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, April 2005. [Online]. Available: http://www.worldcat.org/ isbn/0321112296 [111] Saaty, Thomas L., “Decision making with the analytic hierarchy process,” International Journal of Services Sciences, vol. 1, no. 1, pp. 83–98, January 2008. [Online]. Available: http://www.metapress.com/content/ 02t637305v6g65n8 [112] Schmidt, Douglas, Stal, Michael, Rohnert, Hans, and Buschmann, Frank, Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects, 1st ed. John Wiley & Sons, September 2000. [Online]. Available: http://www.worldcat.org/isbn/ 0471606952 [113] Schneider, Kurt, “Rationale as a By-Product,” in Rationale Management in Software Engineering , 2006, pp. 91–109. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-30998-7 4 [114] Schuster, N., Zimmermann, O., and Pautasso, C., “ADkwik: Web 2.0 Collaboration System for Architectural Decision Engineering,” in SEKE, 2007, pp. 255–260. [115] Shahin, Mojtaba, Liang, Peng, and Khayyambashi, Mohammad R., “Architectural Design Decision: Existing Models and Tools,” in Proceedings of WICSA 2009, 2009, pp. 293–296. [116] Shipman, Frank M. and Marshall, Catherine C., “Formality Considered Harmful: Experiences, Emerging Themes, and Directions on the Use of Formal Representations in Interactive Systems,” Computer Supported Cooperative Work (CSCW), vol. 8, no. 4, pp. 333–352, December 1999. [Online]. Available: http://dx.doi.org/10.1023/A:1008716330212 [117] Shipman, Frank M. and McCall, Raymond, “Supporting knowledge-base evolution with incremental formalization,” in CHI ’94: Proceedings of the SIGCHI conference on Human factors in computing systems. New York, NY, USA: ACM, 1994, pp. 285–291. [Online]. Available: http://dx.doi.org/10.1145/191666.191768 [118] Shum, S. J., “A Cognitive Analysis of Design Rationale Representation,” Ph.D. dissertation, University of York, 1991. [Online]. Available: http://people.kmi.open.ac.uk/sbs/research/phd/phd.html [119] Shum, Simon B., “Analyzing the Usability of a Design Rationale Notation,” in in Design Rationale: Concepts, Techniques, and, 1996, pp. 185–215. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.52.5956 [120] Shum, Simon B. and Hammond, Nick, “Argumentation-based design rationale: what use at what cost?” International Journal of HumanComputer Studies, vol. 40, no. 4, pp. 603–652, April 1994. [Online]. Available: http://dx.doi.org/10.1006/ijhc.1994.1029 37
[121] Simon, Herbert A., Administrative Behavior, 4th Edition, 4 Sub ed. Free Press, March 1997. [Online]. Available: http://www.worldcat.org/isbn/ 0684835827 [122] Sinnema, Marco, van der Ven, Jan S., and Deelstra, Sybren, “Using variability modeling principles to capture architectural knowledge,” SIGSOFT Softw. Eng. Notes, vol. 31, no. 5, p. 5, 2006. [Online]. Available: http://doi.acm.org/10.1145/1163514.1178645 [123] Tang, Antony, Babar, Muhammad A., Gorton, Ian, and Han, Jun, “A survey of architecture design rationale,” J. Syst. Softw., vol. 79, no. 12, pp. 1792–1804, December 2006. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2006.04.029 [124] Tang, Antony, Jin, Yan, and Han, Jun, “A rationale-based architecture model for design traceability and reasoning,” Journal of Systems and Software, vol. 80, no. 6, pp. 918–934, June 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2006.08.040 [125] Tang, Antony, Nicholson, Ann, Jin, Yan, and Han, Jun, “Using Bayesian belief networks for change impact analysis in architecture design,” Journal of Systems and Software, vol. 80, no. 1, pp. 127–148, January 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2006.04.004 [126] Tang, Antony, Tran, Minh, Han, Jun, and van Vliet, Hans, “Design Reasoning Improves Software Design Quality,” in Quality of Software Architectures. Models and Architectures , ser. Lecture Notes in Computer Science, 2008, ch. 2, pp. 28–42. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-87879-7 2 [127] Tang, Antony and van Vliet, Hans, “Modeling constraints improves software architecture design reasoning.” in WICSA/ECSA. IEEE, 2009, pp. 253–256. [Online]. Available: http://dblp.uni-trier.de/db/conf/ wicsa/wicsa2009.html#TangV09 [128] Tang, Antony and Vliet, Hans, “Software Architecture Design Reasoning,” in Software Architecture Knowledge Management , 2009, ch. 9, pp. 155– 174. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02374-3 9 [129] Thurimella, Anil K., Bruegge, Bernd, and Creighton, Oliver, “Identifying and Exploiting the Similarities between Rationale Management and Variability Management,” in SPLC ’08: Proceedings of the 2008 12th International Software Product Line Conference. Washington, DC, USA: IEEE Computer Society, 2008, pp. 99–108. [Online]. Available: http://dx.doi.org/10.1109/SPLC.2008.14 [130] F. K. E. P. T¨orner, “On Hazard Identification and Safety Cases In the Automotive Domain,” Ph.D. dissertation, Chalmers University of Technology, 2008. [131] Toulmin, Stephen E., The Uses of Argument. Cambridge University Press, January 1958. [Online]. Available: http://www.worldcat.org/isbn/ 0521092302 38
[132] Tyree, Jeff and Akerman, Art, “Architecture Decisions: Demystifying Architecture,” IEEE Software, vol. 22, no. 2, pp. 19–27, 2005. [Online]. Available: http://dx.doi.org/10.1109/MS.2005.27 [133] Vesperman, Jennifer, Essential CVS, 1st ed. O’Reilly Media, June 2003. [Online]. Available: http://www.worldcat.org/isbn/0596004591 [134] Vetschera, Rudolf, “Preference-Based Decision Support in Software Engineering,” in Value-Based Software Engineering , 2006, ch. 4, pp. 67–89. [Online]. Available: http://dx.doi.org/10.1007/3-540-29263-2 4 [135] Vliet, Hans, Avgeriou, Paris, Boer, Remco C., Clerc, Viktor, Farenhorst, Rik, Jansen, Anton, and Lago, Patricia, “The GRIFFIN Project: Lessons Learned,” in Software Architecture Knowledge Management, 2009, ch. 8, pp. 137–154. [Online]. Available: http: //dx.doi.org/10.1007/978-3-642-02374-3 8 [136] Weiss, Kathryn A., Ong, Elwin C., and Leveson, Nancy G., “Reusable specification components for model-driven development,” in In Proceedings of the International Conference on System Engineering, INCOSE, 2003. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.5.7488 [137] Wu, Weihang and Kelly, Tim, “Managing Architectural Design Decisions for Safety-Critical Software Systems,” in Quality of Software Architectures , ser. Lecture Notes in Computer Science, Hofmeister, Christine, Crnkovic, Ivica, and Reussner, Ralf, Eds. Springer Berlin Heidelberg, 2006, vol. 4214, ch. 9, pp. 59–77. [Online]. Available: http://dx.doi.org/10.1007/11921998 9 [138] Xin, Wang and Guangleng, Xiong, “Design rationale as part of corporate technical memory,” in Systems, Man, and Cybernetics, 2001 IEEE International Conference on, vol. 3, August 2002, pp. 1904–1908 vol.3. [Online]. Available: http://dx.doi.org/10.1109/ICSMC.2001.973625 [139] Zdun, Uwe and Avgeriou, Paris, “A catalog of architectural primitives for modeling architectural patterns,” Inf. Softw. Technol., vol. 50, no. 9-10, pp. 1003–1034, 2008. [Online]. Available: http: //dx.doi.org/10.1016/j.infsof.2007.09.003 [140] Zdun, Uwe, Avgeriou, Paris, Hentrich, Carsten, and Dustdar, Schahram, “Architecting as decision making with patterns and primitives,” in SHARK ’08: Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge. New York, NY, USA: ACM, 2008, pp. 11–18. [Online]. Available: http://dx.doi.org/10.1145/1370062.1370066 [141] Zelkowitz, Marvin, Principles of Software Engineering and Design (Prentice-Hall software series). Prentice Hall, 1979. [Online]. Available: http://www.worldcat.org/isbn/013710202X [142] Zimmermann, Olaf, “An Architectural Decision Modeling Framework for Service-Oriented Architecture Design,” Ph.D. dissertation, Universit¨at Stuttgart, March 2009. 39
[143] Zimmermann, Olaf, Gschwind, Thomas, J. K¨ uster, Leymann, Frank, and Schuster, Nelly, “Reusable Architectural Decision Models for Enterprise Application Development,” in Software Architectures, Components, and Applications , 2007, pp. 15–32. [Online]. Available: http: //dx.doi.org/10.1007/978-3-540-77619-2 2 [144] Zimmermann, Olaf, Zdun, Uwe, Gschwind, Thomas, and Leymann, Frank, “Combining Pattern Languages and Reusable Architectural Decision Models into a Comprehensive and Comprehensible Design Method,” Software Architecture, Working IEEE/IFIP Conference on, vol. 0, pp. 157–166, February 2008. [Online]. Available: http: //dx.doi.org/10.1109/WICSA.2008.19
40
Appendix E
An Executable Design Decision Representation using Model Transformations Matthias Biehl and Martin T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA2010), September 2010. c
2010 IEEE. Reprinted, with permission.
An Executable Design Decision Representation using Model Transformations Matthias Biehl Embedded Control Systems Royal Institute of Technology Stockholm, Sweden
[email protected] Abstract Design decisions are often tacit knowledge of an architecture and consequently they are easily lost during software evolution, a phenomenon known as knowledge vaporization. As a countermeasure, design decisions can be documented explicitly. However, documenting design decisions is expensive because they need to be captured in addition to the changes in the architecture. We propose an executable representation for design decisions using model transformations, which is independent of a particular component model or architectural description language. As a result, we provide the possibility to reduce knowledge vaporization. At the same time we prevent the high capturing cost, since the corresponding architectural change can be computed automatically.
1
Introduction
During the development and design of a software architecture important decisions about the resulting system are made. These architectural design decisions determine the quality characteristics of the system. The outcome of the design decisions is described explicitly in the form of architectural models that have their own representations such as domain specific languages, architecture description languages, metamodels and domain models. A number of different languages exist, each targeting different domains and particular quality attributes. However, the root causes for the form of the architecture, the design decisions themselves, are usually not explicitly represented in those languages. As a result the architectural knowledge inherent in the design decisions gets lost. This loss of architectural knowledge creates problems during evolution and maintenance [5] and may eventually lead to design erosion [11]. Explicit knowledge about the design decisions would be desirable during later lifecycle phases of the system, when the architecture evolves and needs to be maintained. Under-
Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden
[email protected] standing the intent behind the existing architecture is a very time and cost intensive task. Nevertheless, understanding what is already there and which design decisions have been made previously is a vitally important part of maintenance. It is a prerequisite for changing and evolving the architecture in harmony with the original intent. Another reason for capturing design decisions in safety critical systems is given by the need to justify and document that best practices have been applied. Usually knowledge about design decisions is tacit and design decisions stay in the heads of the architect. Knowledge about the design decisions is dependent on the person, managed by the strategy of personalization [6]. The disadvantage of this personalization strategy of architectural knowledge management surfaces when personnel changes, when new architects work on existing systems or when legacy systems have to be maintained. The knowledge of design decisions is neither codified in the architecture nor in the documentation, and the architectural decision cannot be deduced from a single architectural model either. As a result the knowledge about design decisions gets lost during development and evolution. This phenomenon has been identified in industrial settings and has been named knowledge vaporization [7]. To mitigate this problem, several approaches have been proposed that capture architectural knowledge, e.g. Leveson proposes to capture the intent [10] and Burge proposes to capture software engineering rationale [2]. Due to the central role design decisions have in the development of an architecture, Bosch proposes to document design decisions explicitly [1]. The explicit representation of design decisions has the potential to improve the quality of software architectures by reducing knowledge vaporization. Different representations for design decisions were proposed, most of them are information models based on metamodels. These approaches however share the problem that the design decisions need to be captured in addition to the architecture. This creates overhead for the decision maker and thus design decisions are not widely documented in prac-
tice. Further inhibitors have been identified [4], such as the potential inconsistency between the architecture and the documentation of design decisions. The associated overhead reduces the likelihood of design decisions being captured. This problem is known as the capture problem, one of the major hindrances for explicitly capturing rationale and design decisions. Kruchten et al. discuss the need to reduce the double effort that is currently required when capturing design decision and the need for suitable representations and tools for design decisions [9]. We identify the following desirable objectives for the representation of design decisions: Objective 1: The design decision should be captured and described using an appropriate representation. Objective 2: Design decisions change an architecture. Thus introducing a new design decision requires a double effort, (1) for capturing the changes in the architecture and (2) for documenting the design decision. It is desirable to leverage the same representation for both efforts. Objective 3: The design decision representation should be compatible with existing metamodels, architecture description languages and domain specific languages. This allows users of existing, widespread and accepted languages to add a decision view to their architecture [3]. To be able to be used as an add-on, design decision need to be independent of the architecture description language used. We propose a representation of design decisions in section 2 that fulfills the above criteria. In section 3 we report a case study we performed with our representation. We conclude the paper in section 4 with a summary and ideas for future work.
2
Approach
The documentation of design decisions is a doubleedged sword. On the one hand it is desirable, since it reduces knowledge vaporization and has the potential to improve the system quality during software evolution. On the other hand it is costly, since it creates an overhead for the architect and is thus seldom performed in practice. This problem can be alleviated by an executable representation for design decisions. When a design decision is made in a given architecture, the result is a new architecture that is equal to the first one but additionally incorporates the changes induced by the design decision. If we interpret the design decision as a function, the input of the function is the previous architecture, the output is a new architecture. During architectural refinement several design decisions are made, resulting in a sequence of intermediate architectural models being created. This can be formalized as follows: A design decision d : M → M made on a given architectural model A0 ∈ M
yields a new architectural model A1 ∈ M , where M is the set of possible architectures described according to a common metamodel. The design decision can be interpreted as a function over architectural models, where an execution of the design decision creates a new architecture incorporating the changes induced by the design decision d, in short A1 = d(A0 ). Several design decisions d1 ...dn are made during architectural refinement, formalized as a composition of functions An = (dn ◦ dn−1 ◦ ... ◦ d1 )(A0 ). As a result we can describe the design process explicitly as dn ◦ dn−1 ◦ ... ◦ d1 , i.e. the sequence of steps by which the architecture is refined, instead of the outcome An of the design process. In this work we propose an executable representation of design decisions, allowing us to generate architectural models automatically as described in the last paragraph. To achieve executability of design decisions, a couple of things have to be in place. The design decisions need to be described with sufficient detail so they can be executed. An interpreter needs to be available that can execute the description of a design decision and can produce a modified architecture as output. We propose to use model transformations as an executable representation of design decisions. Model transformations can be executed, the result of the execution reflects a changed architecture. This has the advantage that design decisions only need to be captured as a transformation and the change in the architecture is merely a cause of the execution of the transformation. Since model transformations can be used for models conforming to different metamodels, this approach is not bound to a specific notation and can be applied to architectural models that are described using existing metamodels or architecture description languages. Model transformations provide a mechanism for representing design decisions.
2.1
Mapping between Design Decisions and Model Transformations
In order to identify to what extent design decisions can be represented by model transformations, we examine which information is required for the representation of design decisions. As an orientation we use the ontology of architectural design decisions by Kruchten [8]. According to the ontology a design decision comprises the decision itself, the scope of the decision, the rationale of the decision, cost, risk, author, timestamp and state. We found that the elements of the design decision ontology can be partly represented by model transformations. The scope of the decision describes the context in which the decision is defined. In the ontology Kruchten lists different interpretations of the scope, such as system scope, time scope and organization scope. We focus here on the system
scope, the non-technical interpretations of the scope can be represented in the design decision rationale. The system scope is the precondition under which the design decision can be applied and executed. The scope corresponds to the matching patterns or the left-hand-sides of all the rules of the model transformation. The outcome of the decision can be expressed by the right-hand-side of a model transformation, it will be introduced into the architecture. In summary the core of the design decision, consisting of the decision itself and its application context, can be described with model transformations. The additional elements mentioned in the ontology of design decisions can be regarded as an extension to the core of the decision. We store them textually in a separate data structure called Design Decision Management Container (DDMC). It is used for managing the metadata of each design decision in textual form, such as rationale, cost, risk, author, timestamp and state. Furthermore the DDMC points to the model transformation realizing the decision. The relationship between pairs of design decisions can be documented in DDMCs. Examples of the relationships between design decisions include conflicting design decisions, alternative design decisions and dependencies. Multiple design decisions can be managed as a sequence of DDMCs. A DDMC sequence describes the order in which design decisions are made. In pure information models for design decisions the issue of linking design decisions to the architecture arises. It requires effort, to keep the information about design decisions consistent with the architecture. With executable design decisions this link is created automatically through the pattern matching algorithm of the transformation engine. The transformation engine identifies all the occurrences of the left hand side, when the model transformation is applied.
2.2
Representation of Multiple Design Decisions
Several design decisions are made during the development of an architecture. To record the evolution or history of an architecture a sequence of design decisions has to be recorded. The decisions in this sequence can be represented by several model transformations or by several model transformation rules. Representing a sequence of design decisions by model transformation rules has the disadvantage that single design decisions cannot be executed separately and the execution order of rules may be indeterministic (e.g. for ATL), making it impossible to coerce an ordering. As the order in which the design decisions are executed is relevant when constructing the architecture, we represent multiple design decisions as a sequence of separate model transformations. Moreover, using the latter approach each intermediate architectural model is explicitly constructed and
available as an artifact. The intermediate architectural models can be inspected and analyzed. For each design decision a number of alternative design decisions exist that have been rejected and consequently do not have an effect on the architecture. In this work, however, we focus on documenting the design decisions that are realized in the architecture.
2.3
Requirements for the Model Transformation Language
A number of different model transformation languages exist. A challenge is finding the right model transformation language for the purpose of representing design decisions. To be able to make a suitable selection, we identify the following requirements. The model transformation language needs to be a model-to-model transformation, because both input and output of the transformation are architectural models. Further, the transformation engine needs to support in-place transformations. Most transformation engines generate a completely new target model, whereas inplace transformations create the target model by modifying specific parts in the existing source model.
3
Case Study
To validate our proposal of using model transformations to represent design decisions we performed a case study on design decisions in an automotive brake-by-wire system. In this case study we explored modeling a design decision using different model transformation languages. We examine both ATL and Tiger EMF, two different transformation languages to model design decisions. ATL is a representative from the class of hybrid (declarative and imperative) model transformation languages and Tiger EMF as a representative from the class of model transformations based on triple graph grammars. The intention is to explore the feasibility and usability of different model transformation approaches for representing design decisions, not to provide an exhaustive list of suitable model transformation languages. The details of the case study are left out due to space constraints, we instead focus in the following on the lessons learned. After conducting the case study using two different model transformation formalisms to represent design decisions, we can check the objectives stated in section 1: Objective 1: We demonstrated that it is feasible to express design decisions using different model transformation formalisms. The design decision can be described using endogenous, in-place model-to-model transformations. We used both ATL and Tiger EMF in the case study. Objective 2: The model transformation as a representation of design decisions fulfills two functions simultane-
ously: documenting the design decision and changing the architecture by executing the transformation. Objective 3: The design decision representation is compatible with existing metamodels, as long as they can be processed by model transformation tools. We used the architecture description language EAST-ADL2 in the case study. We noticed that writing up the design decision as a general transformation rule forces the decision maker to think clearly about the decision, i.e. in which context it may be applied and which exceptions have to be made. If the design decision is stated in a general way, it can be applied in several places of the architecture. In the brake-by-wire case study the redundancy design decision could be applied for several sensors in the architecture. The understandability of the model transformations is a question of appropriate training and tools and on the size of the design decision. As one model transformation captures only one single design decision, the size of the model transformation rule is relatively small and limited. We noticed differences between the languages. Creating the model transformation graphically, such as in Tiger EMF, resembles modeling the architecture directly. Textual model transformation descriptions such as those by ATL are verbose and possibly harder to understand.
4
Conclusions and Future Work
Documenting architectural design decisions is an attempt to minimize knowledge vaporization and its undesirable effects during system evolution. In practice, however, design decisions are seldomly captured, despite the large number of benefits. One of the major reasons is the double effort required in capturing both the changes in the architecture and documenting the design decision. In this work we proposed model transformations as an executable representation for documenting design decisions. If design decisions are executable, we can generate their effects on the architecture without needing to change the architecture manually. In addition, any intermediate version of the architecture can be reconstructed by replaying the design decisions up to that point. In a case study we have shown that it is feasible to represent executable design decisions using different model transformations. Model transformations offer a mechanism for capturing design decisions that is independent of a particular architecture description language, metamodel or component model. By using model transformations the concept of design decisions can be added to existing modeling languages. We would like to allow people to change the graphical architecture models in the way they are used to and create the model transformation automatically. Such a tool can hide the model transformation from the user but still use model
transformations as an underlying mechanism for documenting the design decision. The tool creates two snapshots of the architecture, one before the design decision was applied and one afterwards. The tool computes the delta and based on the delta it creates a model transformation describing the design decision. Some design decisions can solve recurring problems. These decisions are in fact application-specific customizations of general design patterns. If design decisions are captured as general rules, they can be reused, and thus reduce the effort for modeling the architecture. A design decision that is created once, can be applied in several places of the architecture. Libraries of such general executable design decisions that only need to be customized when they are applied, can further lower the amount of effort necessary for documenting design decisions.
References [1] J. Bosch. Software architecture: The next step. Software Architecture, 3047:194–199–199, 2004. [2] J. E. Burge and D. C. Brown. An integrated approach for software design checking using rationale. In Proc. Design Computing and Cognition Conference, Cambridge, MA, 2004. [3] J. C. Due˜nas and R. Capilla. The decision view of software architecture. Software Architecture, pages 222–230, 2005. [4] D. Falessi, G. Cantone, and P. Kruchten. Value-based design decision rationale documentation: Principles and empirical feasibility study. In WICSA ’08: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), pages 189–198, Washington, DC, USA, 2008. IEEE Computer Society. [5] B. Graaf. Maintainability through architecture development. In EWSA 2004, pages 206–211, 2004. [6] M. T. Hansen, N. Nohria, and T. Tierney. What’s your strategy for managing knowledge? Harvard Business Review, 77(2), 1999. [7] A. Jansen and J. Bosch. Software architecture as a set of architectural design decisions. In Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, pages 109–120, Washington, DC, USA, 2005. IEEE. [8] P. Kruchten. An ontology of architectural design decisions in software intensive systems. In 2nd Groningen Workshop Software Variability, pages 54–61, October 2004. [9] P. Kruchten, R. Capilla, and J. C. Due˜nas. The decision view’s role in software architecture practice. IEEE Softw., 26(2):36–42, 2009. [10] N. G. Leveson. Intent specifications: An approach to building human-centered specifications. IEEE Transactions on Sw. Eng., 26(1):15–35, January 2000. [11] D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, October 1992.
Appendix F
Documenting Stepwise Model Refinement using Executable Design Decisions Matthias Biehl, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in International Workshop on Models and Evolution (ME 2010), October 2010.
Documenting Stepwise Model Refinement using Executable Design Decisions Matthias Biehl Embedded Control Systems Royal Institute of Technology Stockholm, Sweden
[email protected]
Abstract. During model refinement a wealth of knowledge about the model under development is accumulated that is only partly represented by the model itself. Design decisions and the considered modeling alternatives are neither represented by the model nor are they documented. During later lifecycle stages this information is often not available any more, which reduces the understandability of the model and potentially leads to inconsistencies and erosion of the model. We propose an approach to capture and store the design decisions in model-driven development. We represent design decisions as model transformations and propose tool support that applies this representation to capture design decision with low effort. The captured design decisions provide a record of the model evolution and the rationale of the evolution. Key words: Design Decision, Evolution, Model Transformation, Refinement
1
Introduction
During the early stages of architectural design a number of alternative architectural models are created, evaluated and refined. During this exploration phase a lot of knowledge about the system is acquired, which is important during later lifecycle phases such as detailed design and maintenance. However, this knowledge consisting of design decisions and their justification is usually not documented due to the associated time and cost overhead. Capturing and documenting design decisions is expensive and is often seen as an additional obligation not providing any immediate value in the design process. In fact, the value of design decision documentation will usually surface much later in the lifecycle, for example during maintenance activities. By the time the knowledge is needed, it is usually not readily available any longer. Decisions that seemed to be self-evident at the time they were made can often not be reconstructed or understood later in the development process. This problem is known as knowledge vaporization [3], which results in further problems such as inconsistencies, design erosion, aging and architectural drift [20, 16, 17].
2
Matthias Biehl
The design method of stepwise refinement of programs was first explored by Dijkstra [6] and by Wirth [22]. Wirth states that program development is a series of refinement steps, further he links refinements with the design decisions. Refinement can have slightly different meanings. In the strict sense, a refinement describes adding detail to something that already exists. In a more relaxed sense, refinement can also include adding new functionality. An example of a development method based on architectural refinement is Attribute Driven Design (ADD) [23]. ADD prescribes a top-down decomposition process that subsequently attacks all quality attributes in their order of importance. In this work we assume a model-driven development process, where models are developed iteratively by refining a baseline model. Iterative refinement starts with an initial model, which is the first baseline model and may be empty. In each refinement step the baseline model is changed, yielding a new model that serves as baseline for the consecutive refinement step. One refinement step entails a small change in the model and cannot be understood without considering related refinement steps made immediately before and after. It makes sense to bundle refinement steps into logical entities that comprise several refinement steps. A design decision is such a logical entity that comprises several related refinement steps. When a model is refined, a number of design decisions are made and applied on an initial model. As a result a modified model incorporating the changes induced by the design decisions is created. Thus the model refinement can be documented by a sequence of design decisions. Architects have long recognized the importance of documenting design decisions, as Tang et al. found in their survey on architecture design rationale [18]. Practitioners use documented design rationale to reason about the architecture. While some representations and tool support are available, the capturing of design decisions and their rationale still creates additional overhead, making design decision documentation a double edged sword [10]. This paper is structured as follows. In section 2 we introduce related work. In section 3 we introduce our representation for design decisions. In section 4 we show how this representation can be used to capture design decisions with low effort. In section 5 we present a case study in which we apply our approach on a model of an automotive embedded architecture. We conclude this work in section 6.
2
Related Work
In this section we review related work in the area of design decision representation. Kruchten [9] specifies an ontology of architectural design decisions. A number of different approaches for representing design decisions have been proposed in academia. Informal representations document design decisions in the form of free text and use-cases. Template-based approaches provide a guideline for textual descriptions of design decisions such as the template by Tyree and Akermann [21]. Structural approaches explicitly represent the design delibera-
Documenting Stepwise Model Refinement using Executable Design Decisions
3
tion process, including alternatives and arguments. Examples are IBIS [11], PHI [15], DRL [12] and QOC [14]. Approaches for representing design decisions that were developed in recent years focus on linking design decisions with the architectural model. The SEURAT approach links rationale to specific lines in the source code [4]. AREL is a UML profile that can be used to annotate architectural models with design decisions and rationale [19]. The Archium [7] approach associates design decisions with modifications of the architecture. These models provide descriptions, traceability and linking to other modeling elements.
3
Representation of Design Decisions
In this section we introduce our representation for design decisions, which is tailored for model-driven development. There are several objectives for our representation of design decisions for model-driven development: – Objective 1: Design decisions should be represented explicitly. – Objective 2: The design decision representation should reduce the capture overhead. – Objective 3: Design decisions should be represented independently of a certain modeling language. – Objective 4: The documentation of design decisions should be consistent with the architectural model. – Objective 5: The documentation of design decisions should be linked to the model elements affected by the decision.
3.1
Executable Design Decision
Our representation for a design decision consists of the following parts: a model transformation and a textual description (objective 1). The representation is called executable design decision [1], as a model transformation engine can execute it automatically (objective 2). The core of the executable design decision is a model transformation, which describes both the context in which the design decision can be made and the effect that the design decision will have on the architecture (objective 5). Since we use model transformations to represent design decisions, we can execute the design decision and inspect the effect the design decision has on the model. As a consequence of this automation, the model and the design decision are consistent (objective 4). Model transformations can be specified for any metamodel without needing to change the metamodel (objective 3). Different model transformation technologies can be used for expressing design decisions, as long as the model transformation engine fulfills certain requirements, such as support for model-to-model transformations that are endogenous and in-place.
4
3.2
Matthias Biehl
Formalization of Design Decisions
In the previous section we introduced our representation of design decisions. Design decisions are interpreted as change functions and represented as model transformations. When a design decision is made for a given model, the result is a new model incorporating the changes induced by the design decision. If we interpret the design decision as a function, the input of the function is the previous model, the output is a new model. This can be formalized as follows: A design decision d : M → M made on a given architectural model A0 ∈ M yields a new architectural model A1 ∈ M , where M is the set of possible architectures described according to a common metamodel. The design decision can be interpreted as a function over architectural models, where an execution of the design decision creates a new architecture incorporating the changes induced by the design decision d, in short A1 = d(A0 ). Several design decisions d1 ...dn are made during architectural refinement, formalized as a composition of functions An = (dn ◦ dn−1 ◦ ... ◦ d1 )(A0 ). As a result we can describe the design process explicitly as dn ◦dn−1 ◦...◦d1 , i.e. the sequence of steps by which the architecture is refined, instead of the outcome An of the design process.
4
Capturing Design Decisions
In stepwise model refinement the capturing of design decisions comprises four steps: 1. 2. 3. 4.
Performing an update of the model, so it reflects the new design decision Documenting where in the model the change applies and what is changed Documenting the rationale of the change Linking the documentation to the model elements affected by the change
The overhead of these steps is one of the main reasons why design decisions are not documented [10]. Tools can help to reduce the overhead for the architect, by exploiting the intrinsic relation between steps (1), (2) and (4). A model transformation has a precondition and a postcondition that can be used for documenting where in the model the change applies and what is changed (2). When the model transformation is executed on the initial model, the outcome is the updated model (1). The precondition of the model transformation links the design decision to the model before the change and the postcondition links the design decision to the model after the change (4). A model transformation is capable of capturing steps (1), (2) and (4) by a single representation. The architect does not need to create the model transformation manually, instead it can be created algorithmically from different snapshots of the model. We can create this model transformation based on a snapshot of the model taken before the change and a snapshot taken after the change. We use a triple graph grammar (TGG) rule to describe the design decision dn of section 3.2. A TGG rule consists of three graphs, a left-hand side graph, a right-hand side graph and a mapping graph. We calculate these three components in the following way:
Documenting Stepwise Model Refinement using Executable Design Decisions
5
– Left-hand Side (LHS) The model An−1 corresponds to the context of the applied decision, i.e. the snapshot of the model before the change. – Right-hand Side (RHS) The model An corresponds to the outcome of the applied decision, i.e. the snapshot of the model after the change. – Mapping The mapping graph establishes identity links between elements in the LHS and RHS. Given the LHS and RHS, the mapping graph can be computed e.g. by comparing the values of the model elements in LHS with the model elements in RHS.
5
Case Study
To validate our proposal of using model transformations to represent design decisions we perform a case study on design decisions in a model of an automotive brake-by-wire system. In this case study we explore modeling a design decision using different model transformation languages, ATL and Tiger EMF. ATL is a representative from the class of hybrid (declarative and imperative) model transformation languages and Tiger EMF as a representative from the class of model transformations based on triple graph grammars. The intention is to explore the feasibility and usability of different classes of model transformation approaches for representing design decisions. 5.1
Brake-By-Wire Architecture
In modern cars the traditional mechanics and hydraulic connection between user interface and actuators are increasingly replaced by electronics and software [13]. In this case study we will look at a subsystem of the automotive software architecture, a brake-by-wire system. We use EAST-ADL2 [5] as a representation for the architecture of the brakeby-wire system. EAST-ADL2 is an architecture description language for the domain of automotive embedded systems. It can be used to describe high-level abstract functions and both the hardware and the software architecture of an embedded system. Figure 1 shows an initial architecture of the brake-by-wire system modeled with EAST-ADL2. We use it as an initial model that is subsequently refined. In a brake-by-wire system the brake pedal is a component that reads the user’s input and sends this information over a network to the brake controllers at every wheel. At each wheel a brake controller receives both information about the wheel speed and the requested braking from the pedal. The brake controller actuates the mechanical brake in order to achieve a good braking performance, e.g. to avoid skidding. Safety and reliability are important qualities of a brake-by-wire system. Thus the design decisions made during the development of the brake-by-wire system need to address safety. Common design decisions in safety-critical embedded systems are decisions about the replication of components with the intent to
6
Matthias Biehl
Fig. 1. Simplified brake-by-wire system modeled with EAST-ADL2
enhance the reliability of the system. These decisions have a major impact on both the safety and the cost of the complete system as we will see in this example. Option B in Fig. 2 shows a refined architecture of the brake-by-wire system. Here we intended to increase the reliability and safety of the system and decided to use triple redundancy with a voter for the pedal sensor. An alternative design option uses dual redundancy instead, depicted as option A in Fig. 2. The second sensor serves as a standby, running in parallel with the primary sensor, so that at least one of the components delivers a signal, should the other one fail. Dual redundancy improves reliability compared to the initial model and does not have the high cost of triple redundancy.
Fig. 2. Simplified brake-by-wire system with (A) double redundancy and (B) triple redundancy
5.2
Representation of Design Decisions with Tiger EMF
Tiger EMF [2] is a model transformation framework that is based on triple graph grammars. It supports in-place transformations. A transformation rule is specified using a pattern to be matched in the source model (left-hand side), and a pattern to be created in the target model (right-hand side). Between elements from the left-hand side and elements from the right-hand side a mappingrelation, the third graph, can be specified, which is expressed with corresponding numbers in the left-hand side and right-hand side. The context of the design decision corresponds to the left-hand side of the model transformation, depicted in Fig. 3.
Documenting Stepwise Model Refinement using Executable Design Decisions
7
Fig. 3. Left-hand side of the design decision for double and triple redundancy
The outcome of the design decision corresponds to the right-hand side, depicted in Fig. 4. The negative application condition specifies that the transformation is applied at most once, and due to space constraints it is not included here. The transformation creates an architecture with triple redundancy as depicted in Fig. 2 B.
Fig. 4. Right-hand side of the design decision for triple redundancy
We can use existing tools for reliability and cost analysis on this architecture. Even though the reliability of the system is improved, the component costs for triple redundancy with voter are high. We might want to explore an alternative design decision for double redundancy. Based on the initial architecture (see Fig. 1) and the alternative design decision, we can generate an alternative architecture. We create an alternative design decision using a new model transformation. The right-hand side of the new model transformation is depicted in Fig. 5, the left-hand side is the same as for the previous model transformation, as the decision is applied in the same context. After executing the model transformation, an architecture with double redundancy is created (see Fig. 2 A).
8
Matthias Biehl
Fig. 5. Right-hand side of the design decision for double redundancy
As we have seen in this example, the design space can be explored without much effort by reusing the design decisions and modifying them slightly. Design decisions solving the same issue differently, i.e. alternative design decisions (or model transformations), have the same context (or left-hand side) and a different outcome. Moreover, we can change the design decisions to be applicable in a different context. The design decision for double redundancy (Fig. 5) can be applied to the WheelSpeedSensor instead, by changing the string PedalSensor to WheelSpeedSensor in the corresponding left-hand side (Fig. 3). This can be generalized by introducing parameters into the transformation. 5.3
Representation of Design Decisions with ATL
To show that design decision can be represented with different model transformation languages, we created a second example of the design decision for triple redundancy and implemented it in ATL. The ATLAS Transformation Language (ATL) [8] is a hybrid model transformation language, supporting both declarative and imperative programming styles. An ATL transformation is composed of rules that describe how to create and initialize the elements of the target models. To support in-place transformations, ATL has to be configured to run in a special execution mode, the refining mode. Several practical limitation of the current ATL refining mode exist, such as missing foreach-loops and lazy rules. Due to space constraints we have not included the transformation source code.
6
Conclusion
We proposed model transformation as a representation for design decisions fulfilling the identified objectives for design decisions in model driven development. We call this representation executable design decisions, since an engine can automatically create the changed model based on this design decision representation.
Documenting Stepwise Model Refinement using Executable Design Decisions
9
Design decisions can be captured based on two snapshots of the model: (1) the model before the change and (2) the model after the change. The model transformation representing the design decision can be computed. The architect does not have to code the transformation manually. In a case study we have shown that it is feasible to represent executable design decisions using different model transformation languages. We noticed differences between the languages. Creating the model transformation graphically, such as in Tiger EMF, resembles modeling the architecture directly. Textual model transformation descriptions such as those by ATL are verbose and possibly harder to understand. The sequence of design decisions captures the evolution of the model. Any intermediate version of the model can be reconstructed by replaying the design decision up to that point. This allows the designer to try out several alternative decisions and inspect the produced architecture. At the same time the design decisions are documented and linked to the model. 6.1
Future Work
There is a need for a large industrial case study. Such a case study can be used to find out if design decisions provide an appropriate granularity for model evolution in practice and with more complex refinements. The proposed representation for design decisions does not presuppose that the documented decision is actually realized. However, we would need to provide an additional infrastructure for storing design decisions that were rejected. When the design decision is captured explicitly and to some degree of formality, the decision itself can become the subject of analysis. For example the relation between different design decisions, such as dependency relations, can be calculated automatically. The model transformation provides a precondition (the left-hand side) and a postcondition (the right-hand side) that can be used for deducing dependencies. Acknowledgements This work has been partially funded by the ARTEMIS projects CESAR and iFEST.
References 1. Matthias Biehl and Martin T¨ orngren. An executable design decision representation using model transformations. In 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2010), September 2010. 2. E. Biermann, K. Ehrig, C. K¨ ohler, G. Kuhns, G. Taentzer, and E. Weiss. Graphical definition of in-place transformations in the Eclipse Modeling Framework. In MODELS 2006, volume 4199, pages 425–439, 2006. 3. Jan Bosch. Software architecture: The next step. Software Architecture, 3047:194– 199–199, 2004.
10
Matthias Biehl
4. J. E. Burge and D. C. Brown. An integrated approach for software design checking using rationale. In Proc. Design Computing and Cognition Conference, Cambridge, MA, 2004. 5. Philippe Cuenot, Patrik Frey, Rolf Johansson, Henrik L¨ onn, Yiannis Papadopoulos, Mark-Oliver Reiser, Anders Sandberg, David Servat, Ramin T. Kolagari, Martin T¨ orngren, and Matthias Weber. The east-adl architecture description language for automotive embedded software. Model-Based Engineering of Embedded Real-Time Systems, 2010. 6. Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, October 1976. 7. Anton Jansen, Jan van der Ven, Paris Avgeriou, and Dieter K. Hammer. Tool support for architectural decisions. Software Architecture, Working IEEE/IFIP Conference on, 0:4+, 2007. 8. F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev. ATL: a model transformation tool. Science of Computer Programming, 72:31–39, June 2008. 9. Philippe Kruchten. An ontology of architectural design decisions in software intensive systems. In 2nd Groningen Workshop Software Variability, pages 54–61, October 2004. 10. Philippe Kruchten, Rafael Capilla, and Juan C. Due˜ nas. The decision view’s role in software architecture practice. IEEE Softw., 26(2):36–42, 2009. 11. W. Kunz and H. W. J. Rittel. Issues as elements of information systems. Technical report, Univ. Calif. at Berkeley, 1970. 12. Jintae Lee. Decision representation language (DRL) and its support environment. Technical report, MIT Artificial Intelligence Laboratory, August 1989. 13. Peter Liggesmeyer and Mario Trapp. Trends in embedded software engineering. Software, IEEE, 26(3):19–25, April 2009. 14. Allan MacLean, Richard M. Young, Victoria M. E. Bellotti, and Thomas P. Moran. Questions, options, and criteria: elements of design space analysis. HumanComputer Interaction, 6(3):53–105, 1996. 15. R. McCall. Phi: a conceptual foundation for design hypermedia. Design Studies, 12(1):30–41, January 1991. 16. David L. Parnas. Software aging. In ICSE, pages 279–287, 1994. 17. D. Perry and A. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17(4):40–52, October 1992. 18. Antony Tang, Muhammad A. Babar, Ian Gorton, and Jun Han. A survey of architecture design rationale. J. Syst. Softw., 79(12):1792–1804, December 2006. 19. Antony Tang, Yan Jin, and Jun Han. A rationale-based architecture model for design traceability and reasoning. Journal of Systems and Software, 80(6):918– 934, June 2007. 20. John B. Tran, Michael W. Godfrey, Eric H. S. Lee, and Richard C. Holt. Architectural repair of open source software. In In Proceedings of International Workshop on Program Comprehension, pages 48–59, 2000. 21. Jeff Tyree and Art Akerman. Architecture decisions: Demystifying architecture. IEEE Software, 22(2):19–27, 2005. 22. Niklaus Wirth. Program development by stepwise refinement. Communications of the ACM, 14(4):221–227, April 1971. 23. Rob Wojcik, Felix Bachmann, Len Bass, Paul C. Clements, Paulo Merson, Robert Nord, and William G. Wood. Attribute-driven design (add), version 2.0. Technical report, Software Engineering Institute, November 2006.
