Discussion :

[nicolas66]

Bonjour,

Je suis en train de réaliser un projet sur les matrices creuses en langage C. Dans ce projet, il m'est demandé de constuire un petit diagramme de classes en UML.

En fait je possède une structure 'SSparseMatrix' qui gère les matrices creuses et qui possède deux pointeurs de tête de liste simplement chaînée 'SSLinkedList' sur les colonnes et sur les lignes.

La structure 'SSLinkedList' représente une liste simplement chaînée composée de nodes qui sont décrits dans une structure 'SNode'.

Enfin, chaque node de la liste possède un champ qui est une cellule décrite dans une structure appelée SCell. Cette dernière représente toute cellule de la matrice avec sa valeur et ses indices de ligne et colonne. Elle possède aussi un pointeur sur la prochaine cellule colonne et ligne.

Pour ce qui est du diagramme, j'ai déjà construit les classes avec leurs attributs et leurs opérations mais je ne vois très bien pas quelles relations je peux établir entres elles. Merci d'avance à ceux qui pourront me filer un ptit coup de main pour m'indiquer quelles relations je pourrai mettre sur mon diagramme.

Voici le diagramme de classe que j'ai déjà réalisé :




Nico.

[Groove]

Je pense que ton probleme vient de l'approche que tu as prise. Une approche tres detaillé !

UML est un langage finalement bien proche d'un dialecte, mais pour programmeur. Si tu ne trouve pas comment mettre tes relations c'est a mon avis que tu as deja exprimer tes liens entre classe

Avec le diagramme de classes il y a deux principaux moyens d'exprimer un lien: au moyen d'une assotiation ou d'un attribute dans la classe.



Sur cette exemple, tu as exactement la meme information cependant elle est exprimer de maniere differente. Choisie la maniere que tu veux mais surtout ne duplique pas l'information ! Si tu fais une combinaisons des deux alors tu auras deux instances.

Un conseil cependant. Tu peux utilisé les deux approche dans deux diagrammes différents. L'une ou tu va insisté sur les relations entre les classes (que des associations, aucun attribut) et l'autre ou tu vas insisté sur les attributes (Que des classes pas d'assotiation)

Tu n'es pas obligé de tout detaillé sur tout les diagrammes et c'est meme plutot peu recommandé si tu veux que tes diagrammes soient facilemet lisible.

Voila tout

[nicolas66]

Ah d'accord je ne voyais pas du tout ca de cette manière-là . J'ai refait le diagramme et j'ai essayé de respecter ce que tu m'as dit précédemment. Voici le résultat :



Peux-tu me dire ce qui pourrait clocher dans cette nouvelle mouture ? Merci d'avance

Nico.

[Groove]

UMLement parlant il y a la possition des mots sur les associations. Au milieu c'est le nom de l'assotiation alors que ce qui t'interesse c'est plutot le nom du role de l'assotiation.
Comme ca, ca parait rien mais bon ca change car si tu mets sur l'extrémité la sementique devient pour communique d'un classe a l'autre j'utilise ce nom.

Au milieu, ca correspond a rien au niveau de l'inplementation, c'est utilite dans des cas abstrait, au niveau analyse (et non specification comme ici). Par exemple je pense que tu pourrais faire une classe Employeur et une Employé et les liens avec l'association contrat. (Cette exemple me convient pas parfaitement mais sur le coup je ne trouve rien d'autres.)

Sinon les navigabilités (les fleches quoi) c'est simpa, ca dit qui peut communique avec qui. Bon en C tout est globale alors finalement tout peut relativement communiquer avec tout mais bon.

Sinon ca me parait difficile de faire mieux, c'est pas tres touffu comme projet.

Voila ++

[nicolas66]

Concernant les flèches, je ne les ai pas mises sur mon diagramme précédent car Umbrello ne me permettait pas de le faire. C'est pour cette raison que je suis passé à Poseidon CE.

En ce qui concerne les relations entre les classes, je me pose la question de savoir s'il ne serait pas préférable de mettre des compositions au lieu d'agrégations. En effet, lorsque j'appelle la fonction de destruction de la matrice, je détruit ses cellules ainsi que les deux listes chaînées avec leurs nodes. Je pense que la question fondamentale est de savoir si l'on considère qu'une liste peut par exemple appartenir à plusieurs matrice OU non.

Dernière question : pour le diagramme de cas d'utilisations, j'ai eu l'idée de lister l'ensemble des cas d'utilisations comme étant les différentes méthodes de ma classe SSparseMatrix. Théoriquement l'utilisateur possède le droit d'utiliser les autres classes, mais ce n'est pas le but. Il ne doit passer uniquement que par la classe SSparseMatrix.

Selon moi, on aurait donc les cas :

- Créer matrice
- Détruire matrice
- Opération sur matrice (cas qui englobe l'addition, la multiplication et la soustration)
- Afficher matrice
- etc ...

Est-ce que cette démarche est la bonne ? Merci de ton aide


Nico.