Discussion :

[poulpe77]

bonjour

pour un site web, j'aimerais avoir un conseil pour modéliser un espace client, dans lequel le client peut :
- s'authentifier puis accéder à un tableau de bord
- gérer son compte (modifier ses coordonnées, email,...)
- gérer ses contrats (visualiser détail, modifier certaines propriétés d'un contrat)

si je prends comme use case : "s'authentifier", "consulter le tableau de bord", "gérer son compte" et "gérer ses contrats", comment faire ensuite ? pour modéliser les dss (diagrammes de séquence système ?
si qqn avait déjà réalisé un tel, je suis preneur d'exemple et de conseils
merci pour votre aide

[slim]

Salut !

"gérer son compte" et "gérer ses contrats" ne sont pas des cas d'utilisation. Ils comportent surement plusieurs cas. Chaque cas doit être atomique (élémentaire). Tu dois les décomposer afin d'obtenir des cas d'utilisation (c'est ce que tu as mis entre parentheses).

En ce qui concerne les DSS, il faut pour chaque cas, identifier les classes qui effectuent le traitement et les opértions (fonctions) correspondantes et formaliser la communication entre ces classes dans le temps (c'est la definition des DSE). Tu peux trouver de la doc un peu partout sur internet ("diagramme de séquence", "UML"...). Par contre, pour les DSS, ce sont les interactions (messages) entre l'utilisateur et le systeme qui sont schematisés. C'est là que tu vas retrouver tes cas d'utilisation.

voici une discussion que j'avais créé concernant UML, il y a un diagramme de seq systeme :
gestion d'une bibliothèque

a++

[poulpe77]

je comprends ton point de vue
mais je croyais que les cas de type CRUD (créer, voir, modifier, supprimer) n'étaient qu'un seul use case

prenons l'exemple d'un contrat : avec un montant et une date .

l'espace client permet de voir le contrat, et de modifier le montant, ou la date, de façon indépendante.

tu ferais comme cas : "voir le contrat", "modifier la date du contrat", "modifier le montant" ? là on descend au niveau de la fonctionnalité non ?

à mon avis, c'est le même service métier qui est derrière pour voir et modifier le contrat. Pourquoi ne pas faire un use case "gérer le contrat" ?

[slim]

Tu as raison, on ne doit pas mettre de fonctionalites dans les use cases.
Les cas que tu peux trouver concernant un contrat sont :
- consulter
- creer
- modifier
- supprimer
- etc. (exemple : envoyer, dechirer )

Modifier la date ou le montant d'un contrat n'est pas un cas d'utilisation. C'est une fonctionnalité.

Par contre, "gérer le contrat" regroupe plusieurs cas d'utilisations...

[Nip]

Desole slim mais je ne suis pas du tout d'accord avec toi, les cas d'utilisation cites par poulpe77 sont tout a fait justes.
Les cas que tu donnes sont tout simplement de la decomposition fonctionnelle: "gérer le contrat" est un cas d'utilisation et ne regroupe pas d'autres cas, et ce sont les fonctions associees a cet UC que tu cites en exemple.

Je me repete mais les UC correspondent a la capture des besoins fonctionnels, pas a la decompostion fonctionnelle.
A lire: http://ego.developpez.com/uml/tutoriel/casUtilisation/

[slim]

C'est vrai que j'ai tout faux !

C'est que des fonctionnalités que j'ai mis. Autant pour moi.

[poulpe77]

Merci à Nip et Slim pour vos remarques

maintenant que je dispose des cas d'utilisation, je pense faire l'étape suivante :
- écrire les scénarios nominaux et alternatifs de chaque fonctionnalité présente dans un use case (
- présenter un diagramme de séquence système pour chaque scénario de chaque fonctionnalité

par exemple : "gérer les contrats" permet de visualiser la liste des contrats, visualiser le détail d'un contrat, de modifier par exemple une date et un montant (indépendants)

comment je dois présenter le chose en matière de "scénarios" et de "diagramme de séquence système" ?

merci d'avance