Par où commencer lorsque vous faites un modèle de domaine?

Question

Disons que je l'ai fait une liste de concepts que je vais utiliser pour dessiner mon modèle de domaine. De plus, j'ai deux ou trois cas d'utilisation dont j'ai fait quelques diagrammes de séquence du système.

Lors de l'élaboration du modèle de domaine, je ne sais jamais où commencer:

1. La conception du modèle que je crois que le système soit. Ceci est, si je suis la modélisation d'un corps humain, je commence en ajoutant les concepts de classe de coeur, le cerveau, intestins, estomac, yeux, tête, etc.
2. Commencez par la conception de ce que les cas d'utilisation doivent se faire. Ceci est, si j'ai un cas d'utilisation qui est de faire de quelque chose du corps humain, je voudrais tout d'abord tirer les concepts de classe pour la bouche, la gorge, Stomatch, Bowels, etc.

L'ordre dans lequel je fais des choses est hors de propos? Je dirais probablement qu'il serait préférable d'essayer de concevoir des recours à des concepts de cas, car ils sont généralement ce que vous voulez travailler avec, et non pas d'autres types de concepts qui, bien que l'aide bien décrire l'ensemble du système, une grande partie de la puissance du temps pas même nécessaire pour le projet en cours. Y at-il autre approche que je ne prends pas en considération ici? Comment abordez-vous habituellement cela?

Merci

Answer 1

Je commence par un dessin d'un diagramme de classes avec toutes les relations et mettre en œuvre que les classes qui sont nécessaires en fonction des besoins de votre application.

Vous pouvez utiliser une approche anémique (attributs, plus accesseurs) pour garder les choses simples et éviter l'étape d'écriture logique métier dans la même étape. Avec un modèle anémique, la logique irait dans une classe de service correspondant. De cette façon, vous pouvez envisager des cas d'utilisation plus tard.

Je sais que certaines personnes ne sont pas conscients de cette façon de faire les choses, mais il ne l'aide à l'entretien et évite certains problèmes de dépendance.

Réponse à la question ci-dessous Elysium dévorés :

En termes d'analyse, en commençant par cas d'utilisation (Que) et procéder ensuite aux sons diagramme de classes (Comment) comme une bonne règle. Personnellement, je ferais le diagramme de séquence (quand et qui?) Après, comme vous auriez besoin de savoir entre quels processus / objets doivent être envoyés des messages.

Au-delà de mon point de vue sur les choses est que UML est tout simplement un moyen de modéliser un système / projet et non une méthodologie par lui-même (contrairement à Merise, RAD, RUP, Scrum, etc.). Il n'y a rien qui empêche quelqu'un de commencer avec un diagramme aussi longtemps qu'ils ont les informations suffisantes pour le compléter. En fait, ils devraient se faire en même temps puisque chacun des schémas est une perspective différente du même système / projet.

Donc, dans l'ensemble cela dépend de la façon dont vous allez sur l'analyse. Au cours de mes études, j'ai appris l'approche en cascade rigide, où vous faites une analyse complète du début à la fin avant de produire un code. Cependant, les choses peuvent être différentes dans la pratique, l'impératif pourrait être de produire une application de travail dans le moins de temps possible.

Par exemple, on m'a présenté à la méthodologie Scrum récemment pour un exercice impliquant la création d'un site Web où les gens peuvent poster leurs fictions. Comme il y avait une contrainte de temps et une vision claire de ce qui devrait être atteint, nous avons commencé tout de suite avec un diagramme à nu de classe os pour représenter le modèle de domaine . Les cas ont ensuite été déduites utilisation d'une série d'écrans maquettes que nous avions produits.

De mémoire, les classes étaient Story, Chapitre, utilisateur et catégorie. Cette dernière classe a été supprimée en faveur d'une plus souple classe Tag. Comme vous ne l'imaginez, le diagramme de classe complète du projet existant serait due à l'application beaucoup plus complexe Driven Design domaine et les spécificités du langage de programmation Java.

Cette approche pourrait être considérée comme bâclée. Cependant, un site Web comme celui-ci pourrait facilement être dans quelques semaines à l'aide d'un processus itératif et encore bien conçu. L'avantage d'un processus itératif a sur l'approche en cascade est que vous pouvez ajuster en permanence les exigences que vous allez. besoins fréquents changements est une réalité, car les gens vont souvent changer leur esprit et la possibilité de produire une application de travail après chaque itération permet un à maintenir le cap pour ainsi dire.

Bien sûr, quand vous présentez un projet à un client, une analyse complète des diagrammes UML et des écrans simulacres serait préférable afin qu'ils aient une idée de ce que vous offrez. C'est là que vient UML. Une fois que vous avez expliqué certaines des conventions visuelles, une personne doit être en mesure de comprendre les schémas.

Pour finir, si vous êtes dans la situation où vous essayez de déterminer ce que le client veut, il est probablement une bonne idée de construire progressivement un questionnaire que vous pouvez apporter avec vous. Interviewer une personne est la seule façon que vous pouvez déterminer quels concepts / caractéristiques sont vraiment nécessaires pour une application, et vous devriez vous attendre à revenir afin de clarifier certains aspects. Une autre astuce serait de faire une recherche rapide sur le web lorsque vous êtes confronté à un sujet que vous ne connaissez pas d'importance.

Dans votre example, ce serait de passer par les bases de l'anatomie. Entre autres choses, cela vous aidera à décider ce que le modèle doit contenir et quelle granularité il devrait avoir (quel groupe d'organes devrait être considéré? Quelle est la précision-t-il besoin d'être? Est-ce que seuls les organes doivent modelée ou devraient-ils être décomposé en leurs constituants tels que les tissus, les cellules, la composition chimique, etc.?).

Answer 2

Que DDD, ou non, je recommande de déterminer la langue omniprésente (UL) en interrogeant le propriétaire du produit (s). Etablir la communication d'une manière qui va vous et les propriétaires de produits parlant la même langue, non seulement des aides à la communication, mais être capable de discuter du projet en termes communs tend à aider le modèle de domaine lui-même définir.

Alors, ma réponse est essentiellement pour discuter, écouter et apprendre. Software répond à un besoin. Comprendre le modèle du point de vue des experts jeter les bases solides pour l'application.

Answer 3

Je pense que le point de départ serait logique et se sent tout à l'aise. Il est probablement préférable de commencer par les cas d'utilisation, car ils vous donnent une orientation claire et des objectifs, et vous aider à éviter des situations YAGNI. Étant donné que vous devriez essayer de développer un solide modèle de domaine, il ne devrait pas vraiment d'importance, comme le tableau d'ensemble du domaine est important.

Answer 4

Je voudrais partager mon expérience pour ce type de situations. Je commence habituellement avec des tests d'écriture et le code. Et essayer de couvrir une extrémité à l'autre cas d'utilisation. Cela me donne idée assez juste sur problème et à la fin, j'ai aussi quelque chose de travailler avec moi que je peux montrer le cas à mon client. La plupart des histoires suivantes de temps construire au-dessus d'un précédent, mais il me arrive aussi que les histoires suivantes nécessitent des changements dans le modèle précédent, je suis venu avec. Mais cela ne me affecte pas comme je l'ai déjà une bonne couverture de test. De cette façon, je suis venu avec le modèle qui correspond pour le problème actuel, pas le modèle qui associe le monde réel.

Answer 5

Vous commencez avec Business Requirements qui peut être formalisées ou non. Si officialisé vous utilisez les diagrammes de cas.

Par exemple ici sont des diagrammes de cas d'utilisation pour une application e-commerce: http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010 /07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/ e-commerce-use-case2b.jpg

A partir de ces cas d'utilisation, vous pouvez en déduire naturellement les entités commerciales:. Produits, la catégorie de produits, panier d'achat, ... qui commence à préparer des diagrammes de classes

Il est la meilleure pratique dans de nombreuses méthodes, mais cela est juste du bon sens et naturel.

Answer 6

Réponse courte

Choisissez un cas d'utilisation, tirer un certain diagramme de collaboration (et un diagramme de classes) pour réaliser le domaine des objets impliqués. Concentré uniquement sur les objets ont participé afin d'accomplir objectif de cas d'utilisation. Ecrire TDD cas de test pour définir l'attente et le modèle progressivement vos classes de domaine pour répondre aux attentes. TDD est très utile pour comprendre les comportements attendus et il aide à obtenir le modèle de domaine propre. Vous verrez l'évolution de votre domaine progressivement avec les attentes TDD.

Réponse longue

Mon expérience personnelle avec DDD n'a pas été facile. C'était parce que nous ne disposions pas des fondations nécessaires en premier lieu. Notre équipe a beaucoup de points faibles dans différents domaines; les exigences ne sont pas pris correctement et nous n'avions un représentant du client qui n'a pas été vraiment utile (pas impliqué). Nous ne sommes pas un plan de libération approprié et les développeurs ont un manque de concepts orientés objet, meilleurs principes et ainsi de suite. Le principal problème que nous avions était passé tant de temps à essayer de comprendre la logique de domaine. Nous avons dessiné de nombreux diagrammes de classes et nous ne avons jamais eu le droit de modèle de domaine, nous avons donc cessé de le faire et a découvert ce qui a mal tourné. Le problème était que nous avons essayé trop difficile de comprendre la logique de domaine et au lieu de communiquer, nous avons fait hypothèses sur les exigences. Nous avons décidé de changer notre approche, nous avons appliqué TDD, nous avons commencé à écrire le comportement attendu et code du modèle de domaine pour répondre aux attentes du TDD. Parfois, nous avons l'écriture coincé cas de test TDD parce que nous ne comprenons pas le domaine. Nous avons parlé tout de suite au représentant du client et nous avons essayé d'obtenir une plus grande participation. Nous avons changé notre stratégie de libération; souvent appliqué la méthodologie agile et la libération de sorte que nous avons réel, les commentaires de l'utilisateur final. Cependant, nécessaire pour assurer l'attente de l'utilisateur final a été fixé au bon niveau. Nous refactorisé en fonction des commentaires, et de cette façon le modèle de domaine a progressivement évolué. , Nous avons appliqué ensuite les modèles de conception pour améliorer la réutilisabilité et la maintenabilité. Mon point ici est que seul DDD ne peut pas survivre, nous devons construire l'écosystème qui englobe le domaine, les développeurs doivent avoir des concepts forts POO et nous devons apprécier TDD et test unitaire. Je dirais que DDD est assis au-dessus de toutes les techniques et pratiques POO.