需求获取–软件需求的初始表示
问题：我在总结这一小章节的时候，发现书上对于关联的描述的混乱（本人看不明白，需要大家帮帮忙）关于关联的方向中，通过关联的定义来归纳对于类图中类的关系之间的关系，在我看来关联只是关系中的一种，为什么可以通过关联的定义来归纳其他类的关系之间的互相关系呢？？？请大神指教~~谢谢
目标：完整的收集、整理利益相关方对目标软件系统的需求，并以容易理解的业务语言阐述这些需求，形成文档。
意义：需求获取是需求工程中的后续（分析、规范化等）活动的基础。需求获取对于软件项目的成败具有决定性影响。
输入制品：项目目标、范围及价值的概述性文档，项目合同或任务书，经过评审通过的本次需求工程迭代的工作计划
输出制品：描述软件需求的初步需求模型
用例图：
用例：一个用例代表着系统执行的一系列动作，动作执行的结果能被外部的执行者所察觉。
执行者：外部有用户或外部实体在系统的交互过程中扮演的角色
用例必备的特征：相对独立性、完整性
执行者与用例之间的关系：
表示：执行者与用例之间的㽑在用例图中表示为他们之间的连接边，其意义为执行者触发用例的执行，向用例提供信息或者从用例获取信息。
主动执行者：触发用例执行的执行者
被动执行者：仅仅从用例获取信息的执行者
注：执行者与用例之间一般使用无向边
使用有向边的情况：
- 多个执行者与用例相连时，为了强调其中某个执行者是该用例的主要执行者，则从该执行者到用例之间连接一条有向边。注：在有向边中，信息传递仍然可能是双向的。执行者需要提供初始信息来启动用例，用例的执行结果也可以反馈给执行者
- 为了强调被动执行者仅从用例获取信息，而不向用例提供信息，可以从用例到被动执行者之间连接一条有向边
用例之间的关系：
包含(include):若B是A的子功能，且建模者明确地知道A所对应的动作写中何时将调用B，则用例A包含用例B
扩展(extend)：若A与B相似，但是A的功能比B多，A的动作序列是通过在B的动作序列中的某些执行点上插入附加动作序列而构成的，则称用例A扩展用例B
继承(inheritance):若A与B相似，但A的动作序列是通过改写B的部分动作或者拓展B的部分动作而获得的，则称用例A继承用例B
注：
为了避免语义的复杂性，用例之间的关系不应该超过两层
每个执行者必须至少与一个用例相关联；反之，除了被包含、被扩展的用例外，每个用例必须至少与一个执行者相关联。
执行者之间的关系
继承（也只有继承一种）
布局规则
- 主要的执行者应该放置与用例图的左上方区域
- 触发用例执行的主动执行者应该位于用例的左面，接收用例产生的信息的被动执行者应该放置于用例的右面
- 多个用例垂直方向排列
- 在水平方向绘制包含关系，并将被包含的用例置于包含用例的右侧
- 在垂直方向绘制扩展和继承关系，并将扩展用例置于被扩展用例的下方，将继承用例置于被继承用例的下方。
用例表示
- 用例名称
- 用例的功能或其业务目标
- 与用例有关的执行者
- 用例执行的触发条件（可选）
- 用例执行的前置条件（可选）
- 基本交互动作过程
- 扩展交互动作过程（可选）
- 用例执行完毕时的后置条件（可选）
- 业务规则（可选）
- 非功能需求（可选）
用例的触发条件：激励用例开始执行的事件、动作或系统所处的状态
前置条件：用例在启动时参与该用例的执行者与目标软件系统应该处于何种状态
（前置条件和触发条件的联合语义：当触发事件或动作发生，或者当系统进入触发状态，并且前置条件成立则用例开始执行）
后置条件：用例执行完成之后目标软甲系统应该处于何种状态
基本交互动作过程：正常情况你想啊执行者与目标软件系统之间信息交互的内容及过程，包括系统每次响应执行者传入的信息是应该完成的功能或动作序列
扩展交互动作过程：特殊情况或异常情况下的信息交互及动作序列。
类图：
概念：面向对象软件系统的静态结构
节点：表示系统中的类及其属性和操作
边：表示类之间的关系
类型：需求模型、设计模型
类的属性在UML中表示为：[可见性] 名称[：类型] [多重性] [=初值] [{约束特性}]
类的操作在UML中表示为：[可见性] 名称 [（参数表）] [：返回类型] [{约束特性}]
注：在[ ]中的语法成分为可选项
类之间的关系（以及各个关系之间的关系）：
依赖
- 聚合
- 组合
继承
实现
关联的多重性：说明位于关联段的类可以有多少个实例对象与另一端的类的单个实例对象相联系，他表示参与关联的两个类的对象之间的数量对应关系。
关联的角色名：角色名描述参与关联的类的对象在关联关系汇总扮演的角色或发挥的作用
约束特性：说明针对参与关联的对象或对象集的逻辑约束
布局规则
- 尽量沿着垂直房昂想表示继承关系，沿着水平方向表示关联、聚合、组合、依赖、实现关系。在继承关系中，父类应位于子类的上方；在单向关联、依赖和实现关系中，方向尽量从左往右；在聚合和组合关系中，整体列一般位于部件类的左面
- 在关联边上，多重性、角色名和约束特性等应该靠近关联端
- 如果多条边表示相同的种类关系，他们有公共的类端点，并且在公共端的标注相同，则汇合这些边
活动图：
概念：描述实体为完成某项功能而执行的操作序列，其中的某些操作或者操作的子序列可以并发和同步。
活动图：
初始结点：通过一条简单的有向边指明进入活动图时首个被执行的活动
控制流：表示一个操作完成后对其后续操作的触发
信息流：刻画操作之间的信息交换
终止结点：表示整个活动图执行完毕
作用：精确的描述单个用例汇总的处理流程，也可以用来描述多个用例联合起来形成的处理流程，表达相对复杂的业务操作或者软件处理过程，可以给出针对类中的某个复杂的操作的实现细节、在设计和实现阶段精确的描述线程之间的并发
不足：在描绘对象之间的交互写作方面不如交互图、在描绘对象的行为方面不如状态图
结点类型：
- 活动：计算过程的抽象表示
- 决策点：判断该走的路径（可以看做if {…}else{…}）
- 并发控制：表示控制流经过此节点后分叉成多条可以并行执行的控制流，或者汇合成一条控制流，称为分叉和汇合
- 对象：表示活动需要输入的对象或者作为活动的处理结果输出的对象
边的类型：
- 控制流：连接在两个非对象结点之间的有向边，表示处理流程的顺序推进
- 对象流：从对象结点指向活动结点的有向边表示将对象作为输入数据传入接点；从活动结点指向对象结点的有向边表示对象是活动的输出数据
泳道机制：将活动图用形如泳道分割成数个活动分区，每个分区有一个对象或者一个控制线程负责。每个活动结点应该位于负责执行该活动的对象或线程所在的区域内。