A partir du diagramme des classes complet d'un prototype, il peut s'avérer intéressant de construire divers diagrammes d'interactions (communications ou séquences) pour vérifier la circulation des messages entre les classes. L'intérêt de ce travail est de montrer la nécessité de rajouter des méthodes d'accès aux attributs des classes, afin de respecter leur encapsulation ou bien de faire apparaître des méthodes qui auraient été oubliées.
Ces diagrammes sont construits pour quelques scénarios intéressants ou pour analyser en détail certains cas particuliers.
Nous allons illustrer ce cas dans le cadre du prototype 2 pour un scénario de saisie d'un dossier accident. Ce cas doit être analysé en détail car il nécessite l'accès à plusieurs classes : Dossier pour créer le nouveau dossier, Contrat pour rechercher les informations complémentaires sur l'assuré, Véhicule pour rechercher des informations complémentaires sur le véhicule accidenté, TiersInterne dans le cas où un tiers est également assuré, TiersExterne pour créer les tiers impliqués et pour les relier à la compagnie à laquelle ils sont assurés.
Le diagramme de communications correspondant à ce scénario est le suivant (l'indice i représente les divers véhicules impliqués dans l'accident) :
Ce diagramme représente l'un des scénarios possibles pour saisir un dossier mais il en existe bien d'autres.
Par exemple, à l'étape 2: rechContrat(d), l'utilisateur peut se rendre compte que le contrat de l'assuré a été résilié et qu'il ne peut plus poursuivre.
A l'étape 3: sélectionVéhicule(c), il peut constater que le véhicule n'est plus assuré dans le cadre de ce contrat.
A l'étape 6.1: lierCompagnie(t), il se peut que la compagnie indiquée dans le constat de l'assuré n'existe pas et qu'il faille la créer alors que l'utilisateur n'a pas le droit de créer des compagnies.
Pour un cas réel, tous ces points doivent être pris en compte et il faudra proposer une solution pour chacun.
