Je lis actuellement l'UML de Martin Fowler. Je viens de couvrir la section sur les diagrammes de classe, où il met fortement l'accent sur la nécessité de régler la perspective avant la modélisation des diagrammes de classe. Cependant, je suis légèrement confus quant à la façon dont cela semble pratiquement lorsque cela attire réellement des diagrammes de classe. Je comprends que les implications théoriques changent la signification d'une association d'une perspective à la suivante, par exemple.
Je suppose que ma question principale serait que si, comme par exemple, je modélisais un système de commande simple comme dans le livre, les diagrammes de classe seraient-ils différents et contiennent différentes quantités de notation d'une perspective à une autre. Par exemple, à partir d'une perspective conceptuelle, je voudrais simplement montrer les classes et certaines associations vagues et leur multiplicité, puis lors de la modélisation au point de spécification, citons la navigabilité et les opérations de base et les champs.
J'apprécierais vraiment quelques conseils à ce sujet, car j'aimerais vraiment avoir une meilleure compréhension de ce sujet.
4 Réponses :
bonne question. Voici quelques pensées de ma propre expérience; Je ne peux pas dire si Martin serait d'accord (!) Mais, espérons-le, utile néanmoins.
En résumé: la principale différence provient de la formalité et des choix de conception pour les relations.
J'ai trouvé les suivants utiles:
Structure de base: Cartes approximativement à UML de Fowler comme croquis et fait sur le tableau blanc de manière interactive. L'objectif principal est de comprendre la structure globale. Très informel. En particulier, la mise au point sur les relations est simplement de les identifier, non de formaliser - donc pas de cardinalité, de suppression de comportement, de choix de classes de conteneurs, etc.
modèle de domaine. Un modèle précis, axé sur la formalisation des relations. Plus précisément, nommer l'association se termine, définissant la cardinalité et confirmant le comportement de suppression. Ne considère pas la navigabilité ou le choix des classes de conteneurs pour la cardinalité> 1. Une des meilleures techniques que je connais pour apprendre un domaine de problème.
J'utiliserai presque toujours les deux ci-dessus. La chose essentielle du modèle de domaine consiste à utiliser la dénomination basée sur le verbe plutôt que le rôle basée sur le rôle - car il décrit pourquoi la relation existe (surface effectivement les règles commerciales: par exemple, une commande doit être placée par exactement un client »). J'utilise le modèle de nommage décrit dans SIMSION & WITT Livre.
Il y a du travail à faire pour traduire le modèle de domaine au code de travail, spécifiquement dans les relations. Les langages de programmation ne favorisent pas très bien les relations. Les associations doivent donc être traduites en attributs des classes participantes. C'est à ce stade que la navigabilité entre en jeu, ainsi que le choix du type de collecte pour la multiplicité> 1. C'est également là que toutes les opérations doivent être spécifiées. Je ne trouve pas personnellement ce type de diagramme particulièrement utile. Un modèle de domaine plus le code me donne tout ce dont j'ai besoin.
Je n'utiliserai jamais "UML comme langage de programmation" si j'utilise un outil UML exécutable.
excuses si c'est un peu randonnée, espérons que cela vous aide ...
PS: Si vous voulez un meilleur exemple de nommage basé sur le verbe, j'ai un Poste sur mon blog . S'il vous plaît ne prenez pas cela comme auto-promotion, tout simplement pas à répéter ici.
Long time no see.Merci de vos efforts dans UML Tag Vous êtes vraiment incroyable, j'espère que vous continuerez à écrire dans votre blog sur UML et sur le sujet connexe. J'espère que je peux faire de même mais je suis toujours débutant
Les livres de Martin Fowler sont la merde pour moi (par exemple mon sentiment personnel) dès qu'il commence à parler du diagramme de classe !! Je suis d'accord pour les autres diagrammes, mais le diagramme de classe devrait être plus pragmatique et pas seulement des conceptions de haut niveau !!
C'est toujours la même théorie que vous devez modéliser à plus haut niveau d'abstraction, puis pour modéliser ce dont vous avez vraiment besoin. Je préfère fournir rapidement un code de course et le montrer au client. À partir de cette première étape, nous commençons à modéliser afin d'avoir des demandes fonctionnelles, mais également du code. Une fois que nous avons fini cette deuxième étape, nous le montrons à nouveau au client et fournit à nouveau des diagrammes de classe UML pour modifier ce qui doit être fait. Après 10 itérations, mon projet est généralement terminé. Par exemple, mon projet 3 à 6 mois de 3 à 6 mois. C'est un projet vraiment complexe et mes clients sont généralement satisfaits. Utilisation de la recommandation de Martin Fowler Mon projet n'aurait pas été achevé en 12-18 mois et le client serait certainement déçu.
Exactement, les diagrammes de classe UML ne sont qu'une notation que vous pourriez (et devrait) différemment en fonction de la phase de développement de logiciels que vous allez. Vous pouvez commencer uniquement avec des classes, des attributs et des associations, puis affinez le diagramme pour ajouter des informations sur les types pour Les attributs, puis la navigation, les méthodes de classe, les qualificatifs des associations ... jusqu'à ce que vous obteniez un diagramme de classe complète prêt pour la phase de mise en œuvre
Notez que vous pouvez même itérer au point dans lequel vous supprimez les associations et les remplacer par des attributs de types complexes pour avoir un diagramme de classe encore plus similaire à la mise en œuvre finale. C'est à vous de décider comment utiliser des diagrammes de classe dans chaque phase.
Voici comment j'explique les idées aux développeurs.
conceptuel est les relations. C'est le niveau où l'accouplement devrait se produire. Vous ne devriez pas voir coupler de conceptuel à la mise en œuvre - c'est un signal d'une conception médiocre.
Spécification définit l'algorithme sans définir la mise en œuvre. Dans un diagramme de classe, cela pourrait être représenté comme une classe abstraite. Alan Shalloway appelle des méthodes qui tombent dans ce royaume "Méthodes de sergent": ils aboient des commandes.
La mise en œuvre est l'endroit où le travail réel se produit. Cela pourrait être représenté par des classes concrètes qui mettent en œuvre vos spécifications abstraites.
NOREFERRER"> Modélisation avec un sens du but A 2002 IEEE Article de John Daniels Publié sur le site de Martin Fowler. L'article décrit une distinction utile entre les modèles conceptuels, spécifications et de mise en œuvre.