域模型中的专业化层次结构

时间:2010-05-31 03:36:20

标签: oop uml domain-model

我正在尝试制作管理系统的域模型。我在这个系统中有以下类型的人:

employee
manager
top mananger

我决定定义一个UserEmployeeManagerTop Manager将专门从中{{1}}。 现在,我不知道应该选择什么样的专业化层次结构。 我无法通过以下方式做出决定:

alt text

alt text

哪个可能更好?为什么?

作为一个很长一段时间的编码器,每次我尝试做一个域模型时,我都要反对试图思考我将如何编写代码的想法。根据我的理解,我不应该只考虑对象关系中的域模型中的那些问题。我不必在这里考虑代码重复或任何这类细节,所以我不能真正选择任何一个选项。

由于

修改

我会更明确一点:这是一个管理工人假期计划的程序。通过该计划,员工可以选择一年中的假期日。然后,经理可能会批准或不批准每个员工的那些日子,并且当天最高管理者应该批准或不批准经理的决定。这是我的程序的所有用户应该能够做到的。没有其他任务。

3 个答案:

答案 0 :(得分:2)

在现实生活中,经理也是员工。所以这肯定只是一个日益专业化的链条:

User -> Employee -> Manager -> Top Manager 

修改

  

“这是一个管理的程序   工人的假期计划。“

在你的公司里,经理们有计划的假期吗?他们当然可以。同样可靠的是,您不会构建单独的应用程序来管理它。所以你真正需要的是:

User -> Requester
     -> Approver

每个用户都将成为一个批准链中的请求者。 (您可能需要特别安排CEO)。此外,一些用户将成为一个或多个链中的审批者。最终批准者可能会根据请求者的等级而有所不同:首席执行官不会因批准清洁工作人员的休假安排而烦恼。

您需要一些规则来强制谁可以成为任何给定请求者假期的审批者。除非你有一个非常扁平的组织,否则你会发现你有一个工人和经理层级。例如,团队领导或领班 - 在其他方面“工人”而不是“经理”的个人 - 可能在链中。您还可能需要考虑组织的其他方面。例如,如果员工希望将假期带到下一年,可能需要得到人力资源部的批准,那些人通常对该员工没有管理责任。

修改2

好的,我们正在为一组任意规则建模而不是一个真实的场景。

我们来看看。每个用户都适合由这些任务定义的单个类别:

  • 员工可以请求离开
  • 经理可以批准或拒绝请假申请
  • 高级经理可以接受或推翻批准或拒绝

经理和高层管理人员没有共同的行为。因此,第一个模型是正确的。

答案 1 :(得分:2)

这主要归结为您如何定义术语的问题。基本问题是经理是否可以在任何可能的情况下替代员工 - 并且在不知道工作场所的精确规则的情况下,不可能以某种方式说出这一点。

一般概念是肯定的,至少在某一点上,经理应该能够完成任何下属的工作(至少下一级,很可能是两三级)。

另一方面,在一些有很多工会驱动规则的地方,情况可能并非如此。即使一个人完全有能力完成工作,规则也可能阻止他完全替换该职位。在某些情况下,这可能来自认证要求等(例如,经理可能有一个人有资格完成工作,但所需的认证已经失效)或者来自工会规则之类的事情(例如我曾经因为曾经受到谴责的朋友因为他带着一个手电筒灯泡和电池从公司商店回到他的实验室,而不是找工会材料处理员来为他做这件事。)

答案 2 :(得分:1)

我会把这些作为演员来模仿。它们不是系统的域,而是系统的用户。你会用“想要糖果的学校孩子”,“想要烟草的学校孩子的父母”,“职员”等来模拟一个商店的库存系统吗?虽然只有商店经理(演员)可以在没有收据的情况下给予退款,但在系统级别重要的是系统识别商店经理的密钥,而这是在软件中的权限令牌而不是扮演者所扮演的角色。

您描述的系统域是休假请求和用户帐户,某些用例意味着某些帐户有权对休假请求执行某些状态转换。

将User / Manager / Employee建模为actor和角色的不同之处在于,您可以专注于对需要放入系统的内容进行建模,因为不必具有actor的层次结构 - 您在使用时开始使用抽象案例和系统实体级别,而不是演员。考虑“这将如何在代码中起作用”并不总是一个坏主意,至少就“问为什么要编码这种区别”而言并非总是如此。