[Modélisation] Cas d'utilisation et acteurs

Bonjour,

Je me pose deux questions simples sur le sujet :

1/ identification des acteurs

Est-ce judicieux sur un diagramme de cas d'utilisations de faire apparaître distinctement les profils d'acteurs qui utilisent un même cas d'utilisation ? Je dirais que oui mais j'aimerais votre confirmation que la notion d'acteur est liée à celle de profil d'utilisateur.

2/ traitements batchs

Un ensemble de traitements batchs est-il un cas d'utilisation ? Je n'ai rien trouvé à ce sujet, j'ai pê mal cherché. Si oui, quel acteur identifier ?

Merci pour votre aide :)

Frédéric

Je me permettrais de donner mon avis que sur la première question.

Dans des udescases tu es sencé représenter comme acteur, toute personne ou système extérieur ayant un impact sur ton système.

Le profil est une notion qui apparait dans ton système je pense. Par contre au niveau de tes usecase tu aura autant d'acteur que de profil mais rien ne devra montrer le lien qui les regroupent. En gros pas de généralisation.

Il n'y a pas moyen de regrouper les profils de toute façon.

En fait, je pense que la notion d'acteur est à comprendre comme "rôle". La notion de profil est différente mais finalement liée car derrière un rôle, on peut imaginer vraisemblablement un profil utilisateur.

A+, Fred

Je suis d'accord avec toi.

Le truc est, je pense, de ne pas faire apparaitre une notion de profil car elle est plus applicative que fonctionnel. Maintenant on est d'accord qu'implicitement elle apparait tout de meme

C'est vrai, il ne faut pas confondre cas d'utilisation et algorithmique du systeme.

Mais vous ne croyez pas que la gestion de profils puisse apparaitre dans les use cases? Je verrais bien un uc du genre "gerer le profil" ou "identification" non?

Pour les traitements batch, ben si c'est un process lance par un acteur, t'as tout interet a presenter dans ton diagramme un uc "Lancer XXX" ou XXX est la notion fonctionnelle liee a ton batch. Si un traitement batch permet a un acteur de reinitialiser un base par exemple, ce n'est pas le traitement batch que tu vas montrer mais plutot un use case "Reinitialiser un base", voire meme plus generique "Maintenance".

Si par contre le batch est lance en interne a partir d'un point d'entree de plus haut niveau, aucune raison de faire apparaitre ton traitement batch dans le diagramme general.

En gros, c'est un traitement, pas un cas d'utilisation.

Pour la Q1, un acteur est effectivement à prendre comme "rôle". Il faut donc identifier les rôles que les différents utilisateurs vont jouer vis-àvis de ton système.
Pour Q2, les batchs, plusieurs points à ce sujet. La notion de batch est une notion de niveau implémentation donc elle ne doit pas apparaitre à haut niveau. Ensuite 2 cas se présentent.
Ce qui est fait par ton batch est en fait une fonctionnalité rendue pour réaliser un UC (soit une des étapes soit une post-condition par exemple). Dans ce cas, il ne faut pas parler de batch en terme "batch". Pour te donner une idée, dans le UC "Ouvrir un compte bancaire" on peut avoir une simple post-condition qui dirait "Le compte est créé dans la base des comptes communs et le système éditera un relevé de compte tous les mois (cf. règle de gestion N°23 - Editer un relevé de compte mensuel).
L'édition du relevé sera probablement réalisée au sein d'un batch mais come tu le vois, on n'a pas employé le terme dans la spécification du UC.
Autre cas, ce que fait ton batch n'est pas rattachable à un UC. Par exemple : règle de gestion N°31 - Purger la base contrat tous les 6 mois...
Là, l'utilisation même des UC n'est pas nécessaire et encore une fois, on spécifie l'exigence pas la solution.

En fait, les gens, surtout issus que gros système, s'attachent souvent à LEURS batchs en oubliant que cela répond en fait à un besoin initial qu'ils ont implémenté sous la forme de batch (et c'était sûrement la bonne solution !).
L'important dans cette affaire est donc comme toujours de bien exprimer le besoin et non la solution. Comme cela on sait d'où vient la dite solution et il est donc plus facile de faire le lien entre cette solution est le besoin réel du client.