目录
[6.1 需求分析-结构化需求分析(SA)](#6.1 需求分析-结构化需求分析(SA))
[6.2 数据流图（DFD）基本概念](#6.2 数据流图（DFD）基本概念)
[6.3 需求分析-SA-DFD](#6.3 需求分析-SA-DFD)
[6.4 数据流图平衡原则](#6.4 数据流图平衡原则)
[6.5 答题技巧](#6.5 答题技巧)
[6.6 需求分析-UML图](#6.6 需求分析-UML图)
[6.7 用例图](#6.7 用例图)
[6.8 类图与对象图](#6.8 类图与对象图)
[6.9 顺序图](#6.9 顺序图)
[6.10 通信图(协作图)](#6.10 通信图(协作图))
[6.11 状态图](#6.11 状态图)
[6.12 活动图](#6.12 活动图)
[6.13 定时图](#6.13 定时图)
[6.14 构件图与包图](#6.14 构件图与包图)
[6.15 部署图](#6.15 部署图)
[6.16 设计模式](#6.16 设计模式)
6.1 需求分析-结构化需求分析(SA)
6.2 数据流图（DFD）基本概念
2014.11案例分析题
在结构化分析方法中，数据流图是描述系统逻辑模型的主要工具。
数据流图由四个部分组成：
①数据流：数据在系统内部或外部实体与处理过程之间移动的路径，表示数据的动态传递。如：订单信息。
②加工/处理：对输入数据进行转换或计算的功能模块，代表系统对数据的逻辑操作。如：订单处理（包括验证、计算、生成订单号等操作）。
③数据存储：系统内部用于保存数据的静态区域，代表数据的持久化存储。如：订单表(存储订单详情）。
④外部项：代表与系统交互的外部来源或目标。它们是数据的起点或终点，但本身不属于系统内部。如：客户。
**++判定树和判定表的核心作用是清晰地表达数据流图加工的复杂条件判断和决策逻辑，++**当一个加工的处理过程依赖于多种条件的复杂组合时，用自然语言描述会显得冗长且不清晰。
6.3 需求分析-SA-DFD
6.4 数据流图平衡原则
++层间平衡：数据流个数一致，方向一致
图内平衡：有输入无输出的黑洞，有输出无输入的奇迹，输入不足的灰洞++
父图与子图之间的平衡
子图内平衡
异常现象
黑洞：一个加工只有输入数据流而无输出数据流。
奇迹：一个加工只有输出数据流而无输入数据流。
灰洞：若一个加工的输入数据流无法通过加工产生输出流。
6.5 答题技巧
一、补充实体
实体可能是:
(1)人物角色：如客户、管理员、主管、经理、老师、学生
(2)组织机构：如银行、供应商、募捐机构
(3)外部系统：如银行系统、工资系统、后台数据库(当要开发的是中间件时)
二、补充存储
"**文件" "**表" "**清单" "**档案
三、补充数据流
1、数据平衡原则
(1)顶层图与0层图对比，是否有顶层图有，但0层图无的数据流，或反之。
(2)检查图中每个加工，是否存在只有入没有出，或只有出没有入，或根据输入的数据无法产生对应的输出的情况。
2、按题目说明与图进行匹配
说明中的每一句话，都能与图中有对应关系，当把说明中的实体与数据流标识出来之后，容易缩小对应范围，找出纰漏。
四、补充加工名
加工是用于处理数据流的，所以要补充加工名，可以把该加工涉及到的数据流，在说明中标识出来，再在数据流名称所在的句子中，找"动词+名词"的结构，分析是否可作为加工。
"动词+名词"如：生成报告、发出通知、批改作业、记录分数，当然这只是普遍情况，也有例外，如物流跟踪、用户管理。
6.6 需求分析-UML图
面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型 构成；设计模型则包含以包图 表示的软件体系结构图、以交互图表示的用例实现图 、完整精确的类图、针对复杂对象的状态图 和用以描述流程化处理过程的活动图等。
6.7 用例图
ü用例图描述一组用例、参与者及它们之间的关系。
ü用户角度描述系统功能;
ü参与者是外部触发因素;(包括用户、组织、外部系统，时间，温度湿度，传感器)
ü用例是功能单元。
关系包括:
++包含关系、扩展关系、泛化关系++
用例建模的流程:
u识别参与者(必须)
u合并需求获得用例(必须)
u细化用例描述(必须)
u调整用例模型(可选)
用例建模的主要工作是书写用例规约。用例规约通常包括下面的内容：
用例名称、简要说明、事件流、非功能需求、前置条件、后置条件、扩展点、优先级。
包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
6.8 类图与对象图
类图(class diagram)：类图描述一组类、接口、协作和它们之间的关系。
对象图(object diagram)：对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。表示在某一时刻一组对象及其之间的关系，可以看作是类图在系统某一时刻的实例。
类图在系统的整个生命周期都是有效的，对象图只在系统的某一时间段存在。
u类名，方法名，属性名
u多重度
u关系
ü依赖关系：一个事物发生变化影响另一个事物。
ü泛化关系：特殊/一般关系，子类继承父类。
ü关联关系：描述了一组链，链是对象之间的连接。
*聚合关系：整体与部分生命周期不同。（汽车和轮子的关系）
*组合关系：整体与部分生命周期相同。（公司和部门的关系）
ü实现关系：接口与类之间的关系。
识别设计类是面向对象设计过程中的重要工作，设计类表达了类的职责，即该类所担任的任务。设计类通常分为三种类型，每种类型的主要职责如下，
(1)实体类。实体类映射需求中的每个实体，保存需要存储在永久存储体中的信息，例如，用户、商品等。
(2)控制类。控制类是用于控制用例工作的类，用于对一个或几个用例所特有的控制行为进行建模。例如，结算、备货等。
(3)边界类。边界类用于封装在用例内、外流动的信息或数据流。例如，浏览器、购物车等。
6.9 顺序图
顺序图(sequence diagram，序列图)。顺序图是一种交互图(interaction diagram)，它强调对象之间消息发送的顺序，同时显示对象之间的交互。
顺序图中的消息类型包括:++同步消息(Synchronous Message)、异步消息(Asynchronous Message)、返回消息(Return Message)++ 和**++自关联消息(Self-Message)++**。
顺序图中元素：
(1)对象(Object)，对象是系统中具有特定职责和行为的实体。
(2)生命线(Lifeline），生命线表示对象在交互过程中存在的时间线。
(3)激活(Activation)/控制焦点(Focusof Control)，激活表示对象正在执行某个动作或处于活动状态的时间段。
(4)消息(Message)，消息是对象之间传递的信息，用于触发接收对象的动作或状态变化。
(5)交互片段(Interaction Fragment)，交互片段用于表示顺序图中的一组特殊交互，如循环、条件分支等。
6.10 通信图(协作图)
通信图(communication diagram)。通信图也是一种交互图 ，它强调对象之间存在的消息收发关系，而不专门突出这些消息发送的时间顺序。
6.11 状态图
状态图(state diagram)是对类描述的补充。用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。
6.12 活动图
活动图(activity diagram)是一种特殊的状态图。活动图描述一个操作中要进行的各项活动的执行流程。同时，也常被用来描述一个用例的处理流程或者某种交互流程。
活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。它强调对象间的控制流程。
**++分叉++**是用于将一个控制流分为两个或多个并发运行的分支，它可以用来描述并发线程。如，到达火车站这个活动就可以分为"行李安检"与"车票检查"两个分叉活动。
**++分支++**可以进行简单的真/假测试，并根据测试条件使用转移到达不同的活动或状态。在活动图中可以使用判断来实现控制流的分支。如，根据"用户权限"决定显示"管理员界面"或"普通用户界面"。
泳道式活动图：
在面向对象的设计过程中，活动图(activity diagram)阐明了业务用例实现的工作流程。活动图与流程图(flow chart)的三个主要区别：
(1)活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现系统的行为，而非处理过程;而流程图着重描述处理过程。
(2)流程图一般都限于顺序进程，而活动图则可以支持并发进程。
(3)活动图是面向对象的，而流程图是面向过程的。
在活动图中需要注意区分**++活动状态++** 和**++动作状态++**。
++动作状态是原子的，不能被分解，没有内部转移，没有内部活动++。
动作状态占用的时间是可以忽略的，动作状态的目的是执行进入动作，然后转向另一个状态。++活动状态是可以分解的，不是原子的，其完成工作需要一定的时间++。
6.13 定时图
定时图也叫计时图，也是一种交互图，用于展示交互过程中的真实时间信息，具体描述对象状态变化的时间点以及维持特定状态的时间段。
6.14 构件图与包图
构件图(component diagram)。构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
包的图标像是一个带标签的文件夹，包的基本思想是把共同工作的元素放到一个文件包图，夹中。例:多个类或构件组成了一个子系统，就可以将它们放到一个包中。
6.15 部署图
部署图(deployment diagram)。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
6.16 设计模式
设计模式主要用于得到简洁灵活的系统设计，GoF的书中共有23个设计模式，这些模式可以按两个准则来分类；一是按设计模式的目的划分 ，可分为创建型、结构型和行为型 三种模式；二是按设计模式的范围划分 ，即根据设计模式是作用于类还是作用于对象来划分，可以把设计模式分为类设计模式 和对象设计模式。
设计模式按照其应用模式可以分为三类：创建型、结构型和行为型，三者的作用如下，
创建型模式主要用于创建对象，为设计类实例化新对象提供指南。
结构型模式主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。
行为型模式主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。
设计模式分类，
创建型模式：构造器模式、原型模式。
结构型模式：适配器模式、外观模式、代理模式。
行为型模式：命令模式、中介模式、状态模式和策略模式。
|-------|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
| 创建型模式 | 用于创建对象 | 工厂方法模式、抽象工厂模式、单例模式(Singleton)、建造者模式(Builder)、原型模式(Prototype)。共五种。 口诀：单抽元件（建）厂 |
| 结构型模式 | 处理类或对象的组合 | 适配器模式(Adapter)、装饰器模式、代理模式（Proxy）、外观模式(Facade)、桥接模式(Bridge)、组合模式、享元模式。共七种。 口诀：外侨（桥）组员（元）戴（代）配饰。 |
| 行为型模式 | 描述类与对象怎样交互、怎样分配职责 | 策略模式、模板方法模式、观察者模式、迭代子模式、 责任链模式、命令模式(Command)、备忘录模式(Memento)、状态模式(State)、访问者模式(Visitor)、中介者模式（Mediator）、解释器模式。共十一种。 口诀：观摩（模）对（迭）策，责令解放（访），戒（介） 忘台（态）。 |
创建型模式是对对象实例化过程的抽象。例如Singleton模式确保一个类只有一个实例，并提供了全局访问入口；Prototype模式允许对象在不了解要创建对象的确切类以及如何创建等细节的情况下创建自定义对象；Builder模式将复杂对象的构建与其表示分离。