hiérarchie de spécialisation dans un domaine modèle

Question

Je suis en train de faire le modèle de domaine d'un système de gestion. Je le genre de personnes suivantes dans ce système:

employee
manager
top mananger

J'ai décidé de définir un User, d'où se spécialiseront de Employee, Manager et Top Manager. Maintenant, je ne sais pas quel genre de hiérarchie de spécialisation je choisir. Je ne peux pas décider entre les façons suivantes:

ou

Ce qui pourrait être préférable et pourquoi?

En tant que codeur long temps, chaque fois que j'essaie de faire un domaine modèle, je dois lutter contre l'idée d'essayer de penser à la façon dont je vais au code cela. D'après ce que je comprends, je ne devrais pas penser à ces questions dans le domaine modèle, que dans les relations d'objet. Je ne dois pas penser à la duplication de code ou l'une de ce genre de détails ici, donc je ne peux pas vraiment choisir l'une des options sur l'autre.

Merci

EDIT:

Je vais être un peu plus explicite: Ceci est un programme pour gérer les plans de vacances des travailleurs. Avec ce programme, un employé peut choisir l'ensemble des jours de vacances pour l'année. Ensuite, le gestionnaire peut approuver ou non ces jours pour chacun des employés et à la fin de la journée, le gestionnaire supérieur doit approuver ou désapprouver les décisions du gestionnaire. Ceci est tous les utilisateurs de mon programme sont censés être en mesure de le faire. Il n'y a pas d'autres tâches.

Answer 1

est la plupart du temps à une question de la façon dont vous définissez vos conditions. La question fondamentale est de savoir si un gestionnaire peut être remplacé par un employé en aucun cas possible - et sans savoir précis règles du lieu de travail en cours de modélisation, il est impossible de dire d'une façon ou l'autre à ce sujet.

Une notion générale est que oui, au moins jusqu'à un certain point, dans un pincement un gestionnaire doit être en mesure de faire le travail de l'un de ses subordonnés (au moins un niveau ci-dessous, et peut-être deux ou trois).

Par contre, dans certains endroits avec beaucoup de règles conduit syndicales en place, qui ne peut être le cas du tout. Même si une personne est tout à fait capable de faire un travail, les règles peuvent l'empêcher de se substituer dans cette position du tout. Dans certains cas, cela découle des exigences de certification et tel (par exemple, le gestionnaire peut avoir un été qualifié pour faire le travail, mais la certification requise est écoulée) ou des choses telles que les règles syndicales (par exemple, un de mes amis qui a déjà été réprimandé parce que il portait une ampoule de lampe de poche et batterie à l'arrière du magasin de la compagnie à son laboratoire au lieu d'obtenir un matériel syndicat gestionnaire de le faire pour lui).

Answer 2

Dans la vraie vie, les gestionnaires sont employés aussi. Donc, c'est sûrement juste une chaîne de spécialisation croissante:

User -> Employee -> Manager -> Top Manager 

modifier

  

"Ceci est un programme pour gérer les   vacances plans de travailleurs ».

En vous compagnie Les gestionnaires prennent des vacances planifiées? Certes, ils le font. Et vous aussi sûrement pas allez construire une application distincte pour gérer cela. Donc ce que vous avez vraiment besoin est ceci:

User -> Requester
     -> Approver

Chaque utilisateur sera dans une chaîne Requester d'approbation. (Vous devrez peut-être des arrangements spéciaux pour le PDG). En outre, certains utilisateurs seront approbateurs dans une ou plusieurs chaînes. Le approbateur final sera probablement varier en fonction de la qualité du demandeur: le chef de la direction ne voudra pas se soucier d'approuver les arrangements de vacances du personnel d'entretien

.

Vous aurez besoin de règles pour faire respecter qui peut être un approbateur de toutes les vacances de Requester données. Sauf si vous avez une organisation très plate, vous trouverez vous avez une hiérarchie des travailleurs et des gestionnaires. Par exemple, un chef d'équipe ou chef d'équipe - les personnes qui sont à d'autres égards « travailleurs » plutôt que des « gestionnaires » - peut-être dans la chaîne. Aussi, vous devrez peut-être envisager d'autres aspects de l'organisation. par exemple le père, si l'employé souhaite porter congé à l'année prochaine qui peut nécessiter l'approbation du département des ressources humaines, quelqu'un qui a normalement aucune responsabilité de gestion pour l'employé que ce soit.

Edit 2

D'accord, nous modélisons un ensemble arbitraire de règles plutôt que d'un scénario réaliste.

voir le Let. Chaque utilisateur unique dans une seule catégorie, définie par ces tâches:

• un employé peut demander un congé
• une boîte Gestionnaire d'approbation ou de rejet d'une demande de congé
• Top Manager peut accepter ou d'annuler une approbation ou le rejet

Les gestionnaires et les Top Managers ont pas les comportements en commun. Par conséquent, le premier modèle est le bon.

Answer 3

Je modélise ces acteurs comme. Ils ne sont pas dans le domaine du système, mais les utilisateurs du système. Souhaitez-vous modéliser le système d'inventaire d'un magasin avec « l'école enfant qui veut des bonbons », « parent de l'école enfant qui veut le tabac », « commis », etc.? Bien que seulement un gestionnaire de magasin (acteur) peut donner des remboursements sans reçu, ce qui compte au niveau du système est que le système reconnaît la clé de directeur de magasin, et il est que l'autorisation jeton qui est dans le logiciel plutôt que le rôle de l'acteur prend.

Le domaine du système que vous décrivez est demandes de vacances et le compte utilisateur, et quelques-uns des cas d'utilisation signifie que certains des comptes ont l'autorisation d'effectuer certaines transformations de l'Etat à une demande de congé annuel.

La différence dans la modélisation de l'utilisateur / chef d'entreprise / employés comme des acteurs et des rôles est que vous pouvez vous concentrer sur la modélisation de ce que vous devez mettre dans le système, ne pas avoir des hiérarchies d'acteurs - commencer à utiliser l'abstraction à l'utilisation cas que des entités du système, plutôt que dans les acteurs. Il est une mauvaise idée de ne pas penser toujours « comment cela fonctionnerait dans le code », au moins aussi loin que de demander «pourquoi prendre la peine de coder cette distinction.