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 :
    • 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 :

 

 


page précédente


sommaire

© uml@free.fr - tous droits réservés


page suivante