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.