在我们公司，尽管《需求规格说明书》中有“业务概念图”的章节，但很多项目经理都不能画好，很多复杂的系统只能画出非常简单的几个业务概念。能否做好其实很依赖于你的功力！
你可能会问：有些公司不用UML，不用类图的，难道他们就不能表达好业务概念？
那当然不是了，类图只是其中一种表达方式，一些公司会通过数据字典或者是详细的文字和表格来说明各种业务概念，不过我推崇的还是使用类图，类图强在方便表达类之间的关系和方便进行提炼！
回到这个考勤系统，考勤系统有什么业务概念、它们之间是怎样的关系呢？
我们强调了业务概念图这么高的难度，你可不要被吓怕了，越难的东西你掌握了你就约值钱！请你尽你所能画出本系统的业务概念图，完成后才继续往下学习噢！
这是一个考勤管理系统，与考勤相关的重要业务概念有：考勤记录、请假记录、外出工作记录。
这个系统涉及到人和部门，故重要业务概念还有：部门、员工。

本图列出了关键的业务概念、业务概念的重要属性、业务概念之间的关系，相关业务规则通过注释来说明。
大家所在的公司情况不一样，大家对考勤的理解角度不一样，这个图就会不太一样。
请你比较你画的图与上图的差异，在线提出你的问题，讲师将会解答大家的疑问！考勤记录：
其实就是打卡记录。大家去打卡的时候，有想过打卡机记录了什么吗？打卡机记录了你的工卡的ID和打卡时间。
打卡机如何知道这是上班打卡还是下班打卡？其实它是不知道的，只能看时间与打卡顺序。
如：你们上午上班时间是9:00-12:00，但打卡机有一条记录显示打卡时间是10:30，请问这算上班打卡还是下班打卡？
光靠这些信息还不能判断，如果这是该ID当天的第一次打卡，应该算上班记录，如果是第二次打卡，则可能是下班打卡或者是外出工作时的打卡。
我们公司以前中午休息，大家是需要打卡的，下班时打一次，上班时再打一次，这样一天要打4次卡。中午要打卡的规定，导致了很多问题，大家中午很容易忘记打卡，这样就导致一个人一天只有2次或者3次的打卡记录，导致了一些管理上的混乱。后来我们取消掉中午打卡的规定，只需要上午上班和下午下班各打一次卡便可。
你思考这个考勤系统的时候，如何也遇到我们公司类似的中午打卡问题咋办？那就应该先做业务重组，用简单有效的办法来管理打卡。
你可能有这个问题：打卡机不是记录了员工的工卡ID和打卡时间吗？为什么考勤记录这个类没有工卡ID这个属性？
这个问题问得好！
考勤记录与员工这两个类之间是有关系的，我们看到一个员工有多次打卡记录，一次打卡记录只对应一个员工。也就说说这样的对应关系，已经反应了通过考勤记录是能找到相应的员工的，故考勤记录中不需要设工卡ID座位属性。
类似的，请假记录、外出工作记录类都没有“员工ID”之类的属性，绘制业务概念图时，我们不需要在类中体现它们的“外键”，事实上“员工ID”之类的属性，是这些业务类关系的实现方式之一而已，在需求阶段我们不需要也不应该明确这些关系的实现，何况实现方式还有其它可能呢！请假记录：
只有开始时间与结束时间两个属性，你可能会问请假时长为什么不做为属性之一？
请假时长可以由开始时间与结束时间计算出来，这是一个“导出属性”，对于这样的情况，一般不需要在类中再加一个属性，概念图的类的属性，最好都是“原始”属性，不能由其它东西推导出来的。
当然到数据库设计、程序设计时，这些“导出属性”有可能会设计为数据库的字段和类的某个属性，但这是实现方式，绘制概念图时不需要也不应该明确这些内容。
请假是分类别的，类别没有直接放到请假记录的属性中，而是抽离出来。
请假类别是很重要的一个东西，不同的类别请假的流程、薪金减扣计算都不太一样，对于重要的类别，我一般会单独一个类来表示，并通过批注说明具体有什么类别。
这些类别，在数据库设计时往往被设计为单独的一个表，在程序中往往会使用枚举来表示。将这些重要类别单独一个类表示，可方便设计人员思考。外出请假工作记录：
在思考这个类时，其实是有一些业务上的麻烦的。不知道大家外出工作流程是怎样的？
我们需要外出者填写外出申请，标明起止时间和工作内容等，同时要求如果需要外出时你在公司，则你还需要打卡才能外出。
我们之前还曾很“无聊”地规定所有销售人员，就算你当天一整天都要外出，你都需要先到公司打卡，当然我们后来取消这个不人性化的规定了。
不过现在还是存在问题，也就是很多情况下的外出工作，即需要填写外出申请，也需要打卡，也就是要求：外出工作记录与考勤情况应该是一致的，也就是外出工作记录类的注释所写的内容了。这样的要求有一定的管理麻烦，但暂时又想不出更简单有效的管理办法，这就意味着我们的考勤系统需要考虑这样的功能：能方便检查外出工作记录与考勤情况有没有出入。
整理业务概念时，你会有很多思考。考勤系统看上去不复杂，但涉及到每一个人的利益，涉及到公司的管理制度，就不是这么简单了。
当你去做一个业务系统需求分析时，你的工作重点其实是帮助客户重组业务流程，不使用系统手工操作时，很多工作是不严格和随意的，不整改这些工作，系统是无法做出来的。
重组业务是高难度的工作，你现在才重组了业务概念部分，准备下一个挑战吧，重组业务流程！

转：http://www.umlonline.org/school/thread-182-1-1.html