Sommaire: Cours UML, le langage de modélisation objet unifié
I – PRESENTATION D’UML
I-A – Un peu d’Histoire
I-A-1 – Approche fonctionnelle vs. approche objet
I-A-1-a – La découpe fonctionnelle d’un problème informatique : une approche intuitive
I-A-1-b – Le « plus » de l’approche fonctionnelle : la factorisation des comportements
I-A-1-c – Le revers de la médaille : maintenance complexe en cas d’évolution
I-A-1-d – La séparation des données et des traitements : le piège !
I-A-1-e – 1ère amélioration : rassembler les valeurs qui caractérisent un type, dans le type
I-A-1-f – 2ème amélioration : centraliser les traitements associés à un type, auprès du type
I-A-1-g – Récapitulons
I-A-1-h – Objet ?
I-A-2 – Quels sont les autres concepts importants de l’approche objet ?
I-A-2-a – Encapsulation
I-A-2-b – Héritage (et polymorphisme)
I-A-2-c – Agrégation
I-A-2-d – Résumé sur les concepts fondateurs de l’approche objet
I-A-2-e – L’approche objet, hier et aujourd’hui
I-A-2-f – L’approche objet : une solution parfaite ?
I-A-2-g – Quels sont les remèdes aux inconvénients de l’approche objet ?
I-B – Les méthodes objet et la genèse d’UML
I-B-1 – Méthodes ?
I-B-2 – A quoi sert UML ?
I-C – Avantages et inconvénients d’UML
I-C-1 – Les points forts d’UML
I-C-2 – Les points faibles d’UML
II – MODELISER AVEC UML
II-A – Qu’est-ce qu’un modèle ?
II-B – Comment modéliser avec UML ?
II-B-1 – Une démarche itérative et incrémentale ?
II-B-2 – Une démarche pilotée par les besoins des utilisateurs ?
II-B-3 – Une démarche centrée sur l’architecture ?
II-B-4 – Définir une architecture avec UML (détail de la « vue 4+1 »)
II-B-5 – Résumons la démarche
II-B-6 – Elaboration plutôt que transformation
II-B-7 – Détail des différents niveaux d’abstraction (phases du macro-processus)
II-B-8 – Activités des micro-processus d’analyse (niveau d’abstraction constant)
II-B-9 – Synthèse de la démarche
II-B-10 – Les diagrammes UML
II-B-10-a – Comment « rédiger » un modèle avec UML ?
II-B-10-b – Quelques caractéristiques des diagrammes UML
II-B-10-c – Les différents types de diagrammes UML
II-C – Les vues statiques d’UML
II-C-1 – LES PAQUETAGES
II-C-1-a – Paquetages (packages)
II-C-1-b – Paquetages : relations entre paquetages
II-C-1-c – Paquetages : interfaces
II-C-1-d – Paquetages : stéréotypes
II-C-2 – LA COLLABORATION
II-C-2-a – Symbole de modélisation « collaboration »
II-C-3 – INSTANCES ET DIAGRAMME D’OBJETS
II-C-3-a – Exemples d’instances
II-C-3-b – Objets composites
II-C-3-c – Diagramme d’objets
II-C-4 – LES CLASSES
II-C-4-a – Classe : sémantique et notation
II-C-5 – DIAGRAMME DE CLASSES
II-C-5-a – Diagramme de classes : sémantique
II-C-5-b – Associations entre classes
II-C-5-c – Documentation d’une association et types d’associations
II-C-5-d – Héritage
II-C-5-e – Agrégation
II-C-5-f – Composition
II-C-5-g – Agrégation et composition : rappel
II-C-5-h – Interfaces
II-C-5-i – Association dérivée
II-C-5-j – Contrainte sur une association
II-C-5-k – OCL
II-C-5-l – Stéréotypes
II-C-6 – DIAGRAMMES DE COMPOSANTS ET DE DEPLOIEMENT
II-C-6-a – Diagramme de composants
II-C-6-b – Diagramme de déploiement
II-D – Les vues dynamiques d’UML
II-D-1 – LES CAS D’UTILISATION
II-D-1-a – La conceptualisation : rappel
II-D-1-b – Cas d’utilisation (use cases)
II-D-1-c – Eléments de base des cas d’utilisation
II-D-1-d – Exemples
II-D-2 – COLLABORATION ET MESSAGES
II-D-2-a – Synchronisation des messages
II-D-2-b – Objets actifs (threads)
II-D-3 – DIAGRAMME DE SEQUENCE
II-D-3-a – Diagramme de séquence : sémantique
II-D-3-b – Types de messages
II-D-3-c – Activation d’un objet
II-D-3-d – Exemple complet
II-D-4 – DIAGRAMME D’ETATS-TRANSITIONS
II-D-4-a – Diagramme d’états-transitions : sémantique
II-D-4-b – Super-Etat, historique et souches
II-D-4-c – Actions dans un état
II-D-4-d – Etats concurrents et barre de synchronisation
II-D-4-e – Evénement paramétré
II-D-4-f – Echange de messages entre automates
II-D-5 – DIAGRAMME D’ACTIVITES
II-D-5-a – Diagramme d’activités : sémantique
II-D-5-b – Synchronisation
II-D-5-c – Couloirs d’activités
II-E – Conclusion
II-E-1 – Programmer objet ?
II-E-2 – Utiliser UML ?
Extrait du cours UML, le langage de modélisation objet unifié
I-A-1-a – La découpe fonctionnelle d’un problème informatique : une approche intuitive
Exemple de découpe fonctionnelle d’un logiciel dédié à la gestion d’une bibliothèque :
Le logiciel est composé d’une hiérarchie de fonctions, qui ensemble, fournissent les services désirés, ainsi que de données qui représentent les éléments manipulés (livres, etc ). Logique, cohérent et intuitif.
I-A-1-b – Le « plus » de l’approche fonctionnelle : la factorisation des comportements
Une découpe fonctionnelle « intelligente » consiste à factoriser certains comportements communs du logiciel. En d’autres termes : pour réaliser une fonction du logiciel, on peut utiliser un ensemble d’autres fonctions, déjà disponibles, pour peu qu’on rende ces dernières un tant soit peu génériques. Génial !
I-A-1-c – Le revers de la médaille : maintenance complexe en cas d’évolution
Factoriser les comportements n’a malheureusement pas que des avantages. Les fonctions sont devenues interdépendantes : une simple mise à jour du logiciel à un point donné, peut impacter en cascade une multitude d’autres fonctions. On peut minorer cet impact, pour peu qu’on utilise des fonctions plus génériques et des structures de données ouvertes. Mais respecter ces contraintes rend l’écriture du logiciel et sa maintenance plus complexe. En cas d’évolution majeure du logiciel (passage de la gestion d’une bibliothèque à celle d’une médiathèque par exemple), le scénario est encore pire. Même si la structure générale du logiciel reste valide, la multiplication des points de maintenance, engendrée par le chaînage des fonctions, rend l’adaptation très laborieuse. Le logiciel doit être retouché dans sa globalité :
I-A-1-d – La séparation des données et des traitements : le piège !
Examinons le problème de l’évolution de code fonctionnel plus en détail…
Faire évoluer une application de gestion de bibliothèque pour gérer une médiathèque, afin de prendre en compte de nouveaux types d’ouvrages (cassettes vidéo, CD-ROM, etc…), nécessite :
• de faire évoluer les structures de données qui sont manipulées par les fonctions,
• d’adapter les traitements, qui ne manipulaient à l’origine qu’un seul type de document (des livres).
Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour gérer les données et les actions propres aux différents types de documents.
Il faudra par exemple modifier la fonction qui réalise l’édition des « lettres de rappel » (une lettre de rappel est une mise en demeure, qu’on envoie automatiquement aux personnes qui tardent à rendre un ouvrage emprunté). Si l’on désire que le délai avant rappel varie selon le type de document emprunté, il faut prévoir une règle de calcul pour chaque type de document.
Cours UML
I-A-1-e – 1ère amélioration : rassembler les valeurs qui caractérisent un type, dans le type
Une solution relativement élégante à la multiplication des branches conditionnelles et des redondances dans le code (conséquence logique d’une trop grande ouverture des données), consiste tout simplement à centraliser dans les structures de données, les valeurs qui leurs sont propres :
structDocument
{
charnom_doc[50];
Type_doc type;
Bool est_emprunte;
charemprunteur[50];
structtm date_emprunt;
intdelai_avant_rappel;
}DOC[MAX_DOCS];
voidlettres_de_rappel()
{
/* … */
for(i = 0; i <NB_DOCS; i++)
{
if(DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */
{
/* IMPRIME UNE LETTRE SI SON
DELAI DE RAPPEL EST DEPASSE */
if(date() >=(DOC[i].date_emprunt +DOC[i].delai_avant_rappel))
imprimer_rappel(DOC[i]);
}
}
}
Quoi de plus logique ? En effet, le « délai avant édition d’une lettre de rappel » est bien une caractéristique propre à tous les ouvrages gérés par notre application.
Mais cette solution n’est pas encore optimale !
Cours UML
I-A-1-f – 2ème amélioration : centraliser les traitements associés à un type, auprès du type
Pourquoi ne pas aussi rassembler dans une même unité physique les types de données et tous les traitements associés ?
Que se passerait-il par exemple si l’on centralisait dans un même fichier, la structure de données qui décrit les documents et la fonction de calcul du délai avant rappel ? Cela nous permettrait de retrouver en un clin d’oeil le bout de code qui est chargé de calculer le délai avant rappel d’un document, puisqu’il se trouve au plus près de la structure de données concernée.
Ainsi, si notre médiathèque devait gérer un nouveau type d’ouvrage, il suffirait de modifier une seule fonction (qu’on sait retrouver instannément), pour assurer la prise en compte de ce nouveau type de document dans le calcul du délai avant rappel. Plus besoin de fouiller partout dans le code…
structDocument
{
charnom_doc[50];
Type_doc type;
Bool est_emprunte;
charemprunteur[50];
structtm date_emprunt;
intdelai_avant_rappel;
}DOC[MAX_DOCS];
Cours UML
I-A-1-g – Récapitulons…
En résumé : centraliser les données d’un type et les traitements associés, dans une même unité physique, permet de limiter les points de maintenance dans le code et facilite l’accès à l’information en cas d’évolution du logiciel :
I-A-1-h – Objet ?
Les modifications que nous avons apporté à notre logiciel de gestion de médiathèque, nous ont amené à transformer ce qui était à l’origine une structure de données, manipulée par des fonctions, en une entité autonome, qui regroupe un ensemble de propriétés cohérentes et de traitements associés. Une telle entité s’appelle… un objet et constitue le concept fondateur de l’approche du même nom !
• Un objet est une entité aux frontières précises qui possède une identité (un nom).
• Un ensemble d’attributs caractérise l’état de l’objet.
• Un ensemble d’opérations (méthodes) en définissent le comportement.
• Un objet est une instance de classe (une occurrence d’un type abstrait).
• Une classe est un type de données abstrait, caractérisé par des propriétés (attributs et méthodes) communes à des objets et permettant de créer des objets possédant ces propriétés.
……..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Cours UML, le langage de modélisation objet unifié (975 KO) (Cours PDF)
