Discussion :

[elghadi_mohamed]

bonjour

j'ai un projet à l'etude et je dois concevoir un modele à base d'UML mais je ne sais pas exactement la sequence de conception des diagrammes (je sais que use-case et en premier lieu) plus precisement : pour le diagramme d'etat-transition est ce que le diagramme use-case suffit pour sa conception ou non?

merci

[Hephaistos007]

pour le diagramme d'etat-transition est ce que le diagramme use-case suffit pour sa conception ou non?

Le diagramme d'etat-transition n'a strictement aucun lien avec le diagramme use-case, donc...

[bruno_pages]

au cas ou tu aurais un doute : les use cases parlent de besoin, pas de conception.

Comme il faut bien 'un jour' passer des besoins à la conception rien n'empèche à priori de passer des use cases a une machine a etat. De plus il est tout a fait possible d'utiliser une machine à etat pour une specification haut niveau (ie pas de la conception implémentatoire), ceci etant evidemment egalement le cas pour les classes et les activites.

Mais comme le soupsonne Hephaistos007, ton raccoursis est peu etre un peu rapide ? a toi de voir, il n'y a pas de regles absolues permettant de passer des besoin à une implé, sinon on pourrait faire la chose automatiquement ... et s'inscrire au chomage

[adilo]

les notions du diagramme d'etat-transition est à peu prêt les même que celles de cycle de vie d'un objet en Merise:
- tu reprèsente les états d'un objet dans l'enchainiament de ton traiteemnt et les événements qui permettent le changement de l'état ce ce objet.

[Joshua Beharia]

Hello,

pour ma part, voila en gros le truc:

UseCase Diagram --> Object Diagram --> Sequence Diagram --> StateMachine

Donc je dirais que tout est lié en fait...

Tcho

[Hephaistos007]

UseCase Diagram --> Object Diagram --> Sequence Diagram --> StateMachine

Ah bon ? Et quelle(s) référence(s) à un use-case trouves-tu dans un Object Diagram ?

[N_I_C_S]

Salut,

l'avantage (et la difficulté) d'UML est que l'on peut décrire tout avec tout (contrairement à Merise qui est une méthode séquentielle). Pour ma part, j'utilise surtout l'enchainement :

1- Use Case

Pour chaque Use Case :
2- Diagramme d'activité
3- Diagramme de Séquence
4- Diagramme de Collaboration
5- Diagramme de Classe

[Joshua Beharia]

Ah bon ? Et quelle(s) référence(s) à un use-case trouves-tu dans un Object Diagram ?

En fait, mon diagramme d'objets est fortement influencé par mes cas d'utilisations et la façon dont je les ai traité dans ma phase de recueil des besoins.
Mon découpage en objet me permet des faires des séquences qui vérifie le bon déroulement des mes UCs.
Pour moi, rien n'est décorélé, tout est centré sur les UC(usdp inside).

Voili.

[Joshua Beharia]

Salut,

l'avantage (et la difficulté) d'UML est que l'on peut décrire tout avec tout (contrairement à Merise qui est une méthode séquentielle). Pour ma part, j'utilise surtout l'enchainement :

1- Use Case

Pour chaque Use Case :
2- Diagramme d'activité
3- Diagramme de Séquence
4- Diagramme de Collaboration
5- Diagramme de Classe

Salut N_I_C_S,

une chose m'étonne dans ta description, tu dis que à chaque UC correspond un diagramme d'objet. Cela induit que ton system étudié aura donc plusieurs diagramme d'objet ? Du coup, un objet va être référencé dans pls diagram...
Cela me parait pour le moins bizarre. Pour moi, il y a 1 Object Diagram par system (en fait il y a en a plusieurs car il n'y a pas de solution ultime...).



@+

[Hephaistos007]

En fait, mon diagramme d'objets est fortement influencé par mes cas d'utilisations et la façon dont je les ai traité dans ma phase de recueil des besoins.

Oui d'accord, ca c'est normal. Mais cela n'est pas une référence stricto sensus. En revanche, dans un diagramme d'objets où de séquence, les objets font référence à leur classe respectives, définies au préalable dans le diagrammme de classe. Les bons outils CASE utilise ces références pour accélerer et guider ta conception (autocomplétion, liste de choix, ...).

[nletteron]

L'UML n'est pas de la "conception" c'est un langage de modélisation... Et dans l'écrasante majorité des cas la mise en place d'une application est faite de manière séquentielle rarement de façon transverse donc même pour les diagrammes on suit une certaine logique. Je réalise les vues statiques puis les vues dynamiques. Après l'ordre est peu important, sauf que la définition des besoins est toujours au début c'est tout.

[Hephaistos007]

L'UML n'est pas de la "conception" c'est un langage de modélisation...

Disons qu'UML recouvre plusieurs phases du cycle de développement du logiciel, dont la phase de conception, particulièrement mise en avant (il suffit de compter les diagrammes disponibles).

Et dans l'écrasante majorité des cas la mise en place d'une application est faite de manière séquentielle rarement de façon transverse donc même pour les diagrammes on suit une certaine logique. Je réalise les vues statiques puis les vues dynamiques. Après l'ordre est peu important, sauf que la définition des besoins est toujours au début c'est tout.

Je vois au moins 3 règles qui impose une relation d'ordre (partielle certes)

• Le respect du cycle de développement
• La relation d'instanciation : un modèle d'absraction de niveau n doit être définit avant celui de niveau n-1
• Le point de vue dynamique d'un système ne peut être étudier qu'après la définition du point de vue statique de ce dernier.

[Joshua Beharia]

Oui d'accord, ca c'est normal. Mais cela n'est pas une référence stricto sensus. En revanche, dans un diagramme d'objets où de séquence, les objets font référence à leur classe respectives, définies au préalable dans le diagrammme de classe. Les bons outils CASE utilise ces références pour accélerer et guider ta conception (autocomplétion, liste de choix, ...).

Je n'ai jamais dis que c'était stricto sensus, chacun son sens du développement.
Par contre, un truc me gène: "Les objets font référence à leur classe respective". Qu'elle définiton donnes-tu à une classe une classe ? Et à un objet ?

Dansmon cas, mes objets font référence à eux même, c'est tout.

C'est quoi les outils CASE ?

[Joshua Beharia]

[*]Le respect du cycle de développement

-> Quel cycle de développement utilises-tu ?

[*]La relation d'instanciation : un modèle d'absraction de niveau n doit être définit avant celui de niveau n-1

-> je ne comprend pas la problématique de la relation d'instanciation ?

[*]Le point de vue dynamique d'un système ne peut être étudier qu'après la définition du point de vue statique de ce dernier.

-> ok, mais autorises-tu des retours en arrière ?
-> qd attaques-tu la dynamique ?

[Hephaistos007]

-> Quel cycle de développement utilises-tu ?

Les phases définies par le cycle en cascade me plaisent.

-> -> je ne comprend pas la problématique de la relation d'instanciation ?

"On doit construire le moule avant de construire la pièce". La relation qui lie un "moule" à une pièce est l'instanciation. Voilà pourquoi on construit un diagramme de classe avant un diagramme d'objets, où le méta-modèle d'UML avant le diagramme de classe, etc...

-> -> ok, mais autorises-tu des retours en arrière ?
-> qd attaques-tu la dynamique ?

-> Bien sur, mais les itérations ne change rien au étapes de developpement dans l'absolu (l'analyse des besoins sera toujours avant le codage même si tu reviens en arrière des milliers de fois)
-> Quand tu n'a plus rien à dire avec les diagrammes statiques

[bruno_pages]

... Voilà pourquoi on construit un diagramme de classe avant un diagramme d'objets, où le méta-modèle d'UML avant le diagramme de classe

D'ailleurs dans la pratique tu risque d'avoir du mal à faire le diagramme d'objets avant un minimum au niveau de la définition des classes. Ainsi avec Bouml tu ne pourras pas visualiser des relations entre instances tant qu'elles ne sont pas définie au niveau de leurs classes.

Sinon le diagramme d'objet est très peu utilisé, c'est pour cela que je ne l'ai introduits que tardivement dans Bouml

[Hephaistos007]

D'ailleurs dans la pratique tu risque d'avoir du mal à faire le diagramme d'objets avant un minimum au niveau de la définition des classes. Ainsi avec Bouml tu ne pourras pas visualiser des relations entre instances tant qu'elles ne sont pas définie au niveau de leurs classes.

C'est la référence dont je parlais précédemment, gérée par tout les bons outils CASE

[nletteron]

Je vois au moins 3 règles qui impose une relation d'ordre (partielle certes)
Le respect du cycle de développement
La relation d'instanciation : un modèle d'absraction de niveau n doit être définit avant celui de niveau n-1
Le point de vue dynamique d'un système ne peut être étudier qu'après la définition du point de vue statique de ce dernier

Pour la relation d'instanciation, tout dépend de ton cycle de développement et de la problématique à laquelle tu dois faire face, j'ai déjà vu des modèles d'abstraction n-1 qui permettait dans leur solution de trouver des modèles de niveau n. Il n'est pas à prendre en compte que la conception mais aussi les problématiques indues par l'agencement des différentes abstractions.

Le respect du cycle de développement choisi oui en effet et il est purement séquentiel respectant dans tous les cas le schéma statique => dynamique, quel qu'il soit.

Globalement je suis d'accord avec ces 3 règles de base.

Donc pour répondre à la question, si c'est un projet simple, suis un cycle de développement en bateau