系统分析师学习笔记（十三）

软件架构设计

构件与软件复用

构件（component）也称为组件，是一个功能相对独立的具有可复用价值的软件单元。在OO方法中，一个构件由一组对象构成，包含了一些协作的类的集合，它们共同工作来提供一种系统功能。

可复用性（可重用性）是指系统和（或）其组成部分能在其他系统中重复使用的程度。软件复用的形式可分为垂直式复用和水平式复用。水平式复用是复用不同应用领域中的软件元素，例如，数据结构、排序算法、人机界面构件等。标准函数库是一种典型的原始的水平式复用机制；垂直式复用是在一类具有较多公共性的应用领域之间复用软件构件。

主流构件标准

目前，主流的构件标准有OMG（Object Management Group，对象管理集团）的CORBA、Microsoft的COM（Component Object Model，构件对象模型）和DCOM（Distributed Component Object Model，分布式构件对象模型）和Sun的EJB（Enterprise JavaBean，Java 企业Bean）。

1.CORBA
CORBA技术规范，主要内容包括接口定义语言（Interface Definition Language，IDL）、接口池（Interface Repository，IR）、动态调用接口（Dynamic Invocation Interface，DII）和对象适配器（Object Adapter，OA）等。

（1）接口定义语言。IDL是CORBA规范中定义的一种中性语言，它用来描述服务器对象（向调用者提供服务的对象）的接口，而不涉及对象的具体实现。IDL本身也是面向对象的，它虽然不是编程语言，但它为客户对象（发出服务请求的对象）提供了语言的独立性，因为客户对象只需了解服务器对象的IDL接口，而不必知道其编程语言。CORBA还定义了IDL到C、C++、SmallTalk和Java语言的映射。
（2）接口池。IR包括分布式计算环境中所有可用的服务器对象的接口表示，它使动态搜索可用服务器的接口、动态构造请求及参数成为可能。
（3）动态调用接口。DII提供了一些标准函数以供客户对象动态创建请求和构造请求参数。客户对象将DII与IR配合使用，可实现服务器对象接口的动态搜索、请求及参数的动态构造与动态发送。当然，只要客户对象在编译之前能够确定服务器对象的IDL接口，CORBA也允许客户对象使用静态调用机制。静态机制的灵活性虽不及动态机制，但执行效率却胜过动态机制。
（4）对象适配器。OA用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便它们使用ORB内部的某些功能，例如，服务器对象的登录与激活、客户请求的认证等。

CORBA定义了一种面向对象的构件开发方法，使不同的应用系统可以共享构件。每个对象都将其内部操作细节封装起来，同时又向外界提供精确定义的接口，从而降低了应用系统的复杂性，也降低了软件开发费用。

2.EJB
EJB是用于开发和部署多层结构的、分布式的、面向对象的Java应用系统的跨平台的构建架构。使用EJB编写的应用程序具有可扩展性和交互性，以及多用户安全的特性。这些应用只需要写一次，就可以发布到任何支持EJB规范的服务器平台上。

3.COM/DCOM
Microsoft的COM定义了构件和它们的客户之间互相作用的方式，使得构件和客户端无需任何中介构件就能相互联系。DCOM扩展了COM，使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通信。

构件获取与管理

1.构件的获取
在基于构件的软件开发中，可以通过多种不同的途径来获取构件：

（1）从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件。
（2）通过遗留工程（legacy engineering），将具有潜在复用价值的构件提取出来，得到可复用的构件。
（3）从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件。
（4）开发新的符合要求的构件。

企业或项目组在进行以上决策时，必须考虑到不同方式获取构件的一次性成本和以后的维护成本（直接成本和间接成本），然后做出最优的选择。

2.构件的组织
可复用技术对构件库组织方法的要求是：

（1）支持构件库的各种维护动作，例如，增加、删除或修改构件，尽量不要影响构件库的结构。
（2）不仅要支持精确匹配，还要支持相似构件的查找。
（3）不仅能进行简单的语法匹配，而且能够查找在功能或行为方面等价或相似的构件。
（4）对应用领域具有较强的描述能力和较好的描述精度。
（5）库管理员和用户容易使用。

目前，已有的构件分类方法大致可以归纳为三大类，分别是关键字分类法、刻面（facet）分类法和超文本组织方法。

（1）关键字分类法。关键字分类法将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构，每个概念用一个描述性的关键字表示。当在构件库中加入新的构件时，库管理员必须对构件的功能或行为进行分析，在浏览已有关键字分类结构的同时，将新构件置于最合适的原子级关键字之下。如果无法找到构件的属主关键字，则可以扩充现有的关键字分类结构，引进新的关键字。
（2）刻面分类法。刻面分类法定义若干用于刻画构件特征的“刻面”，每个面包含若干概念，这些概念描述构件在刻面上的特征。刻面可以描述构件执行的功能、被操作的数据、构件应用的语境或其他特征。描述构件的刻面集合称为刻面描述符，一般而言，刻面描述符不超过7个刻面。
（3）超文本方法。与基于数据库系统的构件库组织方法不同，超文本方法基于全文检索技术，其主要思想是：所有构件必须辅以详尽的功能或行为说明文档；说明中出现的重要概念或构件以网状链接方式相互连接；检索者在阅读文档的过程中可按照人类的联想思维方式任意跳转到包含相关概念或构件的文档；全文检索系统将用户给出的关键字与说明文档中的文字进行匹配，实现构件的浏览式检索。超文本组织方法为开发和复用构件提供了直观的多媒体方式。由于网状结构比较自由、松散，因此，超文本方法比前两种方法更易于修改构件库的结构。

3.人员及权限管理
一般来说，构件库系统可包括五类用户，分别是注册用户、公共用户、构件提交者、普通管理员和超级管理员，他们对构件库分别有不同的职责和权限，这些人员相互协作，共同维护着构件库系统的正常运作。同时，系统为每种操作都定义一个权限，包括提交构件、管理构件、查询构件和下载构件等，每个用户可被赋予其中一项或多项操作权限。

构件复用的方法

1.检索与提取构件

（1）基于关键字的检索。系统在图形用户界面上将构件库的关键字树形结构直观地展示给用户，复用者通过对树形结构的逐级浏览，寻找需要的关键字并提取相应的构件。当然，复用者也可以直接给出关键字（其中可含通配符），由系统自动给出合适的候选构件清单。这种方法的优点是比较简单、易于实现，但在某些场合没有应用价值，因为复用者往往无法用构件库中已有的关键字来描述期望的构件功能或行为，对树形结构的浏览也容易使复用者迷失方向。
（2）刻面检索法。该方法基于刻面分类法，由三步构成，分别是构造查询、检索构件和对构件进行排序。这种方法的优点是它易于实现相似构件的查找，但复用者在构造查询时比较麻烦。
（3）超文本检索法。复用者首先给出一个或数个关键字，系统在构件的说明文档中进行精确或模糊的语法匹配，匹配成功后，向复用者列出相应的构件说明。这种方法的优点是用户界面友好，但在某些情况下复用者难以在超文本浏览过程中正确选取构件。

2.理解与评价构件
逆向工程是理解构件的另一种重要手段。它试图通过对构件的分析，结合领域知识，半自动地生成相应的设计信息，然后借助设计信息完成对构件的理解和修改。

对构件可复用性的评价，是通过收集并分析构件的复用者在实际复用该构件的历史过程中的各种反馈信息来完成的。这些信息包括复用成功的次数、对构件的修改量、构件的健壮性度量和其他性能度量等。

3.修改构件
为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。因此，与构件有关的文档和抽象层次更高的设计信息对于构件的修改至关重要。

4.构件组装
构件组装技术大致可以分为三种，分别是基于功能的组装技术、基于数据的组装技术和面向对象的组装技术。

（1）基于功能的组装技术。基于功能的组装技术采用子程序调用和参数传递的方式将构件组装起来。它要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰。当使用这种组装技术进行软件开发时，开发人员首先要对新系统进行功能分解，将系统分解为强内聚、松耦合的功能模块；然后根据各模块的功能需求提取构件，进行适应性修改后，再挂接在上述功能分解框架中。
（2）基于数据的组装技术。基于数据的组装技术首先根据当前软件问题的核心数据结构设计出一个框架，然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。此后，构件的组装方式仍然是传统的子程序调用与参数传递。这种组装技术也要求库中构件以子程序形式出现，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
（3）面向对象的组装技术。由于封装和继承特征，面向对象方法比其他软件开发方法更适合支持软件复用。在面向对象的软件开发方法中，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。

软件架构概述

软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

1.软件架构的意义

（1）架构是项目干系人进行交流的手段。软件架构代表了系统的高层抽象，项目干系人能将它作为建立一个互相理解的基础，形成统一认识，互相交流。不同的项目干系人关心着系统的不同方面，而这些方面都受架构的影响，因此，架构可能是所有项目干系人都关心的一个重要因素。
（2）架构是早期设计决策的体现。软件架构体现了系统的最早的一组设计决策，这些早期的约束比起以后的开发、设计、编码或运行及维护阶段的工作重要得多，对系统生命周期的影响也大得多。早期决策的正确性最难以保证，而且这些决策也最难以改变，影响范围也最大。
（3）架构明确了对系统实现的约束条件。所谓“实现”就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。在具体实现时，必须按照架构的设计，将系统分成若干个组成部分，各部分必须按照预定的方式进行交互，而且每个部分也必须具有架构中所规定的外部特征。这些约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。这样一来，可以分离关注点，架构设计师不必是算法设计者或精通编程语言，他们只需重点考虑系统的总体权衡（tradeoff）问题，而构件的开发人员在架构给定的约束下进行开发。
（4）架构决定了开发和维护组织的组织结构。架构包含了对系统的最高层次的分解，因此一般被作为任务划分结构的基础。任务划分结构又