3.4 3.4 3.4 系统详细设计 系统详细设计 系统详细设计 系统详细设计

3.4 3.4 3.4 系统详细设计 系统详细设计 系统详细设计 系统详细设计

3.4.1

3.4.13.4.13.4.1 系统逻辑系统逻辑系统逻辑系统逻辑结构结构结构结构设计设计设计设计

可以用类图^[40]来描述系统逻辑结构的设计。系统类分析的主要任务是把用例描 述中的各个步骤和动作变换为协作^[41]中的类、类操作和类之间的关系。具体来说就 是把每个步骤所完成的工作交给类来协作完成。用例视图^[42]中的行为描述不能提取 出类。

在一般没有设计模式观念和没有使用过设计模式的程序员，都会是功能(消息函 数)在哪里代码就在哪里，哪里需要功能就在哪里写代码；相同或类似的功能代码只 需要拷贝代码即可；对于一个实体，如果其有多种实现方法，则充分使用面向对象 的继承特性产生子类，以实现代码的复用；哪里需要连接数据库查询数据，就在哪 里与数据库进行连接、查询数据、关闭连接等，如果一不小心忘了关闭连接，会使 系统的并发处理压力加大；代码混乱，可读性差，一个地方出错连带程序的其他地 方变更，这样调试和人员之间的交流就很困难。

根据一般程序员的做法，会在系统主类 MainFrm 中连接数据库、查询数据、读 取外围设备数据组成图片等，有经验的人会为图片设计一个 Picture 类，而系统要检 测人脸图片中是否有人脸、如果有人脸则提取特征、然后将提取的特征与数据库中

查询到的人脸特征进行比对，这些初步都会分给图片类 Picture 来完成；对于获取外 部设备传送的图片，可能有几种情况，可能是从摄像头传来的，可能会是从手持终 端设备传来的，也可能是直接存储在计算机上的，这里需要几个条件判断，判断图 片数据是从那个设备或子系统传来的，在相应的条件里面处理相应的设备数据读取 。 还要很多这样可变和易变的情况，例如如果先前通过的人脸检测算法现在经过确认 不是最好的算法，要换用新的算法，则可以在 Picture 类中修改相应的函数，或者直 接从 Picture 类继承产生新的类，这样将图像数据与处理算法绑定在一起，使图像数 据和检测算法改变都很难，会相互影响。

下图 3-7 给出根据需求初步提取的类图。第 4 章第 8 节将给出经过应用设计模式 后的优化类图。

图 3-7 系统类图

由图可看出分类简单，但是类中的功能复杂，功能分类混乱，例如获取人脸图 片类 PicMachine 类中有从视频头获取图片的方法 getFromMonitor、从手持终端获取 图片的方法 getFromHandset 等，图片类 picture 有方法人脸检测 detector、人脸分割 方法 partition、提取人脸特征的方法 getFaceCharacter 等。这些方法混为一团，当检 测方法更改或者有多种方法时只能修改方法或者继承^[43]picture 类衍生出很多类，从 而是类的层次结构和关系复杂。这些缺点最终导致低内聚和紧耦合^[44]，使程序差可 维护性、易读性、灵活性^[45]。

3.4.2

3.4.23.4.23.4.2 系统动态行为分析系统动态行为分析系统动态行为分析系统动态行为分析

（1）活动图描述系统动态行为—处理流程

用活动图^[46,47]可以表示人脸识别流程如下图 3-8 所示。本文中的设计图均使用

Rational Rose 制作。

图 3-8 人脸识别活动图

（2）序列图描述系统动态行为—数据流向及调用关系

序列图^[49]描述对象是如何通过消息^[50]按时间顺序交互^[51]的关系和顺序，以及数 据的流向。下图 4-4 为人脸识别过程的时序图。

图 3-9 人脸识别过程时序图

从图中可以看出这些对象完成了不属于他们的工作，MainFrm 本不应该去做实 际的连接、查询数据库的操作，在这种设计中却要做这些事情，还要对 picture 提取 的特征与数据库查询到的特征进行比对，等等，之类的事情，很混杂。对象之间的 交互也混乱，这些都说明了这样的设计存在很大的问题。