uml综合案例：员工考勤系统

1《UML2面向对象分析与设计》综合案例：员工考勤系统作业评分实施细则一、第四章作业（用例图和用例文档）1.评分档次用例图和用例文档分别按照满分10分计算，以此作为评分标准，基本的评分准则如下：一档（10分）：图形（文本）条理清楚，无任何明显错误二档（8-9分）：图形/文本清楚，存在个别错误三档（6-7分）：图形/文本一般，存在一定的错误四档（5分）：图形/文本条理不清，存在致命错误或错误数过多一般情况下按错别个数扣分，每个错误按严重程度扣0.5、1、2分，最终成绩向上取整；同类错误不重复扣分。2.参考答案作业答案部分仅供参考，学生的作业可能会多种多样，具体按照第三部分的典型错误扣分，用例图：用例文档：用例编号：UC02用例名：登记考勤作者：谭火彬用例描述：小时工和普通员工通过该用例来编辑和查看自己的考勤信息参与者2员工（含小时工和普通员工）相关用例无前置条件员工已正确登录到该系统后置条件无（将在下次迭代中确定）涉众利益员工：准确地维护自己的考勤信息公司：要求员工的信息准确基本路径1—添加新的考勤1.1、用例起始于用户需要记录新的考勤信息1.2、系统显示当前日期和时间，并提醒用户该时间即为用户的上班时间1.3、用户确认该信息1.4、系统记录当前日期和时间，并将其作为用户考勤信息的上班时间2—提交考勤信息2.1、任何时刻用户都可以提交自己的考勤信息2.2、系统查询用户上班时的考勤记录（E-1）2.3、系统记录当前的日期和时间，作为用户考勤信息的下班时间2.4、系统显示用户今天完整的考勤信息2.5、用户确认提交考勤信息2.6、系统保存考勤信息，并将考勤信息的状态改为“已提交”（D-1）备选路径E-1如果系统没有找到用户上班时的考勤信息，则用例终止；用户可以通过项目经理为其添加上班的考勤信息数据需求A-1考勤信息主要包括：用户名、日期、上班时间、下班时间、状态D-1考勤信息的状态有：“新考勤”（只有上班时间，没有下班时间的考勤信息）、“已提交”（有完整的上下班时间，但还没有进行工资结算的考勤）、“已完成”（已结算工资的考勤）业务规则B-1作为用户考勤信息的上下班时间由系统自动获取，不允许用户编辑B-2状态为“已提交”的考勤信息不允许普通用户进行任何操作；非功能需求无设计约束无待解决问题无用例编号：UC06用例名：计算工资作者：谭火彬用例描述：该用例由系统定期启动，根据员工的考勤和工资级别等信息计算各类员工的工资3参与者时间、项目管理数据库（外部系统）相关用例无前置条件无后置条件无（将在下次迭代中确定）涉众利益员工：…（包括临时工、普通员工、销售人员）公司：…基本路径—计算普通员工和销售人员工资1.用例起始于系统时间到达每月末晚上，需要计算普通员工和销售人员工资(E-1)；2.系统查询所有的普通员工和销售人员的个人信息（D-1）；3.对于每一个员工（普通员工、销售人员）：3.1.根据员工的类别获得其考勤信息或订单信息（E-2）；3.1.1.如果是普通员工，则获得本月的考勤信息（D-2）；3.1.2.如果是销售人员，则获得本月的销售信息（D-3）；3.2.系统从项目管理数据库中获得员工的工资级别信息（E-3）；3.3.系统根据员工的考勤信息（或销售信息）和工资级别信息计算该员工的工资，保存；4.计算完成后，系统产生一个提醒信息，以便于项目经理确认备选路径E-1—计算临时工工资1.用例起始于系统时间达到每个周末的晚上，需要计算临时工工资2.系统查询所有临时工的个人信息3.对于每一个临时工：3.1.获得员工的考勤信息3.2从项目管理数据库中获得员工的工资级别信息；3.3系统根据员工的考勤信息和工资级别信息计算该员工的工资，保存；4.计算完成后，系统产生一个提醒信息，以便于项目经理确认E-2如果找不到该员工的考勤信息或订单信息，则记录相关日志，并转回3计算下一个员工E-3如果无法获得员工工资级别信息，则记录相关日志，并转回3计算下一个员工数据需求D-1.员工信息=员工编号+员工姓名D-2考勤信息参见“登记考勤”用例D-3订单信息参见“登记订单”用例业务规则暂不明确非功能需求暂不明确设计约束4无待解决问题1.系统具体的运行日期和时间有待和用户进一步商定3.2员工的工资级别信息的具体项目有待进一步明确3.3详细的工资计算细节有待进一步明确相关图（可画该用例的活动图）3.典型错误情况3.1用例图部分3.1.1参与者本系统中包含的参与者有：小时工、普通员工、销售人员、项目经理、项目管理数据库、时间，其中由于小时工和普通员工有关考勤的处理细节完全相同，因此为了便于简化和复用，可将他们统一合并为员工（不合并也可以，不算错误），但不能和销售人员合并，因为销售人员没有考勤信息，而是登记订单信息，需要明确区分。（1）时间参与者的使用时间参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例；它只是一种抽象，在定义参与者是不应该将其具体化。如在本系统中存在每周五、月末这样的具体时间点，这些细节不需要在用例图中表现，如有存在，扣0.5-1分；（2）外部系统参与者本系统需要和现有的项目管理数据库进行交互，因此该数据库是一个外部系统，需要定一个外部系统参与者“项目管理数据库”，注意此处应从用户角度定义参与者的名字，不能使用“数据库（扣1分）”、或“DB2数据库/系统”（扣0.5分）；（3）“人”作为参与者“人”作为一个外部因素，当他直接与系统交互时，在用例模型中作为一个参与者表示，但系统不能对他提出任何要求（即人不可能实现系统职责），因此注意用例与“人”关联的方向，一般情况下不要划由用例指向人的方向的关联（扣0-0.5分）；（4）参与者泛化关系的使用泛化代表责任重叠，如果两个参与者之间存在泛化关系，则特化的参与者会继承泛化参与者的所有用例，因此特化参与者不能再和泛化参与者相关用例再建立关联（扣0-0.5分）；此外，在定义泛化关系时要明确，特化的参与者需要泛化参与者所提供的功能，如本系统中项目经理和员工之间可以不定义泛化关系，因为需求中并没有明确表明项目经理需要进行考勤等员工相关操作。最后，如果某泛化/特化的参与者没有参与任何用例，则该参与者可以省略；注意参与者之间只有泛化关系，不存在其它的任何关系（扣0.5-1分）。3.1.2用例本系统中的用例有：登记考勤、查询考勤（这两个可合并成一个维护个人考勤）、查看工资、登记订单、查询订单（这两个也可合并成维护个人订单）、管理员工考勤、计算工资、5发布工资和登录；具体细节参看用例图。（1）用例的命名用例的命名按照“（状语）动词+（定语+）宾语”，且名称要简单易懂，直接反映业务本质，少用“信息”、“数据”等弱名次。典型的错误有：“考勤信息”：缺少动词，到底如何处理考勤信息（扣1分）“维护信息/数据”：维护什么信息/数据（扣1分）（2）用例体现系统需要完成的功能用例描述了系统需要完成的功能，因此不是系统需要处理的就不是用例；如问题陈述中明确表示对员工的奖惩不在本系统中处理，因此有关这些的用例都是错误的（扣1分）（3）用例粒度用例是一组用例实例，太细陷入了功能分解，用例文档不好写，后面的用例分析更没法做。如计算工资，没有必要把三类员工分别作为单独的用例，因为其操作流程比较简单且类似（扣0.5-1分）。（4）用例关系的使用扩展和包含关系从本质上来说非常类似，因此在某些情况下可以混用，但一定要注意这两种关系的方向是不同的，扩展是子用例对主用例的扩展，而包含则表示主用例包含子用例，（扩展方向错误，扣0.5-1分）一般情况下，本系统不需要使用任何用例关系，但如果有人使用，并且使用正确则酌情加1-2分；可以使用的关系有：“计算工资”可以分解出“产生确认消息”的子用例（建议用包含），项目经理的“管理员工考勤”可以分解出“修改考勤”、“修改订单”（建议用扩展）。最后，用例之间只存在这三种关系，使用任何其它不正确的关系都是错误的（扣0.5-1分）3.2用例文档部分用例文档的编写可以按照给定的模板，也可以不按给定的模板；如果使用其它模板，则要求必须包含的项目：用例名称、用例描述、前置条件、基本路径、备选路径、非功能需求等项目。用例文档书写时必须遵循一定的格式，调理清楚，如果没有格式，内容混乱，酌情扣1-2分。（1）用例文档中的基本部分用例名：必须与用例图中的名称一致，如用例图中为“查看工资”，用例文档中为“查看工资信息”，这种不一致扣1分；参与者：参与者部分只与该用例相关的参与者，需要与用例图中保持一致（扣0.5-1分）涉众利益：此部分主要是写清楚相关的涉众即可，至于涉众利益的具体描述不必深究。（2）前置条件和后置条件前置条件约束是约束用例开始前系统状态，后置条件约束用例执行后；系统状态前置、后置条件必须是系统能检测到的，而且对于前置条件必须在用例执行前可以检测到（扣1分）。后置条件一般可以不写。6（3）基本路径的编写用例的基本路径代表了本用例所要达到的主要目标；以参与者与系统进行交互的方式进行描述；编写时除第一句话，其他语句一般都以参与者或用例作为主语。下面的一些典型错误酌情扣0.5-1分基本路径只能处理一种情况，不能把所有的工作都罗列在一起，路经中的每个步骤必须是系统需要且能够处理的。如计算工资，由于小时工、普通员工、销售人员计算方法并不相同，因此该用例的基本路径只能处理一种情况，其他情况应该作为备选路径。（扣1分）7（4）备选路径备选路径的编写比较自由，主要注意的问题是与基本路径的衔接（即是从那个基本路径中派生出来的，一般是通过编号来表示），这部分不必求全（可能有些情况没有考虑到），写了并且正确即可。（5）用例关系在用例文档中的使用用例图中存在关系时，需要在用例文档中进行体现，此部分如果有人做，并且做得正确则加1-2分，做错了就要进行相应的扣分。扩展关系：在主用例中定义“扩展点”（增加“扩展点”项），在用例流程中需要扩展的地方插入扩展点（格式一般为：扩展点名）。在子用例中声明其父用例和对应的扩展点。包含关系：在主用例中定义“包含的子用例”（增加“包含的子用例”项），在用例流程中直接写“调用/包含***子用例”。二、第五章作业（用例分析）1.评分档次一档（10分）：图形（文本）条理清楚，无任何错误二档（8-9分）：图形/文本清楚，存在个别错误三档（6-7分）：图形/文本一般，存在一定的错误四档（5分）：图形/文本条理不清，存在致命错误或错误数过多一般情况下按错别个数扣分，每个错误按严重程度扣0.5、1、2分，最终成绩向上取整；同类错误不重复扣分。2.参考答案作业答案部分仅供参考，学生的作业可能会多种多样，具体按照第三部分的典型错误扣分（相关模型参加PayrollModel(Analysis).mdl文件）：第一个迭代周期（其中维护个人考勤只做基本路径，而计算工资可以只考虑最简单的情况-即计算临时工工资；此外，可以考虑把销售人员“维护个人订单”用例加入）时间(fromVersion1)计算工资(fromVersion1)项目管理数据库(fromVersion1)员工(fromVersion1)维护个人考勤(fromVersion1)8备选构架，以及各层中所包含的类：BoundarylayerControllayerEntitylayerAddTimecardFormSubmitTimeCardFormCalcSalaryFormProjectSystemInterfaceAddTimecardControlCalcSalaryControlSubmitTimecardControl9维护个人考勤（基本路径）-添加新考勤的顺序图:员工:AddTimecardForm:AddTimecardControl:Timecard:Employee1.//添加新的考勤信息1.1.//添加考勤1.1.1.//获取当前时间1.2.//显示当前时间2.//确认2.1.//增加新考勤信息2.1.1.创建考勤信息2.1.2.//关联员工和考勤信息维护个人考勤（基本路径）-提交考勤的顺序图10:员工:SubmitT