Formation Java. Synthèse de lecture «UML : Unified modeling language»

Transcription

1 Formation Java Synthèse de lecture «UML : Unified modeling language» 1

2 Table des matières Note au lecteur : Introduction Qu est-ce que UML Le processus de développement conceptuel et l approche objet Les critiques, tout n est pas idéal! La modélisation et les modèles Penser objet avec UML, pour concevoir objet Les notions UML Les artefacts Les notations Les paquetages La classe paramétrable les associations les contraintes Les restrictions l agrégation la généralisation La classe association La classe abstraite L historique Les modèles et diagrammes Les diagrammes d activités Les diagrammes de classes Les cas d utilisations L illustration suivante d un modèle conceptuel d un point de vente : Les diagrammes de collaborations Les diagrammes d objets Les diagrammes de séquence Les diagrammes d états-transitions Les diagrammes de composants Les diagrammes de déploiements Commentaires et analyse Conclusion Sample UML and Related Notation Diagrams Sample Development activities Bibliographie : Webographie :

3 Unified Modeling Language. Note au lecteur : Ce document est une synthèse de lectures sur le sujet UML, qui consiste en un court résumé et amalgame de parties de lectures, jugées les plus intéressantes (sous toute réserve) et capables de faciliter la compréhension d un lecteur, à partir de plusieurs sites Internet et livre spécialisés sur le sujet ainsi que d autres livres de références sur lesquels certains commentaires et opinions personnels prennent assises. La synthèse a comme but principale de permettre à l étudiant qui produit ce document de mieux connaître le sujet et peut-être d intéresser certains collègues d études. Toutes la documentation utilisée pour produire ce texte est énumérée dans la Bibliographie et la Webographie. L auteur de cette synthèse, qui ne s approprie aucune originalité ou crédit pour ce texte, a fait tous les efforts de notations appropriés afin de permettre aux lecteurs éventuels d accorder le crédit aux auteurs originaux et de permettre aux lecteurs de retracer facilement les sources de la documentation. 1. Introduction 1 Le design et la programmation orientée objet sont de plus en plus utilisés et surtout avec la grande popularité de JAVA, il devient primordial de maîtriser l analyse et le design orientés objet (A/DOO) afin de créer des systèmes aussi robustes qu efficaces Globalement l UML permet aux programmeurs, par une meilleure compréhension du problème et de ses processus, de créer de meilleurs design orientés objet en appliquant des principes connus et des méthodes intuitive d acquisition de savoir-faire. Pour les programmeurs, des connaissances sur ce sujet sont maintenant incontournables. 2. Qu est-ce que UML 2 UML (Unified Modeling Language) est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE. UML est le résultat d'un large consensus et s est imposé comme une norme de notation et de connaissances servant à spécifier, visualiser et construire la démonstration de programme ou logiciel. En 1997, UML est devenu une norme OMG (Object Management Group) qui est un organisme à but non lucratif créé en L'OMG a un rôle est de promotion des standards 1 Unified Modeling Language, Craig Larman 2 Internet : 3

4 qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes. UML permet donc de modéliser une application selon une vision objet. UML possède plusieurs facettes. C'est une norme, un langage de modélisation objet, un support de communication, un cadre méthodologique. UML est tout cela à la fois, ce qui semble d'ailleurs engendrer quelques confusions Le processus de développement conceptuel et l approche objet 3 La compréhension et la décomposition d un problème impliquent l identification des concepts, des attributs et leurs associations avec le domaine jugé important. Le résultat de cette démarche donnera un «modèle conceptuel» qui clarifiera l allocation des responsabilités assignées aux objets par l illustration des envois de messages dans le diagramme. Il y a donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts de base de l'approche objet sont stables et largement éprouvés. De nos jours, programmer "objet", c'est bénéficier d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un réflexe quasiautomatique dès lors qu'on cherche à concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes. Les premiers compilateurs C++ datent du début des années 80 et de nombreux langages orientés objets "académiques" ont étayés les concepts objets (Eiffel, Objective C, Loops...). 3.1 Les critiques, tout n est pas idéal! 4 L'approche objet est moins intuitive que l'approche fonctionnelle. Malgré les apparences, il est plus naturel pour l'esprit humain de décomposer un problème informatique sous forme d'une hiérarchie de fonctions et de données, qu'en terme d'objets et d'interaction entre ces objets. Or, rien dans les concepts de base de l'approche objet ne dicte comment modéliser la structure objet d'un système de manière pertinente. Quels moyens doit-on alors utiliser pour mener une analyse qui respecte les concepts objet Sans un cadre méthodologique approprié, le dérapage de conception est inévitable. L'application des concepts objet nécessite une très grande rigueur. Le vocabulaire imprécis est un facteur d'échec important dans la mise en oeuvre d'une approche objet (risques d'ambiguïtés et d'incompréhensions). Beaucoup de développeurs (même expérimentés) ne pensent souvent objet qu'à travers un langage de programmation. Or les langages orientés objet ne sont que des outils qui proposent une manière particulière d'implémenter certains concepts objet. Ils ne valident en rien l'utilisation de ces moyens techniques pour concevoir un système conforme à la philosophie objet. 3 Unified Modeling Language, Craig Larman 4 Internet : 4

5 Aussi, comment comparer deux solutions de découpe objet d'un système si l'on ne dispose pas d'un moyen de représentation adéquat Il est très simple de décrire le résultat d'une analyse fonctionnelle, mais qu'en est-il d'une découpe objet Pour remédier à ces inconvénients majeurs de l'approche objet, il nous faut donc : 1) Un langage permettant des représentations de concepts abstraits, limitant les ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant des langages orientés objet), facilitant l'analyse (simplifier la comparaison et l'évaluation de solutions). 2) Il faut penser objet dès le départ et disposer d'un outil qui donne une dimension méthodologique à l'approche objet. 3.2 La modélisation et les modèles 5 Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité en vue d'une utilisation précise. Un modèle est une vue très subjective de la réalité. 3.3 Penser objet avec UML, pour concevoir objet. 5 Pour penser et concevoir objet, il faut savoir jongler avec des concepts abstraits, indépendants des langages d'implémentation et des contraintes techniques. Les langages de programmation ne sont pas un support d'analyse adéquat pour "concevoir objet" et constituent un cadre trop rigide pour mener une analyse itérative. Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de cardinalités. La modélisation est très adaptée à notre façon de résoudre un problème en décomposant en sous problèmes. Le comportement regroupe les compétences de l objet. Ce comportement est décrit par ce que l on appelle des méthodes, ou opérations déclenchées par des stimulations externes appelées messages. Le terme " objet " peut être vague. Dans le monde réel, un objet peut représenter un ensemble de choses similaires. Dans la modélisation objet, l objet est une chose précise. On utilisera donc l expression " instance d objet ". En contre parti, l ensemble de choses similaires sera appelé " classe d objet ". Les interactions entre objets se représentent au moyen des diagrammes de collaboration ou des diagrammes d objet. 5 Internet : 5

6 Une classe objet est une définition d un type d objet. Elle décrit un groupe d objets ayant les mêmes propriétés et le même comportement, même structure et même ensemble de méthodes. 4. Les notions UML Les artefacts Les artefacts sont les représentations diagrammatiques des objets, actions ou activités et de leurs multiples influences, qui prennent place dans la planification et l élaboration d un programme. 4.2 Les notations Une note est un commentaire placé sur un diagramme. Elle est attachée à un élément (du diagramme par une ligne en pointillé) sans explication sauf si elle est une contrainte si elle possède le stéréotype <<contrainte>>. 4.3 Les paquetages Les paquetages offrent un mécanisme général pour la partition des modèles et le regroupement des différents éléments de la modélisation. On peut utiliser les stéréotypes <<catégorie>> et << sous systèmes>> permettant de distinguer les paquetages. Un paquetage peut contenir d autres sous-paquetages sans limites de niveaux. Certains éléments du paquetage peuvent être " public " ou implémentation. (visible ou pas de l extérieur). UML décrit les éléments «public» si ces derniers sont dans l interface du paquetage. 4.4 La classe paramétrable Les classes paramétrables sont des modèles de classe. Ces dernières doivent être instanciées avec des paramètres pour obtenir une classe concrète. UML représente une classe paramétrable de la façon suivante : Les types de classes particulières sont définis par des stéréotypes. Par exemple : << utilitaire >> Ce genre de classe permet de regrouper des éléments sans vouloir construire une classe complète (ex : des fonctions mathématiques). 6 Internet : 6

7 4.5 les associations Les associations en UML sont représentées par des traits continus entre les classes. Pour plus de renseignements, il est utile de nommer les associations. Pour cela, le nom de ces dernières se met au milieu de la ligne qui symbolise l association, en italique sous forme verbale en général. Le sens de lecture de l association peut être précisé au moyen des symboles " < " et " > ". De même, pour plus de compréhension de l association, on peut indiquer à chaque extrémité le rôle qui décrit comment une classe voit une autre classe au travers d une association. Le nommage des rôles est sous forme nominale. 4.6 les contraintes Pour les associations, on peut introduire des contraintes. Une contrainte est une relation sémantique entre des éléments du modèle qui spécifie les conditions et les propositions qui doivent être respectées. Certains types de contraintes (comme une contrainte d'association "ou") sont prédéfinis dans UML, les autres devant être définis par les utilisateurs (ex : ordonnée ). Une contrainte est représentée par un texte entre crochets ( {} ). 4.7 Les restrictions La restriction des associations est possible avec la notation UML. La restriction consiste à sélectionner un sous ensemble d objets qui participent à l association. La sélection des objets est caractérisée par un attribut que l on appelle clé. Tous les objets de la classe qui vérifient la clé feront partie de l association. 4.8 l agrégation Une agrégation représente une association non symétrique dans laquelle une extrémité de l association joue un rôle prédominant par rapport à l autre extrémité. ( par exemple, une classe qui fait partie d une autre, une action d une classe impliquant une action dans une autre classe...). L agrégation en UML se représente par un petit losange blanc du côté de l agrégat. Il existe un cas particulier de l agrégation. On l appelle la composition ; il s agit de l association correspondant à la contenance. UML représente la composition par un losange noir 4.9 la généralisation La généralisation est représentée par une flèche qui pointe de la classe la plus spécialisée vers la classe plus générale. Elle exprime le fait que les éléments d une classe soient décrits dans une autre classe. Les attributs, opérations et associations sont hérités par les sous classe. La tête de la flèche est caractérisée par un triangle vide. 7

8 4.10 La classe association UML définie les classes associations qui ont pour but d ajouter des attributs et des opérations à l association. UML représente la classe associative par une classe reliée par un trait en pointillé sur l association concernée La classe abstraite UML représente les classes abstraites par une classe dont le nom est " classe abstraite " et est notée en italique. Les classes abstraites ne sont pas instanciables. Elles servent de spécification 4.12 L historique Il peut sembler nécessaire de mémoriser les sous-états qui ont été actifs dans une agrégations d états. On parle alors d histoire. En mettant le symbole " H " dans un super état, on indique que l on voudrait mémoriser les sous états. " H* " indique que l on veut mémoriser les sous états actifs quel que soit la profondeur de l imbrications des sous états. Avec les automates, on peut indiquer la communication entre objets. En effet, les automates associés aux objets évoluent par l envoi d événements entre automates. Afin d indiquer l envoi d événement vers une classe, UML définit la syntaxe suivante : Evénement ( Arguments ) [ condition ] / Action-Cible.Evénement ( arguments ) 5. Les modèles et diagrammes 7 Il y a les modèles statiques et le modèles dynamiques. Les premiers donnent des informations sur les propriétés structurelles d un système alors que les modèles dynamiques décrivent les propriétés comportementales d un système. Le modèle d analyse pour recherche sur le domaine et le problème et le modèle de design pour la relation avec la solution logique 5.1 Les diagrammes d activités Les diagrammes d activité sont la représentation du comportement d une opération ou d un cas d utilisation en terme d action. Un diagramme d activités représente l état de l exécution d une méthode, sous la forme d un déroulement d étapes. Une activité est un automate à deux états dont le franchissement de la transition entre ces derniers est conditionné par une fin d activité. Dans le diagramme d activité, il existe deux types de transitions : les transitions automatiques ( une flèche simple) qui est franchie quand l activité précédente est finie. 7 Internet : 8

9 Les transitions gardées ( une flèche avec une condition entre crochets ) qui est franchie si la condition est vérifiée. Les diagrammes d activités permettent aussi de visualiser les activités qui s exécutent en parallèle au moyen de barres de synchronisation. Les diagrammes d activités peuvent être découpés en couloirs d activité pour visualiser la responsabilité des objets au sein du système à modéliser.on peut visualiser clairement les objets dans un diagramme d activité. À chaque objet est associé une ligne de vie et ses activités. La manipulation des objets permet aussi la modification de leur état. On peut alors indiquer cet état de l objet dans le symbole de l objet à l aide de crochets. Il est possible de visualiser les objets qui ont été crée par les activités. Pour cela, on relie par une flèche en pointillé l objet et l activité qui l a crée. 5.2 Les diagrammes de classes Les diagrammes de classes sont la représentation de la structure statique en terme de classes de relations. Les objets sont les instances des classes et les liens sont les instances des relations Les classes sont représentées par un rectangle avec trois compartiments : La déclaration d une classe a la syntaxe suivante : Nom-Classe, les attributs et les méthodes. UML permet de définir les attributs dérivés ( attributs qui peuvent être calculés par d autres éléments déjà existants). Ces attributs sont marqués par le symbole " / ". UML définit trois niveaux de visibilité des attributs et des opérations : 1) - privé (l élément n est visible que dans la classe) 2) + public (l élément est visible par toutes les autres classes ) 3) # protégé (visible par la classe et ses sous classes ) La notation UML prévoie aussi les variables et les opérations de classes. Ces éléments sont identifiés par leur nom souligné dans la représentation de la classe. 5.3 Les cas d utilisations Les cas d utilisations décrivent le comportement du système du point de vue utilisateur sous la forme d actions et de réactions. Un cas d utilisation indique une fonctionnalité du système déclenché par un acteur externe au système. Ce genre de diagramme permet de mettre en place et comprendre les besoins du client. Dans le diagramme, interviennent trois éléments : les acteurs, le système et les cas d utilisation. L acteur représente un rôle joué par une personne ou un autre système qui interagit avec le système en cours de modélisation. Les cas d'utilisations permettent d'exprimer les désirs des utilisateurs du logiciel en cours de modélisation. Les cas d'utilisations se déterminent en prenant tous les acteurs en regardant leurs fonctionnalités. L'une des étapes les plus difficiles dans le développement d'un projet est l'analyse des besoins. Il faut décrire les interactions entre les acteurs et le système sous la forme d'un flot 9

10 d'événement pour chaque cas d'utilisation. Pour décrire un cas d'utilisations il faut les éléments suivants : l'événement déclencheur, l'événement qui termine le cas d'utilisation, les interactions entre l'auteur et le cas d'utilisation et la chronologie de ces interactions. 5.4 L illustration suivante d un modèle conceptuel d un point de vente 8 : L'enregistrement d'une vente Décrit-par 1 Catalogue de produits * Spécifications de produits * * Utilisé-par * Descriptions 0..1 Ventes 1 Magasin Stocks Articles 1 * 1 1..* Enregistrement 1 Contenu dans complété Maisons 1 1.* Ventes * Postes Capturation Débuté-par Direction Payé-par Débuté-par Enregistrement-ventes Paiement Client Débuté-par Caissier Les diagrammes de collaborations Les diagrammes de collaboration permettent la représentation spatiale des objets, des liens et des interactions. Il s agit de la structure spatiale statique. Chaque objet est une instance de classe et les liens entre ces objets les instances des associations définies dans le diagramme de classe. Les objets sont représentés par un rectangle dont le nom et la classe sont soulignés. On peut rajouter un deuxième compartiment à l objet pour indiquer les valeurs des attributs. 8 Applying UML and patterns, An Introduction to OO analysis and design (Conceptual model), Craig Larman 10

11 L instanciation des classes composites (avec l agrégation) donne des objets composites. Les interactions sont réalisées par des objets en échangeant des messages. UML définit plusieurs types de message : les messages simples, synchrones asynchrones et minutés. En UML, deux éléments graphiques symbolisent les types de messages. Pour distinguer les autres types de message (autre que asynchrone), on associe un stéréotype aux flèches. On peut indiquer quel est l objet actif en donnant au symbole de l objet concerné une bordure plus épaisse. 5.6 Les diagrammes d objets Les diagrammes d objet sont la représentation des objets et de leurs relations. Ils correspondent à un diagramme de collaboration simplifié, sans représentation des envois de message. 5.7 Les diagrammes de séquence Il s agit de la représentation des interactions entre les objets selon un point de vue temporel. Le diagramme est structuré de la manière suivante : Les objets étudiés sont placés sur la première ligne et pour chaque objet, on lui associe une barre verticale en pointillée appelée " ligne de vie " de l objet. Le diagramme possède un axe des temps dirigé du haut vers le bas. Les messages sont représentés par des flèches horizontales orientées de l émetteur vers le destinataire. Lorsque le message possède un temps de propagation non négligeable, les flèches sont alors obliques. La représentation des périodes d activité des objets est possible à l aide de bande rectangulaire le long des lignes de vie des objets et dont les extrémités représentent le début et la fin de l activité. Dans le diagramme, on peut indiquer les branchements conditionnels par du pseudo code placé le long de la ligne de vie ou alors entre crochets sur le message à conditionner. De même, on peut placer en pseudo code les boucles d itération ( while, for ) 5.8 Les diagrammes d états-transitions Les diagrammes d états-transitions sont la représentation du comportement d une classe en terme d état. On associe à chaque classe un automate qui suit le comportement de la classe. Un objet est à tout moment dans un état donné. L état d un objet est constitué des valeurs instantanées de ses attributs. Les attributs sont des valeurs qui sont associées aux objets. L'objet passe d'un état à un autre par les transitions. Ces états sont représentés par des rectangles au coin arrondi. L état initial se représente par un point noir et l état final par un point noir encerclé. Déclenchées par un événement, les transitions permettent le passage d un état à un autre instantanément. La syntaxe d un événement dans un diagramme est la suivante : Nom_événement ( Nom_paramètre : type,...)[condition] 11

12 " condition " est la garde qui valide ou non le déclenchement d une transition quand l événement s est produit. On peut associer à chaque transition une action à exécuter lors du franchissement dû à un événement. Les spécifications de l action sont contenues dans l objet destinataire. Il est possible de préciser les actions à exécuter lorsque l on est dans un état donné, en entrant ou en sortant. Pour cela UML donne plusieurs mots-clés : entry (action à exécuter dès l entrée dans l état), exit (action à exécuter lors de la sortie de l état), on (action interne provoquée par un événement qui ne provoque pas le passage à un nouvel état), Do (activité à exécuter) Une activité est une action dont le temps d exécution est non négligeable. 5.9 Les diagrammes de composants Les diagrammes de composants décrivent les éléments physiques et leurs relations dans le système en cours de modélisation. Les éléments sont appelés modules. Il existe trois types de modules : la spécification ( les interfaces de classes ), les corps ( la réalisation de la classe ) et les spécifications génériques ( classe paramétrable ). Un composant peut faire référence au service d un autre composant. Il y a alors une relation de dépendance. UML représente cette relation de dépendance par une flèche en pointillé qui pointe de l utilisateur vers le fournisseur. On appelle tâches, un composant qui possède son propre flot de contrôles. Les stéréotypes <<processus>> et <<flot>> sont prédéfinis en UML Les diagrammes de déploiements Les diagrammes de déploiement indiquent la disposition physique des différents matériels qui entrent dans la composition d un système, ainsi que la disposition des programmes exécutables sur ce matériels. Les éléments matériels sont représentés par des cubes ( noeuds ). 6. Commentaires et analyse 9 L'approche objet nécessite une analyse qui génère un questionnement important. Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste plus intuitive et naturelle. Voilà pourquoi il ne faut pas se contenter d'une implémentation objet, mais se discipliner à "penser objet" au cours d'une phase d'analyse préalable. UML permet d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage de programmation. Il a été pensé pour servir de support à une analyse basée sur les concepts objet. 9 Internet : 12

13 UML est un langage universel et visuel et avant tout un support de communication performant, qui facilite la représentation et la compréhension de solutions objet : Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. L'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions. Son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. La notation graphique d'uml n'est que le support du langage. La véritable force d'uml, c'est qu'il repose sur un métamodèle et c'est qui normalise la sémantique des concepts qu'il véhicule! La notation graphique est essentiellement guidée par des considérations esthétiques, même si elle a été pensée dans ses moindres détails. Une autre caractéristique importante d'uml, est qu'il cadre l'analyse. UML permet de représenter un système selon différentes vues complémentaires : les diagrammes. Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques d'un système. Cela permet de mieux contrôler la complexité dans l'expression et l'élaboration des solutions objet. UML favorise donc le prototypage et il sous-entend une démarche d'analyse. UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles! Qualifier UML de "méthode objet" n'est donc pas tout à fait approprié. Une source fréquente de malentendus sur UML a pour origine la faculté d'uml de modéliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus Un ensemble d'activités coordonnées et régulées, en partie ordonnées, dont le but est de créer un produit (matériel ou intellectuel). UML permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc Conclusion UML n'impose pas de méthode de travail mais il est plutôt une boîte à outil qui peutêtre utilisé dans n'importe quel processus de développement logiciel de manière transparente. La faculté d'uml de se fondre dans le processus courant, tout en véhiculant une démarche méthodologique, facilite son intégration et limite de nombreux risques (rejet des utilisateurs, coûts...) sans révolutionner ses méthodes de travail, mais cela devrait être l occasion de se remettre en question, en s inspirant des meilleures pratiques. Finalement, UML n est qu une normalisation permettant aux professionnels de l informatique de mieux et plus communiquer dans l élaboration de projets communs et dans la recherche de la qualité et de l efficience 10. Tout comme tout autre membre de 10 La réingénierie de processus administratif. 13

14 corporation professionnelle, il est impératif d avoir des normes et un language commun surtout dans notre ère de mondialisation. Ce côté normalisation peut s opposer à l image d artiste fonctionnant en solitaire que plusieurs personnes dans le grand domaine de l informatique aime avoir! Pourtant le côté gestion et travail d équipe dans l élaboration de systèmes de plus en plus intelligents 11 et pour l atteint d efficacité et d efficience, aspects incontournables dans notre monde néo-libéral, est de plus en plus prépondérant 12. Ce résumé de textes et opinions ne représente qu un bref apperçu de la matière si vaste en UML. Pour ceux qui ont le goût ou la nécessité de programmer, je crois qu il serait important d approfondir UML car comme dans tout domaine, c est souvent une préparation adéquate et l utilisation des outils adéquats qui mène à l atteinte de l objectif visé. 11 Systèmes à base de connaissances. 12 Strategic Analysis ans action 14

15 8. Sample UML and Related Notation Applying UML and patterns, An Introduction to OO analysis and design, Craig Larman 15

16 9. Diagrams Applying UML and patterns, An Introduction to OO analysis and design, Craig Larman 16

17 10. Sample Development activities Applying UML and patterns, An Introduction to OO analysis and design, Craig Larman 17

18 Bibliographie : Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design, Craig Larman, Prentice Hall PTR La réingénierie des processus administratifs, H. James Harrington, Les Éditions transcontinentales inc., 1998 Systèmes à base de connaissances, Gilbert Paquette et Lucien Roy, Éditions Beauchemin ltée, 1991 Strategic analysis and action, Joseph N. Fry, J. Peter Killing, Prentice-Hall Canada inc., 1995 Webographie : s/uml/ Modelisation objet avec UML, Jean Marc Muller 18