Version imprimable
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,
http://cedric.corsellis.free.fr/images/icon_pirat.png
Salut,
la reponse n'est pas dans la question? je n'ai peut etre pas compris.
ClassB.java :
et dans InterA.java, aucune reference a ClassB.Code:
2
3
4import InterA; ClassB implements InterA { }
donc :
CompB dépend de CompA (des la compilation).
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 ?
http://cedric.corsellis.free.fr/images/icon_pirat.png
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).
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.
http://cedric.corsellis.free.fr/images/icon_pirat.png
en fait, c'est un 'Classifier' qui peut realiser un composant, donc a peu pres n'importe quoi
voir aussi getRealizingClassifier()
Bonjour,
Vous vous creusez la cervelle pour rien car cette phrase n'a pas de sens :mouarf:Citation:
Envoyé par ze_corsaire
Pour un composant une interface est soit requise soit fournie, une interface n'est pas simplement dans un composant.
De la même façon cette phrase manque de sémantique.Citation:
Envoyé par ze_corsaire
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 :
http://bouml.fr/comp1.png
ou ça
http://bouml.fr/comp2.png
en tout cas aucune relation entre les deux composants ;)
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,
http://cedric.corsellis.free.fr/images/icon_pirat.png
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)Citation:
Envoyé par ze_corsaire
Encore une fois cette phrase n'a pas de sensCitation:
Envoyé par ze_corsaire
Tu confonds composant et source (artifact)
RequiseCitation:
Envoyé par ze_corsaire
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.
bien que le post est resolu, comme le dit Bruno :
Plutôt que de raisonner "en Java", c'est en fait similaire "au C",Citation:
Envoyé par bruno_pages
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.
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 ?
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).