Discussion :

[ze_corsaire]

Bonjour,

Soit l'interface (terminologie Java) InterA dans un composant logiciel CompA et un classe ClassB implémentant InterA dans un composant CompB. Quelle est alors la relation induite sur les composants CompA et CompB ?

Merci,

[ndp]

Salut,

la reponse n'est pas dans la question? je n'ai peut etre pas compris.

[alex00]

ClassB.java :

Code :

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

1
2
3
4
import InterA;
ClassB implements InterA {
}

et dans InterA.java, aucune reference a ClassB.

donc :
CompB dépend de CompA (des la compilation).

[ze_corsaire]

Une dépendance ça c'est sûr, mais j'ai vu qu'il existait (en tout cas sous RSD) une relation "Réalisation de composant". Aussi, dans quelles circonstances peut-on dire qu'un composant "réalise" un autre composant ?

[alex00]

Il me semble que cette relation soit plutôt entre CompB et ClassB (ClassB réalise l'implémentation de l'interface de CompB).
Le composant est du coté du triangle (c'est l'abstraction).
(apres lecture rapide de UML superstructure : ComponentRealization).

[ze_corsaire]

Ok, merci pour la référence. Je l'interprète de la même manière, c'est une classe qui peut "réaliser" un composant et non un composant.

[bruno_pages]

Bonjour,

Soit l'interface (terminologie Java) InterA dans un composant logiciel CompA

Vous vous creusez la cervelle pour rien car cette phrase n'a pas de sens

Pour un composant une interface est soit requise soit fournie, une interface n'est pas simplement dans un composant.

un classe ClassB implémentant InterA dans un composant CompB

De la même façon cette phrase manque de sémantique.

La seule chose qui compte est : est-ce que CompB fournie l'interface InterA via ClassB qui fait alors partie des classes internes réalisant le comportement de CompB.

On a donc ça :

ou ça

en tout cas aucune relation entre les deux composants

[ze_corsaire]

Merci Bruno pour ces indications (tjrs) avisées.
Cependant, je me pose encore des questions :

1) il n'existe donc pas de relations directes inter-composant ? Elles sont décrites implicitement par la concordance de leurs interfaces "fournies" et "requises" respectives.

2) je reviens encore sur mon exemple, j'ai CompA qui propose un hook par le biais de l'interface InterA à d'autres composants. L'interface est alors définie dans mon composant CompA et dans une classe ClassA de mon CompA je fais appel à InterA.maMethodeARedefinir(). Le composant CompA ne propose pas d'implémentation de cette interface. Cette interface, pour le composant CompA est-elle "fournie" ou "requise" ou rien de cela ?

Merci,

[bruno_pages]

1) il n'existe donc pas de relations directes inter-composant ? Elles sont décrites implicitement par la concordance de leurs interfaces "fournies" et "requises" respectives.

tu pourrais utiliser des dependencies, mais sauf erreur de ma part elles n'ont pas de signification normé entre les composants (il faudrait que tu vérifie dans la norme)

L'interface est alors définie dans mon composant CompA

Encore une fois cette phrase n'a pas de sens

Tu confonds composant et source (artifact)

dans une classe ClassA de mon CompA je fais appel à InterA.maMethodeARedefinir(). Le composant CompA ne propose pas d'implémentation de cette interface.

Requise

Le but des composants dans UML est le découplage.
Un composant est remplaçable par n'importe quel autre du moment que le 'contrat' défini par les interfaces acquise/requises est inchangé. C'est pourquoi un composant offre/requière des interfaces et non des classes.

[alex00]

bien que le post est resolu, comme le dit Bruno :

Tu confonds composant et source (artifact)

Plutôt que de raisonner "en Java", c'est en fait similaire "au C",
avec l'interface => un fichier .h
et le composant => un fichier .a, .dll, .so ...

interface requise (au link) : on connait les symboles, pas d'implémentation
interface fournie (au link) : on connait les symboles ET (au moins une) implémentation.

Par contre, la ComponentRealization (cf. superstructure), définit bien une relation de réalisation d'un composant par un classifier.
La norme dit que c'est une relation "de réalisation (ou d'implémentation)" (entre guillemets la traduction de la norme, j'attire l'attention sur le fait que implémentation est entre parenthèses).
Il semble donc qu'on puisse avoir aussi bien :
CompB - - - - -|> CompA (la réalisation, cf. norme),
ClassB - - - - -|> CompB (l'implémentation, cf. norme)

ceci étant dit, je ne l'ai jamais utilisé et je ne l'ai jamais vu (a la limite une vague ressemblance avec 'assign class to component' dans Rose, mais qui n'est pas graphique).
Donc autant oublier ce type de relation pour l'instant.

[ze_corsaire]

Parfait, merci Bruno et Alex.

La dernière question d'un Corsaire à la dérive pour détendre l'atmosphère :
est-ce que le nom Hook (typiquement décrit dans l'exemple précédent) dérive de sa représentation en forme de crochet pour les composants ou le contraire ?

[alex00]

et bien, pour continuer la torture, revenons au C (noter au passage la forme "en crochet" de cette lettre).

Je pense que la surcharge de la méthode maMethodeARedefinir() s'apparente plus a un méchanisme de callback que de hook (ou template methode).

Le mechanisme de hook est quant a lui plus proche du pattern décorateur, avec un méchanisme un peu different.

cf. wikipedia hook (avec callback en reference),
et man page malloc_hook (avec code, noter que dans l'appel de malloc, le hook remet en place l'ancien hook, rappelle malloc, puis se remet a la place de l'ancien hook en prevision du prochain appel).