P. 1
IngenierieSystLogiciel_NK_2009

IngenierieSystLogiciel_NK_2009

|Views: 163|Likes:
Published by Souka Kiari Chigou

More info:

Published by: Souka Kiari Chigou on Mar 09, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/12/2014

pdf

text

original

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

HISTORFIQUE DES METHODES AGILES : ...................................................................................................................................................... 53 LES PRINCIPES AGILES ................................................................................................................................................................................ 53 « MODELISATION AGILE » DES PROJETS ..................................................................................................................................................... 55 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

5.1 5.2 5.3 5.4

Alan Turing (un brillant étudiant en mathématiques à Cambridge en Angleterre. Forth…) . (ex coût de la mémoire économisée). • A la fin des années 70. Art. et éventuellement de la documentation. on se rend compte que : .Ingénierie des Systèmes Logiciels 1 Rappels des Concepts du Génie Logiciel « Le logiciel est l'ensemble des programmes. Une machine de Turing sera vue comme une méthode de calcul. NewFlavors. Simula. et pour pouvoir faire face aux problèmes de plus en plus complexes. jeux de tests. dominant maintenant le coût du matériel et peuvent représenter plus de 80 % du coût total d’un système informatique. • Les langages de programmation (« intermédiaire » entre le « programmeur » et la « machine ») vont évoluer dans le temps. 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.3% utilisés sans modification (échec de tentative) . développement et maintenance : spécifications. 1. . Ce sera le modèle de base qui fonde l'informatique moderne.Langages de 1ère génération (1954 – 1958 : Fortran I. etc. on note que au fur et à mesure que les coûts du matériel diminuent.). NKENLIFACK Marcellin Page 1 / 92 .28% payés et non livrés . Java…) • La Complexité du dévellopement des Logiciels étant également liée au matériel.43% des logiciels sont livrés et non utilisés . 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 • Crises : • En 1983. on observe une révolution avec la création des microprocesseurs (1974 = Intel. C++) . procédés et règles. Ada. Programmer (écrire un programme) consiste à écrire une suite d'instructions pour réaliser un traitement sur des données. Neon. L’explosion qui va suivre dans les années 80 entraînera une baisse permanente des coûts du matériel. Au cours des années 70.1 En 1936. Pascal. avec au centre le processeur (entité capable d’interpréter et exécuter un traitement ou processus). Cobol. 1984 = 88020. Ulysse. 1982 = RISC. Objloo. âgé de 24 ans qui cherchera à construire un cerveau artificiel). propose dans un article. Algol60.2% utilisés avec modifications (réussite de tentative) © Dr. 1981) Un logiciel pourra donc être considéré comme un ensemble de programmes informatiques (codes sources. éditables. 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. schémas conceptuels. Algol 58…) . Algol68. • Un peu d’historique 1.Langages de 4ème génération (1970 – 1980 : Smaltalk. Yafool. C(B)) .19% utilisés tels quels .Langages de 5ème génération (année 80 et 90 : Eiffel. pour permettre de développer des solutions de plus en plus performantes . Les coûts des logiciels connaissent une très forte croissance. 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 ».Langages de 2ème génération (1959 – 1961 : Fortran II.2 Malgré les évolutions citées plus haut. relatifs au fonctionnement d'un ensemble de traitements de l'information' » (arrêté du 22 déc. un programme. au fur et a mesure des besoins en terme de qualité. etc. Clos. on note également une évolution des systèmes matériels : Après l’architecture de Von Neumann. utilisation.Langages de 3ème génération (1962 – 1970 : PL1. mode d'emploi. les systèmes matériels vont également évoluer rapidement dans le temps. à la base de toutes les architectures modernes. exécutables) mais également les données qu’ils utilisent et les différents documents se rapportant à ces programmes et nécessaires à leur installation. Lisp.

3% autres… Ces différents problèmes vont conduire à la création du Génie Logiciel. machine).Ingénierie des Systèmes Logiciels 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. 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. NKENLIFACK Marcellin Page 2 / 92 .12% problèmes d’urgence résolus à la hâte .30% des exigences de spécification changent entre la 1ère édition d’une documentation et la première sortie du produit . 2a 2b …) . c'est-à-dire la conformité du logiciel avec les besoins exprimés. Le cycle de vie du logiciel comprend généralement au minima les activités suivantes : • Définition des objectifs. mais également un certain entrainement et de l'expérience (le savoir faire). • Spécification. Le SRA doit dégager clairement les fonctions. recueillir et formaliser les besoins du demandeur (le client) et de l'ensemble des contraintes.6% à des changements de matériel . Ce modèle a été assez largement mis en œuvre. définir le quoi du logiciel après dialogue avec le client. logiciels. outils et techniques utilisées pour développer et maintenir du logiciel dans le but d’assurer la qualité et la productivité. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel. • • • 1. • Objectifs : . exprimer. méthodes ) .Fournir une assurance qualité du produit livré Le génie logiciel s’intéresse : .Améliorer la productivité (de l’équipe de développement) .à la gestion de projets En bref. le premier modèle de développement proposé (1966) est celui dit en ``cascade''. de sa conception à sa disparition. consistant à définir la finalité du projet et son inscription dans une stratégie globale.9% déboguages de programmes . basées notamment sur le prototypage et l'assemblage de composants réutilisables.aux méthodologies : ( techniques. © Dr. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel. De fait. désigne toutes les étapes du développement d'un logiciel. mémoires. plusieurs alternatives au modèle en cascade ont été proposées. d'interprétation et d'anticipation. 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. • D’une étude sur 487 sites de toutes sortes de développement de logiciels. mais il est également basé sur des concepts plus informels. utilisateurs.Maîtriser les coûts et les delais de développement .70% du coût du logiciel est consacré à sa maintenance . il ressort que : . etc. Cette phase débouche généralement sur un document de spécification (Software Requirement Analysis SRA). C’est donc l’art de la construction du logiciel. ou cycle de vie du logiciel Le « cycle de vie d'un logiciel » (en anglais Software Lifecycle).4% améliorations de l’efficacité . environnement). 2001).42% des modifications sont dues à des demandes de l’utilisateur . les délais de sa réalisation et les coûts associés. 1.6% problèmes de documentation . et demande des capacités de communication.4 Le processus logiciel.aux différentes théories . les interfaces (machines.aux outils . c'est-à-dire l'adéquation des méthodes mises en œuvre. (Le Monde – 23 oct. Sa vision simpliste du processus sous-estime le coût des retours en arrière dans le cycle de vie. mais on s'est rapidement aperçu qu'il n'est pas toujours approprié. les contraintes (performance. le Génie Logiciel c’est l’ensemble des méthodes. Le génie logiciel reste un « art »' qui demande de la part de l'informaticien une bonne formation aux différentes techniques (le savoir). On donne ici les contraintes de temps. Historiquement.à l’organisation générale . et la vérification du processus de développement. la « crise du logiciel » n'est pas complètement résolue aujourd’hui.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 ». Ainsi. formalisé en 1970. • Analyse des besoins et faisabilité.17% à des changements de format des données (an 2000.

Cette phase débouche sur un ensemble de codes (Program). on aura un séquencement ou la présence de chacune de ces activités dans le cycle de vie correspondant. livrer et valider le produit. procéder aux tests (on teste à l’atelier. • Qualification. entreprendre des actions correctives (maintenance corrective) et évolutives (maintenance évolutive) sur le logiciel.5. s'assurer de l'interfaçage des différents éléments (modules) du logiciel.1 Représentations des modèles de développement Modèle Exploratoire Cette approche est essentiellement informelle. Codage Test Mise au point Figure 1.livraison). En fonction du choix d'un modèle de cycle de vie entre le client et l'équipe de développement. • Intégration. • Mise en production. formaliser les spécifications élaborées de l'architecture générale du logiciel.SDR). réaliser (programmer) ou codifier dans un langage de programmation des fonctionnalités définies lors de phases de conception. • Documentation. • Maintenance.2 Modèle Cascade Le modèle en cascade est présenté ci-dessous. puis par la suite chez le client .5. • Codage. Faisabilité Analyse des besoins Conception du produit Conception Détaillée -> spécification / cahier des charges -> plan de tests documents de fonctionnement -> Codage Intégration résultats des tests -> Installation Exploitation et maintenance Figure 2.Ingénierie des Systèmes Logiciels Conception générale. Par exemple. vérifier la conformité du logiciel aux spécifications initiales. Modèle Cascade © Dr. Les tests d'intégration (et même parfois unitaires) seront consignés dans un document rapport (Software Test Report – STR). 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. Conception détaillée. Il faut noter que dans ce modèle. • Tests unitaires. • • 1. dans le modèle en V. Modèle exploratoire 1.5 1. 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 . vérifier inidividuellement que chaque sous-ensemble du logiciel est implémenté conformément aux spécifications. une modification dans une étape « N » ne remet en cause que l’étape « N-1 ». indiquer le comment. NKENLIFACK Marcellin Page 3 / 92 . produire les informations nécessaires pour l'utilisation du logiciel et pour des éventuelles évolutions futures.

3 Modèle en V Le Schéma du modèle en V est présenté ci-dessous. . 1. ou sur une analyse primaire. Modèle en spirale © Dr. Analyse des besoins de Faisabilité Installation et test du système ----------------------------------------------------------------------------------> Conformité/complétion/Correction Spécifications --------------------------------------------------------> Conception architecturale ------------------------------> Conception détaillé --------> Programmation Codage Tests unitaires Intégration et tests Acceptation Figure 3.5.Boehem en 1988. Figure 4. NKENLIFACK Marcellin Page 4 / 92 . évaluer les alternatives.Dans le troisième tour : passer en revue les résultats du cycle précédent et planifier le cycle suivant. les alternatives. Il a été proposé par B.4 Modèle en spirale Ce modèle propose de généraliser les deux précédents. Modèle en V Dans le modèle en cascade.Dans le deuxième tour : s’occuper du développement et de la vérification de la solution retenue en cours. . on détermine les objectifs du cycle.Ingénierie des Systèmes Logiciels 1. . proposer un maquettage. les contraintes en s’appuyant sur les cycles précédents. .Dans le premier tour. 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.Dans le premier tour : analyser les risques.5.

On peut y retrouver au moins 4 types de méthodes : • Méhodes de planification stratégique du développement des systèmes applicatifs.Définir clairement des exigences de sortie . Il s’agira de définir un processus décisionnel en se basant sur : .Spécification des besoins . causes. on retrouve les méthodes et outils servant tout au long du processus de développement. suivi de fonctionnement et d’utilisation . stratégies de conduite (pourrait servir pour n’importe quelle entreprise) o Fonction qualité © Dr.6 Méthodes Dans l’Ingénierie d’un système logiciel.Maintenance • Méthode de conduite des projets.contrôle d’avancement et d’exécution de tâches .organisation générale du projet .Ingénierie des Systèmes Logiciels 1. plannings. gain attendu de son éradication o Manuel qualité (spécifique au logiciel à réaliser) o Plan qualité : politique.choix des méthodes à utiliser . gestion des versions.Une stratégie informatique (projets ? budgets ?) . en partant d’un noyau de base qui est par la suite complété progréssivement.Une politique informatique (mission ? objectifs ? règles ?) . c’est « l’attitude du produit à satisfaire les besoins (exprimés) des utilisateurs. une bonne planification et une spécification rigoureuse sont nécessaires.5. apprentissage.définition des profils des participants au projet .Installation : mise en exploitation.animation et conduite des travaux lors des étapes du cycle de développement . Comment peut-on obtenir la qualité ? . Identification des incréments ----------| | | | Spécification des incréments Codage des incrémets Evaluation des incréments | | ------------------------------------------------- Figure 5.gestion et formalisation des dossiers . budgets.Définition du processus et orientation de l’action qualité o Diagnostic de la non qualité : problèmes. Il s’agit d’estimer les moyens prévisionnels. ainsi qu’une bonne planification et une forte indépendance au niveau fonctionnel et au niveau du calendrier.5 Modèle Incrémental Dans cette méthode. poids.Une tactique informatique (faire plus avec moins) . priorotés.gestion des relations contractuelles avec les fournisseurs .Une action informatique (exploitation courante) • Méthodes de développement proprement dit.Conception générale et détaillée . Généralement.suivi analytique des projets • Méthodes d’assurance qualité D’après l’AFNOR. Modèle Incrémental 1. les délais et les coûts . on évolue par incréments. .évaluation des charges. coûts.Réalisation . action.planification .gestion des relations contractuelles avec les utilisateurs .Mesurer la conformité à chaque phase Cela implique 4 grands temps : . NKENLIFACK Marcellin Page 5 / 92 . coûts et moyens .

Mesure de conformité et Animation de l’action qualité. nous avons besoin au départ d’interviews bien faites. niveau de test à atteindre o Qualimétrie du logiciel : évaluaton de la complexité du logiciel.1 Les 7 péchés : . comment ?. vous faites allusion à un concept qui sera présenté plus loin . 1.Mise en œuvre du processus et Action qualité (qui ?.Validable . mais également les 7 mots clés de réussite. difficulté de maintenance.Complète . Bertrand Meyer [Meyer 90] a défini les 7 pièges qui guettent lors d’un procéssus de spécification. outils et méthodes de tests. des fournisseurs de l’application des plans d’assurance qualité.Outils © Dr.Bruit : élément qui n’apporte aucune information (!) / redondance (!) . documentation) En définitive.Langage . construction des jeux d’essai.Contradiction : dans les séquences de spécification . souvent limités) . type de projet. 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 . matériels.Démarche .Vœu pieux : attention à des éléments non vérifiables (!) 1.7.7. Il s’agit beaucoup plus de mobiliser des informations et les partenaires. c’est celle des spécification.Ingénierie des Systèmes Logiciels . il s’agit de satisfaire les besoins de l’utilisateur au sens large.Référence en avant : étant à une page.2 Les 7 caractéristiques d’une bonne spécification : . secteur d’activité) o Cahier de charges qualité : par projet o Plan d’assurance qualité du projet selon les aptitudes requises (fiabilité. conformité par rapport au cahier de charges fonctionnel. temps de réponse.Amélioration par des moyens divers pouvant contribuer à la réussite des trois autres volets o Financiers o Humains o Techniques (logiciels. délais.7 La Spécification La phase la plus délicate dans le processus de développement du logiciel.Cohérente 1. On doit pouvoir la mesurer ou tout au moins la quantifier.Conformité (aux besoins réel et non aux besoins supposés exprimés. …) o Contrat client-fournisseurs o Maquettage.Silence : caractéristique d’un problème auquel ne correspond aucune partie du texte . de l’évolution de la non qualité . au cahier de charges qualité o Gestion opérationnelle de la qualité : suivi périodique des actions qualité. 1. Les méthodes de spécification de logiciels seront de trois catégories : . NKENLIFACK Marcellin Page 6 / 92 . les délais. La qualité peut être « prouvée » en maîtrisant les paramètres tels que les coûts.Communicable . 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.Semi-formelle .3 Les méthodes Lors de la phase de spécification. quand ?) o Définition des normes de qualité (par thème.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…) .Informelle (structurée) .Modifiables .Ambiguités : une phrase peut avoir 2 ou plusieurs sens .Formelle (mathématique) Les méthodes de spécification intègrent : .7.Faisable .Modèle . pouvant déboucher sur une bonne documentation. risques o Recette de qualification : inspection par le client.

UP. mais aussi les formules de la logique de prédicats pour spécifier les propriétés (classes. Ces langages basés sur les mathématiques vont pouvoir prendre en compte n’imorte quel concept abstrait ou logique. Le concepteur devrait donc y penser dès le départ. Durant les étapes du cycle de vie. 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.tests de réception (« in situ » avec le personnel) . BOOCH (dans son approche objet initiale).) 1. Dans tous les cas.tests d’unités (centrés sur les composants) . mais pas sur tous les apspects. • Approche Fonctionnelle Les données et les fonctions sont modélisées séparément. 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. Les outils sont : . Les programmes de tests peuvent parfois être plus longs que le programme à tester.4 Les démarches d’analyse Lorsqu’on veut modéliser un système. Exemples: SADT-SART.Une représentation des processus (fonctions + données) .Une lisibilité claire du dictionnaire de données .tests d’intégration (centrés sur les modules) .tests de validation (vérification des fonctionnalités. modèles.8 Techniques de Tests Les chiffres montrent que dans un procesus de développement. Cas de SADT avec SART. • Méthodes Informelles Elles n’ont pas un formalisme supportant une vérification.Une bonne illustration des entrées et sorties (éventuellement les temps de réponse) 1. etc.Des modèles de contrôle suffisants . • Approche Modèles Voir MDE (Model Driven Ingineering) plus loin.Mixte Un exemple : VDM (Vienna Description Method) : il utilise la théorie des ensembles pour décrire les entités et les objets . modale) . la phase de test coute 40% de l’ensemble (avec 40% pour l’analyse et 20% pour le codage).Logique (temprelle. graphiques ou mixtes facilitant la compréhension et l’expression. objets • Fonctions : transformations des données dans le système • Dynamique : changements dans le temps. etc.7. Exemples: Booch. • Approche Agiles Voir méthodes Agiles plus loin. il faut modéliser trois catégories d’entités : • Données : aspects statiques.tests de régression (suite à des modifications) © Dr. une validation (informatique ou simulation mathématique) Cas de SADT (dans son approche fonctionnelle).Un maximum de modèles de besoins . HOOD. performances …) .Automates . on pourra retrouver des tests aux principales étapes : . MERISE… • Méthodes Semi-formelles Elles permettent des vérifications.Ingénierie des Systèmes Logiciels On pourrait donc très bien leur associer des environnements textuels. etc. OMT. OOA. contrôles (ex :modéliser les données en fonction du temps) La démarche peut être fonctionnelle. NKENLIFACK Marcellin Page 7 / 92 . mixte. Réseaux de Petri.Des modèles d’analyse suffisants .Algebre (algebre universelle. objet. algebre de processus) . lors de votre démarche éssayez toujours de prendre en compte : .

la rigeur et les contraintes de conception généralement imposées dans les langages à vocation industrielle (C/C++. 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 ». etc.9 Processus de test de codes Problématique : 1. faire appel à des générateurs (aléatoires…) de tests et contrôle de tests automatiques (exi.) ne s'appliquent pas nécessairement avec des langages d’accès comme PHP. tout comme il décide de structurer ou non son développement par rapport à des processus éprouvés. à l’instar de PHP sont flexibles.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. Malheureusement. il choisit la précision avec laquelle il souhaite intégrer un paradigme. de codage (types de variables. les procédures doivent permettre d’augmenter les chances de détection de problèmes. résultats obtenus. contraintes sur les attributs d’une table ou d’un fichier…). Cette grande liberté est à l'origine du succès du langage.Les données de test doivent être choisies judicieusement ! . On retrouve : . assert etc. Finalement. Autres Recommandations : Les méthodes de test ne doivent pas être longues et doivent être au mieux simplifiées. incohérences. 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. les relectures dans certains cas seront collégiales. 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. 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.Ne pas se limiter uniquement aux données « normales » ! mais prévoir des données sensibles pouvant entraîner des exceptions. . permissifs et faciles à appréhender. domaines de variation. . plus ou moins critiques. • Dans une approche statique. il est important d’élaborer un « plan de tests » et un « dossier de justification » de ceux-ci (choix des tests. Les tests effectués pourront être statiques (porter sur des textes. Le plus souvent il s'agit d'instabilités dans l'application ou des problèmes de sécurité classiques.Ingénierie des Systèmes Logiciels Les tests doivent permettre de détecter des érreurs ou des insuffisances dans un logiciel. JTests. et les encapsuler directement. • Dans une approche dynamique.1 Beaucoup de langages.les tests de vérification : il s’agit de s’assurer que le système est conforme aux spécifications définies initialement. mais c'est également son plus grand défaut. le programmeur est seul maître à bord. finition. en indiquant les valeurs attendues à chaque fois. Java. 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. • Dans une approche fonctionnelle : .9. etc. • Un gros projet doit absolument avoir un responsable des tests. 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). tests exclus pour certaines raisons telles que le coût ou l’impossibilité physique…) • Durant les tests. résultats attendus.les tests de correction : il s’agit de s’assurer que le système fournit des résultats exacts. branchement de code.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. portabilité. les modèles de BD. certains principes qui font la force de certains langages ne sont pas implémentés dans d’autres langages. preuves d’algorithmes. NKENLIFACK Marcellin Page 8 / 92 . © Dr. en se basant sur un référentiel défini au préalable. 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é. Elles doivent être bien commentées. gauss…) . que ce soit impératif. Par exemple. initialisation. fonctionnel ou orienté objet.) • - 1.

3 implémenter la fonctionnalité.exécuter à nouveau les tests unitaires. Le code source n'est pas réutilisable.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. avec les tracas que cela implique pour vous et vos utilisateurs finaux. © Dr. vous observerez que l'approche TDD débute dès la phase de conception. Le code source n'est pas évolutif : il va sans dire. ajout de fonctionnalités) est susceptible d'engendrer des régressions. organisation interne. Vous serez contraint à moyen terme. 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.Ingénierie des Systèmes Logiciels Le code source n'est pas robuste : toute modification du code source (refactorisation. [Grossglauser07] Figure 6. Le développement piloté par les tests (Test-Driven Development. pas transmissible : si un autre développeur doit vous assister ou reprendre votre travail. 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. 4 exécuter les tests unitaires . 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. NKENLIFACK Marcellin Page 9 / 92 . il sera confronté d'une part à votre code source et d'autre part à l'absence d'un protocole de test uniformisé. de reprogrammer entièrement votre application.. Tout ceci aura non seulement un impact sur la fiabilité de votre programme (et vos prestations de service). on peut résumer son processus en cinq étapes : 1 Ajouter un test.) ainsi que de la phase d'analyse. plus votre application aura une structure complexe plus vous peinerez à déceler des erreurs et problèmes de conception de manière empirique. notamment. passer à l'objectif suivant. mais également sur le temps alloué pour le développement et la maintenance du projet.déboguer en cas d'échec. En reprenant le processus ci-dessus. 2 vérifier qu'il ne passe pas. Dans l'idéal. etc. 1. Il est basé sur le développement piloté par les tests (TDD) et s'adresse particulièrement aux développeurs PHP autonomes. ou TDD) est une méthode de développement mettant les tests unitaires au premier plan. 5 refactoriser le code source .9. Si vous développez en équipe..

Exercice 2 : Proposer un plan qualité pouvant permettre de contrôler les phases du cycle de développement de logiciels dans une structure. © Dr.Ingénierie des Systèmes Logiciels 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. NKENLIFACK Marcellin Page 10 / 92 .

concurrence.1 Introduction Des méthodologies développées permettent de modéliser des systèmes à risques.2.1 Spécifications à l’aide des Réseaux de Petri 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. Un réseau de Petri est dit graphe biparti alterné . NKENLIFACK Marcellin Page 11 / 92 . peuvent passer d'une place à l'autre par franchissementiou tir d'une transition.1.Ingénierie des Systèmes Logiciels 2 Méthodes SADT et Réseaux de Petri 2.Le formalisme des RdP. Les jetons. Le nombre de jetons contenus dans une place Pi sera noté mi. Exemple de réseau de Petri marqué avec un vecteur de marquage M = (1. qui matérialisent l'état du réseau à un instant donné. Ce marquage consiste à disposer un nombre entier (positif ou nul) de marques ou jetons dans chaque place du réseau de Petri. Un RdP a des propriétés intrinsèques (dépendant ou non du marquage de départ) comme les branches mortes (inaccessibles). synchronisation. il est nécessaire de compléter le réseau de Petri par un marquage. etc. sont reliées par des arcs orientés. hiérarchique et structurée du SADT. c'est à dire qu'il y a alternance des types de noeuds : tout arc. 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 ». en nombre fini et non nul. cycles. Pour définir l'état d'un système modélisé par un réseau de Petri. relie soit une place à une transition soit une transition à une place. Il offre la possibilité de parallélisme. etc. . qui doit obligatoirement avoir un noeud à chacune de ses extrémités.2 2. de synchronisme et de parallélisme. Les places Pi et les transitions Ti d'un réseau de Petri. .0.L'approche systémique. [KaiserCottet01] Figure 7. 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.0.2. est généralement bien adaptée pour représenter au mieux les connaissances structurelles et fonctionnelles du système étudié. Dans le cas des réseaux dits à arcs simples ou de poids 1.0) L'évolution de l'état du réseau de Petri correspond à une évolution du marquage. exclusion. Il s’agit de SADT et Réseaux de Petri (RdP). Le marquage du réseau sera alors défini par le vecteur M = {mi}. adapté à la prise en compte des problèmes de concurrence. la régle d'évolution s'énonce de la manière suivante : © Dr. constitue un excellent outil de spécification fonctionnelle d'un problème et de mise en évidence des contraintes.0. 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 : . colorés. continus… hybrides etc. 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. © Dr. Ce fonctionnement représente assez bien les situations réelles où il n'y a pas de priorité dans la succession des événements. Ces règles introduisent en effet un certain indéterminisme dans l'évolution des réseaux de Petri. Il existe de nombreux développements et alternatives : les réseaux temporisés. NB : si une transition est validée. . puisque ceux-ci peuvent passer par différents états dont l'apparition est conditionnée par le choix des transitions tirées. [KaiserCottet01] Figure 8.une transition est franchissable ou sensibilisée ou encore validée lorsque chacune des places en amont possède au moins un jeton.Ingénierie des Systèmes Logiciels 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. 2. NB : Les formlismes tels que « Grafcet » et « MERISE » (MCT) se sont à la base inspirés des réseaux de Petri. transition choisie parmi toutes celles qui sont validées à cet instant.le réseau ne peut évoluer que par franchissement d'une seule transition à la fois. cela n'implique pas qu'elle sera immédiatement franchie. NKENLIFACK Marcellin Page 12 / 92 . 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.le franchissement d'une transition est indivisible et de durée nulle.y U+ et un « marquage ».2.

par exemple. 2. qui a été défini par un groupe de travail de l’Adepa dans les années 1980.2. . permettant de faire. 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. Les extensions des RdP aux RdP-temporisés et RdP-stochastiques. un « choix » en « départ en parallèle ». Par exemple. À 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. de l'évaluation de performances. Hormis l’utilisation du concept d’activité décrit dans cet article et qui n’est pas spécifique à ce modèle. l’orthogonalité pour le parallélisme et la diffusion pour les communications. 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.2. En revanche. Ce problème n’existe pas avec les réseaux de Petri. Ils intègrent l’abstraction.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. etc.. Graphe de marquage Remarque : cette représentation permet de déterminer certaines propriétés d'un graphe. permettent de prendre en compte l'aspect dynamique des problèmes. Il est donc difficile de représenter des applications contenant des recommandations telles que « à la date t. langage normalisé pour les API – Automates Progrmmables Industriels) peut être utilisé en lieu et place des réseaux de Petri.Ingénierie des Systèmes Logiciels 2. les statecharts. constitue une alternative à la modélisation des systèmes à événements discrets.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. . ». [KaiserCottet01] Figure 9. de messages. en cas d’erreur de modélisation. Par exemple si le graphe présente une zone non bouclée. En revanche.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. les automates à états finis permettent de capturer sans difficulté le comportement séquentiel d’une application. Une autre limitation importante du modèle à réseau de Petri concerne la non-existence de mécanisme d’abstraction. il devient rapidement difficile à utiliser quand le besoin de comptage (de pièces. dès que des évolutions simultanées doivent être représentées. Il convient de savoir que le Grafcet. © Dr. 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).. le temps n’est pas pris en compte explicitement par ce modèle. Les Réseaux de Petri Stochastiques généralisés et les Processus de Markov sont utilisés comme moteur de calculs. Le problème de la validation globale d’une application n’est toutefois pas résolu. Le Grafcet (graphe fonctionnel de commande étape transition. Le Grafcet peut être préféré pour des questions de mise en œuvre. Les statecharts sont à considérer pour des applications comportant ces mécanismes. la prise en compte de la durée est tout à fait possible grâce aux extensions temporelles du modèle de base. aucun mécanisme d’agrégation n’est véritablement proposé par les réseaux de Petri. Une extension des automates à états finis. cette partie du marquage une fois atteinte constitue un arrêt de l'évolution du RdP et celui-ci sera déclaré avec blocage. En revanche.. surtout si elles doivent être synchronisées de temps à autre. est en fait un dérivé des réseaux de Petri binaires. 2. En effet. 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.2..) se fait sentir et l’on aura alors plutôt recours aux réseaux de Petri. mais il faut savoir que la mise en œuvre d’un statechart est un problème non résolu à l’heure actuelle. NKENLIFACK Marcellin Page 13 / 92 .

3.les activités génératrices . ou buts ou contextes (Point de vue de l'utilisateur.3.3 Spécification à l’aide se SADT & IDEF (Structured Analysis and Design Technique . soit les 2.Ingénierie des Systèmes Logiciels 2.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.les activités de contrôle . Ils viset à : . contrôler etc. 2.1 Présentation SADT est une méthode graphique établie par Douglas T.les unités utilisées Un modèle SADT est une suite hiérarchisée de diagrammes : (datagrammes et actigrammes) obtenue par raffinements successifs. * Les actigrammes mettent l’accent sur les activités (les données sont véhiculées sur les flèches). .soit un diagramme fils analysant une partie du diagramme père.conférer une valeur ajoutée (entrée -> sortie) . La décomposition est arborescente. les destinations.1 LES ACTIGRAMMES SADT/IDEF0 Les actigrammes sont des diagrammes de décomposition fonctionnelle de l'application.diagrammes de données . les 2 aspects sont duaux et examinés ensemble.liste hiérarchique des diagrammes . ICAM établit ensuite d'autres modèles pour les aspects informationnels (IDEF1) et dynamiques (IDEF2). Ils exigent : .soit un diagramme père synthétisant les diagrammes enfants. le programme ICAM (Integrated Computer-Aided Manufacturing 1972) de l'US air force en commanda une définition domaine publique nommée IDEF0 (1975).diagrammes explicatifs (ou textes uniquement) . NKENLIFACK Marcellin Page 14 / 92 .solliciter (observer. La description comprend une série de « planches ». Au niveau général se trouve le diagramme de contexte (niveau –1). un processus non décomposé est accompagné d’une mini spécification précisant comment sont produites les sorties à partir des entrées. En SADT. de la maintenance de la production …) 2. Chaque « boite » peut-être à nouveau décomposée en un diagramme plus détaillé (Zoom).créer une nouvelle donnée . Kit SADT : .) une donnée * les datagrammes s’appuient sur les données (les flèches représentent les activités).conditions d'activités . En fin de chaîne. montrant les sources. SADT reste encore plus répandu que SA/RT.3.3 SADT/IDEF0 2. 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). ROSS (Softech) vers 1974. du gestionnaire.3. Parallèlement.Icam DEFinition method) 2. Chaque diagramme est .3.diagrammes d'activité . Les diagrammes Le diagramme de contexte représente le système avec ses entrées et ses sorties © Dr. qui lui est à présent préférée pour une meilleure prise en compte des aspects dynamiques. Chaque planche est la décomposition en sous-fonctions d'une fonction du système.glossaire Un modèle est un ensemble de kits établis suivant différents points de vue.

ex A0G1. A0F2... ex A0T1. 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 e2 entrée 1 e1 fonction 1 e1a fonction 2 sortie e1b fonction 3 mecanisme m1 s1 A0 Fonctions principales Figure 11. .. Décomposition en fonctions principales (SADT) Les fonctions 1.) La fonction c e1 s e2 Verbe + complément Axx m Figure 12..). 2. etc. etc). Le diagramme A1 pouvant être décomposé en A11.Ingénierie des Systèmes Logiciels commande entrée 1 sortie entrée 2 (e3) SYSTEME mecanisme A-0 Diagramme de contexte Figure 10. 3 peuvent faire l'objet d'une décomposition dans les diagrammes A1. Un diagramme doit comporter entre 3 et 6 fonctions. NKENLIFACK Marcellin Page 15 / 92 .. ou de glossaires (suffixe G. A12. A2. A3. Chaque diagramme (ex : A0) peut comporter ou être annoté à l'aide de graphiques non formalisés (suffixe F. ex A0F1. Représentation d'une fonction (SADT) © Dr. de textes libres (suffixe T.

ce qui pose un problème de traçabilité. (IDEF0) Certaines conventions permettent de simplifier la représentation en utilisant des flèches à double sens. La fonction doit être nommée par un verbe d'action et un complément d'objet. personnels. Simplement chaque boîte symbolise une donnée du système ou un fichier. commandes sorties entrées Fonction Axx mécanismes Figure 13.Ingénierie des Systèmes Logiciels Une fonction ou une sous-fonction du système à spécifier est représentée par une boîte. Le datagramme est construit indépendamment de l'actigramme. Les données en sont plus détaillées. © Dr. Les flots peuvent être décomposés ou composés. Datagrammes SADT Les datagrammes utilisent le même formalisme que les actigrammes. etc) Plusieurs flèches peuvent être connectées. 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. NKENLIFACK Marcellin Page 16 / 92 . Un nom de flot entouré de parenthèse (e3) n'est pas retrouvé dans le diagramme enfant. • Mécanismes : Ce sont les « entités » nécessaires à la réalisation mécanique de la « fonction » (machines. Si une fonction est décomposée. Les flots Les flots de données sont échangés entre les fonctions. LES DATAGRAMMES SADT commandes écriture Donnée lecture Figure 14. 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 ». le nom du diagramme fils est noté en bas à droite de la boîte. • 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 ». il n'en est pas la traduction inversée.

lecteurs. références du domaine d'emploi de l'application. les "experts". etc. Deux autres modèles ont été définis pour ajouter les aspects informationnels et dynamiques à celui fonctionnel des actigrammes de SADT/IDEF0. 2. ATTRIBUTS NOM CLASSE ENTITE 1:M M:N ATTRIBUTS ATTRIBUTS NOM CLASSE ENTITE 1:1 ATTRIBUTS NOM CLASSE ENTITE NOM CLASSE ENTITE M:1 ATTRIBUTS NOM CLASSE ENTITE Figure 15. le "responsable du projet". Une procédure et des formulaires sont prévus pour organiser et archiver les versions soumises à critiques. 2. Une classe de relation définit un type de relation possible entre les entités de deux classes. les "lecteurs" amenés à lire ou à juger la spécification sans être tenus de rédiger des remarques écrites. le "bibliothécaire" chargé d'archiver et de distribuer les documents. Certains rôles sont définis : • • • • • • • les "auteurs" (analystes) de la spécification (équipe de projet). NKENLIFACK Marcellin Page 17 / 92 . les classes de relation Les entités sont en relation.1 IDEF1 (LE MODELE INFORMATIONS) IDEF1 s'inspire des travaux de CHEN. souvent commentateurs. de conduite de réunion est décrit.2 LES METHODES DE TRAVAIL C'est peut-être l'apport le plus intéressant de la méthode (SADT). © Dr. les remarques des critiques. Les méthodes de travail Une méthode de travail similaire à celle décrite dans IDEF0 est définie. Le cycle auteur lecteur s'applique sur • des brouillons ou des réalisations partielles de la spécification (kits standards) entre auteurs et commentateurs. commentateurs. mais également une technique de travail en équipe.4. • des versions complètes entre auteurs. les réponses des auteurs.3. les "commentateurs" (critiques) amenés à critiquer constructivement la spécification. Ces techniques de travail ou d'autres similaires continuent à être préconisées partout dans le domaine du génie logiciel. le "comité technique" (facultatif) chargé de résoudre les litiges. d'interview.Ingénierie des Systèmes Logiciels 2.3. consultés par les auteurs. (Des auteurs d'autres projets de la même division.3. 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. De même le processus de collection des informations. BACHMAN et NIJSSEN. qui ne définit pas seulement un formalisme. etc).4 LES EXTENSIONS IDEF1/IDEF2 L'ICAM n'a pas retenu les datagrammes de SADT.3. DCQ.

mais si la structure de contrôle est quasi inexistante. Les méthodes de travail Une méthode de travail similaire à celle décrite dans IDEF0 est décrite. 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. NKENLIFACK Marcellin Page 18 / 92 . En effet. 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. Ce diagramme permet de représenter les activités ou conditions affectant l'état général du système. alors elle constituera plutôt une gêne qu’un avantage.structure hiérarchique très modulaire.4 Conclusion Pour une application à caractère distribué. 2. non spécifique d'une entité.aspect dynamique limité . Il faut s’orienter dans ces conditions vers des modèles basés sur les flux de données (SADT.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. 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.nombre restreint de concepts. 2.très bonne lisibilité (même par des non informaticiens) . La représentation formelle est alors un support de la plus grande importance. 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.3. utilise des enchaînements d'activités à l'intérieur du système. SA-RT).5 Avantages et Inconvenients SADT Avantatge : .cohérence entre actigramme et datagramme parfois difficile . Chaque chemin est constitué d'une succession d'activités. les réseaux de Petri. 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 ». sauf si les traitements de données constituent l’essentiel des opérations à modéliser. donc apprentissage rapide et facilité de communication . s’imposeront assez naturellement.pas ou peu de synchronisation Inconvenients : .Ingénierie des Systèmes Logiciels 2. © Dr. l’interaction avec des données est bien prise en compte par le modèle « réseau de Petri à objets ». de par leur fonctionnement asynchrone.4.3.

En résumé. on doit retrouver dans une approche objet au moins 4 principes obligatoires: abstraction. On constate que les applications dites technique. le CoDesign. et une classe d'appartenance. 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). L'état d'un objet est une valeur qui peut être simple. Deux objets o1 et o2 sont égaux si leurs états sont égaux (o1=o2). et les objets (instances) seront considérés comme représentants de classes.marque -… Figure 16. Démarrer () Rouler () Stopper () Démarrer Rouler Stopper -immatriculation . L’univers devient donc une structure composée d’ensemble d’objets déterminant chacun les clés de son comportement. 3. ou structurée. Ces constats ont mis en évidence la nécessité de promouvoir l’abstraction de données. aussi bien dans le domaine de l’Intelligence Artificielle (IA) que dans celui du Génie Logiciel ou des BD. un état représenté par une valeur simple ou structurée. persistance. 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. Exemple: Objet (instance) . telles que la CAO. les applications ont atteint elles aussi un niveau de complexité croissant et de ce fait. NKENLIFACK Marcellin Page 19 / 92 . des outils de programmation sophistiqués. Les types d'objets seront des classes. modularité. auxquels on peut ajouter 3 principes complémentaires : typage. beaucoup de méthodes ont vu le jour. de références à d'autres objets. 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. Dans le dernier cas. des réseaux informatiques et systèmes répartis. Donc nous avons (o1==o2)⇒(o1=o2). la cartographie.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. les systèmes de contrôle temps réel. © Dr. une liste. Ainsi. En fait. 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. Avec l’ère des nouvelles technologies. 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. 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. car ils constituent sans doute la solution la plus souple et offre plus de perspectives pour répondre à ces différents besoins. l’état peut être composé de valeurs simples. ou de valeurs elles-mêmes structurées.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. la modularité et la réutilisabilité [Manhes98] des composants fabriqués. simultanéité. par exemple.Ingénierie des Systèmes Logiciels 3 Approche orientée Objet et UML 3. Deux objets o1 et o2 sont identiques si leurs identifiants sont égaux (o1==o2). nous avons la définition suivante : Objet: abstraction d'une donnée caractérisée par un identifiant unique et invariant. hiérarchie . encapsulation. les langages à objets connaissent un succès grandissant. L'identité et l'égalité de deux objets sont deux notions différentes. Classe VOITURE . un littéral. elles nécessitent à l’heure actuelle. par exemple. Ainsi.

communication. .étude du vocabulaire du projet : noms.Ingénierie des Systèmes Logiciels On distingue 3 types d’abstraction : . … .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). l'analyste construit un modèle du monde réel mettant en évidence les propriétés importantes. les détails d’implantation sont généralement cachés.Abstraction de machine virtuelle : autonomie. 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. . La modularité suppose également la modifiabilité: les objets sont faciles à changer. 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 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 des objets : Le modèle de conception objet s'appuie sur le modèle d'analyse mais contient des détails d'implémentation.identification des objets physiques. NKENLIFACK Marcellin Page 20 / 92 . Cycle de vie spécifique Rappel de quelques définitions Analyse : Partant de la spécification du problème. 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. .Formalisation d’un modèle (liens.…). …) Identification classes et objets Mise en œuvre des classes et objets Identification des relations entre objets Identification des sémantiques des classes et objets Figure 17.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. En capturant la relation de généralisation. objets. Mais. Les possibilités de surcharge et la modularité renforcent la lisibilité des codes. 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. C'est l’objet qui décide la manière d’effectuer les opérations. il facilite la modélisation des objets et la modularité du code. verbes. 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. 3. 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. Hiérarchie (héritage) C’est un « classement » ou ordonnancement des abstractions. Il permet la réutilisation des attributs et opérations des classes d'objets. Les étapes de spécification sont : . Le concepteur du système doit décider quelles sont les caractéristiques de performances du système à optimiser. © Dr. Persistance Ceci concerne la durée de vie d’un objet (important dans les BD. Modularité La modularité est la propriété d’un système décomposé en ensemble de modules cohérents faiblement couplés. ou les données sont disponibles pendant longtemps).Abstraction de coïncidence : objets n’ayant aucune relation entre eux. ou tout au plus ne puissent être intervertis que de façon restrictive. 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é. et élimine les redondances.

en octobre 1994. La méthode unifiée est devenue plutôt le langage UML. Oracle. 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). Un ensemble de partenaires réunis au sein de l'OMG (regroupant notamment IBM. vu le succès initial de ce langage. Généalogie d'UML © Dr.). travaille pour la description d'UML version améliorée. 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. Dans plusieurs cas.5 3.5.Prendre en compte les facteurs d'échelle inhérents aux systèmes complexes et critiques. 3. Les grands traits des objets. HP. Ceci étant. L'examen des méthodes dominantes a permis de dégager un consensus autour d'idées communes. d'association (James Rumbaugh).Créer un langage de modélisation à la fois par les humains et les machines. ces objectifs sont quasiment atteints. Ils d'unifier leurs travaux au sein d'une méthode unique : la méthode unifiée (The Unified Method). on recensait plus de 50 méthodologies orientées objets. 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. 3. 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. repris par de nombreuses méthodes. Rational.Représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets . Les modèles décrivent des façons de procéder courantes. 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. NKENLIFACK Marcellin Page 21 / 92 . s'articulent autour des notions de classe. Les modèles (« patterns ») s’intéressent quant à eux aux résultats du processus et fournissent des exemples.1 LE LANGAGE UML La genèse d'UML La première moitié des années 90 a vu fleurir une cinquantaine de méthodes objets.Ingénierie des Systèmes Logiciels 3. les projets rencontrent des problèmes parce que leurs responsables ne maîtrisent pas des méthodes bien connues des concepteurs expérimentés.5.4 Les « modèles » Les langages de modélisation (à l’instar de UML) permettent de représenter une conception orientée objet. En 1994. Une année plus tard. UML est un élément de base dans la stratégie de plusieurs entreprises. DEC. Ces personnes examinent chaque thème et le décrivent pour que d’autres puissent étudier le modèle et voir comment l’appliquer. . Ces trois chercheurs se sont fixé quatre objectifs : . Ils sont recueillis par des personnes qui repèrent les thèmes récurrents de la conception. Depuis 1996. Les modèles de conception décrivent des techniques de conception. en corrigeant les défauts et en comblant les déficits. Unisys etc. il commence à devenir un « standard de fait ».2 Généalogie UML [wwwGeneal01] Figure 18.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) . ils sont rejoints par Ivar Jacobson. Microsoft.

9 UML 1. des termes se rapportant au standard OMG. temporel.4 Le formalisme d'UML Vous trouverez tous les détails sur les spécifications du métamodèle UML dans [OMGWWW].3). dynamique. Languages and Une Conférence de la programmation orientée objets) Version bêta OOPSLA’96 Soumis à l’OMG en janvier 1997 + OCL (IBM) Révision Soummissiopn à l’OMG en 2003 Définition en cours par une commission de révision Tableau 1. RELATIONS ET CONTRAINTES.1 Date Avant 1993 1993-1994 Octobre 1995 Juin 1996 Septembre 1997 Novembre 1997 Juin 19987 1999-2002 Janvier 2005 2006 Activité Autres méthodes + Booch’91 + OMT-1 + OOSE + Partenaire Booch’93 + OMT-2+… OOPSLA’95 (Object Oriented Applications. Historique Evolution des version d’UML 3. 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. Les paquetages peuvent être emboîtés les uns dans les autres. qui peut être organisationnel. Elles décrivent le système d'un point de vue donné. En combinant toutes ces vues. UML se décompose en plusieurs sous-ensembles • Les vues : Les vues sont les observables du système. architectural. le plus souvent visualisée comme un graphe d’arcs (relations) et de sommets (autres éléments de modélisation).8 MUL 0.0 UML 2.5.2 UML 1.5. leur utilisation est laissée à l'appréciation de chacun. à l'analyse objet et aux méthodes de conception. © Dr.3 Notions usuelles Ce mini glossaire définit les termes employés dans la description du Langage Unifié de Modélisation (UML). METHODES. etc. Un système peut être vu comme un seul paquetage abstrait qui contient tout le reste. par exemple certaines parties critiques. 3. / Programming Systems.0 Méthode Unifiée 0. UML n'étant pas une méthode. en plus de la terminologie spécifique à UML. Figure 19. Paquetage : Un mécanisme universel pour grouper des éléments. logique.0 UML 1.X UML 2.1 UML 1. CLASSE : DESCRIPTION D’ENSEMBLE D’OBJETS PARTAGEANT LES MEMES ATTRIBUTS. De même.Ingénierie des Systèmes Logiciels Evolution des version d’UML Version 1ères reflexions 0. on peut se contenter de modéliser seulement partiellement un système. Diagramme : Une représentation graphique d’une collection d’éléments de modélisation. NKENLIFACK Marcellin Page 22 / 92 . Objet persistant : Un objet qui continu d’exister après la mort du processus qui l’a créé. On retrouvera plus loin.0 est composé de 13 types de diagrammes (9 en UML 1. Métamodèle UML Le formalisme UML 2. il est possible de définir (ou retrouver) le système complet. géographique. même si le diagramme de classes est généralement considéré comme l'élément central d'UML.

4. etc.2TUP (Two track Unified process) UML est très intuitif. Les modèles d'éléments : Les modèles d'éléments sont les briques des diagrammes UML. représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets. • Diagramme de déploiement : représentation du déploiement des composants sur les dispositifs matériels (ordinateurs. 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 de composants (Component diagram) : décrivent les éléments (ou modules) physiques tels que mis en œuvre (fichiers. © Dr. Les 13 diagrammes UML sont dépendants hiérarchiquement et se complètent. correspond à un diagramme de collaboration simplifié. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT). des liens et des interactions . NB : Le POURQUOI. Il décrit les possibilités d'interaction entre le système et les acteurs.) 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. n'est pas défini dans UML actuellement. variante du diagramme d'états-transitions. classe.5.2 Les diagrammes [Fowler03] UML est un langage de modélisation et non une méthode. bibliothèques. systèmes de stockage. En plus des paquetages et des notes.. Exemple d'éléments : cas d'utilisation (CU ou cadut'). • Diagramme d'activité (Activity Diagram) : représentation du comportement d’une opération en terme d’action . contrôle. représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou des acteurs. trois familles de diagrammes composent le langage UML. • 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Ù). 3.. etc.5. qui sont des notions abstraites.. périphériques. NKENLIFACK Marcellin Page 23 / 92 . 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). • Vue des processus : C'est la vue temporelle et technique. Le langage de modélisation est une notation (ésentiellement graphique) que les méthodes utilisent pour représenter la conception. plus simple. ces modèles sont utilisés dans plusieurs types de diagrammes. association. réseaux.RUP (Rational Unified Process) développé par les trois concepteurs d’UML . sans représentation des envois de message. • Vue d'implémentation : Cette vue définit les dépendances entre les modules. Le processus est une façon d’envisager la marche à suivre lors de la conception. plus homogène et plus cohérent que les autres méthodes. synchronisation. 3. • Diagramme de communication (Communication Diagram) : représentation spatiale des objets.) et leurs relations. • Diagramme d’États-Transitions (StateChart / State Machine Diagram) : représentation du comportement d’une classe en terme d’état . c'est-à-dire toutes les fonctionnalités que doit fournir le système. Diagrammes d'interactions (Interaction Diagram) : • Diagramme de séquence (Sequence Diagram) : représentation temporelle des objets et de leurs interactions . • Vue des cas d'utilisation : c'est la description du système "vue" par les acteurs du système. La plupart des méthodes proposent (en principe) un langage de modélisation et un processus. • Vue logique : C'est la définition du système vue de l'intérieur.1 Les vues Les vues peuvent se superposer pour collaborer à la définition du système.4. • Diagramme d'objets (Object diagram) : représentation des objets et de leurs relations. Ceux-ci décrivent le contenu des vues..Ingénierie des Systèmes Logiciels • • Les diagrammes : Les diagrammes sont des éléments graphiques. Il existe des processus qui complètent le langage UML : . il montre la manière dont l'état du système (ou de sousparties) est modifié en fonction des événements du système. bases de données. qui met en œuvre les notions de tâches concurrentes. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI). Les diagrammes peuvent faire partie de plusieurs vues. stimuli.

Le client parcourt le catalogue et sélectionne les produits qu’il souhaite acheter 2. Vous pouvez par exemple ajouter une ligne de précondition (ce qui doit être VRAI au début du cas d’utilisation). • Diagramme de temps (Timing Diagram) : représentation des interactions où l'aspect temporel est mis en valeur. • Utilisez la généralisation quand vous décrivez une variante au comportement standard et que vous voulez simplement la décrire. inversement. 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. Le système affiche les éléments de facturation et les informations concernant la livraison 5.5. Le système valide la transaction 7. Le système expédie un Email de confirmation au client Alternative : Echec de l’autorisation A l’étape 6.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). un cas peut avoir plusieurs acteurs. ACHAT : 1. Formalisme du diagramme de cas d’utilisation : Pendant l’élaboration. Appliquer les règles suivantes : • Utiliser include quand vous voulez éviter la répétition entre plusieurs cas d’utilisation. Le client fournit les informations concernant la livraison (adresse. © Dr. Un seul acteur peut réaliser plusieurs cas et. nous nous occupons d’abord du cas normal. • 3. plus vous devez détailler. • La modélisation par les cas d'utilisation comble le fossé entre les analystes.Ingénierie des Systèmes Logiciels Diagramme global d'interaction (Interaction Overview Diagram) : variante du diagramme d'activité où les nœuds sont des interactions. Un acteur est un rôle que l’utilisateur joue par rapport au système.5. Le système confirme la transaction immédiatement 8. Le client valide ses choix 3. 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. et les quatre derniers chiffres de son numéro de carte de crédit 3b. Les acteurs réalisent les cas d’utilisation. et ensuite des variantes. Plus le risque est important. comme ci-dessous (une application de commerce électronique). Le système affiche les informations associées à ce client concernant la livraison. les diagrammes des cas d'utilisation se retrouveront à tous les stades du projet.5 La modélisation par UML 3. • Utilisez extend quand vous décrivez une variante au comportement standard et que vous voulez explicitement indiquer son activation.5. Le client fournit les informations concernant sa carte de crédit 6. les utilisateurs et les développeurs. livraison en 24 heures ou 3 jours) 4. en déclarant des points d’extension dans le cas d’utilisation de base. Acteur. Aux différents états d'élaboration d’un projet correspond l'utilisation de certains diagrammes. les critères de tarification. 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. Ils montrent les utilisations du système et les acteurs interagissant avec lui. 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. Dans ce cas. 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. NKENLIFACK Marcellin Page 24 / 92 . Nom de l'association de communication Nom de l'acteur Nom du cas d'utilisation Figure 20. Par contre. nous décomposons souvent tous les cas qui deviennent trop complexes.

un cas d’utilisation système est une interaction avec le logiciel. Les cas métier sont utiles. Aux premiers stades de l’élaboration. 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. 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 ». Un exemple de Diagramme de cas d’utilisation Figure 23. mais. © Dr.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. en particulier pour envisager d’autres façons de répondre aux objectifs d’un acteur. Les objets sont créés comme instances de classes. • Les objets-métiers constituent la base de l'architecture des applications. Les termes peuvent être imprécis. mais les cas système sont plus utiles quand il s’agit de planifier. 3. dans l’usage courant. nous nous penchons plus sur les cas métier. alors qu’un cas d’utilisation métier aborde la façon dont un "métier" répond à un client ou à un événement.5.5. 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. NKENLIFACK Marcellin Page 25 / 92 .Ingénierie des Systèmes Logiciels Simuler Convertir Fonction Vitesse Use Stabilité Résoudre équations Use Include précision Include Use Erreur Figure 21 Diagramme de cas d’utilisation de la simulation des systèmes continus ActVenSys Include Include Afficher solutions Include TranDirSys Include Tracer courbes Envoyer Système externe (séquentiel) [Nkenlif04] Figure 22. Nous ne nous attarderons pas sur cette question. Ils interagissent dynamiquement pour offrir le comportement décrit par les cas d'utilisation.

[Fowler03] Figure 24. Voici quelques conseils : • Adaptez le point de vue à partir duquel vous élaborez les modèles au stade où en est le projet. 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. © Dr. Il existe principalement deux sortes de relations statiques : . 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. . créez des modèles conceptuels . • Les définitions des classes et de leurs relations sont regroupées dans des paquetages afin de définir l'architecture des applications. .En phase d’analyse. 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. et vous les utiliserez en permanence.Dans les phases suivantes. NKENLIFACK Marcellin Page 26 / 92 . 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. 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. 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.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). .Ingénierie des Systèmes Logiciels • La modélisation des classes capture le détail de la structure des objets-metiers. Le problème des diagrammes de classe est qu’ils sont si riches que leur utilisation peut être épuisante.

. * Appartient à 1 . * MACRO-ACTION LIEN COUPLAGE SEQ LSAUT ETAPE LIEN EXCLUSIF 1 . NKENLIFACK Marcellin Page 27 / 92 ... * LIEN ACTION ACTION SIMPLE ACTDIRSYS LIEN SELECTIF ACTION DETAILLEE LIEN PARALLELE LIEN SIMPLE [Nkenlif04] ACTION MULTIPLE Figure 25..... * 1 (package) Est décrit par RECVENSYS GRAFCET RECEPTIVITE LOGIQUE RECEPTIVITE TEMPORELLE RECEPTIVITE 1 . 1 ETAPE 0 . * Décrit 0 .Ingénierie des Systèmes Logiciels Exemple de diagramme de classe (package) SYSTEM SEQUENTIEL 0 . * 1 . * Conditionne GRAFCET 1 .... * TRANSITION 1 0 . 1 1 .. * 0 . Un exemple de Diagramme de classes : cas des systèmes séquentiels automatiques et interactions © Dr.

). • Le point de vue de l’implémentation. son TYPE et sa VALEUR par défaut. que l’on appelle nom de rôle. Diagrammes d’objets Un diagramme d’objet est une représentation instantanné des objets présents dans un système à un moment donné. Comme c’est un type de classe spécial. Si vous adoptez le point de vue conceptuel. elle correspond aux interfaces Java. Exemple : Le concept d’"interface UML". Malheureusement. La généralisation est associée à l’héritage. Nous avons réellement des classes et mettons à nu l’implémentation. 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é. UML est bien compatible avec les trois points de vue précédents. représente une classe n’ayant que des opérations publiques. Dans un diagramme de classe UML. NKENLIFACK Marcellin Page 28 / 92 . Un rôle peut être nommé explicitement au moyen d’une étiquette. Notation de la visibilité de clase © Dr. Associations Les associations représentent les liens unissant les instances des classes (Ex. ou peu. mais pas de son implémentation. mais vous pouvez également définir une icône. etc. Ils présentent des différences. Nous nous attachons maintenant au logiciel. De fait. vous tracez un diagramme qui représente les concepts du domaine que vous étudiez. 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. Elle correspond aux membres static en Java ou en C++. 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. et la plupart des modélisateurs ne se préoccupent pas de dissiper la confusion. • Le point de vue des spécifications. une entreprise a un certain nombre de succursales. Visibilité de Classe Figure 26. mais la différence est plus perceptible avec les diagrammes de classe. 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. mais nous nous occupons de ses interfaces. Selon que le diagramme est détaillé ou nom. Stéréotypes Ils constituent le principal mécanisme d’extension d’UML. Attributs Les attributs sont nassez « semblables » aux associations du point de vue conceptuel. la notation d’un attribut peut présenter son NOM. Chaque association a également deux extrémités ou rôles. Généralisation Un exemple de généralisation est celui des clients particuliers et professionnels d’une entreprise. elle est définie comme stéréotype de classe. Il est fondamental de comprendre de quel point de vue on se place. 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. Chaque association a également une multiplicité (« cardinalité ») qui indique le nombre d’objets susceptibles de participer à une association donnée. vous pouvez la traiter comme un stéréotype UML. On peut placer ces dernières dans une classe générique Client (le supertype). un modèle conceptuel ne devrait pas. les stéréotypes sont représentés par un texte entre guillemets (ex : « interface »). CORBA (OMG) et COM (Microsoft). • Le point de vue conceptuel . En étiquetant les classes avec un stéréotype. dont ClientParticulier et Professionnel sont des sous-types. mais également de nombreuses similitides. chacune d’elle étant reliée à l’une des classes de l’association. les membres de classe sont soulignés. une personne travaille dans une entreprise . la délimitation entre eux est quelque peu floue. 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. et aux méthodes et variables de classes en Smaltalk. sans définition de corps pour les méthodes ni les attributs. Généralement. on le nomme souvent diagramme d’instance. tant pour la création que pour l’interprétation des diagrammes de classe. En fait.Ingénierie des Systèmes Logiciels 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). Comme il représente des instances et non des classes. 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).

UML offre une variété d’agrégation plus forte. dériver l’attribut « âge » d’une Personne si l’on connaît sa date de naissance. Exemple : cas d’une Personne sous-typée comme Homme / Femme. La classification multiple permet à un objet d’appartenir à plusieurs types. On peut. Dans la composition. Patient / EnSanté. Remarque : la classification multiple diffère de l’héritage multiple. Composition . par exemple. Dans la classification multiple. Dans la classification unique. © Dr. [Fowler03] Figure 27. 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). Il est important de se rendre compte que la dérivation indique alors une contrainte entre valeurs. un objet n’appartient qu’à un seul type. NKENLIFACK Marcellin Page 29 / 92 . mais un objet ne peut appartenir qu’à un seul type. qui peut hériter de supertypes. 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. et non une assertion de ce qui est calculé et de ce qui est mémorisé. Cependant. l’objet « partie » ne peut appartenir qu’à un seul « tout ».Ingénierie des Systèmes Logiciels Classification multiple et dynamique La classification désigne la relation unissant un objet à un type. Dans l’héritage multiple. agrégation. Figure 28. Classification multiple Agrégation et composition L’agrégation est la relation « est une partie de ». un objet peut être décrit par plusieurs types. De plus. sans qu’il soit pour autant nécéssaire de définir un type spécifique. un type peut avoir plusieurs supertypes. nommée composition. comme le moteur et les roues sont des parties d’une voiture. On étiquette alors une relation de généralisation au moyen d’un discriminateur qui indique sur quelle base s’effectue le sous-tpage. navigabilité. Médecin / Infirmier. qui ne sont pas nécéssairement associés par une relation d’héritage.

et tout les objets qui se référent à ce Client référenceront le même objet logiciel. Ici. parce qu’on souhaite généralement qu’un seul objet logiciel désigne un client du monde réel. mais pas de définition de méthodes ni de champs. ce qui est regrettable. Cette propriété est l’une des plus importantes du modèle objet. © Dr. Il est par exemple normal d’avoir des centaines d’objets qui désignent le « 1er décembre 2007 ». l’identité est très importante. . Notation d’interfaces et classes abstraites Les langages de programmation utilisent rarement l’interface comme construction indépendante. est une classe sans implémentation et ne contient donc que des déclarations d’opérations. et non de l’identité) qui. On représente souvent les interfaces au moyen de classes abstraites. dans ce cas. Habituellement. Une interface pure. le mois et le jour. Il existe souvent plusieurs objets valeur qui représentent le même objet du monde réel. mais on peut aussi ne créer qu’un seul objet Date pour une date donnée et le partager. comme en Java.Ingénierie des Systèmes Logiciels Figure 29. Si vous avez deux objets Date et si vous voulez savoir s’ils mémorisent la même. De telles classes peuvent fournir des implémentations partielles. Les objets valeur sont des objets tels que Date.L’age d’un Employé est calculé : c’est la différence entre la date en cours et la date de naissance. De cette façon.Certaines opérations sur la Société sont une compilaion des opérations des Services. mais que les clients ne verront que l’inteface et jamais l’implémentation. vous devez écrire un test d’égalité (examination de la valeur. Exemple de classe abstraite : FENETRE Objets valeur et objets référence Les objets référence sont des objets tels que Client. NKENLIFACK Marcellin Page 30 / 92 . Figure 30. Ce sont tous des copies interchangeables. Représentation d’Associations et attributs dérivés Notez bien les points suivants (figure ci-dessus) : . les changements apportés à un Client seront disponibles pour tous les utilisateurs de ce Client. On crée et détruit fréquemment de nouvelles Dates. L’idée sous-jacente est que le sous-classement (héritage) fournira l’implémentation. teste l’année. 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. Tout objet qui mémorise l’identité d’un objet Client le fera Via une référence ou un pointeur. c’est vrai qu’on crée un objet Date chaque fois qu’une Date est nécéssaire.

Sur un attribut ou une association. mais elle est également utile pour les classes. NB : gelé ne signifie pas « lecture seule ». … } Ainsi. Il est possible d’attacher une contrainte au rôle : • La contrainte {ordered} : les objet cibles ont un ordre. Une multiplicité de 1 indiquerait qu’il doit y avoir une ligne pour chaque Produit. … } © Dr. Produit unProduit) . 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 ». cette association qualifiée impliquerait une interface telle que la suivante : class Commande { public LigneCommande getLigne (Produit unProduit) . Du point de vue implémentation. frozen indique que la valeur de cet attirbut ou de cette association est immuable pendant toute la durée de vie de l’objet. 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. public void ajouterLigne (Nombre montant. mais ils ne sont pas ordonnés. et une multiplicité de * que l’on peut avoir plusieurs Lignes de Commande par Produit. • La contrainte {hierarchy} : indique qu’ils sont hiérarchisés. Les valeurs en lecture seule seront généralement indiquées avec la contrainte {read-only}. 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).Ingénierie des Systèmes Logiciels 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. autrement dit qu’ils forment une liste et n’apparaîtront qu’une fois dans la liste. qui n’est pas une contrainte UML standard au sens strict. La valeur initiale peut être « null ». NKENLIFACK Marcellin Page 31 / 92 . 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). 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. cela suggère l’emploi du tableau associatif ou d’une structure de données similaire class Commande { private Map _lignes . • La contrainte {bag} : les objets cibles peuvent apparaître plusieurs fois dans la collection. mais que l’accès aux lignes est toujours indexé par Produit. • La contrainte {dag} : indique un graphe orienté acyclique. Cela implique que le constructeur contient généralement un argument fixant cette valeur et qu’aucune opération ne la met à jour. tout accès à une ligne donnée nécessite un Produit comme argument. Associaions qualifiées Du point de vue des spécifications.

Employeur * Emploi 1 0. Dans ce cas. Transformation d’une classe-association en classe à part entière Classe paramétrables Ce concept permet de définir des comportements pour des ensembles. puisque la question ne se pose pas. NB : Ce concept est inutile dans des langages à typage faible comme Smaltalk. . utilisent la notion de classe paramétrable (« template ») ou de patron (« pattern »). Voici le formalisme de representation d’une classe paramétrable en UML: Set Période : IntervalleDate T Paramètre de Classe Paramétrable Inserer ( ) Supprimer ( ) Figure 34.(private) et # (protected). 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.1 Entreprise [Fowler03] Figure 33. en général en créant une classe patron Set. Vous employez n’importe quel marqueur. void supprimer (T unElement) . Ser <Employe> employeSet . on fait appel à la notion de classe-association d’UML. Plusieurs langages de programmation. visibilité Il est possible d’étiqueter tout attribut ou opération par un indicateur de visibilité. Mais UML fournit trois abréviations : + (public). sa signification dépendant du langage. bien qu’il ne soit pas indispensable de le représenter. des opérations et d’autres fonctionnalités aux associations. … } Cela fait. © Dr...1 Emploi Période : IntervalleDate Opération ( ) Figure 32. chacune des classes de l’association d’origine a un rôle monovalué par rapport à la classe Emploi. Exemple de Classe-Association Une autre façon de représenter cette information consiste à faire de Emploi une classe à part entière. Personne * Employeur Entreprise 0.1 Période : IntervalleDate Opération ( ) Personne * 1 0. Classe Paramétrable Le T du diagramme est un paramètre substituable qui représente le type (vous pouvez avoir plusieurs paramètres). class Set <T> { void inserer (T nouvelElemnt) . Le rôle « employeur » est maintenant dérivé. particulièrement C++.Ingénierie des Systèmes Logiciels Classes association Lorsqu’on veut ajouter des attributs. NKENLIFACK Marcellin Page 32 / 92 .. Les multiplicités doivent être modifiées en conséquence.

UML fournit également OCL (Object Constraint Language) pour la spécification formelle des contraintes. et se rapproché bien du langage technique (langage mathématique. exprimées en langage naturel (et encadrées de crochets). OCL est un langage à expressions. 3. A propos de OCL OCL est un langage formel d’expression de contraintes adapté aux diagrammes d’UML (depuis la version 1.anomalieColis » retourne l’ensemble des objets AnomalieColis liés à l’objet Colis concerné. UML vous permet de choisir votre façon de décrire les contraintes et n’impose qu’une règle : les placer entre accolades { }. en mettant l’accent sur la lisibilité. Il permet de spécifier des contraintes sur l’état d’un objet ou d’un ensemble d’objets.Ingénierie des Systèmes Logiciels 3.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. Nous aimons employer des termes courants. • Un état se caractérise par sa durée et sa stabilité. ainsi que de nombreuses opérations de manipulation de ces collections. – postconditions doivent être vérifiées après l’exécution . – attributs dérivés. à l'aide de "gardes" : il s'agit d'expressions booléennes.5. • Une transition représente le passage instantané d'un état vers un autre. Vehicule NumImmatriculation Kilometrage Charge EstLibre * Typeehicule Nom ChargeMax Volume Hauteur / Largeur VitesseMaxVide VitesseMaxCharge est de type 1 { Vehicule. il est aussi possible de conditionner une transition. L’exemple suivant montre l’utilisation du langage OCL. il représente une conjonction instantanée des valeurs des attributs d'un objet.Charge <= TypeVehicule. L’expression « Colis. Exemple de contrainte entre attributs. exprimée en OCL OCL définit plusieurs types de collections d’objets. « Set » est un ensemble au sens mathématique. etc.3 OCL : gestion des Contraintes sur les attributs et associations [Warmer99] Quand vous tracez un diagramme de classe. En d'autres termes : c'est l'arrivée d'un événement qui conditionne la transition. en réponse aux interactions avec d'autres objets/composants ou avec des acteurs. lorsqu'on ne spécifie pas l'événement qui les déclenche.5.5. une grande partie du travail consiste à représenter des contraintes. informatique…) Exemple de contrainte : – invariants sur des classes . • Les transitions peuvent aussi être automatiques. – gardes sur des transitions de diagrammes d’états-transitions ou des messages de diagrammes d’interaction . © Dr. • En plus de spécifier un événement précis. • Une transition est déclenchée par un événement.1 d’UML).ChargeMax } [RoquesVallee01] Figure 35. – ensembles d’objets destinataires pour un envoi de message . avec une grammaire élémentaire et accessible (OCL peut être interprété par des outils).5. OCL limite les ambiguités du langage naturel (bien que lui étant proche). NKENLIFACK Marcellin Page 33 / 92 . 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. L’opération prédéfinie permet de tester si l’ensemble est vide. sans effet de bord sur le système modélisé. 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. et en particulier au diagramme de classes. – préconditions et des postconditions à l’exécution d’opérations : – préconditions doivent être vérifiées avant l’exécution.

y Do : marquer ( ) On : supprimer ( ) copier ( ) Bouton gauche enfoncé Entry : X = e’.x Do : déplacer ( ) Y = e’.x Y = e’.x Y = e. NKENLIFACK Marcellin Page 34 / 92 . executer action ( ) Cond : Transition suivante franchie ou pas de transition Entry : active = false Do : desactiver ( ) [Nkenlif04] Figure 36.y Côté = valeur numéro = Auto Do : Dessiner ( ) Cliquer sur “ étape ” Double cliquer Sélectionner type d’action Saisie paramètres de l’action Do : stockage des paramètres Entry : X = e’. Diagramme d’états concurrents (avec super état) © Dr. Un exemple de Diagramme d’états – transitions ( classe ETAPE d’un système séquentiel) Figure 37.y Double cliquer Sélectionner type d’action Saisie paramètres de l’action Cliquer bouton simulation Condition : transition précédente franchie ou pas de transition Entry : active=true Do : activer ( ).Ingénierie des Systèmes Logiciels 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.

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. • 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). Exemple : il pleut / ouvrir parapluie • Une action correspond à une opération disponible dans l'objet dont on représente les états. © Dr.5. Activité 1 Débranchement Activité 2 Branchement Activité 5 Activité 3 [Garde : si oui] Activité 4 [Sinon] Jonction Fusion Activité 6 Figure 38.5. • En théorie.Ingénierie des Systèmes Logiciels Actions dans un état • On peut aussi associer une action à l'événement qui déclenche une transition. 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. 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. mais seuls les mécanismes complexes ou intéressants méritent d'être représentés. Diagramme d’activité (illustration de fusion. 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é. NKENLIFACK Marcellin Page 35 / 92 .5 La modélisation des interactions Les diagrammes d’interaction capturent le comportement d’un seul cas d’utilisation. • Les actions propres à un état peuvent aussi être documentées directement à l'intérieur de l'état. débranchement et branchement) 3. à 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. tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités. jonction.

un objet est représenté sous la forme d’un rectangle au sommet d’une ligne pointillée verticale. un message qu’un objet s’envoie à lui même. Chaque message porte une étiquette qui indique au minimum son nom. L’ordre dans lequel ces messages sont représentés est de haut en bas. 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. Elle est appelée « ligne de vie » de l’objet. Utilisateur syshyb1 : Systeme Hybride inter1 : sysseq1 : syscont1 : 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 Ecrire consigne Vc Modifier_TC Lire consigne Vc Déterminer A Calculer V Calculer X Ecrire Transfert consigne Vc Transfert de Vr et Xr Lire résultats Xr & Vr Si Vr == 2 ms-1 Vc = 2 ms-1 Si Xr == Q Vc = 0 Si Xr == B Envoyer STOP Vr & Xr TracerCourbe Afficher Résultats Restitution à l’utilisateur Acheminement du STOP Arret Simulation [Nkenlif04] Figure 39 Séquencement d’opérations entre les macro-objets d’un système hybride (l’ascenseur) © Dr. Vous pouvez également faire figurer les arguments des messages et certaines informations de contrôle. Vous pouvez représenter un auto-appel. NKENLIFACK Marcellin Page 36 / 92 .Ingénierie des Systèmes Logiciels Diagramme de Séquence : Dans un diagramme de séquence. On représente chaque message par une flèche entre les lignes de vie de deux objets. en repointant sur la ligne de vie de celui-ci.

10 6. convertir () Perform Rep_lib 4. parcequ’elle permet de mieux voir quelle opération appelle quelle autre opération. Exemple de diagramme de communication © Dr. En revanche. réponsef () simuler 10. paramètres 8. les flèches indiquent les messages envoyés pour la réalisation donnée. NKENLIFACK Marcellin Page 37 / 92 . même si l’orgnisation générale est moins bien perceptible. matrice () 5. simuler 1. afficher () Lorsque le choix se porte sur la fonction. solutions solutions Polynôme 3. la simulation se résume à convertir la fonction et à appeler la résolution de l’équation qui est décrite cidessus [Nkenlif04] 10.Résolution() Fonction de transfert 1. solutions Figure 40. tracer() 9. Un exemple de Diagramme de collaboration : simulation des systèmes continus Diagramme de communication : Figure 41. Comme dans un diagramme de séquence. dériver () 11. UML utilise la numérotation décimale pointée. paramètres Equation différentielle 2. fonction() Consigne 9. tracer() Cal_sol 7. stabilité ( ) rapidité ( ) précision ( ) erreur ( ) 10.Ingénierie des Systèmes Logiciels Diagramme de Collaboration Les diagrammes de collaboration représentent les objets sous forme d’icônes. résoudre 2. l’ordre est indiqué par la numérotation des messages.

trois-tiers ou Internet/intranet. Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. • Différentes topologies de réseau peuvent être modélisées. • Les noeuds sont connectés entre eux. etc. • Les ressources matérielles sont représentées sous forme de noeuds.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. • 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.) qui sont assemblées pour former des applications. • Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants. exécutables. Figure 42. NKENLIFACK Marcellin Page 38 / 92 . UML permet de décrire la topologie des nœuds dans le réseau.5. Les classes sont affectées à des composants fournissant des briques réutilisables pour la construction des applications. qui définissent des sous-systèmes. Elle montre la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. ou des classes de noeuds. objet. Exemple de Diagramme de composants 3. • Les diagrammes de déploiement correspondent à la vue de déploiement d'une architecture logicielle © Dr.Ingénierie des Systèmes Logiciels 3.5. • Le composants peuvent être organisés en paquetages. • Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel précis). Ces composants formeront la base d’une architecture d'application plug-and-play. 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. La nature des lignes de communication et leurs caractéristiques peuvent être précisées. bytecode. Par exemple les architectures client/serveur.5.5.6 La modélisation des composants • Les composants sont les unités physiques de code (source. par encapsulation des détails d'implémentation. Ils permettent de gérer la complexité. à l'aide d'un support de communication.

Ingénierie des Systèmes Logiciels [Fowler03] Figure 43. note © Dr.8 Diagramme de packages Nom de parquetage 1 Dépendance (nommage optionnel) Stéréotype Nom de Paquetage 2 Note textuelle (contrainte textuelle Figure 44. Diagramme de déploiement 3.5.5. NKENLIFACK Marcellin Page 39 / 92 . Dépendance.

en l'occurrence celle des objets. « penser local ».Ingénierie des Systèmes Logiciels 3. nous pouvons donner quelques recommandations. la spécification jusqu'à sa réalisation. qui permettra de spécifier le logiciel. © Dr. qui s’avèrent nécessaires si l’on souhaite concevoir un système par objets : ♦ « Savoir revenir aux étapes précédentes ».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. car il arrive rarement que les classes principales soient trouvées avec exactitude. ♦ « Prototyper rapidement avant de passer à une spécification complète ». Mais attention à une programmation sans spécification. 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. NKENLIFACK Marcellin Page 40 / 92 . car il faut passer très rapidement à une première ébauche du logiciel. viennent se greffer. mais en définissant des opérations de portée locale. Ces classes doivent être introduites naturellement en revenant à la première étape. Pour conclure ce chapitre. des classes auxiliaires dues à la programmation. des la première étape du processus. ♦ Et enfin. en ne cherchant pas à structurer globalement l’ensemble du système. ♦ « Penser abstrait ». surtout qu’à coté des classes principales.

Il a proposé dès le début des années 90. Platform Specific Model). 4. 4. Platform Independant Model) et les modèles dépendants de la plateforme (PSM. Les standards de réalisation étant CORBA (Common Object Request Brokers Architecture). 4. APIs. Evolution des approches du Génie Logiciel sur le plan historique © Dr. l’évolution d’approches du génie logiciel vers l’ingénierie des modèles.Model Driven Enginering). Nous allons présenter le Développement Orienté Modèle (MDD . Le rafinement consiste à introduire dans un modèle abstrait quelques éléments de réalisation de cette abstraction. ou MDE .. Ils sont composés d’une syntaxe (forme définie) et d’une sémantique (signification). langage(s). de distribution et de communication dans un réseau. tel qu’il est spécifié par l’OMG (Object Management Group). 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. Figure 45. MOF (Meta Object Facilities et XMI (XML Metadata Interchange). déploiement. Un modèle est toujours construit selon une vue particulière du systèeme. l’architecture OMA (Object Management Architecture). UML (Unified Modeling Language). qui comprend des produit et standards/documents qui définissent les mécanismes d’interopérabilité. de structure ou de comportement d’un système. On distingue les modèles indépendants de la plateforme (PIM. Ces spécifications sont regroupées sous le concept de MDA (Model Driven Archtecture). Il est constitué de plus de 1000 structures membres. . NKENLIFACK Marcellin Page 41 / 92 . 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. Plateforme : elle est constituée des détails technologiques non pertinents pour les fonctionnalités d’un composant logiciel.Model Driven Development.2 Concepts de base Modèles : ils représentent une partie d’une fonction. maintenance)..1 Évolutions L’OMG (Object Management Group) est un consortium développant et promouvant la théorie et la pratique des objets distribués.Ingénierie des Systèmes Logiciels 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. Abstraction : représente le fait de supprimer les détails non pertinents d’un modèle.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. et mettent à disposition de nombreux outils conceptuels. code.).

4 MDE et UML Les objectifs de MDE (Model Driven Engineering).Représentation de l'application . etc © Dr. architecture. NKENLIFACK Marcellin Page 42 / 92 . et la conformité (du modèle à un méta-modèle). séparation et combinaison des différents aspects d’un système (à l’aide d’un langage spécifique de domaine). Séparation de descriptions fonctionnelles et de l’implémentation. dont MDA est une spécification particulière. 3. L’idée de MDE c’est de concevoir un paradigme paliant aux insuffisances du paradigme Objet. expression précise. Identification.Modélisation . 2. Les relations fondamentales sont la représentation (du système par le modèle). etc. Relation entre ces langages de domaines dans un « framework » global. Ce paradigme n’est pas ammené à remplacer l’approche Objet. . fonction. .Dissociation des aspects indépendants .Statique • L’approche MDE considère elle que « Tout est modèle ».Possibilité de génération de code .Représentation des classes. qui s’est imposées en génie logiciel depuis les années 1980. ● Classes du programme final ● Intégration des « design patterns » 4. 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. • L’approche UML et le développement Objet considère que « Tout est Objet ». classe .Interaction utilisateur-système. etc. sont triples : 1.Méta-modélisation .Ingénierie des Systèmes Logiciels 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. plate-forme.A différents niveaux d'abstraction : système. Rappel du Cycle de vie (basé sur les modèles) ● Au niveau de la modélisation ● Diagrammes de classes ● Abstraction ● Fonctionnalités. 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). . Il existe aussi une possibilité de validation formelle sur les modèles. mais à la compléter. systèmes. tout en donnat une meilleure visibilité.

Ingénierie des Systèmes Logiciels

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

© Dr. NKENLIFACK Marcellin

Page 43 / 92

Ingénierie des Systèmes 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.

© Dr. NKENLIFACK Marcellin

Page 44 / 92

Ingénierie des Systèmes Logiciels

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.
© Dr. NKENLIFACK Marcellin Page 45 / 92

L’usine logicielle et l’ensemble de ses composants met à disposition du développeur un cadre de travail performant. création de la structure de la cible. Contraintes à prendre en compte lors des transformations : Mise en évidence du manque de maturité des transformations. ·MDA : PIM vers PSM 4. et complément avec les attributs et les références). La productivité n’est atteinte que lorsque que cette étape préliminaire est achevée. intégré à un Environnement de Développement Intégré (IDE).Réutilisation .Déjà validés . – orienté structure (2 phases. des règles de mapping). forme une usine logicielle. et à des outils pour automatiser ce processus.Facilitent la modélisation ● Manipulation simple des modèles .6. forment le patron logiciel (patern). ou « template-based » (texte cible contenant du métacode pour accéder aux informations de la source). et surtout. association de plusieurs des catégories précédentes. lors de la création de l’usine logicielle. Contraintes à prendre en compte : Le contenu de la grille doit être réalisé à la main. NKENLIFACK Marcellin Page 46 / 92 . Apport de transformations : Classification des transformations.Ingénierie des Systèmes Logiciels • MDA : PIM vers PSM [wwwMDASup] PIM: Plateform Independent Model PSM: Plateform Specific Model PIM PSM CODE Figure 50. • L’usine logicielle : Le patron logiciel. ● Modèles pré-existants . Identification de leurs caractéristiques. • 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). offre tous les outils nécessaires à un développement rapide de nouvelles applications. peu cher. – orienté transformation de graphe. – hybride.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). 4. – de manière relationelle (basé sur des concepts mathématiques. Elles peuvent être réalisées : – par manipulation directe (implémentation et ordonnancement des règles par l’utilisateur). Apport de patron : Grille d’analyse et identification des éléments indispensable à l’automatisation d’un processus MDA.modifications © Dr.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. L’intégration des Design Patterns (patron) dans MDE est effective aujourd’hui.

le niveau 3 est le méta-modèle des méta-modèles.le niveau zéro est l'implémentation du programme. en respectant les spécifications du MOF (Meta Object Facility).Formalisé ● Les transformations possibles sont présentées à la figure ci-dessous. NKENLIFACK Marcellin Page 47 / 92 . ou méta-méta-modèle.le niveau 2 est le méta-modèle du programme. • UML : On crée une extension d'UML. . Processus MDE ● Modification des modèles Elle s’opère grace à leur description précise : . Ils peuvent représenter un langage connu.1 Langages de modèles Les méta-modèles sont exprimés couramment sous format XMI. [Parrend07] Figure 51. Les Transformations MDE 4. de contraintes (langage OCL). Ils peuvent également être conçus spécifiquement pour un domaine d'application donné.Ingénierie des Systèmes Logiciels 4. [Parrend07] Figure 52.8 Processus MDE Le principe est illustré à la figure ci-après.le niveau 1 est le modèle du programme (classes) . Deux approches existent pour créer un langage de méta-modèle : • MOF : On crée à partir de rien un langage nouveau.Les niveaux de méta-modèles On définit quatre niveaux de méta-modèles : [Parrend07] . IV-A-1 .8. © Dr. par exemple Java ou UML.Langage de domaine . c'est à dire le langage . à l'aide de stéréotypes. c'est à dire la définition d'un métamodèle. Il s'agit donc de la spécification MOF.

2 Étapes de développement MDA Plusleurs phases et transformations sont définies pour un processus MDA : . créer et modifier des schémas XML. XSD est une librairie qui permet de manipuler. plusieurs formats de fichiers sont supportés : 1 Java Annoté 2 XML Schéma 3 Format Rational Rose © Dr. EMF (Eclipse Modeling Framework). ● Les transformations s’opèrent à la chaîne [Parrend07] Figure 54. En ce qui concerne le stockage et l'accès. Pour créer un modèle EMF (au format « Ecore »). Chaaîne de transformations : processus Plusieurs outils peuvent êre mis en jeu durant le processus : ● Plateforme Eclipse: incluant Eclipse. dans des Services Web. 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. . MOF permettra de définir des bases de données de modèles accessibles de manière transparente par les applications. SDO permet d'unifier l'accès à des données hétérogènes. les modèles. par exemple stockés sous forme XML. SDO (Service Data Objects) et XSD (XML Schema Infoset Model). NKENLIFACK Marcellin Page 48 / 92 .Proceder à la génération de code. en partant des diagrammes de classes UML . par les applications. en Base de Données Relationnelle.8.Proceder aux transformations intermédiaires On devra progréssivement préciser ici ce que sera l’application en terme de format de données.Ingénierie des Systèmes Logiciels ● Architecture Figure 53. Architecture du métamodèle MDA 4. réalisation de fonctionnalités.Proceder à la modélisation (normalement en UML) : des modèles manipulables sont générés (au format XMI).

Technologies. Les outils dans la chaîne de transformations 4. pour la manipulation.Ingénierie des Systèmes Logiciels 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. un modèle de type MOF est généré.9 Méthodologie globale de réalisation d’applications Au niveau du processus de développement. logiques. 2 XMI. l'enrichissement est possible de manière simple par la représentation hiérarchique des modèles. ou après traduction en Java annoté (EMF). implémentation o Transformations entre ces langages © Dr. Un langage de transformation de modèle peut également être défini. tous les modèles sont disponibles en format XMI. * Sauvegarde de votre modèle. lui-même composé de . La création de modèle est possible à partir de nombreux formats (Java Annoté. Données Niveaux : Concepts. L'usine logicielle comprend : ● IDE (Environnement de développement intégré) et outils ● Patron logiciel. * Exportation en tant que Classe Java (les diagrammes de classes sont exportés. il est indispensable de systématiser les méthodes de développement logiciel.souvent après avoir enrichi le modèle . 4 Le modèle existant peut être enrichi.Outils de manipulations . à partir de Java Annoté. 2 Ce diagramme UML doit être traduit en Java annoté pour être compris par Eclipse. et importation du fichier XMI créé. 7 Si l'on a besoin de regénérer le code . * Lancement de la plate-forme Eclipse. ● 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. c'est l'implémentation de MOF par Eclipse. Elle fait partie de l'outil NetBeans Figure 55. 3 Ecore. 4 MDR. XML schema. format standard défini par l'OMG. Pour exploiter au maximum ces possibilités. il est souvent indispensable d'implémenter les fonctionnalités de ces classes. avec exploitation directe (Poséidon). et donc de les industrialiser : c’est ce qui est appelé ici « l’usine logicielle ». Services. représentation des modèles de manière graphique. * Exportation sous format XMI. NKENLIFACK Marcellin Page 49 / 92 . Le format « eCore » est l'implémentation Eclipse de la spécification MOF. * Réalisation de programme exécutable Légende : formats de données sur le schéma 1 UML. Meta Data Repository. les formats graphiques UML et les modèles Ecore d'EMF sont préférés. c'est l'implémentation d'une base de données pour modèles compatibles MOF de de Sun.Schéma logiciel. 3 Ensuite. etc.).les ajouts manuels sont conservés. 6 Une fois les classes générées. 5 Le code java est généré à partir des objets eCore enrichis. Nous verrons comment faire la traduction. * Exportation en tant que graphique (si besoin). 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). les autres existent uniquement à fin de documentation). * Ajout des commentaires Javadoc dans le modèle UML. mais la représentation sous forme de fichier texte fait que. Les méthodes et variables peuvent être complétées. Rational Rose. comprenant : o Langage de descriptions de modèles Domaine. le MDE doit apporter des gains de productivité et des gains de prédictabilité [Greenfield03].

Nous présentons ci-dessous. c'est à dire le temps de création de la première version de l'application. Elle a pour vocation d'améliorer la productivité.raffinement manuel Phase d'implémentation . Exemple de schéma de support du processus MDE Le processus complet est présenté à la figure ci-dessous Figure 57. 4.9.une approche incrémentale. de même que l'évolutivité. une méthode de développement d'application correspondante. pour mettre en oeuvre des applications de plus grandes dimensions.choix des principes de l'application (et donc des modèles) .une approche linéaire. c'est à dire la possibilité d'améliorer et d'étendre cette application. exploitable pour des petites applications ou des sous-systèmes .validation des spécifications © Dr. On distinguera deux approches : [Parrend07] . NKENLIFACK Marcellin Page 50 / 92 .1 Approche linéaire Phase de spécifications .validation de l'architecture au niveau fonctionnel Phase de design . Processus complet MDE Une méthodologie de référence est véritablement nécessaire pour rendre MDA réellement opérationnel.adaptation de ces modèles .complétion du code généré .Ingénierie des Systèmes Logiciels Figure 56.génération de code pour la plate-forme-cible .intégration d'outils pré-existants Phase de validation .bon fonctionnement de l'application .raffinement automatique (intégration de modèles existants) .

On obtient un squelette d'application. Chaque affinement doit permettre de nouveaux types d'usage (extension des fonctionnalités). les services. l’introduction de « mégamodele ». 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.9. de l’OMG. +) lors de l'évolution d'une application. Les informations utiles concernant un méta-modèle sont. – histoire.10. selon la méthode linéaire. mais aucune implémentation n’est disponible librement actuellement. ce qui a deux avantages principaux : +) lors de la première réalisation d'une application. et non plus d’en avoir une juxtaposition. des versions fonctionnelles intermédiaires sont disponibles. mais également l’extension de ces modèles par des liens.2 Approche incrémentale Cette approche met en évidence la puissance de MDA. Cependant. comportant tous ses éléments. – auteurs. NKENLIFACK Marcellin Page 51 / 92 . Comme intérêt. Nous l’avons vu avec les nouveaux processus de développement proposés par [Greenfield03]. préférable à un retard pur et simple. support de mobilité.2 La Modularisation des Applications La formalisation des processus de développement rend possible la création d’usines logicielles. 4. et leur exploitation performante suppose une vision macroscopique des éléments disponibles. 2. La principale approche concurente est KDM (Knowledge Discovery Metamodel). 3 peuvent être réalisés par suite d'affinements successifs.10. L’implémentation peut avoir lieu sous forme de « bus logiciel ». * Prototype Réalisation d'une architecture comportant les fonctionnalités minimales (IHM et fonctionnalités clés) selon la méthode linéaire. – définitions alternatives. ou dans un réseau pair-à-pair. Il devient alors possible d’avoir une vision macroscopique des modèles. Cette évolution peut entrer dans un cadre beaucoup plus vaste. aucune spécification n’est prévue pour le maintien de lien entre modèles. selon la méthode linéaire. nous l’avons vu dans la partie correspondante.10 Perspectives de développement 4.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.. La capitalisation des modèles.éventuellement d'une version incomplète. 4. qui modifierait les méthodes © Dr. la méthodologie est conservée. entre autres : – lieu ou se trouve sa définition originale. [Bezivin04] propose. ce qui permet d'accélérer la mise en production . qui supportent non seulement le stockage et la capitalisation des savoirs. mais sans implémentation. méta-modèles et méta-métamodèles. Son objectif est de préciser comment définir des modèles. L’approche Méga-modèle semble très prometteuse. les version intermédiaires doivent être exploitables. L’introduction de ces informations vise à une meilleure interopérabilité entre les outils. * 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. et leurs transformations. – versions suivantes et précédentes. – PSM existants s’il s’agit d’un PIM. * Récursivité Les étapes 2. leur expression. les modèles. et la validation est donc facilitée.Ingénierie des Systèmes Logiciels 4. Les éléments du méga-modèle sont : 1. comme les Bases de données MOF (MOF Repositories). pour palier à cette lacune. * Mise en place des fonctionnalités Compléter chaque fonctionnalité l'une après l'autre. 3. * Architecture complète Intégration des différents principes de fonctionnement : type de client (lourd/léger). L'évolution permanente du logiciel est intégrée dans la méthodologie de développement. et donc les phases de conception. 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. les outils. etc.

de « modèles ». de « framework ». s’accompagne d’une modularisation possible des logiciels. l’aspect de réutilisation. offre la possibilité de mise en place de véritables chaines de production de logiciels. voire nécessite. et progressivement. et « d’outils ». présentées plus haut. mais en tant qu’ensemble de composants assemblables. des modèles existent pour les principaux domaines d’application de MDA. et donc d’améliorer la productivité et la compétitivité d’une industrie encore peu mature [Greenfield03]. et offrirait la possibilité de rendre les applications modulaires. qui permettent un developpement peu onéreux. où tout service peut être disponible indépendamment des autres. Cependant. Ces connaissances sont mises à disposition sous forme de « pattern ». doit offrir de forts gains de productivité et une forte variabilité des applications finales. L’intégration de MDA dans l’industrie logicielle rend possible. Pour les domaines connexes. qui sont disponibles non plus en tant qu’entités monobloc. cette Méthodologie de conception logicielle est innovante. et un enregistrement systématique des connaissances quand à une famille de produits. il est possible de créer des langages spécifiques de domaine relativement facilement. Le développement doit ainsi êetre axé vers la connaissance du domaine d’application. et par conséquent leur génération [Greenfield03]. 4. NKENLIFACK Marcellin Page 52 / 92 . à un niveau d’abstraction supérieur . effectuant chacune une partie du processus. © Dr. La présence d’usines logicielles. elle se traduit par une application systématique de MDA. Cette modularisation extrême. 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. qui ouvre des perspectives méthodologiques immédiates.reste mal aisé.Ingénierie des Systèmes Logiciels utilisées dans les entreprises. Comme intérêt. [Bezivin04] propose un framework de gestion des modèles et de leurs relations basé sur les Mégamodèles. plus que vers la connaissance de la plate-forme cible.c’est à dire à un passage. Ces chaines de production sont composées de plusieurs usines indépendantes. de capitalisation et de mise à disposition des modèles .11 Conclusion De nombreux outils sont disponibles pour la manipulation de modèles. Il s’agit d’une vision à long terme. La mise en place d’Usines Logicielles. Cette modification dans la conception même du logiciel permet l’apparition de chaîne de fournisseurs. fournissant les composants ou les intégrant. l’adoption de nouvelles logiques économiques. Au niveau du développement logiciel. éventuellement proposés par des entreprises différentes. de fait.

• Finalisation. C’est dans cette optique qu’en 2001 aux Etats-Unis 17 grands noms du développement logiciel se sont réunis. 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.« l'hétérogénéité » du projet (plusieurs systèmes d'exploitation. intégration de bases de données.. on peut citer le modèle en spiral.. en Grande-Bretagne. par Jean Pierre Vickoff. Historiquement. • Design avec notamment la présentation générale de l’application. ce qui minimise la modélisation en amont. structure). Il se base sur des phases itératives. ou encore un cahier des charges figé dont les exigences ont évolué au cours de l'élaboration du projet. NKENLIFACK Marcellin Page 53 / 92 . Dès 1994 Jennifer STAPLETON. systèmes en réseaux. Les méthodes agiles sont constituées d’un ensemble de méthodes qui ont un seul objectif : satisfaire le client. de planification et de pilotage de projet. et non un contrat établi préalablement. proposa une méthode de développement rapide d’application (le RAD). qui met plus d'accent sur la production rapide de code opérationnel que sur la documentation. s’appuyant sur cette vision d’une évolution continue. Nous citons ici les quatre principes fondateurs d’agile : [Scott02] [ROQUES07] • 1.. avec la recette et le déploiement du livrable. Pourtant.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 . Sans l’artisan. Ce modèle a notamment influencé l’Extreme Programming (XP) par la suite. Ken SCHWABER et Jeff SUTHERLAND.) . Boehm pour le développement logiciel. la maîtrise d'un projet informatique peut nécessiter un savoir de plus en plus vaste dans différents domaines (logiciels. Pour réduire ce risque de fossé au stricte minimum. 5. 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. . deux « écoles » s’affrontent actuellement : • Ingénierie basée sur les modèles ou Model-Driven.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. présentait DSDM. 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. L’objectif principal ici est de satisfaire le client. leur expertise. .. Dans le début des années 1980. 5.. Ceci est du à plusieurs facteurs : . James Martin. équivalente au RAD2. . ..la "taille" du projet. s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasicomplète en effectuant plusieurs transformations successives. considéré comme une définition du développement Agile et de ses principes. Kent BECK. pour l’adapter au système français (RAD2). 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. père de l'Extreme Programming et coauteur de JUnit. langage(s). Il contient les quatre valeurs fondamentales ainsi que les treize principes de fonctionnement. Les processus qui définissent ce que doit faire chaque personne © Dr. dans la seconde moitié des années quatre-vingtdix.Priorité aux personnes et aux interactions par rapport aux procédures et aux outils … • L’accent est mis sur les individus. Ces facteurs sont en quelque sorte intrinsèques aux projets et participent d'une "manière fixe" à la complexité perçue. créé par Barry W. fondateurs de Scrum.). A l’issue de cette réunion est né le « Manifeste Agile ». préconisée par l’OMG (consortium composant plus de 1000 sociétés). Parmi eux on peut citer Ward CUNNINGHAM l'inventeur du Wiki. code. APIs. Elle a été reprise par la suite en 1991. les méthodes agiles prônent l'incrément et l'itération.. 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.la "complexité" du système étudié (comportement. les meilleurs outils ne servent à rien. • Construction.Ingénierie des Systèmes Logiciels 5 Les méthodes Agiles Les projets informatiques possèdent de plus en plus des aspects très complexes. 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. DSDM est souvent considérée comme la première méthode Agile et. Martin Fowler avec la sociétés « Thought Works » et le serveur d’intégration continue Cruise Control. Dans le cadre de l’Ingénierie des logiciels. • Ingénierie basée sur les méthodes agiles.

coût de la rédaction. en rassemblant des visions différentes d'un même problème. Pour le client.Ingénierie des Systèmes Logiciels 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 négociant un contrat chaque partie se protège plus ou moins des risques financiers.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.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. etc. Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun pour réussir le projet. • 2. coût du maintien en accord avec la réalité. Ces documents ne sont qu'une illusion d'avancement du projet. un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. mais les projets peuvent échouer à tout moment si les délais sont non respectés ou bien les budgets insuffisants. 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.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. NKENLIFACK Marcellin Page 54 / 92 . Figure 58. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Nous présentons ci-dessous. La documentation n'est qu'un support concret qui aide à produire le logiciel. c’est une relation gagnant / gagnant • 4. • 3. Classification des valeurs des méthodes agiles et classiques © Dr. les champs de valeurs des méthodes agiles par rapport aux autres méthodes (classiques). Dans les méthodes Agiles. 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.

préventive. tout les jours : livrer et améliorer ses façons de faire. Issues de l'observation pragmatique de la vie des projets informatiques et se basant sur le partage des responsabilités. parmi lesquelles XP (eXtreme Programming). Scrum. qui adapte les valeurs de XP à la modélisation.Avoir en vue le gain pour le client. le plus tôt possible. Rester souple. Nous les listons cidessous : © Dr. Lean .) La « modélisation agile » est promue par Scott Ambler [Scott02].. 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.Ingénierie des Systèmes Logiciels Le terme AGILE regroupe un ensemble de méthodes. Est-ce que tel document est vraiment utile? Est-ce que cette fonctionnalité a vraiment une valeur ? . . garder la souplesse et livrer le plus vite possible ce qui a de la valeur. Les méthodes Agiles sont conçues pour s’adapter au changement.. . En plus. « coupant » ainsi les coût. être adapté et évolutif. les tests prennent une importance capitale et tout est fait pour faciliter un dialogue simple et direct.S'adapter en tout temps aux circonstances. RUP et RAD 5. Ces méthodes éssayent aussi d’assembler des atouts majeurs des approches RUP (Rationl Unified Process) et RAD (Rapid Application Development). Les méthodes agiles privillégient le développement à itération courte (XP. responsabilité collective…) et libèrent la créativité tout en garantissant réalisme et conformité. éliminer les « bugs » à la source. et à avoir l’humilité de reconnaître qu’on ne sait pas tout et que les autres ont une valeur à apporter à ses propres efforts. Nous listons ici quelques uns des principes fondamentaux : . les méthodologies agiles évitent de s'encombrer de ce qui n'est pas nécessaire. les revus par les pairs. à obtenir des retours rapides et fréquents. de se forcer à développer la solution la plus simple possible qui satisfasse tous les besoins. pas réactive : Donc. une souplesse. à avoir le courage de prendre des décisions et à s’y tenir. . tout les jours. A partir des valeurs fondamentales décrites au paragraphe précédent. Figure 59.Réduire les pertes le plus possible. le code faisant référence.Il faut également un changement de mentalité de la part des participants.3 « Modélisation agile » des projets Les méthodes agiles placent justement l’agilité au centre de l’innovation. NKENLIFACK Marcellin Page 55 / 92 .Avoir une culture de la qualité. la conception commune sur tableau blanc. tout en gardant une une souplesse de planification et d’adptation au changement. Histogramme de mise en perspective des méthodes agiles. Ils doivent avoir deux préoccupation à cœur. ont été déterminés treize principes clés décrits dans le « Manifeste Agile ». Le "test drived development". elles mélangent différentes approches de management (travail en binôme. Ainsi la documentation sera limitée au strict minimum.

Les principes de la modélisation agile sont issus des principes XP. • Clients et développeurs doivent coopérer quotidiennement tout au long du projet. techniques ou fonctionnels. Principes de la modélisation agile La pratique de agile est également issue en partie de XP. • Livrer le plus fréquemment possible des versions opérationnelles. [Scott02] Figure 60. sont à résoudre rapidement pour le bien du projet. avec une tendance pour la période la plus courte. • La simplicité . Les méthodes agiles recommandent que le projet avance à un rythme soutenable • Sponsors. • Les meilleures architectures. avec des itérations allant de deux semaines à deux mois. développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment. à l’ajustement rapide des objectifs projet et des pratiques. ainsi une bonne collaboration et communication avec le client s’en suit.Ingénierie des Systèmes Logiciels • 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. • Bâtir des projets autour d’individus motivés. pour garantir la compétitivité du client. • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. . • Accepter le changement dans les exigences. Leur donner l’environnement et le support dont ils ont besoin et leur faire confiance pour remplir leur capacité à réaliser le travail. Figure 61.SCRUM apporte l’agilité nécessaire à l’accueil favorable de tout changement. • À intervalle régulier. puis ajuste sont comportement en conséquence. • La méthode la plus efficace de transmettre l'information est une conversation en face à face. © Dr. l’ensemble de l’équipe s’interroge sur la manière de devenir encore plus efficace. Pratiques de la modélisation agile Agile s’apuie à la fois sur XP et SCRUM. NKENLIFACK Marcellin Page 56 / 92 . • Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. spécifications et conceptions sont issues d'équipes qui s'auto-organisent. même tard dans le cycle de vie. .XP apporte une capacité à unir l’effort de deux personnes lorsque des points durs.l'art de maximiser la quantité de travail à ne pas faire est essentielle. source de valeur.

Larman veut mettre l’accent sur l’aspect provisoire des modèles. spécialiste de la modélisation agile dit ceci : .Tout modèle est faux ! Et c’est OK Par cet aphorisme provocant.Des modèles multiples et en parallèle Par exemple « diagrammes de classes » et de « séquence » pour faire une esquisse de conception objet . le seul modèle qui fait foi à la fin du projet. Processus de développement utilisé (SCRUM) Craig Larman et la modélisation agile Craig Larman. c’est le code ! The code is the model! © Dr. plutôt que de progiciels couteux et lourds .Ne modélisez pas seul ! La modélisation doit être collaborative et participative .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 .Ingénierie des Systèmes Logiciels [Schwaber04] Figure 62.Des outils simples qui encouragent la créativité Larman encourage l’utilisation de feutres et paperboards. NKENLIFACK Marcellin Page 57 / 92 .

représente l’étape ultime dans l’adoption d’un processus de développement dit « lean » (dérivé de la méthodologie "Toyota Way"). que ce soit au sein d’un cycle en cascade. 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.4. temps d’attente. Les pratiques du TDR trouvent leur source dans la transposition du « lean thinking » au monde du développement logiciel. anomalies non détectées. tests de non-régression manuels.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.Respecter les personnes : d’une part se concentrer sur les personnes qui apportent directement de la valeur pour le client. 5. Modélisation de projet selon Craig Larman 5. Le principe du TDD est qu’aucun code n’est produit tant qu’un test unitaire n’a pas échoué. La mise en oeuvre du lean thinking revient à fusionner les étapes de codage et tests unitaires pour donner naissance à une étape de TDD. dit TDD. Principes du Lean : . C’est l’écriture d’un nouveau « test unitaire » qui va déclencher l’écriture de nouveau « code ». perte d’information.poppendieck.Ingénierie des Systèmes Logiciels L’organisation de la modélisation agile selon Larman peut être représentée ainsi : [Craig03] Figure 63. etc. Dans le monde du développement logiciel. NKENLIFACK Marcellin Page 58 / 92 . Nous avons ici un fonctionnement parfait en mode « pull ». .4 Test-Driven Requirements (TDR) La gestion des exigences dirigées par les tests. les contributeurs les plus importants et les plus reconnus étant les époux Poppendieck (http://www.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. . ou Test-Driven Requirements (TDR). . et d’améliorer fortement la qualité du code.Eliminer les gâchis : tout le lean thinking est orienté vers l’élimination des gâchis. 5.4. 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. 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.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. multiplication des intermédiaires et des échanges formels entre ces intermédiaires.com/). les gâchis sont de plusieurs sortes : fonctionnalités non nécessaires. stocks d’exigences en attente de développement. Cependant.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. © Dr. 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.

3 TDD (Test Driven Development) et TDR (Test Driven Requirement) Le test-driven development est une pratique agile issue de l’Extreme Programming. [MANTEL07] Figure 64. 5. par exemple des règles de gestion. Les trois étapes du TDD sont les suivantes : 1. Le TDR est donc l’aboutissement d’une démarche de changement de ses pratiques vers un processus lean. Les deux dernières étapes vers un processus lean Le processus schématisé à droite illustre une organisation lean.2 Des spécifications exécutables D’après la société Valtech. après avoir placé des points d’arrêt aux endroits du code qu’il pense fautifs. en écrivant des tests plus fins. avant d’écrire le code et les utiliser ensuite comme une mesure d’avancement du travail. On parle ainsi de FTDD. 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. présentent plusieurs limitations. Ecrire le minimum de code qui va faire réussir le test 3. la pratique du FTDD n’est pas suffisante si l’on veut obtenir un processus lean. Ensuite. dans laquelle le client « tire » les fonctionnalités de la première cellule.3. ou demander à un analyste de les créer. plutôt que de les pousser dans la chaîne de production et d’attendre qu’elles soient réalisées. le développeur va exécuter l’application pas à pas. 5. et donc de s’assurer que l’anomalie ne réapparaîtra pas. sur les niveaux plus détaillés pour essayer d’identifier les fonctions fautives.com/) nous permet d’effectuer des tests fonctionnels sans avoir à attendre une version du logiciel exécutable. rapidement et automatiquement. Après avoir atteint un point d’arrêt. cela permet également de se doter d’une batterie de tests de non-régression à l’issue de la correction. cela permet de garantir l’intérêt du test unitaire 2. 5. Ecrire un test et s’assurer qu’il échoue. Functional Test-Driven Development. c'est-à-dire les créer. NKENLIFACK Marcellin Page 59 / 92 . Il est donc possible de rassembler au © Dr. Dans une activité de correction classique. Tout d’abord le test unitaire est… « unitaire » : son but est de vérifier la bonne adéquation du code à la conception. On peut en effet l’utiliser comme outil de diagnostic du code. si importants soient-ils. 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. Non seulement FIT permet d’effectuer des tests quasi-fonctionnels à la façon de tests unitaires automatisés. Au-delà de l’économie de temps par rapport à un débogage classique. et contiennent des tableaux de 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 peut aussi utiliser ces tests à la manière du TDD. mais il permet aussi dans une certaine mesure de corriger plus rapidement le code. ce qui représente un confort immense pour les équipes de développement.3. et zoomer progressivement. en mode « debug ». tout en observant les valeurs des variables afin de détecter le point fautif.4. lorsqu’un développeur recherche la cause d’une anomalie.4. dit XP. 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.1 Appliquer les principes du TDD au niveau fonctionnel L’utilisation du logiciel FIT (http://fit. mais de rendre ces tests abordables par la population concernée. par exemple les tableaux qui vérifient ces règles. Il déroule ensuite la manipulation du testeur. 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. son travail consiste souvent à lancer une instance locale de l’application sur sa machine. Il est donc possible de créer des pages web qui contiennent du texte libre.c2. 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.Ingénierie des Systèmes Logiciels La figure ci-dessous illustre ainsi l’organisation des nombreux projets d’aujourd’hui ayant entrepris le déploiement de méthodes agiles.4. et que l’on peut pousser encore plus loin l’intégration des activités de spécifications et des tests.

un travail de conception permettra de les définir et d’écrire les fixtures qui ont besoin de ces API. Ces faiblesses sont adressées en réajustant les tests fonctionnels et unitaires. Le principe est d’élaborer un modèle à partir duquel on dérive automatiquement les actifs nécessaires aux activités de tests.Ingénierie des Systèmes Logiciels sein d’un même « livrable » les exigences et les tests qui les vérifient. La validation progressive des tests unitaires permet de mesurer l’avancement du travail. 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. NKENLIFACK Marcellin Page 60 / 92 . dont la production du code.(Maître d’Oeuvre) et on écrit ensuite les règles de gestion ou cas d’utilisation correspondants. Il faut disposer d’outils permettant une meilleure collaboration des différents acteurs du processus. 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.3. FIT se révèle trop limité pour répondre totalement à ce besoin. Si les services n’existent pas encore. Nous atteignons ici la dernière étape de mise en place d’un processus lean. Une telle organisation ne peut être supportée qu’avec les outils adéquats. MOE. les tests fonctionnels vont progressivement réussir. On commence par écrire les tests s’inspirant des exemples que fournit la MOA (Maître d’Ouvrage. .TDD : à cette étape. 5. notamment sur l’aspect TDR. le produit est prêt à être livré ! Dans cette organisation. Figure 65. ou des scripts de tests. La forme du wiki paraît idéale pour répondre à cet objectif en permettant une structuration et une contextualisation efficace de l’information. Pour ce faire. c’est-à-dire l’ensemble des exigences et les tests qui les valident. le codage devient en pratique la dernière activité d’ingénierie logiciel avant la livraison. . 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. A cette étape. et une structuration plus contextuelle de l’information. les spécifications deviennent exécutables.FTDD : comme vu précédemment. 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. L’approche MBT © Dr.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. cette étape consiste à écrire les fixtures qui permettent de mettre en oeuvre les tests écrits à l’étape précédente. Dans cette organisation les différentes étapes. Cette étape permet aussi aux développeurs d’enrichir les tests existants lorsqu’ils ne sont pas assez détaillés. Lorsque l’ensemble des tests réussit.Test-Driven Requirements : client et fournisseur travaillent sur un même livrable.4. les développeurs se basent sur des API existantes ou non. L’écriture de tests est utilisée comme un outil de recueil du besoin. Au fur et à mesure de l’implémentation des classes bas-niveau. Par exemple. on peut générer des cahiers de recette. ainsi qu’une facilité de mise à jour. sont conduites par la demande de la dernière étape de la façon suivante : .

4. on ne peut avoir de gain sérieux. 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. l'isolant du reste de l'écosystème informatique. ont besoin d’une meilleure normalisation. Cependant.4. la pratique du TDR entrainera la disparition de certains rôles caractéristiques des silos organisationnels (architecture "en silos" .3. Elle a du sens pour les organisations déjà matures sur cet aspect pour qui l’apprentissage sera modéré.4 Usine logiciel A court terme. adaptées à différents concepts. 5. les méthodes agiles bien que répondant à une demande et à des besoins réels. NKENLIFACK Marcellin Page 61 / 92 . Si une organisation n’entreprend pas ce travail. l’exécution en permanence des tests fonctionnels.Ingénierie des Systèmes Logiciels De la précision du modèle dépend la profondeur des tests que l’on peut générer. Ces méthodologies ont fait l'objet de différentes formalisations. sans en comprendre les principes fondamentaux. Puis.chaque application ou BD l'entreprise reposait sur une plate-forme propriétaire. 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. y ont puisé largement. aussi bien sur des projets aux délais très serrés que sur des projets d'enjeux stratégiques. 5. 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. 5. 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. Par exemple. l'un des plus répandus étant certainement SCRUM.) pour faire place à de nouveaux profils. comme RUP (Rational Unified Process). Même les méthodologies visant les grands projets. et d’un peu plus d’éléments d’assurance qualité. ainsi promu au rang de tests de non-régression.net/articles/changing-roles.html).5 Conclusion : Les méthodes agiles ont désormais fait leurs preuves. ou la modification du code existant. Toutefois. L’approche impose donc un fort investissement dans les activités de modélisation. (http://www. les spécifications et tests « à la mode TDR » seront une charge supplémentaire pour toute l’équipe. • A long terme.davenicolette. Au-delà de l’objectif de non-régression.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. pourra indiquer si une anomalie s’est glissée lors de la production de nouveau code.3. ces activités étant elles-mêmes fusionnées. Le mouvement agile va certainement apporter quelque chose aux entreprises. Ce point participe à la mise en pratique de l’aspect « jidoka » (voir annexe) du lean-thinking. En effet. © Dr. l’usine logiciel agira comme un séquenceur de toutes les activités d’ingénierie logiciel pour les évolutions d’une application.

Les deux types les plus communs de sources de données sont les bases de données et les systèmes de fichiers.) directement sur le clic du bouton.1 Architecture des applications Pour développer une application. Supposez que pour une raison ou une autre. les formulaires. Update. Les composants qui fournissent des services similaires sont généralement regroupés en couches. • La couche d'accès aux données fournit une interface simple pour accéder aux données et les manipuler. Les applications d'entreprises modernes sont communément basées sur l'utilisation de plusieurs composants. Les composants de cette couche abstraient la sémantique de la couche de données sous-jacente. Chaque composant fournit typiquement des méthodes pour créer. le premier réflexe que l’on va avoir sera d’insérer le code d’accès aux données (listes des fournisseurs.Ingénierie des Systèmes Logiciels 6 Processus de Développement. • La couche de stockage des données comprend l'ensemble des sources de données de l'application d'entreprise. Couche de présentation Comosants d’interface utilisateur Composants de comportement L’Interface Graphique (GUI. Delete ») des entités de données. alors que les transactions complexes et longues peuvent utiliser des composants d'ordonnancement avec états. Outils et Métriques de Qualité Nous avons déjà vu au chapitre 1 que dans l’Ingénierie des systèmes logiciels. ou encore des exceptions personnalisées). puis de rajouter le code qui va bien sur le clic d’un bouton par exemple. clients. 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. • La couche métier intègre les fonctionnalités et les traitements propres à l'application. Business Logic Layer) Figure 66. Si à l’inverse vous aviez utilisé le développement en couche. permettant ainsi à la couche métier de ce concentrer sur la logique applicative. elle pourrait vous poser beucoup de difficultés par la suite. Data Access Layer) Stockage des données Bases de données La couche métier (BLL. Une application « en couche » est généralement composée d’au moins 4 couches. Cela participe de ce que l'on appelle communément une architecture orientée par les services (SOA = « Service-Oriented Architecture »). ainsi que tout ce qui régit le comportement de l'interface utilisateur. 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. 6. 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. produits. Read. lire. on retrouve des méthodes et surtout plusieurs outils servant tout au long du processus de développement. comme les pages Web. Même si cette technique fonctionne. on a pris l’habitude de concevoir l’interface utilisateur. 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). Graphic User Interface) Couche métier Interfaces de service Ordonnancement métier Composants métier Les objets métier (BusinnessObjects) Couche d’accès aux données Composants d’accès aux données La couche d’accès aux données (DAL. chacun fournissant une fonctionnalité particulière. vous n’auriez qu’à modifier la couche d’accès à la liste de fournisseur ou des clients. Les fonctionnalités simples peuvent être implémentées avec des composants sans états. etc. NKENLIFACK Marcellin Page 62 / 92 . Si l’on est débutant. Architecture des applications d'entreprise • La couche de présentation contient les composants qui doivent interagir avec l'utilisateur de l'application. Ceci vous contraint de revoir tout le code de votre application avant de la redéployer sur des postes clients. © Dr. mettre à jour et effacer (CRUD = « Create.

) .restructurateurs de code 6.dictionnaires .La migration d’un environnement graphique à un autre est relativement simple Lorsque l’on dit que le travail en équipe est optimisé. les couches métier et d'accès aux données sur un serveur d'applications. Dans un scénario très simple. 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 . là encore.générateur (de codes) .3 • Quelques facteurs pouvant influencer le choix de langages et outils : Niveau d'abstraction o doit être adapté à la tâche ( e.2 Place des Outils Les outils ont un rôle fondamental dans la réalisation d’un processus logiciel. la raison est simple : alors qu’un des membres de l’équipe travaille sur la couche d’accès aux données.prototypeurs .Le travail en équipe est optimisé . dans le cas de migration (d’interface utilisateur par exemple).optimiseurs de performances .La maintenance des données est indépendante du support physique de stockage . 6. structures de fichiers.g. Ainsi. un autre peut tout à fait travailler sur la couche métier ou sur l’interface graphique sans perturber le travail de ses collègues.La gestion des traitements depuis la couche de présentation est facilitée .gestionnaires (de besoins des applications. De même.Ingénierie des Systèmes Logiciels Il est important de noter que ces couches ne sont que des regroupements logiques de composants qui constituent une application.simulateurs . et les bases de données sur un serveur dédié à cet usage. etc. dossiers de projets) . toutes ces couches peuvent résider sur une seule et même machine.analyseurs . la couche de présentation peut se trouver par exemple sur la station de travail de l'utilisateur final. de composants réutilisables. maquettes d’écrans ou d’états. de projet. Dans un autre un peu plus complexe (mais assez commun). 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. modèles.La maintenance des traitements est simplifiée . NKENLIFACK Marcellin .compilateurs de test . inutile de redévelopper tout ce qui a été fait jusqu’à maintenant : il vous suffit de modifier l’interface. 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.éditeurs (de spécification. codes sources. C vs Prolog ) langage machine < assembleur < FORTRAN < C < Java Page 63 / 92 © Dr. la tâche est simplifiée. Avantages de cette technique de développement multicouche : .

.4 Environnements intégrés de programmation Dans un tel environnement. . make. cet enthousiasme doit être modéré: le processus logiciel est encore loin d'être maîtrisé et les différentes formalisations qui en sont proposées font encore l'objet de controverses. 6. 6.g.. Un AGL est basé sur des méthodologies qui formalisent le processus logiciel.g. C. 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. 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. de haute puissance expressive. Java).g. L'informaticien a encore de belles années de travail devant lui avant d'être supplanté par des AGL.g. Assembleur->C …) 6. 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 hautniveau. 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.).. ICON=texte) o un langage général (e. la génération de tests. 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..2 Les outils « CASE » (Computer Aided Software Engineering) Les AGL intègrent différents outils d'aide au développement de logiciels. chacune des phases qui le composent.g. (Exemple : intégration C->Pascal. de diagrammes (TRAMIS VIEW. débogueur symbolique avec exécution pas-à-pas Performance o compilateur rapide? exécutable rapide? (e. et à l'intérieur de ce processus.5. SGBD...g. Mais ils ne communiquent pas pendant l’exécution. COBOL=administration-gestion. appelés outils CASE: éditeurs de texte (vi. C vs Java) Degré de spécialisation o un langage spécialisé est conçu spécialement pour certaines applications (e. macros. compilateur avec messages précis. . C vs C++.5.g. SPSS=statistiques. mais pas très performant) Note 2: parfois il est possible d'écrire un programme en utilisant plus qu'un langage. la génération d'interfaces hommemachine. et dans tous les cas. Lisp vs Scheme) Puissance expressive o supporte plusieurs styles de programmation (e. Autrement dit.000 lignes)? o modules? compilation séparée? (e. outils de gestion de configuration (make)..g. Ada.). © Dr. programmation structurée) o le langage détecte-t-il les erreurs? à la compilation? à l'exécution? (e. etc. il s'agit d'un système pour le développement logiciel assisté par ordinateur. . X-fig. compilateurs. plus c'est facile de le maîtriser (e. 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. 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. emacs. debuggers..Ingénierie des Systèmes Logiciels • • • • • • • • • Simplicité conceptuelle o nombre et régularité des concepts o plus le langage est simple.g. sécuritaire et (en principe) portable.1 Les Ateliers de Génie Logiciel 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. outils pour la mise en forme (pretty-printers).5 6. Néanmoins. notamment en faisant le suivi des différentes phases du processus logiciel et en offrant un cadre cohérent et uniforme de production. sont bien loin d'être totalement automatisables. ce qui permet d'utiliser le langage le plus approprié pour chaque partie. 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. NKENLIFACK Marcellin Page 64 / 92 . 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. Et ils ne sont parfois pas interopérables avec des outils extérieurs.).

.. et assurer ainsi un enchaînement cohérent des différentes phases du processus logiciel. 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). transforment. . D’autres environnements de développement existent sous Unix/Linux qui intègre différents outils pour la programmation et le test. des SGBD. code. prettyprinters. 6. Certains environnement. Enfin.. X11 sous Unix ou Windows sur DOS). programmation (éditeurs de texte.) et utilisés pour l'analyse et la conception des systèmes d'information. mise au point (debuggers. 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. Ces différents environnements proposent des bibliothèques de composants.. Ces environnements permettent un développement rapide et convivial...5. Synthesizer Generator. un générateur de prototypes (TRAMIS Dialog).. Ces ateliers sont généralement basés sur une méthode ou un langage d'analyse et de conception (JSD. A partir de la description formelle d'un langage (à l'aide de grammaires attribuées. des interprètes. En revanche. des générateurs de (squelettes de) code. jeux de test. . Un AGL doit prendre en charge la communication de ces données entre les différents outils. . L'intégration des données est faite par l'intermédiaire des fichiers Unix.Environnements orientés langages . pretty printers. etc. Les environnements de conception (upper-case) : ces ateliers s'intéressent plus particulièrement aux phases d'analyse et de conception du processus logiciel. sont dédiés à un langage particulier. . 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. des outils pour le prototypage. des éditeurs dédiés au langage. utilisent. Oz. 2.) des données: spécification.)... optimiseurs.. de manière à les faire coopérer de façon uniforme. ce qui facilite leur utilisation (voir par exemple l'interface du Macintosh. • Intégration de l'interface utilisateur : tous les outils intégrés dans l'AGL communiquent avec l'utilisateur selon un schéma uniforme.. Gandalf.3 L'intégration d'outils CASE Un AGL intègre différents outils CASE.... sur une même machine. Ils intègrent généralement des outils pour l'édition de diagrammes (avec vérification syntaxique). manuel utilisateur.... . Un AGL devrait également gérer la cohérence entre les différentes versions de ces données (gestion de configuration).. debuggers. . Merise.Environnements structurels . à partir d'une spécification algébrique on peut générer des jeux de test.. . Yourdon. des compilateurs. générateurs d'interfaces homme/machine... des générateurs d'interfaces homme/machine.5.4 Les différents types d'AGL Sur le plan historique. 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 !!!). Ils intègrent généralement des éditeurs (éventuellement dirigés par la syntaxe). Il existe par exemple des environnements dédiés à InterLisp.Environnements boites à outils . une interface graphique. des outils pour l'édition de rapports.. NKENLIFACK Marcellin Page 65 / 92 . modèle conceptuel des données. ce qui peut poser des problèmes de portabilité et de coût. plus évolués. . © Dr. 6... WinDev est un environnement de développement.). le code généré par un éditeur de texte est compilé par un compilateur..Ingénierie des Systèmes Logiciels Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel : conception (éditeurs de texte... concernant notamment la gestion de configurations. interviennent durant la totalité du processus logiciel. compilateurs. Smalltalk. de diagrammes.. outils de génération de tests. SADT. l'application développée est intégrée dans (et généralement inséparable de) l'environnement. debuggers. Cette intégration peut être simplement physique : tous les outils de l'AGL utilisent un seul format de représentation des données. . la gestion (limitée) de configurations est faite par make. .). 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. il existe des générateurs d'environnements de programmation : Mentor. Certains outils. par exemple des fichiers UNIX. • Intégration des activités : un AGL peut gérer le séquencement des appels aux différents outils intégrés. on a noté une évolution rapide suivant les tendances ci-après : . la gestion de projet. Cette intégration peut (devrait) s'effectuer à trois niveaux: • Intégration des données : Les outils CASE manipulent (génèrent..Environnements orientés « méthodes » On distingue essentiellement deux types d'AGL selon la nature des outils intégrés: 1. Loops (l'environnement Loops fonctionne sur une machine dédiée à Loops). des dictionnaires de données. TRAMIS est un environnement de conception qui intègre notamment un éditeur de diagrammes (TRAMIS View). UML .

et donc de les corriger ! Le "Toyota Way" correspond à une méthodologie extrêmement appréciée aujourd'hui. etc. vérifications du respect des règles de codage. un pretty-printer. il n'est pas possible d'aller vite sans qualité.. NKENLIFACK Marcellin Page 66 / 92 . Autrement dit.. Structure d’un EIPL (Environnement Intégré de Production de Logiciel) 6. 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.Ingénierie des Systèmes Logiciels de la logique).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. 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. dans des buts tels que la mise en conformité par rapport aux standards du marché.6 Ateliers et Cycle de vie Dans un AGL. Le but de tout cela étant bien entendu de rendre le code plus sûr.. un debugger. d'un logiciel informatique). 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. et en Java en particulier. un interpréteur. et en quoi est-il important de la contrôler ! En paraphrasant Wikipédia. 6. Besoins Version Spécifications Conception Test Projet Intégration Mesures Maintenance Configuration Base de données SE (Système d’Exploitation) Outils Concept. 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. . contenant un éditeur dédié au langage. Dans le monde informatique en général. mais qu'il n'est pas possible non plus de faire de la qualité sans vitesse. Il est donc possible de contrôler la qualité de son code grâce à ces outils. analyse de la couverture du code par ces tests. Toutes ces raisons ont poussé les acteurs à évoluer vers une standardisation. 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. 6. 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. 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. to get quality right the first time". Outils Program.5. ces différents systèmes génèrent un environnement de programmation dédié au langage. © Dr. Mais rappelons ce que c’est que la qualité d'un logiciel. variés et couteux. on retrouve plusieurs environnements centrés sur un formalisme pouvant permettre de couvrir le cycle de vie du logiciel. Plus largement.5. mais de permettre d'y déceler les erreurs le plus rapidement possible. c'est aussi un moyen que se donnent certaines organisations. Outils spécifiques Gestion d’objet BD Outils d’édition auto. Noyau Outils gestion Outils d’accès Interface publique Figure 67.6 Intérêt de la qualité d'un logiciel.

RelationalTable. on demande deux choses à un ouvrier. alors que SQL le sera au niveau du PSM.). NKENLIFACK Marcellin Page 67 / 92 . Le choix d’un outil de développement répond à plusieurs types d’interrogations. on réduit les défauts et on augmente la productivité. . fier qu'on lui demande de se servir de sa tête et de sa créativité.Ingénierie des Systèmes Logiciels Chez Toyota.associations . UML peut être utilisé comme modèle PIM. La notation UML qui s’impose dans bien des domaines de l’informatique s’adapte de mieux en mieux aux bases de données. etc. on leur demande de demeurer des humains.rétro-conception d’une base de données. Un processware est une application qui fournit les traitements de gestion entre différents progiciels.permet – il de développer des applications client-serveur ? . Ce profil permet de décrire des bases de données notamment à l’aide de stéréotypes prédéfinis (Table. Mieux..héritage .quelle est la composition de l’équipe opérationnelle envisagée ? Le second groupe concerne les spécificité techniques du langage lui même : . Le premier groupe de questions est centré sur une analyse fine du projet à réaliser et sa faisabilité. Ça garde l'ouvrier éveillé. L'un des intérêts de la surveillance de la qualité est la détection précoce des éventuels problèmes.. leurs façons de faire.classes-associations .qui sera le chef de projet et comment se fera le suivi ? .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 : .. "You can't control what you can't measure". Demandez aux développeurs de livrer du code. Depuis plus de 35 ans.agrégations . "On ne peut contrôler ce que l'on ne mesure pas". 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). sont des progiciels d’interconnexion entre applications. la conception des BD était réalisée à l’aide du modèle entité-association. 6. [Linsolas09] Figure 68. Quand le domaine d’implémentation se cantonne aux bases de données.7 6.. puis de pouvoir traduire dans un ou plusieurs PSM (Platform Specific Model) réalisant ainsi l’implémentation concrète du système. À la longue. 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é.. d'améliorer tout les jours.disposons nous de ressources techniques et du temps nécessaires en interne ou devons nous passer par un prestataire extérieur ? . Suivant l’approche de réalisation de logiciels MDA (Model Driven Architecture). View.8 Les « processwares » : Choix de l’outil de développement : Les processware ou Intergiciel. Le second point étant bien plus important que le premier. mais plus important encore.quel est le niveau de portabilité du langage (outils) ? . Le premier pas a été réalisé par Rational Rose avec son profil UML (UML profile for Data Modeling).. pas de devenir des machines.contraintes inter-relations . D'où l'importance d'utiliser un outil de qualité tels que « Sonar » (voir plus loin dans le chpitre). on comprend très vite l'importance de la détection rapide des erreurs. chaque jours: livrer des pièces et trouver de meilleures façons de le faire. Le coût de correction d’une erreur croit exponentiellement avec le temps Comme le rappelle Tom DeMarco. © Dr.

Ingénierie des Systèmes Logiciels

6.9
6.9.1

Outils de Développement « MDA »
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.

© Dr. NKENLIFACK Marcellin

Page 68 / 92

Ingénierie des Systèmes Logiciels

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 »?

© Dr. NKENLIFACK Marcellin

Page 69 / 92

Ingénierie des Systèmes Logiciels

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 [Linsolas09]

qualité de ses projets avec l’outil « Sonar »

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).
© Dr. NKENLIFACK Marcellin Page 70 / 92

JSON. F Le test a échoué (Failure). 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 . qui fait le lien entre les tests et les API de l’application. Le moteur FIT s’occupe du reste. .Journalisation des tests aux format XML.Analyse de la couverture de code (code coverage analyse). à la création de ces story-tests.10. .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.Ingénierie des Systèmes Logiciels • Gestion de profils pour les règles de codage. • Identification des points faibles d'un projet.Support des objets "mock" (simulateur d'objets) . Il nécessite par contre de déployer le code source sur un serveur pour pouvoir exécuter ses tests. les grouper en suites.Un grand nombre de méthodes de tests. • Support des plugins. • Fitnesse (http://fitnesse. l’un des contributeurs du processus XP.c2.Eclipse PDT (le support a été prévu). C’est un bon outil pour l’étape TDR et tests de recette. appelé fixture. E Le test a généré une erreur PHP. 6. L’idée initiale de l’auteur était de créer un moyen simple de tester les story-cards.NuSphere PHPEd. il peut également fonctionner sous Windows.10.PHPEdit.. et de pouvoir associer le client. 6.11 Outils de test TDR avec les méthodes agiles FIT (http://fit. mais n’est pas suffisant pour supporter une approche compréhensive du TDR jusqu’au code. PHPUnit offre quelques fonctionnalités avancées . son éventail de fonctionnalités permet de créer rapidement des tests unitaires complets et adaptés aux applications PHP professionnelles. . .Organisation et exécution des test flexibles. Il utilise la fixture pour lire le tableau et appeler les API de l’application avec les paramètres adéquats. dans une page web standard.3 Utilitaires : • L'utilitaire de ligne de commande : phpunit est le principal outil dédié à la configuration et à l'exécution des tests unitaires.. NKENLIFACK Marcellin Page 71 / 92 . PHPUnit est pris en charge nativement dans les IDE suivant : . PHPUnit offre quelques qualités. Deux outils permettent aujourd’hui de combiner wiki et moteur de tests : Fitnesse et Greenpepper. Cet utilitaire est optimisé pour les systèmes Unix/Linux. TAP ou dans une base de données. 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. 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. surlignant les violations des règles de codage qui s'y trouvent. Le test passe.Un utilitaire en ligne de commande complet. vous pouvez les exécuter indépendamment les uns des autres.Support de « Selenium RC » (environnement de développement intégré (IDE) / tests fonctionnels) .Un syntaxe simple. concept fondamental dans XP. I Le test est marqué comme incomplet (Incomplete). . S Le test est ignoré (Skipped). ou rassembler les suites elles-mêmes afin d'exécuter le tout en une seule fois. . équivalent des spécifications fonctionnelles dans le processus XP. • Fonction "Time machine" permettant de comparer plusieurs versions d'une même application.PHPEclipse (voir plugin Eclipse SimpleTest ). 6.2 Tests unitaires avec « PHPUnit » (un OpenSource) [Grossglauser07] PHPUnit est un framework de test unitaires simple et efficace. © Dr. • Visualisation du code source. . Mais. facile à comprendre et à retenir.Zend Studio. . et d’accompagner ce tableau d’un bout de code.com/) est un outil créé par Ward Cunningham. . PHPUnit offre une solution particulièrement flexible pour organiser vos tests.

DOMF. JTA (Java Transaction API). ActiveX. Initialement. Il est également possible de choisir différents contextes d’exécution.12. HTML. On peut ainsi gérer plusieurs environnements de tests selon les phases de tests à effectuer (développement. L’outil Leirios Test Designer (http://www.12 Autres outils 6.Il est compatible avec la plate forme J2EE (Java 2 Enterprise Edition).Il est ouvert aux supports transparents de tous les types de clients : CORBA. Smaltalk. HTML. Lors d’une bonne mise en œuvre de Greenpepper. ECNA. NKENLIFACK Marcellin Page 72 / 92 . Note : Motif est une interface graphique utilisateur normalisée pour le système Unix (comme Windows l’était pour le DOS initialement). Mais. Schéma de la plateforme DOC Finalement. Les tests peuvent être exécutés indépendamment depuis un serveur ou depuis le poste du développeur. etc. Environnement utilisateur HP View [OSF / Motif] New Ware Outils de gestion APPLICATIONS et du réseau Services d’objets répartis (distribuive Smaltalk de HP) DOMF (Distributed Object Management Facilities) Services de réseau (NCS) [OSF/DCE] Service de gestion de données (Open ODB) [POSC ART] Plateforme Client ou Serveur Environnement de développement de logiciels (Soft bench) [NIST. appelé modèle de test. homologation. © Dr. il est une implémentation du standard DCE de l’OSF. l’équipe de travail peut être répartie sur plusieurs sites avec des développements effectués dans plusieurs villes comportant plusieurs développeurs. un moteur de workflow.Ingénierie des Systèmes Logiciels • Greenpepper (http://www. XML. C++. . programmation Java. .com/) permet d’utiliser un modèle comportemental formalisé avec un sous-ensemble d’UML. JDBC. Ces cas de test peuvent ensuite être traduits en scripts de tests avec un adaptateur adéquat. DOC est à cheval entre RPC procédural et RPC orienté objet (ORB).greenpeppersoftware. ActiveX. Ce délai inclut les phases de tests d’homologation et de pré-production (tests d’intégration avec les systèmes environnants). Figure 70.12. C++] O. Une extension permet également d’intégrer JIRA. 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.leirios. C. ce qui assure la prise en charge des technologies J2EE : EJB. DHTML.Il s’intègre avec les outils de développement Web « Power J ». pour générer les actifs de tests.S. Les extensions permettent l’utilisation du wiki Confluence et l’intégration à une « usine logiciel » par des scripts Maven.2 L’environnement de référence DOC (HP) DOC (Distributed Object Computing) est un RPC proposé par HP. JTS (Java Transaction Server). il se rapproche beaucoup plus de l’ORB à cause des composantes (outils) C++. • 6. JNDI (Java Naming and Directory Interface).1 Le serveur d’application universel EAS : Enterprise Application Server [Sybase] EAS est un serveur d »’applications adapté à la nouvelle informatique. 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. préproduction) ou selon la version des spécifications. Servlet. PowerBuilder … . en attendant que cette couche soit testable avec des outils comme Greenpepper ou FIT. recette. JavaScript. 6.com/) est un outil plus puissant combinant un moteur de tests open-source et une série d’extensions payantes. 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. Tout ceci fait que EAS est adapté au développement d’applications Internet et Intranet.

Ne fonctionne pas correctement sous Windows .com/product/vpuml/productinfovpumlse.com http://www. Acceleo. Netbeans 5.visualparadigm.ibm.html http://myeclipseide.Win’Design Logiciels libres • • • • • • • • • • • • • • • • • http://www.com/en/product/mega_designer/ http://www.12. .visualuml. une base de données à l’aide de la notation UML 2.http://www.) . Méta modèle UML2. de Borland .PowerAMC . arrivé avec Visual Studio 2005.com/fr/ ATL open source : transformations de modèles vers ou depuis UML (etc.MyEclipse .borland.com http://www.Ingénierie des Systèmes Logiciels 6.com/ http://www.Poseidon . Page 73 / 92 © Dr.org Visio : Outil non complet de microsoft .Visual Paradigm . etc.http://argouml.com/modelsphere.Visual UML . un modeleur UML sous GPL pour Windows.Together . On y retrouve entre autres : • Les produits : MSDN Library Visual Basic Visual C++ Visual FoxPro Visual J++ Visual SourceSafe Visual Interdev SQL Server Image composer Media manager Anomaly Tracking System • • • • Les outils multimédia : L’outils système : L’outil transactionnel pour l’intégrité en réseau : Transaction server » L’outil de travail collaboratif : Visual Studio Team Foundation Server.win-design. Poseidon. 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). L’offre s’appelle « Visual Studio ».ModelSphere .7.mega.Objecteering .Enterprise Architect . Logiciels propriétaires Rational Rose : Un des outil les plus important du marché .3 L’offre logicielle de Microsoft : La plate forme de développement de Microsoft fournit tous les outils nécessaires pour élaborer des solutions clientserveur.com/products/developmentintegration/poweramc http://www-306.rational.Visio .com/office/visio Together.com/Products.objecteering.Rational Rose Data Modeler . ArgoUml un modeleur UML sous Licence BSD .html http://www. NKENLIFACK Marcellin .microsoft. d'avoir une gestion des sources.microsoft. Linux.jsp http://www.togethersoft. En passant par la génération des modèles de type MOF et l’import/export de modèles au format XMI.silverrun. Eclipse GMT-XUML Eclipse UML2.sparxsystems.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.com / Racheté par IBM Together (rachété par Borland/Inprise) : Outil fortement couplé avec Java : .com/index.magicdraw.http://www. .sybase.5 Staruml. basé sur ArgoUml (version commerciale) .1 .MagicDraw .tigris. générateur de code source à partir de modèles UML.. 6.com/software/awdtools/developer/datamodeler/ http://www.12. BOUML.au/products/ea. ArgoUML : Outil Open Source. MacOS X et Solaris.com.com/france/office/visio http://www. Internet et Window. Gaphor un modeleur UML sous GPL la version actuelle est 0.http://www.com. Il permet de définir des priorités sur des tâches. . en version libre.MEGA Designer . sans interface graphique.htm http://www.php?id=30 http://www. Dia Umbrello un modeleur UML sous GPL.com/ http://gentleware.

de IBM Software Rational .12. 6.. MPD . un plugin UML pour Eclipse .Ingénierie des Systèmes Logiciels • • • • • • • • • Rational Software Architect / Rational Software Modeler (et toujours Rose/XDE).langages de programmation classiques (procédural. DESIGN/IDEF Design/IDEF est un outil de Meta Software Corp. PowerDesigner. en Java . Il comporte également un simulateur exploitant un langage textuel d'automate. SPECIFX SPECIFX est un outil édité par IGL supportant IDEF0. on retrouvera . Omondo EclipseUML. UNIX (Motif. . SDE for Eclipse.12. MagicDraw. Enterprise Architect. MFC).5 LES OUTILS SADT De nombreux outils traitent le formalisme SADT. exploités par un outil de conception et de simulation HPCN.6 Les outils de développement d’applications de base Comme outils de développement des architectures réparties. un plugin UML pour Eclipse . un éditeur de diagrammes UML . Visual Paradigm for UML. Il comporte un module SADT et un simulateur. Objecteering de Softeam .. NKENLIFACK Marcellin . de Visual Paradigm Internation Ltd. • • SOFTPEN Softpen est un atelier logiciel utilisant comme représentation interne un langage de liste (LIPS). un outil de modélisation UML .. Un générateur de code en langage SML à partir des réseaux HPCN est également disponible.) .7 L’accès aux données MTS : Microsoft Transaction Server : gestion de transactions ORACLE [Oracle] DB2 [IBM] Page 74 / 92 © Dr. (sur PC/MAC/SUN) Les schémas SART sont convertibles en réseaux de pétri colorés. en voici quelques exemples : • ASA • ASA est un outil supportant SADT et disponible sur SUN. 6.langages de 4ème génération (L4G) adapté aux approches de développement montantes : cas des « RAD » . Jude [1]. MacOS.12. orienté objet) . 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.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. de Sybase (outil de modélisation complet intégrant l'UML en plus des classiques MCD. distribué par IGL traitant IDEF0/IDEF1. HPCN et SML sortent un peu de notre domaine d'application.

. . en comptabilisant le nombre de "chemins" possibles au sein de ce code. quels serveurs matériels. les "intérêts" que vous payez sur cette dette deviennent énormes.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.12. pour quelles plates-formes matérielles est-il disponible ? Caractéristiques des Applications créées par l’outil Client / Interface graphique utilisateur Application Middleware / Système d’exploitation / Protocoles Middleware / Accès à distance aux bases de données Middleware / RPC / ORB Serveur / SGBD Avec quels systèmes d’exploitation ou environnements de fenêtrage clients fonctionnent les applications produites ? 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 ? Plusieurs utilisateurs peuvent-ils les utiliser tout de suite ? Si les applications produites sont réparties..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. Quels réseaux supporte-t-il ? Les liaisons sont-elles propriétaires ou utilisent-elle du middleware pour passer les données ? Si ces données sont utilisées pendant le développement. agir ainsi est plus facile sur le court terme.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. Comment y accède-t-on ? Les chaînages multiples en parallèle sont-ils permis ? L’outil peut-il être connecté à d’autres applications ? 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. et peut fournir des résultats avec une certaine précision. NKENLIFACK Marcellin Page 75 / 92 . systèmes d’exploitation et bases de données peuvent-elles utiliser ? 6. l'utilisation de boucles (while.BOEHM et Mc CALL. Tout comme les dettes financières. Ainsi. sur le client ou sur les deux ? Plusieurs développeurs peuvent-ils l’utiliser simultanément ? Si l’outil est réparti. Un logiciel doit présenter les six caractéristiques qualité définies par la norme ISO 9126 qui est issue des approches de B.Fiabilité : maintenir son niveau de service dans des conditions précises et pendant une longue période. © Dr. Métrique : Autre terme utilisé pour définir une mesure. for.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 utilisateur Outil Middleware / Système d’exploitation / Protocoles Middleware / Accès à distance aux bases de données Middleware / RPC / ORB Serveur / SGBD / Référentiel Sous quels systèmes d’exploitation ou système de multifenêtrage l’outils fonctionne-t-il ? Où réside l’outil – sur le serveur.) ou encore d'instructions de branchements conditionnels (if. (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. else) augmentent cette complexité. Il s’agit de (voir l’ouvrage [Schach 92]) : .Ingénierie des Systèmes Logiciels • • • • • • • • Informix [Informix] SQL Server [Microsoft] PostgreSQL MySQL 6. Mais au fil du temps. 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]). comment cela se passe-t-il ? Quel middleware est utilisé ? Quels système d’exploitation est utilisé ? Comment une application produite par l’outil accède-t-elle aux données sur les serveurs ? Des méthodes prioritaires d’accès aux bases de données sont-elles utilisées ? Outils tiers ? Langages standards ou protocoles ? Une application produite avec l’outil peut-elle appeler des programmes sur les serveurs ou d’autres 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.

un autre système d’exploitation ou une autre configuration logicielle ou matérielle. NKENLIFACK Marcellin Page 76 / 92 .Rendement : temps de réponse et le temps de traitement des fonctions acceptables. Nombre d’appels directs Vocabulaire NPD= 8 [moyenne] n=7 [moyenne par classe] NMI=4 [moyenne par classe] TD = 7500 [5 Homme/année] TF= 6000 [moyenne] NL = 25500 [total] Nombre maximum d’imbrications Temps de développement Cette métrique est un indicateur de complexité Cette métrique permet de caractériser la lisibilité d’un composant. . TD = NH/N en heure par homme Avec NH = nombre d’heures N = nombre d’hommes TF = taille des fichiers en octets NL = nombre de lignes de code des modules V=(N1+N2)log2(n1+n2) avec N1=nombre total d’occurrences d’opérateurs N2= nombre total d’occurrences d’opérandes n1= nombre d’opérateurs distincts n2=nombre d’opérandes distincts APPLICATION NUMERIQUE FREQ_COM=0. plus l’effort de compréhension est élevé. de complétude et de sécurité.Facilité d’utilisation : L’utilisation ne demande pas trop d’efforts.Maintenabilité : être rapidement et facilement corrigé. A titre d’exemple. on note une facilité de compréhension. agiles…) . modèles. . Une valeur importante de cette métrique se traduit par une mauvaise lisibilité du code qui affecte la maintenabilité.Portabilité : être installé sur une autre machine.67 DETAILS Permet d’évaluer la lisibilité du code. d’exploitation. Exemple de métriques prises (logiciel SAHY) © Dr. Longueur des instructions LONG_INST=4 Cette métrique constitue un indicateur de lisibilité du programme : les instructions longues sont plus difficiles à comprendre. C’est l’un des avantages du langage Java. Plus le nombre de « mots » employés (vocabulaire d’opérateurs ou opérandes) est élevé. Il peut supporter les modifications de ses spécifications.Ingénierie des Systèmes Logiciels . l’effort de test ou de maintenance. Volume de travail effectué Taille moyenne de fichiers Nombre de lignes Volume du programme Espace de stockage Permet de nommer les indicateurs tels que les charges de développement. V=10700 Tableau 2 . le tableau ci-dessous récapitule certaines métriques de qualité effectuées pour le cas du logiciel SAHY (voir [Nkenlif04]). MESURES Fréquence des Commentaires FORMULES FREQ_COM= NB_COM/NB_INST Avec NB_COM= nombre de commentaires NB_INST= nombre d’instructions exécutables LONG_INST= N/ NB_INST Avec N= nombre total d’occurrences d’opérandes et d’opérateurs NB_INST = nombre d’instructions exécutables Nombre de procédures différentes appelées par un composant n= n1+n2 avec n1= nombre d’opérateurs distincts n2= nombre d’opérandes distinctes [type d’opérateurs distincts] Nombre maximum d’imbrications des structures de contrôle utilisées dans le composant. C’est l’un des avantages des nouvelles approches (objets. tout au contraire. d’apprentissage.

nous n’avons évidemment pas la prétention d’être exhaustif. 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. NKENLIFACK Marcellin Page 77 / 92 . Après avoir appris comment aller chercher l’information demandée.3 Présentation de l’intervention L’objectif que nous nous sommes fixé ici. Illustration du principe d’une communication ergonimique En regardant la figure ci-dessus.1 Problématique de l’ergonomie : Pourquoi aborder ce sujet maintenant ? Après avoir appréhendé les aspects techniques d’un déploiement multicouches. nous allons maintenant voir comment la mettre à disposition de l’utilisateur. 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. 7. lors de vos prochaines expériences professionnelles. 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.1 7.1 Qu’est-ce que l’ergonomie ? Définition et complexité du concept [Morlais 01] Un grand nombre de définitions existent. dans toute communication. que l’on pourrait classer sous la rubrique « trucs et astuces » dans un magasine informatique.2. nous allons voir quelle forme et quelle organisation vous allez mettre en place. des machines et des dispositifs qui puissent être utilisés avec un maximum de confort. en voici quelques unes : "L'ergonomie est l'ensemble des connaissances relatives à l'homme et nécessaires pour concevoir des outils. si ce n’est plus important que le fond même de votre intervention. les vecteurs de communication que vous utiliserez seront aussi importants.1.Ingénierie des Systèmes Logiciels 7 Ergonomie d’Applications Graphiques (Web). Certaines personnes passent plus de 4 ans à étudier l’ergonomie. de sécurité et d'efficacité." © Dr.1. Vous aurez donc à faire l’étape 2 et 3 en prenant en compte les étapes 4 et 5.Concept 5. ce qui importe. 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 ». Dans certaines entreprises multinationales les taches sont séparées mais c’est loin d’être le cas de toutes les structures.Formulation du message 3.Mode de transmission du message 4-Réception du message 1. Petite notion de PNL (Programmation Neuro-Linguistique) 2.1. c’est la raison pour laquelle nous avons choisi de vous présenter des résultats sous forme de « règles ».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. mais qui résulte d’études sérieuses.2 7. Nous allons maintenant approfondir le passage de l’étape 3 à 4.Concept [Morlais 01] Figure 71. 7. Développement en équipe 7.

la mémoire. du domaine du développement de leurs capacités professionnelles au cours de leur vie active. 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. . 7. Cette étude se fait autant sous l'aspect humain de ces fonctions que sous ceux de la modélisation et de la simulation artificielle. psychique et sociale des travailleurs.2. l'épistémologie ou l'anthropologie (parmi les sciences humaines). mentale. de diminution des charges.2. ce qui explique la complexité de la matière. .Ingénierie des Systèmes Logiciels 7.2.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." 7. .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.1. d'amélioration des conditions de travail. 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. . Le rôle de l’ergonomie des interfaces utilisateurs est d’établir la communication entre l’outil et l’opérateur. 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. c’est ce qui nous concerne directement. de l’information. telles la philosophie.dans l’environnement de l’étape 3 : l’ergonomie peut permettre un environnement propice à la bonne transmission du message.les Neurosciences : la Neurobiologie (de la Neuroanatomie à la Neurochimie) pour l'étude des composantes biologiques .) pour la modélisation. en tenant compte de la validité biologique de tels modèles. la motricité ou l'apprentissage. dans le cadre d'objectifs de production. Classiquement. " Définition adoptée par le conseil de la SELF et affichée lors du congrès de Paris en 1988. " 7. © Dr. il s’agit du passage de l’étape 4 à l’étape 5. intelligence artificielle (apprentissage.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. le raisonnement.1.1. Toute conception d’interface doit donc placer l’utilisateur au centre de l’étude.les Sciences de l'Artificiel : mathématiques. Et il est capital de bien comprendre le mode de fonctionnement de l’utilisateur. psychologie et neurosciences) ou l'intelligence artificielle (informatique.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. la neuropsychologie (neurologie. de façon à corriger la situation de travail pour une meilleure adaptation de l'homme en activité ce qui inclut un souci : de santé. L’ergonomie conditionne ainsi l’acceptabilité du système par 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). logique et linguistique) marquait déjà cette nécessité bienheureuse d'une vision plus globale en franchissant les frontières classiques entres les disciplines. c'est-àdire la perception. à une cible déterminée. les représentations. la facilité et l’efficacité d’utilisation. le langage. un processus déterminé. mais aussi d'atteinte des objectifs économiques. Dans notre schéma de départ. 7. NKENLIFACK Marcellin Page 78 / 92 .2. La création des champs d'étude comme la psycholinguistique (psychologie et linguistique). " 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 .2. des machines et des dispositifs techniques qui puissent être utilisés par le plus grand nombre avec le maximum de confort. la facilité d’apprentissage (ces différents points ne sont pas toujours compatibles). à savoir : comment se passe la conceptualisation du message rèçu.D'autres sciences peuvent encore s'ajouter à cette liste. connexionnisme. Ses critères d'application sont du domaine de la protection de la santé physique. de sécurité et d'efficacité.et au sein de l’étape 3 : l’ergonomie peut intervenir dans la construction du message.les Sciences Humaines : Psychologie cognitive & Linguistique pour l'étude de l'humain et du langage .2 La place des technologies cognitives dans l’ergonomie Dans notre schéma.2. etc. les champs disciplinaires intéressés par les sciences cognitives sont : . ainsi que la physique (pour son apport aux Sciences de l'artificiel). l’ergonomie se situe au niveau de l’étape 3 : .

C’est à dire dans tous les milieux soumis à de forte contrainte de vitesse. l’informatique (harware et softeware). ne sont que des spécialisations auxquelles on ne peut postuler qu’après plusieurs années d’étude (en général 4).1. l’automobile et parfois –mais plus rarement– dans le domaine du mobilier. Comme le dis le conseil de la SELF. il est important de rendre lisible la structure de votre site. Comment : .Dans le cas d’un site commercial ou vous cherchez à vendre quelque chose. Pour approfondir la question.avec un plan du site si la structure n’est pas suffisamment lisible. © Dr. un préalable à la mise à disposition de l’information 7. Quand on veut rendre un site accessible sur le Web. importance du titre des pages et des mots clefs. Dans le deuxième cas.3. .1 La prise en compte de l’ergonomie dans le développement d’IHM et plus spécifiquement dans le développement d’applications Web L’« ergonomie de fond ». . des informations ou des produits qui étaient parfois disposés dans des entrepôts de plusieurs centaines de mètres carrés. il est important de savoir comment rendre accessible son site sur le Web. Il faut donc pouvoir retranscrire l’appréhension visuelle qu’avait l’utilisateur en arrivant dans son entrepôt ou sa pièce. l'ergonomie peut être comprise comme " l'adaptation du travail à l'homme ". NKENLIFACK Marcellin Page 79 / 92 .2 Les spécificités du Web Mode de fonctionnement des moteurs de recherche. Les termes que l’on choisit dans la définition de ses mots clefs sont déterminant. des études ont montré que vous avez le droit à 3 cliques et moins d’une minute pour « ferrer » le client ! 7. 7. il n’y a aucune démarche à faire pour se faire référencer. il faut inscrire le site sur une liste. On peut dire que les premiers ergonomes étaient Ford et Taylor.3 7.2. Pour cela.3 Les différents domaines d’application de l’ergonomie Ils sont tout ce qu’il y a de plus divers et varié. les centre de service d’urgence. Ce sont les premiers à avoir complètement redéfini les conditions de travail pour améliorer la productivité. présentation du « profiling ». de stress… On peut citer les aéroports.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. 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. on retrouve les ergonomes dans les domaines ou il a fallut optimiser les conditions de travail. 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). les hôpitaux. Par la suite.Se faire référencer : Sans rentrer dans les détails. et son site est ensuite visité manuellement ou toujours à l’aide de « robot » pour vérifier certains critères. 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.3. Dans le premier cas. de précision. il est bien sur capital d’être bien référencé si on veux être visité. ou si le site est trop grand pour que l’utilisateur ne puisse sans effort avoir une vue d’ensemble. vous pourrez consulter plus tard les sites d’ergonomes que nous avons mis sur le réseau. pariant sur les possibilités d'interfécondation des visions et sur le développement des études transcendant les diverses disciplines 7.2 Quelles inter-connexions avec l’ergonomie ? Les sciences cognitives sont un préalable à la pratique d’une ergonomie efficace.2. .1.avec une signalétique cohérente tout au long de l’application Remarques : . Il existe des moteurs de recherche (type « google » ou « alta vista ») et des annuaires (type « Yahoo »).3. En décomposant le processus de production ils ont rendu la fabrication des voitures accéssible à tout le monde.Ingénierie des Systèmes Logiciels 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.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.2.

alimentation. packs d'eau. recette. vente en ligne. livraison a domicile. 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. commerce en ligne.3. boutique on line. livraison a domicile. commerce en ligne.1 L’ergonomie des applications Web La densité de l’affichage Pour chaque application. magasin virtuel. Casino. commander. Présenter les groupes de données les plus importants selon le critère privilégié (par exemple. commerce electronique.2 © Dr. 6000 produits. fréquence d’utilisation) vers le haut de la fenêtre. . la justification peut se faire de trois manières : .2. . achat en ligne. grande distribution. Remarque : si le travail de l’utilisateur s’appuie sur un formulaire papier. faire en sorte que la disposition des champs dans la fenêtre soit proche de la structure du formulaire.</TITLE> Notons que la balise destinée aux robots précise la langue utilisée. 7.2.3. commande par internet. achat electronique. 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 ». . . acheter. tenir compte des habitudes de travail de l’utilisateur : . optionnelles). c-mescourses. NKENLIFACK Marcellin Page 80 / 92 . courses sur internet. justifier ces libellés à droite et les champs à gauche ." Name=Description> <META content="livraison a domicile.2 7.Ingénierie des Systèmes Logiciels Exemple d’en-tête : Pour se faire référencer auprès des moteurs de recherche qui utilisent des petits robots fournisseurs. (préciser si besoin). lait. Notons que les accents ne sont pas utilisés dans les mots clés.com : Finies les commissions.1 : si les « libellés » sont de dimension sensiblement identique. . couches. il faut trouver un compromis entre la densité d’informations affichées dans chaque fenêtre et le nombre de fenêtres : . 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. commander.3.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.fréquence d’utilisation. recettes de cuisine. conserves.importance dans le contexte (saisies obligatoires. de l'alimentation aux soins et beauté en passant par les produits d'entretien maison.3 : il est également possible de disposer les libellés au dessus des « champs de saisie » . il faut alors les justifier à gauche. faire mes courses de chez moi. se faire livrer € domicile les produits alimentaires de consommation.séquence d’utilisation dans la tâche en cours.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 .BH35WXL" lang=fr name=Keywords> Ce texte est repris en totalité ou en partie par le moteur de recherche. boutique on line. (voir pour les autres sites) 7. achat de vin. achat en ligne. acheter. livraison. et si ce formulaire est bien construit. 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). supermarche.2 : si les libellés sont de dimensions très variables. Aligner verticalement les champs de saisie et/ou d’affichage avec leurs libellés . vente a distance. 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. justifier les champs et les libellés à gauche . services casino.

7. 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.3 La présentation des listes et des tableaux Attribuer systématiquement un titre aux listes et aux tableaux . Cas 2 (libellés de dimension différente) Nom : Prénom : Adresse personnelle (domicile) : Nombre d’enfants à charge : Profession : Profession du conjoint : [Morlais 01] Figure 74. et en incrustation dans le cadre s’il y en a un. Page 81 / 92 © Dr. NKENLIFACK Marcellin . Cas 1 (libellés de dimension sensiblement identique) Nom : Prénom : Profession : Profession du conjoint : Nombre d’enfants à charge : Adresse personnelle (domicile) : Figure 73. Utiliser alors des en-têtes de groupe sans représenter une boîte de groupe. Utilisation des boîtes de groupe (Word) Placer l’en-tête de groupe au dessus de la boîte de groupe. Ne pas utiliser de boîte de groupe pour les boutons de commande. 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).3. [Morlais 01] Figure 75.Ingénierie des Systèmes Logiciels Nom : Prénom : Age : Profession : Ancienneté : Figure 72. ces titres permettront à l’utilisateur de se repérer facilement et rapidement.2.

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) ? . disposition) . on peut être confronté à des éléments de texte trop longs pour contenir dans l’espace d’une ligne de la liste. fournir chaque fois que c’est possible des abréviations bien choisies : . Attention toutefois : dans certains cas. Eviter les alignements centrés (effets de vagues verticales).Par souci d’homogénéité. c’est-à-dire facilement compréhensibles par l’opérateur . Utiliser des termes explicites et non ambigus. Les colonnes doivent être séparées par un double espace (1 caractère blanc x 2). sinon..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 .numériques à droite. Ne mettre donc en majuscule que la première lettre du premier mot du libellé et aucun autre mot de ce libellé.. italique. Eviter d’utiliser des abréviations.Respecter les alignements standards des traitements de texte : . supprimer des parties de texte dans le milieu du libellé et y insérer des points de suspension.2. On distingue trois grands types de libellés : . Repérer chaque champ.l’en-tête de colonne. des caractères de plus petite taille sont quasiment illisibles . Indiquer les unités de mesure utilisées (en abrégé si elles sont connues de l’utilisateur).) utiliser une majuscule à l’initiale. .adopter l’ordre respectant les habitudes de travail de l’utilisateur . 7. 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 . 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.3. . préférer les formes affirmatives. De manière générale. il sera plus judicieux de conserver le début du libellé et de faire suivre ce dernier par des points de suspension. à utiliser pour identifier une donnée affichée ou à saisir . . des libellés de champs de saisie obligatoire. l’utilisation de caractères de plus grande taille gêne la lisibilité. 7. colonne ou groupe de données par un libellé. NKENLIFACK Marcellin Page 82 / 92 . utiliser une seule police de caractères dans un champ.3. gras. ne pas utiliser de synonymes : désigner toujours un même objet ou une même action par le même libellé.6 La couleur La couleur peut être employée pour coder visuellement l’information : différenciation et identification des informations affichées.2. . Faire des phrases (ou expressions) simples. boutons d’option. . Choisir la police de caractères en fonction de critères de lisibilité (éviter l’italique). titre.3. utiliser l’ordre alphabétique ou numérique.préférer la contraction (omission des lettres internes) pour les mots courts . séparer les colonnes par des traits (lignes verticales). Dans ce cas. conservant ainsi le début et la fin du libellé de l’élément.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 .) pour différencier certains textes tels que des mots clès.5 La typographie Concernant la taille des caractères : taille minimum : 8 points . liste.Ingénierie des Systèmes Logiciels 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). couleur. Pour tous les libellés (champs de saisie et champs d’affichage. etc. 7.le cas échéant. des liens. . Si cela ne peut pas être fait (par manque de place). Toutefois. tableau.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. taille maximum : 16 points . alors : . option de menu. à utiliser pour identifier un ensemble de données rassemblées sous la forme d’un groupe. il doit y avoir d’autres indicateurs (libellés. . Lors de la création de listes d’éléments.l’en-tête de groupe. à utiliser pour identifier la colonne d’un tableau ou d’une liste . forme.préférer la troncature pour les mots longs (omission des lettres finales).4 Les éléments textuels Utiliser le vocabulaire appartenant au domaine d’activité des utilisateurs. © Dr.libellés en général à gauche. . il est possible d’utiliser des codages particuliers (police différente.le libellé de champ. etc. . souligné.2.

7 Les icones Les icones peuvent avoir deux fonctions : . Au delà de 5 ou 6. Pour le fond des fenêtres. éviter les teintes de rouge. 7. 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.le jaune avec le vert. si le nombre de niveaux de gris disponible est insuffisant. Homogénéité : quand une icone est utilisée pour représenter quelque chose. ces boutons doivent être placés sur chacun des onglets : le bouton <Annuler> devient <Fermer> et la demande de confirmation devient facultative (<OK> facultatif).jaune ou orange : attention. Exemple : l’icone loupe (ou jumelles) est associé au bouton de commande <Rechercher>. 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 . Attention. é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. vigilance. Centrer les libellés des onglets et les afficher sur une seule ligne. prévoir des hachures). si ces derniers sont liés (dépendants).2. la conserver pour l’ensemble de l’application. Eviter d’utiliser plus d’une rangée d’onglets. toujours choisir les mêmes “ codages couleur ”. sinon du bleu foncé.rouge : alerte. © Dr.représenter une action par une icone associée à un bouton de commande. autrement dit elles doivent être explicites. car la manipulation de 2 ou 3 rangées d’onglets est complexe. 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). Aligner les languettes des onglets à gauche et les accoler les unes aux autres. Utilisation de plusieurs rangées d’onglets ( à ne pas faire !) Quand le principe des onglets est utilisé. Il paraît néanmoins « prudent » de doubler les icones d’un libellé. L’utilisation des onglets Utiliser les onglets pour éviter les successions de boîtes de dialogue ou un trop grand nombre de boutons. interruption.le rouge avec le bleu.3.le jaune avec le violet.aider à identifier la nature d’une information. . Pour de l’information que l’utilisateur doit lire. . sous forme d’icone. . Ainsi. Si les onglets sont indépendants.Ingénierie des Systèmes Logiciels 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. …). essayer de ne jamais utiliser ensemble : . 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. Figure 76. Autrement dit. Privilégier plutôt le gris pâle. . danger. NKENLIFACK Marcellin Page 83 / 92 . de jaune et de ses dérivés (vert. les icones utilisées doivent être représentatives de l’action ou du concept que l’on souhaite représenter. orange. C’est pourquoi certaines associations de couleurs doivent être évitées. . les boutons <OK> et <Annuler> doivent être placés en dehors de l’onglet.vert : signifie que tout se passe correctement. Respecter les règles d’association conventionnelles entre la couleur et sa signification : .

3 Synthèse et Description d’un supermarché « on line » standard 7.2.4.4.4. (EN grande Distribution.Les publicités du site .Recherche et selection du produit .Interfaçage avec des bases de données . © Dr. NKENLIFACK Marcellin Page 84 / 92 .1 Présentation du site c-mescourses. on pourrait ici parler de rendement au pixel !) 7.Selection du produit .1 L’environnement d’achat .1 L’environnement d’achat .1.Les publicités 7.Nombre d’information à transmètre très important.1.com 7.2 L’acte d’achat . et travail ergonomique important.3.Ingénierie des Systèmes Logiciels 7.2 Présentation du site Houra.1 L’environnement d’achat .La livraison 7.Le payement .com 7.Payement et livraison .Recherche du produit .Le portail .4.3.L’inscription .La communication sur le site 7.4.La recherche du produit .4.2 L’acte d’achat .le portail . donc optimisation maximum de l’écran.L’inscription 7.Le payement 7.2 L’acte d’achat .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 : .conclusion TD : Etudier les 3 situations présentées ci-dessus.4. on parle de rendement au m².2.Le portail et l’« ergonomie de fond » .La sélection du produit .Le plan du site .4.4.

un architecte/designer. la bonne ergonomie de ses applications Web ne tient pas à grand chose.. documents de conception. on peut effectuer des ajustements (personnage. • 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. programmes . Quand on élabore un Intranet ou une application spécifique. la prise en compte de ces recommandations ne se substitue pas à la connaissance des utilisateurs ni à la connaissance de leur travail . l’analyse du fonctionnement et du comportement des utilisateurs peut amener à ne pas prendre en compte certaine recommandation.L'intégration pour associer les différents composants du projet.. Ces recommandations sont particulièrement applicables pour les sites Internet qui ne ciblent pas de public particulier. sera choisi parmi les plus expérimentés. même si intéressant.6. au moins un graphiste 2D/3D. soit en faisant la même chose que l’autre. 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 . 2. il est indispensable de toujours travailler en équipe.Ingénierie des Systèmes Logiciels 7. • 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. Notez tout de même que. 3. animation. © Dr.2 Mesures pour gagner en efficacité Voici quelques mesures valables pour différents éléments de votre projet. • 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. Toutes les compétences ne seront jamais cumulées par la même personne. 4. ceci pour assurer un développement continu évitant de mauvaises surprises. Il est donc important de faciliter le « flux de travail ». etc.. elle ne remplace pas une analyse du travail. une destination et un débit. sans exception.6.Les tests pour vérifier que le comportement des composants assemblés est bien celui attendu.5 Conclusion sur l’ergonomie Comme nous avons put le constater ensemble. Note : Les techniques présentées pourraient tout aussi s’appliquer à un projet de SIG. les étapes ci-dessus ne s’enchainent pas forcément toujours de la même façon.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. interface…).. 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). décor. en sonsidérant le travail réalisé comme un liquide ayant une source. Pour obtenir une certaine qualité.1 Le développement en équipe La production d’une application 3D fait intervenir au oins 4 étapes principales : [Lemasson] 1. On pourra dans un projet 3D retrouver par exemple. il suffit de faire attention à un certain nombre de critères. Etant donné qu’un développement est un processus de production numérique. 7. Normalement. un programmeur. NB : Ces mesures doivent être accompagnées d'autres mesures élémentaires comme les conventions de nommage. le chef de projet qui aura comme tâche d'organiser le développement et d'affecter les tâches. Car à tout moment. voir à faire le contraire ! 7. on doit connaître sa version actuelle et qui l'a modifié en dernier. texture. ou l'affectation des tâches et des délais. tels que : modélisation.La conception pour fixer les objectifs et les méthodes employées lors du projet. soit en recommençant ce que l’autre a déjà fait. Tout grand problème devra être divisé en sous problèmes plus simples. • Gestion des versions des fichiers Pour chaque élément du projet. y compris la documentation. NKENLIFACK Marcellin Page 85 / 92 .L'implémentation pour réaliser les composants du projet. 7. elle est simplement complémentaire à un travail d’analyse de la cible.

design et ainsi de suite . Veuillez à ce que tous les répertoires aient un nom significatif.Prototypes prototypes de vos composants. qui facilitera la gestion de plusieurs versions d'un même fichier. dont plusieurs sécurisés. modifier le fichier de son choix et le livrer une fois le travail terminé. On pourra même parfois effectuer la fusion de modifications entre plusieurs version d'un même fichier.2 Systèmes de gestion de versions 7.2. les textures. 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. Les données seront accessibles via un serveur (site internet. chaque membre de l'équipe pourra récupérer la dernière version des fichiers du projet. on peut bloquer les modifications sur un fichier pendant que l'on travaille dessus. Réalisé sous la forme d'un site de news.2 Application concrète : une infrastructure Voici un exemple d’infrastructure technique à mettre en place pour votre projet 3D : .Graphisme2D fichiers conception de vos graphisme. et non sur votre serveur qui est supposé héberger la version développée acquise. documentation d'un composant ou tout autre élément du projet. en interne et en externe.1 L'efficacité du développement point par point 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. Les données ainsi copiées doivent toujours être à 2 endroits différents. Il ne nous encombre pas avec des versions physiques nombreuses du même fichier. Ainsi de façon globale. et compatible avec n'importe quel type de fichier (pas seulement avec de la 3D). c'est à dire les fichiers photoshop ou autre. Voici un exemple d’organisation d’'arborescence : MonProjet . contenant au plus 10 sous répeetoires.7.. une petite amélioration peut consister à héberger sur votre serveur le site internet de l'équipe.7.. Comme modèle d’organisation. Bien sûr. scénario. le chef de projet n'a pas fait correctement son travail d'affectation des tâches.7.1 Notion de gestion de versions Pour éviter de se tromper sur le bon fichier ou d’écraser un fichier plus récent.Ingénierie des Systèmes Logiciels 7. il est donc recommandé d’utiliser un outil logiciel de gestion de versions. Un exemple d’outil de gestion de version est « SVN » (grtuit.2.DocumentsDeConception documents de conception : Références. .. ftp. 7. même si on dispose d'un unique fichier. Il faut signaler ici que s’il arrive que si deux membres de l'équipe travaillent sur le même fichier. Virtools.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. . Ils aident en plus à simplifier et mieux organiser l’arborescence du projet. il est recommandé que le projet soit hébergé dans un répertoire simple.7. Cette technique émane des systèmes UNIX et de CVS. photoshop. sous forme de fichiers VMO pour notre exemple.Compilation dernière version compilée du projet. successeur de CVS).7 7. 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 !). Il vaut mieux toujours travailler e local. très performant. De cette manière. Vous pouvez vous limiter aux 5 dernières versions de votre arborescence en fonction de la place disponible. 7. Les sauvegardes peuvent être gérées automatiquement à l’aide de logiciels tels que « Acronis » (payant) ou « Cobian Backup » (gratuit). on peut faire appel au système de gestion de versions . bibliothèque de matériaux. vous pouvez empêcher un autre membre de l'équipe d'y accéder et de créer une version concurrente à la votre. il vous permettra d'assurer la communication du projet.Modélisations fichiers de conception de vos modèles 3D de votre projet. et bien d’autres situations.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) . on peut à tout moment récupérer l'historique des modifications effectuées ainsi que n'importe quelle version antérieure. eux même ne contenant que 10 sous-répertoires et ainsi de suite.. Pour obtenir des résultats de qualité et une meilleure orgnisation de votre projet.Ressources Virtools du projet composants du projet 3D. Par ailleurs. N’oubliez pas que lorsque l'équipe devient importante (>3). .. Le système SVN peut fonctionner à distance. NKENLIFACK Marcellin Page 86 / 92 . © Dr. c'est à dire les fichiers 3DSMax . les modèles 3D les comportement de caméra .

Le fichier est de plus en plus difficile à manipuler . il a été démontré que à plus de 10 modifications. Voici quelques critères pouvant vous amener à diviser un fichier : .7.3 Diviser pour mieux régner Il est important de scinder en fichiers de plus petite taille.4 Optimisation des modifications au quotidien En général les modifications sur le projet une fois effectuées. Car. Tous cela contribue à la qualité. une fois mise en place. cela signifie que vous refuser d'améliorer votre propre projet. © Dr. elle devient incontournable. engendrent des difficultés plus importantes en ce qui concerne la repercution. D’ailleurs. tout fichier contenant une grande quantité de données. L'intégration automatique permettra de substituer facilement et instantanément deux versions d'un composant. Ceci revient au découpage en modules de plus en plus petits et faciles à contrôler pour des programmeurs. voir obligatoire pour ceux qui effectuent beaucoup de modifications. Elle optimise le temps consacré au projet. Le fractionnement d’un fichier de données favorise également le travail collaboratif (plusieurs personnes travaillant en même temps sur ces données). et rapproche beaucoup plus vite de la phase de test. L’intégration automatique est donc nécéssaire...Ingénierie des Systèmes Logiciels 7. parfois il faut parcourir plusieurs dizaines de menus pour spécifier le nouveau fichier à charger à la place de l'ancien. 7. NKENLIFACK Marcellin Page 87 / 92 . Ce qui permet de détecter rapidement les défauts et les corriger aussi plus rapidement. l'intégration manuelle prend toujours plus de temps que l'intégration automatique. En effet. l’intégration ou la diffusion. Il n’est pas bon de refuser d’apporter des modifications au projet. Ceci nous simplifie la manipulation du contenu de chaque sous fichier. Une solution face à cela.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). c’est « l'intégration automatique ».7. et même sa maintenance.

com/articles/sonar/ Gilles MANTEL. Software Factories Assembling Applications with Patterns. 2003). Date de publication : 04/12/2006 http://pparrend. Microsoft Professional. Addison Wesley. IUT FV de Bandjoun. 3 edition (September 19.cui. Boston. Meyer. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process.ca/cours/gpa77 http://cui. Ergonomie des applications Web.html#uml Jack Greenfield et Keith Short. Introduction au développement en équipe pour la 3D Date de publication : 10/04/07. 2002. Schach. ENSMA Guillaume Lemasson. Practical Software Engineering. Département d’Informatique. http://jp-grossglauser. Craig Larman. http://lemasson.1 Dernière mise à jour : 15/08/2007. On the Need for Megamodels Preliminary Draft.ch/ScDep/Cours/GenieLogiciel/ http://www. Agile and Iterative Development: A Manager's Guide. Models. Agile Project Management with Scrum. Contrôler la qualité de ses projets avec Sonar.developpez. octobre 07.polymtl. octobre 07. Test-Driven Requirements. Introduction à MDA : Principe. Thèse de Doctorat/PhD. 2003.html http://www.unige. pour du logiciel de qualité » Inter éditions 1990. Jean-Pierre Grossglauser. Reproduit avec la permission de Francis Cottet.omg. Modélisation Objet et Développement d’un Atelier de Simulation des Automatismes Industriels Hybrides.etsmtl. http://sarbogast. UML Distilled: A Brief Guide to the Standard Object Modeling Language.unige. Cameroun. mise à jour : 13/08/2009. Wiley. Valtech Training Stephen R.developpez. Valtech Technology B. Publisher: Addison-Wesley Professional. 1992 Ken Schwaber.gpa.com/ Jean Bézivin.developpez. Christian de la Morlais.com/books.Ingénierie des Systèmes Logiciels BIBLIOGRAPHIE [Arbogast06] [Bezivin04] [Craig03] [Fowler03] Sébastien Arbogast. Frameworks and Tools. OOPSLA. 2004 www. IRWIN. « Conception et programmation par objet.ca/inf2300 © Dr. Date de publication : 18 mai 2006.org (site Web de l’OMG contenant les spécifications sur le métamodèle UML et le processus MDE) Pierre Parrend. 2003 Martin FOWLER. ISBN: 0321193687 http://martinfowler. UML est-il soluble dans les méthodes agiles ?. Séminaire : DataWeb et NTIC. Language: English.com/ Romain Linsolas. [Greenfield03] [Grossglauser07] [KaiserCottet01] [Lemasson] [Linsolas09] [MANTEL07] [Meyer 90] [Morlais 01] [Nkenlif04] [OMGWWW] [Parrend07] [ROQUES07] [Schach 92] [Schwaber04] [Scott02] Autres sources • • • • www.com/tutoriel/mda-intro/ Pascal ROQUES. NKENLIFACK Marcellin Page 88 / 92 . Introduction aux tests unitaires avec PHPUnit 3. Frédéric Jouault et Patrick Valduriez. Univ Yaoundé1. 2001 Marcellin Nkenlifack. MDA par la pratique.developpez.cours. ENSP. OOPSLA 2004. LES RÉSEAUX DE PETRI. 2004.ch/ScDep/Cours/GenieLogiciel/index. http://linsolas. Paperback: 192 pages.com/tutoriels/langages/php/phpunit/ Claude Kaiser.developpez. Scott Ambler .

et on s’assure qu’il ne se reproduira plus. 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. Système de production de Toyota Ces valeurs sont supportées par les deux piliers suivants : . des matières premières. on retrouve un ensemble de méthodes tournées vers l’organisation de sa production selon un mode « pull ». c’est-à-dire tendre vers la perfection en impliquant tous les acteurs depuis le top-management jusqu’à l’opérateur. le lecteur pourra consulter l’ouvrage référence en la matière : The Machine That Changed the World : The Story of Lean Production. on trouve les concepts suivants : . rangé. et Roos. c’est-à-dire garder un espace de travail propre. Parmi les fondations. de la formation du personnel. on arrête immédiatement la chaîne. dont le système de production est souvent représenté sous la forme d’une maison.Jidoka : notion d’empêcher un maillon de la chaîne de passer une pièce défectueuse au maillon suivant. Le plus fameux d’entre eux est le constructeur automobile Toyota. etc. Cette organisation permet également de diminuer ses stocks au maximum. 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. Jones.Just-in-time : notion de produire la bonne pièce à la bonne quantité et au bon moment. Pour plus de détails.Kaizen : amélioration continue des processus. Si un défaut est identifié sur un élément dans la chaine de production.5S : la gestion de l’espace de travail. NKENLIFACK Marcellin Page 89 / 92 . © Dr. . le toit représentant les valeurs vers lesquelles tend Toyota.Ingénierie des Systèmes Logiciels 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. on répare le défaut. de Womack. on redémarre ensuite la chaîne de production. voire de les réduire à zéro. . efficace. Sous cette appellation. Les défauts peuvent provenir des machines.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->