LABORATOIRE
INFORMATIQUE, SIGNAUX ET SYSTÈMES DE SOPHIA ANTIPOLIS UMR 6070
C OLLABORATIVE M ODELING FOR I NTEGRATING S ECURITY P ROPERTIES ON A M EDICAL S HARING A PPLICATION Clémentine NEMO, Mireille BLAY-FORNARINO Equipe M ODALIS Rapport de recherche ISRN I3S/RR–2009-09–FR Juillet 2009
Laboratoire d’Informatique de Signaux et Systèmes de Sophia Antipolis - UNSA-CNRS 2000, rte.des Lucioles – Les Algorithmes – Bât Euclide B – B.P. 121 – 06903 Sophia-Antipolis Cedex – France Tél.: 33 (0)4 92 94 27 01 – Fax: 33 (0)4 92 94 28 98 – www.i3s.unice.fr UMR6070
I3S / CNRS - UNIVERSITE NICE - SOPHIA ANTIPOLIS
Collaborative Modeling for Integrating Security Properties on a Medical Sharing Application Research Report
Clementine NEMO, Mireille BLAY-FORNARINO Equipe MODALIS Juillet 2009
This technical report details the impact of manual integration of concerns in models. It is a preliminary work to automate the concerns integration on models.
Thanks We thank the students which work on profile modeling: Stephane Dupin, Yoann Ligavant, Rose Nerrière, Xin Zhao. We thank also Alban Gaignard to help us in the NeuroLOG middleware and security concerns understanding.
2
Table of Content 1.
2.
Context .................................................................................................................................... 5 1.1
Industrial and Scientific interests ........................................................................................ 5
1.2
NeuroLOG data sharing application (guiding example) ...................................................... 6 Initial Existing Models.............................................................................................................. 7
2.1 Context Model ........................................................................................................................ 7 2.2 Image Insertion ....................................................................................................................... 8 2.3 Tools Invocation .................................................................................................................... 10 2.4 Our Approach to Design Security Concerns .......................................................................... 13 3.
Identification Integration ...................................................................................................... 14 3.1 Presentation of the Profile.................................................................................................... 14 3.2 Constraints ............................................................................................................................ 14 3.3 Applying Profile ..................................................................................................................... 15 3.4 Toward Actions ..................................................................................................................... 18 3.5 Performances ........................................................................................................................ 18
4.
Access Control List (ACL) Integration .................................................................................... 19 4.1 Presentation of the Profile.................................................................................................... 19 4.2 Constraint.............................................................................................................................. 20 4.3 Applying Profile ..................................................................................................................... 20 4.4 Toward Actions ..................................................................................................................... 24 4.5 Performances ........................................................................................................................ 24
5.
Authentication Integration .................................................................................................... 24 5.1 Presentation of the Profile.................................................................................................... 24 5.2 Constraints ............................................................................................................................ 25 5.3 Applying Profile ..................................................................................................................... 25 5.4 Toward Actions ..................................................................................................................... 28 5.5 Performances ........................................................................................................................ 29
6.
Data Encryption Integration .................................................................................................. 29 6.1 Presentation of the Generic Solution ................................................................................... 29 6.2 Constraints ............................................................................................................................ 30 6.3 Applying Profile ..................................................................................................................... 30 6.4 Toward Actions ..................................................................................................................... 32 6.5 Performances ........................................................................................................................ 33
7.
Trace Integration ................................................................................................................... 33 3
7.1 Presentation of the Profile.................................................................................................... 33 7.2 Constraints ............................................................................................................................ 34 7.3 Applying Profile ..................................................................................................................... 34 7.4 Toward Actions ..................................................................................................................... 35 7.5 Performances ........................................................................................................................ 35 8.
Merge of the Concerns .......................................................................................................... 36 8.1 Comments ............................................................................................................................. 36 8.3 Performance Visualizations .................................................................................................. 36 8.3 Applying Profile ..................................................................................................................... 37
9.
Conclusion & Perspectives .................................................................................................... 41
10.
Illustration List ....................................................................................................................... 44
11.
Bibliography........................................................................................................................... 45
4
1. Context The UML is the de facto standard for system specification. But how does it support the specification, analysis and integration of concerns? In this technical report, we study (1) the definition of concerns as UML profile, (2) the changes and the cost needed to integrate such concerns, (3) the constraints that a system must verify to satisfy concerns specification. The aim is to extrapolate mechanisms for automating concern intergation. The approach is exemplified with “security” concern (access controls, role based controls, encrypting …) and their integration in the architecture deployed for the NeuroLOG project [8] (cf. Section 1.2 ). This report is organized as follows. This section specifies the context of this work and the application we use as example. Section 2 gives an overview of NeuroLOG base use cases and their modeling in UML. Sections 3 to 7 describe respectively identification, access control, authentication, data encryption and trace policies integrations. Section 8 explains how these concerns could be integrated in a unified model. Finally section 9 wraps up with conclusions and future work.
1.1 Industrial and Scientific interests Policy based management of software applications has been subject to increased attention, and several frameworks have been introduced for the purpose of concern specification and enforcement. In [1] authors define a concern as “a set of rules governing the choices in the behavior of a system”. A system adheres to a concern if it satisfies rules defining this policy. As an example consider the permission rule access stating that users are allowed to access to data only after a valid login. To satisfy such a concern the architecture of the application is modified introducing new elements to check login and changing behavior of elements supporting data access. The system adheres to this concern if all components accessing to data are secured. We focus on the impacts of concern introducing at the architectural level. Software engineering promotes the application of a systematic, disciplined, quantifiable approach to the development. In particular, software design plays an important role in developing software allowing software engineers to produce various models that constitutes a blueprint of the solution to be implemented [12]. The model driven engineering (MDE) approach [3] goes further producing models or codes from business models. To fulfill the various requirements of an application, different facets (concerns) of a software design must be described to show specific properties of a software system. Patterns and aspects are well known paradigms to deal with several points of view on architecture and to capitalize on recurrent solutions to common problem [4][6]. These approaches are a way to minimize design complexity when building more complex architectures, automate reliable applications and accelerate development time. According to users’ specifications and reuse of concerns the models are validated and applications generated. It avoids the repetitive tasks, the simulation techniques (moreover expansive and difficult to deploy on large software) and supports the detection of conflicts early in the development process. Even if a lot of works deals with automatic integration of concerns, they do not take into consideration the overlapping between the concerns integrations and the automatic restoration of the models validity. We aim to construct a system of automatic multiple integrations of concerns and automatic restoration of validity. Previously we need to evaluate the impact of manual integration. Objective: In this technical report, we evaluate the impact of manual integration of concern (based on management of data accesses) in a model.Our approach formalizes the definition of concerns by UML profiles, analyzes the application of profiles on models and evaluates the genericity of the solutions. 5
1.2 NeuroLOG data sharing application (guiding example) The management of data access is a crucial point in distributed systems. Data items are shared between different sites according to distribution policies, which have to be common or not between the sites. Our examples come from the NeuroLOG project which addresses secure data sharing in the medical domain [8].The NeuroLOG middleware targets the secure integration of distributed data management tools (including metadata and semantic data) and image processing tools for addressing neurosciences requirements. The software will be deployed on collaborative sites. On each site, users are registered and an administrator has specific administration rights as described in the NeuroLOG Security Policy document1. The two main actors in the system are thus the site administrator, maintaining and deploying data and services; the researchers (users), performing local or remote operations implying local or remote data. In this technical report, we focus on five required concerns: • •
• • •
1
Identification: the system requires knowing all the users. For example in the NeuroLOG middleware all accesses to servers have to be identified (section 3). Access Control List (ACL) of user roles: the system manages data accesses according to user groups. For example, in the NeuroLOG middleware a group is created and managed by one site but users from other sites may be registered into it. Site administrators may decide which data shore on their site is accessible to which group (section ). Authentication: the system requires certificate users. It allows authenticating the users in a distributed system. For example in the NeuroLOG middleware all system users are authenticated through non-repudiable nominative X509 certificates (section 5). Data encryption: the system requires sharing encrypted data. For example in the NeuroLOG middleware, data is encrypted on the data base by the user and decrypted by the server (section 6). Trace: the system requires tracing accesses to data. For example in the NeuroLOG middleware, accesses to local data are traced individually in a non repudiable manner on each site (section 7).
http://neurolog.polytech.unice.fr
6
2. Initial Existing Models Our approach integrates different security concerns on models. These models are defined according to the NeuroLOG policy document. We choose to design three initial models focusing on the relations between a client (a user on a collaborative site) and a server (a neuroLOG server of the collaborative site). These models do not consider any security aspect. The first model describes the base architecture. The following models present two practical use cases. The first one explains how a user can insert new medical images within the system; the second one explains how data can be processed through invocations tools [5].
2.1 Context Model The model in Figure 1 depicts the communication between a client (ClientWeb) and a server (NeurologServer) in a general context. The client accesses to the database through the server by the operations view, add and delete of the Store interface. The server handles the request and transmits it to the LocalStorageRessourceService through the LocalStore interface. Besides, another functionality depicted on this model is the communication between the different NeuroLOG servers through the GlobalRegistry. Indeed, the client can access to remote sites through the server as long as they are registered in the GlobalRegistry (Figure 2).
Figure 1 Initial Context Model
7
Figure 2 Sequence Diagram of Initial Context
2.2 Image Insertion The model in Figure 3 depicts the relations between the client (DICOMClient) and the local data base (LocalStorageRessourceRegistry) when inserting new medical images (DICOM)2 within the system. We specify the insertion of new data by the client in the sequence diagram Figure 4.
2
Digital Imaging and COmmunications in Medicine
8
Figure 3 Image Insertion
The NeurologServer receives a data insertion request by the DICOMClient and starts a transaction. It consists in two independent activities: (1) obtaining a unique identifier for data to insert, and (2) realizing the storage supported by the grid or file controller (LocalStorageRessourceService), it depends on the kind of data insertion request. Then if everything is successful, the data manager (MetadataManager) updates the meta-data with location and file access information and finally the transaction is committed. The server then inserts meta-data in the system. If the meta-data insertion fails, the previous transaction is reverted with a roll-back mechanism, otherwise, the server notifies the client of data acceptance.
9
Figure 4 Sequence Diagram of Image Insertion
2.3 Tools Invocation The next model (Figure 5) depicts the construction and the submission of a job. The client (ToolInvocationClient) chooses the tools to apply on an image through the JobBuilder interface, which offers a choice of tools depending on the image type. The client submits the request to the server (NeurologServer). It transmits the request to the ToolInvocationManager which dispatches the processing to the different sites (locally, or on another site, or on the grid). We specify the process in the sequence diagram Figure 6.
10
Figure 5 Tools Invocation
11
Figure 6 Sequence Diagram of Tool Invocation
12
2.4 Our Approach to Design Security Concerns The requirement of data protection from unauthorized user access is as old as multi-user computing. Several architectural patterns have been defined to deal with these concerns. When composing these concerns, interactions often arise causing a variety of issues. Some development tools support design pattern integration [11] but not support the interaction detection. We investigate such interactions through this case study in order to define tools supporting detection and solving of such conflicts. We propose here to do manually the same thing for architectural patterns modeling security concerns in order to evaluate the problems we must solve when automatically composing them. To design architectural patterns using standard tools, we choose to express them using the UML profile formalism and to apply these profiles on the models defined in this section. In the following sessions, we deal with each concern as follows: •
•
•
Profile definition : o
In the following profile diagrams, the blue stereotypes represent stereotypes already included in the system. In this case the profile does not define it, but only references it. The red stereotypes of the profile represent the required elements. These elements have to be bound to the model on which the profile will be applied. This binding is defined by the integrator actor.
o
After each profile presentation, we explain the constraints included in the profile. Our aim is to underline elements that should be invariant whatever changes are operated.
Applying Profile : o
We illustrate the concerns integration applying profile on the initial models developed in this section 2.
o
We apply each profile on three models to underline the actions composing the profile application.
Actions extrapolation: o
•
We detail the actions to update the initial model and obtain the resulting model after applying the profile.
Performance: o
When applying profile, several changes must be made. We count the number of elements created or changed in the model resulting of the profile integration. In this way, we can evaluate the “cost/performance” of manually integrating concerns using the following metrics: -
number of created elements (Ec) including references and attributes
-
number of added stereotypes (Es)
-
number of modified elements (Em) (adding references, attributes or operations, not including adding of stereotypes)
-
maximum depth of modified elements (d)
Finally, in section 8, we integrate all the concerns on models and analyze the merge actions to construct the new models.
13
3. Identification Integration The identification concern aims to limit the accesses to a middleware only by identified users.
3.1 Presentation of the Profile The UML Profile (Figure 7) defines by the required stereotype the architectural structure of the concern. We note the definition of a stereotype which allows identifying the through and operations and checking the through operation. The corresponds to an entry point for this concern.
Figure 7 - Identification Profile
3.2 Constraints We name constraints, properties which have to be verified on the model resulting of the profile application. 14
We name structural constraints, the constraints which express the references between stereotyped elements. They are expressed in the profile diagram by links and multiplicity. A reference between two stereotypes
and in a profile diagram means a reference between all the elements stereotyped and . For instance, each interface is associated to an only component.
Other constraints must be satisfied when applying this profile. They are detailed literally in the corresponding stereotype definition. We note that is possible to formalize them with an appropriate language like OCL. For this profile : • • •
All exposed interfaces of are . All component requiring interfaces are . All operations of all interfaces take parameter.
3.3 Applying Profile Applying the identification profile on the initial existing models (section 3) means to modify them. The resulting models satisfy the constraints detailed section in 3.2. The orange element denotes the required element indicated by the integrator to apply the profile. The NeurologServer is stereotyped .
Figure 8 Initial Context Model Updating by the Identification Profile Integration
15
16
Figure 9 Image Insertion Model Updating by Identification Profile Integration
17
Figure 10 Tool Invocation Model Updating by Identification Profile Integration
3.4 Toward Actions From the binding of one element (here NeurologServer stereotyped ) we deduce all the actions to compute on the model to integrate the profile. We literally explain the process to understand the logic of the automation. • • • • •
From the all the exposed interfaces are stereotyped . The parameter is created. From all their operations take as input parameter. From the all the component requiring them is stereotyped . The component, and interfaces, and operations, parameter, and the references between them are created. The name of the interfaces and components are build using a same prefix3.
3.5 Performances In the three examples, the bound element is NeurologServer. From it we can calculate the number of created or modified elements and the addition of stereotypes on elements. We can generalize these counts. The formulas are expressing, in all models, the modifications induced by the application of the identification profile. They are an expression of the genericity of the profile from the bound element. For the identification profile:
3
Neurolog is the prefix used in our example. However users fail naming one component with a non “generic” name. Automating profile integration should clarify the resulting models.
18
•
Number of created elements: Ec = 22 + 3c + o (22 represents the number of elements always created by the profile application : component, interface, interface, operation, operation, parameter, the references between them …)
•
Number of added stereotypes: Es = 9 + i +c
•
Number of modified elements : Em = o + 3c + 2 (to each client are added two attributes and one reference and to each operation is added a parameter and one reference is added to e)
•
Depth of modified elements from e : d = 3 (clients of exposed interface are now linked to an identification component) • • • •
e the element stereotyped i the number of exposed interfaces of e o the number of operations in i c the number of component requiring the exposed interfaces of e
4. Access Control List (ACL) Integration Access Control Lists (ACL) concern specifies rules definitions in order to enable or disable access to a set of operations. This concern needs to identify user. It is built on top of the identification profile (Section 3), reusing the structure and the stereotypes. Access rights in this model do not adhere to single users but are associated to roles and each role is associated to a set of permissions. We do not develop this aspect of the pattern in this section because we focus on the impacts on the architecture. For more information on modeling RBAC pattern see [7] [2].
4.1 Presentation of the Profile The UML Profile (Figure 7) defines by the required stereotype the architectural structure of the ACL concern. The structure and the constraints repeat the identification profile and add stereotypes to manage and check users’ rules. More precisely the allows the to check the context through the interface. The exposes the interface with the operation to check the users’ rules from the .
19
Figure 11 Access Control List Profile
4.2 Constraint Structural constraints are expressed by the ACL profile and other constraints are the same as the identification profile.
4.3 Applying Profile The integrator chooses to apply access control to the NeurologServer. The NeurologServer is stereotyped .
20
Figure 12 Initial Context Model Updating by the ACL Profile Integration
21
Figure 13 Image Insertion Model Updating by the ACL Profile Integration
22
Figure 14 Tool Invocation Model Updating by the ACL Profile Integration
23
4.4 Toward Actions From the binding of one element (here NeurologServer stereotyped ) we deduce all the actions to compute on the model to integrate the profile. We literally explain the process to understand the logic of the automation. The first five points are the same as the actions of the identification profile. • • • • • • • • • • •
From the all the exposed interfaces are stereotyped . The parameter is created. From all their operations take as input parameter. From the all the component requiring them is stereotyped . The component, and interfaces, and operations, parameter and the references between them are created. The and its exposed interface are created. The requires interface. The interface and its operation are created. The exposes interface. The requires interface. The operation takes as input parameter and returns .
4.5 Performances In the three examples, the bound element is NeurologServer. From it we can calculate the number of created or modified elements and the addition of stereotypes on elements. We can generalize these counts. The formulas are expressing, in all models, the modifications induced by the application of the identification profile. They are an expression of the genericity of the profile from the bound element. For the authentication profile: •
Number of created Elements : Ec = 29 + 3c + o
•
Number of stereotypes added : Es = 13 + i +c
•
Number of modified elements : Em = o + 3c + 2
•
Depth of modified elements from e : d = 3 • • • •
e the element stereotyped i the number of exposed interfaces of e o the number of operations in i c the number of component requiring the exposed interfaces of e
5. Authentication Integration The authentication concern limits the access to a component (ie limits the use of the operations of its exposed interfaces) only by authenticated users. The trust in the user authenticity is given by a certificate authority.
5.1 Presentation of the Profile The UML Profile (Figure 15) defines by the required stereotype the architectural structure of the authentication profile. The represents the 24
component which all accesses have to be authenticated. The profile introduces a stereotype which delivers certificate through interface and controls the authentication through interface. The profile introduces a stereotype, corresponding to the signature of certificate request required to get the back.
Figure 15 Authentication Profile
5.2 Constraints The structural constraints are detailed by the authentication profile. The other constraints are: • • •
All exposed interfaces of are . All component requiring interfaces are . All operations of all interfaces take as input parameter.
5.3 Applying Profile The integrator chooses that all accesses to the NeurologServer have to be authenticated. The NeurologServer is also stereotyped .
25
Figure 16 Initial Context Model Updating by the Authentication Profile Integration
26
Figure 17 Image Insertion Model Updating by the Authentication Profile Integration
27
Figure 18 Tool Invocation Model Updating by the Authentication Profile Integration
5.4 Toward Actions From the binding of one element (here NeurologServer stereotyped ) we deduce all the actions to compute on the model to integrate the profile. We literally explain the process to understand the logic of the automation. • • • • •
From the all the exposed interfaces are stereotyped . The parameter is created. From all their operations take as input parameter. From the all the component requiring them is stereotyped . The component, and interfaces, and operation, and parameters and the references between them are created. 28
5.5 Performances •
Number of created Elements : Ec = 20 + c + o
•
Number of stereotypes added : Es = 9 + i +c
•
Number of modified elements : Em = o + c + 2
•
Depth of modified elements from e : d = 3 • • • •
e the element stereotyped i the number of exposed interfaces of e o the number of operations in i c the number of components requiring the exposed interfaces of e
6. Data Encryption Integration The data encryption concern allows the encryption of a parameter. Encryption is the process of transforming data using an algorithm to make it unreadable to anyone except those possessing special knowledge (private key for example). The result of the process is encrypted data. The reverse process, decryption makes the encrypted data readable again.
6.1 Presentation of the Generic Solution The UML Profile (Figure 19) defines the architectural structure of the data encryption profile. The required element is identified by the stereotype. The which uses operations with the as input through could encrypt the parameter with the operation. The which provides operations through could decrypt the parameter with the operation.
29
Figure 19 Data Encryption Profile
6.2 Constraints The structural constraints are detailed by the data encryption profile. The other constraints are: • • • •
All operations with as input are . All interfaces using a are . All components requiring are . All components exposing are .
6.3 Applying Profile We highlight the required element in orange in the following diagrams (Figure 20, Figure 21). Then Info is the element.
30
Figure 20 Initial Context Model Updating by the Data Encryption Profile Integration
31
Figure 21 Image Insertion Model Updating by the Data Encryption Profile Integration
6.4 Toward Actions From the binding of one element (here Info stereotyped ) we deduce all the actions to compute on the model to integrate the profile. We literally explain the process to understand the logic of the automation. • • • • • • • • •
From the all operations with this parameter as input are stereotyped . All interfaces with a are stereotyped . All components requiring are stereotyped . All components exposing are stereotyped . The component, and interfaces, and and references between them are created. The reference between and is created. The reference between and is created. The references between and all are created. The references between and all are created.
32
6.5 Performances •
Number of created Elements : Ec = 11 + dc + de
•
Number of stereotypes added : Es = 6 + o + i + dc + de
•
Number of modified elements : Em = dc + de
•
Depth of modified elements from e : d = 3 • • • • •
e the element stereotyped o the number of operations with an input parameter e i the number of interfaces with an operation with an input parameter e dc the number of component exposing i ec the number of component requiring i
We focus on only one parameter denoted as protected. Applying the same profile on a set of parameters will not create so many elements as several components can be shared.
7. Trace Integration The trace concern has to record every access to operations of a given interface.
7.1 Presentation of the Profile The UML Profile (Figure 22) defines, by the required stereotype, the architectural structure of the trace profile. The manages the operation in a log file corresponding to the actions executed in the interface. The traced elements in the log files are .
Figure 22 Trace Profile
33
7.2 Constraints The structural constraints are detailed by the trace profile. The other constraint is: •
All components exposing interface are
7.3 Applying Profile The integrator chooses that all accesses to the Store interface have to be traced. The Store interface is also stereotyped .
Figure 23 Initial Context Model Updating by the Trace Profile Integration
34
Figure 24 Image Insertion Model Updating by the Trace Profile Integration
7.4 Toward Actions From the binding of one element (here Store stereotyped ) we deduce all the actions to compute on the model to integrate the profile. We literally explain the process to understand the logic of the automation. • • •
From the interface all the components exposing this one are stereotyped . The component, interface, operation, parameter and references between them are created. The reference between all and interface are created.
7.5 Performances •
Number of created Elements : Ec = 8 + c
•
Number of stereotypes added : Es = 6 + c
•
Number of modified elements : Em = c
•
Depth of modified elements from e : d = 1 •
c the number of component exposing 35
8. Merge of the Concerns In this section we present the initial models of the section 2 updated by the applications of all the profiles presented in this technical report: identification, ACL, authentication, data encryption, trace.
8.1 Comments Before presenting the updated models, we make remarks on the multiple profiles applications. These remarks are a first way to construct the automation of the merge of the applications and to the detection of conflicts. •
•
•
We notice a profile hierarchy: the ACL profile is based on the identification profile. If the ACL profile is applied before the identification profile, the second application is useless. If the ACL profile is applied after the identification profile, the common stereotypes and elements are merged. An element is created only if it does not exist. The Store interface is and . This implies that all the operations of the Store interface have as input parameter a and a . It would be interesting to merge these two parameters, to include the in the . Dynamically the calls to the and the operations have to be ordered. Should the write an encrypted data or not?
8.3 Performance Visualizations From the performance formulas of profiles we count the number of created and modified elements on models resulting of multiple integrations. The visualization allows evaluating the effective changes of models and the impact of each profile’s integration on them (the diagrams depict just the performances on the initial context model). The quantification of manual integration concerns allows identifying the performance expected with an automatic integration tool.
Figure 25 Ratio of Created Elements by Concerns Integrations on the Initial Context Model
36
Figure 26 Ratio of Modified Elements by Concerns Integrations on the Initial Context Model
8.3 Applying Profile
37
Figure 27 Merge of Integration Concerns in Initial Context Model
38
Figure 28 Merge of Integration Concerns in Image Insertion Model
39
Figure 29 Merge of Integration Concerns in Tool Invocation Model
40
9. Conclusion & Perspectives In this technical report, we propose to model concerns by UML profiles. Profiles allow formulating the architectural structure of the concerns and constraints. From the required elements of a profile, we manually change the model to create a new model. This resulting model integrates the concern and satisfies all the constraints defined by the profile. The application on three models allows underlining the main actions composing the future automatic application of models. This preliminary work makes a first step to define action language to automate policy integration in models. Required Elements: The approach proposed for integrating concerns is based on binding of required elements. This approach has been developed by template and aspect-oriented design [13]. We will use these bindings to check if a system satisfies all the constraints required by policies. So we keep binding in memory after applying profiles. Performances: Our usage-driven approach of profile integration allows identifying the performances that we can expect from automating model generation. The determination of these metrics is one contribution of this report. We are working in the same way on evaluating the performance we can expect from automating “repairs” of models that no more satisfy constraints required by some policies. Metrics proposed to evaluate performance should be improved according to Model-Driven Measurement [9]. Profile Composition: Applying profile induces to create new elements: components, interfaces… Some of them are shared between profiles. Detecting these “mergeable” elements can be done using the name of the component in this example. Work on model compositions propose to detect such elements as “matching” elements or signature-based approach [14]. We propose to use such techniques to detect shared components. Process: The next step consists in defining productive models from visuals model (for example UML diagrams). The productive models are created in the Eclipse-EMF framework (Figure 30). Languages of model transformations, like Kermeta, defined on metamodels ( .ecore) to transform model (.xmi) generate prolog actions. The Prolog actions engine the model transformations to generate the result of the profiles integrations (Figure 31). The use of Prolog language should allow us to detect conflicts.
41
Figure 30 Metamodel on Eclipse EMF
42
Figure 31 From Productive Models to Prolog
43
10.
Illustration List
Figure 1 Initial Context Model .......................................................................................................... 7 Figure 2 Sequence Diagram of Initial Context .................................................................................. 8 Figure 3 Image Insertion ................................................................................................................... 9 Figure 4 Sequence Diagram of Image Insertion.............................................................................. 10 Figure 5 Tools Invocation ................................................................................................................ 11 Figure 6 Sequence Diagram of Tool Invocation .............................................................................. 12 Figure 7 - Identification Profile ....................................................................................................... 14 Figure 8 Initial Context Model Updating by the Identification Profile Integration......................... 15 Figure 9 Image Insertion Model Updating by Identification Profile Integration ............................ 17 Figure 10 Tool Invocation Model Updating by Identification Profile Integration........................... 18 Figure 11 Access Control List Profile ............................................................................................... 20 Figure 12 Initial Context Model Updating by the ACL Profile Integration ..................................... 21 Figure 13 Image Insertion Model Updating by the ACL Profile Integration ................................... 22 Figure 14 Tool Invocation Model Updating by the ACL Profile Integration .................................... 23 Figure 15 Authentication Profile ..................................................................................................... 25 Figure 16 Initial Context Model Updating by the Authentication Profile Integration .................... 26 Figure 17 Image Insertion Model Updating by the Authentication Profile Integration ................. 27 Figure 18 Tool Invocation Model Updating by the Authentication Profile Integration.................. 28 Figure 19 Data Encryption Profile ................................................................................................... 30 Figure 20 Initial Context Model Updating by the Data Encryption Profile Integration .................. 31 Figure 21 Image Insertion Model Updating by the Data Encryption Profile Integration ............... 32 Figure 22 Trace Profile .................................................................................................................... 33 Figure 23 Initial Context Model Updating by the Trace Profile Integration ................................... 34 Figure 24 Image Insertion Model Updating by the Trace Profile Integration................................. 35 Figure 25 Ratio of Created Elements by Concerns Integrations on the Initial Context Model....... 36 Figure 26 Ratio of Modified Elements by Concerns Integrations on the Initial Context Model..... 37 Figure 27 Merge of Integration Concerns in Initial Context Model ................................................ 38 Figure 28 Merge of Integration Concerns in Image Insertion Model ............................................ 39 Figure 29 Merge of Integration Concerns in Tool Invocation Model............................................. 40 Figure 30 Metamodel on Eclipse EMF ............................................................................................ 42 Figure 31 From Productive Models to Prolog ................................................................................. 43
44
11.
Bibliography
1. A. Abran, P. Bourque, R. Dupuis, and J. W. Moore: Guide to the Software Engineering Body of Knowledge - SWEBOK. IEEE Press. Eds. 2001. 2. David Basin, Jurgen Doser and Torsten Lodderstedt: Model driven security: From UML models to access control infrastructures. In ACM Transactions on Software Engineering and Methodology (TOSEM), pages 39 - 91, jan 2006. 3. Don Batory: Multilevel models in model-driven engineering, product lines, and metaprogramming. In IBM systems journal (IBM Syst. J.), vol. 45, pages 527 - 539, IBM Corp., jul 2006. 4. Côté, I.; Heisel, M.; Wentzlaff, I.: Pattern-based Exploration of Design Alternatives for the Evolution of Software Architectures. In proceedings of International Journal of Cooperative Information Systems (IJCIS), Special Issue Software Architecture - Towards the Software Engineering Core, Best Papers of the ECSA'07. 5. Alban Gaignard and Johan Montagnat NeuroLOG: Software Architecture (draft document, January 23, 2008) http://neurolog.polytech.unice.fr/ 6. Gregor Kiczales, Mira Mezini: Separation of Concerns with Procedures, Annotations, Advice and Pointcuts. In Proceedings of the 19th European Conference on Object-Oriented Programming (ECOOP), pages 195-213, Springer, 2005. 7. Dae-Kyoo Kim, Pooja Mehta and Priya Gokhale: Describing Acess Control Models as Design Patterns Using Roles. In Proceedings of the Pattern Languages of Programs (PLOP 2006), ACM, Porteland, Oregon, 21-23 october 2006 8. Johan Montagnat, Alban Gaignard, Diane Lingrand, Javier Rojas Balderrama, Philippe Collet, Philippe Lahire: NeuroLOG: a community-driven middleware design. In Proceedings of the HealthGrid, pages 49--58, IOS Press, Chicago, 2-4 jun 2008. 9. Martin Monperrus ans Jean-Marc Jézéquel: A model-driven Measurement Approach. In Proceedings of the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems (MODELS'2008). 10. Alexis Muller, Olivier Caron, Bernard Carre and Gilles Vanwormhoudt: On Some Properties of Parameterized Model Application. In Proceedings of the First European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA'2005), A. Hartman and D. Kreische Eds., Nuremberg, nov 2005. 11. Patterns: Model-Driven Development Using Ibm Rational Software Architect. IBM Corp. 12. Bjørnar Solhaug and Ketil Stølen: Compositional Refinement of Policies in UML - Exemplified for Access Control. In proceedings of the 13th European Symposium on Research in Computer Security (ESORICS 2008), pp. 300-316, LNCS 5283, Springer 2008. 13. Raghu Reddy, S. Ghosh, Robert France, S. Straw, J. Bieman, N. McEachen, E. Song and G. Georg: Directives for Composing Aspect-Oriented Design Class Models. In Transactions on Aspect-Oriented Software Development I, pages 75-105, Springer, 2006. 14. Raghu Reddy, Robert France, Benoit Baudry and Franck Fleurey: Model composition - a signature-based approach. In Aspect Oriented Modeling (AOM), Montego Bay, Jamaica, oct 2005. 45
