Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Bonjour,
Merci infiniment Cinephil, hed, et ifa
J’ai modifier mon digramme de classe en suivant vos conseils, et maintenant je m’intéroge sur les autres diagramme dont j’aurai besoin !
A mon avis je n’aurai pas besoin d’un digramme de séquences, ni d’un digramme d’activité, ni d’un diagramme de composants, ni d’un autre diagramme !??
Mais no ! Je rigole !! Je ne sais pas de quel autre diagramme j’aurai besoin dans ma conception !! Pouvez-vous m’éclaircir !
De manière générale, voici les diagrammes que l'on fait :
UC
DC
Séquence (au moins un par UC)
Ensuite, selon tes besoins, et selon ce que tu veux rendre plus explicite, tu ajoute tout autre diagramme de ton choix.
De retour
Bonjour
Question urgente ! au niveau du diagramme de classe pourquoi ne pas faire une classe client mère et deux classes filles 'client OCP' et 'client_concurrent' pour différencier nos clients par rapport à ceux de nos concurrent dans le marché ?? et même chose pour les produits ??
changement dans les critères de mon systéme :
Mon systéme ne s'occupe pas des commandes faites par nos client !
Alors est ce que dans ce cas je peux faire une association directe entre la classe 'client' et la classe 'produit' pour connaitre les différents produits acheter par nos clients (même chose pour le sproduits acheté par les clients de nos concurrents) ??
merci de me répondre le plus possible sur ma question !
j'attend vos réponses
Au niveau diagramme de classes, les clients de tes concurrents sont identifiés par l'association qui existe entre Concurrents et Entreprises ; il me semble qu'on ne représente pas la classe résultant de cette association puisqu'on est au niveau conceptuel.Envoyé par _medi
Question urgente ! au niveau du diagramme de classe pourquoi ne pas faire une classe client mère et deux classes filles 'client OCP' et 'client_concurrent' pour différencier nos clients par rapport à ceux de nos concurrent dans le marché ?? et même chose pour les produits ??
Oui bien sûr !changement dans les critères de mon systéme :
Mon systéme ne s'occupe pas des commandes faites par nos client !
Alors est ce que dans ce cas je peux faire une association directe entre la classe 'client' et la classe 'produit' pour connaitre les différents produits acheter par nos clients (même chose pour le sproduits acheté par les clients de nos concurrents) ?
Au contraire, je trouve àa possible. Après, cela reste un choix, il faut voir à quoi cela t'avances de faire cet héritage.pourquoi ne pas faire une classe client mère et deux classes filles 'client OCP' et 'client_concurrent' pour différencier nos clients par rapport à ceux de nos concurrent dans le marché ??
Bonjour,
Pour identifier les clients de nos concurrents !il faut voir à quoi cela t'avances de faire cet héritage.
Par rapport aux autres diagrammes :
pour les UC je ne vois pas quel cas d'utilisation je dois faire !De manière générale, voici les diagrammes que l'on fait :
UC
DC
Séquence (au moins un par UC)
Vous pouvez me donné un exeple de UC dans ce systéme ?
A se soir
Poses toi simplement ces deux questions :Vous pouvez me donné un exeple de UC dans ce systéme ?
- Qui va utiliser ton programme ?
- Pourquoi vont ils l'utiliser (sous entendu, pourquoi faire?)
La 1e question te donne tes acteurs, la deuxieme tes cas d'utilisations.
Bonjour
Alors les profils concernés:Poses toi simplement ces deux questions :
- Qui va utiliser ton programme ?
- Pourquoi vont ils l'utiliser (sous entendu, pourquoi faire?)
- administrateur: alimentation des tables
- Responsable veille: pour validation des données
- utilisateur: pour consultation
Le diagramme de UC et comme suite :
Mais je dois le détailler encore plus, et je ne sais pas comment faire !!??
Aussi, au niveau du diagramme de classe je dois faire un rapport de chaque classe ! je ne sais pas de quoi s'agit-ilpouvez-vous me donné un exemple ?
Après tu peux disséquer les patates.
A première vue, je pense qu'il va y avoir une liaison entre la patate 'alimenter les tables' et la patate 'valider les données'. La deuxième a besoin de la première.
Pour disséquer demande toi :
- que fait l'acteur ?
- quelle conséquence à l'intérieur de la patate ?
On peut imaginer que lorsque l'administrateur va insérer de nouvelles données, il y aura un message vers le responsable veille pour lui demander de contrôler et valider les données afin de les rendre disponibles pour l'utilisateur.
Regarde sur des tutoriels UML (tu en trouveras sûrement sur ce site) pour savoir comment représenter tout ça. Perso je n'ai quasiment jamais fait de Use Cases (sauf en cours une fois) alors je ne peux pas trop t'aider.
Qui te le demande ?Aussi, au niveau du diagramme de classe je dois faire un rapport de chaque classe !
Je ne sais pas trop ce que ça veut dire non plus ! Il veut quoi le demandeur dans le rapport ?
Pour moi un diagramme de UC avec trois use case n'est pas choquant.
Bonjour,
grazie mille les mecs, vous êtes toujours la pour m'aider
mon responsable de stageQui te le demande ?
j'aimerai bien que ca soit aussi l'avis de mon responsable de stage par ce que lui il trouve mon analyse 'trééééés léger'Pour moi un diagramme de UC avec trois use case n'est pas choquant.
Cinephil merci bcp, j'ai réussi à disséquer mes patatesAprès tu peux disséquer les patates.par un diagramme d'activité.
Maintenant j'ai besoin de faire un diagramme de collaboration haut niveau ! mais je ne vois pas ls objets que j'aurai dans ce diagramme !
Si le diagramme avec trois UC est l'ensemble de ton analyse, alors oui , c'est trèèèèèèès légerCitation:
Pour moi un diagramme de UC avec trois use case n'est pas choquant.
j'aimerai bien que ca soit aussi l'avis de mon responsable de stage par ce que lui il trouve mon analyse 'trééééés léger'
Par contre, un dossier avec trois UC, description textuelle des trois, scénarii (diagramme de séquence système) nominal, alternatif, exceptionnel et eventuellement maquette, là, c'est loin d'être léger.
Bonjour
c'est déja fais, Merci hedun dossier avec trois UC, description textuelle des trois, scénarii (diagramme de séquence système) nominal, alternatif, exceptionnel et eventuellement maquette
au niveau du diagramme de collaboration haut niveau
Est-ce, je vais placé mon système qui est le SGBD_Marketing comme objet centrale, et les acteurs : admin, responsable veille, utilisateur ?
Pas forcément, tu n'es pas obligé d'avoir un seul diagramme de collaboration , tu peux en avoir un par use case par exemple.
Bonjour
No ! mais le diagramme de quel je parle c'est au niveau de la phase d'étude préliminaire (capture du besoin), c'est un d'un diagramme de collaboration haut niveau permettant de modéliser le contexte (système/acteurs et messages haut niveau).Pas forcément, tu n'es pas obligé d'avoir un seul diagramme de collaboration , tu peux en avoir un par use case par exemple.
Sinon, si vous êtes d'accord, c'est correcte ce que j'ai fais ?
Mercije vais placé mon système qui est le SGBD_Marketing comme objet centrale, et les acteurs : admin, responsable veille, utilisateur ?
Je ne sais pas, je ne fais jamais ce genre de diagramme, qui semble (me tromperais je?) identique au diagramme de use case.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager