Discussion :

[Pragmateek]

Bonjour

quel est la meilleure façon de modéliser les fonctionnalités d'un composant graphique comme un formulaire par exemple, ou même un composant plus bas-niveau comme une grille de données ?

Afin d'indiquer :
- les informations que doit présenter le formulaire :
-- "Show date",
-- "Show id"
- celles qu'il doit recueillir :
-- "Get name",
-- "Get product".

Ceci d'un point de vue purement fonctionnel, pas graphique, ce n'est pas une maquette.

Merci.

[Tommy31]

Ca peut se faire au travers d'une classe stéréotypée, dont les attributs déclarés représentent les champs du formulaire. Tu peux supplétivement ajouter des stéréotypes pour décrire la nature du contrôle de saisi associé à l'attribut (combo, radio, password).

[Pragmateek]

Merci de ta réponse, c'est parfait pour la traduction des informations à fournir.

Et pour bien différencier ce que le composant affiche de ce qu'il reçoit ?
Un stéréotype supplémentaire sur les attributs est-il envisageable ?
En particuliers est-ce que UML autorise la superposition des stéréotypes ?

[hegros]

Et pour bien différencier ce que le composant affiche de ce qu'il reçoit ?

Avec tout les diagrammes UML dans l'absolu avec un enchaînement logique si possible mais pourquoi ne pas commencer avec un diagramme de composant justement pour définir les interfaces requises (ce qu'il reçoit) et les interfaces fournies (ce qu'il affiche)

[Pragmateek]

Merci, en effet le diagramme de composant semble l'idéal pour traduire à la fois les données fournies et celles demandées.

[Vlade]

L'idée de Tommy31 est pas mal si nous sommes en phase de modélisation de l'architecture physique du logiciel. Je dirai qu'il vaudrait mieux juste mettre de keywords et non pas utilisé le stéreotype qui est un mécanisme lourd lié au profile.
Un stéréotype doit être crée dans un profile comme le demande l'OMG.
Le keywords s'est une information supplémentaire dans le model et grpahique qui semble mieux adapté à ce besoin.

Bien sûre que la modélisation du diagramme de composant est indispensable en phase de première modélisation avant de passer à la modélisation physique.
Un usecase diagramme en amont serait bien aussi afin de voir le scope du projet.
En Résume il fausrait commencer par:
-un usecase diagramme, suivi d'un diagramme de composant et enfin d'un diagramme de classe.
Il faudrait aussi lié la logique entre les diagrammes afin de réutiliser les même éléments dans plusieurs diagrammes. Là ca devient puissant comme approche
Je veux dire plusieurs vue mais un même élement au niveau de la strcuture UML.