Dans un module écrit en Maude, les règles de réécriture constituent les unités élémentaires d’exécution. Elles interprètent les actions locales du système modélisé, et peuvent être exécutées dans un temps constant et de manière concurrente (à n’importe quel moment). Le langage Maude est entouré de nombreuses techniques et outils d’analyses formelles des comportements de systèmes tels que, la technique de vérification par invariants, le prouveur de théorèmes, le model-checker LTL, l’analyse de terminaison et l’analyse de cohérence. RT- Maude dispose d’un ensemble de commandes de simulation, d’analyse formelle et de vérification de propriétés LTL par model checking [137]. L’exécution et l’analyse d’un module temporisé se fait par rapport à la stratégie choisie pour l’application des règles « tick » de ce module. Notons que les techniques d’avancement du temps de RT-Maude procèdent à un échantillonnage de l’espace des états d’un système temporisé de telle sorte qu’au lieu de couvrir tout le domaine du temps, seulement certains moments sont visités.
Maude nous offre la possibilité de simuler l’exécution des réécritures (via des règles de réécriture) ou des réécritures équationnelles (via des équations) dans un module M par l’implémentation des deux commandes : reduce et rewrite.
La commande reduce (abrégée par red) permet à un terme initial d’être réduit par application des équations et des axiomes d’adhésion dans un module donné. Elle se présente sous la syntaxe suivante :
Reduce {in module :} term .
Pour simuler le comportement possible d’un système, RT-Maude dispose de deux modes de réécriture temporisée, implémentées respectivement par la commande de réécriture standard timed rewrite (ou trew) et la commande de réécriture équitable timed fair
51
rewrite (ou tfrew). Chacune de ces commandes simule un comportement possible du système, selon sa propre stratégie, jusqu’à une durée de temps donnée.
La technique de vérification par invariants est une technique simple, mais très utile, qui peut être menée dans Maude en utilisant la commande search. Elle représente une des techniques les plus courantes pour vérifier les propriétés de sûreté dans les différents types de systèmes informatiques. Néanmoins, elle peut être utilisée aussi pour la vérification des propriétés de vivacité.
Étant donné un système de transition t et un état initial s0, un invariant I est un prédicat définissant un sous-ensemble d’états qui comprend l’état s0 et tous les états accessibles à partir de s0 par un nombre fini de transitions. Par conséquent, un invariant est un prédicat qui définit un ensemble d’états contenant tous les états accessibles depuis s0. Dans ce cas, la sûreté est vérifiée si l’invariant est maintenu, ce qui signifie que rien de mauvais ne peut jamais se produire. Les propriétés de vivacité peuvent donc être vérifiées si on considère le cas contraire, c’est-à-dire, que les invariants sont considérés comme des états désirables (des états recherchés ou souhaités).
La technique de vérification par invariants est implémentée dans Maude par la commande search. Sa syntaxe est conforme à la forme générale suivante [138] :
search [n, m] in <nom-module>: <Terme-1> <flèche-de-recherche> <Terme-2> such that <condition> .
• n est un argument optionnel fournissant une limite sur le nombre de solutions souhaitées,
• m est un argument optionnel indiquant la profondeur maximale de la recherche, • <nom-module> le module où la recherche aura lieu,
• <Terme-1> le terme initial,
• <Terme-2> le pattern qui doit être atteint,
• <flèche-de-recherche> est une flèche indiquant la forme de la preuve de réécriture de <Terme-1> au <Terme-2> :
o =>1 la preuve de réécriture comprenant exactement une seule étape, o =>+ la preuve de réécriture consiste en une ou plusieurs étapes, o =>* la preuve consiste en aucune, une ou plusieurs étapes et
o =>! indique que seuls les chemins à états déterministe sont exploité. • <Condition> est une propriété optionnelle qui doit être satisfaite par l’état atteint. Pour l’analyse d’accessibilité, RT-Maude offre également une commande de recherche temporisée (tsearch) pour vérifier si un état t dans un système est accessible à partir d’un état initial et dans une limite de temps donnée. Cette commande adopte par défaut la stratégie de recherche en largeur dans l’arbre de calcul (arbre d’accessibilité).
52
Tableau 3.2. Opérateurs de LTL et notation Maude.
Opérateur LTL Notation Maude Opérateur LTL Notation Maude
┬ ⊥ ¬ ∧ ∨ ℛ True False ~_ _/\_ _\/_ ○_ _U_ _R_ → ↔ ⇝ ⇒ ⇔ _->_ _<->_ <>_ []_ _W_ _|->_ _=>_ _<=>_
La deuxième technique de vérification, que nous présentons, est basée sur la logique temporelle linéaire (LTL). Dans l'environnement Maude, deux éléments sont nécessaires à l'utilisation du vérificateur de modèles. Pour un module système Maude donné, ces deux éléments sont :
1. Une spécification système donnée par la théorie de réécriture décrite au sein de ce module,
2. Une spécification de besoins donnée par une propriété ou une série de propriétés à propos du système en modélisation.
Le Model Checking supporté par la plate-forme de Maude utilise la logique LTL essentiellement pour sa simplicité et les procédures de décision bien définies qu'il offre (pour plus de détails, voir [105] ou [129]). Dans un module prédéfini LTL, on trouve la définition des opérateurs pour la construction d'une formule (propriété) dans la logique temporelle linéaire. Une partie des opérateurs LTL est définie dans la syntaxe de Maude par le module fonctionnel LTL suivant :
fmod LTL is …
*** opérateurs définis de LTL
op _->_ : Formula Formula -> Formula . *** implication op _<->_ : Formula Formula -> Formula . *** equivalence op <>_ : Formula -> Formula . *** eventualy op []_ : Formula -> Formula . *** always op _W_ : Formula Formula -> Formula . *** unless op _|->_ : Formula Formula -> Formula . *** leads-to
op _=>_ : Formula Formula -> Formula . *** strong implication op _<=>_ : Formula Formula -> Formula . *** strong equivalence …
endfm
Les opérateurs LTL sont représentés dans Maude en utilisant une forme syntaxique semblable à leur forme d'origine. Par exemple, l'opération [] est défini dans Maude par l'opérateur (always). Cet opérateur s'applique sur une formule pour donner une nouvelle formule. Nous avons, par ailleurs, besoin d'un opérateur indiquant si une formule donnée est vraie ou fausse dans un certain état. Nous trouvons un tel opérateur (|=) dans un module prédéfini appelé SATISFACTION :
53
fmod SATISFACTION is protecting LTL .
sort State .
op _|=_ : State Formula ~> Bool . endfm
L'état State est générique. Après avoir spécifier le comportement de son système dans un module système ou module rt-maude de Maude, l'utilisateur peut spécifier plusieurs prédicats exprimant certaines propriétés liées au système. Ces prédicats sont décrits dans un nouveau module qui importe deux modules : celui qui décrit l'aspect dynamique du système et le module SATISFACTION. Soit, par exemple, M-PREDS le nom du module décrivant les prédicats sur les états du système :
mod M-PREDS is protecting M .
including SATISFACTION . subsort Configuration < State . …
endm
M est le nom du module décrivant le comportement du système. L'utilisateur doit préciser que
l'état choisi (configuration choisie dans cet exemple) pour son propre système est sous type de type State. A la fin, nous trouvons le module MODEL-CHECKER qui offre la fonction model- Check, ou bien le module prédéfini TIMED-MODEL-CHECKER pour les modules temporisés. L'utilisateur peut appeler cette fonction en précisant un état initial donné et une formule. Le Model Checker de Maude vérifie si cette formule est valide (selon la nature de la formule et la procédure du Model Checker adoptée par le système Maude) dans cet état ou l'ensemble de tous les états accessibles depuis l'état initial. Si la formule n'est pas valide, un contre-exemple (counter-example) est affiché. Le contre-exemple concerne l'état dans lequel la formule n'est pas valide :
fmod MODEL-CHECKER is including SATISFACTION . …
op counterexample : TransitionList TransitionList -> ModelCheckResult [ctor] . op modelCheck : State Formula ~> ModelCheckResult .
… endfm
Pour les modules temporisés, les formules en logique temporelle linéaire (LTL) à vérifier doivent être définies dans un module, spécifié en termes de la logique de réécriture, qui importe le module spécifiant le système à analyser ainsi que le module prédéfini TIMED-MODEL- CHECKER.
Le Modèle-Checker intégré de Maude vérifie automatiquement la validité de la formule LTL en parcourant tous les états accessibles depuis l'état initial spécifié. Si la formule n'est pas valide, un contre-exemple sera généré. Les propositions (qui doivent être paramétrées) doivent être déclarées de sorte Prop, et leur sémantique doit être exprimée par des équations de la forme :
54
Avec b un terme booléen, ce qui signifie que la proposition Prop tient dans tous les états {t} tel que {t} |= prop est évaluée à vraie.
Une formule de la logique temporelle est construite à partir de formules atomiques (temporisées et non temporisées), des constantes True et False et d’opérateurs de la logique temporelle (hormis l’opérateur Next) tels que la négation (¬), la conjonction (/\), la disjonction (\/), until (U), l’opérateur Fatalement (<> ), l’opérateur Globalement ( [] ), …etc. Le tableau 3.2 présente chacun des opérateurs LTL vus dans le chapitre précédent et leur forme respective en Maude. Le symbole "_" représente l'emplacement d'une proposition atomique de LTL.
La commande de model checking (borné dans le temps) se présente avec la syntaxe suivante : (mc t0 |= formule timeLimit .)
Celle-ci vérifie si une formule de la logique temporelle formule tient dans tous les états accessibles à partir de l’état initial t0 et dans la limite de temps timeLimit.
3.6 Conclusion
Nous avons présenté, dans ce chapitre, les notions relatives à la compréhension des concepts de base de la logique de réécriture, du système Maude et de son extension RT-Maude. Dans un premier temps, nous avons présenté l’aspect théorique de la logique de réécriture, qui est basée sur deux concepts théoriques très connus depuis bien longtemps : les systèmes de réécriture et les spécifications équationnelles. Avec ces concepts, la logique de réécriture possède un pouvoir d’abstraction et de description de tout type de système.
Ensuite, nous avons introduit le système Maude qui un langage caractérisé par la simplicité, la performance et l’expressivité. Maude est un candidat idéal pour la spécification de système car il est basé sur une logique très mathématique et dispose d’une forte sémantique et des techniques d’analyses formelles. L’extension RT-Maude est un langage très puissant et très expressif. Il offre un outil pour la spécification formelle, la simulation et l’analyse formelle des systèmes temps réel.
La modélisation avec UML
Sommaire
4.1 Introduction ………...……… 4.2 La modélisation ………...……….. 4.2.1 Les types de modélisation ………..……… 4.2.1.1 Modélisation Informelle ………..……… 4.2.1.2 Modélisation Semi-Formelle ………..………. 4.2.1.3 Modélisation Formelle ………...……….. 4.2.2 La Modélisation Orientée Objet ………..………... 4.3 Historique des méthodes de conception ………..……….. 4.4 UML (Unified Modeling Language) ………...……….. 4.4.1 Les diagrammes UML ………...………. 4.4.2 Extensions d’UML ………..………... 4.4.2.1 Stéréotypes ……...….………..……… 4.4.2.2 Valeurs étiquetées (tagged values) …………..……… 4.4.2.3 Le langage de contraintes OCL (Object Constraints Language) ….… 4.4.3 Vues et diagrammes UML ……….……… 4.4.4 UML et Cycle de développement ………..………. 4.4.5 Diagramme d’états-transitions ………..………. 4.5 Processus de développement ………..………... 4.5.1 Méthode Processus Unifié (UP) ………..……...… 4.5.2 Méthode 2 Tracks Unified Process (2TUP) ……….……….. 4.6 Conclusion ………...……….. 55 55 55 56 56 56 57 57 58 58 62 62 63 63 63 64 65 71 71 72 73
55 4.1 Introduction
La tâche de conception des systèmes a toujours besoin d’un langage ou d’une méthode de spécification et de modélisation pour créer et analyser des modèles et communiquer avec les collaborateurs et les clients.
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés et identifiés, définis par des propriétés. Une propriété est soit un attribut soit une entité élémentaire comportementale de l’objet. La fonctionnalité du système émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités de cette approche est qu’elle encapsule les données et leurs traitements associés au sein d’un unique objet. C’est dans ce contexte que nous présentons quelques éléments du langage UML qui s’est imposé comme un standard que rencontrent tous les développeurs dans l’industrie du génie logiciel.