umlcore6.pdfVIP

返回总目录返回总目录 返回总目录返回总目录 目目 录录 目目 录录 6 2 第第 章章 物理架构视图物理架构视图 第第 章章 物理架构视图物理架构视图 6.1 逻辑架构4 6.2 物理架构4 6.3 组 件 图7 6.4 展 开 图10 6.5 复杂节点的建模12 6.6 节点的组件配置13 6.7 小 结15 第 章 物理架构视图 6 系统架构是构成系统的各部分 结构 接口 通信机制 的框架性描述 通过定义一个 ( ) 合适的架构 使得更容易完成下述工作 浏览系统 找到一个特殊功能的位置或概念 标 志加入一个新功能或概念的位置使其更适合总的系统架构 架构必须足够详细从而使得能 够将它映射到真正的代码 架构不仅要容易浏览 足够详细 而且还要具有可伸缩性 即 能够从不同的级别上了解它 例如 架构应该提供一个包括几个主要部分的顶级视图 从 顶级视图中 开发人员可以选取其中的一个部分 了解其内部结构 然后更进一步了解更 详细的结构 通过特定工具 详细了解系统的各个部分是可能的 一个定义明确的架构允许加入新的功能和概念而不会给系统中的其它部分带来新的问 题 例如 在一个旧的单片集成电路系统中 系统中某一部分的小的改变将导致一些好象 ( 与此无关的部分停止工作 这主要是因为系统中各部分存在着复杂的关系所致) 架构给开发人员提供一个有关系统的视图 通过它开发人员可以知道系统是如何构造 的 某一功能或概念在何处 随着时间的改变 在开发过程中因为重要的发现和经验这张 视图可能不得不作些改变 架构必须随着被开发系统的变化而变化 应该实时地反应系统 在各个阶段的结构 很自然地 基本架构在系统的第一个版本中定义 初始的架构的质量 对于开发人员改变 扩展 更新系统功能有着至关重要的作用 UML 中 架构 的定义为 架构是系统的组织结构 可以递归地将架构分解成 通过接口交互的部分 连接各个 部分的关系 组装各个部分的约束 Buschmann 等人(1996)提供了另一个软件架构的定义 软件架构是系统的子系统和组件及其之间关系的一种描述 典型地 子系统和组件是 通过不同的视图描述的 显示了软件系统与功能和非功能的性质 系统的软件架构是一个 人工的产物 它是软件设计活动的结果 可以用很多视图来描述架构 每一张视图集中描述系统的某一个方面 系统的完整结 构的描述只需定义所有相关的视图 在 UML 中 这些视图通常为 用例视图 逻辑视 图 并发视图 组件视图 和分布视图 一个更广的分类方法将架构分解成逻辑和物理架 构 逻辑架构主要指定系统的功能特点 通过系统的功能需求来描述 物理架构则描述系 统的非功能部分 如可靠性 兼容性 资源使用和系统分布 这些架构将在本章中详细讨 论 有时候 有经验的开发者有一种 神奇 的能力来定义好的架构 但是 这种能力来 自于他设计的很多系统 通过大量的系统设计 他们知道什么样的解决方案能解决问题 什么样的方案不能工作 他们一般重用过去的成功的解决方案 事实上 最近 许多工作 集中在研究如何描述有经验的开发人员在设计软件架构时重复使用的架构模式或框架 ( 解决方案 ) Buschmann 等人(1996)定义了下列架构模式 层模式 将系统分解成一组组子任务 每一组子任务处于一个特殊的抽象级 管道和过滤模式 系统处理数据流 将很多处理步骤封装在过滤组件中 数据通 过管道在相邻的过滤器间传递 可以将过滤器重新组装建立相关的子系统或系统 行为 黑板模式 系统中 几个特殊子系统组合它们的知识建立一个部分的或大约的方 案来解决还没有确切解决方案的问题 代理模式 将系统分解成很多组件 组件通过远程服务激活来交互 代理组件负 责协调通信和