HAL Id: hal-02481632
https://hal.archives-ouvertes.fr/hal-02481632
Submitted on 17 Feb 2020HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
L’Art de la Spécification Valide
Michel Lemoine
To cite this version:
Michel Lemoine. L’Art de la Spécification Valide. [Rapport de recherche] ONERA Document intérieur, N.T. 5/7084/MH, novembre 1970. 2020. �hal-02481632�
L’Art de la Sp´ecification Valide
Michel Lemoine
17 f´
evrier 2020
Table des mati`
eres
1 VALID en r´esum´e 5
1.1 But de VALID . . . 5
1.2 Les principes sur lesquels repose VALID . . . 5
1.3 Le processus de VALID . . . 7
1.3.1 Goal Oriented Requirement Engineering (GORE) . . . 8
1.3.2 Les diagrammes UML . . . 9
1.3.3 OCL : Object Constraint Language . . . 10
1.4 Documents construits avec VALID . . . 11
2 Les notations utilis´ees dans VALID 12 2.1 KAOS - OBJECTIVER . . . 12
2.1.1 Pourquoi KAOS/Objectiver . . . 13
2.1.2 Notations KAOS/Objectiver . . . 14
2.1.3 Processus de construction des mod`eles Objectiver . . . 16
2.2 Notations UML utilis´ees . . . 17
2.2.1 R`egles de transformation de diagrammes de responsabilit´e en classes UML 17 2.2.2 D´etails s´emantiques sur les diagrammes de classe et les diagrammes ´etats transitions . . . 18
2.2.3 Apport de la mod´elisation statique et dynamique ”`a-la-UML” . . . 20
2.3 Sp´ecification du syst`eme avec OCL . . . 20
3 L’outillage support de VALID 23 3.1 Outillage support de GORE . . . 23
3.2 Outillage support d’UML . . . 23
3.3 Outillage support d’OCL . . . 23
3.4 Illustration de VALID `a l’aide d’un exemple simple . . . 24
3.4.1 URD et SRD d’un mini syst`eme de gestion bancaire . . . 24
3.4.2 Identification des propri´et´es . . . 29
3.4.3 Codage en OCL . . . 30
3.4.4 Premi`eres conclusions . . . 31
4 Smartphone 32 4.1 URD d’un smartphone sˆur de fonctionnement . . . 32
4.2 Cahier des charges et mod`eles Objectiver . . . 34
4.2.1 Niveau initial . . . 35
4.2.2 Communication t´el´ephonique . . . 36
4.2.3 Autres fonctionnalit´es . . . 38
4.2.4 Authentification . . . 39
4.2.6 Introduction d’un code . . . 41
4.2.7 Gestion des informations partag´ees . . . 42
4.2.8 Vente smartphone . . . 43
4.3 Diagramme de classe du smartphone . . . 44
4.3.1 Etape 1 : identification des classes . . . .´ 44
4.3.2 Etape 2 : identification des op´´ erations des classes . . . 44
4.3.3 Etape 3 : identification des attributs des classes . . . .´ 45
4.3.4 Etape 4 : identification des relations . . . .´ 45
4.3.5 Etape 5 : repr´´ esentation graphique du smartphone . . . 45
4.3.6 Etape 6 : ´´ evaluation du diagramme de classes . . . 47
4.4 Sp´ecification en OCL du smartphone . . . 48
4.4.1 Sp´ecification de la classe ”gestionEmpreinte” . . . 49
4.4.2 Code OCL de la classe ”gestionnaireCode” . . . 52
4.4.3 Sp´ecification de la classe ”gestionServices” . . . 53
4.4.4 Sp´ecification de la classe ”gestionInformation” . . . 53
4.4.5 Sp´ecification de la classe ”CarteM`ere” . . . 54
5 En mati`ere de conclusion 55
A Appendix ”gestion bancaire” 56
Table des figures
1.1 Paradigme d’Abrial et Schuman . . . 6
1.2 Processus de VALID . . . 7
2.1 Mod`ele de buts . . . 14
2.2 Mod`ele de responsabilit´e . . . 15
2.3 Processus Objectiver . . . 16
2.4 Un exemple de diagramme de classes . . . 18
2.5 Diagramme ´etats-transitions de la classe ”Administrateur Annuaire” . . . 19
3.1 Diagramme de plus haut niveau pour les comptes bancaires . . . 24
3.2 Diagramme de raffinement de la gestion des comptes. . . 25
3.3 Diagramme de raffinement de la gestion des personnes. . . 26
3.4 Diagramme global `a ´eviter . . . 27
3.5 Diagramme de classes des comptes bancaires provenant de USE. . . 31
4.1 SmartPhone au plus haut niveau . . . 35
4.2 Appeler ou recevoir un appel . . . 36
4.3 Appeler ou recevoir un appel . . . 37
4.4 Autres fonctionnalit´es . . . 38
4.5 Authentification . . . 39
4.6 Lecture d’empreinte . . . 40
4.7 Lecture de code . . . 41
4.8 Tout ce qui concerne la gestion des informations partag´ees . . . 42
4.9 R´einitialisation du smartphone . . . 43
4.10 Diagramme de classe du smartphone . . . 46
Avertissement : L’art de la sp´ecification valide, titre ˆo combien pompeux, n’est que le sinc`ere hommage rendu `a Donald Knuth pour ses ouvrages sur The Art of Programming.
Un titre plus modeste est : “VALID : une m´ethodologie pour la sp´ecification for-melle”, sachant que le terme m´ethodologie est utilis´e ici comme “un ensemble de m´ethodes”.
Le texte est compos´e de 5 chapitres et de 2 annexes.
— Le chapitre 1 est un r´esum´e de la m´ethodologie VALID. Il pr´esente les principes et le processus sous-jacent.
— Le chapitre 2 est relatif aux notations tr`es utilis´ees que sont Objectiver, UML et OCL. Ces notations sont relatives `a 3 domaines :
— la r´edaction des cahiers de charge avec Objectiver, — la conception et mod´elisation d’une solution en UML,
— la sp´ecification de la solution envisag´ee avec OCL (Object Constraint Language). — Le chapitre 3 d´etaille l’outillage disponible.
Il est `a remarquer que tous les outils propos´es sont gratuits dans tout contexte `a but non lucratif. Ce chapitre propose ´egalement un exemple simple couvrant tout le processus de VALID.
— Le chapitre 4 pr´esente un exemple plus cons´equent li´e `a un objet que tous les lecteurs poss`edent : un smartphone, poss´edant de bonnes propri´et´es.
— Le chapitre 5 est une br`eve conclusion sur la m´ethodologie propos´ee par VALID. — L’annexe concerne les cahiers des charges g´en´er´es avec Objectiver pour les exemples
pr´esent´es aux chapitres 3 et 4.
Le lecteur uniquement soucieux de comprendre ce qu’est la notion de sp´ecification formelle lira le chapitre 1, alors que le lecteur soucieux de d´evelopper des sp´ecification formelles devra maˆıtriser les autres chapitres.
1
VALID en r´
esum´
e
1.1
But de VALID
VALID est une m´ethodologie1 permettant de passer d’un cahier des charges du client `a une
sp´ecification rigoureuse du syst`eme `a d´evelopper.
Qui doit d´evelopper une sp´ecification `a partir du cahier des charges du client ? Ce n’est certainement pas le client (MOA) : il a des besoins, un budget et ce n’est ni son travail ni dans sa capacit´e `a d´evelopper le futur syst`eme.
Ce n’est pas non plus le rˆole de la maˆıtrise d’œuvre (MOE) qui ne doit pas ˆetre juge et partie : elle doit d´evelopper le syst`eme une fois qu’elle se sera mis d’accord avec la MOA sur les objectifs et le budget !
Id´ealement il faudrait faire intervenir une Assistance `a la Maˆıtrise d’Ouvrage (AMOA), ´
equipe pluridisciplinaire qui doit `a la fois maˆıtriser les probl`emes du client et avoir de tr`es bonnes comp´etences informatiques, afin de faire valider par la MOA les besoins, et pr´esenter `a la MOE une premi`ere sp´ecification rigoureuse du syst`eme `a d´evelopper.
1.2
Les principes sur lesquels repose VALID
Les principes sur lesquels repose VALID viennent de deux sources compl´ementaires : d’un cˆot´e les aspects traditionnels du d´eveloppement prˆon´es par le G´enie Logiciel (Software Engi-neering - SE) et de l’autre cˆot´e du paradigme de J.R. Abrial et S. Schuman.
Pour ce qui est du G´enie Logiciel une source int´eressante est le SWEBOK2. Cet ouvrage est disponible `a www.swebok.org de l’IEEE. C’est une excellente compilation de tout le vo-cabulaire n´ecessaire au d´eveloppement des Syst`emes `a Logiciel Pr´epond´erant (SLP). Il offre ´
egalement une tr`es bonne vision des probl`emes et solutions potentielles associ´ees, ainsi qu’une imposante bibliographie. Un autre ouvrage francophone tr`es int´eressant est le livre d’A. Stroh-meier3 intitul´e G´enie logiciel : principes, m´ethodes et techniques.
Le G´enie Logiciel prˆone l’utilisation d’un cycle de vie (Software Life Cycle - SLC) ad hoc pour d´evelopper tout SLP. Quel que soit le SLC choisi, un certain nombre d’´etapes s´equentielles s’enchaˆınent, chacune ayant une ou plusieurs entr´ees et g´en´erant une ou plusieurs sorties. La principale faiblesse des SLC est li´ee au fait que les documents en sortie de chaque ´etape ne sont jamais garantis comme ´etant conformes aux documents en entr´ee. C’est pour cette raison que d`es
1. M´ethodologie est ici pris dans le sens d’ensemble de m´ethodes et de techniques d’un domaine particulier. 2. Guide to the Software Engineering Body of Knowledge Fundamental Algorithms, P. Bourque et R.E. Fairley, 2014
3. G´enie logiciel : principes, m´ethodes et techniques, Presses polytechniques et universitaires romandes, A. Strohmeier et D. Buchs, 1996
le d´ebut des ann´ees 70 J.R. Abrial4 et S. Schuman ont propos´e un paradigme qui se r´esume en
“Programmer, c’est prouver”. En d’autres termes il faut montrer que le document produit lors d’une certaine transformation est conforme au document en entr´ee. En math´ematique traditionnelle, on repr´esente ce paradigme par le sch´ema de la figure 1.1.
Figure 1.1 – Paradigme d’Abrial et Schuman
Une formule devient un th´eor`eme si on exhibe une preuve i.e. si la formule est d´eductible des axiomes `a l’aide de r`egles d’inf´erence.
J.R. Abrial et S. Schuman ont propos´e les analogies suivantes : — “Preuve” et “D´eveloppement”
— “Axiomes” et “Sp´ecification ou Cahier des charges du client” — “Th´eor`eme” et “Programme ou Sp´ecification du syst`eme”.
Ce paradigme est ´et´e largement mis en pratique `a travers des m´ethodologies (quasi) in-dustrielles comme celle propos´ee par RODIN5 (Rigorous Open Development Environment for Complex System). La seule limitation r´eside dans le fait que l’on part d’une sp´ecification sup-pos´ee ˆetre correcte. Or en G´enie Logiciel traditionnel, mˆeme en utilisant des m´ethodes tr`es ´
eprouv´ees, la sp´ecification initiale demeure un texte en langue naturelle, repr´esentant ce que souhaite le client. Et rien ne permet de garantir que ce texte en langue naturelle est bien repr´esentatif des v´eritables besoins du client.
Notre proposition pour VALID consiste `a combler ce trou, `a savoir la capacit´e `a d´evelopper une premi`ere sp´ecification valid´ee des besoins du client.
Comment valider les besoins du client ?
Une solution bien accept´ee consiste `a construire une sp´ecification rigoureuse du sys-t`eme `a d´evelopper.
Nous ne pr´etendons pas que le passage du cahier des charges initial du client `a une sp´ ecifi-cation rigoureuse du syst`eme `a d´evelopper est simple car le texte initial en langue naturelle est par d´efinition tr`es informel alors qu’une sp´ecification rigoureuse est tr`es formelle. C’est pour cette raison que nous introduisons dans VALID les moyens de rajouter, au fur et `a mesure des transformations, la s´emantique rendant la sp´ecification de plus en plus rigoureuse, tout en permettant de v´erifier que chaque ´etape est correcte.
Le lecteur curieux pourrait poser la question : comment valider une sp´ecification ri-goureuse, voire formelle ?
Nous utilisons la m´ethode traditionnelle de reverse-engineering qui consiste `a traduire le texte formel en texte informel, traduction faite par l’AMOA. Autant le passage de l’informel au formel n´ecessite une m´ethode tr`es rigoureuse6, autant le passage inverse est facile et les ´eventuelles
4. Jean-Raymond Abrial, ”Data Semantics”. In Klimbie and Koffeman (eds), Data Base Management, North-Holland, pp. 1–59.
5. http ://rodin.cs.ncl.ac.uk/ 6. C’est l`a l’objet de VALID.
erreurs induites sont imm´ediatement d´etect´ees lors d’une simple relecture par l’AMOA et la MOE
1.3
Le processus de VALID
Comment passer d’un cahier des charges du client `a une sp´ecification rigoureuse du syst`eme `a d´evelopper ?
Le processus propos´e par VALID est d´ecrit dans la figure 1.2. Il fait apparaˆıtre 3 traitements s´equentiels et 5 documents.
Figure 1.2 – Processus de VALID
Acronym (en) Definition (en) D´efinition
URD User Requirements Document Cahier des charges du client
GORE Goal Oriented Requirements
Engineering
Ing´enierie des Besoins par les Buts V & V Verification : Am I building the
right system ?
Validation : est-ce que je construis le bon syst`eme ?
Validation : Am I building the system right ?
V´erification : est-ce que je construis le syst`eme correctement ?
UML Design Unified Modelling Language Design
Conception avec les notations UML
SRD System Requirements
Docu-ment
Cahier des charges du Syst`eme `a D´ e-velopper
OCL Specification Object Constraint Language Specification
Sp´ecification avec la notation OCL Class Diagram Static view of classes Diagramme de classes, support de
l’Architecture Statique du Syst`eme State-transition
diagrams
Class automata Diagramme ´etats-transition de
chaque classe
Notez bien les faux amis que sont les termes “Validation and Verification” en anglais versus “V´erification et Validation” en fran¸cais !
1.3.1
Goal Oriented Requirement Engineering (GORE)
Le 1er traitement fait r´ef´erence `a la technologie GORE qui permet de repr´esenter des buts,
qu’ils soient fonctionnels ou non fonctionnels. De nombreuses m´ethodologies rigoureuses existent : nous avons retenu KAOS. Deux raisons justifient ce choix :
— en premier la m´ethode est pr´esent´ee dans l’ouvrage7 remarquable d’Axel Van
Lam-sweerde ;
— en deuxi`eme le fait que KAOS en tant que m´ethode est support´e par un outil commercial : Objectiver8.
Le document en entr´ee de GORE est le cahier des charges initial (URD) fourni par le client. Il est suppos´e contenir l’expression de ses besoins. `A noter que si ce cahier des charges n’existe pas, il faudra d’une mani`ere ou d’une autre le cr´eer afin d’avoir un document initial d’entr´ee auquel se r´ef´erer.
L’objectif de GORE est de permettre de transformer l’URD d’entr´ee en un document de sortie que nous appellerons le cahier des charges revisit´e ou cahier des charges du sys-t`eme `a d´evelopper (SRD). Ce dernier contient `a la fois un texte et une suite de mod`eles, constituant une 1e formalisation du syst`eme `a d´evelopper. Il est important que le texte du
ca-hier des charges revisit´e soit conforme `a un standard pour les cahiers des charges, comme par exemple l’IEEE 8309.
Pour ce qui est de la suite des mod`eles, elle repr´esente une 1esp´ecification semi formelle du
syst`eme `a d´evelopper. La technologie GORE est particuli`erement importante car elle permet de commencer `a concevoir le syst`eme `a d´evelopper.
Le SRD qui est un document en sortie doit id´ealement poss´eder 3 propri´et´es :
7. Axel Van Lamsweerde, Requirements Engineering, From System Goals to UML Models to Software Spe-cifications, 2009, Addison-Wesley
8. http ://objectiver.com
— il doit ˆetre complet, i.e. il doit explicitement contenir tous les besoins (fonctionnels et non fonctionnels) du client ;
— il doit ˆetre coh´erent, i.e. il ne doit y avoir aucune contradiction entre les besoins ; — et enfin il faut que tous les besoins puissent ˆetre satisfaits, i.e. soient implantables avec
les technologies disponibles au moment de la r´edaction du cahier des charges.
L’obtention de ces 3 propri´et´es est indispensable si l’on veut d´evelopper un syst`eme valide. En effet le cahier des charges initial contient beaucoup d’implicite et est donc particuli`erement incomplet ! Qui plus est, les besoins du client sont la concat´enation de nombreux besoins ex-prim´es par ses diff´erentes parties prenantes. Et cet ensemble de besoins contient tr`es souvent de nombreuses contradictions. Dernier point `a ne pas n´egliger : le client veut certainement voir son syst`eme implant´e ! Pour cela il dispose d’un budget et il est donc essentiel que le cahier des charges revisit´e puisse ˆetre implant´e ou, si l’on ne peut pas, il faut pouvoir expliquer pourquoi certaines fonctionnalit´es ou non fonctionnalit´es (i.e. buts ou contraintes) ne peuvent pas l’ˆetre.
1.3.2
Les diagrammes UML
Le 2e traitement du processus de VALID est celui qui nous fait passer d’un cahier des
charges revisit´e (texte et ensemble de mod`eles) `a une premi`ere architecture du syst`eme. En effet, apr`es avoir bien d´efini ce que devra satisfaire le syst`eme `a d´evelopper, il faut ˆetre capable de mod´eliser le syst`eme sous une forme exclusivement fonctionnelle car il ne faut pas oublier qu’un ordinateur, malgr´e tous les progr`es r´ealis´es depuis le d´ebut de l’informatique, est surtout apte `a transformer (i.e. traiter) des donn´ees en d’autres donn´ees. Cela revient `a dire que les aspects fonctionnels et non fonctionnels du cahier des charges revisit´e doivent tous ˆetre convertis en fonctions ou traitements. Si cela ne pose pas de difficult´e majeure pour les aspects fonctionnels du cahier des charges revisit´e, il y a n´ecessit´e `a transformer les non fonctionnalit´es ou contraintes du syst`eme `a d´evelopper en fonctionnalit´es.
Comment faire cela ?
Une solution, maintenant bien accept´ee en informatique, consiste `a construire, via des no-tations appropri´ees, une repr´esentation statique et dynamique du syst`eme. La repr´esentation statique doit permettre d’identifier quels sont les composants du syst`eme et leurs relations, la repr´esentation dynamique doit quant `a elle permettre d’exprimer le comportement de chaque composant.
Ayant mod´elis´e de fa¸con tr`es abstraite les aspects statique et dynamique d’un syst`eme, il est alors possible de r´epondre `a la question : est-ce cela que souhaite le client ? Et il est clair que la notation UML10 offre de r´eelles possibilit´es, si l’on sait se restreindre, dans les
diagrammes `a utiliser.
Nous avons choisi deux types de diagramme : — le diagramme de classes du syst`eme ;
— et le diagramme ´etats-transitions de chaque classe du diagramme de classe.
Ces deux types de diagrammes vont permettre d’avoir une vision statique et dynamique de l’architecture m´etier11 du syst`eme `a d´evelopper.
Comment passer du cahier des charges revisit´e `a l’architecture du syst`eme ? Le cahier des charges revisit´e contient, par d´efinition et de fa¸con textuelle, toutes les fonction-nalit´es et contraintes `a satisfaire. Ces fonctionnalit´es et contraintes sont (th´eoriquement) toutes
10. Les notations UML sont suppos´ees ˆetre largement connues !
11. Nous parlons de l’architecture m´etier du syst`eme `a d´evelopper car il ne s’agit pas encore d’implanter le syst`eme. De ce fait le vocabulaire utilis´e est encore le vocabulaire du client. Bien ´evidemment le d´eveloppement par la MOE du syst`eme transformera chacune des classes m´etier en des classes informatiques.
traduites en termes de traitements (i.e. op´erations). Nous proposons de regrouper les op´erations en classes, au sens traditionnel de l’Orient´e Objet. En d’autres termes, la mod´elisation du cahier des charges revisit´e permet d’identifier des op´erations que l’on regroupe en classes, responsables d’une ou plusieurs op´erations ou fonctionnalit´es. Bien ´evidemment le regroupement ne se fait pas au hasard : il est guid´e par la m´ethode choisie pour mod´eliser le cahier des charges revisit´e. En particulier il faut introduire dans l’architecture du syst`eme les mod`eles des entit´es sur lesquelles les op´erations (exigences ou attentes) agissent. On dira plus simplement qu’il ne faut pas oublier de repr´esenter les donn´ees manipul´ees. Le diagramme de classes r´esultant comportera donc d’une part les agents du syst`emes et de l’environnement, et d’autre part les donn´ees manipul´ees par ces agents.
Le passage des aspects statiques aux aspects dynamiques se fait de fa¸con traditionnelle via l’introduction d’un automate qui permet de d´ecrire, pour une classe donn´ee, comment ses op´erations s’enchaˆınent les unes les autres.
Les deux types de diagrammes UML cr´e´es vont ainsi `a leur tour ´etendre les propri´et´es du cahier des charges revisit´e. On se retrouve donc avec des mod`eles plus complets, coh´erents et implantables.
1.3.3
OCL : Object Constraint Language
Le 3e traitement pr´econis´e par VALID est celui qui va donner une s´emantique aux
fonc-tionnalit´es identifi´ees lors de la mod´elisation du cahier des charges revisit´e. Il faut bien se rappeler qu’une mod´elisation UML tant statique que dynamique fait apparaˆıtre d’une part les ´
el´ements manipul´es (ici des classes au sens de l’Orient´e Objet) et d’autre part des identificateurs d’op´erations12, ces derni`eres n’ayant a priori aucune signification particuli`ere, en dehors de la
vraisemblance syntaxique que l’AMOA a bien voulu lui donner. L’´etape “Sp´ecification en OCL” consiste justement `a donner une 1re signification `a chaque op´eration i.e. `a pr´eciser comment les
op´erations font ´evoluer les ´el´ements manipul´es Quelle technique peut-on utiliser ?
Celle que nous proposons a ´et´e promue il y a maintenant longtemps par C.A.R. Hoare (plus souvent appell´e T. Hoare) avec la notion de pr´e- et post-conditions et invariants, notions que l’on retrouve dans des langages de programmation orient´es objets de haut niveau comme Eiffel et JML. L’int´erˆet de l’utilisation d’un tel style est que l’on n’exprime pas seulement le “comment” mais ´egalement le “quoi”. En d’autres termes on ne d´eveloppe pas seulement un algorithme pour une op´eration donn´ee mais ´egalement les propri´et´es que cette op´eration respecte ou conf`ere au syst`eme, selon le cas. Et c’est l`a le but ultime d’une sp´ecification du syst`eme `a d´evelopper. En effet, tout syst`eme poss`ede un certain nombre de propri´et´es. C’est `a partir de l’expression de ces propri´et´es que l’on pourra exprimer en “quoi” une op´eration, quelle qu’elle soit, respecte les propri´et´es du syst`eme.
Il faut surtout ne pas oublier que certaines contraintes provenant du cahier des charges revisit´e, mˆeme si elles ont ´et´e toutes transform´ees en fonctionnalit´es, peuvent ˆetre traduites en propri´et´es du syst`eme. Ce faisant on pourra ´etablir une tra¸cabilit´e entre les contraintes initiales du cahier des charges et les fonctionnalit´es implantables.
Une difficult´e potentielle est relative `a l’identification des propri´et´es du syst`eme `a d´evelopper. En effet, un invariant du syst`eme n’est rien d’autre qu’une propri´et´e, en g´en´eral exprim´ee en logique. D’o`u la difficult´e inh´erente `a l’approche formelle, et donc en particulier `a VALID :
12. Attention au vocabulaire. Dans une mod´elisation de diagrammes avec UML on parle d’op´erations ou de services, pas de m´ethodes ! Ce dernier vocabulaire est r´eserv´e `a l’implantation !
quelles sont les propri´et´es du syst`eme ? Il est clair que certaines sont ´evidentes `a la lecture de l’URD ou du SRD. La difficult´e r´eside dans l’identification de toutes les propri´et´es !
La derni`ere difficult´e `a r´egler est celle de la notation `a utiliser.
Nous avons port´e notre choix vers OCL car ce langage formel est volontairement simple d’acc`es et repr´esente un juste milieu entre langage naturel et langage math´ematique. Il permet ainsi de limiter les ambig¨uit´es dans la sp´ecification des contraintes logicielles. Sa grammaire simple lui permet d’ˆetre interpr´et´e par des outils logiciels pour faire de la programmation par contrat et v´erifier qu’un logiciel r´epond `a ses sp´ecifications techniques. En particulier, OCL permet de manipuler des invariants dans un mod`ele, sous forme de pseudo-code :
— pr´e et postconditions pour une op´eration ; — expressions de navigation ;
— expressions bool´eennes ; — etc.
Une autre raison du choix d’OCL est qu’il est utilis´e dans la d´efinition du m´etamod`ele UML. `
A se rappeler : la programmation par contrat de B. Meyer d´erive de la logique qu’avait postul´ee T. Hoare !
1.4
Documents construits avec VALID
Tel que pr´esent´e dans l’illustration 1.2, VALID prend en entr´ee un cahier des charges client et permet de g´en´erer en final une sp´ecification rigoureuse du syst`eme `a d´evelopper.
Cette sp´ecification est compos´ee d’une part du texte (conforme `a un certain standard) du cahier des charges revisit´e, d’autre part de 3 types de diagrammes :
1. un diagramme de classes m´etier repr´esentatif de l’architecture statique du syst`eme `a d´evelopper ;
2. un ensemble de diagrammes ´etats-transitions, un diagramme par classe ;
3. et pour chaque classe, un texte OCL contenant (´eventuellement) des invariants de classe, et pour chaque op´eration de classe sa s´emantique en termes de pr´e- et post-conditions. Dans la pratique le niveau de d´etails de la sp´ecification ainsi construite sera tr`es fortement coupl´e au texte du cahier des charges revisit´e. En d’autres termes, plus ce dernier sera d´etaill´e et complet et coh´erent, plus la sp´ecification sera d´etaill´ee. Cela revient `a dire que la 1e´etape de
VALID est essentielle. Qui plus est, c’est cette ´etape qui pr´ecise les contraintes que le syst`eme `a d´evelopper doit respecter ! Il est clair que plus on pourra transformer les contraintes en termes de fonctionnalit´es, meilleure sera la sp´ecification.
Il ne faut cependant pas croire que cette transformation sera toujours simple : il restera des cas o`u l’on ne saura pas faire, et ce sera alors le rˆole de la MOE de demander `a la MOA de mieux pr´eciser les contraintes de son syst`eme.
En particulier les non fonctionnalit´es identifi´ees dans l’URD initial devraient ˆetre toutes traduites en fonctionnalit´es ou en propri´et´es. Il est imp´eratif de v´erifier que ce sera le cas et montrer, via de la tra¸cabilit´e que toute contrainte initiale se traduit soit par une fonctionnalit´e, soit par une propri´et´e du syst`eme `a implanter.
2
Les notations utilis´
ees dans VALID
Le 2e chapitre de VALID pr´esente bri`evement les notations choisies et pour chacune d’elles
donne un aper¸cu de la m´ethode sous-jacente `a utiliser pour transformer les documents d’entr´ee en documents de sortie.
2.1
KAOS - OBJECTIVER
Nous introduisons ci-apr`es un glossaire r´ecapitulatif du vocabulaire utilis´e pour GORE par Objectiver.
Id. Description Alias (en)
attente but terminal assign´e `a un agent de l’environnement expectation agent objet actif r´ealisant des op´erations pour atteindre des
buts
Objectiver distingue les agents du syst`eme (uniquement responsable d’exigences) et les agents de l’environne-ment (uniquel’environne-ment responsable d’attentes)
agent
but, sous-but, objectif, besoin
assertion prescriptive capturant un objectif `a satisfaire par la coop´eration d’agents.
Les exigences et les attentes sont des cas particuliers de buts
goal, need
but fonction-nel
un but est qualifi´e de fonctionnel quand il correspond `a un traitement traduisible par un algorithme
functional goal but non
fonc-tionnel
un but est consid´er´e comme non fonctionnel quand il d´ e-crit une propri´et´e du syst`eme (comme par exemple s´ ecu-rit´e, performance, ...) ou quand il d´ecrit une contrainte `
a satisfaire pour d´evelopper le syst`eme (choix impos´e du langage de programmation, ...)
constraint, operational constraint
conflit un conflit entre buts existe si sous une certaine condi-tion, les buts ne peuvent ˆetre r´ealis´es tous ensemble
conflict exigence but terminal assign´e `a un agent du logiciel en consid´
e-ration, i.e. `a d´evelopper
requirement obstacle condition, (autre qu’un but) dont la satisfaction peut
empˆecher certains buts d’ˆetre atteints ; tout obstacle d´ e-finit un ensemble de comportement non souhait´es
Id. Description Alias (en) propri´et´e du
domaine
invariant du domaine ou hypoth`ese. Un invariant du do-maine est une propri´et´e que l’on sait vraie dans chaque ´etat d’´el´ements du domaine, par exemple une loi phy-sique.
Une hypoth`ese est une propri´et´e sur un ´el´ement du do-maine suppos´ee vraie
domain property
raffinement relation liant un but `a d’autres buts appel´es ses sous-buts.
La conjonction (raffinement ET) de tous les sous-buts constitue une condition n´ecessaire pour garantir le but raffin´e.
La disjonction (raffinement OU) de sous-buts stipule que la satisfaction d’un seul sous-but suffit `a satisfaire le but p`ere.
refinement
responsabilit´e relation entre un agent et une exigence ou une attente responsibility
2.1.1
Pourquoi KAOS/Objectiver
Pour ce qui est de la capture des besoins nous avons choisi la m´ethode KAOS support´ee par l’outil industriel Objectiver. La raison de ce choix est triple :
— une notation simple ;
— une m´ethode sous-jacente efficace ;
— et surtout la possibilit´e de d´efinir un cahier des charges revisit´e ayant les propri´et´es requises, `a savoir compl´etude, coh´erence et satisfiabilit´e.
Explications
— Dans l’article ancien de G. A. Miller1 intitul´e ”The magical number seven, plus or minus
two : Some limits on our capacity for processing information” il a ´et´e (d´e)montr´e que si l’on veut maˆıtriser une notation, quelle qu’elle que soit, il faut que le nombre de concepts consi-d´er´es soit petit. 7(+/-2) est ce fameux nombre magique. Et de ce point de vue, comme on peut le voir dans les mod`eles des buts et des responsabilit´es de KAOS/Objectiver pr´esent´es ci-apr`es le nombre de concepts est tr`es restreint.
— La m´ethode de d´eveloppement de KAOS/Objectiver pr´econise de partir des objectifs (buts ou besoins, vocabulaire ´equivalent) client de plus haut niveau et de les raffiner en une ou plusieurs arborescences. Le raffinement consiste `a d´ecomposer chaque but en un ensemble de sous-buts plus simples `a satisfaire. On retrouve implicitement les principes introduits dans le monde de l’informatique d`es 1971 par N. Wirth dans Program Development by Stepwise Refinement. Les feuilles des arborescences sont les buts de plus bas niveau. Elles sont appel´ees ATTENTE ou EXIGENCE. Les EXIGENCES sont des buts `a imp´erativement implanter. Les ATTENTES sont ´egalement des buts mais leur satisfaction est laiss´ee `a l’ext´erieur du syst`eme. Il est essentiel de comprendre que ce qui sera `a implanter est l’ensemble des feuilles des arborescences, pas du tout les buts et sous-buts interm´ediaires. L’efficacit´e de la m´ethode KAOS est li´ee en particulier au fait que l’on arrˆete de raffiner d`es que le sous-but consid´er´e peut ˆetre traduit par un algorithme ou une fonctionnalit´e que l’on saura facilement implanter.
— Propri´et´es des arborescences. Nous avons ´ecrit qu’un cahier des charges revisit´e doit ˆetre complet (i.e. tous les besoins ont ´et´e envisag´es), coh´erent (absence de contradiction
entre les besoins) et satisfiable (on sait implanter). Ces 3 propri´et´es sont atteignables avec KAOS/Objectiver. La compl´etude est obtenu via d’une part le raffinement ET ou OU et d’autre part via la notion d’obstacles. Ce concept introduit par Axel Van Lamsweerde dans son livre Requirements Engineering consiste `a identifier si pour chaque sous-but il y a des conditions qui font qu’un sous-but ne serait pas atteignable. Comme l’identification de ces obstacles est sous une forme logique math´ematique, on peut ais´ement garantir que toutes les conditions peuvent ˆetre identifi´ees, donc que le syst`eme sera complet. Bien ´evidemment l’identification de ces obstacles conduit `a introduire de nouveaux sous-buts pour pallier, autant que possible, les obstacles !
La coh´erence est plus difficile `a mettre œuvre. En effet elle d´epend de l’identification dans les arborescences de buts manifestement en contradiction. Ce travail ne peut ˆetre r´ealis´e que par analyse de la s´emantique des diff´erents buts repr´esent´es dans les arbores-cences. Ces derni`eres pouvant ˆetre tr`es grandes, il n’est pas toujours simple de d´ecouvrir les contradictions potentielles. Il existe heureusement un moyen rigoureux de d´emontrer la coh´erence. Ce moyen s’appuie sur les m´ethodes formelles qui consistent `a mod´eliser le syst`eme complet sous forme de propri´et´es math´ematiques exprim´ees en utilisant une logique.
Quelle logique ? Diverses logiques sont utilisables. La plus utilis´ee est la logique des pr´ e-dicats du 1erordre. Elle est en g´en´eral suffisante !
Enfin, la satisfiabilit´e est simple `a garantir car la construction des arborescences suppose que les feuilles sont implantables. Si tel n’´etait pas le cas, cela signifierait que l’arbores-cence est infinie !
2.1.2
Notations KAOS/Objectiver
Nous redonnons ci-apr`es la signification des notations utilis´ees dans les mod`eles de buts et les mod`eles de responsabilit´es.
Figure 2.1 – Mod`ele de buts Concepts manipul´es dans le mod`ele des buts
— BUT : but, sous-but Un but permet d’exprimer un objectif fonctionnel ou non fonc-tionnel que le syst`eme doit satisfaire.
ATTENTE et EXIGENCE sont des buts terminaux, i.e. des buts non raffin´es par convention. Une ATTENTE est un but assign´e `a un agent de l’environnement. Une EXIGENCE est un but assign´e `a un agent du syst`eme, i.e. du syst`eme `a d´evelopper.
— PROPRIETE DU DOMAINE
Une propri´et´e du domaine repr´esente un invariant du domaine ou une hypoth`ese. Un invariant du domaine est une propri´et´e vraie pour un certain ´el´ement du syst`eme alors qu’une hypoth`ese est une propri´et´e que l’on suppose toujours vraie.
— OBSTACLE
Condition autre qu’un but qui peut empˆecher certains buts d’ˆetre atteints : ils peuvent ´egalement d´efinir des comportements non souhait´es. Les obstacles sont des ´el´ements es-sentiels d’une analyse des risques du logiciel `a d´evelopper.
— CONFLIT (repr´esent´e par un zigzag rouge)
C’est une relation entre 2 buts, relation traduisant le fait que les 2 buts en conflit ne peuvent ˆetre r´ealis´es en mˆeme temps. `A ne pas confondre avec les obstacles ! Un conflit traduit souvent le fait qu’il manque de l’information dans le cahier des charges initial. — Relation entre buts : raffinement de but
Tout but non terminal se raffine en une arborescence. L’arborescence comprend des raf-finements ET, et/ou des rafraf-finements OU.
Raffinement ET : une seule sous-arborescence (seul le raffinement ET est repr´esent´e dans le mod`ele de buts de la figure 2.1). Une arborescence ET traduit le fait que le but de plus haut niveau (i.e. le but p`ere) est satisfait par le ET (condition suffisante) de tous ses sous-buts.
Raffinement OU : d’un but p`ere partent plusieurs sous-arborescences.
Le raffinement OU traduit le fait que la satisfaction de l’une des sous-arborescences est suffisante `a satisfaire le but de plus haut niveau.
— Relation entre obstacle et but : obstruction et r´esolution
Une obstruction (repr´esent´ee par une fl`eche `a extr´emit´e rouge) est une relation qui va d’un obstacle vers un but : une obstruction empˆeche la r´ealisation d’un but.
Une r´esolution (repr´esent´ee par une fl`eche `a extr´emit´e verte) est une relation qui va d’un but vers un obstacle : une r´esolution est l’introduction d’un (nouveau) (sous-)but afin d’annihiler/amoindrir les effets d’un obstacle.
Figure 2.2 – Mod`ele de responsabilit´e Concepts manipul´es dans le mod`ele des responsabilit´es — Agent
C’est un ´el´ement actif du syst`eme r´ealisant (i.e. satisfaisant) des buts terminaux (AT-TENTE ou EXIGENCE).
C’est l’agent que la MOE devra mettre en place pour satisfaire des EXIGENCEs. 2. Agent de l’environnement
C’est l’agent externe au syst`eme MAIS dont la pr´esence est indispensable afin de satisfaire les ATTENTEs.
— Relation entre agent et buts
Il s’agit d’assignation de responsabilit´e entre un agent du syst`eme et une exigence, un agent de l’environnement et une attente.
2.1.3
Processus de construction des mod`
eles Objectiver
Il est `a noter que Objectiver propose un diagramme tr`es simple du processus pr´econis´e par KAOS dans l’illustration suivante.
Figure 2.3 – Processus Objectiver
Le processus Objectiver fait apparaˆıtre les documents en entr´ee et en sortie, et de fa¸con tr`es simplifi´ee l’´etape de mod´elisation. De cette illustration il faut retenir :
— que les documents en entr´ee ne se limitent pas au seul cahier des charges client. Des interviews des parties prenantes et la prise en compte des documents existants sont pertinentes pour analyser le probl`eme et en d´eduire les mod`eles ;
— que les documents en sortie sont d’une part et en premier un mod`ele Web du cahier des charges revisit´e et d’autre part et en final le cahier des charges revisit´e textuel ;
— comme l’indique cette illustration l’int´erˆet d’un document Web est double : sa facilit´e de partage entre les parties prenantes, et de ce fait sa validation informelle par les parties prenantes elles-mˆemes.
La construction des mod`eles avec l’environnement support d’Objectiver se fait en 9 ´etapes s´equentielles.
1. Introduction de l’URD dans un diagramme de texte d’Objectiver 2. Analyse du texte et identification des buts
3. Structuration des buts en un ou plusieurs diagrammes des buts
4. Identification des agents du syst`eme et de l’environnement et construction des dia-grammes des responsabilit´es
5. Documentation de tous les concepts (diagrammes de buts, attentes et exigences, agents) 6. Validation/invalidation des mod`eles par les parties prenantes
7. Mise `a jour des mod`eles 8. Blindage des mod`eles 9. G´en´eration du SRD
2.2
Notations UML utilis´
ees
Pour ce qui concerne la construction du diagramme de classe et des diagrammes ´ etats-transitions de chaque classe, nous faisons l’hypoth`ese que tous les lecteurs connaissent ces notations et maˆıtrisent correctement leur s´emantique. Nous renvoyons donc au site o`u la derni`ere version d’UML est disponible. Au d´ebut 2018 il s’agit de la version 2.5.
2.2.1
R`
egles de transformation de diagrammes de responsabilit´
e en
classes UML
VALID propose des r`egles simples de transformation pour passer des mod`eles Objectiver (mod`ele des buts et mod`ele des responsabilit´es) `a des classes ”`a-la-UML”. En effet Objectiver, en introduisant la notion d’agents (du syst`eme et de l’environnement) attribue explicitement la responsabilit´e des fonctionnalit´es de plus bas niveau (respectivement les exigences et les attentes) `a ces agents.
Que sont ces agents en UML ? Ni plus ni moins que des classes au sens de l’Orient´e Objet. Rappelons qu’une classe est une abstraction qui offre, lorsqu’elle est instanci´ee, des services, ici des buts terminaux (exigence et attente), qui sont a priori fonctionnels.
La r`egle de transformation propos´ee par VALID est donc :
— tout agent du syst`eme est transform´e en une classe interne, dont les op´erations sont les exigences dont il est responsable ;
— tout agent de l’environnement est transform´e en une classe externe (ou utilitaire), dont les op´erations sont les attentes dont il est responsable !
Le distinguo entre classe du syst`eme et classe utilitaire (ou classe externe) provient du fait qu’en KAOS/Objectiver un agent de l’environnement est responsable d’attentes c’est-`a-dire de services qui sont/seront disponibles (th´eoriquement) `a l’ext´erieur du syst`eme `a d´evelopper ! Alors que les exigences correspondent `a ce qu’il faudra implanter pour le syst`eme `a d´evelopper. Cette r`egle permet donc d’envisager maintenant de construire une premi`ere architecture du syst`eme `a d´evelopper en introduisant un diagramme de classes client et des diagrammes ´ etats-transitions. En d’autres termes il faut donc regrouper les classes UML en un diagramme de classes permettant ainsi d’obtenir l’architecture statique m´etier du syst`eme. Le fait d’associer
`
a chaque classe client un automate (i.e. un diagramme ´etats-transition) permet de maˆıtriser la dynamique du syst`eme2 `a d´evelopper, et en particulier d’obtenir de la part de la MOA une validation encore plus forte puisqu’il existe des outils informatiques permettant de simuler le fonctionnement des automates !
2.2.2
D´
etails s´
emantiques sur les diagrammes de classe et les
dia-grammes ´
etats transitions
Diagramme de classes
En UML un diagramme de classes m´etier contient trois types de classes, comme pr´esent´e dans l’illustration de la figure 2.4. Il est `a noter que les deux diagrammes font r´ef´erence `a un exemple non trait´e dans ce document.
Figure 2.4 – Un exemple de diagramme de classes
La classe “Syst`eme Annuaire” est ici la classe m´etier du syst`eme `a d´evelopper. En effet quel que soit le syst`eme `a d´evelopper (mˆeme si ici nous nous restreignons `a des classes m´etier) il est indispensable de se rappeler que le syst`eme final est compos´e d’une part de classes externes, d’autre part de classes internes. Cette classe syst`eme (la seule `a ˆetre ex´ecutable) repr´esente le syst`eme, tel que l’utilisateur le souhaite (en esp´erant que l’AMOA a bien fait son travail). Cette classe syst`eme est le reflet de l’interface du syst`eme, tel qu’il sera utilis´e ! Il est `a noter que dans ce diagramme de classes n’apparaˆıt aucune relation entre les diff´erentes classes externes
2. Attention cependant au fait que les automates ne concernent que les classes du syst`eme, et certainement pas tout le syst`eme. L’automate du syst`eme complet contient trop d’´etats pour pouvoir ˆetre explicitement repr´esent´e.
ou internes. La raison de cette absence de relations provient du fait que le cahier des charges que nous avons trait´e n’en fait apparaˆıtre implicitement aucune !
Diagramme ´etats-transitions
Comme on peut le voir dans l’illustration 2.5, le diagramme ´etats-transitions fait apparaˆıtre les services ou op´erations offertes par la classe “Administrateur Annuaire”. Nous avons respect´e la s´emantique des diagrammes ´etats-transitions au sens de Harel. En d’autres termes, un et un seul ´etat initial, un ou plusieurs ´etats finals. L’absence d’´etat final signifierait que l’automate ne s’arrˆete jamais !
Un examen plus d´etaill´e du diagramme ´etats-transitions fait apparaˆıtre les 6 op´erations identifi´ees dans le diagramme de classes. Remarque : normalement les transitions entre ´etats doivent ˆetre labell´ees par le nom des op´erations figurant dans la classe dont on construit le diagramme ´etats-transitions. Nous avons respect´e ce principe. Mais pour des raisons de clart´e et surtout de simplicit´e des ´etats, les identificateurs choisis sont tr`es abr´eg´es.
Figure 2.5 – Diagramme ´etats-transitions de la classe ”Administrateur Annuaire” Le diagramme fait ´egalement apparaˆıtre des gardes ([OK, pas OK, erreur] et une nouvelle transition “exit”. Pourquoi ces nouveaux ´el´ements ? C’est l`a un apport tr`es significatif de la mod´elisation de l’automate. En effet, le raffinement de buts en sous-buts fait apparaˆıtre de nombreux sous-buts, sans pour autant ˆetre sˆur que tous les cas possibles ont ´et´e examin´es. Les obstacles ont permis d’en identifier de nouveaux, mais encore une fois la compl´etude n’est pas garantie totale. Avec un automate on va pouvoir demander au client une validation et obte-nir, comme dans l’illustration consid´er´ee, le fait qu’il manque des transitions. Les 2 transitions correspondant aux gardes ([OK] et [pas OK]) proviennent du fait que l’authentification de l’ad-ministrateur de l’annuaire a ´et´e r´eussie ou pas. Une modification qui doit ˆetre faite concerne la nouvelle op´eration “exit” introduite dans le diagramme ´etats-transitions de la classe “Admi-nistrateur Annuaire”. Cette transition correspond simplement au fait que l’admi“Admi-nistrateur de l’annuaire peut quitter normalement le syst`eme, information totalement absente du cahier des charges initial.
2.2.3
Apport de la mod´
elisation statique et dynamique ”`
a-la-UML”
La mod´elisation ”`a-la-UML” du syst`eme `a d´evelopper est restreinte aux aspects statique et dynamique de l’utilisation du syst`eme. Ce point peut paraˆıtre restrictif, mais il ne l’est pas car l’objectif affich´e de VALID est la sp´ecification (i.e. plus le “quoi” que le “comment”) du syst`eme `
a d´evelopper.
La mod´elisation ”`a-la-UML” permet d’obtenir la liste des composants qu’il faudra implanter et pour chacun d’eux on repr´esentera leur comportement. Attention `a bien v´erifier que tous les composants sont bien pris en compte, et en particulier toutes les donn´ees, repr´esent´ees ´egalement par des classes. L’identification de ces donn´ees est relativement simple dans la mesure o`u la plupart apparaissent en tant que param`etres des op´erations identifi´ees.
Comme le montre le simple exemple ci-dessus, la mod´elisation du diagramme de classes et du comportement de chaque classe permet `a la fois de corriger certaines erreurs et surtout de valider la compl´etude du document. Dans la pratique on invalide la compl´etude car on est plus `
a mˆeme de d´etecter des manques ou des erreurs. C’est une remarque g´en´erale `a ne pas oublier ! On sait plus invalider que valider !
L’´etape de mod´elisation avec UML permet de donner plus de s´emantique dans la mesure o`u on sp´ecifie sous une forme graphique quel est le comportement de toute instance de chaque classe. Donc les aspects compl´etude (ou au contraire absence de compl´etude) sont bien mis en valeur.
2.3
Sp´
ecification du syst`
eme avec OCL
Pourquoi faut-il sp´ecifier formellement avant de programmer un syst`eme ? Petit rappel : dans l’´etape initiale de VALID nous montrons comment on peut passer des besoins d’un client (l’URD) `a un cahier des charges du syst`eme (le SRD) `a d´evelopper. Cette ´
etape permet de s’assurer que l’on a bien identifi´e les besoins du client. La 2e ´etape permet
ensuite de passer du cahier des charges revisit´e `a une architecture du syst`eme `a d´evelopper. Cette architecture, statique et partiellement dynamique, est la condition sine qua non initiale `
a satisfaire avant de d´evelopper des programmes. Mais cette architecture est insuffisante car nous n’avons aucun contenu s´emantique pour les ´el´ements composant du syst`eme. Le rˆole de la 3e ´etape de VALID consiste `a sp´ecifier le syst`eme, i.e. `a d´ecrire formellement ce que chaque
´
el´ement composant du syst`eme doit faire. Pour cette description nous avons besoin de notations pr´ecises. Avant de passer `a un langage de programmation de type algorithmique, il est important de sp´ecifier en utilisant la logique math´ematique traditionnelle, ´eventuellement compl´et´ee par de l’algorithmique.
Et pour ce faire OCL (tout autant que d’autres notations comme par exemple JML - Java Modeling Language) est une tr`es bonne notation. On va donc pouvoir sp´ecifier logiquement i.e. sp´ecifier des propri´et´es des ´el´ements composant du syst`eme ou simplement sp´ecifier des op´erations. L’int´erˆet d’une telle notation est que sans n´egliger les aspects algorithmiques (i.e. le “Comment”) on peut sp´ecifier (i.e. le “Quoi”) les propri´et´es logiques du syst`eme.
UML model:
<umlmodel> ::= model <modelname> [ <modelbody> ] <modelname>::= <name> ___________________________________ Model body <modelbody>::= { <enumerationdefinition> } { <associationdefinition> | <associationclassdefinition> } <classdefinition>
{<classdefinition> | <associationdefinition> | <associationclassdefinition>} [ constraints { constraintdefinition> } ]
_________________________________________ Enumeration
<enumerationdefinition> ::= enum <enumerationname> { <elementname> { , <elementnamei } } <enumerationname> ::= <name>
<elementname> ::= <name> _________________________________________ Class definition
<classdefinition> ::= [ abstract ] class <classname> [ < classname> { , <classname> } ] [ attributes { <attributename> : <type> } ]
[ operations { <operationdeclaration> [ = <oclexpression> ] { <preconditiondefinition> | <postconditiondefinitioni } } ] [ constraints { <invariantdefinition> } ] end <classname> ::= <name> <attributename> ::= <name> _________________________________ Association definition
<associationdefinition> ::= ( association | composition | aggregation ) <associationname> between
<classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] <classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] { <classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] } end
<multiplicity> ::= ( * | <digit> { <digit> } [ .. ( * | <digit> { <digit> } ) ] ) { , ( * | <digit> { <digit> } [ .. ( * | <digit> { <digit> } ) ] ) }
<associationname> ::= <name> <rolename> ::= <name>
_________________________________ Associationclass definition
<associationclassdefinition> ::= [ abstract ] associationclass <classname> [ < <classname> { , <classname> } ] between
<classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] <classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] { <classname> [ <multiplicity> ] [ role <rolename> ] [ ordered ] } [ attributes { <attributename> : <type> } ]
[ operations { <operationdeclaration> [ = <oclexpression> ] {<preconditiondefinition> | <postconditiondefinition> } } ] [ constraints { <invariantdefinition> } ]
end
__________________ Constraint
<constraintdefinition> ::= <invariantcontext> | <operationcontext>
<invariantcontext> ::= context [ <variablename> : ] <classname> { <invariantdefinition> } <operationcontext> ::= context <classname> <operationconstraints>
<invariantdefinition> ::= inv [ <invariantname> ] : <booleanoclexpression> <operationconstraints> ::= <operationdeclaration>
( <preconditiondefinition> | <postconditiondefinition> ) { <preconditiondefinition> | <postconditiondefinition> }
<preconditiondefinition> ::= pre [ <preconditionname> ] : <booleanoclexpression> <postconditiondefinition> ::= post [ <postconditionname> ] : <booleanoclexpression> ) <invariantname> ::= <name> <variablename> ::= <name> <preconditionname> ::= <name> <postconditionname> ::= <name> ________________________________ Operation declaration
<operationdeclaration> ::= <operationname> ( [ <parameters> ] ) [ : <type> ]
<parameters> ::= <parametername> : <type> { , <parametername> : <type> } <operationname> ::= <name>
<parametername> ::= <name> _______________________
Type
<type> ::= <collectiontype> | <simpletype> | <enumerationname> <collectiontype> ::= ( Set | Bag | Sequence ) (
{ <collectiontype> | <simpletype> | <enumerationname> } )
<simpletype> ::= Integer | Real | Boolean | String | <classname> _____________________________
<name> ::= ( <letter> | ) { <letter> | <digit> | } <letter> ::= a | b | . . . | z | A | B | . . . | Z <digit> ::= 0 | 1 | . . . | 9
<oclexpression> ::= (* Replace this symbol by an ordinary OCL expression. *) <booleanoclexpression> ::= (* Replace this symbol by an ordinary OCLexpression
which results in a boolean value. *) _____________________________________ Expressions OCL
3
L’outillage support de VALID
VALID propose une m´ethodologie qui offre un processus et reprend des notations bien conso-lid´ees, et d’usage courant. Toute m´ethodologie n´ecessitant la pr´esence d’outils support, nous avons s´electionn´e pour chaque ´etape du processus des outils de niveau industriel et, dans la mesure du possible, gratuits.
3.1
Outillage support de GORE
Pour l’´etape GORE, notre choix s’est port´e sur Objectiver pour les raisons ´evoqu´ees plus haut. Cet outil industriel, outre sa puissance expressive, a aussi le grand m´erite d’ˆetre gratuit pour l’enseignement et la recherche.
http ://www.objectiver.com permet de t´el´echarger une version d’´evaluation de l’outil.
3.2
Outillage support d’UML
Pour l’´etape 2, `a savoir la mod´elisation UML de l’architecture statique du syst`eme `a d´ eve-lopper et les diagrammes ´etats-transitions des classes, de nombreux outils sont disponibles.
— Papyrus dans sa version int´egr´e `a l’IDE Eclipse https ://eclipse.org/papyrus/ est un outil tr`es pertinent. Il est `a noter que Papyrus inclut un ´editeur OCL directement li´e aux diff´erents diagrammes UML que l’on aura construit.
— ArgoUML est un logiciel libre qui supporte les langages suivants : Java, C++, PHP, C# et SQL.
— une autre solution tr`es simple d’utilisation est l’environnement StarUML t´el´echargeable `
a l’adresse http ://staruml.io.
La liste des ´editeurs UML est longue. Peu importe le support UML choisi car notre objectif reste la manipulation (construction et surtout v´erification) de sp´ecifications OCL.
3.3
Outillage support d’OCL
Pour ce qui est d’OCL, nous pr´econisons d’abord de sp´ecifier le texte OCL (n’importe quel ´
editeur de texte convient), puis, de manipuler les textes OCL `a l’aide de l’environnement USE. Cet environnement est disponible `a https ://sourceforge.net/projects/useocl/.
USE s’av`ere ˆetre un outil puissant de manipulations de sp´ecifications textuelles et graphiques d’OCL. Il est `a noter que USE permet de visualiser a posteriori le diagramme de classe de la sp´ecification ´ecrite en OCL.
Pr´ecaution `a prendre : une bonne lecture du manuel d’utilisation intitul´e USE : UML-based Specification Environment est indispensable `a tous ceux qui veulent vraiment sp´ e-cifier des syst`emes valides.
3.4
Illustration de VALID `
a l’aide d’un exemple simple
La m´ethodologie VALID est illustr´ee ci-apr`es via un exemple tr`es simple.
3.4.1
URD et SRD d’un mini syst`
eme de gestion bancaire
L’URD que nous proposons est relatif `a un syst`eme de gestion bancaire. Ce syst`eme inclut d’une part des banques et des comptes bancaires, et d’autre part des personnes propri´etaires de ces comptes bancaires. L’objectif final du syst`eme est de permettre la gestion des comptes et des propri´etaires, gestion signifiant essentiellement cr´eation, suppression, modification, etc.
Appliquant la m´ethode et les notations d’Objectiver, nous proposons la suite de diagrammes de buts pr´esent´es ci-apr`es.
Figure 3.1 – Diagramme de plus haut niveau pour les comptes bancaires
Le syst`eme de gestion bancaire est raffin´e en 2 sous-buts (gestion des comptes et gestion des personnes) et une attente (gestion des banques). “Gestion des banques” est une attente, donc a priori sous la responsabilit´e d’un agent ext´erieur, ici identifi´e par “Banques”.
Figure 3.2 – Diagramme de raffinement de la gestion des comptes.
Pour le raffinement de la “gestion des comptes”, nous avons cr´e´e 3 exigences, permettant respectivement de “cr´eer un compte”, “supprimer un compte” et “associer un compte `a une personne”. Ces 3 exigences sont sous la responsabilit´e de l’agent “Gestionnaire compte”.
Figure 3.3 – Diagramme de raffinement de la gestion des personnes.
Le sous-but “gestion des personnes” est relatif aux personnes qui ont un compte bancaire. C’est pour cela que nous avons consid´er´e 2 exigences, l’un relative `a la cr´eation d’un propri´etaire d’un compte, l’autre `a la suppression d’un propri´etaire d’un compte.
Ce qu’il ne faut pas faire avec Objectiver c’est de construire des diagrammes comportant trop d’exigences et/ou d’attentes. Le diagramme ci-dessous est relativement illisible.
Id´ealement tout sous-but ne devrait ˆetre raffin´e que par un seul niveau de sous-buts, d’at-tentes et/ou d’exigences.
Figure 3.4 – Diagramme global `a ´eviter
En effet la lisibilit´e de tout diagramme de buts est essentielle `a la compr´ehension du probl`eme ainsi qu’`a la solution propos´ee.
Dictionnaire des symboles manipul´es
Type Identificateur D´efinitions
Agent Banques Repr´esente l’ensemble des banques
Agent Gestionnaire compte Agent responsable des comptes, donc fournis-sant les exigences “cr´eer compte, supprimer compte, associer compte `a propri´etaire” Agent Gestionnaire propri´etaire Responsable de “cr´eer propri´etaire compte,
supprimer propri´etaire compte”
Buts et
sous-buts non docu-ment´es
syst`eme de gestion bancaire, ges-tion compte, gesges-tion des per-sonnes
Sont raffin´es dans des diagrammes de buts
Attente gestion des banques On fait l’hypoth`ese que les banques sont g´ e-r´ees par une entit´e externe
Exigences cr´eer compte, supprimer compte,
associer compte `a propri´etaire, cr´eer compte,
supprimer propri´etaire compte
Sont d´efinis dans le SRD correspondant pr´ e-sent´e en annexe
3.4.2
Identification des propri´
et´
es
Pour pouvoir sp´ecifier formellement en OCL il faut avant tout bien identifier les propri´et´es que le syst`eme doit pr´eserver. Pour l’exemple consid´er´e et bien que l’URD de d´epart ne le pr´ecise pas, nous introduisons 3 propri´et´es `a imp´erativement respecter :
1. un client peut avoir plusieurs comptes ;
2. pour une banque donn´ee, un client ne peut y avoir qu’un et un seul compte ; 3. tous les comptes bancaires doivent avoir un solde positif.
La prise en compte des propri´et´es peut se faire soit directement au niveau graphique, soit au niveau du texte OCL :
— Les items 1 et 2 sont sp´ecifi´es graphiquement dans le diagramme de classes (pr´esent´e plus loin) par des multiplicit´es appropri´ees.
— L’item 3 est traduit dans la sp´ecification OCL par l’expression “inv positif : solde>0”. Il est `a remarquer qu’il n’y a pas d’ordre entre les propri´et´es car elles doivent ˆetre ind´ epen-dantes. Si ce n’est pas le cas, il faut alors le traduire graphiquement et/ou logiquement. Un tel cas traduit sans nul doute une mod´elisation pour le moins “faible”!
3.4.3
Codage en OCL
model CompteBancaire class Banque attributes nom: String end class Personne attributes age : Integer end class Compte attributes solde : Integer operations crediter (c:Integer) pre: c>0post: solde = solde@pre + c debiter (d:Integer)
pre: d>0 and solde>d
post: solde = solde@pre - d getSolde ()
end
association
aDesClients between
Banque[*] role banque
Personne[1..*] role clients end association aDesComptes between Banque[1..*] Compte[*] end association aUnCompte between
Personne [1] role proprietaire Compte[1..*]
end
constraints context Compte
Seule la 3e propri´et´e est prise en compe au niveau OCL puisque les deux autres ont pu ˆetre
trait´ees graphiquement. Le codage OCL fait apparaˆıtre l’invariant qui stipule que tout compte doit avoir un solde positif. La sp´ecification de l’op´eration de d´ebit pr´eserve bien cet invariant puisque en pr´econdition on v´erifie que la somme `a retirer est bien positive et que cette somme est bien inf´erieure au solde du compte.
L’utilisation de l’environnement USE permet de visualiser les diff´erents ´el´ements manipul´es dans la sp´ecification OCL avec tous les d´etails introduits lors de la mod´elisation. Cette visua-lisation du diagramme de classe est riche car elle s’appuie sur une sp´ecification plus compl`ete (les op´erations sont introduites).
Personne age : Integer Banque nom : String Compte solde : Integer crediter(c : Integer) debiter(d : Integer) getSolde() clients 1..* aDesClients banque * compte * aDesComptes banque 1..* compte 1..* aUnCompte proprietaire 1
Figure 3.5 – Diagramme de classes des comptes bancaires provenant de USE.
3.4.4
Premi`
eres conclusions
De ce simple exemple nous pouvons conclure qu’il faut proc´eder avec une extrˆeme rigueur si l’on veut obtenir un r´esultat offrant les 3 propri´ets attendues que sont la compl´etude, la coh´erence et la satisfiabilit´e.
Il faut cependant ne pas oublier que ce qui a ´et´e construit est un ensemble de mod`eles `a partir d’un URD client. Quid de la validation de cette mod´elisation ? Quelles techniques `a utiliser et aussi qui peut mener cette ´evaluation ?
4
Smartphone
Ce chapitre traite un exemple plus ´elabor´e, r´eutilisant le processus VALID.
4.1
URD d’un smartphone sˆ
ur de fonctionnement
L’URD initial pourrait ˆetre traduit par la simple phrase : “Smartphone sˆur de fonctionnement via l’utilisation d’une empreinte digitale”.
Avant de rentrer dans les d´etails, nous rappelons `a tous nos lecteurs (qui ont certainement un smartphone) ce que nous envisageons comme d´efinition. Un ordiphone1 ou t´el´ephone intel-ligent, est un t´el´ephone mobile disposant de nombreuses fonctionnalit´es : assistant num´erique personnel, appareil photo num´erique et mˆeme ordinateur portable. La saisie des donn´ees se fait le plus souvent par le biais d’un ´ecran tactile ou, plus rarement d’un clavier ou d’un sty-let. Selon le principe d’un ordinateur, il peut ex´ecuter divers logiciels/applications grˆace `a un syst`eme d’exploitation sp´ecialement con¸cu pour mobiles, et donc en particulier fournir des fonc-tionnalit´es en plus de celles des t´el´ephones mobiles classiques comme : l’agenda, la t´el´evision, le calendrier, la navigation sur le Web, la consultation et l’envoi de courrier ´electronique, la g´eolocalisation, le dictaphone/magn´etophone, la calculatrice, la boussole, l’acc´el´erom`etre, le gyroscope, la messagerie vocale visuelle, la cartographie num´erique etc. Les appareils les plus sophistiqu´es b´en´eficient ´egalement de la reconnaissance vocale et de la synth`ese vocale.
Quelques d´etails `a consid´erer
Compte-tenu de la richesse des services fournis par un smartphone la quantit´e d’informations personnelles est tr`es grande et doit donc ˆetre particuli`erement prot´eg´ee. D’o`u un tr`es haut niveau de s´ecurit´e pour ce qui concerne l’acc`es `a son contenu. Pour ce faire l’utilisateur devra syst´ematiquement ˆetre identifi´e lorsqu’il veut utiliser manuellement son t´el´ephone.
Afin de rendre l’utilisation des smartphones sˆure, les constructeurs les ont dot´es de lecteur d’empreinte digitale (mˆeme s’il s’av`ere que ce syst`eme n’est pas sans faille). Il faut alors garantir que l’empreinte digitale sera parfaitement reconnue, ce qui pose de nombreuses questions :
— comment cr´eer une premi`ere empreinte digitale ?
— comment garantir que la reconnaissance de l’empreinte est correcte ? — que faut-il envisager de faire si l’on veut vendre le smartphone ?
— quid d’un mode de secours sans utiliser l’empreinte digitale (c’est le cas si le propri´ e-taire du smartphone ne peut plus utiliser ses empreintes digitales).
— etc. !
Nous pr´esentons ci-apr`es comment Objectiver a ´et´e utilis´e pour mod´eliser le cahier des charges revisit´e pour un smartphone, intelligent et sˆur de fonctionnement.
Il est essentiel de remarquer que les mod`eles pr´esent´es ci-apr`es traduisent une solution po-tentielle, et que bien d’autres mod´elisations peuvent ˆetre tout aussi valides. En d’autres termes
1. Dans la suite du texte nous utiliserons plus souvent le terme smartphone, mˆeme si l’Acad´emie recommande d’utiliser le terme ordiphone !
il faut se convaincre que les mod`eles sont complets, coh´erents et faisables, donc conduisent `a une impl´ementation effective.
Seule la d´ecouverte d’une erreur permet d’invalider et de ce fait, le lecteur doit faire un s´erieux effort de compr´ehension de la solution propos´ee.
4.2
Cahier des charges et mod`
eles Objectiver
La pr´esentation des arborescences et leur lecture est faite de gauche `a droite et en profondeur `
a raison d’un diagramme par page. Il est `a noter qu’il n’y a aucune priorit´e entre les diff´erents sous-buts. Nous rappelons que tous les sous-buts doivent ˆetre satisfaits lors d’un raffinement ET, alors que pour un raffinement OU un seul sous-but satisfait garantit le but p`ere.
Les mod`eles pr´esent´es ci-apr`es introduisent pour la plupart la notion d’obstacle. Cette notion permet de prendre en compte tout ce qui empˆeche une fonctionnalit´e d’aboutir. Elle correspond `
4.2.1
Niveau initial
Figure 4.1 – SmartPhone au plus haut niveau Le diagramme fait apparaˆıtre 5 sous-buts pour le smartphone :
1. ”communication t´el´ephonique” qui permet le dialogue entre un appelant et un appel´e, 2. ”autres fonctionnalit´es” qui recouvre tous les autres services offerts par le smartphone, 3. ”authentification ” qui assure les aspects s´ecurit´e,
4. ”information partag´ee” qui correspond `a toutes les informations g´er´ees par les diverses applications,
5. et ”vente smartphone” qui concerne les actions `a effectuer lorsque l’on vend le t´el´ephone. Il est `a noter que les points 4 et 5 ci-dessus ne figurent pas explicitement dans l’URD initial. Il faut cependant les prendre en compte pour une plus grande compl´etude.
Important : l’aspect ”vol du smartphone” n’a pas besoin d’ˆetre consid´er´e puisqu’il y a une authentification requise pour se servir du t´el´ephone. Tout smartphone ´etant de nos jours g´eolocalisable, il aurait mˆeme pu ˆetre envisag´e de r´ecup´erer un smartphone vol´e.
4.2.2
Communication t´
el´
ephonique
Figure 4.2 – Appeler ou recevoir un appel
Ce diagramme repr´esente le fait d’appeler un correspondant ET le fait de recevoir un appel t´el´ephonique. O`u peut-on introduire la notion d’obstacle ?
Manifestement les exigences ”appelant”, ”´echange” et ”appel´e” ne peuvent donner lieu `a un obstacle car pour identifier un obstacle il faut prendre la n´egation de tout (sous-)but et v´erifier si cette n´egation peut ˆetre `a son tour raffin´ee.
Pour les attentes consid´er´ees (”appelant”, ´echange” et ”appel´e”), leur n´egation n’a aucun sens. On ne doit donc pas les consid´erer.
Par contre la n´egation du sous-but ”communication t´el´ephonique” est simplement traduite par ”pas de r´eseau t´el´ephonique”. Et ce dernier sous-but est r´esolu par 2 exigences, ”attendre r´eparation” et ”chercher nouveau r´eseau”.
Le lecteur attentif constate qu’il s’agit bien d’un OU entre les 2 r´esolutions, donc qu’il faut prendre en compte ces 2 r´esolutions au niveau de la conception.
Figure 4.3 – Appeler ou recevoir un appel Une communication t´el´ephonique est un ´echange entre deux t´el´ephones.
Le choix de prendre des attentes est li´e au fait que c’est le mat´eriel t´el´ephonique qui assure ces services.
L’obstacle envisag´e est le fait de ne pas avoir de r´eseau t´el´ephonique. Dans ce cas, deux r´esolutions sont propos´ees :
— “attendre r´eparation” stipule que le mat´eriel t´el´ephonique ne fait rien. Il y a simplement attente !
— “chercher un nouveau r´eseau” stipule que le mat´eriel fait la recherche d’un nouveau r´eseau. Il faut bien se rappeler qu’en Objectiver on doit mod´eliser tous les cas possibles. C’est `a l’im-pl´ementation qu’un choix final sera fait, selon les capacit´es du mat´eriel consid´er´e.
Il faut aussi remarquer que dans la mod´elisation les attentes tout comme les exigences correspondent `a des actions ou traitements, traduits par des verbes ou des substantifs.
Le seul obstacle consid´er´e est relatif `a l’absence de r´eseau t´el´ephonique. Dans ce cas l`a, il est propos´e soit d’attendre la r´eparation du r´eseau, soit de chercher un nouveau r´eseau. Ces exigences sont sous la responsabilit´es de 2 agents diff´erents : ”mat´eriel t´el´ephonique” d’un cˆot´e, ”gestionnaire services” de l’autre.
