Discussion :

[scofield]

bonjour ,
je suis appelé a modéliser avec uml .Et pour les use case , quand je vois ce qui se fait !je met un peut l'approche habituelle .Et après ca, ma promotrice me dit que j'ai pas a faire ce qui se fera au niveau de l'application final (les taches).
juste un diagramme global, qui sera détaillé de plus en plus .

donc ,si moi je trouve ;ajouter enregistrement, supprimer, modifier, dans plein de use case .Et celle la me dit non : bonjour la bonne conception

bref ,voici joint un petit descriptif des rôle d'un des service appartenant a mon domaine d'étude . les deux dernier vont suivre bientôt.
vente - maintenance -pièces détachés

Et aussi ,est ce qu'on doit mettre les tableau des taches et les fiche des cas d'utilisation une par une avant les diagrammes .
enfin , quelle sont les critères concernant la profondeur du détail ou pas, dans les use' case! (quand est ce qu'on détaille et quand on le fait moins)

bientôt je mettrai les diagramme catastrophe et vous pourrai m'éclairer si possible .

[ego]

Bon, plusieurs points.
Peux-tu mettre un peu de ponctuation dans tes phrases car on du mal à lire sans cela.

Pour tes exemples, il faut déjà mettre des verbes à l'infinitif car sans cela, les phrases (au niveau de chaque rôle) sont ambigues.
Dans tes exemples, il semble que certains éléments soient faits en dehors d'un quelconque logiciel. Cela ressemble donc plus à des activités métier indépendamment de toute informatisation. Il ne faudrait donc retenir que ce qui est en lien avec le logiciel (ce que logiciel pourra faire).
Pour avoir une idée plus claire sur les cas d'utilisation, regardes ici

[scofield]

avec un peut de retard c vrai ,mais quand même au rdv.
pas la peine de rire au nez , j demande juste un peut de lumière sur cette affaire.

voila en 2 temps ce que j'ai fait , les role des acteur des 3 service :
-Vente .Pièces détachés .Maintenance.

et des diagrammes uses cases ..!
en pièce jointe.
MERCI A VOUS
PS: les uses case sont dans un fichier word ZIPé.

[ego]

Je supprimerai "DG" car j'ai plus l'impression que tu décris ici des éléments de hiérarchie au sein de l'entreprise.
Les vrais acteurs semblent plutôt être les autres acteurs R.... et FC

Je supprimerai "Authentification" et "Changer mot de passe"
Je ne garderai que :
- Vente pièce
- Achat pièce (est-ce vraiment un UC, quelle différence entre Vente et Achat)
- Vente véhicule
- Etablir ...


Maintenance, je mettrai, comme je te l'ai dis précédemment, des verbes à l'infinitif.

Euh.........je viens de lire l'ensemble de tes UC, c'est la folie.

As-tu lu mon article sur les relations entre UC.
Tes schémas ressemblent à des sacs de noeuds, n'utilises AUCUNE relation entre UC et mets toi SIMPLEMENT dans la peau de chaque acteur quand il arrive devant ton application, il doit se dire "Tiens je lance l'application XX pour faire YYY car je suis payé pour faire YYY"

Et le YYY est un cas d'utilisation.
Restes en au YYY sans essayer de faire des relations. Ton UC "Maintenance" est plutôt un package de cas d'utilisation

[scofield]

Bonjour ego , franchement je suis a la fois reconnaissant et désolé que tu ai lire ces use cases .
par ce que ils était assez mal foutue ,si j puis dire .Bien que ce matin en 20minute j'ai pu rabibocher
un peut certain avec deux amies .
le problème c'est qu'ici a la fac les prof ne sont pas aussi a la page qu'il le prétendent .
je veut dire qu'a part les exo académique rien de concret.justement , j'ai même pu convaincre ma
promotrice cet après midi de la validité des mes uses. comme quoi qu'on en a pas de pro a coté "pas le choix.

voila , pour la vente et l'achat de pièce on a rajouté la première pour parler des cas d'établissement bon commande de
pièce(chez le fournisseur).
l'authentification c'est le truc sacré ici , comme mon application est sous oracle donc , c'est aussi la pour administrer
les utilisateur(acteur).et comme ya pas d'administrateur (en doit met qq a la palace) comptable etc d'où le dg.

POUR résumer , IL Y A deux service maintenance et pièces détachés qui sont relié dans les cas de prestation ou ,changement de pièce y a!et la vente presque dissocié des deux autre dans le system (sauf si ya des client qui font leur carnet de garantie chez eux ce qui na pas l'aire de les intéresser).

ET AU FAITE , elle a accepté les uses case modifié et on passe , au diagramme de séquences , puis de collaboration
(au lieu de passer direct a l'activité).
bizarre dilem que ce lui ci , j'ai pas envie de traîner puisque ici y a pas d'aide sure et garantie , et comme c'est a
moi de programmer toute cette application pendant les vacance (mon binome ne veut pas) , en même temps j'ai envie d'apprendre a faire bien .
LES CAS retouché son joint en bas Rmq: je ne sais pas si je pourrai poster un schema qui décrit de façon pratique tout les processus (1.pour la vente véhicule , et 1 pour la maintenance et pièces détaché en interaction ou en voie tout "fait par moi").

PS: comme le forum na pas le temps de ce substituer au encadreur officiel avant nous le choix ? ENCORE MERCI 1x100

[ego]

je reste sur mes remarques :
- des UC qui devraient être plutôt des packages
- trop de relations inutiles voire sémantiquement fausses
- des UC bizarres i.e. voir achat et vente déclenché par le même acteur c'est plus que bizarre. Je n'arrive pas vraiment à imaginer quil y ait les 2 UC dans une même application. Une explication sur ce point ?

Pour tes profs, recommandes leur de consulter le forum !!

[scofield]

bonjour ,

peut tu mettre tes remarques ou correction , en precisant a quel figure elle sont destiné.

fig.1

fig.2

fig.3

fig4
ps: "j'achete la piece chez les fournisseur et je la vend pour les clients voila pr les cas." ET MERCI