Dois-je mettre les acteurs du domaine Modèle / classe Diagramme?

Question

Lors de la conception à la fois le domaine de modèle et des diagrammes de classes, je suis la difficulté à comprendre ce qu'il faut mettre en eux.

Je vais vous donner un exemple de ce que je veux dire:

Je fais un programme vacances planificateur, qui a un Administrator et End-Users. Le Administrator fait quelques choses comme l'enregistrement End-Users dans le programme, en changeant leurs previleges, etc. Le End-User peut choisir ses vacances jours, etc.

J'ai d'abord défini un Administrator et End-User comme des concepts dans le domaine modèle, et plus tard comme classes dans le diagramme de classes. Dans le diagramme de classes, les deux classes ont fini par avoir deux méthodes comme

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

etc.

seulement après un certain temps, je compris que les acteurs sont en fait les deux Administrator et End-User, et peut-être je me suis cette conception tout à fait tort. Au lieu de remplir les classes d'administrateur et l'utilisateur final avec des méthodes pour faire ce que mon cas d'utilisation demande, je pourrais définir d'autres classes du domaine pour les faire, et ont des contrôleurs gèrent les cas d'utilisation (en fait, je décide de faire un pour chaque Cas d'utilisation). Je pourrais avoir un UserDatabase.RegisterNewUser() et UserDatabase.UnregisterUser(int id);, par exemple, au lieu d'avoir ces méthodes sur la classe Administrator.

L'idée serait d'essayer de penser à l'ensemble des vacances-planificateur comme un « programme fermé » qui a un ensemble de fonctionnalités et ne dérange pas avec des choses telles que l'authentification, qui devrait être interne / protégé, étant que les seules choses publiques je laisse le voir du monde extérieur serait ses contrôleurs.

Est-ce l'approche de droit? Ou suis-je recevoir ce tout à fait tort? Est-il généralement mauvaise idée aux acteurs mis dans le domaine modèle / classe-diagrammes? Quelles sont les bonnes règles de base pour cela?

Mon professeur est application UML et modèles , que je trouve terrible , donc je voudrais savoir où je pourrais regarder plus d'informations sur cette situation modèles d'acteur décrit.

Je suis encore un peu confus au sujet de tout cela, que cette nouvelle approche est radicalement différente de tout ce que je l'ai fait avant.

Answer 1

Je ne dirais pas que votre conception, comme vous spéculez, est tout à fait tort, en fait l'administrateur et l'utilisateur final sont des objets de domaine valides qui devraient être représentés en quelque sorte dans les diagrammes de classes. Tout simplement parce que vous identifiez ces deux entités comme des acteurs ne signifie pas qu'ils devraient être exclus du domaine, rappelez-vous, votre domaine est votre portée, ou « contexte pertinent », qui est, l'ensemble des objets utiles qui jouent un rôle important dans votre Solution.

Vous pouvez commencer avec des objets de base qui composent votre modèle, il suffit de les écrire, sans autre analyse, comme brainstorming ...

• vacances
• Emplacement
• Agent de Voyage
• Calendrier
• Utilisateur
• Réservation
• Service de réservation (Cela peut être une interface pour accéder à la substance de réservation de vacances)

Ensuite, essayez d'établir les relations entre ces objets, si vous ne trouvez pas une relation qui signifie que vous ne choisissez pas les bons objets, si elles font partie du même domaine de problème, ils doivent être liés en quelque sorte.

Après un certain temps, vous découvrirez qu'il ya des objets manquants, essayez de résumer autant que possible, et représentent les abstractions correctes, design patterns peuvent vous aider avec ça.

Lorsque tous les objets possibles est représenté avec toutes ses propriétés et méthodes, alors vous devriez avoir un bien, mais pas encore terminé, la conception fonctionnelle.

Je sais que vous devriez avoir beaucoup de théorie dans votre esprit, alors allez-y, sans crainte, je me suis utilisé cette approche à plusieurs reprises avec succès au travail.

Enfin obtenir une copie de UML Distilled

Cordialement,

Answer 2

Je pense que vous devriez en apprendre davantage sur la modélisation de domaine et processus d'obtention de cas d'utilisation à des diagrammes de classes. Les acteurs comme classificateurs peuvent faire partie des diagrammes de classes, mais pour les diagrammes de classes utilisés pour l'analyse et la conception sont la modélisation du système que vous développez et un acteur est une entité externe. Lorsque vous utilisez des cas d'utilisation et l'utilisation des diagrammes de cas, l'objectif est d'identifier requrements fonctionnels et non-fonctionnels, donc définir la portée du système à développer et à des entités externes - rôles ou systèmes - en interaction avec le système que vous développez. Dans les diagrammes de cas d'utilisation, vous pouvez parfois trouver une boîte représentant les limites du système, qui englobe tous les cas d'utilisation, qui seront réalisés dans votre système, mais les acteurs sont hors de la boîte. Lors de la modélisation de domaine, vous oubliez généralement sur le système tout à fait, parce que vous voulez capturer la façon dont les travaux de domaine. Souvent, des diagrammes spéciaux et des éléments de modélisation sont utilisés pour la modélisation de domaine. Comme je l'ai dit, le point est de comprendre le domaine dans lequel sera utilisé le système. Les diagrammes de classes dans la phase d'analyse et de conception décrivent le système que vous développez, donc pas d'acteurs peuvent être à l'intérieur.