Discussion :

[sampaiX]

Bonjour
je suis débutant en UMl je ne sais que faire les diagramme de cas d'utilisation, de classe, etat ,activité et séquence

j'aimerai faire le diagramme de composant mais je ne sais pas par ou commencer, je me base sur le diagramme de cas d'utilisation ou j'associe chaque vu de mon systéme par rapport a un acteur et qui contiendra les cas d'utilisation approprié, c'est sa le but
?
merci de bien vouloir m'aider

[bruno_pages]

Bonjour,

Il n'y a pas de lien entre les UCs et les composants, en effet les composants montrent l'architecture de l'application en terme de groupes d'interfaces requises/offertes/implémentées, il s'agit donc d'implémentation.

[sampaiX]

et donc je me base sur quoi pour faire mon diagramme de composant? , je ne trouve pas par ou commencer

[bruno_pages]

la première chose à faire est surtout de ne pas se tromper de version d'uml

avant uml 2 les composants n'étaient pas normé, et ils étaient souvent utilisés pour représenter le déploiement, c'est à dire les fichiers générés, libs, executables.

depuis uml 2 le déploiement est assuré par les artéfacts qui eux peuvent entre autre être utilisés pour représenter les fichiers générés, libs, exécutables

donc si vous lisez de la doc sur les composants vérifiez bien pour qu'elle version d'uml car la majorité des articles ne sont pas uml 2

un composant est une entité réutilisable et remplaçable décrite par des interfaces. Au niveau boite noire (on ne voit pas l'intérieur) un composant est décrit par les interfaces qu'il offre et les interfaces qu'il requiert. Un composant offre donc des services (par exemple utilisables par d'autres composants) et peut aussi en nécessitez pour son propre fonctionnement. Tout composant peut être remplacé par un autre ayant les même interfaces.

on peut bien-sûr voir un lien avec une librairie qui offre aussi des services et en requiert, sauf qu'une librairie c'est au niveau du concret, du déploiement, ce sont des classes (et non des interfaces), des fichiers bien réels etc, alors qu'un composant est au niveau abstrait.

si on se met au niveau boite blanche on peut voir l'intérieur du composant et voir les interfaces réalisées par lui, ou les sous composants car ils peuvent être hiérarchiques

il vous faut donc choisir des composants représentant des groupes ayant un sens au sens services offerts/requis, et le diagramme de composant montre les liens entre eux. par exemple si le composant C1 offre l'interface I et que le composant C2 utilise l'interface I alors un diagramme montre la connexion C1----o)----C2

exemple :


les composants permettent donc de montrer le découpage / architecture de votre application, mais à un niveau encore abstrait, par au niveau fichier/libs même si rien n'empêche plus tard d'avoir un niveau concret (artéfact) proche de celui des composant.

il faut cependant bien avouer que les composants sont rarement utilisés, le plus souvent on découpe via des paquetages, mais c'est en fait non normé et moins précis que les composants. si vous avez déjà un découpage en entités reposant sur ldes paquetages vous pouvez par tir d'exu pour en faire des composants puis affiner

[sampaiX]

d'accord alors si je dis que j'ai un systéme de reservation et que le client peut reserver en ligne:

j'aurai un composant "systéme de gestion de reservation" qui offre une interface que le client utilise
et dans le shéma y'aura:

un composant "systéme de gestion de reservation" et un composant client qui est considéré comme un acteur externe dans le diagramme de cas d'utilisation

c'est sa normalment non ?

[bruno_pages]

un composant "systéme de gestion de reservation" et un composant client qui est considéré comme un acteur externe dans le diagramme de cas d'utilisation

non !

les acteurs ne font pas parti du système considéré, par définition ils dont externes, le système réalise/implémente les UCs

les composants décrivent l'architecture interne et font donc parti du système

là vous êtes en train de dire que votre application est un composant, cela ne sert à rien. Les composants permettent de décomposer/découper le système, avec un composant qui représente tout vous n'avez rien fait

[sampaiX]

ok donc le diagramme de composant n'a rien avoir avec le diagramme de cas d'utilisation et il n'a rien avoir avec le diagramme de classe
je ne voie pas d'ou je vais partir,
c'est une autre notion, et il n'est relié a aucun des autre diagramme, parceque mon exo est simple le diagramme de classe est composé de:

Client, Reservation, Salle,Date reservation et d'autre petite classe attaché a la reservation
j'aurai besoin d'un pointeur pour me guider sur mon travail si sa vous dérange pas
merci

[bruno_pages]

si la chose à faire est simple alors oubliez les composants car ils serviront à rien