结构化系统建模
1.数据流图 DFD(Data Flow Diagram)
数据流图由数据流（data flow），加工（process），文件（data store），源 / 宿（Source / Sink）四部分组成。
- 数据流是有一组固定成分的数据组成，表示数据的流向，用箭头表示。它可以从源、文件流向加工，也可以从加工流向文件和宿，还可以从一个加工流向另一个加工。
- 加工描述了输入数据留到输出数据了之间的变换，也就是输入数据流做了什么处理后变成了输出数据流，用圆或椭圆表示。每个加工有一个名字和一个编号。
- 源/宿中，源是指系统所需数据的发源地，宿是指系统所产生的数据的归宿地，用方框表示。源或宿均对应于外部实体。
- 数据的存储用双杠表示。
实例：
Level-0 Diagram:
Level-1 Diagram:
数据流图约束：
加工（Process）：
- 加工必须有数据流入，否则你加工的数据从何而来，在流图中，只有输出的对象是源（Source）
- 加工必须有数据流出，否则会产生数据黑洞（black hole). 在流图中，只有输入的对象是宿（Sink）
- 加工是一个动作，里面含有动词
文件（Data Store）：
- 数据不能从一个文件直接流向另一个文件，必须通过加工处理
- 数据不能从源（Source）直接流向文件，likewise，数据不能冲文件直接流向宿（Sink）
- 文件是名词表达式。
源 / 宿 （Source/Sink):
- 数据不能从源直接流向宿，必须通过加工处理。
- 源/宿 是外部实体，是名词。
数据流 （Data Flow）：
- 数据流不能直接回到其刚离开的加工。
- 数据流进入数据存储（Data Store）意味着Create/Update
- 数据流离开数据存储意味着Retrive
- 数据流是内部实体，也是名词。
判定表
对于复杂逻辑可以使用判定表（Decision Table）。
定表通常有以下四个部分组成：
1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
实例：
实体联系图ER
（Entity-Relationship）
对于DFD中名词，也就是实体，描述这些实体之间的关系用ER图，其实ER图和UML的概念类图（Conceptual / domain class diagram)有很多相似之处。
流程图（Flow Chart）
A flowchart is a type of diagram thatrepresents an algorithmor process, showing the steps as boxes of various kinds, and their order by connecting these with arrows.
ž Oval(椭圆形) – Start and end Symbols
ž Rectangles(矩形) – Generic processing steps
ž Diamonds – Conditional or decision
ž Parallelogram(平行四边形) – 输入输出 input/output
实例：
面向对象系统建模
需求建模( Modeling Requirements) - Use case View
可以为用户需求创建多种不同的视图。 每个视图都提供特定类型的信息。 当您创建这些视图时，最好经常在各个视图之间进行切换。 创建时，可以从任何视图开始。
|
关系图或文档 |
需求模型中描述的内容 |
节 |
|---|---|---|
|
用例图 |
谁使用系统以及使用系统执行什么操作。 |
描述系统的使用方式 |
|
概念类图 |
用于描述需求的类型的术语表；可在系统界面看到的类型。 |
定义用于描述需求的术语 |
|
活动图 |
由用户与系统或其部件执行的活动之间的工作流和信息。 |
显示用户和系统之间的工作流 |
|
序列图 |
用户与系统或其部件之间的交互的序列。 活动图的替代视图。 |
显示用户和系统之间的交互 |
|
附加文档或工作项 |
性能、安全性、可用性和可靠性条件。 |
描述服务质量要求 |
|
附加文档或工作项 |
非特定于具体用例的约束和规则 |
显示业务规则 |
当用于此目的时，UML 类图的内容称为“概念类图“，也称为域模型（Domain Model）
用例图
用例之间的关系：
- 泛化Generalization
- 包含Include : 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。指向分解出来的功能用例
- 扩展extend：扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。指向基础用例
包含(include)、扩展(extend)、泛化(Inheritance) 的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
逻辑建模 （Modeling a System's Logical Structure）- Logical View
Class Diagram,Sequence Diagram, State machine Diagram
层关系图可直观显示系统的高级逻辑架构：http://technet.microsoft.com/zh-cn/dd409462(v=vs.89)
一个Web应用的4层关系图：
业务流程建模 （Modeling System Workflows）- Process View
活动图（Activity Diagram）
何时使用活动图
- 描述用户和您的系统之间的业务流程或工作流。 有关更多信息，请参见 用户需求建模 。
- 描述某一用例中执行的步骤。 有关更多信息，请参见 UML
用例图：准则 。 - 描述软件中的方法、函数或操作。 有关更多信息，请参见 建立软件系统体系结构模型 。
活动图中的主要元素
- 活动（Activity）：如果活动只包含一个动作，则此活动（Activity）是动作（Action）
例如“付款”这个活动，可能包含“检验账号余款”，“选择付款方式”，“确认付款”等动作。 - 泳道（swimlane）：根据每个活动的职责对所有活动进行划分。
- 对象流：类似于DFD中数据流，只不过在OO中Entity叫对象。
- 分支与合并（Decision and Merge Nodes)
- 分叉与汇合（Folk and Join Nodes)
案例
Reference:
1. 如何在Visio中画活动图：http://technet.microsoft.com/zh-cn/dd409465(v=vs.89)
2. http://www.cnblogs.com/ywqu/archive/2009/12/14/1624082.html
构建和部署 - Deployment View
Component, Package, Deployment Diagrams
数据库建模
数据库基础知识
超键（Super Key）：能唯一确定一组属性
候选键（Candidate Key）：最小属性集的超键，减少一个属性，其就不是超键了，但增加一个属性，其任然是超键，但不是候选键。
主键（Primary Key）：从候选键中选择一个即为主键。
子键（Subkey）：Super key函数确定关系中所有属性，这是好的函数依赖（FD），但如果有这样的FD，其只能函数确定关系中部分属性，而不是全部属性，那么次局部Super key就是subkey。
如何消除子键（http://www.tomjewett.com/dbdesign/dbdesign.php?page=subkeys.php）
无损连接分解（lossless join decomposition）
1. 把所有函数依赖子键的属性移到一个新表
2. 将子键复制到新表中，并将其标识为新表中得主键。
3. 在老表中保留子键作为新表的外键（Foreign key），此时老表和新表满足many-to-one的关系
数据库规范化（Normalization）
当数据库中得所有表都没有子键，那么此数据库将满足3NF的要求。
部分函数依赖：此时的subkey 是 primary key的一部分。
传递函数依赖：此时的subkey 不是 primary key的一部分。
数据库设计步骤
- 需求分析：形成DFD
- 概念结构分析：E-R图
- 逻辑结构设计：将E-R图转换为指定的数据模型，数据库规范化，确定完整性约束，确定用户试图。
- 物理结构设计：结合DBMS，优化存储结构和数据存储路径
- 应用程序设计