ingénierie des systèmes logiciels - dphu · 2014-10-12 · avec au centre le processeur (entité...

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

[email protected]

Version Dec. 2009

SSoommmmaaii rr ee

SOMMAIRE................................................................................................................................................................................................................. II 1 RAPPELS DES CONCEPTS DU GENIE LOGICIEL..................................................................................................................................... 1

1.1 UN PEU D’HISTORIQUE................................................................................................................................................................................. 1 1.2 CRISES : ....................................................................................................................................................................................................... 1 1.3 LE GENIE LOGICIEL...................................................................................................................................................................................... 2 1.4 LE PROCESSUS LOGICIEL, OU CYCLE DE VIE DU LOGICIEL............................................................................................................................. 2 1.5 REPRESENTATIONS DES MODELES DE DEVELOPPEMENT............................................................................................................................... 3

1.5.1 Modèle Exploratoire .......................................................................................................................................................................... 3 1.5.2 Modèle Cascade................................................................................................................................................................................. 3 1.5.3 Modèle en V....................................................................................................................................................................................... 4 1.5.4 Modèle en spirale............................................................................................................................................................................... 4 1.5.5 Modèle Incrémental ........................................................................................................................................................................... 5

1.6 METHODES................................................................................................................................................................................................... 5 1.7 LA SPECIFICATION....................................................................................................................................................................................... 6

1.7.1 Les 7 péchés :..................................................................................................................................................................................... 6 1.7.2 Les 7 caractéristiques d’une bonne spécification : ............................................................................................................................ 6 1.7.3 Les méthodes...................................................................................................................................................................................... 6 1.7.4 Les démarches d’analyse ................................................................................................................................................................... 7

1.8 TECHNIQUES DE TESTS................................................................................................................................................................................. 7 1.9 PROCESSUS DE TEST DE CODES.................................................................................................................................................................... 8

1.9.1 Problématique : ................................................................................................................................................................................. 8 1.9.2 Processus de test :.............................................................................................................................................................................. 9

2 METHODES SADT ET RESEAUX DE PETRI............................................................................................................................................. 11 2.1 INTRODUCTION .......................................................................................................................................................................................... 11 2.2 SPECIFICATIONS A L’AIDE DES RESEAUX DE PETRI .................................................................................................................................... 11

2.2.1 Description ...................................................................................................................................................................................... 11 2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri ......................................................................................................... 12 2.2.3 Graphes de marquage...................................................................................................................................................................... 13 2.2.4 Limites des RdP et extensions des possibilités ................................................................................................................................. 13 2.2.5 Extensions et autres Outils proches ................................................................................................................................................. 13

2.3 SPECIFICATION A L’AIDE SE SADT & IDEF ............................................................................................................................................... 14 2.3.1 Présentation..................................................................................................................................................................................... 14 2.3.2 Modèles SADT ................................................................................................................................................................................. 14 2.3.3 SADT/IDEF0.................................................................................................................................................................................... 14 2.3.4 LES EXTENSIONS IDEF1/IDEF2................................................................................................................................................... 17 2.3.5 Avantages et Inconvenients SADT.................................................................................................................................................... 18

2.4 CONCLUSION.............................................................................................................................................................................................. 18 3 APPROCHE ORIENTEE OBJET ET UML................................................................................................................................................... 19

3.1 INTRODUCTION .......................................................................................................................................................................................... 19 3.2 LES CONCEPTS DE BASE: ............................................................................................................................................................................ 19

Abstraction ( ≡ définition d’une classe).............................................................................................................................................................. 19 Encapsulation...................................................................................................................................................................................................... 20 Modularité........................................................................................................................................................................................................... 20 Hiérarchie (héritage)........................................................................................................................................................................................... 20 Le typage ............................................................................................................................................................................................................. 20 Simultanéité......................................................................................................................................................................................................... 20 Persistance .......................................................................................................................................................................................................... 20

3.3 CYCLE DE VIE :........................................................................................................................................................................................... 20 3.4 LES « MODELES »....................................................................................................................................................................................... 21 3.5 LE LANGAGE UML................................................................................................................................................................................. 21

3.5.1 La genèse d'UML............................................................................................................................................................................. 21 3.5.2 Généalogie UML.............................................................................................................................................................................. 21 3.5.3 Notions usuelles ............................................................................................................................................................................... 22 3.5.4 Le formalisme d'UML ...................................................................................................................................................................... 22 3.5.5 La modélisation par UML................................................................................................................................................................ 24

3.6 CONCLUSION.............................................................................................................................................................................................. 40 4 MDE : MODEL DRIVEN ENGINEERING ..................... .............................................................................................................................. 41

4.1 ÉVOLUTIONS .............................................................................................................................................................................................. 41 4.2 CONCEPTS DE BASE.................................................................................................................................................................................... 41 4.3 MDE ET LE GENIE LOGICIEL....................................................................................................................................................................... 41 4.4 MDE ET UML............................................................................................................................................................................................ 42 4.5 ELEMENTS DE MDA................................................................................................................................................................................... 43

4.5.1 Les éléments de MDA....................................................................................................................................................................... 44 4.6 TECHNOLOGIE MDE .................................................................................................................................................................................. 45

4.6.1 Principe de MDE ............................................................................................................................................................................. 45 4.6.2 Description des deux catégories de transformations : ..................................................................................................................... 46

4.7 MDE ET LES « DESIGN PATTERNS »........................................................................................................................................................... 46 4.8 PROCESSUS MDE....................................................................................................................................................................................... 47

4.8.1 Langages de modèles ....................................................................................................................................................................... 47 4.8.2 Étapes de développement MDA........................................................................................................................................................ 48

4.9 METHODOLOGIE GLOBALE DE REALISATION D’APPLICATIONS................................................................................................................... 49 4.9.1 Approche linéaire ............................................................................................................................................................................ 50 4.9.2 Approche incrémentale .................................................................................................................................................................... 51

4.10 PERSPECTIVES DE DEVELOPPEMENT........................................................................................................................................................... 51 4.10.1 Les Mégamodèles............................................................................................................................................................................. 51 4.10.2 La Modularisation des Applications ................................................................................................................................................ 51

4.11 CONCLUSION.............................................................................................................................................................................................. 52 5 LES METHODES AGILES.............................................................................................................................................................................. 53

5.1 HISTORFIQUE DES METHODES AGILES : ...................................................................................................................................................... 53 5.2 LES PRINCIPES AGILES................................................................................................................................................................................ 53 5.3 « MODELISATION AGILE » DES PROJETS..................................................................................................................................................... 55 5.4 TEST-DRIVEN REQUIREMENTS (TDR)........................................................................................................................................................ 58

5.4.1 Lean sofware development............................................................................................................................................................... 58 5.4.2 Les étapes d’une évolution « lean » ................................................................................................................................................. 58 5.4.3 TDD (Test Driven Development) et TDR (Test Driven Requirement) .............................................................................................. 59

5.5 CONCLUSION :............................................................................................................................................................................................ 61 6 PROCESSUS DE DEVELOPPEMENT, OUTILS ET METRIQUES DE QUALITE................................................................................. 62

6.1 ARCHITECTURE DES APPLICATIONS............................................................................................................................................................ 62 6.2 PLACE DES OUTILS..................................................................................................................................................................................... 63 6.3 QUELQUES FACTEURS POUVANT INFLUENCER LE CHOIX DE LANGAGES ET OUTILS : .................................................................................. 63 6.4 ENVIRONNEMENTS INTEGRES DE PROGRAMMATION.................................................................................................................................. 64 6.5 LES ATELIERS DE GENIE LOGICIEL ............................................................................................................................................................ 64

6.5.1 Qu'est ce qu'un atelier de génie logiciel ?........................................................................................................................................ 64 6.5.2 Les outils « CASE » (Computer Aided Software Engineering)......................................................................................................... 64 6.5.3 L'intégration d'outils CASE.............................................................................................................................................................. 65 6.5.4 Les différents types d'AGL ............................................................................................................................................................... 65 6.5.5 Standardisation des ateliers............................................................................................................................................................. 66 6.5.6 Ateliers et Cycle de vie..................................................................................................................................................................... 66

6.6 INTERET DE LA QUALITE D'UN LOGICIEL, ET DE SON CONTROLE A L’AIDE DES OUTILS APPROPRIES........................................................... 66 6.7 LES « PROCESSWARES » : ........................................................................................................................................................................... 67 6.8 CHOIX DE L’OUTIL DE DEVELOPPEMENT : .................................................................................................................................................. 67 6.9 OUTILS DE DEVELOPPEMENT « MDA » ..................................................................................................................................................... 68

6.9.1 AndroMDA pour Java (un générateur d’application)...................................................................................................................... 68 6.9.2 Delphi Architecte ............................................................................................................................................................................. 70

6.10 OUTILS DE CONTROLE DE QUALITE ET DE TEST DE CODES......................................................................................................................... 70 6.10.1 Contrôler la qualité de ses projets avec l’outil « Sonar » ................................................................................................................ 70 6.10.2 Tests unitaires avec « PHPUnit » (un OpenSource) ........................................................................................................................ 71 6.10.3 Utilitaires : ...................................................................................................................................................................................... 71

6.11 OUTILS DE TEST TDR AVEC LES METHODES AGILES................................................................................................................................... 71 6.12 AUTRES OUTILS.......................................................................................................................................................................................... 72

6.12.1 Le serveur d’application universel EAS : Enterprise Application Server [Sybase]..........................................................................72 6.12.2 L’environnement de référence DOC (HP)........................................................................................................................................ 72 6.12.3 L’offre logicielle de Microsoft : ....................................................................................................................................................... 73 6.12.4 Quelques Logiciels de modélisation UML........................................................................................................................................ 73 6.12.5 LES OUTILS SADT.......................................................................................................................................................................... 74 6.12.6 Les outils de développement d’applications de base ........................................................................................................................ 74 6.12.7 L’accès aux données ........................................................................................................................................................................ 74 6.12.8 L’aspect gestion du projet................................................................................................................................................................ 75

6.13 LES QUESTIONS QUE L’ON DOIT SE POSER LORSQU’ON EST FACE A UN SYSTEME OU UN PROJET (PAR EXEMPLE DE TYPE CLIENT-SERVEUR) 75 6.14 ELEMENTS DE QUALITE LORS D’UN DEVELOPPEMENT................................................................................................................................ 75

7 ERGONOMIE D’APPLICATIONS GRAPHIQUES (WEB), DEVELOPP EMENT 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


© Dr. NKENLIFACK Marcellin Page 1 / 92

� �

11 RRaappppeellss ddeess CCoonncceeppttss dduu GGéénniiee LL ooggiicciieell « Le logiciel est l'ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitements de l'information' » (arrêté du 22 déc. 1981) Un logiciel pourra donc être considéré comme un ensemble de programmes informatiques (codes sources, éditables, exécutables) mais également les données qu’ils utilisent et les différents documents se rapportant à ces programmes et nécessaires à leur installation, utilisation, développement et maintenance : spécifications, schémas conceptuels, jeux de tests, mode d'emploi, etc. 1.1 Un peu d’historique

• En 1936, Alan Turing (un brillant étudiant en mathématiques à Cambridge en Angleterre, âgé de 24 ans qui cherchera à construire un cerveau artificiel), propose dans un article, tout d'abord de formaliser la notion d'algorithme grâce à la définition d'un dispositif abstrait que depuis on appelle « machine de Turing ». Ce sera le modèle de base qui fonde l'informatique moderne. Une machine de Turing sera vue comme une méthode de calcul, un programme.

Programmer (écrire un programme) consiste à écrire une suite d'instructions pour réaliser un traitement sur des données.

• Les langages de programmation (« intermédiaire » entre le « programmeur » et la « machine ») vont évoluer dans le temps, au fur et a mesure des besoins en terme de qualité, et pour pouvoir faire face aux problèmes de plus en plus complexes.

- Langages de 1ère génération (1954 – 1958 : Fortran I, Algol 58…) - Langages de 2ème génération (1959 – 1961 : Fortran II, Algol60, Cobol, Lisp, Forth…) - Langages de 3ème génération (1962 – 1970 : PL1, Algol68, Pascal, Simula, C(B)) - Langages de 4ème génération (1970 – 1980 : Smaltalk, Ada, C++) - Langages de 5ème génération (année 80 et 90 : Eiffel, Clos, Yafool, Objloo, Art, Ulysse, NewFlavors, Neon,

Java…) • La Complexité du dévellopement des Logiciels étant également liée au matériel, on note également une

évolution des systèmes matériels : Après l’architecture de Von Neumann, à la base de toutes les architectures modernes, les systèmes matériels vont

également évoluer rapidement dans le temps, pour permettre de développer des solutions de plus en plus performantes ; avec au centre le processeur (entité capable d’interpréter et exécuter un traitement ou processus). Au cours des années 70, on observe une révolution avec la création des microprocesseurs (1974 = Intel, 1982 = RISC, 1984 = 88020, etc.). L’explosion qui va suivre dans les années 80 entraînera une baisse permanente des coûts du matériel. 1.2 Crises :

• Malgré les évolutions citées plus haut, on note que au fur et à mesure que les coûts du matériel diminuent, les coûts des programmes informatiques (curieusement) augmentent !

La diminution des coûts du matériel (hardware) a conduit à associer l’ordinateur à de plus en plus de produits. Les coûts des logiciels connaissent une très forte croissance, dominant maintenant le coût du matériel et peuvent représenter plus de 80 % du coût total d’un système informatique. (ex coût de la mémoire économisée). • A la fin des années 70, on ne sait pas « faire » des logiciels (plusieurs tentatives de logiciels vont échouer) - Les besoins et contraintes de l’utilisateur ne sont pas respectés (pas de facilité d’emploi, interfaces

homme/machine inexistantes) - Les coûts ne sont pas maîtrisés - On relève régulièrement des retards dans la livraison des produits (non maîtrise du temps) - On note une grande rigidité dans les solutions mises en place - Quelque fois on arrive à des incohérences pendant l’utilisation - On est aussi confronté au manque de performance et de robustesse (fiabilité) - Les codes sont difficiles à maintenir - On arrive parfois à des logiciels non utilisables • En 1983, on se rend compte que : - 43% des logiciels sont livrés et non utilisés - 28% payés et non livrés - 19% utilisés tels quels - 3% utilisés sans modification (échec de tentative) - 2% utilisés avec modifications (réussite de tentative)



� �

• Les coûts de maintenance (lorsque cela se fait) dépassent ceux du développement • Le coût d’une erreur parfois dépasse le coût du système • Les pannes causées par le « bug de l’an 2000 » ont coûté environ 175 milliards de dollars aux entreprises du

monde, (Le Monde – 23 oct. 2001). • D’une étude sur 487 sites de toutes sortes de développement de logiciels, il ressort que : - 70% du coût du logiciel est consacré à sa maintenance - 42% des modifications sont dues à des demandes de l’utilisateur - 30% des exigences de spécification changent entre la 1ère édition d’une documentation et la première sortie du

produit - 17% à des changements de format des données (an 2000, 2a 2b …) - 12% problèmes d’urgence résolus à la hâte - 9% déboguages de programmes - 6% à des changements de matériel - 6% problèmes de documentation - 4% améliorations de l’efficacité - 3% autres…

Ces différents problèmes vont conduire à la création du Génie Logiciel.

1.3 Le Génie Logiciel Le Génie Logiciel est défini le 30 décembre 1983 comme étant « l’ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationnaliser la production du logiciel et son suivi ».

• Objectifs : - Maîtriser les coûts et les delais de développement - Améliorer la productivité (de l’équipe de développement) - Fournir une assurance qualité du produit livré

Le génie logiciel s’intéresse : - aux différentes théories - aux méthodologies : ( techniques, méthodes ) - aux outils - à l’organisation générale - à la gestion de projets

En bref, le Génie Logiciel c’est l’ensemble des méthodes, outils et techniques utilisées pour développer et maintenir du logiciel dans le but d’assurer la qualité et la productivité. C’est donc l’art de la construction du logiciel. Le génie logiciel est basé sur des méthodologies et des outils qui permettent de formaliser et même d'automatiser partiellement la production de logiciels, mais il est également basé sur des concepts plus informels, et demande des capacités de communication, d'interprétation et d'anticipation. De fait, la « crise du logiciel » n'est pas complètement résolue aujourd’hui. Le génie logiciel reste un « art »' qui demande de la part de l'informaticien une bonne formation aux différentes techniques (le savoir), mais également un certain entrainement et de l'expérience (le savoir faire). 1.4 Le processus logiciel, ou cycle de vie du logiciel

Le « cycle de vie d'un logiciel » (en anglais Software Lifecycle), désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre. L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.

Historiquement, le premier modèle de développement proposé (1966) est celui dit en ``cascade'', formalisé en 1970. Ce modèle a été assez largement mis en œuvre, mais on s'est rapidement aperçu qu'il n'est pas toujours approprié. Sa vision simpliste du processus sous-estime le coût des retours en arrière dans le cycle de vie. Ainsi, plusieurs alternatives au modèle en cascade ont été proposées, basées notamment sur le prototypage et l'assemblage de composants réutilisables. Le cycle de vie du logiciel comprend généralement au minima les activités suivantes :

• Définition des objectifs, consistant à définir la finalité du projet et son inscription dans une stratégie globale. • Analyse des besoins et faisabilité, exprimer, recueillir et formaliser les besoins du demandeur (le client) et de

l'ensemble des contraintes. • Spécification, définir le quoi du logiciel après dialogue avec le client. On donne ici les contraintes de temps,

etc. Cette phase débouche généralement sur un document de spécification (Software Requirement Analysis - SRA). Le SRA doit dégager clairement les fonctions, les interfaces (machines, utilisateurs, environnement), les contraintes (performance, mémoires, logiciels, machine).



� �

• Conception générale. formaliser les spécifications élaborées de l'architecture générale du logiciel. • Conception détaillée, indiquer le comment, définir de façon précise chaque sous-ensemble du logiciel. Ces

deux phases déboucheent généralement sur un document de conception (Software Design Report - SDR). • Codage, réaliser (programmer) ou codifier dans un langage de programmation des fonctionnalités définies lors

de phases de conception. Cette phase débouche sur un ensemble de codes (Program). • Tests unitaires, vérifier inidividuellement que chaque sous-ensemble du logiciel est implémenté

conformément aux spécifications. • Intégration , s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Les tests d'intégration (et

même parfois unitaires) seront consignés dans un document rapport (Software Test Report – STR). • Qualification , vérifier la conformité du logiciel aux spécifications initiales, procéder aux tests (on teste à

l’atelier, puis par la suite chez le client - livraison). • Documentation, produire les informations nécessaires pour l'utilisation du logiciel et pour des éventuelles

évolutions futures. • Mise en production, livrer et valider le produit. • Maintenance, entreprendre des actions correctives (maintenance corrective) et évolutives (maintenance

évolutive) sur le logiciel. En fonction du choix d'un modèle de cycle de vie entre le client et l'équipe de développement, on aura un séquencement ou la présence de chacune de ces activités dans le cycle de vie correspondant. Par exemple, dans le modèle en V, les procédures de vérification de la conformité du logiciel aux spécifications sont supposées être élaborées dès les phases de conception. 1.5 Représentations des modèles de développement 1.5.1 Modèle Exploratoire

Cette approche est essentiellement informelle.

Codage

Test

Mise au point

1.5.2 Modèle Cascade Le modèle en cascade est présenté ci-dessous. Il faut noter que dans ce modèle, une modification dans une étape

« N » ne remet en cause que l’étape « N-1 ».

Faisabilité

Analyse des besoins

-> spécification / cahier des charges

Conception du produit

-> plan de tests

Conception Détaillée

documents de fonctionnement -> Codage

Intégration

résultats des tests -> Installation

Exploitation et maintenance

Figure 1. Modèle exploratoire

Figure 2. Modèle Cascade



� �

1.5.3 Modèle en V

Le Schéma du modèle en V est présenté ci-dessous. Analyse

des besoins de

Faisabilité

��---------------------------------------------------------------------------------->

Installation et test du

système

Conformité/complétion/Correction

Spécifications ��--------------------------------------------------------> Acceptation

Conception architecturale

��------------------------------> Intégration et tests

Conception détaillé

��--------> Tests unitaires

Programmation Codage

Dans le modèle en cascade, chaque spécification faite aux étapes de gauche doit correspondre à une procédure de

test (jeu de test à décrire) pour s’assurer que le composant correspond à la description faite aux étapes de droite.

1.5.4 Modèle en spirale Ce modèle propose de généraliser les deux précédents. Il a été proposé par B.Boehem en 1988. - Dans le premier tour, on détermine les objectifs du cycle, les alternatives, les contraintes en s’appuyant sur les cycles précédents, ou sur une analyse primaire. - Dans le premier tour : analyser les risques, évaluer les alternatives, proposer un maquettage. - Dans le deuxième tour : s’occuper du développement et de la vérification de la solution retenue en cours. - Dans le troisième tour : passer en revue les résultats du cycle précédent et planifier le cycle suivant.

Figure 3. Modèle en V

Figure 4. Modèle en spirale



� �

1.5.5 Modèle Incrémental

Dans cette méthode, on évolue par incréments, en partant d’un noyau de base qui est par la suite complété progréssivement. Généralement, une bonne planification et une spécification rigoureuse sont nécessaires, ainsi qu’une bonne planification et une forte indépendance au niveau fonctionnel et au niveau du calendrier.

Identification des incréments

Spécification des incréments

Codage des incrémets

-----------�� | | | |

Evaluation des incréments

| | -------------------------------------------------

1.6 Méthodes

Dans l’Ingénierie d’un système logiciel, on retrouve les méthodes et outils servant tout au long du processus de développement. On peut y retrouver au moins 4 types de méthodes :

• Méhodes de planification stratégique du développement des systèmes applicatifs. Il s’agira de définir un processus décisionnel en se basant sur :

- Une politique informatique (mission ? objectifs ? règles ?) - Une stratégie informatique (projets ? budgets ?) - Une tactique informatique (faire plus avec moins) - Une action informatique (exploitation courante)

• Méthodes de développement proprement dit. - Spécification des besoins - Conception générale et détaillée - Réalisation - Installation : mise en exploitation, gestion des versions, apprentissage, suivi de fonctionnement et

d’utilisation - Maintenance

• Méthode de conduite des projets. Il s’agit d’estimer les moyens prévisionnels, les délais et les coûts

- planification - évaluation des charges, coûts et moyens - animation et conduite des travaux lors des étapes du cycle de développement - choix des méthodes à utiliser - contrôle d’avancement et d’exécution de tâches - organisation générale du projet - gestion des relations contractuelles avec les utilisateurs - définition des profils des participants au projet - gestion et formalisation des dossiers - gestion des relations contractuelles avec les fournisseurs - suivi analytique des projets

• Méthodes d’assurance qualité D’après l’AFNOR, c’est « l’attitude du produit à satisfaire les besoins (exprimés) des utilisateurs.

Comment peut-on obtenir la qualité ? - Définir clairement des exigences de sortie - Mesurer la conformité à chaque phase

Cela implique 4 grands temps : - Définition du processus et orientation de l’action qualité

o Diagnostic de la non qualité : problèmes, causes, poids, coûts, gain attendu de son éradication

o Manuel qualité (spécifique au logiciel à réaliser) o Plan qualité : politique, priorotés, action, budgets, plannings, stratégies de conduite

(pourrait servir pour n’importe quelle entreprise) o Fonction qualité

Figure 5. Modèle Incrémental



� �

- Mise en œuvre du processus et Action qualité (qui ?, comment ?, quand ?) o Définition des normes de qualité (par thème, type de projet, secteur d’activité) o Cahier de charges qualité : par projet o Plan d’assurance qualité du projet selon les aptitudes requises (fiabilité, temps de réponse,

…) o Contrat client-fournisseurs o Maquettage, prototype et simulation o Revues et inspection des étapes de l’analyse des besoins au codage o Règles et procédures de tests : étapes de test, construction des jeux d’essai, outils et

méthodes de tests, délais, niveau de test à atteindre o Qualimétrie du logiciel : évaluaton de la complexité du logiciel, difficulté de maintenance,

risques o Recette de qualification : inspection par le client, conformité par rapport au cahier de

charges fonctionnel, au cahier de charges qualité o Gestion opérationnelle de la qualité : suivi périodique des actions qualité, des fournisseurs

de l’application des plans d’assurance qualité, de l’évolution de la non qualité - Mesure de conformité et Animation de l’action qualité. Il s’agit beaucoup plus de mobiliser des informations et les partenaires, notamment :

o En créant les événements spécifiques o En amenant le maximum d’acteurs à participer o En respectant les valeurs individuelles et la confiance

- Amélioration par des moyens divers pouvant contribuer à la réussite des trois autres volets o Financiers o Humains o Techniques (logiciels, matériels, documentation)

En définitive, il s’agit de satisfaire les besoins de l’utilisateur au sens large. La qualité peut être « prouvée » en maîtrisant les paramètres tels que les coûts, les délais. On doit pouvoir la mesurer ou tout au moins la quantifier.

1.7 La Spécification La phase la plus délicate dans le processus de développement du logiciel, c’est celle des spécification.

Bertrand Meyer [Meyer 90] a défini les 7 pièges qui guettent lors d’un procéssus de spécification, mais également les 7 mots clés de réussite. 1.7.1 Les 7 péchés :

- Bruit : élément qui n’apporte aucune information (!) / redondance (!) - Silence : caractéristique d’un problème auquel ne correspond aucune partie du texte - Surspécification : lorsqu’on se lance dans un développement qui donne des détails inutiles (par exemple

anticiper sur les tables de la BD…) - Contradiction : dans les séquences de spécification - Ambiguités : une phrase peut avoir 2 ou plusieurs sens - Référence en avant : étant à une page, vous faites allusion à un concept qui sera présenté plus loin - Vœu pieux : attention à des éléments non vérifiables (!)

1.7.2 Les 7 caractéristiques d’une bonne spécification : - Conformité (aux besoins réel et non aux besoins supposés exprimés, souvent limités) - Communicable - Faisable - Modifiables - Validable - Complète - Cohérente

1.7.3 Les méthodes Lors de la phase de spécification, nous avons besoin au départ d’interviews bien faites, pouvant déboucher sur une

bonne documentation. Les méthodes de spécification de logiciels seront de trois catégories : - Informelle (structurée) - Semi-formelle - Formelle (mathématique)

Les méthodes de spécification intègrent : - Modèle - Démarche - Langage - Outils



� �

On pourrait donc très bien leur associer des environnements textuels, graphiques ou mixtes facilitant la compréhension et l’expression.

• Méthodes Informelles Elles n’ont pas un formalisme supportant une vérification, une validation (informatique ou simulation mathématique) Cas de SADT (dans son approche fonctionnelle), BOOCH (dans son approche objet initiale), MERISE…

• Méthodes Semi-formelles Elles permettent des vérifications, mais pas sur tous les apspects. Cas de SADT avec SART, Réseaux de Petri, E/A avec langages … (entité association)

• Méthodes Formelles Elles intègrent des langages permettant de définir toutes les contraintes et de garantir les vérification et la validation complète. Ces langages basés sur les mathématiques vont pouvoir prendre en compte n’imorte quel concept abstrait ou logique. Les outils sont :

- Automates - Logique (temprelle, modale) - Algebre (algebre universelle, algebre de processus) - Mixte

Un exemple : VDM (Vienna Description Method) : il utilise la théorie des ensembles pour décrire les entités et les objets ; mais aussi les formules de la logique de prédicats pour spécifier les propriétés (classes, etc.)

1.7.4 Les démarches d’analyse

Lorsqu’on veut modéliser un système, il faut modéliser trois catégories d’entités : • Données : aspects statiques, objets • Fonctions : transformations des données dans le système • Dynamique : changements dans le temps, contrôles (ex :modéliser les données en fonction du temps)

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

• Approche Fonctionnelle Les données et les fonctions sont modélisées séparément. Exemples: SADT-SART, etc. • Approche Objet Les données et les fonctions sont encapsulées dans les mêmes « boites » qui dialoguent entre elles (les objets) par envoi de messages. Exemples: Booch, HOOD, OOA, OMT, UP, etc.

• Approche Modèles

Voir MDE (Model Driven Ingineering) plus loin.

• Approche Agiles Voir méthodes Agiles plus loin.

Dans tous les cas, lors de votre démarche éssayez toujours de prendre en compte :

- Un maximum de modèles de besoins - Des modèles d’analyse suffisants - Une représentation des processus (fonctions + données) - Des modèles de contrôle suffisants - Une lisibilité claire du dictionnaire de données - Une bonne illustration des entrées et sorties (éventuellement les temps de réponse)

1.8 Techniques de Tests Les chiffres montrent que dans un procesus de développement, la phase de test coute 40% de l’ensemble (avec 40%

pour l’analyse et 20% pour le codage). Les programmes de tests peuvent parfois être plus longs que le programme à tester. Le concepteur devrait donc y penser dès le départ.

Durant les étapes du cycle de vie, on pourra retrouver des tests aux principales étapes : - tests d’unités (centrés sur les composants) - tests d’intégration (centrés sur les modules) - tests de validation (vérification des fonctionnalités, performances …) - tests de réception (« in situ » avec le personnel) - tests de régression (suite à des modifications)



� �

Les tests doivent permettre de détecter des érreurs ou des insuffisances dans un logiciel, en se basant sur un référentiel défini au préalable. On retrouve :

- les tests de vérification : il s’agit de s’assurer que le système est conforme aux spécifications définies initialement.

- les tests de correction : il s’agit de s’assurer que le système fournit des résultats exacts. - les tests de validation : il s’agit de s’assurer que le système répond aux attentes de l’utilisateur et aux

contraintes de l’environnement. Les tests effectués pourront être statiques (porter sur des textes, des spécifications ou des modules programmes sans les exécuter) ou dynamiques (porter sur des programmes à exécuter ou sur des séries de données entrées).

• Dans une approche statique, il est recommandé une vérification par plusieurs personnes (relecture des acteurs de différents niveaux et parfois même extérieurs au projet) des différents documents d’analyse, de codage (types de variables, initialisation, portabilité, branchement de code, incohérences, contraintes sur les attributs d’une table ou d’un fichier…), les modèles de BD, domaines de variation, preuves d’algorithmes, finition, etc. les relectures dans certains cas seront collégiales.

• Un gros projet doit absolument avoir un responsable des tests. • Dans une approche dynamique, il est important d’élaborer un « plan de tests » et un « dossier de

justification » de ceux-ci (choix des tests, résultats attendus, résultats obtenus, tests exclus pour certaines raisons telles que le coût ou l’impossibilité physique…)

• Durant les tests, les procédures doivent permettre d’augmenter les chances de détection de problèmes. • Dans une approche fonctionnelle : - Proceder à des tests aléatoires (statistiques) : elle permet des tirages selon une loi de probabilité qui peut être

uniforme ou basée sur une distribution aléatoire (poisson, gauss…) - Les données de test doivent être choisies judicieusement ! - Ne pas se limiter uniquement aux données « normales » ! mais prévoir des données sensibles pouvant entraîner

des exceptions. o tests aux limites (valeurs frontières) o tests hors limites (monkey) o cas nominaux

Exemple :

X/0 (-1)

-2

(0)

0

• Dans une approche orientée objet par exemple, il est préférable de décrire les méthodes de test en même

temps que les autres méthodes de la classe, et les encapsuler directement, en indiquant les valeurs attendues à chaque fois.

• Autres Recommandations : - Les méthodes de test ne doivent pas être longues et doivent être au mieux simplifiées. Elles doivent être bien

commentées. - Les jeux de tests doivent être définis clairement et justifiés - N’hésitez pas à effectuer certains tests au fur et à mesure de la mise en œuvre - Certaines méthodes doivent illustrer clairement les modes d’utilisation des autres méthodes jugées importantes - En cas de nécessité, faire appel à des générateurs (aléatoires…) de tests et contrôle de tests automatiques (exi.

JTests, assert etc.)

1.9 Processus de test de codes

1.9.1 Problématique : Beaucoup de langages, à l’instar de PHP sont flexibles, permissifs et faciles à appréhender. Malheureusement, certains principes qui font la force de certains langages ne sont pas implémentés dans d’autres langages. Par exemple, la rigeur et les contraintes de conception généralement imposées dans les langages à vocation industrielle (C/C++, Java, etc.) ne s'appliquent pas nécessairement avec des langages d’accès comme PHP. Finalement, le programmeur est seul maître à bord, il choisit la précision avec laquelle il souhaite intégrer un paradigme, que ce soit impératif, fonctionnel ou orienté objet, tout comme il décide de structurer ou non son développement par rapport à des processus éprouvés. Cette grande liberté est à l'origine du succès du langage, mais c'est également son plus grand défaut. Beaucoup de développeurs (PHP…) qui n'ont pas de formation spécifique en programmation ou qui sont peu expérimentés ne perçoivent pas l'importance d'un processus de développement, et de test en particulier. L'abscence d'une forme structurée de tests engendre notamment les problématiques suivantes : Le code source n'est pas testé en profondeur : cela a pour conséquence des aléas de « post-publication », plus ou moins critiques. Le plus souvent il s'agit d'instabilités dans l'application ou des problèmes de sécurité classiques.



� �

Le code source n'est pas robuste : toute modification du code source (refactorisation, ajout de fonctionnalités) est susceptible d'engendrer des régressions. Le code source n'est pas réutilisable, pas transmissible : si un autre développeur doit vous assister ou reprendre votre travail, il sera confronté d'une part à votre code source et d'autre part à l'absence d'un protocole de test uniformisé. Le code source n'est pas évolutif : il va sans dire, plus votre application aura une structure complexe plus vous peinerez à déceler des erreurs et problèmes de conception de manière empirique. Vous serez contraint à moyen terme, de reprogrammer entièrement votre application. Tout ceci aura non seulement un impact sur la fiabilité de votre programme (et vos prestations de service), mais également sur le temps alloué pour le développement et la maintenance du projet, avec les tracas que cela implique pour vous et vos utilisateurs finaux.

1.9.2 Processus de test : Nous présentons ci-après un processus et quelques conseils vous permettant d'utiliser les tests unitaires dans vos

projets PHP.

[Grossglauser07]

Le processus qui vous est proposé ci-dessus fait abstraction des contraintes liées à la gestion de projet (cahier des charges, organisation interne, etc.) ainsi que de la phase d'analyse. Il est basé sur le développement piloté par les tests (TDD) et s'adresse particulièrement aux développeurs PHP autonomes. Si vous développez en équipe, la base restera sensiblement la même mais vous devrez fournir des précisions au niveau de l'organisation et du partage des tâches, notamment. Le développement piloté par les tests (Test-Driven Development, ou TDD) est une méthode de développement mettant les tests unitaires au premier plan, on peut résumer son processus en cinq étapes :

1 Ajouter un test, 2 vérifier qu'il ne passe pas, 3 implémenter la fonctionnalité, 4 exécuter les tests unitaires - déboguer en cas d'échec, 5 refactoriser le code source - exécuter à nouveau les tests unitaires, passer à l'objectif suivant...

En reprenant le processus ci-dessus, vous observerez que l'approche TDD débute dès la phase de conception. Dans l'idéal, la structure de votre application devrait être modélisée dans un éditeur UML puis son squelette généré directement dans des fichiers PHP.

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



� �

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



� �

22 MM éétthhooddeess SSAADDTT eett RRéésseeaauuxx ddee PPeettrr ii 2.1 Introduction Des méthodologies développées permettent de modéliser des systèmes à risques, pour contribuer à l'intégration de la Sécurité Opérationnelle dans la phase d'analyse et de spécification des « systèmes automatisés ». Il s’agit de SADT et Réseaux de Petri (RdP).

- L'approche systémique, hiérarchique et structurée du SADT, est généralement bien adaptée pour représenter au mieux les connaissances structurelles et fonctionnelles du système étudié.

- Le formalisme des RdP, adapté à la prise en compte des problèmes de concurrence, de synchronisme et de parallélisme, constitue un excellent outil de spécification fonctionnelle d'un problème et de mise en évidence des contraintes. Les propriétés mathématiques qui découlent de l'analyse des RdP permettent une étude comportementale et structurelle essentielle à la validation d'une spécification.

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

2.2.1 Description Le Réseau de Pétri (RDP) décrit « mathématiquement » des systèmes grâce une représentation graphique dont les arcs et les nœuds sont valués avec des marquages. Il offre la possibilité de parallélisme, synchronisation, concurrence, exclusion, etc. Un RdP a des propriétés intrinsèques (dépendant ou non du marquage de départ) comme les branches mortes (inaccessibles), cycles, etc. Les places Pi et les transitions Ti d'un réseau de Petri, en nombre fini et non nul, sont reliées par des arcs orientés. Un réseau de Petri est dit graphe biparti alterné , c'est à dire qu'il y a alternance des types de noeuds : tout arc, qui doit obligatoirement avoir un noeud à chacune de ses extrémités, relie soit une place à une transition soit une transition à une place. Pour définir l'état d'un système modélisé par un réseau de Petri, il est nécessaire de compléter le réseau de Petri par un marquage. Ce marquage consiste à disposer un nombre entier (positif ou nul) de marques ou jetons dans chaque place du réseau de Petri. Le nombre de jetons contenus dans une place Pi sera noté mi. Le marquage du réseau sera alors défini par le vecteur M = {mi} .

[KaiserCottet01]

L'évolution de l'état du réseau de Petri correspond à une évolution du marquage. Les jetons, qui matérialisent l'état du réseau à un instant donné, peuvent passer d'une place à l'autre par franchissementiou tir d'une transition. Dans le cas des réseaux dits à arcs simples ou de poids 1, la régle d'évolution s'énonce de la manière suivante :

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



� �

Le franchissement d'une transition consiste à retirer un jeton dans chacune des places en amont de la transition et à ajouter un jeton dans chacune des places en aval de celle-ci.

[KaiserCottet01]

Un RdP peut être décrit entièrement avec les matrices d’incidences (ou caractéristiques) U- y U+ et un « marquage ». Les “jetons” ont généralement une interprétation semantique qui designe un changement d’état dû au franchissement de la transition. Les interfaces avec l’extérieur” se matérialisent par des transitions sans place. Il existe de nombreux développements et alternatives : les réseaux temporisés, colorés, continus… hybrides etc. NB : Les formlismes tels que « Grafcet » et « MERISE » (MCT) se sont à la base inspirés des réseaux de Petri.

2.2.2 Règles générales d'évolution temporelle d'un réseau de Petri Les règles générales d'évolution des réseaux de Petri marqué simple sont les suivantes :

- une transition est franchissable ou sensibilisée ou encore validée lorsque chacune des places en amont possède au moins un jeton,

- le réseau ne peut évoluer que par franchissement d'une seule transition à la fois, transition choisie parmi toutes celles qui sont validées à cet instant,

- le franchissement d'une transition est indivisible et de durée nulle. NB : si une transition est validée, cela n'implique pas qu'elle sera immédiatement franchie. Ces règles introduisent en effet un certain indéterminisme dans l'évolution des réseaux de Petri, puisque ceux-ci peuvent passer par différents états dont l'apparition est conditionnée par le choix des transitions tirées. Ce fonctionnement représente assez bien les situations réelles où il n'y a pas de priorité dans la succession des événements.

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



� �

2.2.3 Graphes de marquage L'évolution temporelle d'un RdP peut être décrite par un graphe de marquage représentant l'ensemble des marquages accessibles et d'arcs correspondant aux franchissements des transitions faisant passer d'un marquage à l'autre pour un marquage initial M0.

[KaiserCottet01]

Remarque : cette représentation permet de déterminer certaines propriétés d'un graphe. Par exemple si le graphe présente une zone non bouclée, cette partie du marquage une fois atteinte constitue un arrêt de l'évolution du RdP et celui-ci sera déclaré avec blocage.

2.2.4 Limites des RdP et extensions des possibilités

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

2.2.5 Extensions et autres Outils proches

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

- Les Réseaux de Petri Stochastiques généralisés et les Processus de Markov sont utilisés comme moteur de calculs.

- Les extensions des RdP aux RdP-temporisés et RdP-stochastiques, permettent de prendre en compte l'aspect dynamique des problèmes, permettant de faire, par exemple, de l'évaluation de performances.

Figure 9. Graphe de marquage



� �

2.3 Spécification à l’aide se SADT & IDEF (Structured Analysis and Design Technique - Icam DEFinition method)

2.3.1 Présentation SADT est une méthode graphique établie par Douglas T. ROSS (Softech) vers 1974. Parallèlement, le programme ICAM (Integrated Computer-Aided Manufacturing 1972) de l'US air force en commanda une définition domaine publique nommée IDEF0 (1975). ICAM établit ensuite d'autres modèles pour les aspects informationnels (IDEF1) et dynamiques (IDEF2). SADT reste encore plus répandu que SA/RT, qui lui est à présent préférée pour une meilleure prise en compte des aspects dynamiques. SADT part du constat selon lequel le monde est constitué de données et d’actions (comme c’est par exemple le cas avec les noms et les verbes en Langage Naturel).

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

* Les actigrammes mettent l’accent sur les activités (les données sont véhiculées sur les flèches). Ils viset à : - conférer une valeur ajoutée (entrée -> sortie) - créer une nouvelle donnée - solliciter (observer, contrôler etc.) une donnée

* les datagrammes s’appuient sur les données (les flèches représentent les activités). Ils exigent : - les activités génératrices - les activités de contrôle - les unités utilisées

Un modèle SADT est une suite hiérarchisée de diagrammes : (datagrammes et actigrammes) obtenue par raffinements successifs. Chaque « boite » peut-être à nouveau décomposée en un diagramme plus détaillé (Zoom). Au niveau général se trouve le diagramme de contexte (niveau –1), montrant les sources, les destinations. Chaque diagramme est

- soit un diagramme fils analysant une partie du diagramme père, - soit un diagramme père synthétisant les diagrammes enfants, soit les 2.

En fin de chaîne, un processus non décomposé est accompagné d’une mini spécification précisant comment sont produites les sorties à partir des entrées. Kit SADT :

- diagrammes d'activité - conditions d'activités - diagrammes de données - diagrammes explicatifs (ou textes uniquement) - liste hiérarchique des diagrammes - glossaire

Un modèle est un ensemble de kits établis suivant différents points de vue, ou buts ou contextes (Point de vue de l'utilisateur, du gestionnaire, de la maintenance de la production …)

2.3.3 SADT/IDEF0

2.3.3.1 LES ACTIGRAMMES SADT/IDEF0 Les actigrammes sont des diagrammes de décomposition fonctionnelle de l'application. Les diagrammes Le diagramme de contexte représente le système avec ses entrées et ses sorties



� �

entrée 1

entrée 2

(e3)

SYSTEME

commande

mecanisme

sortie

A-0 Diagramme de contexte

Le système est ensuite décomposé en ses principales fonctions dans un diagramme A0 :

entrée 1

entrée 2

commande

mecanisme

sortie

A0 Fonctions principales

fonction 1

fonction 2

fonction 3 s1

e1

e2

c1

e1a

e1b

m1

Les fonctions 1, 2, 3 peuvent faire l'objet d'une décomposition dans les diagrammes A1, A2, A3. Le diagramme A1 pouvant être décomposé en A11, A12, etc. Un diagramme doit comporter entre 3 et 6 fonctions. Chaque diagramme (ex : A0) peut comporter ou être annoté à l'aide de graphiques non formalisés (suffixe F, ex A0F1, A0F2, etc), de textes libres (suffixe T, ex A0T1, ...), ou de glossaires (suffixe G, ex A0G1,...) La fonction

e 1

e 2 Verbe

c

m

s

+ complément

Axx

Figure 10. Le diagramme de contexte SADT porte le nom A-0

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

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



� �

Une fonction ou une sous-fonction du système à spécifier est représentée par une boîte. La fonction doit être nommée par un verbe d'action et un complément d'objet. Si une fonction est décomposée, le nom du diagramme fils est noté en bas à droite de la boîte. Les flots Les flots de données sont échangés entre les fonctions.

entréesFonction

commandes

mécanismes

sorties

Axx

Suivant le coté de connexion avec la boîte, ils ont un des quatre rôles suivants :

• Entrées : Ce sont les « entités » nécessaires à la fonction transformées par elle en « sorties ». • Commandes : Ce sont les entités qui commandent le déroulement interne de la fonction (au moins une

commande est obligatoire) • Sorties : Ce sont les « entités » produites par la « fonction ». • Mécanismes : Ce sont les « entités » nécessaires à la réalisation mécanique de la « fonction » (machines,

personnels, etc) Plusieurs flèches peuvent être connectées. Les flots peuvent être décomposés ou composés. Une flèche en provenance de l'extérieur du diagramme comprend en plus de son nom un code (e/s/c/m) suivi de son numéro d'ordre par rapport à la boîte. Un nom de flot entouré de parenthèse (e3) n'est pas retrouvé dans le diagramme enfant. (IDEF0) Certaines conventions permettent de simplifier la représentation en utilisant des flèches à double sens. LES DATAGRAMMES SADT

Donnée

commandes

lectureécriture

Les datagrammes utilisent le même formalisme que les actigrammes. Simplement chaque boîte symbolise une donnée du système ou un fichier. Le datagramme est construit indépendamment de l'actigramme, il n'en est pas la traduction inversée, ce qui pose un problème de traçabilité. Les données en sont plus détaillées.

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

Figure 14. Datagrammes SADT



� �

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

• les "auteurs" (analystes) de la spécification (équipe de projet), • les "commentateurs" (critiques) amenés à critiquer constructivement la spécification. (Des auteurs

d'autres projets de la même division, DCQ, etc), • les "lecteurs" amenés à lire ou à juger la spécification sans être tenus de rédiger des remarques écrites, • les "experts", références du domaine d'emploi de l'application, consultés par les auteurs, souvent

commentateurs, • le "bibliothécaire" chargé d'archiver et de distribuer les documents, • le "comité technique" (facultatif) chargé de résoudre les litiges, • le "responsable du projet".

Le cycle auteur lecteur s'applique sur

• des brouillons ou des réalisations partielles de la spécification (kits standards) entre auteurs et commentateurs,

• des versions complètes entre auteurs, commentateurs, lecteurs, etc. Une procédure et des formulaires sont prévus pour organiser et archiver les versions soumises à critiques, les remarques des critiques, les réponses des auteurs. De même le processus de collection des informations, d'interview, de conduite de réunion est décrit.

2.3.4 LES EXTENSIONS IDEF1/IDEF2 L'ICAM n'a pas retenu les datagrammes de SADT. Deux autres modèles ont été définis pour ajouter les aspects informationnels et dynamiques à celui fonctionnel des actigrammes de SADT/IDEF0.

2.3.4.1 IDEF1 (LE MODELE INFORMATIONS) IDEF1 s'inspire des travaux de CHEN, BACHMAN et NIJSSEN.

NOM CLASSE ENTITE

ATTRIBUTS

NOM CLASSE ENTITE

ATTRIBUTS

NOM CLASSE ENTITE

ATTRIBUTSNOM CLASSE ENTITE

ATTRIBUTS

NOM CLASSE ENTITE

ATTRIBUTS

M:N

1:M

1:1

M:1

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

Figure 15. Modèle d'information ("classes")



� �

2.3.4.2 IDEF2 (LE MODELE DYNAMIQUE) Un modèle IDEF2 est composé de trois sous-modèles différents : Entity flow network submodel La gestion d'une entité telle qu'elle a pu être identifiée dans la phase IDEF1, utilise des enchaînements d'activités à l'intérieur du système. Le sous-modèle "Entity flow network" est une représentation graphique de tous les chemins que peut suivre le traitement d'une entité dans le système. Chaque chemin est constitué d'une succession d'activités. Ressource Disposition Trees Ce type de diagramme dont la représentation est similaire à celle d'un organigramme permet de définir les conditions de disponibilité d'une ressource, avec les actions possibles sur cette ressource :

• allocate • free • preempt • error

System Control Networks Le symbolisme de ce type de diagramme est proche de celui du « Entity flow network submodel ». Ce diagramme permet de représenter les activités ou conditions affectant l'état général du système, non spécifique d'une entité. Facility Diagrams Cet outil est un éditeur graphique doté d'un ensemble de symboles permettant de réaliser des diagrammes explicatifs non liés directement à la méthode. Les méthodes de travail Une méthode de travail similaire à celle décrite dans IDEF0 est décrite.

2.3.5 Avantages et Inconvenients SADT Avantatge :

- aspect dynamique limité - cohérence entre actigramme et datagramme parfois difficile - pas ou peu de synchronisation

Inconvenients : - très bonne lisibilité (même par des non informaticiens) - nombre restreint de concepts, donc apprentissage rapide et facilité de communication - structure hiérarchique très modulaire.

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



� �

33 AApppprroocchhee oorr iieennttééee OObbjj eett eett UUMM LL 3.1 Introduction Deux types de motivation orientent actuellement les concepteurs dans le choix des méthodes de conception: la possibilité de prendre en compte des applications et des systèmes de plus en plus complexes [Gardarin97][Leray92][Zoller97] et le soucis de diminuer les coûts de réalisation et de maintenance. Avec l’ère des nouvelles technologies, des réseaux informatiques et systèmes répartis, les applications ont atteint elles aussi un niveau de complexité croissant et de ce fait, elles nécessitent à l’heure actuelle, des outils de programmation sophistiqués. On constate que les applications dites technique, telles que la CAO, la cartographie, les systèmes de contrôle temps réel, le CoDesign, représentent une activité croissante et nécessitent une plus grande participation des personnes aussi bien pour l'effort de conception et validation que de maintenance et d'évolution. Ces constats ont mis en évidence la nécessité de promouvoir l’abstraction de données, la modularité et la réutilisabilité [Manhes98] des composants fabriqués. Ainsi, beaucoup de méthodes ont vu le jour, chacune tentant à sa manière d’apporter une solution satisfaisante et parmi elles, les méthodes objets (orientées objet) et leurs techniques d’analyse et de conception appropriées. Pourquoi parler de Programmation Orientée Objets (POO) ? La complexité et la taille des projets nécessite des outils de programmation nombreux et perfectionnés pour mener à bien les applications dans les meilleurs délais. En fait, les langages à objets connaissent un succès grandissant, aussi bien dans le domaine de l’Intelligence Artificielle (IA) que dans celui du Génie Logiciel ou des BD, car ils constituent sans doute la solution la plus souple et offre plus de perspectives pour répondre à ces différents besoins. 3.2 Les concepts de base: [Bouzegoub97] Un objet est une abstraction d'une donnée du monde réel caractérisée ainsi: Objet = identité + état + comportement L'identité d'un objet est représentée par un identifiant (object identifier ou OID) unique et invariant qui permet de référencer l'objet indépendamment des autres objets. L'état d'un objet est une valeur qui peut être simple, par exemple, un littéral, ou structurée, par exemple, une liste. Dans le dernier cas, l’état peut être composé de valeurs simples, de références à d'autres objets, ou de valeurs elles-mêmes structurées. Le comportement d'un objet est défini par un ensemble d'opérations applicables à l'objet et définies dans sa classe d'appartenance. En résumé, nous avons la définition suivante : Objet: abstraction d'une donnée caractérisée par un identifiant unique et invariant, un état représenté par une valeur simple ou structurée, et une classe d'appartenance. L'identité et l'égalité de deux objets sont deux notions différentes. Deux objets o1 et o2 sont identiques si leurs identifiants sont égaux (o1==o2). Deux objets o1 et o2 sont égaux si leurs états sont égaux (o1=o2). Donc nous avons (o1==o2)⇒(o1=o2). L’univers devient donc une structure composée d’ensemble d’objets déterminant chacun les clés de son comportement. Les types d'objets seront des classes, et les objets (instances) seront considérés comme représentants de classes. Exemple:

Les principes énoncés plus haut offrent des qualités pour mettre en œuvre des méthodes rigoureuses. Ainsi, on doit retrouver dans une approche objet au moins 4 principes obligatoires: abstraction, encapsulation, modularité, hiérarchie ; auxquels on peut ajouter 3 principes complémentaires : typage, simultanéité, persistance. Abstraction ( ≡≡≡≡ définition d’une classe) Elle fait ressortir les caractéristiques essentielles d’un objet (qui le distinguent de tous les autres) et donc procure des frontières conceptuelles vigoureusement définies du point de vue de l’observateur (utilisateur).

Figure 16. Exemple de représentation d'un objet d'une classe

Objet (instance)

Démarrer Rouler Stopper

. Classe VOITURE .

-immatriculation - marque - …

Démarrer () Rouler () Stopper ()



� �

On distingue 3 types d’abstraction : - Abstraction d’action : objets procurant un ensemble généralisé d’opérations réalisant toutes le même nombre de

fonctions et le même genre. - Abstraction de machine virtuelle : autonomie. - Abstraction de coïncidence : objets n’ayant aucune relation entre eux. C'est l’objet qui décide la manière d’effectuer les opérations. Il n’est pas besoin de connaître l’implémentation interne d’un objet… Encapsulation C’est le procédé de séparation des éléments d’une abstraction qui constituent sa structure et son fonctionnement. Elle permet de dissocier l’interface conceptuelle de la mise en œuvre d’un objet (on cache l’implémentation des méthodes). L’encapsulation suppose également lisibilité et compréhensibilité. Les possibilités de surcharge et la modularité renforcent la lisibilité des codes. Mais, les détails d’implantation sont généralement cachés. Modularité La modularité est la propriété d’un système décomposé en ensemble de modules cohérents faiblement couplés. La modularité suppose également la modifiabilité: les objets sont faciles à changer. Hiérarchie (héritage) C’est un « classement » ou ordonnancement des abstractions. En capturant la relation de généralisation, il facilite la modélisation des objets et la modularité du code. Il permet la réutilisation des attributs et opérations des classes d'objets, et élimine les redondances. Le typage Le fait d’imposer la classe d’un objet de façon que les objets de types différents ne puissent pas être intervertis, ou tout au plus ne puissent être intervertis que de façon restrictive. Simultanéité Deux objets différents doivent pouvoir agir en même temps et à des endroits différents (soit sur la même machine, soit sur des machines différentes,…). Persistance Ceci concerne la durée de vie d’un objet (important dans les BD, ou les données sont disponibles pendant longtemps). 3.3 Cycle de vie : Le cycle de vie d’un logiciel est généralement proche de l’incrémental (par opposition au cycle itératif classique). Les étapes de spécification sont : - étude du vocabulaire du projet : noms, verbes, objets, … - identification des objets physiques. - Formalisation d’un modèle (liens, communication, …)

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

Figure 17. Cycle de vie spécifique

Identification classes et objets

Identification des relations entre objets

Identification des sémantiques des classes et objets

Mise en œuvre des classes et objets



� �

3.4 Les « modèles » Les langages de modélisation (à l’instar de UML) permettent de représenter une conception orientée objet. Les

modèles (« patterns ») s’intéressent quant à eux aux résultats du processus et fournissent des exemples. Dans plusieurs cas, les projets rencontrent des problèmes parce que leurs responsables ne maîtrisent pas des méthodes bien connues des concepteurs expérimentés. Les modèles décrivent des façons de procéder courantes. Les modèles de conception décrivent des techniques de conception. Ils sont recueillis par des personnes qui repèrent les thèmes récurrents de la conception. Ces personnes examinent chaque thème et le décrivent pour que d’autres puissent étudier le modèle et voir comment l’appliquer. 3.5 LE LANGAGE UML 3.5.1 La genèse d'UML La première moitié des années 90 a vu fleurir une cinquantaine de méthodes objets. L'examen des méthodes dominantes a permis de dégager un consensus autour d'idées communes. Les grands traits des objets, repris par de nombreuses méthodes, s'articulent autour des notions de classe, d'association (James Rumbaugh), de partition en sous-systèmes (Grady Booch) et autour de l'expression des besoins à partir de l'étude de l'interaction entre l'utilisateur et le système (les use cases d'Ivar Jacobson). En 1994, on recensait plus de 50 méthodologies orientées objets. C’est dans le but de remédier à cette dispersion que les « poids-lourds » de la méthodologie orientée objets ont entrepris de se regrouper autour d’un standard. Partant de la constatation que les différences entre les méthodes s'amenuisent et que la « guerre » des méthodes ne fait plus progresser la technologie objet, en octobre 1994, Grady Booch et James Rumbaugh se sont réunis au sein de la société RATIONAL dans le but de travailler à l’élaboration d’une méthode commune qui intègre les avantages de l’ensemble des méthodes reconnues, en corrigeant les défauts et en comblant les déficits. Ils d'unifier leurs travaux au sein d'une méthode unique : la méthode unifiée (The Unified Method). Une année plus tard, ils sont rejoints par Ivar Jacobson. Ces trois chercheurs se sont fixé quatre objectifs :

- Représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets - Etablir un couplage explicite entre les concepts et les artefacts (phénomène/structure virtuelle dont

l’apparition est liée à une expérience/un cas) - Prendre en compte les facteurs d'échelle inhérents aux systèmes complexes et critiques. - Créer un langage de modélisation à la fois par les humains et les machines.

Depuis 1996, ces objectifs sont quasiment atteints. La méthode unifiée est devenue plutôt le langage UML. UML est un élément de base dans la stratégie de plusieurs entreprises. Un ensemble de partenaires réunis au sein de l'OMG (regroupant notamment IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.), travaille pour la description d'UML version améliorée. UML n'est pas un standard de fait mais un standard « industriel » de l'OMG (novembre 1997) au même titre que CORBA par exemple. Ceci étant, vu le succès initial de ce langage, il commence à devenir un « standard de fait ». 3.5.2 Généalogie UML [wwwGeneal01]

Figure 18. Généalogie d'UML



� �

Evolution des version d’UML

Version Date Activité Avant 1993 Autres méthodes + Booch’91 + OMT-1 + OOSE + Partenaire

1ères reflexions 0.0 1993-1994 Booch’93 + OMT-2+… Méthode Unifiée 0.8 Octobre 1995 OOPSLA’95 (Object Oriented Programming Systems, Languages and

Applications, / Une Conférence de la programmation orientée objets) MUL 0.9 Juin 1996 Version bêta OOPSLA’96 UML 1.0 Septembre 1997 Soumis à l’OMG en janvier 1997 + OCL (IBM) UML 1.1 Novembre 1997 Révision UML 1.2 Juin 19987 UML 1.X 1999-2002 UML 2.0 Janvier 2005 Soummissiopn à l’OMG en 2003 UML 2.1 2006 Définition en cours par une commission de révision

3.5.3 Notions usuelles Ce mini glossaire définit les termes employés dans la description du Langage Unifié de Modélisation (UML). On retrouvera plus loin, en plus de la terminologie spécifique à UML, des termes se rapportant au standard OMG, à l'analyse objet et aux méthodes de conception. Automate : Un comportement qui spécifie les séquences d’états traversées par un objet ou une interaction en réponse à des événements accompagnés des réponses et des actions. CLASSE : DESCRIPTION D’ENSEMBLE D’OBJETS PARTAGEANT LES MEMES ATTRIBUTS, METHODES, RELATIONS ET CONTRAINTES. Diagramme : Une représentation graphique d’une collection d’éléments de modélisation, le plus souvent visualisée comme un graphe d’arcs (relations) et de sommets (autres éléments de modélisation). Objet persistant : Un objet qui continu d’exister après la mort du processus qui l’a créé. Paquetage : Un mécanisme universel pour grouper des éléments. Les paquetages peuvent être emboîtés les uns dans les autres. Un système peut être vu comme un seul paquetage abstrait qui contient tout le reste. 3.5.4 Le formalisme d'UML Vous trouverez tous les détails sur les spécifications du métamodèle UML dans [OMGWWW].

Le formalisme UML 2.0 est composé de 13 types de diagrammes (9 en UML 1.3). UML n'étant pas une méthode, leur utilisation est laissée à l'appréciation de chacun, même si le diagramme de classes est généralement considéré comme l'élément central d'UML. De même, on peut se contenter de modéliser seulement partiellement un système, par exemple certaines parties critiques. UML se décompose en plusieurs sous-ensembles

• Les vues : Les vues sont les observables du système. Elles décrivent le système d'un point de vue donné, qui peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet.

Tableau 1. Historique Evolution des version d’UML

Figure 19. Métamodèle UML



� �

• Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.

• Les modèles d'éléments : Les modèles d'éléments sont les briques des diagrammes UML, ces modèles sont utilisés dans plusieurs types de diagrammes. Exemple d'éléments : cas d'utilisation (CU ou cadut'), classe, association, etc.

3.5.4.1 Les vues Les vues peuvent se superposer pour collaborer à la définition du système.

• Vue des cas d'utilisation : c'est la description du système "vue" par les acteurs du système. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI ).

• Vue logique : C'est la définition du système vue de l'intérieur. Elle explique comment peuvent être satisfaits les besoins des acteurs (c'est le COMMENT ).

• Vue d'implémentation : Cette vue définit les dépendances entre les modules. • Vue des processus : C'est la vue temporelle et technique, qui met en œuvre les notions de tâches concurrentes,

stimuli, contrôle, synchronisation, etc. • Vue de déploiement : Cette vue décrit la position géographique et l'architecture physique de chaque élément du

système (c'est le OÙ). NB : Le POURQUOI, n'est pas défini dans UML actuellement. 3.5.4.2 Les diagrammes [Fowler03] UML est un langage de modélisation et non une méthode. La plupart des méthodes proposent (en principe) un langage de modélisation et un processus. Le langage de modélisation est une notation (ésentiellement graphique) que les méthodes utilisent pour représenter la conception. Le processus est une façon d’envisager la marche à suivre lors de la conception. Il existe des processus qui complètent le langage UML :

- RUP (Rational Unified Process) développé par les trois concepteurs d’UML - 2TUP (Two track Unified process)

UML est très intuitif, plus simple, plus homogène et plus cohérent que les autres méthodes. En plus des paquetages et des notes, trois familles de diagrammes composent le langage UML. Les 13 diagrammes UML sont dépendants hiérarchiquement et se complètent. Ils permettent de visualiser et de manipuler les éléments de la modélisation :

→→→→ Diagrammes Structurels ou Diagrammes statiques (Structure Diagram) • Diagramme de classes (Class diagram) : représentation de la structure statique en terme de classes et

de relations. • Diagramme d'objets (Object diagram) : représentation des objets et de leurs relations, correspond à un

diagramme de collaboration simplifié, sans représentation des envois de message. • Diagramme de composants (Component diagram) : décrivent les éléments (ou modules) physiques

tels que mis en œuvre (fichiers, bibliothèques, bases de données...) et leurs relations. • Diagramme de déploiement : représentation du déploiement des composants sur les dispositifs

matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent avec eux.

• Diagramme des paquetages (Package Diagram) : • Diagramme de structures composites (Composite Structure Diagram) :

→→→→ Diagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagram) • Diagramme des cas d'utilisation (use-cases) (Use case diagram) : représentation des fonctions du

système du point de vue de l’utilisateur. Il décrit les possibilités d'interaction entre le système et les acteurs, c'est-à-dire toutes les fonctionnalités que doit fournir le système.

• Diagramme d’États-Transitions (StateChart / State Machine Diagram) : représentation du comportement d’une classe en terme d’état ; il montre la manière dont l'état du système (ou de sous-parties) est modifié en fonction des événements du système.

• Diagramme d'activité (Activity Diagram) : représentation du comportement d’une opération en terme d’action ; variante du diagramme d'états-transitions, il permet de représenter le déclenchement d'événements en fonction des états du système et de modéliser des comportements parallélisables (multi-threads ou multi-processus).

Diagrammes d'interactions (Interaction Diagram) : • Diagramme de séquence (Sequence Diagram) : représentation temporelle des objets et de leurs

interactions ; représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou des acteurs.

• Diagramme de communication (Communication Diagram) : représentation spatiale des objets, des liens et des interactions ; représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets.



� �

• Diagramme global d'interaction (Interaction Overview Diagram) : variante du diagramme d'activité où les nœuds sont des interactions.

• Diagramme de temps (Timing Diagram) : représentation des interactions où l'aspect temporel est mis en valeur.

Aux différents états d'élaboration d’un projet correspond l'utilisation de certains diagrammes. Par contre, les diagrammes des cas d'utilisation se retrouveront à tous les stades du projet. 3.5.5 La modélisation par UML 3.5.5.1 La modélisation des cas d'utilisation • Les cas d'utilisations partitionnent les besoins fonctionnels d'un système (selon le point de vue d'une catégorie

d'utilisation à la fois). Ils montrent les utilisations du système et les acteurs interagissant avec lui. • La modélisation par les cas d'utilisation comble le fossé entre les analystes, les utilisateurs et les développeurs.

La façon de décrire le contenu d’un cas d’utilisation varie énormément et UML ne souhaite pas imposer une norme. Vous pouvez par exemple ajouter une ligne de précondition (ce qui doit être VRAI au début du cas d’utilisation). Un format simple pour capturer un cas d’utilisation consiste à décrire le scénario de base sous forme d’étapes numérotées et les variantes de cette séquence, comme ci-dessous (une application de commerce électronique).

ACHAT : 1. Le client parcourt le catalogue et sélectionne les produits qu’il souhaite acheter 2. Le client valide ses choix 3. Le client fournit les informations concernant la livraison (adresse, livraison en 24 heures ou 3 jours) 4. Le système affiche les éléments de facturation et les informations concernant la livraison 5. Le client fournit les informations concernant sa carte de crédit 6. Le système valide la transaction 7. Le système confirme la transaction immédiatement 8. Le système expédie un Email de confirmation au client Alternative : Echec de l’autorisation

A l’étape 6, la transaction n’est pas validée par le système Autoriser le client à saisir à nouveau les informations concernant sa carte de crédit et réessayer

Alternative : Client régulier 3a. Le système affiche les informations associées à ce client concernant la livraison, les critères de tarification, et les quatre derniers chiffres de son numéro de carte de crédit 3b. Le client peut accepter ou modifier les valeurs affichées Retourner au scénario principal de l’étape 6

La quantité de détails dont vous avez besoin dépend du risque que présente le cas d’utilisation. Plus le risque est important, plus vous devez détailler. Un acteur est un rôle que l’utilisateur joue par rapport au système. Les acteurs réalisent les cas d’utilisation. Un seul acteur peut réaliser plusieurs cas et, inversement, un cas peut avoir plusieurs acteurs. Formalisme du diagramme de cas d’utilisation : Pendant l’élaboration, nous décomposons souvent tous les cas qui deviennent trop complexes. Nous le faisons en phase de construction si nous nous rendons compte que nous ne pouvons pas construire la totalité du cas en une seule itération. Dans ce cas, nous nous occupons d’abord du cas normal, et ensuite des variantes. Appliquer les règles suivantes : • Utiliser include quand vous voulez éviter la répétition entre plusieurs cas d’utilisation. • Utilisez la généralisation quand vous décrivez une variante au comportement standard et que vous voulez

simplement la décrire. • Utilisez extend quand vous décrivez une variante au comportement standard et que vous voulez explicitement

indiquer son activation, en déclarant des points d’extension dans le cas d’utilisation de base.

Figure 20. Acteur, cas d'utilisation et association

Nom de l'association de communication

Nom de l'acteur Nom du cas d'utilisation



� �

[Nkenlif04]

Cas d’utilisation « Métier » et « Système » : Vous entendrez souvent parler de « cas d’utilisation système » et « cas d’utilisation métier ». Les termes peuvent être imprécis, mais, dans l’usage courant, un cas d’utilisation système est une interaction avec le logiciel, alors qu’un cas d’utilisation métier aborde la façon dont un "métier" répond à un client ou à un événement. Nous ne nous attarderons pas sur cette question. Aux premiers stades de l’élaboration, nous nous penchons plus sur les cas métier, mais les cas système sont plus utiles quand il s’agit de planifier. Les cas métier sont utiles, en particulier pour envisager d’autres façons de répondre aux objectifs d’un acteur. 3.5.5.2 La modélisation des classes et des objets • La modélisation objet est utilisée dans le langage UML pour définir des objets-métiers et l'architecture de

l'application. Les objets sont créés comme instances de classes. Ils interagissent dynamiquement pour offrir le comportement décrit par les cas d'utilisation. La modélisation objet définit le comportement requis par les différentes classes pour assurer la bonne mise en place des cas d'utilisation et des règles de gestion.

• Les objets-métiers constituent la base de l'architecture des applications. Ces objets peuvent être réutilisés à travers des domaines d'application ou encore être identifiés et dérivés directement des cas d'utilisation ou du domaine de l'application.

Figure 21 Diagramme de cas d’utilisation de la simulation des systèmes continus

Figure 22. Un exemple de Diagramme de cas d’utilisation

Figure 23. Relation d’extension

Système externe (séquentiel)

Simuler

Envoyer

précision

Tracer courbes

Afficher solutions

Use

Include

Use

Include

Vitesse

Erreur

Stabilité

Include

Include

Convertir Fonction

Résoudre équations

ActVenSys TranDirSys

Include

Include

Use



� �

• La modélisation des classes capture le détail de la structure des objets-metiers. Les classes constituent la base pour la génération des codes et pour la génération des schémas de bases de données.

• Les définitions des classes et de leurs relations sont regroupées dans des paquetages afin de définir l'architecture des applications. Ces paquetages peuvent être emboîtés les uns dans les autres. Les relations entre paquetages définissent les dépendances dans l'application et déterminent la stabilité de l'architecture.

Un diagramme de classe décrit les types d’objets qui composent le système et les différents types de relations statiques qui existent entre eux. Il existe principalement deux sortes de relations statiques :

- Les associations : (un client peut par exemple louer un certain nombre de cassettes vidéo) - Les sous-types : (une infirmière est une sorte de personne).

Les diagrammes de classes représentent également les attributs et les opérations d’une classe et les contraintes qui s’appliquent à la façon dont les objets sont connectés. [Fowler03]

Quand utiliser les diagrammes de classe ? [Fowler03] Les diagrammes de classe sont l’épine dorsale de presque toutes les méthodes orientées objet, et vous les utiliserez en permanence. Le problème des diagrammes de classe est qu’ils sont si riches que leur utilisation peut être épuisante.

Voici quelques conseils : • Adaptez le point de vue à partir duquel vous élaborez les modèles au stade où en est le projet.

- En phase d’analyse, créez des modèles conceptuels ; - Dans les phases suivantes, concentrez-vous sur les modèles de spécification ; - Ne créez des modèles d’implémentation que pour illustrer une technique particulière.

Figure 24. Notations de diagramme de classes



� �

Exemple de diagramme de classe [Nkenlif04]

Figure 25. Un exemple de Diagramme de classes : cas des systèmes séquentiels automatiques et interactions

1

Co

nd

itio

nn

e

Déc

rit

ETAPE TRANSITION

ACTION

RECEPTIVITE

ACTDIRSYS

LIEN

LIEN SELECTIF

LIEN PARALLELE

LIEN SIMPLE

RECVENSYS

ACTION SIMPLE

ACTION MULTIPLE

(package)

GRAFCET

Ap

par

tien

t à

RECEPTIVITE LOGIQUE

RECEPTIVITE TEMPORELLE

(package)

SYSTEM SEQUENTIEL

GRAFCET

ACTION DETAILLEE

0 .. 1

Est décrit par 0 .. *

1

1 .. * 1 .. *

0 .. 1

0 .. *

1 .. *

0 .. * 1 .. *

MACRO-ACTION

1 .. *

1 .. *

LIEN EXCLUSIF

LSAUT ETAPE

LIEN COUPLAGE SEQ



� �

Les points de vue de base Vous pouvez partir de trois poinst de vue différents quand vous créez un diagramme de classe (ou n’importe quel modèle), mais la différence est plus perceptible avec les diagrammes de classe. • Le point de vue conceptuel . Si vous adoptez le point de vue conceptuel, vous tracez un diagramme qui représente

les concepts du domaine que vous étudiez. De fait, un modèle conceptuel ne devrait pas, ou peu, prendre en compte le logiciel qui pourrait le mettre en œuvre et donc être considéré comme indépendant du langage (c’est ce que Cook & Daniels appellent point de vue essentiel).

• Le point de vue des spécifications. Nous nous attachons maintenant au logiciel, mais nous nous occupons de ses interfaces, mais pas de son implémentation.

• Le point de vue de l’implémentation. Nous avons réellement des classes et mettons à nu l’implémentation. Il est fondamental de comprendre de quel point de vue on se place, tant pour la création que pour l’interprétation des diagrammes de classe. Malheureusement, la délimitation entre eux est quelque peu floue, et la plupart des modélisateurs ne se préoccupent pas de dissiper la confusion. UML est bien compatible avec les trois points de vue précédents. En étiquetant les classes avec un stéréotype, vous pouvez fournir une indication sur le point de vue : Vous annotez les classes "classes implémentation" si vous partez du point de vue de l’implémentation et "type" si vous partez du point de ue conceptuel ou de celui des spécifications. Diagrammes d’objets Un diagramme d’objet est une représentation instantanné des objets présents dans un système à un moment donné. Comme il représente des instances et non des classes, on le nomme souvent diagramme d’instance. Associations Les associations représentent les liens unissant les instances des classes (Ex. une personne travaille dans une entreprise ; une entreprise a un certain nombre de succursales, etc.). Chaque association a également deux extrémités ou rôles, chacune d’elle étant reliée à l’une des classes de l’association. Un rôle peut être nommé explicitement au moyen d’une étiquette, que l’on appelle nom de rôle. Chaque association a également une multiplicité (« cardinalité ») qui indique le nombre d’objets susceptibles de participer à une association donnée. Attributs Les attributs sont nassez « semblables » aux associations du point de vue conceptuel. Selon que le diagramme est détaillé ou nom, la notation d’un attribut peut présenter son NOM, son TYPE et sa VALEUR par défaut. La syntaxe UML est : visibilité nom : type = valeurParDefaut Opérations Les opérations sont les processus qu’une classe sait mener à bien et elles correspondent aux méthodes d’une classe. Généralisation Un exemple de généralisation est celui des clients particuliers et professionnels d’une entreprise. Ils présentent des différences, mais également de nombreuses similitides. On peut placer ces dernières dans une classe générique Client (le supertype), dont ClientParticulier et Professionnel sont des sous-types. La généralisation est associée à l’héritage. Stéréotypes Ils constituent le principal mécanisme d’extension d’UML. Si vous avez besoin d’une construction de modélisation qui ne fait pas partie d’UML mais qui présente des similarités avec une construction qui en fait partie, vous pouvez la traiter comme un stéréotype UML. Les stéréotypes permettent d'apposer une sémantique particulière aux éléments UML. On peut alors spécialiser le langage UML afin qu'il s'adapte mieux au domaine dans lequel le langage est utilisé. Exemple : Le concept d’"interface UML", représente une classe n’ayant que des opérations publiques, sans définition de corps pour les méthodes ni les attributs. En fait, elle correspond aux interfaces Java, CORBA (OMG) et COM (Microsoft). Comme c’est un type de classe spécial, elle est définie comme stéréotype de classe. Généralement, les stéréotypes sont représentés par un texte entre guillemets (ex : « interface »), mais vous pouvez également définir une icône. On peut citer par exemple l'utilisation de stéréotype "<<Table>>" sur des classes dans les diagrammes de classes dans le cadre d'une modélisation de base de données. Opérations et attributs : visibilité de classe Une opération ou un attribut qui s’applique à une classe et non à une instance a une visibilité de classe. Elle correspond aux membres static en Java ou en C++, et aux méthodes et variables de classes en Smaltalk. Dans un diagramme de classe UML, les membres de classe sont soulignés.

Figure 26. Notation de la visibilité de clase

Visibilité de Classe



� �

Classification multiple et dynamique La classification désigne la relation unissant un objet à un type. Dans la classification unique, un objet n’appartient qu’à un seul type, qui peut hériter de supertypes. Dans la classification multiple, un objet peut être décrit par plusieurs types, qui ne sont pas nécéssairement associés par une relation d’héritage. Remarque : la classification multiple diffère de l’héritage multiple. Dans l’héritage multiple, un type peut avoir plusieurs supertypes, mais un objet ne peut appartenir qu’à un seul type. La classification multiple permet à un objet d’appartenir à plusieurs types, sans qu’il soit pour autant nécéssaire de définir un type spécifique. Exemple : cas d’une Personne sous-typée comme Homme / Femme, Médecin / Infirmier, Patient / EnSanté. On étiquette alors une relation de généralisation au moyen d’un discriminateur qui indique sur quelle base s’effectue le sous-tpage. [Fowler03]

Agrégation et composition L’ agrégation est la relation « est une partie de », comme le moteur et les roues sont des parties d’une voiture. Cependant, UML offre une variété d’agrégation plus forte, nommée composition. Dans la composition, l’objet « partie » ne peut appartenir qu’à un seul « tout ». De plus, on suppose généralement que les parties sont créées et meurent avec le tout (la destruction du tout se propage en cascade à ses parties).

Associations et attributs dérivés Les association dérivées et les attributs dérivés dépendent d’autres associations ou d’autres attributs. On peut, par exemple, dériver l’attribut « âge » d’une Personne si l’on connaît sa date de naissance. Il est important de se rendre compte que la dérivation indique alors une contrainte entre valeurs, et non une assertion de ce qui est calculé et de ce qui est mémorisé.

Figure 27. Classification multiple

Figure 28. Composition , agrégation, navigabilité, contraintes



� �

Notez bien les points suivants (figure ci-dessus) :

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

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

Objets valeur et objets référence Les objets référence sont des objets tels que Client. Ici, l’identité est très importante, parce qu’on souhaite généralement qu’un seul objet logiciel désigne un client du monde réel. Tout objet qui mémorise l’identité d’un objet Client le fera Via une référence ou un pointeur, et tout les objets qui se référent à ce Client référenceront le même objet logiciel. De cette façon, les changements apportés à un Client seront disponibles pour tous les utilisateurs de ce Client. Les objets valeur sont des objets tels que Date. Il existe souvent plusieurs objets valeur qui représentent le même objet du monde réel. Il est par exemple normal d’avoir des centaines d’objets qui désignent le « 1er décembre 2007 ». Ce sont tous des copies interchangeables. On crée et détruit fréquemment de nouvelles Dates. Si vous avez deux objets Date et si vous voulez savoir s’ils mémorisent la même, vous devez écrire un test d’égalité (examination de la valeur, et non de l’identité) qui, dans ce cas, teste l’année, le mois et le jour. Habituellement, c’est vrai qu’on crée un objet Date chaque fois qu’une Date est nécéssaire, mais on peut aussi ne créer qu’un seul objet Date pour une date donnée et le partager.

Figure 29. Représentation d’Associations et attributs dérivés

Figure 30. Exemple de classe abstraite : FENETRE



� �

Les objets valeur doivent être immuables (ou gelés – frozen) Immuabilité : « frozen » UML définit la contrainte frozen (gelé) comme applicable à un attribut ou à une extrémité d’association, mais elle est également utile pour les classes. Sur un attribut ou une association, frozen indique que la valeur de cet attirbut ou de cette association est immuable pendant toute la durée de vie de l’objet. Elle doit être définie à la création de l’objet et ne peut jamais être modifiée (tout au long de la vie de l’objet). La valeur initiale peut être « null ». Cela implique que le constructeur contient généralement un argument fixant cette valeur et qu’aucune opération ne la met à jour. On peut appliquer frozen à une classe pour indiquer que toutes les terminaisons d’association et tous les attributs associés à cette classe sont gelés. NB : gelé ne signifie pas « lecture seule ». Les valeurs en lecture seule seront généralement indiquées avec la contrainte { read-only}, qui n’est pas une contrainte UML standard au sens strict. Collections pour les rôles d’assocition multivalués Un rôle multivalué (considéré comme un ensemble) est un rôle dont la multiplicité a une valeur maximale supérieure à 1 (* par exemple). Il est possible d’attacher une contrainte au rôle :

• La contrainte {ordered} : les objet cibles ont un ordre, autrement dit qu’ils forment une liste et n’apparaîtront qu’une fois dans la liste. • La contrainte {bag} : les objets cibles peuvent apparaître plusieurs fois dans la collection, mais ils ne sont pas ordonnés. • La contrainte {hierarchy} : indique qu’ils sont hiérarchisés. • La contrainte {dag} : indique un graphe orienté acyclique.

Associaions qualifiées Une association qualifiée est une spécification en UML qui est équivalente au concept de programmation connu sous le nom de « tableau associatif », de « map » ou encore de dictionnaire. L’exemple : ci-dessous indique qu’une Société ne peut pas avoir deux Employés différents pour le même Matricule .

Du point de vue des spécifications, cette association qualifiée impliquerait une interface telle que la suivante :

class Commande { public LigneCommande getLigne (Produit unProduit) ; public void ajouterLigne (Nombre montant, Produit unProduit) ; …

} Ainsi, tout accès à une ligne donnée nécessite un Produit comme argument. Une multiplicité de 1 indiquerait qu’il doit y avoir une ligne pour chaque Produit, et une multiplicité de * que l’on peut avoir plusieurs Lignes de Commande par Produit, mais que l’accès aux lignes est toujours indexé par Produit. Du point de vue implémentation, cela suggère l’emploi du tableau associatif ou d’une structure de données similaire

class Commande { private Map _lignes ; … }

Figure 31. Associaions qualifiées



� �

Classes association Lorsqu’on veut ajouter des attributs, des opérations et d’autres fonctionnalités aux associations, on fait appel à la notion de classe-association d’UML.

Une autre façon de représenter cette information consiste à faire de Emploi une classe à part entière. Les multiplicités doivent être modifiées en conséquence. Dans ce cas, chacune des classes de l’association d’origine a un rôle monovalué par rapport à la classe Emploi. Le rôle « employeur » est maintenant dérivé, bien qu’il ne soit pas indispensable de le représenter. [Fowler03]

Classe paramétrables Ce concept permet de définir des comportements pour des ensembles, en général en créant une classe patron Set. Plusieurs langages de programmation, particulièrement C++, utilisent la notion de classe paramétrable (« template ») ou de patron (« pattern »).

class Set <T> { void inserer (T nouvelElemnt) ; void supprimer (T unElement) ; … }

Cela fait, vous pouvez utiliser la définition de la classe paramétrable Set pour créer des classes dérivées afin de mémoriser des éléments spécifiques.

Ser <Employe> employeSet ;

Voici le formalisme de representation d’une classe paramétrable en UML:

Le T du diagramme est un paramètre substituable qui représente le type (vous pouvez avoir plusieurs paramètres). NB : Ce concept est inutile dans des langages à typage faible comme Smaltalk, puisque la question ne se pose pas. visibilité Il est possible d’étiqueter tout attribut ou opération par un indicateur de visibilité. Vous employez n’importe quel marqueur, sa signification dépendant du langage. Mais UML fournit trois abréviations : + (public), - (private) et # (protected).

Figure 32. Exemple de Classe-Association

Figure 33. Transformation d’une classe-association en classe à part entière

Figure 34. Classe Paramétrable

Entreprise * Employeur Personne

Emploi Période : IntervalleDate Opération ( )

0..1

Entreprise

Employeur

Personne

Emploi Période : IntervalleDate Opération ( )

0..1 1 1 * * 0..1

Set Période : IntervalleDate Inserer ( ) Supprimer ( )

T

Paramètre de Classe Paramétrable



� �

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

OCL définit plusieurs types de collections d’objets, ainsi que de nombreuses opérations de manipulation de ces collections. « Set » est un ensemble au sens mathématique. L’expression « Colis.anomalieColis » retourne l’ensemble des objets AnomalieColis liés à l’objet Colis concerné. L’opération prédéfinie permet de tester si l’ensemble est vide. A propos de OCL OCL est un langage formel d’expression de contraintes adapté aux diagrammes d’UML (depuis la version 1.1 d’UML), et en particulier au diagramme de classes. Il permet de spécifier des contraintes sur l’état d’un objet ou d’un ensemble d’objets, avec une grammaire élémentaire et accessible (OCL peut être interprété par des outils). OCL limite les ambiguités du langage naturel (bien que lui étant proche), et se rapproché bien du langage technique (langage mathématique, informatique…) Exemple de contrainte :

– invariants sur des classes ; – préconditions et des postconditions à l’exécution d’opérations : – préconditions doivent être vérifiées avant l’exécution, – postconditions doivent être vérifiées après l’exécution ; – gardes sur des transitions de diagrammes d’états-transitions ou des messages de diagrammes d’interaction ; – ensembles d’objets destinataires pour un envoi de message ; – attributs dérivés, etc.

3.5.5.4 La modélisation des comportements Diagramme d’état-transition

• Les diagrammes d'état-transition permettent de décrire les changements d'états d'un objet ou d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.

• Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des attributs d'un objet.

• Une transition représente le passage instantané d'un état vers un autre. • Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui

conditionne la transition. • Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui les déclenche. • En plus de spécifier un événement précis, il est aussi possible de conditionner une transition, à l'aide de

"gardes" : il s'agit d'expressions booléennes, exprimées en langage naturel (et encadrées de crochets).

Figure 35. Exemple de contrainte entre attributs, exprimée en OCL

Vehicule NumImmatriculation Kilometrage Charge EstLibre

est de type

Typeehicule Nom ChargeMax Volume Hauteur / Largeur VitesseMaxVide VitesseMaxCharge

{ Vehicule. Charge <= TypeVehicule. ChargeMax }

* 1



� �

[Nkenlif04]

Figure 36. Un exemple de Diagramme d’états – transitions ( classe ETAPE d’un système séquentiel)

Figure 37. Diagramme d’états concurrents (avec super état)

Cliquer bouton simulation Condition : transition précédente franchie ou pas de transition

Bouton gauche enfoncé

Double cliquer Sélectionner type d’action Saisie paramètres de l’action

X =0 Y= 0 côté = 0 Numéro = 0 active = false Cliquer sur le bouton “ étape ” Changement du pointeur de la souris Cliquer dans la zone de dessin

Entry : X = e.x Y = e.y Côté = valeur numéro = Auto Do : Dessiner ( )

Cliquer sur “ étape ”

Entry : X = e’.x Y = e’.y Do : marquer ( ) On : supprimer ( ) copier ( )

Entry : X = e’.x Y = e’.y Do : déplacer ( )

Do : stockage des paramètres

Entry : active=true Do : activer ( ), executer action ( )

Cond : Transition suivante franchie ou pas de transition

Entry : active = false Do : desactiver ( )

Double cliquer Sélectionner type d’action

Saisie paramètres de l’action



� �

Actions dans un état • On peut aussi associer une action à l'événement qui déclenche une transition.

La syntaxe est alors la suivante : événement / action • Ceci exprime que la transition (déclenchée par l'événement cité) entraîne l'exécution de l'action

spécifiée sur l'objet, à l'entrée du nouvel état. Exemple : il pleut / ouvrir parapluie

• Une action correspond à une opération disponible dans l'objet dont on représente les états. • Les actions propres à un état peuvent aussi être documentées directement à l'intérieur de l'état.

UML définit un certain nombre de champs qui permettent de décrire les actions dans un état : • entry / action : action exécutée à l'entrée de l'état • exit / action : action exécutée à la sortie de l'état • on événement / action : action exécutée à chaque fois que l'événement cité survient • do / action : action récurrente ou significative, exécutée dans l'état

Diagramme d’activité • UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas

d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états-transitions). • Le passage d'une activité vers une autre est matérialisé par une transition. • Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont

automatiques). • En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls

les mécanismes complexes ou intéressants méritent d'être représentés.

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

Figure 38. Diagramme d’activité (illustration de fusion, jonction, débranchement et branchement)

Activité 5 Activité 2

Activité 3

Activité 1

Activité 6

Activité 4

Branchement

Débranchement

Fusion

Jonction

[Sinon]

[Garde : si oui]



� �

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

[Nkenlif04]

Figure 39 Séquencement d’opérations entre les macro-objets d’un système hybride (l’ascenseur)

syshyb1 : Systeme Hybride

Saisie paramètres Demande paramètres

Utilisateur

Clique sur Simuler

inter1 : Interactions

sysseq1 : SSysSequentiel

syscont1 : SSysContinu

Acheminer paramètres

DémarrerSimulateurSeq

DémarrerSimulateurCont

Modifier_TS

Ecrire consigne Vc

Transfert consigne Vc Déterminer A Calculer V Calculer X Ecrire

Vr & Xr TracerCourbe

Afficher Résultats

Transfert de Vr et Xr Si Vr == 2 ms-1 Vc = 2 ms-1 Si Xr == Q Vc = 0

Si Xr == B Envoyer STOP Acheminement

du STOP

Restitution à l’utilisateur

Modifier_TC

Lire consigne Vc

Lire résultats Xr & Vr

Arret Simulation

Tantque simulation Modifier_T



� �

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

[Nkenlif04]

Diagramme de communication :

Figure 40. Un exemple de Diagramme de collaboration : simulation des systèmes continus

Figure 41. Exemple de diagramme de communication

Fonction de transfert

Equation différentielle Polynôme

Consigne

Perform Rep_lib

Cal_sol

3.Résolution()

1. paramètres

2. p

ara

mè

tres

simuler

5. fo

nctio

n() 6. réponsef ()

4. m

atrice

()

7. dériver ()

8. solutions

9.

10. tracer() 11. afficher ()

10. tracer()

2. résoudre

simuler

1. convertir ()

Lorsque le choix se porte sur la fonction, la simulation se résume à convertir la fonction et à appeler la résolution de l’équation qui est décrite ci-dessus

9. stabilité ( ) rapidité ( ) précision ( ) erreur ( ) 10. solutions

solutions

10



� �

3.5.5.6 La modélisation des composants • Les composants sont les unités physiques de code (source, objet, bytecode, exécutables, etc.) qui sont assemblées

pour former des applications. Les classes sont affectées à des composants fournissant des briques réutilisables pour la construction des applications. Ces composants formeront la base d’une architecture d'application plug-and-play.

• La réutilisation dans le langage UML intervient avant la compilation sous forme de classes réutilisables ou de frameworks et après la compilation sous la forme d'assemblage de composants.

• Le diagramme de composants montre la mise en oeuvre physique des modèles de la vue logique avec l'environnement de développement.

• Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.

• Le composants peuvent être organisés en paquetages, qui définissent des sous-systèmes. Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. Ils permettent de gérer la complexité, par encapsulation des détails d'implémentation.

3.5.5.7 La modélisation de la distribution et du déploiement • La modélisation de déploiement permet de représenter la façon dont l'application est distribuée dans un réseau. Elle

montre la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels.

• Différentes topologies de réseau peuvent être modélisées. Par exemple les architectures client/serveur, trois-tiers ou Internet/intranet. UML permet de décrire la topologie des nœuds dans le réseau, la façon dont ces nœuds sont connectés et la manière dont l'application est partitionnée et distribuée sur ces nœuds. • Les ressources matérielles sont représentées sous forme de noeuds. • Les noeuds sont connectés entre eux, à l'aide d'un support de communication.

La nature des lignes de communication et leurs caractéristiques peuvent être précisées. • Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel précis), ou des classes

de noeuds. • Les diagrammes de déploiement correspondent à la vue de déploiement d'une architecture logicielle

Figure 42. Exemple de Diagramme de composants



� �

[Fowler03]

3.5.5.8 Diagramme de packages

Figure 43. Diagramme de déploiement

Figure 44. Dépendance, note

Nom de parquetage 1

Dépendance (nommage optionnel)

Stéréotype Nom de Paquetage 2

Note textuelle (contrainte textuelle



� �

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



� �

44 MM DDEE :: MM ooddeell DDrr iivveenn EEnnggiinneeeerr iinngg La maîtrise d'un projet informatique peut nécessiter un savoir de plus en plus vaste dans différents domaines (logiciels, langage(s), code, APIs, ...). Nous allons présenter le Développement Orienté Modèle (MDD - Model Driven Development, ou MDE - Model Driven Enginering), tel qu’il est spécifié par l’OMG (Object Management Group). Ces spécifications sont regroupées sous le concept de MDA (Model Driven Archtecture), et mettent à disposition de nombreux outils conceptuels.

4.1 Évolutions L’OMG (Object Management Group) est un consortium développant et promouvant la théorie et la pratique des objets distribués. Il est constitué de plus de 1000 structures membres. Il a proposé dès le début des années 90, l’architecture OMA (Object Management Architecture), qui comprend des produit et standards/documents qui définissent les mécanismes d’interopérabilité, de distribution et de communication dans un réseau. Les standards de réalisation étant CORBA (Common Object Request Brokers Architecture), UML (Unified Modeling Language), MOF (Meta Object Facilities et XMI (XML Metadata Interchange). MDA (Model Driven Architecture) est une extension de OMA pour faire évoluer et généraliser cette interopérabilité le long de tout le cycle de vie du logiciel (conception, déploiement, maintenance). L’idée principale ici est d’arriver à la séparation entre les spécifications des fonctionnalités et la caractérisation de ces fonctionnalités pour une plateforme spécifique.

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

On a failli assister à une « Mort » des logiciels due à de multiples difficultés : ● Lors de l'évolution ● Ajouts de fonctionnalités ● Correction de bugs ● Trop de rustines (« bug patch ») ● Application ● Peu cohérente ● Peu compréhensibles ● Evolution difficile

Ces difficultés ont amené à proposer le concept de modèle : ● Modèles plus aptes ● Visibilité bonne ● Donc compréhension aisée

MDE est-il un moyen d'éviter la « mort » des logiciels ? Nous présentons ci-dessous, l’évolution d’approches du génie logiciel vers l’ingénierie des modèles.

Figure 45. Evolution des approches du Génie Logiciel sur le plan historique



� �

Cette évolution tient compte de nombreux besoins et contraintes : ● Au niveau du contrôle de la conception ● Le niveau code entraîne des difficultés ● Les Modèles facilitent le développement, tout en donnat une meilleure visibilité. Il existe aussi une possibilité de validation formelle sur les modèles. Ex : langage OCL (Object constraint language)

● Au niveau de l’évolution ● Visibilité de l'application ● Visibilité des modifications ● Modèles génériques ● Réutilisables

● Au niveau du cycle de vie ● Prototypage rapide ● Concentration sur ● Conception globale ● Conception unitaire ● Développement minimal ● Evolution

● Au niveau de la modélisation ● Diagrammes de classes ● Abstraction ● Fonctionnalités, systèmes, etc. ● Classes du programme final ● Intégration des « design patterns »

4.4 MDE et UML Les objectifs de MDE (Model Driven Engineering), dont MDA est une spécification particulière, sont triples :

1. Séparation de descriptions fonctionnelles et de l’implémentation, 2. Identification, expression précise, séparation et combinaison des différents aspects d’un système (à l’aide d’un langage spécifique de domaine), 3. Relation entre ces langages de domaines dans un « framework » global.

L’idée de MDE c’est de concevoir un paradigme paliant aux insuffisances du paradigme Objet, qui s’est imposées en génie logiciel depuis les années 1980. Ce paradigme n’est pas ammené à remplacer l’approche Objet, mais à la compléter.

• L’approche UML et le développement Objet considère que « Tout est Objet ». Les relations fondamentales qui y sont mises en oeuvre sont l’héritage (d’une super-classe par une classe simple) et l’instanciation (d’une classe par un objet).

- Modélisation - Représentation des classes, etc. - Possibilité de génération de code - Statique

• L’approche MDE considère elle que « Tout est modèle ». Les relations fondamentales sont la représentation (du système

par le modèle), et la conformité (du modèle à un méta-modèle). - Méta-modélisation - Représentation de l'application

- A différents niveaux d'abstraction : système, fonction, classe - Dissociation des aspects indépendants - Interaction utilisateur-système, architecture, plate-forme, etc

Figure 46. Rappel du Cycle de vie (basé sur les modèles)



� �

- 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

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

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.

Figure 47. Comparaison des approches Classes et Modèles

Figure 48. La méta-programmation



� �

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

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.

Figure 49. Eléments de MDA



� �

Un processus de génie logiciel exploitant les possibilités de MDA a cependant été proposé : le « Model-Driven Software Development » - MDSD ([wwwMDA06]). 4.6 Technologie MDE . MDE engloble toute cette nouvelle approche d’ingénierie dont la conception d’ensemble est orientée modèles. Les Spécifications de MDE s’appuient sur :

- la technologie MDA - les autres technologies connexes :

o UML , largement utilisé par ailleurs, qui permet une mise en oeuvre aisée de MDA en offrant un support connu,

o XMI , XML Metadata Interchange, qui propose un formalisme de structuration des documents XML de telle sorte qu'ils permettent de représenter des méta-données d'application de manière compatible,

o MOF , Metadata Object Facility, spécification qui permet le stockage, l'accès, la manipulation, la modification, de méta-données,

o CWM (Common Warehouse Metamodel), base de données pour méta-données. L’intérêt de MDE c’est d’aider les utilisateurs à résoudre les problèmes d’intégration en fournissant des spécifications d’interopérabilité ouvertes et indépendantes des vendeurs. En effet, les avantages que retirent les entreprises sur le MDE sont principalement

• le fait qu'une architecture basée sur MDA est prête pour les évolutions technologiques. • la plus grande facilité d'intégration des applications et des systèmes autour d'une architecture partagée. • une interopérabilité plus large permettant de ne pas être lié à une plate-forme.

4.6.1 Principe de MDE MDE exige plusieurs principes : - séparation entre la Description de l'application et la Description du contexte technique (architecture et

plateforme). - Réunion des modèles et/ou transformation - Génération de code

L’idée de base de MDE est la suivante : penser l'application au niveau du modèle et laisser le soin de l'implémentation aux outils. Ce paradigme est omniprésent en informatique : les langages nous ont affranchi des processeurs et ils nous affranchissent maintenant des systèmes d'exploitation. Pour le dire brièvement, l'interopérabilité prend de la hauteur. MDE préconise l'interopérabilité au niveau des modèles. Il s'agit d'avoir la possibilité d'écrire et de faire évoluer le modèle en fonction de l'organisation à la vitesse requise par l'organisation et non plus par les plateformes.

- Au niveau de l'organisation on parle de PIM ; - Au niveau des plate-formes, de PSM.

Une application complète de MDA se composera donc d'un PIM et d'un ou de plusieurs PSM. A titre d’exemple, on retrouve à un niveau d'abstraction supérieur la démarche qui avec le même langage Delphi permet d'obtenir par la CLX (Component Library X(cross)-Platform, - "Bibliothèque de composants multi-plateformes") un exécutable qui pourra faire appel aux API (Application Programming Interface) Windows ou à Linux, avec le même source. Le langage de choix dans lequel écrire le MDA est UML. C'est en effet un standard depuis son adoption par l'OMG en 1997. L'application sera ensuite implémentée sur un large éventail de systèmes : des ordinateurs de bureau, aux serveurs, aux mainframes et au travers d'Internet. Les PSM peuvent communiquer entre eux en faisant intervenir plusieurs plateformes qui ont à échanger des données : le développement de CORBA continuera d'être favorisé par l'OMG dans ce sens. La demande croissante des utilisateurs en temps réel, en système embarqué, en système tolérant et en systèmes d'entreprises va accélérer le rythme de standardisation de CORBA. Les services de CORBA permettront de synchroniser rapidement quatre services dominants identifiés par l'OMG dans le MDA :

• Services d'annuaire • Services de Transaction • Services de sécurité • Services distribués d'événement et d'avis D'autres viendront s'ajouter à cette liste.

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



� �

• MDA : PIM vers PSM [wwwMDASup]

PIM: Plateform Independent Model PSM: Plateform Specific Model

4.6.2 Description des deux catégories de transformations : • Les transformations « modèle à modèle » Elles sont indispensables en cas de grande distance conceptuelle entre le PIM (indépendant de la plateforme) et le PSM (spécifique à la plate-forme). Elles peuvent être réalisées :

– par manipulation directe (implémentation et ordonnancement des règles par l’utilisateur), – de manière relationelle (basé sur des concepts mathématiques, des règles de mapping), – orienté transformation de graphe, – orienté structure (2 phases, création de la structure de la cible, et complément avec les attributs et les références), – hybride, association de plusieurs des catégories précédentes. • Les transformations « modèle à code » Les transformations modèle à code sont de types « visitor-based » (mécanisme qui traverse la représentation du modèle), ou « template-based » (texte cible contenant du métacode pour accéder aux informations de la source).

Apport de transformations : Classification des transformations, Identification de leurs caractéristiques. Contraintes à prendre en compte lors des transformations : Mise en évidence du manque de maturité des transformations.

4.7 MDE et les « Design Patterns »

• Le patron logiciel : Le schéma logiciel, associé à des processus de capture et d’exploitation des informations décrites, et à des outils pour automatiser ce processus, forment le patron logiciel (patern).

• L’usine logicielle : Le patron logiciel, intégré à un Environnement de Développement Intégré (IDE), forme une usine logicielle. L’usine logicielle et l’ensemble de ses composants met à disposition du développeur un cadre de travail performant, peu cher, et surtout, offre tous les outils nécessaires à un développement rapide de nouvelles applications.

Apport de patron : Grille d’analyse et identification des éléments indispensable à l’automatisation d’un processus MDA. Contraintes à prendre en compte : Le contenu de la grille doit être réalisé à la main, lors de la création de l’usine logicielle. La productivité n’est atteinte que lorsque que cette étape préliminaire est achevée.

L’intégration des Design Patterns (patron) dans MDE est effective aujourd’hui. ● Modèles pré-existants

- Déjà validés - Facilitent la modélisation

● Manipulation simple des modèles - Réutilisation - modifications

Figure 50. ·MDA : PIM vers PSM

PIM

CODE

PSM



� �

4.8 Processus MDE Le principe est illustré à la figure ci-après.

[Parrend07]

● Modification des modèles

Elle s’opère grace à leur description précise : - Langage de domaine - Formalisé

● Les transformations possibles sont présentées à la figure ci-dessous.

[Parrend07]

4.8.1 Langages de modèles Les méta-modèles sont exprimés couramment sous format XMI . Ils peuvent représenter un langage connu, par exemple Java ou UML. Ils peuvent également être conçus spécifiquement pour un domaine d'application donné. Deux approches existent pour créer un langage de méta-modèle :

• MOF : On crée à partir de rien un langage nouveau, en respectant les spécifications du MOF (Meta Object Facility),

• UML : On crée une extension d'UML, à l'aide de stéréotypes, de contraintes (langage OCL). IV-A-1 - Les niveaux de méta-modèles On définit quatre niveaux de méta-modèles : [Parrend07]

- le niveau zéro est l'implémentation du programme, - le niveau 1 est le modèle du programme (classes) - le niveau 2 est le méta-modèle du programme, c'est à dire le langage - le niveau 3 est le méta-modèle des méta-modèles, ou méta-méta-modèle, c'est à dire la définition d'un méta-

modèle. Il s'agit donc de la spécification MOF.

Figure 51. Processus MDE

Figure 52. Les Transformations MDE



� �

● Architecture

4.8.2 Étapes de développement MDA Plusleurs phases et transformations sont définies pour un processus MDA :

- Proceder à la modélisation (normalement en UML) : des modèles manipulables sont générés (au format XMI), en partant des diagrammes de classes UML

- Proceder aux transformations intermédiaires On devra progréssivement préciser ici ce que sera l’application en terme de format de données, réalisation de fonctionnalités. On pourra donc transformer les métamodèles initiaux (indicant les contraintes que doit respecter l’application) en modèles fonctionnels cibles dotés de services particuliers.

- Proceder à la génération de code. En ce qui concerne le stockage et l'accès, les modèles, MOF permettra de définir des bases de données de modèles accessibles de manière transparente par les applications.

● Les transformations s’opèrent à la chaîne

[Parrend07]

Plusieurs outils peuvent êre mis en jeu durant le processus : ● Plateforme Eclipse: incluant Eclipse, EMF (Eclipse Modeling Framework), SDO (Service Data Objects) et XSD (XML Schema Infoset Model).

SDO permet d'unifier l'accès à des données hétérogènes, par exemple stockés sous forme XML, en Base de Données Relationnelle, dans des Services Web, par les applications. XSD est une librairie qui permet de manipuler, créer et modifier des schémas XML.

Pour créer un modèle EMF (au format « Ecore »), plusieurs formats de fichiers sont supportés : 1 Java Annoté 2 XML Schéma 3 Format Rational Rose

Figure 53. Architecture du métamodèle MDA

Figure 54. Chaaîne de transformations : processus



� �

Voici les opérations lors du processus pour un développement incrémental :

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

● Poseidon : nous listons ci-dessous les différentes transformations réalisées dans un processus intégrant l’outil Poseidon :

* Création de modèles UML, * Ajout des commentaires Javadoc dans le modèle UML, * Sauvegarde de votre modèle, * Exportation en tant que Classe Java (les diagrammes de classes sont exportés, les autres existent uniquement à fin de documentation), * Exportation sous format XMI, * Exportation en tant que graphique (si besoin), * Lancement de la plate-forme Eclipse, et importation du fichier XMI créé.

* Réalisation de programme exécutable

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

4.9 Méthodologie globale de réalisation d’applications Au niveau du processus de développement, le MDE doit apporter des gains de productivité et des gains de prédictabilité [Greenfield03]. Pour exploiter au maximum ces possibilités, il est indispensable de systématiser les méthodes de développement logiciel, et donc de les industrialiser : c’est ce qui est appelé ici « l’usine logicielle ». L'usine logicielle comprend : ● IDE (Environnement de développement intégré) et outils ● Patron logiciel, lui-même composé de

- Outils de manipulations - Schéma logiciel, comprenant :

o Langage de descriptions de modèles � Domaine, Services, Technologies, Données � Niveaux : Concepts, logiques, implémentation

o Transformations entre ces langages

Figure 55. Les outils dans la chaîne de transformations



� �

Le processus complet est présenté à la figure ci-dessous

Une méthodologie de référence est véritablement nécessaire pour rendre MDA réellement opérationnel. Nous présentons ci-dessous, une méthode de développement d'application correspondante. Elle a pour vocation d'améliorer la productivité, c'est à dire le temps de création de la première version de l'application, de même que l'évolutivité, c'est à dire la possibilité d'améliorer et d'étendre cette application. On distinguera deux approches : [Parrend07]

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

4.9.1 Approche linéaire Phase de spécifications - choix des principes de l'application (et donc des modèles) - adaptation de ces modèles - validation de l'architecture au niveau fonctionnel

Phase de design - raffinement automatique (intégration de modèles existants) - raffinement manuel

Phase d'implémentation - génération de code pour la plate-forme-cible - complétion du code généré - intégration d'outils pré-existants

Phase de validation - bon fonctionnement de l'application - validation des spécifications

Figure 56. Exemple de schéma de support du processus MDE

Figure 57. Processus complet MDE



� �

4.9.2 Approche incrémentale Cette approche met en évidence la puissance de MDA. L'évolution permanente du logiciel est intégrée dans la méthodologie de développement, ce qui a deux avantages principaux :

+) lors de la première réalisation d'une application, des versions fonctionnelles intermédiaires sont disponibles, ce qui permet d'accélérer la mise en production - éventuellement d'une version incomplète, préférable à un retard pur et simple, +) lors de l'évolution d'une application, la méthodologie est conservée, et la validation est donc facilitée.

* Prototype Réalisation d'une architecture comportant les fonctionnalités minimales (IHM et fonctionnalités clés) selon la méthode linéaire.

* Architecture complète Intégration des différents principes de fonctionnement : type de client (lourd/léger), support de mobilité, etc., selon la méthode linéaire. On obtient un squelette d'application, comportant tous ses éléments, mais sans implémentation.

* Mise en place des fonctionnalités Compléter chaque fonctionnalité l'une après l'autre, selon la méthode linéaire.

* Récursivité Les étapes 2, 3 peuvent être réalisés par suite d'affinements successifs. Chaque affinement doit permettre de nouveaux types d'usage (extension des fonctionnalités), les version intermédiaires doivent être exploitables.

* Validation de la version finale * Evolutions

Elles peuvent se faire selon le même principe que les affinements succesifs ayant conduit à la version complète du produit.

4.10 Perspectives de développement

4.10.1 Les Mégamodèles MDA effectue un glissement des abstractions utilisées comme unité de base du développement logiciel de l’objet vers le modèle. Son objectif est de préciser comment définir des modèles, leur expression, et leurs transformations. Cependant, aucune spécification n’est prévue pour le maintien de lien entre modèles. Nous l’avons vu avec les nouveaux processus de développement proposés par [Greenfield03], un modèle ne permet un gain de performance que dans un schéma où il est en liaison avec un ensemble d’autres modèles. [Bezivin04] propose, pour palier à cette lacune, l’introduction de « mégamodele », qui supportent non seulement le stockage et la capitalisation des savoirs, comme les Bases de données MOF (MOF Repositories), mais également l’extension de ces modèles par des liens. Il devient alors possible d’avoir une vision macroscopique des modèles, et non plus d’en avoir une juxtaposition. Les informations utiles concernant un méta-modèle sont, entre autres :

– lieu ou se trouve sa définition originale, – définitions alternatives, – auteurs, – histoire, – versions suivantes et précédentes, – PSM existants s’il s’agit d’un PIM.

Les éléments du méga-modèle sont : 1. les modèles, méta-modèles et méta-métamodèles, 2. les services, 3. les outils.

L’introduction de ces informations vise à une meilleure interopérabilité entre les outils, et donc les phases de conception. L’implémentation peut avoir lieu sous forme de « bus logiciel », ou dans un réseau pair-à-pair. La principale approche concurente est KDM (Knowledge Discovery Metamodel), de l’OMG. La capitalisation des modèles, et leur exploitation performante suppose une vision macroscopique des éléments disponibles. L’approche Méga-modèle semble très prometteuse, mais aucune implémentation n’est disponible librement actuellement. Comme intérêt, on peut noter la capitalisation des modèles et de leurs liens avec les autres éléments mis en oeuvre dans le processus de développement.

4.10.2 La Modularisation des Applications La formalisation des processus de développement rend possible la création d’usines logicielles, nous l’avons vu dans la partie correspondante. Cette évolution peut entrer dans un cadre beaucoup plus vaste, qui modifierait les méthodes



� �

utilisées dans les entreprises, et offrirait la possibilité de rendre les applications modulaires, et par conséquent leur génération [Greenfield03]. L’auteur propose de s’inspirer des processus de l’industrie traditionnelle :

– assemblage de composants standards – produits finaux similaires mais distincts – standardisation – intégration – automatisation – chaine logistique distribuant le risque et les coûts dans un réseau de fournisseurs spécialisés et interdépendants

Une telle organisation doit permettre un fort gain par économie d’échelle. Au niveau du développement logiciel, elle se traduit par une application systématique de MDA, et un enregistrement systématique des connaissances quand à une famille de produits. Ces connaissances sont mises à disposition sous forme de « pattern », de « framework », de « modèles », et « d’outils ». Le développement doit ainsi êetre axé vers la connaissance du domaine d’application, plus que vers la connaissance de la plate-forme cible. La présence d’usines logicielles, qui permettent un developpement peu onéreux, offre la possibilité de mise en place de véritables chaines de production de logiciels. Ces chaines de production sont composées de plusieurs usines indépendantes, effectuant chacune une partie du processus, fournissant les composants ou les intégrant. Cette modularisation extrême, où tout service peut être disponible indépendamment des autres, doit offrir de forts gains de productivité et une forte variabilité des applications finales. Il s’agit d’une vision à long terme, qui ouvre des perspectives méthodologiques immédiates. Comme intérêt, cette Méthodologie de conception logicielle est innovante.

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



� �

55 LL eess mméétthhooddeess AAggii lleess Les projets informatiques possèdent de plus en plus des aspects très complexes. Ceci est du à plusieurs facteurs :

- la "taille" du projet, - la "complexité" du système étudié (comportement, structure), - « l'hétérogénéité » du projet (plusieurs systèmes d'exploitation, intégration de bases de données, systèmes en

réseaux, ...). - ...

Ces facteurs sont en quelque sorte intrinsèques aux projets et participent d'une "manière fixe" à la complexité perçue. Pourtant, cette dernière est aussi d'essence subjective dépendant directement du "savoir" et de la compétence du modélisateur Du fait de la densification des moyens et des outils mis à disposition, la maîtrise d'un projet informatique peut nécessiter un savoir de plus en plus vaste dans différents domaines (logiciels, langage(s), code, APIs, ...) . Dans le cadre de l’Ingénierie des logiciels, deux « écoles » s’affrontent actuellement :

• Ingénierie basée sur les modèles ou Model-Driven, préconisée par l’OMG (consortium composant plus de 1000 sociétés), s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète en effectuant plusieurs transformations successives.

• Ingénierie basée sur les méthodes agiles, qui met plus d'accent sur la production rapide de code opérationnel que sur la documentation, ce qui minimise la modélisation en amont.

5.1 Historfique des méthodes agiles : Les méthodes dites Agiles ont été créées notamment suite à un nombre trop important d’échecs dans les projets. Historiquement, on peut citer le modèle en spiral, créé par Barry W. Boehm pour le développement logiciel. Il se base sur des phases itératives. Ce modèle a notamment influencé l’Extreme Programming (XP) par la suite. Dans le début des années 1980, James Martin, s’appuyant sur cette vision d’une évolution continue, proposa une méthode de développement rapide d’application (le RAD). Elle a été reprise par la suite en 1991, par Jean Pierre Vickoff, pour l’adapter au système français (RAD2). Elle repose sur un cycle de développement en cinq phases :

• Initialisation pour définir le périmètre fonctionnel et le plan de communication • Cadrage pour la définition des objectifs et des moyens à allouer au projet. • Design avec notamment la présentation générale de l’application. • Construction, phase pendant laquelle le produit sera construit module par module avec une validation

permanente de l’utilisateur pour les spécifications et les différents prototypes. • Finalisation, avec la recette et le déploiement du livrable.

Dès 1994 Jennifer STAPLETON, en Grande-Bretagne, présentait DSDM, équivalente au RAD2. DSDM est souvent considérée comme la première méthode Agile et, dans la seconde moitié des années quatre-vingt-dix, une vague d’une dizaine de méthodes dont « Extreme programming » et « Scrum » sont les principales représentantes, développa encore les techniques adaptatives d’estimation, de planification et de pilotage de projet. Les méthodes agiles sont constituées d’un ensemble de méthodes qui ont un seul objectif : satisfaire le client. C’est dans cette optique qu’en 2001 aux Etats-Unis 17 grands noms du développement logiciel se sont réunis. Parmi eux on peut citer Ward CUNNINGHAM l'inventeur du Wiki, Kent BECK, père de l'Extreme Programming et coauteur de JUnit, Ken SCHWABER et Jeff SUTHERLAND, fondateurs de Scrum, Martin Fowler avec la sociétés « Thought Works » et le serveur d’intégration continue Cruise Control. Ces 17 personnalités qui viennent toutes d'horizons différents ont réussies à extraire de leurs concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels. A l’issue de cette réunion est né le « Manifeste Agile », considéré comme une définition du développement Agile et de ses principes. Il contient les quatre valeurs fondamentales ainsi que les treize principes de fonctionnement.

5.2 Les principes agiles L’idée de base est de faire face efficcement aux multiples problèmes de lourdeur et parfois d’imprécision dans la gestion des projets ; ou encore un cahier des charges figé dont les exigences ont évolué au cours de l'élaboration du projet. L’objectif principal ici est de satisfaire le client, et non un contrat établi préalablement. Pour réduire ce risque de fossé au stricte minimum, les méthodes agiles prônent l'incrément et l'itération . Nous citons ici les quatre principes fondateurs d’agile : [Scott02] [ROQUES07]

• 1- Priorité aux personnes et aux interactions par rapport aux procédures et aux outils … • L’accent est mis sur les individus, leur expertise, l’esprit d’équipe plutôt que sur les processus et les outils Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne



� �

brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus prolifique et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes d'un même problème.

• 2- Priorité aux applications fonctionnelles opérationnelles par rapport à une documentation pléthorique • On privilégie le code testé Les processus lourds génèrent une documentation exhaustive avec tous ses inconvénients : ambiguïté du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.

• 3- Priorité à la collaboration avec le client par rapport à la négociation de contrats • Le client devient un partenaire qui participe au projet pour donner régulièrement son feedback Le but d’un projet est de gagner de l’argent aussi bien pour le client que pour le fournisseur. En négociant un contrat chaque partie se protège plus ou moins des risques financiers, mais les projets peuvent échouer à tout moment si les délais sont non respectés ou bien les budgets insuffisants. La conséquence n’est pas compliquée. Le client et le fournisseur se retrouvent alors devant un procès où finalement tout le monde est perdant puisque le client ne peut avoir son logiciel et le fournisseur risque tout simplement de faire faillite selon l’importance que le projet avait. Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun pour réussir le projet, c’est une relation gagnant / gagnant

• 4- Priorité à l’acceptation et la réactivité au changement par rapport à la planification • Le planning est flexible pour accepter les modifications nécessaires Comme on l’a vu dans les chapitres précédents lorsqu’un plan est défini l’équipe essaie de s’y tenir et ne fait pas attention aux évènements extérieurs qui peuvent arriver à tout moment du projet. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est réactif aux changements des marchés et s'assure en plus que le logiciel développé est parfaitement conforme à ses véritables besoins. Nous présentons ci-dessous, les champs de valeurs des méthodes agiles par rapport aux autres méthodes (classiques).

Figure 58. Classification des valeurs des méthodes agiles et classiques



� �

Le terme AGILE regroupe un ensemble de méthodes, parmi lesquelles XP (eXtreme Programming). Ces méthodes éssayent aussi d’assembler des atouts majeurs des approches RUP (Rationl Unified Process) et RAD (Rapid Application Development), tout en gardant une une souplesse de planification et d’adptation au changement.

5.3 « Modélisation agile » des projets Les méthodes agiles placent justement l’agilité au centre de l’innovation. En plus, elles mélangent différentes approches de management (travail en binôme, responsabilité collective…) et libèrent la créativité tout en garantissant réalisme et conformité. Issues de l'observation pragmatique de la vie des projets informatiques et se basant sur le partage des responsabilités, les méthodologies agiles évitent de s'encombrer de ce qui n'est pas nécessaire, « coupant » ainsi les coût. Ainsi la documentation sera limitée au strict minimum, le code faisant référence, les tests prennent une importance capitale et tout est fait pour faciliter un dialogue simple et direct. Nous listons ici quelques uns des principes fondamentaux :

- Avoir une culture de la qualité, préventive, pas réactive : Donc, éliminer les « bugs » à la source, le plus tôt possible. Le "test drived development", les revus par les pairs, la conception commune sur tableau blanc, une souplesse.

- Avoir en vue le gain pour le client, garder la souplesse et livrer le plus vite possible ce qui a de la valeur. - S'adapter en tout temps aux circonstances, être adapté et évolutif. Rester souple. - Réduire les pertes le plus possible. Est-ce que tel document est vraiment utile? Est-ce que cette fonctionnalité a

vraiment une valeur ? - Il faut également un changement de mentalité de la part des participants. Ils doivent avoir deux préoccupation

à cœur, tout les jours : livrer et améliorer ses façons de faire, tout les jours. Les méthodes agiles privillégient le développement à itération courte (XP, Scrum, Lean ...) La « modélisation agile » est promue par Scott Ambler [Scott02], qui adapte les valeurs de XP à la modélisation. Les mots clés de la modélisation agile sont :

· Communication · Simplicity · Feedback · Courage · Humility

Les clés d’une modélisation réussie consistent à promouvoir une communication efficace entre tous les participants du projet, de se forcer à développer la solution la plus simple possible qui satisfasse tous les besoins, à obtenir des retours rapides et fréquents, à avoir le courage de prendre des décisions et à s’y tenir, et à avoir l’humilité de reconnaître qu’on ne sait pas tout et que les autres ont une valeur à apporter à ses propres efforts. Les méthodes Agiles sont conçues pour s’adapter au changement. A partir des valeurs fondamentales décrites au paragraphe précédent, ont été déterminés treize principes clés décrits dans le « Manifeste Agile ». Nous les listons ci-dessous :

Figure 59. Histogramme de mise en perspective des méthodes agiles, RUP et RAD



� �

• Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions opérationnelles de l’application, source de valeur. • Accepter le changement dans les exigences, même tard dans le cycle de vie, pour garantir la compétitivité du client. • Livrer le plus fréquemment possible des versions opérationnelles, avec des itérations allant de deux semaines à deux mois, avec une tendance pour la période la plus courte. • Clients et développeurs doivent coopérer quotidiennement tout au long du projet. • Bâtir des projets autour d’individus motivés. Leur donner l’environnement et le support dont ils ont besoin et leur faire confiance pour remplir leur capacité à réaliser le travail. • La méthode la plus efficace de transmettre l'information est une conversation en face à face. • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. Les méthodes agiles recommandent que le projet avance à un rythme soutenable • Sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment. • Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. • La simplicité - l'art de maximiser la quantité de travail à ne pas faire est essentielle. • Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent. • À intervalle régulier, l’ensemble de l’équipe s’interroge sur la manière de devenir encore plus efficace, puis ajuste sont comportement en conséquence.

Les principes de la modélisation agile sont issus des principes XP.

[Scott02]

La pratique de agile est également issue en partie de XP.

Agile s’apuie à la fois sur XP et SCRUM.

- XP apporte une capacité à unir l’effort de deux personnes lorsque des points durs, techniques ou fonctionnels, sont à résoudre rapidement pour le bien du projet.

- SCRUM apporte l’agilité nécessaire à l’accueil favorable de tout changement, à l’ajustement rapide des objectifs projet et des pratiques, ainsi une bonne collaboration et communication avec le client s’en suit.

Figure 60. Principes de la modélisation agile

Figure 61. Pratiques de la modélisation agile



� �

[Schwaber04]

Craig Larman et la modélisation agile Craig Larman, spécialiste de la modélisation agile dit ceci :

- Ne modélisez pas seul ! La modélisation doit être collaborative et participative

- Des outils simples qui encouragent la créativité Larman encourage l’utilisation de feutres et paperboards, plutôt que de progiciels couteux et lourds

- Des modèles multiples et en parallèle Par exemple « diagrammes de classes » et de « séquence » pour faire une esquisse de conception objet

- Les modèles ne sont pas de la documentation! Nous modélisons pour avoir une conversation ensemble et pour développer une compréhension commune

- Tout modèle est faux ! Et c’est OK Par cet aphorisme provocant, Larman veut mettre l’accent sur l’aspect provisoire des modèles, le seul modèle qui fait foi à la fin du projet, c’est le code !

The code is the model!

Figure 62. Processus de développement utilisé (SCRUM)



� �

L’organisation de la modélisation agile selon Larman peut être représentée ainsi :

[Craig03]

5.4 Test-Driven Requirements (TDR) La gestion des exigences dirigées par les tests, ou Test-Driven Requirements (TDR), représente l’étape ultime dans l’adoption d’un processus de développement dit « lean » (dérivé de la méthodologie "Toyota Way"). Les pratiques du TDR trouvent leur source dans la transposition du « lean thinking » au monde du développement logiciel.

5.4.1 Lean sofware development Les principes du « lean thinking » ont été transposés au monde du développement logiciel par les travaux de nombreux experts en développement informatique, les contributeurs les plus importants et les plus reconnus étant les époux Poppendieck (http://www.poppendieck.com/). Principes du Lean : - Eliminer les gâchis : tout le lean thinking est orienté vers l’élimination des gâchis. Dans le monde du développement logiciel, les gâchis sont de plusieurs sortes : fonctionnalités non nécessaires, stocks d’exigences en attente de développement, anomalies non détectées, tests de non-régression manuels, temps d’attente, multiplication des intermédiaires et des échanges formels entre ces intermédiaires, perte d’information, etc. - Qualité intrinsèque : l’objectif est d’éliminer les défauts le plus tôt possible et de faire en sorte que les défauts ne puissent pas se produire. - Livrer rapidement : réduire ses délais de développement pour rapprocher le plus possible le moment d’une demande d’évolution de sa livraison. - Respecter les personnes : d’une part se concentrer sur les personnes qui apportent directement de la valeur pour le client, d’autre part accueillir les idées d’amélioration de chaque personne impliquée dans le processus et pas simplement du top-management ou d’un groupe d’experts.

5.4.2 Les étapes d’une évolution « lean » L’organisation classique des activités d’ingénierie logiciel (activités d’ingénierie logiciel successivement réalisées, que ce soit au sein d’un cycle en cascade, ou au sein d’une itération) est caractéristique d’une approche prédictive du développement logiciel et donc à l’opposé d’une organisation « pull » préconisée par le lean-thinking. Cependant, l’émergence des pratiques agiles au sein des maîtrises d’oeuvre ont permis aux développeurs d’organiser plus efficacement leur travail avec le Test-Driven Development, dit TDD, et d’améliorer fortement la qualité du code. Le principe du TDD est qu’aucun code n’est produit tant qu’un test unitaire n’a pas échoué. Cette approche illustre parfaitement la mise en application du lean thinking au monde du développement logiciel : l’étape de codage ne produit rien tant que l’étape de test unitaire ne le demande pas. Nous avons ici un fonctionnement parfait en mode « pull ». C’est l’écriture d’un nouveau « test unitaire » qui va déclencher l’écriture de nouveau « code ». La mise en oeuvre du lean thinking revient à fusionner les étapes de codage et tests unitaires pour donner naissance à une étape de TDD.

Figure 63. Modélisation de projet selon Craig Larman



� �

La figure ci-dessous illustre ainsi l’organisation des nombreux projets d’aujourd’hui ayant entrepris le déploiement de méthodes agiles.

[MANTEL07]

Le processus schématisé à droite illustre une organisation lean, dans laquelle le client « tire » les fonctionnalités de la première cellule, plutôt que de les pousser dans la chaîne de production et d’attendre qu’elles soient réalisées. Le TDR est donc l’aboutissement d’une démarche de changement de ses pratiques vers un processus lean.

5.4.3 TDD (Test Driven Development) et TDR (Test Driven Requirement) Le test-driven development est une pratique agile issue de l’Extreme Programming, dit XP. Les trois étapes du TDD sont les suivantes :

1. Ecrire un test et s’assurer qu’il échoue, cela permet de garantir l’intérêt du test unitaire 2. Ecrire le minimum de code qui va faire réussir le test 3. Améliorer le code en s’assurant que le test continue de réussir Revenir à l’étape 1 avec un nouveau test unitaire

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

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

5.4.3.2 Des spécifications exécutables D’après la société Valtech, la pratique du FTDD n’est pas suffisante si l’on veut obtenir un processus lean, et que l’on peut pousser encore plus loin l’intégration des activités de spécifications et des tests. FIT permet en effet d’ignorer le texte d’une page web et de n’utiliser que les tableaux marqués comme étant des tests. Il est donc possible de créer des pages web qui contiennent du texte libre, par exemple des règles de gestion, et contiennent des tableaux de tests, par exemple les tableaux qui vérifient ces règles. Il est donc possible de rassembler au

Figure 64. Les deux dernières étapes vers un processus lean



� �

sein d’un même « livrable » les exigences et les tests qui les vérifient. Nous atteignons ici la dernière étape de mise en place d’un processus lean. Dans cette organisation les différentes étapes, dont la production du code, sont conduites par la demande de la dernière étape de la façon suivante : - Test-Driven Requirements : client et fournisseur travaillent sur un même livrable, c’est-à-dire l’ensemble des exigences et les tests qui les valident. L’écriture des tests sous format tabulaire permet de valider la compréhension des uns et des autres. C’est pour cela qu’à cette étape nous disons que les exigences sont dirigées par les tests. On commence par écrire les tests s’inspirant des exemples que fournit la MOA (Maître d’Ouvrage, MOE- (Maître d’Oeuvre) et on écrit ensuite les règles de gestion ou cas d’utilisation correspondants. L’écriture de tests est utilisée comme un outil de recueil du besoin. - FTDD : comme vu précédemment, cette étape consiste à écrire les fixtures qui permettent de mettre en oeuvre les tests écrits à l’étape précédente. Pour ce faire, les développeurs se basent sur des API existantes ou non. Si les services n’existent pas encore, un travail de conception permettra de les définir et d’écrire les fixtures qui ont besoin de ces API. Cette étape permet aussi aux développeurs d’enrichir les tests existants lorsqu’ils ne sont pas assez détaillés. A cette étape, les spécifications deviennent exécutables. L’intégration de ces tests dans l’usine logicielle permettra de faire apparaître de nouveaux tests fonctionnels en échec et donc de déclencher le travail de l’étape suivante. - TDD : à cette étape, les développeurs conçoivent les différentes classes et méthodes implémentant le service en définissant d’abord les tests unitaires permettant de vérifier leur fonctionnement. La validation progressive des tests unitaires permet de mesurer l’avancement du travail. Au fur et à mesure de l’implémentation des classes bas-niveau, les tests fonctionnels vont progressivement réussir. Lorsque l’ensemble des tests réussit, le produit est prêt à être livré ! Dans cette organisation, le codage devient en pratique la dernière activité d’ingénierie logiciel avant la livraison. Il faut quand même compter quelques ajustements au cours de ces différentes étapes, car le codage peut mettre en lumière des faiblesses dans les exigences ou dans la conception. Ces faiblesses sont adressées en réajustant les tests fonctionnels et unitaires. Une telle organisation ne peut être supportée qu’avec les outils adéquats. FIT se révèle trop limité pour répondre totalement à ce besoin, notamment sur l’aspect TDR. Il faut disposer d’outils permettant une meilleure collaboration des différents acteurs du processus, et une structuration plus contextuelle de l’information. La forme du wiki paraît idéale pour répondre à cet objectif en permettant une structuration et une contextualisation efficace de l’information, ainsi qu’une facilité de mise à jour.

5.4.3.3 Eliminer les gâchis avec le MBT (Model Based Testing) Le Model-Based Testing propose une alternative aux outils comme FIT et ses dérivés. Le principe est d’élaborer un modèle à partir duquel on dérive automatiquement les actifs nécessaires aux activités de tests. Par exemple, on peut générer des cahiers de recette, ou des scripts de tests.

Figure 65. L’approche MBT



� �

De la précision du modèle dépend la profondeur des tests que l’on peut générer. L’approche impose donc un fort investissement dans les activités de modélisation. Elle a du sens pour les organisations déjà matures sur cet aspect pour qui l’apprentissage sera modéré.

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

5.4.3.5 Mutation organisationnelle et fonctionnelle • La mise en place du TDR implique également d’entreprendre une mutation organisationnelle afin de faire sauter les séparations entre les activités amont et aval des équipes de développement. Si une organisation n’entreprend pas ce travail, les spécifications et tests « à la mode TDR » seront une charge supplémentaire pour toute l’équipe. • A long terme, la pratique du TDR entrainera la disparition de certains rôles caractéristiques des silos organisationnels (architecture "en silos" - chaque application ou BD l'entreprise reposait sur une plate-forme propriétaire, l'isolant du reste

de l'écosystème informatique.) pour faire place à de nouveaux profils. Par exemple, les rôles d’analyste et de testeur sont amenés à fusionner car il n’existe plus de besoin d’avoir des ressources spécialisées sur les exigences et sur les tests, ces activités étant elles-mêmes fusionnées.

(http://www.davenicolette.net/articles/changing-roles.html).

5.5 Conclusion :

Les méthodes agiles ont désormais fait leurs preuves, aussi bien sur des projets aux délais très serrés que sur des projets d'enjeux stratégiques. Ces méthodologies ont fait l'objet de différentes formalisations, adaptées à différents concepts, l'un des plus répandus étant certainement SCRUM. Même les méthodologies visant les grands projets, comme RUP (Rational Unified Process), y ont puisé largement.

Toutefois, les méthodes agiles bien que répondant à une demande et à des besoins réels, ont besoin d’une meilleure normalisation, et d’un peu plus d’éléments d’assurance qualité. Le mouvement agile va certainement apporter quelque chose aux entreprises. Cependant, sans en comprendre les principes fondamentaux, on ne peut avoir de gain sérieux.



� �

66 PPrroocceessssuuss ddee DDéévveellooppppeemmeenntt ,, OOuutt ii llss eett MM ééttrr iiqquueess ddee QQuuaall ii ttéé

Nous avons déjà vu au chapitre 1 que dans l’Ingénierie des systèmes logiciels, on retrouve des méthodes et surtout plusieurs outils servant tout au long du processus de développement.

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

Couche de présentation

Comosants d’interface utilisateur Composants de comportement

L’Interface Graphique

(GUI, 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, Data Access Layer)

Stockage des données

Bases de données

La couche métier (BLL, Business Logic Layer)

• La couche de présentation contient les composants qui doivent interagir avec l'utilisateur de l'application, comme

les pages Web, les formulaires, ainsi que tout ce qui régit le comportement de l'interface utilisateur. • La couche métier intègre les fonctionnalités et les traitements propres à l'application. Les fonctionnalités simples

peuvent être implémentées avec des composants sans états, alors que les transactions complexes et longues peuvent utiliser des composants d'ordonnancement avec états. Les composants métier sont généralement dissimulés derrière une sous-couche d'interface de service qui agit comme une façade afin de dissimuler la complexité de l'implémentation. Cela participe de ce que l'on appelle communément une architecture orientée par les services (SOA = « Service-Oriented Architecture »).

• La couche d'accès aux données fournit une interface simple pour accéder aux données et les manipuler. Les composants de cette couche abstraient la sémantique de la couche de données sous-jacente, permettant ainsi à la couche métier de ce concentrer sur la logique applicative. Chaque composant fournit typiquement des méthodes pour créer, lire, mettre à jour et effacer (CRUD = « Create, Read, Update, Delete ») des entités de données.

• La couche de stockage des données comprend l'ensemble des sources de données de l'application d'entreprise. Les deux types les plus communs de sources de données sont les bases de données et les systèmes de fichiers.

Figure 66. Architecture des applications d'entreprise



� �

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

- La maintenance des données est indépendante du support physique de stockage - La maintenance des traitements est simplifiée - La gestion des traitements depuis la couche de présentation est facilitée - Le travail en équipe est optimisé - La migration d’un environnement graphique à un autre est relativement simple

Lorsque l’on dit que le travail en équipe est optimisé, la raison est simple : alors qu’un des membres de l’équipe travaille sur la couche d’accès aux données, un autre peut tout à fait travailler sur la couche métier ou sur l’interface graphique sans perturber le travail de ses collègues. De même, dans le cas de migration (d’interface utilisateur par exemple), là encore, la tâche est simplifiée. Ainsi, inutile de redévelopper tout ce qui a été fait jusqu’à maintenant : il vous suffit de modifier l’interface. 6.2 Place des Outils Les outils ont un rôle fondamental dans la réalisation d’un processus logiciel. En particulier pour les aspects suivants :

• Spécification des besoins • Conception des solutions • Réalisation des solutions (programmation) • Assurance qualité du logiciel

o spécification de la qualité requise o spécification des règles de construction o test et mise au point des programmes et applications o qualimétrie du logiciel o gestion de la qualité du logiciel

• Conduite des projets o Evaluation des charges, coûts et délais o Planification des tâches o Suivi et gestion des projets o Gestion de la documentation o Coordination des travaux individuels

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

Typologie des outils

- éditeurs (de spécification, modèles, maquettes d’écrans ou d’états, structures de fichiers, codes sources, dossiers de projets)

- générateur (de codes) - compilateurs de test - analyseurs - prototypeurs - simulateurs - dictionnaires - gestionnaires (de besoins des applications, de composants réutilisables, de projet, etc.) - optimiseurs de performances - restructurateurs de code

6.3 Quelques facteurs pouvant influencer le choix de langages et outils :

• Niveau d'abstraction o doit être adapté à la tâche ( e.g. C vs Prolog )

langage machine < assembleur < FORTRAN < C < Java



� �

• Simplicité conceptuelle o nombre et régularité des concepts o plus le langage est simple, plus c'est facile de le maîtriser (e.g. Lisp vs Scheme)

• Puissance expressive o supporte plusieurs styles de programmation (e.g. C vs Java)

• Degré de spécialisation o un langage spécialisé est conçu spécialement pour certaines applications (e.g.

COBOL=administration-gestion, SPSS=statistiques, ICON=texte) o un langage général (e.g. C, Ada, ML) peut faire n'importe quoi mais avec un peu plus d'effort de

programmation • Sécurité

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

• Support de gros projets o le langage offre-t-il des mécanismes pour aider à la réalisation de gros projets (> 500.000 lignes)? o modules? compilation séparée? (e.g. Pascal vs Ada)

• Environnement de développement o existe-t-il des outils de développement adaptés au langage? o éditeur avec indentation automatique et coloration syntaxique, compilateur avec messages précis,

débogueur symbolique avec exécution pas-à-pas • Performance

o compilateur rapide? exécutable rapide? (e.g. Ada vs Java) • Coûts de développement et maintenance

o les programmeurs disponibles maîtrisent-ils le langage? sont-ils productifs? le langage permet-t-il de réutiliser et étendre des librairies et programmes existants?

• Portabilité o le langage est-il répandu ? Existe-t-il un standard bien établi? (e.g. C vs C++, Java). Peut-on migrer

facilement d’une plateforme à une autre ? Note 1: on fait souvent face à des compromis car ces facteurs sont souvent contradictoires (e.g. Java est de haut-niveau, de haute puissance expressive, sécuritaire et (en principe) portable, mais pas très performant) Note 2: parfois il est possible d'écrire un programme en utilisant plus qu'un langage, ce qui permet d'utiliser le langage le plus approprié pour chaque partie. (Exemple : intégration C->Pascal, Assembleur->C …)

6.4 Environnements intégrés de programmation Dans un tel environnement, on retrouvera plusieurs outils intégrés (travaillant ensemble) autour d’un langage et

conçus pour travailler ensemble en vue de fabriquer un programme exploitable. Ces outils peuvent partager plusieurs instances d’objet ou encore avoir les mêmes types d’interfaces ou de procédures d’utilisation interne ou externe (shell, macros, make, etc.). Mais ils ne communiquent pas pendant l’exécution. Et ils ne sont parfois pas interopérables avec des outils extérieurs.

6.5 Les Ateliers de Génie Logiciel 6.5.1 Qu'est ce qu'un atelier de génie logiciel ? Un AGL (Atelier de Génie Logiciel) est un logiciel aidant à la réalisation de logiciels. Autrement dit, il s'agit d'un système pour le développement logiciel assisté par ordinateur. Un AGL intègre des outils adaptés aux différentes phases de la production d'un logiciel et facilite la communication et la coordination entre ces différentes phases. Un AGL est basé sur des méthodologies qui formalisent le processus logiciel, et à l'intérieur de ce processus, chacune des phases qui le composent. Les AGL apportent une réelle solution à certains problèmes du génie logiciel et contribuent nettement à l'amélioration de la productivité et de la qualité du logiciel, notamment en faisant le suivi des différentes phases du processus logiciel et en offrant un cadre cohérent et uniforme de production. Néanmoins, cet enthousiasme doit être modéré: le processus logiciel est encore loin d'être maîtrisé et les différentes formalisations qui en sont proposées font encore l'objet de controverses, et dans tous les cas, sont bien loin d'être totalement automatisables. L'informaticien a encore de belles années de travail devant lui avant d'être supplanté par des AGL... 6.5.2 Les outils « CASE » (Computer Aided Software Engineering) Les AGL intègrent différents outils d'aide au développement de logiciels, appelés outils CASE: éditeurs de texte (vi, emacs, ...), de diagrammes (TRAMIS VIEW, X-fig, ...), outils de gestion de configuration (make), SGBD, compilateurs, debuggers, outils pour la mise en forme (pretty-printers), la génération de tests, la génération d'interfaces homme-machine, ...



� �

Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel : conception (éditeurs de texte, de diagrammes, ...), programmation (éditeurs de texte, compilateurs, pretty printers, générateurs d'interfaces homme/machine...), mise au point (debuggers, outils de génération de tests, ...), etc. Certains outils, concernant notamment la gestion de configurations, la gestion de projet, interviennent durant la totalité du processus logiciel. 6.5.3 L'intégration d'outils CASE Un AGL intègre différents outils CASE, de manière à les faire coopérer de façon uniforme. Cette intégration peut (devrait) s'effectuer à trois niveaux:

• Intégration des données : Les outils CASE manipulent (génèrent, utilisent, transforment, ...) des données: spécification, modèle conceptuel des données, jeux de test, code, manuel utilisateur, .... Différents outils sont amenés à partager une même donnée: les tables générées par un éditeur de diagrammes sont utilisées par un SGBD, le code généré par un éditeur de texte est compilé par un compilateur, à partir d'une spécification algébrique on peut générer des jeux de test, ...

Un AGL doit prendre en charge la communication de ces données entre les différents outils. Cette intégration peut être simplement physique : tous les outils de l'AGL utilisent un seul format de représentation des données, par exemple des fichiers UNIX, sur une même machine. Cette approche implique que tous les outils de l'AGL connaissent la structure logique (l'organisation) des fichiers qu'ils sont amenés à utiliser: il est nécessaire de normaliser la structure logique des fichiers. L'intégration des données peut se faire également au niveau logique en utilisant un système de gestion des objets qui gère automatiquement les différentes entités et leurs inter-relations (cette approche nécessite la définition des différents types de données manipulées).

Un AGL devrait également gérer la cohérence entre les différentes versions de ces données (gestion de configuration).

• Intégration de l'interface utilisateur : tous les outils intégrés dans l'AGL communiquent avec l'utilisateur selon un schéma uniforme, ce qui facilite leur utilisation (voir par exemple l'interface du Macintosh, X11 sous Unix ou Windows sur DOS).

• Intégration des activités : un AGL peut gérer le séquencement des appels aux différents outils intégrés, et assurer ainsi un enchaînement cohérent des différentes phases du processus logiciel. Cet aspect implique que l'on dispose d'un modèle du processus de développement bien accepté (ce qui relève un peu de l'utopie !!!).

6.5.4 Les différents types d'AGL Sur le plan historique, on a noté une évolution rapide suivant les tendances ci-après :

- Environnements orientés langages - Environnements structurels - Environnements boites à outils - Environnements orientés « méthodes »

On distingue essentiellement deux types d'AGL selon la nature des outils intégrés: 1. Les environnements de conception (upper-case) : ces ateliers s'intéressent plus particulièrement aux phases

d'analyse et de conception du processus logiciel. Ils intègrent généralement des outils pour l'édition de diagrammes (avec vérification syntaxique), des dictionnaires de données, des outils pour l'édition de rapports, des générateurs de (squelettes de) code, des outils pour le prototypage, ... Ces ateliers sont généralement basés sur une méthode ou un langage d'analyse et de conception (JSD, SADT, Yourdon, Merise, UML ...) et utilisés pour l'analyse et la conception des systèmes d'information.

TRAMIS est un environnement de conception qui intègre notamment un éditeur de diagrammes (TRAMIS View), un générateur de prototypes (TRAMIS Dialog), ...

2. Les environnements de développement (lower-case) : ces ateliers s'intéressent plus particulièrement aux phases d'implémentation et de test du processus logiciel. Ils intègrent généralement des éditeurs (éventuellement dirigés par la syntaxe), des générateurs d'interfaces homme/machine, des SGBD, des compilateurs, optimiseurs, pretty-printers, debuggers, ...

WinDev est un environnement de développement.

D’autres environnements de développement existent sous Unix/Linux qui intègre différents outils pour la programmation et le test. L'intégration des données est faite par l'intermédiaire des fichiers Unix, la gestion (limitée) de configurations est faite par make... Certains environnement, plus évolués, sont dédiés à un langage particulier. Il existe par exemple des environnements dédiés à InterLisp, Smalltalk, Loops (l'environnement Loops fonctionne sur une machine dédiée à Loops), Oz... Ces différents environnements proposent des bibliothèques de composants, une interface graphique, des éditeurs dédiés au langage, des interprètes, debuggers, ... Ces environnements permettent un développement rapide et convivial. En revanche, l'application développée est intégrée dans (et généralement inséparable de) l'environnement, ce qui peut poser des problèmes de portabilité et de coût. Enfin, il existe des générateurs d'environnements de programmation : Mentor, Gandalf, Synthesizer Generator, ... A partir de la description formelle d'un langage (à l'aide de grammaires attribuées,



� �

de la logique), ces différents systèmes génèrent un environnement de programmation dédié au langage, contenant un éditeur dédié au langage, un pretty-printer, un debugger, un interpréteur, ... 6.5.5 Standardisation des ateliers Le problème majeur que l’on peut rencontrer c’est la difficulté de communication entre les différents ateliers de plus en plus nombreux, variés et couteux. Toutes ces raisons ont poussé les acteurs à évoluer vers une standardisation.

6.5.6 Ateliers et Cycle de vie

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

Besoins Spécifications Conception Test Intégration Maintenance

Version Configuration Projet Mesures

Base de données

SE (Système d’Exploitation)

6.6 Intérêt de la qualité d'un logiciel, et de son contrôle à l’aide des outils appropriés [Linsolas09] plusieurs solutions performantes existent pour le contrôle de la qualité du logiciel. Mais rappelons ce que c’est que la qualité d'un logiciel, et en quoi est-il important de la contrôler ! En paraphrasant Wikipédia , la gestion de la qualité est l'ensemble des activités qui concourent à l'obtention de la qualité dans un cadre de production de biens ou de services (dans notre cas, d'un logiciel informatique). Plus largement, c'est aussi un moyen que se donnent certaines organisations, dans des buts tels que la mise en conformité par rapport aux standards du marché. Dans le monde informatique en général, et en Java en particulier, la qualité d'une application va être directement liée à la qualité du code. De nombreux outils s'affairent à contrôler certains aspects de cette qualité du code : exécution de tests unitaires, analyse de la couverture du code par ces tests, vérifications du respect des règles de codage, etc. Il est donc possible de contrôler la qualité de son code grâce à ces outils, et d'avoir une confiance accrue en son application ! Le contrôle de la qualité va donc pousser l'équipe de développement à adopter et à respecter certains standards de développement. Le but de tout cela étant bien entendu de rendre le code plus sûr, mais de permettre d'y déceler les erreurs le plus rapidement possible... et donc de les corriger ! Le "Toyota Way" correspond à une méthodologie extrêmement appréciée aujourd'hui, aussi appelée le "Lean". Celle-ci est basée sur 14 principes dont l'un d'eux est le "Build a culture of stopping to fix problems, to get quality right the first time". Ce principe est là pour nous rappeler qu'il est impossible d'accélérer et de soutenir une fréquence de production sans que la qualité soit au coeur de toutes les actions. Autrement dit, il n'est pas possible d'aller vite sans qualité, mais qu'il n'est pas possible non plus de faire de la qualité sans vitesse. C'est aussi pour cela qu'il est aujourd'hui primordial de disposer d'une intégration continue et d'un processus itératif et incrémental.

Figure 67. Structure d’un EIPL (Environnement Intégré de Production de Logiciel)

Noyau

BD

Gestion d’objet Outils

Program.

Outils Concept.

Outils spécifiques

Outils gestion

Interface publique

Outils d’accès

Outils d’édition

auto.



� �

Chez Toyota, on demande deux choses à un ouvrier, chaque jours: livrer des pièces et trouver de meilleures façons de le faire. Le second point étant bien plus important que le premier. Ça garde l'ouvrier éveillé, fier qu'on lui demande de se servir de sa tête et de sa créativité. Demandez aux développeurs de livrer du code, mais plus important encore... d'améliorer tout les jours, leurs façons de faire. À la longue, on réduit les défauts et on augmente la productivité. Mieux, on leur demande de demeurer des humains, pas de devenir des machines.

L'un des intérêts de la surveillance de la qualité est la détection précoce des éventuels problèmes. Or lorsque l'on sait que le coût de la correction d'une erreur augmente considérablement avec le temps (voir image ci-dessous), on comprend très vite l'importance de la détection rapide des erreurs...

[Linsolas09]

Comme le rappelle Tom DeMarco, "You can't control what you can't measure", "On ne peut contrôler ce que l'on ne mesure pas"... D'où l'importance d'utiliser un outil de qualité tels que « Sonar » (voir plus loin dans le chpitre).

6.7 Les « processwares » : Les processware ou Intergiciel, sont des progiciels d’interconnexion entre applications. Un processware est une application qui fournit les traitements de gestion entre différents progiciels. 6.8 Choix de l’outil de développement : Le choix d’un outil de développement répond à plusieurs types d’interrogations. Le premier groupe de questions est centré sur une analyse fine du projet à réaliser et sa faisabilité. - disposons nous de ressources techniques et du temps nécessaires en interne ou devons nous passer par un

prestataire extérieur ? - qui sera le chef de projet et comment se fera le suivi ? - quelle est la composition de l’équipe opérationnelle envisagée ? Le second groupe concerne les spécificité techniques du langage lui même : - quel est le niveau de portabilité du langage (outils) ? - permet – il de développer des applications client-serveur ? - quel sera le supports technique offert ? Note : Un logiciel est évalué selon des critères relatifs à la qualité de traduction d’éléments d’un diagramme de classes :

- associations - classes-associations - agrégations - contraintes inter-relations - héritage - rétro-conception d’une base de données.

Suivant l’approche de réalisation de logiciels MDA (Model Driven Architecture), les objectifs des outils sont de permettre de modéliser un système dans un modèle PIM (Platform Independent Model) en utilisant un langage de spécifications approprié, puis de pouvoir traduire dans un ou plusieurs PSM (Platform Specific Model) réalisant ainsi l’implémentation concrète du système. Quand le domaine d’implémentation se cantonne aux bases de données, UML peut être utilisé comme modèle PIM, alors que SQL le sera au niveau du PSM. Depuis plus de 35 ans, la conception des BD était réalisée à l’aide du modèle entité-association. La notation UML qui s’impose dans bien des domaines de l’informatique s’adapte de mieux en mieux aux bases de données. Le premier pas a été réalisé par Rational Rose avec son profil UML (UML profile for Data Modeling). Ce profil permet de décrire des bases de données notamment à l’aide de stéréotypes prédéfinis (Table, RelationalTable, View, etc.).

Figure 68. Le coût de correction d’une erreur croit exponentiellement avec le temps



� �

6.9 Outils de Développement « MDA »

6.9.1 AndroMDA pour Java (un générateur d’application) L'idée qui se cache derrière MDA en tant que méthode, et donc derrière AndroMDA en tant qu'outil, c'est de se dire que la plus grande partie d'une application doit pouvoir être conçue indépendamment de la technologie utilisée pour l'implémenter. Le résultat de cet effort de conception, ce sont des modèles qui peuvent être spécifiées dans un langage standard, et lui aussi indépendant de la technologie d'implémentation : UML. Ensuite, la démarche la plus simpliste est de partir de ces modèles pour les traduire manuellement en leur implémentation en fonction de la technologie utilisée, ce qui est souvent très long et très facilement source d'erreurs inutiles et d'incohérences. Il se trouve justement qu'avec l'expérience, on a pu identifier des schémas de conception (plus connus dans leur dénomination anglophone de « design patterns ») génériques, qui permettaient de résoudre des problèmes classiques, de proposer une solution éprouvée qu'il suffisait de réutiliser. On s'est aussi rendu compte que l'implémentation de ces modèles dans une technologie donnée était automatisable dans une certaine mesure. C'est ce que fait AndroMDA : il extrait toutes les informations qu'il peut d'un modèle UML, y applique un ensemble de modèles de conception et de paramètres de configuration pour produire tout le code générique d'une application, ne laissant au développeur qu'à boucher les trous en implémentant les parties qui n'ont pas pu être spécifiées dans le modèle, notamment parce qu'elles dépendaient de la technologie d'implémentation choisie. La part de code généré dans le code intégral de votre application dépend donc de deux facteurs : le niveau de détail de votre modèle et sa conformité avec les attentes d'AndroMDA d'une part, et le nombre et la qualité des modules de génération mis en oeuvre par AndroMDA d'autre part. Ca peut encore vous paraître très abstrait, mais vous allez voir : c'est réellement bluffant, d'autant qu'on s'attend souvent à ce qu'un générateur de code produise un code assez « sale », parsemé de variables numérotées et autres commentaires codés. Mais avec AndroMDA, ce n'est pas du tout le cas grâce à ses importantes possibilités de configuration et à l'utilisation de modèles de conception standards.

AndroMDA prend en entrée un modèle métier spécifié en UML (« Unified Modeling Language ») et génère des parties importantes des couches nécessaires pour construire une application Java. La faculté d'AndroMDA à traduire automatiquement des spécifications métier haut niveau en un code de qualité permet un gain de temps significatif dans l'implémentation d'applications Java.

[Arbogast06]

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

Figure 69. Architecture des applications d'entreprise – Implémentation AndroMDA



� �

• Couche métier : la couche métier générée par AndroMDA est principalement consituée de services configurés en utilisant le framework Spring. AndroMDA crée des méthodes vides dans les classes d'implémentation où la logique métier peut être ajoutée. Les services générés peuvent éventuellement être interfacés avec des EJB. Dans ce scénario, les services doivent être déployés dans un conteneur d'EJB comme JBoss AS. Les services peuvent également être exposés comme des WebServices, fournissant une interface indépendante de la plateforme aux clients qui souhaitent accéder à leurs fonctionnalités. AndroMDA peut aussi générer des processus et des ordonnancements métier pour le moteur d'ordonnancement jBPM (qui fait partie de la famille de produits JBoss).

• Couche d'accès aux données : AndroMDA s'appuie sur le très populaire outil de mapping objet relationnel Hibernate pour la génération de la couche d'accès aux données des applications. Il produit des objets d'accès aux données (DAO - « Data Access Objects ») pour les entités définies dans le modèle UML. Ces objets d'accès aux données utilisent l'interface de programmation d'Hibernate pour convertir les champs de bases de données en objets et vice-versa.

• Bases de données : puisque les application générées par AndroMDA utilisent Hibernate pour accéder aux données, vous pouvez utiliser n'importe quelle base de données supportée par Hibernate.

Remarques : - Puisque AndroMDA est totalement modulaire, il est fondamentalement extensible et il y a de très nombreuses possibilités

d'ajout de modules qui génèreront une implémentation pour des technologies propres à votre environnement. l'équipe d'AndroMDA a créé récemment une nouvelle initiative pour coordonner et encourager la création de modules additionnels. Sachez par exemple qu'un effort important est en cours pour finaliser une pile de modules pour .NET, qui devrait à terme vous permettre de générer à votre convenance une application Java et/ou .NET à partir des mêmes modèles.

- Contrairement à certains générateurs de code classiques, AndroMDA ne se contente pas de générer des fichiers de classes Java : il génère également les fichiers de configuration XML traditionnellement nécessaires dans la plupart des frameworks Java, comme les fichiers de mapping d'Hibernate, les fichiers de description de beans de Spring ou encore les fichiers de configuration d'Axis. En fait, ce qui est intéressant, c'est qu'alors même que vous n'avez pas encore bouché les trous d'implémentation, simplement avec votre modèle, AndroMDA génère une application qui compile et peut déjà être déployée sans erreur dans un serveur d'applications ! Bien sûr il manque des fonctionnalités, mais toute l'infrastructure est prête.

Propagation des données entre les couches Les bases de données relationnelles stockent les données comme des champs dans des tables. La couche d'accès aux données récupère ces champs depuis la base de données et les transforme en objets qui représentent les entités du domaine métier. C'est pourquoi on appelle ces objets des entités métier. La couche d'accès aux données passe les entités métier à la couche métier qui éxecute sa logique sur ces entités. Concernant la communication entre la couche métier et la couche présentation, il y a véritablement deux écoles de pensée. Certains recommandent que la couche de présentation puisse avoir un accès direct aux entités métier, tandis que d'autres préconisent l'inverse : les entités métier devraient être totalement isolées de la couche de présentation et la couche métier devrait encapsuler les données dans ce que l'on appelle des objets de valeur (« value objects ») avant de les transmettre à la couche de présentation. Essayons de comprendre les avantages et les inconvénients de ces deux approches. La première approche (que des entités, pas d'objets de valeur) est plus simple à implémenter. Vous n'avez pas besoin de créer des objets de valeur ou d'écrire aucun code pour transférer l'information depuis les entités vers les objets de valeur. En fait, pour de petites applications simples où la couche de présentation et la couche métier s'exécutent sur la même machine, cette approche fonctionnera très bien. Mais pour des applications plus grandes et plus complexes, cette approche s'adapte mal, notamment pour les raisons suivantes : • La logique métier n'est plus contenue exclusivement dans la couche métier. Il est alors tentant de manipuler

directement les entités depuis la couche de présentation, et de disperser du même coup la logique métier dans des endroits différents, ce qui peut rapidement devenir un cauchemar en termes de maintenabilité. Et dans le cas où il y a plusieurs interfaces de présentation pour un service (par exemple une interface web, un client riche et un client mobile), la logique métier doit alors être dupliquée dans tous ces clients. De plus, il n'ya rien qui empêche les clients de corrompre les entités, intentionnellement ou pas.

• Lorsque la couche de présentation s'exécute sur une machine différente (par exemple dans le cas d'un client riche), il est complètement absurde de sérialiser tout un réseau d'entités pour l'envoyer au client. Prenons l'exemple de la présentation à l'utilisateur d'une liste de commandes. Dans ce scénario, nous n'avons pas besoin de transmettre tous les détails de chaque commande à l'application cliente. Tout ce dont le client a besoin, c'est d'un numéro de commande, d'une date et d'un montant total pour chaque commande. Ensuite, si l'utilisateur souhaite voir les détails d'une commande en particulier, nous pouvons toujours lui transmettre cette commande en entier.

• Passer des entités réelles au client peut poser un risque de sécurité. Voulez-vous que l'application cliente puisse toujours accéder au salaire dans une entité « Employé » ou à votre marge de profit dans une entité « Commande » ?



� �

Les objets de valeur fournissent une solution pour tous ces problèmes. D'accord, il faut écrire un peu de code en plus, mais en échange vous obtenez une couche métier d'une solidité à toute épreuve qui communique efficacement avec la couche présentation. On peut voir les objets de valeur comme une vision contrôlée cohérente avec les besoins de votre application cliente. Notez d'ailleurs qu'AndroMDA fournit un support de base pour la transformation d'entités en objets de valeur (et vice-versa), un support qui va d'ailleurs encore une fois vous faire gagner beaucoup de temps.

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

• Système d'attributions de fonds pour l'industrie off-shore 150 classes, 2 millions d'objets dans une institution de financement internationale

• Système de gestion de l'imposition des personnes physiques et des entreprises 130 classes, 10 millions d'objets utilisé par 200 administrateurs

• ERP Gestion de ressources en personnel et en équipements 300 classes, 2 millions d'objets utilisé par 200 personnes d'une chaîne de télévision

• Logistique Analyse des besoins en temps réel, planification des ventes et de la distribution 230 classes, 2 millions d'objets

• e-Banking Middleware pour rendre un AS/400 bancaire compatible COM 60 classes, 5000 objets au format XML.

6.10 Outils de contrôle de Qualité et de Test de codes

6.10.1 Contrôler la qualité de ses projets avec l’outil « Sonar » [Linsolas09] Sonar offre une solution performante du contrôle de la qualité du logiciel. Cet outli sert à offrir un suivi de la qualité d'un logiciel. Il s'agit toutefois là d'une solution facile à déployer, très agréable à utiliser, et vraiment complète. De plus, elle est aujourd'hui la seule solution (open source en tout cas) à proposer la visualisation et le regroupement de ces données pour un ensemble de projets, et non pour un seul projet. L'intégration d'un gestionnaire de plugins est un aspect important pour le développement de Sonar. Sonar est un outil open-source initiallement développé par la société suisse Hortis . Depuis novembre 2008, c'est la société suisse SonarSource qui se charge du développement et du support de Sonar. Le but principal de cet outil est de fournir de nombreuses statistiques (ou "metrics") sur des projets. Ces données permettent ainsi d'évaluer la qualité du code, et d'en connaître l'évolution au cours du développement. D'un point de vue architectural, Sonar est composé de 3 couches principales : • Les plugins Maven 2, qui exécutent les plugins de rapports (Checkstyle, PMD, etc.) et en récoltent les résultats.

(l’outil Checkstyle propose plus d'une centaine de règles, et il en va de même avec l’outil PMD). • La base de données, qui stocke et historise les informations sur les projets "surveillés" par Sonar. • Le serveur web qui agrège les résultats et affiche des dashboards pour les projets. Principales fonctionnalités Nous listons ici les principales fonctionnalités de l'outil Sonar.

• Tableau de bord complet des différents projets suivis. • Détection rapide du code à risque. • Mesures quantitatives : nombre de classes, duplication de code, etc... • Mesures qualitatives : couverture et taux de réussite des tests, complexité du code, respect des règles de codage... • Historiques des statistiques, pour en voir l'évolution au cours du temps. • Support de plus de 600 règles de qualité (suivant la norme ISO 9126-3).



� �

• Gestion de profils pour les règles de codage. • Visualisation du code source, surlignant les violations des règles de codage qui s'y trouvent. • Fonction "Time machine" permettant de comparer plusieurs versions d'une même application. • Identification des points faibles d'un projet. • Support des plugins.

6.10.2 Tests unitaires avec « PHPUnit » (un OpenSource) [Grossglauser07] PHPUnit est un framework de test unitaires simple et efficace, son éventail de fonctionnalités permet de créer

rapidement des tests unitaires complets et adaptés aux applications PHP professionnelles. PHPUnit offre une solution particulièrement flexible pour organiser vos tests, vous pouvez les exécuter indépendamment les uns des autres, les grouper en suites, ou rassembler les suites elles-mêmes afin d'exécuter le tout en une seule fois.

PHPUnit offre quelques qualités... - Un syntaxe simple, facile à comprendre et à retenir. - Un grand nombre de méthodes de tests. - Organisation et exécution des test flexibles. - Un utilitaire en ligne de commande complet. PHPUnit offre quelques fonctionnalités avancées - Support des objets "mock" (simulateur d'objets) - Analyse de la couverture de code (code coverage analyse). - Support de « Selenium RC » (environnement de développement intégré (IDE) / tests fonctionnels) - Journalisation des tests aux format XML, JSON, TAP ou dans une base de données. PHPUnit est pris en charge nativement dans les IDE suivant : - NuSphere PHPEd. - PHPEdit. - Zend Studio. - PHPEclipse (voir plugin Eclipse SimpleTest ). - Eclipse PDT (le support a été prévu).

6.10.3 Utilitaires : • L'utilitaire de ligne de commande : phpunit est le principal outil dédié à la configuration et à l'exécution des

tests unitaires. Cet utilitaire est optimisé pour les systèmes Unix/Linux. Mais, il peut également fonctionner sous Windows. La liste des commandes est disponible en tapant : phpunit --help

• Indicateur de résultat : Un indicateur de résultat est fourni pour chaque méthode de test exécutée : Tiré de [Grossglauser07]

Indicateur Description . Le test passe. F Le test a échoué (Failure). E Le test a généré une erreur PHP. S Le test est ignoré (Skipped). I Le test est marqué comme incomplet (Incomplete).

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

• Fitnesse (http://fitnesse.org/) est un outil libre qui utilise une version modifiée de FIT comme moteur de tests et permet de décrire ses tests dans un wiki. Il nécessite par contre de déployer le code source sur un serveur pour pouvoir exécuter ses tests. C’est un bon outil pour l’étape TDR et tests de recette, mais n’est pas suffisant pour supporter une approche compréhensive du TDR jusqu’au code.



� �

• Greenpepper (http://www.greenpeppersoftware.com/) est un outil plus puissant combinant un moteur de tests open-source et une série d’extensions payantes. Les extensions permettent l’utilisation du wiki Confluence et l’intégration à une « usine logiciel » par des scripts Maven. Une extension permet également d’intégrer JIRA, un moteur de workflow. Les tests peuvent être exécutés indépendamment depuis un serveur ou depuis le poste du développeur. Il est également possible de choisir différents contextes d’exécution. On peut ainsi gérer plusieurs environnements de tests selon les phases de tests à effectuer (développement, homologation, recette, préproduction) ou selon la version des spécifications.

Lors d’une bonne mise en œuvre de Greenpepper, l’équipe de travail peut être répartie sur plusieurs sites avec des développements effectués dans plusieurs villes comportant plusieurs développeurs. Le délai moyen entre la fin de l’écriture du code pour une livraison donnée et la mise en production de cette nouvelle version peut être ramené à juste quelques heures. Ce délai inclut les phases de tests d’homologation et de pré-production (tests d’intégration avec les systèmes environnants). La seule activité manuelle effectuée après l’écriture de la dernière ligne de code consiste à vérifier le bon fonctionnement de l’interface graphique, en attendant que cette couche soit testable avec des outils comme Greenpepper ou FIT.

• L’outil Leirios Test Designer (http://www.leirios.com/) permet d’utiliser un modèle comportemental

formalisé avec un sous-ensemble d’UML, appelé modèle de test, pour générer les actifs de tests. Ce modèle est parcouru par un moteur calculant le nombre de tests et les vérifications à effectuer pour en déduire les cas de tests. Ces cas de test peuvent ensuite être traduits en scripts de tests avec un adaptateur adéquat.

6.12 Autres outils

6.12.1 Le serveur d’application universel EAS : Enterprise Application Server [Sybase] EAS est un serveur d »’applications adapté à la nouvelle informatique. - Il est ouvert aux supports transparents de tous les types de clients : CORBA, XML, HTML, DHTML, ActiveX, C,

C++, PowerBuilder … - Il est compatible avec la plate forme J2EE (Java 2 Enterprise Edition), ce qui assure la prise en charge des

technologies J2EE : EJB, Servlet, JNDI (Java Naming and Directory Interface), JTA (Java Transaction API), JTS (Java Transaction Server), JDBC.

- Il s’intègre avec les outils de développement Web « Power J », HTML, programmation Java, JavaScript, ActiveX. Tout ceci fait que EAS est adapté au développement d’applications Internet et Intranet.

6.12.2 L’environnement de référence DOC (HP) DOC (Distributed Object Computing) est un RPC proposé par HP. Initialement, il est une implémentation du

standard DCE de l’OSF.

Finalement, DOC est à cheval entre RPC procédural et RPC orienté objet (ORB). Mais, il se rapproche beaucoup

plus de l’ORB à cause des composantes (outils) C++, Smaltalk, DOMF, etc.

Note : Motif est une interface graphique utilisateur normalisée pour le système Unix (comme Windows l’était pour le DOS initialement).

Figure 70. Schéma de la plateforme DOC

O.S.

Services de réseau (NCS) [OSF/DCE]

Service de gestion de données (Open ODB) [POSC ART]

DOMF (Distributed Object Management Facilities)

Services d’objets répartis (distribuive Smaltalk de HP)

APPLICATIONS

Environnement utilisateur HP View [OSF / Motif] New Ware

Outils de gestion

et du réseau

Environnement de développement de

logiciels (Soft bench)

[NIST, ECNA, C++]

Plateforme Plateforme Plateforme Plateforme

Client ou ServeurClient ou ServeurClient ou ServeurClient ou Serveur



� �

6.12.3 L’offre logicielle de Microsoft : La plate forme de développement de Microsoft fournit tous les outils nécessaires pour élaborer des solutions client-serveur, Internet et Window. L’offre s’appelle « Visual Studio ». On y retrouve entre autres : • Les produits : MSDN Library

Visual Basic Visual C++ Visual FoxPro Visual J++ Visual SourceSafe Visual Interdev SQL Server

• Les outils multimédia : Image composer Media manager

• L’outils système : Anomaly Tracking System • L’outil transactionnel pour l’intégrité en réseau : Transaction server » • L’outil de travail collaboratif : Visual Studio Team Foundation Server, arrivé avec Visual Studio 2005. Il permet de définir des

priorités sur des tâches, d'avoir une gestion des sources, etc. 6.12.4 Quelques Logiciels de modélisation UML Outils UML 2 pour les bases de données

Principaux logiciels du marché permettant de modéliser du niveau conceptuel à la génération de script SQL, une base de données à l’aide de la notation UML 2. En passant par la génération des modèles de type MOF et l’import/export de modèles au format XMI.

- Enterprise Architect http://www.sparxsystems.com.au/products/ea.html - MagicDraw http://www.magicdraw.com/ - MEGA Designer http://www.mega.com/en/product/mega_designer/ - ModelSphere http://www.silverrun.com/modelsphere.html - MyEclipse http://myeclipseide.com - Objecteering http://www.objecteering.com/ - Poseidon http://gentleware.com/index.php?id=30 - PowerAMC http://www.sybase.com/products/developmentintegration/poweramc - Rational Rose Data Modeler http://www-306.ibm.com/software/awdtools/developer/datamodeler/ - Together http://www.borland.com - Visio http://www.microsoft.com/france/office/visio - Visual Paradigm http://www.visualparadigm.com/product/vpuml/productinfovpumlse.jsp - Visual UML http://www.visualuml.com/Products.htm - Win’Design http://www.win-design.com/fr/

Logiciels libres

• ATL open source : transformations de modèles vers ou depuis UML (etc.) ; ATL est un langage de type QVT (le standard QVT définit un ensemble de langages permettant d exprimer des transformations de modèles à modèles).

• Dia • Umbrello un modeleur UML sous GPL. Ne fonctionne pas correctement sous Windows ; • ArgoUml un modeleur UML sous Licence BSD ; • Gaphor un modeleur UML sous GPL la version actuelle est 0.7.1 ;; • BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris; • Eclipse GMT-XUML • Eclipse UML2, Méta modèle UML2, sans interface graphique. • Netbeans 5.5 • Staruml, en version libre. • Acceleo, générateur de code source à partir de modèles UML.

Logiciels propriétaires • Rational Rose : Un des outil les plus important du marché - http://www.rational.com / Racheté par IBM • Together (rachété par Borland/Inprise) : Outil fortement couplé avec Java : - http://www.togethersoft.com; • ArgoUML : Outil Open Source; - http://argouml.tigris.org • Visio : Outil non complet de microsoft ; - http://www.microsoft.com/office/visio • Together, de Borland ; • Poseidon, basé sur ArgoUml (version commerciale) ;



� �

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

6.12.5 LES OUTILS SADT De nombreux outils traitent le formalisme SADT, en voici quelques exemples :

• ASA ASA est un outil supportant SADT et disponible sur SUN. Il comporte également un simulateur exploitant un langage textuel d'automate.

• DESIGN/IDEF Design/IDEF est un outil de Meta Software Corp., distribué par IGL traitant IDEF0/IDEF1. (sur PC/MAC/SUN) Les schémas SART sont convertibles en réseaux de pétri colorés, exploités par un outil de conception et de simulation HPCN. Un générateur de code en langage SML à partir des réseaux HPCN est également disponible. HPCN et SML sortent un peu de notre domaine d'application.

• SOFTPEN Softpen est un atelier logiciel utilisant comme représentation interne un langage de liste (LIPS). Il comporte un module SADT et un simulateur.

• SPECIFX SPECIFX est un outil édité par IGL supportant IDEF0.

6.12.6 Les outils de développement d’applications de base Comme outils de développement des architectures réparties, on retrouvera - langages de programmation classiques (procédural, orienté objet) - langages de 4ème génération (L4G) adapté aux approches de développement montantes : cas des « RAD » - ateliers de génie logiciel (AGL) adapté aux approches de développement descendantes : cas des « CASE » Les outils de développement d’interfaces graphiques (GUI) • Les API Window (SDK, MFC), MacOS, UNIX (Motif, X11) • OpenGUI [GTT] • Openside • Open UI ⇒⇒⇒⇒ Quelques autres L4G • IDEO [SAPIEN] • Power++ et Optima++ • 4D [ACI] • Delphi [Inprise/Borland] • Power Builder [] • SQL Window [Gupta] • GESERIX (ouvert à Unix) • Windo4GL • Jbuilder [Inprise/Borland] • Developpeur/2000 [Oracle] • Visual Basic [Microsoft] • C++Builder [Inprise/Borland] ⇒⇒⇒⇒ Quelques autres AGL • WinDev [PCSoft] • Power AMC • ArtEnterprise : AGL extrêmement puissant • Designer/2000 [Oracle] • ROSE [Rational] • GDPro [ASTI] 6.12.7 L’accès aux données • MTS : Microsoft Transaction Server : gestion de transactions • ORACLE [Oracle] • DB2 [IBM]



� �

• Informix [Informix] • SQL Server [Microsoft] • PostgreSQL • MySQL 6.12.8 L’aspect gestion du projet • MS Project [Microsoft] • PSN : Project Scheduler Network [Scitor] • BIRB [CGI] : l’outil s’appuie sur l’expertise auprès des clients • PERT intervient également dans la gestion du projet 6.13 Les questions que l’on doit se poser lorsqu’on est face à un système ou un projet (par

exemple de type client-serveur) Caractéristiques de l’Outil de Développement

Client / Interface graphique utilisateur

Sous quels systèmes d’exploitation ou système de multifenêtrage l’outils fonctionne-t-il ?

Outil Où réside l’outil – sur le serveur, sur le client ou sur les deux ? Plusieurs développeurs peuvent-ils l’utiliser simultanément ?

Middleware / Système d’exploitation / Protocoles

Si l’outil est réparti. Quels réseaux supporte-t-il ? Les liaisons sont-elles propriétaires ou utilisent-elle du middleware pour passer les données ?

Middleware / Accès à distance aux bases de données

Si ces données sont utilisées pendant le développement. Comment y accède-t-on ? Les chaînages multiples en parallèle sont-ils permis ?

Middleware / RPC / ORB L’outil peut-il être connecté à d’autres applications ? Comment ? Peut-il accéder aux bibliothèques de classes ? Comment ?

Serveur / SGBD / Référentiel Si l’outil (ou les données qu’il utilise) est archivé sur un serveur, pour quelles plates-formes matérielles est-il disponible ?

Caractéristiques des Applications créées par l’outil

Client / Interface graphique utilisateur

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 ?

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

Middleware / Système d’exploitation / Protocoles

Si les applications produites sont réparties, comment cela se passe-t-il ? Quel middleware est utilisé ? Quels système d’exploitation est utilisé ?

Middleware / Accès à distance aux bases de données

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 ?

Middleware / RPC / ORB 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 ?

Serveur / SGBD Si des applications réparties sont produites, quels serveurs matériels, systèmes d’exploitation et bases de données peuvent-elles utiliser ?

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



� �

- Facilité d’utilisation : L’utilisation ne demande pas trop d’efforts, tout au contraire, on note une facilité de compréhension, d’apprentissage, d’exploitation, de complétude et de sécurité. - Maintenabilité : être rapidement et facilement corrigé. Il peut supporter les modifications de ses spécifications. C’est l’un des avantages des nouvelles approches (objets, modèles, agiles…) - Portabilité : être installé sur une autre machine, un autre système d’exploitation ou une autre configuration logicielle ou matérielle. C’est l’un des avantages du langage Java. - Rendement : temps de réponse et le temps de traitement des fonctions acceptables. A titre d’exemple, le tableau ci-dessous récapitule certaines métriques de qualité effectuées pour le cas du logiciel SAHY (voir [Nkenlif04]).

MESURES FORMULES APPLICATION NUMERIQUE

DETAILS

Fréquence des Commentaires

FREQ_COM= NB_COM/NB_INST Avec NB_COM= nombre de commentaires NB_INST= nombre d’instructions exécutables

FREQ_COM=0,67

Permet d’évaluer la lisibilité du code.

Longueur des instructions

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

LONG_INST=4

Cette métrique constitue un indicateur de lisibilité du programme : les instructions longues sont plus difficiles à comprendre.

Nombre d’appels directs

Nombre de procédures différentes appelées par un composant

NPD= 8 [moyenne]

Cette métrique est un indicateur de complexité

Vocabulaire

n= n1+n2 avec n1= nombre d’opérateurs distincts n2= nombre d’opérandes distinctes

[type d’opérateurs distincts]

n=7

[moyenne par classe]

Cette métrique permet de caractériser la lisibilité d’un composant. Plus le nombre de « mots » employés (vocabulaire d’opérateurs ou opérandes) est élevé, plus l’effort de compréhension est élevé.

Nombre maximum d’imbrications

Nombre maximum d’imbrications des structures de contrôle utilisées dans le composant.

NMI=4 [moyenne par classe]

Une valeur importante de cette métrique se traduit par une mauvaise lisibilité du code qui affecte la maintenabilité.

Temps de développement

TD = NH/N en heure par homme Avec NH = nombre d’heures N = nombre d’hommes

TD = 7500

[5 Homme/année]

Volume de travail effectué

Taille moyenne de fichiers

TF = taille des fichiers en octets TF= 6000 [moyenne]

Espace de stockage

Nombre de lignes NL = nombre de lignes de code des modules

NL = 25500 [total]

Volume du programme

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

V=10700

Permet de nommer les indicateurs tels que les charges de développement, l’effort de test ou de maintenance.

Tableau 2 . Exemple de métriques prises (logiciel SAHY)



� �

77 EErr ggoonnoommiiee dd’’ AAppppll iiccaatt iioonnss GGrr aapphhiiqquueess ((WWeebb)),, DDéévveellooppppeemmeenntt eenn ééqquuiippee 7.1 Problématique de l’ergonomie : 7.1.1 Pourquoi aborder ce sujet maintenant ? Après avoir appréhendé les aspects techniques d’un déploiement multicouches, nous allons voir quelle forme et quelle organisation vous allez mettre en place. Après avoir appris comment aller chercher l’information demandée, nous allons maintenant voir comment la mettre à disposition de l’utilisateur. 7.1.2 Pourquoi accorder de l’importance à l’ergonomie de son site et plus généralement de ses

applications ? Quelque soit le domaine dans lequel vous intervenez, les vecteurs de communication que vous utiliserez seront aussi importants, si ce n’est plus important que le fond même de votre intervention. Petite notion de PNL (Programmation Neuro-Linguistique) [Morlais 01]

En regardant la figure ci-dessus, dans toute communication, ce qui importe, ce n’est pas l’étape 1 mais bien finalement l’étape 5 ! Les outils que l’on vous a donné lors des précédentes interventions permettent de passer de l’étape 2 à l’étape 3. Nous allons maintenant approfondir le passage de l’étape 3 à 4. Dans certaines entreprises multinationales les taches sont séparées mais c’est loin d’être le cas de toutes les structures. Vous aurez donc à faire l’étape 2 et 3 en prenant en compte les étapes 4 et 5. 7.1.3 Présentation de l’intervention L’objectif que nous nous sommes fixé ici, est de vous sensibiliser à l’importance de l’ergonomie et de vous donner quelques points de repère vous permettant d’être rapidement opérationnel, lors de vos prochaines expériences professionnelles. Certaines personnes passent plus de 4 ans à étudier l’ergonomie, nous n’avons évidemment pas la prétention d’être exhaustif, c’est la raison pour laquelle nous avons choisi de vous présenter des résultats sous forme de « règles », que l’on pourrait classer sous la rubrique « trucs et astuces » dans un magasine informatique, mais qui résulte d’études sérieuses. Pour vous permettre d’appréhender cela, nous allons d’abord nous intéresser à l’Ergonomie en rentrant un peu dans les « détails conceptuels ». Nous établirons ensuite une grille de critères à observer et nous terminerons par l’étude de site Internet pour voir concrètement la mise en application de ces principes. 7.2 Qu’est-ce que l’ergonomie ? [Morlais 01]

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

Figure 71. Illustration du principe d’une communication ergonimique

2- Formulation du message

3- Mode de transmission du

message

4-Réception du message

5- Concept 1- Concept



� �

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

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

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

- dans l’environnement de l’étape 3 : l’ergonomie peut permettre un environnement propice à la bonne transmission du message, de l’information,

- et au sein de l’étape 3 : l’ergonomie peut intervenir dans la construction du message, c’est ce qui nous concerne directement.

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

7.2.2 La place des technologies cognitives dans l’ergonomie Dans notre schéma, il s’agit du passage de l’étape 4 à l’étape 5, à savoir : comment se passe la conceptualisation du message rèçu.

7.2.2.1 Comment définir les sciences cognitives ? Les sciences cognitives sont un ensemble de disciplines qui étudient les activités liées aux fonctions cognitives, c'est-à-dire la perception, les représentations, la mémoire, le langage, le raisonnement, la motricité ou l'apprentissage. Cette étude se fait autant sous l'aspect humain de ces fonctions que sous ceux de la modélisation et de la simulation artificielle, en tenant compte de la validité biologique de tels modèles. Classiquement, les champs disciplinaires intéressés par les sciences cognitives sont :

- les Sciences Humaines : Psychologie cognitive & Linguistique pour l'étude de l'humain et du langage ; - les Neurosciences : la Neurobiologie (de la Neuroanatomie à la Neurochimie) pour l'étude des

composantes biologiques ; - les Sciences de l'Artificiel : mathématiques, intelligence artificielle (apprentissage, connexionnisme, etc.)

pour la modélisation. - D'autres sciences peuvent encore s'ajouter à cette liste, telles la philosophie, l'épistémologie ou

l'anthropologie (parmi les sciences humaines), ainsi que la physique (pour son apport aux Sciences de l'artificiel).

La création des champs d'étude comme la psycholinguistique (psychologie et linguistique), la neuropsychologie (neurologie, psychologie et neurosciences) ou l'intelligence artificielle (informatique, logique et linguistique) marquait déjà cette nécessité bienheureuse d'une vision plus globale en franchissant les frontières classiques entres les disciplines.



� �

Les sciences cognitives forment ainsi un domaine de recherche qui se nourrit de la confrontation des points de vue des divers secteurs liés à l'étude de la cognition, pariant sur les possibilités d'interfécondation des visions et sur le développement des études transcendant les diverses disciplines

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

7.2.3 Les différents domaines d’application de l’ergonomie Ils sont tout ce qu’il y a de plus divers et varié. On peut dire que les premiers ergonomes étaient Ford et Taylor. Ce sont les premiers à avoir complètement redéfini les conditions de travail pour améliorer la productivité. En décomposant le processus de production ils ont rendu la fabrication des voitures accéssible à tout le monde. Comme le dis le conseil de la SELF, l'ergonomie peut être comprise comme " l'adaptation du travail à l'homme ". Par la suite, on retrouve les ergonomes dans les domaines ou il a fallut optimiser les conditions de travail. C’est à dire dans tous les milieux soumis à de forte contrainte de vitesse, de précision, de stress… On peut citer les aéroports, les hôpitaux, les centre de service d’urgence, l’informatique (harware et softeware), l’automobile et parfois –mais plus rarement– dans le domaine du mobilier. Pour approfondir la question, vous pourrez consulter plus tard les sites d’ergonomes que nous avons mis sur le réseau.

7.3 La prise en compte de l’ergonomie dans le développement d’IHM et plus spécifiquement dans le développement d’applications Web

7.3.1 L’« ergonomie de fond », un préalable à la mise à disposition de l’information

7.3.1.1 Importance et réalisation de l’organisation générale de l’application Le challenge d’une application Web est de rendre accessible via un petit écran de 800 x 600 pixel, des informations ou des produits qui étaient parfois disposés dans des entrepôts de plusieurs centaines de mètres carrés. Il faut donc pouvoir retranscrire l’appréhension visuelle qu’avait l’utilisateur en arrivant dans son entrepôt ou sa pièce. Pour cela, il est important de rendre lisible la structure de votre site. Comment :

- avec un plan du site si la structure n’est pas suffisamment lisible, ou si le site est trop grand pour que l’utilisateur ne puisse sans effort avoir une vue d’ensemble,

- avec une signalétique cohérente tout au long de l’application Remarques :

- Notez que la structure « visuelle » que vous donnez à votre utilisateur n’est pas forcément calquée sur l’architecture technique que vous avez déterminée au préalable.

- Dans le cas d’un site commercial ou vous cherchez à vendre quelque chose, des études ont montré que vous avez le droit à 3 cliques et moins d’une minute pour « ferrer » le client !

7.3.1.2 Les spécificités du Web Mode de fonctionnement des moteurs de recherche, importance du titre des pages et des mots clefs, présentation du « profiling ».

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



� �

Exemple d’en-tête :

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

7.3.2 L’ergonomie des applications Web

7.3.2.1 La densité de l’affichage � Pour chaque application, il faut trouver un compromis entre la densité d’informations affichées dans chaque

fenêtre et le nombre de fenêtres : - une forte densité d’affichage entraîne davantage d’erreurs de la part de l’utilisateur et augmente le temps

nécessaire pour repérer une information ; - une trop grande dilution de l’information dans un trop grand nombre de fenêtres gêne l’utilisateur dans sa

perception globale de l’application.

7.3.2.2 La disposition des éléments dans les fenêtres � Pour regrouper les données (regroupement au sein de rubriques) et définir leur enchaînement (chronologie de

présentation des données affichées ou à saisir), tenir compte des habitudes de travail de l’utilisateur : - fréquence d’utilisation, - séquence d’utilisation dans la tâche en cours, - importance dans le contexte (saisies obligatoires, optionnelles).

Présenter les groupes de données les plus importants selon le critère privilégié (par exemple, fréquence d’utilisation) vers le haut de la fenêtre. Remarque : si le travail de l’utilisateur s’appuie sur un formulaire papier, et si ce formulaire est bien construit, faire en sorte que la disposition des champs dans la fenêtre soit proche de la structure du formulaire.

� Aligner verticalement les champs de saisie et/ou d’affichage avec leurs libellés ; la justification peut se faire de trois manières :

- 1 : si les « libellés » sont de dimension sensiblement identique, justifier les champs et les libellés à gauche ; - 2 : si les libellés sont de dimensions très variables, justifier ces libellés à droite et les champs à gauche ; - 3 : il est également possible de disposer les libellés au dessus des « champs de saisie » ; il faut alors les justifier à gauche.



� �

Nom : Profession : Prénom : Ancienneté : Age :

Nom : Profession : Prénom : Profession du

conjoint :

Adresse personnelle

(domicile) : Nombre d’enfants à

charge :

Nom : Nombre d’enfants à charge : Prénom : Profession : Adresse personnelle (domicile) : Profession du conjoint :

[Morlais 01]

� Attribuer un libellé à chaque donnée et à chaque groupe de données. � Séparer les différentes catégories d’informations par des espaces et éventuellement par des boîtes de groupe (=

encadrements).

[Morlais 01]

� Placer l’en-tête de groupe au dessus de la boîte de groupe, et en incrustation dans le cadre s’il y en a un. � Ne pas utiliser de boîte de groupe pour les boutons de commande. � Ne pas utiliser systématiquement des boîtes de groupe quand il y a un en-tête : trop de cadres peuvent gêner la

lisibilité globale de la fenêtre. Utiliser alors des en-têtes de groupe sans représenter une boîte de groupe.

7.3.2.3 La présentation des listes et des tableaux � Attribuer systématiquement un titre aux listes et aux tableaux ; ces titres permettront à l’utilisateur de se

repérer facilement et rapidement.

Figure 72. Cas 1 (libellés de dimension sensiblement identique)

Figure 73. Cas 2 (libellés de dimension différente)

Figure 74. Cas 3 (libellés positionnés au dessus des champs de saisie)

Figure 75. Utilisation des boîtes de groupe (Word)



� �

� Si une liste ou un tableau est muni d’un ascenseur (car sa taille/format ne permet pas de voir l’intégralité de son contenu), alors : - Ascenseur vertical : les en-têtes de lignes de données doivent défiler mais les en-têtes de colonnes doivent

toujours rester visibles ; - ascenseur horizontal : les en-têtes de colonnes doivent défiler mais les en-têtes de lignes de données

doivent toujours rester visibles. - Respecter les alignements standards des traitements de texte : - libellés en général à gauche, - numériques à droite. Eviter les alignements centrés (effets de vagues verticales).

� Les colonnes doivent être séparées par un double espace (1 caractère blanc x 2). Si cela ne peut pas être fait

(par manque de place), séparer les colonnes par des traits (lignes verticales). � Comment organiser les éléments à l’intérieur d’un tableau/d’une liste (c’est-à-dire sur quoi se baser pour

établir la chronologie des données) ? - adopter l’ordre respectant les habitudes de travail de l’utilisateur ; - le cas échéant, utiliser l’ordre alphabétique ou numérique.

7.3.2.4 Les éléments textuels � Utiliser le vocabulaire appartenant au domaine d’activité des utilisateurs. � Utiliser des termes explicites et non ambigus. Faire des phrases (ou expressions) simples, c’est-à-dire

facilement compréhensibles par l’opérateur ; préférer les formes affirmatives. � Indiquer les unités de mesure utilisées (en abrégé si elles sont connues de l’utilisateur). � Eviter d’utiliser des abréviations, sinon, fournir chaque fois que c’est possible des abréviations bien choisies :

- utiliser uniquement celles qui sont le plus largement adoptées par les utilisateurs car ces derniers pourront avoir rencontré certaines abréviations qui signifient autre chose ;

- préférer la contraction (omission des lettres internes) pour les mots courts ; - préférer la troncature pour les mots longs (omission des lettres finales). - Par souci d’homogénéité, ne pas utiliser de synonymes : désigner toujours un même objet ou une même

action par le même libellé.

� Lors de la création de listes d’éléments, on peut être confronté à des éléments de texte trop longs pour contenir dans l’espace d’une ligne de la liste. Dans ce cas, supprimer des parties de texte dans le milieu du libellé et y insérer des points de suspension, conservant ainsi le début et la fin du libellé de l’élément. Attention toutefois : dans certains cas, il sera plus judicieux de conserver le début du libellé et de faire suivre ce dernier par des points de suspension.

� Repérer chaque champ, liste, tableau, colonne ou groupe de données par un libellé. On distingue trois grands types de libellés : - le libellé de champ, à utiliser pour identifier une donnée affichée ou à saisir ; - l’en-tête de colonne, à utiliser pour identifier la colonne d’un tableau ou d’une liste ; - l’en-tête de groupe, à utiliser pour identifier un ensemble de données rassemblées sous la forme d’un

groupe.

7.3.2.5 La typographie � Concernant la taille des caractères :

taille minimum : 8 points ; des caractères de plus petite taille sont quasiment illisibles ; taille maximum : 16 points ; l’utilisation de caractères de plus grande taille gêne la lisibilité.

� Choisir la police de caractères en fonction de critères de lisibilité (éviter l’italique). � Eviter d’utiliser plus de trois polices de caractères différentes dans une même fenêtre ou sur plusieurs fenêtres

affichées simultanément. � De manière générale, utiliser une seule police de caractères dans un champ. Toutefois, il est possible d’utiliser

des codages particuliers (police différente, couleur, italique, gras, souligné...) pour différencier certains textes tels que des mots clès, des liens, des libellés de champs de saisie obligatoire, etc.

� Pour tous les libellés (champs de saisie et champs d’affichage, option de menu, boutons d’option, titre, etc.) utiliser une majuscule à l’initiale. Ne mettre donc en majuscule que la première lettre du premier mot du libellé et aucun autre mot de ce libellé.

7.3.2.6 La couleur La couleur peut être employée pour coder visuellement l’information : différenciation et identification des informations affichées.

� La couleur ne doit pas être le seul moyen utilisé pour communiquer de l’information et ne devrait pas être le seul élément qui distingue deux objets ; il doit y avoir d’autres indicateurs (libellés, forme, disposition) ;



� �

appliquer ce principe surtout pour tenir compte des utilisateurs « daltoniens » ou « achromates » mais aussi pour les écrans monochromes (même si ces derniers sont « rares » !)

� Choisir les couleurs en gardant à l’esprit que l’objectif est de faciliter la lisibilité des informations affichées. C’est pourquoi certaines associations de couleurs doivent être évitées. Ainsi, essayer de ne jamais utiliser ensemble : - le rouge avec le bleu, - le jaune avec le violet, - le jaune avec le vert.

Pour le fond des fenêtres, éviter les teintes de rouge, de jaune et de ses dérivés (vert, orange, …). Privilégier plutôt le gris pâle, sinon du bleu foncé. Pour de l’information que l’utilisateur doit lire, éviter le bleu pâle (et les couleurs pâles en général).

� Homogénéité : au sein d’une même application et entre différentes applications destinées à un même groupe d’utilisateurs, toujours choisir les mêmes “ codages couleur ”.

� Respecter les règles d’association conventionnelles entre la couleur et sa signification : - vert : signifie que tout se passe correctement, - jaune ou orange : attention, vigilance, - rouge : alerte, danger, interruption.

� Eviter d’utiliser plus de 5 ou 6 couleurs différentes dans une même fenêtre (mais également au sein d’une même application). Au delà de 5 ou 6, cela entraîne une surcharge visuelle et l’utilisateur éprouve des difficultés à saisir le rôle joué par la couleur au sein de l’application.

� Concernant les états sur les imprimantes noir et blanc : s’assurer que chaque couleur reste visible sur les impressions (il doit y avoir correspondance entre les couleurs qui apparaissent à l’écran et les niveaux de gris des sorties papier ; si le nombre de niveaux de gris disponible est insuffisant, prévoir des hachures).

7.3.2.7 Les icones Les icones peuvent avoir deux fonctions :

- aider à identifier la nature d’une information, sous forme d’icone, - représenter une action par une icone associée à un bouton de commande.

Exemple : l’icone loupe (ou jumelles) est associé au bouton de commande <Rechercher>. � Attention, les icones utilisées doivent être représentatives de l’action ou du concept que l’on souhaite

représenter, autrement dit elles doivent être explicites. Il paraît néanmoins « prudent » de doubler les icones d’un libellé.

� Homogénéité : quand une icone est utilisée pour représenter quelque chose, la conserver pour l’ensemble de l’application. Autrement dit, ne pas utiliser deux ou plusieurs icones différentes pour désigner une seule et même action ou un seul et même concept.

L’utilisation des onglets � Utiliser les onglets pour éviter les successions de boîtes de dialogue ou un trop grand nombre de boutons. � Eviter d’utiliser plus d’une rangée d’onglets, car la manipulation de 2 ou 3 rangées d’onglets est complexe. �

Quand le principe des onglets est utilisé, si ces derniers sont liés (dépendants), les boutons <OK> et <Annuler> doivent être placés en dehors de l’onglet. Si les onglets sont indépendants, ces boutons doivent être placés sur chacun des onglets : le bouton <Annuler> devient <Fermer> et la demande de confirmation devient facultative (<OK> facultatif).

� Centrer les libellés des onglets et les afficher sur une seule ligne. � Aligner les languettes des onglets à gauche et les accoler les unes aux autres.

Figure 76. Utilisation de plusieurs rangées d’onglets ( à ne pas faire !)



� �

7.4 Etude : analyse des supermarchés « on line » : fidélisation du client par l’ergonomie Les supermarchés en ligne intègrent toutes les problématiques qui nous intéressent :

- Interfaçage avec des bases de données - Nombre d’information à transmètre très important, donc optimisation maximum de l’écran, et travail

ergonomique important. (EN grande Distribution, on parle de rendement au m², on pourrait ici parler de rendement au pixel !)

7.4.1 Présentation du site c-mescourses.com

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

7.4.1.2 L’acte d’achat - La recherche du produit - La sélection du produit - Le payement - La livraison

7.4.2 Présentation du site Houra.com

7.4.2.1 L’environnement d’achat - le portail - Le plan du site - Les publicités

7.4.2.2 L’acte d’achat - Recherche du produit - Selection du produit - L’inscription - Le payement

7.4.3 Synthèse et Description d’un supermarché « on line » standard

7.4.3.1 L’environnement d’achat - Le portail - La communication sur le site

7.4.3.2 L’acte d’achat - Recherche et selection du produit - Payement et livraison - conclusion TD : Etudier les 3 situations présentées ci-dessus.



� �

7.5 Conclusion sur l’ergonomie Comme nous avons put le constater ensemble, la bonne ergonomie de ses applications Web ne tient pas à grand

chose, il suffit de faire attention à un certain nombre de critères. Notez tout de même que, la prise en compte de ces recommandations ne se substitue pas à la connaissance des utilisateurs ni à la connaissance de leur travail ; elle ne remplace pas une analyse du travail, elle est simplement complémentaire à un travail d’analyse de la cible. Ces recommandations sont particulièrement applicables pour les sites Internet qui ne ciblent pas de public particulier. Quand on élabore un Intranet ou une application spécifique, l’analyse du fonctionnement et du comportement des utilisateurs peut amener à ne pas prendre en compte certaine recommandation, voir à faire le contraire !

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

7.6.1 Le développement en équipe La production d’une application 3D fait intervenir au oins 4 étapes principales : [Lemasson]

1- La conception pour fixer les objectifs et les méthodes employées lors du projet. 2- L'implémentation pour réaliser les composants du projet. 3- L'intégration pour associer les différents composants du projet. 4- Les tests pour vérifier que le comportement des composants assemblés est bien celui attendu.

Etant donné qu’un développement est un processus de production numérique, les étapes ci-dessus ne s’enchainent pas forcément toujours de la même façon. Car à tout moment, on peut effectuer des ajustements (personnage, décor, interface…). Il est donc important de faciliter le « flux de travail », en sonsidérant le travail réalisé comme un liquide ayant une source, une destination et un débit. On devra s’assurer que le travail de chacun des membres de l'équipe démarre au bon endroit et fini bien là où il doit finir (dans votre application et pas à la poubelle), ceci pour assurer un développement continu évitant de mauvaises surprises.

7.6.2 Mesures pour gagner en efficacité Voici quelques mesures valables pour différents éléments de votre projet, sans exception, tels que : modélisation, texture, animation, documents de conception, programmes ... • Partage et sécurité des données

Chaque membre de l'équipe doit avoir accès immédiatement à tous les documents du projet qui lui sont nécessaires, y compris la documentation.

• Gestion des versions des fichiers Pour chaque élément du projet, on doit connaître sa version actuelle et qui l'a modifié en dernier.

• Division pour régner On doit faire en sorte que chaque élément du projet ne traite que d'un domaine limité et soit ré-utilisable. Tout grand problème devra être divisé en sous problèmes plus simples.

• Compilation quotidienne On doit pouvoir compiler le projet tous les jours pour connaître létat d'avancement et pouvoir évaluer où l'on en est.

NB : Ces mesures doivent être accompagnées d'autres mesures élémentaires comme les conventions de nommage, ou l'affectation des tâches et des délais...



� �

7.7 L'efficacité du développement point par point

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

MonProjet - DocumentsDeConception

� documents de conception : Références, scénario, design et ainsi de suite - Ressources Virtools du projet

� composants du projet 3D, les textures, les modèles 3D les comportement de caméra ... - Modélisations

� fichiers de conception de vos modèles 3D de votre projet, c'est à dire les fichiers 3DSMax - Graphisme2D

� fichiers conception de vos graphisme, c'est à dire les fichiers photoshop ou autre. - Compilation

� dernière version compilée du projet, sous forme de fichiers VMO pour notre exemple. - Prototypes

� prototypes de vos composants.

7.7.2 Systèmes de gestion de versions

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

7.7.2.2 Application concrète : une infrastructure Voici un exemple d’infrastructure technique à mettre en place pour votre projet 3D :

- un serveur distant pour : � stocker votre projet sous la forme d'un répertoire géré par SVN � effectuer les sauvegardes quotidiennes du projet vers une autre destination (CobianBackup)

- des postes de travail clients équipés : � d'un répertoire local de travail où sera placé la dernière version du projet par SVN � des logiciels de travail : 3dsMAx, Virtools, photoshop....

N’oubliez pas que lorsque l'équipe devient importante (>3), une petite amélioration peut consister à héberger sur votre serveur le site internet de l'équipe. Réalisé sous la forme d'un site de news, il vous permettra d'assurer la communication du projet, en interne et en externe.



� �

7.7.3 Diviser pour mieux régner Il est important de scinder en fichiers de plus petite taille, tout fichier contenant une grande quantité de données. Ceci nous simplifie la manipulation du contenu de chaque sous fichier, et même sa maintenance. Ceci revient au découpage en modules de plus en plus petits et faciles à contrôler pour des programmeurs. Le fractionnement d’un fichier de données favorise également le travail collaboratif (plusieurs personnes travaillant en même temps sur ces données). Voici quelques critères pouvant vous amener à diviser un fichier :

- Le fichier est de plus en plus difficile à manipuler - Plusieurs membres de l’équipe doivent intervenir régulièrement sur le contenu du fichier.

Une conséquence supplémentaire de cette mesure c’est le fait de pouvoir créer des composants indépendants et donc réutilisables (pouvant être réutilisés dans un autre projet pour gagner en temps).

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



� �

BBII BBLL II OOGGRRAAPPHHII EE [Arbogast06] Sébastien Arbogast, MDA par la pratique, Date de publication : 18 mai 2006. http://sarbogast.developpez.com/ [Bezivin04] Jean Bézivin, Frédéric Jouault et Patrick Valduriez, On the Need

for Megamodels Preliminary Draft, OOPSLA 2004. [Craig03] Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley, 2003 [Fowler03] Martin FOWLER, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Paperback: 192 pages,

Publisher: Addison-Wesley Professional; 3 edition (September 19, 2003), Language: English, ISBN: 0321193687 http://martinfowler.com/books.html#uml

[Greenfield03] Jack Greenfield et Keith Short, Software Factories Assembling Applications with Patterns, Models, Frameworks and Tools, OOPSLA, 2003.

[Grossglauser07] Jean-Pierre Grossglauser, Introduction aux tests unitaires avec PHPUnit 3.1 Dernière mise à jour : 15/08/2007, http://jp-grossglauser.developpez.com/tutoriels/langages/php/phpunit/

[KaiserCottet01] Claude Kaiser, LES RÉSEAUX DE PETRI, Reproduit avec la permission de Francis Cottet, ENSMA [Lemasson] Guillaume Lemasson, Introduction au développement en équipe pour la 3D

Date de publication : 10/04/07, http://lemasson.developpez.com/ [Linsolas09] Romain Linsolas, Contrôler la qualité de ses projets avec Sonar, mise à jour : 13/08/2009,

http://linsolas.developpez.com/articles/sonar/ [MANTEL07] Gilles MANTEL, Test-Driven Requirements, octobre 07, Valtech Technology [Meyer 90] B. Meyer, « Conception et programmation par objet, pour du logiciel de qualité » Inter éditions 1990. [Morlais 01] Christian de la Morlais, Ergonomie des applications Web, Séminaire : DataWeb et NTIC, IUT FV de Bandjoun,

Département d’Informatique, 2001 [Nkenlif04] Marcellin Nkenlifack, Modélisation Objet et Développement d’un Atelier de Simulation des Automatismes Industriels

Hybrides, Thèse de Doctorat/PhD, ENSP, Univ Yaoundé1, Cameroun, 2004 [OMGWWW] www.omg.org (site Web de l’OMG contenant les spécifications sur le métamodèle UML et le processus MDE) [Parrend07] Pierre Parrend, Introduction à MDA : Principe, Date de publication : 04/12/2006

http://pparrend.developpez.com/tutoriel/mda-intro/ [ROQUES07] Pascal ROQUES, UML est-il soluble dans les méthodes agiles ?, octobre 07, Valtech Training [Schach 92] Stephen R. Schach, Practical Software Engineering, IRWIN, Boston, 1992 [Schwaber04] Ken Schwaber, Agile Project Management with Scrum, Microsoft Professional, 2004. [Scott02] Scott Ambler , Agile Modeling: Effective Practices for Extreme Programming and the

Unified Process, Wiley, 2002. Autres sources

• www.cui.unige.ch/ScDep/Cours/GenieLogiciel/index.html • http://www.gpa.etsmtl.ca/cours/gpa77 • http://cui.unige.ch/ScDep/Cours/GenieLogiciel/ • http://www.cours.polymtl.ca/inf2300



� �

ANNEXE :

Le « Lean thinking »

L’utilisation du mot lean fait référence à l’organisation des chaînes de production d’industriels japonais qui ont révolutionné les méthodes de production dans les années 80. Le plus fameux d’entre eux est le constructeur automobile Toyota, dont le système de production est souvent représenté sous la forme d’une maison, le toit représentant les valeurs vers lesquelles tend Toyota.

Système de production de Toyota Ces valeurs sont supportées par les deux piliers su ivants : - Just-in-time : notion de produire la bonne pièce à la bonne quantité et au bon moment. Sous cette appellation, on retrouve un ensemble de méthodes tournées vers l’organisation de sa production selon un mode « pull », c’est-à-dire organiser sa chaîne de production de manière à ce qu’une étape ne produise pas un élément tant qu’il n’est pas demandé par l’étape suivante. Cela revient à piloter sa chaîne de production en fonction de son carnet de commande et plus en fonction d’une estimation de la demande et de la capacité de production de sa chaîne. Cette organisation permet également de diminuer ses stocks au maximum, voire de les réduire à zéro. - Jidoka : notion d’empêcher un maillon de la chaîne de passer une pièce défectueuse au maillon suivant. Si un défaut est identifié sur un élément dans la chaine de production, on arrête immédiatement la chaîne, on répare le défaut, et on s’assure qu’il ne se reproduira plus, on redémarre ensuite la chaîne de production. Les défauts peuvent provenir des machines, des matières premières, de la formation du personnel, etc. Parmi les fondations, on trouve les concepts suivan ts : - Kaizen : amélioration continue des processus, c’est-à-dire tendre vers la perfection en impliquant tous les acteurs depuis le top-management jusqu’à l’opérateur. - 5S : la gestion de l’espace de travail, c’est-à-dire garder un espace de travail propre, rangé, efficace. Pour plus de détails, le lecteur pourra consulter l’ouvrage référence en la matière : The Machine That Changed the World : The Story of Lean Production, de Womack, Jones, et Roos.