Analyse en UML

L'Analyse comportera 3 grandes parties que nous présenterons dans un ordre logique :

• Identification des classes candidates et structuration préliminaire.
• Affinage et enrichissement du modèle.
• Analyse dynamique du modèle et consolidation.

Dans la réalité nous allons faire des allers retours entre ses étapes pour arriver à un résultat correct.
Enfin, la conception générique nous permettra de générer l'embryon du futur système réel.

Objectif de l'analyse

Fournir un modèle qui réponde aux objectifs fonctionnels du système.
Fournir un modèle qui soit structuré de façon à permettre :

• Une bonne évolutivité du système.
• Une bonne maintenabilité du système.
• Une bonne modularité du système.

Les objectifs recherchés dans cette phase du projet seront dans la prochaine phase (conception) confrontés à la réalité du déploiement et de l'exploitation c.a.d :

• Le paramétrage du système.
• Le déploiement du système.
• Les mises à jour du système.

Diagrammes / Outils / Langages Utilisés

Diagrammes utilisés :

• Class Diagram.
• Object Diagram.
• Package Diagram.
• Sequence Diagram.
• State Diagram.
• Activity Diagram.

Outils utilisés :

• L'environnement de modélisation UML Rhapsody.

Langages utilisés :

• UML 2.1.
• OCL.
  

Documents collectés et Documents livrés

Documents collectés :

• Les diagrammes réalisés dans la phase d'étude préalable.
• Les documents texte réalisés dans la phase d'étude préalable.
  

Documents livrés :

• Un modèle complet permettant d'entamer la phase de conception finale.
• Un modèle suffisamment réaliste pour autoriser le déploiement et l'exploitation du système.
• Un modèle composé de blocs fonctionnels autonomes afin de développer et de tester chacun d'eux avant de réaliser le système complet.
• Un modèle bien commenté afin que sa compréhension par un tiers ne nécessite pas des heures de réunion.
  

Remarque sur la Génération de Code

A partir de maintenant, tout ce qui est modéliser dans l'environnement est susceptible d'être utilisé pour générer du code si le modèle s'avère finalement devenir un programme informatique ou quelque chose de "générable" automatiquement à partir du modèle.
Il est donc fondamental d'adopter des règles de nommage qui seront adaptées à cette éventuelle génération. (A voir selon le langage cible).

Nous vous proposons une règle :

• Respecter les règles de nommage du C.
• Commencer les noms par une minuscule sauf pour les classes.
• Séparer les noms composés par des majuscules.
• MaClasseX est composée de maMethodeY() et de sonAttributZ.

Identification des Classes Candidates

Il n'existe pas de méthode miracle pour identifier les classes candidates.
Les classes identifiées constituent simplement une base de départ et seront ensuite validées, complétées, généralisées au fur et à mesure de l'étude.
Nous n'avons pas dans cette phase la prétention d'identifier miraculeusement toutes les bonnes classes du modèle final.
Une des méthodes possibles pour amorcer le processus consiste à simplement identifier dans les besoins fonctionnels les entités génériques.
Le piège classique consiste à identifier une Classe pour un Use Case.

L'une des méthodes utilisée pour identifier les classes candidates consiste pour chaque concept identifié à se poser les questions suivantes :
Si ce concept, cet élément, cette chose était une Classe :

• Quelles données la caractériserait ?
• Quelles opérations pourrait-elle réaliser ?
• Quel serait son métier dans le système ?

Si vous ne pouvez pas répondre à l'une de ces questions ce n'est pas une classe candidate.
Si la réponse à la dernière question est trop complexe c'est que c'est une classe qui devrait probablement être décomposée en sous classes.

Identification des Classes Candidates : Exemple

Si nous reprenons pour exemple le DAB vu précédemment, une identification des classes de départ pourrait être ceci.

Cette proposition n'est qu'un exemple incomplet qui n'identifie vraiment que les concepts de base du DAB et ne contient pas les périphériques écran / clavier qui sont utilisés par le système et qui ne nécessitent pas de traitement particulier.

Exercice :

Faites le même exercice avec la caisse enregistreuse que nous avons étudié précédemment.

Structuration en Blocs Fonctionnels ou Packages

La structuration en « Category » en « Packages » ou en « Blocs Fonctionnels » consiste simplement à regrouper les classes identifiées dans des groupes et des sous groupes.
En effet au delà d'une douzaine de classes il est préférable de les regrouper dans des «Packages » qui constituent un niveau d'encapsulation supérieur à la classe.
Parfois, la définition de ces « groupes / blocs / packages » est réalisée avant même l'identification des classes candidates et peut aussi parfois être apporté par la capture des besoins techniques.
Au stade ou nous en sommes dans la modélisation cette structuration verra sûrement des classes passer d'un package à l'autre et des packages se créer et se défaire au fur et à mesure de l'étude.

Structuration en Packages : Exemple

L'exemple ci-contre n'est pas des plus significatif vu le petit nombre de classes.

Nous avons cependant regroupé les classes relatives à la gestion du client et de compte client d'un coté et la supervision de l'appareil DAB d'un autre.

Exercice :

Regrouper les classes candidates de votre caisse enregistreuse dans des packages.

Affiner le Modèle de Classes

L'identification des classes candidates, des « Catégories / Blocs / Packages » du système constituent la base d'un modèle que nous allons maintenant faire évoluer jusqu'au modèle final.
Pour affiner et enrichir notre modèle nous allons :

• Affiner les associations.
• Ajouter les attributs.
• Ajouter les opérations.
• Optimiser le modèle par des généralisations.

Nous sommes à ce moment à peu près au milieu de la démarche 2TUP et de la démarche top > down. Il est donc parfois difficile de faire la part des choses et de choisir entre rester parfaitement générique ou aller jusqu'à la conception préliminaire.

Quelques règles pour affiner

Le modèle final sera composé de packages qui devront être le plus indépendant possible. Il est donc classique d'avoir pour chaque package une classe principale qui sert :

• A l'initialisation des éléments du package.
• De point d'entrée des messages venant de l'extérieur.
• De « tour de contrôle » pour les classes du package.

Les attributs et les opérations ne sont pas forcément typés dès le début mais doivent porter des noms très clairs.
Les environnements de modélisation créés automatiquement les accèsseurs et mutateurs des attributs.
Les associations doivent rester le plus simple et le moins nombreuses possible.

Affiner le Modèle de Classes : Exemple 1

Nous avons ici affiné les classes identifiées préalablement et nous avons introduit les classes de gestion du stock de billet.

Les attributs et opérations ajoutés ont été imaginés à partir des Use Cases et des futurs diagrammes de séquences qui devront vérifier le fonctionnement dynamique du modèle.

Exercice :

Faites le même développement sur la caisse enregistreuse.

Affiner le Modèle de Classes : Exemple 2

Afin que le suivi qualité requis par le service technique qui maintiendra le Dab, soit automatisé, nous avons généralisé les différentes informations requises dans une classe.

Cette généralisation peut apparaître dès que l'on détecte un ou plusieurs attributs communs entre au moins deux classes.

Si ces derniers constituent vraiment une valeur commune, la généralisation devient intéressante.

Exercice :

Idem avec la caisse enregistreuse

Remarque sur la Méthode de Travail

Nul n'est à l'abri d'un plantage ou d'une fausse manipulation et le modèle que nous allons faire évoluer doit être modifié dans le temps.
Pour limiter les risques de pertes et de fausses manipulations il est recommandé de :

• Créer des nouvelles versions du modèle à chaque étape.
• Faire des sauvegardes sur des supports amovibles.

Les ressources réseau nécessaires à l'utilisation d'un modèle sont importantes. Il est donc préférable de travailler son modèle localement.

Enrichissement du Statique par la Dynamique

Pour valider et enrichir notre modèle, nous reprenons les diagrammes de séquences établis dans la première phase en mode Black Box et nous allons les développer en utilisant les classes de notre modèle.
Le diagramme de séquence fait intervenir des objets, il est donc intéressant de créer des diagrammes de séquences pour des cas critiques ou caractéristiques qui testent vraiment le modèle.
Si nous avons des échanges de messages entre objets dans le diagramme de séquence c'est qu'il doit exister une relation entre les classes du diagramme de classe et réciproquement.

Modèle Dynamique : Exemple

Nous avons ici développé le diagramme de séquence définit en mode black box au moment de la capture des besoins.

Nous avons fait apparaître un objet différent pour chaque liste de billets.

Nous continuons de laisser à l'objet DAB la responsabilité des affichages, des saisies et de la communication avec la BDD centrale.

Nous n'avons pas introduit ici les notions de message asynchrone.

Exercice :

Critiquez ce diagramme.

Remarque sur le Diagramme de Séquence

Quand vous créez un diagramme de séquence vous avez le choix entre :

• Le mode « Design » qui vous permet de créer dans les classes du modèle les opérations correspondantes aux messages de la séquence.
• Le mode « Analysis » qui ne répercute rien dans le modèle.

En mode « Design » quand vous créez un message, celui ci dispose d'un « Label » qui peut être différent de celui de l'opération qui le réalise.
En cliquant sur la liste déroulante de la zone « Realization », vous pouvez appeler un message existant ou en créer un nouveau.

Création des ports et interfaces du modèle

Les associations, agrégations et compositions du modèle définissent déjà les liens qui existent entre les classes.
Les messages échangés entre l'environnement et le système décrivent dans les SD les interactions avec l'extérieur.
Nous allons maintenant créer des ports et des interfaces pour contractualiser les échanges clé du système :

• Les interactions entre packages.
• Les interactions avec l'extérieur.

Cette contractualisation des échanges clés va pérenniser le modèle et améliorer sont évolutivité.

Ports et Interfaces : Exemple

Nous avons modéliser ici simplement les interactions entre le système et l'extérieur en utilisant le SD de retrait d'argent.

Le port_8 qui regroupe à la fois l'interface requise IBdd et l'interface réalisée IDab pourrait être décomposé en 2 ports car il s'agit d'interaction vers deux environnements différents.

Exercice :

Compléter ce Diagramme d'après le UCD du DAB.

Organisation de la Conception

L'analyse qui fournit un modèle fonctionnel complet et juste doit conclure sur une conception générique du système. C'est à dire que les différents blocs fonctionnels doivent être organisés selon les pré-requis des spécifications techniques.
Dans le cas par exemple d'un système logiciel organisé selon une architecture 3 tiers, les différents blocs fonctionnels seront répartis dans les couches IHM, Métier et Données.
Ensuite, le code de chaque bloc fonctionnel pourra être généré s'il s'agit de logiciel pour le composant qui le recevra. Ceci afin de valider l'adéquation du modèle et de l'environnement de modélisation avec l'environnement qui le fera fonctionner.

Enrichissement du Modèle par Itération

La modélisation complète d'un système est généralement obtenue par plusieurs itérations des différentes phases précédemment décrites.
On utilise les différentes vues statiques et dynamiques pour vérifier le modèle et quand l'ensemble de ces vues fournissent un modèle cohérent qui répond aux besoins fonctionnels et techniques identifiés durant la phase de pré-étude, nous pouvons passer à la phase de conception préliminaire.
Dans le cas d'un projet informatique, il est conseillé si l'on peut, de générer le code et de tester sa cohérence au fur et à mesure de la modélisation.
Cet objectif annexe ne dois cependant pas entraver l'objectif principal de modélisation de cette phase.

Exercices

Réalisez le modèle de la caisse enregistreuse sans vous préoccuper des packages ni des ports.
Structurez le modèle précédent en packages.
Ajoutez à votre modèle les ports qui vous semblent judicieux.
Proposez un diagramme de classe permettant de modéliser un système de fichier comportant des raccourcis, des fichiers et des répertoires tous contenus dans un répertoire.
Proposez le diagramme de classe d'une partie d'échec.
Proposez le diagramme d'état d'une partie d'échec.

Questions

Donnez les trois principaux diagrammes utilisés en phase d'analyse.
Quels sont les documents nécessaires au lancement de la phase d'analyse ?
Pourquoi regrouper les classes en packages ?
Quelle est l'utilité des ports et interfaces ?
Donnez un moyen de vérifier la cohérence de votre modèle.
Quels sont les principales qualités attendues d'un modèle ?
Quels seront les problèmes qui devront être traités en phase de conception après l'analyse ?

Projet

A partir de la capture des besoins réalisée précédemment vous allez modéliser complètement la carte de télé-maintenance sans tenir compte des contraintes temps réel.
Vous serez évaluez sur :
Votre capacité à innover, à créer et sur la couverture fonctionnelle de votre projet.
La cohérence entre vos diagrammes de classes et de séquences et le respect de la norme UML 2.1.1.
La modularité et la capacité d'évolution de votre modèle.
L'organisation de votre modèle, la clarté de vos documents, votre capacité à expliquer vote modèle.
Chacun doit se noter sur 20 en donnant ses points forts et ses points faibles, nous corrigerons si nécessaire.