需求分析

一、定义边界

二、发现主角

直接与系统交互的涉众才能被称为业务主角。一个涉众可以衍生出多个主角
业务主角总是在边界之外
与业务目标无关的要求也不应当在该边界中体现

三、获取业务用例

功能性需求

functional requirement, FR
项目中具体需要提供的功能和内容，比如用户登陆功能、收发邮件功能和论坛功能等

非功能性需求

non functional requirement, NFR
项目中为满足客户业务需要必须达到的一些特性
安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性

• 系统性能：如需要满足N个用户同时使用，页面响应速度不能超过M秒。
• 可靠性：系统需要7＊24小时连续运行，年非计划宕机时间不能高于8小时，要求能快速部署，特别是在系统出现故障时，能够快速的切换到备用机。

在统一过程（UP）中需求按 FURPS＋模型分类：

• 功能性（Functional）：特性、功能、安全性；
• 可用性（Usability）：人性化因素、帮助、文档；
• 可靠性（Reliability）：故障频率、可恢复性、可预测性；
• 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率；
• 可支持性（Supportability）：适应性，可维护性、国际化、可配置性；
• ＋ 指一些辅助性的和次要性的因素，比如：

1. 实现（Implementation）：资源限制、语言和工具、硬件等；
2. 接口（Interface）：强加于外部系统接口之上的约束；
3. 操作（Operation）：对其操作设置的系统管理；
4. 包装（Packaging）：例如物理的包装盒；
5. 授权（Lagal）：许可证或其它授权方式。

使用 FURPS＋分类方案（或者其它分类方案）作为需求范围的检查列表是有效的，可以避免遗漏系统的某些重要方面。其中某些需求可以统称为质量属性（quality attribute）、质量需求（quality requirement）或系统的某属性，这些需求包括：可用性、可靠性、性能和可支持性

UML

从架构分类：对象、交互、状态
对象：
类、组件、部署
行为（交互）：
用例、时序、协作、活动
状态：
状态

三视图：
用例、类、时序（/活动）

文->表->图

模型

用例模型

用例图、时序图、实现图

动态模型

时序图、活动图、状态图、流程模型

时序图

活动图

状态图

流程模型

逻辑模型

类模型

A logical model is a static view of the objects and classes that make up the design/analysis space 逻辑模型是构成设计/分析空间的对象和类的静态视图

类模型 class model

定义
描述 系统的行为与持久状态

Typically, a Domain Model is a looser, high level view of Business Objects and entities, while the Class Model is a more rigorous and design focused model
域模型是业务对象和实体的一个松散的、高级的视图
类模型则是一个更严格的、以设计为重点的模型

A class encapsulates state (attributes) and offers services to manipulate that state (behavior)
类封装了状态以及提供操作状态的行为

继承 Inheritance

组件模型

组件

组件接口

组件节点

需求
约束
场景
可追溯性

服务组件

安全组件

物理模型

部署模型

部署图

物理模型

结构图（静态） Structure Diagram：

• 类、对象、包<-模型、组合结构、组件、部署<-网络、属性
  • Class、Object、Package<-Model、Composite Structure、Component、Deployment<-Network Architecture、Profile

行为图（动态） Behavior Diagram：

• 用例<-信息流、活动、状态机<-行为状态机<-协议状态机、交互图-<[顺序、协作、时序、交互预览]
  • UseCase、InformationFlow、Activity、StateMachine<-BehavioralState、Interaction-<Sequence、Comunication、Timing、Interaction

结构图（6）：
对象、类、包、组合结构、组件、部署

行为图（7）：
用例、顺序、时序、活动、状态、交互、协作
特殊图（3）：
需求模型、数据模型、用户接口模型

获取需求

涉众

从涉众中划分角色

需求优先矩阵

边界

从用户角色

元素

编号
级别
名称
分组

用例图 Use Case

用例卡片

例子：

定义

描述给定边界中的一系列饥渴目标
用例图描述需求场景

A Use Case Model describes the proposed functionality of a new system 用例模型描述系统期望的功能

输入 in

分阶段（概念、业务、系统）的用例场景描述文档
用例卡片

输出 out

分阶段的用例图
通过用例提取渲染出活动图，带泳道的活动图分步骤有序性细化了如何实现用例图目标的各种行为

完整描述

意见与笔记：描述用例
需求：必须是能够提供给最终用户的正式需求（F）
约束：
前置条件
后置条件
不变性属性/条件
场景：正式、有序的，通常与顺序图相互呼应
场景图：顺序图描述工作流
可添加的属性：实现阶段、版本号、复杂性评级、模版状态
元素：边界、角色Actors、用例、约束

关系

generaliztion，抽象用例的具体实现
extend，非必须的需求（NF）
include，大且复杂抽象的需求拆分出具体且重要的某一个或多个，（F）
The include relationship could be used:

  - to simplify large use case by splitting it into several use cases,
  - to extract **common parts** of the behaviors of two or more use cases.

粒度

概念建模，一个完整的事件流
业务建模，一个完整的事情
系统建模，用例视角针对计算机的，以一个用例能够描述操作着与计算机的一次完整交互为宜

获取

主角对系统边界内有明确的期望、明确的回报要求

误区

以步骤为用例【错】以完整目标作为用例【对】
寄信人->寄信【对】 寄信人->买信封、买邮票、付钱、投递【错】

Tips

复杂系统，采取高层次抽象
用例间不要使用泛化关系、尽量使用包含/扩展代替
绘制 业务用例实现 是简单的好习惯

业务用例

客户业务视角
尽可能的抽象

in:
概念模型
out:
系统用例

图形

椭圆 右下角/

业务用例实现

对抽象的业务用例的具现化
根据业务用例实现得出关键业务对象，业务对象转化为设计对象，从而生成代码

图形

虚椭圆 右下角/

系统用例

系统视角，定义系统范围、获取功能性（FR）需求的，我们追求的最终需求。

in:
业务用例
out:

（系统）用例实现：
用例实现是连接用例模型与系统实现的桥梁。

概念用例：
很少采用，但对业务用例到系统用例过渡有一定指导作用。
例：
预存话费 <- refine [开立账户，存入现金，转账，支付划账]

业务实体

是 类的一种版型，具有对象的所有性质，包含属性和方法 应用于 业务建模阶段 建立 领域模型 代表 业务角色执行业务用例时 处理/使用的 事物

理解
参与者与用例描述在这个问题领域中达到什么目标
业务实体描述了使用什么来达成业务目标/通过什么来记录业务目标
问题领域比作大楼，业务实体就是构成大楼的石头瓦砖

举例
饭店中的业务实体：菜单、饮料
机场的业务实体：机票、登机牌
心理治疗场景：患者的情绪

图形

正圆 右下角 /

获取业务实体

业务用例场景：
参与者实现其业务目标的过程描述

例：
寄信人到达邮局，购买信封，将信装入信封，写上地址，称重，计算邮资，购买油票，贴上油票，邮寄信件，拿走回执。

动词后的名词，即业务实体的备选对象

整合

一个用例模型包含了多个用例图
每个用例对应该用例的协作图
双击用例图，可以进入该用例的协作图

Q

1.什么是用例图，有什么作用意义，怎么使用，举例，拓展【注意事项】。
2.

时序/顺序/序列图 Sequence

定义

描述一个用例的事件流（行为顺序）

作用
放在用例模型下，描述用例场景

One sequence diagram typically represents a single Use Case ‘scenario’ or flow of events 一个时序图通常代表一个用例场景、事件流

描述用例场景（业务流程）必选，时序图/协作图 辅助

shows objects as lifelines running down the page, with their interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline

显示在当前页面的生命线，消息传递，从源到端

好处：
序列图是记录使用场景的一种极好的方法，可以在分析的早期捕获所需的对象，并在设计的后期验证对象的使用。从一个对象到另一个对象的消息流，因此对应于类/对象支持的方法和事件。

元素

主角
边界
业务实体
对象

示例

描述对象之间的交互顺序

描述用例的顺序图

消息可以是完整的，或者分段的

递归消息

MQ消息丢失与发现

del生命线

消息交叉

复杂机制，不推荐

• Alternative fragment (denoted “alt”) models if…then…else constructs.
• Option fragment (denoted “opt”) models switch constructs.
• Break fragment models an alternative sequence of events that is processed instead of the whole of the rest of the diagram.
• Parallel fragment (denoted “par”) models concurrent processing.
• Weak sequencing fragment (denoted “seq”) encloses a number of sequences for which all the messages must be processed in a preceding segment before the following segment can start, but which does not impose any sequencing within a segment on messages that don’t share a lifeline.
• Strict sequencing fragment (denoted “strict”) encloses a series of messages which must be processed in the given order.
• Negative fragment (denoted “neg”) encloses an invalid series of messages.
• Critical fragment encloses a critical section.
• Ignore fragment declares a message or message to be of no interest if it appears in the current context.
• Consider fragment is in effect the opposite of the ignore fragment: any message not included in the consider fragment should be ignored.
• Assertion fragment (denoted “assert”) designates that any sequence not shown as an operand of the assertion is invalid.
• Loop fragment encloses a series of messages which are repeated.

门面组件

对象内解构

状态延续

活动图 activity

定义

显示活动的顺序

完成一个目标需要做的活动、活动的执行顺序
可以跨用例、描述并发

活动图是状态图的一个变体

示例

完整

活动

行为

控制流

起始节点

终止节点1-单流程终止

终止节点2-全流程终止

对象与对象流

分支与合并节点

Decision nodes and merge nodes

分叉与连接节点

Forks and joins

中断活动区域

分区

描述购票：

主角（从用例图中获取）

基于用例图，描述用例的

时序/计时Timing

定义

显示状态在时间线上的改变

值生命线

并发多状态的

状态机图 State Machine

协作/通信/合作/图 comunication