[PDF] JFLA 2021 - 32 èmes Journées Francophones des Langages

View - Download JFLA 2021 - 32 èmes Journées Francophones des Langages

Previous PDF

Next PDF

Event-B formalization of a variability-aware component model patterns framework 1

Jean-Paul Bodeveix

b,a, Arnaud Dieumegardc,d, Mamoun Filalib,e a

UPS - 118 Route de Narbonne, F-31062 Toulouse

bIRIT - 118 Route de Narbonne, F-31062 Toulouse cONERA, 2 Avenue Edouard Belin, F-31055 Toulouse dIRT Saint Exupéry, 3 Rue Tarfaya, F-31400 Toulouse eCNRS - 118 Route de Narbonne, F-31062 ToulouseAbstract Inthedomainofmodel-drivenengineering,patternshaveemergedasaubiquitousstructuringmechanism. Patterns

are used for instance at the requirement analysis level, during system design, and during the deployment and code

generation phases.

We focus on formalizing the operational semantics of pattern application on component-based system designs.

More precisely, our ultimate goal is to provide a semantic framework to support the use of patterns for the production

ofcorrect-by-constructionarchitectures, i.e., thestructural(static)correctnessofthearchitecturesobtainedthroughthe

formal application of patterns. To that end, we propose an Event-B framework for patterns specification, instantiation

and application. This model is built incrementally through horizontal refinements which introduce components, ports,

and connectors. Patterns with variability are defined, instantiated and can be applied to user models. We show that

these operations preserve the structural properties of hierarchical component models.

Keywords:Design patterns, formal refinement, variability, system engineering, critical systems1. Introduction

In the domain of model-driven engineering, patterns have emerged as an ubiquitous structuring mechanism. Pat-

terns are used for instance to express and structure requirements and to ease their analysis [Car15]. During the process

production homogeneity. Patterns may take various forms and are specifically structured: textual patterns expressed

as sentences, structural patterns for describing components combinations, code patterns for code generation.

The work we present here results from exchanges with safety system engineers who practice patterns for solving

identified safety issues. Their application of patterns produce refined system architectures taking into account safety-

specific concerns. In this context, we focus on automatically instantiated safety refinement patterns. The patterns we

rely on are based on the ones detailed in [PKK15].

We are interested in making the use of such a notion in the system development process precise. Our ultimate goal

is to build environments that support correct-by-construction component-based architecture transformations, i.e., the

structural correctness of the architectures obtained through the application of patterns. For this purpose, we show that

the transformed model satisfies well-formedness properties such as: component inclusion relation is acyclic, links be-

tween two components do not cross other components boundaries, modelling elements of the transformed architecture

model only come from source models and pattern models. For this purpose, we propose to use Event-B as the support1

This work was initiated while working on the MOISE project at IRT Saint Exupery then continued with the support of ONERA

Email addresses:first.last@irit.fr(Jean-Paul Bodeveix),first.last@enseeiht.fr(Arnaud Dieumegard), first.last@irit.fr(Mamoun Filali)

Preprint submitted to ElsevierJanuary 5, 2021

platform to define the notion of hierarchical component. This Event-B model is built incrementally through horizon-

tal refinements which introduce components, ports and connectors. Next, refinement defines patterns variability and

their instantiation by fixing variable elements. Last, we define pattern application on user models. We show that this

transformation preserves the structural properties of the component model. We remark that Event-B is mainly used to

assess the correctness of pattern instantiation and application.

Achieving the production of structurally correct component models may be reached using different approaches.

Thetranslation validationapproach [PSS98] consists in verifying each individual translation, whereastransformation

verification[BL09] consists in verifying the generator itself once and for all. In this paper, we adopt the transformation

verification approach. The specification of the transformation and its verification are done incrementally through

successive refinements, as supported by the Event-B method [Abr10].

Section 2 motivates our proposal by means of a small case study, and presents our pattern model. In Section 3, we

describehowpatternsareappliedtocomponentmodels. Section4brieflypresentsEvent-Banditsset-basednotations.

Section 5 introduces our formal modeling framework based on Event-B. Section 6 details within this formal setting

the steps followed to apply a pattern to a model. Section 7 provides insights on our prototype tool. Section 8 discusses

some related work. Section 9 concludes and suggests some future work.

This paper is an extension of work originally presented at the FACS 2018 conference. Compared with [BDF18a],

•New examples of component-related pattern application (voter, recovery block pattern) and link-related patterns

(monitor-actuator) are provided.

•The proof of the preservation of the acyclicity of the sub-component relation by pattern application is detailed.

Also, a variant expression justifies the termination of sub-component unfolding.

•The prototype Caml tool is presented together with raw text-based encoding of models as processed by the tool.

•We provide the component/pattern metamodel on which our Sirius [VMP14] editor is based.

2. Motivating example

We describe here an example that will be used first to clarify what we mean by a pattern and by pattern application.

Section 2.1 features a very simple component model. We then showcase the transformation of this model to replicate

one of its components. Focus will be on the N-Version programming pattern as described in [Arm10] or [PKK15].

This pattern is proposed in the context of architecture safety to enhance system robustness. We detail its structure and

content, the solution that is provided by the application of such a pattern, and its complexity from the scope of its

variability.

2.1. Component models

Inourwork, weconsiderhierarchicalcomponentmodelsasanabstractionoftheclassical"boxesandarrows"mod- eling formalism used to model: systems as for example Capella [SVV +16], SysML [OMG12] or AADL [FG12]; soft- ware as for example BIP [BBB +11], UML [RJB04], Scade [ADS+06]; or hardware as for example VHDL [HGW00].

In each of these formalisms, components are connected through arrows (and sometimes ports or interfaces).

We provide in Fig. 1 an example of a very simple component model. This model features thesc1component with

two input ports and one output port connected tosc2through the linkl3. In addition to the structural description of

our simple model, we have attached to thesc1component one comment (square box) representing the association of

a component with its specification, its verification or its validation artifacts or any other information of interest related

to the component.

2.2. Replicating a component

In the use case depicted in this paper, we propose to take the example that some analysis of the system leads to the

need to provide different implementations of thesc1component to make the system fault tolerant. This mechanism

is in this context referred to as a replication of a component.

An example of our simple system where thesc1component has been replicated is provided in Fig. 2. In this

new version of the model, we have three versions (comp_X) (XË ^1;2;3`) whose inputs are taken from the original

2

Figure 1: A simple component model

inputs of thesc1component and dispatched using specific duplication (split_Y) (YË ^1;2`) components whose

purpose isto replicate theirinputs on eachone of theiroutputs (the specificationof thesecomponentsis providedin the

split speccomments). Then, the outputs of the replicatedcomp_Xcomponents are connected to a new component

(vote_1) in charge of taking the decision of which one of thecomp_Xcomponent output shall be relied on and sent to

the outputs of the originalsc1component.Figure 2: A component model where a component is replicated three times

of thesc1component is the same), but also duplicates elements of the original model (the newcomp_Xcomponents)

and introduces new elements such as replication constraints (Diverse implementation of comp_1, comp_2,

comp_3), and component specifications (vote spec, andsplit spec).

2.3. Implementing a link

We complement the previous example with an example where the analysis of the system leads to the need to

make more safe a link between components. In this context we provide a possible solution in the shape of additional

3

components implementing monitoring on the link between componentssc1andsc2. Figure 3 provides an example

of such an implementation of a link. The idea here is to replace the link with two components (Monitoring_1and

Actuation_1) implementing the monitoring of the value carried by the link and the modification of the value carried

by the link to a failsafe value when monitoring detects a problem on the value.Figure 3: A component model where a link has been implemented

Once again, implementing a link this way preserves the original structure of the model and integrates additional

elements in the model (new components and specification information).

2.4. Pattern model

The previously depicted model transformations are considered in our setting as an example of the application of

a design pattern. The model of Fig. 1 is the source model, and the model of Fig. 2 is the target or destination model

where the pattern has been applied. What remains to be defined is what is the model of the pattern itself.

Many design pattern description formats have been defined in the literature. We decided to rely on the classical

patterndescriptionformatproposedbyCoplien[Cop96]. Thiscomprisesmanyinformationamongwhicharethename

of the pattern, its context of use and the problem solved by the pattern, the strength and weaknesses of the pattern, a

graphicalmodelrepresentationandmuchadditionalinformation. WealsorelyontheworkofPreschernetal.[PKK15]

where a set of architectural safety patterns are proposed for high level architecture definition. These patterns are

connected to IEC 61508 standard methods for achieving safety and are extended with formal argumentation models.

An example of such a pattern is provided in Fig. 4.Figure 4: N-Version Programming pattern extract from [PKK15]

4

While this representation of a pattern is very interesting, it is nevertheless restricted to its structural description. It

maybeinterestingtoexplicitlyexpresstheparametersofthepatternanditsvariability. InthecontextoftheN-Version

Programmingpattern,Nis a parameter meaning the number of times the software is developed. This parameter also

impacts the implementation of the voting algorithm (voteblock). In addition to these, the links between the blocks

described in theSolutionsection of Fig. 4 are a simplification of the actual possible links between blocks as there

may be multiple links between these blocks: theNversions of the block all have the same number of inputs and

outputs. Both of these numbers are also parameters of the pattern that shall be made explicit. We thus propose an

extension of this model representation of patterns where these parameters are made explicit.

Fig. 5 is our proposal for an alternative graphical representation of the N-Version programming pattern model. In

this model, we rely on structural elements like components, ports, and links between components through ports, and

multiplicityobjects attached to components and ports.multiplicitymarkers are attached to components and

ports. They appear inside brackets in the figure. In this pattern model, four different multiplicity elements are defined:

nb_comp,nb_in,nb_out, andnb_vin. They respectively stand for the number of times the component is replicated,

the number of input and output ports of the replicated component, and the number of inputs of thevotecomponent.Figure 5: The N-Version programming pattern model

By selecting the model element to be replicated (sc1in Fig. 1), themultiplicitymarkersnb_inandnb_out

are set respectively to two and one. The user shall then provide the value fornb_compwhich is set to 3 in this case.

Based on the user selection and provided values, the pattern model is instantiated: 1) its root component will have two

input ports and one output port; 2) the root component of the pattern will be renamed assc1; 3) thecompcomponent

will be replicatednb_comptimes as copies of thesc1component withnb_ininput ports andnb_outoutput ports;

4) thesplitcomponent will be instantiatednb_intimes with one input port andnb_compoutput ports; 5) the

votecomponent will be instantiated withnb_compinput ports andnb_outoutput ports (here one); 6) links between

components are elaborated depending on their connection pattern (detailed in the following section); Here, we use the

Transposepattern (writtenTransin figures) to connect portiof componentjto portjof componenti; in the same

way, theFlatCpattern connects all the ports ofcompreplicates to distinct ports of thevotecomponent:nb_vinis

constrained to benb_compnb_out. 7) finally, the originalsc1model element is replaced with the newly produced

sc1component and its content. Fig. 6 shows two instances of ourN-Version-Programmingpattern, the first one

withnb_in=2,nb_out=1,nb_comp=3 and the second one withnb_in=2,nb_out=2,nb_comp=3.

Fig. 8 is our proposal for an alternative graphical representation of the Monitor/Actuator pattern model provided in

Fig.7 which introduces a monitor to check the result computed by the main component and sends it a shutdown signal(a)(b)

Figure 6: (a) shows a first instance of the pattern. (b) shows a second instance5

in case an error is detected. This model of the pattern is simpler than the previous one as onlyIdentitylinks (Ident

in the figure) are used to connect a single port of a single source and a single target component and all multiplies have

have the default value (1).Figure 7: Monitor actuator pattern extract from [PKK15]

Figure 8: The Monitor-Actuator pattern model

In our setting, a pattern model is thus a family (in the product line [KCH +90] terminology) of models. Each

combination of multiplicities allows for the definition of apattern instance. The production of design pattern instances

and the application of the produced pattern instance on a model element shall thus be implemented for components

and links.

The purpose of the Event-B model proposed in this paper is first to formally define the previously presented struc-

ture of a pattern, and second to propose a formal definition of the pattern instantiation and application algorithms. We

provide the formalization of pattern instantiation and pattern application algorithms for patterns applied on compo-

nents and keep the formalization of the application on links as future work. We have also represented the structure

of component models and its extension for pattern models, and mappings between model and pattern as Ecore

2meta-

models that is a de-facto standard formalism for the specification of graph grammars

3. This second formalization is2

https://www.eclipse.org/modeling/emf/

3Unlike abstract syntax which usually describe trees.

6

used to easily produce tools for the creation, modification, and visualization of model instances used throughout this

paper. We detail these elements in Section 7.

3. Pattern application

The aim of this section is to give an overview of the different steps of pattern instantiation and application. Our

starting point is a parameterized pattern of which parameters are the multiplicities attached to pattern elements (com-

ponents and ports) and the model elements on which the pattern is applied. We distinguish three steps for pattern

application: initialization, elaboration, and application of patterns as depicted in Fig. 9.pattern initializationpattern instance elaborationpattern instance applicationFigure 9: Pattern application process Figure 10: N-Version Programming pattern (Fig. 5) mapped to a component of the source model (Fig. 1)

3.1. Pattern initialization

During the initialization step, some of the pattern parameters are set and the root component of the pattern is

identified. Patterns are parameterized by the multiplicity of their components and ports. These parameters must be

fixed to create the pattern instance that will be applied to the model.

Parameters of the pattern interface are defined through the mapping of pattern elements to the elements of the

model on which the pattern is applied. Figures 10 and 11 are the respective mappings of the application of the

N-Version programmingand theMonitor/Actuatorpatterns on the source model of Fig. 1. Note that some

mapping information can be synthesized as for example the mapping of ports given the mapping of links. Hence they

are not represented in Fig. 11.

Mappings constrain the multiplicity of some parameters of the pattern. In Fig. 10 the value of thenb_inparameter

is set to the value 2 based on the mapping of the pattern input port (NVerProg.i) to two distinct ports of the model

(system.i1andsystem.i2). Parameternb_outis set to 1 based on the mapping of the output port of the pattern.

The value of thenb_vinparameter is computed during the elaboration phase (see section 3.2).

Finally, thenb_compmultiplicity remains to be set by the user as it cannot be computed solely using mapping

information. 7 Figure 11: Monitor/Actuator pattern (Fig. 8) mapped to a link of the source model (Fig. 1)

3.2. Pattern instance elaborationsm

sm qtm tm pFigure 12: Pattern link The goal of the second step is to "elaborate" the pattern. This elaboration leads to a pattern instance where multiplicities have been suppressed and which can be directly applied to a given model. The elaboration of a pattern is a complex operation since its unfolding can be considered as recursive along two dimensions: horizontally due to the multiplicities and vertically due to the nesting of components. This leads to the fact that the number of instances of a sub-component is the product of the multiplicities of all its ancestors including itself. When a component is replicated, its contained ports are also replicated.

Links between ports are unfolded depending on their semantics which specify how the multiple instances of the

source and destination port in the pattern should be connected. It is illustrated in Fig. 12 where componentssand

quotesdbs_dbs22.pdfusesText_28

[PDF] L 'AGROSYSTEME :

[PDF] electrostatique

[PDF] Biographie d Ahmed Sefruoui Né en 1915 ? Fès, Ahmed Sefrioui est

[PDF] Aïcha, la passion du Prophète de l islam

[PDF] Aide ? l 'habillage et le déshabillage adulte

[PDF] Aide ? l habillage et le déshabillage adulte

[PDF] Aide ? l habillage et le déshabillage adulte

[PDF] Ménage Dax, garde d 'enfants, aide ? domicile - Vivaservices

[PDF] Liste des Services d 'Aide et d 'Accompagnement ? Domicile en

[PDF] Demande de subvention pour l achat d un ordinateur portable

[PDF] La réglementation des aides financières aux familles - Caf

[PDF] Aides aux étudiants - Université de Reims Champagne-Ardenne

[PDF] Les aides financières d 'action sociale - Caf

[PDF] reglement regional pour l 'attribution et le versement des aides a l

[PDF] Guide des aides ? l 'apprentissage