软件架构理解和延伸

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型 软件系统各个方面的设计。

软件架构是一个系统的 草图。软件 体系结构是构建 计算机软件实践的基础。

简介

定义

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象 组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在 面向对象领域中，组件之间的连接通常用 接口来实现。

软件 体系结构是构建 计算机软件实践的基础。与 建筑师设定建筑项目的设计原则和目标，作为 绘图员画图的基础一样，一个 软件架构师或者 系统架构师陈述 软件构架以作为满足不同客户需求的实际系统设计方案的基础。

目标

正如同软件本身有其要达到的目标一样， 架构设计要达到的目标是什么呢？一般而言， 软件架构设计要达到如下的目标：

可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

可伸缩性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的 软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（Customer Experience）。 软件系统必须易于使用。

市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

历史

早在1960年代，诸如 E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和Microsoft内部的相关活动，软件架构这个概念开始越来越流行起来。

卡内基梅隆大学和 加州大学埃尔文分校在这个领域作了很多研究。 卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如 软件组件、连接器、风格等等。 加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使得一个建筑独一无二。

软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是 建筑设计师必须面对的核心问题。英国首相 丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。 英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

在 软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界， 现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。

几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。

相互关系

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个 组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个 软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

是一般而言，软件系统的架构（ArchitECture）有两个要素：

它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行 详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关 系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

种类

根据我们关注的角度不同，可以将架构分成三种：

逻辑架构

软件系统中元件之间的关系，比如用户界面，数据库， 外部系统接口， 商业逻辑元件，等等。

比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图

图2、一个逻辑架构的例子

从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如 WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

物理架构

软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的 分布式系统的物理架构，图中所有的元件都是 物理设备，包括 网络分流器、 代理服务器、WEB服务器、 应用服务器、 报表服务器、整合服务器、 存储服务器、主机等等。

系统架构

系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是 架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行 软件设计需要做出的决定中，必然会包括 逻辑结构、 物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的 架构设计文档。比如一个中等的 数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

视图

我们决定以多种构架视图来表示 软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、 系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为 构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

逻辑视图：包括最重要的设计类、从这些设计类到包和 子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。

配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在 分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在 软件构架文档中。

您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、 数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

重点

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要。

系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售 构件。插入范围更广的系统。

形式

构架模式

构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施（ 中间件）是可以在其上构建某种构架的 构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。

模式示例

[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

类别 模式结构 层管道和过滤器黑板 分布式系统代理交互系统 模型-视图-控制器表示-抽象-控制 自适应系统反射微核

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要 构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

为阐明其含义，下面将详述其中的两个；完整说明请参见。模式以下列广泛使用的形式来表示：

模式名环境问题影响，描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层

环境需要进行结构分解的大系统。

问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直 构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。

影响

系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。

示例：

1. 通用层

严格的分层构架规定设计元素（类、构件、包、 子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。

2. 业务系统层

上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

有关该模式的深入讨论，请参见指南：分层。

模式名黑板

环境没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、 语音识别和监视系统。

问题多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

影响

知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略

不同顾问的输入（结果或部分解决方案）可能有不同的表示方式

各顾问并不直接知道对方的存在，但可以评估对方发布的工作

解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。

示例：

以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。

构架风格 软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。

逻辑视图：类图、 状态机和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图： 构件图。部署视图：配置图。

设计

描述语言

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。

架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言，如Wright (由卡内基梅隆大学开发)，Acme (由卡内基梅隆大学开发)，C2 (由UCI开发)， Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。

视图

构架

构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：

逻辑视图：类图、状态图和对象图。

进程视图：类图与对象图（包括任务 - 进程与线程）。

实施视图：构件图。

部署视图：配置图。

用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。

流程

在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。

架构师

软件设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的 架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体会到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

[1]  

实践

实践中的理解

软件架构是对软件系统运行时元素的抽象，软件系统可能有很多层抽象，或由多重业务流程所组成，每层抽象或每个业务流程都有自己的软件架构。

软件架构是平衡的艺术。

1. 软件架构设计的What & Why

● 啥是软件架构（Software Architecture）？

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

软件架构设计就是从宏观上说明一套软件系统的组成与特性。

软件架构设计是一系列有层次的决策 ，比如：功能与展现的决策；技术架构的决策；自主研发还是合作；商业软件还是开源软件 。

● 为啥要进行软件架构设计？

业务需求层出不穷；软件系统越来越复杂；参与的人越来越多；共性和特殊性的问题越来越多；技术发展日异月新；……

2. 软件架构师

2.1. 软件架构师是干什么的

介于需求与开发的中间人	良好的沟通能力
能够统领全局的大牛	良好的大局观
能够将需求转换为技术	洞悉前沿与市场嗅觉
能够为软件研发提供指导	见多识广的大牛
需要全面思考软件系统方方面面的问题	缜密地思考问题
能够攻关和搞定重要技术难题	公司可信赖的支柱

2.2. 架构师的素质

全局思维	从业务、市场，到技术实现； 从软件的过去、现在，到将来； 从外部客户，到内部研发； 从软件研发，到硬件部署； 从功能实现，到运行效率
战略思维	在所在行业的发展战略； 在业务领域的发展战略； 在技术方向的发展战略； 在潜在市场的发展战略。
前瞻思维	市场趋势的发展动向； 前沿技术的发展动向； 竞争对手的发展动向； 合作伙伴的发展动向。
抽象思维	各项业务需求：抽象成功能模块； 各项功能的实现：抽象成软件架构。
逆向思维	假如不实现会怎样？ 假如没搞定会怎样？ 假如没有它会怎样？ 假如被延期会怎样？

2.3.  架构师的分类

随着行业和社会的发展，架构师的定义和分类越来越广泛和细分，广泛和细分其实并不矛盾，如果“广泛”是x轴，“细分”是y轴，则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说，或目前来说，集合业界的大致认知，总结如下：

No.	分类	描述
1	解决方案架构师	与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。
2	系统架构师	也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
3	平台架构师	这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其 实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
4	业务架构师	业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
5	网络架构师	过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
6	移动架构师	移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
7	前端架构师	这也是移动互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/…），跨浏览器设计等等。
8	...	...

3.  软件需求

软件架构设计中常说需求驱动架构设计，可见需求在整个架构设计中起到了关键指引和方向的作用，如果以目标导向为原则，则需求的满足和实现就是架构设计的终极目标。
OK，在进行架构设计之前，我们先看下软件需求。

3.1.  软件需求怎么来的（软件需求的过程）

阶段	需求阶段	说明	什么人做什么事		可能产生的文档
			客户方	实施方	客户方	实施方
1	业务需求	来自客户的原始需求，背景描述，业务诉求和期望目标。	项目负责人或接口人描述需求或提供客户方需求文档。	销售或售前接触客户，听取和记录需求。	工作说明书（SOW），或邀标书	售前的方案建议书
2	用户需求	通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。	项目负责人或接口人接受访谈和调研。	需求分析师或项目经理等进行需求调研。		调研计划、用户需求调研提问库、调研日志、用户需求说明书
3	软件需求	从系统实现的角度描述的需求。开发人员（设计和分析人员）在业务需求、用户需求的基础上形成的。		需求分析师或项目经理、架构师等讨论和细化需求，编写需求文档		SRS（Software Requirement Specification）软件需求规格说明书

3.2.  软件需求的分类：

另外，也有McCall软件质量模型：

注：在架构设计中，对非功能性需求的重视程度，也会影响架构设计的好与劣；但也要平衡过渡设计和适可而止的关系。

4.  软件架构的过程

业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程：

架构阶段	目标	方式方法	现实工作场景
预架构阶段	全面理解需求；需求结构化，摒弃“需求列表”，建立二维需求观（ADMEMS矩阵）。	使用ADMEMS矩阵方法，捋清需求间关系和发现衍生需求。	1、与人：与项目经理、需求分析师等内部需求人员了解需求；与客户了解需求（不建议架构师做需求分析师角色）。 2、与物：了解《需求规格说明书》等需求文档。" 3、对需求有什么问题，反馈给售前或销售，可能会参与拜访客户或电话会议。 4、销售或售前有时会要求提供一个大致的工作量，以便他们初步评估项目可行性。
概念架构	高层组件及其关系	1、初步设计，基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计（不是必须）。 2、高层分割，将复杂系统切分为多个二级系统或多个子系统。 3、考虑非功能需求，采用ADMEMS推荐的目标-场景-决策表。	1、参与内部讨论：项目可行性分析、讨论，从需求、技术、人力、风险等角度提供建议。 2、项目投标准备：参与投标团队的技术方案编写，编写系统架构章节，解决招标书上技术问题的问答。 3、参与项目讲标：作为讲标团队成员参与项目讲标，负责技术问答环节的应对。
细化架构		5视图法	在项目概要设计阶段，进行架构设计，制定规范和约定，为详细设计提供指导。
实现	详细设计 编码实现	架构设计形成详细设计文档	在项目实现阶段，对开发人员提供规范指引和技术支持。

注：架构设计的过程和内容的不是固定不变的，现实中，比如售前提供解决方案中，很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等，这时候，架构师就需要有螺旋思维和跳跃思维的方式，就像武功中，招式是死的，人是活的，要学会灵活运用。

5.  软件架构设计的方式方法

5.1.  多视图法

多视图方法是业界广泛认同的一种架构设计思路，包括：
● SEI的3视图法：
模块视图、组件-连接器视图、分配视图。
● 西门子的4视图法：
概念视图、模块视图、代码视图、执行视图。
● RUP的4+1视图法：
用例视图、逻辑视图、开发视图、进程视图、物理视图。
● 联邦企业架构框架：
技术架构视图、信息架构视图、应用架构视图、业务架构视图。
● ……

5.2.  5视图法

5视图法分析的意义：

● 全面分析软件系统方方面面的问题
● 尽早地发现和排除项目风险与不确定因素
● 从不同角度去展现要设计的软件系统
● 为项目进行中不同的干系人提供指导：
    -- 逻辑架构描述系统功能，并指导系统测试
    -- 开发架构规范软件的层次及代码风格
    -- 数据架构指导数据库的设计
    -- 运行架构定义了一些关键过程的设计
    -- 物理架构明确软件如何部署与实施

5.3.  5视图法设计步骤

两种观念：

观念	设计步骤
观念一	顺序进行： 1、逻辑架构。 2、开发架构 3、数据架构 4、运行架构 5、物理架构
观念二	5个视图是穿插进行设计的，对复杂系统而言，根本不可能将逻辑视图设计完了后再考虑其它视图。
笔者观念	观念一和观念二的情况在现实状况中都可能存在，要根据具体情况具体分析，但总体而言，5视图穿插进行思考更有利于思考的全局性和完整性。

5.4.  如何进行5视图法的设计

以下5视图表格中的工具和方法每个架构师或略有差异，以下仅为参考。

5.4.1.  逻辑架构

逻辑架构的重点是考虑软件功能性需求。

No.	考虑的方面	产出物	工具	说明
1	系统功能划分为几个子系统与功能模块？	系统功能树	树型结构图
2	向什么用户提供什么样的功能？	用例模型	UML用例图	体现用户和行为
3	每个功能都是怎样的操作流程与分支？	用例描述	用例描述表	含输入输出、事件流分析； 不要有界面描述
			UML活动图	进行业务流程分析，包括泳道图
4	如何通过界面与用户交互？怎样交互？	鲁棒分析	鲁棒图	通过对“用例描述表”进行原文分析法拣出名词和动词
5	应当设计哪些类与界面？怎样设计？	领域模型	UML类图
6	与哪些外部系统接口？怎样接口？	接口描述	UML类图

5.4.2.  开发架构

开发架构重点关注的是开发编码实现方面的问题。

No.	考虑的方面	产出物	工具	说明
1	分层结构设计	分层架构图（开发架构图）	各种绘图工具	好的分层结构支持自动化测试
2	开发技术选项	开发语言 开发框架 开发工具		考虑商用产品、开源框架、自研框架
3	模块划分	源码工程；Project目录结构； 分包(分库)
4	开发规范	开发/编码规范文档；
5	软件质量属性	分析和决策结果		考虑运行期和开发期软件质量属性，并权衡利弊进行决策。

5.4.3.  数据架构

数据架构不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

No.	考虑的方面	产出物	工具	说明
1	数据是集中还是分布存储的？如何考虑分布式存储？	数据架构图
2	领域模型到数据库表的转换？表结构关系的设计？	逻辑模型 物理模型 ER图	Power Designer Visio
3	实体如何设计？充血模型和贫血模型？	UML类图
4	使用什么数据库？关系型还是非关系型？	选型结果

关系型数据库	非关系型数据库（NoSQL）
Oracle（首次发行：1980年） MySQL（首次发行：1995） MS SQL Server（首次发行：1989） PostgreSQL（首次发行：1989） IBM DB2（首次发行：1983） Microsoft Access（首次发行：1992） Sybase ASE（首次发行：1987） SQLite（首次发行：2000） ……	MongoDB（首次发行：2009） Cassandra（首次发行：2008） Apache CouchDB Hbase Redis db4o BaseX ……

5.4.4.  运行架构

运行架构关注的不再是全局而是局部，着重关注那些关键点与难点，常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行，同时也要考虑质量属性。

No.	考虑的方面	产出物	工具	说明
1	运行：同步vs.异步；并发vs.串行	考虑开发架构中代码的实现。
2	交互：对象间交互；状态转换	考虑开发架构的合理性，到类、到接口、到代码。
3	质量：安全；可靠；可伸缩	考虑开发架构的合理性
4	性能：响应时间；吞吐量	估算： 在线人数、并发人数； 每秒事务量； 响应时间。

5.4.5.  物理架构

物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。

	考虑的方面	产出物	工具	说明
1	网络方面：网络拓扑；网络设备；安全机制	拓扑图 安全规范
2	性能方面：可靠性、可伸缩性	需要什么样设备性能
3	部署方面：集中式还是分布式；组件部署	部署图

6.  一个思考，谁驱动了架构设计？

需求驱动了架构设计？

质量属性了驱动了架构设计（ADD）？

领域驱动了架构设计（DDD）？

风险驱动了架构设计？

质疑驱动了架构设计？

……

到底是谁驱动了架构设计？我们以船舶设计建造为例，来看这些问题：

目标和结果 à	问题 à	回答 à	小结
设计和制造一艘远洋货轮，能经历数月海上颠簸和长途跋涉，并保证货物的安全和完整，最后能顺利抵达目标港口。	我们为什么要设计和制造这样的大船？	市场有这个需求； 获利很丰厚； 解决就业； ……	不管是外部需求还是内部的需求，都是需求。不正是需求驱动吗？
	如何保证货船能长途航行并经受波涛和风雨？	船要造的结实；	鲁棒性	这些不正是质量属性驱动设计吗？
		引擎设计的强劲；	性能
		船的燃料充足；	持续可用性
		装备卫星电话、GPS、雷达等设备	互操作性
		货物和人员要安全	安全性
	船舶设计师怎么设计这样的船舶？	现在都会通过计算机进行船舶的CAD和3D模型设计。	是不是佷似领域模型驱动了设计？
	造船一定有很多风险吧？	那是，比如订货方客户有时提出改装船舶的意见（需求变化的风险）；有时某些工艺成品率不稳定（质量风险）；等等。	所有可能的风险点在设计时都要考虑到，做好预案，才能保证架构设计的可行性和灵活性，风险驱动了架构设计。
	上面怎么提了那么多问题，其实还有很多问题，比如……	嗯，你现在有不少疑问了。	不断的质疑架构设计中可能存在各种问题，有质疑才有思考，才有解决方案，从而推动架构设计的不断完善。

总结：

以上几个方面都能驱动架构设计，并不是零和的规则，而是一个立方体从不同方向看的问题。以上方面有些是指导思想，有些是行动方式，有的兼而有之，阐述方式看似不同，终极目标还是造出大船（实现需求），造出好船（质量属性），怎么造（领域模型），造的顺利（风险控制），挑不出毛病（架构师自己先质疑问题并解决了）。

7.  软件架构设计的误区

● 高开高走落不到实处

● 理想与现实需要折中

● 遗漏关键性约束与非功能需求

● 为虚无的未来埋单而过度设计

● 过早做出关键性决策

● 客户说啥就是啥成为酱油哥

● 埋头干活儿缺乏前瞻性

● 架构设计还要考虑系统可测性

● 架构设计不要企图一步到位

对比延伸：怎么区别软件架构、系统架构、解决方案架构、企业架构？ - https://www.zhihu.com/question/20308367

参考文献：《一线架构师实践指南》&《软件架构十个技巧及成功团队具备的气质》