uml 在需求分析阶段的应用

         上一篇博客写了uml在软件开发过程中的应用，这以篇要详细介绍一下UML在需求分析过程中的应用。

         以机房收费系统为例进行讲解，先介绍一个该系统。

         首先该系统的用户分为三个等级，一般用户，操作员，管理员，一般用户的权限，能够查看学生余额，充值记录，上机记录，学生上机状态查看等。操作员可以进行学生注册，充值，退卡，收取金额查询，学生退卡查询，学生基本信息的维护，查看操作员的工作记录。管理员负责对上机的一些基本数据的设定，结账。添加，删除用户，查看日结账单，周结账单。首先看一下设备连接图：

        

读卡器的工作就是读取卡的id号，并触发系统中一次enter 事件。

工作流程就是，

 

 

 

主要的流程就是这五个步骤，其他的在这个过程中，或者以后都可以进行实现。

一．用户需求：

         了解了工作过程之后，就可以开始获取用户需求了，所以开始进行需求分析。

         通过了解，与系统相关的人员主要有以下几种，

         （1）      学生。提供细心给操作员，进行注册。拿着卡进行刷卡上下机。

         （2）      一般用户。能够查看学生余额，充值记录，上机记录，学生上机状态查看，强制下机。

         （3）      操作员。学生注册，充值，退卡，收取金额查询，学生退卡查询，学生基本信息的维护，查看操作员的工作记录。

         （4）      管理员。基本数据的设定，结账。添加，删除用户，查看日结账单，周结账单的打印。

         （5）      系统开发人员。负责开发机房收费系统的项目组成员。

         （6）      机房主任。查看所有账务项目。

          备注：在收集用户的需求时，要考虑到关心软件系统开发所有人员的需求，不仅要了解最终用户的需求，还有了解其他使用系统的需求，（如机房主任），还要了解软件开发人员的需求。

二．需求分析与描述

         首先要对用户提出的需求进行分析，以此来确定其中要实现的系统功能，然后再同用户进行更加深入的讨论交流，确定哪些需求是功能性，那些是非功能性的，哪些是软件系统的需求，哪些不是，哪些需求是可以实现的，哪些需求是无法实现或暂时无法实现。

         由于需求过多，所以以其中的一条需求为例

         需求原文：操作员的学生注册功能。

         操作员需要对学校所有要上机的学生进行注册，注册的内容包括姓名，性别，学号，班级，年级，备注，和每个学生卡的卡号。他是机房收费系统中最基本的一项需求，在开发的过程中，要认真的进行考虑。

         将所有的需求分析进行完成以后，得到了用户需求分析结构，为了更好的表示一般采用表格的形式：（这里不全部例出）

                                                      表（1）

序号	用户需求	软件需求	功能需求	可以实现
01	提供自己关于注册卡的所有信息给操作员，进行注册	否	否	可以
02	查看学生卡内的余额	是	是	可以
03	学生卡注册	是	是	可以
04	设定上机需要的基本数据	是	是	可以
.	….	……	…	…

三．用例分析

         在需求分析完成后，开始进行用例分析，为了能够正确的找出系统的用例，需要确定系统的边界，找出系统的执行者。根据表1的需求结果进行用例分析。

1.      系统的边界

         从需求中可以看出，学生可以将卡放在读卡器上进行读取信息，读卡器将信息发送到系统中，并触发enter事件。

         这时要考虑机房收费系统是否包括读卡器。机房收费系统是一个软件系统，因此不包括读卡器。

 

2.      系统的执行者

         有了系统的边界，就可以更容易的找出系统的执行者，从系统的边界中可以知道读卡器是系统的执行者。

         执行者主要分析每一个操作是由谁来执行的。由需求描述可以看出，用例的执行者还有，一般用户，操作员，管理员。所有该系统总共有四个执行者。读卡器，一般用户，操作员，管理员。

 

3.      系统的用例

          有了边界和执行者，就可以分析这些执行者是如何与系统进行交互的，进一步找出系统的用例。通过需求的分析，可以看出每个执行者的目标和希望得到的价值。

         读卡器     读取卡的卡号，发送给系统。

        一般用户。能够查看学生余额，充值记录，上机记录，学生上机状态查看。

        操作员。学生注册，充值，退卡，收取金额查询，学生退卡查询，学生基本信息的维护，查看操作员的工作记录。

        管理员。基本数据的设定，结账。添加，删除用户，查看日结账单，周结账单的打印。

 

4.      画出系统用例模型图

 

            可以看出这个系统有四个执行者，和24个用例。如果这里的每个用例需要进行详细的解释，还需要些用例描述，这里不再给出。

四．领域模型分析

           这里所说的领域是用例的业务领域，也就是需要解决问题的领域。对领域知识的理解直接关系到系统开发的成败。

1.      领域概念

          领域概念就是描述一个现实世界中的某个问题的一些名词和术语。建立领域模型的第一步是找出描述这些问题的概念和术语。

         对机房收费系统的所有用例和用户需求分析，找到尽力能找到的所有的明细，动词，动词词组。

                                                        需求过程中的名词

学生	读卡器	一般用户	操作员	管理员	机房管理人员
学生基本信息	日结账单	周结账单	充值记录	基本数据	卡

                           

                                          需求过程中的动词或动词词组

查看学生余额	基本数据设定	注册	充值	退卡	收取金额查询
学生退卡查询	学生基本信息维护	强制下机	结账	添加用户	删除用户
打印账单

在记录用户的需求时，应该尽可能的记录所有出现过的词汇，方便以后挑选，避免漏掉重要的词汇。

2.      概念类

        从上边列出的名词开始筛选，找出可能的概念类。

        学生：是一个概念类。

        卡：是一个概念类

        读卡器：与系统没有关系，所以不是概念类。

        一般用户：是概念类，操作时，要知道是谁进行的操作

        操作员：是概念类，操作时，要知道是谁进行的操作

        管理员：是概念类，操作时，要知道是谁进行的操作

        机房管理人员： 不是一个概念类，与系统的开发无关

        学生基本信息：是一个概念类，注册的时候需要。但是包含在学生类里。

        日结账单：是一个概念类

        周结账单：是一个概念类

        基本数据：是一个概念类

        经过上面对所有的名词进行分析，可以得到所有的概念类，在应用时为了方便，每个概念类都有一个英文名称。

概念类名称	英文名称	概念类名称	英文名称	概念类名称	英文名称
学生	Student	一般用户	General user	操作员	Operator
管理员	Admin	日结账单	Daycheck	周结账单	Weekcheck
基本数据	BasicData	卡	Card

 

         找出了所有的概念类以后，然后找到类与类之间的关系，并找到他们呢所具有的方法与属性，如何找这里不再解释，最后画出一张类图。

 

机房收费系统的领域模型 1

五．工作流程分析

 

         流程图

          前边建立的领域模型，描述了系统的各个类之间的静态结构，下面使用活动图顺序图来描述系统的动态行为。

         机房收费系统的核心工作就是，注册卡，充值，负责学生刷卡上下机，然后打印账单。

 

 

                                                机房收费系统学生卡注册上机流程图 1

            管理员登陆系统以后，先要进行基本数据的设定，基本数据设定成功以后，就可以进行注册，充值，然后就可以刷卡上机，刷卡下机，或者进行一些其他的操作(上边需求分析提到的用例)。

 

顺序图

         前边分析了系统的领域模型，和系统流程，下面看一下系统是如何与外界进行交互的。用例描述时是用文字描述的，下面用顺序图来描述一个用例的执行过程。他主要描述系统的外在行为，即系统的输入域输出。

系统是软件系统的抽象，顺序图描述了系统接受一条数据和对这条数据进行的处理过程。首先要从读卡器哪里获取数据。然后由系统或者操作员进行操作。

这个顺序图描述的内容与用例的文本是完全一样的。顺序图更加直观的描述了用例的执行过程。为进一步设计系统打下基础。

         需求分析是软件开发的起始部分，也是软件中最为关键的部分，对于用户的需求理解，直接决定了系统的正确性。所以在进行需求分析的时候，一定要全面，正确的分析。