基于体系结构的软件开发

设计模式 – 概述

模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。
一个软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。

设计模式 – MVC模式

设计模式 – 好的设计模式具备的特征

解决一个问题：从模式可以得到解，而不仅仅是抽象的原则或策略。
是一个被证明了的概念：模式通过—个记录得到解．而不是通过理论或推测。
解并不是显然的：许多解决问题的方法（例如软件设计范例或方法）是从最基本的原理得到解；而最好的方法是以非直接的方式得到解，对大多数比较困难的设计问题来说，这是必要的。
描述了一种关系：模式并不仅仅描述模块，它给出更深层的系统结构和机理。
模式有重要的人为因素：所有的软件服务于人类的舒适或生活质量，而最好的模式追求它的实用性和美学。

设计模式 – 基本成分

模式名称
问题
解决方案
后果

设计模式 – 描述

（1）模式名称和分类
（2）目的
（3）别名
（4）动机
（5）应用
（6）结构
（7）成分
（8）合作
（9）后果
（10）实现
（11）例程代码
（12）已知的应用
（13）相关模式

设计模式 – 模式与体系结构

模式作为体系结构构造块
构造异构体系结构
模式和方法
实现模式

设计模式 – 层次

Coad的面向对象模式
代码模式
框架应用模式
形式合约

设计模式 – 分类

设计模式 – MVC模式的设计与实现 – 框架

设计模式 – MVC模式的设计与实现 – 应用

设计模式 – MVC模式的设计与实现 – 类图

设计模式 – MVP模式

中间件技术 – 中间件的功能

负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
提供一个多层体系结构的应用开发和运行的平台，以及一个应用开发框架，支持模块化的应用开发。
屏蔽硬件、操作系统、网络和数据库的差异。
提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

中间件技术 – 中间件的分类

底层中间件：JVM（Java Virtual Machine，Java虚拟机）、CLR（Common Language Runtime，公共语言运行库）、ACE（Adaptive Communication Environment，自适配通信环境）等
通用型中间件：也称为平台，其主流技术主要有RPC、ORB、MOM（Message-Oriented Middleware，面向消息的中间件）等
集成型中间件：WorkFlow、EAI等

中间件技术 – 中间件的发展趋势

规范化。规范的建立极大地促进了中间件技术的发展，同时保证了系统的扩展性、开放性和互操作性。
构件化和松耦合。基于XML和Web Service的中间件技术，使得不同系统之间、不同应用之间的交互建立在非常灵活的基础上。
平台化。一些大的中间件厂商在已有的中间件产品基础上，提出了完整的面向互联网的软件平台战略计划和应用解决方案。

中间件技术 – 中间件与构件的关系

面向需求
业务的分隔和包容性
设计与实现隔离
隔离复杂的系统资源
符合标准的交互模型
软件复用
提供对应用构件的管理

ABSD方法 – 基本概念

ABSD方法为产生软件系统的概念体系结构提供构造，概念体系结构描述了系统的主要设计元素及其关系。概念体系结构代表了在开发过程中作出的第一个选择，相应地，它是达到系统质量和商业目标的关键，为达到预定功能提供了一个基础。
体系结构驱动，是指构成体系结构的商业、质量和功能需求的组合。
使用ABSD方法，设计活动可以在体系结构驱动一决定就开始，这意味着需求抽取和分析还没有完成，就开始了软件设计。设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时，例如产品线系统或长期运行的系统，快速开始设计是至关重要的。
软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能的例子有：每个元素必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。

ABSD方法 – ABSD方法与生命周期

体系结构的设计与演化 – 设计与演化过程

实验原型阶段。这一阶段考虑的首要问题是要获得对系统支持的问题域的理解。为了达到这个目的，软件开发组织需要构建一系列原型，与实际的最终用户一起进行讨论和评审，这些原型应该演示和支持全局改进的实现。但是，来自用户的最终需求是很模糊的，因此，整个第一个阶段的作用是使最终系统更加精确化，有助于决定实际开发的可行性。
演化开发阶段。实验原型阶段的结果可以决定是否开始实现最终系统，如果可以，开发将进入第二个阶段。与实验原型阶段相比，演化开发阶段的重点放在最终产品的开发上。这时，原型即被当作系统的规格说明，又可当作系统的演示版本。这意味着演化开发阶段的重点将转移到构件的精确化。

体系结构的设计与演化 – 实验原型阶段 – 第一个开发周期

第一个开发周期没有具体的、明确的目标。此时，为了提高开发效率，缩短开发周期，所有开发人员可以分成了两个小组，一个小组创建图形用户界面，另一个小组创建一个问题域模型。两个小组要并行地工作，尽量不要发生相互牵制的现象。
在第一个周期结束时，形成了两个版本，一个是图形用户界面的初始设计，另一个是问题域模型，该模型覆盖了问题域的子集。用户界面设计由水平原型表示，也就是说，运行的程序只是实现一些用户界面控制，没有实现真正的系统功能。

体系结构的设计与演化 – 实验原型阶段 – 第二个开发周期

标识构件
提出软件体系结构模型
把已标识的构件映射到软件体系结构中
分析构件之间的相互作用
产生软件体系结构
软件体系结构正交化

体系结构的设计与演化 – 演化开发阶段

需求变动归类
制订体系结构演化计划
修改、增加或删除构件
更新构件的相互作用
产生演化后的体系结构
迭代
对以上步骤进行确认，进行阶段性技术评审
对所做的标记进行处理

ABSDM – 开发模型

ABSDM – 体系结构文档化

文档是在系统演化的每一个阶段，系统设计与开发人员的通讯媒介，是为验证体系结构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。
体系结构文档化过程的主要输出结果是体系结构需求规格说明和测试体系结构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
软件体系结构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。

ABSDM – 体系结构复审

体系结构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
由外部人员进行复审的目的是保证体系结构的设计能够公正地进行检验，使组织的管理者能够决定正式实现体系结构。