第三部分细化迭代1--基础(12-16章)导论.ppt

PRJ270: Essentials of Rational Unified Process Module 1 Best Practices of Software Engineering 第三部分 细化迭代1 – 基础（2） 主要内容 第 12 章 从需求到设计-迭代进化 第 13 章 逻辑架构和UML包图 第 14 章 迈向对象设计 第 15 章 UML交互图 第 16 章 UML类图 第 12 章 从需求到设计—迭代进化 12.1 以迭代方式做正确的事，正确地做事 12.2 尽早引发变更 在设计和实现工作中，特别是在早期迭代中 发现和变更一些需求。 在早期迭代中引发某些“不可避免的变更”。 尽早编程、测试和演示有助于尽早引发不可避免的变更。 在细化阶段结束时，大约可靠定义了80%的需求 第 13 章 逻辑架构和UML包图 13.1 示例 13.2 什么是逻辑架构和层 逻辑架构是软件类的宏观组织结构，它将软件类组织成包，子系统和层等 层：对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层，反之则不然。常见的层： 用户界面 应用逻辑和领域对象 技术服务：数据库接口、错误日志，独立于应用，可在多个系统中复用。 UML包图所表示的层 13.4 什么是 软件架构 架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统的接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构（这些元素及其接口，协作和组成）的架构风格 13.5 应用UML：包图 包 UML包图通常用于描述系统的逻辑架构——层、子系统、包等。层可以建模为UML包。 包是一种对模型元素（类、接口、组件、节点、协同。Use Case图，甚至其它包）进行成组组织的通用机制。 包用于定义一个名字空间或容器。 可以有可视性标识 +/-/# 包的表示 包的表示——嵌套包的不同表示法 包间的关系 主要有两种： 依赖 泛化 包间的关系——依赖 依赖：一个元素的定义的改变会引起另一个元素发生相应改变 包之间的依赖关系概述了包中元素的依赖关系，即包间的依赖关系可从独立元素间的依赖关系导出。 包的依赖关系可以加上许多构造型规定它的语义，其中最常见的是输入依赖 输入依赖(Import Dependency)是包与包之间的一种存取(Access)依赖关系。输入(importing)允许一个包中的元素存取另一个包中的元素 输入依赖是单向的。 包间的关系——泛化 与类的泛化关系一样：表示一般与特殊的关系 两个包之间存在泛化关系，指其中的特殊性包必须遵循一般性包的接口。 与类的继承相同，特殊包一般继承其所包含的公共类，并且可以重载和添加自己的类。 UML工具：从代码逆向工程产生包图 开发过程早期： 画出UML包图的草图，根据这些草图组织代码 开发过程后期： 用UML CASE工具对源代码进行逆向工程，从而自动生成包图 13.6 使用层进行设计 系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰、内聚的关注分离。较低的层是低级别和一般性服务，较高的层则是与应用相关。 协作与耦合是从较高层到较低层进行，避免从较低层到较高层的耦合 使用层的好处 总的来说，使用层可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离； 层可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰。 封装和分解了相关的复杂性。 某些层能够用新的实现替换。 较低层包含可复用功能。 某些层可以是分布式的。 通过逻辑划分，有助于团队开发。 准则：内聚职责；使关系分离 领域层和领域模型之间的关系 定义：领域层与应用逻辑层；领域对象 典型的软件系统都有UI逻辑和应用逻辑，我们如何使用对象设计应用逻辑 “全能类”？但OO思想提倡创建软件对象！如：pos系统具有销售与支付功能，Sale类与Payment类 从真实世界出发设计对象，分配应用逻辑职责，称为领域对象，因此应用逻辑层被称为领域层 领域层和领域模型的关系：领域模型可以给我们领域层命名的灵感 定义：层、层和分区 层（tier）最初表示逻辑层，现表示物理进程节点 层（layer）表示对系统在垂直方面的分区 分区（partition）表示对层在水平方向进行划分，形成相对平行的子系统 准则：不要把外部资源表示为最低层 大部分系统依赖于外部资源或服务，例如MySQL库存数据库。这些是物理实现构件，而不是逻辑结构中的层 就逻辑架构和层而言，对某个持久数据集合的访问可以看作领域层中的子领域-库存子领域。而提供数据库访问的一般性服务则可以视为技术服务分区-持久性服务。 13.7 准则：模型-视图分离原则 模型：领域层对象同义