Dites que vous examinez les 6 types de base de diagramme UML (à partir de celui-ci les éléments de style UML 2.0)
Prétendre que vous êtes insensé et que vous avez envie d'élaborer tous les 6 diagrammes pour votre système.
Que commenceriez-vous? Ensuite, que iriez-vous? Quel est le meilleur ordre de visiter chaque diagramme si vous avez une idée Je pense que vous devriez commencer par le diagramme physique et travailler votre chemin au diagramme de classe. Top vers le bas, je dis toujours ..? Je me trompe?
4 Réponses :
Le diagramme physique est probablement aussi bon un endroit pour commencer comme n'importe où. Je trouve des diagrammes d'activité vraiment utiles pour élaborer les kinks dans une conception et les séquences sont bonnes pour beaucoup de même raison. J'ai rarement pris la peine de diagrammes de machine à états.
Je pense de manière réaliste que vous allez vouloir revenir à la conception que vous faites de toute façon de toute façon (conception itératée, woo!) Donc, il vaut probablement la peine de commencer avec tout ce qui va apporter le plus de clarté à votre projet.
Les diagrammes UML sont des représentations de divers modèles d'une conception. Je ne suis pas sûr qu'ils puissent être proprement sérialisés comme vous le décrivez. Fréquemment, un diagramme de classe est utilisé à la fois dans les phases d'analyse et de conception d'un processus. De même, d'autres diagrammes sont utilisés dans plusieurs phases.
Cela dépend de l'aspect d'une conception qui vous intéresse à tout moment dans le temps que vous utilisez le diagramme approprié pour "voir" un modèle de la conception.
J'ai vu les deux "Démarrer avec le diagramme de classe" et "Démarrer avec le modèle de cas d'utilisation" proposé. Je suis venu à comprendre que cela n'a pas vraiment d'importance.
Je pense que vous voulez commencer par le comportement de haut niveau du système à l'aide de plusieurs diagrammes, puis passe progressivement sur une conception plus détaillée à l'aide du même ensemble de diagrammes.
les cas d'utilisation sont les principaux qui définissent "quel" votre système Donc, résumant, à peu près: Utilisez des cas, une activité, une machine à états, une classe, une séquence, un composant, un déploiement. Cet ordre a du sens car il devient plus profond envers les aspects de la mise en œuvre et loin des aspects d'analyse, par exemple. Quelqu'un intéressé à comprendre exactement quels cas d'utilisation vous trouverez et quelles règles d'activité vous appliquerez (diagrammes d'activité) peuvent arrêter la "lecture" plus tôt que quelqu'un qui doit comprendre la logique détaillée complète de votre stratégie de déploiement.
Je dois dire que cette réponse était particulièrement utile. J'ai particulièrement apprécié l'activité avant la machine d'État et la classe avant la séquence et l'activité avant la classe.
@bobobobo, TX pour les félicitations - toujours heureux d'être utile!
Comme l'a mentionné @vincent Ramdhanie, vous ne vous lancerez probablement pas de conception en terminant un diagramme et en continuant avec d'autres. Quoi qu'il en soit, j'aime bien votre réponse car cela donne une façon raisonnable de commencer, du moins pour moi. Merci pour l'aide
La classe, la séquence et le diagramme d'usecase représentent plus de 90% du diagramme généralement créé à l'intérieur d'un projet. Le diagramme de classe elle-même représente parfois plus de diagramme que tous les autres diagrammes.
La meilleure solution consiste à le garder simple et à adapter la modélisation au niveau de l'équipe.
Si aucune expérience UML , créez simplement un diagramme de classe pour représenter le squelette de votre application.
Si le niveau débutant commence ensuite par un diagramme d'usecase, de séquence et de classe.
Si le niveau moyen utilise tous les diagrammes car chaque diagramme couvre une autre vue qui n'est pas toujours possible de coder avec Java. Je veux dire que Java n'est associé qu'au diagramme de classe et de séquence.