Fork me on GitHub

UML（6）

Posted on | Edited on | In | Views:

面向对象系统分析与设计（6）

1. 系统设计

  • 定义：将分析模型的逻辑结构加以实现前的准备过程。

哪些工作内容：

  1. 考虑非功能性需求的弊端；
  2. 考虑全局设计问题；
  3. 考虑实现的环境 —— implement environment；
  4. 补充 classes 的所有属性和操作；
  5. 将 implementation 的工作分成可执行的小块；
  6. 为 subsystems 间建立接口。

当可以从“分析模式”平滑过渡到“设计模式”时（即无需大改时），就是开始系统设计的最佳时刻。

1.1 设计的意义和标准

上文列出的 6 项工作必须要在 implementation 前完成，所以不能跳过设计这一步骤。

  1. 研究非功能性需求提高质量；
  2. 看重设计目标和扩展功能，而不是管理目标。
  3. 遵循的标准：外观标准、依赖标准、维护标准、开销标准等等。
  4. 考虑的范畴：
    • 数据的管理；
    • 访问权限管理；
    • 流程控制；
    • 边界条件；

1.2 设计 Tips：

  1. 指定 admin 的用例，作为 start-up 和 shutdown。
  2. 指定 errors 的异常处理机制。

1.3 implement environment

  • 要考虑在构建一个 system 时，技术和管理上所受到的限制。
    • 比如：系统运行环境问题、硬件/软件问题、编程语言选择问题、参与人员问题等。
  • 策略：定位对 implement environment 的依赖，然后可以创建代理的方式（类似 JVM 的跨平台）来解决。

2. UP 设计过程

  1. 设计 use-cases（PPT P21）
  2. 设计 classes（PPT P57）
  3. 设计 subsystems（PPT P75）

2.1 use-case 设计

  1. 确定要设计哪些类
    • 保持可追溯性：use-case 设计的实现 -> use-case 分析的实现 -> use-case
  2. 增加说明：使用类图、非功能性的需求。

其中 OO Design 的迭代过程：

  1. 设计初步类图模型；
  2. 为每个用例设计一个 sequence diagram。
    • 开发初步的 sequence diagrams；
    • 开发多层的 sequence diagrams。
  3. 修改类图；
    • 修改方法名；
    • 修改属性等；
  4. 用 package 打包（或者分 subsystem、分层）等方式，按功能将类图设计分区。

2.1.1 设计初步类图模型

  1. 扩展 domain model class diagram。
    • 注：domain model 是指缩略版的类图，只有类名、属性名两种信息。不含 method、没有+、-、#等符号。
    • 1）增加属性的 type 和初值。
    • 2）增加可见性标识。
  2. 详细设计。
    • 1）交互图实现指向性。
    • 2）补足箭头，让其连贯起来。
    • 3）每个类增加 method。

2.1.2 设计初步 sequence diagram

初步 sequence diagram 的假设：

1. perfect technology assumption。比如不考虑登录注销功能。
2. perfect memory assumption。比如不考虑存储问题。
3. perfect solution assumption。比如不考虑 Exception 分支。

2.1.3 设计 multilayer sequence

  1. 修改 domain layer，其中加入 use-case controller 和 classes；
  2. 增加 data access layer。
    • 增加额外的数据访问类，作为外界数据库交互用途；
    • 取消掉 perfect memory 假设。
    • 职责分离。（以前是 controller 要实例化一个实体类，这个 instance 要求 DA 类去操作 instance 的属性去读数据库；增加 data access layer后：controller 可以直接要求 DA 类去实例化那个实体类，而且由 DA 类来完成读库，传初始值给 instance 等操作）
  3. 增加 view layer。
    • 增加额外的 user-interface 类。比如增加 windows 类用来实现 actor 和 controller 之间的交互。
    • 为每个用例增加 GUI 表格或者 Web 网页。

2.1.4 修改类图

  1. 做到每层一个类图：
    • view 层和 data access 层增加新类；
    • domain 层的 use-case controller 增加新类。
  2. 时序图的 messages 增加 methods：
    • 构造方法；
    • getter 和 setter 方法；
    • 用例特有的方法。

2.1.5 打包分区

  1. 高级的 UML 图会将相关的类联系起来；
  2. 确认一个 system 的主要组成和依赖。
  3. 为每层确定最终的分区情况。
  4. 划分子系统、在 packages 中体现出层次性。

2.2 classes 设计

  • 前提：要设计的类，必须是能够被实现的类才行。
  • 这些类出自两个地方：
    1. the problem domain：改进之前对类的分析；如果必要，可以将类划分为多个设计类。
    2. the solution domain：一般的公用类库、框架等；实现一个系统的技术工具等。

2.2.1 solution domain

  1. 如果是 boundary classes，要考虑指定的 user interface technologies。
  2. 如果是 entity classes，要考虑指定的 data management technologies。
  3. 如果是 control classes，要考虑：
    1. distribution issues：看需不需要分布式吧。
    2. performance issues：考虑跟 boundary class 和 entity class 的兼容问题。
    3. transaction issues：考虑是否需要事务管理技术。

2.2.2 activities

  1. 完善 activities 的规格：
    1. 补足属性、联结、操作等；
    2. 补足可见性等；
    3. 对操作增加约束，比如先决条件、后发动作等。
    4. 异常等。
  2. 选出可重用的组件：
    1. 类库；
    2. 对非功能性需求的一般设计机制（generic design mechanisms）：持久性、分布式、安全性、事务管理等。
  3. 重建设计模式：
    1. realize associations：[理解]大概指可变性、适应性。
    2. 利用继承、代理等实现重用。
  4. 优化设计模式：
    1. 修改访问路径；
    2. 拆分 classes；
    3. 缓存；
    4. 延迟计算。

2.2.3 优秀的类的设计

  1. 完整、充足：无论什么 users 想做的都能满足；
  2. primitiveness：operations 采用最简单最省力的方式；
  3. 高内聚
  4. 低耦合

2.2.4 generic design mechanisms

针对常见的需求，一些好的实践。

  1. 设计模型，同义词：example。
    • 针对 object 和 RDBMS 对应的情况，优秀的做法是：
      1. 一个 class 对应一张表；
      2. 一个 属性对应表中一个字段；
      3. 主键对应 objectId；
      4. 每个 object 对应表中一行；
      5. classes 间的 association 与表中关系对应；
      6. 继承关系，也在表中对应。
  2. 框架，不解释。

2.3 subsystems 设计

将系统拆分成子系统，便于更好的管理。

子系统中可以包括：

  1. 设计类；
  2. 用例的实现；
  3. 其他子系统；
  4. 接口。

Tips：用例可以设计成子系统；子系统可以被当做交互图。

2.3.1 子系统的分区/分层

  1. 可以递归的划分子系统；
  2. 每层为高层提供服务，以及使用下层的服务；
  3. 层次结构：
    1. closed layered architecture: 一般指上下层的调用，不可以跨层。较常见。
    2. open layered architecture: 可跨层调用。耦合度高，较少见。
  4. 子系统分区：
    • 一层可分多个子系统；
    • 层间存在 peer to peer 的服务。

2.3.2 子系统接口

  • 通常叫做 API
  • 包括：操作名、参数及参数类型、返回值；
  • Tips：
    1. 如果有一个依赖指向这个子系统，那么这个子系统有必要提供一个接口。
    2. 使用接口的 client，与这个子系统的实现是 independent 的。

2.4 deployment model

  • 定义：描述一个 system 是如果在物理上部署/安排的。
  • deployment diagram 要展示的有：
    1. nodes：一般指计算资源（处理器等）；
    2. relationships：一般指 nodes 的连接方式。
  • 一般的分布式部署采用三层结构。
    1. 1）clients：用户接口。
    2. 2）database functionality：数据库的功能。
    3. 3）business/application logic：业务逻辑。
    4. [理解]其实是一种 server/client 结构，可以当做 view 层、业务层、DAO 层来看待，每层都可独立替代。

2.5 检查设计

一个大型 project 的开发会涉及很多人员甚至团队，所以要在设计的最后统一命名风格、统一 OO 的规矩、消除冗余类等等。检查工作要持续到 project 的始末。

-------------The End-------------