heron  

Unified Model Language


Autres méthodes:

 

Cette méthode jouit d’une grande popularité.

En fait ce n’est pas vraiment une méthode, il ne s’agit qu’un d’un ensemble de modélisation.

 

L’ensemble est complexe, et difficile à appliquer à un vrai projet.

 

L’américain Craig Larmann a su, sur ces techniques de modélisation  bâtir une méthode de projet.

Cette méthode peut s’utiliser soit dans le cadre d’un enchaînement linéaire, soit dans une approche itérative. Très schématiquement les phases sont les suivantes.

 

Analyse

 

  1. Requirements : Il s’agit de lire le cahier des charges et de le mettre sous formes d’items, chaque item est un requirement. Dans la suite de l’analyse on vérifiera que tous les requirements ont été pris en compte.
  2. Uses Case : Il s’agit de représenter l’application sous la forme d’une série de Uses Cases. Un use case illustre un enchaînement d’opération exécutée en vue d’un objectif d’un l’utilisateur. Pour une analyse intéressante, il faut retenir l’objectif final, éviter de considérer des objectifs intermédiaires. Cette phase comprend plusieurs diagrammes, le plus intéressant est probablement le diagramme de séquence. Celui-ci ressemble au MCT de Merise

Exemple de diagramme de séquence.:

 

 

 

Chaque ligne d’eau, symbolise un opérateur les visages sont les opérateurs externes à l’entreprise, les soleils sont des opérateurs de l’entreprise.

 

Cette phase se termine par une série de contrats d’opérations. Il y a un contrat d’opération par flèche pointant vers un opérateur interne. Ce contrat spécifie ce que cet opérateur doit alors faire.

 


  1. Diagramme de classe d’analyse

 

Ce diagramme illustre les classes d’objets du métier, il est un peu équivalent au MCD de Merise, mais il intègre en plus la notion d’héritage.

 

Voici un exemple:

 

 

 

A l’issue de ces trois phases, l’analyse est terminée, les besoins du client sont bien définis.

 

Noter qu’aucune hypothèse de technique d’implémentation n’a encore été introduite. La réalisation ne sera pas forcément codée dans un langage objet, voir même il n’y aura pas d’informatique.


Design

 

Nous devons maintenant prendre des options techniques :

 

 

Dans une solution objet, nous poursuivons par les phases suivantes :

 

  1. Diagramme de classes de conception. Cette fois il s’agit des classes qui seront réellement codées en langage objet. Pour chaque classe du diagramme d’analyse, il faut décider :

·         Implémenter en objet.

·         Implémenter dans une base de données.

·         Ignorer.

  1. Diagramme de collaboration. Ce diagramme illustre les appels de méthodes entre objets.
  2. Stratégie de visibilité. Pour qu’un objet puisse appeler une méthode d’un autre objet, il doit en posséder une référence. Il faut décider qui connaît qui, quand et comment.

 

Conclusion

 

Cet aperçu est très schématique. Il s’agissait ici de montrer l’essentiel, de permettre des rapprochements avec Merise et Structured Analysis, et surtout de vous convaincre que UML est utilisable.

 

 

Retour au menu général.