2. 软件需求 & 面向对象分析

目录

1. 软件需求

1.1 需求分类

1.2 需求获取

1.3 需求分析

2. 面向对象分析（OOA）

2.1 统一建模语言 UML

2.2 用例模型

2.2.1 用例图的元素 

2.2.2 识别参与者

2.2.3 合并需求获得用例

2.2.4 细化用例描述

2.3 分析模型

2.3.1 定义概念类

2.3.2 确定类之间的关系

2.3.3 为类添加职责

---

1. 软件需求

在软件生命周期中需求分析是⾮常重要的⼀步，在进行需求分析前，我们需要先了解⼀下需求的分类以及如何获取需求。

1.1 需求分类

1. 业务需求：指反映企业或客户对系统的目标要求，通常来自与企业内部。
2. 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。
3. 系统需求：从系统角度来说明软件的需求，包括功能需求(系统必须实现的功能)、非功能需求(比如软件的质量，可维护性，效率等等)和设计约束(交付时的一些限制条件，比如必须采用国有自主知识产权的数据库，必须运行在某个操作系统下)等等。

1.2 需求获取

需求获取的方式主要有以下几种：

• 用户访谈：最基本的方式。
• 问卷调查：由于对用户进行逐一访谈比较耗时且用户时间不一定允许及时参与访谈，所以可以预先准备问卷调查表让用户填写，再根据结果进行小范围访谈，可以看做是对用户访谈的一种优化。
• 采样：对特定群体进行采样，研究所选出的样本，得到有用信息。对于信息系统的开发，现在文档就是采样种群。
• 情节串联板：通过一系统图片、幻灯片来进行讲解，说明系统应该如何运行。

1.3 需求分析

获取需求后，进行具体的需求分析工作，最终形成软件需求规格说明书做为向下⼀个阶段交付的

成果。

工作内容有以下几点：

1. 绘制系统上下文范围关系图：用于定义系统与系统外部实体间界限和接口的简单模型，为需求确定范围；
2. 创建用户界面原型：可以通过快速开发工具开发一个原型或者通过幻灯片、Flash等演示工具制作一个演示原型，甚至可以通过纸笔画出一些关键的界面接口示意图，从而帮助用户更好的理解要解决的问题，理解系统;
3. 分析需求的可行性：对获取到的需求进行成本、性能和技术实现方面的可行性研究，以及是否与其他的需求存在冲突，是否有对外部的依赖等;
4. 确定需求的优先级：是制订迭代计划的一个重要的依据，可以使用满意和不满意指标进行说明。满意度表示当需求被实现时用户的满意程度，不满意度表示当需求未被实现时用户的不满意程度；
5. 为需求建立模型：表现形式主要是图表加上少量的文字描述，图形化的描述使需求更加清晰、易懂。需求分析模型主要描述系统的数据、功能、用户界面和运行的外部行为，并不会涉及软件的具体实现细节，同时，为后续的软件设计提供了系统的表示视图；
6. 创建数据字典：对系统用到的所有数据项和结构进行定义，以确保开发人员使用统一的数据定义。

2. 面向对象分析（OOA）

OOA的基本任务是运用面象对象方法，对问题域进行分拆和理解，正确认识事物间的关系，找

出描述问题域和系统功能的类和对象，定义它们的属性和职责，以及它们之间形成的各种联系。

2.1 统一建模语言 UML

UML(Unified Modeling Language)是一种易于表达、功能强大且普遍适用的建模语言，它的作用不限于支持OOA和OOD，还支持从需求分析开始的软件开发全过程。
UML的重要组成部分：

• 事物：事物也称为建模元素，包括结构事物、行为事物、分级事物和注释事物，这些事物是UML模型中最基本的OO构造块;
• 关系：UML用关系把各个事物结合在一起，主要的关系有: 依赖(dependency)、关联association)、泛化(generalization)、实现(realization);
• 图：主要包括类图、对象图、构件图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图等。

2.2 用例模型

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们关心的是系统所能提供的服务，把从用户那里获取的需求记录下来，进行合成与提炼，从而建立用例模型。在OOA方法中，构建用例模型一般需要经历以下阶段分别的，识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

2.2.1 用例图的元素 

用例是一种描述系统需求的方法，在用例图中，主要包括参与者、用例和通信关联三种元素：如下图所示。

• 参与者：参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等：
• 用例：指在系统中执行的动作，这些动作将生成参与者可见的结果。也就是说用例表示系统所提供的服务，它定义了系统是如何被参与者所使用，描述的是参与者为了使用系统提供的服务与使用发生的一段对话；
• 通信关联：表示的是参与者和用例之间的关系，或者用例与用例之间的关系。箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者，如果不想强调对话中的主动与被动关系，可以使用不带箭头的关系实线。

2.2.2 识别参与者

参与者是与系统交互的所有事物，不仅可以由人承担，还可以是其他系统和硬件设备，要注意的是，参与者一定在系统之外，不是系统的一部分。执行系统功能的参与者可能有多个，有主次之分，开发用例的主要目的是找到主要参与者。 

2.2.3 合并需求获得用例

将参与者都找到之后，接下来就要仔细检查参与者，为每个参与者确定用例。
首先，要将获取到的需求分配给参与者，比如，普通用户可以进行注册，登录，编辑个人信息，发贴子，修改自己发的贴子，发站内信等等，管理员不仅可以进行普通用户的操作还可以进行版块管理等等。
其次，进行需求合并操作，并产生用例，比如对于帖子来说，可以相关的操作描述成具体的动作如：发布帖子，修改帖子，删除帖子，在这里合并为操作帖子。注：用例并不需要包括具体的操作流程(事件流)，事件流将在细化用例描述中体现。
然后，将识别到的参与者和合并生成的用例通过用例图的形式表示出来，至此以获得用例模型的框架。如下图所示：

2.2.4 细化用例描述

用例描述可以迭代完成，先对一些重要的用例编制相对细致的描述，对于那些不重要的用例可以留待以后再补充完成，用例描述通常包括用例名称、简要说明、事件流、非功能需求、前置和后置条件、扩展点、优先级。

2.3 分析模型

2.3.1 定义概念类

概念类：模型中可以代表事物与概念的对象。

OOA的主要任务就是找到系统中的对象和类，这些类将反映到OOD中的软件类和OOP中具体的实现类。
发现类的方式有很多种，其中应用最广泛的是名词短语法，具体步骤如下:

1. 阅读和理解需求文档或用例描述
2. 筛选出名词或名词短语，建立初始类清单(候选类)
3. 将候选类分为三类:分别是显而易见的类，明显无意义的类和不确定类别的类
4. 舍弃明显无意义类别的类
5. 讨论不确定类别的类，直到把他们合并或调整到其他两个类别。 

2.3.2 确定类之间的关系

当完成了类的寻找⼯作之后，就是理清这些类之间的关系，类之间的关系有：关联、依赖、泛

化、聚合、组合和实现，他们在UML中的表示方式如下：

• 关联关系：提供不同类的对象之间的结构关系，而不是类与类之间的关系，两个对象之间一般以动词连接，比如，用户-发布-帖子，可以用一个箭头连接，表示关联关系对象可以从一个端得到另一端对象，如果没有箭头，认为是一个双向关系或是一个未定义的关联；
• 依赖关系：两个类A和 B，如果B变化可能会引起A的变化，则称类A依赖与B，比如，一个类是另一个类的数据成员，一个类是另一个类的某个操作的参数等；
• 聚合关系：共享聚集关系通常简称为聚合关系，他表示了类之间整体与部分的关系，“部分”可以属于不同的“整体”，“部分”与“整体”的生命周期可以不同，比如，汽车和车轮一个汽有一多个轮子，汽车坏了，轮子还可以用，轮了坏了可以再换一个；
• 组合关系：组合聚集关系通常简称为组合关系，他也表示了类之间整体与部分的关系，与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，比如：一个公司有多个部门，他们之间就是组合关系，公司一旦倒闭，部分也就不存在了；
• 实现关系:描述的是类和接口之间的关系，一个类可以实现接口中声明的方法；
• 泛化关系:描述的是父类与子类之间的关系，继承关系是泛化关系的反关系，也就是说子类继承了父类，而父类是子类的泛化。 

2.3.3 为类添加职责

在找到概念类并且理清了他们之间的关系后，就可为类添加职责，主要包括两方面内容：

• 类所维护的知识，即成员变量或属性
  • 注意要保持属性的简单性，即:只定义与系统责任和目标相关的属性，使用简单数据类型定义；不为类关联定义属性。
  • 类能够执行的行为，即成员方法或责任
    • 可以根据动词来判断，再进行筛选，与识别类的过程类似。

这个阶段只找出一些主要的、明显、与业务规则相关的部分，切忌在这个阶段不断地细化 。