一、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的视图

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

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

5、视图和基本图的关系

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

6、UML类图的组成

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

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

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

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

2、领域模型的构建步骤

（1）识别概念类
找出当前需求中的候选概念类：
通过对用例描述中的名词或名词短语寻找和识别概念类；
- 概念类和属性的辨析
  属性一般是可以赋值的，比如数字或者文本。如果该名词不能被赋值，那么就“有可能”是一个概念类。如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。
（2）描述概念类
在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。
（3）添加关联
在概念类之间添加必要的关联来记录那些需要保存记忆的关系，概念之间的关系用关联、继承、组合/聚合来表示。
- 关联类型：
  须要知道型关联：将概念之间的关系信息保持一段时间的关联，需着重考虑。
  只需理解型关联：有助于增强对领域中关键概念的理解的关联。
- 找寻关联遵循的原则：
  集中查找须要知道型关联；
  识别概念类比识别关联更重要，领域模型创建应该更注重概念类的识别；
  太多的关联容易使领域模型变得混乱；
  避免显示冗余或导出关联；
3、用例模型的创建步骤

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

4、用例
- 用例一定是系统功能，系统功能不一定是用例
- 寻找用例的过程：找动词，确定动作的目的性，概括成一个用例
- 用例分类
- 基本用例：和角色直接相关的用例，表示系统的功能需求。是用户和系统直接交互形成的事件
- 子用例：通过场景描述分析归纳出的用例，也表示了系统的功能，但这些用例与角色无直接关系，间接交互，而与基本用例存在关联关系；
- 包含子用例和基本子用例
- 包含子用例：
  多个基本用例中的某个与角色交互的场景具有相同的操作（条件1），且这些场景都是基本用例中必须执行的步骤（条件2），它是基本用例的步骤集合中的一个子集，不会和角色产生直接关联。
  包含子用例的确定，必须从用户角度出发，“用例一定是系统功能，但是系统功能不一定是用例”
5、用例图

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

6、用例说明

模板如下：

7、系统顺序图

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

8、操作契约

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

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

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

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

面向对象需求分析方法

一、UML统一建模语言

1、主要特点

2、基本结构

3、UML的视图

5、视图和基本图的关系

6、UML类图的组成

2、领域模型的构建步骤

3、用例模型的创建步骤

4、用例

5、用例图

6、用例说明

7、系统顺序图

8、操作契约

相关推荐