读大象有感

发表于 | 分类于 ， ， |

面向过程与面向对象

面向过程与面向对象是认识世界的思想或方法论。世界则可以认为是由一定的原因产生的结果，原因和结果对应着计算机世界中的输入和输出。面向过程认为世界是由“因“到“果”的一次转换过程产生，关注的重心在于转换过程，即世界是由过程产生的。而面向对象则认为世界是由各个相互独立的对象（在没有“因”的作用下，这些对象在没有外力作用下是静止的）组成，，由“因”对这些对象的驱动所产生的“果”，关注的重心在于对象，即世界是由对象交互产生的。从中可以看出，面向过程的思考方式是从“因”开始，推算出“果”。而面向对象则是从“果”中分析出与“果”有关的一系列的对象。

使用面向对象方法的原因是可以化繁为简

面向对象的两大特性

  1. 封装
  2. 多态

可能大家会觉得奇怪，面向对象不是有三大特性吗？封装/继承/多态。这是因为我认为继承和多态是相同的概念，故统一称为多态。继承表达的是子类能继承父类的特征和行为，同时也具有一些自己特殊的特征和行为。多态表达的是一类对象有多种的表达方式（即父类能用任意一个子类来表达）。而实现继承与多态都是基于语言特性是重写，而实现重写的底层原理是方法动态绑定。因此，从这个角度看，继承与多态是相同的概念，只是继承更侧重于描述复用，是多态的实现方式，而多态更侧重于描述继承的使用方式。(在这里，我把实现接口和继承基类的方式都统称为继承了）。

抽象层次和抽象角度

抽象层次决定了事物的边界。拿汽车来打个比方，我们从高的抽象层次去看待汽车，我们能看到汽车由车轮、发动机等部件组成，但汽车内部（即往低层次抽象），则看到汽车由齿轮、螺丝组成。从高层次抽象去看待事物使我们对事物有更直观的认识，因为高层次抽象面对的事物更少，事物越少使我们更容易去认识和接受这些事物。因此，我们认识一个事物的时候通常都是由高抽象层次（最易理解的层次）开始，然后逐步降低抽象层次，再对事物作进一步的深入了解，从而勾勒出事物的本质。这种由高层次抽象->低层次抽象认识事物的过程就是分析对象的方法。逐步降低抽象层次的方法使得我们每次只需要面对相同抽象层次下有限的复杂度和有限的对象结构。

抽象层次也决定了我们分析问题的步骤。

眼中无边界，心中有边界

抽象角度决定了看待事物的角度。继续拿汽车作比喻，对购车客户来说，有些客户关心汽车的外观（如车的形状，涂装），而有些客户则关心汽车的功能（载重，可载人数），而有些着关心汽车的性能（每公里油耗，加速度等）。从汽车的示例中可以看出，一个事物的表现形式是多方面的，我们从不同的方面去看待事物有着不同的结果，我们如果能从越多的方面去看待事物，则越接近事物的“真相”。但大多数情况下我们并没有太多的精力和时间去从所有方面（角度）去分析一个事物，我们只需要从我们关心的角度去分析一个事物则足够了。由此可见，确定好抽象角度可以在抽象层次的基础上进一步收窄我们要认识的事物的“面”。

我们关心的方面即是我们要分析问题的抽象角度。抽象角度也即是我们的业务目标

如果说抽象层次为我们提供了认识事物的方法，则抽象角度则为我们提供了认识事物的方向。两者的结合其实就是面向对象设计方法了！面向对象设计方法的目标是从事物的表象（问题领域）中找出构成事物表象的一切对象及这些对象的运行规律，从而解释事物的表象（解决问题领域）。

面向对象的困难

虽然我们认识到世界是由对象构成。但当我们解决实际的问题领域时，则存在以下问题：

  1. 为什么解决这个问题领域时要抽象出这些对象呢？即如何从问题领域中找出这些对象的呢？

    抽象层次+抽象角度的分析方法让我们找到了这些对象

  2. 为什么这些对象就能解决问题领域呢？

    我们需要一个可验证分析结果是否正确的方法。

即我们应该有一种能从表象->抽象出问题领域本质（对象）的论证方法，也要有一种本质->表象的印证方法。

面向对象的困难通过建模的方法来解决。理想的建模就是UML+软件统一过程方法来完成。

建模公式

  • 问题领域 = \(\sum_1^n\)抽象角度
  • 抽象角度 = 业务目标 = 业务用例
  • 业务用例 = \(\sum_1^n\)特定场景
  • 特定场景 = 静态事物 + 特定的条件 + 特定的动作 或者 特定的事 = 特定的事物 + 特定的规则 + 特定的人的行为

建模公式表达的含义是所有的问题领域都是由1个或多个业务目标（业务用例）构成，解决了这些业务用例即解决了问题领域。业务用例可以由多个特定的场景表达，从这些场景中可以找出构成业务用例的人、事、物、规则。人、事、物、规则是构成问题领域的根本，找到了它们也就解决了问题领域。

业务范围与系统范围

业务范围与系统范围是不同的，业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在，系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能则会超出业务范围，例如操作日志。有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志使得系统更加健壮。

UML核心元素

参与者

  • 参与者对系统有着明确的目标和要求并且主动发出动作
  • 系统是为参与者服务的
  • 参与者必然在分析问题领域的边界之外

用例

用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。一个用例场景就是一个用例的实例。

一个完整的用例定义由参与者、前置条件、场景、后置条件构成。

用例的特征

  • 用例是相对独立的

    这意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例从功能上说是完备的。用例本质体现了参与者的愿望，不能完整达到参与者愿望的不能称为用例。

  • 用例的执行结果对参与者来说是可观测的和有意义的

  • 不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

  • 用例必然是以动宾短语形式出现的。

  • 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。

用例的粒度

相信使用过uml进行用例划分的时候，都会出现用例粒度选择困难症。出现用例粒度问题的根本原因是没有确定好边界，也就是没有定义好抽象层次。当边界定好之后，参与者就可以确定下来了，而用例的粒度以该用例是否完成了参与者的某个完整目的为依据。

不论粒度如何选择，必须把握的原则是在同一个需求阶段（抽象层次）下，所有用例的粒度应该是同一量级的。

获取用例

通过提问的方式来获取用例：

  • 你对系统有什么期望？
  • 你打算在这个系统里做些什么事情？
  • 你做这件事的目的是什么？
  • 你做完这件事希望有一个什么样的结果？

由以下几点来确保用例的正确性：

  • 一个明确的有效目标才是一个用例的来源
  • 一个真实的目标应当完备地表达主角的期望
  • 一个有效的目标应当在系统边界内，由主角发动，并有着明确的后果。

用例的分类

用例按建模阶段有不同的用例版型。

在业务建模阶段，会有业务用例和业务用例实现的版型，由于是业务建模，因此业务用例中不应该有计算机相关的概念名称，而应该真实使用业务专有名词进行描述。

在概念建模阶段，会有概念用例版型，概念用例用于获取业务用例中的核心业务逻辑，这些核心业务逻辑提示了业务模式，成为业务架构的重要指导。

在系统建模阶段，会有系统用例和系统用例实现。

业务实体

业务实体是类的一种版型：

  • 业务实体是来自现实世界的，在我们建模的问题领域里一定能够找到与它相对应的事物，并且这个事物是参与者在完成其业务目标的过程中使用到的或创建出来的。
  • 业务实体一定是在分析业务流程的过程当中发现的，而业务流程实际上就是业务用例场景，对业务用例场景没有贡献的事物，即使它是客观存在的，也不应当为它建模。
  • 业务实体作为类的版型，具有对象的所有性质，包括属性和方法，同时也具有对象的独立性，即业务实体只应当包含它本身固有的特性，而不能包含外界是如何使用它的信息。

包

UML认为好的分包具有高内聚、低耦合的性质，包之间的关系也只有依赖1关系。

分包的原则：

  • 分入同一个包中的那些元素应当是相互联系紧密，甚至不可分割的。同时这些元素又具有某些相同的性质，使得包可以抽象出一些接口来代表包内事物与包外的事物交互，以避免包外的事物频繁地直接访问包内元素。这样包就具有高内聚的性质。
  • 保证包之间的依赖关系不会被传递。如B依赖于A，C依赖于B，当A修改导致B要做出修改，C不会受到影响。
  • 包之间的依赖关系应当是单向的，应当尽量避免双向依赖2和循环依赖3。

分析类

  • 分析类代表系统中主要的“职责簇”，这意味着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”。
  • 分析类可以产生系统的设计类和子系统，这意味着计算机实现是可以通过某种途径“产生”出来的，而不是拍脑袋拍出来的。

边界类

边界类是一种用于对系统外部环境与其内部动作之间的交互进行建模的类。

任何两个有交互的关键对象之间都应当考虑建立边界类。

现实世界中，边界类的实例可以是窗口、通信协议、打印机接口、传感器、终端等，在计算机世界里，边界类可以是一个消息中间件、一个驱动程序、一组对象接口甚至任意一个类。

边界类的常用场景：

  • 参与者与用例之间应当建立边界类

  • 用例与用例之间如果有交互，应当为其建立边界类

    一个用例如果要访问另一个用例，直接访问用例内部对象是不好的结构，这样将导致紧耦合的发生。而边界类可以隔离这种直接访问，其作用相当于一个门面模式。在最终实现时，用例之间的边界类可以演化为一组API、一组JMS消息、通信协议或一组代理类

  • 如果用例与系统边界之外的非人对象有交互，例如第三方系统，应当为其建立边界类

    这通常是因为异构系统、异构数据、访问权限、安全通道等原因。在具体实现时，边界类可以演化为中介和通信协议，中介的例子如网关、通信中间件、代理服务器、安全认证服务器、WebService、SOA组件等;通信协议的例子如HTTP、FTP等

  • 在相关联的业务对象有明显的独立性要求，即它们可能在各自的领域内发展和变化，但又希望互不影响时，也应当为它们建立边界类。

边界类的目的就是为了解耦，当有紧耦合时，就要考虑边界类。

控制类

控制类用于对一个或几个用例所特有的控制行为进行建模。控制类来源于对用例场景当中动词的分析和定义，包括限制动词的描述。

实体类

实体类用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如，事件、人员或一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。

实体类源于业务模型中的业务实体，业务实体可以在后续的过程中被分拆、合并。

在设计阶段，实体类可以被设计为EntityBean、POJO等。

分析类有三高：高于设计实现、高于语言实现、高于实现方式

关系

关联关系(association)

关联关系是一种静态关系，通常与运行状态无关，而是由“常识”、“规则”、“法律”等因素决定，所以关联关系是一种强关联关系。

例如，公司与员工之间一对多就是一种符合“常识”的关系；乘车人和车票之间的一对一关系是符合“规则”的关系；公民和身份证之间的一对一关系是符合“法律”的关系。

关联关系用来定义对象之间静态的、天然的结构。

关联关系与依赖关系的区别在于，关联关系仅仅是“知道”关联对象的存在，但不会对它进行访问或修改。而依赖关系不但知道依赖对象的存在，还会对它进行访问或修改。

聚合关系（aggregation）与组合关系（composition)都属于关联关系，只是它们在关联关系的基础上多了一层语义。聚合关系表达了整体由部分构成的主义，而组合关系表达整体拥有部分的语义。聚合关系与组合关系的区别在于聚合关系中的整体与部分不是强依赖的，即使整体不存在了，部分仍存在。

依赖关系(dependency)

依赖关系描述一个对象在运行期会使用到另一个对象的关系。与关联关系不同的是，依赖关系是一种临时性的关系，它通常是在运行期发生，并且随着运行场景不同，依赖关系也可能发生变化。

依赖关系是一种弱关系，它不是天然存在的，并且会随着运行场景的变化而变化。如人和刀这两个对象，平时它们是没有关系的，但在削苹果这个场景里，人依赖于刀，脱离了这个场景，依赖关系就不存在了。

扩展关系(extends)

扩展关系用于在用例模型中说明基本用例的扩展用例。与包含关系不同的是，扩展表示的是“可选”，而不是“必需”，这意味着没有扩展用例，基本用例也是完整的。例如：打电话用例，在打电话时可以保留当前通话而接听另一个电话，保留通话就是一个扩展用例，因为没有保留通话功能，打电话用例也是完整的。

抽象出扩展用例的意图往往是因为扩展用例表达了关键的可选的核心业务，或该扩展用例有可复用意义的。

包含关系（include)

包含关系也是应用于用例模型中，用于说明基本用例依赖于包含用例的结果。缺失包含用例，基本用例将是不完整的。

抽象出包含用例的意图往往是因为包含用例表达了关键的必选的核心业务，或该包含用例有可复用意义的。

实现关系（realize)

实现关系用于用例模型或类图中。用于用例模型中表达了一个用例的多种实现方式，而在类图中表达了接口的多种实现方式。

精化关系（refine）

精化关系用于用例模型，一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致地展示了基本用例的核心业务。

概念模型是用于获取业务模型中的关键概念的，从业务模型中分析出实现业务目标的那些核心行为和实体，从而描述出一个关键的业务结构以得到一个易于理解的业务框架。这些关键概念就是对业务用例的精化。

泛化关系（generalization）

即继承

UML核心视图

用例图

业务用例视图

业务用例视图应当按真实业务进行建模，其过程不应包含任何计算机观点。因此，业务用例视图建模的边界是业务范围。

业务用例视图在建立业务用例模型阶段使用

概念用例视图

概念用例视图是对业务用例视图的扩展、包含、精化关系视图。概念用例来源于业务用例，是对业务用例场景分析后，从中抽取出关键的、可复用的过程或对象，作为核心业务概念，从而形成概念用例。

概念用例视图在建立概念用例模型阶段使用

系统用例视图

系统用例来源于业务用例和概念用例，以系统范围为边界，粒度应为一次系统交互过程。

系统用例视图在建立系统用例模型阶段使用

类图

类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。类图建模是先概念层->分析层->实现层这样一个随着抽象层次的逐步降低而细化的过程。

业务层类图

业务层类图位于业务建模阶段，描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。业务层类图中的类和类关系与最终的实现类并不一定有直接和明显的对应关系。类图着重于对问题领域的概念化理解，而不是实现，因此类名称通常都是问题领域中实际事物的名称。

概念层类图

概念层类图位于概念建模阶段，考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。也就是说，这时候我们不必关心类最终是用什么语言编码，用什么设计模式设计，我们所关心的只是这样一些类，它们通过接口进行交互，进而完成问题领域中的业务目标。概念层类图用分析类和分析模型图来表示。

设计层类图

设计层类图直接映射到可执行代码。

活动图

活动图主要用于描述用例场景、对象交互。活动图主要作用：

  • 帮助发现概念用例
  • 帮助发现业务实例
  • 帮助发现角色

状态图

状态图主要用于描述对象的状态变化以确定何种行为改变了对象状态，以及对象状态变化对系统的影响。状态图可以用来描述业务实体对象、分析类对象、设计类对象。状态图用于描述实体类对象的整个生命周期内的状态变迁以获得对这个实体对象的理解，同时获得系统和实体对象相互影响的关系。状态图通常只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。

时序图

时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。

由于类图有三个层次的观点：业务层、概念层、设计层，因此，时序图也可以针对这三个层次的对象进行绘制时序图，从而有了业务模型的时序图、概念模型的时序图、设计模型的时序图。

协作图

协作图描述了对象间交互的一种模式；它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。

协作图因为展示了对象间的关系，使得它更适用于获得对对象结构的理解，而时序图则更适于获得对于调用过程的理解。

同样的，协作图也会按建模阶段有不同类型的协作图：业务模型协作图、分析模型协作图、设计模型协作图

UML核心模型

用例模型

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

用例模型有三个层次的模型：业务用例模型、概念用例模型、系统用例模型。业务用例模型用于识别和规定业务需求，概念用例模型用来分析和确认业务需求，而系统用例模型用来规定系统开发需求。

业务用例模型

业务用例模型的目的是为现在的或客户预想中的真实业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型，它不需要考虑计算机环境。相对于系统模型来说，业务模型是对现实业务的一种直观的理解，而没有加入其他的因素，因而更容易在客户和开发双方达成共同理解。

业务用例模型奖在业务方和承建方之间建立这样的共识：要建立的计算机系统所面对的问题领域就是这个样子的。

完整的业务用例模型应包含以下内容：

  • 业务用例视图（包括业务用例实现视图）
  • 业务用例场景（活动图、时序图、协作图）
  • 业务用例规约
  • 业务规则
  • 业务词汇表
  • 业务对象模型（类图、状态图）
  • 包图

概念用例模型

概念用例模型是在基本业务用例中抽象出关键和核心的工作单元，针对这些工作单元建立模型来简化业务。概念用例通过包含、泛化、扩展关系连接到基本业务用例。

由于业务用例是从业务主角的观点去建立的，通常业务主角只会负责整个业务流程中的一个环节。如果我们希望获得对整个业务流程的了解，从单个业务用例就难以获得。概念用例模型就是从业务用例中“抽取”出针对某个关键业务流程产生贡献的工作单元，再用这些工作单元来组织成这个业务流程，以得到对业务流程的理解。

完整的概念用例模型包含以下内容：

  • 概念用例视图

  • 概念用例分析（活动图、时序图、协作图）

    着重点在于表达概念用例如何贡献或实现业务用例的

  • 分析类视图

  • 分析场景（活动图、时序图、协作图）

    分析场景使用分析类绘制对象交互图，从对象的角度去实现概念用例分析场景

获得概念用例的方法：

  • 观察现有的业务用例场景，发现某些有着相似名称，在不同的业务用例场景中多次出现，或者位于不同的泳道中的活动。
  • 通过对客户业务的分析，或者咨询业务专家，得知对客户来说最为重要的一些业务实体。了解对这些业务实体可能进行的主要操作来获得备选的概念用例。
  • 通过对客户业务的分析，或者咨询业务专家，得知对客户来说最为关心，影响整个流程成败的关键业务环节，然后了解这些关键业务环节做什么，以此来获得备选的概念用例。

系统用例模型

在建立系统用例模型过程中，应该意识到模型的边界已从业务范围变更为系统范围了。

在统一过程中，系统的功能性需求完全由用例模型来表达。作为客户方和开发主的契约，用例模型必须得到客户的认可。用例模型从作用上讲完全等同于“需求规格说明书”，它将作为合同附件来约定系统的开发范围。另一方面，用例模型也是客户理解系统的最重要途径。如果客户认可用例模型，开发方就可以认为系统正是客户所需要的。

完整的系统用例模型包含以下内容：

  • 业务用例

    系统用例使用精化关系连接到业务用例，表明软件过程的可追溯性，说明哪些用例是从哪个或哪些业务用例演化出来的。

  • 概念用例

    作为从业务用例到系统用例的过渡，概念用例对用例模型来说只起到获取用例的指导作用。它作为用例模型的附加说明存在。

  • 用例视图

  • 用例规约

  • 补充规约

  • 业务规则

  • 用例场景

  • 分析对象

系统用例的获取方法：

分析业务用例场景，尤其是活动图。按泳道中的活动作为备选用例，然后使用排除用例、合并用例、抽象用例等方法确定系统用例。

领域模型

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

  • 业务对象实体，表示业务中使用到或产生的东西。如定单、账号、合同等。
  • 系统需要处理的现实世界中的对象和概念。如商品、买家、卖家等。
  • 将要发生或已经发生的事件。如购买、撤单、付费等。

如果说业务用例场景下的业务对象模型研究的是特定的业务实例（即业务对象结构如何实现该业务），那么领域模型研究的则是高于特定业务场景的一般规律（即试图定义出能够满足所有业务用例场景的对象结构。可以说，领域模型是从所有业务用例场景对象交互模型当中抽象再出来的更高级别的业务对象模型；它表示了业务对象结构和交互的一般规律，提示了业务运行的“本质”和“核心”。

简单地说，领域模型是从业务模型所有用例场景中找出最为关键和核心的问题或痛点，偿试抽象出更为关键的对象，以优化业务对象模型结构，以达到优化业务结构的目的。

领域模型是对用例驱动的设计方式的一种补充或优化，因为领域模型的建立需要跨多个用例分析后到的结果，而用例驱动一次只会在一个用例范围内分析对象模型。

分析模型

分析模型建立在系统用例模型或领域模型之后。分析模型使用分析类来建立系统原型，获得系统实现需求的第一手方案。

分析类的获取方法：

对照着用例场景的活动图或时序图，然后使用分析类去实现用例场景。在参与者与系统之间加入一个边界类代表操作界面，在边界类与实体之间加入一个控制类代表业务逻辑，然后对照用例场景，一步一步忠实地把用例场景过程用分析类实现出来。

获得分析类之后就可以定义分析类之间的关系了，定义分析类的关系应遵循以下几个原则：

  • 边界类应通过控制类与实体类交互
  • 实体类与实体类之间可以有聚合或组合关系，但不应有依赖关系，它们只能通过控制类间接交互。
  • 控制类与控制类之间不应当有聚合或组合关系，并尽量减少依赖关系。

分析类的关系确定之后，还可以对分析类的关系进行优化，优化的手段有以下这些：

  • 业务规则

    业务规则的复杂程度或预计未来变更的频率，都有可能影响分析类的定义，可能会在分析类中添加一些属性，为规则新增一个分析类，甚至设立问题领域建立领域模型。

  • 结构优化

    如果分析类关系是网状结构，则应该使用面向对象的原则，转换为星形结构。一般的手段是添加中介类，门面模型等。

  • 分离职责

    如果一个分析类负责的事情太多，则考虑将它分解职责单一的分析类。

分析模型的主要内容：

从分析模型中可以看出，分析模型还应该可以映射到架构视图、组件视图甚至部署视图。

维护分析模型与需求同步，加上架构设计、框架设计、编程规范等作为编码实现的约束，而放弃维护设计模型与需求的同步。分析模型保证了需求，架构设计保证了系统，框架设计指导了实现，编程规范约束了编码。

软件架构和框架

架构就代表了一个软件项目对系统的定义和理解。软件架构在较高的抽象层次上，将系统规划为一些独立的逻辑部件，各负其责，这些部件通过标准的通信接口传递信息。一个架构就是一个系统的骨架。

框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础结构，对开发工作起到减少工作量、指导和规范作用。

架构需要描述两个方面的内容：业务架构和软件架构。

业务架构的目标是为业务领域建立一个维护和扩展的逻辑结构，描述业务的构成。业务架构使用领域包和组织结构包来表示业务主要领域和组织结构关系。

业务架构可由用例模型和领域模型推导出来，同时业务架构对用例模型和领域模型有着重要的指导作用。

软件架构需要在业务架构的基础上引入计算机环境，计算机环境包括硬件环境和软件环境。硬件环境指网络拓扑结构、服务器及其他设备等，而软件环境则指操作系统、应用服务器、中间件、数据库以及其他第三方软件等。软件架构需要说明业务架构如何分布在计算机环境中，并得以执行。

软件架构包含两个视角：广度视角和深度视角。广度视角指的是常见的软件分层结构，深度视角则是每一层的详细说明。

架构需要描述的主要内容：

  • 业务架构概述

    主要描述业务概要，包括背景、商业模式、商业目标、系统目标等。

  • 组织结构

    主要描述客户方的组织结构，各部门的职责和关系，以及每个部门在整个业务架构中所起的作用。

  • 业务模块

    分模块描述每个业务模块在整个业务中要完成的商业目标，与相关业务模块的关系，以及模块内部的主要业务流程

  • 典型用例场景

    从用例场景中挑选出重要的典型用例场景，描述该场景如何串联各个业务模块，在各个业务模块中的主要处理事项以及产生的结果

  • 软件架构概要

    根据客户的系统要求和现有条件，说明系统的设计目标和设计原则，以及软件架构中将要描述的内容。

  • 计算环境

    系统运行的硬件和软件环境

  • 软件层次

    从广度视角描述软件层次结构，描述每一层次的职责、设计目的和约束（包括标准、规范和使用的框架），并描述每一层次之间交互所使用的通信协议和接口。

  • 实现架构

    从深度视角描述软件层次。需要使用时序图和交互图描述模块中典型的交互场景，说明该架构中的主要对象是如何交互而完成使命的。

  • 典型用例场景的架构实现

    按需使用时序图、交互图、活动图等动态视图，采用软件架构中的元素来实现一个或多个典型的用例场景。这些场景应当贯穿整个软件层次、使用到所有的架构模块和通信协议。

  • 非功能性需求

    描述系统的非功能性需求，例如可靠性、可用性、可扩展性、可移植性等。也可包括客户对系统质量的要求，如容错能力、友好性、响应时间等。

设计模型

设计模型即我们所熟悉的详细设计。由于维护设计模型与需求同步的难度和成本比较高，因此并不需要对每一个用例场景都需要进行设计建模。

适用场合有：

  • 解释软件架构

    设计模型用来解释软件架构如何运行，以及描述应当如何使用架构的编程模型。

  • 解释软件框架

    用设计模型来解释框架如何运行，如何使用框架的类库以及开发时应当怎么遵循编程模型。

  • 典型用例场景

  1. 如果A事物发生变化，B事物必然变化，我们称B依赖于A;反之则无依赖 ↩

  2. A依赖于B，B依赖于A ↩

  3. A依赖于B，B依赖于C，而C又依赖于A ↩