《大象：thinking in uml 》(第二版) 11章 系统分析 3-4节 用例实现、软件架构和框架

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

一个用例可能有多个用例实现，每个用例实现都是设想的一种实现方式。虽然实现方式和过程不同，但目的是相同的，同样要达到用例所规定的系统目标。为了表示出用例实现与它所实现的用例之间的关系，我们可以用图11.13来表示。这幅图表明了实现到需求之间的追溯关系

11.3.2 现在行动：实现用例

在5.6.3分析模型的意义一节中作者介绍过，分析模型是采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型。于是边界类对象、控制类对象和实体类对象就成为我们用来实现用例的关键对象

要为用例实现建模，我们需要经过以下三个步骤

第一步，我们需要在用例场景当中发现和定义实体对象。这些实体对象代表了我们将要操作的业务数据。发现和定义实体对象的方法很简单，在这个用例场景当中，每一个活动都是由动词＋名词构成的，这些名词就是我们要寻找的实体。

第二步，我们需要用控制对象来操作和处理实体对象中的数据。在初步实现用例的时候，我们可以简单地为每一个实体对象加上一个控制对象。每个控制对象操作一个实体对象，它默认地包含所有对该实体对象的处理逻辑。

第三步，我们需要用边界对象来构建接收外部指令的界面。边界对象负责接收来自系统外部的指令，并将指令传达给控制对象，控制对象根据指令执行相应的逻辑程序，然后将结果返回给边界对象。最后再由边界对象将结果展示给外部。
图11.16　批量申请登记用例实现场景
图11.17　sur_批量申请登记用例实现

至此，两个用例实现场景绘制完毕。在绘制过程中，我们得到了一些关键对象以及这些关键对象的方法。接下来我们把这些关键对象集中在一个图里，定义它们的关系，就得到了分析类图，如图11.18所示
图11.18　申请登记分析类图

11.3.3 进一步讨论

为什么用分析类而不是设计类来实现用例场景

分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。分析类的抽象层次高于设计实现，高于语言实现，也高于实现方式

可以看到，由于分析类的抽象层次较高，基本上停留在“概念”阶段，相对于设计实现、语言实现、实现方式这些较低抽象层次的工作来说，需要考虑的信息量要少得多，而能够让分析工作专注在实现需求上。相对于设计模式、编程风格这些因素来说，忠实地实现需求才是第一位的。另外，也由于分析类的抽象层次较高，概括能力就很强，也就比设计和实现要稳定。在一个演进式的软件生命周期里，维护稳定的分析类比维护易变的设计类要投入更少的精力，更容易获得一个稳定架构来指导整个软件的开发

11.4 软件架构和框架

11.4.2 什么是软件架构

软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定

11.4.3 什么是软件框架

软件框架是软件架构的一种实现，是一个半成品

11.4.4 软件架构的基本构成

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