Rubrique « Info »

C'est quoi, une "collaboration d'un ensemble d'instances" ?

C'est tout simplement absent de tous vos AGL (début 2002). Mais c'est bien présent dans le méta-modèle d'UML 1.4 :

figure 1 Instances des éléments de comportement du méta-modèle UML1.4

    Ce diagramme ne montre qu'une partie des instances des éléments de comportement : il manque les interactions (ce qui vous permet de visualiser les messages entre instances, dans un diagramme de collaboration classique).
    Reste la question : comment cela se représente-t-il, et à quoi cela sert.
    Cela se représente par une ellipse en pointillé. Or, en UML, le seul autre symbole pointillé se retrouve avec les dépendances.
    Cette ellipse permet de représenter des éléments qui collaborent entre entre eux :
- soit pour réaliser une collaboration bien précise, et [OMG], dans son draft UML1.4 prend l'exemple des pattern ;
- soit pour réaliser une interface ou des use-case, ce qui semble être le lien idéal entre les cas d'utilisation (point de vue fonctionnel d'UML, où l'objet n'intervient pas) et les interfaces (point de vue objet, voir même "composant" d'UML, où l'interface du système est clairement identifié, que ce soit au niveau de l'Analyse ou de la Conception préliminaire ou détaillée).

Nous allons examiner le premier cas (réalisation de collaboration), pour mieux illustrer la nature de ce symbole ("collaboration d'ensemble d'instance"), avant d'aborder le second cas, qui répond à la question de départ : comment, en UML, établir le lien entre le paradigme fonctionnel et l'objet ?

Réalisation de collaboration :

    Le draft UML1.4 d'[OMG] prend essentiellement l'exemple du design pattern : on se trouve donc au niveau Conception. 

figure 2 Collaboration d'un ensemble d'instance dans le cadre d'un design pattern

    La figure 2 illustre le fait que 2 instances (une file d'appel et "barre graphique" qui représente la capacité de la file d'appel ainsi que le nombre d'appels dans la file) collaborent dans le cadre du design pattern "observeur - observé".
Remarque : l'exemple est issu du draft UML1.4, section 3.66.2, sans que le terme "SlidingBarIcon" ne soit jamais explicité... on doit en deviner le sens à partir des 3 diagrammes qui utilisent cette instance !
    Il faut bien réaliser qu'une "collaboration d'un ensemble d'instance" fonctionne comme un package et peut contenir des diagrammes de collaboration (qui à leur tour peuvent utiliser des "collaborations d'ensemble d'instances" qui ... etc). La figure suivante illustre ce fait.

figure 3 : une collaboration incluant un diagramme de collaboration

    La figure 3 illustre le fait que l'on peut représenter la structure interne d'un design pattern.

Réalisation de cas d'utilisation et d'opération 

    Le lien entre paradigme fonctionnel (exprimé au travers des cas d'utilisation, qui illustrent le fonctionnement externe attendu par les utilisateurs externes du système modélisé) et le paradigme objet (utilisé pour modélisé l'intérieur du système via des classes d'analyses ou de conception) tient presque en un seul diagramme tiré d'UML 1.4 : 

figure 4 : réalisation d'opérations et de cas d'utilisation

    En illustrant le concept de "sous-système",  le draft UML1.4 d'[OMG] insiste sur le fait que ce "sous-sytème" regroupe 2 parties :
- une partie dite de "spécification" incluant des opérations et des cas d'utilisations identifiées par les acteurs externes du système (paradigme fonctionnel)
- une partie dite de "réalisation", qui met en avant la fameuse "collaboration d'ensemble d'instance". Cette dernière peut, via une dépendance de type "abstraction", à savoir l'abstraction "realize", implémenter soit une opération, soit un cas d'utilisation.
    Rappelons que l'abstraction de type "realize" sert justement à relier 2 éléments qui représentent le même concept à différents niveaux d'abstraction.
    Or le niveau d'abstraction qui utilise un paradigme fonctionnel est typiquement celui d'une analyse de très haut niveau, à savoir la spécifications des besoins. C'est là qu'interviennent les opérations et cas d'utilisation qui figurent à gauche dans le sous-système de la figure 4.
    Le niveau d'abstraction qui utilise un paradigme objet est typiquement la Conception, au travers entre autres, de collaboration entre instances pour mieux visualiser les rôles des différents objets modéliser pour réaliser les spécifications évoquées ci-dessus.

Presque ? 
    Deux seuls regrets viennent ternir cette brillante perspective :

1/ Aucun outils AGL actuel (début 2002) ne permet dans un diagramme de collaboration de :
- visualiser une "collaboration d'ensemble d'instances" (l'ellipse pointillée) ;
- d'associer à cette ellipse une dépendance de type abstraction (le "realize") vers :
    * une instance (ce qui est dommage, vue que les instances existent naturellement dans tout diagramme de collaboration);
    * un cas d'utilisation (essayez d'introduire un cas d'utilisation dans un diagramme de collaboration ! Impossible... et l'ellipse pointillée n'est pas plus disponible dans les diagrammes de cas d'utilisation !)

2/ Cet élément (la "collaboration d'ensemble d'instances") n'étant reconnu par aucun AGL, il n'existe aujourd'hui (début 2002) aucun moyen standard reconnu pour lier une analyse de haut niveau (spécifications des besoins) basé sur le paradigme fonctionnel et une analyse structurante ou une conception. La dégradation d'un modèle d'analyse en modèle de conception reste inévitable, comme cela est dénoncé dans ce grand écart.