建模定义

简单说来，建模是对现实的简化抽象，不过如此。它并不意味着要用特定的符号、工具和流程。我们只是想研究复杂的东西，让其中的一些部分易于理解。正如他们所说，有时候你是见木不见林。不必要的细节反而会让情况更加难以理解。最好还是隐藏那些不必要的细节，只专注于具体情况的重要方面。所以不管你用什么建模工具，什么Notation表示法，只要有助于的问题域的理解都是好的模型。

为什么要建（画）模（图）

1）一图胜千言，方便理解和沟通。
2）模型在软件工程各个阶段都发挥着重要作用，从需求分析时的用例图和概念领域模型（Conceptualdomain model)，到开发阶段的类图，活动图，架构图，到上线的部署图，建模无处不在。
3）人类一开始是没有文字的，所以人类处理图像的进程比语言快60000倍，我们回忆起图片类的信息要比文字类信息容易6倍。

建（画）模（图）时需要注意些什么

1）软件建模，尽量使用通用的notation，如果你在流程图中用菱形表示处理而不是分支，就会让人困惑。
2）用不同的形状和颜色来区分不同的功能，领域，层次等，想想思维导图的工作原理。
3）注意图形在画面中的布局和颜色搭配，图表的颜值很重要。
4）使用UML但不要迷信，我们的重点是交付软件，而不是模型，所以不建不必要的模型，不维护不重要的模型，轻装上阵，保持敏捷。
5）仅仅使用UML是不够的，例如在设计UI时，使用UI流程图（User Interface Flow Diagram)是比较合适的。
6）对于非UML图，要特别注意图形中的箭头，要保持箭头在整个图表中语义的一致性，一般来说，箭头可以用来表示数据流向、服务调用、提供支撑等。
7）敏捷建模和敏捷开发的思想一致，建模过程不应该是自顶向下的瀑布式的，而是要坚持拥抱变化，坚持团队协助（collaborative），保持快速反馈，不断的演化、迭代的过程。

UML建模

如上文所述，UML不是软件建模的必须，但是通用的UML图形表示法，能够减少沟通成本。1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划–就像建筑工人多年来所使用的建筑设计图一样。

UML分为结构型和行为型建模图形，其分类如下图所示：

UML包含12种图形，但我们经常用到的不过5种左右，下面分别做下简单介绍。

结构型图形

类图

类图是UML中我们使用最多的图形，在面向对象和领域建模的不二之选，其关系类型包括关联，泛化，实现，其中关联又可细分为普通关联，组合聚合，依赖，平时我们比较容易混淆的是关联关系，下面着重介绍下不同的关联关系。

关联关系

表示类和类之间是有关联的，有关系的，可以是单向的，也可以是双向的。关系的表示上可以用multiplicitylabel 和 role进行辅助描述，选择合适的label很重要确保可以顺畅的描述关系。

一个范例：

1）一个老师可以教零到多门课程
2）一个课程只能被一个老师教授

组合和聚合关系

组合、聚合是强关联关系，隐含了整体和部分的关系。
聚合(Aggregation）：空心菱形，聚合是整体和部分的关联关系，通常可以用“has a”来描述关系。
组合（Compostion）：实心菱形，组合是增强型的聚合关系，除了具备“has a”关系，还包含着部分脱离整体就没有意义的语义。

两者的却别主要体现在语义上，在coding层面，基本是一样的，没有任何差别，都是一个类以list成员变量的形式存在于另一个类中。所以如果很难区分聚合和组合，也不用太纠结，随他去吧。

Craig Larmansays it best: If in doubt, leave it out.

一个范例：

1）组合：一所大学是有多个学院组成的，学院不可以脱离学校独立存在。
2）聚合：学院里会有很多教授，即使学院没有了，教授仍然可以独立存在。

依赖关系

类和类之间最弱的联结关系，依赖总是单向的，语言中体现为局部变量、方法的参数或者对静态方法的调用。

一个范例：

行为型图形

用例图

用例图试图描概括了用例中角色和系统之间的关系，描述了系统功能需求，角色和系统的交互以及系统的反应。是客户和开发人员全貌理解项目需求功能比较好的一个方式，也是后续功能迭代的依据和方向。

一个范例：

活动图

活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。活动图能够表示并发活动的情形，活动图是面向对象的。

活动图和流程图主要区别：
1）活动图与流程图类似，活动图的元素更丰富，支持并行活动、事件等。
2）活动图是面向对象的，而流程图是面向过程的。

一个范例：

状态图

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

简单示例：

1）简单状态

2）带内部活动的状态：

标识内部状态的标签有些是被保留的，这些标签是：
entry/ (behavior performed upon entry to the state)
do/ (ongoing behavior, performed as long as the element is in the state)
exit/ (behavior performed upon exit from the state)

3）带有子状态的复合状态：

顺序图

序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。

顺序图大家使用的也比较多，详细资料网上也有很多，这里重点给出两种用的不是很多的表示法。示例来自网络文档。

1）调用自身对象的序列图

2）用序列图表示if else逻辑，alt表示Alternatives

OK，UML就介绍这么多，下面我们来结合一个保障平台真实项目，来看一下系统建模的最核心部分，领域建模和数据建模的实战过程。

领域建模+数据建模

领域建模（及后续的数据建模）是我们日常业务开发中的核心的核心，一个抽象合理，关系清晰，可扩展性好的领域模型，基本已经是我们项目成功的一半了，当然，这个建模的过程也是不容易的，需要很好的业务理解力和抽象能力。所以公司的能力矩阵，很强调业务理解力和抽象能力，意义就在这，因为这是业务架构师和优秀工程师需要具备的能力。
还好，这个领域建模的过程也是有一套方法学的，而且这个过程和我们的敏捷开发一样，是开放的，拥抱变化的，不断迭代调整的过程。

领域建模过程

简单来说，这个敏捷建模过程无外乎下面四步：
1）获取用户需求，和stakeholders一起编写用户故事。
2）重点关注用户故事中的名词，建立领域词汇表（Domain vocabulary），对领域概念进行抽象，建立领域模型。
3）对领域模型进行细化，建立数据库表结构（Physical DataModel）。
4）根据对需求理解的深入或调整，迭代重复前面三步。

关于更多敏捷数据建模的知识，强力建议阅读http://agiledata.org/essays/agileDataModeling.html

保障平台建模实战

这是一个保障平台项目真实实战过程，业务方的需求是建设一个以保证金抵押方式给客户提供保障的系统。其建模过程如下所述：
1）用户故事，因为篇幅的缘故，这里没有列出所有的User Stories。

2）领域词汇表
保证金（fund）：用户在保障平台的资金，资金来源渠道有自缴、保险、授信等。
资金组（fund group）：资金组由一个或多个渠道的保证金组成，一个服务占用的资金来自于一个资金组，一个资金组可以用来开通多个服务。
充值（deposit)：用户充值，增加其在平台的保证金。
转出（withdraw）：用户转出，减少用户在平台的保证金。
占用（occupy）：保证金额度不变，可用保证金变少。
释放（release）：保证金额度不变，可用保证金变多。
赔付（payout）：平台使用用户保证金进行赔付，保证金减少。

3）领域模型
在UML介绍部分阐述过了，领域建模采用UML类图表示法是比较通用的做法。在本项目中，用类图建立的领域模型如下：

4）有了领域模型之后，进行简单的细化，就可以翻译成数据库模型了（PDM）
详细的PDM就不给出了，只给出资金占用部分的。

更多关于如何从领域模型到数据库表结构转换的方法，请参考http://www.tomjewett.com/dbdesign/dbdesign.php

优秀图形展播

正如开篇对建模的定义，建模不需要特定的工具和表示法，要做到能够把复杂的概念，通过自己的理解、消化、抽象，并用通俗易懂的图形表型出来，这不仅需要长时间经验的积累，还需要独具创新的构思和创意。下面是一些我日常收集的感觉画的不错和有创意的图。

交易转化率图

虚线表示不同阶段跳出（终止交易），亮点是巧妙的用线条的粗细来表示traffic的大小，很形象。

就医O2O图

这张关于O2O的图非常好，line上面的是online，下面的是offline，简洁明了。

参考资料：

http://www.agilemodeling.com/essays/umlDiagrams.htm
https://www.visual-paradigm.com/VPGallery/diagrams/Activity.html
https://www.uml-diagrams.org/state-machine-diagrams.html
http://agiledata.org/essays/agileDataModeling.html
http://www.tomjewett.com/dbdesign/dbdesign.php

【UML】聊聊系统建模相关推荐

使用 UML进行系统建模实验报告[图书管理系统]
一．实验目的针对指定软件系统的需求进行分析和设计: 使用Microsoft Visio软件,绘制 UML 图. 二．实验设备计算机.Microsoft Visio软件. 三．实验内容及步骤 1.介 ...
跟我学 UML 系统建模
UML 系统建模 1 概述 1.1 课程概述汇集 UML 及其相关的一些话题回顾 UML 相关的符号与概念以电商订单相关业务为例,借助 UML 完成系统建模将 UML 变成提升建模效率,表达架 ...
想学设计模式、想搞架构设计，先学学 UML 系统建模吧
UML 系统建模 1 概述 1.1 课程概述汇集 UML 及其相关的一些话题回顾 UML 相关的符号与概念以电商订单相关业务为例,借助 UML 完成系统建模将 UML 变成提升建模效率,表达架 ...
VP-UML系统建模工具研究
一.基本信息标题:VP-UML系统建模工具研究时间:2014 出版源:软件工程师领域分类:面向对象:CASE:UML:系统建模: 二.研究背景问题定义:VP-UML系统建模的主要特点难点:运 ...
《大象 ---Thinking in UML》
内容前言: 本书以UML为载体,将面向对象的分析设计思想巧妙地融入建模过程中,通过贯穿全书的实例将软件系统开发过程中方方面面的知识有机地结合在一起,用生动的语言和精彩的事例将复杂枯 ...
UML对基于B/S模式的图书管理系统的分析与设计
[导读]对基于B/S模式下的图书管理系统进行分析,运用UML的静态和动态模型图,对系统的分析结果进行可视化建模,并对系统模型图进行概括性论证. 1 前言使用计算机软件对图书进行管理,是计算机应用的一 ...
构建面向对象的应用软件系统框架
l 转自:http://www.lvjiyong.com/books/OODesigner/ 孙亚民目录第一部分综述 4 第1章本书会讨论什么内容 5 第2章系统的分层结构 ...
二、全国计算机三级数据库考试——理论知识总结（填空题）
上一篇博客:一.全国计算机三级数据库考试--理论知识总结(选择题)_简时刻的博客-CSDN博客说明:红色字为三级数据库考试中需要输入的答案,填空题在考试中一共15道题,一题2分,一共30分. IDE ...
数据库学习：数据模型
前言数据建模就是通过减低数据库设计的复杂度得到各个方面都能理解的数据抽象,包括定义实以及它们之间的关系.接下来学习数据建模的基本概念以及数据模型的发展过程. 正题在开始编写文章前,有几个问题需要思 ...
2022年计算机软件水平考试信息系统项目管理（高级）练习题及答案
2022年计算机软件水平考试信息系统项目管理(高级)练习题及答案,根据最新计算机软件水平考试信息系统项目管理(高级)大纲与历年计算机软件水平考试信息系统项目管理(高级)真题汇总编写,包含计算机软件水平 ...

【UML】聊聊系统建模

建模定义

为什么要建（画）模（图）

建（画）模（图）时需要注意些什么

UML建模

结构型图形

类图

关联关系

一个范例：

组合和聚合关系

一个范例：

依赖关系

一个范例：

行为型图形

用例图

一个范例：

活动图

一个范例：

状态图

顺序图

领域建模+数据建模

领域建模过程

保障平台建模实战

优秀图形展播

就医O2O图

参考资料：

【UML】聊聊系统建模相关推荐

最新文章

热门文章

【UML】聊聊系统建模

​建模定义

为什么要建（画）模（图）

建（画）模（图）时需要注意些什么

UML建模

结构型图形

类图

关联关系

一个范例：

组合和聚合关系

一个范例：

依赖关系

一个范例：

行为型图形

用例图

一个范例：

活动图

一个范例：

状态图

顺序图

领域建模+数据建模

领域建模过程

保障平台建模实战

优秀图形展播

就医O2O图

参考资料：

【UML】聊聊系统建模相关推荐

最新文章

热门文章

建模定义