《大象：thinking in uml 》(第二版) 12章 系统设计

只供参考，喜欢请支持正版图书

分析和设计是有着显著差别的

■　从工作任务上来说，分析做的是需求的计算机概念化，设计做的是计算机概念实例化。
■　从抽象层次上来说，分析是高于实现语言、实现方式的；设计是基于特定的语言和实现方式的。因此分析的抽象层次高于设计的抽象层次。
■　从角色上来说，分析是系统分析员承担的，设计是设计师承担的。
■　从工作成果来说，分析的典型成果是分析模型和组件模型，设计的成果是设计类、程序包
分析的抽象层次高于实现语言和实现方式是有着极大好处的。如果要维护设计与需求的一致是很困难的，因为设计包含很多需求不需要而系统必需的信息。比如增加了一些设计模式，或者在实体类里增加了系统控制需要的属性。而分析由于不必考虑实现方式，就可以省略这些内容，因而更容易维护

12.2 设计模型

12.2.2 现在行动：将分析模型映射到设计模型

12.3 接口设计

12.3.2 现在行动：设计接口

面向对象给我们带来的一大好处是接口与实现的分离，这使得我们在考虑程序逻辑时可以完全不用考虑程序将怎样编写，而只考虑对象交互的接口。对于设计工作来说，这既是一个挑战，也是一大优势

12.3.2.2 为具有相似行为的对象设计接口

我们用12.2设计模型一节中的Entity层实体对象为例，将这些相同的操作方法提取出来形成接口，然后所有的实体对象都实现这个接口，其结果如图12.10所示。

12.3.2.3 为软件各层次设计接口

实际上这类问题就是门面模式（Façade）要解决的问题。门面模式的意图是在系统内抽象出高层的接口，外部系统通过接口访问系统内部而不是直接访问系统内部的类。

采用门面模式来处理WEB层和BusinessControl层之间的交互可以有效地减少交互的复杂度，使得层次之间保持清晰的关联。图12.12展示了采用门面模式后WEB层和BusinessControl层之间的交互情况。可以看到，交互的复杂程度得到了有效的控制
我们可以有基于行为模式和基于服务的两种接口抽象策略。

一种是将类的相同行为抽象成接口，可称之为基于行为模式的接口抽象策略。例如经过12.2设计模型一节中对BusinessControl层设计模型的建模我们可以发现，许多BusinessControl类都具有相同的行为，例如提交表单、保存表单、查询表单、应用业务规则、推进工作流状态等，这些相同的行为就是抽象接口的基础。根据这些相同的行为，我们可以抽象出如图12.13所示的接口

只供参考，喜欢请支持正版图书