L'objectif de cet enchaînement des activités est de détailler la conception du système.

Rubriques


      Classe d'analyse
Classe d'analyse
  Classe d'analyse
Classe d'analyse
  Classe de conception
Classe de
conception
  Interface
Interface
Sous-système de conception
Sous-système
de conception
  Cas d'utilisation
Cas d'utilisation
 
               
 
Concepteur
Concepteur
 

 
Conception d'Enterprise JavaBeans (EJB)
Conception
d'Enterprise
JavaBeans
(EJB)

 
Conception de classes
Conception
de classes

 
Concevoir les éléments de testabilité
Concevoir
les éléments
de testabilité

 
Conception de sous-systèmes
Conception
de sous-systèmes

 
Conception de cas d'utilisation
Conception
de cas d'utilisation

 
               
      Modèle de conception
Modèle de
conception
Enterprise Java Bean (EJB)
Enterprise
Java Bean
(EJB)
  Modèle de conception
Modèle de
conception
Classe de conception
Classe de
conception
  Paquetage de conception
Paquetage
de conception
Classe de testabilité
Classe de
testabilité
  Sous-système de conception
Sous-système
de conception
Classe de conception
Classe de
conception
  Modèle de conception
Modèle de
conception
Réalisation de cas d'utilisation de conception
Réalisation
de cas d'utilisation
de conception
 
                  Interface
Interface
Modèle de conception
Modèle de
conception
     

      Carte de navigation
Carte de
navigation
Modèle de conception
Modèle de
conception
 
       
 
Auditeur technique
Auditeur
technique

 

 
Revoir la conception
Revoir la
conception

 
       
      Compte-rendu de la revue
Compte-rendu
de la revue
 


Description To top of page

Cet enchaînement des activités a pour objectifs :

  • Précision des définitions des éléments de conception en précisant comme les éléments de conception réalisent le comportement qui leur est demandé.
  • Précision et mise à jour des réalisations de cas d'utilisation basées sur un nouvel élément de conception identifié (maintenant les réalisations de cas d'utilisation à jour).
  • Révision de la conception à mesure qu'elle évolue

Informations connexes To top of page

Cette section fournit des liens vers des informations complémentaires relatives à cet enchaînement des activités.

Calendrier To top of page

Commence dans la phase d'élaboration. Se reproduit dans les phases de construction et de transition.

Caractère facultatif To top of page

Requis

Dotation en personnel Haut de la page

En général, une personne ou une petite équipe est responsable d'un ensemble d'éléments de conception, le plus souvent un ou plusieurs packages ou sous-systèmes contenant d'autres éléments de conception. Cette personne/équipe est responsable de l'élaboration des détails de conception pour les éléments contenus dans le package ou le sous-système : complétant toutes les définitions d'opération et celle des relations avec d'autres éléments de conception. L'Activité : Conception de classe est axée sur la précision de la conception des éléments de conception de classes , alors que l'Activité : Conception de sous-système se concentre sur l'allocation de comportement mappé sur le sous-système lui-même sur des éléments de conception contenus (des des classes ou sous-systèmes contenus).

Les individus responsables de la conception de classes doivent être également identifiables dans le langage d'implémentation, ainsi que dans les algorithmes ou les technologies devant être employés par la classe. Les individus ou équipes responsables des sous-systèmes doivent être plus généralistes, capables de prendre des décisions sur le partitionnement adéquat des fonctionnalités entre les éléments de conception et de comprendre les compromis inhérents, impliqués dans diverses alternatives de conception.

Alors que les éléments de conception individuelle sont détaillés, les réalisations de cas d'utilisation doivent être détaillées pour refléter les responsabilités croissantes des éléments de conception. En général, une personne ou une petite équipe est responsable du détail d'une ou de plusieurs réalisations de cas d'utilisation connexes. Comme des éléments de conception sont ajoutés ou détaillés, les réalisations de cas d'utilisation doivent être revus et modifiés du fait qu'ils ne sont plus à jour, ou comme des améliorations du modèle de conception permettent des simplifications dans les réalisations de cas d'utilisation. Les individus ou les équipes responsables des réalisations de cas d'utilisation doivent avoir une compréhension plus large du comportement requis par les cas d'utilisation et les compromis des différentes approches d'allocation de ce comportement aux éléments de conception. De plus, comme ils sont responsables de la sélection des éléments qui vont exécuter les cas d'utilisation, ils doivent avoir une parfaite connaissance des comportements externes (publics) des éléments de conception.

Principes et conseils de travail Haut de la page

En général, le travail est effectué individuellement ou par petites équipes, avec des interactions inter-groupes informelles si nécessaires pour communiquer les modifications entre les équipes. A mesure que les éléments de conception sont détaillés, les responsabilités changent souvent entre les équipes, nécessitant des modifications simultanées sur un certain nombre d'éléments de conception et de réalisations de cas d'utilisation. Du fait de l'interaction des responsabilités, il est presque impossible pour les membres des équipes de conception de travailler isolés. Pour maintenir l'effort de conception axé sur le comportement requis du système (comme exprimé dans les réalisations de cas d'utilisation), un schéma typique d'interactions émerge :

  • des éléments de conception sont détaillés par les personnes ou les équipes responsables ;
  • un petit groupe (peut-être 2 à 5 personnes) se forme de manière informelle pour déterminer l'impact des nouveaux éléments de conception sur un ensemble des réalisations de cas d'utilisation existants ;
  • dans le cours de la discussion, les modifications sur la réalisation des cas d'utilisation et les éléments de conception participants sont identifiés ;
  • le cycle se répète jusqu'à ce tout le comportement requis pour l'itération soit conçu.

Comme le processus lui-même est itératif, les critères pour tout le comportement requis pour l'itération varient selon la position dans le cycle de vie :

  • Dans la phase d'élaboration, l'accent est mis sur des comportements architecturalement importants, tous les autres détails étant effectivement ignorés (ou plutôt écrasés).
  • Dans la phase de construction, il y a un déplacement vers l'achèvement et la cohérence de la conception, de telle sorte qu'à la fin de cette phase il n'y a plus de problèmes de conception non résolus.

Notez que la conception d'une itération n'a pas besoin d'être achevée pour commencer l'implémentation et les tests. Implémenter et tester partiellement une conception au cours de son évolution peut être un moyen effectif pour la valider et la détailler, même dans une itération.


RUP (Rational Unified Process)   2003.06.15