Dans ce module, vous avez étudié :

• Les diagrammes UML

• Les étapes d’élaboration d’une application

• Les design patterns

La version actuelle d’UML est constituée de 14 diagrammes, que l’on peut scinder en 3 grands groupes :

• les diagrammes structurels, qui définissent les différents éléments qui constituent votre application,

• les diagrammes de comportement, qui définissent comment ces éléments se comportent tout au long de l’application,

• les diagrammes d’interaction, qui définissent comment les éléments interagissent entre eux.

Nous avons vu un diagramme de chacun de ces groupes.

Diagrammes structurels ou statiques (UML Structure) :

• Diagramme de classes (Class diagram)

  • perspective conceptuelle des classes intervenant dans le logiciel.

• Diagramme d’objets (Object diagram)

  • représentation des instances de classes utilisées dans le logiciel.

• Diagramme de composants (Component diagram)

  • représentation des composants du système d’un point de vue physique, tels qu’ils sont mis en œuvre (fichiers, bibliothèques, etc.).

• Diagramme de paquetages (Package diagram)

  • gestion des dépendances entre packages.

• Diagramme de déploiement (Deployment diagram)

  • représentation des éléments physiques (ordinateurs, périphériques, etc.) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.

• Diagramme de structures composites (Composite structure diagram)

  • représentation des relations entre composants d’une classe.

• Diagramme de profil (Profile diagram)

Diagrammes de comportement :

• Diagramme des cas d’utilisation (Use-case diagram)

  • représentation des interactions possibles entre le système et les acteurs (intervenants extérieurs au système).

• Diagramme d’activité (Activity diagram)

  • représentation sous forme de flux ou d’enchaînements d’activités du comportement du système ou de ses composants.

• Diagramme états-transitions (State machine diagram)

  • représentation sous forme de machine à états finis du comportement du système ou de ses composants.

Diagrammes d'interaction :

• Diagramme de séquence (Sequence diagram)

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

• Diagramme de communication (communication diagram)

  • représentation simplifiée d’un diagramme de séquence

• Diagramme de vue d’ensemble (interaction overview diagram)

  • représentation des enchaînements possibles entre les scénarios identifiés sous forme de diagrammes de séquences.

• Diagramme de temps (timing diagram)

  • représentation de l’évolution d’une donnée au cours du temps.

On peut décomposer l’élaboration d’une application en 4 grandes phases :

1. L'expression des besoins :

Ici, on s’intéresse au « quoi faire » et non au « comment faire ». Il s’agit donc de déterminer quels sont les acteurs exploitant l’application et, surtout, leur buts. On va ainsi déterminer les grandes fonctionnalités de l’application.

Les diagrammes UML utiles pour cette phase sont, en particulier :

• les diagrammes de cas d’utilisation,

• les diagrammes de séquences « systèmes »,

• les diagrammes d’activités.

2. L'obtention d'un modèle du système :

Ici, on essaye de déterminer les classes de l’application, leurs relations et leurs attributs. On décrit les abstractions et les informations essentielles du domaine.

Les diagrammes UML utiles pour cette phase sont, en particulier :

• les diagrammes de classes,

• les diagrammes d’objets.

3. La conception détaillée :

Ici, on détermine les méthodes, les types, les dépendances entre packages. On décrit les interactions entre objets et les sens de navigabilité (un objet dépend d’un autre mais pas inversement).

Les diagrammes UML utiles pour cette phase sont, en particulier :

• les diagrammes de packages,

• les diagrammes d’interactions.

4. Le passage au codage

Ici, on s’appuie beaucoup sur les diagrammes de classes et de séquence afin de coder l’application. Attention : on ne débute pas le codage avant de savoir précisément ce que l’on doit coder, autrement dit avant que les diagrammes mentionnés ci-dessus soient bien clairs !

On peut séparer ces design patterns en plusieurs catégories. Ici, j’en ai choisi 3 :

• Les design patterns de construction :

  dont le but est de permettre de construire des objets complexes répondant à certaines spécifications ou contraintes. Parmi ces design patterns, on trouve :

  • Abstract Factory (ou Fabrique abstraite en français) :
    Permet de créer des objets de différentes classes formant un tout cohérent.
  • Builder (Monteur) :
    Permet des construire des objets en réalisant différentes étapes.
  • Factory (Fabrique) :
    Permet de créer des objets dont on ne connaît pas la classe avec certitude à la compilation (on ne la connaît qu'à l'exécution du programme).
  • Prototype :
    Permet de "cloner" des objets existants.
  • Singleton :
    Permet de garantir qu'une seule instance d'une classe donnée sera créée pendant toute l'exécution du programme.

• Les design patterns de structuration :

  dont le but est de structurer des objets complexes :

  • Adapter (Adaptateur) :
    Permet d'adapter le format des données transmises à une classe sans avoir à adapter son code.
  • Bridge (Pont) :
    Permet de scinder un ensemble de classes monolithiques en une combinaison plus restreinte de classes plus spécialisées.
  • Composite :
    Permet de créer aisément des objets complexes qui en contiennent d'autres de diverses classes.
  • Decorator (Décorateur) :
    Permet d'affecter dynamiquement (à l'exécution plutôt qu'à la compilation) des comportements à une classe.
  • Facade (Façade) :
    Permet d'offrir une interface simple à un système complexe.
  • Flyweight (Poids mouche) :
    Permet de partager entre différentes instances de classes des informations similaires, de manière à réduire la consommation mémoire.
  • Proxy (Procuration) :
    Permet de produire un objet qui sert de substitut à un autre.

• Les design patterns de comportement :

  dont le but est d’étendre le comportement, les fonctionnalités, d’objets ou, tout simplement, de rendre certaines fonctionnalités possibles :

  • Chain of responsibility (Chaîne de responsabilité) :
    Permet de mettre en place une circulation d'informations dans un ensemble ordonné de handlers.
  • Command (Commande) :
    Permet de transformer des actions en des objets qui permettront de les réaliser.
  • Iterator (Itérateur) :
    Permet d'itérer sur les éléments d'une collection sans exposer la structure interne de celle-ci.
  • Interpreter (Interpréteur) :
    Permet de définir un langage (arbre d'expressions) et fournit les méthodes pour l'interpréter.
  • Memento :
    Permet de sauvegarder/recharger l'état d'un objet sans exposer son implémentation.
  • Mediator (Médiateur) :
    Permet de réduire les dépendances entre objets en leur imposant de communiquer uniquement via un objet médiateur.
  • Observer (Observateur) :
    Permet de mettre en place un système de notification entre objets.
  • State (État) :
    Permet de modifier le comportement d'un objet en fonction de son état.
  • Strategy (Stratégie) :
    Permet de définir une famille d'algorithmes encapsulés dans des objets et de les rendre interchangeables.
  • Template Method (Patron de méthode) :
    Permet de représenter au sein d'une classe un algorithme séparé en plusieurs étapes et de redéfinir certaines d'entre elles dans des sous-classes.
  • Visitor (Visiteur) :
    Permet de rajouter de nouvelles fonctionnalités à une classe sans avoir à la modifier.

Les design patterns indiqués en rouge sont ceux décrits dans les séances suivantes.

Une référence utile avec plein d'exemples et d'explications : Refactoring Guru.