软件创新设计理论课.pptVIP

“4+1”视图模型—小结 “4＋1”视图模型一览表 * 软件体系结构建模 软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模 根据建模的侧重点不同，可以将软件体系结构的模型分为5种： 结构模型 框架模型 动态模型 过程模型 功能模型 * 软件体系结构建模 结构模型 这是一个最直观、最普遍的建模方法。 这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。 研究结构模型的核心是体系结构描述语言。 * 软件体系结构建模 框架模型 框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。 框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。 * 软件体系结构建模 动态模型 动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。 例如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。 * 软件体系结构建模 过程模型 过程模型研究构造系统的步骤和过程。 结构是遵循某些过程脚本的结果。 功能模型 功能模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。 功能模型可以看作是一种特殊的框架模型。 * “4+1”视图模型 前述5种模型各有所长。 将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。 如Kruchten提出了用于体系结构描述的“4+1”视图模型（1995年） 从5个不同的视角（逻辑视图、进程视图、物理视图、开发视图和场景视图）来描述软件体系结构。 每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。 * “4+1”视图模型 “4+1”模型概述 * 逻辑视图 过程视图 开发视图 物理视图 最终用户： 功能需求 编程人员： 软件管理 系统集成人员： 性能、可扩充性、吞吐量等 系统工程人员： 系统、拓扑、安装、通信等 场景 “4+1”视图模型 * “4+1”视图模型 逻辑视图（Logical View） 当采用面向对象的设计方法时，逻辑视图即是对象模型。 过程视图（Process View） 描述系统的并发和同步方面的设计。 物理视图（Physical View） 描述软件到硬件之间的映射关系，反映系统在分布方面的设计。 开发视图（Development View） 描述软件在开发环境下的静态组织。 * “4+1”视图模型 对体系结构进行的描述是围绕着以上4个视图展开的。然后，通过选择出的一些用例（use cases）对体系结构加以说明。这些用例被称作场景（scenarios），它们构成了第5个视图。 体系结构的概念在每个视图里面都可以独立应用。 这就是说，可以在每个视图里面定义体系结构的各种组成元素，如构件、连接件等。对于不同的视图，还可以选择不同的体系结构风格，因此在同一个系统结构中可以使用多种风格。 在每一种视图里，使用该视图特定的符号。 这避免了符号用法和意义的混乱。 “4+1”视图模型是一个十分通用的模型： 可以便用其他的符号表示法，也可以使用其他的设计方法，尤其是逻辑视图和过程视图的分解。 * “4+1”视图模型 “4+1”模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西 系统工程师先从物理视图，然后从过程视图靠近体系结构。 最终使用者、客户、数据专家从逻辑视图看体系结构 项目经理、软件配置人员从开发视图看体系结构。 不是所有的软件体系结构都需要完整的“4+1”视图 没有用的视图在体系结构描述中可以被省略 例如对于非常小的系统，逻辑视图和开发视图有可能非常相似以至于没有必要把它们分开描述。 场景视图在各种环境下都是有用的 * “4+1”视图模型—逻辑视图 逻辑视图 -- 面向对象的分解 逻辑视图主要支持功能需求—系统应当向用户提供什么样的服务。 从问题域出发，采用面向对象的方法，按照抽象、封装、继承的原则，进行分解，得到代表着系统的关键抽象表示的集合。 这些抽象表示的具体形式就是对象和对象的类。 这种分级不仅是为了功能分析，而且担负着在系统的各部分中确定公共机制和设计元素的作用。 使用Rational / Booch方法，通过类图和类模板来表示逻辑体系结构。 对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，例如 E-R 图，来代替面向对象的方法 * “4+1”视图模型—逻辑视图 逻辑视图的符号表示法 逻辑体系结构的符号表示法是从Booch方法派生而来的。可以使用Rational Rose等UML建模工具 * 构件 实例 继承 使用 包含，聚集 关联 类层次 参数化类 类服务 类 连接件 “4+1”视图模型