技术谈系统建模.pdfVIP

系统建模简介

建模定义

简单说来，建模是对现实的简化抽象，不过如此。它并不意味着要用特定的符

号、工具和流程。我们只是想研究复杂的东西，让其中的一些部分易于理解。

正如他们所说，有时候你是见木不见林。不必要的细节反而会让情况更加难以

理解。最好还是隐藏那些不必要的细节，只专注于具体情况的重要方面。所以

不管你用什么建模工具，什么Notation表示法，只要有助于的问题域的理解

都是好的模型。

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

1）一图胜千言，方便理解和沟通。

2）模型在软件工程各个阶段都发挥着重要作用，从需求分析时的用例图和概

念领域模型（Conceptualdomainmodel)，到开发阶段的类图，活动图，架构

图，到上线的部署图，建模无处不在。

3）人类一开始是没有文字的，所以人类处理图像的进程比语言快60000倍，我

们回忆起类的信息要比文字类信息容易6倍。

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

1）软件建模，尽量使用通用的notation，如果你在流程图中用菱形表示处理

而不是分支，就会让人困惑。

2）用不同的形状和颜色来区分不同的功能，领域，层次等，想想思维导图的工

作原理。

3）注意图形在画面中的布局和颜色搭配，图表的颜值很重要。

4）使用UML但不要，我们的重点是交付软件，而不是模型，所以不建不必

要的模型，不不重要的模型，轻装上阵，保持敏捷。

5）仅仅使用UML是不够的，例如在设计UI时，使用UI流程图（User

InterfaceFlowDiagram)是比较合适的。

6）对于非UML图，要特别注意图形中的箭头，要保持箭头在整个图表中语义的

一致性，一般来说，箭头可以用来表示数据流向、服务调用、提供支撑等。

7）敏捷建模和敏捷开发的思想一致，建模过程不应该是自顶向下的瀑布式的，

坚持拥抱变化，坚持团队协助（collaborative），保持快速反馈，不断

的演化、迭代的过程。

UML建模

如上文所述，UML不是软件建模的必须，但是通用的UML图形表示法，能够减

少沟通成本。1997年，OMG组织（ObjectManagementGroup对象管理组织）

发布了统模语言（UnifiedModelingLanguage，UML）。UML的目标之一

就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出

了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人

员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设

计图一样。

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

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

绍。

结构型图形

类图

类图是UML中我们使用最多的图形，是面向对象和领域建模的不二之选，因

为其在领域建模中重要性，我会着重介绍下类图。类图的关系类型包括关联，

泛化，实现，其中关联又可细分为普通关联，组合聚合，依赖，平时我们比较

容易的是关联关系，下面重点介绍下不同的关联关系。

关联关系

表示类和类之间是有关联的，有关系的，可以是单向的，也可以是双向的。关

系的表示上可以用multiplicitylabel和role进行辅助描述，选择合适的

label很重要确保可以顺畅的描述关系。如果发现label不能通顺描述关系，

就要思考是不是label描述有问题或是关系本身就有问题，要及时纠正。

一个范例：

1）一个老师可以教零到多门课程

2）一个课程只能被一个老师教授

组合和聚合关系

组合、聚合是强关联关系，隐含了整体和部分的关系。

聚合(Aggregation）：空心菱形，聚合是整体和部分的关联关系，通常可以用

“hasa”来描述关系。

组合（Compostion）：实心菱形，组合是增强型的聚合关系，除了具备“has

a”关系，还包含着部分脱离整体就没有意义的语义。

两者的却别主要体现在语义上，在coding层面，基本是一样的，没有任何差

别，都是一个类以list成员变量的形式存在于另一个类中。所以如果很难区分

聚合和组合，也不用太纠结，随他去吧。

CraigLarmansaysitbest:Ifindoubt,l