系统建模

最新推荐文章于 2024-06-17 12:45:58 发布

原创最新推荐文章于 2024-06-17 12:45:58 发布 · 2.3k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#数据库建模 #数据库

系统架构同时被 2 个专栏收录

33 篇文章

订阅专栏

系统建模

5 篇文章

订阅专栏

结构化系统建模

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)