面向模式的软件架构-卷1_5(模式系统)

来源:互联网 发布:大数据岗位分类 编辑:程序博客网 时间:2024/05/27 01:13

卷一看完了

模式系统

模式系统:一个软件体系结构模式的汇集,它包括模式在软件开发中的实现,组合和实际使用的指南。

需要满足以下要求:

1)应该包括足够的基本模式

2)应该统一描述它所要的模式

3)应该揭示模式间的各种关系

4)应该组织它的组成模式

5)应该支持软件系统的构造

6)应该可以进行自我演化

                       

模式分类

分类要求:

1)分类图式应该是简单的易学的

2)分类图示应该包括少而精的分类标准

3)每个分类标准应该反映模式的自然属性

4)分类图示应该给用户提供一个路标

5)分类图示对于新模式的集成应该是开放的,不需要对分类进行重构

 

模式类别分类:

1.体系结构模式 2.设计模式 3.惯用法

 

问题类别分类

1.从混沌到结构:支持将系统任务分解成相互合作的子任务的模式

2.分布式系统: 为组件分布在不同进程中的系统或有组件分布在几个子系统和组件内的系统提供基本结构的模式

3.交互式系统: 用例帮助构建人机交互系统的模式

4.适应性系统:包括为应用程序的扩展和改进提供基本结构的模式

5.结构化分解:将子系统和复杂组件适当分解为相互合作部分的模式

6.工作的组织:定义组件怎样协作以提供一种复杂服务的模式

7.访问控制:防止与控制对服务和组件访问的模式

8.管理:用来对同类的对象、服务和组件的集合进行全面处理的模式

9.通信:有助于组件间组织通信的模式

10.资源处理 有助于管理共享组件和对象的模式

 

分类图示

 

体系结构模式

设计模式

惯用法

从混沌到结构

管道和过滤器

黑板

解释器

 

分布式系统

代理者

管道和过滤器

微核

 

 

交互式系统

MVC

PAC

 

 

适应性系统

微核

映像

 

 

创建

 

抽象工厂

原型

生成器

单件

工厂方法

结构化分解

 

整体-部分

组合

 

工作的组织

 

主控-从属

责任链

命令

中介者

 

访问控制

 

代理

外观

迭代器

 

服务变化

 

桥接

策略

模板方法

服务扩展

 

装饰

访问者

 

管理

 

命令处理器

视图处理程序

备忘录

 

适应

 

适配器

 

通信

 

出版者-订阅者

转发器-接收器

客户机-分配器-服务器

 

资源处理

 

享元

计数指针

其他部分模式也可以包含进来:反应器、客户机-服务器 可以用来构建分布式系统;组合消息可以用于通信 句柄-主体 可以用于访问控制。

 

模式选择的步骤

1.具体指定问题:精确描述问题

2.选择符合正在进行的设计活动的模式分类(限制适用的模式的数量)

3.根据设计问题的自然特性选择合适的问题分类(如果没有问题分类能够与具体的设计问题相匹配,尽可能选择可替换的问题分类)

4.比较问题描述(选择那些问题描述和强制条件和设计问题能够最佳匹配的模式)

5.比较优点和不足 如果有多个模式选择,需要挑选最便利,影响最小的

6.针对设计问题,选择可以最好的实现解决方案的变体(完成模式选择)

7.选择一个可替换的问题分类,如果没有合适的问题分类,或者被选择的问题分类不包含能够使用的模式,选择一个能够进一步概括设计问题的问题分类

 

模式和软件体系结构

软件体系结构:对子系统、软件系统组件以及它们之间相互关系的描述。(子系统和组件一般定义在不同的视图内,以显示软件系统的相关功能属性和非功能属性,系统的软件体系结构式一件人工制品)

 

组件:软件系统的一个封装部分,组件有一个外部接口(组件可以表示为模板、类、对象或者一组相关函数)

组件的类型:1、处理元素2、数据元素3、连接元素

另外一种分类:1、控制器组件2、协作者组件3、接口组件4、服务提供者组件5、信息持有者组件5、构造用组件。

 

关系:表示组件之间的连接,关系可以是静态或者动态的(聚合、继承是静态关系的例子;对象创建、)对象之间的通信和数据传输是动态的例子)组件之间的关系对软件体系结构的总体质量又很大的影响。

 

视图:代表一个软件体系结构的部分方面,这个部分方面专门显示一个软件系统的特定属性。

视图的分类一:1、概念上的体系结构(组件、连接器等)2、模块体系结构(子系统、模块、出口、入口等)3、代码体系结构(文件、目录、库、包含文件)4、执行体系结构(任务、线程、进程)。

分类二:1、逻辑视图(设计的对象模型或者实体关系图等)2、进程实体(并发与同步情况)3、物理视图(软件到硬件的映射及其分布式情况)4、开发视图(在软件开发环境中的软件静态组织)。

 

功能和非功能属性

功能属性:用来处理系统功能性的特定方面,并且通常与特定的功能需求相关。功能特性可与通过特定的功能使用户之间可看到应用程序,也可以通过它的实现来描述。

非功能属性:定义了未被功能属性描述覆盖的系统特征。一般包括:易操作性、互操作性、效率、可靠性、可测试性、可重用性

 

软件设计:以系统的软件体系结构为目标的软件开发者执行的活动,构造一个软件系统的整体活动。

 

软件体系结构中的模式

模式目标:1、使用某个特定方法解决一个问题要比使用其他方法好2、使用可预测的非功能属性建造软件系统。

模式与方法学:模式通过一组具体技术来补充现有的分析和设计方法,用于解决那些非常特别却又反复重现的设计问题。方法学:为建造高质量软件提供步骤和指南,模式使用方法学并进行扩展。

模式与软件过程:模式集成到一种增量式的提交过程中,使得工作更具预测性;另外一条经验:使用高层体系结构模式早于中层设计模式,惯用法在它们之后使用

 

软件体系结构的重要技术

1.抽象 层模式、抽象工厂

2.封装 转发器-接收器等

3.信息隐藏 整体-部分 映像

4.模块化 层模式,管道与过滤器,整体与部分

5.事务分离

6.耦合和内聚 出版者-订阅者 客户机-分配器-服务器

7.充分性、完整性、原始性 策略模式 (充分:组件应该捕获抽象的交互需要的特性,完整:组件应该捕获其抽象的全部特性,原始:组件能够执行的所有操作应该都是容易实现的)

8.策略与实现分离 软件体系结构尽量将策略和实现分成不同的组件,如果不能,可以在组件内对策略和实现的功能特性进行分离(策略模式)

9.接口与实现的分离 任何组件应由接口和实现两部分组成,接口定义组件的功能并说明如何使用,实现为组件为功能实现通过的代码,不可被用户访问(桥接模式)

10.单一引用点:软件系统内的任何条码都应该仅仅被声明和定义一次

11.分而治之

 

软件体系结构的非功能属性

1.易修改性: 1)可维护性,软件体系结构往往能够进行局部性修改而对其他组件负面影响最小化2)可扩展性,软件系统需要松散耦合的组件,能够在不影响组件客户的情况下替换,也支持新组件的集成 3)可移植性 按照硬件无关的方式组织软件系统 4)结构重组 重新组织软件体系结构的组件和组件的关系,支持在不影响主体部分的情况下灵活的配置组件。

2.互操作性 软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口

3.效率 效率不仅涉及算法,对于组件及其耦合,恰当的分配责任也很重要(设计模式一般都会引入中间层,降低效率)

4.可靠性 在应用或系统错误面前,在意外或错误使用的情况下维持软件系统功能特性的基本能力1、容错 2、健壮性

5.可测试性

6.可重用性