Discussion :

[MetaGolgot]

Bonjour,

J'ai lu plusieurs articles/tuto sur UML et deux plus j'ai deux livres a la maison. Le problème c'est cas la partie sur les UC sont tjrs court avec peu d'exemple!

Je suis nouveau ds une boite ou il y a quasi pas documents fonctionnelle de plus il y a plusieurs projets en dev sans aucun UC ni BUC!

Et devinez qui va devoir faire tous les UC/BUC?

Ma premiere question est si apd de ce premier UC que j'ai fais si vous pouvez m'aider a en faire un BUC pour voir la différence... ou alors c'est deja un BUC que j'ai fais!

Donc je voudrais avec votre aide voir un vrai exemple de UC et de BUC!

J'ai utilisé StarUml pour le schema (ma premiere) et il y a aussi un jpg.

voici un exemple concret:

Description Courtier:

Le courtier utilise le système Web (front end web basé sur un système interne dBCourt) pour créer ou gérer ses contrats ! A partir du système il peut choisir un client existant ou d’ajouter un nouveau.
Un courtier a un «score » (degré de relation avec la société) selon son ancienneté, portefeuille de clients, type de contrat, … Selon son « score » il a le droit de faire un nouveau contrat sans passé par un gestionnaire interne sur dBCourt.
S’il a le droit le système Web fait le contrat dans dBCourt automatiquement, crée les documents à imprimer contrat, avenants, premier quittance, qu’il renvois dans le system WEB.

S’il n’a pas le droit le systéme WEB fait le contrat ans dBCourt, il informe via courriel le gestionnaire de contrat et attends l’acceptation du gestionnaire. Le gestionnaire soit il accepte le contrat soir sous-réserves de modification après dBCourt crée les documents à imprimer contrats, avenants, premier quittance, qu’il renvois dans WEB.

Une fois que les documents sont faits dans WEBpar acceptation automatique ou gestionnaire, le courtier prends contacte avec son client.

[bruno_pages]

il va falloir relire les tutos concernant les cas d'utilisation, par exemple celui-ci

• pas de raison d'attacher un label à une relation entre un acteur et un UC, c'est l'UC qui doit dire à quoi il correspond
• par de relation entre UCs autre que des dépendance include / extend ou des héritage

[MetaGolgot]

merci,

je n'avais pas lu celui la à cause du titre :-) maintenant c'est fait! il ne dit pas plus que les autres tutos!

J'ai tenu compte de tes remarque et j'ai changé le diagramme + ce que je venais de lire est tous frais :-)

Donc pas de relation entre UC à part Include/Extend cela vaut dire il faut nécessairement affiné plus pour faire les liens entre les actions ou système!

J'insiste sur le fait que dans mon cas les systèmes elles existent mais il n'y a pas document fonctionnelle!

De plus en lisant http://www.developpez.net/forums/d19...ness-use-case/

je voudrais vraiment pouvoir voir la différence entre un UC et un BUC!

un article sur UC vs BUC
http://www.processwave.net/Essays/Bu...s_SystemUC.htm

J'ai qlqs questions par rapport à mon schéma:

1. Pourquoi je ne peux pas nommer mes systèmes?
2. l'UC Contrat Intranet représente la dB centrale qui est mis a jours par le FrontEnd! En réalité dB référentiel... est ce que j'ai présenté ca de la bonne manière?
3. la différence entre Association et DirectedAssociation (StarUML)?

merci d'avance pour vos réponses!

[chaplin]

Dans le tuto, il y a un passage dont tu ne semble pas tenir compte d'après ton analyse:

Un biais classique dans l'identification des acteurs est dû au fait que les acteurs peuvent aussi être d'autres systèmes. Aussi, il est fréquent de vouloir identifier comme acteur les référentiels de données existant dans le système d'information. Effectivement, le système à produire aura sûrement à récupérer ou à mettre à jour des données issues de ces référentiels mais le risque d'identifier ces systèmes comme acteur est qu'ensuite, lors de la rédaction des cas d'utilisation, on risque de rentrer trop tôt dans la solution et oublier l'expression première du besoin. Je ne dis pas qu'identifier ce type d'acteur est une erreur fondamentale mais l'expérience montre que l'intérêt est minime et que les biais induits sont néfastes : une description des cas d'utilisation plus proche de la solution que du besoin.

Le système communique avec l'exterieur, les acteurs sont à l'exterieur du système et les use cases à l'intérieur du système.

[MetaGolgot]

ben justement... si tu veux faire référence a "contrat intranet" qui est ma vrai dB contrat, dans ce schéma je ne l'identifie pas comme Acteur mais bien un UC du système backoffice! j'aurais pu l'appeler "Gestions Contrats"...

L'Acteur courtier y accède via le frontend et l'Acteur gestionnaire via le backoffice... je voudrais que cette notion de dB centralisé soit présent c'est pour cela que je pose la question... est ce correcte? ou la nomenclature...

merci pour ta réponse,
MG

[chaplin]

Tu veux dire que le back office est ta base de données ?

[hegros]

Tu veux lier dans ton uc de la technique et du fonctionnel ? Un UC s'est vu comme un service si c'est important de voir la base de données centralisée il faudrait utiliser un diagramme de déploiement pour le mettre en évidence.

Retrouver une base de données dans un BUC c'est contradictoire puisque les UC sont sensés représentés une grande valeur métiers.

[chaplin]

Bonjour Hegros et bonne année, comme tu le soulignes MetaGolgot mélange fonctionnel et technique.
Un site internet va forcément avoir une source d'information, frontbase en l'occurence, donc la BDD sera un élément du système.

Disons que lors du passage des use cases aux diagrammes de séquences, les interactions entre objets vont concernés des objets
qui vont servir d'interface avec la base de données, au sens d'une source d'information.

[MetaGolgot]

merci pour vos réponses,

en effet je suis débutant justement j'essaye de comprendre par rapport a mon système existant que j'ai décrit au début quel est sa meilleure représentation de digramme Uc...
Après si vous me dites pour lier fonctionnelle et technique je dois faire d'autres diagramme déploiement ou séquence ok je le ferais...

... mais d'abord j'aimerais au moins comprendre quelle est le bon UC pour bien comprendre le principe!

par exemple j'ai fais une version 3 ds l'UC... dois-je carrément enlever Gestion Contrat ds mon backoffice?

donc je voudrais une corréction de mon diagramme avec explication si possible :-)

merci d'avance,
futur MetaUseCaseMan ;-)

[chaplin]

Un use case peut-être mis en relation avec un acteur ou un autre use case:

Use Case ------------- Use Case (intérieur au système)
Use Case ------------- Acteur (extérieur au système)

Je précise volontairement intérieur et extérieur au système pour te dire que ton diagramme n'est pas "UML correct", c'est à dire qu'un Use Case d'un système ne pas être mis en relation avec un Use Case d'un autre système.
Le seul cas possible avec l'exterieur du système est la relation Acteur - Use case. En revanche, un acteur peut être un autre système.


Je pense que ça devrais t'aider en étudiant un exemple: Look Up Item Availability Use Case.

[MetaGolgot]

... donc, je dois faire abstraction totale de mes systèmes existant? comme ce schéma version 4?

et si je veux représenter le système existants avec ses fonctionnalités je dois faire un diagramme de déploiement ou séquence? je voudrais quand même rester a un niveau élevé car ce seront des documents fonctionnels pour la compréhension de l'environnement existant...

en effet j'ai regardé via google image pour "use case" et je n'ai pas vu de schéma avec liens inter-système!

... et maintenant mon UC est-il correcte?

ps: je viens de commander "UML par la pratique" et "Writing Effective Use Cases"

[chaplin]

UML par la pratique de Pascal Roques ?

En général les uses cases se trouvent dans un cadre pour distinguer le système des acteurs. Pour l'usage des notations, cela semble correct, après c'est à toi de savoir ce que tu mets dans tes use case, je ne connais pas ton sujet.

je veux représenter le système existants ... je dois faire un diagramme de déploiement

Uniquement pour la partie physique.

avec ses fonctionnalités

Ce sont les use case pour être général.

en effet j'ai regardé via google image pour "use case" et je n'ai pas vu de schéma avec liens inter-système!

- J'essaye de vérifier mes dires avant de les écrire même si ce n'est pas dans un français parfait, c'est toujours bon de vérifier .

[hegros]

Merci chaplin toi de même

Uniquement pour la partie physique.

dans un diagramme de déploiement tu peux préciser l'os d'une machine ou une version d'un navigateur web ou d'un système de base de données ou encore un fichier XML ou un composant logiciel en supplément de la partie physique que j'interprete par matériel et réseau peut-être à tord.

[chaplin]

Merçi Hegros, j'ajouterais pour complèter les Use Case et leur scénarios, d'utiliser :

• les diagrammes de séquence systèmes
• les diagrammes d'activité

[MetaGolgot]

merci pour vos réponses,

oui j'ai commandé celui de Pascale Roques, j'ai lu les commentaires dans la partie livre uml!

... donc si j'ai bien compris, j'ai besoin de deux diagramme UML distinct pour décrire le système existant:

* un diagramme UC pour le fonctionnel.
* un diagramme Déploiement pour la partie technique.

ça se complique un peu, je pensais pouvoir faire un diagramme avec une vue haut niveau fonctionnel et la présence des applications/dB!

Questions:

1. Vous avez dit pas de relation entre système ds un UC! Alors Pourquoi ds StarUml dans la partie Use Case il y a moyen de faire des packages? un package peut représenter un système et il peut etre lié a un autre package...
2. Par rapport a la description de mon problème, est ce que mon dernier diagramme UC est correcte?

...demain je vais essayer de faire un diagramme de déploiement!

si vous avez une autre manière de présenter "graphiquement" simplement un système existant avec ses fonctions de haut niveau faites le moi savoir svp!

merci d'avance pour vos réponses

[chaplin]

Vous avez dit pas de relation entre système ds un UC! Alors Pourquoi ds StarUml dans la partie Use Case il y a moyen de faire des packages? un package peut représenter un système et il peut etre lié a un autre package...

- Par package, il faut comprendre un ensemble de classe. C'est pareil de parler de biliothèque de fonction, sauf qu'en UML, la conception est réalisée en mode objet (ie classe). Un programme peut très bien se résumer à un exe, mais pour la souplesse et par rapport aux processus métiers on répartie le code entre les packages par rapport à des domaines métiers.

En bref, le code des classes est réparti dans les packages par rapport à une logique métier. Il s'agit ni plus ni moins de l'ensemble des fichiers qui contiennent le code de l'application réalisé avec UML comme langage de modélisation. Ta BDD, elle vient d'un éditeur, tu l'a considère comme un boîte noire en tant qu'installation physique. Bien entendu, ton code compilé dans les packages va donner des fichiers qui entreront en compte dans le déploiement. Sauf que dans un diagramme de package, on s'interesse à savoir ce qu'il y a dans chacun d'eux, tandis que le diagramme de déploiement va permettre de gérer les fichiers, programmes et matériels à un niveau supérieur sans regarder leur contenu.

Par rapport a la description de mon problème, est ce que mon dernier diagramme UC est correcte?

- L'usage de la notation UML est correct, les acteurs semblent bon.
Pour les noms des use case, il faut identifier les ensembles d'interactions qui constitue un objectif fonctionnel.

Entre les use cases Gerer les documents et Gerer les contrats, autant le deuxième use case est clair, autant le premier me semble évasif, faut il comprendre les documents d'un contrat ?

Tu dois avoir à l'esprit que chaque use case définit un axe métier, donc l'ensemble des use case définit la totalité des fonctionnalités de ton programme.

J'espère que c'est un peu plus clair, sinon lit le bouquin de Pascal Roques, il donne pas mal d'exemple pour avoir les idées clairs sur le sujet.

[behess]

je voudrais vraiment pouvoir voir la différence entre un UC et un BUC!

un article sur UC vs BUC
http://www.processwave.net/Essays/Bu...s_SystemUC.htm

Selon l'article que tu cites :

- le BUC serait produit dans un premier temps par l'analyste métier (chez nous : maîtrise d'ouvrage). C'est une première approche des cas d'utilisation permettant de mettre en lumière certains éléments de niveau métier.

- le SUC serait un raffinement du BUC par l'analyste système (chez nous : maîtrise d'oeuvre). C'est un développement plus abouti du BUC, avec l'ajout potentiel d'acteurs techniques ou même de sous cas d'utilisation nécessaires à la compréhension fine du besoin.

Enfin c'est ce que j'ai compris

[MetaGolgot]

... en fait après avoir lu 2 bouquins sur UML, je me rends compte qu'il est pas fait pour faire un schéma disons pour présenter une infrastructure existante sans être axé sur l'analyse.

Un Use Case doit être utilisé pour rendre compte d'un UC pas un schéma en utilisant la représentation UC qui peut emmener a des confusion si qqn connait la notation UML!

Donc le bon vieux VISIO fait tjrs l'affaire pour présenter une vue globlae de l'infrastructure avec ou sans "actions" des utilisateurs si nécessaire pour le schéma!

Merci a tous pour vos réponses!