软件架构设计与模式

软件架构设计与模式薛君敖 博士 Junao Xue Ph.D

xuejunao@2009年12月9-11日

讲师介绍81年赴美，美国哥伦比亚大学电脑科学硕士、物理学博士。 85-87 在美国芝加哥AT/T Bell Laboratory工作期间，参与编写5ESS(超大型交换机)Database Retrofit的数据库架构层面的设计和实施方案，包括：设计和管理安全的数据库架构，设计和管 理高可用性解决方案，优化和实施数据库的数据恢复计划，设计、部署和巩固数据库架构。 88-94 在美国新泽西州 AT/T Bell Laboratory工作期间，是DACS(大型传输交换连接设备)的 Architect组成员，为DACS的逻辑架构、物理架构和系统架构设计提供解决方案，并主持DACS 的 FSTS(工厂测试系统)系统设计，从硬件基础设施、技术平台、应用平台到应用的设计和实施 。之后参与编写SDH和DWDM两大光通讯网络的网管系统(INMS)的逻辑/物理/系统架构设计 方案。 94-02 Lucent Technologies Bell Labs Innovations 在任朗讯科技贝尔实验室网管技术支持小组组长兼任原邮电部网管专家顾问期间，为北京，上 海，深圳，武汉，南昌等地SDH/DWDM/光网络及网管的设计和实施提供技术解决方案 03-06 在任“微软-北京邮电大学软件学院-亚鸿世纪软件联合研究中心”副主任、兼任北京亚鸿 世纪软件公司总经理和中科软国际部技术顾问期间，为中国电信业提供业务流程重组(BPR) 、业务流程管理(BPM)的IT解决方案；领导编写为韩国电信和中国电信用的基于 COBIT/ITIL/MOF的IT解决方案，指导开发基于Biztalk和SPS的OSS/BSS已部署在河南通信、威海通 信。 06-现在 普信管理 & 祝成科技 在任首席IT专家期间，为上海浦发银行、上海农商行、中国兵器集团财务公司提供包括对IT建设 /IT服务管理/IT应用的评估咨询服务，并为它们做了IT评估报告和IT规划包括21个IT系统的升级 架构设计和需求分析；以RUP为指导，领导开发了基于SOA/BPM/Web2.0技术平台的银行/金融 业GRC综合管理平台。 85-01贝尔实验室DMTS(资深研究员),04-09 微软MVP(最有价值专家)2

Agenda 软件架构导引 业务建模 & UML 需求分析 软件架构视图 架构设计实践 架构设计模式 面向服务架构SOA

什么是架构?软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。主流的标准观点有： ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、 构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述 内容设计与演化的原理(principle)”。 Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设 计和数据结构设

计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信 协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各 设计方案之间进行选择。 Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component)、连接件 (connector)和约束(constrain)}。其中构件可以是一组代码，如程序的模块；也可以是一个 独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等， 用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和 条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息； 代码复制迁移的一致性约束；什么条件下此种连接无效等。 Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等， 虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统 的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及 其约束(或者连接语义),这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE 的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。4

架构与框架 框架，即framework。是某种应用的半成品，是一组组件，供用户选用完成自己的系统。 简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软 件。框架一般处在低层应用平台(如J2EE)和高层业务逻辑之间的中间层。 因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问 题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只 需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统 很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多 人使用，所以结构很好，扩展性也很好，而且它是不断升级的，你可以直接享受别人升级 代码带来的好处。 架构与框架的区别与联系如下： 1 .呈现形式不同.架构的呈现形式是一个设计规约，而框架则是程序代码。 2.目的不同.体系结构的目的是指导一个软件系统的实施与开发；而框架的目的是为复用。 因此，一个框架可有其架构，用于指导该框架的开发，反之不然。 3.有种特殊的架构，DSSA(领域特定体系结构)其目的也是为了复用。 4. 架构风格在其用程序代码实现后就成了Corba、COM架构框架，也叫中间件集成框架， 或对象中间件。

架

构的范围 软件架构—这次培训的主关注点。 硬件架构—包括CPU, 内存，硬盘，周 边设备例如打印机，与连接这些元素的 部分。 组织架构—是一些关于商业进程，组 织结构，规则和职责，与组织核心能力 的部分。 信息架构—包含组织好的信息结构。 软件架构、硬件架构、组织架构和信 息架构是全部系统架构的子结构。 企业架构与系统架构很相似，包括硬 件，软件，人员等。但是，企业架构与 商业有很强的联系，因为它专注于商业 对象的联系，专注于商业敏捷性和组织 效率。企业架构可能穿插于公司间。

架构师分类 企业架构师EA (Enterprise Architect) EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title是首席软件 架构师，实际上就是EA角色。 基础结构架构师IA (Infrastructure Architect) IA的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架 和组件，这些是技术型公司传承下来的最宝贵的财富。 特定技术架构师TSA (Technology-Specific Architect) TSA主要从事类似安全架构、存储架构等专项技术的规划和设计工作。

解决方案架构师SA (Solution Architect) SA的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论， 不断地进行组合，来创造出满足用户需求的选择。软件架构师基本上是EA+TSA+IA,是程序员向上发展的道路，比如JAVA架构师、 DotNet架构师、LAPM架构师等等，系统架构师实际上是SA+TSA,更着力于综合运用 已有的产品和技术，来实现客户期望的需求。

架构师的主要职责1、确认需求 在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的 认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。 2、系统分解 依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随 后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向 ”分解，还要对同一逻辑层分块，进行“横向”分解。这体现了软件架构师的功力。 3、技术选型 架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。 例如：Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql?是否需要采 用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？架构师对产品和技术的选 型只限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重 要

的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。 4、制定技术规格说明 架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通， 始终保证开发者依照它的架构意图去实现各项功能。架构师通过它制定的技术规格说明书(UML视图 、Word文档，Visio文件)与开发者沟通，保证开发者可以从不同角度去观察、理解各自承担的子系 统或者模块。架构师还需要与项目经理、需求分析员，甚至与最终用户保持沟通。

架构师的全面职责架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实 现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说 明进行指导和协调。 领导与协调整个项目中的技术活动(分析、设计和实施等) 推动主要的技术决策，并最终表达为软件构架 确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、 设计、实施和部署等―视图‖ 确定设计元素的分组以及这些主要分组之间的接口 为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并 保证相关决定被有效的传达和贯彻 理解、评价并接收系统需求 评价和确认软件架构的实现

架构师的素质要求从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程，必须要有 经验积累和素质培养。架构师要具备的素质有： 1、发挥团队作用的沟通能力 为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师 具有较强的沟通能力。 2、基于技术和知识的领导能力 架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。 架构师要保证这种执行力就需要具有领导能力。但架构师在项目里面可能更多地使用非正式 的领导力，即影响力，包括个人魅力、技术能力、知识传递等等。 3、抽象思维和逻辑分析能力 架构师必须具备抽象思维和逻辑分析的能力，才能看清系统的整体，掌控全局，形成大局 观。架构师不仅要有在问题领域上的经验，也需要有在软件工程领域内的经验，这样才能准 确的理解需求，用软件工程的思想，把需求转化和分解成可用计算机语言实现的程序。 4、拥有深度和广度的技术和知识 架构师必须精通面向过程和面向对象的基本概念和实施途径，具备这种技术能力才可以 更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响 力。架构师的技术知识广度也很重要，这样才可能综合各种

技术，选择更加适合项目的解决 方案。架构师应是项目团队中的技术权威。

软件系统架构要素 它是一个软件系统从整体到部分的最高层次的划分。 一个系统通常是由组件组成的，而这些组件如何形成、相互之间如何发生作 用，则是关于这个系统本身结构的重要信息。系统包括架构组件( Architecture Component)、连接器(Connector)、任务流(Task-flow)。 架构组件是组成系统的核心“砖瓦”,而连接器则描述这些 组件之间通讯的路 径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些组件和 连接器完成某一项需求。 它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的 决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎 重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。

软件架构的目标 可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要，因 此软件系统必须非常可靠。 安全性(Secure)。软件系统所承担的交易的商业价值极高，系统的安全性非 常重要。 可扩展性(Scalable)。软件必须能够在用户的使用率、用户的数目增加很快 的情况下，保持合理的性能，才能适应用户的市场扩展得可能性。 可定制化(Customizable)。同样的一套软件，可以根据客户群的不同和市场 需求的变化进行调整。 可延伸性(Extensible)。在新技术出现的时候，一个软件系统应当允许导入 新技术，从而对现有系统进行功能和性能的扩展 可维护性(Maintainable)。软件系统的维护包括两方面：1。排除现有的错 误，2。将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效 地降低技术支持的花费 客户体验(Customer Experience)。软件系统必须易于使用。 市场时机(Time to Market)。软件用户要面临同业竞争，软件提供商也要面 临同业竞争。以最快的速度争夺市场先机非常重要。

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

软件系统的逻辑架构图

软件架构的种类软件系统的物理架构图

物理架构： 软件元件是怎 样放到硬件上 的

软件架构的种类系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、 性能等。 系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架 构设计工作中最为困难的工作。 架构的两要素：元件划分和设计决定。 元件划分 一个软件系统中的元件首先是逻辑元件。这些逻辑

元件如何放到硬件上，以 及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等 做出贡献，是非常重要的信息。 设计决定 进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它 们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出， 就很难更改的。

架构设计的要素元件划分 一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上， 以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、 性能等做出贡献，是非常重要的信息。 设计决定 进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以 及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一 旦作出，就很难更改的。

构架重点视图可以表示系统的整体设计，但构架与以下几个具体方面相关： 模型的结构，即组织模式，例如分层。 基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。 几个关键场景，它们表示了整个系统的主要控制流程。 记录模块度、可选特征、产品线状况的服务。 构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突 出重要的特征。在考虑以下方面时，这些特征非常重要： 系统演进，即进入下一个开发周期。 在产品线环境下复用构架或构架的一部分。 评估补充质量，例如性能、可用性、可移植性和安全性。 向团队或分包商分配开发工作。 决定是否包括市售构件。 插入范围更广的系统。

Agenda 软件架构导引 业务建模 & UML 需求分析 软件架构视图 架构设计实践 架构设计模式 面向服务架构SOA

RUP – 统一开发过程

现

配置与变更管理 项目管理 环 境

监

控

业务建模 流程

业务建模过程过程评估业务状态 获取常用业务词汇 维护业务规则 评估目标组织 设定和调整目标 制定业务建模指南 关键工件 业务前景 目标组织评估 业务建模指南 业务词汇表 业务规则

说明当前业务评估目标组织 找出业务主角和用例 设定和调整目标 找出业务角色和实体

关键工件目标组织评估 业务用例模型 业务用例 补充业务说明

业务前景业务对象模型 业务用例实现 确定业务流程 维护业务规则 设定和调整目标 定义业务构架 获取常用业务词汇 找出业务主角和用例 关键工件 业务规则 业务前景 业务构架文档 业务词汇表 业务用例模型 业务用例 补充业务说明

本文来源：https://www.bwwdw.com/article/4b74.html