软件体系结构知识点-复习概要：[4]

第4章软件体系结构描述和设计

1．软件体系结构描述方法的种类：(a)图形表达工具（特点：简洁易懂、容易使用、使用广泛、不规范、不精确。）；(b)模块内连接语言（采用将一种或几种传统程序设计语言的模块连接起来的模块内连接语言（MIL）。MIL方式对模块化的程序设计和分段编译等程序设计与开发技术确实发挥了很大的作用。但是由于这些语言处理和描述的软件设计开发层次过于依赖程序设计语言，因此限制了它们处理和描述比程序设计语言元素更为抽象的高层次软件体系结构元素的能力。）；(c)基于软件构件的系统描述语言（基于软构件的系统描述语言将软件系统描述成一种是由许多以特定形式相互作用的特殊软件实体构造组成的组织或系统。这种表达和描述方式虽然也是较好的一种以构件为单位的软件系统描述方法，但是他们所面向和针对的系统元素仍然是一些层次较低的以程序设计为基础的通信协作软件实体单元，而且这些语言所描述和表达的系统一般而言都是面向特定应用的特殊系统，这些特性使得基于软构件的系统描述仍然不是十分适合软件体系结构的描述和表达。）；(d)软件体系结构的描述语言（软件体系结构的描述语言（ADL）是在吸收了传统程序设计中的语义严格精确的特点基础上，针对软件体系结构的整体性和抽象性特点，定义和确定适合于软件体系结构表达与描述的有关抽象元素，因此，ADL是当前软件开发和设计方法学中一种发展很快的软件体系结构描述方法。）。

2．ADL（体系结构描述语言）提供了具体的语法与刻画体系结构的概念框架。ADL使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析。

3．IEEE P1471于2000年9月21日通过IEEE-SA标准委员会评审。IEEE P1471适用于软件密集的系统，其目标在于：便于体系结构的表达与交流，并通过体系结构要素及其实践标准化，奠定质量与成本的基础。

4．基于RUP（Rational United Process）、采用UML模型描述软件的体系结构，认为体系结构描述的关键是定义视点、视图以及建模元素之间的映射关系。与IEEE P1471相比，该建议标准的体系结构描述方案涉及面比较窄，所注重的层次比较低，因而更具体。由于将体系结构的描述限于UML和RUP，具有一定的局限性，但该建议标准结合了业界已经广泛采用的建模语言和开发过程，因而易于推广，可以有效实现在跨组织之间重用体系结构描述结果。

5．ADL与传统程序设计语言的比较：(a)构造能力：ADL能够使用较小的独立体系结构元素来建造大型软件系统；

(b)抽象能力：ADL使得软件体系结构中的构件和连接件描述可以只关注它们的抽象特性，而不管其具体的实现细节；(c)重用能力：ADL使得组成软件系统的构件、连接件甚至是软件体系结构都成为软件系统开发和设计的可重用部件；(d)组合能力：ADL使得其描述的每一系统元素都有其自己的局部结构，这种描述局部结构的特点使得ADL支持软件系统的动态变化组合；(e)异构能力：ADL允许多个不同的体系结构描述关联存在；(f)分析和推理能力：ADL允许对其描述的体系结构进行多种不同的性能和功能上的多种推理分析。

ADL与需求语言的区别：后者描述的是问题空间，而前者扎根于解空间。

ADL与建模语言的区别：后者对整体行为的关注要大于对部分的关注，而ADL集中在构件的表示上。

6．ADL的构成要素：(1)构件：一个计算单元或数据存储；是计算与状态存在的场所；(2)连接件：用来建立构件间的交互以及支配这些交互规则的体系结构构造模块；(3)体系结构配置或拓扑：描述体系结构构件与连接件的连接图。

7．软件体系结构的设计在需求分析之后，软件设计之前。描述好体系结构，做好承上启下的工作很重要。一方面：体系结构描述如何向其他文档转移；另一方面：如何利用需求分析成果来直接生成系统的体系结构说明。

8．C2概述：在C2中，连接件负责构件之间消息的传递，而构件维持状态、执行操作并通过两个名字分别为“top”和“bottom”的端口和其它的构件交换信息。每个接口包含一种可发送的消息和一组可接收的消息。构件之间的消息要么是请求其它构件执行某个操作的请求消息，要么是通知其他构件自身执行了某个操作或状态发生改变的通知消息。构件之间的消息交换不能直接进行，而只能通过连接件来完成。每个构件接口最多只能和一个连接件相连，而连接件可以和任意数目的构件或连接件相连。请求消息只能向上层传送而通知消息只能向下层传送。通知消息的传递只对应于构件内部的操作，而和接收消息的构件的需求无关。

9．UML(Unified Modeling Language)是一种用可视化方法对软件系统进行描述、实施和说明的标准语言。支持用不同实现技术进行的软件开发全过程。

10．UML包括的九种图：(a)静态图：用例图、类图、对象图、构件图、部署图；(b)动态图：顺序图、协作图、状态图、活动图。

11．UML的四层元模型体系结构：(a)元-元模型层定义了元模型层的规格说明语言；(b)元模型层为给定的建模语言定义规格说明；(c)模型层用来定义特定软件系统的模型；(d)用户对象用来构建给定模型的特定实例。

12．XML(extensible markup language)可扩展标记语言主要是一种数据描述方法。XML的技术主要有三个：Schema、XSL和XLL。

13．体系结构设计的基本原则：(a)抽象；(b)分而治之；(c)封装和信息隐藏；(d)模块化；(e)高内聚和低耦合；(f)注意点分离；(g)策略和实现的分离；(h)接口和实现的分离。

14．体系结构设计方法的元模型：(1)第一阶段：捕捉需求（客户：表示那些关心软件体系结构设计的系统相关人员。包括：客户、最终用户、系统开发人员、系统维护人员、销售人员等。领域知识：表示在解决某一问题中所应用的知识的范围。需求规格说明：表示规格说明，描述了所要开发的体系结构系统的需求。）；(2)第二阶段：提取解决方案的结构（需求规格说明、领域知识。工件：表示某一方法的工件描述。这是指诸如工件类、工件操作、工件属性等。一般，每种工件都有一套与之相关的试探法，用来标识相关的工件实例。解决方案抽象：定义了体系结构中（子）结构的概念表示。）；(3)第三阶段：体系结构规格说明（解决方案抽象、领域知识。体系结构描述：定义了软件体系结构的规格说明。）。

15．体系结构设计方法的类型：(a)工件驱动（artifact-driven）的方法（缺点：(a)文本形式的系统需求不够清楚、精确、完整。以它作为导出体系结构抽象的来源作用不够；(b)子系统的语义过于简单，难以作为体系结构构件；(c)对子系统的组合支持不足。）；(b)用例驱动（use-case-driven）的方法（缺点：(a)难以适度把握领域模型和商业模型的细节；(b)对于如何选择与体系结构相关的用例没有提供系统的支持；(c)用例没有为体系结构抽象提供坚实的基础；(d)包的语义过于简单，难以作为体系结构构件。）；(c)模式驱动（pattern-driven）的方法（缺点：(a)在处理范围广泛的体系结构问题时，模式库可能不够充分；(b)对模式的选择仅依靠通用知识和软件工程师的经验；(c)模式的应用并不是一个简单直接的过程，它需要对问题进行全面的分析；(d)对于模式组合没有提供很好的支持。）；(d)域驱动（domain-driven）的方法（缺点：(a)问题领域分析在导出体系结构抽象方面效果较差；(b)解决方案领域分析不够充分。）。

16．小结：（1）工件驱动的方法中，体系结构抽象被表示为分组的工件，它们是从需求规格说明导出的；用例驱动的体系结构设计方法从用例模型导出体系结构抽象，用例模型表示了系统预期要实现的功能；模式驱动的体系结构设计方法试图通过从去定义的模式库中选择体系结构模式来开发体系结构；领域驱动的体系结构设计方法从领域模型导出体系结构抽象。（2）每种方法都有不足之处，总的说来，可以总结为如下几点：(a)在规划体系结构设计阶段所遇到的困难；(b)客户需求不是体系结构抽象的稳固基础；(c)难以适度控制领域模型；(d)体系结构抽象的语义能力不足；(e)对组合体系结构抽象的支持不足。