Discussion :

[gregb34]

Bonjour,

J'aurais aimé connaitre les liens entres les diagrammes suivant :

Cas d'utilisation
Sequence
Classe
Activités
Etat/Transitions

Par exemple, dans Cas d'utilisateur, les acteurs ont un type definis par une classe du diagramme des classes..

MErci à vous

[g0up1l]

Oula ! j'ai l'impression que tu mélange un peu tout !

Je ne vais pas faire un cours complet, ce ne sont pas les exemples qui manquent.
Néanmoins, sache qu'il ya deux familles de diagramme, les diagramme statiques et les diagrammes dynamiques. Les premiers modèlisent les composants de ton système d'information, les seconds modèlisent le comportement de ces composants.
Il n'y a pas de lien formel entre les différents diagrammes, tu dois les voir comme différents niveaux d'abstraction de ton SI. Tout au plus peut-on parler de cohérence entre les diagrammes quand, par exemple pour le diagramme d'objets, on retrouve des objets issus des classes du diagramme de classe.

Ton exemple des cas d'utilisations qui s'inspire du diagramme de classes est erroné. En effet, les uses-cases ne sont ni plus ni moins que les fonctionnalités attendus par les utilisateurs. Au moment où ils sont rédigés, on ne sait même pas qu'elles seront les classes du SI !

Por finir, n'oublie pas qu'UML est un langage et non une méthode, donc tu n'auras pas forcément de lien 'concret' dans la suite de rédaction de tes diagrammes.

[Nip]

Ton exemple des cas d'utilisations qui s'inspire du diagramme de classes est erroné. En effet, les uses-cases ne sont ni plus ni moins que les fonctionnalités attendus par les utilisateurs. Au moment où ils sont rédigés, on ne sait même pas qu'elles seront les classes du SI !.

Juste pour preciser tes propos; on commence le plus souvent par les UC avant d'attaquer le diagramme de classe, histoire d'identifier les classes plus facilement. En effet une fois que tu as identifie ce qui doit etre mis en jeu avec les UC, il est plus simple de correctement identifier ses classes.
Ensuite, la communication entre objet que presente un diagramme de sequence est base sur ton diagramme de classe.
Le diagramme d'etat/transition correspond au cycle de vie de la classe, que tu as initialement definie dans ton diagramme de classe.
Dans un diagramme d'activite, tu decris une ...activite, par exemple basee sur tes UCs.

Voila comment sont lies les diagrammes que tu as donne.

[g0up1l]

Ensuite, la communication entre objet que presente un diagramme de classe est base sur ton diagramme de classe.

?? Tu veux parler du diagramme d'objet ou de séquence, je suppose !

A ce propos, on peut très bien commencer par un diagramme d'objet, ou de séquence, avant le diagramme de classe. Ceci afin de se clarifier les idées sur la manière dont les objets du SI ( au sens large ) communiquent. En effet, c'est parfois au cours de ce diagramme que tu démontres que tel objet doit avoir telle responsabilité. Ce qui t'aide à définir ta classe.

Pour moi, il n'ya pas de séquencement à proprement parler des diagrammes.

[Nip]

?? Tu veux parler du diagramme d'objet ou de séquence, je suppose !

hehe vi bien sur

A ce propos, on peut très bien commencer par un diagramme d'objet, ou de séquence, avant le diagramme de classe. Ceci afin de se clarifier les idées sur la manière dont les objets du SI ( au sens large ) communiquent. En effet, c'est parfois au cours de ce diagramme que tu démontres que tel objet doit avoir telle responsabilité. Ce qui t'aide à définir ta classe.

Pour moi, il n'ya pas de séquencement à proprement parler des diagrammes.

Disons qu'il n'y a pas d'ordre a proprement defini et de toute maniere comme dans n'importe quel developpement, tes specs changent en cours de route et il est tout a fait possible de revenir sur des diagrammes etablis.
Concernant l'ordonnancement, il me parait quelque peu hasardeux d'attaquer un diagramme de sequence sans avoir au prealable defini tes classes. Ca t'aide sans aucun doute a mieux definir leur responsabilite, mais pour ca faut qu'elles soient ...definies.
Mais nous sommes d'accord il n'y a pas d'ordre impose, juste un ordre plus simple a suivre .

[Hephaistos007]

Si besoin, voici une discussion similaire : http://www.developpez.net/forums/sho...d.php?t=231813

[g0up1l]

hehe vi bien sur

Concernant l'ordonnancement, il me parait quelque peu hasardeux d'attaquer un diagramme de sequence sans avoir au prealable defini tes classes. Ca t'aide sans aucun doute a mieux definir leur responsabilite, mais pour ca faut qu'elles soient ...definies.

Parceque tu n'as peut-être pas été confronté au problème !

Il y a une chose simple archi-connue mais qu'il faut avoir à l'esprit quand on aborde un nouveau métier,
c'est qu'un objet est caractérisé par un état ( la valeur de ses attributs ) et un comportement, ce qui est aussi important.

La plupart des applications sont typée "Base de données", autrement dit :
on se trouve en présence d'objets plutôt statiques dont les attributs sont facilement identifiables et dont les comportements propres sont limités.
Par exemple : Article, Client, Facture, Commande...Dans ce cas, un diagramme statique sera le bienvenu pour modélider notre SI.

Par contre, il y a des applications où les comportements sont mis en valeurs plus nettement,
et dans ce cas, un diagramme dynamique est une façon d'organiser sa conception.

Par exemple : modélisation d'un auto-commutateur.
Tu n'as quasiment que des comportements. 'décrocher','tonalité','commuter','parler','occupé'...

Le premier diagramme que je fais comporte des instance d'objets dont j'ignore la classe mais à qui j'attribut un comportement.
Je vais donc poser mes objets comme ça sur le diagramme, les faire communiquer et, in fine, je concevrais un moule pour ces objets, c'est à dire...une classe !