uml 在需求分析阶段的应用

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

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

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

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

工作流程就是，

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

一．用户需求：

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

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

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

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

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

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

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

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

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

二．需求分析与描述

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

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

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

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

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

                                                      表（1）

三．用例分析

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

1.      系统的边界

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

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

2.      系统的执行者

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

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

3.      系统的用例

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

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

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

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

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

4.      画出系统用例模型图

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

四．领域模型分析

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

1.      领域概念

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

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

                                                        需求过程中的名词

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

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

2.      概念类

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

        学生：是一个概念类。

        卡：是一个概念类

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

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

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

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

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

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

        日结账单：是一个概念类

        周结账单：是一个概念类

        基本数据：是一个概念类

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

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

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

五．工作流程分析

         流程图

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

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

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

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

顺序图

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

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

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

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