软件工程——面向对象需求分析方法——知识点总结

一、UML统一建模语言

1、主要特点

标准的图形化建模语言，是面向对象分析与设计的一种标准表示。

• 不是可视化的程序设计语言
• 不是工具或知识库的规格说明
• 不是过程
• 不是方法
• 是一种建模语言，一种标准表示

2、基本结构

(1)基本构造块
事物+关系+图
(2)语义规则
name、scope、visibility、integrity、execution
(3)通用机制
specification、adornment、common division、extensibility mechanism
(4)事物及关系
Structural thing、Behavior thing、Group thing、Annotation thing

3、UML的视图

用模型来描述系统结构（静态特征）和行为（动态特征），从不同的视角为系统架构进行建模，从而形成不同的视图，主要有：

• 逻辑视图/结构模型视图、静态视图：展现系统的静态或结构组成及特征，
• 构建视图/实现模型视图/开发视图：关注软件代码的静态组织与管理
• 进程视图/行为模型视图/过程视图/协作视图/动态视图：描述设计的并发和同步等特性，关注系统非功能性需求，
• 部署视图/环境模型视图/物理视图：：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等）
• 用例视图/用户模型视图/场景试图：强调从用户的角度看到的或需要的系统功能.
  

4、9个基本图

用例图/类图/对象图/顺序图/协作图/状态图/活动图/构件图/部署图

我愿称之为“九大巨人”（>==<）：
用例图——进击的巨人，因为是本章主角，而且用例真的很高深，就像进巨的设定。
类图——战锤巨人，从无到有，创造的可以是类，也可以是杀神武器。
对象图——女巨人（谁让她和阿尔敏搞对象
顺序图——铠之巨人，贯穿始终，好懂但是很纠结
协作图——车夫巨人，它体现了协作的重要性
状态图——始祖巨人，受到“不战之约”的影响，改变状态
活动图——超大巨人，因为它“活动”最不方便
构件图——颚之巨人，作为一个“胡桃夹”，这很构件。
部署图——野兽巨人，吉克也是个步步为营的部署高手。

5、视图和基本图的关系

用例视图：用例图和活动图【调查兵团】
逻辑视图：类图、对象图、顺序图/协作图【马莱军】
进程视图：状态图、活动图【艾伦和阿尔敏两个好“兄弟”】
构件视图：构件图【三代颚之巨人】
部署视图：部署图【吉克之义勇军】

6、UML类图的组成

UML类图用于描述类以及类之间的关系。

类的组成部分
①类名
②属性（可见性 属性名：类型名= 初始值 {性质串}）
③操作（可见性 操作名（参数表）：返回值类型 {性质串} ）

类的关系分类一
①关联【普通关联、导航关联、递归关联】
②组合和聚合
③依赖和继承

类的另一种分类
①依赖关系
②关联关系
③聚合关系
④组合关系
⑤继承关系

二、面向对象的需求分析建模

1、模型组成

包含两类模型：
（1）领域模型：
表示了需求分析阶段“当前系统”逻辑模型的静态结构及业务流程，：针对某一特定领域内概念类或者对象的抽象可视化表示。概括性的描述业务背景和业务流程。
以下元素不适用于领域模型：软件制品，例如窗口、界面、数据库、软件模型中具有职责或方法的对象。
（2）用例模型：
定义了“目标系统”做什么的需求。由以下四个部分组成
1)用例图（基础）：角色、用例、联系
2)用例说明（基础）：成功场景和分支场景
3)系统顺序图（附加说明）
4)操作契约（附加说明）

两者之间的关系如图：

2、领域模型的构建步骤

（1）识别概念类
找出当前需求中的候选概念类：
通过对用例描述中的名词或名词短语寻找和识别概念类；

• 概念类和属性的辨析
  属性一般是可以赋值的，比如数字或者文本。如果该名词不能被赋值，那么就“有可能”是一个概念类。如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。

（2）描述概念类
在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。
（3）添加关联
在概念类之间添加必要的关联来记录那些需要保存记忆的关系，概念之间的关系用关联、继承、组合/聚合来表示。

• 关联类型：
  须要知道型关联：将概念之间的关系信息保持一段时间的关联，需着重考虑。
  只需理解型关联：有助于增强对领域中关键概念的理解的关联。
• 找寻关联遵循的原则：
  集中查找须要知道型关联；
  识别概念类比识别关联更重要，领域模型创建应该更注重概念类的识别；
  太多的关联容易使领域模型变得混乱；
  避免显示冗余或导出关联；

3、用例模型的创建步骤

以用例为核心从使用者的角度描述和解释待构建系统的功能需求。
确定问题域的分析范围
问题域指的是在一次用例建模过程中，需要思考的问题边界，和场景相关
场景包括环节，环节中体现问题。
确定该范围内可能出现的角色
可以是使用系统的使用者、和用户使用场景关联的人、
根据业务背景或者领域模型，确定每个角色需要的用例，并形成用例图
①每个角色用例不同
基于确定的用例，整理成规范的用例描述文本
也就是需要生成用例说明
用例图整合
在可能的情况下，将多个角色的用例图整合成一个相对完整的用例图；
绘制系统顺序图
针对每个用例，结合相应的用例描述，确定系统顺序图中角色与系统之间的交互，绘制基于用例的系统顺序图，系统顺序图描述角色和系统的交互过程
确定操作契约
基于每个系统顺序图，确定每个事件交互经过系统处理后应该返回给角色的声明性结果，即操作契约；

4、用例

• 用例一定是系统功能，系统功能不一定是用例

• 寻找用例的过程：找动词，确定动作的目的性，概括成一个用例

• 用例分类

• 基本用例：和角色直接相关的用例，表示系统的功能需求。是用户和系统直接交互形成的事件

• 子用例：通过场景描述分析归纳出的用例，也表示了系统的功能，但这些用例与角色无直接关系，间接交互，而与基本用例存在关联关系；

• 包含子用例和基本子用例

• 包含子用例：
  多个基本用例中的某个与角色交互的场景具有相同的操作（条件1），且这些场景都是基本用例中必须执行的步骤（条件2），它是基本用例的步骤集合中的一个子集，不会和角色产生直接关联。
  包含子用例的确定，必须从用户角度出发，“用例一定是系统功能，但是系统功能不一定是用例”
  

• 扩展子用例：（多个）基本用例中的某些场景存在相同的条件判断的情况，可以将其抽取出来作为基本用例的子用例；

• 例如：取款和查询余额：是否需要打印凭证：同样的条件判断下实现的分支场景集合。那么打印凭证可以作为取款的扩展子用例
  

5、用例图

1、组成
Actor/User_case/Association
2、用例图的确定
找动词，确定用例和关联
3、角色
(1)使用系统的对象，代表角色可以是人、系统、设备、组织、时钟等，表示一类用户，
(2)如何确定角色：
通过“自问自答”(主要用户？谁会使用这个系统？谁会维护这个系统？有无与其他系统交互的情况？是否存在时钟信号？)
4、用例
(1)场景集合，场景包括成功场景和失败场景，描述用户如何成功使用系统功能实现需求目标。
(2)如何判断用例：
分析系统承载的日常任务、为了承载业务所需要提供的功能，系统对数据的处理？哪些事件会影响系统状态？

6、用例说明

模板如下：

7、系统顺序图

1、对象和消息
(1)对象：角色对象、系统对象
(2)消息：创建/删除/同步/异步
2、背景
用例描述的基础上需要进一步确定角色与系统之间的交互信息，并以可编程的方式将其命名
3、组成元素
(1)角色
(2)代表软件系统的对象
(3)角色与system之间的交互信息，简称消息或操作
4、注意事项
并不是所有场景都需要，只有比较复杂或者主要的场景才需要绘制系统顺序图

8、操作契约

1、定义
处理系统事件的操作，也称为系统事件；
2、背景
系统顺序图上代表待构建软件系统的对象，在接收到角色所发起的系统事件请求之后，系统对象根据需求的内容所返回的一个明确的结果以及相关对象的状态，以便软件设计时进行参考
它是为系统操作而定义的，参考领域模型中业务对象接收到相同的系统事件后，执行必须的业务处理时，各业务对象的状态以及系统操作执行的结果。
3、模板

4、创建原则
(1)根据系统顺序图识别进入到系统内的所有系统事件，即操作；
·针对每一个系统操作结合对应的用例领域模型，找到与此操作相关的概念类对象；
·对那些相对复杂以及用例描述中不清楚的那些系统操作按照后置条件内容确定对象的状态变化，
5、组成元素
对象、关系、属性
6、操作契约和领域模型产生关联的原因
原因在于创建操作契约的过程中，涉及领域模型的概念类知识。
7、注意事项
后置条件的陈述应该是声明性的，以强调系统状态所发生的变化，而非强调这种变化是如何设计实现的。 【只说结果，不重视过程】