在学习UML建模的时候，我们还需要思考一个软件模型从0->1这样一个诞生的过程需要经过什么，为什么模型需要这样建，为什么要这样输出?建模的目的是帮助我们更好的理解面向对象的软件开发和对软件系统的整体有更深入和清晰的理解。

模型是论点，静态图是论据，动态图是论证。建立什么模型，首先要先确定的是该项目该项目要采用什么样的生命周期。

今天要整理的是模型相关的知识,主要包括以下:

用例模型，是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约，是需求工作流程的结果，可当作设计工作流程和测试工作流程的输入使用。

之前关于用例我们有三个层次的解释，关于用例模型同样有三个不同的对应的区分:业务用例、概念用例、系统用例。

统一过程是一种演进式的软件过程，在整个产品生命周期之内充满了许多小规模的迭代，而每一次迭代的开始几乎都是从识别用例开始，从用例被实现而结束。

以上的三种用例模式分别是用于在软件开发的不同周期阶段发生作用的，业务用例模式用于识别和规定业务需求，概念模型用于分析和确认业务需求，而系统用例模式用来规定系统开发需求。这三者之间是渐渐精化的关系。

一、业务用例模型

业务用例模型位于统一过程的先启阶段，在业务建模的核心工作流中完成。需要明确一点，业务模型是业务范围，建立的目的是为现存的业务和客户预想中的真实业务建立模型，是为了理解客户的业务，不能带有计算机思考在里面。业务用例模型采用业务用例来绘制，表达业务的观点。

业务用例场景:说明用例执行的过程。
业务用例规约: 说明用例的使用者、目标、场景、相关业务规则、业务实体等。
业务用例规则: 说明客户执行业务用例必须遵循的法律、惯例、规定。
业务对象模型: 描述业务模型中关键的业务对象，以及如何贡献于业务目标。
业务对象实现视图: 将业务用例实现用实现关系连接到业务用例，每一个业务用例代表了业务用例目标的一种实现方式。
实现场景: 说明每一个业务用例实现的步骤。

二、概念用例模型

概念用例模式也位于先启阶段，是业务用例建模的一个子集。在统一过程中，没有强调概念用例的建立，一般来说业务用例的粒度很大，描述时很粗略，而系统用例需要使用软件开发的需要，所以会比较精细，而概念模型的建立是居于两者之间的一个过渡。我们使用它来分解业务复杂的业务模型。

概念用例视图: 该视图得到的概念用例用包含、泛化、拓展关系连接到基本业务用例。表示这些来源以及他们服务于哪个或者哪些业务用例。
概念用例分析: 从模型中选出重要的业务用例场景集中起来，进行分析如何实现。
分析类视图: 分析类视图绘制出从概念用例分析过程中抽象出来的分析类的静态关系。
分析场景: 使用分析类绘制对象交互图，从对象的角度去实现概念用例分析场景。

获取概念用例:

可以观察现有的业务场景，发现那些经常出现的名称，可能就是关键的概念用例。

什么时候使用概念用例模型呢？一般来说，面临的软件规模很庞大，复杂，有7-8个泳道存在，或者说你想早点获得系统原型，可以建立概念模型。如果业务领域规模很小，业务用例粒度较小，简单，就不比使用概念模型了。

三、系统用例模型

系统用例模型用于统一过程中先启阶段的后期以及精化阶段的早期。实际上，系统建模就是我们说的需求获取。也可以直接省略系统，叫用例模型这说法了。

用例规约：用例规约应采用文档形式描述参与者如何启动和终止用例，参与者如何使用用例完成目标，用例的执行事件流，相应的规则等内容。
补充规约:补充规约应说明与用例相关的非功能性需求。例如响应时间、可靠性、可用性。
业务规则、用例实现、用例场景、分析对象跟以上的内容差不多。

如何获取系统用例呢？

如果建立系统用例时，已经存在业务用例了，可以从业务用例中推导出来。因为推导系统用例的方法是分析业务用例场景，尤其是活动图。因为采用活动图绘制业务用例场景时将业务主角和业务工人作为泳道，因此特别方便观察他们的职责（活动）。系统用例可以从这些职责里抽取出来。 一 开始，可以简单地把每个泳道中的活动都作为一 个用例，以泳道作为参与者，把它们绘制出来。然后考虑以下问题：

在观察一些用例时，如果参与者不使用计算机来使用这个用例，则可以排除。还有如果使用计算机实现代价很大，可以考虑排除。

观察剩下的候选用例，分析参与者使用它们的目的。目的通常可以从参与者关心的结果看出来。虽然候选用例可能有不同的名字，但是如果它们的结果是相同的或相似的，应当考虑合并。

例如虽然审批A文件、审查B文件是两个不同的候选用例，但是它们的结果都导致某业务得到批准，那么可以考虑合并为一 个审查文件用例。合井后，审批 A 文件和审查 B 文件是括曆 件用例的泛化。

抽象用例

观察剩下的候选用例，分析参与者使用它们的方式。使用方式可以从用例场景里归纳出来。如查询A报表和杳询B报表是两个不同的目的，有不同的结果。但是它们选择查询条件的过程是一样的，可以考虑抽象出一 个设置查询条件的用例，查询 A 报表和查询 B 报表都包含这个用例。

补充用例

向用例模型中加入那些与业务实现无关但是对系统运行必须的非业务性需求，例如使用管理用户账号、备份系统数据等。

如果你的分析工作中包含有概念用例模型，那么充分利用它。概念用例会为系统用例的获取提供很好的参考。

四、领域模型

从领域模型的基本概念来讲，这里说的领域模型与领域驱动设计的定义是一致的，都是通过抽象现实世界当中的事物，以概念化的手段，以模型的方式定义。基本概念一致，但是在《大象UML》这本书中，讲述的定义领域模型的方法以及领域模型定义出来以后的实际用途与《领域驱动设计》一书的确是不同的。

《领域驱动设计》一书倡导的领域建模实际上是一 种由内而外、先内功后招式的方法。先追求“真理与规律 ”，再用它来实现 “外在的表现”。它要求建模团队里有资深的领域专家，在领域专家的带领下，从业务需求当中找出那些体现了业务本质的事物、规则和结构，并为之建模，目标是定义出业务运行的规律和原理，在此基础上再去搭建具体应用程序的设计。这种方法实质上是先搭建业务架构，再实现具体业务。

这里讲的领域模型建模方法是使用用例驱动的模式，先明确业务，通过对用例场景、业务对象模型来找出某一个问题的解决方案。遵循的是用例驱动方法 ( UDO ) , 而不是领域驱动方法 ( DDD ) 。关于用力驱动和领域驱动的取舍，我就不做更多深入。

领域模型是采用业务对象建立起来的 一 种模型，我们把领域模型当中使用到的业务对象称为领域类。一般来说，领域类有三种典型的形式：

• 业务对象实体，表示业务中使用到或产生的东西。如定单、账号、合同等。
• 系统需要处理的现实世界中的对象和概念。如商品、买家、卖家等。
• 将要发生或已经发生的事件。如购买、撤单、付费等。
领域模型研究的是高于特定业务场景的一般规律，从所有业务对象用例场景对象交互模型当中抽象出来更高级别的业务对象模型，它表示了对业务对象结构和交互的一般规律，揭示了业务运行的本质和核心。

实际工作中，建立好的领域模型是很难的，我们必须对整个业务领域了解的非常透彻才可能，要求建模者具有深厚的行业知识背景，或者具高超的抽象能力，井且遍历了绝大部分的业务用例场景。

对于较小的项目，或者业务比较简单的项目，我们并不需要建立完整的业务领域模型。但总有某项业务或某个对象相对比较复杂，这时我们可以仅仅针对该业务或对象来建立 一 个小型的局部领域模型。

五、分析模型

分析类用于获取系统中的主要的职责蔟，他们代表系统的原型类，是系统必须处理的主要抽象概念。分析模型使用分析类来建立系统原型。

在统一过程中，分析类被定义为一种可选的模型，是从需求向设计模型转化的过渡。

如何使用分析模型:

六、软件架构和框架模型

从以前的软件发展到现在，基本会采用现成的、开源或自发的软件框架，也越来越忠实软件架构的建立。

统一过程是以架构为中心的开发模式，如果说用例代表了一个软件项目对需求的定义和理解，架构就代表了对系统的定义和理解了。软件架构在较高的抽象上，将系统规划为一些独立的逻辑部件，各司其职。

现实中，很多人把架构和框架搞混，框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础架构，可以减少开发工作量、指导和规范作用。

架构是系统蓝图，是大楼的结构、外观和功能性设计，需要考虑抗震，防火等功能。框架是建设大楼中一些成熟的工艺的应用，比如楼梯成型等等。框架是解决方案，加速和提高系统质量的半成品。

软件架构分为两者: 业务架构和技术架构。

业务架构

业务架构是在先启阶段完成的，在精化阶段得以改进，目标是为业务领域建立一个而维护和拓展的逻辑结构，描述业务的构成。

业务架构不仅仅是使用一张图来表示那么简单，需要写一份文档:

描述每一个领域包的职责、与其他领域包的关系，例如门户网站负责什么，与购物中心如何交互。
对一些重要的领域，例如购物中心，使用领域模型来解释他如何运作。
下图可以看到业务架构与核心模型的关系。用例模型、领域模型所描述的业务流程，通过抽象可得到业务架构。

软件架构

软件架构需要在业务架构的基础上引入计算机环境。软件环境和硬件环境。软件架构需要说明业务架构如何分布在计算机环境中，得以进行。

一个典型的软件架构包含两个视角，广度视角和深度视角。

关于架构和框架这里不做深入描述。

七、设计模型

设计模型就是我们所熟知的详细设计，采用设计类绘制，它主要考虑实现语言、架构、框架、编程模型、规范，目标是有程序逻辑来实现用例。

待续。。