Discussion :

[Ikki_2504]

Bonjour,

Je débute avec UML, et j'aurais souhaité vos avis / critiques d'un diagramme de classes que j'ai réalisé dans le cadre d'un TP (image de mon travail plus bas).

L'objectif est de construire un diagramme de classe modélisant un de ces jeu pour enfants, où l'on construit un circuit avec des rails que l'on clipse ensemble, et que l'on fait avancer un petit train dessus.

Il y a 4 fonctionnalités principales à modéliser :
1 - construction d'un circuit à partir de rails de bases (droit, virage à droite, virage à gauche, aiguillage, pont, passage à niveau)
2 - Construction d'un train à partir de voitures de base (locomotive, wagon, voiture de voyageurs, …)
3 - Positionnement du train sur le circuit,
4 - Déplacement du train sur le circuit en ayant la possibilité de modifier les aiguillages et de choisir la direction du train.

Le passage à niveau doit simuler le fonctionnement d'un vrai passage à niveau. Lorsque le train en approche, une sonnerie devra retentir, des lumières clignoter pour signaler l'arrivée du train et les barrières devront se fermer et rester fermées jusqu'à ce que le train soit passé.


=> Mon diagramme est encore incomplet, mais n'étant pas sûr de la modélisation de base, je viens demander vos avis avant de partir sur une fausse piste

=> Ma 1ère version : http://www.noelshack.com/up/aac/trai...ec2657ef12.png

S'il y a des choses choquantes / fausses / à améliorer / incompréhensibles, n'hésitez pas

Merci d'avance !

[hegros]

Pourquoi est-ce qu'il y a 4 fonctionnalités et qu'un seul diagramme de classe ?

Les méthodes des classes tu les as trouver comment ? A partir d'un diagramme de séquence ?


Pour voiture c'est pas très clair pourquoi tu utilises une réflexivité ?

La classe autre ne devrait pas apparaître si c'est pour indiquer qu'il y a encore une analyse de ce qui pourrait bien hériter de rail..

cela ne me plait pas trop l'héritage comme design ( passage à niveau d'un rail), je verrais plus une composition avec le circuit comme tu l'as fais entre circuit et rail (donc composition entre circuit et passage à niveau plutôt que l'héritage)

[Ikki_2504]

Bonjour, et merci de vous être penché sur mon problème

Il n'y a qu'un seul diagramme pusqu'au final, cela représente un logiciel, et toutes les fonctionnalités sont liées... Il faut faire un diagramme par fonctionnalité ??

Les méthodes, je les ai "inventées", c'est-à-dire que je me suis posé la question "si je devais programmer le logiciel basé sur ce diagramme, de quelles méthodes aurais-je besoin pour le faire fonctionner ?"

Pour voiture, j'utilise une reflexivité car un train est composé d'une locomotive et de n voitures. Cela permet de répondre un point 2, à savoir créer un train dont les voitures sont liées entre elles...

La classe "autre", je l'avais créée justement parce que je ne vois pas trop quoi différencier entre un rail "droit", un rail "virage à gauche", "virage à droite" etc... Je veux dire par là qu'ils n'ont aucune propriété différente si ce n'est leur nom. Devrais-je approfondir + ce point ? Et si oui, que mettre dans les différentes classes ainsi créées ?

Enfin, quel est le problème soulevé par l'héritage ? Pourquoi la composition serait-elle plus appropriée ici ?

En attendant une réponse, je vais une V2 en tenant compte des remarques

[hegros]

Il n'y a qu'un seul diagramme pusqu'au final, cela représente un logiciel, et toutes les fonctionnalités sont liées... Il faut faire un diagramme par fonctionnalité ??

La logique 1 logiciel = 1 diagramme est erronée. Imagine un logiciel de plusieurs milliers ou millions de ligne de code est-ce qu'il serait possible de tout faire rentrer dans 1 diagramme ? Il est préférable d'avoir une vue par fonctionnalité + 1 vue qui les réunis

Les méthodes, je les ai "inventées", c'est-à-dire que je me suis posé la question "si je devais programmer le logiciel basé sur ce diagramme, de quelles méthodes aurais-je besoin pour le faire fonctionner ?"

Il est préférable de faire un diagramme de séquence pour la fonctionnalité x et d'en déduire ainsi les méthodes. Est-ce que tu as fais un diagramme de séquence pour voir si tes méthodes collent bien à la dynamique du logiciel ?

Enfin, quel est le problème soulevé par l'héritage ? Pourquoi la composition serait-elle plus appropriée ici ?

Car je peux écrire ceci qui n'a pas de sens pour des rails mais plutot pour le passage à niveau (je reconnais que c'est un choix conceptuel au final mais cela ne me semble pas un bon design ton choix)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Rail rail = new PassageANiveau();

rail.AllumerFeux();
rail.LeverBarrieres();
rail.DeclencheSonnerie();

[Ikki_2504]

Ok, c'est certain que pour un "vrai" logiciel, un seul diagramme n'est pas possible. Mais dans mon cas, il y a assez peu de fonctionnalités, et donc il faut voir ce diagramme comme "la vue qui les réunit toutes".
Et puis malheureusement, je ne coderais pas le logiciel qui découle de ce diagramme, car je fais ce TP dans le cadre d'un cours de Conception, et en Conception... on conçoit, mais on ne programme pas (oui c'est dommage )
Mais je garde le conseil en mémoire pour le jour où je plancherai sur un logiciel plus gros

Pour le diagramme de séquence ... C'est pas bête du tout, je vais en faire un, ça devrait effectivement m'aider

Enfin pour l'histoire du passage à niveaux ... J'y avais pas pensé, bonne idée
Par contre j'ai refait le diagramme, mais j'avoue que ça ne me plaît qu'à moitié... La classe "Autre" devient la classe "Rail" ; et la classe "Circuit" se compose des classes "Rail", "Aiguillage" et "PassageANiveaux" ... Ça le fait ?
=> http://www.noelshack.com/up/aac/trainsv2-b320033a29.png

[Geo2A]

Bonjour,

Quelques remarques.

Vous utilisez une agrégation au lieu d'une composition. (par exemple entre circuit et rails) une composition présente un couplage plus fort, et est représentée avec un losange rempli (en noir en général). Le circuit n'existe pas sans les rails, donc il est composé de rails.

Un circuit est composé d'un ou de n trains. Qui sont composés de une locomotive et composés de un à n voitures (pas de réflexivité).

J'aurais pour ma part introduit une classe "élément rails" avec passage à niveaux, aiguillage, rails qui hérite de cette classe. La première propriété (ou méthode) de cette classe étant de constater l'état de fermeture de l'ensemble des composants.

Un passage à niveaux est composé d'objets "feux", "sonneries", barrieres"
chacun ayant des états "clignotants", "active", "levée/baissée", ces différents états étant dépendant ils doivent être modélisés à travers un diagrammes d'états transition. (si le feux clignote et la barrière se baisse pas il va y avoir un soucis!).

Le seul fonctionnement du passage à niveau est un exercice de modélisation à lui tout seul amha.

"si je devais programmer le logiciel basé sur ce diagramme, de quelles méthodes aurais-je besoin pour le faire fonctionner ?"

Comme le soulignent certains auteurs célèbres, il ne faut pas s'occuper du comment faire mais du quoi faire. Vous devez vous posez des questions en terme de cas d'utilisation pour démarrer votre modèle. Mettez vous dans la peau d'un gamin qui va jouer au train, que veut-il faire ?

Il n'y a qu'un seul diagramme pusqu'au final, cela représente un logiciel, et toutes les fonctionnalités sont liées... Il faut faire un diagramme par fonctionnalité ??

L'intérêt majeur de la modélisation UML est, au travers des cinq diagrammes de base, de fournir une vue du modèle sous un angle différend. Il ne faut pas faire un diagramme par "fonctionnalité", mais utiliser différends types de diagrammes pour les différentes approches du problème.