Textbook

第一章软件体系结构概论

软件危机

表现
1、软件成本日益增长。
2、开发进度难以控制。
（用户需求变化等意想不到的原因）
3、软件质量差。
（程序员习惯以自己的想法替代用户需求）
4、软件维护困难。
（缺标准，开发人员的流失，软件修改十分“危险”很容易出bug）
原因
1、用户需求不明确。
（用户不清楚具体需求，用户需求有遗漏、二义甚至错误，用户需求变化，开发者与用户之间理解的差异）
2、缺乏正确、全面的理论指导。
（软件开发过分依赖开发者的高度智力投入，以及技巧与创造性。使得软件开发个性化强）
3、软件规模越来越大。
（大型项目需要团队共同完成，而团队之间不一定能有效协作）
4、软件复杂度越来越高。
克服方法
探索用工程的方法进行软件生成的可能性，即用现代工程概念、原理、技术和方法进行计算机软件开发、维护和管理。
软件工程：用工程、科学和数学的原则与方法，研制和维护计算机软件的有关技术以及管理方法。

软件重用

概念：在两次货多次不同的软件开发过程之中，重复使用相同或相近的软件元素的过程。

构件

概念

可重用的软件元素：
程序代码，测试用例，设计文档，设计过程，需求分析，领域知识。
可重用构件：语义完整、语法正确和有重用价值的单位软件。
粒度：可重用软件元素的大小。
构件的3C模型
1、概念（Concept）-构件做什么的描述
2、内容（Content）-构件如何实现概念
3、语境（Context）-描述构件的应用场景以及修改指导。

构件获取

领域：一组相似或相近软件需求的应用系统所覆盖的功能区域。
领域工程：领域分析，领域设计，领域实现等。

构件管理

种类
1、构件描述：方便搜寻
2、构件分类：方便管理
3、构件库组织：方便管理与搜寻
4、人员及权限管理：安全性
5、用户意见反馈：方便迭代开发
构件描述
对构件的制作和重用提供依据以及方便管理。
如：实现方式，编程语言，注释，生产日期，价格等。
构件分类方法
1、关键字分类法：每个概念用一个描述性关键字表示。
2、刻面分类法：定义一些刻画构件特征的“面”（3C模型中的概念），通常不超过七八个刻面。
eg. 青鸟构件库的刻面分类：使用环境，应用领域，功能，层次，表示方法。
3、超文本组织方法。
构件种类
1、独立而成熟的构件。
2、有限制的构件。
3、适应性构件。
4、装配构件。
（要使用胶水代码进行连接使用）
5、可修改的构件。
（开发中使用得多）

基于构件的软件开发

优势：降低开成本，缩短开发时间。
劣势：兼容性，独创性缺失从而竞争力下降。对构件提供者的依赖性。
获取构件的途径：
1、在现有构件中搜寻，直接使用或修改后使用。
2、通过遗留工程，将有重用价值的构件重组后使用。
3、从市场上购买现成的商业构件COTS（Commercial Off-The-Shell）
4、开发新构件。
构件重用
可重用构件的特殊要求
1、功能上独立与完整。
2、通用性高，灵活。
3、稳定性高，质量保证。
4、标准化程度高。
应用广泛的构件技术规范
CORBA（Common Object Request Broker Architecture）通用对象请求代理结构；
OMG（Object Management Group）对象管理组织；
EJB（Enterprise Java Bean）Sun公司；
DCOM（Distributed Component Object Model）分布式构件对象模型 Microsoft；
它们都实现了接口对象的分离，提供了构件交互能力。

软件体系结构

概念：是在处理算法与数据结构之上的，关于整体系统结构设计和描述方面的问题。是软件系统的一个结构、行为和熟悉的高级抽象。（除了概念的组织结构与系统的拓扑结构外，还有系统需求与元素的对应关系。）
重设计重用。
软件体系结构组成部分：
1、构件（Component）：一组代码，或程序块或一个独立的程序。（如SQL服务器）
2、连接件（Connector）：关系的抽象，用以表示构件之间的相互作用。（如过程调用、管道等）
3、配置（Configuration）：用于对构件与连接件的语义说明。
4、端口：表示构件与外部环境的交互点。
5、角色：连接件的接口。

软件体系结构核心模型

软件体系结构的意义
1、是系统开发中不同参与者进行交流和信息传播的媒介。
2、是早期设计决策的体现。
3、可以反映软件的的质量以及瓶颈。
4、本身也是一种可传递可重用的模型。
软件体系结构应用现状
1、ADL（Architecture Description Language）软件体系结构描述语言：描述体系结构的概念框架。（C2，Wright，Aesop，Unicon等）
优秀的ADL的特性：组装性，抽象性，重用性，可配置性，异构性，可分析性等。
2、软件体系结构描述构造与表示：用一定描述方法，对体系结构进行描述。
eg. “4+1”模型：由逻辑视图，开发视图，过程视图，和物理视图组成。用应用场景将这4个有机结合起来。比较细致地描述了需求和体系结构之间的关系。
3、体系结构的设计、分析与验证：如何将系统分解成相应的组成成分（构件，连接件）
eg. 风格设计。结构分析，功能分析，非功能分析。
4、体系结构的发现、演化与重用：对已有的系统，提取体系结构等。
5、基于体系结构等软件开发；
6、特定领域的体积结构；
7、软件体系结构的支持工具：软件体系结构的支持工具。
8、软件产品线体系结构：提高重用性。
9、建立软件体系结构的方法；
软件体系结构的研究与应用之中的不足之处：
1、缺乏统一的软件体系结构概念，导致软件体系结构的研究范围模糊。
2、ADL繁多，缺乏统一的ADL标准。
3、软件体系结构研究缺乏统一的理论模型支持。
4、市面上的多种标准规范或建议标准不易于操作。
5、软件体系结构性质的研究尚不充分，不能明确给出一个良好的体系极高的属性或评断标准，也没有给出良好体系就高的设计指导原则，因此对于软件开发实践缺乏有力的促进作用。
6、缺乏有效的支持环境，以及软件体系结构理论研究与环境支持不同步，缺乏有效的体系结构分析、设计、方针和验证工具支持，导致体系结构应用困难。
7、缺乏有效的体系结构复用方案。
8、体系结构发现方法研究相对欠缺。

第二章软件体系结构建模

软件体系结构模型：

1、结构模型：最直观最普遍的建模方法，通过体系结构的构件、连接件和其他概念来刻画结构；力图通过结构，来反映系统的重要语义内容。
包括：系统的配置，约束，隐含的假设条件，风格，性质。
2、框架模型：与结构模型类似，但不侧重结构的细节，而侧重整体的结构。主要以一些特殊的问题作为目标，建立只针对和适应这类问题的结构。
3、动态模型：对结构或框架模型的补充，研究系统的“大粒度”的行为及其性质。如系统总体结构的配置或演化、通信通道或计算过程的建立或拆除等方面的行为。
4、过程模型：研究构造系统的步骤与过程，因而其机构是遵循某些脚本的结果。
5、功能模型：体系机构的一组功能构件，按照层次组成，下层向上层提供服务，可以看作为一种特殊的框架模型。