Quelle devrait être la séquence de création des diagrammes en UML? [fermé]

Question

Comme nous le savons, UML contient 13 types de diagrammes (structurels et comportementaux)

Avant de commencer un développement logiciel, nous sommes en phase d’exigence et de conception. Quel diagramme doit être créé et quand? .. Quelle devrait être la séquence de création des diagrammes dans UML en phase de conception et d'exigence?

En fait, s’il n’ya pas de séquence rigide, nous devons d’abord créer un diagramme structurel de manière rigide, mais le comportement tel que le diagramme d’activité peut changer en fonction de l’expérience utilisateur.

Pouvons-nous créer un diagramme de déploiement et un diagramme de composants comme un seul?

Answer 1

Il n'y a absolument aucune règle concernant la séquence de tels diagrammes.

Parfois, lorsque la structure des données et le comportement de votre modèle de domaine sont faciles à définir ou à documenter, la création des diagrammes de classes permet tout d'abord de définir des abstractions plus claires qui permettent de créer un diagramme de séquence qui ait un sens.

Dans d'autres cas, lorsque la nature du modèle de domaine est inconnue ou peu claire, il sera plus logique de créer d'abord un diagramme de séquence, puis d'en tirer des classes.

Ce dont je suis sûr, c’est que les révisions de ces diagrammes deviendront concurrentes (par exemple, les diagrammes de séquence peuvent révéler quelque chose qui n’a pas été pris en compte dans les diagrammes de classe, et inversement).

De même, après le démarrage du développement logiciel, ces diagrammes peuvent encore changer, car des abstractions et des conceptions plus intuitives ou plus faciles à gérer se révèlent, que ce soit via des tests unitaires ou des tests de l'expérience de l'utilisateur, etc.>

Ne vous laissez jamais séduire par l’idée que ces diagrammes sont rigides de quelque manière que ce soit et nécessitent donc une séquence de création - croyez-moi, ils ne le seront pas. Si vous les traitez comme étant rigides et infaillibles, vous vous tirez une balle dans le pied ET vous attachez un bras derrière vous dans le cadre de votre effort de développement logiciel.

UPDATE Comme indiqué dans les commentaires, si vous ne savez vraiment pas quel diagramme utiliser en premier, le diagramme de cas d'utilisation sera très important dès la phase de collecte des exigences.

Au-delà, ce que j'ai écrit ci-dessus s'applique.

Answer 2

Je suis d'accord avec Jon et Pete, mais j'ajoute respectueusement que UML est le quoi et le comment varie. Il existe des processus tels que OOA et OOD (OOAD) qui décrivent le comment et ce qu'est UML. Les articles du wiki sont utiles, mais cela fonctionne plus comme cela. De nombreux processus RUP développés impliquent également le comment de UML.

Un ensemble standard de commandes pour un projet impliquant un utilisateur (utilisez à nouveau ce dont vous avez besoin): 1. Cas d’utilisation (axé sur les interactions utilisateur / système. 2. Activité / séquence qui explore les cas d'utilisation. 3. Diagramme composant / interface si vous connectez des systèmes. 4. Package / Class si vous faites une grosse construction OO. 5. Déploiement pour montrer ce qui se passe où dans l’infrastructure.

Rien de magique sur les éléments de modèle / diagramme que j'ai énumérés ci-dessus, mais cela semble être l'ensemble commun.

Answer 3

  

En fait, s’il n’ya pas de séquence rigide, nous devons d’abord créer un diagramme structurel de façon rigide, mais le comportement tel que le diagramme d’activité peut changer en fonction de l’expérience utilisateur?

La forme suit la fonction. Si vous devez changer le comportement, il y a de fortes chances que vous ayez besoin de changer la structure à partir de laquelle ce comportement émerge.

Answer 4

L'analyse de cas d'utilisation est un moyen efficace de capturer les objectifs des exigences. Utilisez les descriptions de cas d'utilisation pour identifier vos objets de domaine et produire un modèle de domaine. Je trouve que le CRC est utile à ce stade, même s’il n’est pas officiel UML. Une fois que j'ai produit mon modèle de domaine, je crée un diagramme de séquence pour chaque cas d'utilisation. Bien que les diagrammes d'activité soient aussi une alternative utile. J'ai résolu le modèle de domaine en un modèle de classe plus détaillé. À ce stade, il est simple de produire un modèle de déploiement.