IngenierieSystLogiciel NK 2009

Université de Douala
The University of Douala
Académie Internet
Support de cours
Ingénierie des Systèmes

Logiciels
Dr. Marcellin Julius NKENLIFACK

(+237) 99 82 28 57
mnkenlif@yahoo.fr
Version Dec. 2009

Sommaire
SOMMAIRE................................................................................................................................................................................................................. II
1 RAPPELS DES CONCEPTS DU GENIE LOGICIEL..................................................................................................................................... 1
1.1 UN PEU D’HISTORIQUE ................................................................................................................................................................................. 1
1.2 CRISES : ....................................................................................................................................................................................................... 1
1.3 LE GENIE LOGICIEL...................................................................................................................................................................................... 2
1.4 LE PROCESSUS LOGICIEL, OU CYCLE DE VIE DU LOGICIEL............................................................................................................................. 2
1.5 REPRESENTATIONS DES MODELES DE DEVELOPPEMENT ............................................................................................................................... 3
1.5.1 Modèle Exploratoire .......................................................................................................................................................................... 3
1.5.2 Modèle Cascade................................................................................................................................................................................. 3
1.5.3 Modèle en V ....................................................................................................................................................................................... 4
1.5.4 Modèle en spirale............................................................................................................................................................................... 4
1.5.5 Modèle Incrémental ........................................................................................................................................................................... 5
1.6 METHODES ................................................................................................................................................................................................... 5
1.7 LA SPECIFICATION ....................................................................................................................................................................................... 6
1.7.1 Les 7 péchés :..................................................................................................................................................................................... 6
1.7.2 Les 7 caractéristiques d’une bonne spécification : ............................................................................................................................ 6
1.7.3 Les méthodes...................................................................................................................................................................................... 6
1.7.4 Les démarches d’analyse ................................................................................................................................................................... 7
1.8 TECHNIQUES DE TESTS................................................................................................................................................................................. 7
1.9 PROCESSUS DE TEST DE CODES .................................................................................................................................................................... 8
1.9.1 Problématique : ................................................................................................................................................................................. 8
1.9.2 Processus de test :.............................................................................................................................................................................. 9
2 METHODES SADT ET RESEAUX DE PETRI ............................................................................................................................................. 11
2.1 INTRODUCTION .......................................................................................................................................................................................... 11
2.2 SPECIFICATIONS A L’AIDE DES RESEAUX DE PETRI .................................................................................................................................... 11
2.2.1 Description ...................................................................................................................................................................................... 11
2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri ......................................................................................................... 12
2.2.3 Graphes de marquage...................................................................................................................................................................... 13
2.2.4 Limites des RdP et extensions des possibilités ................................................................................................................................. 13
2.2.5 Extensions et autres Outils proches ................................................................................................................................................. 13
2.3 SPECIFICATION A L’AIDE SE SADT & IDEF ............................................................................................................................................... 14
2.3.1 Présentation..................................................................................................................................................................................... 14
2.3.2 Modèles SADT ................................................................................................................................................................................. 14
2.3.3 SADT/IDEF0.................................................................................................................................................................................... 14
2.3.4 LES EXTENSIONS IDEF1/IDEF2................................................................................................................................................... 17
2.3.5 Avantages et Inconvenients SADT.................................................................................................................................................... 18
2.4 CONCLUSION .............................................................................................................................................................................................. 18
3 APPROCHE ORIENTEE OBJET ET UML................................................................................................................................................... 19
3.1 INTRODUCTION .......................................................................................................................................................................................... 19
3.2 LES CONCEPTS DE BASE: ............................................................................................................................................................................ 19
Abstraction ( ≡ définition d’une classe) .............................................................................................................................................................. 19
Encapsulation...................................................................................................................................................................................................... 20
Modularité........................................................................................................................................................................................................... 20
Hiérarchie (héritage)........................................................................................................................................................................................... 20
Le typage ............................................................................................................................................................................................................. 20
Simultanéité......................................................................................................................................................................................................... 20
Persistance .......................................................................................................................................................................................................... 20
3.3 CYCLE DE VIE :........................................................................................................................................................................................... 20
3.4 LES « MODELES »....................................................................................................................................................................................... 21
3.5 LE LANGAGE UML................................................................................................................................................................................. 21
3.5.1 La genèse d'UML ............................................................................................................................................................................. 21
3.5.2 Généalogie UML.............................................................................................................................................................................. 21
3.5.3 Notions usuelles ............................................................................................................................................................................... 22
3.5.4 Le formalisme d'UML ...................................................................................................................................................................... 22
3.5.5 La modélisation par UML................................................................................................................................................................ 24
3.6 CONCLUSION .............................................................................................................................................................................................. 40
4 MDE : MODEL DRIVEN ENGINEERING ................................................................................................................................................... 41
4.1 ÉVOLUTIONS .............................................................................................................................................................................................. 41
4.2 CONCEPTS DE BASE .................................................................................................................................................................................... 41
4.3 MDE ET LE GENIE LOGICIEL ....................................................................................................................................................................... 41
4.4 MDE ET UML............................................................................................................................................................................................ 42
4.5 ELEMENTS DE MDA................................................................................................................................................................................... 43
4.5.1 Les éléments de MDA....................................................................................................................................................................... 44
4.6 TECHNOLOGIE MDE .................................................................................................................................................................................. 45
4.6.1 Principe de MDE ............................................................................................................................................................................. 45
4.6.2 Description des deux catégories de transformations : ..................................................................................................................... 46
4.7 MDE ET LES « DESIGN PATTERNS »........................................................................................................................................................... 46
4.8 PROCESSUS MDE....................................................................................................................................................................................... 47
4.8.1 Langages de modèles ....................................................................................................................................................................... 47
4.8.2 Étapes de développement MDA........................................................................................................................................................ 48
4.9 METHODOLOGIE GLOBALE DE REALISATION D’APPLICATIONS ................................................................................................................... 49
4.9.1 Approche linéaire ............................................................................................................................................................................ 50
4.9.2 Approche incrémentale .................................................................................................................................................................... 51
4.10 PERSPECTIVES DE DEVELOPPEMENT ........................................................................................................................................................... 51
4.10.1 Les Mégamodèles............................................................................................................................................................................. 51
4.10.2 La Modularisation des Applications ................................................................................................................................................ 51
4.11 CONCLUSION .............................................................................................................................................................................................. 52
5 LES METHODES AGILES.............................................................................................................................................................................. 53
5.1 HISTORFIQUE DES METHODES AGILES : ...................................................................................................................................................... 53
5.2 LES PRINCIPES AGILES ................................................................................................................................................................................ 53
5.3 « MODELISATION AGILE » DES PROJETS ..................................................................................................................................................... 55
5.4 TEST-DRIVEN REQUIREMENTS (TDR)........................................................................................................................................................ 58
5.4.1 Lean sofware development............................................................................................................................................................... 58
5.4.2 Les étapes d’une évolution « lean » ................................................................................................................................................. 58
5.4.3 TDD (Test Driven Development) et TDR (Test Driven Requirement) .............................................................................................. 59
5.5 CONCLUSION :............................................................................................................................................................................................ 61
6 PROCESSUS DE DEVELOPPEMENT, OUTILS ET METRIQUES DE QUALITE................................................................................. 62
6.1 ARCHITECTURE DES APPLICATIONS............................................................................................................................................................ 62
6.2 PLACE DES OUTILS ..................................................................................................................................................................................... 63
6.3 QUELQUES FACTEURS POUVANT INFLUENCER LE CHOIX DE LANGAGES ET OUTILS : .................................................................................. 63
6.4 ENVIRONNEMENTS INTEGRES DE PROGRAMMATION .................................................................................................................................. 64
6.5 LES ATELIERS DE GENIE LOGICIEL ............................................................................................................................................................ 64
6.5.1 Qu'est ce qu'un atelier de génie logiciel ?........................................................................................................................................ 64
6.5.2 Les outils « CASE » (Computer Aided Software Engineering)......................................................................................................... 64
6.5.3 L'intégration d'outils CASE.............................................................................................................................................................. 65
6.5.4 Les différents types d'AGL ............................................................................................................................................................... 65
6.5.5 Standardisation des ateliers............................................................................................................................................................. 66
6.5.6 Ateliers et Cycle de vie..................................................................................................................................................................... 66
6.6 INTERET DE LA QUALITE D'UN LOGICIEL, ET DE SON CONTROLE A L’AIDE DES OUTILS APPROPRIES ........................................................... 66
6.7 LES « PROCESSWARES » :........................................................................................................................................................................... 67
6.8 CHOIX DE L’OUTIL DE DEVELOPPEMENT : .................................................................................................................................................. 67
6.9 OUTILS DE DEVELOPPEMENT « MDA » ..................................................................................................................................................... 68
6.9.1 AndroMDA pour Java (un générateur d’application) ...................................................................................................................... 68
6.9.2 Delphi Architecte ............................................................................................................................................................................. 70
6.10 OUTILS DE CONTROLE DE QUALITE ET DE TEST DE CODES ......................................................................................................................... 70
6.10.1 Contrôler la qualité de ses projets avec l’outil « Sonar » ................................................................................................................ 70
6.10.2 Tests unitaires avec « PHPUnit » (un OpenSource) ........................................................................................................................ 71
6.10.3 Utilitaires : ...................................................................................................................................................................................... 71
6.11 OUTILS DE TEST TDR AVEC LES METHODES AGILES................................................................................................................................... 71
6.12 AUTRES OUTILS.......................................................................................................................................................................................... 72
6.12.1 Le serveur d’application universel EAS : Enterprise Application Server [Sybase].......................................................................... 72
6.12.2 L’environnement de référence DOC (HP)........................................................................................................................................ 72
6.12.3 L’offre logicielle de Microsoft : ....................................................................................................................................................... 73
6.12.4 Quelques Logiciels de modélisation UML........................................................................................................................................ 73
6.12.5 LES OUTILS SADT.......................................................................................................................................................................... 74
6.12.6 Les outils de développement d’applications de base ........................................................................................................................ 74
6.12.7 L’accès aux données ........................................................................................................................................................................ 74
6.12.8 L’aspect gestion du projet................................................................................................................................................................ 75
6.13 LES QUESTIONS QUE L’ON DOIT SE POSER LORSQU’ON EST FACE A UN SYSTEME OU UN PROJET (PAR EXEMPLE DE TYPE CLIENT-SERVEUR)
75
6.14 ELEMENTS DE QUALITE LORS D’UN DEVELOPPEMENT ................................................................................................................................ 75
7 ERGONOMIE D’APPLICATIONS GRAPHIQUES (WEB), DEVELOPPEMENT EN EQUIPE ............................................................ 77
7.1 PROBLEMATIQUE DE L’ERGONOMIE : ......................................................................................................................................................... 77
7.1.1 Pourquoi aborder ce sujet maintenant ? .......................................................................................................................................... 77
7.1.2 Pourquoi accorder de l’importance à l’ergonomie de son site et plus généralement de ses applications ?..................................... 77
7.1.3 Présentation de l’intervention.......................................................................................................................................................... 77
7.2 QU’EST-CE QUE L’ERGONOMIE ? ................................................................................................................................................................ 77
7.2.1 Définition et complexité du concept ................................................................................................................................................. 77
7.2.2 La place des technologies cognitives dans l’ergonomie................................................................................................................... 78
7.2.3 Les différents domaines d’application de l’ergonomie..................................................................................................................... 79
7.3 LA PRISE EN COMPTE DE L’ERGONOMIE DANS LE DEVELOPPEMENT D’IHM ET PLUS SPECIFIQUEMENT DANS LE DEVELOPPEMENT
D’APPLICATIONS WEB ............................................................................................................................................................................................... 79
7.3.1 L’« ergonomie de fond », un préalable à la mise à disposition de l’information ............................................................................. 79
7.3.2 L’ergonomie des applications Web .................................................................................................................................................. 80
7.4 ETUDE : ANALYSE DES SUPERMARCHES « ON LINE » : FIDELISATION DU CLIENT PAR L’ERGONOMIE.......................................................... 84
7.4.1 Présentation du site c-mescourses.com............................................................................................................................................ 84
7.4.2 Présentation du site Houra.com....................................................................................................................................................... 84
7.4.3 Synthèse et Description d’un supermarché « on line » standard...................................................................................................... 84
7.5 CONCLUSION SUR L’ERGONOMIE................................................................................................................................................................ 85
7.6 APPROCHE GENERALE SUR LE DEVELOPPEMENT (3D) EN EQUIPE ............................................................................................................... 85
7.6.1 Le développement en équipe ............................................................................................................................................................ 85
7.6.2 Mesures pour gagner en efficacité ................................................................................................................................................... 85
7.7 L'EFFICACITE DU DEVELOPPEMENT POINT PAR POINT ................................................................................................................................. 86
7.7.1 Partage et sécurité des données ....................................................................................................................................................... 86
7.7.2 Systèmes de gestion de versions ....................................................................................................................................................... 86
7.7.3 Diviser pour mieux régner ............................................................................................................................................................... 87
7.7.4 Optimisation des modifications au quotidien ................................................................................................................................... 87
BIBLIOGRAPHIE ...................................................................................................................................................................................................... 88
Ingénierie des Systèmes Logiciels

1 Rappels des Concepts du Génie Logiciel
« 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)
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, schémas conceptuels, jeux de
tests, mode d'emploi, etc.
1.1 Un peu d’historique

• En 1936, Alan Turing (un brillant étudiant en mathématiques à Cambridge en Angleterre, âgé de 24 ans qui
cherchera à 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 (1970 – 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…)
• La Complexité du dévellopement des Logiciels étant également liée au matériel, on note é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
également é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.2 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
- Quelque 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)
© Dr. NKENLIFACK Marcellin Page 1 / 92

•
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
• Les pannes causées par le « bug de l’an 2000 » ont coûté environ 175 milliards de dollars aux entreprises du
monde, (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, 2a 2b …)
- 12% problèmes d’urgence résolus à la hâte
- 9% déboguages de programmes
- 6% à des changements de matériel
- 6% problèmes de documentation
- 4% améliorations de l’efficacité
- 3% autres…
Ces différents problèmes vont conduire à la création du Génie Logiciel.
1.3 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.4 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, 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, consistant à 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 de
l'ensemble des contraintes.
• 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.

• Conception détaillée, indiquer le comment, définir de façon précise chaque sous-ensemble du logiciel. Ces
deux phases déboucheent 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 (Program).
• 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, puis par la suite chez le 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.5 Représentations des modèles de développement
1.5.1 Modèle Exploratoire

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

1.5.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 Cascade


1.5.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 --------------------------------------------------------> Acceptation
Conception ------------------------------> Intégration
architecturale et tests
Conception --------> Tests
détaillé unitaires
Programmation
Codage
Figure 3. Modèle en V
Dans le modèle en cascade, 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.5.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, on détermine les objectifs du cycle, les alternatives, les contraintes en s’appuyant sur les cycles
précédents, ou sur une analyse primaire.
- Dans le premier tour : analyser les risques, évaluer les alternatives, proposer un maquettage.
- Dans le deuxième tour : s’occuper du développement et de la vérification de la solution retenue en cours.
- Dans le troisième tour : passer en revue les résultats du cycle précédent et planifier le cycle suivant.
Figure 4. Modèle en spirale


1.5.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émets
| Evaluation des
| incréments
| |
-------------------------------------------------
Figure 5. Modèle Incrémental
1.6 Méthodes
Dans l’Ingénierie d’un système logiciel, on retrouve les méthodes et outils servant tout au long du processus de
développement.
On peut y retrouver au moins 4 types de méthodes :
• Méhodes de 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 (mission ? objectifs ? règles ?)
- Une stratégie informatique (projets ? budgets ?)
- Une tactique informatique (faire plus avec moins)
- Une action informatique (exploitation courante)
• Méthodes de développement proprement 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
• Méthode de 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
• Méthodes d’assurance qualité
D’après l’AFNOR, 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, action, 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 client-fournisseurs
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.7 La Spécification
La phase la plus délicate dans le processus de développement du logiciel, c’est celle des spécification.
Bertrand Meyer [Meyer 90] a défini les 7 pièges qui guettent lors d’un procéssus de spécification, mais également les 7
mots clés de réussite.
1.7.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…)
- Contradiction : dans les séquences de spécification
- 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.7.2 Les 7 caractéristiques d’une bonne spécification :
- Conformité (aux besoins réel et non aux besoins supposés exprimés, souvent limités)
- Communicable
- Faisable
- Modifiables
- Validable
- Complète
- Cohérente
1.7.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 donc très bien 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
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 :
- Automates
- Logique (temprelle, modale)
- Algebre (algebre universelle, algebre de processus)
- Mixte
Un exemple : VDM (Vienna Description Method) : il 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.)
1.7.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
• Fonctions : transformations des données dans le système
• Dynamique : changements dans le temps, contrôles (ex :modéliser les données en fonction du temps)
La démarche peut être fonctionnelle, objet, modèles, mixte, etc.

• Approche Fonctionnelle
Les données et les fonctions sont modélisées séparément.
Exemples: SADT-SART, etc.
• Approche Objet
Les données et les fonctions sont encapsulées dans les mêmes « boites » qui dialoguent entre elles (les objets) par
envoi de messages.
Exemples: Booch, HOOD, OOA, OMT, UP, etc.
• Approche Modèles
Voir MDE (Model Driven Ingineering) plus loin.
• Approche Agiles
Voir méthodes Agiles plus loin.
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.8 Techniques de Tests

Les chiffres montrent que dans un procesus de développement, la phase de test coute 40% de l’ensemble (avec 40%
pour l’analyse et 20% pour le codage). Les programmes de tests 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 retrouve :
- les tests de vérification : il s’agit de s’assurer que le système est conforme aux spécifications définies
initialement.
- 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.
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.
• Un gros projet doit absolument avoir un responsable des tests.
• 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…)
• Durant les tests, les procédures doivent permettre d’augmenter les chances de détection de problèmes.
• Dans une approche fonctionnelle :
- Proceder à des tests aléatoires (statistiques) : elle permet des tirages selon une loi de probabilité qui peut être
uniforme ou basée sur une distribution aléatoire (poisson, gauss…)
- Les données de test doivent être choisies judicieusement !
- Ne pas se limiter uniquement aux données « normales » ! mais prévoir des données sensibles pouvant entraîner
des exceptions.
o tests aux limites (valeurs frontières)
o tests hors limites (monkey)
o cas nominaux
Exemple :
-2 0
X/0 (-1) (0)
• 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. Elles doivent être 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 (exi.
JTests, assert etc.)
1.9 Processus de test de codes

1.9.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/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 tracas que cela implique pour
vous et vos utilisateurs finaux.
1.9.2 Processus de test :

Nous présentons ci-après un processus et quelques conseils vous permettant d'utiliser les tests unitaires dans vos
projets PHP.
[Grossglauser07]
Figure 6. 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.


Travaux dirigés :
Exercice 1 : Qu’est ce qui d’après vous pourait faire en en sorte qu’on ne maîtrise pas la fabrication du
logiciel ? donner des exemples concrets.
Exercice 2 : Proposer un plan qualité pouvant permettre de contrôler les phases du cycle de développement
de logiciels dans une structure.


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 7. 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.
[KaiserCottet01]
Figure 8. 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- y 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 : Les formlismes 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 marquage

L'évolution temporelle d'un RdP peut être décrite par un graphe de marquage 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.
[KaiserCottet01]
Figure 9. 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 Progrmmables 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
(Structured Analysis and Design Technique - Icam DEFinition method)
2.3.1 Présentation
SADT est une méthode graphique établie par Douglas T. ROSS (Softech) vers 1974. 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).
ICAM établit ensuite d'autres modèles pour les aspects informationnels (IDEF1) et dynamiques (IDEF2).
SADT reste encore plus répandu que SA/RT, qui lui est à présent préférée pour une meilleure prise en compte des
aspects dynamiques.
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).
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 logiciel.
La description comprend une série de « planches ». Chaque planche est la décomposition en sous-fonctions d'une
fonction du système. La 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 viset à :
- 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.
Chaque « boite » peut-être à nouveau décomposée en un diagramme plus détaillé (Zoom).
Au niveau général se trouve le diagramme de contexte (niveau –1), montrant les sources, les destinations.
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 2.
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é
- 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 10. 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 11. 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 12. 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.
Les flots
Les flots de données sont échangés entre les fonctions.
commandes
sorties
entrées
Fonction
Axx
mécanismes
Figure 13. 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èse (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 14. 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'en est pas la traduction inversée, ce qui pose 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 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, DCQ, 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
L'ICAM n'a pas 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 INFORMATIONS)

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 15. 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 :
Entity flow network submodel

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.
Les méthodes de travail

Une méthode de travail similaire à celle décrite dans IDEF0 est décrite.
2.3.5 Avantages et Inconvenients SADT

Avantatge :
- aspect dynamique limité
- cohérence entre actigramme et datagramme parfois difficile
- pas ou peu de synchronisation
Inconvenients :
- 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 motivation 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 et parmi
elles, les méthodes objets (orientées objet) et leurs techniques d’analyse et de conception appropriées.
Pourquoi parler de Programmation Orientée Objets (POO) ?

La complexité et la taille des projets nécessite des outils de programmation nombreux et perfectionnés pour mener à
bien les applications dans les meilleurs délais.
En fait, les langages à 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 la solution la plus souple et offre plus de
perspectives 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 () -…
Stopper ()
Démarrer Rouler Stopper
Figure 16. 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’abstraction :

- 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)
C’est un « classement » ou ordonnancement des abstractions. En capturant la relation de généralisation, il facilite
la modélisation des objets et la modularité du code. Il 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 pendant
longtemps).
3.3 Cycle de vie :

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 objets
Figure 17. 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 langages de modélisation (à l’instar de 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 fournissent des exemples.
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.
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.
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 (James 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 James 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'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é 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 à 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.), travaille pour la description
d'UML version améliorée.
UML n'est pas un standard de fait mais un standard « industriel » de l'OMG (novembre 1997) au même titre que
CORBA par exemple. Ceci étant, vu le succès initial de ce langage, il commence à devenir un « standard de fait ».
3.5.2 Généalogie UML

[wwwGeneal01]
Figure 18. Généalogie d'UML


Evolution des version 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.2 Juin 19987
UML 1.X 1999-2002
UML 2.0 Janvier 2005 Soummissiopn à l’OMG en 2003
UML 2.1 2006 Définition en cours par une commission de révision
Tableau 1. Historique Evolution des version d’UML
3.5.3 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 : DESCRIPTION D’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 continu 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.4 Le formalisme d'UML

Vous trouverez tous les détails sur les spécifications du métamodèle UML dans [OMGWWW].
Figure 19. Métamodèle UML
Le formalisme UML 2.0 est composé de 13 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.
UML se décompose en plusieurs 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, ces modèles sont
utilisés dans plusieurs types de diagrammes. Exemple d'éléments : cas d'utilisation (CU ou cadut'), classe,
association, etc.
3.5.4.1 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 les acteurs du système. 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 défini dans UML actuellement.
3.5.4.2 Les diagrammes

[Fowler03]
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 méthodes.
En plus des paquetages et des notes, trois familles de diagrammes composent le langage UML. Les 13 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 :
→ Diagrammes Structurels ou Diagrammes statiques (Structure Diagram)
• Diagramme de classes (Class diagram) : représentation de la structure statique en terme 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 message.
• 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) :
• Diagramme de structures composites (Composite Structure Diagram) :
→ Diagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagram)
• 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’état ; 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’action ; 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 Diagram) :
• 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) : représentation des interactions où l'aspect temporel est mis
en valeur.
Aux différents états d'élaboration d’un projet correspond l'utilisation de certains diagrammes. Par contre, les
diagrammes des cas d'utilisation se retrouveront à tous les stades du projet.
3.5.5 La modélisation par UML
3.5.5.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 20. 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 ce cas, 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.
• Utilisez la généralisation quand vous décrivez une variante au comportement standard et que vous voulez
simplement la décrire.
• Utilisez extend quand vous décrivez une variante au comportement standard et que vous voulez explicitement
indiquer son activation, en déclarant des points d’extension dans le cas d’utilisation de base.


Simuler
Convertir Fonction
Vitesse
Include
Use
Stabilité Include
Use Afficher
Résoudre équations Include solutions
précision
Include
Use
Include
Erreur
Figure 21 Diagramme
ActVenSys de cas d’utilisation de la simulation des systèmes continus
TranDirSys Include
Tracer courbes
Envoyer
Système externe
(séquentiel)
[Nkenlif04]
Figure 22. Un exemple de Diagramme de cas d’utilisation
Figure 23. Relation d’extension
Cas d’utilisation « Métier » et « Système » :

Vous entendrez souvent parler de « cas d’utilisation système » et « cas d’utilisation métier ». Les termes peuvent ê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.
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.
3.5.5.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 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 classe décrit les types d’objets qui composent le système et les différents types de relations statiques
qui existent entre eux. 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.
[Fowler03]
Figure 24. Notations de diagramme de classes
Quand utiliser les diagrammes de classe ? [Fowler03]

Les diagrammes de classe 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 classe 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 classe

(package)
SYSTEM
SEQUENTIEL
0 .. *
Est décrit par
1
(package)
RECVENSYS
GRAFCET
RECEPTIVITE LOGIQUE
RECEPTIVITE TEMPORELLE
Appartient à
RECEPTIVITE
1 .. * GRAFCET
Conditionne
1 .. * 1 .. *
0 .. 1
0 .. 1
1 .. *
1 ETAPE
TRANSITION
1 .. * 0 .. *
0 .. *
MACRO-ACTION
Décrit
LIEN COUPLAGE SEQ

1 .. *
ACTION SIMPLE
LSAUT ETAPE LIEN
ACTION
LIEN EXCLUSIF
ACTDIRSYS
LIEN SELECTIF
ACTION DETAILLEE
LIEN PARALLELE
LIEN SIMPLE ACTION MULTIPLE
[Nkenlif04]
Figure 25. 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 poinst de vue différents quand vous créez un diagramme de classe (ou n’importe quel
modèle), mais la différence est plus perceptible avec les diagrammes de classe.
• 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 peu, prendre en compte
le logiciel qui pourrait le mettre en œuvre et donc être considéré comme indépendant du langage (c’est ce que Cook
& Daniels appellent 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.
Il est fondamental de comprendre de quel point de vue on se place, tant pour la création que pour l’interprétation des
diagrammes de classe. Malheureusement, la délimitation entre eux est quelque peu floue, et la plupart des modélisateurs
ne se préoccupent pas de dissiper la confusion.
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.
Diagrammes d’objets
Un diagramme d’objet est une représentation instantanné 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.
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 nassez « 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 similitides. 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.
Visibilité de Classe
Figure 26. Notation de la visibilité de clase


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]
Figure 27. 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).
Figure 28. Composition , agrégation, navigabilité, contraintes
Associations et attributs dérivés

Les association 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 29. 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.
Figure 30. 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 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 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 met à 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 qu’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.
Figure 31. Associaions qualifiées
Du point de vue des spécifications, cette association qualifiée impliquerait une interface telle que la suivante :
class Commande
{
public LigneCommande getLigne (Produit unProduit) ;
public void ajouterLigne (Nombre montant, Produit unProduit) ;
…
}
Ainsi, tout accès à une ligne donnée nécessite un Produit comme argument. Une multiplicité de 1 indiquerait qu’il doit y
avoir une ligne pour chaque Produit, et une multiplicité de * que l’on peut avoir plusieurs Lignes de Commande par
Produit, mais que l’accès aux lignes est toujours indexé par Produit.
Du point de vue implémentation, cela suggère l’emploi du tableau associatif ou d’une structure de données similaire
class Commande
{
private Map _lignes ;
…
}

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.
Personne * Employeur Entreprise

0..1
Emploi
Période : IntervalleDate
Opération ( )
Figure 32. Exemple de Classe-Association
Une autre façon de représenter cette information consiste à faire de Emploi une classe à part entière. Les multiplicités
doivent être modifiées en conséquence.
Dans ce cas, 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 33. Transformation d’une classe-association en classe à part entière
Classe 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.
Ser <Employe> employeSet ;
Voici le formalisme de representation d’une classe paramétrable en UML:
Set T
Paramètre de
Période : IntervalleDate Classe Paramétrable
Inserer ( )
Supprimer ( )
Figure 34. 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.5.3 OCL : gestion des Contraintes sur les attributs et associations

[Warmer99]
Quand vous tracez un diagramme de classe, 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 également 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
* 1 VitesseMaxVide
VitesseMaxCharge
{ Vehicule.Charge <= TypeVehicule.ChargeMax }

[RoquesVallee01]
Figure 35. 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.
A propos de OCL
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). OCL limite
les ambiguités du langage naturel (bien que lui étant proche), et se rapproché bien du langage technique (langage
mathématique, informatique…)
Exemple de contrainte :
– 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.5.5.4 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, exprimées en langage naturel (et encadrées de crochets).


X =0 Y= 0 côté = 0 Numéro = 0 active = false
Cliquer sur le bouton “ étape ”

Changement du pointeur de la souris
Cliquer dans la zone de dessin
Entry : X = e.x Y = e.y

Côté = valeur numéro = Auto
Do : Dessiner ( )
Double cliquer
Cliquer sur “ étape ” Sélectionner type d’action
Saisie paramètres de l’action
Entry : X = e’.x Y = e’.y Do : stockage des paramètres

Do : marquer ( )
On : supprimer ( ) copier ( )
Cliquer bouton simulation
Double cliquer
Bouton gauche Condition : transition précédente
Sélectionner type d’action
enfoncé franchie ou pas de transition
Saisie paramètres de l’action
Entry : X = e’.x Y = e’.y

Do : déplacer ( ) Entry : active=true
Do : activer ( ), executer action ( )
Cond : Transition suivante

franchie ou pas de transition
Entry : active = false

Do : desactiver ( )
[Nkenlif04]
Figure 36. Un exemple de Diagramme d’états – transitions ( classe ETAPE d’un système séquentiel)
Figure 37. 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
Activité 3 Activité 4
[Garde : si oui]
[Sinon] Jonction
Fusion
Activité 6
Figure 38. Diagramme d’activité (illustration de fusion, jonction, débranchement et branchement)
3.5.5.5 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.
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 39 Séquencement d’opérations entre les macro-objets d’un système hybride (l’ascenseur)

Diagramme de Collaboration

Les diagrammes de collaboration 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
opération, 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 10. tracer()
la fonction, la simulation se 9. stabilité ( )
rapidité ( )
résume à convertir la fonction
précision ( )
et à appeler la résolution de erreur ( )
l’équation qui est décrite ci- 10. solutions
dessus
[Nkenlif04]
Figure 40. Un exemple de Diagramme de collaboration : simulation des systèmes continus
Diagramme de communication :
Figure 41. Exemple de diagramme de communication


3.5.5.6 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.
• Le 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.
Figure 42. Exemple de Diagramme de composants
3.5.5.7 La modélisation de la distribution et du déploiement

• La modélisation de déploiement permet de représenter la façon dont l'application est distribuée dans un 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


[Fowler03]
Figure 43. Diagramme de déploiement
3.5.5.8 Diagramme de packages
Nom de parquetage 1
Dépendance (nommage optionnel)
Stéréotype Note textuelle

Nom de Paquetage 2 (contrainte textuelle
Figure 44. Dépendance, note


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 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), code, APIs, ...).
Nous allons présenter le Développement Orienté Modèle (MDD - Model Driven Development, ou MDE - Model
Driven Enginering), 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.
4.1 Évolutions
L’OMG (Object Management Group) est un consortium développant et promouvant la théorie et la pratique des objets
distribués. 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. Les standards de réalisation étant
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 de vie du logiciel (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.
4.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.
4.3 MDE et le génie logiciel
On a failli assister à une « Mort » des logiciels due à de multiples difficultés :

● Lors de l'évolution
● Ajouts de fonctionnalités
● Correction de bugs
● Trop de rustines (« bug patch »)
● Application
● Peu cohérente
● Peu compréhensibles
● Evolution difficile
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 45. 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
● Réutilisables
● Au niveau du cycle de vie
● Prototypage rapide
● Concentration sur
● Conception globale
● Conception unitaire
● Développement minimal
● Evolution
Figure 46. Rappel du Cycle de vie (basé sur les modèles)
● Au niveau de la modélisation
● Diagrammes de classes
● Abstraction
● Fonctionnalités, systèmes, etc.
● Classes du programme final
● Intégration des « design patterns »
4.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 paliant aux insuffisances du paradigme Objet, qui s’est imposées en génie logiciel
depuis les années 1980. Ce paradigme n’est pas ammené à remplacer l’approche Objet, mais à la compléter.
• L’approche UML et le développement Objet considère 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
- 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).
- 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éneration de code
La figure suivante montre ces deux approches : Classes et Modèles
Figure 47. 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.
Figure 48. La méta-programmation
4.5 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 (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 transformation, 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.
4.5.1 Les éléments de MDA

Ils sont présentés dans la figure suivante
Figure 49. Elé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èce 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èle 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]).
4.6 Technologie MDE

. MDE engloble 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é par ailleurs, 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.
En effet, les avantages que retirent les entreprises sur le MDE sont principalement
• 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.
4.6.1 Principe 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 transformation
- 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.
Pour le dire brièvement, l'interopérabilité prend 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, 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
D'autres viendront s'ajouter à cette liste.
.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. Le 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 terme 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
PIM
PSM
CODE
Figure 50. ·MDA : PIM vers PSM
4.6.2 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.
4.7 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 des é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 aujourd’hui.
● Modèles pré-existants
- Déjà validés
- Facilitent la modélisation
● Manipulation simple des modèles
- Réutilisation
- modifications


4.8 Processus MDE
Le principe est illustré à la figure ci-après.
[Parrend07]
Figure 51. Processus 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 52. Les Transformations MDE
4.8.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).
IV-A-1 - Les niveaux de méta-modèles
On définit quatre niveaux de méta-modèles :
[Parrend07]
- 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

Figure 53. Architecture du métamodèle MDA
4.8.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, 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, les 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
[Parrend07]
Figure 54. Chaaî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).
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 Relationnelle, 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. Nous verrons comment faire la
traduction.
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.
● 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 à fin 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
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èle 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èle 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 de Sun. Elle fait partie de l'outil NetBeans
Figure 55. Les outils dans la chaîne de transformations
4.9 Méthodologie globale de réalisation d’applications

Au niveau du processus de développement, le MDE doit apporter des gains de productivité et des gains de prédictabilité
[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 56. Exemple de schéma de support du processus MDE
Le processus complet est présenté à la figure ci-dessous
Figure 57. Processus complet MDE
Une méthodologie de référence est véritablement nécessaire pour rendre MDA réellement opérationnel.
Nous présentons ci-dessous, une méthode de développement d'application 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.
4.9.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

4.9.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 ses é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és 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.
4.10 Perspectives de développement

4.10.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 ou 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 concurente 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.
4.10.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].
L’auteur 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 êetre 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 developpement 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 à long terme, qui ouvre des perspectives méthodologiques immédiates.
Comme intérêt, cette Méthodologie de conception logicielle est innovante.
4.11 Conclusion
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 domaine 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écessite, 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 Les méthodes Agiles
Les projets informatiques possèdent de plus en plus des aspects très complexes. Ceci est du à 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, ...).
- ...
Ces facteurs sont en quelque sorte intrinsèques 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, langage(s), code, APIs, ...) .
Dans le cadre de l’Ingénierie des logiciels, deux « écoles » s’affrontent actuellement :

• Ingénierie basée sur les modèles ou Model-Driven, préconisée par l’OMG (consortium composant plus de 1000
sociétés), 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.
5.1 Historfique des méthodes agiles :

Les méthodes dites Agiles 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, é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 JUnit, Ken SCHWABER et Jeff SUTHERLAND, fondateurs de Scrum, Martin Fowler avec la sociétés
« Thought Works » et le serveur d’intégration continue Cruise Control.
Ces 17 personnalités qui viennent toutes d'horizons différents ont réussies à 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 », 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.
5.2 Les principes agiles

L’idée de base est de faire face efficcement 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. L’objectif principal ici est de satisfaire le client, et non un contrat établi préalablement. Pour réduire ce risque de
fossé au stricte minimum, les méthodes agiles prônent l'incrément et l'itération.
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).
Figure 58. Classification des valeurs des méthodes agiles et classiques


Le terme AGILE regroupe un ensemble de méthodes, parmi lesquelles XP (eXtreme Programming).
Ces méthodes éssayent aussi d’assembler des atouts majeurs des approches RUP (Rationl Unified Process) et RAD
(Rapid Application Development), tout en gardant une une souplesse de planification et d’adptation au changement.
Figure 59. Histogramme de mise en perspective des méthodes agiles, RUP et RAD
5.3 « 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 réalisme et
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ût. 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 revus 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 adapté et é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éoccupation
à cœur, tout les jours : livrer et améliorer ses façons de faire, tout les jours.
Les méthodes agiles privillégient le développement à itération courte (XP, Scrum, Lean ...)
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 se forcer à 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 clés 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 dans les 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 transmettre 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.
• À intervalle régulier, 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.
[Scott02]
Figure 60. Principes de la modélisation agile
La pratique de agile est également issue en partie de XP.
Figure 61. Pratiques de la modélisation agile
Agile s’apuie à 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 projet et des pratiques, ainsi une bonne collaboration et communication avec le client s’en suit.


[Schwaber04]
Figure 62. Processus de développement utilisé (SCRUM)
Craig Larman et la modélisation agile
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 qui encouragent la créativité
Larman encourage l’utilisation de feutres et paperboards, plutôt que de progiciels couteux et lourds
- 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 63. Modélisation de projet selon Craig Larman
5.4 Test-Driven Requirements (TDR)

La gestion des exigences dirigées par les tests, ou Test-Driven Requirements (TDR), représente l’étape ultime dans
l’adoption d’un processus de développement dit « lean » (dérivé de la méthodologie "Toyota Way").
Les pratiques du TDR trouvent leur source dans la transposition du « lean thinking » au monde du développement
logiciel.
5.4.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 défauts 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 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.
5.4.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 ci-dessous illustre ainsi l’organisation des nombreux projets d’aujourd’hui ayant entrepris le déploiement de
méthodes agiles.
[MANTEL07]
Figure 64. 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.
5.4.3 TDD (Test Driven Development) et TDR (Test Driven Requirement)

Le test-driven development est une pratique agile issue de l’Extreme Programming, dit XP. Les trois étapes du TDD
sont les suivantes :
1. Ecrire un test et s’assurer qu’il échoue, cela permet de garantir l’intérêt du test unitaire
2. Ecrire le minimum de code qui va faire réussir le test
3. Améliorer le code en s’assurant que le test continue de réussir
Revenir à l’étape 1 avec un nouveau test unitaire
Les tests unitaires, si importants soient-ils, présentent plusieurs limitations. Tout d’abord le test unitaire est…
« unitaire » : son but est de vérifier 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 était 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.
5.4.3.1 Appliquer les principes du TDD au niveau fonctionnel

L’utilisation du logiciel FIT (http://fit.c2.com/) nous permet d’effectuer des tests fonctionnels sans avoir à attendre une
version du logiciel exécutable, ce qui représente un confort immense 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.
5.4.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 la MOA (Maître d’Ouvrage, MOE- (Maître d’Oeuvre) 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 logiciel avant la livraison. Il faut
quand même compter quelques ajustements au cours de ces 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 se révèle trop 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.
5.4.3.3 Eliminer les gâchis avec le MBT (Model Based Testing)

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.
Figure 65. L’approche MBT

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é.
5.4.3.4 Usine logiciel

A court terme, il est indispensable de se doter d’une usine logiciel 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 logiciel 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.
5.4.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 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.
(http://www.davenicolette.net/articles/changing-roles.html).
5.5 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’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.


6 Processus de Développement, 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

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

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

Interfaces de service (BusinnessObjects)
Ordonnancement métier
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 66. Architecture 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étier 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 ce 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 cette technique de développement multicouche :

- 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.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
o spécification de la qualité requise
o spécification des règles de construction
o test et mise au point des programmes et applications
o qualimétrie du logiciel
o gestion de la qualité du logiciel
• Conduite des projets
o Evaluation des charges, coûts et délais
o Planification des tâches
o Suivi et gestion des projets
o Gestion de la documentation
o 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 code
6.3 Quelques facteurs pouvant influencer le choix de langages et outils :

• 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 modules? compilation séparée? (e.g. Pascal vs Ada)
• Environnement de développement
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 (en principe) 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.4 Environnements intégrés de programmation

Dans un tel environnement, on retrouvera plusieurs outils intégrés (travaillant ensemble) autour d’un langage et
conçus pour travailler ensemble en 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.
6.5 Les Ateliers de Génie Logiciel
6.5.1 Qu'est ce qu'un atelier de génie logiciel ?

Un AGL (Atelier de Génie Logiciel) 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, et dans tous les cas, sont bien loin d'être totalement automatisables. L'informaticien a encore de belles
années de travail devant lui avant d'être supplanté par des AGL...
6.5.2 Les outils « CASE » (Computer Aided Software Engineering)

Les AGL intègrent différents 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 pour la mise en forme (pretty-printers), la génération de tests, la génération 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.5.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 devrait également gérer 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 sous
Unix ou 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 relève un peu de l'utopie !!!).
6.5.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, ...
WinDev est un environnement de développement.
D’autres environnements de développement existent sous Unix/Linux qui intègre 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 environnement, 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.5.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.5.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 67. Structure d’un EIPL (Environnement Intégré de Production de Logiciel)
6.6 Intérêt de 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, et en Java en particulier, la qualité d'une application va être directement liée à
la qualité du code. 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 sans
qualité, mais qu'il n'est pas possible non plus de faire de la qualité sans 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 jours: livrer des pièces et trouver de meilleures façons de
le faire. Le second point étant bien plus important que le premier. Ça 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 68. 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.7 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.8 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é 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 supports technique offert ?
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 d’une base de données.
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 plus de 35 ans, 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.9 Outils de Développement « MDA »
6.9.1 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. Ca peut encore
vous paraître très abstrait, mais vous allez voir : c'est réellement bluffant, d'autant qu'on s'attend souvent à ce qu'un
générateur de code produise un code assez « sale », parsemé de variables numérotées et autres commentaires codés. Mais
avec AndroMDA, ce n'est pas du tout le cas grâce à ses importantes possibilités de configuration et à l'utilisation de modèles
de conception standards.
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 haut niveau en un code de qualité permet un gain de temps significatif dans
l'implémentation d'applications Java.
[Arbogast06]
Figure 69. Architecture des applications d'entreprise – Implémentation AndroMDA
• Couche de présentation : AndroMDA offre actuellement un choix entre deux technologies pour implémenter des
couches de présentation web : Struts (plus d'infos ici et là, ou encore ici) 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.
• Bases de données : puisque les application 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.
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éé récemment une nouvelle initiative pour coordonner et encourager la création de modules
additionnels. Sachez par exemple qu'un effort important est en cours pour finaliser une pile de modules pour .NET, qui
devrait à terme vous permettre de générer à votre convenance une application Java et/ou .NET à partir des mêmes
modèles.
- Contrairement à certains générateurs de code 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 traditionnellement 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. En fait, 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 manque 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 (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 aucun 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.
• Passer des entités réelles au client peut poser un risque de sécurité. 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. D'accord, 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.2 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 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
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 outli 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 la seule solution (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 « PHPUnit » (un OpenSource)

[Grossglauser07]
PHPUnit est un framework de test 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...
- Un syntaxe simple, facile à comprendre et à retenir.
- Un grand nombre de méthodes de tests.
- Organisation et exécution des test 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 format 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 (le support a été prévu).
6.10.3 Utilitaires :
• 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.11 Outils de test TDR avec les méthodes agiles

FIT (http://fit.c2.com/) 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 (http://fitnesse.org/) 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 (http://www.greenpeppersoftware.com/) 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 (http://www.leirios.com/) 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.12 Autres outils
6.12.1 Le serveur d’application universel EAS : Enterprise Application Server [Sybase]

EAS est un serveur d »’applications adapté à la nouvelle informatique.
- 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.12.2 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.
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 Serveur [NIST, ECNA, C++] Services d’objets répartis
(distribuive Smaltalk de HP)
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 70. Schéma de la plateforme DOC
Finalement, DOC est à cheval entre RPC procédural et RPC orienté objet (ORB). Mais, il se rapproche beaucoup
plus de l’ORB à cause des 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).

6.12.3 L’offre 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.
6.12.4 Quelques Logiciels de modélisation UML

Outils UML 2 pour les bases de données
Principaux logiciels du marché permettant de modéliser du niveau conceptuel à la génération de script 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
l’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. Ne fonctionne pas correctement sous Windows ;
• ArgoUml un modeleur UML sous Licence BSD ;
• 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 5.5
• 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;
• ArgoUML : Outil Open Source; - http://argouml.tigris.org
• 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 [1], en Java ;
• MagicDraw, un éditeur de diagrammes UML ;
• Enterprise Architect, un outil de modélisation UML ;
6.12.5 LES OUTILS SADT

De nombreux outils traitent le formalisme SADT, en voici quelques exemples :
• 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.12.6 Les outils de développement d’applications de base

Comme outils de développement des architectures réparties, on retrouvera
- langages de programmation classiques (procédural, orienté objet)
- langages de 4ème génération (L4G) adapté aux approches de développement montantes : cas des « RAD »
- ateliers de génie logiciel (AGL) adapté aux approches de développement descendantes : cas des « CASE »
Les outils 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]
• Developpeur/2000 [Oracle]
• Visual Basic [Microsoft]
• C++Builder [Inprise/Borland]
⇒ Quelques autres AGL

• WinDev [PCSoft]
• Power AMC
• ArtEnterprise : AGL extrêmement puissant
• Designer/2000 [Oracle]
• ROSE [Rational]
• GDPro [ASTI]
6.12.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
6.12.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
6.13 Les questions que l’on doit se poser lorsqu’on est face à un système ou un projet (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’outils 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 Quels 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 ? Quelle 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.14 Eléments de qualité lors d’un développement

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. Ainsi, l'utilisation de boucles (while, for...) ou encore d'instructions
de branchements conditionnels (if, else) augmentent cette complexité. (Définition de Wikipédia)
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 en anglais ou encore [Fowler03]).
Métrique : Autre terme utilisé pour définir une mesure.
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 peut 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 le 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 2 . Exemple de métriques prises (logiciel SAHY)


7 Ergonomie d’Applications Graphiques (Web), 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 vous allez mettre en place. Après avoir appris comment 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 son site et plus généralement 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 71. 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 de l’intervention

L’objectif que nous nous sommes fixé ici, 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’é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 site
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’environnement 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 rèç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.
Cette étude se fait autant sous l'aspect humain de ces fonctions que sous 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 l’étape 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 softeware), l’automobile et parfois –mais plus
rarement– dans le domaine du mobilier.
Pour approfondir la question, vous pourrez consulter plus tard les sites d’ergonomes que nous avons mis sur le réseau.
7.3 La prise en compte de l’ergonomie dans le développement d’IHM et plus spécifiquement

dans le développement d’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 de 800 x 600 pixel, 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 :
- 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 « ferrer » 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 ») et des annuaires (type « Yahoo »). Dans le premier
cas, il n’y a aucune démarche à faire pour se faire référencer, se 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 veux être visité.
Les termes que l’on choisit dans la définition de ses mots clefs sont déterminant.


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)
7.3.2 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 72. Cas 1 (libellés de dimension sensiblement identique)
Nom : Profession :
Prénom : Profession du
conjoint :
Adresse personnelle Nombre d’enfants à

(domicile) : charge :
Figure 73. 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 74. 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 75. 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 ;
- ascenseur 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 :
- libellés en général à gauche,
- 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 icones

Les icones peuvent avoir deux fonctions :
- aider à identifier la nature d’une information, sous forme d’icone,
- représenter une action par une icone associée à un bouton de commande.
Exemple : l’icone loupe (ou jumelles) est associé au bouton de commande <Rechercher>.
Attention, les icones 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 icones
d’un libellé.
Homogénéité : quand une icone est utilisée pour représenter quelque chose, la conserver pour l’ensemble de
l’application. Autrement dit, ne pas utiliser deux ou plusieurs icones 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 76. 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 Etude : analyse des supermarchés « on line » : fidélisation du client par l’ergonomie
Les supermarchés en ligne intègrent toutes les problématiques qui nous intéressent :
- Interfaçage avec des bases de données
- Nombre d’information à transmètre très important, donc optimisation maximum de l’écran, et travail
ergonomique important. (EN grande Distribution, on parle de rendement au m², on pourrait ici parler de
rendement au pixel !)
7.4.1 Présentation du site c-mescourses.com

7.4.1.1 L’environnement d’achat
- Le portail et l’« ergonomie de fond »
- Les publicités du site
- L’inscription
7.4.1.2 L’acte d’achat

- La recherche du produit
- La sélection du produit
- Le payement
- La livraison
7.4.2 Présentation du site Houra.com

- le portail
- Le plan du site
- Les publicités

- Recherche du produit
- Selection du produit
- L’inscription
- Le payement
7.4.3 Synthèse et Description d’un supermarché « on line » standard

- Le portail
- La communication sur le site

- Recherche et selection du produit
- Payement et livraison
- conclusion
TD : Etudier les 3 situations présentées ci-dessus.


7.5 Conclusion sur l’ergonomie
Comme nous avons put le constater ensemble, la bonne ergonomie de ses applications Web 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 certaine recommandation, voir à faire le contraire !
7.6 Approche générale sur le développement (3D) en équipe

Nous voulons à ce niveu présenter comment aborder un développment en équipe pour la 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.6.1 Le développement en équipe

La production d’une application 3D fait intervenir au oins 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 fini 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.6.2 Mesures pour gagner en efficacité

Voici quelques mesures valables pour différents éléments de votre projet, sans exception, tels que : modélisation,
texture, animation, documents de conception, programmes ...
• Partage et sécurité des données
Chaque membre de l'équipe doit avoir accès immédiatement à tous les documents du projet qui lui sont nécessaires,
y compris la documentation.
• Gestion des versions des fichiers
Pour chaque élément du projet, on doit connaître sa version actuelle et qui l'a modifié en dernier.
• Division pour régner
On doit faire en sorte que chaque élément du projet ne traite que d'un domaine limité et soit ré-utilisable. Tout grand
problème devra être divisé en sous problèmes plus simples.
• Compilation quotidienne
On doit pouvoir compiler le projet tous les jours pour connaître létat d'avancement et pouvoir évaluer où l'on en est.
NB : Ces mesures doivent être accompagnées d'autres mesures élémentaires comme les conventions de nommage, ou
l'affectation des tâches et des délais...


7.7 L'efficacité du développement point par point
7.7.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 à 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 comportement 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, sous forme de fichiers VMO pour notre exemple.
- Prototypes
prototypes de vos composants.
7.7.2 Systèmes de gestion de versions

7.7.2.1 Notion de gestion de versions
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 version 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.7.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é 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.7.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.7.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é que à 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. Tous cela contribue à la qualité.


BIBLIOGRAPHIE
[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
[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.
[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/
[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/
[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 (site Web de l’OMG contenant les spécifications sur le métamodèle UML et le processus MDE)
[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.
[Scott02] Scott Ambler , Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process, Wiley, 2002.
Autres sources
• www.cui.unige.ch/ScDep/Cours/GenieLogiciel/index.html
• http://www.gpa.etsmtl.ca/cours/gpa77
• http://cui.unige.ch/ScDep/Cours/GenieLogiciel/
• http://www.cours.polymtl.ca/inf2300


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.

IngenierieSystLogiciel NK 2009

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IngenierieSystLogiciel NK 2009

Încărcat de

Drepturi de autor:

Formate disponibile

Université de Douala

The University of Douala

Ingénierie des Systèmes

Dr. Marcellin Julius NKENLIFACK

Version Dec. 2009

1.1 Un peu d’historique

• En 1983, on se rend compte que :

© Dr. NKENLIFACK Marcellin Page 1 / 92

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

1.3 Le Génie Logiciel

1.4 Le processus logiciel, ou cycle de vie du logiciel

© Dr. NKENLIFACK Marcellin Page 2 / 92

Conception générale. formaliser les spécifications élaborées de l'architecture générale du logiciel.

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

1.5.1 Modèle Exploratoire

Figure 1. Modèle exploratoire

résultats des tests -> Installation

Figure 2. Modèle Cascade

© Dr. NKENLIFACK Marcellin Page 3 / 92

1.5.4 Modèle en spirale

Figure 4. Modèle en spirale

© Dr. NKENLIFACK Marcellin Page 4 / 92

Figure 5. Modèle Incrémental

© Dr. NKENLIFACK Marcellin Page 5 / 92

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

© Dr. NKENLIFACK Marcellin Page 6 / 92

1.7.4 Les démarches d’analyse

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

1.8 Techniques de Tests

© Dr. NKENLIFACK Marcellin Page 7 / 92

X/0 (-1) (0)

1.9 Processus de test de codes

© Dr. NKENLIFACK Marcellin Page 8 / 92

1.9.2 Processus de test :

Figure 6. processus de de développement dirigé par les tests

© Dr. NKENLIFACK Marcellin Page 9 / 92

© Dr. NKENLIFACK Marcellin Page 10 / 92

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

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

© Dr. NKENLIFACK Marcellin Page 11 / 92

Figure 8. 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

© Dr. NKENLIFACK Marcellin Page 12 / 92

Figure 9. Graphe de marquage

2.2.4 Limites des RdP et extensions des possibilités

2.2.5 Extensions et autres Outils proches

© Dr. NKENLIFACK Marcellin Page 13 / 92

2.3.2 Modèles SADT

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

2.3.3.1 LES ACTIGRAMMES SADT/IDEF0

© Dr. NKENLIFACK Marcellin Page 14 / 92

A-0 Diagramme de contexte

Figure 10. 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 :

Figure 11. Décomposition en fonctions principales (SADT)

Un diagramme doit comporter entre 3 et 6 fonctions.

Figure 12. Représentation d'une fonction (SADT)

© Dr. NKENLIFACK Marcellin Page 15 / 92

Figure 13. Les flots de données (SADT)

LES DATAGRAMMES SADT

Figure 14. Datagrammes SADT

© Dr. NKENLIFACK Marcellin Page 16 / 92

Certains rôles sont définis :