Quelques questions sur l'utilisation des diagrammes UML

Le problème exposé dans ce sujet a été résolu.

Bonsoir à tous,
J’ai eu quelques cours sur UML récemment et j’ai quelques questions à vous poser :

1.Est-il nécessaire de modéliser les use case qui n’auront pas d’impact sur "notre futur logiciel" ? Par exemple doit on modéliser l’ensemble d’un système de facturation même si notre logiciel n’interviendra que dans que dans une sous-partie de ce système (j’espère avoir été clair ^^ ).

2.Même question pour le diagramme d’activités .

3.Vaut-il mieux faire le diagramme de classe avant le diagramme de séquence lors de la conception ?

Merci d’avance pour vos réponses et bonne soirée :)

+0 -0

3.Vaut-il mieux faire le diagramme de classe avant le diagramme de séquence lors de la conception ?

Octodex

Concernant les questions 1 et 2, je ne suis pas sûr de comprendre donc je préfère ne pas dire de bêtises. Sinon, je trouve plus simple mais aussi plus logique de commencer par le diagramme de classe avant celui de séquence.

Lu’!

Pour la 1., tu ne modélises dans ton diagramme de cas d’utilisation que les actions haut niveau que vont pouvoir déclencher les acteurs principaux du système (et les éventuels raffinements de ces actions). Pour ton histoire de facturation où ton système intervient partiellement, si l’idée est qu’un autre système vient te demander un certain nombre de d’informations par une action directe : c’est un cas d’utilisation. Si le système externe vient juste consulter une base que tu as mis à jour dans tes autres cas d’utilisation, ce n’est pas un cas d’utilisation.

Pour le 2., tu modélises les diagrammes d’activité de chacuns de tes CUs. Si ce diagramme d’activité dialogue avec une autre acteur, tu ne modélises que le fait qu’il existe un dialogue, pas ce qui se passe au sein de l’autre système dans ce dialogue.

Et perdu pour la 3 ;) . On va justement partir d’un diagramme de séquence qui très abstrait (ne contenant a priori pas de classes par exemple) mais bien plus concret que ne peut l’être le diagramme d’activité par exemple. Et l’on va progressivement le raffiner de manière à faire apparaître des entités logiques qui vont représenter des tâches précises, c’est l’ajout progressif de ces entités qui va permettre de progressivement dériver les classes et les liaisons qui existent entre elles. Notamment parce que, je le rappelle, dans la conception d’une classe, on commence par penser à ses actions (que nous donne le diagramme de séquence), puis ses liaisons, et finalement seulement les attributs qui vont permettre d’assurer son travail correct.

En conception, l’idée est toujours la même : partir du plus abstrait pour aller vers le plus concret. Donc on définit d’abord les cas d’utilisation, puis on précise ces cas d’utilisations à travers le diagramme d’activité et le diagramme de séquence (on peut avoir plusieurs phases passant de l’un à l’autre d’ailleurs), ensuite on détaille au maximum ces phases de dialogue pour en déduire les entités logiques dans le programme et leur organisation (diagramme de classe et d’objet), que l’on va encore détailler vers typiquement les diagrammes état/transitions et les diagrammes de collaboration.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte