基于自动化办公系统的需求分析与建模

1. 项目与背景介绍

最近在《高级软件工程》这门课上学习了对项目进行需求分析与建模的方法，主要包括用例分析与建模、业务领域建模、关系数据建模等。为了掌握这些方法同时达到学以致用的目的，我将对自己的实践项目进行需求分析与建模，希望能对知识产生更进一步的理解。

本次要进行需求分析与建模的项目是基于请假流程管理的OA系统（Office Automation System，办公自动化系统），下面我将依次以用例建模、业务领域建模、关系数据建模的顺序对该项目展开分析。

2. 用例建模

2.1 用例

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

用例的基本要素：

• 一个用例应该由业务领域内的某个参与者（Actor）所触发。
• 用例必须能为特定的参与者完成一个特定的业务任务。
• 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

2.2 用例的抽象层级

用例一般可以划分为如下三个抽象层级：

• 抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例。

• 高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束。

• 扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

2.3 用例建模的基本步骤

1. 从需求表述中找出用例，往往是动名词短语表示的抽象用例；
2. 描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
3. 对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
4. 进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

2.4 准确提取用例的基本方法

1. 从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；

2. 验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件： 　　

• • 它是不是一个业务过程? 
  • 它是不是由某个参与者触发开始？
  • 它是不是隐式或显示地终止于某个参与者？
  • 它是不是为某个参与者完成了有用的业务工作？　　

　　 3. 在需求中识别出参与者、系统或子系统：

• • 参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者； 

  • 用例会属于系统或子系统　 

2.5 项目功能需求概述

本项目是要实现一个基于请假流程管理的OA系统，该系统的用途主要面向企业进行人事管理，其用户主要包括企业的普通员工及管理者，员工可以使用系统发起请假申请，管理者可以使用系统进行申请审批。系统的主要功能需求如下：

• 每一位公司的员工都有一个系统账户，员工可以用此账户登录系统。
• 公司采用分级定岗，从1-8依次提升
• 6级（含）以下员工为业务岗（普通员工）
• 7-8级为管理岗，其中7级为部门经理，8级为总经理
• 公司所有员工都可以使用系统进行请假申请。
• 所有员工都可以查看系统通知，申请请假的员工可以查看自己的请假审批进度，经理可以查看待审批的请假申请。
• 员工请假时间少于72小时，部门经理审批后直接通过。
• 员工请假时间大于72小时，部门经理审批后还需总经理进行审批。
• 部门经理请假需直接由总经理审批。
• 总经理提起请假申请，系统自动批准通过。

2.6 项目的用例建模

根据以上需求的描述，可以提取出用例如下：

• 登录系统
• 注销登录
• 申请请假
• 查看系统通知
• 审批请假

由此，可以画出用例图：

3. 业务领域建模

3.1 业务领域建模

• 业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
• 开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

3.2 业务领域建模的基本步骤

1. 收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料； 

2. 头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

3. 给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

4. 将结果用 UML 类图画出来。

3.3 项目的业务领域建模

为了实现不同级别的员工（普通员工、部门经理、总经理）登录系统后可使用的系统功能不同，本系统引入了RBAC（Role-Based Access Control，基于角色的访问控制）的方法进行实现，其主要思路是：系统中存在着多种角色（Role），不同的角色可以使用的系统资源（权限、功能等）是不同的，我们只需将控制访问的资源与角色进行绑定，然后再将系统的用户（User）与角色进行绑定，这样一来不同的用户就对应不同的角色，然后再对应不同的权限，从而就实现了不同用户访问不同系统功能的目的。

基于之前的用例建模和引入的RBAC设计，我们可以总结出业务领域中的相关类如下：

• 部门类：拥有ID、名称属性；
• 员工类：拥有ID、姓名、所属部门ID、职位、职级等属性；
• 用户类：拥有ID、用户名、密码、所属员工ID等属性；
• 角色类：拥有ID、角色描述等属性；
• 权限类：拥有ID、权限名称等属性；
• 请假信息类：拥有ID、申请人ID、请假类型、请假开始时间、请假结束时间、请假原因等属性；
• 处理任务类：拥有ID、请假信息ID、处理人ID、处理结果、处理意见、创建时间、处理时间、处理状态等属性；
• 消息通知类：拥有ID、接收人ID、内容、生成时间等属性。

由此可以画出系统的UML类图如下：

 

4. 关系数据建模

根据业务领域建模中的关联关系和关联类，我们可以进一步对项目进行关系数据建模，并进行关系型表设计，如下所示：

• Department

字段	数据类型	长度	非空	键	注释
department_id	bigint	20	是	主键	部门ID
department_name	varchar	32	是		部门名称

 

 

 

 

 

 

• Employee

字段	数据类型	长度	非空	键	注释
employee_id	bigint	20	是	主键	员工ID
name	varchar	32	是		员工姓名
department_id	bigint	20	是	外键	所属部门ID
title	varchar	32	是		职位
level	int	255	是		职级

 

 

 

 

 

 

 

• User

字段	数据类型	长度	非空	键	注释
user_id	bigint	20	是	主键	用户ID
username	varchar	32	是		用户名
password	varchar	64	是		用户密码
employee_id	bigint	20	是	外键	所属员工ID

 

 

 

 

 

 

• Role

字段	数据类型	长度	非空	键	注释
role_id	bigint	20	是	主键	角色ID
role_description	varchar	32	是		角色描述

 

 

 

 

• Permission

字段	数据类型	长度	非空	键	注释
permission_id	bigint	20	是	主键	权限ID
permission_name	varchar	32	是		权限名称

 

 

 

 

 

• LeaveInformation

字段	数据类型	长度	非空	键	注释
information_id	bigint	20	是	主键	请假信息ID
employee_id	bigint	20	是	外键	申请人ID
leave_type	int	255	是		请假类型
start_time	datetime	0	是		请假起始时间
end_time	datetime	0	是		请假结束时间
reason	varchar	128	是		请假原因

 

 

 

 

 

 

 

 

• Task

字段	数据类型	长度	非空	键	注释
task_id	bigint	20	是	主键	处理任务ID
information_id	bigint	20	是	外键	请假信息ID
employee_id	bigint	20	是	外键	处理人ID
process_result	varchar	32	否		处理结果
opinion	varchar	255	否		处理意见
create_time	datetime	0	是		创建时间
process_time	datetime	0	否		处理时间
process_state	varchar	32	是		处理状态

 

 

 

 

 

 

 

 

 

 

 

• Notice

字段	数据类型	长度	非空	键	注释
notice_id	bigint	20	是	主键	消息通知ID
receiver_id	bigint	20	是	外键	接收人ID
content	varchar	255	是		通知内容
creat_time	datetime	0	是		创建时间

 

 

 

 

 

 

• Role-Permission

字段	数据类型	长度	非空	键	注释
rp_id	bigint	20	是	主键	角色-权限ID
role_id	bigint	20	是	外键	角色ID
permission_id	bigint	20	是	外键	权限ID

 

 

 

 

 

• User-Role

字段	数据类型	长度	非空	键	注释
ur_id	bigint	20	是	主键	用户-角色ID
user_id	bigint	20	是	外键	用户ID
role_id	bigint	20	是	外键	角色ID

 

 

 

 

 

5. 业务概念原型