Modéliser avec UML (suite...)
q
Détail des différents niveaux d'abstraction
(phases du macro-processus)
- Conceptualisation
- L'entrée de l'analyse à ce niveau, est le dossier d'expression des besoins client.
- A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs.
- Il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !
- Le but de la conceptualisation est :
- de définir le contour du système à modéliser (de spécifier le "quoi"),
- de capturer les fonctionnalités principales du système, afin d'en fournir une meilleure compréhension (le modèle produit sert d'interface entre les acteurs du projet),
- de fournir une base à la planification du projet.
- Analyse du domaine
- L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas d'utilisation" UML).
- Il s'agit de modéliser les éléments et mécanismes principaux du système.
- On identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments :
- les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
- ils sont indispensables à la mission du système,
- ils gagnent à être réutilisés (ils représentent un savoir-faire).
- A ce stade, on organise aussi (selon des critères purement logiques), les éléments du domaine en "catégories" :
- pour répartir les tâches dans les équipes,
- regrouper ce qui peut être générique, etc...
- Analyse applicative
- A ce niveau, on modélise les aspects informatiques du système, sans pour autant rentrer dans les détails d'implémentation.
- Les interfaces des éléments de modélisation sont définis (cf. encapsulation).
- Les relations entre les éléments des modèles sont définies.
- Les éléments de modélisation utilisés peuvent être propres à une version du système.
- Conception
- On y modélise tous les rouages d'implémentation et on détaille tous les éléments de modélisation issus des niveaux supérieurs.
- Les modèles sont optimisés, car destinés à être implémentés.
q Activités des micro-processus d'analyse
(niveau d'abstraction constant)
- A chaque niveau d'abstraction, un micro-processus régit la construction des modèles.
- UML ne régit pas les activités des micro-processus, c'est le principe d'abstraction qui permet l'élaboration itérative et incrémentale des modèles.
- Exemple de micro-processus de construction d'un modèle :
- identifiez les classes (d'objets) :
- recherchez les classes candidates (différentes suivant le niveau d'abstraction) à l'aide de diagrammes d'objets (ébauches),
- filtrez les classes redondantes, trop spécifiques ou vagues, qui ne représentent qu'une opération ou un attribut,
- documentez les caractéristiques des classes retenues (persistances, nombre maximum d'instances, etc.).
- identifiez les associations entre classes / interactions entre objets (instances) :
- recherchez les connexions sémantiques et les relations d'utilisation,
- documentez les relations (nom, cardinalités, contraintes, rôles des classes...),
- en spécification, filtrez les relations instables ou d'implémentation,
- définissez la dynamique des relations entre objets (les interactions entre instances de classes et les activités associées).
- identifiez les attributs et les opérations des classes :
- recherchez les attributs dans les modèles dynamiques (recherchez les données qui caractérisent les états des objets),
- filtrez les attributs complexes (faites-en des objets) et au niveau spécification, ne représentez pas les valeurs internes propres aux mécanismes d'implémentation,
- recherchez les opérations parmi les activités et actions des objets (ne pas rentrer dans le détail au niveau spécification).
- optimisez les modèles :
- choisissez vos critères d'optimisation (généricité, évolutivité, précision, lisibilité, simplicité...),
- utilisez la généralisation et la spécialisation (classification),
- documentez et détaillez vos modèles, encapsulez.
- validez les modèles :
- vérifiez la cohérence, la complétude et l'homogénéité des modèles,
- confrontez les modèles à la critique (comité de relecture...).
q Synthèse de la démarche
Modéliser une application n'est pas une activité linéaire.
Il s'agit d'une tâche très complexe, qui nécessite une approche :
- itérative et incrémentale (grâce aux niveaux d'abstraction), car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et maîtriser,
- centrée sur l'architecture (définie par la vue "4+1"), car il s'agit de la clé de voûte qui conditionne la plupart des qualités d'une application informatique,
- guidée par la prise en compte des besoins des utilisateurs (à l'aide des cas d'utilisation), car ce qui motive l'existence même du système à concevoir, c'est la satisfaction des besoins de ses utilisateurs.
|