Une tentative d’utilisation conjointe d’UML et d’une méthode formelle pour la modélisation de la sécurité des aéroports Yves Ledru* — Régine Laleau** — Sylvie Vignes*** * LIG, Université de Grenoble-1

[email protected] ** Laboratoire LACL, Université de Paris 12

[email protected] *** GET/ENST, dépt Informatique et Réseaux, Paris

[email protected]

Le projet EDEMOI 1 a pour but la modélisation de la sécurité des aéroports. Son approche passe par la production de modèles graphiques (un ensemble de diagrammes UML) destinés à être validés par les experts du domaine, et de modèles formels destinés à être vérifiés. Pour assurer la correspondance entre ce qui est validé et ce qui est vérifié, il faut établir un lien fort entre ces deux types de modèles. L’outil RoZ permet un tel lien en traduisant des diagrammes UML annotés vers une spécification Z. Cet article discute l’utilisation de l’outil RoZ dans le contexte d’EDEMOI et les problèmes rencontrés lors de cette tentative de traduction. RÉSUMÉ.

ABSTRACT. The framework of this paper is the EDEMOI project whose aim is to model airport security. This approach involves the production of a graphical model (a set of UML class diagrams), to support the validation activity, and a formal model for verification purposes. In order to make sure that what is validated is also what is verified, a strong link must exist between both models. RoZ offers a solution to this problem by translating annotated UML diagrams into Z specification. This paper presents the application of the RoZ tool to the model of the EDEMOI project and lists the problems faced during this translation approach. MOTS-CLÉS :

Intégration de méthodes de spécification, sécurité, UML, méthodes formelles, Z.

KEYWORDS:

Method integration for specification, security, UML, formal methods, Z.

1. Le projet EDEMOI était soutenu par l’ACI Sécurité Informatique 2003-2006.

1. Introduction La communauté scientifique a développé de nombreuses notations pour assister le développement de logiciels et de systèmes. D’une part, les méthodes formelles ont permis de vérifier le développement de nombreux systèmes critiques (Craigen et al., 1993, Behm et al., 1999). D’autre part, des notations graphiques comme UML sont utilisées comme support pour la communication entre les différents intervenants d’un projet. La combinaison de ces deux types de formalismes est donc perçue comme une façon de combiner les activités de validation (“Construisons nous le bon système ?”), qui peuvent bénéficier du caractère intuitif des notations graphiques, et de vérification (“Notre construction est-elle correcte ?”). Plusieurs équipes ont tenté de faire ce lien et des outils ont été développés en direction de méthodes à base de modèles comme B, Z, ou VDM. La démarche la plus courante consiste à traduire les diagrammes UML vers la notation formelle. Ainsi plusieurs efforts ont été menés pour traduire UML en B (Meyer et al., 1999, Mammar et al., 2006), Z ou Object-Z (Kim et al., 1999, Dupuy et al., 2000). D’autres travaux, plus récents, ont adopté le chemin inverse pour extraire une représentation graphique d’un modèle formel (Fekih et al., 2004, Idani, 2006). Enfin, d’autres efforts visent à rendre UML plus formel, notamment au travers du langage OCL (Warmer et al., 2003). Dans cet article, nous nous concentrons sur la première technique (traduction d’UML vers une méthode formelle), et évaluons sa pertinence et ses limites dans le contexte du projet EDEMOI 1 . Ce projet s’intéresse à la modélisation des réglementations de sécurité2 . Son objectif est d’utiliser des méthodes formelles comme B (Abrial, 1996) ou Z (ISO 2002) pour analyser ces réglementations, vérifier leur cohérence et en extraire des cas de test de conformité. Depuis trente ans, des efforts très significatifs ont été dédiés à l’amélioration de la sécurité du transport aérien. L’aéroport joue un rôle clé dans ce dispositif en empêchant l’embarquement d’armes ou d’objets dangereux à bord des avions. La sécurité des aéroports est régie par des normes et recommandations internationales telles que l’Annexe 17 de l’Organisation de Aviation Civile Internationale (ICAO, 2002). Il s’agit de documents qui souffrent des carences intrinsèques à l’emploi de la langue naturelle : risque d’ambiguïté ou d’incomplétude, faible support d’outils pour vérifier leur cohérence et pour aider à leur validation. Le but du projet EDEMOI est de construire des modèles de ces réglementations et de vérifier leur cohérence avec des outils formels. Dans ce contexte, les modèles graphiques, réalisés en UML, constituent une étape intermédiaire entre les documents en langue naturelle et les modèles formels. Ils mettent en évidence la structure du modèle et doivent satisfaire trois propriétés. Tout d’abord, ils doivent être proches du texte des normes pour faciliter la traçabilité entre les éléments du modèle et le texte qui les décrit. Ensuite, ces modèles doivent être lisibles par des experts de l’aviation civile 1. http ://www-lsr.imag.fr/EDEMOI/ 2. Dans le monde aéroportuaire, le terme “sûreté” désigne la protection de l’aviation civile contre des actes d’intervention illicite. Dans cet article, nous préférons utiliser le terme “sécurité” qui est usuel dans la communauté informatique.

ayant une formation d’ingénieur. Enfin, le lien entre modèles graphiques et formels doit être clairement établi, de préférence par des outils automatiques. Ceci permet d’assurer que le modèle formel vérifié correspond au modèle graphique validé. Cet article est consacré à ce dernier besoin. Au début du projet EDEMOI, nous comptions sur des outils existants de traduction automatique d’UML vers B ou Z, développés notamment par des partenaires du projet. Cet article montre que les outils existants sont inadaptés à ce besoin et que de nouvelles avancées sont nécessaires. La Sect. 2 présente les intervenants et les principaux documents du projet EDEMOI. La Sect. 3 détaille un des diagrammes UML et illustre la démarche de modélisation adoptée pour passer du texte au diagramme. Il introduit également divers stéréotypes notamment dédiés à la modélisation de la sécurité. La Sect. 4 décrit la traduction des modèles UML en Z et la Sect. 5 passe en revue les difficultés expérimentées lors de cette traduction. Enfin la Sect. 6 tire les conclusions de ce travail.

2. Intervenants et documents du projet EDEMOI La Fig. 1 présente les principaux documents et intervenants du projet. Les autorités de certification sont responsables de la rédaction et de l’évolution des normes internationales. Elles participent également au contrôle de leur application dans les aéroports. Leur rôle au sein du projet EDEMOI est de valider les modèles des standards internationaux. Les analystes (model engineers) construisent les modèles à partir du texte des normes et vérifient leur cohérence. Ils peuvent aussi utiliser les modèles formels pour produire des cas de test ou des animations. Le projet EDEMOI a montré que ces cas de test constituent un deuxième support d’interaction avec les autorités de certification.

Certification Authority produces International Standard

human translation

reads

The EDEMOI stakeholders

reads/validates Graphical Model

systematic translation

produces

Model Engineer

Figure 1. Les intervenants du projet EDEMOI

Formal Model produces or updates

animation generation

Test Scenarios

Le projet comprend donc quatre types de documents. Les normes internationales sont des documents en langue naturelle qui décrivent les règles de la sécurité des aéroports. Les modèles graphiques sont préparés par les analystes et validés par les autorités de certification. Les modèles formels sont uniquement utilisés par les analystes et servent d’entrée à divers outils de vérification (démonstrateurs, animateurs, générateurs de tests). Les cas de test sont produits à partir des modèles. Ils peuvent servir de base aux tests réalisés par les inspecteurs dans les aéroports, mais servent également de support au dialogue entre les analystes et les autorités de certification. Tous ces documents doivent correspondre à la même réalité. Divers types de liens peuvent être établis entre eux. Tout d’abord, les liens entre les normes et les diagrammes UML sont de nature informelle ; ils sont identifiés “à la main” par les analystes et enregistrés dans les modèles. A l’autre bout de la chaîne, le lien entre les modèles formels et les tests est établi automatiquement par des outils qui soit génèrent ces tests à partir des modèles, soit exploitent des outils d’animation pour vérifier la concordance entre ces scénarios et le modèle. Au milieu de la chaîne, le lien entre les diagrammes UML et les modèles formels devrait être automatisé car ces derniers ne sont jamais vus par les autorités de certification. Leur validation est donc indirecte et se base fortement sur ce lien. En particulier, ce lien est nécessaire pour établir une traçabilité entre les résultats produits à partir de ces modèles (vérifications, tests générés) et le texte original des normes. C’est ce lien qui est étudié dans cet article.

3. Les diagrammes UML La Fig.2 donne quelques mesures de la taille des modèles UML correspondant à l’annexe 17. La démarche qui a mené à leur construction est détaillée dans (Laleau et al., 2006). Ces modèles ne comprennent que des diagrammes de classes. Dans cette section, nous illustrons la démarche de construction sur un exemple tiré de ces diagrammes et nous introduisons quelques extensions d’UML sous forme de stéréotypes dédiés à ce type de modélisation.

3.1. Contrôle des passagers et des bagages à mains Les modèles ont été établis à partir de la version anglophone de l’Annexe 17 (version 10). Nous reproduisons ci-dessous les deux principaux articles qui portent sur la sécurité des passagers et de leurs bagages à main. 4.3.1 Each Contracting State shall establish measures to ensure that originating passengers and their cabin baggage are screened prior to boarding an aircraft engaged in international civil aviation operations. 4.3.2 Each Contracting State shall ensure that transfer and transit passengers and their cabin baggage are subjected to adequate security controls to prevent unauthorized articles from being taken on board aircraft engaged in international civil aviation operations.

Paquetage AirSide entitiesAirport LandSide SecurityProperties Total

diagrammes 8 8 2 1 19

classes 111 66 11 32 220

associations 99 64 10 30 203

Figure 2. Taille des modèles UML

Les mesures qui s’appliquent au passagers diffèrent selon leur origine. Le premier article concerne les passagers qui commencent leur voyage à l’aéroport (“originating passengers”). De ce fait, ils n’ont encore été soumis à aucun contrôle et il est nécessaire qu’un contrôle spécifique, le “filtrage” (screening), soit appliqué à ces passagers et à leurs bagages à main avant l’embarquement. Le second article concerne les passagers en transit ou en correspondance. Il s’agit de passagers qui ont été filtrés lors d’une étape précédente de leur voyage. La norme prévoit d’adapter le contrôle, par exemple en fonction de la confiance que l’on a dans leur aéroport d’origine. En outre, d’autres articles de la norme s’assurent que ces passagers restent dans des zônes sous contrôle. 3.1.1. Diagramme de classes correspondant La Fig. 3 donne une modélisation en UML des principaux éléments de ces deux paragraphes. Les classes cabinP assenger et embarkedCabinLuggage correspondent aux passagers et à leurs bagages à main. Des attributs booléens enregistrent l’état “filtré” ou “contrôlé” des instances de ces classes. Le modèle n’explicite pas la séman-

embarkedCabinLuggage screened : Boolean controlled : Boolean

any:aircraft 0..n

0..n

0..n 0..n

/CL_ownership

CL_ownership

1

/CL_ownership

originatingPassenger screened : Boolean 1 aircraft

transitPassenger

(from entitiesAirport)



1

1..n aircraftCabin 1..n

1

embarked

0..n

controlled : Boolean

/CL_ownership



1 transferPassenger

cabinPassenger

controlled : Boolean

Figure 3. Diagramme de classes pour les passagers et leurs bagages à main

cabinPassenger

armedPassenger



obligedPassenger

ordinaryPassenger

Figure 4. Divers types de passagers

tique de ces deux attributs. Par contre d’autres modèles, non repris dans cet article, détaillent le point d’inspection/filtrage et permettent de mieux décrire ces notions. La classe cabinP assenger se spécialise en trois sous-classes, selon les origines des passagers (au départ, en transit ou en correspondance). Selon le cas, un attribut screened ou controlled a été ajouté à la sous-classe. Un stéréotype comeF rom exprime que la spécialisation porte sur l’origine du passager. En effet, d’autres articles de l’annexe 17 font la distinction entre trois types de passagers : les passagers ordinaires, ceux qui ont l’autorisation de porter une arme (par exemple un garde du corps), et ceux qui sont obligés de voyager suite à une décision judiciaire ou administrative. Cette deuxième spécialisation est présentée à la Fig. 4 et un stéréotype kindOf la distingue de la précédente. Ces stéréotypes représentent donc des propriétés indépendantes qui peuvent être combinées en 9 sous-classes de cabinP assenger. La Fig. 3 présente les entités importantes des articles 4.3.1 et 4.3.2. Une d’entre elles constitue la “cible de sécurité” (“security target”), aussi appelée “subject matter” ou “topic” dans (Cysneiros et al., 2004). A la Fig. 3, l’avion est la cible de sécurité car ces mesures sont destinées à assurer la sécurité du vol. Un stéréotype securityT arget est utilisé pour identifier un objet correspondant à cette cible et le lier à sa classe par une relation stéréotypée instanceOf. On évite ainsi de stéréotyper directement la classe aircraf t qui peut apparaître dans d’autres diagrammes où elle ne sera pas nécessairement la cible de sécurité. Enfin, l’association embarked fait le lien entre les passagers qui ont embarqué et l’une des cabines de l’avion. 3.1.2. Ajout de propriétés de sécurité Le diagramme de classes de la Fig. 3 donne tous les éléments pour exprimer la propriété de sécurité suivante : Les passagers ordinaires ne transportent pas d’armes, d’explosifs ou autres objets non autorisés dans la cabine d’un avion. (propriété 2.1) Cette propriété correspond à l’ensemble de propriétés du paragraphe 4.3 de l’annexe 17. La Fig. 5 exprime que la propriété 2.1 est garantie par la combinaison des propriétés P4, P5, P6 et P23. P4 et P5 correspondent aux paragraphes 4.3.1 et 4.3.2. P6 garantit qu’une fois inspecté, un passager ne peut plus avoir de contact avec des passagers non-inspectés. Enfin P23 impose que toute arme transportée par un avion

P2.1 A17-4.3

P4 A17-4.3.1

P5 A17-4.3.2

P5Transfer

P6 A17-4.3.3

P23 A17-4.6.6

P5Transit

Figure 5. Hiérarchie de propriétés de sécurité

doit être déchargée et placée hors de portée des passagers (à l’exception des armes autorisées pour les personnels armés). La hiérarchie poursuit la décomposition de P5 par deux sous-propriétés qui dépendent du type de passager (en transfert ou en transit). La Fig. 5 est extraite du diagramme SecurityP roperties, qui regroupe l’ensemble des propriétés de sécurité dans une seule hiérarchie. En ingénierie des besoins, cet arbre correspond à l’identification et la décomposition de buts (Dardenne et al., 1993). Il exprime comment un but de haut niveau (par exemple P2.1) est satisfait par une conjonction ou une combinaison de sous-buts (ici P4, P5, P6 et P23). UML ne prévoit pas d’exprimer des buts par un diagramme de classes. Nous avons dès lors décidé de les exprimer dans des classes stéréotypées par SecurityP roperty. Pour assurer la traçabilité, chacune de ces classes comprend un attribut dont le nom fait référence au paragraphe correspondant de l’annexe 17. Il s’agit ensuite de relier les propriétés de sécurité aux éléments du modèle. La Fig. 6 illustre comment ces classes stéréotypées sont intégrées au diagramme de la Fig. 3. Dans la plupart des cas, les propriétés de sécurité sont reliées à des associations du diagramme original. Ainsi P4 et P5 portent sur l’association CL_ownership. Le lien entre cette association et la propriété de sécurité s’exprime en transformant l’association en classe associative. Un stéréotype af f ect indique que la classe associative fait référence à une propriété de sécurité. La propriété 2.1 apparait également dans ce diagramme de classes et est reliée à l’association embarked.

3.2. Résumé de la démarche de modélisation La traduction du document en langue naturelle vers un diagramme UML comprend trois étapes : (1) l’identification de buts, c’est à dire de propriétés de sécurité, regroupés dans une hiérarchie ; (2) la production d’un diagramme de classes qui regroupe

embarkedCabinLuggage

P4

screened : Boolean controlled : Boolean 0..n

0..n

A17-4.3.1 0..n

P5

0..n

A17-4.3.2

CL_ownership /CL_ownership

any:aircraft



P5Transit

1 /CL_ownership



originatingPassenger



P5Transfer

screened : Boolean P2.1 A17-4.3

aircraft

1

(from entitiesAirport)



transitPassenger controlled : Boolean

/CL_ownership

1 1..n

aircraftCabin 1

embarked

0..n

1 cabinPassenger

transferPassenger controlled : Boolean

Figure 6. Diagramme de classes complété par les propriétés de sécurité

les principales entités et relations dans un modèle du domaine ; (3) le lien entre les propriétés de sécurité et les entités et relations du domaine. Notre démarche comporte également l’identification des agents chargés de faire respecter les règles de sécurité. Ils ne sont pas illustrés par l’exemple de cet article et ne sont pas traduits en Z. Nos modèles utilisent un UML étendu par deux sortes de stéréotypes. Les premiers sont propres à notre démarche et indépendants de la réalité modélisée. Ils marquent les propriétés de sécurité, leurs liens vers des éléments du modèle et la cible de sécurité (une par diagramme). Les seconds sont propres à la réalité modélisée : ils expriment des propriétés sémantiques propres au domaine d’application. C’est ici le cas de  comeF rom et kindOf, qui précisent des relations de spécialisation. Les résultats de notre modélisation sont regroupés dans quatre paquetages synthétisés par la Fig. 2. SecurityP roperties contient la hiérarchie de propriétés de sécurité. entitiesAirport est un modèle du domaine qui introduit les principales entités. AirSide et LandSide regroupent des diagrammes qui, comme la Fig. 6, font le lien entre entités du domaine et propriétés de sécurité. Notons que plusieurs travaux proposent d’étendre UML pour prendre en compte les aspects liés à la sécurité. Les concepts de Misuse Case (Sindre et al., 2000), Abuse Case (McDermott et al., 1999) and Security Use Case (Firesmith, 2003) permettent de spécifier des scénarios de menaces qui peuvent violer la sécurité des systèmes. Le projet européen CORAS (Lund et al., 2003) a développé une méthode basée sur UML pour l’analyse de risques de sécurité. secureUML (Lodderstedt et al., 2002) introduit dans UML les concepts de RBAC (Role-Based Access Control) et UMLsec (Jürjens,

2002) s’intéresse au développement de logiciels sécuritaires. A notre connaissance, aucun travail ne considère les réglementations de sécurité.

4. Traduction en un modèle formel Le modèle UML construit aux étapes précédentes est un mélange de notations structurées (classes, associations, spécialisations,. . . ) et d’annotations en langue naturelle : les propriétés de sécurité sont exprimées en anglais. Dans le contexte d’UML, OCL peut être utilisé à la place des annotations en langue naturelle. OCL (Warmer et al., 2003) est une notation formelle qui peut exprimer la plupart des propriétés de sécurité que nous avons identifiées. Malheureusement, ce langage ne bénéficie à ce jour que d’un faible outillage, qui ne permet pas de vérifier la cohérence des annotations avec le modèle ou de générer des tests, même si des efforts ont été faits dans ce sens, par exemple dans le projet SOCLe (Azambre et al., 2005)

4.1. Choix d’un langage cible Parmi les nombreux langages formels de spécification, les langages à base de modèles, comme Z et B, sont proches d’OCL dont ils ont influencé la conception, et disposent de nombreux outils de support (démonstrateurs, animateurs, générateurs de tests). Ces langages expriment les spécifications par des assertions qui prennent la forme de propriétés invariantes, c’est à dire des propriétés qui doivent être vérifiées à la fin de chaque opération, ainsi que des pré- et post-conditions associées aux opérations. Une analyse préliminaire menée dans le projet EDEMOI a conclu qu’une majorité de propriétés de la sécurité aéroportuaire pouvaient s’exprimer sous la forme d’invariants. Par exemple, l’objectif principal de la sécurité aéroportuaire équivaut à l’invariant suivant : “Il n’y a pas d’objets dangereux à bord d’un avion.” Dans l’exemple des passagers et de leurs bagages à main, on peut identifier des propriétés similaires : “Tous les passagers embarqués sur un avion ont été contrôlés ou filtrés.”, “Les bagages à main embarqués sur un avion ont été contrôlés ou filtrés.” Le choix de B et Z comme langages cibles de notre traduction résulte de leur capacité à exprimer de telles propriétés de sécurité et de la disponibilité d’outils qui permettent une traduction automatique.

4.2. RoZ RoZ (Dupuy et al., 2000) est un outil de traduction automatique d’un diagramme de classes UML, complété par des annotations formelles, vers une spécification Z. Le diagramme de classes détermine la structure de la spécification et les annotations permettent d’ajouter des invariants ou de spécifier des opérations. L’outil est constitué

d’un ensemble de scripts pour l’outil Rational Rose3 . Les annotations sont exprimées directement en Z dans les champs “documentation” du modèle, comme le montre la Fig. 7. Les annotations peuvent ainsi être insérées à divers niveaux dans le diagramme (attribut, classe, association ou vue), selon la portée de la contrainte. Ainsi la Fig. 7 montre deux propriétés exprimées au niveau de l’association embarked. Dans cette figure, l’outil travaille sur une version simplifiée du diagramme de classes, présenté à la Sect. 5 (Fig. 9). A partir de ce diagramme annoté, l’outil produit une spécification Z. Par exemple l’association embarked est traduite par : embarkedRel 1 CabinpassengerExt; AircraftcabinExt passengersOfCabin : AIRCRAFTCABIN → 7 F CABINPASSENGER cabinOfPassenger : CABINPASSENGER → 7 AIRCRAFTCABIN dom cabinOfPassenger ⊆ Cabinpassenger ran cabinOfPassenger ⊆ Aircraftcabin passengersOfCabin = {x : ran cabinOfPassenger • x 7→ {y : dom cabinOfPassenger | cabinOfPassenger (y) = x • y}} cabinOfPassenger = S {x : dom passengersOfCabin • {y : passengersOfCabin(x ) • y 7→ x }} embarkedRel embarkedRel 1 ∀ p : dom cabinOfPassenger | p.kindOfPassenger = Originating • p.screened = True ∀ p : dom cabinOfPassenger | (p.kindOfPassenger = Transit ∨ p.kindOfPassenger = Transfer ) • p.controlled = True

Dans cette spécification Z, le premier schéma embarkedRel1 correspond à la traduction automatique de l’association. Il inclut les schémas CabinP assengerExt et Aircraf tcabinExt4 , qui déclarent les extensions des classes cabinP assenger et aircraf tCabin, c’est à dire les ensembles d’objets existants de ces classes. Ces ensembles, nommés CabinP assenger et Aircraf tcabin, incluent les domaine et codomaine de l’association. Chacun des rôles de l’association est traduit comme une fonction partielle. Ces fonctions sont déclarées dans la partie supérieure du schéma et deux contraintes définissent chaque rôle en fonction de l’autre. Formellement, une seule définition est suffisante, mais la redondance des définitions est destinée à faciliter le travail d’un outil d’animation de la spécification (Jaza). Le schéma embarkedRel inclut cette traduction automatique de la relation et y ajoute les deux contraintes définies par l’utilisateur dans le champ de documen3. http ://www.rational.com 4. Par manque de place, nous ne donnons pas la définition de ces schémas.

Figure 7. Un diagramme de classes annoté dans RoZ

tation de l’association. La première contrainte impose que les passagers au départ (“Originating”) aient été filtrés, la seconde prescrit le contrôle des autres passagers (en correspondance ou en transit). De façon similaire des annotations contraignent le contrôle des bagages à main. Celles-ci portent simultanément sur les associations CL_ownership et embarked. Elles sont dès lors exprimées dans le contexte de l’ensemble du diagramme pour avoir la visibilité sur les deux associations. 4.2.1. Ajout d’opérations au modèle Le modèle ainsi construit ne comporte aucune opération. Celles-ci sont nécessaires pour animer le modèle en créant/détruisant des objets, des liens ou en modifiant leurs attributs. RoZ permet de générer automatiquement la spécification Z des opérations de base sur les objets et associations. Ainsi, l’opération ci-dessous est générée et permet de modifier la valeur de l’attribut screened d’un bagage à main. CABINLUGGAGEChangeScreened ∆CABINLUGGAGE newscreened ? : Boolean screened 0 = newscreened ? LuggageID 0 = LuggageID ∧ controlled 0 = controlled

L’opération prend en entrée la nouvelle valeur de l’attribut. Sa définition exprime que la valeur finale de l’attribut (screened0 ) est égale à ce paramètre d’entrée et que

aircraftId = 'Avion1'

aircraftId = 'Avion2'

aircraftId = 'Avion3'

cabinID = 'Cabin1'

controlled = True kindOfPassenger = Transfer name = 'van den broucke' screened = False

LuggageID = 'Luggage3' controlled = True screened = False

controlled = False kindOfPassenger = Originating name = 'Dupont' screened = False

LuggageID = 'Luggage1' controlled = False screened = False

LuggageID = 'Luggage2' controlled = False screened = False

Figure 8. Un instantané des objets et de leurs liens

les autres attributs ne changent pas. Parmi ces attributs, LuggageID a été ajouté au modèle car l’outil RoZ nous impose de fournir un identifiant pour chaque objet. En UML, les diagrammes comportementaux, comme les diagrammes Etats/Transitions, sont généralement utilisés pour exprimer la dynamique d’un modèle. De tels diagrammes sont en fait complémentaires à la définition d’opérations dans le diagramme de classes : la définition de l’opération décrit ses effets sur les variables du modèle, tandis que les diagrammes Etats/Transitions expriment la synchronisation entre les événements externes et l’appel de ces opérations. RoZ ne supporte pas à ce jour la traduction de tels diagrammes, mais un tel travail constitue une perspective pour l’outil. 4.2.2. Animation du modèle Le modèle peut maintenant être exploité par des outils Z. Lors de cette étude, nous avons utilisé l’animateur Jaza 5 . Nous avons également développé un outil de visualisation de l’état du modèle, sur base de l’outil Dotty (Gansner et al., 2000). La Fig. 8 donne une de ces vues instantanées de l’état : deux passagers et leurs bagages à main ont été créés, l’un d’entre eux a déjà embarqué après avoir été contrôlé ; l’autre est un passager au départ qui n’a été ni filtré ni contrôlé. Nous avons l’intention d’utiliser ces instantanés, qui correspondent à des diagrammes d’objets, lors du processus de validation et de nos interactions avec les experts de l’aviation civile. 5. http ://www.cs.waikato.ac.nz/˜marku/jaza/

aircraft aircraftId : AIRCRAFTID

cabinLuggage LuggageID : LUGGAGEID screened : Boolean controlled : Boolean AddLuggageToPassenger() 0..n +LuggagesOfPassenger

1 +AircraftOfCabin

CLowner... CabinsOfAircraft +CabinsOfAircraft 0..n aircraftCabin cabinID : CABINID AddCabinToAircraft()

+PassengerOfLuggage 1 cabinPassenger name : NAME +cabinOfPassenger +passengersOfCabin kindOfPassenger : KINDOFPASSENGER screened : Boolean embarked 0..1 0..n controlled : Boolean

Figure 9. Diagramme de classes utilisé en entrée de RoZ

5. Difficultés rencontrées lors de la traduction d’UML vers Z Nous avons mentionné dans la Sect. 4 que RoZ avait été utilisé sur une version simplifiée du diagramme de classes (Fig. 9). Nous allons maintenant présenter les difficultés de traduction qui rendent ces simplifications nécessaires. La Fig. 9 diffère de la Fig. 6 suite aux simplifications suivantes : – Les propriétés de sécurité n’apparaissent plus comme des classes stéréotypées. – La cible de sécurité n’est plus identifiée. – Les sous-classes de cabinP assenger ont été remplacées par l’attribut kindOf P assenger, et les attributs des sous-classes (screened et controlled) ont été remontés au niveau de leur super-classe. – Des identifiants ont été ajoutés aux classes (cabinID, aircraf tID, LuggageID, name). – Tous les rôles des associations sont nommés. – La multiplicité du rôle cabinOf P assenger est affaiblie et passe de 1 à 0..1. – La multiplicité du rôle CabinsOf Aircraf t est affaiblie et passe de 1..n to 0..n. Nous détaillons maintenant chacune de ces simplifications. Traduction des stéréotypes : Les stéréotypes de nos diagrammes sont soit liés à la modélisation de la sécurité (propriétés de sécurité, cible de sécurité), ou sont propres à l’application (ici, spécialisations stéréotypées). RoZ a été développé hors du contexte de la sécurité et ne prend pas en compte la sémantique de ces stéréotypes. Dès lors, des classes ou associations stéréotypées seront traduites comme des éléments non stéréotypés. Dans nos modèles, cela conduit par exemple à traduire chaque propriété de

sécurité comme une classe. Dès lors, nous avons enlevé ces classes stéréotypées et inclus les contraintes qu’elles exprimaient dans les champs “documentation” du modèle. On peut imaginer une évolution de RoZ dédiée à la modélisation de la sécurité qui prenne en compte les stéréotypes SecurityP roperty et securityT arget, et leur consacre un traitement spécifique. Les propriétés de sécurité seraient ainsi traduites par des invariants ajoutés à l’élément du modèle qui leur est lié. Pour la cible de sécurité, aucune traduction n’est nécessaire, mais l’outil pourrait vérifier que chaque diagramme comporte une et une seule de ces cibles. Par contre, les autres stéréotypes (par exemple  comeF rom ) sont spécifiques à l’application et il serait difficile d’adapter l’outil pour chaque application. Traduction de la relation d’héritage : L’héritage est une construction importante pour la modélisation qui doit être prise en compte par RoZ. Dans sa version actuelle, l’outil traduit l’héritage simple (pas d’héritage multiple). Malheureusement, cette traduction est très complexe, car le langage cible (Z) n’est pas un langage objet. Il est donc nécessaire de “coder” explicitement dans la spécification la sémantique de l’héritage. La traduction actuelle est trop complexe pour être exploitable par l’animateur Jaza. La solution la plus simple serait d’adopter une traduction semblable à celle de l’outil UB2SQL (Mammar et al., 2006) où l’objet est traduit par une association entre un élément et les valeurs de ses attributs. Une telle traduction est mieux adaptée au traitement de la spécialisation, mais rend plus complexe l’écriture de contraintes sur les données. Contraintes techniques de l’outil : RoZ fait l’hypothèse que chaque classe a au moins un attribut et que chaque rôle a un nom unique. Ceci explique l’ajout d’attributs et de noms de rôles au modèle. Comme RoZ est destiné à l’activité de modélisation, nous avons délibérément choisi de ne pas ajouter automatiquement un identifiant à chaque objet. Ce choix est de nature méthodologique : pour chaque classe, l’analyste doit se poser la question de l’identification des clés ; il n’ajoute un identifiant qu’en cas de nécessité. Rendre le modèle plus dynamique et exécutable : L’affaiblissement des multiplicités des rôles facilite l’animation du modèle. Par exemple à la Fig. 6, la multiplicité de cabinOf P assenger impose que chaque passager soit rattaché à sa cabine d’embarquement dès sa création. Ceci résulte du fait que le diagramme est dédié à la propriété de sécurité qui impose que tout passager embarqué ait été inspecté. Dès lors, le modèle se concentre sur l’état où les passagers ont déjà embarqué. En affaiblissant la multiplicité de ce rôle, le nouveau modèle permet d’étudier l’opération d’embarquement et les conditions qui y sont liées. Par exemple, l’animation de la spécification montre que l’embarquement d’un passager qui n’est ni contrôlé ni filtré mène à une violation d’invariant. L’affaiblissement des multiplicités peut également faciliter la création des objets. Par exemple, la multiplicité de CabinsOf Aircraf t impose de créer simultanément l’avion et la première des cabines qui lui sont liées. Comme les opérations de base

générées par RoZ ne permettent de créer qu’un objet, ou qu’un lien, à la fois, il est nécessaire de définir manuellement toute opération qui implique la création de plusieurs objets et liens. La génération d’opérations qui permettent la création simultanée de plusieurs objets est une évolution envisagée pour RoZ. Taille de la spécification : Le diagramme de classes des passagers et des bagages à main n’est qu’un des 19 diagrammes produits par le projet EDEMOI. Chacun de ces diagrammes pris isolément reste d’une taille raisonnable et, moyennant les transformations décrites ci-dessus, peut être traduit par RoZ. Cependant, nous prévoyons que la traduction et l’animation simultanée de l’ensemble des diagrammes posera problème. Même en enlevant les propriétés de sécurité, le modèle comprend 188 classes et 173 associations. La spécification Z résultante comprendra des centaines de schémas et un état global très complexe. On peut conjecturer que la plupart des outils n’ont jamais été confrontés à des spécifications de cette taille et seront mis en difficulté. De plus, l’animation interactive d’un modèle aussi complexe suppose des interfaces adaptées.

6. Conclusion Cet article a présenté l’approche du projet EDEMOI pour la modélisation de la sécurité des aéroports. Le modèle s’appuie sur deux types de langages : les langages graphiques supportent les activités de validation, et les langages formels permettent la vérification. L’existence d’un fort lien entre ces modèles est indispensable pour s’assurer que le modèle vérifié correspond au modèle validé. Nous avons détaillé les difficultés rencontrées pour traduire automatiquement le modèle UML en Z. La plupart d’entre elles ne sont pas spécifiques à RoZ et seraient rencontrées avec d’autres outils de traduction. Certains problèmes, comme la taille des spécifications et la traduction de l’héritage, ne sont pas liés au contexte de la modélisation de la sécurité. D’autres sont plus spécifiques à notre démarche de modélisation. D’une part, celle-ci définit un “profil” qui exploite systématiquement les stéréotypes pour étendre UML. D’autre part, la plupart des diagrammes sont des descriptions statiques où les contraintes de multiplicité gènent l’animation. Heureusement, la plupart de ces problèmes spécifiques à notre démarche peuvent être résolus en spécialisant RoZ. D’autres problèmes, comme ceux liés à la taille des spécifications nécessitent de pousser les expérimentations pour mieux les cerner.

7. Bibliographie Abrial J., The B-Book, Cambridge University Press, 1996. Azambre D., Bergeron M., Mullins J., « Validating UML and OCL models in SOCLe by simulation and model-checking », 2nd Int. Workshop On Model-Based Methodologies for Pervasive and Embedded Software, June 2005, Rennes, France, 2005. Behm P., Benoit P., Faivre A., Meynadier J., « METEOR : A successful application of B in a large project », FM’99 : World Congress on Formal Methods, LNCS 1709, Springer, 1999.

Craigen D., Gerhart S., Ralston T., An International Survey of Industrial Applications of Formal Methods–Case Studies, vol. 2, NIST, 1993. Cysneiros L. M., do Prado Leite J. C. S., « Nonfunctional Requirements : From Elicitation to Conceptual Models. », IEEE Trans. Software Eng., 2004. Dardenne A., van Lamsweerde A., Fickas S., « Goal-Directed Requirements Acquisition. », Science of Computer Programming, 1993. Dupuy S., Ledru Y., Chabre-Peccoud M., « An Overview of RoZ : a Tool for Integrating UML and Z Specifications », 12th Conference on Advanced information Systems EngineeringCAiSE’2000, LNCS 1789, Springer, 2000. Fekih H., Jemni L., Merz S., « Transformation des spécifications B en des diagrammes UML », AFADL : Approches Formelles dans l’Assistance au Développement de Logiciels, 2004. Firesmith D., « Security Use Cases. », Journal of Object Technology, vol. 2, n˚ 1, p. 53-64, 2003. Gansner E. R., North S. C., « An open graph visualization system and its applications to software engineering », Software - Practice and Exp., 2000. ICAO, Annex 17 to the Convention on Int. Civil Aviation - Security - Safeguarding International Civil Aviation against acts of unlawful interference. 2002. Idani A., « Couplage de spécifications B et de descriptions UML pour l’aide aux développements formels des Systèmes d’Information. », Actes du XXIVème Congrès INFORSID, Hammamet, Tunisie, 31 mai - 4 juin, 2006, p. 577-593, 2006. ISO, Information technology – Z formal specification notation – Syntax, type system and semantics. 2002. Jürjens J., « UMLsec : Extending UML for Secure Systems Development. », UML’02, 5th Int. Conf., LNCS 2460, Springer, p. 412-425, 2002. Kim S., Carrington D., « Formalizing the UML Class Diagram Using Object-Z », in , R. France, , B. Rumpe (eds), UML’99, LNCS 1723, Springer, 1999. Laleau R., Vignes S., Ledru Y., Lemoine M., Bert D., Donzeau-Gouge V., Dubois C., Peureux F., « Adopting a situational requirements engineering approach for the analysis of civil aviation security standards », Software Process : Improvement and Practice (SPIP), vol. 11, n˚ 5, p. 487-503, 2006. Lodderstedt T., Basin D. A., Doser J., « SecureUML : A UML-Based Modeling Language for Model-Driven Security. », UML’02, 5th Int. Conf., LNCS 2460, Springer, p. 426-441, 2002. Lund M. S., Hogganvik I., Seehusen F., Stølen K., UML profile for security assesssment., Technical Report n˚ STF40 A03066, SINTEF Telecom and Informatics, 2003. Mammar A., Laleau R., « A formal approach based on UML and B for the specification and development of database applications. », Autom. Softw. Eng., vol. 13, n˚ 4, p. 497-528, 2006. McDermott J., Fox C., « Using Abuse Case Models for Security Requirements Analysis », 15th Annual Computer Security Applications Conference, Phoenix, Arizona, USA, 1999, 1999. Meyer E., Souquières J., « A Systematic Approach to Transform OMT Diagrams to a B Specification », FM’99 : World Congress on Formal Methods, LNCS 1708, Springer, 1999. Sindre G., Opdahl A. L., « Eliciting Security Requirements by Misuse Cases. », TOOLS (37), IEEE Computer Society, p. 120-131, 2000. Warmer J., Kleppe A., The Object Constraint Language (Second Edition) - Getting your models ready for MDA, Addison-Wesley, 2003.