Admin CliCours
Sommaire: Cours Introduction à la modélisation orientée objets avec UML
1 Vocation de ce document
2 Présentation générale d’UML
2.1 Introduction
2.2 Unified : historique des méthodes de conception
2.3 Modeling : analyse et conception
2.4 Language : méthodologie ou langage de modélisation ?
2.5 Différentes vues et diagrammes d’UML
3 Le diagramme des cas (vue fonctionnelle)
3.1 Les cas d’utilisation
3.2 Liens entre cas d’utilisation : include et extend
4 Le diagramme des classes (vue structurelle)
4.1 Introduction au diagramme des classes
4.2 Les différents niveaux de description
4.3 Les diagrammes de packages
4.4 Description d’une classe
4.4.1 Les attributs
4.4.2 Les opérations
4.5 Les interfaces
4.6 Les associations
4.6.1 Les cardinalités (ou multiplicités)
4.6.2 Attributs et classes d’association
4.6.3 Qualificatifs
4.6.4 Associations et attributs dérivés
4.6.5 Ajout de contraintes et de règles
4.7 Sous-types et généralisation
4.7.1 Agrégation et composition
4.8 Classes paramétriques
5 Les diagrammes de séquences (vue fonctionnelle)
6 Les diagrammes d’états (vue dynamique)
6.1 Etats et Transitions
6.2 Actions et activités
6.2.1 Exemple : diagramme d’états d’un réveil
6.2.2 Événements spéciaux
6.3 Ordonnancement
6.4 Diagrammes hiérarchisés
6.4.1 Parallélisme et synchronisation
6.5 Le diagramme d’activité (vue dynamique)
6.6 Extension de UML : les stéréotypes
6.7 Conclusion
7 Glossaire
7.1 Extrait français du glossaire
7.2 Glossaire complet en anglais
8 NETographie (dernière mise à jour : 2001-2002)
8.1 Programmation objets et UML
8.2 Les patterns (ou patrons)
Extrait du cours introduction à la modélisation orientée objets avec UML
1 Vocation de ce document
Ce document s’adresse à de futurs ingénieurs qui seront confrontés dans leur vie professionnelle au développement d’applications informatiques industrielles, en tant que concepteurs aussi bien que clients.
De par sa fonction, l’ingénieur, qu’il soit spécialiste d’informatique ou non, doit être capable de spécifier clairement le problème qu’il doit résoudre. S’il n’est pas informaticien, il aura sans doute à dialoguer avec des équipes de conception pour s’assurer que ses spécifications sont bien comprises. S’il est re sponsable d’une équipe de développement, il aura à assimiler les spécifications qu’il aura contribué à établir.
2 Présentation générale d’UML
2.1 Introduction
Le génie logiciel et la méthodologie s’efforcent de couvrir tous les aspects de la vie du logiciel. Issus de l’expérience des développeurs, concepteurs et chefs de projets, ils sont en constante évolution, parallèlement à l’évolution des techniques informatiques et du savoir-faire des équipes.
Comme toutes les tentatives de mise à plat d’une expérience et d’un savoir-faire, les méthodologies ont parfois souffert d’une formalisation excessive, imposant aux développeurs des contraintes parfois contre-productives su r leur façon de travailler.
Avec la mise en commun de l’expérience et la maturation des savoir-faire, on voit se développer à présent des méthodes de travail à la fois plus proches de la pratique réelle des experts et moins contraignantes.
2.2 Unified : historique des méthodes de conception
À chacune des différentes phases de la conception d’un logiciel correspondent des problèmes ou des contraintes différentes. Naturellement, ces niveaux ont fait l’objet de recherches méthodologiques considérables depuis les années 80. Il en résulte que de nombreuses méthodes de développement ou d’analyse de logiciel ont vu le jour, chacune plus ou moins spécialisée ou adaptée à une démarche particulière, voire à un secteur industriel particulier (bases de données, matérie l embarqué, …) [url1]. Celles-ci ayant été développées indépendamment les unes des autres, elles sont souvent partiellement redondantes ou incompatibles entre elles lorsqu’el les font appel à des notations ou des terminologies différentes, voire à des faux amis.
2.3 Modeling : analyse et conception
Une bonne méthodologie de réalisation de logiciels suppose une bonne maîtrise de la distinction entre l’analyse et la conception, distinction que nous exposons dans le polycopié complémentaire ([Sig05a]). Le lecteur verra qu’en pratique, le respect d’une distinction entre des phases d’analyse et de conception rigoureusement indépendantes n’est pas tenable, mais il est important d’avoir en tête la différence lorsqu’on s’apprête à réaliser un logiciel. Encore une fois, il est important de g arder à l’esprit qu’UML n’offre pas une méthodologie pour l’analyse et la conception, mais un langage qui permet d’exprimer le résultat de ces phases.
Du point de vue des notations employées en UML, les différences entre l’analyse et la conception se traduisent avant tout par des différences de niveau de détail dans les diagrammes utilisés. On peut ainsi noter les différences suivantes :
– Dans un diagramme de classes d’analyse, les seules classes qui apparaissent servent à décrire des objets concrets du domaine modélisé. D ans un diagramme
2.4 Language : méthodologie ou langage de modélisation ?
Il est important de bien faire la distinction entre une méthode qui est une démarche d’organisation et de conception en vue de résoudre un problème informatique, et le formalisme dont elle peut user pour exprimer le résultat (voir le glossa ire en annexe).
Les grandes entreprises ont souvent leurs propres méthodes de conception ou de réalisation de projets informatiques. Celles-ci sont liées à des raisons historiques, d’organisation administrative interne ou encore à d’autres contraintes d’environnement (défense nationale, …) et il n’est pas facile d’en changer. Il n’était donc pas réaliste de tenter de standardiser une méthodologie de conception au niveau mondial.
UML n’est pas une méthode, mais un langage. Il peut donc être utilisé sans remettre en cause les procédés habituels de conception de l’entreprise et, en particulier, les méthodes plus anciennes telles que celle proposée par OMT sont tout à fait utilisables.
D’ailleurs, la société RATIONAL (principale actrice de UML) propose son propre processus de conception appelé OBJECTORY [JBR97a] et entièrement basé sur UML.
2.5 Différentes vues et diagrammes d’UML
Toutes les vues proposées par UML sont complémentaires les unes des autres, elles permettent de mettre en évidence différents aspects d’un logiciel à réaliser. On peut organiser une présentation d’UML autour d’un découpage en vues, ou bien en différents diagrammes, selon qu’on sépare plutôt les aspects fonctionnels des aspects architecturaux, ou les aspects statiques des aspects dynamiques. Nous adopterons plutôt dans la suite un découpage en diagrammes, mais nous commençons par présenter les différentes vues, qui sont les suivantes :
1 – la vue fonctionnelle, interactive, qui est représentée à l’aide de diagrammes de cas et de diagrammes des séquences, fera l’objet des sections 3 à la page 8 et 5 à la page 21. Elle cherche à appréhender les interactions entre les différents acteurs/utilisateurs et le système, sous forme d’objectif à atteindre d’un côté et sous forme chronologique de scénarios d’interaction typiq ues de l’autre.
2 – la vue structurelle, ou statique, présentée dans la section 4 à la page 10, réunit les diagrammes de classes et les diagrammes de packages. Les premiers favorisent la structuration des données et tentent d’identifier les objets/composants constituant le programme, leurs attributs, opérations et méthodes, ainsi queles liens ou associations qui les unissent. Les seconds s’attachent à regrouper les classes fortement liées entre elles en des composants les plus autonomes possibles. A l’intérieur de chaque package, on trouve un diagramme de classes.
……..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Cours Introduction à la modélisation orientée objets avec UML (424 KO) (Cours PDF)
