3 设计模型
3.1 映射分析类到设计类
设计类是指设计层面的类，映射分析类到设计类的过程实际上就是细化分析类的属性、方法，使类达到可以进行面向对象编程的程度。在分析类的属性和职责的表示方式可以比较随意、不强调规范，在设计类中就需要按照UML的语法进行表示。在从分析类到设计类的映射过程并不一定是分析类的一个属性对应设计类的一个属性，分析类的一个职责对应设计类的一个方法。类的属性和方法应该按照UML中的格式表示。
类的属性格式为：
〔可见性〕属性名〔：类型〕〔‘〔‘多重性〔次序〕’〕’〕〔＝初始值〕〔｛特性｝〕
类的操作格式为：
〔可见性〕操作名〔（参数列表）〕〔：返回类型〕〔｛特性｝〕
图9是一个由分析类Project映射而来的设计类。
图9 设计类Project
3.2 整理设计类
在最终的类图上并不是所有的类都是由分析类映射而来的，系统中的绝大部分类都是由分析类映射而来的。在完成映射之后，还需要对已有的类根据设计原则进行优化。面向对象主要的设计原则有：开放-封闭原则（OCP）、Liskov替换原则（LSP）、依赖倒置原则（DIP）、接口分离原则（ISP）等。
1. 开放-封闭原则（OCP）
开放-封闭原则描述为“对于扩展是开放的，对于更改是封闭的”。对于扩展是开放的，这意味着模块的行为是可以扩展的。当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模块的功能。“对于更改是封闭的”对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。
2. Liskov替换原则（LSP）
若对每个类型S的对象O1，都存在一个类型T的对象O2，使得在所有针对T编写的程序P中，用O1替换O2后，程序P行为功能不变，则S是T的子类型。
3. 依赖倒置原则（DIP）
高层模块不应该依赖于低层模块。二者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。
4. 接口隔离原则（ISP）
不要强迫客户依赖于它们不用的方法。
遵循以上原则，可以使我们的软件更具灵活性，强壮性。但灵活是需要付出代价的，由多态带来的性能损失就是最明显的一个问题。所以我们需要权衡，需要做出选择，在灵活与性能之间做出选择。
依据一些面向对象设计原则对现在的类进行整理是一种最基本的形式。有一些已经遵守了面向对象设计原则的技术在设计中经常使用，比如设计模式。设计模式是已经得到很好证明的巧妙、优良、通用面向对象系统的解决方案。当我们在设计中应用设计模式时，为了设计上的考虑将会引入新的类加入到我们的设计中。
使用设计模式具有以下好处：首先，使用设计模式可以更准确地描述问题和它们的解决方案；其次，使用设计模式可以具有一致性，即如果对一些已知的问题我们有一类标准的解决方案，那么在遇到相同问题时，我们能够采取一致的方法，这就使代码更容易理解；再次，在遇到问题时，无需每次都从底层做起，而是可以从标准解决方案入手，并对它改编，使之适应特殊问题的需要。这样就节省了时间，并且提高了开发的质量和效率。
我们根据系统的架构将设计类进行了整理，在表示层主要是窗体类，他们的基类是TForm，所有窗体类太多，所以没有把他们一一列出，仅仅列出几个自定义的表示层的基类，如图10所示。
图10 表示层中的类
图11业务逻辑层中的实体类
图12 业务逻辑层中的边界类图
3.3 更新用例实现
当完成了类的设计后，需要根据类的设计更新在分析阶段的用例实现。主要工作是更新交互图，使用类的方法更新交互图中的内容。图13~图15是在类的设计完成之后更新“选择建设项目”这个用例的用例实现中的顺序图。
图13 “选择建设项目”基本流的顺序图
图14 “选择建设项目”可选流1的顺序图
图15 “选择建设项目”可选流2的顺序图
3.4 类细节设计
在上面对类设计的步骤中，设计了类的属性、方法。有些情况下设计到这个层次就可以了。由开发人员在程序编写过程中设计类中方法的具体实现。我个人的意见是如果条件允许在设计阶段尽量对类的重要方法进行设计。下面将以一个具体的类来说明类图中的详细设计。在该软件中有一个类叫做Tevaluate，它的类图如图16所示
图16 Tevaluate类图
详细设计可以很好地指导开发人员进行开发。另外，如果概要设计和详细设计一气呵成，设计中的问题会相对较少。详细设计可以采用自然语言、流程图、伪代码等多种方式实现。如图17使用伪代码对Tevaluate的方法PartEvaluate进行的详细设计。
图17 类的详细设计
图 18 PartEvaluate的活动图
可以使用活动图描述类图中一些比较复杂的类的实现。如图18所示，它描述的就是类Tevaluate中的方法PartEvaluate的实现，根据类的详细设计和活动图很容易就能够了解设计者的意图，开发人员很快就能够将其实现。
未完待续......
