IngenierieSystLogiciel Nkenlif 2020-2021 Oct20 v10

Université de Douala
« Master 2 IASIG 2020-2021 »
Support de Cours
Ingénierie
Ingénierie des Systèmes
Logiciels
Pr Marcellin Julius A. NKENLIFACK

Chef du Département de Mathématiques et Informatique à la Faculté des Sciences de l’Université de Dschang
mnkenlif@hotmail.com
Version 10 (oct. 2020)

Sommaire
Sommaire ........................................................................................................................................................................... ii
1 Rappels des Concepts du Génie Logiciel ................................................................................................................... 5
1.1 DEFINITION ......................................................................................................................................................... 5
1.2 UN PEU D’HISTORIQUE ........................................................................................................................................ 5
1.3 CRISES................................................................................................................................................................. 5
1.4 LE GENIE LOGICIEL............................................................................................................................................. 6
1.5 LE PROCESSUS LOGICIEL, OU CYCLE DE VIE DU LOGICIEL .................................................................................... 6
1.6 REPRESENTATIONS DES MODELES DE DEVELOPPEMENT ...................................................................................... 7
1.6.1 Modèle Exploratoire ................................................................................................................................... 7
1.6.2 Modèle Cascade ......................................................................................................................................... 7
1.6.3 Modèle en V ................................................................................................................................................ 8
1.6.4 Modèle en spirale ....................................................................................................................................... 8
1.6.5 Modèle Incrémental .................................................................................................................................... 9
1.7 ACTIVITES CAPITALES DU CYCLE DE VIE ............................................................................................................. 9
1.8 LA SPECIFICATION ............................................................................................................................................ 10
1.8.1 Les 7 péchés : ........................................................................................................................................... 10
1.8.2 Les 7 caractéristiques d’une bonne spécification :................................................................................... 10
1.8.3 Les méthodes ............................................................................................................................................ 10
1.8.4 Les démarches d’analyse .......................................................................................................................... 11
1.9 VERIFICATION ET TESTS DE LOGICIELS ............................................................................................................. 12
1.9.1 Concepts ................................................................................................................................................... 12
1.9.2 Réalisation ................................................................................................................................................ 12
1.9.3 Organisation du test ................................................................................................................................. 12
1.9.4 Le graphe de contrôle d’un programme ................................................................................................... 12
1.9.5 Techniques de Tests .................................................................................................................................. 14
1.9.6 Processus de test de codes ........................................................................................................................ 16
2 Méthodes SADT et Réseaux de Petri ....................................................................................................................... 18
2.1 INTRODUCTION.................................................................................................................................................. 18
2.2 SPECIFICATIONS A L’AIDE DES RESEAUX DE PETRI............................................................................................ 18
2.2.1 Description ............................................................................................................................................... 18
2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri ................................................................. 19
2.2.3 Graphes de marquages ............................................................................................................................. 20
2.2.4 Limites des RdP et extensions des possibilités.......................................................................................... 20
2.2.5 Extensions et autres Outils proches.......................................................................................................... 20
2.3 SPECIFICATION A L’AIDE SE SADT & IDEF ...................................................................................................... 21
2.3.1 Présentation.............................................................................................................................................. 21
2.3.2 Modèles SADT .......................................................................................................................................... 21
2.3.3 SADT/IDEF0 ............................................................................................................................................ 22
2.3.4 LES EXTENSIONS IDEF1/IDEF2 ........................................................................................................... 24
2.3.5 Avantages et Inconvenients de SADT ....................................................................................................... 25
2.4 CONCLUSION ..................................................................................................................................................... 26
3 Approche orientée Objet et UML ............................................................................................................................. 27
3.1 INTRODUCTION.................................................................................................................................................. 27
3.2 LES CONCEPTS DE BASE:.................................................................................................................................... 27
Abstraction ( ≡ définition d’une classe) .................................................................................................................. 28
Encapsulation ........................................................................................................................................................... 28
Modularité ................................................................................................................................................................ 28
Hiérarchie (héritage) ............................................................................................................................................... 28
Le typage .................................................................................................................................................................. 28
Simultanéité .............................................................................................................................................................. 28
Persistance ............................................................................................................................................................... 28
3.3 APERÇU DU CYCLE GENERAL DE DEVELOPPEMENT............................................................................................ 28
3.4 LES « MODELES » .............................................................................................................................................. 29
3.5 LE LANGAGE UML ....................................................................................................................................... 29
3.5.1 La genèse d'UML ...................................................................................................................................... 29
3.5.2 Généalogie UML à l’origine .................................................................................................................... 29
3.5.3 Le formalisme d'UML ............................................................................................................................... 30
3.5.4 La modélisation par UML ........................................................................................................................ 32
3.5.5 OCL : gestion des Contraintes sur les attributs et associations ............................................................... 49
3.6 CONCLUSION ..................................................................................................................................................... 50
4 Les méthodes Agiles ................................................................................................................................................ 51
4.1 CONTEXTE ET DEFINITION ................................................................................................................................. 51
4.2 HISTORIQUE DES METHODES AGILES ................................................................................................................. 51
4.3 LES PRINCIPES AGILES ....................................................................................................................................... 52
4.4 LES METHODES AGILES ONT-ELLES DES LIMITES ? ............................................................................................ 53
4.5 EVOLUTION DES DIFFERENTES METHODES......................................................................................................... 53
4.6 CHOIX DE METHODE AGILE ET OPTIMISATION.................................................................................................... 54
4.6.1 Comparaison ............................................................................................................................................ 54
4.6.2 Unification ou combinaison de méthodes dans la pratique ...................................................................... 54
4.6.3 Processus SCRUM.................................................................................................................................... 55
4.6.4 Processus DSDM ...................................................................................................................................... 56
4.6.5 Processus XP (eXtreme Programming) .................................................................................................... 57
4.6.6 SAFE......................................................................................................................................................... 57
4.6.7 SAFe vs Scrum .......................................................................................................................................... 57
4.7 « MODELISATION AGILE » DES PROJETS ............................................................................................................ 57
4.7.1 Les valeurs d'une modélisation Agile ....................................................................................................... 57
4.7.2 Modélisation agile : le point de vue de Craig Larman ............................................................................. 59
4.8 TEST-DRIVEN REQUIREMENTS (TDR)............................................................................................................... 60
4.8.1 Lean sofware development ....................................................................................................................... 60
4.8.2 Les étapes d’une évolution « lean ».......................................................................................................... 61
4.8.3 TDD (Test Driven Development) et TDR (Test Driven Requirement) ...................................................... 61
4.8.4 Processus FDD ......................................................................................................................................... 63
4.8.5 BDD : développement basé sur les spécifications .................................................................................... 64
4.9 CONCLUSION : ................................................................................................................................................... 64
5 Ingénierie basée sur les Modèles .............................................................................................................................. 66
5.1 MDE : MODEL DRIVEN ENGINEERING .............................................................................................................. 66
5.1.1 Évolutions ................................................................................................................................................. 66
5.1.2 Concepts de base ...................................................................................................................................... 66
5.1.3 MDE et le génie logiciel ........................................................................................................................... 66
5.1.4 MDE et UML ............................................................................................................................................ 67
5.1.5 Supports de la technologie MDE .............................................................................................................. 68
5.1.6 MDE et les « Design Patterns » ............................................................................................................... 71
5.1.7 Processus de modification MDE .............................................................................................................. 72
5.1.8 Méthodologie globale de réalisation d’applications ................................................................................ 74
5.1.9 Perspectives de développement ................................................................................................................ 76
5.1.10 Conclusion sur MDA ................................................................................................................................ 77
5.2 SYSTEMES BASES SUR LES MODELES : CONCEPTION ARCHITECTURALE AVEC LA METHODE ARCADIA ........... 78
5.2.1 Présentation de Arcadia ........................................................................................................................... 78
5.2.2 Phases de la démarche de modélisation ................................................................................................... 79
5.2.3 Mise en œuvre dans Capella ..................................................................................................................... 79
6 Processus de Mise en Oeuvre, Outils et Métriques de Qualité ................................................................................. 81
6.1 ARCHITECTURE DES APPLICATIONS ................................................................................................................... 81
6.1.1 Architecture en couches............................................................................................................................ 81
6.1.2 Modèle MVC et interfaces graphiques ..................................................................................................... 82
6.2 PLACE DES OUTILS ............................................................................................................................................ 82
6.3 CHOIX DE L’OUTIL DE DEVELOPPEMENT............................................................................................................ 83
6.4 QUELQUES FACTEURS CARACTERISANT LES LANGAGES DE DEVELOPPEMENT ................................................... 83
6.5 ENVIRONNEMENT INTEGRE DE PROGRAMMATION ............................................................................................. 84
6.6 LES ATELIERS DE GENIE LOGICIEL.................................................................................................................... 84
6.6.1 Qu'est ce qu'un Atelier de Génie Logiciel (AGL) ? .................................................................................. 84
6.6.2 Les outils « CASE » (Computer Aided Software Engineering)................................................................. 84
6.6.3 L'intégration d'outils CASE ...................................................................................................................... 84
6.6.4 Les différents types d'AGL ........................................................................................................................ 85
6.6.5 Standardisation des ateliers ..................................................................................................................... 85
6.6.6 Ateliers et Cycle de vie ............................................................................................................................. 85
6.7 INTERET DE GERER LA QUALITE D'UN LOGICIEL, ET DE SON CONTROLE A L’AIDE DES OUTILS APPROPRIES ........ 86
6.8 LES « PROCESSWARES » .................................................................................................................................... 87
6.9 OUTILS DE DEVELOPPEMENT MBSE (MODEL BASED SYSTEM ENGINEERING) .................................................. 87
6.9.1 PolarSys Solutions .................................................................................................................................... 87
6.9.2 AndroMDA pour Java (un générateur d’application) .............................................................................. 87
6.9.3 Delphi Architecte ...................................................................................................................................... 89
6.10 OUTILS DE CONTROLE DE QUALITE ET DE TEST DE CODES ................................................................................ 90
6.10.1 Contrôler la qualité de ses projets avec l’outil « Sonar » ........................................................................ 91
6.10.2 Tests unitaires avec le framework « xUnit » (un OpenSource) ................................................................ 91
6.10.3 Outils utilisables pour la méthode agile FDD (Feature Driven Development)........................................ 92
6.10.4 Tests TDR ................................................................................................................................................. 92
6.11 AUTRES OUTILS DE REALISATION ...................................................................................................................... 93
6.11.1 La suite « RAD Studio XE »...................................................................................................................... 93
6.11.2 Le serveur d’application universel « EAS : Enterprise Application Server » .......................................... 93
6.11.3 L’environnement de référence DOC (HP) ................................................................................................ 93
6.11.4 Quelques Logiciels de modélisation UML ................................................................................................ 94
6.11.5 Les outils SADT ........................................................................................................................................ 95
6.11.6 Les outils historiques de développement d’interfaces graphiques (GUI) ................................................. 95
6.11.7 L’accès aux données ................................................................................................................................. 96
6.11.8 L’aspect gestion du projet ........................................................................................................................ 96
6.11.9 L’offre historique logicielle de Microsoft : .............................................................................................. 96
6.12 LES QUESTIONS QUE L’ON DOIT SE POSER FACE A UN SYSTEME OU UN GROS PROJET D’ENTREPRISE (PAR
EXEMPLE DE TYPE CLIENT-SERVEUR) ............................................................................................................................ 97
6.13 ELEMENTS DE QUALITE LORS D’UN DEVELOPPEMENT (LES METRIQUES) ........................................................... 97
6.14 DOCUMENTATION TECHNIQUE DES PROJETS IMPORTANTS (ET ACTIVITES) ........................................................ 98
6.14.1 Modèle global .............................................................................................. Error! Bookmark not defined.
6.14.2 Description détaillée de toutes les tables (BD) ........................................... Error! Bookmark not defined.
6.14.3 Description de tous les attributs avec tous leurs détails.............................. Error! Bookmark not defined.
6.14.4 Architecture de l'application à mettre en place ........................................................................................ 99
6.14.5 Eléments de programmation ........................................................................ Error! Bookmark not defined.
6.14.6 Diagrammes applicatifs............................................................................... Error! Bookmark not defined.
6.14.7 Sécurité, etc. ................................................................................................ Error! Bookmark not defined.
7 Ergonomie d’Applications Graphiques, Développement en équipe ....................................................................... 100
7.1 PROBLEMATIQUE DE L’ERGONOMIE ................................................................................................................ 100
7.1.1 Pourquoi aborder ce sujet maintenant ? ................................................................................................ 100
7.1.2 Pourquoi accorder de l’importance à l’ergonomie de ses applications ? .............................................. 100
7.1.3 Présentation............................................................................................................................................ 100
7.2 QU’EST-CE QUE L’ERGONOMIE ? ..................................................................................................................... 100
7.2.1 Définition et complexité du concept ....................................................................................................... 100
7.2.2 La place des technologies cognitives dans l’ergonomie ......................................................................... 101
7.2.3 Les différents domaines d’application de l’ergonomie........................................................................... 102
7.3 L’ERGONOMIE DANS LE DEVELOPPEMENT D’IHM, EN PARTICULIER DANS LES APPLICATIONS WEB................ 102
7.3.1 L’« ergonomie de fond », un préalable à la mise à disposition de l’information ................................... 102
7.3.2 Mise en pratique de l’ergonomie des applications (Web) ...................................................................... 103
7.4 APPROCHE GENERALE SUR LE DEVELOPPEMENT EN EQUIPE ............................................................................ 107
7.4.1 Le développement en équipe ................................................................................................................... 107
7.5 L'EFFICACITE DU DEVELOPPEMENT POINT PAR POINT ...................................................................................... 107
7.5.1 Partage et sécurité des données ............................................................................................................. 107
7.5.2 Systèmes de gestion de versions ............................................................................................................. 108
7.5.3 Diviser pour mieux régner ...................................................................................................................... 108
7.5.4 Optimisation des modifications au quotidien ......................................................................................... 108
7.6 CONCLUSION SUR L’ERGONOMIE ..................................................................................................................... 109
BIBLIOGRAPHIE ......................................................................................................................................................... 110
Ingénierie des Systèmes Logiciels (M2 IASIG)

1 Rappels des Concepts du Génie Logiciel
1.1 Définition
« Le logiciel est l'ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitements de l'information' » (arrêté du 22 déc. 1981)
En d’autres termes, un logiciel pourra donc être considéré comme un ensemble de programmes informatiques (codes
sources, éditables, exécutables) mais également les données qu’ils utilisent et les différents documents se rapportant à
ces programmes et nécessaires à leur installation, utilisation, développement et maintenance : spécifications
(fonctionalités, contraintes, facteur de qualité, interface), schémas conceptuels, jeux de tests, mode d'emploi, etc.
1.2 Un peu d’historique

• En 1936, Alan Turing (un brillant étudiant en mathématiques à Cambridge en Angleterre, âgé de 24 ans qui
cherche à construire un cerveau artificiel), propose dans un article, tout d'abord de formaliser la notion
d'algorithme grâce à la définition d'un dispositif abstrait que depuis on appelle « machine de Turing ». Ce sera
le modèle de base qui fonde l'informatique moderne. Une machine de Turing sera vue comme une méthode de
calcul, un programme.
Programmer (écrire un programme) consiste à écrire une suite d'instructions pour réaliser un traitement sur des données.
• Les langages de programmation (« intermédiaire » entre le « programmeur » et la « machine ») vont évoluer
dans le temps, au fur et a mesure des besoins en terme de qualité, et pour pouvoir faire face aux problèmes de
plus en plus complexes.
- Langages de 1ère génération (1954 – 1958 : Fortran I, Algol 58…)
- Langages de 2ème génération (1959 – 1961 : Fortran II, Algol60, Cobol, Lisp, Forth…)
- Langages de 3ème génération (1962 – 1970 : PL1, Algol68, Pascal, Simula, C(B))
- Langages de 4ème génération (1971 – 1980 : Smaltalk, Ada, C++)
- Langages de 5ème génération (année 80** et 90** : Eiffel, Clos, Yafool, Objloo, Art, Ulysse, NewFlavors,
Neon, Java, Wlangage …)
• La Complexité du développement des Logiciels étant également liée au matériel, on note parallelement
également une évolution des systèmes matériels :
Après l’architecture de Von Neumann, à la base de toutes les architectures modernes, les systèmes matériels vont
évoluer rapidement dans le temps, pour permettre de développer des solutions de plus en plus performantes ; avec au
centre le processeur (entité capable d’interpréter et exécuter un traitement ou processus).
Au cours des années 70**, on observe une révolution avec la création des microprocesseurs (1974 = Intel, 1982 =
RISC, 1984 = 88020, etc.).
L’explosion qui va suivre dans les années 80** entraînera une baisse permanente des coûts du matériel.
1.3 Crises
• Malgré les évolutions citées plus haut, on note que au fur et à mesure que les coûts du matériel diminuent, les
coûts des programmes informatiques (curieusement) augmentent !
La diminution des coûts du matériel (hardware) a conduit à associer l’ordinateur à de plus en plus de produits. Les
coûts des logiciels connaissent une très forte croissance, dominant maintenant le coût du matériel et peuvent
représenter plus de 80 % du coût total d’un système informatique (ex coût de la mémoire économisée).
• A la fin des années 70, on ne sait pas « faire » des logiciels (plusieurs tentatives de logiciels vont échouer)
- Les besoins et contraintes de l’utilisateur ne sont pas respectés (pas de facilité d’emploi, interfaces
homme/machine inexistantes)
- Les coûts ne sont pas maîtrisés
- On relève régulièrement des retards dans la livraison des produits (non maîtrise du temps)
- On note une grande rigidité dans les solutions mises en place
- Quelques fois on arrive à des incohérences pendant l’utilisation
- On est aussi confronté au manque de performance et de robustesse (fiabilité)
- Les codes sont difficiles à maintenir
- On arrive parfois à des logiciels non utilisables
• En 1983, on se rend compte que :

- 43% des logiciels sont livrés et non utilisés
- 28% payés et non livrés
- 19% utilisés tels quels
- 3% utilisés sans modification (échec de tentative)
- 2% utilisés avec modifications (réussite de tentative)
© Pr NKENLIFACK Marcellin [oct. 2020] Page 5 / 112

•
Les coûts de maintenance (lorsque cela se fait) dépassent ceux du développement


• Le coût d’une erreur parfois dépasse le coût du système
Illustration : Les pannes causées par le « bug de l’an 2000 » ont coûté environ 175 milliards de dollars aux
entreprises du monde (journal « Le Monde » – 23 oct. 2001).
• D’une étude sur 487 sites de toutes sortes de développement de logiciels, il ressort que :
- 70% du coût du logiciel est consacré à sa maintenance
- 42% des modifications sont dues à des demandes de l’utilisateur
- 30% des exigences de spécification changent entre la 1ère édition d’une documentation et la première sortie du
produit
- 17% à des changements de format des données (an 2000, format CAN 2.0A-2.0B, adressages (ex. IPv6)…)
- 12% à des problèmes d’urgence résolus à la hâte
- 9% aux déboguages de programmes
- 6% à des changements de matériel
- 6% à des problèmes de documentation
- 4% aux améliorations de l’efficacité
- 3% aux autres types de problèmes.
Ces différents problèmes vont conduire à la création du Génie Logiciel.
1.4 Le Génie Logiciel

Le Génie Logiciel est défini le 30 décembre 1983 comme étant « l’ensemble des activités de conception et de mise en
œuvre des produits et des procédures tendant à rationnaliser la production du logiciel et son suivi ».
• Objectifs :
- Maîtriser les coûts et les delais de développement
- Améliorer la productivité (de l’équipe de développement)
- Fournir une assurance qualité du produit livré
Le génie logiciel s’intéresse :
- aux différentes théories
- aux méthodologies : (techniques, méthodes)
- aux outils
- à l’organisation générale
- à la gestion de projets
En bref, le Génie Logiciel c’est l’ensemble des méthodes, outils et techniques utilisées pour développer et maintenir
du logiciel dans le but d’assurer la qualité et la productivité. C’est donc l’art de la construction du logiciel.
Le génie logiciel est basé sur des méthodologies et des outils qui permettent de formaliser et même d'automatiser
partiellement la production de logiciels, mais il est également basé sur des concepts plus informels, et demande des
capacités de communication, d'interprétation et d'anticipation. De fait, la « crise du logiciel » n'est pas complètement
résolue aujourd’hui. Le génie logiciel reste un « art »' qui demande de la part de l'informaticien une bonne formation
aux différentes techniques (le savoir), mais également un certain entrainement et de l'expérience (le savoir faire).
1.5 Le processus logiciel, ou cycle de vie du logiciel

Le « cycle de vie d'un logiciel » (en anglais Software Lifecycle), désigne toutes les étapes du développement d'un
logiciel, du début de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons
intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les
besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en
œuvre. L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont
détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi
de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.
Historiquement, le premier modèle de développement proposé (1966) est celui dit en ``cascade'', formalisé en 1970.
Ce modèle a été assez largement mis en œuvre, mais on s'est rapidement aperçu qu'il n'est pas toujours approprié. Sa
vision simpliste du processus sous-estime le coût des retours en arrière dans le cycle de vie. Ainsi, plusieurs alternatives
au modèle en cascade ont été proposées, basées notamment sur le prototypage et l'assemblage de composants
réutilisables.
Le cycle de vie du logiciel comprend généralement au minima les activités suivantes :
• Définition des objectifs : définir la finalité du projet et son inscription dans une stratégie globale.
• Analyse des besoins et faisabilité, exprimer, recueillir et formaliser les besoins du demandeur (le client) et
l'ensemble des contraintes. Ceci débouche sur le « Business Requirements Specification (BRS) » ou le
« Customer Requirements Specification / User Requirements Specification »
• Spécification : définir le quoi du logiciel après dialogue avec le client. On donne ici les contraintes de temps,
etc. Cette phase débouche généralement sur un document de spécification (Software Requirement Analysis -
SRA). Le SRA doit dégager clairement les fonctions, les interfaces (machines, utilisateurs, environnement), les
contraintes (performance, mémoires, logiciels, machine).

•

Conception générale. formaliser les spécifications élaborées de l'architecture générale du logiciel. Le
document produit est appelé « High Level Design Document (HLDD) ».
• Conception détaillée, indiquer le comment, définir de façon précise chaque sous-ensemble du logiciel. Le
document produit est appelé « Low Level Design Document (LLDD) ». Ces deux phases débouchent
généralement sur un document de conception (Software Design Report - SDR).
• Codage, réaliser (programmer) ou codifier dans un langage de programmation, des fonctionnalités définies
lors de phases de conception. Cette phase débouche sur un ensemble de codes (Programmes).
• Tests unitaires, vérifier inidividuellement que chaque sous-ensemble du logiciel est implémenté
conformément aux spécifications.
• Intégration, s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Les tests d'intégration (et
même parfois unitaires) seront consignés dans un document rapport (Software Test Report – STR).
• Qualification, vérifier la conformité du logiciel aux spécifications initiales, procéder aux tests (on teste à
l’atelier, par la suite dans un environnement similaire à celui du client - livraison).
• Documentation, produire les informations nécessaires pour l'utilisation du logiciel et pour des éventuelles
évolutions futures.
• Mise en production, livrer et valider le produit.
• Maintenance, entreprendre des actions correctives (maintenance corrective) et évolutives (maintenance
évolutive) sur le logiciel.
En fonction du choix d'un modèle de cycle de vie entre le client et l'équipe de développement, on aura un séquencement
ou la présence de chacune de ces activités dans le cycle de vie correspondant.
Par exemple, dans le modèle en V, les procédures de vérification de la conformité du logiciel aux spécifications sont
supposées être élaborées dès les phases de conception.
1.6 Représentations des modèles de développement
1.6.1 Modèle Exploratoire

Cette approche est essentiellement informelle.
Codage
Test
Mise au point
Figure 1. Modèle exploratoire

1.6.2 Modèle Cascade
Le modèle en cascade est présenté ci-dessous. Il faut noter que dans ce modèle, une modification dans une étape
« N » ne remet en cause que l’étape « N-1 ».
Faisabilité
Analyse des -> spécification / cahier des charges
besoins
Conception du -> plan de tests
produit
Conception
Détaillée
documents de fonctionnement -> Codage
Intégration
résultats des tests -> Installation
Exploitation et
maintenance
Figure 2. Modèle en Cascade


1.6.3 Modèle en V
Le Schéma du modèle en V est présenté ci-dessous.
Analyse Installation
des besoins et test du
de
Faisabilité ----------------------------------------------------------------------------------> système
Conformité/complétion/Correction
Spécifications --------------------------------------------------------> Qualification
Conception ------------------------------> Intégration
architecturale et tests
Conception --------> Tests
détaillé unitaires
Programmation
Codage
Figure 3. Modèle en V
Dans le modèle en V, chaque spécification faite aux étapes de gauche doit correspondre à une procédure de test (jeu
de test à décrire pour s’assurer que le composant correspond à la description faite) aux étapes de droite.
1.6.4 Modèle en spirale

Ce modèle propose de généraliser les deux précédents. Il a été proposé par B.Boehem en 1988.
- Dans le premier tour, déterminer les objectifs du cycle, les alternatives, les contraintes en s’appuyant sur les cycles
précédents, ou sur une analyse primaire.
- Dans le deuxième tour : analyser les risques, évaluer les alternatives, proposer un maquettage.
- Dans le troisième tour : s’occuper du développement et de la vérification de la solution retenue en cours.
- Dans le quatrième tour : passer en revue les résultats du cycle précédent et planifier le cycle suivant.
Analyse des
Collecte des besoins Planification Analyse des risques risques basée sur
et Planification du la réaction des
projet usagers
Analyse des
risques basée sur
Planification basée les besoins
sur les
commentaires des Décision oui / non
usagers Prototype Initial
Prototype n-ième
Vers un Système
complété
Evaluations
Evaluation de l'usager Ingénierie
Système
Ingéniérisé
Figure 4. Modèle en spirale


1.6.5 Modèle Incrémental
Dans cette méthode, on évolue par incréments, en partant d’un noyau de base qui est par la suite complété
progréssivement. Généralement, une bonne planification et une spécification rigoureuse sont nécessaires, ainsi qu’une
bonne planification et une forte indépendance au niveau fonctionnel et au niveau du calendrier.
Identification
des incréments
Spécification
-----------
 des incréments
| Codage des
| incréments
| Evaluation des
| incréments
| |
-------------------------------------------------
Figure 5. Modèle Incrémental
1.7 Activités capitales du cycle de vie

Dans l’Ingénierie d’un système logiciel, on retrouve des outils servant tout au long du processus de développement.
On peut y retrouver au moins 4 types d’activités :
• Planification stratégique du développement des systèmes applicatifs.
Il s’agira de définir un processus décisionnel en se basant sur :
- Une politique informatique (missions ? objectifs ? règles ?)
- Une stratégie informatique (projets ? budgets ?)
- Une tactique informatique (faire plus avec moins)
- Une action informatique (exploitation courante)
• Développement p roprement dit.
- Spécification des besoins
- Conception générale et détaillée
- Réalisation
- Installation : mise en exploitation, gestion des versions, apprentissage, suivi de fonctionnement et
d’utilisation
- Maintenance
• Conduite des projets.
Il s’agit d’estimer les moyens prévisionnels, les délais et les coûts
- planification
- évaluation des charges, coûts et moyens
- animation et conduite des travaux lors des étapes du cycle de développement
- choix des méthodes à utiliser
- contrôle d’avancement et d’exécution de tâches
- organisation générale du projet
- gestion des relations contractuelles avec les utilisateurs
- définition des profils des participants au projet
- gestion et formalisation des dossiers
- gestion des relations contractuelles avec les fournisseurs
- suivi analytique des projets
• Assurance qualité
D’après l’AFNOR (Association Francaise de Normalisation), c’est « l’attitude du produit à satisfaire les
besoins (exprimés) des utilisateurs ».
Comment peut-on obtenir la qualité ?
- Définir clairement des exigences de sortie
- Mesurer la conformité à chaque phase
Cela implique 4 grands temps :
- Définition du processus et orientation de l’action qualité
o Diagnostic de la non qualité : problèmes, causes, poids, coûts, gain attendu de son
éradication
o Manuel qualité (spécifique au logiciel à réaliser)
o Plan qualité : politique, priorotés, actions, budgets, plannings, stratégies de conduite
(pourrait servir pour n’importe quelle entreprise)
o Fonction qualité

- Mise en œuvre du processus et action qualité (qui ?, comment ?, quand ?)


o Définition des normes de qualité (par thème, type de projet, secteur d’activité)
o Cahier de charges qualité : par projet
o Plan d’assurance qualité du projet selon les aptitudes requises (fiabilité, temps de réponse,
…)
o Contrat clients-fournisseur
o Maquettage, prototype et simulation
o Revues et inspection des étapes, de l’analyse des besoins au codage
o Règles et procédures de tests : étapes de test, construction des jeux d’essai, outils et
méthodes de tests, délais, niveau de test à atteindre
o Qualimétrie du logiciel : évaluaton de la complexité du logiciel, difficulté de maintenance,
risques
o Recette de qualification : inspection par le client, conformité par rapport au cahier de
charges fonctionnel, au cahier de charges qualité
o Gestion opérationnelle de la qualité : suivi périodique des actions qualité, des fournisseurs
de l’application, des plans d’assurance qualité, de l’évolution de la non qualité
- Mesure de conformité et animation de l’action qualité. Il s’agit beaucoup plus de mobiliser des
informations et les partenaires, notamment :
o En créant les événements spécifiques
o En amenant le maximum d’acteurs à participer
o En respectant les valeurs individuelles et la confiance
- Amélioration par des moyens divers pouvant contribuer à la réussite des trois autres volets
o Financiers
o Humains
o Techniques (logiciels, matériels, documentation)
En définitive, il s’agit de satisfaire les besoins de l’utilisateur au sens large.
La qualité peut être « prouvée » en maîtrisant les paramètres tels que les coûts, les délais. On doit pouvoir la
mesurer ou tout au moins la quantifier.
1.8 La Spécification
La phase la plus délicate dans le processus de développement du logiciel, c’est celle des spécifications. Il s’agit de
spécifier ce qui doit être fait. Bertrand Meyer [Meyer 90] a défini les 7 pièges qui nous guettent lors d’un procéssus de
spécification, mais également les 7 mots clés de réussite.
1.8.1 Les 7 péchés :
- Bruit : élément qui n’apporte aucune information (!) / redondance (!)
- Silence : caractéristique d’un problème auquel ne correspond aucune partie du texte
- Surspécification : lorsqu’on se lance dans un développement qui donne des détails inutiles (par exemple
anticiper sur les tables de la BD quand cela n’est pas nécéssaire …)
- Contradiction : dans les séquences de spécification (sens opposés)
- Ambiguités : une phrase peut avoir 2 ou plusieurs sens
- Référence en avant : étant à une page, vous faites allusion à un concept qui sera présenté plus loin
- Vœu pieux : attention à des éléments non vérifiables (!)
1.8.2 Les 7 caractéristiques d’une bonne spécification :
- Conforme (conformité aux besoins réels et non aux besoins supposés exprimés, souvent limités)
- Communicable
- Faisable
- Modifiable
- Validable
- Complète
- Cohérente
1.8.3 Les méthodes
Lors de la phase de spécification, nous avons besoin au départ d’interviews bien faites, pouvant déboucher sur une
bonne documentation.
Les méthodes de spécification de logiciels seront de trois catégories :
- Informelle (structurée)
- Semi-formelle
- Formelle (mathématique)
Les méthodes de spécification intègrent :
- Modèle
- Démarche
- Langage
- Outils
On pourrait leur associer des environnements textuels, graphiques ou mixtes facilitant la compréhension et l’expression.


• Méthodes Informelles
Elles n’ont pas un formalisme supportant une vérification, une validation (informatique ou simulation mathématique)
Cas de SADT (dans son approche fonctionnelle), BOOCH (dans son approche objet initiale), MERISE…
• Méthodes Semi-formelles
Elles permettent des vérifications, mais pas sur tous les apspects.
Cas de SADT avec SART, Réseaux de Petri, E/A avec langages … (entité association)
• Méthodes Formelles (spécification formelle)
Elles intègrent des langages permettant de définir toutes les contraintes et de garantir les vérification et la validation
complète. Ces langages basés sur les mathématiques vont pouvoir prendre en compte n’imorte quel concept abstrait ou
logique. Les outils sont beaucoup plus orintés vers :
- Automates
- Logique (temprelle, modale)
- Algebre (algebre universelle, algebre de processus)
- Mixte (combinaison)
À titre d’exemple, nous allons citer :
* VDM (Vienna Description Method) :
Ce langage utilise la théorie des ensembles pour décrire les entités et les objets ; mais aussi les formules de la
logique de prédicats pour spécifier les propriétés (classes, etc.).
* Langage Z :
Z est un langage formel développé à l’Université d’Oxford à la suite des travaux de Jean René Abrial. Le langage
Z utilise les notions ensemblistes, le calcul des propositions (et, ou, non, implication, etc.) et des prédicats
(quantificateurs existentiels – il existe - et universel – quel que soit -), les relations (partie du produit cartésien de
plusieurs ensembles) et fonctions (relations avec au plus une image par valeur du domaine de définition), les
séquences ou suites (fonctions des entiers naturels dans un autre ensemble pour imposer un ordre aux valeurs).
* Langage B :
B est une méthode (incluant le langage B) également développée par J.R. Abrial, qui pourrait substituer Z. B couvre
le processus, de la spécification formelle au programme.
La méthode B dispose d’un langage de spécification à base de machines abstraites, d’une technique de raffinage des
spécifications (des notions abstraites aux notions des langages de programmation), des obligations de preuve
associées à chaque étape, d’un outil permettant de supporter ce processus (atelier B, Steria).
* Méthode et Langage RAISE :
RAISE (Rigourous Approach for Indistrial Software Engineering) est une méthode développement formelle assez
rigoureuse, qui possède son propre langage formel spécification [Raise95].
1.8.4 Les démarches d’analyse

Lorsqu’on veut modéliser un système, il faut modéliser trois catégories d’entités :
• Données : aspects statiques, objets, attributs et relations
• Fonctions : transformations des données dans le système
• Dynamique : changements dans le temps (suite aux événements), contrôles (ex : modéliser les données en
fonction du temps)
La démarche peut être orientée fonctionnelle, objet, modèles, mixte, etc.

• Approches Fonctionnelles
Les données et les traitements sont modélisés séparément. Exemples: SADT-SART, MERISE, etc.
• Approches Objets
Les données et les fonctions sont encapsulées dans les mêmes « boites » qui dialoguent e0ntre elles (les objets) par
envoi de messages. Exemples: Booch, HOOD, OOA, OOD, SOART, FUSION, OMT, OOM, UP, MACAO, etc.
• Approches Modèles
On étudiera MDE (Model Driven Engineering) plus loin dans ce document.
• Approches Agiles (voir méthodes Agiles plus loin dans le document).
Dans tous les cas, lors de votre démarche éssayez toujours de prendre en compte :
- Un maximum de modèles de besoins
- Des modèles d’analyse suffisants
- Une représentation des processus (fonctions + données)
- Des modèles de contrôle suffisants
- Une lisibilité claire du dictionnaire de données
- Une bonne illustration des entrées et sorties (éventuellement les temps de réponse)


1.9 Vérification et Tests de logiciels
1.9.1 Concepts
Tester un logiciel, c’est valider sa conformité par rapport à des exigences, c’est-à-dire par rapport à l’ensemble de la
spécification, et de la conceptiondu logiciel et en fonction d’un certain nombre de critères. Par exemple, domaines
d’entrées, taux d’erreurs acceptable, etc.
• Il existe plusieurs méthodes de test : –Test boîte noire-blanche, –Prédiction d’erreur (on sait ce qu’on cherche)
–Tests automatiques, ...
• De même, il existe différents types de tests : fonctionnels, non-fonctionels, structurels.
Le document de l’IEEE (norme 729) indique que la faute est à l’origine de l’erreur, qui se manifeste par des
anomalies dans le logiciel, qui peuvent causer des pannes.
faute => erreur => anomalie => panne
1.9.2 Réalisation
Le cycle de vie du projet logiciel doit intégrer les tests, avec notamment les documents suivants [wwwTestLog11] :
• Plan Projet: il s’agit du plan global du projet, servant de référence pour l’ensemble
• Spécification / Conception: il s’agit des documents permettant l’élaboration du code et des tests associé
• Plan de tests: il s’agit d’un document qui décrit :
– L’organisation du test (équipes, environnement)
– Les stratégies (en fonction deséléments d’objectifs du projet, despécifications, d’architectures, différentes
stratégies de tests sont à envisager.
Ex WEB: test de l’interface, test de la logique “business” (authen-tification, transaction,...), test de la base,
test de performances, destress ...
– Les critères d’arrêt des tests: 100% de couverture de code n’est pas 100% des possibilités.
• Standard de test. Il assure une homogénéité d’écriture et de validation.
• Rapports de tests. Il permet de donner un état précis de ce qui aété testé, et des résultats obtenus.
En particulier, il faut pouvoir indiquer : quelles sont les exigences couvertes ? –et comment les a-t-on
couvertes (combien de tests/exigences, testsnormaux, aux limites, de robustesse).
• Traçabilité : Il s’agit d’assurer une bonne traçabilité entre les exigences et les tests. En particulier, cela permet
d’avoir une connaissance de l’impact d’une modification de spécification.
1.9.3 Organisation du test

Cette activité couvre différents aspects:
• Humain: Cet aspect consiste à spécifier qui fait quoi (Plan de test)
– Comment est constituée uneéquipe de validation
– Comment elle interagit avec le développement
– Comment le département Qualité (s’il existe) interagit
– Quelle est l’interaction avec l’utilisateur final
• Technique: Cet aspect indique le « Comment » :
– Comment met-on en place la base (ou les bases) de tests
– L’environnement matérieléventuel (hôtes, mais cartes embarquées, autre matériel, réseau, ...). Il faut être au
plus près de la mise enœuvre finale.
– Quel outillage pour les tests automatiques ? Pour les mesures detests ?
– Utilisation d’outils maison ou COTS: s’est-on assuré de leur validité?
1.9.4 Le graphe de contrôle d’un programme

C’est un graphe qui résume les structures de contrôle d’un programme donné.
[Lonchamp03]
Figure 6 Quelques éléments de construction des graphes de contrôle des programmes
La construction d’un graphe de contrôle de programme permet (à l’aide de jeux de tests) de vérifier le programme en
s’assurant que des critères de couverture sont réunis.


La complexité cyclomatique est déterminée par la formule C = A – N + 2, où A est le nombre d’arcs et N est le nombre
de nœuds. La complexité cyclomatique d'une méthode augmente proportionnellement au nombre de points de décision.
- Une méthode avec une haute complexité cyclomatique est plus difficile à comprendre et à maintenir.
- Une complexité cyclomatique trop élevée (supérieure à 30) indique qu'il faut refactoriser la méthode.
- Une complexité cyclomatique inférieure à 30 peut être acceptable si la méthode est suffisament testée.
- La complexité cyclomatique est liée à la notion de "code coverage", c'est à dire la couverture du code par les
tests. Dans l'idéal, une méthode devrait avoir un nombre de tests unitaires égal à sa complexité cyclomatique
pour avoir un "code coverage" de 100%. Cela signifie que chaque chemin de la méthode a été testé.
Ceci peut permettre aussi d’indiquer la complexité d’un programme, dans une certaine mesure. En plus, « C » est la
borne supérieure du nombre de tests à effectuer pour que tous les arcs du graphe soient couverts au moins une fois.
De façon plus générale, lorsque votre graphe n’est pas connexe (fait de plusieurs composantes par élément), la
complexité cyclomatique d'un programme structuré est définie par : C = A – N + 2P
P étant le nombre de composantes connexes du graphe. Evidemment, dans le cas particulier d’un graphe connexe, fait
d’une seule composante, on a P=1.
Exemples de prorammes et de graphes de contrôle correspondants
1- Exemple-Algo1 : Algorithme d’Euclide (calcul du pgcd d’un nombre)
begin
read(x) ; read(y) ;
while (not (x = y) ) loop
if x > y then
x := x - y ;
else
y := y - x ;
end if ;
end loop ;
pgcd := x ;
end ;
2- Exemple-Algo2 : conditionnelle simple

if x < 0 then
x := -x ;
end if ;
z := x ;
3- Exemple-Algo3 : double conditionnelle

if (not (x=0)) then
y := 5 ;
else
z := z - x ;
end if ;
if (z > 1) then
z := z / x ;
else
z := 0 ;
end if ;
Figure 7 Graphes de contrôle pour les exemples Algo1, Algo2 et Algo3 présentés plus haut


1.9.5 Techniques de Tests
Les chiffres montrent que dans un processus de développement, la phase de test coute 40% de l’ensemble (avec 40%
pour l’analyse et 20% pour le codage). Ceci pousse à réaliser des programmes de tests qui peuvent parfois être plus
longs que le programme à tester. Le concepteur devrait donc y penser dès le départ.
Durant les étapes du cycle de vie, on pourra retrouver des tests aux principales étapes :
- tests d’unités (centrés sur les composants)
- tests d’intégration (centrés sur les modules)
- tests de validation (vérification des fonctionnalités, performances …)
- tests de réception (« in situ » avec le personnel)
- tests de régression (suite à des modifications)
Les tests doivent permettre de détecter des érreurs ou des insuffisances dans un logiciel, en se basant sur un
référentiel défini au préalable. On retrouvera généralement au niveau opérationnel :
- les tests de vérification : il s’agit de s’assurer que le système est conforme aux spécifications initiales.
- les tests de correction : il s’agit de s’assurer que le système fournit des résultats exacts.
- les tests de validation : il s’agit de s’assurer que le système répond aux attentes de l’utilisateur et aux
contraintes de l’environnement.
Un gros projet doit absolument avoir un responsable des tests. Les tests effectués pourront être statiques (porter
sur des textes, des spécifications ou des modules programmes sans les exécuter) ou dynamiques (porter sur des
programmes à exécuter ou sur des séries de données entrées).
• Dans une approche statique, il est recommandé une vérification par plusieurs personnes (relecture des
acteurs de différents niveaux et parfois même extérieurs au projet) des différents documents d’analyse, de
codage (types de variables, initialisation, portabilité, branchement de code, incohérences, contraintes sur les
attributs d’une table ou d’un fichier…), les modèles de BD, domaines de variation, preuves d’algorithmes,
finition, etc. Les relectures dans certains cas seront collégiales. Ceci correspond à ce que l’on appelle l’analyse
de propriétés du système, sans exécution (vérification statique).
1- Techniques informelles
A l’aide de « check », on peut vérifier/rechercher des erreurs sur un document (revue ou inspection) ou sur
un code (parcourir comme le ferait une machine – « code walk through »).
2- Techniques formelles
On peut vérifier/rechercher des erreurs sur un programme en utilisant des langages formels (ou
mathématiques) pour prouver le programme.
Lorsqu’il est possible de prouver {pré condition} programme {post condition}, alors on parle de
correction partielle.
Or, normalement il faut ajouter une preuve de terminaison du programme pour prouver la totalité de la
correction du programme.
* Nous avons l’axiome de substitution arrière : {Q[x\exp]} x := exp {Q}
qui nous fait savoir que si Q est vraie pour x après l’affectation alors Q est vraie pour exp avant
l’affectation. Il suffit de réécrire l’expression Q avec exp à la place de x.
Application : Soit le programme suivant : on nous demande de le prouver, avec comme précondition {true}
et comme postcondition {output = input1 + input2 }
{true}
begin
read(a) ;
read(b) ;
x := a + b ;
write(x) ;
end
{output = input1 + input2 }
Preuve :
Si {output = input1 + input2 } est vrai après write(x), c’est à dire output = x,
{ x = input1 + input2 } doit être vrai après x := a + b.
Donc {a + b = input1 + input2} doit être vrai après read(a), c’est à dire a := input1.
Donc {input1 + b = input1 + input2} doit être vrai après read(b), c’est à dire b := input2.
Donc {input1 + input2 = input1 + input2} doit être vrai initialement.
Comme cela est toujours vrai on prouve bien que la pré-condition du programme {true} implique la
post-condition. Le programme est correct.
* Voici la règle générale de preuve pour les structures de contrôle :


A partir de là, on peut comprendre que si les assertions 1 et 2 sont vraies alors l’assertion 3 est vraie (et
réciproquement).
Soit une conditionnelle if cond then S1 else S2 endif dont la pré condition est Pre et la post condition est
Post. La rège de preuve est :
* Voici la règle générale de preuve pour l’itération while :
I est une assertion donnée, appelée « invariant de boucle », qui est conservée « vraie » à chaque itération
quand cond est vraie. Alors, quel que soit le nombre d’itérations, I sera vrai à la sortie du while ainsi que
not cond. Cet invariant de boucle, qui « traverse » la boucle, n’est pas toujours facile à trouver.
Remarque : L’exercice de « preuve formelle de programmes » n’est pas très courant dans la pratique, car
jugé trop abstrait et parfois complexe. Toutefois, il est recommandé d’en tenir compte pour pouvoir mieux
concevoir et même documenter les programmes écrits. Il est possible d’insérer des assertions, pré, post et
invariants de boucle, dans le code du programme (Java, …) pour aider lors du déboguage de programmes
• Dans une approche dynamique, il est important d’élaborer un « plan de tests » et un « dossier de
justification » de ceux-ci (choix des tests, résultats attendus, résultats obtenus, tests exclus pour certaines
raisons telles que le coût ou l’impossibilité physique…). Elle correspond également à ce que l’on appelle
l’expérimentation (test) du comportement de l’application avec un ensemble bien choisi de exp à la place de x.
 Approche fonctionnelle (« boite noire ») :

- On tient compte beaucoup plus des sorties attendues du programme, et non de sa structure interne.
Données => [ Programme ] => Résultats
- Si vous procedez à des tests aléatoires (statistiques), ils faciliteront des tirages selon une loi de probabilité
qui peut être uniforme ou basée sur une distribution aléatoire (poisson, gauss…)
- Vous devez choisir les données de test de façon judicieuse !
- Ne pas se limiter uniquement aux données « normales » ! mais prévoir des données sensibles pouvant
entraîner des exceptions.
* test aux limites (valeurs frontières)
* tests hors limites (monkey)
* cas nominaux
Exemple :
-2 0
X/0 (-1) (0)
 Approche structurelle (« boite blanche »)

Cette approche met plus d’accent sur la structure interne du programme. Plusieurs critères peuvent être utilisés :
Couverture des instructions, Couverture des arcs du graphe de contrôle, Couverture des chemins du graphe de
contrôle, Couverture des conditions. Il est d’ailleurs recommandé de combiner ceux-ci pour certains cas.
Lorsqu’on a représenté chaque instruction de de contrôle au sein du programme par son élément graphique et on
a construit le graphe de proche en proche, les tests peuvent être facilement faits.
Ceci entre dans les techniques dites de représentation en boîte blanche. Les structures de contrôle du programme
à tester seront remplacées par une sorte de « graphe de flot ».
La couverture des arcs suppose qu’en simulant l’exécution de l’algorithme avec le jeu de données, vous traversez
chaque arc du graphe (Entre deux nœuds, on a des arcs).
Par contre, la couverture des chemins suppose la traversés de tous les chemins possibles, entre le nœud initial et
le nœud terminal.
- Couverture des instructions : s’assurer que chaque instruction élémentaire est exécutée au moins
une fois ;
- Couverture des arcs du graphe de contrôle ; Nous allons prendre ici deux exemple :
* En considérant le cas de l’algorithme « Exemple-Algo1 » présenté plus haut, en prenant le jeu d’essai constitué des
valeurs (x=3,y=3), (x=4,y=3), (x=3,y=4) on constate qu’il satisfait les 2 critères de couverture (instructions et arcs).
* En considérant le cas de l’algorithme « Exemple-Algo2 » présenté plus haut, (x = -2) satisfait le critère de
couverture des instructions mais pas celui des arcs. Il faudrait aussi tester ce qui se passe quand x est positif.
- Couverture des chemins du graphe de contrôle ; Nous prenons ici un exemple :


* En considérant le cas l’algorithme « Exemple-Algo3 » présenté plus haut, le jeu d’essai (x=0,z=1), (x=1,z=3)
vérifie la couverture des arcs mais pas celle des chemins et ne peut donc détecter une division par zéro.
(x=0,z=3), (x=1,z=1), (x=0,z=1), (x=1,z=3) vérifie la couverture des chemins et détecte donc la division par zéro.
Comme inconvénient de cette approche, le nombre de chemins grandit très vite pour des programmes
réels, ce qui fait que ce critère devienne difficile à exploiter de façon pratique.
- Couverture des conditions : il s’agit de couvrir à VRAI et à FAUX toutes les conditions
élémentaires de toutes les conditionnelles du programme.
Exemple :
if (a > 1 and b = 0)
x := x / a ;
end if ;
if (a = 2 or x > 1) then
x := x + 1 ;
end if;
Application:
a > 1 False True
b=0 False True
a=2 False True
x>1 False True
On voit ici que le jeu (a=1,b=0,x=3), (a=2,b=1,x=1) couvre bien toutes les conditions mais
pas toutes les instructions.
• Dans une approche orientée objet par exemple, il est préférable de décrire les méthodes de test en même
temps que les autres méthodes de la classe, et les encapsuler directement, en indiquant les valeurs attendues à
chaque fois.
• Autres Recommandations :
• Les méthodes de test ne doivent pas être longues et doivent être au mieux simplifiées et bien commentées.
• Les jeux de tests doivent être définis clairement et justifiés
• N’hésitez pas à effectuer certains tests au fur et à mesure de la mise en œuvre
• Certaines méthodes doivent illustrer clairement les modes d’utilisation des autres méthodes jugées importantes
• En cas de nécessité, faire appel à des générateurs (aléatoires…) de tests et contrôle de tests automatiques
(exemple : JTests, assert etc.)
1.9.6 Processus de test de codes

Comment tester ? Les tests peuvent être effectués de plusieurs manières :
• Manuellement
• Automatiquement (grâce aux outils tels que WinRunner, Rational Robot, LoadRunner, TestDirector …)
• Combinaison des techniques manuelle et automatique.
1.9.6.1 Problématique :
Beaucoup de langages, à l’instar de PHP sont flexibles, permissifs et faciles à appréhender. Malheureusement,
certains principes qui font la force de certains langages ne sont pas implémentés dans d’autres langages. Par exemple, la
rigeur et les contraintes de conception généralement imposées dans les langages à vocation industrielle (C++, Java, etc.)
ne s'appliquent pas nécessairement avec des langages d’accès comme PHP.
Finalement, le programmeur est seul maître à bord, il choisit la précision avec laquelle il souhaite intégrer un
paradigme, que ce soit impératif, fonctionnel ou orienté objet, tout comme il décide de structurer ou non son
développement par rapport à des processus éprouvés. Cette grande liberté est à l'origine du succès du langage, mais c'est
également son plus grand défaut.
Beaucoup de développeurs (PHP…) qui n'ont pas de formation spécifique en programmation ou qui sont peu
expérimentés ne perçoivent pas l'importance d'un processus de développement, et de test en particulier.
L'abscence d'une forme structurée de tests engendre notamment les problématiques suivantes :
Le code source n'est pas testé en profondeur : cela a pour conséquence des aléas de « post-publication », plus ou
moins critiques. Le plus souvent il s'agit d'instabilités dans l'application ou des problèmes de sécurité classiques.
Le code source n'est pas robuste : toute modification du code source (refactorisation, ajout de fonctionnalités) est
susceptible d'engendrer des régressions.
Le code source n'est pas réutilisable, pas transmissible : si un autre développeur doit vous assister ou reprendre votre
travail, il sera confronté d'une part à votre code source et d'autre part à l'absence d'un protocole de test uniformisé.
Le code source n'est pas évolutif : il va sans dire, plus votre application aura une structure complexe, plus vous
peinerez à déceler des erreurs et problèmes de conception de manière empirique. Vous serez contraint à moyen terme,
de reprogrammer entièrement votre application.


Tout ceci aura non seulement un impact sur la fiabilité de votre programme (et vos prestations de service), mais
également sur le temps alloué pour le développement et la maintenance du projet, avec les tracasseries que cela
implique pour vous et vos utilisateurs finaux.
1.9.6.2 Processus de test :

Nous présentons un processus et quelques conseils vous permettant d'utiliser les tests unitaires dans vos projets PHP.
[Grossglauser07]
Figure 8. Processus de de développement dirigé par les tests
Le processus qui vous est proposé ci-dessus fait abstraction des contraintes liées à la gestion de projet (cahier des
charges, organisation interne, etc.) ainsi que de la phase d'analyse. Il est basé sur le développement piloté par les tests
(TDD) et s'adresse particulièrement aux développeurs (PHP) autonomes.
Si vous développez en équipe, la base restera sensiblement la même mais vous devrez fournir des précisions au niveau
de l'organisation et du partage des tâches, notamment.
Le développement piloté par les tests (Test-Driven Development, ou TDD) est une méthode de développement mettant
les tests unitaires au premier plan, on peut résumer son processus en cinq étapes :
1 Ajouter un test,
2 Vérifier qu'il ne passe pas,
3 Implémenter la fonctionnalité,
4 exécuter les tests unitaires - déboguer en cas d'échec,
5 refactoriser le code source - exécuter à nouveau les tests unitaires, passer à l'objectif suivant...
En reprenant le processus ci-dessus, vous observerez que l'approche TDD débute dès la phase de conception.
Dans l'idéal, la structure de votre application devrait être modélisée dans un éditeur (UML…) puis son squelette généré
directement dans des fichiers (PHP).


2 Méthodes SADT et Réseaux de Petri
2.1 Introduction
Des méthodologies développées permettent de modéliser des systèmes à risques, pour contribuer à l'intégration de la
Sécurité Opérationnelle dans la phase d'analyse et de spécification des « systèmes automatisés ». Il s’agit de SADT et
Réseaux de Petri (RdP).
• L'approche systémique, hiérarchique et structurée du SADT, est généralement bien adaptée pour représenter au
mieux les connaissances structurelles et fonctionnelles du système étudié.
• Le formalisme des RdP, adapté à la prise en compte des problèmes de concurrence, de synchronisme et de
parallélisme, constitue un excellent outil de spécification fonctionnelle d'un problème et de mise en évidence
des contraintes. Les propriétés mathématiques qui découlent de l'analyse des RdP permettent une étude
comportementale et structurelle essentielle à la validation d'une spécification.
2.2 Spécifications à l’aide des Réseaux de Petri
2.2.1 Description
Le Réseau de Pétri (RDP) décrit « mathématiquement » des systèmes grâce une représentation graphique dont les arcs
et les nœuds sont valués avec des marquages.
Il offre la possibilité de parallélisme, synchronisation, concurrence, exclusion, etc.
Un RdP a des propriétés intrinsèques (dépendant ou non du marquage de départ) comme les branches mortes
(inaccessibles), cycles, etc.
Les places Pi et les transitions Ti d'un réseau de Petri, en nombre fini et non nul, sont reliées par des arcs orientés. Un
réseau de Petri est dit graphe biparti alterné, c'est à dire qu'il y a alternance des types de noeuds : tout arc, qui doit
obligatoirement avoir un noeud à chacune de ses extrémités, relie soit une place à une transition soit une transition à une
place.
Pour définir l'état d'un système modélisé par un réseau de Petri, il est nécessaire de compléter le réseau de Petri par un
marquage. Ce marquage consiste à disposer un nombre entier (positif ou nul) de marques ou jetons dans chaque place
du réseau de Petri. Le nombre de jetons contenus dans une place Pi sera noté mi. Le marquage du réseau sera alors
défini par le vecteur M = {mi}.
[KaiserCottet01]
Figure 9. Exemple de réseau de Petri marqué avec un vecteur de marquage M = (1,0,1,0,0,2,0)


L'évolution de l'état du réseau de Petri correspond à une évolution du marquage. Les jetons, qui matérialisent l'état du
réseau à un instant donné, peuvent passer d'une place à l'autre par franchissementiou tir d'une transition. Dans le cas
des réseaux dits à arcs simples ou de poids 1, la règle d'évolution s'énonce de la manière suivante :
Le franchissement d'une transition consiste à retirer un jeton dans chacune des places en amont de la transition et à
ajouter un jeton dans chacune des places en aval de celle-ci.
Avant Franchissement Après franchissement
Mt = (1,2,1,0) Mt+1 = (0,1,2,1)
[KaiserCottet01]
P1 P2 U- Consommation
T1 T2 T3 T4 T5
P1 2
P2 1
2 P3 1 2
T1 T2 P4 1
3 P5 1
P3
U+ Production
T1 T2 T3 T4 T5
P1 2
T3 T4
P2 1
P4 P5 P3 1 3
P4 1
P5 1
T5
2
Figure 10. Un RdP (comportant 5 places et 5 transitions) / et Matrices
Un RdP peut être décrit entièrement avec les matrices d’incidences (ou caractéristiques) U-, U+ et un « marquage ».
Les “jetons” ont généralement une interprétation semantique qui designe un changement d’état dû au franchissement
de la transition.
Les interfaces avec l’extérieur se matérialisent par des transitions sans place.
Il existe de nombreux développements et alternatives : les réseaux temporisés, colorés, continus, hybrides, etc.
NB : Plusieurs formalismes tels que « Grafcet » et « MERISE » (MCT) se sont à la base inspirés des réseaux de Petri.
2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri

Les règles générales d'évolution des réseaux de Petri marqué simple sont les suivantes :
• une transition est franchissable ou sensibilisée ou encore validée lorsque chacune des places en amont
possède au moins un jeton,

•

le réseau ne peut évoluer que par franchissement d'une seule transition à la fois, transition choisie parmi
toutes celles qui sont validées à cet instant,
• le franchissement d'une transition est indivisible et de durée nulle.
NB : si une transition est validée, cela n'implique pas qu'elle sera immédiatement franchie. Ces règles introduisent en
effet un certain indéterminisme dans l'évolution des réseaux de Petri, puisque ceux-ci peuvent passer par différents états
dont l'apparition est conditionnée par le choix des transitions tirées. Ce fonctionnement représente assez bien les
situations réelles où il n'y a pas de priorité dans la succession des événements.
2.2.3 Graphes de marquages

L'évolution temporelle d'un RdP peut être décrite par un graphe de marquages représentant l'ensemble des marquages
accessibles et d'arcs correspondant aux franchissements des transitions faisant passer d'un marquage à l'autre pour un
marquage initial M0.
P1 P3
T3 Avec M0 : (1, 0, 1,0)
M2 M1 : (0, 1, 0, 1)
T1 M2 : (1, 0, 0, 1)
T2 M3 : (0, 1, 1, 0)
T1 T2 T3 Mo M1
T3
M3
T1
P2 P4
[KaiserCottet01]
Figure 11. Graphe de marquage
Remarque : cette représentation permet de déterminer certaines propriétés d'un graphe. Par exemple si le graphe
présente une zone non bouclée, cette partie du marquage une fois atteinte constitue un arrêt de l'évolution du RdP et
celui-ci sera déclaré avec blocage.
2.2.4 Limites des RdP et extensions des possibilités

La capacité de description du modèle par réseau de Petri trouve ses limites lorsque des dates absolues apparaissent dans
le cahier des charges. En effet, le temps n’est pas pris en compte explicitement par ce modèle. Il est donc difficile de
représenter des applications contenant des recommandations telles que « à la date t, ... ». En revanche, la prise en
compte de la durée est tout à fait possible grâce aux extensions temporelles du modèle de base. Il est donc tout à fait
naturel d’envisager une représentation par réseau de Petri d’un cahier des charges contenant : « après une attente de
10 secondes, ... ». La distinction n’est pas toujours immédiate mais découle d’une référence à un temps absolu (date) ou
à un temps relatif (durée). Une autre limitation importante du modèle à réseau de Petri concerne la non-existence de
mécanisme d’abstraction. Hormis l’utilisation du concept d’activité décrit dans cet article et qui n’est pas spécifique à
ce modèle, aucun mécanisme d’agrégation n’est véritablement proposé par les réseaux de Petri.
2.2.5 Extensions et autres Outils proches

Bien sûr, d’autres outils de modélisation peuvent être utilisés pour la modélisation à événements discrets. Par exemple,
les automates à états finis permettent de capturer sans difficulté le comportement séquentiel d’une application. En
revanche, dès que des évolutions simultanées doivent être représentées, surtout si elles doivent être synchronisées de
temps à autre, la représentation par graphe d’état devient complexe (on parle d’explosion combinatoire du nombre
d’états) et surtout le comportement global du modèle devient difficile à appréhender. Le Grafcet (graphe fonctionnel de
commande étape transition, langage normalisé pour les API – Automates Programmables Industriels) peut être utilisé en
lieu et place des réseaux de Petri. Il convient de savoir que le Grafcet, qui a été défini par un groupe de travail de
l’Adepa dans les années 1980, est en fait un dérivé des réseaux de Petri binaires. Le Grafcet peut être préféré pour des
questions de mise en œuvre. En revanche, il devient rapidement difficile à utiliser quand le besoin de comptage (de
pièces, de messages, etc.) se fait sentir et l’on aura alors plutôt recours aux réseaux de Petri. Signalons enfin que la règle
du Grafcet stipulant que « toutes les transitions franchissables sont franchies simultanément » introduite pour le rendre
déterministe transforme, en cas d’erreur de modélisation, un « choix » en « départ en parallèle ». Ce problème n’existe
pas avec les réseaux de Petri. Une extension des automates à états finis, les statecharts, constitue une alternative à la
modélisation des systèmes à événements discrets. Ils intègrent l’abstraction, l’orthogonalité pour le parallélisme et la
diffusion pour les communications. Le problème de la validation globale d’une application n’est toutefois pas résolu. À
noter que les statecharts permettent de modéliser simplement les mécanismes de préemption sur un groupe d’états et


comportent un mécanisme d’historique permettant de replacer le modèle dans le dernier état qui avait été atteint avant
une préemption. Les statecharts sont à considérer pour des applications comportant ces mécanismes, mais il faut savoir
que la mise en œuvre d’un statechart est un problème non résolu à l’heure actuelle.
• Les Réseaux de Petri Stochastiques généralisés et les Processus de Markov sont utilisés comme moteur de
calculs.
• Les extensions des RdP aux RdP-temporisés et RdP-stochastiques, permettent de prendre en compte l'aspect
dynamique des problèmes, permettant de faire, par exemple, de l'évaluation de performances.
2.3 Spécification à l’aide se SADT & IDEF

2.3.1 Présentation
SADT (Structured Analysis and Design Technique) est une méthode graphique établie par Douglas T. ROSS (Softech)
vers 1974.
SADT part du constat selon lequel le monde est constitué de données et d’actions (comme c’est par exemple le cas avec
les noms et les verbes en Langage Naturel).
Parallèlement, le programme ICAM (Integrated Computer-Aided Manufacturing 1972) de l'US air force en commanda
une définition domaine publique nommée IDEF0 (1975). IDEF signifiait initialement Icam DEFinition method, mais a
depuis 1999 été rebaptisé Inegrated DEFinition method.
• ICAM établit ensuite d'autres modèles pour les aspects informationnels (IDEF1) et dynamiques (IDEF2).
• La version SART, prend mieux en compte divers aspects dynamiques, et surtout des opérations temps réel.
IDEF3 capture donc mieux collecter et décrire les flux de processus, avec l’état des objets.
• IDEF4 permet la Conception Orientée Objets.
• IDEF 5 permet de capturer la description des Ontologies.
• L’appoche a par la suite évolué en termes de définition de spécifications (les détails d’implémentation étant
progressifs) :
- IDEF6 : Design rationale capture
- IDEF7 : Information system auditing
- IDEF8 : User interface modeling
- IDEF9 : Business constraint discovery
- IDEF10 : Implementation architecture modeling
- IDEF11 : Information artifact modeling
- IDEF12 : Organization modeling
- IDEF13 : Three schema mapping design
- IDEF14 : Network design
Comme outil logiciel d'aide à la réalisation des diagrammes IDEF de différents niveaux nous avons :
http://www.idef.com/idef-software/
2.3.2 Modèles SADT

SADT/IDEF0 est une méthode graphique particulièrement bien adaptée pour une description fonctionnelle. Elle est
donc surtout utilisée en phase de spécification système ou logicielle.
La description comprend une série de « planches ». Chaque planche est la décomposition en sous-fonctions d'une
fonction du système. Cette décomposition est arborescente.
En SADT, les 2 aspects sont duaux et examinés ensemble.

* Les actigrammes mettent l’accent sur les activités (les données sont véhiculées sur les flèches). Ils visent à :
- conférer une valeur ajoutée (entrée -> sortie),
- créer une nouvelle donnée,
- solliciter (observer, contrôler, etc.) une donnée.
* Les datagrammes s’appuient sur les données (les flèches représentent les activités).
Ils exigent :
- les activités génératrices,
- les activités de contrôle,
- les unités utilisées.
Un modèle SADT est une suite hiérarchisée de diagrammes (datagrammes et actigrammes), obtenue par raffinements
successifs.
Au niveau général se trouve le diagramme de contexte (niveau –1), montrant les sources, les destinations.
Par la suite, chaque diagramme est :
• soit un diagramme fils analysant une partie du diagramme père,
• soit un diagramme père synthétisant les diagrammes enfants,

• soit les deux.

Chaque « boite » peut-être à nouveau décomposée en un diagramme plus détaillé (Zoom).
En fin de chaîne, un processus non décomposé est accompagné d’une mini spécification précisant comment sont
produites les sorties à partir des entrées.
Kit SADT :
• diagrammes d'activités
• conditions d'activités
• diagrammes de données
• diagrammes explicatifs (ou textes uniquement)
• liste hiérarchique des diagrammes
• glossaire
Un modèle est un ensemble de kits établis suivant différents points de vue, ou buts ou contextes (Point de vue de
l'utilisateur, du gestionnaire, de la maintenance de la production …)
2.3.3 SADT/IDEF0
2.3.3.1 LES ACTIGRAMMES SADT/IDEF0

Les actigrammes sont des diagrammes de décomposition fonctionnelle de l'application.
Les diagrammes
Le diagramme de contexte représente le système avec ses entrées et ses sorties
commande
entrée 1
sortie
entrée 2
SYSTEME
(e3)
mecanisme
A-0 Diagramme de contexte
Figure 12. Le diagramme de contexte SADT porte le nom A-0
Le système est ensuite décomposé en ses principales fonctions dans un diagramme A0 :
c1
commande
entrée 2
fonction 1
e2
entrée 1
e1 e1a fonction 2
sortie
e1b fonction 3 s1
mecanisme
m1
Fonctions principales
A0
Figure 13. Décomposition en fonctions principales (SADT)
Les fonctions 1, 2, 3 peuvent faire l'objet d'une décomposition dans les diagrammes A1, A2, A3. Le diagramme A1
pouvant être décomposé en A11, A12, etc.

Un diagramme doit comporter entre 3 et 6 fonctions.


Chaque diagramme (ex : A0) peut comporter ou être annoté à l'aide de graphiques non formalisés (suffixe F, ex A0F1,
A0F2, etc.), de textes libres (suffixe T, ex. A0T1, ...), ou de glossaires (suffixe G, ex. A0G1,...).
La fonction
e1
s
e2
Verbe
+ complément
Axx
m
Figure 14. Représentation d'une fonction (SADT)
Une fonction ou une sous-fonction du système à spécifier est représentée par une boîte. La fonction doit être nommée
par un verbe d'action et un complément d'objet.
Si une fonction est décomposée, le nom du diagramme fils est noté en bas à droite de la boîte (Axx).
Les flots
Les flots de données sont échangés entre les fonctions.
commandes
sorties
entrées
Fonction
Axx
mécanismes
Figure 15. Les flots de données (SADT)
Suivant le coté de connexion avec la boîte, ils ont un des quatre rôles suivants :
• Entrées : Ce sont les « entités » nécessaires à la fonction, transformées par elle en « sorties ».
• Commandes : Ce sont les entités qui commandent le déroulement interne de la fonction (au moins une
commande est obligatoire)
• Sorties : Ce sont les « entités » produites par la « fonction ».
• Mécanismes : Ce sont les « entités » nécessaires à la réalisation mécanique de la « fonction » (machines,
personnels, etc.)
Plusieurs flèches peuvent être connectées. Les flots peuvent être décomposés ou composés.
Une flèche en provenance de l'extérieur du diagramme comprend en plus de son nom un code (e/s/c/m) suivi de son
numéro d'ordre par rapport à la boîte.
Un nom de flot entouré de parenthèses (e3) n'est pas retrouvé dans le diagramme enfant (IDEF0).


Certaines conventions permettent de simplifier la représentation en utilisant des flèches à double sens.
LES DATAGRAMMES SADT
commandes
écriture lecture
Donnée
Figure 16. Datagrammes SADT
Les datagrammes utilisent le même formalisme que les actigrammes. Simplement, chaque boîte symbolise une donnée
du système ou un fichier.
Le datagramme est construit indépendamment de l'actigramme, il n'est pas la traduction inversée (de l’actigramme), ce
qui semble poser un problème de traçabilité. Les données en sont plus détaillées.
2.3.3.2 LES METHODES DE TRAVAIL

C'est peut-être l'apport le plus intéressant de la méthode (SADT), qui ne définit pas seulement un formalisme, mais
également une technique de travail en équipe. Ces techniques de travail ou d'autres similaires continuent à être
préconisées partout dans le domaine du génie logiciel.
Certains rôles y sont définis :
• les "auteurs" (analystes) de la spécification (équipe de projet),

• les "commentateurs" (critiques) amenés à critiquer constructivement la spécification (des auteurs d'autres
projets de la même division, etc.),
• les "lecteurs" amenés à lire ou à juger la spécification sans être tenus de rédiger des remarques écrites,
• les "experts", références du domaine d'emploi de l'application, consultés par les auteurs, souvent
commentateurs,
• le "bibliothécaire" chargé d'archiver et de distribuer les documents,
• le "comité technique" (facultatif) chargé de résoudre les litiges,
• le "responsable du projet".
Le cycle auteur/lecteur s'applique sur :

• des brouillons ou des réalisations partielles de la spécification (kits standards) entre auteurs et
commentateurs,
• des versions complètes entre auteurs, commentateurs, lecteurs, etc.
Une procédure et des formulaires sont prévus pour organiser et archiver les versions soumises à critiques, les remarques
des critiques, les réponses des auteurs.
De même le processus de collection des informations, d'interview, de conduite de réunion est décrit.
2.3.4 LES EXTENSIONS IDEF1/IDEF2
Dans les extensions, l'ICAM n'a pas complètement retenu les datagrammes de SADT. Deux autres modèles ont été
définis pour ajouter les aspects informationnels et dynamiques à celui fonctionnel des actigrammes de SADT/IDEF0.
2.3.4.1 IDEF1 (LE MODELE INFORMATION)

IDEF1 s'inspire des travaux de CHEN, BACHMAN et NIJSSEN.


ATTRIBUTS
NOM CLASSE ENTITE
1:M
M:N 1:1
ATTRIBUTS ATTRIBUTS
ATTRIBUTS
NOM CLASSE ENTITE
NOM CLASSE ENTITE NOM CLASSE ENTITE
M:1
ATTRIBUTS
NOM CLASSE ENTITE
Figure 17. Modèle d'information ("classes")

Les classes d'entités
L'analyse des données d'un système permet d'identifier des classes d'entités.
Les classes de relation
Les entités sont en relation. Une classe de relation définit un type de relation possible entre les entités de deux classes.
Les méthodes de travail
Une méthode de travail similaire à celle décrite dans IDEF0 est définie.
2.3.4.2 IDEF2 (LE MODELE DYNAMIQUE)

Un modèle IDEF2 est composé de trois sous-modèles différents :
• Sous modèle « Entity flow network »

La gestion d'une entité telle qu'elle a pu être identifiée dans la phase IDEF1, utilise des enchaînements d'activités à
l'intérieur du système.
Le sous-modèle "Entity flow network" est une représentation graphique de tous les chemins que peut suivre le
traitement d'une entité dans le système. Chaque chemin est constitué d'une succession d'activités.
• « Ressource Disposition Trees »

Ce type de diagramme dont la représentation est similaire à celle d'un organigramme permet de définir les conditions
de disponibilité d'une ressource, avec les actions possibles sur cette ressource :
 allocate
 free
 preempt
 error
• « System Control Networks »

Le symbolisme de ce type de diagramme est proche de celui du « Entity flow network submodel ». Ce diagramme
permet de représenter les activités ou conditions affectant l'état général du système, non spécifique d'une entité.
« Facility Diagrams »
Cet outil est un éditeur graphique doté d'un ensemble de symboles permettant de réaliser des diagrammes explicatifs
non liés directement à la méthode.
2.3.5 Avantages et Inconvenients de SADT

Inconvenients :
- aspect dynamique limité,
- cohérence entre actigramme et datagramme parfois difficile,
- pas ou peu de synchronisation.
Avantatge :
- très bonne lisibilité (même par des non informaticiens)
- nombre restreint de concepts, donc apprentissage rapide et facilité de communication
- structure hiérarchique très modulaire.


2.4 Conclusion
Pour une application à caractère distribué, les réseaux de Petri, de par leur fonctionnement asynchrone, s’imposeront
assez naturellement, sauf si les traitements de données constituent l’essentiel des opérations à modéliser. En effet,
l’interaction avec des données est bien prise en compte par le modèle « réseau de Petri à objets », mais si la structure de
contrôle est quasi inexistante, alors elle constituera plutôt une gêne qu’un avantage. Il faut s’orienter dans ces conditions
vers des modèles basés sur les flux de données (SADT, SA-RT). Un critère important qui peut conduire au choix des
réseaux de Petri est le besoin de pouvoir établir des preuves formelles de propriétés (vivacité ou atteignabilité par
exemple) devant absolument être satisfaites par l’application. La représentation formelle est alors un support de la plus
grande importance.


3 Approche orientée Objet et UML
3.1 Introduction
Deux types de motivations orientent actuellement les concepteurs dans le choix des méthodes de conception: la
possibilité de prendre en compte des applications et des systèmes de plus en plus complexes
[Gardarin97][Leray92][Zoller97] et le soucis de diminuer les coûts de réalisation et de maintenance. Avec l’ère des
nouvelles technologies, des réseaux informatiques et systèmes répartis, les applications ont atteint elles aussi un niveau
de complexité croissant et de ce fait, elles nécessitent à l’heure actuelle, des outils de programmation sophistiqués. On
constate que les applications dites technique, telles que la CAO, la cartographie, les systèmes de contrôle temps réel, le
CoDesign… représentent une activité croissante et nécessitent une plus grande participation des personnes aussi bien
pour l'effort de conception et validation que de maintenance et d'évolution.
Ces constats ont mis en évidence la nécessité de promouvoir l’abstraction de données, la modularité et la réutilisabilité
[Manhes98] des composants fabriqués.
Ainsi, beaucoup de méthodes ont vu le jour, chacune tentant à sa manière d’apporter une solution satisfaisante, parmi
elles, les méthodes objets (orientées objets) et leurs techniques d’analyse et de conception appropriées.
Pourquoi parler de l’approche Orientée Objets ?

La complexité et la taille des projets nécessitent des outils de développement nombreux et perfectionnés pour mener à
bien les applications dans les meilleurs délais.
En fait, les environnements à objets connaissent un succès grandissant, aussi bien dans le domaine de l’Intelligence
Artificielle (IA) que dans celui du Génie Logiciel ou des BD, car ils constituent sans doute l’une des solutions les plus
souples pour répondre à ces différents besoins.
3.2 Les concepts de base:

[Bouzegoub97]
Un objet est une abstraction d'une donnée du monde réel caractérisée ainsi :
Objet = identité + état + comportement
L'identité d'un objet est représentée par un identifiant (object identifier ou OID) unique et invariant qui permet de
référencer l'objet indépendamment des autres objets. L'état d'un objet est une valeur qui peut être simple (par exemple,
un littéral), ou structurée (par exemple, une liste). Dans le dernier cas, l’état peut être composé de valeurs simples, de
références à d'autres objets, ou de valeurs elles-mêmes structurées. Le comportement d'un objet est défini par un
ensemble d'opérations applicables à l'objet et définies dans sa classe d'appartenance. En résumé, nous avons la
définition suivante :
Objet : abstraction d'une donnée caractérisée par un identifiant unique et invariant, un état représenté par
une valeur simple ou structurée, et une classe d'appartenance.
L'identité et l'égalité de deux objets sont deux notions différentes. Deux objets o1 et o2 sont identiques si leurs
identifiants sont égaux (o1==o2). Deux objets o1 et o2 sont égaux si leurs états sont égaux (o1=o2). Donc nous avons
(o1==o2)(o1=o2).
L’univers devient donc une structure composée d’ensemble d’objets déterminant chacun les clés de son comportement.
Les types d'objets seront des classes, et les objets (instances) seront considérés comme représentants de classes.
Exemple:
Objet (instance)
. Classe VOITURE .
-immatriculation
Démarrer () - marque
Rouler () - puissance
Stopper () - couleur
-…
Démarrer Rouler Stopper
Figure 18. Exemple de représentation d'un objet d'une classe
Les principes énoncés plus haut offrent des qualités pour mettre en œuvre des méthodes rigoureuses. Ainsi, on doit
retrouver dans une approche objet au moins 4 principes obligatoires : abstraction, encapsulation, modularité, hiérarchie ;
auxquels on peut ajouter 3 principes complémentaires : typage, simultanéité, persistance.


Abstraction ( ≡ définition d’une classe)
Elle fait ressortir les caractéristiques essentielles d’un objet (qui le distinguent de tous les autres) et donc procure
des frontières conceptuelles vigoureusement définies du point de vue de l’observateur (utilisateur).
On distingue 3 types d’abstractions :
- Abstraction d’action : objets procurant un ensemble généralisé d’opérations réalisant toutes le même nombre de
fonctions et le même genre.
- Abstraction de machine virtuelle : autonomie.
- Abstraction de coïncidence : objets n’ayant aucune relation entre eux.
C'est l’objet qui décide la manière d’effectuer les opérations. Il n’est pas besoin de connaître l’implémentation interne
d’un objet…
Encapsulation
C’est le procédé de séparation des éléments d’une abstraction qui constituent sa structure et son fonctionnement.
Elle permet de dissocier l’interface conceptuelle de la mise en œuvre d’un objet (on cache l’implémentation des
méthodes).
L’encapsulation suppose également lisibilité et compréhensibilité. Les possibilités de surcharge et la modularité
renforcent la lisibilité des codes. Mais, les détails d’implantation sont généralement cachés.
Modularité
La modularité est la propriété d’un système décomposé en ensemble de modules cohérents faiblement couplés.
La modularité suppose également la modifiabilité : les objets sont faciles à changer.
Hiérarchie (héritage)
Elle conctitue un « classement » ou ordonnancement des abstractions. En assurant la relation de généralisation,
elle facilite aussi la modélisation des objets et la modularité du code. Elle permet la réutilisation des attributs et
opérations des classes d'objets, et élimine les redondances.
Le typage
Le fait d’imposer la classe d’un objet de façon que les objets de types différents ne puissent pas être intervertis,
ou tout au plus ne puissent être intervertis que de façon restrictive.
Simultanéité
Deux objets différents doivent pouvoir agir en même temps et à des endroits différents (soit sur la même
machine, soit sur des machines différentes,…).
Persistance
Ceci concerne la durée de vie d’un objet (important dans les BD, ou les données sont disponibles longtemps).
3.3 Aperçu du cycle général de développement

Le cycle de vie d’un logiciel est généralement proche de l’incrémental (par opposition au cycle itératif classique). Les
étapes de spécification sont :
- étude du vocabulaire du projet : noms, verbes, objets … ;
- identification des objets physiques ;
- Formalisation d’un modèle (liens, communication, …).
Identification classes
et objets
Mise en œuvre des classes Identification des

sémantiques des
et objets
classes et objets
Identification des
relations entre classes
Figure 19. Cycle de vie spécifique
Rappel de quelques définitions

Analyse : Partant de la spécification du problème, l'analyste construit un modèle du monde réel mettant en évidence les
propriétés importantes. Le modèle d'analyse est une abstraction précise et concise du but de l'application et non de la
façon dont elle sera bâtie.
Conception du système : Le concepteur du système prend des décisions de haut niveau sur l'architecture d'ensemble du
système. Pendant cette phase, le système cible est découpé en sous-systèmes fondés à la fois sur la structure de l'analyse
et sur l'architecture proposée. Le concepteur du système doit décider quelles sont les caractéristiques de performances
du système à optimiser.
Conception des objets : Le modèle de conception objet s'appuie sur le modèle d'analyse mais contient des détails
d'implémentation.


Implémentation : Les classes d'objets et leurs relations développées durant la phase de conception des objets sont
finalement traduites dans un langage de programmation.
3.4 Les « modèles »
Les modèles décrivent des façons de procéder courantes. Les modèles de conception décrivent des techniques de
conception. Ils sont recueillis par des personnes qui repèrent les thèmes récurrents de la conception. Ces personnes
examinent chaque thème et le décrivent pour que d’autres puissent étudier le modèle et voir comment l’appliquer.
Les langages de modélisation (à l’instar d’UML) permettent de représenter une conception orientée objet. Les
modèles (« patterns ») s’intéressent quant à eux aux résultats du processus et débouchent sur des applications.
Dans plusieurs cas, les projets rencontrent des problèmes parce que leurs responsables ne maîtrisent pas des méthodes
bien connues des concepteurs expérimentés.
3.5 LE LANGAGE UML

3.5.1 La genèse d'UML
La première moitié des années 90* a vu fleurir une cinquantaine de méthodes objets. L'examen des méthodes
dominantes a permis de dégager un consensus autour d'idées communes. Les grands traits des objets, repris par de
nombreuses méthodes, s'articulent autour des notions de classe, d'association (Jim Rumbaugh), de partition en sous-
systèmes (Grady Booch) et autour de l'expression des besoins à partir de l'étude de l'interaction entre l'utilisateur et le
système (les use cases d'Ivar Jacobson). En 1994, on recensait plus de 50 méthodologies orientées objets. C’est dans le
but de remédier à cette dispersion que les « poids-lourds » de la méthodologie orientée objets ont entrepris de se
regrouper autour d’un standard. Partant de la constatation que les différences entre les méthodes s'amenuisent et que la
« guerre » des méthodes ne fait plus progresser la technologie objet, en octobre 1994, Grady Booch et Jim Rumbaugh
se sont réunis au sein de la société RATIONAL dans le but de travailler à l’élaboration d’une méthode commune qui
intègre les avantages de l’ensemble des méthodes reconnues, en corrigeant les défauts et en comblant les déficits. Ils
décident d'unifier leurs travaux au sein d'une méthode unique : la méthode unifiée (The Unified Method). Une année
plus tard, ils sont rejoints par Ivar Jacobson.
Ces trois chercheurs se sont fixés quatre objectifs :
- Représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets
- Etablir un couplage explicite entre les concepts et les artefacts (phénomène/structure virtuelle dont
l’apparition est liée à une expérience/un cas)
- Prendre en compte les facteurs d'échelle inhérents aux systèmes complexes et critiques.
- Créer un langage de modélisation exploitable à la fois par les humains et les machines.
Depuis 1996, ces objectifs sont quasiment atteints. La méthode unifiée est devenue plutôt le langage UML. UML
est un élément de base dans la stratégie de plusieurs entreprises. Un ensemble de partenaires réunis au sein de l'OMG
(regroupant notamment IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.), travaillent pour la description et
l’amélioration d'UML.
UML est un standard « industriel » de l'OMG (novembre 1997) au même titre que CORBA (Common Object request
Broker Architecture) par exemple. Ceci dit, le succès initial de ce langage a fait de lui un « standard de fait ».
3.5.2 Généalogie UML à l’origine

[wwwGeneal01]
Généalogie d’UML
UML
(Rumbaugh, Booch,
Jacobson)
Use-Case Fusion
(I. (HP-
ClASSE-
OOA OOA-OODLE OMT OOA- RELATION
(P. (Schlaer & (J. Rumbaugh et OOD (P. Desfray)
al.) (G.Booch) CRC
(R. Wirf-Brooks)
JSD
(M. Jackson)
Data-Flow Diagrammes Entite-Relation
SADT/SA-SD Etat-Transition Merise
( De Marco) (HAREL) (chen)
Figure 20. Généalogie d'UML


Evolution des versions d’UML
Version Date Activité
Avant 1993 Autres méthodes + Booch’91 + OMT-1 + OOSE + Partenaire
1ères reflexions 0.0 1993-1994 Booch’93 + OMT-2+…
Méthode Unifiée 0.8 Octobre 1995 OOPSLA’95 (Object Oriented Programming Systems, Languages and Applications, /
Une Conférence de la programmation orientée objets)
MUL 0.9 Juin 1996 Version bêta OOPSLA’96
UML 1.0 Septembre 1997 Soumis à l’OMG en janvier 1997 + OCL (IBM)
UML 1.1 Novembre 1997 Révision
UML 1.X 1998-2002 1.2 (juin 1998), 1.3 (mars 2000), 1.4 (sept 2001), 1.5 (mars 2003)
UML 2.0 Janvier 2005 New diagrams: object diagrams, package diagrams, composite structure diagrams, interaction
overview diagrams, timing diagrams, profile diagrams. Collaboration diagrams were
renamed to communication diagrams.
Activity diagrams and sequence diagrams were enhanced (Activities were redesigned to use a
Petri-like semantics).
Classes have been extended with internal structures and ports (composite structures). New
notation for concurrency and branching using combined fragments.
New metaclasses were added: connector, collaboration use, connector end, device, deployment
specification, execution environment, accept event action, send object action, structural feature
action, value pin, activity final, central buffer node, data stores, flow final, interruptible
regions, loop nodes, parameter, port, behavior, behaviored classifier, duration, interval, time
constraint, combined fragment, creation event, destruction event, execution event, interaction
fragment, interaction use, receive signal event, send signal event, extension, etc.
Many stereotypes were eliminated from the Standard UML Profile, e.g. «destroy», «facade»,
«friend», «profile», «requirement», «table», «thread».
Integration between structural and behavioral models was improved with better support for
executable models.
UML 2.1 2006 Définition par une commission de révision
UML 2.1.2 Novembre 2007 2.1.1 (août 2007)
UML 2.2 Février 2009 14 types de diagrammes
UML 2.3 Mai 2010 clarified associations and association classes, added final classifier, updated component
diagrams, composite structures, actions, etc.
UML 2.4.1 Août 2011 few fixes and updates to classes, packages - added URI package attribute; updated
2.4 (mars 2011) actions; removed creation event, execution event, send and receive operation events,
send and receive signal events, renamed destruction event to destruction occurrence
specification; profiles - changed stereotypes and applied stereotypes to have upper-case
first letter - «Metaclass» and stereotype application.
UML 2.5 beta2 Decembre 2013 Few clarifications and fixes for stereotypes, state machines, activities. Protocol state
machines are now denoted using «protocol» instead of {protocol}. Use cases are no
longer required to express some needs of actors and to be initiated by an actor.
Tableau 1. Historique et évolution des versions d’UML
3.5.3 Le formalisme d'UML

3.5.3.1 Notions usuelles
Ce mini glossaire définit les termes employés dans la description du Langage Unifié de Modélisation (UML). On
retrouvera plus loin, en plus de la terminologie spécifique à UML, des termes se rapportant au standard OMG, à
l'analyse objet et aux méthodes de conception.
Automate : Un comportement qui spécifie les séquences d’états traversées par un objet ou une interaction en réponse à
des événements accompagnés des réponses et des actions.
Classe : Ensemble d’objets partageant les memes attributs, methodes, relations et contraintes.
Diagramme : Une représentation graphique d’une collection d’éléments de modélisation, le plus souvent visualisée
comme un graphe d’arcs (relations) et de sommets (autres éléments de modélisation).
Objet persistant : Un objet qui continue d’exister après la mort du processus qui l’a créé.
Paquetage : Un mécanisme universel pour grouper des éléments. Les paquetages peuvent être emboîtés les uns dans les
autres. Un système peut être vu comme un seul paquetage abstrait qui contient tout le reste.
3.5.3.2 Spécifications
UML 2.x présente quatre sous ensembles de spécification de modélisations :
• « Superstructure » : définit les notations et sémantiques de diagrammes et leurs éléments de modeles.
• « Infrastructure » : définit le Coeur du métamodèle sur lequel s’appuie la superstructure.
• « Object Constraint Language » (OCL) : definit des règles qui régissent les éléments de modèles.
• « UML Diagram Interchange » : définit comment les diagrammes UML peuvent être mis en forme et
échangés.
Vous trouverez tous les détails sur les spécifications du métamodèle UML dans [OMGWWW].


Figure 21. Métamodèle UML
Le formalisme UML (depuis la version 2.2) est composé de 14 types de diagrammes (9 en UML 1.3). UML n'étant pas
une méthode, leur utilisation est laissée à l'appréciation de chacun, même si le diagramme de classes est généralement
considéré comme l'élément central d'UML. De même, on peut se contenter de modéliser seulement partiellement un
système, par exemple certaines parties critiques. Les différents éléments d'un diagramme UML sont liés de manière
logique grâce aux composants (représentations) suivants [wwwUMLdesign09] :
[wwwUMLdesign09]
UML peut fournir une perception à pluseurs niveaux hiérarchiques d’abstraction, ou sous plusieurs angles
(sous-ensembles) :
• Les vues : Les vues sont les « observables » du système. Elles décrivent le système d'un point de vue donné,
qui peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En combinant
toutes ces vues, il est possible de définir (ou retrouver) le système complet.
• Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le contenu des vues, qui
sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.
• Les modèles d'éléments : Les modèles d'éléments sont les briques des diagrammes UML. Ils sont utilisés dans
plusieurs types de diagrammes. Exemple d'éléments : cas d'utilisation (CU ou "cadut"), classe, association, etc.
3.5.3.3 Les vues
Les vues peuvent se superposer pour collaborer à la définition du système.
• Vue des cas d'utilisation : C'est la description du système "vue" par ses acteurs. Elle correspond aux besoins
attendus par chaque acteur (c'est le QUOI et le QUI).
• Vue logique : C'est la définition du système vue de l'intérieur. Elle explique comment peuvent être satisfaits les
besoins des acteurs (c'est le COMMENT).
• Vue d'implémentation : Cette vue définit les dépendances entre les modules.
• Vue des processus : C'est la vue temporelle et technique, qui met en œuvre les notions de tâches concurrentes,
stimuli, contrôle, synchronisation, etc.
• Vue de déploiement : Cette vue décrit la position géographique et l'architecture physique de chaque élément du
système (c'est le OÙ).

NB : Le POURQUOI, n'est pas encore défini dans UML à cette date.


3.5.3.4 Les diagrammes
UML est un langage de modélisation et non une méthode. La plupart des méthodes proposent (en principe) un langage
de modélisation et un processus. Le langage de modélisation est une notation (ésentiellement graphique) que les
méthodes utilisent pour représenter la conception. Le processus est une façon d’envisager la marche à suivre lors de la
conception. Il existe des processus qui complètent le langage UML :
- RUP (Rational Unified Process) développé par les trois concepteurs d’UML ;
- 2TUP (Two track Unified process).
UML est très intuitif, plus simple, plus homogène et plus cohérent que les autres approches.
En plus des paquetages et des notes, trois familles de diagrammes composent le langage UML. Les 14 diagrammes
UML sont dépendants hiérarchiquement et se complètent. Ils permettent de visualiser et de manipuler les éléments de la
modélisation. On peut les regrouper en trois sous-ensembles :
→ Diagrammes Structurels ou Diagrammes statiques (Structure Diagrams)
• Diagramme de classes (Class diagram) : représentation de la structure statique en termes de classes et
de relations.
• Diagramme d'objets (Object diagram) : représentation des objets et de leurs relations (correspond à un
diagramme de collaboration simplifié, sans représentation des envois de messages). Un diagramme
d’objet est une représentation instantannée des objets présents dans un système à un moment donné.
Comme il représente des instances et non des classes, on le nomme souvent diagramme d’instance.
• Diagramme de composants (Component diagram) : décrivent les éléments (ou modules) physiques
tels que mis en œuvre (fichiers, bibliothèques, bases de données...) et leurs relations.
• Diagramme de déploiement : représentation du déploiement des composants sur les dispositifs
matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les
composants du système sont répartis sur ces éléments matériels et interagissent avec eux.
• Diagramme des paquetages (Package diagram) : représentation des dépendances entre paquetages,
c’est-à-dire les dépendances entre ensembles de définitions. NB : un paquetage est un « conteneur
logique » permettant de regrouper et d'organiser les éléments dans le modèle UML.
• Diagramme de structures composites (Composite Structure Diagram) : il décrit sous forme de « boîte
blanche » les relations entre composants d'une classe.
• Diagramme de profils (Profil Diagram) : intégré à partir de UML 2.2, le diagramme de profils permet
de spécialiser, de personnaliser pour un domaine particulier un meta-modèle de référence d'UML.
→ Diagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagrams)
• Diagramme des cas d'utilisation (use-cases) (Use case diagram) : représentation des fonctions du
système du point de vue de l’utilisateur. Il décrit les possibilités d'interaction entre le système et les
acteurs, c'est-à-dire toutes les fonctionnalités que doit fournir le système.
• Diagramme d’États-Transitions (StateChart / State Machine Diagram) : représentation du
comportement d’une classe en terme d’états ; il montre la manière dont l'état du système (ou de sous-
parties) est modifié en fonction des événements du système.
• Diagramme d'activité (Activity Diagram) : représentation du comportement d’une opération en terme
d’actions ; variante du diagramme d'états-transitions, il permet de représenter le déclenchement
d'événements en fonction des états du système et de modéliser des comportements parallélisables
(multi-threads ou multi-processus).
Diagrammes d'interactions (Interaction Diagrams)
• Diagramme de séquence (Sequence Diagram) : représentation temporelle des objets et de leurs
interactions ; représentation séquentielle du déroulement des traitements et des interactions entre les
éléments du système et/ou des acteurs.
• Diagramme de communication (Communication Diagram) : représentation spatiale des objets, des
liens et des interactions ; représentation simplifiée d'un diagramme de séquence se concentrant sur les
échanges de messages entre les objets.
• Diagramme global d'interaction (Interaction Overview Diagram) : variante du diagramme d'activité où
les nœuds sont des interactions.
• Diagramme de temps (Timing Diagram) : interactions avec mise en valeur de l'aspect temporel.
Aux différents états d'élaboration du projet correspond l'utilisation de certains diagrammes. Par contre, les diagrammes
des cas d'utilisation pourront être mis à contribution à différents stades du projet (comme élément de validation).
3.5.4 La modélisation par UML
3.5.4.1 La modélisation des cas d'utilisation

• Les cas d'utilisations partitionnent les besoins fonctionnels d'un système (selon le point de vue d'une catégorie
d'utilisation à la fois). Ils montrent les utilisations du système et les acteurs interagissant avec lui.

•

La modélisation par les cas d'utilisation comble le fossé entre les analystes, les utilisateurs et les développeurs.
Nom de l'association
de communication
Nom de l'acteur Nom du cas d'utilisation
Figure 22. Acteur, cas d'utilisation et association
La façon de décrire le contenu d’un cas d’utilisation varie énormément et UML ne souhaite pas imposer une norme.
Vous pouvez par exemple ajouter une ligne de précondition (ce qui doit être VRAI au début du cas d’utilisation).
Un format simple pour capturer un cas d’utilisation consiste à décrire le scénario de base sous forme d’étapes
numérotées et les variantes de cette séquence, comme ci-dessous (une application de commerce électronique).
ACHAT :
1. Le client parcourt le catalogue et sélectionne les produits qu’il souhaite acheter
2. Le client valide ses choix
3. Le client fournit les informations concernant la livraison (adresse, livraison en 24 heures ou 3 jours)
4. Le système affiche les éléments de facturation et les informations concernant la livraison
5. Le client fournit les informations concernant sa carte de crédit
6. Le système valide la transaction
7. Le système confirme la transaction immédiatement
8. Le système expédie un Email de confirmation au client
Alternative : Echec de l’autorisation
A l’étape 6, la transaction n’est pas validée par le système
Autoriser le client à saisir à nouveau les informations concernant sa carte de crédit et réessayer
Alternative : Client régulier
3a. Le système affiche les informations associées à ce client concernant la livraison, les critères de tarification, et les
quatre derniers chiffres de son numéro de carte de crédit
3b. Le client peut accepter ou modifier les valeurs affichées
Retourner au scénario principal de l’étape 6
La quantité de détails dont vous avez besoin dépend du risque que présente le cas d’utilisation. Plus le risque est
important, plus vous devez détailler.
Un acteur est un rôle que l’utilisateur joue par rapport au système. Les acteurs réalisent les cas d’utilisation. Un seul
acteur peut réaliser plusieurs cas et, inversement, un cas peut avoir plusieurs acteurs.
Formalisme du diagramme de cas d’utilisation :

Pendant l’élaboration, nous décomposons souvent tous les cas qui deviennent trop complexes. Nous le faisons en phase
de construction si nous nous rendons compte que nous ne pouvons pas construire la totalité du cas en une seule
itération. Dans cette situation, nous nous occupons d’abord du cas normal, et ensuite des variantes.
Appliquer les règles suivantes :
• Utiliser « include » quand vous voulez éviter la répétition entre plusieurs cas d’utilisation.
• Utiliser la généralisation quand vous décrivez une variante au comportement standard. En fait, extend est
nécéssaire pour décrire non seulement une variante au comportement standard, mais aussi lorsque vous voulez
explicitement indiquer son activation, en déclarant des points d’extension dans le cas d’utilisation de base.
Cas d’utilisation « Métier » et « Système » :

Vous entendrez souvent parler de « cas d’utilisation système » et « cas d’utilisation métier ». Ces termes peuvent
paraître imprécis, mais, dans l’usage courant, un cas d’utilisation système est une interaction avec le logiciel, alors
qu’un cas d’utilisation métier aborde la façon dont un "métier" répond à un client ou à un événement (en situation
réelle).
Nous ne nous attarderons pas sur cette question. Aux premiers stades de l’élaboration, nous nous penchons plus sur les
cas métier, mais les cas système sont plus utiles quand il s’agit de planifier. Les cas métier sont utiles, en particulier
pour envisager d’autres façons de répondre aux objectifs d’un acteur.


Simuler
Convertir Fonction
Vitesse
Include
Use
Stabilité Include
Use Afficher
Résoudre équations Include solutions
Précision
Include
Use
Include
Erreur
Figure 23 Diagramme
ActVenSys de cas d’utilisation de la simulation des systèmes continus
TranDirSys Include
Tracer courbes
Enoi /
Reception
Système externe
(séquentiel)
[Nkenlif04]
Figure 24. Exemple de Diagramme de cas d’utilisation (modélisant la simulation d’un système continu)
Achat
Client Régulier
« Extend » Point d’extension
(infos tarifaires, infos livraisons) Infos Tarifaire
Infos Livraison
Figure 25. Relation d’extension
3.5.4.2 La modélisation des classes et des objets

• La modélisation objet est utilisée dans le langage UML pour définir des objets-métiers et l'architecture de
l'application. Les objets sont créés comme instances de classes. Ils interagissent dynamiquement pour offrir le
comportement décrit par les cas d'utilisation. La modélisation objet définit le comportement requis par les
différentes classes pour assurer la bonne mise en place des cas d'utilisation et des règles de gestion.
• Les objets-métiers constituent la base de l'architecture des applications. Ces objets peuvent être réutilisés à travers
des domaines d'application ou encore être identifiés et dérivés directement des cas d'utilisation ou du domaine de
l'application.
• La modélisation des classes capture le détail de la structure des objets-metiers. Les classes constituent la base pour
la génération des codes et pour la génération des schémas par exemple de bases de données.
• Les définitions des classes et de leurs relations sont regroupées dans des paquetages afin de définir l'architecture
des applications. Ces paquetages peuvent être emboîtés les uns dans les autres. Les relations entre paquetages
définissent les dépendances dans l'application et déterminent la stabilité de l'architecture.
Un diagramme de classes décrit la structure interne (les types d’objets qui composent) du système, les différents types
de relations statiques qui existent entre eux. Les diagrammes de classes représentent également les attributs et les

opérations d’une classe et les contraintes qui s’appliquent à la façon dont les objets sont connectés. Il existe

principalement deux sortes de relations statiques :
- Les associations : un client peut par exemple louer un certain nombre de cassettes vidéo ;
- Les sous-types : une infirmière est une sorte de personne.
Les diagrammes de classes représentent également les attributs et les opérations d’une classe et les contraintes qui
s’appliquent à la façon dont les objets sont connectés.
Commande
Multiplicité : obligatoire
Client
Date de réception * 1
Est prépayé
nombre : Chaine Nom
prix : Monnaie Adresse
Solvabilité ( ) : Chaine
Expédier ( ) Association
Fermer ( )
1 Généralisation
Classe
(Si la commande.client.solvabilité est "douteuse"
alors commande. estPrépayée doit être vrai)
Client professionnel Client Particulier

Contrainte
nomDuContact Numéro carte de visite
Attributs solvabilité
créditAutorisé
Nom de Rôle Opérations (Solvabilités ()
Rappeler ( ) **douteuse)
Facture mensuelle (entier)
Multiplicité : multi-valuée
ligne * ****
*
Ligne de commande Commercial 0..1
Multiplicités
Qualités : Entier Employé
Optionnelle
Prix : Monnaie
Disponible : Booléen
* 1
Produit
[Fowler03]
Figure 26. Notations de diagramme de classes
Quand utiliser les diagrammes de classes ? [Fowler03]

Les diagrammes de classes sont l’épine dorsale de presque toutes les méthodes orientées objet, et vous les utiliserez en
permanence.
Le problème des diagrammes de classes est qu’ils sont si riches que leur utilisation peut être épuisante.
Voici quelques conseils :
• Adaptez le point de vue à partir duquel vous élaborez les modèles au stade où en est le projet.
- En phase d’analyse, créez des modèles conceptuels ;
- Dans les phases suivantes, concentrez-vous sur les modèles de spécification ;
- Ne créez des modèles d’implémentation que pour illustrer une technique particulière.

Exemple de diagramme de classes

(package)
SYSTEM
SEQUENTIEL
0 .. *
Est décrit par
1
(package)
RECVENSYS
GRAFCET
RECEPTIVITE LOGIQUE
RECEPTIVITE TEMPORELLE
Appartient à
RECEPTIVITE
GRAFCET
Conditionne
1 Débouche sur ETAPE

TRANSITION
1 .. * 0 .. *
MACRO-ACTION
Décrit
LIEN COUPLAGE SEQ
LSAUT ETAPE LIEN ACTION SIMPLE

ACTION
LIEN EXCLUSIF
ACTDIRSYS
LIEN SELECTIF
ACTION DETAILLEE
LIEN PARALLELE
LIEN SIMPLE ACTION MULTIPLE
[Nkenlif04]
Figure 27. Un exemple de Diagramme de classes : cas des systèmes séquentiels automatiques et interactions

Les points de vue de base

Vous pouvez partir de trois points de vue différents quand vous créez un diagramme de classes ou n’importe quel
modèle, mais la différence sera plus perceptible avec les diagrammes de classes.
• Le point de vue conceptuel. Si vous adoptez le point de vue conceptuel, vous tracez un diagramme qui représente
les concepts du domaine que vous étudiez. De fait, un modèle conceptuel ne devrait pas (ou devrait peu), prendre
en compte le logiciel qui pourrait le mettre en œuvre et donc être considéré comme indépendant du langage (point
de vue essentiel).
• Le point de vue des spécifications. Nous nous attachons maintenant au logiciel, mais nous nous occupons de ses
interfaces, mais pas de son implémentation.
• Le point de vue de l’implémentation. Nous avons réellement des classes et mettons à nu l’implémentation.
UML est bien compatible avec les trois points de vue précédents. En étiquetant les classes avec un stéréotype, vous
pouvez fournir une indication sur le point de vue : Vous annotez les classes "classes implémentation" si vous partez du
point de vue de l’implémentation et "type" si vous partez du point de ue conceptuel ou de celui des spécifications.
Associations
Les associations représentent les liens unissant les instances des classes (Ex. une personne travaille dans une entreprise ;
une entreprise a un certain nombre de succursales, etc.).
Chaque association a également deux extrémités ou rôles, chacune d’elle étant reliée à l’une des classes de
l’association. Un rôle peut être nommé explicitement au moyen d’une étiquette, que l’on appelle « nom de rôle ».
Chaque association a également une multiplicité (« cardinalité ») qui indique le nombre d’objets susceptibles de
participer à une association donnée.
Attributs
Les attributs sont assez « semblables » aux associations du point de vue conceptuel.
Selon que le diagramme est détaillé ou nom, la notation d’un attribut peut présenter son NOM, son TYPE et sa
VALEUR par défaut.
La syntaxe UML est : visibilité nom : type = valeurParDefaut
Opérations
Les opérations sont les processus qu’une classe sait mener à bien et elles correspondent aux méthodes d’une classe.
Généralisation
Un exemple de généralisation est celui des clients particuliers et professionnels d’une entreprise. Ils présentent des
différences, mais également de nombreuses similitudes. On peut placer ces dernières dans une classe générique
« Client » (le supertype), dont « ClientParticulier » et « Professionnel » sont des sous-types. La généralisation est
associée à l’héritage.
Stéréotypes
Ils constituent le principal mécanisme d’extension d’UML. Si vous avez besoin d’une construction de modélisation qui
ne fait pas partie d’UML mais qui présente des similarités avec une construction qui en fait partie, vous pouvez la traiter
comme un stéréotype UML.
Les stéréotypes permettent d'apposer une sémantique particulière aux éléments UML. On peut alors spécialiser le
langage UML afin qu'il s'adapte mieux au domaine dans lequel le langage est utilisé.
Exemple : Le concept d’"interface UML", représente une classe n’ayant que des opérations publiques, sans définition
de corps pour les méthodes, ni les attributs. En fait, elle correspond aux interfaces Java, CORBA (OMG) et COM
(Microsoft). Comme c’est un type de classe spécial, elle est définie comme stéréotype de classe.
Généralement, les stéréotypes sont représentés par un texte entre guillemets (ex : « interface »), mais vous
pouvez également définir une icône. On peut citer par exemple l'utilisation de stéréotype "<<Table>>" sur des classes
dans les diagrammes de classes dans le cadre d'une modélisation de base de données.
Opérations et attributs : visibilité de classe

Une opération ou un attribut qui s’applique à une classe et non à une instance a une visibilité de classe. Elle correspond
aux membres static en Java ou en C++, et aux méthodes et variables de classes en Smaltalk. Dans un diagramme de
classe UML, les membres de classe sont soulignés.


Commande
Visibilité d’instance Obtenir Numéro

ObtenirProchainNuméroLibre
Visibilité de classe
Figure 28. Notation de la visibilité de classe et d’instance
Classification multiple et dynamique

La classification désigne la relation unissant un objet à un type.
Dans la classification unique, un objet n’appartient qu’à un seul type, qui peut hériter de supertypes.
Dans la classification multiple, un objet peut être décrit par plusieurs types, qui ne sont pas nécéssairement associés par
une relation d’héritage.
Remarque : la classification multiple diffère de l’héritage multiple. Dans l’héritage multiple, un type peut avoir
plusieurs supertypes, mais un objet ne peut appartenir qu’à un seul type. La classification multiple permet à un objet
d’appartenir à plusieurs types, sans qu’il soit pour autant nécéssaire de définir un type spécifique.
Exemple : cas d’une "Personne" sous-typée comme "Homme" / "Femme", "Médecin" / "Infirmier", "Patient" /
"EnSanté". On étiquette alors une relation de généralisation au moyen d’un discriminateur qui indique sur quelle base
s’effectue le sous-tpage.
[Fowler03]
Discriminateur
Chirurgien
rôle Médecin
Femme
Médecin de
famille
Personne Infirmier
patient
Homme sexe
Kinési-
thérapeute
Patient
Figure 29. Classification multiple
Agrégation et composition
L’agrégation est la relation « est une partie de », comme le moteur et les roues sont des parties d’une voiture.
Cependant, UML offre une variété d’agrégation plus forte, nommée composition. Dans la composition, l’objet
« partie » ne peut appartenir qu’à un seul « tout ». De plus, on suppose généralement que les parties sont créées et
meurent avec le tout (la destruction du tout se propage en cascade à ses parties).


(Ordered) Composition
Point
3..* 1..*
Polygone Cercle
rayon
Style
couleur Agrégation
estPlein
1 1
Figure 30. Composition, agrégation, navigabilité, contraintes
Associations et attributs dérivés

Les associatiosn dérivées et les attributs dérivés dépendent d’autres associations ou d’autres attributs. On peut, par
exemple, dériver l’attribut « âge » d’une Personne si l’on connaît sa date de naissance. Il est important de se rendre
compte que la dérivation indique alors une contrainte entre valeurs, et non une assertion de ce qui est calculé et de ce
qui est mémorisé.
Figure 31. Représentation d’Associations et attributs dérivés
Notez bien les points suivants (figure ci-dessus) :

- L’age d’un Employé est calculé : c’est la différence entre la date en cours et la date de naissance.
- Certaines opérations sur la Société sont une compilaion des opérations des Services.
Notation d’interfaces et classes abstraites

Les langages de programmation utilisent rarement l’interface comme construction indépendante, ce qui est regrettable.
Les développements orientés objet présentent entre autres l’intérêt de pouvoir faire varier les interfaces des classes
indépendamment de leur implémentation. Cette propriété est l’une des plus importantes du modèle objet.
Une interface pure, comme en Java, est une classe sans implémentation et ne contient donc que des déclarations
d’opérations, mais pas de définition de méthodes ni de champs. On représente souvent les interfaces au moyen de
classes abstraites. De telles classes peuvent fournir des implémentations partielles.
L’idée sous-jacente est que le sous-classement (héritage) fournira l’implémentation, mais que les clients ne verront que
l’inteface et jamais l’implémentation.


Fenêtre Windows
Fenêtre
activer ( )
(abstract) désactiver ( )
Editeur de
texte
activer 0
désactiver 0
Fenêtre X11
dépendance activer ( )
désactiver ( )
Fenêtre Mac
activer ( )
désactiver ( )
Figure 32. Exemple de classe abstraite : FENETRE
Objets "valeur" et objets "référence"

Les objets référence sont des objets tels que Client. Ici, l’identité est très importante, parce qu’on souhaite
généralement qu’un seul objet logiciel désigne un client du monde réel. Tout objet qui mémorise l’identité d’un objet
Client le fera Via une référence ou un pointeur, et tout les objets qui se référent à ce Client référenceront le même objet
logiciel. De cette façon, les changements apportés à un Client seront disponibles pour tous les utilisateurs de ce Client.
Les objets valeur sont des objets tels que Date. Il existe souvent plusieurs objets valeur qui représentent le même objet
du monde réel. Il est par exemple normal d’avoir des centaines d’objets qui désignent le « 1er décembre 2007 ». Ce sont
tous des copies interchangeables. On crée et on détruit fréquemment de nouvelles Dates. Si vous avez deux objets Date
et si vous voulez savoir s’ils mémorisent la même, vous devez écrire un test d’égalité (examination de la valeur, et non
de l’identité) qui dans ce cas, teste l’année, le mois et le jour. Habituellement, c’est vrai qu’on crée un objet Date
chaque fois qu’une Date est nécéssaire, mais on peut aussi idéalement ne créer qu’un seul objet Date pour une date
donnée et le partager.
Les objets valeur doivent être immuables (ou gelés – frozen).
Immuabilité : « frozen »
UML définit la contrainte frozen (gelé) comme applicable à un attribut ou à une extrémité d’association, mais elle est
également utile pour les classes.
Sur un attribut ou une association, frozen indique que la valeur de cet attirbut ou de cette association est immuable
pendant toute la durée de vie de l’objet. Elle doit être définie à la création de l’objet et ne peut jamais être modifiée (tout
au long de la vie de l’objet). La valeur initiale peut être « null ». Cela implique que le constructeur contient
généralement un argument fixant cette valeur et qu’aucune opération ne la mette à jour.
On peut appliquer frozen à une classe pour indiquer que toutes les terminaisons d’association et tous les attributs
associés à cette classe sont gelés.
NB : gelé ne signifie pas « lecture seule ». Les valeurs en lecture seule seront généralement indiquées avec la contrainte
{read-only}, qui n’est pas une contrainte UML standard au sens strict.
Collections pour les rôles d’assocition multivalués

Un rôle multivalué (considéré comme un ensemble) est un rôle dont la multiplicité a une valeur maximale supérieure à
1 (* par exemple). Il est possible d’attacher une contrainte au rôle :
• La contrainte {ordered} : les objet cibles ont un ordre, autrement dit, ils forment une liste et n’apparaîtront
qu’une fois dans la liste.
• La contrainte {bag} : les objets cibles peuvent apparaître plusieurs fois dans la collection, mais ils ne sont pas
ordonnés.
• La contrainte {hierarchy} : indique qu’ils sont hiérarchisés.
• La contrainte {dag} : indique un graphe orienté acyclique.


Associaions qualifiées
Une association qualifiée est une spécification en UML qui est équivalente au concept de programmation connu sous le
nom de « tableau associatif », de « map » ou encore de dictionnaire.
L’exemple : ci-dessous indique qu’une Société ne peut pas avoir deux Employés différents pour le même Matricule.
Société
Matricule
1
Employé
Figure 33. Associaions qualifiées
Du point de vue des spécifications, cette association qualifiée impliquerait une interface telle que la suivante :
class Societe
{
public Employe getEmploye (Matricule unMatricule) ;
public void ajouterEmploye (String nome, Matricule unMatricule) ;
…
}
Ainsi, tout accès à un enregistrement donné nécessite un Matricule comme argument. Une multiplicité de 1 indiquerait
qu’il doit y avoir un Employé pour chaque Matricule.
Dans l’exemple donné plus bas, une multiplicité de * indiquerait plutôt que l’on peut avoir plusieurs Emplois dans
l’Entreprise par Personnel.
Du point de vue implémentation, cela suggère l’emploi du tableau associatif ou d’une structure de données similaire
class Entreprise
{
private Map _Emplois ;
…
}
Classes association
Lorsqu’on veut ajouter des attributs, des opérations et d’autres fonctionnalités aux associations, on fait appel à la notion
de classe-association d’UML.
* Employeur
Personnel Entreprise
0..1
Emploi
Période : IntervalleDate
Opération ( )
Figure 34. Exemple de Classe-Association
Une autre façon de représenter cette information consiste à faire de « Emploi » une classe à part entière. Dans ce cas, les
multiplicités doivent être modifiées en conséquence.
A chacune des classes de l’association d’origine a un rôle monovalué par rapport à la classe Emploi. Le rôle
« employeur » est maintenant dérivé, bien qu’il ne soit pas indispensable de le représenter.


Employeur
Emploi
* 0..1
1 0..1 Période : IntervalleDate * 1
Personne Entreprise
Opération ( )
[Fowler03]
Figure 35. Transformation d’une classe-association en classe à part entière
Classes paramétrables
Ce concept permet de définir des comportements pour des ensembles, en général en créant une classe patron Set.
Plusieurs langages de programmation, particulièrement C++, utilisent la notion de classe paramétrable (« template »)
ou de patron (« pattern »).
class Set <T>
{
void inserer (T nouvelElemnt) ;
void supprimer (T unElement) ;
…
}
Cela fait, vous pouvez utiliser la définition de la classe paramétrable Set pour créer des classes dérivées afin de
mémoriser des éléments spécifiques.
Set <Employe> employeSet ;
Voici le formalisme de representation d’une classe paramétrable en UML :
Set T
Paramètre de
Classe
Période : IntervalleDate Paramétrable
Inserer ( )
Supprimer ( )
Figure 36. Classe Paramétrable
Le T du diagramme est un paramètre substituable qui représente le type (vous pouvez avoir plusieurs paramètres).
NB : Ce concept est inutile dans des langages à typage faible comme Smaltalk, puisque la question ne se pose pas.
visibilité
Il est possible d’étiqueter tout attribut ou opération par un indicateur de visibilité. Vous employez n’importe quel
marqueur, sa signification dépendant du langage. Mais UML fournit trois abréviations : + (public), - (private) et #
(protected).
3.5.4.3 La modélisation des comportements
Diagramme d’état-transition
• Les diagrammes d'état-transition permettent de décrire les changements d'états d'un objet ou d'un composant,
en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.
• Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des
attributs d'un objet.
• Une transition représente le passage instantané d'un état vers un autre.
• Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui
conditionne la transition.
• Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui les déclenche.
• En plus de spécifier un événement précis, il est aussi possible de conditionner une transition, à l'aide de
"gardes" : il s'agit d'expressions booléennes, en langage naturel (et encadrées de crochets).


Produit
envisagé
Produit non disponible Produit en Alerte

(suspension de vente)
QtéDispo == 0
QtéVendue == MaxQtéVendable
Acquisition
Approvisionnement QtéVendue ==
MaxQtéVendable
Promotion
Produit disponible Produit en promotion
(en vente)
Arrêt de la
promotion
Produit retiré
du marché
Figure 37. Exemple de Diagramme d’états – transitions (classe PRODUIT dans un site de gestion des ventes)
Annulation
Attente
Vérification Expédition
Livré
fin
Examination Autorisé
Rejeté
Figure 38. Diagramme d’états concurrents (avec super état)


Actions dans un état
• On peut aussi associer une action à l'événement qui déclenche une transition.
La syntaxe est alors la suivante : événement / action
• Ceci exprime que la transition (déclenchée par l'événement cité) entraîne l'exécution de l'action
spécifiée sur l'objet, à l'entrée du nouvel état.
Exemple : il pleut / ouvrir parapluie
• Une action correspond à une opération disponible dans l'objet dont on représente les états.
• Les actions propres à un état peuvent aussi être documentées directement à l'intérieur de l'état.
UML définit un certain nombre de champs qui permettent de décrire les actions dans un état :
• entry / action : action exécutée à l'entrée de l'état
• exit / action : action exécutée à la sortie de l'état
• on événement / action : action exécutée à chaque fois que l'événement cité survient
• do / action : action récurrente ou significative, exécutée dans l'état
Diagramme d’activité
• UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas
d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états-transitions).
• Le passage d'une activité vers une autre est matérialisé par une transition.
• Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont
automatiques).
• En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls
les mécanismes complexes ou intéressants méritent d'être représentés.
Activité 1
Débranchement
Activité 2 Branchement Activité 5
[Garde : si oui] [Sinon]

Activité 3 Activité 4
Jonction
Fusion
Activité 6
Figure 39. Diagramme d’activité (illustration de fusion, jonction, débranchement et branchement)
3.5.4.4 La modélisation des interactions

Les diagrammes d’interaction capturent le comportement d’un seul cas d’utilisation. Ils représentent un certain nombre
d’objets et de messages qui sont transmis entre ces objets dans la réalisation du cas d’utilisation. Ils sont des modèles
qui décrivent la façon dont des groupes d’objets collaborent pour réaliser un comportement donné.


Diagramme de Séquence :
Dans un diagramme de séquence, un objet est représenté sous la forme d’un rectangle au sommet d’une ligne
pointillée verticale. Elle est appelée « ligne de vie » de l’objet. Elle représente la vie de l’objet durant l’interaction.
C’est Jacobson qui a été le premier à populariser cette forme de représentation.
On représente chaque message par une flèche entre les lignes de vie de deux objets. L’ordre dans lequel ces messages
sont représentés est de haut en bas. Chaque message porte une étiquette qui indique au minimum son nom. Vous pouvez
également faire figurer les arguments des messages et certaines informations de contrôle. Vous pouvez représenter un
auto-appel, un message qu’un objet s’envoie à lui même, en repointant sur la ligne de vie de celui-ci. Le diagramme
doit toujours bien faire ressortir les événements qui créent et ceux qui détruisent chaque objet.
syshyb1 : inter1 : sysseq1 : syscont1 :

Utilisateur Systeme Hybride Interactions SSysSequentiel SSysContinu
Clique sur Simuler

Demande paramètres
Saisie paramètres
Acheminer paramètres
DémarrerSimulateurSeq
DémarrerSimulateurCont
Tantque simulation
Modifier_T Modifier_TS Modifier_TC
Ecrire consigne Vc
Lire consigne Vc Déterminer A
Transfert consigne Vc
Calculer V
Calculer X
Ecrire
Transfert de Vr et Xr Lire résultats Xr & Vr Vr & Xr

Si Vr == 2 ms-1
Vc = 2 ms-1 TracerCourbe
Si Xr == Q
Vc = 0 Afficher
Restitution à l’utilisateur Résultats
Si Xr == B
Acheminement Envoyer STOP
du STOP
Arret Simulation
[Nkenlif04]
Figure 40 Séquencement d’opérations entre les macro-objets d’un système hybride (l’ascenseur)
Diagramme de Communication (ancien diagramme de Collaboration)

Ces diagrammes représentent les objets sous forme d’icônes. Comme dans un diagramme de séquence, les flèches
indiquent les messages envoyés pour la réalisation donnée. En revanche, l’ordre est indiqué par la numérotation des
messages.
UML utilise la numérotation décimale pointée, parcequ’elle permet de mieux voir quelle opération appelle quelle autre,
même si l’orgnisation générale est moins bien perceptible.


simuler
1. paramètres
Polynôme
Equation différentielle
3.Résolution()
2. résoudre
2. paramètres
8. solutions
solutions
Fonction de transfert
Perform
Rep_lib
1. convertir ()
Consigne
4. matrice ()
5. fonction()
9.
10
6. réponsef ()
simuler Cal_sol 7. dériver ()

10. tracer()
11. afficher ()
Lorsque le choix se porte sur la 10. tracer()
fonction, la simulation se résume 9. stabilité ( )
à convertir la fonction et à rapidité ( )
appeler la résolution de précision ( )
l’équation qui est décrite ci- erreur ( )
dessus 10. solutions
[Nkenlif04]
Figure 41. Un Diagramme de communication/collaboration : simulation des systèmes continus
Communication d’opérations
Com piloter
1 démarrer
unPilote : PiloteAutomatique uneVoiture : Voiture
2 allumer
leMoteur : Moteur
Figure 42. Exemple de diagramme de communication simplifié
3.5.4.5 La modélisation des composants

Les composants sont les unités physiques de code (source, objet, bytecode, exécutables, etc.) qui sont assemblées
pour former des applications. Les classes sont affectées à des composants fournissant des briques réutilisables pour la
construction des applications. Ces composants formeront la base d’une architecture d'application plug-and-play. La
réutilisation dans le langage UML intervient avant la compilation sous forme de classes réutilisables ou de frameworks
et après la compilation sous la forme d'assemblage de composants.
• Le diagramme de composants montre la mise en oeuvre physique des modèles de la vue logique avec
l'environnement de développement.

•

Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en
évidence la réutilisation de composants.
• Les composants peuvent être organisés en paquetages, qui définissent des sous-systèmes. Les sous-systèmes
organisent la vue des composants (de réalisation) d'un système. Ils permettent de gérer la complexité, par
encapsulation des détails d'implémentation.
Couche de présentation
Forms beans Jakarta Struts
Action beans
Sous-système
Dépendance
Couche d’affaires
Objet d’affaires Broker de

Persistance
Composants
Couche de persistance
SGBD
JDBC
Interface
Figure 43. Exemple de Diagramme de composants
3.5.4.6 La modélisation de la distribution et du déploiement

La modélisation du déploiement permet de représenter la façon dont l'application est distribuée dans un
environnement (réseau). Elle montre la disposition physique des matériels qui composent le système et la répartition des
composants sur ces matériels. Différentes topologies (de réseau) peuvent être modélisées. Par exemple les architectures
client/serveur, trois-tiers ou Internet/intranet. UML permet de décrire la topologie des nœuds dans le réseau, la façon
dont ces nœuds sont connectés et la manière dont l'application est partitionnée et distribuée sur ces nœuds. Les
ressources matérielles sont représentées sous forme de noeuds. Les noeuds sont connectés entre eux, à l'aide d'un
support de communication. La nature des lignes de communication et leurs caractéristiques peuvent être précisées. Les
diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel précis), ou des classes de noeuds.
Les diagrammes de déploiement correspondent à la vue de déploiement d'une architecture logicielle.


TCP/IP : Serveur Unité Diabétologie

: Base de
Données Objet
Connexion
: Domaine soins
Serveur unité Hépatologie
Base de données Objet
Domaine soins « Communication »
Configuration Unité Pathologie
: Configure
Application serveur Connaissance
Unité Pathologie Médicales
Configuration
TCP/IP : Configure
Interface utilisateur
Objet Contenu
Application Nœud
Interface Objet Contenu
Nœud
: un PC sous Windows
: Façade client Composant

Hépatologie
IU
: IU Unité Hépatologie
[Fowler03]
Figure 44. Exemple de diagramme de déploiement

3.5.4.7 Diagramme de packages

Ce diagramme n’était pas très utilisé au départ, mais il s’est montré de plus en plus utile.
Nom de parquetage 1
Dépendance (nommage optionnel)
Stéréotype Note textuelle

Nom de Paquetage 2 (contrainte textuelle)
Figure 45. Exemple : dépendance entre packages et notes
3.5.5 OCL : gestion des Contraintes sur les attributs et associations

[Warmer99]
Quand vous tracez un diagramme de classes, une grande partie du travail consiste à représenter des contraintes.
UML vous permet de choisir votre façon de décrire les contraintes et n’impose qu’une règle : les placer entre accolades
{ }. Nous aimons employer des termes courants, en mettant l’accent sur la lisibilité. UML fournit OCL (Object
Constraint Language) pour la spécification formelle des contraintes. Le langage OCL permet d’exprimer des
contraintes (formellement) sous forme d’expressions booléennes qui doivent être vérifiées par le modèle. OCL est un
langage à expressions, sans effet de bord sur le système modélisé.
L’exemple suivant montre l’utilisation du langage OCL. La contrainte que nous voulons exprimer est la suivante :
« une charge de véhicule ne doit pas excéder la charge maximale supportable par celui-ci.
Vehicule Typeehicule
NumImmatriculation Nom
Kilometrage ChargeMax
Charge est de type Volume
EstLibre Hauteur / Largeur
VitesseMaxVide
* 1
VitesseMaxCharge
{ Vehicule.Charge <= TypeVehicule.ChargeMax }

[RoquesVallee01]
Figure 46. Exemple de contrainte entre attributs, exprimée en OCL
OCL définit plusieurs types de collections d’objets, ainsi que de nombreuses opérations de manipulation de ces
collections.
« Set » est un ensemble au sens mathématique. L’expression « Colis.anomalieColis » retourne l’ensemble des objets
AnomalieColis liés à l’objet Colis concerné. L’opération prédéfinie permet de tester si l’ensemble est vide.
En résumé :
OCL est un langage formel d’expression de contraintes adapté aux diagrammes d’UML (depuis la version 1.1
d’UML), et en particulier au diagramme de classes. Il permet de spécifier des contraintes sur l’état d’un objet ou d’un
ensemble d’objets, avec une grammaire élémentaire et accessible (OCL peut être interprété par des outils tels que
« USE »). OCL limite les ambiguités du langage naturel (bien que lui étant proche), et se rapproche bien du langage
technique (langage mathématique, informatique…).
Formulation des contraintes :
– invariants sur des classes ;
– préconditions et des postconditions à l’exécution d’opérations :
– préconditions doivent être vérifiées avant l’exécution,
– postconditions doivent être vérifiées après l’exécution ;
– gardes sur des transitions de diagrammes d’états-transitions ou des messages de diagrammes d’interaction ;
– ensembles d’objets destinataires pour un envoi de message ;
– attributs dérivés, etc.


3.6 Conclusion
L'idée majeure qui préside dans le concept objet consiste à conserver la même philosophie depuis l'analyse des
besoins à partir du monde réel, la spécification jusqu'à sa réalisation, en l'occurrence celle des objets.
Pour conclure ce chapitre, nous pouvons donner quelques recommandations, qui s’avèrent nécessaires si l’on
souhaite concevoir un système par objets :
♦ « Savoir revenir aux étapes précédentes », car il arrive rarement que les classes principales soient trouvées avec
exactitude, des la première étape du processus, surtout qu’à coté des classes principales, des classes auxiliaires dues à la
programmation, viennent se greffer. Ces classes doivent être introduites naturellement en revenant à la première étape.
♦ « Prototyper rapidement avant de passer à une spécification complète », car il faut passer très rapidement à une
première ébauche du logiciel, qui permettra de spécifier le logiciel. Mais attention à une programmation sans
spécification.
♦ « Penser abstrait », car la conception par objets permet de définir des modèles du monde réel par abstraction des
classes et des opérations indépendantes de la nature des objets manipulés.
♦ Et enfin, « penser local », en ne cherchant pas à structurer globalement l’ensemble du système, mais en définissant
des opérations de portée locale.


4 Les méthodes Agiles
4.1 Contexte et définition

Les projets informatiques possèdent de plus en plus des aspects très complexes. Ceci est dû à plusieurs facteurs :
- la "taille" du projet,
- la "complexité" du système étudié (comportement, structure),
- l'hétérogénéité du projet (plusieurs systèmes d'exploitation, intégration de bases de données, systèmes en
réseaux, multimédia...).
- etc.
Ces facteurs sont en quelque sorte intrinsèque aux projets et participent d'une "manière fixe" à la complexité perçue. Pourtant,
cette dernière est aussi d'essence subjective dépendant directement du "savoir" et de la compétence du modélisateur. Du fait
de la densification des moyens et des outils mis à disposition, la maîtrise d'un projet informatique peut nécessiter un savoir de
plus en plus vaste dans différents domaines (logiciels, langages, code, APIs, ...).
En réponse à un malaise et aux insuffisances et difficultés liées aux méthodes de développement traditionnelles, des
nouvelles méthodes ont été mises au point, parmi lesquelles les méthodes agiles.
Dans le cadre de l’Ingénierie des logiciels, deux « écoles » s’affrontent :

• Ingénierie basée sur les modèles ou Model-Driven, préconisée par l’OMG (Object Management Group),
s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète
en effectuant plusieurs transformations successives.
• Ingénierie basée sur les méthodes agiles, qui met plus d'accent sur la production rapide de code opérationnel que
sur la documentation, ce qui minimise la modélisation en amont.
Les méthodes Agiles bien que s’appliquant actuellement aux projets de développement en informatique (conception
de logiciel), peuvent très bien s'appliquer à divers types de projets, compte tenu du fait qu’elles se veulent plus
pragmatiques que les méthodes traditionnelles.
Veronique Messager Rota, dans [Gestion de projet : Vers les méthodes agiles] propose la définition suivante :
“Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce
qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des
clients”.
4.2 Historique des méthodes agiles

Les méthodes agiles logicielles sont une nouvelle approche de développement de logiciels informatiques, qui repose sur
des cycles de développement itératifs et adaptatifs, dans lesquels une application est produite et testée en continu. Elles
ont été créées notamment suite à un nombre trop important d’échecs dans les projets.
Historiquement, on peut citer le modèle en spiral, créé par Barry W. Boehm pour le développement logiciel. Il se base
sur des phases itératives. Ce modèle a notamment influencé l’Extreme Programming (XP) par la suite.
Dans le début des années 1980, James Martin, s’appuyant sur cette vision d’une évolution continue, proposa une
méthode de développement rapide d’application (le RAD). Elle a été reprise par la suite en 1991, par Jean Pierre
Vickoff, pour l’adapter au système français (RAD2). Elle repose sur un cycle de développement en cinq phases :
• Initialisation pour définir le périmètre fonctionnel et le plan de communication
• Cadrage pour la définition des objectifs et des moyens à allouer au projet.
• Design avec notamment la présentation générale de l’application.
• Construction, phase pendant laquelle le produit sera construit module par module avec une validation
permanente de l’utilisateur pour les spécifications et les différents prototypes.
• Finalisation, avec la recette et le déploiement du livrable.
Dès 1994 Jennifer STAPLETON, en Grande-Bretagne, présentait DSDM, une solution équivalente au RAD2.
DSDM est souvent considérée comme la première méthode Agile et, dans la seconde moitié des années quatre-vingt-
dix, une vague d’une dizaine de méthodes (dont « Extreme programming » et « Scrum » sont les principales
représentantes), développa encore les techniques adaptatives d’estimation, de planification et de pilotage de projet.
Les méthodes agiles sont constituées d’un ensemble de méthodes qui ont un seul objectif : satisfaire le client. C’est dans
cette optique qu’en 2001 aux Etats-Unis 17 grands noms du développement logiciel se sont réunis.
Parmi eux on peut citer Ward CUNNINGHAM l'inventeur du Wiki, Kent BECK, père de l'Extreme Programming et
coauteur de l’outil de test « JUnit », Ken SCHWABER et Jeff SUTHERLAND, fondateurs de Scrum, Martin Fowler
avec la société « Thought Works » et le serveur d’intégration continue Cruise Control.
Ces 17 personnalités qui viennent toutes d'horizons différents ont réussi à extraire de leurs concepts respectifs des
critères pour définir une nouvelle façon de développer des logiciels.


A l’issue de cette réunion est né le Manifeste Agile (« Manifesto For Agile Software Development »), considéré
comme une définition du développement agile et de ses principes. Il contient les quatre valeurs fondamentales ainsi que
les treize principes de fonctionnement.
4.3 Les principes agiles
L’idée de base est de faire face efficacement aux multiples problèmes de lourdeur et parfois d’imprécision dans la
gestion des projets ; ou encore un cahier des charges figé dont les exigences ont évolué au cours de l'élaboration du
projet. Les méthodes agiles impliquent au maximum le client dans le projet de manière à lui livrer un produit très vite
qui sera sans cesse remis à jour et amélioré.
L’objectif principal ici est de satisfaire le client, et non un contrat établi préalablement. Pour réduire ce risque de fossé
au strict minimum, les méthodes agiles prônent l'incrément et l'itération.
Les méthodes agiles se déclinent sous forme de valeurs, de principes et de meilleures pratiques de développement, tel
par exemple XP (Extreme Programming).
Nous citons ici les quatre principes fondateurs d’agile : [Scott02] [ROQUES07]
• 1- Priorité aux personnes et aux interactions par rapport aux procédures et aux outils …
• L’accent est mis sur les individus, leur expertise, l’esprit d’équipe plutôt que sur les processus et les outils
Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans
l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne
brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus prolifique et
permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes
d'un même problème.
• 2- Priorité aux applications fonctionnelles opérationnelles par rapport à une documentation pléthorique
• On privilégie le code testé
Les processus lourds génèrent une documentation exhaustive avec tous ses inconvénients : ambiguïté du
langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une
illusion d'avancement du projet.
Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui
fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.
• 3- Priorité à la collaboration avec le client par rapport à la négociation de contrats
• Le client devient un partenaire qui participe au projet pour donner régulièrement son feedback
Le but d’un projet est de gagner de l’argent aussi bien pour le client que pour le fournisseur. En négociant un
contrat chaque partie se protège plus ou moins des risques financiers, mais les projets peuvent échouer à tout
moment si les délais sont non respectés ou bien les budgets insuffisants. La conséquence n’est pas compliquée.
Le client et le fournisseur se retrouvent alors devant un procès où finalement tout le monde est perdant puisque
le client ne peut avoir son logiciel et le fournisseur risque tout simplement de faire faillite selon l’importance
que le projet avait.
Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun pour réussir le
projet, c’est une relation gagnant / gagnant
• 4- Priorité à l’acceptation et la réactivité au changement par rapport à la planification
• Le planning est flexible pour accepter les modifications nécessaires
Comme on l’a vu dans les chapitres précédents, lorsqu’un plan est défini, l’équipe essaie de s’y tenir et ne fait
pas attention aux évènements extérieurs qui peuvent arriver à tout moment du projet. Il est en plus à l'origine
des conflits client/fournisseur classiques sur les délais de livraison. Pour le client, pouvoir adapter les besoins
en cours de projet est un atout concurrentiel : il est réactif aux changements des marchés et s'assure en plus que
le logiciel développé est parfaitement conforme à ses véritables besoins.
Nous présentons ci-dessous, les champs de valeurs des méthodes agiles par rapport aux autres méthodes
(classiques).


1- Ressources humaines
et communication
2- Applications Planification
fonctionnelles rigide
3- Collaboration
étroite avec Négociation
le client de contrat
4- Accueil
réactivité au changement Documentation
Processus
et outils
Figure 47. Classification des valeurs des méthodes agiles et classiques
4.4 Les méthodes Agiles ont-elles des limites ?

Pour l’instant, la critique que l’on peut avancer par rapport aux méthodes agiles, c’est la difficulté à faire face aux
projets pour lesquels les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés (par exemple,
client indisponible, ressources humaines dispersées géographiquement, acteurs du projet inertes ou refus des
changements…). A ce moment on pourrait faire face à de nombreux dangers : risques de dérives, documentation
insuffisante, inadaptation à des projets de grande envergure.
4.5 Evolution des différentes méthodes

Le terme AGILE regroupe un ensemble de méthodes que nous citons ci-dessous avec les dates de publication officielle :
* Rapid Application Development (RAD, 1991)
* Dynamic Systems Development Method (DSDM, 1995) : développée par un consortium Anglais, en Grande-
Bretagne à partir de 1994, et qui commercialise le RAD
* Scrum (1996)
* Feature Driven Development (FDD, 1999): créée par Jeff De Luca.
* Extreme programming (XP, 1999)
* Adaptive Software Development (ASD, 2000): créée par Jim Highsmith.
* Crystal clear (2004)
* etc.
La plupart de ces méthodes éssayent d’assembler des atouts majeurs des approches RUP (Rationl Unified Process) et
RAD (Rapid Application Development), tout en gardant une souplesse de planification et d’adaptation au changement.
Il faut noter que d’autres méthodes se réclament de l'agilité :
* MACAO (Méthode d'Analyse et de Conception d'Applications Orientées-Objet) : support de la notation UML,
démarche en spirale de type RAD, développement participatif par prototypage incrémental, formes de conception
(Design Patterns) pour l'IHM, architecture n-tiers, composants logiciels réutilisables.
* KANBAN : mise en place entre deux postes de travail, elle limite la production du poste amont aux besoins exacts
du poste aval. Cette méthode est plus adaptée aux entreprises ayant une production répétitive et relativement régulière.
* AUP (Agile Unified Process) : c’est une déclinaison Agile, non libre de droits, de Rational Unified Process (RUP –
qui est un produit propriétaire d’IBM, mais pas une méthode Agile).
* PUMA (Processus Urbanisant les Méthodes Agiles).


4.6 Choix de méthode agile et optimisation
4.6.1 Comparaison
Un comparatif entre les méthodes agiles de réalisation (en plus de RUP et RAD) est fourni dans le tableau ci-après :
Crystal clear Equipe = 6 (Mise sur les pratiques les moins contraignantes -> Méthode très peu formalisée)
XP Equipe = 12 (importance de la communication informelle et de l’autonomie de l’équipe)
SCRUM (Nombreux processus empiriques et définis implicitement)
FDD Equipe = 20
DSDM Extensible grâce aux rôles et aux responsabilités bien définis -> (facilitateur, etc.)
ASD Extensible, mais reste très générale -> Nécessite une adaptation au cas par cas
RUP Importance des parcours bien définis -> Support de gros projets
RAD Présence d’un groupe de coordination et de rapport -> Encadre et formalise la communication
Taille du Project
Source : Business Interactif
Figure 48. Histogramme de mise en perspective des méthodes agiles, RUP et RAD
4.6.2 Unification ou combinaison de méthodes dans la pratique

Aucune méthode agile prise indépendamment n’était véritablement complète au départ (léger manque de cohérence
pour certaines…). Face à d’inombrables méthodes, le choix pourrait être une difficulté supplémentaire. Il n’ya pas de
méthode idéale en tant que telle, l’essentiel étant de s’appuyer sur une utilisation optimisée des pratiques de base tout en
s’enrichissant d'une sélection des pratiques spécifiques utiles à un contexte de projet particulier. Pour aider les
utilisateurs à faire le bon choix (selon leur contexte), un comparatif entre Scrum, XP et PUMA est présenté ci-dessous.
Scope des pratiques Agiles SCRUM XP PUMA

Recueil élémentaire des besoins OUI OUI OUI
Simple liste ou fiches de récits utilisateurs
Gestion systémique des exigences NON NON OUI
Formalisation Agile d’un document structuré mais élémentaire
Gestion formelle des communications complexes NON NON OUI
Organisation, charte projet, plan de communication, techniques optimisées de maîtrise de
réunions en contexte difficiles.
Estimation de charges Agiles niveau « équipe » OUI OUI OUI
Axée sur la vision des intervenants, typiquement : planning poker game
Techniques et outillage d’estimation de charges Agiles NON NON OUI
Basées « métriques » standardisées (points de Cas d’utilisation, de récits, de scénarios, d’objets
WEB, Evaluateur, etc.)
Pilotage des niveaux d’itérations d’un projet OUI MINIMA OUI
Gestion des réunions « équipe » OUI OUI OUI
Techniques extrêmes de qualité du code NON OUI OUI
Techniques standards mais formalisées et structurées de qualité de la conception et du codage NON NON OUI
Approche globale simplifiée (PUMA Essentiel) NON NON OUI
Justifications financières agiles et formelles NON NON OUI
Techniques Agiles de suivi des risques externes NON NON OUI
Techniques simples d’amélioration du processus Agile (Lean management) OUI OUI OUI
Rapprochement avec des bases ou processus normés (CMM) NON PARTIEL OUI
Disponibilité de Frameworks Agiles (architecture globale d’entreprise, techniques de veille NON NON OUI
technologique, SOA, BPM)
[AgileBlog]
Tableau 2 Comparatif entre Scrum, XP et PUMA


Une approche élargie, libre et ouverte a été proposée, consistant à construite à partir des meilleures pratiques existantes
qu'on intègrerait, fédèrerait et complèterait. Des efforts ont été faits pour unifier ou rendre beucoup plus interopérables les
diverses méthodes, en s’appuyant sur les points forts de chacune d’elle. Jean-Pierre Vickoff dégagé les éléments de Proposition
pour l'Unification des Méthodes Agiles ou PUMA (publiés sur [www.adeli.org]).
Il est possible de combiner les pratiques collaboratives de Scrum à l’ingénierie du logiciel XP. Cela donne un résultat
très acceptable pour des projets de niveau moyen. Il suffit de constituer de petites équipes au sein desquelles XP est
appliquée, SCRUM étant utilisée pour la coordination des différentes équipes.
Des voies intéressantes ont été ouvertes, qui combinent les méthodes agiles et des techniques en cascade classiques.
Voici une liste d’éléments pouvant servir de socle de pratiques communes à l'ensemble des méthodes agiles :
• Spécification et validation permanente des Exigences.
• Participation de l'utilisateur final aux groupes de travail.
• Groupes de travail disposant du pouvoir de décision.
• Autonomie et organisation centralisée de l'équipe (motivation).
• Niveau méthodologique variable en fonction des enjeux du projet.
• Pilotage par les enjeux et les risques.
• Recherche d'excellence technique de la conception.
• Vision graphique d'une modélisation nécessaire et suffisante.
• Vision de la documentation nécessaire et suffisante.
• Planification stratégique globale basée sur des itérations rapides.
• Réalisation en jalons par prototypage actif itératif et incrémental.
• Normes et techniques raisonnables de qualité du code (métrique).
• Architecture à base de composants, gestion des changements.
• Recherche continue d'optimisation et d'amélioration des pratiques
4.6.3 Processus SCRUM

Scrum affirme sa différence dans des pratiques de courtes réunions quotidiennes (Stand-Up meeting). Ces temps de
travail commun ont pour objectifs d'améliorer la motivation des participants, de synchroniser les tâches, de débloquer
les situations difficiles et d'accroître le partage de la connaissance.
[Schwaber04]
Figure 49. Processus de développement utilisé (SCRUM)


Le principe de la méthodologie SCRUM [Scrum09] est de développer un logiciel de manière incrémentale en
maintenant une liste totalement transparente des demandes d'évolutions ou de corrections à implémenter (backlog).
Avec des livraisons très fréquentes, toutes les 4 semaines en général, le client reçoit un logiciel à chaque fois, un
logiciel possédant toujours plus de fonctionnalités et en parfait état de fonctionnement. Pour cela, la méthode s'appuie
sur des développements itératifs à un rythme constant d'une durée de 2 à 4 semaines. Les évolutions peuvent donc être
plus facilement intégrées que dans un cycle en V.
4.6.4 Processus DSDM

La méthode DSDM est basée sur une démarche évolutive et incrémentale. Au départ, il a pour objectif de pallier au
manque de formalisme précis au niveau de RAD, qu’il complète d’ailleurs par des principes qui couvrent l'ensemble du
développement logiciel. Dans un processus DSDM, les acteurs se spécialisent dans des « rôles ». Lors d’un projet
DSDM, on pourra par exemple retrouver : « sponsors exécutifs », « ambassadeurs », « utilisateurs visionnaires »,
« utilisateurs conseillers », « animateur-facilitateur », « rapporteurs » …
La méthode DSDM obéit à 9 principes de base que voici :
- Implication active d’utilisateurs, obligatoire
- Pouvoir de décision des équipes DSDM
- Livraison fréquente de produits
- Adéquation aux besoins : critère essentiel pour que les produits livrés soient acceptés
- Nécessité d'utiliser un développement itératif et incrémental pour obtenir une solution adaptée aux besoins
- Reversibilité des modifications effectuées au cours du développement
- Définition des besoins à un niveau global
- Intégration des tests à toutes les étapes du cycle de vie
- Approche basée sur la collaboration et la coopération entre toutes les personnes intéressées par le projet
Le processus DSDM de développement de projets est composé de 5 phases.
- Etude de faisabilité
- Etude business
- Modèle fonctionnel itératif
- Conception et réalisation itératives
- Mise en œuvre
Le cycle de développement DSDM est présenté à la figure ci-dessous.
Faisabilité
Etude
métier
Modèle Mises-en
Fonctionnel Œuvre
Conception et
Construction
Figure 50 Processus DSDM
Le principal inconvenient de DSDM c’est la contractualisation (difficile). Car les notions de délai et de coût sont des
critères fondamentaux par rapport aux fonctionnalités du produit, contrairement aux approches traditionnelles qui
privillégient plutôt les fonctionnalités. L’autre difficulté qui pourrait apparaître, c’est la gestion de la relation avec le
client/utilisateur.


4.6.5 Processus XP (eXtreme Programming)
Le processus XP met plus d’accent sur la construction de l'application. XP durant la planification utilise une approche
comparable à un jeu, appelée « Planning game », qui permet d’impliquer à la fois les utilisateurs et les développeurs.
Un ensemble de techniques sont mises en œuvre pour la production du code. On peut citer la programmation en binôme
(Pair programming), l'appropriation collective du code, la Refactorisation (Refactoring) et l'Intégration continue. Dans
ce cas, la méthode RAD suggère des revues de code personnelles, puis collectives et l'intégration avant chaque Focus
(ou Show). Normalement, même avec le RAD, on ne devrait procéder à une programmation en binôme que pour les
parties de code les plus stratégiques.
4.6.6 SAFE
La méthode Scaled Agile Framework (SAFE) apporte plus de souplesse et de flexibilité dans la gestion de projets. Elle
SAFe permet surtout d'adapter la méthode agile à l'échelle de l'entreprise. Elle permet d’instaurer au sein d’une même
entreprise un langage commun et fluide entre les différentes équipes concernées par le développement d’un produit.
Plus le développement au sein d’une entreprise occupe une place importante, plus les équipes qui s’y rapportent sont
nombreuses. La méthode SAFe intervient donc pour apporter davantage de cohérence et de flexibilité entre les
différents acteurs. Il s’agit précisément de proposer au client un produit final à la hauteur de son cahier des charges.
4.6.6.1 Comment utiliser SAFe (Scaled Agile Framework) ?
Le concept SAFe s’adresse essentiellement aux équipes de développement constituées de 50 à 150 personnes
[SAFE19]. En deçà, le déploiement de cette méthode agile ne possède pas véritablement d’intérêt. Pour fonctionner,
SAFe s’articule autour de trois degrés distincts de gouvernance : la gestion d’équipes, la gestion de programmes et la
gestion de portefeuilles projets. Ces différents niveaux sont centralisés au niveau de l’Agile Release Train. À l’occasion
d’un séminaire appelé « Program Implement Planning », l’ensemble des personnes impliquées sera informé des
objectifs à atteindre et des cycles de développement prévus (sprint) pour y parvenir.
4.6.6.2 Concept de « back log » sur la stratégie d'entreprise
Le backlog le backlog regroupe une liste des fonctionnalités du futur produit. Sselon [SAFE19], il est Placé sous la
responsabilité du « Product Owner » (Chef de produit/client). Même si le backlog d’un produit ne contient pas toutes les
spécificités du produit, celui-ci fera l’objet d’un affinement progressif au fil des différents cycles de développement.
Les fonctions essentielles mentionnées, elles, doivent toutefois être priorisées de manière à déterminer leur ordre de
réalisation. Le backlog pourra évoluer régulièrement en fonction de la stratégie visée par l’entreprise et, surtout, pour
répondre aux besoins du client.
4.6.7 SAFe vs Scrum

Bien qu’étant les principales approches dans la gestion de projets Agiles, SAFE et Scrum n’évoluent pas forcément
dans les mêmes couloirs. En effet, Scrum est plus indiqué pour les projets agiles mono-équipe, tandis que SAFe lui est
intéressant pournmettre en œuvre des projets agiles plus transversaux entre plusieurs équipes.
4.7 « Modélisation agile » des projets

Les méthodes agiles placent justement l’agilité au centre de l’innovation. En plus, elles mélangent différentes approches
de management (travail en binôme, responsabilité collective…) et libèrent la créativité tout en garantissant le réalisme
et la conformité.
Issues de l'observation pragmatique de la vie des projets informatiques et se basant sur le partage des responsabilités, les
méthodologies agiles évitent de s'encombrer de ce qui n'est pas nécessaire, « coupant » ainsi les coûts. Ainsi, la
documentation sera limitée au strict minimum, le code faisant référence, les tests prennent une importance capitale et
tout est fait pour faciliter un dialogue simple et direct. Nous listons ici quelques uns des principes fondamentaux :
- Avoir une culture de la qualité, préventive, pas réactive : donc, éliminer les « bugs » à la source, le plus tôt
possible. Le "test drived development", les revues par les pairs, la conception commune sur tableau blanc, une
souplesse.
- Avoir en vue le gain pour le client, garder la souplesse et livrer le plus vite possible ce qui a de la valeur.
- S'adapter en tout temps aux circonstances, être évolutif, rester souple.
- Réduire les pertes le plus possible. Est-ce que tel document est vraiment utile? Est-ce que cette fonctionnalité a
vraiment une valeur ?
- Il faut également un changement de mentalité de la part des participants. Ils doivent avoir deux préoccupations
à cœur, tout les jours : livrer et améliorer ses façons de faire, tout les jours.
Les méthodes agiles privilégient le développement à itération courte (XP, Scrum, Lean, ASD ...)
4.7.1 Les valeurs d'une modélisation Agile

La « modélisation agile » est promue par Scott Ambler [Scott02], qui adapte les valeurs de XP à la modélisation.

Les mots clés de la modélisation agile sont :


· « Communication »
· « Simplicity »
· « Feedback »
· « Courage »
· « Humility »
Les clés d’une modélisation réussie consistent à promouvoir une communication efficace entre tous les participants du
projet, de s’efforcer à développer la solution la plus simple possible qui satisfasse tous les besoins, à obtenir des retours
rapides et fréquents, à avoir le courage de prendre des décisions et s’y tenir, et avoir l’humilité de reconnaître qu’on ne
sait pas tout et que les autres ont une valeur à apporter à ses propres efforts.
Les méthodes Agiles sont conçues pour s’adapter au changement. A partir des valeurs fondamentales décrites au
paragraphe précédent, ont été déterminés treize principes fondamentaux décrits dans le « Manifeste Agile ». Nous les
listons ci-dessous :
• Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions opérationnelles de
l’application, source de valeur.
• Accepter le changement des exigences, même tard dans le cycle de vie, pour garantir la compétitivité du client.
• Livrer le plus fréquemment possible des versions opérationnelles, avec des itérations allant de deux semaines à
deux mois, avec une tendance pour la période la plus courte.
• Clients et développeurs doivent coopérer quotidiennement tout au long du projet.
• Bâtir des projets autour d’individus motivés. Leur donner l’environnement et le support dont ils ont besoin et leur
faire confiance pour remplir leur capacité à réaliser le travail.
• La méthode la plus efficace de transmission de l'information est une conversation en face à face.
• Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. Les méthodes agiles
recommandent que le projet avance à un rythme soutenable
• Sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.
• Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
• La simplicité - l'art de maximiser la quantité de travail à ne pas faire est essentielle.
• Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
• À intervalles réguliers, l’ensemble de l’équipe s’interroge sur la manière de devenir encore plus efficace, puis
ajuste sont comportement en conséquence.
*) Les principes de la modélisation agile sont issus des principes XP. Ils sont repris dans la figure ci-dessous :
Core Principles: Supplementary Principles:
• Assume simplicity * Content is More Important

• Embrace Change Than Representation
• Enabling The Next Effort is * Open and Honest Communication
Your Secondary Goal
• Incremental Change
• Maximize Stakeholder ROI
• Model With a Purpose
• Multiple Models
• Quality Work
• Rapid Feedback
• Working Software is Your
Primary Goal
• Travel Light
[Scott02]
Figure 51. Principes de la modélisation agile


*) La pratique de agile est également issue en partie de XP Les meilleures pratiques sont repris ci-dessous :.
Core Practices: Supplementary Practices
• Active stakeholder Participation
• Apply the Right Artifact (s)
• Collective Ownership
• Create Several Models in parallel
• Create Simple Content * Apply Modelling Standards
• Depict Models Simply * Apply Patterns Gently
• Display Models Publicly * Discard Temporary Models
• Iterate to Another Artifact * Formalize Contract Models
• Model in Small Increments * Update Only When It Hurts
• Model With Others
• Prove it With Code
• Single Source Information
• Use the Simplest Tools
Figure 52. Pratiques de la modélisation agile

*) Certains modèles Agiles peuvent s’apuyer à la fois sur XP et SCRUM.
- XP apporte une capacité à unir l’effort de deux personnes lorsque des points durs, techniques ou fonctionnels,
sont à résoudre rapidement pour le bien du projet.
- SCRUM apporte l’agilité nécessaire à l’accueil favorable de tout changement, à l’ajustement rapide des
objectifs du projet et des pratiques, ainsi, une bonne collaboration et communication avec le client s’en suit.
4.7.2 Modélisation agile : le point de vue de Craig Larman

Craig Larman, spécialiste de la modélisation agile dit ceci :
- Ne modélisez pas seul ! La modélisation doit être collaborative et participative
- Des outils simples et moins onéreux qui encouragent la créativité. Larman encourage l’utilisation de "feutres"
et "paperboards", plutôt que de progiciels couteux et lourds (pendant la modélisation).
- Des modèles multiples et en parallèle. Par exemple « diagrammes de classes » et de « séquence » pour faire une
esquisse de conception objet.
- Les modèles ne sont pas de la documentation! Nous modélisons pour avoir une conversation ensemble et pour
développer une compréhension commune.
- Tout modèle est faux ! Et c’est OK. Par cet aphorisme provocant, Larman veut mettre l’accent sur l’aspect
provisoire des modèles, le seul modèle qui fait foi à la fin du projet, c’est le code !
The code is the model !
L’organisation de la modélisation agile selon Larman peut être représentée ainsi :
[Craig03]
Figure 53. Modélisation de projet selon Craig Larman


4.8 Test-Driven Requirements (TDR)
La gestion des exigences dirigées par les tests, ou Test-Driven Requirements (TDR), représente une démarche de
formalisation des besoins (issue des Méthodes Agiles) qui permet de réduire les risques d'incompréhension. Elle a été
l’étape ultime dans l’adoption d’un processus de développement dit « lean » (dérivé de la méthodologie "Toyota Way"
– voir Annexe).
La technique TDD (acronyme pour Test-Driven Development) vous encourage à formaliser vos tests avant même de
créer votre première ligne de code. Elle comporte 5 étapes :
- Ajoutez un premier test
- Vérifiez que ce test échoue (car le code n’existe pas encore)
- Écrivez le code suffisant pour passer le test
- Validez immédiatement le test de ce code
- Améliorez le code sans modifier ni le test ni la fonctionnalité
Vous facilitez ainsi la production d’un code valide en toutes circonstances ! Définissez d’abord des tests précis avec vos
équipes agiles. Partagez ensuite une vision globale du programme à développer. On peut à chaque fois revenir à l’étape
1 avec un nouveau test unitaire.
Le développement piloté par les tests est souvent utilisé avec la méthode XP (Extreme Programming).
Les pratiques du TDR trouvent leur source dans la transposition du « lean thinking » au monde du développement
logiciel.
4.8.1 Lean sofware development
Les principes du « lean thinking » ont été transposés au monde du développement logiciel par les travaux de nombreux
experts en développement informatique, les contributeurs les plus importants et les plus reconnus étant les époux
Poppendieck (http://www.poppendieck.com/).
Principes du Lean :
- Eliminer les gâchis : tout le lean thinking est orienté vers l’élimination des gâchis. Dans le monde du développement
logiciel, les gâchis sont de plusieurs sortes : fonctionnalités non nécessaires, stocks d’exigences en attente de
développement, anomalies non détectées, tests de non-régression manuels, temps d’attente, multiplication des
intermédiaires et des échanges formels entre ces intermédiaires, perte d’information, etc.
- Qualité intrinsèque : l’objectif est d’éliminer les défauts le plus tôt possible et de faire en sorte que les
disfonctionnements ne puissent pas se produire.
- Livrer rapidement : réduire ses délais de développement pour rapprocher le plus possible le moment d’une demande
d’évolution de sa livraison.
- Respecter les personnes : d’une part, tenir compte (se concentrer) sur les personnes qui apportent directement de la
valeur pour le client, d’autre part accueillir les idées d’amélioration de chaque personne impliquée dans le processus et
pas simplement du top-management ou d’un groupe d’experts.
[WWWOpenTDD99]
Figure 54 Les étapes de la technique TDD par Xavier Pigeon

4.8.2
Les étapes d’une évolution « lean »


L’organisation classique des activités d’ingénierie logiciel (activités d’ingénierie logiciel successivement réalisées,
que ce soit au sein d’un cycle en cascade, ou au sein d’une itération) est caractéristique d’une approche prédictive du
développement logiciel et donc à l’opposé d’une organisation « pull » préconisée par le lean-thinking.
Cependant, l’émergence des pratiques agiles au sein des maîtrises d’oeuvre ont permis aux développeurs d’organiser
plus efficacement leur travail avec le Test-Driven Development, dit TDD, et d’améliorer fortement la qualité du code.
Le principe du TDD est qu’aucun code n’est produit tant qu’un test unitaire n’a pas échoué. Cette approche illustre
parfaitement la mise en application du lean thinking au monde du développement logiciel : l’étape de codage ne produit
rien tant que l’étape de test unitaire ne le demande pas. Nous avons ici un fonctionnement parfait en mode « pull ».
C’est l’écriture d’un nouveau « test unitaire » qui va déclencher l’écriture de nouveau « code ». La mise en oeuvre du
lean thinking revient à fusionner les étapes de codage et tests unitaires pour donner naissance à une étape de TDD.
La figure 68 illustre ainsi l’organisation de nombreux projets d’aujourd’hui avec le déploiement de méthodes agiles.
[MANTEL07]
Figure 55. Les deux dernières étapes vers un processus lean
Le processus schématisé à droite illustre une organisation lean, dans laquelle le client « tire » les fonctionnalités de la
première cellule, plutôt que de les pousser dans la chaîne de production et d’attendre qu’elles soient réalisées. Le TDR
est donc l’aboutissement d’une démarche de changement de ses pratiques vers un processus lean.
4.8.3 TDD (Test Driven Development) et TDR (Test Driven Requirement)

Les tests unitaires, sont importants mais présentent des limitations. Tout d’abord le test unitaire est « unitaire » : il
vérifie la bonne adéquation du code à la conception. Ensuite, les jeux de données sont souvent peu représentatifs du
métier ou du fonctionnel. Il est donc important de franchir le palier permettant de faire des tests fonctionnels de la
même manière que des tests unitaires dans TDD, mais de rendre ces tests abordables par la population concernée.
4.8.3.1 Appliquer les principes du TDD au niveau fonctionnel

L’utilisation du logiciel FIT (http://fit.c2.com/) permet d’effectuer des tests fonctionnels sans attendre une version du
logiciel exécutable, ce qui représente un confort pour les équipes de développement. Le développeur est ainsi capable
de lancer de tels tests autant de fois que nécessaire pendant qu’il développe et s’assurer que ses évolutions ou
corrections n’introduisent pas de régression. Il peut aussi utiliser ces tests à la manière du TDD, c'est-à-dire les créer, ou
demander à un analyste de les créer, avant d’écrire le code et les utiliser ensuite comme une mesure d’avancement du
travail. On parle ainsi de FTDD, Functional Test-Driven Development.
Non seulement FIT permet d’effectuer des tests quasi-fonctionnels à la façon de tests unitaires automatisés, rapidement
et automatiquement, mais il permet aussi dans une certaine mesure de corriger plus rapidement le code. On peut en effet
l’utiliser comme outil de diagnostic du code. Dans une activité de correction classique, lorsqu’un développeur recherche
la cause d’une anomalie, son travail consiste souvent à lancer une instance locale de l’application sur sa machine, en
mode « debug », après avoir placé des points d’arrêt aux endroits du code qu’il pense fautifs. Il déroule ensuite la
manipulation du testeur, travail qui nécessite souvent des interactions avec ce dernier afin de clarifier son scenario ou de
retrouver un jeu de données similaire dans l’environnement de développement. Après avoir atteint un point d’arrêt, le
développeur va exécuter l’application pas à pas, tout en observant les valeurs des variables afin de détecter le point
fautif. FIT peut être utilisé pour sonder les différentes parties du code par l’écriture de tests qui reflètent les
manipulations d’un testeur, et zoomer progressivement, en écrivant des tests plus fins, sur les niveaux plus détaillés
pour essayer d’identifier les fonctions fautives. Au-delà de l’économie de temps par rapport à un débogage classique,
cela permet également de se doter d’une batterie de tests de non-régression à l’issue de la correction, et donc de
s’assurer que l’anomalie ne réapparaîtra pas.
4.8.3.2 Des spécifications exécutables

D’après la société Valtech, la pratique du FTDD n’est pas suffisante si l’on veut obtenir un processus lean, et que l’on
peut pousser encore plus loin l’intégration des activités de spécifications et des tests.


FIT permet en effet d’ignorer le texte d’une page web et de n’utiliser que les tableaux marqués comme étant des tests. Il
est donc possible de créer des pages web qui contiennent du texte libre, par exemple des règles de gestion, et
contiennent des tableaux de tests, par exemple les tableaux qui vérifient ces règles. Il est donc possible de rassembler au
sein d’un même « livrable » les exigences et les tests qui les vérifient. Nous atteignons ici la dernière étape de mise en
place d’un processus lean. Dans cette organisation, les différentes étapes dont la production du code, sont conduites par
la demande de la dernière étape de la façon suivante :
- Test-Driven Requirements : client et fournisseur travaillent sur un même livrable, c’est-à-dire l’ensemble des
exigences et les tests qui les valident. L’écriture des tests sous format tabulaire permet de valider la compréhension des
uns et des autres. C’est pour cela qu’à cette étape nous disons que les exigences sont dirigées par les tests. On
commence par écrire les tests s’inspirant des exemples que fournit le MOA (Maître d’Ouvrage – PO - Project Owner)
ou le MOE (Maître d’œuvre – PS - Project Superviser) et on écrit ensuite les règles de gestion ou cas d’utilisation
correspondants. L’écriture de tests est utilisée comme un outil de recueil du besoin.
- FTDD : comme vu précédemment, cette étape consiste à écrire les fixtures qui permettent de mettre en oeuvre les tests
écrits à l’étape précédente. Pour ce faire, les développeurs se basent sur des API existantes ou non. Si les services
n’existent pas encore, un travail de conception permettra de les définir et d’écrire les fixtures qui ont besoin de ces API.
Cette étape permet aussi aux développeurs d’enrichir les tests existants lorsqu’ils ne sont pas assez détaillés. A cette
étape, les spécifications deviennent exécutables. L’intégration de ces tests dans l’usine logicielle permettra de faire
apparaître de nouveaux tests fonctionnels en échec et donc de déclencher le travail de l’étape suivante.
- TDD : à cette étape, les développeurs conçoivent les différentes classes et méthodes implémentant le service en
définissant d’abord les tests unitaires permettant de vérifier leur fonctionnement. La validation progressive des tests
unitaires permet de mesurer l’avancement du travail. Au fur et à mesure de l’implémentation des classes bas-niveau, les
tests fonctionnels vont progressivement réussir. Lorsque l’ensemble des tests réussit, le produit est prêt à être livré !
Dans cette organisation, le codage devient en pratique la dernière activité d’ingénierie logicielle avant la livraison.
Toutefois, on note quelques ajustements dans les différentes étapes, car le codage peut mettre en lumière des faiblesses
dans les exigences ou dans la conception. Ces faiblesses sont adressées en réajustant les tests fonctionnels et unitaires.
Une telle organisation ne peut être supportée qu’avec les outils adéquats. FIT peut paraître limité pour répondre
totalement à ce besoin, notamment sur l’aspect TDR. Il faut disposer d’outils permettant une meilleure collaboration
des différents acteurs du processus, et une structuration plus contextuelle de l’information. La forme du wiki paraît
idéale pour répondre à cet objectif en permettant une structuration et une contextualisation efficace de l’information,
ainsi qu’une facilité de mise à jour.
4.8.3.3 Eliminer les gâchis avec le MBT (Model Based Testing) et ATDD
[MBTWWW]
Figure 56. L’approche MBT
Le Model-Based Testing propose une alternative aux outils comme FIT et ses dérivés. Le principe est d’élaborer un
modèle à partir duquel on dérive automatiquement les actifs nécessaires aux activités de tests. Par exemple, on peut
générer des cahiers de recette, ou des scripts de tests.
De la précision du modèle dépend la profondeur des tests que l’on peut générer. L’approche impose donc un fort
investissement dans les activités de modélisation. Elle a du sens pour les organisations déjà matures sur cet aspect pour
qui l’apprentissage sera modéré.
Il s’agit donc d’assurer le pilotage de la production et la maintenance de tests fonctionnels et d’acceptation, en se
référant à une modélisation qui spécifie bien les besoins exprimés. Cette approche a prouvé son efficacité.
* Les techniques de l’ « Acceptance Test Driven Development » (ATDD) font partie des méthodes agiles. Elles
permettent aussi (comme MBT), de formaliser l’expression de besoins métier dans des scénarii utilisateurs, pouvant être


exploités directement pour des tests de validation. Ces différents test définis, vont guider directement le processus de
développement, avec intégration progressive.
4.8.3.4 Usine logiciel

A court terme, il est indispensable de se doter d’une usine logicielle permettant l’exécution en permanence des tests
unitaires et fonctionnels si l’on souhaite réussir sa mise en oeuvre du TDR.
Ce point participe à la mise en pratique de l’aspect « jidoka » (voir annexe) du lean-thinking. En effet, l’exécution en
permanence des tests fonctionnels, ainsi promu au rang de tests de non-régression, pourra indiquer si une anomalie s’est
glissée lors de la production de nouveau code, ou la modification du code existant.
Au-delà de l’objectif de non-régression, l’usine logicielle agira comme un séquenceur de toutes les activités
d’ingénierie logiciel pour les évolutions d’une application. Ainsi l’intégration de nouvelles spécifications associées à
leurs tests dans le référentiel projet mettra en lumière le besoin de développer les fixtures (outils de test et performance)
associées. Puis, l’intégration des fixtures montrera l’échec des tests associés et déclenchera ainsi le travail de TDD pour
concevoir et développer le code nécessaire à la réussite de ces tests.
4.8.3.5 Mutation organisationnelle et fonctionnelle

• La mise en place du TDR implique également d’entreprendre une mutation organisationnelle afin de faire
sauter les séparations entre les activités amont et aval des équipes de développement. Si une organisation
n’entreprend pas ce travail, les spécifications et tests « à la mode TDR » seront une charge supplémentaire pour
toute l’équipe.
• A long terme, la pratique du TDR entrainera la disparition de certains rôles caractéristiques des silos
organisationnels (architecture "en silos" - chaque application ou BD de l'entreprise reposait sur une plate-forme
propriétaire, l'isolant du reste de l'écosystème informatique.) pour faire place à de nouveaux profils. Par exemple,
les rôles d’analyste et de testeur sont amenés à fusionner car il n’existe plus de besoin d’avoir des ressources
spécialisées sur les exigences et sur les tests, ces activités étant elles-mêmes fusionnées [TDRwww11].
4.8.4 Processus FDD

Le processus FDD (Feature Driven Development – développement dirigé par les fonctionnalités) met en œuvre la
notion de « Features set » (groupes de fonctionnalités). FDD a comme spécificité de se focaliser sur les objectifs
immédiats mesurables (Mission focused), avec comme guide la notion de « valeur métier » qui traite en priorité des
fonctionnalités porteuses de valeur. On retrouvera également ces valeurs dans la méthode RAD (objectifs de Focus) et
même dans Scrum (avec la notion de « Sprint »). FDD décrit 5 activités de base durant le processus de
développement de logiciels (voir figure ci-dessous) :
- Développement de modèle général
- Spécifiction de la liste de fonctionnalités
- Planification par fonctionnalité
- Conception par fonctionnalité
- Réalisation par fonctionnalité
[FDDWWW2]
Figure 57 Modèle du cycle de vie du Processus FDD


NB : - Dans un métamodèle FDD, on peut visualiser à la fois les processus et les données mises en jeu au niveau des
méthodes. Ceci garantit une bonne lisibilité et une clarté, offrant ainsi une compatibilité avec UML.
- Le développement basé sur les fonctionnalités avait été conçu en 1997 par Jeff de Luca pour des besoins
spécifiques d’un projet informatique à grande échelle : 15 mois et 50 personnes dans une banque à Singapour.
Pour une bonne maîtrise des projets FDD, il est recommandé d’avoir une traçabilité sans failles des grades étapes du
processus de développement. C’est ainsi que FDD définit six étapes principales à couvrir, en attribuant un poucentage à
chaque phase de réalisation du projet (voir tableau ci-dessous tiré de [www.featuredrivendevelopment.com]).
Domain Walkthrough Design Design Inspection Code Code Inspection Promote To Build
1% 40% 3% 45% 10% 1%
4.8.5 BDD : développement basé sur les spécifications

BDD (Behavior-Driven Development) a été conçue par Dan North, en réponse au développement piloté par les tests
(TDD), avec pour objectif d’harmoniser les conversations entre tous les interlocuteurs responsables de la définition du
produit ou du service. La technique BDD met l’accent sur la coopération entre les développeurs, les responsables
qualité (ou QA pour Quality Assurance) et l’ensemble des parties prenantes (que ce soit sur le plan techniques ou non)
de votre projet. Elle offre 5 principales phases :
1. Faites participer les parties prenantes à vos ateliers collaboratifs (workshop).
2. Utilisez des exemples pour décrire le comportement de votre code informatique.
3. Préférez le mot « devrait » pour clarifier les responsabilités et modifier vos fonctionnalités.
4. Préférez l’expression « vérifier que » pour différencier les résultats de chaque intégration.
5. Automatisez les exemples pour partager vos commentaires et vos tests aux parties prenantes.
[WWWOpenTDD99]
Figure 58 Les étapes de la technique BDD par Dan North
Le langage commun et les interactions directes entre les acteurs du projet résolvent des problèmes rencontrés par de
nombreuses équipes agiles. C’est aussi faire le lien entre les tests unitaires du code et les tests fonctionnels des
utilisateurs !
La technique BDD vous vous permet de rendre le dialogue avec les experts plus clair et moins contraignant.
Appliquez notamment le principe des cinq pourquoi à chacune de vos user stories. Vous rendrez aussi vos
documentations (fonctionnelles et techniques) plus lisibles avec Cucumber (par exemple).
4.9 Conclusion :
Les méthodes agiles ont désormais fait leurs preuves, aussi bien sur des projets aux délais très serrés que sur des projets
d'enjeux stratégiques. Ces méthodologies ont fait l'objet de différentes formalisations, adaptées à différents concepts,
l'un des plus répandus étant certainement SCRUM. Même les méthodologies visant les grands projets, comme RUP
(Rational Unified Process), y ont puisé largement.


Toutefois, les méthodes agiles bien que répondant à une demande et à des besoins réels, ont besoin d’une meilleure
normalisation, et d’encore un peu plus d’éléments d’assurance qualité.
Le mouvement agile va certainement apporter quelque chose aux entreprises. Cependant, sans en comprendre les
principes fondamentaux, on ne peut avoir de gain sérieux.
Pour mener à bien votre projet avec plusieurs équipes Agiles, selon [WWWOpenTDD99] :
• Choisissez une ou plusieurs techniques de pilotage pour orienter votre gestion de projet agile avec différentes
équipes de développement.
• Vous suivez les étapes, les pratiques et les phases de ces techniques en fonction de vos moyens (techniques,
humains, financiers, etc.).
• En tant que facilitateur agile, vous pouvez utiliser ces 3 techniques pour affiner les critères d’acceptation,
préciser les fonctionnalités et clarifier les objectifs de vos user stories.
• Les techniques TDD, BDD et FDD complètent les principales méthodes agiles.
Avec la grande percée de l’Intélligence Artificielle (IA), l’agilioté va davantage grandir et ouvrir d’autres perspectives.


5 Ingénierie basée sur les Modèles
5.1 MDE : Model Driven Engineering
La maîtrise d'un projet informatique peut nécessiter un savoir de plus en plus vaste dans différents domaines
(logiciels, langage(s), codes, Automates Programmables Industriels (API) …
Nous allons présenter le Développement Orienté Modèle (MDD - Model Driven Development), tel qu’il est spécifié par
l’OMG (Object Management Group). Ces spécifications sont regroupées sous le concept de MDA (Model Driven
Archtecture), et mettent à disposition de nombreux outils conceptuels.
5.1.1 Évolutions
L’OMG (Object Management Group) est un consortium développant et promouvant la théorie et la pratique des
« systèmes ouverts » (objets répartis…). Il est constitué de plus de 1000 structures membres. Il a proposé dès le début
des années 90, l’architecture OMA (Object Management Architecture), qui comprend des produit et
standards/documents qui définissent les mécanismes d’interopérabilité, de distribution et de communication dans un
réseau. Par la suite, les standards de réalisation ont suivi : CORBA (Common Object Request Brokers Architecture),
UML (Unified Modeling Language), MOF (Meta Object Facilities) et XMI (XML Metadata Interchange).
MDA (Model Driven Architecture) est une extension de OMA pour faire évoluer et généraliser cette interopérabilité le
long de tout le cycle (conception, déploiement, maintenance).
L’idée principale ici est d’arriver à la séparation entre les « spécifications des fonctionnalités » et la « caractérisation
de ces fonctionnalités » pour une plateforme spécifique.
5.1.2 Concepts de base

Modèles : ils représentent une partie d’une fonction, de structure ou de comportement d’un système. Ils sont
composés d’une syntaxe (forme définie) et d’une sémantique (signification). On distingue les modèles indépendants de
la plate-forme (PIM, Platform Independant Model) et les modèles dépendants de la plateforme (PSM, Platform Specific
Model).
Abstraction : représente le fait de supprimer les détails non pertinents d’un modèle. Le rafinement consiste à
introduire dans un modèle abstrait quelques éléments de réalisation de cette abstraction. Un modèle est toujours
construit selon une vue particulière du systèeme.
Plateforme : elle est constituée des détails technologiques non pertinents pour les fonctionnalités d’un composant
logiciel.
5.1.3 MDE et le génie logiciel

On a failli assister à une « Mort » des logiciels due à de multiples difficultés au cours des évolutions :
● Ajouts de fonctionnalités,
● Correction de bugs,
● Trop de rustines (« bug patch » - correctifs),
● Applications peu cohérentes, sans spécifications formelles,
● Blocages face aux nombreux codes peu compréhensibles
● Difficultés face à l’évolutivité.
Ces difficultés ont amené à proposer le concept de "modèle" :

● Modèles plus aptes
● Visibilité bonne
● Donc compréhension aisée
MDE est-il un moyen d'éviter la « mort » des logiciels ?

Nous présentons ci-dessous, l’évolution d’approches du génie logiciel vers l’ingénierie des modèles.
Figure 59. Evolution des approches du Génie Logiciel sur le plan historique

Cette évolution tient compte de nombreux besoins et contraintes :


● Au niveau du contrôle de la conception
- Le niveau code entraîne des difficultés
- Les Modèles facilitent le développement, tout en donnat une meilleure visibilité. Il existe aussi une possibilité
de validation formelle sur les modèles. Ex : langage OCL (Object constraint language)
● Au niveau de l’évolution
- Visibilité de l'application
- Visibilité des modifications
- Modèles génériques
- Modèles réutilisables
● Au niveau du cycle de vie
- Prototypage rapide
- Concentration sur l’essentiel
- Conception globale
- Conception unitaire
- Développement minimal
- Evolution facilitée
Cycle de vie
Analyse
Recette
Conception
Globale Tests
D’intégration
Conception
Unitaire Tests
Unitaire
Développement
Figure 60. Rappel du Cycle de vie de développement
● Au niveau de la modélisation
- Diagrammes de classes
- Abstraction
- Fonctionnalités, systèmes, etc.
- Classes du programme final
- Intégration des « design patterns »
5.1.4 MDE et UML

Les objectifs de MDE (Model Driven Engineering), dont MDA est une spécification particulière, sont triples :
1. Séparation de descriptions fonctionnelles et de l’implémentation,
2. Identification, expression précise, séparation et combinaison des différents aspects d’un système (à l’aide d’un
langage spécifique de domaine),
3. Relation entre ces langages de domaines dans un « framework » global.
L’idée de MDE c’est de concevoir un paradigme palliant aux insuffisances du paradigme Objet, qui s’est imposé en
génie logiciel depuis les années 1980. Ce paradigme n’est pas amené à remplacer l’approche Objet, mais à la compléter.
• L’approche UML et le développement Objet considèrent que « Tout est Objet ». Les relations
fondamentales qui y sont mises en oeuvre sont : l’héritage (d’une super-classe par une classe simple) et
l’instanciation (d’une classe par un objet).
- Modélisation
- Représentation des classes, etc.
- Possibilité de génération de code
- Vision statique
• L’approche MDE considère elle que « Tout est modèle ». Les relations fondamentales sont la représentation
(du système par le modèle), et la conformité (du modèle à un méta-modèle). Ses principes sont les suivants :

- Méta-modélisation

- Représentation de l'application
- A différents niveaux d'abstraction : système, fonction, classe
- Dissociation des aspects indépendants
- Interaction utilisateur-système, architecture, plate-forme, etc
- Possibilité de :
- Manipulation de modèles
- Transformation de modèles
- Fusion de modèles
- Et génération de code
La figure suivante schématise ces deux approches : Classes et Modèles
Figure 61. Comparaison des approches Classes et Modèles
● Le concept de « Méta », soudjaçant au terme metamodèle.

● Méta = sur, à propos de, autour
● Méta-modèle = autour des modèles
● Méta-modélisation = modélisation + manipulation des modèles
● La méta-programmation
● Manipulation du programme
- Au niveau code
- Interface de manipulation (autorisant l’ajout de méthodes, d'attributs)
● Avant la métamodélisation, cette étape préalable s’appuie sur une interface de base pour réaliser le
métaprogramme.
Programme de base
Interface de base Méta programme
Implémentation
Meta-interface
Figure 62. La méta-programmation
5.1.5 Supports de la technologie MDE

. MDE englobe toute cette nouvelle approche d’ingénierie dont la conception d’ensemble est orientée modèles.
Les Spécifications de MDE s’appuient sur :
- la technologie MDA
- les autres technologies connexes :
o UML, largement utilisé, qui permet une mise en oeuvre aisée de MDA en offrant un support connu,
o XMI, XML Metadata Interchange, qui propose un formalisme de structuration des documents XML
de telle sorte qu'ils permettent de représenter des méta-données d'application de manière compatible,

o

MOF, Metadata Object Facility, spécification qui permet le stockage, l'accès, la manipulation, la
modification, de méta-données,
o CWM (Common Warehouse Metamodel), base de données pour méta-données.
L’intérêt de MDE c’est d’aider les utilisateurs à résoudre les problèmes d’intégration en fournissant des spécifications
d’interopérabilité ouvertes et indépendantes des vendeurs. Quelques avantages que retirent les entreprises sur MDE :
• le fait qu'une architecture basée sur MDA est prête pour les évolutions technologiques.
• la plus grande facilité d'intégration des applications et des systèmes autour d'une architecture partagée.
• une interopérabilité plus large permettant de ne pas être lié à une plate-forme.
5.1.5.1 Eléments de MDA

Durant l’évolution des technologies Objet, une tendance forte à été l’uniformisation des langages, mais un certain
nombre de caractéristiques n’ont pas été incorporées aux langages :
– Relations entre les classes patrons (Design Pattern),
– Aspects,
– Présence sur le Web,
– Relation des objets aux bases de données,
– Relation des objets aux processus.
MDA a pour objectif de formaliser les efforts qui avaient été réalisés jusque là en matière de « Bonnes Pratiques » de
développement, et donc pour permettre de mieux prendre en compte ces caractéristiques des logiciels.
MDA doit permettre de représenter tout élément d’une application comme un modèle : les programmes, les traces, les
plate-formes, les transformations, les méta-modèles, les vérifications, les composants, etc. Tous ces éléments doivent
être disponibles au niveau technologique, pour assurer le succès de MDA.
MDA n’est donc pas une révolution dans les solutions qu’il propose, mais un moyen de formaliser et de rendre
accessible à une large communauté de développement les Bonnes Pratiques du génie logiciel.
MDA est au cœur de la stratégie de l’OMG pour réaliser, faire évoluer et maintenir les systèmes informatiques. MDA se
base sur la technique de séparation des préoccupations. Ceci ouvre de nouvelles perspectives.
L’idée est de séparer les aspects business des aspects techniques en utilisant les modèles. Le standard central du MDA
est basé sur le « Process » et les « Composant ». Il permet de construire des PIM ; et sert en même temps de base à la
génération de PSM.
5.1.5.2 Les éléments de MDA

Ils sont présentés dans la figure suivante
Finance
E-commerce
Manufacturing
UML
Model Driven
Space Telecom
Architecture
Figure 51 : Eléments de MDA
Transportation Healthcare
More….
Figure 63. Quelques uns des éléments de MDA


Les modèles créés (PIM) sont associés à des modèles de plate-forme (PM), et transformés, pour obtenir un modèle
d'application spécifique à la pate-forme (PSM).
En général, la réalisation de modèles spécifiques de domaines consiste à créer un « langage » permettant de mieux
appréhender un problème. A ce niveau, on peut distinguer deux approches :
- Création de toutes pièces d’un langage conforme aux spécifications MOF
- Création d’un profil UML particulier (Un profil, proposition d’une communauté, regroupe un ensemble d’éléments
(composants, stéréotypes, icônes, propriétés…) qui s’appliquent à un contexte particulier tout en conservant le métamodèle
d’UML intact.).
Il faut noter que l’intégration de MDA dans l’industrie logicielle exige forcément d’adopter une nouvelle logique
économique.
La mise en place d’Usines Logicielles, telle que envisagée, s’accompagnerait d’une modularisation possible des
logiciels, qui sont disponibles non plus en tant qu’entités monobloc, mais en tant qu’ensemble de composants
assemblables, éventuellement proposés par des entreprises différentes.
• Les Chalenges :
- Définition précise de la frontière entre PIM et PSM
- Méthodologie MDA (stratégique)
- Explicitation des transformations (UML vers EJB, UML vers WS, …)
On retrouve deux types de transformations : « modèle à modèle », et « modèles à code »
- Outillage
• XMI
XMI est un format standard de représentation de modèles (UML). Il est basé sur XML. Ce format est utilisé
par les éditeurs UML pour réaliser les imports / exports de modèles d'un outil vers un autre outil.
L'OMG n'a pas jugé utile de standardiser un processus associé à ces outils. Leur rôle est de répondre aux besoins des
utilisateurs de manière générique, et non de proposer de solutions définitives pour certains types d'applications précises.
Un processus de génie logiciel exploitant les possibilités de MDA a cependant été proposé : le « Model-Driven
Software Development » - MDSD ([wwwMDA06]).
5.1.5.3 Exigences de MDE

MDE exige plusieurs principes :
- séparation entre la Description de l'application et la Description du contexte technique (architecture et
plateforme),
- Réunion des modèles et/ou transformations,
- Génération de code.
L’idée de base de MDE est la suivante : penser l'application au niveau du modèle et laisser le soin de l'implémentation
aux outils. Ce paradigme est omniprésent en informatique : les langages nous ont affranchi des processeurs et ils nous
affranchissent maintenant des systèmes d'exploitation. L'interopérabilité prend ainsi de la hauteur.
MDE préconise l'interopérabilité au niveau des modèles. Il s'agit d'avoir la possibilité d'écrire et de faire évoluer le
modèle en fonction de l'organisation à la vitesse requise par l'organisation et non plus par les plateformes.
- Au niveau de l'organisation, on parle de PIM ;
- Au niveau des plate-formes, de PSM.
Une application complète de MDA se composera donc d'un PIM et d'un ou de plusieurs PSM.
A titre d’exemple, on retrouve à un niveau d'abstraction supérieur la démarche qui avec le même langage Delphi permet
d'obtenir par la CLX (Component Library X(cross)-Platform, - "Bibliothèque de composants multi-plateformes") un
exécutable qui pourra faire appel aux API (Application Programming Interface) Windows ou à Linux, avec le même
source.
Le langage de choix dans lequel écrire le MDA est UML. C'est en effet un standard depuis son adoption par l'OMG en
1997. L'application sera ensuite implémentée sur un large éventail de systèmes : des ordinateurs de bureau aux serveurs
ou aux mainframes, et au travers d'Internet. Les PSM peuvent communiquer entre eux en faisant intervenir plusieurs
plateformes qui ont à échanger des données : le développement de CORBA continuera d'être favorisé par l'OMG dans
ce sens. La demande croissante des utilisateurs en temps réel, en système embarqué, en système tolérant et en systèmes
d'entreprises va accélérer le rythme de standardisation de CORBA. Les services de CORBA permettront de
synchroniser rapidement quatre services dominants identifiés par l'OMG dans le MDA :
• Services d'annuaire,
• Services de Transaction,
• Services de sécurité,
• Services distribués d'événement et d'avis,
• Etc.


« .NET » et « ONE » sont des plate-formes au-dessus desquelles se place l'architecture conduite par le modèle MDA.
Cette approche globale de haut niveau présente beaucoup d'avantages par rapport aux approches spécifiques. En effet, le
partage d'une logique commune au sein d'une industrie réduit d'emblée les nombreux problèmes d'interconnexion de
systèmes qu'ont fait surgir au fil du temps les particularismes développés sans concertations. MDA est l'outil qui permet
à une industrie de décrire ses fonctions indépendamment des implémentations. Cette approche contribue à l'émergence
de normes en offrant une lisibilité que peuvent partager une masse critique d'entreprises.
En termes de produits, MDA est implémenté dans un outil qui intègre la modélisation et le développement. Il gère des
classes servant les objets métiers, leur présentation et leur persistance.
• MDA : PIM vers PSM [wwwMDASup]

PIM: Plateform Independent Model
PSM: Plateform Specific Model
Modélisation : Modélisation :
Spécifications Description de
PIM
Domaine et Plate-forme
Scenarii
PIM PM
PSM
PSM
CODE
Programme
Figure 64. ·MDA : PIM vers PSM / programme
5.1.5.4 Description des deux catégories de transformations

• Les transformations « modèle à modèle »
Elles sont indispensables en cas de grande distance conceptuelle entre le PIM (indépendant de la plateforme) et le
PSM (spécifique à la plate-forme). Elles peuvent être réalisées :
– par manipulation directe (implémentation et ordonnancement des règles par l’utilisateur),
– de manière relationelle (basé sur des concepts mathématiques, des règles de mapping),
– orienté transformation de graphe,
– orienté structure (2 phases, création de la structure de la cible, et complément avec les attributs et les
références),
– hybride, association de plusieurs des catégories précédentes.
• Les transformations « modèle à code »
Les transformations modèle à code sont de types « visitor-based » (mécanisme qui traverse la représentation du
modèle), ou « template-based » (texte cible contenant du métacode pour accéder aux informations de la source).
Apport de transformations : classification des transformations, identification de leurs caractéristiques.
Contraintes à prendre en compte lors des transformations : mise en évidence du manque de maturité des
transformations.
5.1.6 MDE et les « Design Patterns »

• Le patron logiciel : Le schéma logiciel, associé à des processus de capture et d’exploitation des informations
décrites et à des outils pour automatiser ce processus, forment le patron logiciel (patern).
• L’usine logicielle : Le patron logiciel, intégré à un Environnement de Développement Intégré (IDE), forme
une usine logicielle. L’usine logicielle et l’ensemble de ses composants met à disposition du développeur un
cadre de travail performant, peu cher, et surtout, offre tous les outils nécessaires à un développement rapide de
nouvelles applications.
Apport de patron : grille d’analyse et identification d’éléments indispensable à l’automatisation d’un processus
MDA.
Contraintes à prendre en compte : Le contenu de la grille doit être réalisé à la main, lors de la création de l’usine
logicielle. La productivité n’est atteinte que lorsque que cette étape préliminaire est achevée.


L’intégration des Design Patterns (patron) dans MDE est effective.
● Manipulation simple des modèles
- Réutilisation
- Modifications
- Facilitation de la modélisation
5.1.7 Processus de modification MDE

● Modification des modèles
Elle s’opère grace à leur description précise :
- Langage de domaine
- Formalisé
● Les transformations possibles sont présentées à la figure ci-dessous.
[Parrend07]
Figure 65. Les Transformations MDE
5.1.7.1 Langages de modèles

Les méta-modèles sont exprimés couramment sous format XMI. Ils peuvent représenter un langage connu, par
exemple Java ou UML. Ils peuvent également être conçus spécifiquement pour un domaine d'application donné.
Deux approches existent pour créer un langage de méta-modèle :
• MOF : On crée à partir de rien un langage nouveau, en respectant les spécifications du MOF (Meta Object
Facility),
• UML : On crée une extension d'UML, à l'aide de stéréotypes, de contraintes (langage OCL). ta-modèles
On définit quatre niveaux de méta-modèles :

- le niveau zéro est l'implémentation du programme,
- le niveau 1 est le modèle du programme (classes)
- le niveau 2 est le méta-modèle du programme, c'est à dire le langage
- le niveau 3 est le méta-modèle des méta-modèles, ou méta-méta-modèle, c'est à dire la définition d'un méta-
modèle. Il s'agit donc de la spécification MOF.
● Architecture [Parrend07]
M3 Méta-méta model (MOF)

Linguistic instanciation
M2 Méta modèle (UML, CWM)

XMI
M1 Models (UML classes, Objects)
Real-world things, Represented By

M0 program execution
Conformant To
Ontological instanciation
Figure 66. Architecture du métamodèle MDA


5.1.7.2 Étapes de développement MDA
Plusleurs phases et transformations sont définies pour un processus MDA :
- Proceder à la modélisation (normalement en UML) : des modèles manipulables sont générés (au format XMI),
en partant des diagrammes de classes UML.
- Proceder aux transformations intermédiaires.
On devra progréssivement préciser ici ce que sera l’application en terme de format de données et réalisation de
fonctionnalités. On pourra donc transformer les métamodèles initiaux (indicant les contraintes que doit respecter
l’application) en modèles fonctionnels cibles dotés de services particuliers.
- Proceder à la génération de code.
En ce qui concerne le stockage et l'accès à des modèles, MOF permettra de définir des bases de données de
modèles accessibles de manière transparente par les applications.
● Les transformations s’opèrent à la chaîne
Modélisation
Modèle Transformation Génération

de code
Modèle Modèle Programme

Modèle
Intégration Stockage
Accès
MOF
[Parrend07]
Figure 67. Chaîne de transformations : processus
Plusieurs outils peuvent êre mis en jeu durant le processus :
● Plateforme Eclipse: incluant Eclipse, EMF (Eclipse Modeling Framework), SDO (Service Data Objects) et
XSD (XML Schema infoset model Data).
SDO permet d'unifier l'accès à des données hétérogènes, par exemple stockés sous forme XML, en Base de
Données Relationnelles, dans des Services Web, par les applications. XSD est une librairie qui permet de
manipuler, créer et modifier des schémas XML.
Pour créer un modèle EMF (au format « Ecore »), plusieurs formats de fichiers sont supportés :
1 Java Annoté,
2 XML Schéma,
3 Format Rational Rose.
Voici les opérations lors du processus pour un développement incrémental :

1. La première étape consiste à créer un modèle UML.
2. Ce diagramme UML doit être traduit en Java annoté pour être compris par Eclipse.
3. Ensuite, un modèle de type MOF est généré, à partir de Java Annoté. Le format « eCore » est l'implémentation
Eclipse de la spécification MOF.
4. Le modèle existant peut être enrichi.
5. Le code java est généré à partir des objets eCore enrichis.
6. Une fois les classes générées, il est souvent indispensable d'implémenter les fonctionnalités de ces classes.
Les méthodes et variables peuvent être complétées, mais le modèle lui-même ne peut pas être modifié (afin de
permettre la regénération de code sans perte de données).
7. Si l'on a besoin de regénérer le code - souvent après avoir enrichi le modèle - les ajouts manuels sont conservés.
● Plateforme Poseidon
Nous listons ci-dessous les différentes transformations réalisées dans un processus intégrant l’outil Poseidon :

* Création de modèles UML,

* Ajout des commentaires Javadoc dans le modèle UML,
* Sauvegarde de votre modèle,
* Exportation en tant que Classe Java (les diagrammes de classes sont exportés, les autres existent uniquement à
des fins de documentation),
* Exportation sous format XMI,
* Exportation en tant que graphique (si besoin),
* Lancement de la plate-forme Eclipse, et importation du fichier XMI créé.
* Réalisation de programme exécutable
UMl
Modélisation :
Java Annoté
EMF
EMF
ECORE Modèle EMF
E
Programme
ATL
XMI Modèle
JMI
Poséidon
MDR
MOF
Modélisation
Graphique
UMl Poséidon
Légende : formats de données sur le schéma

1 UML, représentation des modèles de manière graphique, avec exploitation directe (Poséidon), ou après traduction en Java annoté (EMF),
2 XMI, format standard défini par l'OMG, tous les modèles sont disponibles en format XMI, mais la représentation sous forme de fichier texte fait que, pour
la manipulation, les formats graphiques UML et les modèles Ecore d'EMF sont préférés,
3 Ecore, c'est l'implémentation de MOF par Eclipse. La création de modèles est possible à partir de nombreux formats (Java Annoté, XML schema,
Rational Rose, etc.), l'enrichissement est possible de manière simple par la représentation hiérarchique des modèles. Un langage de transformation de
modèles peut également être défini.
4 MDR, Meta Data Repository, c'est l'implémentation d'une base de données pour modèles compatibles MOF (de Sun). Elle fait partie de l'outil NetBeans
Figure 68. Quelques outils dans la chaîne de transformations
5.1.8 Méthodologie globale de réalisation d’applications

Au niveau du processus de développement, MDE doit apporter des gains de productivité et des gains de prédictibilité
[Greenfield03]. Pour exploiter au maximum ces possibilités, il est indispensable de systématiser les méthodes de
développement logiciel, et donc de les industrialiser : c’est ce qui est appelé ici « l’usine logicielle ».
L'usine logicielle comprend :
● IDE (Environnement de Développement Intégré) et outils
● Patron logiciel, lui-même composé de
- Outils de manipulations
- Schéma logiciel, comprenant :
o Langage de descriptions de modèles
 Domaine, Services, Technologies, Données
 Niveaux : Concepts, logiques, implémentation
o Transformations entre ces langages


Figure 69. Exemple de schéma de support du processus MDE
Le processus complet est présenté à la figure ci-dessous
Spécifications Génération
CIM PM
De code
Intégration Programme
PSM
M
Description de
PM Stockage
plate-forme
Accès
MOF
Figure 70. Processus complet MDE
Nous présentons ci-dessous, une méthode de développement d'applications correspondante. Elle a pour vocation
d'améliorer la productivité, c'est à dire le temps de création de la première version de l'application, de même que
l'évolutivité, c'est à dire la possibilité d'améliorer et d'étendre cette application.
On distinguera deux approches :

[Parrend07]
- une approche linéaire, exploitable pour des petites applications ou des sous-systèmes,
- une approche incrémentale, pour mettre en oeuvre des applications de plus grandes dimensions.
5.1.8.1 Approche linéaire

Phase de spécifications
- choix des principes de l'application (et donc des modèles),
- adaptation de ces modèles,
- validation de l'architecture au niveau fonctionnel.
Phase de design
- raffinement automatique (intégration de modèles existants),
- raffinement manuel.
Phase d'implémentation
- génération de code pour la plate-forme-cible,
- complétion du code généré,
- intégration d'outils pré-existants.

Phase de validation

- bon fonctionnement de l'application,
- validation des spécifications.
5.1.8.2 Approche incrémentale

Cette approche met en évidence la puissance de MDA. L'évolution permanente du logiciel est intégrée dans la
méthodologie de développement, ce qui a deux avantages principaux :
+) lors de la première réalisation d'une application, des versions fonctionnelles intermédiaires sont disponibles, ce qui
permet d'accélérer la mise en production - éventuellement d'une version incomplète, préférable à un retard pur et simple,
+) lors de l'évolution d'une application, la méthodologie est conservée, et la validation est donc facilitée.
* Prototype
Réalisation d'une architecture comportant les fonctionnalités minimales (IHM et fonctionnalités clés) selon la
méthode linéaire.
* Architecture complète
Intégration des différents principes de fonctionnement : type de client (lourd/léger), support de mobilité, etc., selon
la méthode linéaire.
On obtient un squelette d'application, comportant tous les éléments, mais sans implémentation.
* Mise en place des fonctionnalités
Compléter chaque fonctionnalité l'une après l'autre, selon la méthode linéaire.
* Récursivité
Les étapes 2, 3 peuvent être réalisées par suite d'affinements successifs. Chaque affinement doit permettre de
nouveaux types d'usage (extension des fonctionnalités), les version intermédiaires doivent être exploitables.
* Validation de la version finale
* Evolutions
Elles peuvent se faire selon le même principe que les affinements succesifs ayant conduit à la version complète du
produit.
5.1.9 Perspectives de développement

5.1.9.1 Les Mégamodèles
MDA effectue un glissement des abstractions utilisées comme unité de base du développement logiciel de l’objet vers le
modèle. Son objectif est de préciser comment définir des modèles, leur expression, et leurs transformations.
Cependant, aucune spécification n’est prévue pour le maintien de lien entre modèles. Nous l’avons vu avec les
nouveaux processus de développement proposés par [Greenfield03], un modèle ne permet un gain de performance que
dans un schéma où il est en liaison avec un ensemble d’autres modèles.
[Bezivin04] propose, pour palier à cette lacune, l’introduction de « mégamodele », qui supportent non seulement le
stockage et la capitalisation des savoirs, comme les Bases de données MOF (MOF Repositories), mais également
l’extension de ces modèles par des liens. Il devient alors possible d’avoir une vision macroscopique des modèles, et non
plus d’en avoir une juxtaposition.
Les informations utiles concernant un méta-modèle sont, entre autres :
– lieu où se trouve sa définition originale,
– définitions alternatives,
– auteurs,
– histoire,
– versions suivantes et précédentes,
– PSM existants s’il s’agit d’un PIM.
Les éléments du méga-modèle sont :
1. les modèles, méta-modèles et méta-métamodèles,
2. les services,
3. les outils.
L’introduction de ces informations vise à une meilleure interopérabilité entre les outils, et donc les phases de
conception. L’implémentation peut avoir lieu sous forme de « bus logiciel », ou dans un réseau pair-à-pair.
La principale approche concurrente est KDM (Knowledge Discovery Metamodel), de l’OMG.
La capitalisation des modèles, et leur exploitation performante suppose une vision macroscopique des éléments
disponibles. L’approche Méga-modèle semble très prometteuse, mais aucune implémentation n’est disponible librement
actuellement.
Comme intérêt, on peut noter la capitalisation des modèles et de leurs liens avec les autres éléments mis en oeuvre dans
le processus de développement.

5.1.9.2
La Modularisation des Applications


La formalisation des processus de développement rend possible la création d’usines logicielles, nous l’avons vu dans la
partie correspondante. Cette évolution peut entrer dans un cadre beaucoup plus vaste, qui modifierait les méthodes
utilisées dans les entreprises, et offrirait la possibilité de rendre les applications modulaires, et par conséquent leur
génération.
[Greenfield03] propose de s’inspirer des processus de l’industrie traditionnelle :
– assemblage de composants standards
– produits finaux similaires mais distincts
– standardisation
– intégration
– automatisation
– chaine logistique distribuant le risque et les coûts dans un réseau de fournisseurs spécialisés et interdépendants
Une telle organisation doit permettre un fort gain par économie d’échelle. Au niveau du développement logiciel, elle se
traduit par une application systématique de MDA, et un enregistrement systématique des connaissances quand à une
famille de produits. Ces connaissances sont mises à disposition sous forme de « pattern », de « framework », de
« modèles », et « d’outils ».
Le développement doit ainsi être axé vers la connaissance du domaine d’application, plus que vers la connaissance de la
plate-forme cible. La présence d’usines logicielles, qui permettent un développement peu onéreux, offre la possibilité de
mise en place de véritables chaines de production de logiciels. Ces chaines de production sont composées de plusieurs
usines indépendantes, effectuant chacune une partie du processus, fournissant les composants ou les intégrant. Cette
modularisation extrême, où tout service peut être disponible indépendamment des autres, doit offrir de forts gains de
productivité et une forte variabilité des applications finales.
Il s’agit d’une vision qui ouvre des perspectives méthodologiques immédiates. Comme intérêt, cette Méthodologie de
conception logicielle est innovante.
5.1.10 Conclusion sur MDA

De nombreux outils sont disponibles pour la manipulation de modèles, et progressivement, des modèles existent pour
les principaux domaines d’application de MDA. Pour les domaines connexes, il est possible de créer des langages
spécifiques de domaines relativement facilement.
Cependant, l’aspect de réutilisation, de capitalisation et de mise à disposition des modèles - c’est à dire à un passage, de
fait, à un niveau d’abstraction supérieur - reste mal aisé. [Bezivin04] propose un framework de gestion des modèles et
de leurs relations, basé sur les Mégamodèles.
L’intégration de MDA dans l’industrie logicielle rend possible, voire nécessaire, l’adoption de nouvelles logiques
économiques. La mise en place d’usines logicielles, présentées plus haut, s’accompagne d’une modularisation possible
des logiciels, qui sont disponibles non plus en tant qu’entités monobloc, mais en tant qu’ensemble de composants
assemblables, éventuellement proposés par des entreprises différentes. Cette modification dans la conception même du
logiciel permet l’apparition de « chaîne de fournisseurs », et donc d’améliorer la productivité et la compétitivité d’une
industrie encore peu mature [Greenfield03].


5.2 Systèmes basés sur les modèles : conception architecturale avec la méthode ARCADIA
5.2.1 Présentation de Arcadia
ARCADIA (Architecture Analysis & Design Integrated Approach) est une approche intégrée d'analyse
d'architecture et de conception, très adaptée à la conception des systèmes complexes, des systèmes critiques, pouvant
nécessiter des multiples et fortes contraintes fonctionnelles et non fonctionnelles. Ceci inclut par exemple des
architectures logicielles hétérogènes, des achitectures d’objets connectés, des architectures électroniques ou électriques,
des processus industriels, etc. cette méthode est adaptable aux processus et contraintes liées à de multiples cycles de vie
de développement, couvrant les approche descendantes, ascendante, la réutilisation d'applicatifs, les approches
incrémentales, itératives, etc.
Cette méthode d'ingénierie est basée sur des modèles pour la conception architecturale (matériels, logiciels et
systèmes en général). Elle a été développée par la société Thales (groupe d'électronique spécialisé dans l'aérospatiale,
la défense, la sécurité et le transport terrestre dont le siège social se situe dans le quartier de La Défense à Paris) entre
2005 et 2010 (précisement en 2007), pour répondre au besoin de plus en plus réccurent de placer l'architecture et la
collaboration au centre de l'ingénierie des systèmes. Au départ, elle s’est appuyée sur un processus itératif associant des
architectes opérationnels de tous les domaines d’activité de Thales.
Les fondements d’Arcadia permettent de favoriser :
- Une collaboration efficiente en éliminant les barrières entre les branches de et orientations de l’ingénierie :
Architectes, Développeurs, Experts, Équipes IVVQ (Intégration – Vérification – Validation – Qualification),
Client, Partenaires externes, etc.
- Une distinction claire entre besoin et solution et préconise une approche fondée sur les points de vue (telle que
décrite dans l'ISO / CEI 42010) ;
- Des modèles prenant en charge la collaboration et la co-ingénierie à l'échelle de l'entreprise ;
- Une conception architecturale sur mesure ;
- Une gestion de la complexité et de la taille (montée en charge) ;
- Testé sur le terrain dans des situations industrielles réelles ;
- Des possibilités d’extensions, en cas d’ouverture à la valeur ajoutée spécifique au domaine ;
- Une Adaptabilité à plusieurs cycles de vie et systèmes de travail partagé.
Arcadia met en œuvre des concepts qui restent tout à fait compatibles avec les autres langages d'architecture à
l’instar de DODAF / NAF Architecture Frameworks (Department of Defense Architecture Framework / NATO
Architecture Framework, Architecture Framework éditée par l’OTAN), UML2 (Unified Modeling Language), SysML
(Systems Modeling Language), AADL (Architecture Analysis and Design Language), etc.
ARCADIA recommande trois types d’activités ayant le même niveau d'importance, mais obligatoires :
- Analyse des besoins et modélisation
- Construction et validation d'architecture
- Ingénierie des besoins
La figure ci-dessous schématise la place des trois activités dans le cycle de vie global utilisé.
Figure 71 Activités du cycle de vie global utilisé [ArcadiaCapella18]

La figure précédente montre bien que l’approche peut se décliner en :
- Démarche itérative ou incrémentale
- Démarche descendante ou ascendante (remontante)
- Etc.


La démarche permet des activités ordonnacées ou parallèles. Elle permet également une construction progressive et
focalisée de l’architecture. L’autre point fort d’ARCADIA c’est la capacityé d’ajustement des activités et adaptation à
un domaine particulier.
5.2.2 Phases de la démarche de modélisation

Les étapes sont résumées dans la figure ci-dessous.
Figure 72 Schématisation des interactions entre des phases d’une modélisation Arcadia [ArcadiaCapella18]
5.2.2.1 Analyse Opérationnelle (besoins utilisateurs)
Définit les acteurs et leurs activités opérationnelles (ce qu’ils doivent accomplir comme activités, leurs interactions
avec le système et entre eux).
5.2.2.2 Analyse du Besoin Système

Décrire ce fait le système pour répondre effectivement aux besoins opérationnels. Ceci permet, après analyse
fonctionnelle externe, de bien identifier les modules/procédures fonctionnels que le système doit réaliser pour les
utilisateurs. On devra tenir compte des propriétés non fonctionnelles exigées à ce niveau.
5.2.2.3 Architecture Logique (solution notionnelle)
Comment fonctionne le système indépendamment de toute implémentation physique. Ceci permet, après une
analyse fonctionnelle interne, d’identifier les séquences d’activités, fonctions ou sous-fonctions qui interagissent pour
pour réaliser les procédures fonctionnelles recensées à l’étape précédente, mais en tenant compte des contraintes
non-fonctionnelles traitables à ce niveau.
5.2.2.4 Architecture Physique (solution finale)
Il décrit comment est composé le système physique qui est conctruit. A ce niveau, on opère les choix techniques en
itégrant toutes les contraintes liées à l’implémentation. Les composant softwares ou hardwares qui implémentent les
différents modules recensés et tient compte des contraintes et limites des ressources matérielles.
5.2.2.5 "End-Product Breakdown Structure" (EPBS) et Contrats d'Intégration dans les scenarios fonctionnels
Ici, les composants du système en tant que produit utilisable seront définis. On mettra en évidence la stcucture et les
modlités de distribution du produit final.
Il s’agit en fait de valider le processus complet (toutes les phases précédentes), car les conditions à remplir par les
composants physiques identifiés à la phase précédente, seront prises en compte et vérifées à cette phase, afin de garantir
que le client sera satisfait par les modules réalisés.
5.2.3 Mise en œuvre dans Capella

Capella est un outil opensource pour l’ingénierie des systèmes basées sur les modèles (MBSE : Model-Based
Systems Engineering) complet, extensible et déjà bien éprouvé sur le terrain, qui permet de concevoir avec succès une
architecture système, logicielle et matérielle. Cette solution aide les architectes de systèmes à formaliser les
spécifications et à maîtriser la conception architecturale. Elle fournit un processus outillé permettant la modélisation
graphique des architectures systèmes, logicielles ou matérielles, et ce, en conformité avec les principes et


recommandations définis par la méthode Arcadia, une méthodologie basée sur un modèle qui couvre chaque phase
d'ingénierie. Capella est maintenu par le groupe de travail industriel « PolarSys de la Fondation Eclipse ».
Cet outil offre un environnement d'ingénierie proposant une démarche basée sur les modèles plutôt que d’être
centrée documents, une démarche pilotée par un processus, et offrant par construction les moyens d'assurer une co-
ingénierie effective. L’environnement est assez intuitif, ce qui facilite la tâche aux ingénieurs, qui se concentrent sur la
définition de leurs architectures plutôt que sur l'apprentissage et l'exploitation de langages de modélisation tels que
SysML ou encore UML, pour capturer leurs besoins.
Capella offre de nombreuses fonctionnalités, parmi lesquelles un navigateur de méthodologie intégré, rappelant
directement le principe de la méthode ARCADIA à l’utilisateur et fournissant des conseils méthodologiques efficaces.
Ce navigateur d'activité fournit un accès méthodologique à toutes les activités clés de Capella, y compris la création de
tous les diagrammes, niveau par niveau. Capella a eu l’avantage de s’améliorer progressivement dans le temps, en
utilisant des versions antérieures de l’outil sur les projets internes de Thales.
Il contient de nombreuses fonctionnalités efficaces telles que:
- Calcul automatique des simplifications graphiques (par exemple, échanges d’informations entre les fonctions
de niveau inférieur peuvent être automatiquement affichées sur les fonctions de niveau supérieur) ;
- Diagrammes contextuels automatisés : le contenu est mis à jour automatiquement en fonction des éléments
présélectionnés, éléments de modèle et règles sémantiques prédéfinies ;
- Filtres : permettent à l'utilisateur d'afficher des vues simplifiées d'un diagramme en sélectionnant des
options d'affichage et masquer / afficher automatiquement des éléments de modèle spécifiques
Voici les différents modules de base de Capella, groupés dans des différentes zones [wwwCapella18] :
• Navigateur méthodologique : cette zone présente les différentes phases d'ingénierie pour la modélisation d’une
architecture, et des raccourcis pour créer de nouveau diagrammes en lien avec la phase d'ingénierie considérée ; cette
vue permet également de faciliter la « transition » entre phases d'ingénierie, de façon à créer les liens de réalisation entre
phases et les éléments associés ;
• Navigateur sémantique : permet de naviguer aisément dans le modèle : pour tout élément sélectionné dans la
zone « projet » ou sur un diagramme, la zone navigateur sémantique va présenter à l'utilisateur l'ensemble des
références autour de cet élément, c'est-à-dire ses relations de contenance ou de référence ainsi que l'ensemble des
diagrammes dans lequel l'élément est impliqué ;
• Projet : présente une vue arborescente du modèle Capella en cours, et qui contient l'ensemble des éléments
sémantiques et des diagrammes créés par l'utilisateur ;
• Diagramme : présente une vue graphique d'un extrait du modèle et permet d'éditer le modèle en termes de
création, modification, suppression d'éléments, mais aussi de modification de l'organisation ou l'apparence d'éléments
dans le diagramme ;
• Propriétés : affiche l'ensemble des propriétés données pour un élément sélectionné dans le modèle ou dans un
diagramme.


6 Processus de Mise en Oeuvre, Outils et Métriques de Qualité
Nous avons déjà vu au chapitre 1 que dans l’Ingénierie des systèmes logiciels, on retrouve des méthodes et surtout
plusieurs outils servant tout au long du processus de développement.
6.1 Architecture des applications
6.1.1 Architecture en couches

Pour développer une application, on a pris l’habitude de concevoir l’interface utilisateur, puis de rajouter le code qui va
bien sur le clic d’un bouton par exemple. Si l’on est débutant, le premier réflexe que l’on va avoir sera d’insérer le code
d’accès aux données (listes des fournisseurs, produits, clients, etc.) directement sur le clic du bouton. Même si cette
technique fonctionne, elle pourrait vous poser beucoup de difficultés par la suite. Supposez que pour une raison ou une
autre, que la liste des fournisseurs ou des clients ne provienne plus d’une base de données mais plutôt d’un fichier Excel
ou même d’un fichier XML. Ceci vous contraint de revoir tout le code de votre application avant de la redéployer sur
des postes clients. Si à l’inverse vous aviez utilisé le développement en couche, vous n’auriez qu’à modifier la couche
d’accès à la liste de fournisseur ou des clients.
Les applications d'entreprises modernes sont communément basées sur l'utilisation de plusieurs composants, chacun
fournissant une fonctionnalité particulière. Les composants qui fournissent des services similaires sont généralement
regroupés en couches, elles-mêmes organisées en une pile dans laquelle les composants d'une couche donnée utilisent
les services des composants de la couche en-dessous (ou ceux des composants de la même couche).
Une application « en couche » est généralement composée d’au moins 4 couches. Mais on pet très bien ajouter une
couche supplémentaire pour la gestion des classes ou d’objets communs aux autres couches (cas des threads spécialisés,
ou encore des exceptions personnalisées).
Couche de présentation L’Interface Graphique

Composants d’interface utilisateur (GUI, Graphic User Interface)
Composants de comportement
Couche métier Les objets métier

Interfaces de service
Ordonnancement métier (BusinnessObjects)
Composants métier
Couche d’accès aux données La couche d’accès aux

données
Composants d’accès aux données (DAL, Data Access Layer)
Stockage des données La couche métier

(BLL, Business Logic Layer)
Bases de données
Figure 73. Architecture en couches des applications d'entreprise
• La couche de présentation contient les composants qui doivent interagir avec l'utilisateur de l'application, comme
les pages Web, les formulaires, ainsi que tout ce qui régit le comportement de l'interface utilisateur.
• La couche métier intègre les fonctionnalités et les traitements propres à l'application. Les fonctionnalités simples
peuvent être implémentées avec des composants sans états, alors que les transactions complexes et longues peuvent
utiliser des composants d'ordonnancement avec états. Les composants métiers sont généralement dissimulés derrière
une sous-couche d'interface de service qui agit comme une façade afin de dissimuler la complexité de
l'implémentation. Cela participe de ce que l'on appelle communément une architecture orientée par les services (SOA
= « Service-Oriented Architecture »).
• La couche d'accès aux données fournit une interface simple pour accéder aux données et les manipuler. Les
composants de cette couche abstraient la sémantique de la couche de données sous-jacente, permettant ainsi à la
couche métier de se concentrer sur la logique applicative. Chaque composant fournit typiquement des méthodes pour
créer, lire, mettre à jour et effacer (CRUD = « Create, Read, Update, Delete ») des entités de données.


• La couche de stockage des données comprend l'ensemble des sources de données de l'application d'entreprise. Les
deux types les plus communs de sources de données sont les bases de données et les systèmes de fichiers.
Il est important de noter que ces couches ne sont que des regroupements logiques de composants qui constituent une
application. La façon dont ces couches sont matérialisées dans un environnement matériel et logiciel réel peut varier de
façon importante en fonction de plusieurs facteurs. Dans un scénario très simple, toutes ces couches peuvent résider sur
une seule et même machine. Dans un autre un peu plus complexe (mais assez commun), la couche de présentation peut
se trouver par exemple sur la station de travail de l'utilisateur final, les couches métier et d'accès aux données sur un
serveur d'applications, et les bases de données sur un serveur dédié à cet usage.
Avantages de la technique de développement multicouches :

- La maintenance des données est indépendante du support physique de stockage
- La maintenance des traitements est simplifiée
- La gestion des traitements depuis la couche de présentation est facilitée
- Le travail en équipe est optimisé
- La migration d’un environnement graphique à un autre est relativement simple
Lorsque l’on dit que le travail en équipe est optimisé, la raison est simple : alors qu’un des membres de l’équipe
travaille sur la couche d’accès aux données, un autre peut tout à fait travailler sur la couche métier ou sur l’interface
graphique sans perturber le travail de ses collègues. De même, dans le cas de migration (d’interface utilisateur par
exemple), là encore, la tâche est simplifiée. Ainsi, inutile de redévelopper tout ce qui a été fait jusqu’à maintenant : il
vous suffit de modifier l’interface.
6.1.2 Modèle MVC et interfaces graphiques

L’un des éléments qui contribuent le plus massivement au succès des langages événementiels et objets (Java…), c’est la
facilité de mise au point d’interfaces graphiques.
Le modèle MVC est un « design pattern » issu de Smalltalk-80. MVC signifie Model View Controller. Il s’agit d’une
façon d’organiser les différents composants d’un logiciel de façon à faciliter la réutilisation et éviter des problèmes de
conception et d’implémentation. Ce modèle est très générique et ne s’applique pas qu’aux interfaces graphiques, même
si c’est pour la conception d’interfaces graphiques qu’il est le plus utile.
Comme son nom l’indique, ce modèle contient trois composants :
1. Model : la partie « modèle » correspond au coeur de l’application. Elle contient les données que le
programme manipule et gère les changements d’états induits par les opérations sur ces données.
2. View : la partie « vue » correspond à l’interface en sortie présentée à l’utilisateur pour lui donner
connaissance de l’état de la partie « modèle ».
3. Controller : la partie « contrôleur » correspond à l’interface en entrée présentée à l’utilisateur pour interagir
avec la partie « modèle ».
À une même partie « modèle » peuvent être associées plusieurs vues, destinées à plusieurs utilisateurs ou à un seul. À
chaque fois que l’état de la partie « modèle » change, il faut informer du changement chacune des vues concernées par
la modification, afin que celles-ci mettent à jour l’information présentée aux utilisateurs.
De même, chaque action de l’utilisateur doit être transmise par un contrôleur à la partie « modèle » pour donner lieu à
une action sur les données.
La façon la plus propre de gérer ces interactions entre vues, modèle et contrôleur est de notifier tout changement
qui concerne l’un ou l’autre des éléments sous la forme d’un événement. Les différents composants s’abonnent à des
sources d’événements et se voient notifier ceux-ci lorsqu’ils se produisent.
6.2 Place des Outils

Les outils ont un rôle fondamental dans la réalisation d’un processus logiciel. En particulier pour les aspects suivants :
• Spécification des besoins
• Conception des solutions
• Réalisation des solutions (programmation)
• Assurance qualité du logiciel
- spécification de la qualité requise
- spécification des règles de construction
- test et mise au point des programmes et applications
- qualimétrie du logiciel
- gestion de la qualité du logiciel
• Conduite des projets
- Evaluation des charges, coûts et délais
- Planification des tâches
- Suivi et gestion des projets
- Gestion de la documentation

-
Coordination des travaux individuels


• Mise en exploitation des programmes
• Diffusion et gestion des versions
• Gestion dictionnaire de développement
• Gestion des communications inter-outils
• Gestion de l’interface homme-machine
• Gestion des problèmes de télémaintenance en cas de diffusion multiple
• Assistance à la formation des développeurs
Typologie des outils

• éditeurs (de spécification, modèles, maquettes d’écrans ou d’états, structures de fichiers, codes sources,
dossiers de projets)
• générateur (de codes)
• compilateurs de test
• analyseurs
• prototypeurs
• simulateurs
• dictionnaires
• gestionnaires (de besoins des applications, de composants réutilisables, de projet, etc.)
• optimiseurs de performances
• restructurateurs de codes
6.3 Choix de l’outil de développement

Le choix d’un outil de développement répond à plusieurs types d’interrogations.
• Le premier groupe de questions est centré sur une analyse fine du projet à réaliser et sa faisabilité.
- Disposons-nous de ressources techniques et du temps nécessaires en interne ou devons nous passer par un
prestataire extérieur ?
- qui sera le chef de projet et comment se fera le suivi ?
- quelle est la composition de l’équipe opérationnelle envisagée ?
• Le second groupe concerne les spécificités techniques du langage lui même :
- quel est le niveau de portabilité du langage (outils) ?
- permet – il de développer des applications client-serveur ?
- quel sera le support technique offert ?
Suivant l’approche de réalisation de logiciels MDA (Model Driven Architecture), les objectifs des outils sont de
permettre de modéliser un système dans un modèle PIM (Platform Independent Model) en utilisant un langage de
spécifications approprié, puis de pouvoir traduire dans un ou plusieurs PSM (Platform Specific Model) réalisant ainsi
l’implémentation concrète du système. Quand le domaine d’implémentation se cantonne aux bases de données, UML
peut être utilisé comme modèle PIM, alors que SQL le sera au niveau du PSM.
Depuis plusieurs dizaines d’années, la conception des BD était réalisée à l’aide du modèle entité-association. La
notation UML qui s’impose dans bien des domaines de l’informatique s’adapte de mieux en mieux aux bases de
données. Le premier pas a été réalisé par Rational Rose avec son profil UML (UML profile for Data Modeling). Ce
profil permet de décrire des bases de données notamment à l’aide de stéréotypes prédéfinis (Table, RelationalTable,
View, etc.).
6.4 Quelques facteurs caractérisant les langages de développement

• Niveau d'abstraction
o doit être adapté à la tâche ( e.g. C vs Prolog )
langage machine < assembleur < FORTRAN < C < Java
• Simplicité conceptuelle
o nombre et régularité des concepts
o plus le langage est simple, plus c'est facile de le maîtriser (e.g. Lisp vs Scheme)
• Puissance expressive
o supporte plusieurs styles de programmation (e.g. C vs Java)
• Degré de spécialisation
o un langage spécialisé est conçu spécialement pour certaines applications (e.g.
COBOL=administration-gestion, SPSS=statistiques, ICON=texte)
o un langage général (e.g. C, Ada, ML) peut faire n'importe quoi mais avec un peu plus d'effort de
programmation
• Sécurité
o le langage aide-t-il à prévenir les erreurs? (e.g. programmation structurée)

o le langage détecte-t-il les erreurs? à la compilation? à l'exécution? (e.g. C vs Lisp)


• Support de gros projets
o le langage offre-t-il des mécanismes pour aider à la réalisation de gros projets (> 500.000 lignes) ?
o supporte-t-il les modules ? compilation séparée ? (e.g. Pascal vs Ada)
• Environnement de développement1
o existe-t-il des outils de développement adaptés au langage ?
o éditeur avec indentation automatique et coloration syntaxique, compilateur avec messages précis,
débogueur symbolique avec exécution pas-à-pas
• Performance
o compilateur rapide ? exécutable rapide ? (e.g. Ada vs Java)
• Coûts de développement et maintenance
o les programmeurs disponibles maîtrisent-ils le langage ? sont-ils productifs? le langage permet-t-il de
réutiliser et étendre des librairies et programmes existants ?
• Portabilité
o le langage est-il répandu ? Existe-t-il un standard bien établi ? (e.g. C vs C++, Java). Peut-on migrer
facilement d’une plateforme à une autre ?
Note 1: on fait souvent face à des compromis car ces facteurs sont souvent contradictoires (e.g. Java est de haut-
niveau, de haute puissance expressive, sécuritaire et portable, mais pas très performant).
Note 2: parfois il est possible d'écrire un programme en utilisant plus qu'un langage, ce qui permet d'utiliser le
langage le plus approprié pour chaque partie. (Exemple : intégration C->Pascal, Assembleur-> C …)
6.5 Environnement intégré de programmation

Dans un tel environnement, on retrouvera plusieurs outils intégrés (opérant ensemble) autour d’un langage et conçus
pour y opérer vue de fabriquer un programme exploitable. Ces outils peuvent partager plusieurs instances d’objet ou
encore avoir les mêmes types d’interfaces ou de procédures d’utilisation interne ou externe (shell, macros, make, etc.).
Mais ils ne communiquent pas pendant l’exécution. Et ils ne sont parfois pas interopérables avec des outils extérieurs.
Ces environnements intègrent généralement les points forts de la plupart des facteurs listés ci-dessus. On peut citer
par exemple l’environnement Eclipse.
6.6 Les Ateliers de Génie Logiciel
6.6.1 Qu'est ce qu'un Atelier de Génie Logiciel (AGL) ?

Un AGL est un logiciel aidant à la réalisation de logiciels. Autrement dit, il s'agit d'un système pour le développement
logiciel assisté par ordinateur. Un AGL intègre des outils adaptés aux différentes phases de la production d'un logiciel et
facilite la communication et la coordination entre ces différentes phases. Un AGL est basé sur des méthodologies qui
formalisent le processus logiciel, et à l'intérieur de ce processus, chacune des phases qui le composent.
Les AGL apportent une réelle solution à certains problèmes du génie logiciel et contribuent nettement à l'amélioration
de la productivité et de la qualité du logiciel, notamment en faisant le suivi des différentes phases du processus logiciel
et en offrant un cadre cohérent et uniforme de production. Néanmoins, cet enthousiasme doit être modéré: le processus
logiciel est encore loin d'être maîtrisé et les différentes formalisations qui en sont proposées font encore l'objet de
controverses.
6.6.2 Les outils « CASE » (Computer Aided Software Engineering)

Les AGL intègrent des outils d'aide au développement de logiciels appelés outils CASE: éditeurs de texte (vi, emacs...),
de diagrammes (TRAMIS VIEW, X-fig...), outils de gestion de configuration (make), SGBD, compilateurs, debuggers,
outils de mise en forme (pretty-printers), générateurs de tests, générateurs d'interfaces homme-machine, ...
Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel : conception (éditeurs de
texte, de diagrammes, ...), programmation (éditeurs de texte, compilateurs, pretty printers, générateurs d'interfaces
homme/machine...), mise au point (debuggers, outils de génération de tests, ...), etc.
Certains outils, concernant notamment la gestion de configurations, la gestion de projet, interviennent durant la totalité
du processus logiciel.
6.6.3 L'intégration d'outils CASE

Un AGL intègre différents outils CASE, de manière à les faire coopérer de façon uniforme. Cette intégration peut
(devrait) s'effectuer à trois niveaux:
• Intégration des données : Les outils CASE manipulent (génèrent, utilisent, transforment, ...) des données:
spécification, modèle conceptuel des données, jeux de test, code, manuel utilisateur, .... Différents outils sont
amenés à partager une même donnée: les tables générées par un éditeur de diagrammes sont utilisées par un


SGBD, le code généré par un éditeur de texte est compilé par un compilateur, à partir d'une spécification
algébrique on peut générer des jeux de test, ...
Un AGL doit prendre en charge la communication de ces données entre les différents outils. Cette
intégration peut être simplement physique : tous les outils de l'AGL utilisent un seul format de représentation des
données, par exemple des fichiers UNIX, sur une même machine. Cette approche implique que tous les outils de
l'AGL connaissent la structure logique (l'organisation) des fichiers qu'ils sont amenés à utiliser: il est nécessaire
de normaliser la structure logique des fichiers. L'intégration des données peut se faire également au niveau
logique en utilisant un système de gestion des objets qui gère automatiquement les différentes entités et leurs
inter-relations (cette approche nécessite la définition des différents types de données manipulées).
Un AGL gère élement la cohérence entre les différentes versions de ces données (gestion de configuration).
• Intégration de l'interface utilisateur : tous les outils intégrés dans l'AGL communiquent avec l'utilisateur
selon un schéma uniforme, ce qui facilite leur utilisation (voir par exemple l'interface du Macintosh, X11 sur
Unix ou anciens Windows sur DOS).
• Intégration des activités : un AGL peut gérer le séquencement des appels aux différents outils intégrés, et
assurer ainsi un enchaînement cohérent des différentes phases du processus logiciel. Cet aspect implique que
l'on dispose d'un modèle du processus de développement bien accepté (ce qui n’est pas évident !).
6.6.4 Les différents types d'AGL

Sur le plan historique, on a noté une évolution rapide suivant les tendances ci-après :
• Environnements orientés langages
• Environnements structurels
• Environnements boites à outils
• Environnements orientés « méthodes »
On distingue essentiellement deux types d'AGL selon la nature des outils intégrés:
1. Les environnements de conception (upper-case) : ces ateliers s'intéressent plus particulièrement aux phases
d'analyse et de conception du processus logiciel. Ils intègrent généralement des outils pour l'édition de
diagrammes (avec vérification syntaxique), des dictionnaires de données, des outils pour l'édition de rapports,
des générateurs de (squelettes de) code, des outils pour le prototypage, ... Ces ateliers sont généralement basés
sur une méthode ou un langage d'analyse et de conception (JSD, SADT, Yourdon, Merise, UML ...) et utilisés
pour l'analyse et la conception des systèmes d'information.
TRAMIS est un environnement de conception qui intègre notamment un éditeur de diagrammes (TRAMIS View), un
générateur de prototypes (TRAMIS Dialog), ...
2. Les environnements de développement (lower-case) : ces ateliers s'intéressent plus particulièrement aux phases
d'implémentation et de test du processus logiciel. Ils intègrent généralement des éditeurs (éventuellement dirigés
par la syntaxe), des générateurs d'interfaces homme/machine, des SGBD, des compilateurs, optimiseurs, pretty-
printers, debuggers, ...
Exemple : WinDev est un environnement de développement.
D’autres environnements de développement existent sous Unix/Linux, qui intègrent différents outils pour la
programmation et le test. L'intégration des données est faite par l'intermédiaire des fichiers Unix, la gestion (limitée) de
configurations est faite par make...
Certains environnements plus évolués sont dédiés à un langage particulier. Il existe par exemple des environnements
dédiés à InterLisp, Smalltalk, Loops (l'environnement Loops fonctionne sur une machine dédiée à Loops), Oz... Ces
différents environnements proposent des bibliothèques de composants, une interface graphique, des éditeurs dédiés au
langage, des interprètes, debuggers ... Ces environnements permettent un développement rapide et convivial. En
revanche, l'application développée est intégrée dans (et généralement inséparable de) l'environnement, ce qui peut poser
des problèmes de portabilité et de coût. Enfin, il existe des générateurs d'environnements de programmation : Mentor,
Gandalf, Synthesizer Generator, ... A partir de la description formelle d'un langage (à l'aide de grammaires attribuées,
de la logique), ces différents systèmes génèrent un environnement de programmation dédié au langage, contenant un
éditeur dédié au langage, un pretty-printer, un debugger, un interpréteur, ...
6.6.5 Standardisation des ateliers

Le problème majeur que l’on peut rencontrer c’est la difficulté de communication entre les différents ateliers de plus en
plus nombreux, variés et couteux. Toutes ces raisons ont poussé les acteurs à évoluer vers une standardisation.
6.6.6 Ateliers et Cycle de vie

Dans un AGL, on retrouve plusieurs environnements centrés sur un formalisme pouvant permettre de couvrir le cycle
de vie du logiciel.

Besoins Spécifications
Conception Test Intégration

 Maintenance
Version Configuration Projet Mesures
Base de données
SE (Système d’Exploitation)
Outils
Concept.
Outils Outils
Program. Gestion d’objet spécifiques
BD
Noyau Outils
Outils
d’édition gestion
auto.
Outils Interface
d’accès publique
Figure 74. Structure d’un EIPL (Environnement Intégré de Production de Logiciel)
Note : Un logiciel est évalué selon des critères relatifs à la qualité de traduction d’éléments d’un diagramme de classes :
associations, classes-associations, agrégations, contraintes inter-relations, héritage, rétro-conception de BD.
6.7 Intérêt de gérer la qualité d'un logiciel, et de son contrôle à l’aide des outils appropriés
[Linsolas09]
Plusieurs solutions performantes existent pour le contrôle de la qualité du logiciel.
Mais rappelons ce que c’est que la qualité d'un logiciel, et en quoi est-il important de la contrôler !
En paraphrasant Wikipédia, la gestion de la qualité est l'ensemble des activités qui concourent à l'obtention de la
qualité dans un cadre de production de biens ou de services (dans notre cas, d'un logiciel informatique). Plus
largement, c'est aussi un moyen que se donnent certaines organisations, dans des buts tels que la mise en conformité
par rapport aux standards du marché.
Dans le monde informatique en général, la qualité d'une application va être directement liée à la qualité du code (ceci
est particulièrement vrai dans des langages comme Java). De nombreux outils s'affairent à contrôler certains aspects de
cette qualité du code : exécution de tests unitaires, analyse de la couverture du code par ces tests, vérifications du
respect des règles de codage, etc. Il est donc possible de contrôler la qualité de son code grâce à ces outils, et d'avoir une
confiance accrue en son application !
Le contrôle de la qualité va donc pousser l'équipe de développement à adopter et à respecter certains standards de
développement. Le but de tout cela étant bien entendu de rendre le code plus sûr, mais de permettre d'y déceler les
erreurs le plus rapidement possible... et donc de les corriger !
Le "Toyota Way" correspond à une méthodologie extrêmement appréciée aujourd'hui, aussi appelée le "Lean". Celle-ci
est basée sur 14 principes dont l'un d'eux est le "Build a culture of stopping to fix problems, to get quality right the
first time". Ce principe est là pour nous rappeler qu'il est impossible d'accélérer et de soutenir une fréquence de
production sans que la qualité soit au coeur de toutes les actions. Autrement dit, il n'est pas possible d'aller vite en
sacrifieant la qualité, mais qu'il n'est pas possible non plus de faire de la qualité en sacrifiant la vitesse. C'est aussi pour
cela qu'il est aujourd'hui primordial de disposer d'une intégration continue et d'un processus itératif et incrémental.
Chez Toyota, on demande deux choses à un ouvrier, chaque jour : livrer des pièces et trouver de meilleures façons de
le faire. Le second point étant bien plus important que le premier. Cela garde l'ouvrier éveillé, fier qu'on lui demande
de se servir de sa tête et de sa créativité.
Demandez aux développeurs de livrer du code, mais plus important encore... d'améliorer tout les jours, leurs façons
de faire. À la longue, on réduit les défauts et on augmente la productivité. Mieux, on leur demande de demeurer des
humains, pas de devenir des machines.


L'un des intérêts de la surveillance de la qualité est la détection précoce des éventuels problèmes. Or lorsque l'on sait
que le coût de la correction d'une erreur augmente considérablement avec le temps (voir image ci-dessous), on
comprend très vite l'importance de la détection rapide des erreurs...
[Linsolas09]
Figure 75. Le coût de correction d’une erreur croit exponentiellement avec le temps
Comme le rappelle Tom DeMarco, "You can't control what you can't measure", "On ne peut contrôler ce que l'on ne
mesure pas"... D'où l'importance d'utiliser un outil de qualité tels que « Sonar » (voir plus loin dans le chpitre).
6.8 Les « processwares »
Les processware ou Intergiciel, sont des progiciels d’interconnexion entre applications.
Un processware est une application qui fournit les traitements de gestion entre différents progiciels.
6.9 Outils de Développement MBSE (Model based System Engineering)
6.9.1 PolarSys Solutions
6.9.1.1 Capella
6.9.1.2 Papyrus (SysML / UML)

Papyrus est la solution PolarSys pour la modélisation SysML et UML. Il s'appuie sur la plate-forme Eclipse sous-
jacente et sur d'autres offres basées sur Polarsys et Eclipse pour répondre aux besoins d'intégration du cycle de vie, tels
qu'un environnement de développement intégré C / C ++, un contrôle de source (par exemple, Git) et la génération de
rapports. Grâce à sa prise en charge intégrée de la modélisation UML et SysML, Papyrus constitue la base de l'adoption
et de l'utilisation de l'ingénierie dirigée par les modèles (MDE) et de l'ingénierie des systèmes basés sur les modèles
(MBSE). De plus, les partenaires ont déjà construit des outils industriels basés sur Papyrus pour soutenir leurs domaines
et leurs clients.
6.9.1.3 CDT Eclipse (Outils de développement C / C ++)
Le projet CDT fournit un environnement de développement intégré entièrement fonctionnel en C et C ++ basé sur la
plate-forme Eclipse. Les fonctionnalités incluent : prise en charge de la création de projet et construction gérée pour
diverses chaînes d'outils, construction standard, navigation source, divers outils de connaissance source, tels que la
hiérarchie des types, le graphe d'appels, le navigateur d'inclusion, le navigateur de définition de macro, l'éditeur de code
avec mise en évidence de la syntaxe, le pliage et l'hyperlien navigation, refactoring et génération de code source, outils
de débogage visuel, y compris la mémoire, les registres et les visualiseurs de désassemblage.
6.9.2 AndroMDA pour Java (un générateur d’application)
L'idée qui se cache derrière MDA en tant que méthode, et donc derrière AndroMDA en tant qu'outil, c'est de se dire que
la plus grande partie d'une application doit pouvoir être conçue indépendamment de la technologie utilisée pour
l'implémenter. Le résultat de cet effort de conception, ce sont des modèles qui peuvent être spécifiées dans un langage
standard, et lui aussi indépendant de la technologie d'implémentation : UML. Ensuite, la démarche la plus simpliste est
de partir de ces modèles pour les traduire manuellement en leur implémentation en fonction de la technologie utilisée,
ce qui est souvent très long et très facilement source d'erreurs inutiles et d'incohérences. Il se trouve justement qu'avec
l'expérience, on a pu identifier des schémas de conception (plus connus dans leur dénomination anglophone de « design
patterns ») génériques, qui permettaient de résoudre des problèmes classiques, de proposer une solution éprouvée qu'il
suffisait de réutiliser. On s'est aussi rendu compte que l'implémentation de ces modèles dans une technologie donnée
était automatisable dans une certaine mesure. C'est ce que fait AndroMDA : il extrait toutes les informations qu'il peut
d'un modèle UML, y applique un ensemble de modèles de conception et de paramètres de configuration pour produire
tout le code générique d'une application, ne laissant au développeur qu'à boucher les trous en implémentant les parties
qui n'ont pas pu être spécifiées dans le modèle, notamment parce qu'elles dépendaient de la technologie
d'implémentation choisie. La part de code généré dans le code intégral de votre application dépend donc de deux
facteurs : le niveau de détail de votre modèle et sa conformité avec les attentes d'AndroMDA d'une part, et le nombre et
la qualité des modules de génération mis en oeuvre par AndroMDA d'autre part.


AndroMDA prend en entrée un modèle métier spécifié en UML (« Unified Modeling Language ») et génère des parties
importantes des couches nécessaires pour construire une application Java. La faculté d'AndroMDA à traduire
automatiquement des spécifications métier de haut niveau en un code de qualité permet un gain de temps significatif
dans l'implémentation d'applications Java.
L’Architecture en couche est décrite ci-dessous :
• Couche de présentation : AndroMDA offre actuellement un choix entre deux technologies pour implémenter des
couches de présentation web : Struts et JSF (« JavaServer Faces » - framework de programmation Java). Il accepte
en entrée des diagrammes d'activité UML pour spécifier les enchaînements de pages, et génère des composants
pour les frameworks Struts ou JSF.
• Couche métier : la couche métier générée par AndroMDA est principalement consituée de services configurés en
utilisant le framework Spring. AndroMDA crée des méthodes vides dans les classes d'implémentation où la logique
métier peut être ajoutée. Les services générés peuvent éventuellement être interfacés avec des EJB. Dans ce
scénario, les services doivent être déployés dans un conteneur d'EJB comme JBoss AS. Les services peuvent
également être exposés comme des WebServices, fournissant une interface indépendante de la plateforme aux
clients qui souhaitent accéder à leurs fonctionnalités. AndroMDA peut aussi générer des processus et des
ordonnancements métier pour le moteur d'ordonnancement jBPM (qui fait partie de la famille de produits JBoss).
• Couche d'accès aux données : AndroMDA s'appuie sur le très populaire outil de mapping objet relationnel
Hibernate pour la génération de la couche d'accès aux données des applications. Il produit des objets d'accès aux
données (DAO - « Data Access Objects ») pour les entités définies dans le modèle UML. Ces objets d'accès aux
données utilisent l'interface de programmation d'Hibernate pour convertir les champs de bases de données en objets
et vice-versa.
• Couche Bases de données : puisque les applications générées par AndroMDA utilisent Hibernate pour accéder aux
données, vous pouvez utiliser n'importe quelle base de données supportée par Hibernate.
APPLICATION
Couche de Présentation
Composants d’interface Utilisateur JSP, Struts and
JSF
Composants de comportement
Couche Métier
Interfaces de services Web services / AXIS
Ordonnancement Métier jBPM
Composants Métier Springs/EJB
Couche d’accès aux données
Composants d’accès aux données Hibernate
Couche stockage des données

Toutes les bases
Bases de données de données supportées
par Hibernate
[Arbogast06]
Figure 76. Architecture des applications d'entreprise – Implémentation AndroMDA


Remarques :
- Puisque AndroMDA est totalement modulaire, il est fondamentalement extensible et il y a de très nombreuses possibilités
d'ajout de modules qui génèreront une implémentation pour des technologies propres à votre environnement. l'équipe
d'AndroMDA a créé une initiative pour coordonner et encourager la création de modules additionnels. Sachez par
exemple qu'un effort important a été réalisé pour finaliser une pile de modules pour .NET, afin de permettre de générer à
votre convenance une application Java et/ou .NET à partir des mêmes modèles.
- Contrairement à certains générateurs classiques, AndroMDA ne se contente pas de générer des fichiers de classes Java :
il génère également les fichiers de configuration XML nécessaires dans la plupart des frameworks Java, comme les
fichiers de mapping d'Hibernate, les fichiers de description de beans de Spring ou encore les fichiers de configuration
d'Axis. Ce qui est intéressant, c'est qu'alors même que vous n'avez pas encore bouché les trous d'implémentation,
simplement avec votre modèle, AndroMDA génère une application qui compile et peut déjà être déployée sans erreur
dans un serveur d'applications ! Bien sûr il peut y manquer des fonctionnalités, mais toute l'infrastructure est prête.
Propagation des données entre les couches
Les bases de données relationnelles stockent les données comme des champs dans des tables. La couche d'accès aux
données récupère ces champs depuis la base de données et les transforme en objets qui représentent les entités du
domaine métier. C'est pourquoi on appelle ces objets des entités métier. La couche d'accès aux données passe les entités
métier à la couche métier qui éxecute sa logique sur ces entités.
Concernant la communication entre la couche métier et la couche présentation, il y a véritablement deux écoles de
pensée. Certains recommandent que la couche de présentation puisse avoir un accès direct aux entités métier, tandis que
d'autres préconisent l'inverse : les entités métier devraient être totalement isolées de la couche de présentation et la
couche métier devrait encapsuler les données dans ce que l'on appelle des objets de valeur (« value objects ») avant de
les transmettre à la couche de présentation. Essayons de comprendre les avantages et les inconvénients de ces deux
approches.
La première approche (rien que des entités, pas d'objets de valeur) est plus simple à implémenter. Vous n'avez pas
besoin de créer des objets de valeur ou d’écrire un code pour transférer l'information depuis les entités vers les objets de
valeur. En fait, pour de petites applications simples où la couche de présentation et la couche métier s'exécutent sur la
même machine, cette approche fonctionnera très bien. Mais pour des applications plus grandes et plus complexes, cette
approche s'adapte mal, notamment pour les raisons suivantes :
• La logique métier n'est plus contenue exclusivement dans la couche métier. Il est alors tentant de manipuler
directement les entités depuis la couche de présentation, et de disperser du même coup la logique métier dans des
endroits différents, ce qui peut rapidement devenir un cauchemar en termes de maintenabilité. Et dans le cas où il y
a plusieurs interfaces de présentation pour un service (par exemple une interface web, un client riche et un client
mobile), la logique métier doit alors être dupliquée dans tous ces clients. De plus, il n'ya rien qui empêche les
clients de corrompre les entités, intentionnellement ou pas.
• Lorsque la couche de présentation s'exécute sur une machine différente (par exemple dans le cas d'un client riche),
il est complètement absurde de sérialiser tout un réseau d'entités pour l'envoyer au client. Prenons l'exemple de la
présentation à l'utilisateur d'une liste de commandes. Dans ce scénario, nous n'avons pas besoin de transmettre
tous les détails de chaque commande à l'application cliente. Tout ce dont le client a besoin, c'est d'un numéro de
commande, d'une date et d'un montant total pour chaque commande. Ensuite, si l'utilisateur souhaite voir les détails
d'une commande en particulier, nous pouvons toujours lui transmettre cette commande en entier.
• Le fait de passer des entités réelles au client peut poser un risque de sécurité (exemple : voulez-vous que
l'application cliente puisse toujours accéder au salaire dans une entité « Employé » ou à votre marge de profit
dans une entité « Commande ») ?
Les objets de valeur fournissent une solution pour tous ces problèmes. C’est vrai, il faut écrire un peu de code en plus,
mais en échange vous obtenez une couche métier d'une solidité à toute épreuve qui communique efficacement avec la
couche présentation. On peut voir les objets de valeur comme une vision contrôlée cohérente avec les besoins de votre
application cliente. Notez d'ailleurs qu'AndroMDA fournit un support de base pour la transformation d'entités en objets
de valeur (et vice-versa), un support qui va d'ailleurs encore une fois vous faire gagner beaucoup de temps.
6.9.3 Delphi Architecte

Delphi Architecte est un « studio » de développement. Il permet de développer une application MDA depuis le PIM
(Plateform Independant Model) jusqu'aux PSM (Plateform Specific Model). Bold intégré à Delphi permet cette
architecture de développement conduite par le modèle. Par exemple, la base de données ainsi que les fonctions d'accès
sont mises en place, suivies, modifiées directement depuis le modèle. C'est un gain énorme en cohérence de projet dans
la durée, dans la réutilisation de modules fiables et dans l'indépendance par rapport aux systèmes d'exploitation et aux
bases de données.
En unissant Bold dans Delphi, cette architecture trouve une implémentation qui bénéficie de l'efficacité et des
performances de Delphi. Le fait que Delphi tourne sous Windows 32 / 64 bit, sous .NET et sous Linux s'inscrit
parfaitement dans la logique MDA en offrant les PSM d'implémentation. En amont, Bold, livré avec la version
Architecte de Delphi permet d'établir et de conduire le modèle qui soutient l'application. Le modèle peut être écrit à
l'aide de Rational Rose ou de ModelMaker. L'avantage de ce dernier est qu'il est livré avec Delphi.


La puissance de l'approche MDA dans Delphi a été mise en oeuvre par Bold pour développer de manière très efficace,
des applications dans des domaines variés :
• Système d'attributions de fonds pour l'industrie off-shore
150 classes, 2 millions d'objets dans une institution de financement internationale
• Système de gestion de l'imposition des personnes physiques et des entreprises
130 classes, 10 millions d'objets utilisé par 200 administrateurs
• ERP
Gestion de ressources en personnel et en équipements
300 classes, 2 millions d'objets utilisé par 200 personnes d'une chaîne de télévision
• Logistique
Analyse des besoins en temps réel, planification des ventes et de la distribution
230 classes, 2 millions d'objets
• e-Banking
Middleware pour rendre un AS/400 bancaire compatible COM
60 classes, 5000 objets au format XML.
6.10 Outils de contrôle de Qualité et de Test de codes

Plusieurs facteurs de test peuvent entrer en jeu :
1. Authorization: Validation of users to connect to application
Security Testing
Functionality / Requirements Testing
2. Access Control: Permission to valid user to use specific service
Security Testing
3. Audit Trail: Maintains metadata about operations
Error Handling Testing
4. Correctness: Meet customer requirements in terms of functionality
All black box Testing Techniques
5. Continuity in Processing: Inter process communication
Execution Testing
Operations Testing
6. Coupling: Co existence with other application in customer site
Inter Systems Testing
7. Ease of Use: User friendliness
User Interface Testing
Manual Support Testing
8. Ease of Operate: Ease in operations
Installation testing
9. File Integrity: Creation of internal files or backup files
Recovery Testing
10. Reliability: Recover from abnormal situations or not. Backup files using or not
Recovery Testing
Stress Testing
11. Portable: Run on customer expected platforms
Compatibility Testing
Configuration Testing
12. Performance: Speed of processing
Load Testing
Stress Testing
Data Volume Testing
Storage Testing
13. Service Levels: Order of functionalities
Stress Testing
14. Methodology: Follows standard methodology during testing
Compliance Testing
15. Maintainable: Whither application is long time serviceable to customers or not
Compliance Testing (Mapping between quality to testing connection)

6.10.1 Contrôler la
qualité de ses projets avec l’outil « Sonar »


[Linsolas09]
Sonar offre une solution performante du contrôle de la qualité du logiciel. Cet outil sert à offrir un suivi de la qualité
d'un logiciel. Il s'agit toutefois là d'une solution facile à déployer, très agréable à utiliser, et vraiment complète. De plus,
elle est aujourd'hui une des rares solutions (open source en tout cas) à proposer la visualisation et le regroupement de
ces données pour un ensemble de projets, et non pour un seul projet.
L'intégration d'un gestionnaire de plugins est un aspect important pour le développement de Sonar.
Sonar est un outil open-source initiallement développé par la société suisse Hortis. Depuis novembre 2008, c'est la
société suisse SonarSource qui se charge du développement et du support de Sonar. Le but principal de cet outil est de
fournir de nombreuses statistiques (ou "metrics") sur des projets. Ces données permettent ainsi d'évaluer la qualité du
code, et d'en connaître l'évolution au cours du développement.
D'un point de vue architectural, Sonar est composé de 3 couches principales :
• Les plugins Maven 2, qui exécutent les plugins de rapports (Checkstyle, PMD, etc.) et en récoltent les résultats.
(l’outil Checkstyle propose plus d'une centaine de règles, et il en va de même avec l’outil PMD).
• La base de données, qui stocke et historise les informations sur les projets "surveillés" par Sonar.
• Le serveur web qui agrège les résultats et affiche des dashboards pour les projets.
Principales fonctionnalités
Nous listons ici les principales fonctionnalités de l'outil Sonar.
• Tableau de bord complet des différents projets suivis.
• Détection rapide du code à risque.
• Mesures quantitatives : nombre de classes, duplication de code, etc.
• Mesures qualitatives : couverture et taux de réussite des tests, complexité du code, respect des règles de codage...
• Historiques des statistiques, pour en voir l'évolution au cours du temps.
• Support de plus de 600 règles de qualité (suivant la norme ISO 9126-3).
• Gestion de profils pour les règles de codage.
• Visualisation du code source, surlignant les violations des règles de codage qui s'y trouvent.
• Fonction "Time machine" permettant de comparer plusieurs versions d'une même application.
• Identification des points faibles d'un projet.
• Support des plugins.
6.10.2 Tests unitaires avec le framework « xUnit » (un OpenSource)

[Grossglauser07], [JunitWWW]
Le terme générique « xUnit » désigne un outil permettant de réaliser des tests unitaires dans un langage donné (dont
l'initiale remplace « x » le plus souvent).
Au départ, on a vu la création de « SUnit », un environnement de test pour le langage Smalltalk, créé en octobre 1994
par Kent Beck. Le succès de cet outil a amené la communauté à créer des adaptations pour plusieurs autres langages :
• Aunit pour Ada ;
• ASUnit pour ActionScript ;
• cppunit pour C++;
• CUnit pour C;
• DUnit pour Delphi ;
• FLEXunit pour Adobe Flex ;
• Google Test pour C++
• HUnitpour Haskell
• JSUnit pour Javascript ;
• JUnit et TestNG pour Java ;
• NUnit pour .NET ;
• NUnitASP pour ASP.NET (support interrompu depuis le 31 janvier 2008) ;
• OUnit pour Ocaml
• OCunit pour Objective C;
• PHPUnit et SimpleTest pour PHP ;
• unittest pour Python ;
• Test::Unit pour Ruby ;
• Test::More pour Perl
Le Framework « JUnit »
Ce framework a été créé par Kent Beck et Erich Gamma, et s’avère aujourd’hui être l’un des outils de la série des
xUnit connaissant le plus de succès. Deux types de fichiers de tests sont utilisés ici :
- des TestCase : classes contenant des méthodes pour tester le bon fonctionnement d'une classe
- une TestSuite : exécute un certain nombre de TestCase déjà définis.


L’automatisation des tests devient encore plus intéressante lorsque l’on associe l’utilitaire libre « myT2 » lors des tests
de codes Java. Vous trouverez plus de détails sur JUnit dans [JunitWWW].
Le Framework « TestNG »
Ce framework (Next Generation Java Testing) a été conçu pour couvrir toutes les categories de tests : modulaires
(classes séparées), fonctionnel, finitude, integration (ensemble du système avec pluseurs classes et packages), etc.
Vous trouverez plus de détails sur TestNG dans [TestNGWWW].
Le Framework « PhpUnit »
PHPUnit est un framework de tests unitaires simple et efficace, son éventail de fonctionnalités permet de créer
rapidement des tests unitaires complets et adaptés aux applications PHP professionnelles. PHPUnit offre une solution
particulièrement flexible pour organiser vos tests, vous pouvez les exécuter indépendamment les uns des autres, les
grouper en suites, ou rassembler les suites elles-mêmes afin d'exécuter le tout en une seule fois.
PHPUnit offre quelques qualités :
- Une syntaxe simple, facile à comprendre et à retenir.
- Un grand nombre de méthodes de tests.
- Organisation et exécution des tests flexibles.
- Un utilitaire en ligne de commande complet.
PHPUnit offre quelques fonctionnalités avancées
- Support des objets "mock" (simulateur d'objets)
- Analyse de la couverture de code (code coverage analyse).
- Support de « Selenium RC » (environnement de développement intégré (IDE) / tests fonctionnels)
- Journalisation des tests aux formats XML, JSON, TAP ou dans une base de données.
PHPUnit est pris en charge nativement dans les IDE suivant :
- NuSphere PHPEd.
- PHPEdit.
- Zend Studio.
- PHPEclipse (voir plugin Eclipse SimpleTest ).
- Eclipse PDT.
• L'utilitaire de ligne de commande : phpunit est le principal outil dédié à la configuration et à l'exécution des
tests unitaires. Cet utilitaire est optimisé pour les systèmes Unix/Linux. Mais, il peut également fonctionner
sous Windows. La liste des commandes est disponible en tapant :
phpunit --help
• Indicateur de résultat : Un indicateur de résultat est fourni pour chaque méthode de test exécutée :
Tiré de [Grossglauser07]
Indicateur Description
. Le test passe.
F Le test a échoué (Failure).
E Le test a généré une erreur PHP.
S Le test est ignoré (Skipped).
I Le test est marqué comme incomplet (Incomplete).
6.10.3 Outils utilisables pour la méthode agile FDD (Feature Driven Development)
* CASE Spec : outil professionnel pour les développements FDD.
* TechExcel DevSuite : outils commercial adapté à FDD.
* FDD Project Manager Application (FDDPMA) : produit de gestion des applications développées dans un processus
FDD itératif. Son interface est de type Web, permettant la generation de rapports et graphiques.
* FDD Tools : plateforme Opensource supportant tout le processus de développement FDD.
* FDD Tracker : solution pour gérer et suivre l’évolution de projets de type FDD.
* FDD Viewer : outil de visualisation FDD.
6.10.4 Tests TDR

FIT ([FITwww12]) est un outil créé par Ward Cunningham, l’un des contributeurs du processus XP. L’idée initiale de
l’auteur était de créer un moyen simple de tester les story-cards, équivalent des spécifications fonctionnelles dans le
processus XP, et de pouvoir associer le client, concept fondamental dans XP, à la création de ces story-tests.
FIT permet ainsi de spécifier des tests à un niveau fonctionnel et de les exécuter automatiquement sans avoir besoin de
déployer et d’exécuter l’application.
Le principe de fonctionnement est de décrire des tests sous une forme tabulaire, dans une page web standard, et
d’accompagner ce tableau d’un bout de code, appelé fixture, qui fait le lien entre les tests et les API de l’application. Le
moteur FIT s’occupe du reste. Il utilise la fixture pour lire le tableau et appeler les API de l’application avec les
paramètres adéquats. Il retourne ensuite le résultat du test dans le même tableau en mettant en couleur les cases du
tableau selon le résultat du test.


Deux outils permettent aujourd’hui de combiner « wiki » et « moteur de tests » : Fitnesse et Greenpepper.
• Fitnesse ([FitnesWWW10]) est un outil libre qui utilise une version modifiée de FIT comme moteur de tests et
permet de décrire ses tests dans un wiki. Il nécessite par contre de déployer le code source sur un serveur pour
pouvoir exécuter ses tests. C’est un bon outil pour l’étape TDR et tests de recette, mais n’est pas suffisant pour
supporter une approche compréhensive du TDR jusqu’au code.
• Greenpepper ([GreenWWW10]) est un outil plus puissant combinant un moteur de tests open-source et une
série d’extensions payantes. Les extensions permettent l’utilisation du wiki Confluence et l’intégration à une
« usine logiciel » par des scripts Maven. Une extension permet également d’intégrer JIRA, un moteur de
workflow. Les tests peuvent être exécutés indépendamment depuis un serveur ou depuis le poste du
développeur. Il est également possible de choisir différents contextes d’exécution. On peut ainsi gérer plusieurs
environnements de tests selon les phases de tests à effectuer (développement, homologation, recette,
préproduction) ou selon la version des spécifications.
Lors d’une bonne mise en œuvre de Greenpepper, l’équipe de travail peut être répartie sur plusieurs sites avec
des développements effectués dans plusieurs villes comportant plusieurs développeurs. Le délai moyen entre la
fin de l’écriture du code pour une livraison donnée et la mise en production de cette nouvelle version peut être
ramené à juste quelques heures. Ce délai inclut les phases de tests d’homologation et de pré-production (tests
d’intégration avec les systèmes environnants). La seule activité manuelle effectuée après l’écriture de la
dernière ligne de code consiste à vérifier le bon fonctionnement de l’interface graphique, en attendant que cette
couche soit testable avec des outils comme Greenpepper ou FIT.
• L’outil Leirios Test Designer ([LeiriosWWW10]) permet d’utiliser un modèle comportemental formalisé avec
un sous-ensemble d’UML, appelé modèle de test, pour générer les actifs de tests. Ce modèle est parcouru par
un moteur calculant le nombre de tests et les vérifications à effectuer pour en déduire les cas de tests. Ces cas
de test peuvent ensuite être traduits en scripts de tests avec un adaptateur adéquat.
6.11 Autres outils de réalisation
6.11.1 La suite « RAD Studio XE »

Cet atelier regroupe un ensemble de produits pour le développement en RAD d’applications client serveur, multi-tier ou
Web, leur intégration à la majorité de SGBD et au « cloud », etc.
RAD Studio inclut en standard :
- Delphi, C++Builder pour les développements natifs Windows
- Delphi Prism pour les développements rapides « .NET » avec possibilité de réaliser des modules ou de s’interfacer
avec Linux, MacOSX ou Windows.
- RadPHP, un environnement de développement visuel d’applications Web en PHP.
- Outils de déboguage et de test.
- Modules de liaison avec d’autres environnements.
6.11.2 Le serveur d’application universel « EAS : Enterprise Application Server »

[Sybase]
EAS est un serveur d »’applications adapté aux gros développements.
- Il est ouvert aux supports transparents de tous les types de clients : CORBA, XML, HTML, DHTML, ActiveX, C,
C++, PowerBuilder …
- Il est compatible avec la plate forme J2EE (Java 2 Enterprise Edition), ce qui assure la prise en charge des
technologies J2EE : EJB, Servlet, JNDI (Java Naming and Directory Interface), JTA (Java Transaction API), JTS
(Java Transaction Server), JDBC.
- Il s’intègre avec les outils de développement Web « Power J », HTML, programmation Java, JavaScript, ActiveX.
Tout ceci fait que EAS est adapté au développement d’applications Internet et Intranet.
6.11.3 L’environnement de référence DOC (HP)

DOC (Distributed Object Computing) est un RPC proposé par HP. Initialement, il est une implémentation du
standard DCE de l’OSF.
DOC est une plateforme de développement d’applications réparties intégrant à la fois les propriétés des RPC
procéduraux et des RPC orientés objets (ou ORB). Mais, il se rapproche beaucoup plus de l’ORB grâce à ses
composantes (outils) C++, Smaltalk, DOMF, etc.
Note : Motif est une interface graphique utilisateur normalisée pour le système Unix (comme Windows l’était pour le
DOS initialement).


Environnement utilisateur HP
Environnement de View [OSF / Motif] New Ware
développement de Outils de gestion
logiciels APPLICATIONS
(Soft bench) et du réseau
Plateforme
Client ou [NIST, ECNA, C++] Services d’objets répartis
(distribuive Smaltalk de HP)
Serveur
DOMF (Distributed Object Management Facilities)
Services de réseau (NCS) Service de gestion de données

[OSF/DCE] (Open ODB) [POSC ART]
O.S.
Figure 77. Schéma de la plateforme DOC
6.11.4 Quelques Logiciels de modélisation UML
Outils UML 2 pour bases de données

Principaux logiciels du marché permettant de modéliser du niveau conceptuel à la génération de scripts
SQL, une base de données à l’aide de la notation UML 2. En passant par la génération des modèles de type
MOF et ’import/export de modèles au format XMI.
- Enterprise Architect http://www.sparxsystems.com.au/products/ea.html
- MagicDraw http://www.magicdraw.com/
- MEGA Designer http://www.mega.com/en/product/mega_designer/
- ModelSphere http://www.silverrun.com/modelsphere.html
- MyEclipse http://myeclipseide.com
- Objecteering http://www.objecteering.com/
- Poseidon http://gentleware.com/index.php?id=30
- PowerAMC http://www.sybase.com/products/developmentintegration/poweramc
- Rational Rose Data Modeler http://www-306.ibm.com/software/awdtools/developer/datamodeler/
- Together http://www.borland.com
- Visio http://www.microsoft.com/france/office/visio
- Visual Paradigm http://www.visualparadigm.com/product/vpuml/productinfovpumlse.jsp
- Visual UML http://www.visualuml.com/Products.htm
- Win’Design http://www.win-design.com/fr/
Logiciels libres
• ATL open source : transformations de modèles vers ou depuis UML (etc.) ; ATL est un langage de type QVT
(le standard QVT définit un ensemble de langages permettant d exprimer des transformations de modèles à
modèles).
• Dia
• Umbrello un modeleur UML sous GPL.
• ArgoUml un modeleur UML sous Licence BSD - http://argouml.tigris.org
• Gaphor un modeleur UML sous GPL la version actuelle est 0.7.1 ;;
• BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris;
• Eclipse GMT-XUML
• Eclipse UML2, Méta modèle UML2, sans interface graphique.
• Netbeans
• Staruml, en version libre.
• Acceleo, générateur de code source à partir de modèles UML.
Logiciels propriétaires
• Rational Rose : Un des outil les plus important du marché - http://www.rational.com / Racheté par IBM
• Together (rachété par Borland/Inprise) : Outil fortement couplé avec Java : - http://www.togethersoft.com;
• Visio : Outil non complet de microsoft ; - http://www.microsoft.com/office/visio
• Together, de Borland ;
• Poseidon, basé sur ArgoUml (version commerciale) ;

•

Rational Software Architect / Rational Software Modeler (et toujours Rose/XDE), de IBM Software
Rational ;
• PowerDesigner, de Sybase (outil de modélisation complet intégrant l'UML en plus des classiques MCD, MPD
...) ;
• Objecteering de Softeam ;
• Visual Paradigm for UML, de Visual Paradigm Internation Ltd. ;
• SDE for Eclipse, un plugin UML pour Eclipse ;
• Omondo EclipseUML, un plugin UML pour Eclipse ;
• Jude, en Java ;
• MagicDraw, un éditeur de diagrammes UML ;
• Enterprise Architect, un outil de modélisation UML ;
6.11.5 Les outils SADT

De nombreux outils traitent le formalisme SADT. Nous citons quelques exemples :
• Outil logiciel d'aide à la réalisation des diagrammes IDEF de différents niveaux :
http://www.idef.com/idef-software/
• ASA
ASA est un outil supportant SADT et disponible sur SUN. Il comporte également un simulateur exploitant un
langage textuel d'automate.
• DESIGN/IDEF
Design/IDEF est un outil de Meta Software Corp., distribué par IGL traitant IDEF0/IDEF1. (sur
PC/MAC/SUN)
Les schémas SART sont convertibles en réseaux de pétri colorés, exploités par un outil de conception et de
simulation HPCN. Un générateur de code en langage SML à partir des réseaux HPCN est également disponible.
HPCN et SML sortent un peu de notre domaine d'application.
• SOFTPEN
Softpen est un atelier logiciel utilisant comme représentation interne un langage de liste (LIPS). Il comporte un
module SADT et un simulateur.
• SPECIFX
SPECIFX est un outil édité par IGL supportant IDEF0.
6.11.6 Les outils historiques de développement d’interfaces graphiques (GUI)

• Les API Window (SDK, MFC), MacOS, UNIX (Motif, X11)
• OpenGUI [GTT]
• Openside
• Open UI
 Quelques autres L4G

• IDEO [SAPIEN]
• Power++ et Optima++
• 4D [ACI]
• Delphi [Inprise/Borland]
• Power Builder []
• SQL Window [Gupta]
• GESERIX (ouvert à Unix)
• Windo4GL
• Jbuilder [Inprise/Borland]
• Oracle Developper (ancien Developpeur/2000) [Oracle]
• Visual Basic [Microsoft]
• C++Builder [Inprise/Borland]
 Quelques autres AGL

• WinDev [PCSoft]
• Power AMC
• ArtEnterprise : AGL extrêmement puissant
• Oracle Designer (ancien Designer/2000) [Oracle]
• ROSE [Rational]
• GDPro [ASTI]

6.11.7 L’accès aux données

• MTS : Microsoft Transaction Server : gestion de transactions
• ORACLE [Oracle]
• DB2 [IBM]
• Informix [Informix]
• SQL Server [Microsoft]
• PostgreSQL
• MySQL / MaryaDB
6.11.8 L’aspect gestion du projet

• MS Project [Microsoft]
• PSN : Project Scheduler Network [Scitor]
• BIRB [CGI] : l’outil s’appuie sur l’expertise auprès des clients
• PERT intervient également dans la gestion du projet
• Tuleap : est une « forge logicielle » (libre) éditée par la société Enalean permettant le pilotage des projets,
l’amélioration de la qualité des développements et facilite la collaboration. La forge favorise la productivité, la
traçabilité et la qualité des processus pendant le cycle de vie des projets. Ce logiciel libre est utilisé par plusieurs
milliers d'utilisateurs dans le monde pour leurs développements professionnels. La suite Tuleap intègre les outils
suivants :
Développer et livrer:
- Gestionnaire de versions: Subversion, Git
- Intégration continue: Hudson, Jenkins
Planifier et organiser:
- Tracker hautement configurable avec Workflow
- Tracker de bugs
- Gestion des tâches et des backlog Scrum
- Gestion des demandes de supports
- Tableaux de bords avec widgets
- Reporting : statistiques, graphiques, Gantt
- Recherche dans les trackers
Collaborer et échanger:
- Gestionnaire de documents avec circuits d'approbation
- Wiki
- Forums, messagerie instantanée, listes de distribution
- Flux RSS, annonces
Intéropérabilité:
- LDAP
- Web services : SOAP
- architecture en plugins
- Url API
- Command Line Interface
Contrôle et sécurité:
- Gestion fine des permissions
- Totale traçabilité
- Notification et suivi des changements
6.11.9 L’offre historique logicielle de Microsoft :

La plate forme de développement de Microsoft fournit tous les outils nécessaires pour élaborer des solutions client-
serveur, Internet et Window. L’offre s’appelle « Visual Studio ».
On y retrouve entre autres :
• Les produits : MSDN Library
Visual Basic
Visual C++
Visual FoxPro
Visual J++
Visual SourceSafe
Visual Interdev
SQL Server
• Les outils multimédia : Image composer
Media manager

• L’outils système :
Anomaly Tracking System


• L’outil transactionnel pour l’intégrité en réseau : Transaction server »
• L’outil de travail collaboratif : Visual Studio Team Foundation Server, arrivé avec Visual Studio 2005. Il permet de
définir des priorités sur des tâches, d'avoir une gestion des sources, etc.
• Des outils de modélisation, de déboguage et de test des applications.
6.12 Les questions que l’on doit se poser face à un système ou un gros projet d’entreprise (par
exemple de type client-serveur)
Caractéristiques de l’Outil de Développement
Client / Interface graphique
Sous quels systèmes d’exploitation ou système de multifenêtrage l’outil fonctionne-t-il ?
utilisateur
Où réside l’outil – sur le serveur, sur le client ou sur les deux ?
Outil
Plusieurs développeurs peuvent-ils l’utiliser simultanément ?
Middleware / Système d’exploitation Si l’outil est réparti. Quels réseaux supporte-t-il ?
/ Protocoles Les liaisons sont-elles propriétaires ou utilisent-elle du middleware pour passer les données ?
Middleware / Accès à distance aux Si ces données sont utilisées pendant le développement. Comment y accède-t-on ?
bases de données Les chaînages multiples en parallèle sont-ils permis ?
L’outil peut-il être connecté à d’autres applications ?
Middleware / RPC / ORB Comment ?
Peut-il accéder aux bibliothèques de classes ? Comment ?
Si l’outil (ou les données qu’il utilise) est archivé sur un serveur, pour quelles plates-formes
Serveur / SGBD / Référentiel
matérielles est-il disponible ?
Caractéristiques des Applications créées par l’outil

Avec quels systèmes d’exploitation ou environnements de fenêtrage clients fonctionnent les applications
Client / Interface graphique produites ?
utilisateur Sur quelles plateformes matérielles fonctionne-t-il ?
L’outil génère-t-il automatiquement des interfaces graphiques utilisateurs pour différentes plateformes ?
Les applications produites par l’outil fonctionnent-elle sur des clients, des serveurs ou sur les deux ?
Application
Plusieurs utilisateurs peuvent-ils les utiliser tout de suite ?
Si les applications produites sont réparties, comment cela se passe-t-il ?
Middleware / Système d’exploitation
Quel middleware est utilisé ?
/ Protocoles Quel système d’exploitation est utilisé ?
Comment une application produite par l’outil accède-t-elle aux données sur les serveurs ?
Middleware / Accès à distance aux
Des méthodes prioritaires d’accès aux bases de données sont-elles utilisées ? Outils tiers ? Langages
bases de données standards ou protocoles ?
Une application produite avec l’outil peut-elle appeler des programmes sur les serveurs ou d’autres
Middleware / RPC / ORB clients ? Quelles techniques sont utilisées pour ce faire ?
Peut-il accéder aux bibliothèques de classes ?
Si des applications réparties sont produites, quels serveurs matériels, systèmes d’exploitation et bases de
Serveur / SGBD
données peuvent-elles utiliser ?
6.13 Eléments de qualité lors d’un développement (les métriques)

Rappel de quelques définitions
Complexité cyclomatique : Métrique destinée à mesurer la complexité d'un code informatique, en comptabilisant le
nombre de "chemins" possibles au sein de ce code. Il s'agit du nombre de points de décision de la méthode (if, case,
while, ...) + 1 (le chemin principal). Ainsi, l'utilisation de boucles (while, for...) ou encore d'instructions de
branchements conditionnels (if, else) augmentent cette complexité. Ainsi, la complexité cyclomatique d'une méthode
vaut au minimum 1, puisqu'il y a toujours au moins un chemin.
Dette technique : La dette technique est une dette que vous encourez à chaque fois que vous faites quelque chose de la
mauvaise façon en laissant la qualité du code se détériorer. Tout comme les dettes financières, agir ainsi est plus facile
sur le court terme. Mais au fil du temps, les "intérêts" que vous payez sur cette dette deviennent énormes, jusqu'à
atteindre un point où une réécriture complète de l'application devient plus facile que de maintenir ou de modifier le code
existant (Explications de Martin Fowler [Fowler03]).
Métrique : Autre terme utilisé pour définir une mesure de qualité dans un développement logiciel.
Un logiciel doit présenter les six caractéristiques qualité définies par la norme ISO 9126 qui est issue des approches
de B.BOEHM et Mc CALL. Il s’agit de (voir l’ouvrage [Schach 92]) :
- Capacité fonctionnelle : accueillir un ensemble de fonctions et de propriétés bien définies pour l’exécution de tâches
dans le respect de l’application des normes, des prescriptions, et fournir des résultats avec une certaine précision.
- Fiabilité : maintenir son niveau de service dans des conditions précises et pendant une longue période.
- Facilité d’utilisation : L’utilisation ne demande pas trop d’efforts, tout au contraire, on note une facilité de
compréhension, d’apprentissage, d’exploitation, de complétude et de sécurité.


- Maintenabilité : être rapidement et facilement corrigé. Il peut supporter les modifications de ses spécifications. C’est
l’un des avantages des nouvelles approches (objets, modèles, agiles…)
- Portabilité : être installé sur une autre machine, un autre système d’exploitation ou une autre configuration logicielle
ou matérielle. C’est l’un des avantages du langage Java.
- Rendement : temps de réponse et temps de traitement des fonctions acceptables.
A titre d’exemple, le tableau ci-dessous récapitule certaines métriques de qualité effectuées pour le cas du logiciel
SAHY (voir [Nkenlif04]).
MESURES FORMULES APPLICATION DETAILS

NUMERIQUE
Fréquence des FREQ_COM= NB_COM/NB_INST Permet d’évaluer la lisibilité du code.
Commentaires Avec
NB_COM= nombre de commentaires FREQ_COM=0,67
NB_INST= nombre d’instructions
exécutables
Longueur des LONG_INST= N/ NB_INST Cette métrique constitue un indicateur de
instructions Avec lisibilité du programme : les instructions
N= nombre total d’occurrences longues sont plus difficiles à comprendre.
LONG_INST=4
d’opérandes et d’opérateurs
NB_INST = nombre d’instructions
exécutables
Nombre d’appels Nombre de procédures différentes NPD= 8 Cette métrique est un indicateur de
directs appelées par un composant [moyenne] complexité
Vocabulaire n= n1+n2 Cette métrique permet de caractériser la
avec n=7 lisibilité d’un composant. Plus le nombre de
n1= nombre d’opérateurs distincts « mots » employés (vocabulaire d’opérateurs
n2= nombre d’opérandes distinctes [moyenne par classe] ou opérandes) est élevé, plus l’effort de
[type d’opérateurs distincts] compréhension est élevé.
Nombre maximum Nombre maximum d’imbrications des Une valeur importante de cette métrique se
NMI=4
d’imbrications structures de contrôle utilisées dans le traduit par une mauvaise lisibilité du code qui
[moyenne par classe]
composant. affecte la maintenabilité.
Temps de TD = NH/N en heure par homme Volume de travail effectué
développement Avec TD = 7500
NH = nombre d’heures [5 Homme/année]
N = nombre d’hommes
Taille moyenne de TF = taille des fichiers en octets TF= 6000 Espace de stockage
fichiers [moyenne]
Nombre de lignes NL = nombre de lignes de code des NL = 25500
modules [total]
Volume du V=(N1+N2)log2(n1+n2) Permet de nommer les indicateurs tels que les
programme avec charges de développement, l’effort de test ou
N1=nombre total d’occurrences de maintenance.
d’opérateurs V=10700
N2= nombre total d’occurrences
d’opérandes
n1= nombre d’opérateurs distincts
n2=nombre d’opérandes distincts
Tableau 3 . Exemple de métriques prises (logiciel SAHY)
6.14 Documentation technique des projets importants (et activités)

Un des aspects fondamentaux pour la réussite d’un grand projet de développement logiciel, c’est la
docuementation technique complète, qui devrait être rédigée de manière exploitable par n’importe quel
technicien.
Nous listons quelques éléments, suivis de leurs détails, qui doivent être pris en compte lors de la rédaction
de ces manuels au fur et à mesure des phases de réalisation :
- Architecture du système et modèle global
- Description détaillée de toutes les structures de données (traitements critiques en mémoire)
- Description détaillée de toutes les structures de stockage (description de tous les attributs avec leurs
détails et impacts ; bases de données ; architectures des fichiers : conceptuels, applicatifs, fonctionnels)
- Architecture de l'application à mettre en place
- Eléments et contraintes de programmation
- Diagrammes conceptuels et applicatifs détaillés
- Sécurité (physique, logique, process, données systèmes, données stratégiques, données applicatives…)
- Politique qualité et évolutivité


Les sous-rubriques de chaque rubrique sont fournies ci-dessous. Notez bien que chacune d’elle devrait être
détaillée au maximum.
6.14.1 Architecture du système et modèle global

* Modèle conceptuel de données ou Diagramme de classes
* Modèle logique
6.14.2 Description détaillée de toutes les structures de données (traitements critiques en mémoire)
* Classe les tables par ordre de création
* Indication sur les tables liées
* On doit à chaque fois préciser les contraintes la portée de chaque table
6.14.3 Description détaillée des structures de stockage (bases de données, architectures des fichiers :
conceptuels, applicatifs, fonctionnels, description de tous les attributs avec tous leurs détails
* Chaque table aura un attribut "IDNomTable" et "CodeNomTable" (ou éventuellement "NumNomTable")
* Les attributs doivent être significatifs (nom choisis)
* les attributs qui s'afficheront seront toujours en plusieurs langues (>= 2 langues)
* On doit éviter les caractères accentués (sur les noms d'attributs)
* On doit à chaque fois préciser les valeurs par défaut (s'il y en a), les contraintes (interval...) et la portée
* On doit fournir un ou plusieurs exemples de valeurs de l'attribut (pour une meilleure compréhension)
* Etc.
6.14.4 Architecture de l'application à mettre en place
* Liste de tous les Menus, classés en niveaux (1, 2, 3) et numérotés hiérarchiquement
* On doit à chaque fois le fichier de la requête envisagée (utile) pour ce traitement
* On doit préciser le nom du fichier du traitement (PHP, Java...)
* On doit indiquer le répertoire (ou le sous répertoire) de stockage sur le disque dur de chaque fichier en
regroupant par module
* Décrire le rôle de chaque fichier
6.14.5 Eléments et contraintes de programmation
* Bibliothèques utilisées (envisagées)
* Bibliothèques à créer (exemple des entêtes à intégrer dans divers états)
* Variables principales : leurs rôles et leur portée, leurs types et les types compatibles
* Fonctions principales : signature, portée (paramètres, tables et autres contextes impactés), sous-fonctions
appelées, résultats
* Limites et Méthode de test (indique comment tester efficacement) pour chaque module ou chaque
fonction clé
6.14.6 Diagrammes conceptuels et applicatifs détaillés
* Diagrammes détaillés des séquences de cas d’activités par sous-ensembles de traitements
* Diagrammes d'activités par sous-ensembles de traitements
* (ou alors) Décrire (sous forme d'enchainement d'activités) chaque traitement
* Liste des composants produits et des composants outils, y compris les middlewares
* Diagramme de composants ou diagramme de déploiement (selon les cas)
6.14.7 Sécurité (physique, logique, process, données système, données stratégiques, données
applicatives…)
* Technique de signature ou de cryptage
* Elément de politique de sécurité...
* Protocoles de sauvegarde et restauration
* Etc.
6.14.8 Politique qualité et évolutivité
* Protocoles de test qualité
* Versionnage
* Protocole de mise à jour (séquence du mode opératoire par module, sous-module, procédure, etc.)
* Migration vers un autre environnement (précautions à prendre : exemple variation de types...)
* Eléments (variables…) de support des montées en charge
* Etc.


7 Ergonomie d’Applications Graphiques, Développement en équipe
7.1 Problématique de l’ergonomie
7.1.1 Pourquoi aborder ce sujet maintenant ?

Après avoir appréhendé les aspects techniques d’un déploiement multicouches, nous allons voir quelle forme et
quelle organisation finale vous allez mettre en place. Après avoir appris comment créer (ou aller chercher l’information
demandée), nous allons maintenant voir comment la mettre à disposition de l’utilisateur.
7.1.2 Pourquoi accorder de l’importance à l’ergonomie de ses applications ?

Quelque soit le domaine dans lequel vous intervenez, les vecteurs de communication que vous utiliserez seront aussi
importants, si ce n’est plus important que le fond même de votre intervention.
Petite notion de PNL (Programmation Neuro-Linguistique)
2- Formulation du 4-Réception du
message message
1- Concept 5- Concept
3- Mode de
transmission du
message
[Morlais 01]
Figure 78. Illustration du principe d’une communication ergonimique
En regardant la figure ci-dessus, dans toute communication, ce qui importe, ce n’est pas l’étape 1 mais bien finalement
l’étape 5 ! Les outils que l’on vous a donné lors des précédentes interventions permettent de passer de l’étape 2 à l’étape
3. Nous allons maintenant approfondir le passage de l’étape 3 à 4.
Dans certaines entreprises multinationales les taches sont séparées mais c’est loin d’être le cas de toutes les structures.
Vous aurez donc à faire l’étape 2 et 3 en prenant en compte les étapes 4 et 5.
7.1.3 Présentation
L’objectif est de vous sensibiliser à l’importance de l’ergonomie et de vous donner quelques points de repère vous
permettant d’être rapidement opérationnel, lors de vos prochaines expériences professionnelles.
Certaines personnes passent plus de 4 ans à étudier l’ergonomie, nous n’avons évidemment pas la prétention d’être
exhaustif, c’est la raison pour laquelle nous avons choisi de vous présenter des résultats sous forme de « règles », que
l’on pourrait classer sous la rubrique « trucs et astuces » dans un magasine informatique, mais qui résulte d’une
synthèse d’études sérieuses.
Pour vous permettre d’appréhender cela, nous allons d’abord nous intéresser à l’Ergonomie en rentrant un peu dans les
« détails conceptuels ». Nous établirons ensuite une grille de critères à observer et nous terminerons par l’étude de sites
Internet pour voir concrètement la mise en application de ces principes.
7.2 Qu’est-ce que l’ergonomie ?

[Morlais 01]
7.2.1 Définition et complexité du concept
Un grand nombre de définitions existent, en voici quelques unes :
"L'ergonomie est l'ensemble des connaissances relatives à l'homme et nécessaires pour concevoir des outils, des
machines et des dispositifs qui puissent être utilisés avec un maximum de confort, de sécurité et d'efficacité."
7.2.1.1 D’après Alain WISNER

L'Ergonomie peut être définie comme " l'adaptation du travail à l'homme " ou plus précisément comme " La mise en
œuvre de connaissances scientifiques relatives à l'homme et nécessaires pour concevoir des outils, des machines et des


dispositifs techniques qui puissent être utilisés par le plus grand nombre avec le maximum de confort, de sécurité et
d'efficacité. "
Définition adoptée par le conseil de la SELF et affichée lors du congrès de Paris en 1988.
" L'ergonomie est une discipline scientifique qui étudie le fonctionnement de l'homme en activité professionnelle : elle
est une technologie qui rassemble et organise les connaissances de manière à les rendre utilisables pour la conception
des moyens de travail ; elle est un art lorsqu'il s'agit d'appliquer ces connaissances pour la transformation d'une réalité
existante ou pour la conception d'une réalité future. Ses critères d'application sont du domaine de la protection de la
santé physique, mentale, psychique et sociale des travailleurs, du domaine du développement de leurs capacités
professionnelles au cours de leur vie active, dans le cadre d'objectifs de production. "
7.2.1.2 D’après Antoine LAVILLE

" Les résultats de l'analyse du travail doivent permettre de mettre en évidence les éléments qui dans le travail de
l'homme ou d'une population donnée sont particulièrement difficiles ou inadaptés, de façon à corriger la situation de
travail pour une meilleure adaptation de l'homme en activité ce qui inclut un souci : de santé, de diminution des charges,
d'amélioration des conditions de travail, mais aussi d'atteinte des objectifs économiques."
7.2.1.3 D’après François DANIELLOU

On peut maladroitement tenter de synthétiser toutes ces définitions en disant de l’ergonomie que c’est : « Une discipline
scientifique visant à rendre accessible, à une cible déterminée, un processus déterminé, le plus simplement possible. »
L’objectif est d’améliorer les conditions de travail (permettant ainsi d’augmenter le rendement !) et les leviers activés
sont divers, ce qui explique la complexité de la matière.
Dans notre schéma de départ, l’ergonomie se situe au niveau de l’étape 3 :

- dans l’interface de l’étape 3 : l’ergonomie peut permettre un environnement propice à la bonne
transmission du message, de l’information,
- et au sein de l’étape 3 : l’ergonomie peut intervenir dans la construction du message, c’est ce qui nous
concerne directement.
Le rôle de l’ergonomie des interfaces utilisateurs est d’établir la communication entre l’outil et l’opérateur.
L’ergonomie conditionne ainsi l’acceptabilité du système par l’utilisateur, la facilité et l’efficacité d’utilisation, la
facilité d’apprentissage (ces différents points ne sont pas toujours compatibles).
Il est illusoire de croire à la possibilité de faire « une bonne interface » ou « un logiciel ergonomique » en faisant
l’impasse sur la connaissance des futurs utilisateurs et sur leur manière de travailler. Toute conception d’interface doit
donc placer l’utilisateur au centre de l’étude. Et il est capital de bien comprendre le mode de fonctionnement de
l’utilisateur, c’est la raison pour laquelle nous allons maintenant aborder un groupe de sciences sans lequel l’ergonomie
ne saurait exister : les sciences cognitives (la cognitique est d’abord reservée aux cigiticiens).
7.2.2 La place des technologies cognitives dans l’ergonomie

Dans notre schéma, il s’agit du passage de l’étape 4 à l’étape 5, à savoir : comment se passe la conceptualisation du
message reçu.
7.2.2.1 Comment définir les sciences cognitives ?
Les sciences cognitives sont un ensemble de disciplines qui étudient les activités liées aux fonctions cognitives, c'est-à-
dire la perception, les représentations, la mémoire, le langage, le raisonnement, la motricité ou l'apprentissage.
Ceci concerne à la fois les aspects humains de ces fonctions et ceux de la modélisation et de la simulation artificielle, en
tenant compte de la validité biologique de tels modèles. Classiquement, les champs disciplinaires intéressés par les
sciences cognitives sont :
- les Sciences Humaines : Psychologie cognitive & Linguistique pour l'étude de l'humain et du langage ;
- les Neurosciences : la Neurobiologie (de la Neuroanatomie à la Neurochimie) pour l'étude des
composantes biologiques ;
- les Sciences de l'Artificiel : mathématiques, intelligence artificielle (apprentissage, connexionnisme, etc.)
pour la modélisation.
- D'autres sciences peuvent encore s'ajouter à cette liste, telles la philosophie, l'épistémologie ou
l'anthropologie (parmi les sciences humaines), ainsi que la physique (pour son apport aux Sciences de
l'artificiel).
La création des champs d'étude comme la psycholinguistique (psychologie et linguistique), la neuropsychologie
(neurologie, psychologie et neurosciences) ou l'intelligence artificielle (informatique, logique et linguistique) marquait
déjà cette nécessité bienheureuse d'une vision plus globale en franchissant les frontières classiques entres les
disciplines.
Les sciences cognitives forment ainsi un domaine de recherche qui se nourrit de la confrontation des points de vue des
divers secteurs liés à l'étude de la cognition, pariant sur les possibilités d'interfécondation des visions et sur le
développement des études transcendant les diverses disciplines


7.2.2.2 Quelles inter-connexions avec l’ergonomie ?
Les sciences cognitives sont un préalable à la pratique d’une ergonomie efficace. Comment imaginer pouvoir travailler
sur l’étape 3 si l’on ne maîtrise pas les étapes 4 et 5 ?
Il est intéressant de constater que les formations d’ergonome (que ce soit en Europe ou aux Etats-Unis), ne sont que des
spécialisations auxquelles on ne peut postuler qu’après plusieurs années d’étude (en général 4).
Gardez donc en mémoire les préalables à l’ergonomie et n’oubliez pas que la question de fond reste « comment
l’utilisateur va-t-il appréhender/comprendre l’outil ? » et non comment faire quelque chose de beau !
7.2.3 Les différents domaines d’application de l’ergonomie

Ils sont tout ce qu’il y a de plus divers et varié. On peut dire que les premiers ergonomes étaient Ford et Taylor. Ce sont
les premiers à avoir complètement redéfini les conditions de travail pour améliorer la productivité. En décomposant le
processus de production, ils ont rendu la fabrication des voitures accéssible à tout le monde. Comme le dis le conseil de
la SELF, l'ergonomie peut être comprise comme " l'adaptation du travail à l'homme ".
Par la suite, on retrouve les ergonomes dans les domaines ou il a fallut optimiser les conditions de travail. C’est à dire
dans tous les milieux soumis à de forte contrainte de vitesse, de précision, de stress… On peut citer les aéroports, les
hôpitaux, les centre de service d’urgence, l’informatique (harware et software), l’automobile et parfois –mais plus
rarement– dans le domaine du mobilier.
7.3 L’ergonomie dans le développement d’IHM, en particulier dans les applications Web
7.3.1 L’« ergonomie de fond », un préalable à la mise à disposition de l’information
7.3.1.1 Importance et réalisation de l’organisation générale de l’application
Le challenge d’une application Web est de rendre accessible via un petit écran, des informations ou des produits qui
étaient parfois disposés dans des entrepôts de plusieurs centaines de mètres carrés. Il faut donc pouvoir retranscrire
l’appréhension visuelle qu’avait l’utilisateur en arrivant dans son entrepôt ou sa pièce. Pour cela, il est important de
rendre lisible la structure de votre site. Comment le faire ?
- avec un plan du site si la structure n’est pas suffisamment lisible, ou si le site est trop grand pour que
l’utilisateur ne puisse sans effort avoir une vue d’ensemble,
- avec une signalétique cohérente tout au long de l’application
Remarques :
- Notez que la structure « visuelle » que vous donnez à votre utilisateur n’est pas forcément calquée sur
l’architecture technique que vous avez déterminée au préalable.
- Dans le cas d’un site commercial ou vous cherchez à vendre quelque chose, des études ont montré que
vous avez le droit à 3 cliques et moins d’une minute pour « conquérir » le client !
7.3.1.2 Les spécificités du Web

Mode de fonctionnement des moteurs de recherche, importance du titre des pages et des mots clefs, présentation du
« profiling ».
- Se faire référencer :
Sans rentrer dans les détails, il est important de savoir comment rendre accessible son site sur le Web.
Il existe des moteurs de recherche (type « google » ou « alta vista » ou « Hotbot ») et des annuaires (type « Yahoo »).
Dans le premier cas, il n’y a aucune démarche à faire pour se faire référencer, ce sont des petits « moteurs » qui
parcourent le Web et référence les sites en fonction des mots clefs indiqués dans au début du code HTML et des mots
figurants dans le site. Dans le deuxième cas, il faut inscrire le site sur une liste, et son site est ensuite visité
manuellement ou toujours à l’aide de « robot » pour vérifier certains critères.
Quand on veut rendre un site accessible sur le Web, il est bien sur capital d’être bien référencé si on veut être visité. Les
termes que l’on choisit dans la définition de ses mots clefs sont déterminants.


Exemple d’en-tête :
Pour se faire référencer auprès des moteurs de recherche qui utilisent des petits robots fournisseurs, ils
utilisent les mots clefs suivants qui se trouve dans la balise du titre :
<META content="LIVRAISON DE COURSES A DOMICILE !! C-mescources vous permet de faire vos

courses rapidement. 6000 produits, de l'alimentation aux soins et beauté en passant par les produits
d'entretien maison." Name=Description>
<META content="livraison a domicile, achat en ligne, boutique on line, achat electronique, commerce en
ligne, courses sur internet, c-mescourses, livraison a domicile, livraison, vente a distance, magasin virtuel,
services casino, commande par internet, achat de vin, acheter, commander, recette, Casino, recettes de
cuisine, supermarche, alimentation, grande distribution, vente en ligne, boutique on line, commerce
electronique, commerce en ligne, livraison a domicile, acheter, commander, achat en ligne,BH35WXL"
lang=fr name=Keywords>
Ce texte est repris en totalité ou en partie par le moteur de recherche, mais il arrive aussi que ces derniers
utilisent l’intitulé noté dans les balises « title » de la page c’est à dire ici :
<TITLE>c-mescourses.com : Finies les commissions, faire mes courses de chez moi, se faire livrer €
domicile les produits alimentaires de consommation, packs d'eau, lait, conserves, couches.</TITLE>
Notons que la balise destinée aux robots précise la langue utilisée. Cela peut limiter le trafic généré puisque
le site ne répond pas à toutes les demandes dont la langue cible est précisée et n’est pas « français », mais
cela permet de mieux cibler l’internaute et de ne pas générer du trafic « non susceptible d’être client » qui
coûte chère en tuyau et en matériel le serveur devant pouvoir répondre à tout le monde en même temps.
(préciser si besoin). Notons que les accents ne sont pas utilisés dans les mots clés. (voir pour les autres sites)
Figure 79 Exemple d'entête utile au référencement d'un site
7.3.2 Mise en pratique de l’ergonomie des applications (Web)

7.3.2.1 La densité de l’affichage
 Pour chaque application, il faut trouver un compromis entre la densité d’informations affichées dans chaque
fenêtre et le nombre de fenêtres :
- une forte densité d’affichage entraîne davantage d’erreurs de la part de l’utilisateur et augmente le temps
nécessaire pour repérer une information ;
- une trop grande dilution de l’information dans un trop grand nombre de fenêtres gêne l’utilisateur dans sa
perception globale de l’application.
7.3.2.2 La disposition des éléments dans les fenêtres

 Pour regrouper les données (regroupement au sein de rubriques) et définir leur enchaînement (chronologie de
présentation des données affichées ou à saisir), tenir compte des habitudes de travail de l’utilisateur :
- fréquence d’utilisation,
- séquence d’utilisation dans la tâche en cours,
- importance dans le contexte (saisies obligatoires, optionnelles).
Présenter les groupes de données les plus importants selon le critère privilégié (par exemple, fréquence d’utilisation)
vers le haut de la fenêtre.
Remarque : si le travail de l’utilisateur s’appuie sur un formulaire papier, et si ce formulaire est bien construit, faire en
sorte que la disposition des champs dans la fenêtre soit proche de la structure du formulaire.
 Aligner verticalement les champs de saisie et/ou d’affichage avec leurs libellés ; la justification peut se faire de
trois manières :
- 1 : si les « libellés » sont de dimension sensiblement identique, justifier les champs et les libellés à gauche ;
- 2 : si les libellés sont de dimensions très variables, justifier ces libellés à droite et les champs à gauche ;
- 3 : il est également possible de disposer les libellés au-dessus des « champs de saisie » ; il faut alors les justifier à
gauche.


Nom : Profession :
Prénom : Ancienneté :
Age :
Figure 80. Cas 1 (libellés de dimension sensiblement identique)
Nom : Profession :
Prénom : Profession du
conjoint :
Adresse personnelle Nombre d’enfants à

(domicile) : charge :
Figure 81. Cas 2 (libellés de dimension différente)
Nom : Nombre d’enfants à charge :
Prénom : Profession :
Adresse personnelle (domicile) : Profession du conjoint :
[Morlais 01]
Figure 82. Cas 3 (libellés positionnés au dessus des champs de saisie)
 Attribuer un libellé à chaque donnée et à chaque groupe de données.

 Séparer les différentes catégories d’informations par des espaces et éventuellement par des boîtes de groupe (=
encadrements).
[Morlais 01]
Figure 83. Utilisation des boîtes de groupe (Word)
 Placer l’en-tête de groupe au-dessus de la boîte de groupe, et en incrustation dans le cadre s’il y en a un.
 Ne pas utiliser de boîte de groupe pour les boutons de commande.
 Ne pas utiliser systématiquement des boîtes de groupe quand il y a un en-tête : trop de cadres peuvent gêner la
lisibilité globale de la fenêtre. Utiliser alors des en-têtes de groupe sans représenter une boîte de groupe.
7.3.2.3 La présentation des listes et des tableaux

 Attribuer systématiquement un titre aux listes et aux tableaux ; ces titres permettront à l’utilisateur de se
repérer facilement et rapidement.



Si une liste ou un tableau est muni d’un ascenseur (car sa taille/format ne permet pas de voir l’intégralité de
son contenu), alors :
- Ascenseur vertical : les en-têtes de lignes de données doivent défiler mais les en-têtes de colonnes doivent
toujours rester visibles ;
- Acenseur horizontal : les en-têtes de colonnes doivent défiler mais les en-têtes de lignes de données
doivent toujours rester visibles.
- Respecter les alignements standards des traitements de texte :
- Placer les "libellés" en général à gauche,
- Placer les "numériques" à droite.
Eviter les alignements centrés (effets de vagues verticales).
 Les colonnes doivent être séparées par un double espace (1 caractère blanc x 2). Si cela ne peut pas être fait
(par manque de place), séparer les colonnes par des traits (lignes verticales).
 Comment organiser les éléments à l’intérieur d’un tableau/d’une liste (c’est-à-dire sur quoi se baser pour
établir la chronologie des données) ?
- adopter l’ordre respectant les habitudes de travail de l’utilisateur ;
- le cas échéant, utiliser l’ordre alphabétique ou numérique.
7.3.2.4 Les éléments textuels

 Utiliser le vocabulaire appartenant au domaine d’activité des utilisateurs.
 Utiliser des termes explicites et non ambigus. Faire des phrases (ou expressions) simples, c’est-à-dire
facilement compréhensibles par l’opérateur ; préférer les formes affirmatives.
 Indiquer les unités de mesure utilisées (en abrégé si elles sont connues de l’utilisateur).
 Eviter d’utiliser des abréviations, sinon, fournir chaque fois que c’est possible des abréviations bien choisies :
- utiliser uniquement celles qui sont le plus largement adoptées par les utilisateurs car ces derniers pourront
avoir rencontré certaines abréviations qui signifient autre chose ;
- préférer la contraction (omission des lettres internes) pour les mots courts ;
- préférer la troncature pour les mots longs (omission des lettres finales).
- Par souci d’homogénéité, ne pas utiliser de synonymes : désigner toujours un même objet ou une même
action par le même libellé.
 Lors de la création de listes d’éléments, on peut être confronté à des éléments de texte trop longs pour contenir
dans l’espace d’une ligne de la liste. Dans ce cas, supprimer des parties de texte dans le milieu du libellé et y
insérer des points de suspension, conservant ainsi le début et la fin du libellé de l’élément. Attention toutefois :
dans certains cas, il sera plus judicieux de conserver le début du libellé et de faire suivre ce dernier par des
points de suspension.
 Repérer chaque champ, liste, tableau, colonne ou groupe de données par un libellé. On distingue trois grands
types de libellés :
- le libellé de champ, à utiliser pour identifier une donnée affichée ou à saisir ;
- l’en-tête de colonne, à utiliser pour identifier la colonne d’un tableau ou d’une liste ;
- l’en-tête de groupe, à utiliser pour identifier un ensemble de données rassemblées sous la forme d’un
groupe.
7.3.2.5 La typographie
 Concernant la taille des caractères :
Taille minimum : 8 points ; des caractères de plus petite taille sont quasiment illisibles ;
Taille maximum : 16 points ; l’utilisation de caractères de plus grande taille gêne la lisibilité.
 Choisir la police de caractères en fonction de critères de lisibilité (éviter l’italique).
 Eviter d’utiliser plus de trois polices de caractères différentes dans une même fenêtre ou sur plusieurs fenêtres
affichées simultanément.
 De manière générale, utiliser une seule police de caractères dans un champ. Toutefois, il est possible d’utiliser
des codages particuliers (police différente, couleur, italique, gras, souligné...) pour différencier certains textes
tels que des mots clés, des liens, des libellés de champs de saisie obligatoire, etc.
 Pour tous les libellés (champs de saisie et champs d’affichage, option de menu, boutons d’option, titre, etc.)
utiliser une majuscule à l’initiale. Ne mettre donc en majuscule que la première lettre du premier mot du libellé
et aucun autre mot de ce libellé.
7.3.2.6 La couleur
La couleur peut être employée pour coder visuellement l’information : différenciation et identification des informations
affichées.
 La couleur ne doit pas être le seul moyen utilisé pour communiquer de l’information et ne devrait pas être le
seul élément qui distingue deux objets ; il doit y avoir d’autres indicateurs (libellés, forme, disposition) ;


appliquer ce principe surtout pour tenir compte des utilisateurs « daltoniens » ou « achromates » mais aussi
pour les écrans monochromes (même si ces derniers sont « rares » !)
 Choisir les couleurs en gardant à l’esprit que l’objectif est de faciliter la lisibilité des informations affichées.
C’est pourquoi certaines associations de couleurs doivent être évitées. Ainsi, essayer de ne jamais utiliser
ensemble :
- le rouge avec le bleu,
- le jaune avec le violet,
- le jaune avec le vert.
Pour le fond des fenêtres, éviter les teintes de rouge, de jaune et de ses dérivés (vert, orange, …). Privilégier plutôt le
gris pâle, sinon du bleu foncé.
Pour de l’information que l’utilisateur doit lire, éviter le bleu pâle (et les couleurs pâles en général).
 Homogénéité : au sein d’une même application et entre différentes applications destinées à un même groupe
d’utilisateurs, toujours choisir les mêmes “ codages couleur ”.
 Respecter les règles d’association conventionnelles entre la couleur et sa signification :
- vert : signifie que tout se passe correctement,
- jaune ou orange : attention, vigilance,
- rouge : alerte, danger, interruption.
 Eviter d’utiliser plus de 5 ou 6 couleurs différentes dans une même fenêtre (mais également au sein d’une
même application). Au-delà de 5 ou 6, cela entraîne une surcharge visuelle et l’utilisateur éprouve des
difficultés à saisir le rôle joué par la couleur au sein de l’application.
 Concernant les états sur les imprimantes noir et blanc : s’assurer que chaque couleur reste visible sur les
impressions (il doit y avoir correspondance entre les couleurs qui apparaissent à l’écran et les niveaux de gris
des sorties papier ; si le nombre de niveaux de gris disponible est insuffisant, prévoir des hachures).
7.3.2.7 Les icônes

Les icônes peuvent avoir deux fonctions :
- aider à identifier la nature d’une information, sous forme d’icône,
- représenter une action par une icône associée à un bouton de commande.
Exemple : l’icône loupe (ou jumelles) est associé au bouton de commande <Rechercher>.
 Attention, les icônes utilisées doivent être représentatives de l’action ou du concept que l’on souhaite
représenter, autrement dit, elles doivent être explicites. Il paraît néanmoins « prudent » de doubler les icônes
d’un libellé.
 Homogénéité : quand une icône est utilisée pour représenter quelque chose, la conserver pour l’ensemble de
l’application. Autrement dit, ne pas utiliser deux ou plusieurs icônes différentes pour désigner une seule et
même action ou un seul et même concept.
L’utilisation des onglets
 Utiliser les onglets pour éviter les successions de boîtes de dialogue ou un trop grand nombre de boutons.
 Eviter d’utiliser plus d’une rangée d’onglets, car la manipulation de 2 ou 3 rangées d’onglets est complexe.

Figure 84. Utilisation de plusieurs rangées d’onglets ( à ne pas faire !)
Quand le principe des onglets est utilisé, si ces derniers sont liés (dépendants), les boutons <OK> et <Annuler> doivent
être placés en dehors de l’onglet. Si les onglets sont indépendants, ces boutons doivent être placés sur chacun des
onglets : le bouton <Annuler> devient <Fermer> et la demande de confirmation devient facultative (<OK> facultatif).
 Centrer les libellés des onglets et les afficher sur une seule ligne.
 Aligner les languettes des onglets à gauche et les accoler les unes aux autres.


7.4 Approche générale sur le développement en équipe
Nous voulons à ce niveu présenter comment aborder un développment en équipe pour un projet (3D) et les méthodes et
mesures de base à mettre en place pour l’exécution d’un tel projet.
Note : Les techniques présentées pourraient tout aussi s’appliquer à un projet de SIG.
Pour obtenir une certaine qualité, il est indispensable de toujours travailler en équipe. Toutes les compétences ne seront
jamais cumulées par la même personne. On pourra dans un projet 3D retrouver par exemple, au moins un graphiste
2D/3D, un programmeur, un architecte/designer, etc.
Normalement, le chef de projet qui aura comme tâche d'organiser le développement et d'affecter les tâches, sera choisi
parmi les plus expérimentés. Il devra fire en sorte que les différents intervenants du projet travaillent ensemble de
manière coordonnée et sans gaspiller trop d'énergie ; soit en faisant la même chose que l’autre, soit en recommençant ce
que l’autre a déjà fait, même si intéressant.
7.4.1 Le développement en équipe

La production d’une application fait intervenir au moins 4 étapes principales :
[Lemasson]
1- La conception pour fixer les objectifs et les méthodes employées lors du projet.
2- L'implémentation pour réaliser les composants du projet.
3- L'intégration pour associer les différents composants du projet.
4- Les tests pour vérifier que le comportement des composants assemblés est bien celui attendu.
Etant donné qu’un développement est un processus de production numérique, les étapes ci-dessus ne s’enchainent pas
forcément toujours de la même façon. Car à tout moment, on peut effectuer des ajustements (personnage, décor,
interface…). Il est donc important de faciliter le « flux de travail », en sonsidérant le travail réalisé comme un liquide
ayant une source, une destination et un débit. On devra s’assurer que le travail de chacun des membres de l'équipe
démarre au bon endroit et finit bien là où il doit finir (dans votre application et pas à la poubelle), ceci pour assurer un
développement continu évitant de mauvaises surprises.
7.5 L'efficacité du développement point par point

7.5.1 Partage et sécurité des données
Il est fondamental que tous les développeurs aient accès à toutes les informations (ils doivent savoir comment et où y
acceder) : documents de conception, bibliothèque de matériaux, documentation d'un composant ou tout autre élément
du projet. Les données seront accessibles via un serveur (site internet, ftp, répertoire sur un réseau local) et devront
absolument être sauvegardés automatiquement à la fin de chaque journée de travail (n’oublez jamais que vos disques
durs peuvent cracher à tout moment !).
Les sauvegardes peuvent être gérées automatiquement à l’aide de logiciels tels que « Acronis » (payant) ou « Cobian
Backup » (gratuit). Les données ainsi copiées doivent toujours être au moins à 2 endroits différents. Vous pouvez vous
limiter aux 5 dernières versions de votre arborescence en fonction de la place disponible.
Il vaut mieux toujours travailler e local, et non sur votre serveur qui est supposé héberger la version développée acquise.
Comme modèle d’organisation, il est recommandé que le projet soit hébergé dans un répertoire simple, contenant au
plus 10 sous répeetoires, eux même ne contenant que 10 sous-répertoires et ainsi de suite. Veuillez à ce que tous les
répertoires aient un nom significatif.
Voici un exemple d’organisation d’'arborescence :
MonProjet
- DocumentsDeConception
 documents de conception : Références, scénario, design et ainsi de suite
- Ressources Virtools du projet
 composants du projet 3D, les textures, les modèles 3D les comportements de caméra ...
- Modélisations
 fichiers de conception de vos modèles 3D de votre projet, c'est à dire les fichiers 3DSMax
- Graphisme2D
 fichiers conception de vos graphisme, c'est à dire les fichiers photoshop ou autre.
- Compilation
 dernière version compilée du projet (fichiers binaires).
- Prototypes
 prototypes de vos composants.

7.5.2
Systèmes de gestion de versions


7.5.2.1 Présentation
Pour éviter de se tromper sur le bon fichier ou d’écraser un fichier plus récent, et bien d’autres situations, on peut faire
appel au système de gestion de versions ; qui facilitera la gestion de plusieurs versions d'un même fichier. Ainsi de
façon globale, chaque membre de l'équipe pourra récupérer la dernière version des fichiers du projet, modifier le fichier
de son choix et le livrer une fois le travail terminé.
Cette technique émane des systèmes UNIX et de CVS.
Pour obtenir des résultats de qualité et une meilleure orgnisation de votre projet, il est donc recommandé d’utiliser un
outil logiciel de gestion de versions. Ils aident en plus à simplifier et mieux organiser l’arborescence du projet. Il ne
nous encombre pas avec des versions physiques nombreuses du même fichier. Bien sûr, même si on dispose d'un unique
fichier, on peut à tout moment récupérer l'historique des modifications effectuées ainsi que n'importe quelle version
antérieure. On pourra même parfois effectuer la fusion de modifications entre plusieurs versions d'un même fichier.
Un exemple d’outil de gestion de version est « SVN » (grtuit, successeur de CVS), très performant, et compatible avec
n'importe quel type de fichier (pas seulement avec de la 3D).
Par ailleurs, on peut bloquer les modifications sur un fichier pendant que l'on travaille dessus. De cette manière, vous
pouvez empêcher un autre membre de l'équipe d'y accéder et de créer une version concurrente à la votre.
Il faut signaler ici que s’il arrive que si deux membres de l'équipe travaillent sur le même fichier, le chef de projet n'a
pas fait correctement son travail d'affectation des tâches.
Le système SVN peut fonctionner à distance. Les données de l'équipe qui sont centralisées sur le serveur distant
peuvent être récupérées via le net suivant différents protocoles, dont plusieurs sécurisés.
7.5.2.2 Application concrète : une infrastructure

Voici un exemple d’infrastructure technique à mettre en place pour votre projet 3D :
- un serveur distant pour :
 stocker votre projet sous la forme d'un répertoire géré par SVN
 effectuer les sauvegardes quotidiennes du projet vers une autre destination (CobianBackup)
- des postes de travail clients équipés :
 d'un répertoire local de travail où sera placée la dernière version du projet par SVN
 des logiciels de travail : 3dsMAx, Virtools, photoshop....
N’oubliez pas que lorsque l'équipe devient importante (>3), une petite amélioration peut consister à héberger sur votre
serveur le site internet de l'équipe. Réalisé sous la forme d'un site de news, il vous permettra d'assurer la communication
du projet, en interne et en externe.
7.5.3 Diviser pour mieux régner

Il est important de scinder en fichiers de plus petite taille, tout fichier contenant une grande quantité de données. Ceci
nous simplifie la manipulation du contenu de chaque sous fichier, et même sa maintenance. Ceci revient au découpage
en modules de plus en plus petits et faciles à contrôler pour des programmeurs.
Le fractionnement d’un fichier de données favorise également le travail collaboratif (plusieurs personnes travaillant en
même temps sur ces données).
Voici quelques critères pouvant vous amener à diviser un fichier :
- Le fichier est de plus en plus difficile à manipuler
- Plusieurs membres de l’équipe doivent intervenir régulièrement sur le contenu du fichier.
Une conséquence supplémentaire de cette mesure c’est le fait de pouvoir créer des composants indépendants et donc
réutilisables (pouvant être réutilisés dans un autre projet pour gagner en temps).
7.5.4 Optimisation des modifications au quotidien

En général les modifications sur le projet, une fois effectuées, engendrent des difficultés plus importantes en ce qui
concerne la repercution, l’intégration ou la diffusion. Car, parfois il faut parcourir plusieurs dizaines de menus pour
spécifier le nouveau fichier à charger à la place de l'ancien...
Il n’est pas bon de refuser d’apporter des modifications au projet. En effet, cela signifie que vous refuser d'améliorer
votre propre projet.
Une solution face à cela, c’est « l'intégration automatique ». Une fois mise en place, elle devient incontournable.
D’ailleurs, il a été démontré qu’à plus de 10 modifications, l'intégration manuelle prend toujours plus de temps que
l'intégration automatique. L’intégration automatique est donc nécéssaire, voir obligatoire pour ceux qui effectuent
beaucoup de modifications.
L'intégration automatique permettra de substituer facilement et instantanément deux versions d'un composant.
Elle optimise le temps consacré au projet, et rapproche beaucoup plus vite de la phase de test. Ce qui permet de détecter
rapidement les défauts et les corriger aussi plus rapidement. Tout cela contribue à la qualité.


7.6 Conclusion sur l’ergonomie
Comme nous avons pu le constater ensemble, la bonne ergonomie de ses applications ne tient pas à grand-chose, il
suffit de faire attention à un certain nombre de critères.
Notez tout de même que, la prise en compte de ces recommandations ne se substitue pas à la connaissance des
utilisateurs ni à la connaissance de leur travail ; elle ne remplace pas une analyse du travail, elle est simplement
complémentaire à un travail d’analyse de la cible. Ces recommandations sont particulièrement applicables pour les sites
Internet qui ne ciblent pas de public particulier.
Quand on élabore un Intranet ou une application spécifique, l’analyse du fonctionnement et du comportement des
utilisateurs peut amener à ne pas prendre en compte certaines recommandations, voir à faire autrement !


BIBLIOGRAPHIE
[AgileBlog] http://agile.blog.com, Comparaison entre méthodes agiles, (consulté le 10 oct 2010)

[Arbogast06] Sébastien Arbogast, MDA par la pratique, Date de publication : 18 mai 2006. http://sarbogast.developpez.com/
[Bezivin04] Jean Bézivin, Frédéric Jouault et Patrick Valduriez, On the Need
for Megamodels Preliminary Draft, OOPSLA 2004.
[Craig03] Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley, 2003
[DSDMWWW] http://www.dsdm.org, site de référence DSDM (consulté le 10 oct 2010)
[DSDMWWW2] http://capirossi.org/info/prj_mgt-4.htm, Processus agile DSDM (consulté le 10 oct 2010)
[FDDWWW] http://en.wikipedia.org/wiki/Feature_Driven_Development.htm, modélisation agile FDD (consulté le 10 oct 2010)
[FDDWWW2] http://www.agilemodeling.com/essays/fdd.htm, modélisation agile avec FDD (consulté le 20 jan 2009)
[MBTWWW] http://www.it-expertise.com/lalignement-de-lit-avec-les-besoins-metier/, tests, approch MBT (consulté le 20 fev 2011)
[FITwww12] http://fit.c2.com/, Outil FIT (consulté le 15 nov 2012)
[FitnesWWW10] http://fitnesse.org/, outil Fitnesse, consulté le 20 février 2010
[Fowler03] Martin FOWLER, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Paperback: 192 pages,
Publisher: Addison-Wesley Professional; 3 edition (September 19, 2003), Language: English, ISBN: 0321193687
http://martinfowler.com/books.html#uml
[Greenfield03] Jack Greenfield et Keith Short, Software Factories Assembling Applications with Patterns, Models, Frameworks and
Tools, OOPSLA, 2003.
[GreenWWW10] http://www.greenpeppersoftware.com/, outil Greenpepper, consulté le 20 février 2010
[Grossglauser07] Jean-Pierre Grossglauser, Introduction aux tests unitaires avec PHPUnit 3.1
Dernière mise à jour : 15/08/2007, http://jp-grossglauser.developpez.com/tutoriels/langages/php/phpunit/
[JunitWWW] http:// www.junit.org, site web de l’outil de test Junit (consulté le 10 oct 2010)
[TestNGWWW] http://testng.org/doc/book.html, site web de l’outil de test TestNG (consulté le 10 oct 2010)
[Lonchamp03] Jacques Lonchamp, Cours de Génie Logiciel, CNAM – CRA, Nancy, 2003
[KaiserCottet01] Claude Kaiser, LES RÉSEAUX DE PETRI, Reproduit avec la permission de Francis Cottet, ENSMA
[Lemasson] Guillaume Lemasson, Introduction au développement en équipe pour la 3D
Date de publication : 10/04/07, http://lemasson.developpez.com/
[LeiriosWWW10] http://www.leirios.com/, outil Leirios Test Designer, consulté le 20 février 2010
[Linsolas09] Romain Linsolas, Contrôler la qualité de ses projets avec Sonar, mise à jour : 13/08/2009,
http://linsolas.developpez.com/articles/sonar/
[MANTEL07] Gilles MANTEL, Test-Driven Requirements, octobre 07, Valtech Technology
[Meyer 90] B. Meyer, « Conception et programmation par objet, pour du logiciel de qualité » Inter éditions 1990.
[Morlais 01] Christian de la Morlais, Ergonomie des applications Web, Séminaire : DataWeb et NTIC, IUT FV de Bandjoun,
Département d’Informatique, 2001
[Nkenlif04] Marcellin Nkenlifack, Modélisation Objet et Développement d’un Atelier de Simulation des Automatismes Industriels
Hybrides, Thèse de Doctorat/PhD, ENSP, Univ Yaoundé1, Cameroun, 2004
[OMGWWW] www.omg.org (contenant les spécifications du métamodèle UML et le processus MDE) (consulté le 15 dec 2009)
[Parrend07] Pierre Parrend, Introduction à MDA : Principe, Date de publication : 04/12/2006
http://pparrend.developpez.com/tutoriel/mda-intro/
[ROQUES07] Pascal ROQUES, UML est-il soluble dans les méthodes agiles ?, octobre 07, Valtech Training
[Schach 92] Stephen R. Schach, Practical Software Engineering, IRWIN, Boston, 1992
[Schwaber04] Ken Schwaber, Agile Project Management with Scrum, Microsoft Professional, 2004.
[Scrum09] http://www.pentalog.fr/notre_demarche/methodologie_agile_scrum.htm, Méthodologie AGILE-Scrum
[Scott02] Scott Ambler , Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process, Wiley, 2002.
[Tellier] I.Tellier, Introduction à l'informatique, cours de L1 Miashs, Univ. Lille3
[TDRwww11] http://www.davenicolette.net/articles/changing-roles.html, méthode TDR (consulté le 28 juin 2010)
[Raise95] Chris Goerges et al., The RAISE Development method, Prentice Hall International (UK), 1995.
[wwwUMLdesign09] www.inventive-design.net/content/view/105/1/
site Web contenant un support UML2 (2009)
[ArcadiaCapella18] http://polarsys.org/capella/arcadia.html
site Web sur la méthide ARCADIA et l’outil de mosélisation « capella », consulté le 14 avril 2018
[wwwCapella18] https://fr.wikipedia.org/wiki/Capella_(ingénierie)]
site de présentation de Capella (Wikipedia), consulté le 23 juillet 2018
[MomoA-M18] Momo Arnaud, Implementation d’un Systeme de Mobile Banking Géo-spatialisé, Mémoire de fin d’études, Master2
IASIG, Université de Douala, nov 2018
[SAFE19] https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-collaborative/1443840-safe-la-methode-agile-qui-s-aligne-
sur-la-strategie-d-entreprise/
l’approche SAFE des méthodes Agiles (consulté le 15 oct 2019)
[WWWOpenTDD99] https://openclassrooms.com/fr/courses/4511316-perfectionnez-votre-gestion-de-projet-agile/4694996-progressez-avec-
les-techniques-tdd-fdd-et-bdd#r-4768562
Technique TDD (consulté le 15 oct 2019)
[wwwTestLog11] https://www.irif.fr/~eleph/Enseignement/2010-11/CoursTests.pdf, consulté le 27 oct 2019.
Autres sources
Outils logiciels
- Capella https://www.polarsys.org/capella/download.html
- Papyrus http://papyrus.sourceforge.net/
- CDT Eclipse https://www.eclipse.org/cdt/
- Enterprise Architect http://www.sparxsystems.com.au/products/ea.html
- MagicDraw http://www.magicdraw.com/
- MEGA Designer http://www.mega.com/en/product/mega_designer/

- ModelSphere
http://www.silverrun.com/modelsphere.html

- MyEclipse http://myeclipseide.com
- Objecteering http://www.objecteering.com/
- Poseidon http://gentleware.com/index.php?id=30
- PowerAMC http://www.sybase.com/products/developmentintegration/poweramc
- Rational Rose Data Modeler http://www-306.ibm.com/software/awdtools/developer/datamodeler/
- Together http://www.borland.com
- Visio http://www.microsoft.com/france/office/visio
- Visual Paradigm http://www.visualparadigm.com/product/vpuml/productinfovpumlse.jsp
- Visual UML http://www.visualuml.com/Products.htm
- Win’Design http://www.win-design.com/fr/
Communautés agiles
• agilemanifesto.org : Manifeste des méthodes agiles
• www.agilealliance.com : Agile Alliance
• pmdoi.org : Declaration of Interdependence
• xp-france.net : Communauté eXtreme Programing Francaise
• www.featuredrivendevelopment.com : Communauté Feature Driven Development
• www.sigmat.fr : Association sigmaT pour la Généralisation des Méthodes Agiles à Toulouse.
• www.agile-suiss.org : Communauté Agile Suisse
• www.agilequebec.ca : Communauté Agile de Québec
• www.agilemontreal.ca : Communauté Agile de Montréal
• www.extremeprogramming.org : Site de la méthode xp
• [www.adeli.org] : Association pour la maîtrise des systèmes d'informations
• www.rad.fr : Site historique de la méthode RAD
• www.embarcadero.com : Site de RAD Studio XE
• www.cui.unige.ch/ScDep/Cours/GenieLogiciel/index.html
• www.gpa.etsmtl.ca/cours/gpa77
• cui.unige.ch/ScDep/Cours/GenieLogiciel/
• www.cours.polymtl.ca/inf2300
• www.adeli.org


ANNEXE :
Le « Lean thinking »
L’utilisation du mot lean fait référence à l’organisation des chaînes de production d’industriels japonais qui ont révolutionné les
méthodes de production dans les années 80. Le plus fameux d’entre eux est le constructeur automobile Toyota, dont le système de
production est souvent représenté sous la forme d’une maison, le toit représentant les valeurs vers lesquelles tend Toyota.
Système de production de Toyota
Ces valeurs sont supportées par les deux piliers suivants :
- Just-in-time : notion de produire la bonne pièce à la bonne quantité et au bon moment. Sous cette appellation, on retrouve un
ensemble de méthodes tournées vers l’organisation de sa production selon un mode « pull », c’est-à-dire organiser sa chaîne de
production de manière à ce qu’une étape ne produise pas un élément tant qu’il n’est pas demandé par l’étape suivante. Cela revient à
piloter sa chaîne de production en fonction de son carnet de commande et plus en fonction d’une estimation de la demande et de la
capacité de production de sa chaîne. Cette organisation permet également de diminuer ses stocks au maximum, voire de les réduire à
zéro.
- Jidoka : notion d’empêcher un maillon de la chaîne de passer une pièce défectueuse au maillon suivant. Si un défaut est identifié sur
un élément dans la chaine de production, on arrête immédiatement la chaîne, on répare le défaut, et on s’assure qu’il ne se reproduira
plus, on redémarre ensuite la chaîne de production. Les défauts peuvent provenir des machines, des matières premières, de la
formation du personnel, etc.
Parmi les fondations, on trouve les concepts suivants :

- Kaizen : amélioration continue des processus, c’est-à-dire tendre vers la perfection en impliquant tous les acteurs depuis le top-
management jusqu’à l’opérateur.
- 5S : la gestion de l’espace de travail, c’est-à-dire garder un espace de travail propre, rangé, efficace.
Pour plus de détails, le lecteur pourra consulter l’ouvrage référence en la matière : The Machine That Changed the
World : The Story of Lean Production, de Womack, Jones, et Roos.

Langue

IngenierieSystLogiciel Nkenlif 2020-2021 Oct20 v10

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

IngenierieSystLogiciel Nkenlif 2020-2021 Oct20 v10

Titre original :

Transféré par

Droits d'auteur :

Université de Douala

« Master 2 IASIG 2020-2021 »

Pr Marcellin Julius A. NKENLIFACK

Version 10 (oct. 2020)

1.2 Un peu d’historique

• En 1983, on se rend compte que :

© Pr NKENLIFACK Marcellin [oct. 2020] Page 5 / 112

Les coûts de maintenance (lorsque cela se fait) dépassent ceux du développement

1.4 Le Génie Logiciel

1.5 Le processus logiciel, ou cycle de vie du logiciel

© Pr NKENLIFACK Marcellin [oct. 2020] Page 6 / 112

1.6 Représentations des modèles de développement

1.6.1 Modèle Exploratoire

Figure 1. Modèle exploratoire

résultats des tests -> Installation

Figure 2. Modèle en Cascade

© Pr NKENLIFACK Marcellin [oct. 2020] Page 7 / 112

1.6.4 Modèle en spirale

Figure 4. Modèle en spirale

© Pr NKENLIFACK Marcellin [oct. 2020] Page 8 / 112

Figure 5. Modèle Incrémental

1.7 Activités capitales du cycle de vie

© Pr NKENLIFACK Marcellin [oct. 2020] Page 9 / 112

- Mise en œuvre du processus et action qualité (qui ?, comment ?, quand ?)

© Pr NKENLIFACK Marcellin [oct. 2020] Page 10 / 112

1.8.4 Les démarches d’analyse

La démarche peut être orientée fonctionnelle, objet, modèles, mixte, etc.

© Pr NKENLIFACK Marcellin [oct. 2020] Page 11 / 112

1.9.3 Organisation du test

1.9.4 Le graphe de contrôle d’un programme

Figure 6 Quelques éléments de construction des graphes de contrôle des programmes

© Pr NKENLIFACK Marcellin [oct. 2020] Page 12 / 112

2- Exemple-Algo2 : conditionnelle simple

3- Exemple-Algo3 : double conditionnelle

© Pr NKENLIFACK Marcellin [oct. 2020] Page 13 / 112

© Pr NKENLIFACK Marcellin [oct. 2020] Page 14 / 112

* Voici la règle générale de preuve pour l’itération while :

 Approche fonctionnelle (« boite noire ») :

X/0 (-1) (0)

 Approche structurelle (« boite blanche »)

© Pr NKENLIFACK Marcellin [oct. 2020] Page 15 / 112

1.9.6 Processus de test de codes

© Pr NKENLIFACK Marcellin [oct. 2020] Page 16 / 112

1.9.6.2 Processus de test :

Figure 8. Processus de de développement dirigé par les tests

© Pr NKENLIFACK Marcellin [oct. 2020] Page 17 / 112

2.2 Spécifications à l’aide des Réseaux de Petri

Figure 9. Exemple de réseau de Petri marqué avec un vecteur de marquage M = (1,0,1,0,0,2,0)

© Pr NKENLIFACK Marcellin [oct. 2020] Page 18 / 112

Avant Franchissement Après franchissement

Mt = (1,2,1,0) Mt+1 = (0,1,2,1)

Figure 10. Un RdP (comportant 5 places et 5 transitions) / et Matrices

2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri

© Pr NKENLIFACK Marcellin [oct. 2020] Page 19 / 112

2.2.3 Graphes de marquages

Figure 11. Graphe de marquage

2.2.4 Limites des RdP et extensions des possibilités

2.2.5 Extensions et autres Outils proches

© Pr NKENLIFACK Marcellin [oct. 2020] Page 20 / 112

2.3 Spécification à l’aide se SADT & IDEF

2.3.2 Modèles SADT

En SADT, les 2 aspects sont duaux et examinés ensemble.

© Pr NKENLIFACK Marcellin [oct. 2020] Page 21 / 112

2.3.3.1 LES ACTIGRAMMES SADT/IDEF0