MODULE No 9

Titre : Qualification

But : expliquer les qualificateurs en UML

Antécédents : Module 4 et étude SEL du TP

Corps :

Le digramme de classe (ou conceptuel) UML suivant est censé représenter l’association entre Répertoire et Fichier dans un ordinateur :

Ce diagramme est équivalent à (a la même signification de) la phrase suivante : Un Répertoire contient 0 ou plusieurs Fichiers et un Fichier réside dans 1 ou plusieurs Répertoires.

Est-ce que le diagramme est correct ?

Aucun doute qu’un Répertoire donné (c’est-à-dire une instance de la classe Répertoire ou, en d’autres termes, un objet appartenant à l’ensemble des objets que l’on a décidé d’appeler Répertoire) peut être vide ou peut contenir 1 ou plusieurs objets que l’on subsume sous le mot de « Fichier » (la classe Fichier).

Mais, la multiplicité côté Répertoire est-elle correcte ? C’est-à-dire : un objet de type Fichier peut-il être dans plusieurs objets de type Répertoire ? De prime abord, oui. Le fichier « PhotoJulien.jpg » peut être en même temps dans le Répertoire « PhotoAmis » et dans le répertoire « PhotoPoursAmies ».

Mais, est-ce qu’il s’agit du même objet ? Oui, du point de vue de l’utilisatrice « naïve » Aïda qui a fait une copie dans le répertoire PhotoPoursAmies pour la montrer Geneviève. Pour elle, il s’agit exactement du même objet (on suppose, bien sûr, qu’elle a fait une copie et qu’après elle ne l’a pas modifiée).

Mais si, en parlant avec une autre amie, Aïda s’aperçoit que Julien est moins fidèle qu’elle ne le pensait et, avec Photoshop, elle barbouille le visage de Julien, que se passe-t-il dans sa tête (seulement du point de vue de notre problème d’association entre fichiers et répertoires, bien sûr) ? Aïda pourrait penser qu’en barbouillant la photo dans le répertoire PhotoAmis elle a barbouillé, en même temps, la photo dans le répertoire PhotoPourAmies qu’elle va transférer sur la clef USB. Cette pensée n’est pas plus bête que celle plus correcte que, vous et moi, nous avons : c’est-à-dire que la photo sur la clef ne sera pas barbouillée. Mais pourquoi nôtre idée est-elle plus correcte ? Parce que nous connaissons le domaine mieux qu’Aïda. Nous savons qu’il y a deux objets appartenant à la classe Fichier qui sont complètement indépendants et dont le seul lien est le nom — le contenu ne les relie pas, car Aïda pourrait très mettre la photo de Anniss dans le même objet fichier sans changer de nom au fichier.

Nous connaissons mieux le domaine, il est vrai. Mais faisons un effort et imaginons que nous sommes au début de l’informatique, dans les années 1950 (l’époque où ingénieurs et mathématiciens jetaient les bases le deux approches fort différentes de l’informatique que nous avons vu dans un autre cours) et imaginons que nous sommes responsables de concevoir un système de gestion de fichiers. Qui nous empêcherait de garder un seul fichier physique avec des « pointeurs » dans les répertoires qui ont besoin du fichier. Dans ce cas le Julien barbouillé dans PhotoAmis serait barbouillé partout comme le pense Aïda.

Donc d’un point de vue « naïf » (naïf par rapport aux mises en œuvre actuelles des systèmes de gestion des fichiers) la représentation UML que nous avons donnée au début est correcte mais d’un autre point de vue elle ne l’est pas.

Note Cet exemple met en évidence comment une association si simple entre deux classes si connues (par nous) peut être complexe à analyser dès que l’on approfondit le domaine en considérant les points de vues des différentes parties prenantes. Fin de la note.

Oublions cette complexité et ne considérons que la multiplicité côté Fichier et imaginons que l’on veille trouver un certain fichier (un objet) dans un répertoire. Notre modèle ne nous permet pas de savoir comment le trouver. Pourquoi? Parce qu’un Répertoire peut contenir plusieurs Fichiers : s’il n’en contenait qu’un (1) on n’aurait pas de problèmes. La difficulté de trouver le fichier dans le monde réel est rendue dans notre modèle par l’« * » côté Fichier qui indique qu’il n’y a pas qu’un fichier dans un répertoire et que si on veut trouver un fichier déterminé (un fichier qui est un objet et qui donc a un « nom propre ») il faut faire un choix.

Nous savons que, dans le « monde réel des ordinateurs », peut « trouver » le fichier, il suffit de connaître son nom. D’un point de vu conceptuel le nom du fichier réduit l’association de plusieurs (*) à un (1). Est-ce que le fait de dire lors d’une analyse que le nom du fichier permet de l’identifier univoquement dans un répertoire est important ? Ça dépend. Ça dépend du moment où vous introduisez cette information. Ce qui est certain, c’est qu’à un certain moment vous devez le faire.

Note Le moment dépend de beaucoup d’éléments : du type de projet, des caractéristiques des individus, des connaissances des individus, des méthodes de l’entreprise, etc. Ce qui est certain, c’est que cette « réduction de la multiplicité » est rarement introduite dès le début. Même la multiplicité souvent n’est pas introduite dès le début. Elle est introduite dès le début quand la partie du domaine concernée est tellement connue qu’il n’y a pas de « vrai » problème ! Vous devez certainement le faire quand vous concevez votre base de données, car elle dépend, surtout, de votre description (modèle) du domaine. Fin de la note

Le qualificateur (un rectangle accroché à la classe) est la façon de représenter cette réduction en UML. Voilà comment on peut représenter ce « plus d’information » sur le monde réel des fichiers en UML.

« NomCompletFichier » est donc le qualificateur qui permet de lier sans ambiguïté un objet de type Répertoire à un objet de type Fichier. Plus précisément : en UML un qualificateur permet de choisir un objet ou un sous-ensemble d’objets de l’ensemble d’objets à l’autre extrémité de l’association. Il permet donc de diminuer la multiplicité sans nécessairement la réduire à 1.

La réduction à 1 est l’idéal du point de vue de la lisibilité et de la facilité de compréhension.

Un qualificateur est donc employé pour choisir un sous-ensemble d’objets de l’ensemble du côté plusieurs (*) de l’association.

Un exercice facile pour voir si la fonction d’un qualificateur est claire :

Est-ce que le diagramme ci-dessus est correct ?

Nonm car il peut y avoir plusieurs Fichiers ayant la même extension.

Note Comme vous pouvez le constater, en présentant cet exemple, j’ai fait des hypothèses que je n’ai pas explicitées : comme par exemple que NomCompletFichier = NomFichier+Extension.

— Pourquoi j’ai fait cela ?

— Parce que c’est tellement connu !

Voilà une très mauvaise réponse. C’est très connu par les informaticiens et par ceux qui « fréquentent » avec une certaine assiduité les ordinateurs. Pas par tous. Cette note pour souligner que l’une des choses les plus difficiles d’une analyse, c’est de savoir quels sont les besoins et les connaissances implicites qu’il faut expliciter Fin de la note

Le diagramme correct est donc le suivant :

C'est-à-dire que dans un répertoire donné il peut y avoir plusieurs fichiers avec une extension donnée.

Conséquents :

· Être à l’aise avec la qualification et ne pas penser que l’on réduit toujours la multiplicité à 1.

· Avoir augmenté la conscience que lors d’une vraie analyse il faut réfléchir même sur les choses qui semblent les plus évidentes.

Note 01 :