Afef Awadid
email: afef.awadid@irt-systemx.fr

Remi Boyer
email: remi.boyer@irt-systemx.fr

On the Conceptualization of Tools for Traceabilitybased Change Impact Analysis using a Domainspecific Modeling Approach

Keywords: design changes, traceability-based change impact analysis, CIA parameters, domain-specific modeling, multi-view modeling, graph-based modeling II

In the context of system architecture design, design changes are deemed as an important issue in the field of cyber-physical systems. This is due to their costs that can increase up to several folds with each step of the life cycle, from conceptual design to operation. Accordingly, before putting such changes into practice, their impacts need to be analyzed based on traceability of dependencies among elements in system artifacts. However, traceability-based Change Impact Analysis (CIA) is time consuming and error-prone process, if performed manually. Thus, a number of tools have been developed in this regard. Yet, in the absence of approaches guiding the specification and implementation of such tools, research reveals their inadequacy for the needs of the industry. To overcome this, this paper proposes a domain-specific modeling approach for the conceptualization of traceability-based CIA tools. Such approach is composed of three building blocks. First, a language for traceability-based CIA designed around the concept of "CIA parameters" (i.e., all kind of information that could contribute to quantitative or qualitative change impact assessment). Second, a modeling procedure referring to a multi-view modeling approach that explains how to use the traceability language to allow creation and machine processing of models (i.e., analysis of models in terms of change impact). Third, mechanisms and algorithms focusing on the implementation of the modeling procedure on a metamodeling platform. The proposed approach is thus an attempt to bridge the gap between design and implementation of traceability-based CIA tools. The approach is illustrated on an example from the aviation field.

I. INTRODUCTION

With the increasing complexity of cyber-physical systems such as self-driving cars [START_REF] Birchler | Costeffective Simulation-based Test Selection in Self-driving Cars Software[END_REF], their architectural design focusing on modelling and mapping system artifacts (e.g., requirements and functions) needs to be optimized [START_REF] Bouskela | Formal requirements modeling for cyber-physical systems engineering: An integrated solution based on FORM-L and Modelica[END_REF]. Such optimization requires accounting for design change as one of the key issues in the field of cyber-physical systems [START_REF] Wolf | What don't we know about CPS architectures?[END_REF]. Design change refers to "the changes resulting from a modification within or outside the original scope of work and require re-design and revision to the contract documents" [START_REF] Shourangiz | Flexibility of BIM towards design change[END_REF]. The system architecture design change is derived from different sources such as customer requirements, functional design, operating environment, and implementation technology [START_REF] Phoomboplab | Self-resilient production systems: framework for design synthesis of multi-station assembly systems[END_REF]. Consequently, its cost can increase up to several folds with each phase of the system life cycle from conceptual design to operation [START_REF] Chew | Industrial implementation issues of total site heat integration[END_REF] and hence can be prohibitively high. Given this, Change Impact Analysis (CIA) referring to analysis of change propagation for instance in terms of the workload needs to be performed before putting any design change into practice [START_REF] Tang | Workload-Based Change Propagation Analysis in Product Design[END_REF].

CIA builds upon traceability of dependencies between elements in system artifacts [START_REF] Holt | Foundations for model-based systems engineering: from patterns to models[END_REF]. Thus, it is no surprise that there is a multitude of tools available for traceability-based change impact analysis such as Requisite Pro and DOORS. However, in spite of the large number of such tools, their adoption rate throughout industry remains low [START_REF] Saiedian | A streamlined, costeffective database approach to manage requirements traceability[END_REF]. One reason for their inadequacy for the needs of the industry [START_REF] Saiedian | A streamlined, costeffective database approach to manage requirements traceability[END_REF] is the deficiency in their conceptualization. Indeed, approaches for the conceptualization of traceability-based CIA tools are still lacking. By such conceptualization, we mainly refer to (i) the definition of the requirements that the tool must fulfill, (ii) the identification of the parameters that can be used to analyze and assess change impact, regardless of the application domain, and (iii) the determination of the basic functionalities of a traceability-based CIA tool.

As an attempt to bridge the research gap between design and implementation of tools for traceability-based change impact analysis, this paper proposes a domain-specific modeling approach that guides the specification and implementation of such tools so that they meet the stakeholders' expectations. This method is composed of three parts: (1) a traceability language involving a set of CIA parameters, (2) a modeling procedure referring to a multi-view modeling approach that explains how to use the traceability language to allow creation and machine processing of models (i.e., analysis of models in terms of change impact), and (3) mechanisms and algorithms focusing on the implementation of the modeling procedure on a metamodeling platform.

The rest of the paper is organized as follows. Section 2 presents the theoretical foundations of this research and gives an overview of the related work. The proposed domainspecific modelling approach for the conceptualization of traceability-based CIA tools is presented and illustrated on an example from the aviation field in Section 3. Section 4 concludes the paper with some future research directions.

A. Theoretical Foundations a) Change Impact Analysis (CIA): CIA refers to the process of exploring the effects of a given change in other parts of the system [START_REF] Kretsou | Change impact analysis: A systematic mapping study[END_REF]. A natural way to analyze change impact is to raise the following questions: If I change this design element or this requirement, what are the elements that will be affected and must be modified in turn? ; If I change this model element, what effort is required and what will the cost be? [START_REF] Douglass | Agile Model-Based Systems Engineering Cookbook Improve system development by applying proven recipes for effective agile systems engineering[END_REF]. By putting emphasis on how change propagates and affects its surroundings [START_REF] Breivoll | Change Impact Analysis-A Case Study[END_REF], CIA seeks to reduce risks that often arise from changes being made without consideration of the potential impacts. A change in the system architecture design refers generally to one of the three following change types: add, alter, or remove architecture element(s) [START_REF] Damak | Operational Context-Based Design and Architecting of Autonomous Vehicles[END_REF]. Each change type is triggered by a Design Change Request. The latter can occur, for instance, when the design team realized that the design of a subsystem needs to be changed in order to accommodate constraints from another subsystem [START_REF] Guegan | Assessing the Maturity of Interface Design[END_REF]. b) Traceability: In practice, change impact analysis relies on traceability defined as "a discernible association among two or more logical entities such as requirements, system elements, verifications, or tasks" [START_REF] Park | A framework of the requirements for the management of a nuclear fuel cycle facility[END_REF]. Albeit traceability is considered as one of the most frequently adopted techniques for change impact analysis [START_REF] Kretsou | Change impact analysis: A systematic mapping study[END_REF], it has been argued that a traceability model "is not sufficient to capture the progress of evolving artifacts" [START_REF] Yadav | Evolution traceability roadmap for business processes[END_REF] as elements at the architectural design may evolve to a new configuration of architectural elements [START_REF] Van Den | Change impact analysis of crosscutting in software architectural design[END_REF]. In view of this, to perform change impact analysis, it is not sufficient to define a traceability representation language and hence to create traceability models. It is important likewise to allow the automated processing of those models. This may include for instance the capability of determining the elements that will be affected by a given change and the change associated cost. Nevertheless, these capabilities are constrained by the presence of CIA parameters referring to all kind of information that could contribute to quantitative or qualitative change impact assessment. Examples of CIA parameters in the context of software development are amount of change defined as the extent of changes that occurred on a software artifact [START_REF] Arisholm | Assessing the changeability of two object-oriented design alternatives--A controlled experiment[END_REF] and change proneness referring to the probability of a software artifact to change [START_REF] Jaafar | Detecting asynchrony and dephase change patterns by mining software repositories[END_REF].

c) Domain-specific Modeling Method: Unsurprisingly, in light of the previous section, it seems clear that two elements are pivotal to the conceptualization of traceabilitybased CIA tools: a modeling language for creating traceability models and mechanisms for ensuring the automated processing of those models. Against this background, a domain-specific modeling method could be a promising approach for conceptualizing such tools. Indeed, besides a modeling language, a domain-specific modeling method involves a modeling procedure and mechanisms & algorithms [START_REF] Karagiannis | Metamodelling platforms[END_REF]. While modelling procedure emphasizes on how to employ the modeling language to achieve results, mechanisms & algorithms focus on the tool support [START_REF] Awadid | Overlap-Driven Approach for the Conceptualization of Consistency Preserving Modeling Tools[END_REF]. The latter includes, among others, the automated support of modeling procedure. Along with the already discussed reason, there are two other reasons why a domain-specific modeling method could be a suitable approach for the conceptualization of traceability-based CIA tools. First, "domain specific modeling is well suited for domains where the composition of different elements is very flexible" [START_REF] Leitner | Towards multimodeling for domain description[END_REF]. This is the case for system architecture design domain. Second, a domain-specific modeling method fosters the use of familiar concepts to the domain while constructing models of applications [START_REF] Hernández | Automating the development of scientific applications using domain-specific modeling[END_REF]. Building on this, adopting a domainspecific modeling approach for the conceptualization of traceability-based CIA tools would promote their ease of use and acceptance by the end-users. Additionally, a DSM method is developed by first constructing a meta-model that describes the ontology of the domain and that can be created either from scratch or using existing solutions [START_REF] Hernández | Automating the development of scientific applications using domain-specific modeling[END_REF].

B. Related Work

The importance of traceability has been widely recognized throughout the systems engineering industry, as it does not only help to comprehend a system more easily [START_REF] Königs | Traceability in Systems Engineering-Review of industrial practices, state-of-the-art technologies and new research solutions[END_REF], but also underpins the design change impact analysis [START_REF] Holt | Foundations for model-based systems engineering: from patterns to models[END_REF]. Thus, it should come as no surprise that traceability-based change impact analysis has garnered a lot of attention from both academic and industry literature (e.g., [START_REF] Cleland-Huang | Software and systems traceability for safety-critical projects[END_REF], [START_REF] Abraham | Guidelines for architecture models as boundary objects[END_REF], [START_REF] Wohlrab | Boundary objects and their use in agile systems engineering[END_REF], [START_REF] Santiago | Model-driven engineering as a new landscape for traceability management: A systematic literature review[END_REF], [START_REF] Von Knethen | QuaTrace: a tool environment for (semi-) automatic impact analysis based on traces[END_REF], and [START_REF] Hassane | MAPLE-T: a tool for process enactment with traceability support[END_REF]). Consequently, several approaches have been proposed in this regard. Although they all attempt to support traceability-based CIA, these approaches differ markedly in the nature of such support. In this sense and based on the review of the literature, we distinguish between two kinds of support: conceptual and technical. Unlike the former which focuses on providing metamodels or ontologies for traceability, the focus of the latter is rather on providing tools allowing automated support of traceability-based CIA. Accordingly, existing literature can be broadly classified into two categories: process-centric and tool-centric, where the first category concentrates on the how of "traceability-based CIA" from the conceptual point of view, while the second category emphasizes on the how from the technical point of view.

The generic traceability process model proposed by [START_REF] Gotel | Traceability fundamentals[END_REF] is one of the approaches fitting in the first category. This model involves the main activities in the lifecycle of a trace and serves as a basis for articulating the challenge of traceability. Furthermore, [START_REF] Cleland-Huang | Trace queries for safety requirements in high assurance systems[END_REF] suggests a usage-centered traceability process that employs UML class diagrams in order to define traceability strategies for a project. [START_REF] Peraldi-Frati | Requirement traceability in safety critical systems[END_REF], [START_REF] Sanchez | Introducing safety requirements traceability support in model-driven development of robotic applications[END_REF], and [START_REF] Katta | A conceptual model of traceability for safety systems[END_REF] propose traceability metamodels along with queries dedicated to the safety domain.

The second strand of approaches is on providing tool support. Central to this strand are the traceability tools such as DOORS [43] and Requisite Pro [44]. These Commercial Off the Shelf (COTS) tools support the management of traces between requirements and other artifacts. Nevertheless, they do not possess the capability of analyzing the impact of artefacts evolution and thus of updating traceability links and affected artifacts in a timely manner. On the one hand, this justifies their low adoption rate throughout industry [START_REF] Saiedian | A streamlined, costeffective database approach to manage requirements traceability[END_REF]. On the other hand, it upholds the need for approaches guiding the specification and implementation of traceability-based CIA tools.

III. A DSM APPROACH FOR THE CONCEPTUALIZATION OF TRACEABILITY-BASED CIA TOOLS

This section sets forth (1) the requirements that a domainspecific modeling approach for conceptualizing traceabilitybased CIA tools should satisfy (Section A), and (2) the building blocks of such approach (Section B).

A. Requirements for the DSM Approach

Referring to recent literature in domain specific modeling [START_REF] Wieland | A domain-specific modeling method for supporting the generation of business plans[END_REF], the conceptualization of a domain-specific modeling approach consists first in defining the requirements that this method needs to fulfill. To do so, we relied on experts in system architecture design such as system architects and system engineers, as they are not only accustomed to traceability-based CIA tools, but also acquainted with the limitations of those they use. These experts refer to stakeholders in different joint academic-industry research projects namely System & Safety Continuity (S2C) project [25] and I(SC)² -Collaborative systems engineering of complex systems (I(SC)²) project [26]. As highlighted in Table 1, the resulting requirements are classified into two categories depending on whether a given requirement should be covered by the modeling language (i.e., the "what" of the intended domain-specific modeling approach) or by the modeling procedure and/ or the algorithms & mechanisms (i.e., the "how" of the intended domain-specific modeling approach). With this in mind, the first category encompasses requirements pertaining to language for traceability-based CIA, while the second includes those related to support of traceability-based CIA. The traceability language/ metamodel on which to base the domain-specific modeling approach has to be application domain agnostic Req3: The traceability language on which to base the domain-specific modeling approach should exhibit the link between traceability and change impact analysis.

Support of traceabilitybased CIA

Req4: The domain-specific modeling approach should allow for the creation of traceability models Req5: The domain-specific modeling approach should provide the system architecture design model from which the traceability model is derived Req6: The domain-specific modeling approach should allow for the co-evolution of system architecture design model and its corresponding traceability model Req7: The domain-specific modeling approach should provide mechanisms and functionalities for ensuring the automated support of traceability-based CIA

B. Building Blocks of the DSM Approach

The proposed DSM approach is composed of three building blocks: (1) the language for traceability-based CIA, (2) the modeling procedure, and (3) the mechanisms & algorithms (cf. Section c): together they attempt to respond to the requirements defined in Table 1. Moreover, the DSM approach (and thus their building blocks) is illustrated on an example from the aviation field. a) Language for traceability-based CIA: This language lies in a metamodel that captures the main concepts and relations related to traceability-based CIA and that brings to the forefront the notion of "CIA parameter". Accordingly, CIA parameters referring to all kind of information that could contribute to quantitative or qualitative change impact assessment (cf. Section b) constitute an inherent part of the proposed modeling language. As mentioned earlier, the modeling language of a domain-specific modeling method can be built either from scratch or adapted from existing one(s) (cf. Section c).

In our case, the specification of the intended metamodel relied on two existing traceability patterns derived from the fields of software engineering and systems engineering. The first embodies a traceability pattern for crosscutting [START_REF] Van Den | Change impact analysis of crosscutting in software architectural design[END_REF]. The concept of "crosscutting" assumes that at least two phases, levels, or domains are somehow interrelated. The second pattern stands for an ontology defining traceability concepts [START_REF] Holt | Foundations for model-based systems engineering: from patterns to models[END_REF].

The choice of these patterns is motivated by their ability to meet the second requirement in Table 1. Once chosen, the two patterns are examined in terms of two aspects. First, the meaning of concepts and relations they use. Second, the relevance of each of these concepts and relations to change impact analysis, by considering the notion of "CIA parameters". "CIA parameters" can serve as a basis for both automated generation of traceability views and change impact assessment. Following this, we built a metamodel for supporting traceability-based change impact analysis as shown in Fig. 1. The resulting metamodel lays the foundation for developing traceability-based CIA tools that can meet the stakeholders' expectations, as it fulfills the requirements falling within the first category in Table 1. As a matter of fact, the proposed metamodel captures the key concepts in traceability-based CIA (cf. Req1 in Table 1). Besides this, it is application domain agnostic since it is based on generic traceability patterns (cf. Req2). Furthermore, by highlighting the relationship between the concepts of "Traceable Element" and "CIA Parameter", the proposed metamodel exhibits the link between traceability and change impact analysis (cf. Req3).

As seen in Fig. 1, CIA parameters are inherent to the proposed metamodel. The definition of these parameters is grounded on both theory (literature on traceability languages) and practice (experience with several academic-industry research projects).

For the sake of clarity, all the concepts that seem relevant to the understanding of the metamodel are exposed in Table 2, where CIA parameters are highlighted in yellow. It is defined in terms of domain, phase, and/ or level. We distinguish between intra-domain (e.g. within the systems engineering domain) and inter-domain (e.g. between systems engineering and safety analysis domains), intra-level (e.g. within the aircraft level) and inter-level (e.g. between aircraft and item levels) , and intra-phase (e.g. within the phase of aircraft functional architecture) and inter-phase relationships (e.g. between the phases of aircraft functional architecture and functional safety verification) Traceability Relationship Semantics The meaning of a traceability relationship (e.g., refinement, verification, and validation). Note that the list of "traceability relationship semantics" may cover semantics that are specific to given application domains. Hence, such list cannot be exhaustive.

b) Modeling Procedure: As mentioned earlier in Section c, the second building block of a domain-specific modeling method known as "modeling procedure" focuses on how to use the modeling language to achieve results. Applying this to our proposal, we define the modeling procedure as the component of the domain-specific modeling approach that accentuates on how to employ the proposed metamodel (cf. Fig. 1) to conceptualize a traceability-based CIA tool that meets the expected requirements. Consequently, in contrast to the modeling language focusing on the "what" of the domain-specific modeling approach, the modeling procedure rather puts emphasis on the "how" part. Thus, it targets the second category of requirements in Table 1.

In this vein and in order to accommodate the first three requirements within this category (i.e., Req4-Req6), we advocate the use of a multi-view modeling approach as a modeling procedure. Multi-view modeling refers to "a methodology where different aspects of the system are captured by different models or views" [START_REF] Reineke | Basic problems in multi-view modeling[END_REF]. It is considered as a "particular approach for coping with the complexity of the system by decomposing its overarching model into several views" [START_REF] Bork | Preserving multi-view consistency in diagrammatic knowledge representation[END_REF]. By "system", [START_REF]Systems and software engineering-System life cycle processes[END_REF] refers to any entity whose architecture is of interest (e.g., hardware, software, and processes). When it comes to mastering the systems' complexity, the usefulness of multi-view modeling "is obvious and objectively proven" [START_REF] Fischer | based modeling-Towards defining the viewpoint concept and implications for supporting modeling tools[END_REF]. Against this background, it was found that applying a multi-view approach makes "it easier to cope with overall size of the problem domain" and leads "to a deeper understanding of the problem domain" [START_REF] Easterbrook | Do viewpoints lead to better conceptual models? An exploratory case study[END_REF]. This is one of the main reasons why we advocated a multi-view modeling approach as a modeling procedure. Indeed, in the context of this study, a traceabilitybased CIA process constitutes our system of interest. Such process is consistently seen as complex, as it deals not only with two different but interrelated aspects: traceability and change impact analysis, but also with two kinds of different but interrelated models: system architecture model and its corresponding traceability model.

On the one hand, a system architecture model is commonly composed of several diagrams. It can thus be captured using several views. On the other hand, a traceability model allows to capture the dependencies between elements in the system architecture model. Consequently, traceability views can be generated from system architecture views based on such dependencies.

Building on this, the modeling procedure distinguishes between two types of views: 1) the system architecture views referring to the different diagrams of the system architectural model; and 2) the traceability views standing for the diagrams capturing the dependencies between the different system architecture views. As said before, traceability views can be generated from system architecture views using existing dependencies, and hence using "Traceability Relationships Semantics" (cf. Table 2). Therefore, the "CIA parameters" proposed by the metamodel (cf. Fig. 1) can be used not only for assessing change impact analysis, but also for supporting the automated generation of traceability views. Regarding the representation of the latter, the modeling procedure upholds a graph-based notation, as "graph-based modeling is a wellknown technique in many branches of knowledge allowing analysis and synthesis of systems" [START_REF] Zawiślak | Graph-Based Modelling in Science[END_REF]. In this sense, being built on the concepts of "Traceable Elements" and their "Relationships", the proposed metamodel makes it easier the implementation of a graph-based modeling language, where "Traceable Elements" correspond to the nodes of the graph, while the "Relationships" represent its edges.

Considering the described modeling procedure, the technical novelty of the proposed approach lies in the generation of a traceability graph from system architecture views using the notion of "CIA parameters".

For illustration purposes, we demonstrate this modeling procedure on an example from the aviation field, where the analysis on an In-Flight Entertainment (IFE) system relies on several architecture views. Two examples of such views focusing on the functional analysis of the IFE system are shown in Fig. 2 and Fig. 3. Comparing to view 1 (cf. Fig. 2), view 2 (cf. Fig. 3) examines the high-level functions to explore in greater detail the functional analysis. It is worth noting here that view 1 and view 2 are performed according to the Arcadia method and adopting the Capella tool [START_REF]Eclipse: Capella[END_REF]. To generate an example of a traceability graph from "View 1" and "View 2" and to assess the impact of altering each of the functions "Provide Aircraft Information, Commands and Means", "Entertain with IFE System", "Perform Cabin Management Activities" in "view 1", we resorted to two of the proposed "CIA parameters" viz., "Traceability Relationships Semantics" and "Traceable Element Magnitude" by proceeding in the following way:

• Let X a "Traceable Element" in "View1";

• Let Y a "Traceable Element" in "View2";

• Initialize "X_Magnitude" with zero;

• For each X

• For each Y

• If X→Y Relationship Semantics is "Refinement" Then

• Create a graph triplet <X, X→Y, Y>

• Increment "X_Magnitude" with one As shown above, "Magnitude" of a given "Traceable Element" X is determined automatically as it refers to the number of its corresponding graph triplets. The resulting traceability view is presented in Fig. 4, where only the three aforementioned high-level functions are displayed. As highlighted in Fig. 4, each of the high-level functions is accompanied with the value of its magnitude based on which the impact of its alteration can be assessed. In this sense, compared to the other functions, "Provide Aircraft Information, Commands and Means" is the most costly in terms of design update effort, as it has the greatest affected architecture elements.

For instance, the label "F3_Magnitude: 2" implies that two sub-functions are linked to F3 and is created once the graph triplets associated with F3 are created. c) Mechanisms & Algorithms: Unlike the modeling procedure which concentrates on the "how" of traceabilitybased CIA from the conceptual point of view, mechanisms and algorithms spotlight on the "how" from the technical point of view. In other words, mechanisms and algorithms is the building block of the domain-specific modeling approach that seeks to implement the modeling procedure and thus to provide the automated support for it (cf. Req7 in Table 1). This entails the implementation of the multi-view modeling approach, where a graph-based modeling language needs to be developed in order to allow the creation of traceability views in the form of graphs. Concretely, implementing the multi-view modeling approach is tantamount to implementing the underlying viewpoints on any metamodeling platforms such as ADOxx [START_REF]The ADOxx metamodelling platform[END_REF].

To illustrate this idea, an insight on how to implement the main aspects of the proposed modeling procedure using the ADOxx metamodeling platform is given in Table 3. Considering the "traceability viewpoint" of the modeling procedure (row 2 in Table 3), we have implemented a graphbased modeling language composed of two modeling constructs: "Traceable Element" as node and "Traceability Relationship" as edge. The result of such implementation on ADOxx is shown in Fig. 5. Fig. 5. "Traceability viewpoint" implemented as a graph-based modeling language using ADOxx Focusing on the "CIA parameters" aspect (row 5 of Table 3), it has been implemented as attributes with values as displayed in Fig. 6. The latter illustrates an instantiation of two CIA parameters: "Traceability Relationship Semantics" and "Traceability Relationship Type" on the edge "Entertain with IFE System → Command VOD Service". Because of the significant rework cost it may incur, system architecture design update is consistently seen as challenging. Consequently, the need for analyzing the impacts of design changes based on traceability of dependencies between elements in system artifacts is unquestioned. Nevertheless, the underlying process requires tool support, as it is tedious, time consuming, and inaccurate. Yet, despite the large number of existing tools in this area, experience with joint academicindustry research projects showed their inadequacy for the industry needs, mainly in terms of analyzing the impact of artefacts evolution and thus of updating traceability links and affected artifacts in a timely manner.

Against this background, this paper proposed a domainspecific modeling approach for the conceptualization of traceability-based CIA tools. The approach aims at providing guidance on how to specify and implement such tools so that they meet the stakeholders' expectations.

Driven by a set of requirements, the proposed approach is structured around three building blocks: (1) a language/metamodel for traceability-based CIA. Central to this language is the concept of "CIA parameters" referring to all kind of information that could contribute to quantitative or qualitative change impact assessment; (2) a modeling procedure referring to a multi-view modeling approach that explains how to use the traceability language to allow creation and machine processing of models (i.e., analysis of models in terms of change impact). It distinguishes between two types of views: system architecture views and traceability views, where the latter can be generated from the former using the CIA parameter "Traceability Relationship Semantics". The "CIA parameters" can thus guide both the assessment of change impact analysis and the generation of traceability views in the form of graphs; and (3) mechanisms and algorithms focusing on the implementation of the modeling procedure on a metamodeling platform. The approach was illustrated on the example of the In-Flight Entertainment system.

Accounting for "traceability-based CIA" from both conceptual and technical point of view, the domain-specific modeling approach attempts to bridge the gap between design and implementation of traceability-based CIA tools.

As future work, we plan (1) to elaborate on the modeling procedure as to the graph-based analysis of change impact using "CIA parameters" and (2) to perform additional illustration of the approach in the context of safety-critical systems engineering field where traceability-based CIA tools are required to strengthen certification arguments. Empirical studies with real cases and proper evaluation of the approach are therefore envisaged.

Fig. 1 .

 1 Fig. 1. Metamodel for supporting traceability-based CIA

Fig. 2 .

 2 Fig. 2. A IFE system architecture view: view 1

Fig. 4 .

 4 Fig. 4. An example of a generated traceability view

Fig. 6 .

 6 Fig. 6. Example of implementation of "CIA parameters" as attributes with values using ADOxx IV. CONCLUSIONS

TABLE I .

 I REQUIREMENTS FOR A DSM APPROACH FOR THE CONCEPTUALIZATION OF TRACEABILITY-BASED CIA TOOLS

	Category	Requirements
		Req1: The domain-specific modeling approach should
		be based on a metamodel capturing the key concepts in
		traceability-based CIA
	Language for traceability-	Req2:
	based CIA

TABLE II .

 II It focuses on how many target traceable elements are semantically linked to the considered source traceable element. The notion of "magnitude" is considered whenever a semantic relation exists between two architecture elements. Therefore, it can capture indirect relationships. Traceability Relationship Type

		DESCRIPTION OF THE METAMODEL CONCEPTS
	Concept	Description
	View	An instance of a viewpoint referring to a definition to which a view must comply (e.g. the underlying diagram
		types)).
	Traceable Element	The element that can be traced. We distinguish between "Source traceable element" (i.e. the traceable element
		being modified) and "Target traceable Element" (i.e. the traceable element being affected)
	Traceable Element Attribute	A property of a traceable element that could be modified or affected. Hence, traceable element attribute refers to
		both the modified attribute(s) of the source traceable element and the affected attribute(s) of the target traceable
		element
	Relationship	The traceability relationship being considered between two traceable elements
	Domain	A given domain of application
	Level	Each level is a refinement of the previous one
	Phase	A phase can refer to any phase in the system development lifecycle
	CIA parameter	Any kind of information that could contribute to quantitative or qualitative change impact assessment
	Change Nature	Addition, alteration, or deletion (e.g., addition of an aircraft component)
	Traceable element Level	The level of the source traceable element (e.g., the aircraft level)

Traceable Element Domain

The domain of the source traceable element (e.g. the aircraft safety analysis domain) Traceable Element Phase The phase of the source traceable element (e.g., the aircraft functional architecture) Traceable Element Type It distinguishes between two types of traceable elements: atomic and composite Traceable Element Magnitude

TABLE III .

 III

	Co-evolution	of	system	Using Event Handlers. Event Handlers
	architecture views and the	are AdoScripts that are executed when
	generated traceability in order	certain events occur such as creating an
	to	ensure	consistency	instance, creating a connector and
	between them			editing an attribute value.
	CIA parameters			Using Attributes defining certain
					properties of classes or relation classes
					THE WAY TO IMPLEMENT THE MODELING PROCEDURE ON
					ADOXX METAMODELING PLATFORM
					Main aspects of the modeling procedure	How it is implemented on ADOxx
					Viewpoints (i.e., the different
					modeling languages needed	Using ADOxx Model Types. A Model
					to create views) such as the	Type determines a subset of all
					graph-based	modeling	instantiable classes and relations to be
					language needed to create	used by the modeler to create models.
					traceability views
					Interrelated views: linking	Using the attribute type "InterRef"
					"Traceability Elements" from	which describes the relationship
					different views of system	between two objects from two or more
					architecture	classes within or across models