Discussion :

[dev_compil]

Bonjour,

Après avoir suivi plusieurs tutos sur l'UML aucun code présenté ne répond à ma question :

Soit le diagramme de classe suivant.


On pourrait implémenter ces classes et leurs associations suivant le code ci-dessous. La multiplicité * donne lieu à une collection (ici implémentée sous forme de tableau) en faisant abstraction du langage utilisé, seul le principe compte.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

Class Bibliothèque {

	private
		Livre mesLivres [];
		
}



Class Livre{

	private
		Auteur mesAuteurs[];
		Bibliothèque maBibliothèque;
		
}



Class Auteur {

	private
		Classe_L4 mesClassesL4[];
		Livre monLivre;

}



Class Classe_L4 {

	private
		Auteur monAuteur;
}

Quel est mon problème !
Si je suis l'implémentation par les classes proposées, la "simple" fenêtre donnant la liste des bibliothèque comportera bien des objets de la classe Bibliothèque. Or celle-ci contient une collection de Livre, eux-même une collection d'Auteurs et ainsi de suite pour les niveaux suivants.
Est-ce normal d'avoir autant de données pour une "simple liste" de bibliothèques ?
Le membres sous forme de collection des différentes classes, en suivant la navigation des associations, peut ainsi retourner une quantité impressionnante de données de la base.

Ai-je tout faux dans mon raisonnement ?


Merci pour vos réponses qui ne manqueront pas de m'éclairer.

Cordialement,

[bruno_pages]

Bonjour,

Je ne suis pas d'accord avec
- toutes les multiplicités, par exemple le fait qu'un auteur ne puisse écrire que 0 (pas sure qu'on soit auteur dans ce cas ) ou 1 livre,
- ni sur le fait que toutes les relations soient bidirectionnelles : est-il utile qu'un livre sache dans qu'elle bibliothèque il est ?
- sans compter que j'ai un problème avec votre classe Livre car on ne sait pas s'il elle représente un exemplaire d'un livre ou l'entité livre abstraite. Si c'est un exemplaire alors le pauvre auteur n'est pas prêt de vivre avec un tirage à 1 unique exemplaire dans le meilleur des cas Si c'est l'entité Livre alors le fait qu'elle ne puisse être que dans 1 bibliothèque ne va pas

Mais peu importe, je ne vois pas en quoi il y a un problème, vous auriez pu aussi compter les occurrences de mots dans les livre, voir les molécules les constituant, qu'auriez vous dit alors ?

Si votre modèle est correct et décrit ce que vous souhaitez sa complexité sera celle attendu

[dev_compil]

Bonjour,

Je débute depuis peu dans l'UML. Les livres traitant de l'UML sont trop théoriques. Le peu de code ne me donne pas toutes les clés de compréhension pour parvenir à la conception d'un produit final. L'analyse présentée était un support grossier pour marquer la multiplicité plusieurs (*). La multiplicité * donnerait lieu à une collection (sous forme de tableau, liste, ...) d'après la littérature.

j'ai tout de suite compris qu'en instanciant un objet de ladite classe cela impliquait (dès la construction) une recherche des données pour le remplir. Mais l'eau a coulé sous les ponts depuis mon post. J'ai pu lire des brides de code de quelques projets et pu, avec satisfaction, voir que le tableau de l'objet était chargé ultérieurement. . Cela correspond mieux à ma conception des choses. La majorité sont en JAVA. Avec un peu de confusion entre les langages lus, par moment je prenais les déclarations de membres comme des objets internes qui était instanciés à la création alors qu'avec JAVA il fait penser référence/"pointeur" et non instance. Shame on me.

Merci pour votre réponse et s'être penché sur mon post.

Cordialement,


Petite annonce : Le projets complets ne sont malheureusement pas légion. Si vous avez des liens vers des projets/tutos/... avec un code le plus complet possible, je suis très très demandeur.

Merci

[thierryc]

Quelques remarques:

- sur la multiplicité: cela dépend de vos besoins. Si vous n'avez à gérer qu'une seule bibliothèque, qu'un seul lieu, alors votre multiplicité à 1 entre livre et bibliothèque peut être OK. Sinon le lien est multiple. Si vous avez plusieurs exemplaires d'un même ouvrage, alors votre relation entre livre et auteur est trop simple là aussi. Tout dépend du problème auquel vous voulez répondre.

- sur l'implémentation des relations entre objets: en faisant l'hypothèse que votre modèle UML est un modèle de conception, une classe UML génère au moins 1 classe en source, en général plusieurs: une classe dans votre langage côté serveur, une autre côté client, une interface, une table dans la base de données, éventuellement un DTD dans XML, etc. Les relations se traduisent suivant les implémentations en pointeurs ou en références, en indexes de tables ou en identifiants uniques. Si vous voulez représenter un objet dans un autre, vous pouvez utiliser la relation d'aggrégation forte (losange noire). Si la multiplicité est simple, cela peut se traduire directement par un objet composant dans son composite. Si la multiplicité est multiple, cela peut éventuellement se traduire par un tableau d'objets. L'implémentation finale dépend des capacités et limitations de votre langage d'implémentation. Si la multiplicité est multiple des deux côtés, alors il est impossible d'avoir une relation de composition correcte.

- sur la modélisation: vous avez intérêt à lire Peter Coad, qui peut vous donner de bonnes indications sur les différents types d'objet dans une modélisation: UML en couleurs.

Cordialement,
Thierry