软件工程第7章软件的体系结构的设计.ppt

7.7.2 构件创立 构件的设计应追求可复用性目标。 如何才能使目前创建的构件在未来能够为其他软件项目所用？ 在横向复用的情况下，必须确保构件具有跨越多个差异较大的应用领域的可复用价值； 在纵向复用的情况下，必须根据领域分析的成果创立构件。 * * 构件创立 构件创立过程包含两项必须依序展开的活动： ⑴领域分析； ⑵确定构件及其接口。 * * （一）领域分析 领域：从软件工程的观点看，领域就是向目标软件系统提出应用需求的问题及其背景知识。 领域分析的主要任务：针对单个或一族相似的领域，以软件复用为目标，探寻并挖掘领域或领域族中能够为多个目标软件系统共用的软构件。 领域分析与需求获取及需求分析活动有相似之处：它们都是软件项目中直接基于应用领域的开发活动，都要完成程度不同的领域建模任务。 * * 领域分析 领域分析过程可大致归纳为以下步骤： ⑴发现并描述可复用的实体（包括构件）及其职责； ⑵对这些实体/职责及它们之间的关系进行抽象化、一般化和参数化； ⑶对可复用的实体/职责进行分类、归并，以备日后复用； ⑷建立领域应用的参考体系结构，该结构主要由可复用的实体连接而成。 * * （二）确定构件及其接口 此项工作的主要任务是将领域分析认为可复用的实体或职责确立为构件，定义构件的职责、接口，确定它们与体系结构中其他相关设计元素之间的协作关系。 为提高构件的可复用性，构件的设置和构件接口的定义必须遵循以下原则。 ⑴广泛、深入地使用各种抽象化、参数化、模板化手段以发掘公共性，将构件的功能和行为与其应用上下文严格分离，从而提高可复用性。 如，除接口定义中的函数参数外，接口中其他成份不应与构件的运行环境相关。 ⑵通过构件的职责和接口的设计，保证复用时构件能够简便地组装进新的软件系统。 * * 确定构件及其接口 ⑶公共构件极大化，即，将多个子系统或构件的公共职责提取成为独立的公共构件 或从多个子系统及构件的若干职责中抽取公共的支持性服务，将这些服务按照强内聚、松耦合原则封装为独立的公共构件。 如果这些构件的公共性、基础性足够强，它们甚至可以进入技术支撑设施。 ⑷通用性不同的设计元素划归不同的构件。 为方便构件的开发，需要不同开发技能的设计元素也应该划归不同的构件。 ⑸构件接口极小化。 * * 确定构件及其接口 在领域分析过程中必须充分考虑当前软件项目的需求，因此领域分析认为可复用的实体或职责显然也应该在概念体系结构中出现，尽管命名或者职责划分边界可能会有差异。 确定构件及其接口的工作内容和方法类似于7.6.1节中的“确定子系统及其接口”。 构件与子系统在概念和用途上毕竟不同，在构件的设置和构件接口的定义过程中必须把握以下关键差异点： ⑴构件的设计应该追求可复用性目标。 ⑵构件的内聚度应该高于子系统。 如果一个构件具备多项职责，那么这些职责应该紧密相关。 ⑶构件的规模小于子系统。 子系统中可以包含构件，但构件中不会包含子系统。 * * 例 7.13 确定构件及其接口 假设领域分析认为日志管理功能在未来可以被复用，因此需要将其封装成构件。 日志管理构件的职责主要来源于“日志管理” 用例。 为了完成这些职责，显然应该将 “日志管理器”纳入此构件，该控制类的职责包括日志信息的查询和保存。 如例7.6所述，实体类“日志”也应该划归该构件。 根据接口极小化原则，该构件的接口定义如下。 ⑴ queryLog：查询日志。 ⑵ writeLog：写日志。 ⑶ queryEvent：查询曾经发生的异常事件。 ⑷ writeEvent：记录异常事件。 * * 确定构件及其接口 考虑日志管理构件与体系结构中其他设计元素的协作关系 传感器监测和配置管理子系统均通过writeLog使用日志管理构件提供的日志保存服务。 例7.9引入的com.seBook.safeHome.log.UI包负责将来自用户界面的日志查询请求转化为对queryLog的调用，并将此调用的结果交予com.seBook.safeHome.log. deviceInteraction包以显示到“显示面板”之上。 日志管理构件的设置及接口设计如图7.22所示。引入日志管理构件后精化得到的软件体系结构如图7.18所示。 * * 图7.22 构件设置及构件接口设计 7.7.3 构件复用 在体系结构设计过程中复用业已存在的软构件的最佳时机是7.6.1节所述的“搜索并选取可用的设计资产”，因为软构件（库）是最重要的可用设计资产之一。 要使库中的软构件在当前的软件项目中发挥作用，准确地理解构件至关重要。 考虑到设计信息对于理解软构件的必要性以及构件使用者逆向发掘设计信息的困难性，构件开发者在构件的附加文档中应全面、准确地说明以下内容： ⑴构件的功能与行为；