Je ne comprend pas bien la notion de port dans UML 2. Je voudrais savoir comment cela se traduit dans le code.
Version imprimable
Je ne comprend pas bien la notion de port dans UML 2. Je voudrais savoir comment cela se traduit dans le code.
il n'y a pas de traduction fixe, un port étant à un trop haut niveau d'abstraction pour n'avoir qu'une représentation possible.
si le classifier est une classe et que le port est associé à un service supporté par une opération de cette classe, alors le code correspondant sera l'appel de cette opération
personnellement je n'aime pas les ports, la notion est trop floue, port pourrait se traduire par 'bidule' ...
J'ai déjà vu ce genre de notation :
Est-ce que ça à un rapport avec la notion de port ? Que signifie cette notation ?Code:
2
Cela sert à matérialiser la connexion/l'interface entre deux composants.Citation:
Envoyé par verbose
Les extrémités peuvent être des "ports" modulo qu'on précise ce que cela recouvre.
- W
Merci pour ta réponse wiztricks, est-ce que tu aurais un exemple concret ?
---O indique que le composant offre/implémente une interface
---( indique que le composant requière/utilise une interface
les composant sont définis à partir des interfaces qu'ils offrent et celles qu'il nécessitent
pour montrer la liaison entre deux composants à propos d'une interface on peut connecter les deux signes, exemple :
http://bouml.sourceforge.net/doc/fig...ramdrawing.png
En fait je ne maîtrise pas très bien les diagrammes de composants.
Si je comprends bien, le composent Store est constitué de trois classes Order, Product et Customer et de deux interfaces OrderableItem et Person, et utilise deux autres interfaces OrderEntry et Account.
Order et Customer utilisent Person. Order et Product utilisent OrderableItem.
Est-ce que c'est bien ça ?
nonCitation:
Est-ce que c'est bien ça ?
Order, Product et Customer sont des sous composants (pas des classes) de Store
Order requière l'interface Person, qui est offerte par Customer
Order requière l'interface OrderableItem, qui est offerte par Product
Order offre l'interface OrderEntry
Customer requière l'interface Account, qui n'est offerte par aucun sous composant de Store => Store requière l'interface Account
OrderEntry (offerte par le sous composant Order) est également offerte par Store, mais il y a ici rien d'obligatoire. Par contre les interfaces Person et OrderableItem offertes par des sous composants de Order restent 'cachées' et ne sont pas offertes par Store
Concrètement, c'est quoi un composant ? Comment ça se traduit dans le code source ?
Un composant est un truc défini par ses interfaces offertes et requises, un composant est remplaçable par un autre ayant les mêmes interfaces offertes et requises.Citation:
Concrètement, c'est quoi un composant ?
Un composant n'a donc rien de concret
Un composant n'a pas de traduction au niveau code.Citation:
Comment ça se traduit dans le code source ?
Le code c'est du déploiement, un composant n'est pas au niveau déploiement (contrairement aux artifacts).
Ma question est un peu terre à terre, mais quel est l'intérêt de modéliser quelque chose qui n'a pas de traduction dans le code source ?
En clair, qu'apporte le diagramme de composant à la compréhension du problème à résoudre ?
un diagramme de cas d'utilisations n'a pas non plus de traduction dans le code source, cela ne le rend pas inutile pour autant ;)
les composants permettent typiquement de montrer la décomposition en sous systèmes, et les interactions entre-eux (via les interfaces)
sinon je n'ai peut être pas été assez complet dans ma précédente réponse : un composant n'est pas au niveau du déploiement mais il est possible de dire quel sont les artifacts déployant un composant
Il y a nécessairement un (plusieurs) lien entre les use cases, les composants et la réalisation. Personnellement, j'utilise plutôt le stéréotype <<trace>>.
- W
Je crois que je commence à piger. Merci d'avoir répondu à mes questions :D