Discussion :

[kiricesa]

bonjour tout le monde!
je voudrais une aide pour faire la modélisation du'une application pour la gestion informatisée du transport scolaire sur abonnement!
l'application devra permettre aux usagers:
1. Enregistrer les abonnés et pouvoir traiter les données y relatifs (modifier,supprimer, afficher)
2. Editer leur carte d'abonnement si l'abonné est nouveau ou modifier certaines informations dessus si jamais l'abonné changa d'etablissement.
3. Pouvoir retrouver le conducteur qui a effectué le transport a une date donnée pour les cas où il y aurait une plainte
4. montrer les différentes stations d'arret(les lignes)

j'ai fait un MCD et je voudrais que votre aide dessus afin de pouvoir en faire un diagramme de ces d'utilisation.

[ok.Idriss]

Salut.

Pour commencer, les différentes données du MCD doivent être uniques. Par exemple, on ne doit retrouver ni idEtablissement ni idPeriode, ni idEmploye dans ton entité Abonné. On ne doit pas non plus retrouver les attributs idVehicule, idEmploye dans l'entité Ligne.

Pour les mêmes raisons, il faut donner un nom différents aux attributs similaires comme par exemple les différents noms, prénoms, numéros de téléphone, etc

Par ailleurs tu utilise les mêmes cardinalités pour chaque associations (1,n partout ). Es-tu certain que cela répond bien à tes règles de gestion ?

Quelques exemples :

Un abonné peut-il vraiment fréquenter plusieurs établissement à la fois ? J'aurais tendance à dire que l'on ne fréquente qu'un seul établissement à la fois par abonné (cardinalité 1,1) ...

Un véhicule est-il forcément conduit par au moins 1 conducteur ? Un véhicule venant d'être acquis n'a pas encore été conduit => J'aurais donc plutôt tendance à mettre une cardinalité 0,n même si ça ne change pas grand chose au niveau logique.

As t-on forcement au moins un abonné par établissement enregistré ? Quand on en est pas certain, il vaut mieux mettre une cardinalité plus large (0,n) ... sauf si tu en es certain bien entendu ...

Autre chose : Le conducteur n'est-il pas lui aussi un employé ?

Bref, voici déjà ces quelques points à revoir

Cordialement,
Idriss

[montesq]

j'ai fait un MCD et je voudrais que votre aide dessus afin de pouvoir en faire un diagramme de ces d'utilisation.

Déjà il faut te mettre d'accord avec toi même: tu postes dans le forum UML et tu parles de MCD

Sinon, d'autres remarques concernant ton pdf:
1° conducteur, abonné, employé sont avant tout des personnes qui ont des attributs communs (nom, prénom, adresse, tél...)
2° je pense qu'il est nécessaire de distingué l'abonné et son abonnement
3° les attributs début service, départ et arrivée ne doivent pas appartenir au véhicule

[ok.Idriss]

Déjà il faut te mettre d'accord avec toi même: tu postes dans le forum UML et tu parles de MCD

Effectivement, je n'ai pas fait attention à ce détail ...

Le choix du MCD pour la gestion des données est un bon choix mais attention : il s'agit de modéliser la base de donnée et non l'application dans son intégralité.

Le MCD et un schéma de la méthode MERISE (et non le langage d'analyse et conception UML), il faut donc poster sur le forum MERISE. Un modérateur pourra sans doute déplacer le sujet ...

Cordialement,
Idriss

[kiricesa]

Salut!
merci beaucoup pour vos suggestions!
la raison pour laquelle j'ai posté sur le Forum UML est que je veux partir d'un MCD pour faire la modélisation en UML car je n'y connais pas grand chose!

[ok.Idriss]

Le MCD te sert à modéliser la base de données d'un SI ... Certains utilisent le diagramme de classe UML aux mêmes fins ou le schéma entité/relation américain équivalent au MCD. Dans tout les cas, une seule modélisation (correcte) au niveau conceptuel suffit.

Attention toutefois, avec ton MCD tu modélise la bdd et non la totalité de l'appli (UML peut te servir pour modéliser les cas d'utilisations, les scénarios d'exécutions, puis les classes, etc).

Cordialement,
Idriss

[kiricesa]

bonjour!

tenant compte de vos remarques,j'ai fait un autre MCD mais les difficultés persistent.
pour les véhicules,j'ai maintenu la cardinalité 1,N car nous ne parlons que des véhicules déjà acquises.
1. c'est vrai le client(abonné),l'employé et le chauffeur sont tous des personnes,mais comment faire puisque ces personnes remplisent des fonctions distinctes?
2. qu'entendez vous par séparer l'abonné(client) de son abonnement?
3. est-il possible de trouver à partir de ce MCD des cas d'utilisation?au fait ma moélisation doit être faite en UML comme je l'ai déjà dit.
merci de bien vouloir continuer à m'aider.

[montesq]

bonjour!

tenant compte de vos remarques,j'ai fait un autre MCD mais les difficultés persistent.
pour les véhicules,j'ai maintenu la cardinalité 1,N car nous ne parlons que des véhicules déjà acquises.
1. c'est vrai le client(abonné),l'employé et le chauffeur sont tous des personnes,mais comment faire puisque ces personnes remplisent des fonctions distinctes?
2. qu'entendez vous par séparer l'abonné(client) de son abonnement?
3. est-il possible de trouver à partir de ce MCD des cas d'utilisation?au fait ma moélisation doit être faite en UML comme je l'ai déjà dit.
merci de bien vouloir continuer à m'aider.

1. il s'agit de la notion d'héritage en UML
2. le client porte des attributs de type: nom prénom, age, adresse... L'abonnement porte des attributs de type: date de début de validité, date de fin de validité, "zones"... En outre, un client peut avoir plusieurs abonnements au cours de sa vie, donc il s'agit bien de classes différentes
3. Vous faites les choses à l'envers. Si vous voulez modéliser en UML alors il est plus logique d'abord d'identifier les cas d'utilisations et d'ensuite faire le diagramme des classes (qui sont les classes qui interviennent dans les cas d'utilisation identifiés)

[ok.Idriss]

1. il s'agit de la notion d'héritage en UML

étant donnée qu'il s'agit d'un MCD, je dirais plutôt qu'il aille voir du côté des extensions de MERISE II (dont l'héritage fait partie).

3. Vous faites les choses à l'envers. Si vous voulez modéliser en UML alors il est plus logique d'abord d'identifier les cas d'utilisations et d'ensuite faire le diagramme des classes (qui sont les classes qui interviennent dans les cas d'utilisation identifiés)

Tout à fait , sauf s'il se concentre uniquement sur la gestion des données de son application. Après, il est vrai qu'avant de se concentrer sur la gestion des données, il est mieux de faire les spécifications de son application (notamment avec cas d'utilisations en UML).

Cordialement,
Idriss

[montesq]

@ok.Idriss

au fait ma moélisation doit être faite en UML comme je l'ai déjà dit.

En conséquence, je propose d'arrêter de parler de MCD, Merise... et de se concentrer sur UML. Je ne pense pas que mélanger MCD et diagramme de classes aide beaucoup notre ami qui ne semble pas encore avoir les idées bien au clair jusqu'à maintenant

[ok.Idriss]

@ montesq :

1. Enregistrer les abonnés et pouvoir traiter les données y relatifs (modifier,supprimer, afficher)
2. Editer leur carte d'abonnement si l'abonné est nouveau ou modifier certaines informations dessus si jamais l'abonné changa d'etablissement.
3. Pouvoir retrouver le conducteur qui a effectué le transport a une date donnée pour les cas où il y aurait une plainte
4. montrer les différentes stations d'arret(les lignes)

Il s'agit aussi de gestion de l'information (SI), donc MERISE est bien adapté à ça. Après, il est vrai que cela semble confus ... et que le PO ne semble pas savoir ce qu'il veut.

Comme tu le dit, il faut d'abord partir de cas d'utilisations UML, la gestion des données viendra après ...

[kiricesa]

salut!

merci pour vos conseils!

là je vous présente mon diagrame des UC et je pense que j'ai besoin de vous pour vos critiques et surtout pour me corriger et me sugerer ds solutions.
merci

[kiricesa]

bonjour!

la description du cahier des charges est comme suit:

L'OTRACO dans ses taches cotidiennes assure entre autres le transport scolaire sur abonnement.
un client qui a besoin de beneficier de ces services se présente à la caisse,paie un montant qui est fonction de la distance entre son lieu d'habitation et son etablissement!la caisse lui donne en echange un rçu.le client présente le reçu à un agent du service exploitation qui prend en charge les abonnement.ce dernier à la vue du reçu inscrit le client dans le registre (les clients fréquentant des écoles différentes, chaque établissement a son registre), complète à l'aide d'une machine à écrire la carte d'abonnement, temponne les cases correspondants à sa période d'abonnement, la signe et la lui donne.
si au cours d'une même année scolaire le client décide de changer d'etablissement, il revient payer et on lui fait une nouvelle carte et on l'enregistre dans le registre du nouvel établissement.

pour ce qui est du transport, à chaque ligne on envoit un bus qui effectue le ramassage des elèves et les bus peuvent varier tous les jours et evidement les chauffeurs!
quand un client vient se plaindre pour un service mal rendu par le chauffeur,on demande la date puis on verifie quel chauffeur etait de service sur cette ligne et à cette date pour lui demander des explication.

j'ai essayé de faire un diagramme des as d'utilisation mes j'ai besoin que vous m'aidiez!

1. est ce que j'ai choisi les bon acteurs?
2. est ce que mes cas d'utilisations sont ils appropriés?
3. les relations entre elles sont elles correctement mises?

S'il vous plait aidez moi en me donnantvos critiques et vos conseils
merci