The DAM Profile

The DAM profile has been defined by mapping, systematically, the concepts of the DAM domain model onto UML extensions and onto MARTE concepts. It includes a set of DAM extensions (stereotypes and tags) and a DAM library containing dependability specific types. To maintain a small (and usable) set of stereotypes, only a subset of conceptual classes of the domain model were mapped to stereotypes but, when it had been possible, complex datatypes have been defined. The DAM profile is formed by two packages (Figure 3.8(a)): the DAM UML Extensions and the DAM Library. The

Chapter 3. Languages for modeling critical systems: MARTE and DAM 46

Figure 3.7: Maintenance domain model

first contains all the stereotypes, obtained as UML extensions and MARTE inheritances, defined by DAM; the latter is the model library in which datatypes are defined. The DAM Library is structured in turn as two packages(Figure3.8(b)): the Basic DA Types and the Complex DA Types.

Figure 3.8: DAM profile

To maintain the traceability of the DAM stereotypes and datatypes, it was decided to use the same name of the conceptual classes defined in the DAM domain model, adding the prefix Da. As an example the Figure 3.9 shows the set of stereotypes obtained by mapping conceptual classes belonging to the Core package of the DAM domain model. In the figure, five different stereotypes are showed: DaComponent, DaService, DaStep, DaConnector and DaServiceRequest. In particular, while the first three inherit from MARTE stereotypes, the last two extend UML metaclasses since the concepts they represent are not present in MARTE. Each stereotype defines its own tagged-values

and, where present, inherits those defined in the MARTE stereotype from which it inherits. The same approach has been used to define other stereotypes belonging to other packages.

Figure 3.9: Core package of the DAM profile

The DAM Library imports NFPs and reuse the VSL defined in the MARTE profile. The complex datatypes represent those conceptual classes that have been not mapped to stereotypes: these datatypes come from the Threat and Maintenance packages of the DAM Domain Model. Example of complex datatypes are the DaFault, DaError and the DaFailure that map respectively the Fault, Error and Failure conceptual classes. Each datatype shows, as properties, the attributes of the conceptual classes. On the other hand, the basic dataypes are simply enumerative types (defining frequencies, failure detectability, etc.) or valued types (Figure3.10)

Chapter 3. Languages for modeling critical systems: MARTE and DAM 48

An integrated methodology for

quantitative analysis of Critical

Systems

Chapter 4

A Model-Driven Approach for

Quantitative Analysis

This chapter has the objective to describe the steps necessary to move towards a Model- Driven approach for quantitative analysis of critical systems. The proposed approach integrate the formal Model-Based analysis (i.e. quantitative analysis performed with a formal modeling approach) with the benefits given by Model-Driven which support automatic generation of formal models starting from an high-level description of the system. In detail the approach combines the three different techniques described in Sec- tion 1.3, in order to exploit the benefits brought by each of them: divide-and-conquer, multi-formalism/multi-paradigm and automatic generation. According to Model-Driven paradigm (Chapter 2), the system under analysis can be described by using high-level specifications expressed in Domain Specific Modeling Languages (DSMLs), automatic transformation chains are able to generate formal models. Note that, also if used some- times as interchangeable, there is a slight difference between DSL and DSML: the second specifically addresses modeling languages, while the first is a more general concept and can be applied, for example, also to programming languages.

The proposed methodology is implementable into cost-effective processes in order to re- duce time-to-market, specifically during the verification stages of development lifecycles. The definition of DSMLs and model transformations can not be a handcrafted discipline, but must be ruled by mechanisms and techniques with the aim of improving reuse. The originality of the proposed approach is in combining the three main research trends, previously listed, in a comprehensive methodology based on Model-Driven principles and that are able to generate single or multi-formalism, and component-based formal models by means of transformational techniques. This approach follows and deepens what described in [52], adding new details and shades, coming from the application of

the methodology to real-world systems of different applicative domain, as it will be de- scribed in PartIII. The main innovation resides in the extension of horizontal languages with vertical one; furthermore new high-level modeling languages have been defined (Chapter5) as well as new formal operators and techniques (Chapter 6). Next sections show the proposed approach and its application to a first simple application domain.

4.1

Description of the approach

In this Section the proposed approach is described. Figure 4.1 depicts the conceptual schema behind the approach; it is a three stages approach in order to combine hetero- geneity, compositionality and automatic generation of formal modeling.

High Level

stage

Formal

stage

Multi-Formal

stage

Figure 4.1: Conceptual schema of the methodology

The stages are described in a top-down manner. The first stage (high-level stage) covers all phases of high-level modeling of the system and its requirements. In order to establish an automated method, it is necessary that all models comply with languages whose syntax has been formally defined. At this stage, the creation of high-level models requires the use of a DSML that can be eventually defined from existing ones and/or using the UML profiling technique. The definition of the DSML requires that language engineers carefully analyze considered domain aspects in order to define and realize a proper meta- model; system modelers shall use the defined DSML and create a model of the system under analysis by specifying peculiar characteristics (properly integrated into the DSML itself).

At the second stage (formal stage) several formal models can be automatically generated on the basis of the high-level one: each of the generated models can be expressed in a different formal language. In this context “formal” means that these languages are based on strong mathematical bases (both combinatorial and state-based formalisms).

Chapter 4. A Model-Driven Approach for Quantitative Analysis 52

Examples of formalisms that can be used at this stage range from combinatorial to state- based: Fault Tree, Queuing Networks, Process Algebras, Petri Nets and their extensions. The choice of the language depends on the specific characteristics of the system, and on the type of the requirements whose fulfillment has to be verified through formal modeling.

At the third stage (multi-formal stage) single-formalism models are composed in order to create a multi-formal model of the entire system. If quantitative analysis can be performed using a single-formalism model, then the third stage is not necessary. The multi-formal stage is instead necessary for quantitative analysis that require an overall and multi-aspect model of the system, in this case a single-formalism model can not be sufficient to allow the required analysis. The importance of having a multi-formal approach makes possible to have an unique model of the overall system, which expresses its peculiar aspects by choosing the best fitting formalism. This level allows not only a multi-formal description of the system, but also the definition of a model solution process that is able to analyze efficiently each sub-model with the most appropriate solver and aggregates the results in an appropriate manner (as performed by the Os- MoSys framework). The relationships among high-level model subparts are mapped into compositionality operators, which define the rules of passing parameters and/or results between models.

Model-to-model (M2M) transformations allow the generation of models from others. In this approach the following kinds of M2M transformations are defined:

• Level 1 M2M transformations: they are used to generate formal models from high- level specifications, allowing to pass from the first to the second modeling stage. • Level 2 M2M transformations: they are used to perform translations between

formal models inside the second stage. Such passage is often desirable in order to simplify the final multi-formal model and therefore the solution process (e.g. FTs can be expressed through SANs). It is important to clarify that this transformation passage is optional, not strictly required by the approach.

• Level 3 M2M transformations: they generate a multi-formal model by adding compositional operators among the models produced at the second stage. In order to accomplish to this purpose, these transformations have as inputs both formal models and the high-level model developed at the first stage, since some required information may not have been translated into the second stage models.

At the end additional Model-to-Text (M2T) transformations can be used to transform both single and multi-formal models (those belonging to second and third stage) into

the specific syntax of the analysis solver: as an example SAN models can be transformed into the concrete syntax of the M¨obius tool, i.e. into a set of XML files, written in the concrete syntax understood by the tool.