软件架构与设计模式_2

《软件架构与设计模式_2》由会员分享，可在线阅读，更多相关《软件架构与设计模式_2（134页珍藏版）》请在金锄头文库上搜索。

1、软件架构与设计模式曾令秋 博士、副教授 2014年4月,1. 软件架构 软件架构定义 架构设计方法与过程 软件架构的设计要点 2. 模式简介 模式的定义 模式的分类 3. 常用模式 从混沌到结构 分布式基础设施 事件多路分离和分派 接口分割 组件分割 4. 典型面向服务的架构SOA,2,目录,1. 软件架构,1.1 架构定义,软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构，Garlan & Shaw模型的基本思想是：软件体系结构=构件(component)、连接件(connector)和约束(constrain)： 构件可以是一组代码，如程序的模块；也可以是一个独立的程序； 连接

2、件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用； 约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。,4,架构定义,软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。,5,例: ACE的分层架构,6,架构的范围,软件架构本门课程的主关注点。硬件架构包括CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。组织架构是一些关于商业进程，组织结构，

3、规则和职责，与组织核心能力的部分。信息架构包含组织好的信息结构。软件架构、硬件架构、组织架构和信息架构是全部系统架构的子结构。企业架构与系统架构很相似，包括硬件，软件，人员等。,7,企业架构师EA (Enterprise Architect) 的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title是首席软件架构师，实际上就是EA角色;基础结构架构师IA (Infrastructure Architect) 的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些是技术型公司传承下来的最宝贵的财富;特定技术架构师TSA (Technology-Speci

4、fic Architect)主要从事类似安全架构、存储架构等专项技术的规划和设计工作;解决方案架构师SA (Solution Architect)的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。软件架构师基本上是EA+TSA+IA,是程序员向上发展的道路,系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。,架构师分类,8,1.2 架构设计基本过程,概念化阶段,分析阶段,架构设计阶段,并行开发和测试阶段,验收与交互阶段,愿景,需求,架构,可执行系统,交付的系统,9,架构设计基本过程,分析阶段

5、,需求分析,领域建模,确定关键需求,概念性架构设计,细化架构,验证架构,架构设计阶段,10,软件需求,需求 系统必须满足的情况或提供的能力. 可以直接来自客户需要, 也可以来自合同,标准,规范或其他有正规约束力的文档,软件需求,功能需求,非功能需求,质量属性,约束,运行期质量属性,开发期质量属性,11,软件系统架构要素 它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由组件组成的，而这些组件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。系统包括架构组件、连接器、任务流。架构组件是组成系统的核心“砖瓦”，而连接器则描述这些 组件之间通讯的路径、通讯的机制、通讯的

6、预期结果，任务流则描述系统如何使用这些组件和连接器完成某一项需求。它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。,1.3 软件架构的设计要素,12,软件架构的目标,可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非 常重要。可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能，

7、才能适应用户的市场扩展得可能性。 可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。,13,软件架构的目标,可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展；可维护性（Maintainable）。软件系统的维护包括两方面：1。排除现有的错 误，2。将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效 地降低技术支持的花费客户体验（Customer Experience）。软件系统必须易于使用。市场时机（Time to Market）。软件用户要面临同业竞争，软件提供

8、商也要面 临同业竞争。以最快的速度争夺市场先机非常重要。,14,软件架构的种类,软件系统的逻辑架构图,逻辑架构： 软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等,15,软件架构的种类,物理架构： 软件元件是怎样放到硬件上的,软件系统的物理架构图,16,软件架构的种类,系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、 性能等。 系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架 构设计工作中最为困难的工作。架构的两要素：元件划分和设计决定。 元件划分 一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以 及这些元件

9、如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等 做出贡献，是非常重要的信息。 设计决定 进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它 们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出， 就很难更改的。,17,视图可以表示系统的整体设计，但构架与以下几个具体方面相关：模型的结构，即组织模式，例如分层。 基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。 记录模块度、可选特征、产品线状况的服务。 构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突 出重要的特征。在考虑以下方

10、面时，这些特征非常重要： 系统演进，即进入下一个开发周期。 在产品线环境下复用构架或构架的一部分。 评估补充质量，例如性能、可用性、可移植性和安全性。 向团队或分包商分配开发工作。 决定是否包括市售构件。 插入范围更广的系统。,构架重点,18,2. 模式 Pattern,19,模式简介,要素 背景 context 问题 problem 作用力 (约束) force 解决方案 solution,20,2.1 模式定义,POSA1的定义: A pattern for software architecture describes a particular recurring design prob

11、lem that arise in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by its constituent components, their relationships, and the ways in which they collaborate.,21,模式的特性,最佳实践的记录,更高一级的抽象,设计的公共词汇表,记录软件架构的工具,支持具有良好属性的软件构建,与项目细节, 实现方法,

12、编程语言无关,22,例子：简单的模式Explicit Interface (显式接口),背景 软件架构工作的主要关注点之一: 有效恰当地表述组件接口,问题 一个组件代表一个自含的功能单位及其发布的使用契约. 客户可以使用它来建立自己的功能, 但是直接访问组件的完全实现, 则会导致客户依赖组件的内部表示, 最终增加了应用程序内部的耦合度,作用力(force) 客户只能依赖组件发布的接口, 对实现的修改不能影响客户 客户不倚赖组件的地理位置 组件提供的方法对客户有意义, 能有效正确使用,将组件接口的声明与实现分离, 只对客户曝露组件接口, 同时隐藏实现和位置,23,Method _B,method

13、 _A,Explicit Interface (显式接口),method _B _imp,method _A_ imp,客户,接口,实现,多态分派,组件,24,误解与陷阱,企图将所有软件开发活动和工件变成模式,企图将每个新颖的和复杂的设计贴上模式的标签,将模式看成一些固定不变的事物: 如特定的类配置,将模式看作编码指南,有限或误解的模式词汇导致对给定问题使用了错误的模式,企望机械应用模式就可以得到精致的架构,25,误解与陷阱,企图在需要新思想的软件开发中使用现成模式,对模式如何起作用以及怎样起作用企望过高,企图完全基于自动化工具使用模式,将模式当作组件的简单集合,认为基于模式的设计排斥或替代重

14、构,26,2.2 模式分类,按粒度分类 架构, 设计, 惯用法 按效果好坏分类 模式, 反模式 按问题域(使用目的)分类 (以分布式计算为例) 从混沌到结构 分布式基础设施 事件多路分离和分派 接口分割 组件分割,27,应用程序控制 并发 同步 对象交互 适配与扩展 模态(modal)行为 资源管理 (对象生命周期管理) 数据库访问,3. 常用模式,28,常用模式,从混沌到结构 分布式基础设施 事件多路分离和分派 接口分割 组件分割 应用程序控制 并发 同步 对象交互 适配与扩展 模态(modal)行为 资源管理 数据库访问,29,3.1 从混沌到结构,30,3.1 从混沌到结构,从混沌到结构

15、 将需求和约束转换为粗粒度的软件结构 各部分定义清晰,可操作 抽象与划分, 忽略细节 关注 性能, 持续可用性 可扩展性, 可维护性 支持变化,31,3.1 从混沌到结构,领域建模 满足应用领域的功能性需求, 同时适应变化 功能属性 业务流程 业务算法选择,Domain Model,32,Domain Model (领域模型),背景 为应用建立初始结构,问题 需求和约束只是隐含了功能, 但还不能为应用提供直接具体的开发结构 对系统范围和应用领域缺乏精确和合理的洞见, 会使实现成为一团烂泥,难于理解, 难于开发, 不易交付,作用力(force) 需求列表只是应用的问题域, 而不是解域, 需要映射

16、为软件实体,建立一个模型, 定义系统的业务职责范围以及可能的变化:模型元素是对应用领域的概念抽象, 它们的角色和交互反映了应用领域的工作流,33,从混沌到结构,分解领域模型 应用与环境怎样交互? 应用怎样处理数据? 应用支持什么变化? 应用的预期生命周期如何?,34,Domain Model (领域模型),内部划分,数据流处理,数据驱动处理,系统演进,用户界面 变化,功能变化,远程通信,Domain Model,Domain Object,Pipes and Filters,35,Layers (分层),背景 必须支持系统的不同部分独立开发和演进,问题 由于受系统大小, 上市时间等需求约束, 需要考虑系统不同部分的独立开发和演进 如果系统架构不能清晰合理分离关注点, 则各部分的交互得不到很好的支持, 也不能独立开发,作用力(force) 如何寻求平衡,能够 合理划分系统, 使各部分可以独立开发和部署 不陷于细节的泥淖,