本章的主要内容是面向对象设计

设计的概念

      设计活动

            与分析一样，设计也是一个建模活动，它在分析模型的基础上完成在实现在环境的类建模、状态图建模、协作按摩、组件建模、部署建模、持久建模和用户界面原型，实现从需求分析到软件实现之间的跨越。

      设计原则

            1. 模块化；2. 耦合度和内聚性；3. 复用性。

软件体系结构

      仓库体系结构

            在仓库体系结构中，有两不同的软件部件：一个表示当前的中心数据结构和一组相互独立的处理中心数据的子系统。仓库体系结构适合于数据由一个子系统产生而由其他子系统使用的情形，其典型的应用包括现代编译器、管理信息系统、CAD 系统和 CASE 工具集等。

      分层体系结构

            层次化是一种概念，它将软件设计组织成为类或组件的层次或集合，在同一个层次上的类或组件完成一个特定的目的，例如实现系统的用户界面或业务逻辑。良好的层次结构可以易于系统的扩展与维护，不同的层次之间通过借口进行通信。

      MVC 体系结构

            在 MVC 体系结构中，子系统划分成为不同的三种类型：模型子系统负责存储系统的中心数据；视图子系统负责将模型中的数据展示给用户；控制器子系统负责管理与用户的交互处理。

      客户机/服务器体系结构

            在客户机/服务器体系结构中，作为服务器的子系统为其他客户机的子系统提供服务，作为客户机的子系统负责与用户的交互。通常由某个远程程序调用机制或公共对象代理完成请求的服务，例如：CORBA 或 Java  RMI。

      管道和过滤体系结构

            在管道和过滤器体系结构中，数据在不同的子系统之间流动，每一个子系统处理输入的一组数据，并将处理结构输出给其他子系统。这时，子系统同称为过滤器，子系统之间的联系成为管道。

系统设计

      识别设计元素

            设计元素的基本原则如下：1. 如果一个“分析类”比较简单，代表着单一的逻辑抽象，那么可以将其映射为“设计类”。通常，主动参与者对应的边界类、控制类和一般的实体类都可以直接映射为设计类；2. 如果“分析类”的职责比较复杂，很难由单个“设计类”承担，则应该将其映射成“子系统接口”。通常，被动参与者对应的边界类被映射成子系统接口；3. 子系统的划分应该符合高内聚、低耦合的原则。

      数据库存储策略

            1. 数据文件；2. 关系数据库；3. 面向对象数据库。

      部署子系统

            UML 部署图反映了系统中软件和硬件的物理架构，表示系统运行时的处理结点以及结点中组件的配置。

      系统设计评审

            1. 检查“正确性”的问题列表；2. 检查“完整性”的问题列表；3. 检查“一致性”的问题列表；4. 检查“可行性”的问题列表。

详细设计

      方法建模

            1. 方法的命名；2. 方法的可见性；3. BorrowerInfo 类的方法建模。

      属性建模

            与方法建模类似，类的属性建模也要进行命名和设置可见性。属性建模包括以下原则：1. 将所有的属性可见性设置为 Private；2. 仅通过 set 方法更新属性；3. 仅通过 get 方法访问属性；4. 在属性的 set 方法中，实现简单的有效性验证，而在独立的验证方法中实现复杂的逻辑验证。

      状态建模

            状态建模是一种动态建模技术，它主要用于确定系统的行为。在详细设计时，状态建模一般只发生在依赖状态展示不同行为的类上。在状态建模中，状态通过对象属性的值来表示，转移是方法调用的结果，经常会反映业务规则。

      关系建模

            在分析阶段，初步得到了类之间的关联关系。再详细设计阶段，需要进一步确定详细的关联关系、依赖关系和聚合关系等。此外，还可以根据类之间的共性和差异，利用泛化关系对整体结构进行优化。且不同对象之间存在 4 中可能的连接：全局、参数、局部和域。

 

 

      详细设计评审

            评审方法如下：1. 选择适用于设计阶段的度量指标，包括时间开销、错误类型和严重性等；2. 检查每一个系统模块是否被详细设计；3. 检查每一个详细设计是否属于系统结构的一部分，如果不是其中的一部分，则应该修改系统结构；4. 检查设计的完整性；5. 检查设计是否可测试；6. 检查详细设计的以下方面：简单性、通用性、可扩展性、可效性和可一致性。

应用设计模式

      Abstract Factory 模式

            Abstract Factory 设计模式的目的是用于封装具体的平台，从而使应用程序可以在不同的平台上运行。

      Adaptor 模式

            适配器设计模式的目的是封装遗留系统的代码。当一个调用子系统需要访问一个遗留系统提供的功能时，有可能遗留系统提供的借口与调用子系统的标准接口不一致，通过创建一个 Adaptor 类，用遗留系统的方法实现该标准接口就可以解决这个问题。由于调用双方只需访问标准接口，因此以后可以方便地用其他组件代替遗留系统。

      Bridge 模式

            改模式将一个类的接口与具体实现进行分离。

      Facade 模式

            Facade 模式用简单的统一接口封装子系统，从而降低类之间的相关性。

用户界面设置

      用户界面设计原则

            1. 用户控制式；2. 一致性；3. 个性化；4. 宽容性；5. 反馈；6. 审美和可用性。

      Web 界面的设计

            Web 界面的设计要求具有简洁性，避免使用许多复杂的图片和动画等造成用户操作的分心，同时界面布局应当适合清晰地表达信息，并具有与之匹配的导航性。另外，Web 界面的设计要求保持一致性，诸如同样的按钮在所有窗口中保持一致的位置、始终使用一致的配色方案等。

      用户支持

            用户界面应该提供清晰地系统提示和反馈信息，并提供某种形式的在线帮助。这些信息的描述需要认真地进行设计，应当考虑到上下文环境、用户的经验和水平，信息显示风格以及产品所在国家的语言文化等。

设计文档

      IEEE标准 1016—1998 提供了文档模板。