问题域部分的设计.docx
《问题域部分的设计.docx》由会员分享，可在线阅读，更多相关《问题域部分的设计.docx（24页珍藏版）》请在冰豆网上搜索。
问题域部分的设计
第六章问题域部分的设计
一、什么是面向对象设计
1、OOA与OOD的关系：
1）面向对象的设计就是在OOA的基础上运用面向对象方法，主要解决与现实有滚得问题，目标是产生一个符合现实条件的OOD模型。
与现实条件有关的因素有:
图形用户系统、硬件、操作系统、网络、数据管理系统和编辑语言等。
2）由于OOD以OOA模型为基础且OOA与OOD采用一致的表示方法，这使得从OOA到OOD不存在转换，只需做必要的修改和调整，或补充某些细节，并增加几个与现实关联的相独立部分即可。
因此OOA与OOD之间不存在分析与设计的鸿沟，二者能紧密衔接，大大降低了从OOA与OOD的难度、工作量和出错频率。
3）OOA主要针对问题域，识别有关的对象以及它们之间的关系，产生一个映射问题域，满足用户需求，独立于实现的OOA模型。
OOD主要解决与实现有关的问题，基于OOA模型，针对具体的软、硬件条件（如机器、网络、OS、GUI、DBMS等）产生一个可实现的OOD模型。
2、OOD模型和过程
在OOA阶段只考虑问题域和系统操作责任，在OOD阶段要考虑与具体实现的问题。
图6-1OOD模型
从一个侧面观察
OOD模型包括五个主要部分——一个核心部分加四个外围部分
问题域部分、人机交换部分、控制驱动部分、数据管理部分、构建及部署部分
从另一侧面观察
OOD模型每个部分仍采用OOA的概念和表示方法，只是在辅助模型中要增加分别于描述构件模型和部署的构件图和部署图。
OOD过程：
设计OOD模型的五个部分
问题域部分的设计、人机交互部分的设计、控制流管理部分的设计、数据管理部分的设计、构件部署设计。
前4项不强调次序，每个部分均采用与OOA一致的概念、表示法及活动，但具有自己独特的策略。
进行构件部署设计要在其前面四个部分完成后进行。
二、问题域部分的设计
对OOA结果按实现条件进行补充与调整就是问题域部分。
进行问题域部分设计，要继续运用OOA的方法，包括概念、表示法及一部分策略。
不但要根据实现条件进行OOD设计，而且由于需求变化或新发现了错误，也要对OOA的结果进行修改。
本章的重点是对OOA结果进行补充与调整，要强调的是这部分工作主要不是细化，但OOA未完成的细节定义要在OOD完成。
1、为复用类而增加结构
2、提高性能
3、增加一般类以建立共同协议
4、按编程语言调整继承
5、转化复杂关联决定关系的实现方式
6、调整与完善属性
7、构造及优化算法
8、决定对象间的可访问性
9、定义对象实例
10、其他
如下针对一些主要的情况讲述如何进行问题域的设计
1、为复用类而增加结构
如果在OOA识别和定义的类是本次开发中新定义的，而且没有可复用的资源，则需要进一步设计和编程。
如果已存在一些可复用的类，而且这些类既有分析、设计时的定义，又有源程序，那么，复用这些类即可提高开发效率与质量。
可复用的类可能只是与OOA模型中的类相似，而不是完全相同对二者进行修改。
1）如果完全相同，就把可复用的类直接加到问题域，并用{复用}标记所复用的类。
2）如果大于，就把可复用的类直接加到问题域，并用{复用}标记所复用的类，所需要的累再继承它。
3）如果大于，就把可复用的类直接加到问题域，删除可复用类中的多余信息，并用{复用}标记所复用的类。
4）如果相似，按如下方法处理；
·把要复用的类加到问题域，标以“复用”。
·划掉（或标出）不用的属性与服务。
·建立从复用类到问题域原有的类之间的泛化关系。
·由于问题域的类继承了“复用”类的特征，所以有些属性和服务不需要了应
该把它们划掉。
·考虑修改问题域原有类的结构和连接，必要时移到“复用”类。
图6-2问题域中例题
2、提高性能
1）调整对象的分布
把需要频繁交换信息的对象，尽量地放在一台处理机上。
2）增加保存中间结果的属性或类
避免以后重复计算。
3）提高或降低系统的并发度，可能要人为地增加或减少主动对象。
4）合并通讯频繁的类
5）用聚合关系描述复杂类
如果一个所描述事物过于复杂，其操作也可能比较复杂，因为其中间可能要包多项工作内容。
对这种情况的处理，可考虑用聚合关系描述复杂类。
6）细化对象的分类
如果一个类的概念范畴过于大，那么它所描述的对象的实际情况可能就有若干差异。
解决的一个方法就是把类划分的更细一些，在原先较为一般的类之下定义一些针对不同具体情况的类。
在每个特殊类中分别定义适合各自对象的操作。
3、增加一般类以建立共同协议
1）增加一个类，将所有具有相同操作和属性的类组织在一起，提供通用的协议。
2）增加一般的类，提供局部通用的协议。
3）对相似操作的处理。
通过对特征标记做小的修改，以使他们相同，然后再把他们提升到一般类中。
4、按编程语言调整继承
由于在OOA强调如实地反映问题域，OOD考虑实现问题，所用语言不支持多继承，甚至不支持继承。
1）对多继承的调整
方法一：
采用聚合把多继承转换为单继承
因为聚合和泛化是不同的概念，这种方法并不是通用的（按定义）。
在大多数情况下，需要考虑形成多继承的原因，将本来在特殊类中显式定义的信息离出来，作为部分对象，以原来的一般类作为整体对象。
图6-3多继承中的一个继承换为聚合示例
图6-4所示的模型中有一个多继承，现假设编程语言不支持多继承，仅支持单继承。
图6-4多继承示例图6-5采用聚合的方式把多继承转换为单位继承示例
由于在图6-4所示的模型是按人员身份对一本类“人员”进行分类，并形成了其下的两个特殊类“研究生”和“教职工”，现在用身份作为一个类，依据它对原模型进行调整，如图6-5所示。
图6-5用类“人员”创建对象的用意不变。
创建类“研究生”的对象时，使用类“人员”和类“身份”以及自身的信息，类“教职工”也与此类似。
创建“在职研究生”的对象时，使用类图中的四个类的信息。
方法二：
采用压平的方式
采用这种方法，使得类“教职工”和“研究生”中的一些特征要在类的“在职研究生”中重复出现，导致信息冗余。
图6-6采用压平的方式把多继承转换为单位继承
图6-7采用压平和聚合的方式把继承转换为单位继承
2）取消继承
方法一：
把继承结构展平
图6-8完全取消继承示例
方法二：
采用聚合的方法
图6-9采用聚合的方式取消继承
3）对多态性的调整
在继承结构中，具有相同名字的属性和操作，在不同的类中可以具有不同的类型和行为。
这种在继承结构中对同一命令具有不同的含义的机制，就是继承的多态。
如果编程的语言不支持多态，就需要把多态有关的属性和操作的名字分别赋不同的含义，也即明确把他们是为不同的东西，不但如此，往往还要按实际要求，重新考虑对象的分类，并对属性和操作进行调整。
属性“边数”、“顶点坐标”和操作“绘图”不能被所有的特殊继承或不参加修改的继承，就说明它们只能适合多边形集合的一个子集，把这个子集定义为一个特殊的类“不规则多边形”，并把这些属性和操作下降到该特殊类中。
这样类“正多边形”和“矩形”也不能继承那些不适合自己的属性和操作，而是要自己进行的定义。
如图6-1所示。
图6-10多态性的调整示例
5、转化复杂关联决定关系的实现方式
（1）对复杂关联的转化
1）把多元关联和N元关联转化为二元关联
2）把多对多关联类转化为一对多关联
图6-11把多对关联转化为一对关联
在图6-11中类“供需合同”设立了两个属性“卖方”和“买方”在实例化后分别用于记录类“供货商”和“客户”的对象的标识。
若不仅仅需要从类“供需合同”的对象访问其他对象，还存在着其他对象的访问。
（2）关联的实现方式
对关联进行调整后，要考虑关联的实现方式。
A.聚合
决定在整体类中指出部分类时，是用部分类直接作为整体类中的属性的数据类型，还是把部分类用作指针或对象标识的基类型，再用这样的指针或对象标示定义整体类的属性。
如果是组合，最好用第1种方式，否则就需要在程序中保证整体对象与部分对象的生命周期的一致性。
B.关联
通常，通过在对象中设立指针或对象标识以指向或记录另一端的对象的方法，来实现关联。
如果是单向关联，就在源端的类中设立属性，用来标记另一端的类将来创建的对象。
如果是双向关联，就在两端类中各设立属性，用来标记对方将来创建的对象。
如果关联中对方类的多重性是1，那么可在本方设立一个指向对方对象的指针，或设立一个记录对方对象引用的属性。
如果对方类的多重性大于1，那么可在本方设立一个指向对方对象的指针集合或引用集合。
若关联的某端有角色名，最好把其作为另一端类的属性名，以访问与角色名相邻的类。
6、调整完备与属性
按照语法：
[可见性]属性名[‘：
’类型][‘=’初始值]
对属性的定义进行完善。
每一个属性或者包含单个值，或者包含作为一个整体的密切相关的一组值。
图6-12对编辑语言不支持的属性类型进行调整的示例
若要给出对属性的性质的约束，如“工龄<60”或“0≤英语成绩≤100”等，也要看语言是否对其直接支持，否则要在算法上考虑如何实现。
为了维护数据的完整性，必须要考虑需要一起更新的多个相关联的数据值。
特别是，当基本的数据发生变化时，必须更新导出的属性。
通过下列方法可以做到这一点：
1）显式的代码
因为每一个导出属性是根据一个或多个基本对象属性定义的，更新导出属性的一种方法是，在更新基本对象属性的操作中插入更新导出属性的代码。
这种附加的代码将明确地更新依赖基本对象属性的导出属性，使得基本属性与导出属性的值同步。
2）批处理性的重计算
当基本数据以批处理的方式改变时，可能在所有的基本数值改变之后，再重新计算所有的导出属性的值。
3）触发器
凡是依赖基本属性的属性，都必须将它自己向基本属性注册。
当基本属性的值被更新时，由专门设置的触发器更新导出属性的值。
7、构造和优化算法
对于需要设计的操作，要从如下几方面进行详细地定义：
1）按照定义操作的格式：
[可见性]操作名[‘（’参数列表‘）’][‘:
’返回类型]
完善操作的定义。
2）从问题域的角度，根据其责任，考虑实现操作的算法，即对象是怎样提供操作的。
3）若操作有前后置条件或不变式，考虑编程语言是否予以支持。
若不支持，在操作的方法中要予以实现。
4）建议进一步地分析特定类的对象相关的所有交互图，找出其所有与之相关的消息。
一个对象所要响应的每个消息都要由该对象的操作处理，其中的一个操作也可能要使用其他操作。
如果类拥有状态图，还可根据内部转换以及外部转换上的动作，设计算法的详细逻辑。
可用自然语言或进行了一定结构化的自然语言描述算法，也可以使用程序框图或活动图描述算法。
在算法中还要考虑对例外和特殊情况的处理。
如考虑对输入错误、来自中间件或其它软硬件的错误的消息以及其它例外情况的处理。
在系统较为复杂或需要处理大批量的数据的情况下，若系统在性能上有要求，就要对系统的体系结构和算法进行优化。
8、决定对象间的可访问性
从类A的对象到类B的对象有4种访问性
（1）属性可见性：
B是A的一个属性（关联、聚合）
classA
{…;Bb;…}
（2）参数可见性：
B的对象是A的一个方法的参数（依赖）
A.amethod（Bb）//间接地找到一个对象，并赋给b
（3）局部声明可见性：
B的对象是在A的一个方法中声明的一个局部变量（依赖）
classA:
:
amethod
{…;Bb;…}
（4）全局可见性：
B的对象在某种程度上全局可见（依赖）声明B的全局实例变
量。
对于后三种情况而言，从类A到类B间存在着依赖关系，在程序运行期间A的对象与B的对象存在着临时性的连接（临时链），而第一种情况中的链是由从类A到类B间的关联实例化而来的。
9、定义对象实例
在逻辑上，一个类是对一组对象的抽象描述。
在物理上，一个类所创建的各对象，要么在内存中，要么在外存中。
在内存中创建的一个对象，用一个变量记录它的标识。
在外存中的对象，可能保存在一个文件中，也可能保存在一个数据库表中。
在OOD中，根据不同的实现条件和实现策略，可以按如下的方式定义对象：
1）用相应的类定义内存中的全局性对象，包括静态声明和动态创建两种方式。
可以一次针对一个对象定义一个变量，也可以成批地定义对象。
例如，可以定义一个数组，它的每个元素是一个对象变量，以此来成批地定义对象。
2）当系统需要通过从外存读取数据来创建一个对象时，先创建该对象，再从外存中读取这个对象数据，把数据赋值给对象的相应属性。
按照一定的策略，内存中的永久对象要保存到外存中，请参看数据管理部分。
无论那种方式，都需要在在OOD文档中加以说明。
按如下格式在类描述模板的定义对象部分进行描述：
处理机：
<节点名>{，<节点名>}；
内存对象：
{<名称>[（n元数组）][<文字描述>]}；
外存对象：
{<名称>[<文字描述>]}；
10、其他
在OOD的问题域部分应该根据具体问题考虑使用设计模式。
在OOD的问题域部分，根据情况，还有一些其它需要考虑的问题。
例如，考虑加入进行输入数据验证这样的类；考虑对来自中间件或其它软硬件的错误进行处理的类，以及对其它例外情况进行处理的类。
有些作法是在OOD阶段不把这样的读写属性的操作放在类中，而认为这是一种约定，编程人员能理解。
有些作法也不把诸如创建和复制对象这样的操作放在OOD模型中。
第七章人机交互部分的设计
一、什么是人机交互部分
人机交互部分是OOD模型的组成部分之一，突出人如何任命系统以及系统如何向用户提交信息。
设计人机交互就是要设计输入与输出，其中包含的对象以及其间的关系构成了人机交互的模型。
图7-1设计员与用户协作设计人机界面的工作过程
把人机交互部分作为系统中一个独立的组成部分，进行分析和设计，有利于隔离界面支持系统的变化对问题域部分的影响。
二、人机交互部分的需求分析
对使用系统的人进行分析—以便设计出适合其特点的交互方式和界面表现形式；
对人和机器的交互过程进行分析—核心问题是人如何命令系统，以及系统如何向人提交信息。
1、分析与系统交互的人——人员参与者
人对界面的需求，不仅在于人机交互的内容，而且在于他们对界面表现形式、风格等方面的爱好。
—前者是客观需求，对谁都一样；后者是主观需求，因人而异。
（1）列举所有的人员参与者
（2）对人员参与者进行调查研究
（3）区分人员类型，并了解人员的主主观需求
（4）统计（或估算）各类人员的比例
（5）按照一定的准则进行折中与均衡
2、从用况（usecase）分析人机交互
usecase的构成
（1）参与者的行为和系统行为按时序交替出现，左右分明。
形成交叉排列的段落。
（2）每个段落至少含有一个输入语句或输出语句；
（3）有若干纯属参与者自身或系统自身的行为陈述；
（4）可能包含一些控制语句或括号。
抽取方法：
删除所有与输入、输出无关的语句和不再包含任何内容的控制语句与括号，剩下的就是对一个参与者（人）使用一项系统功能时的人机交互描述。
图7-2从用况提取人机交互描述的示例
三、如何设计人交互部分
1、设计输入与输出
（1）设计输入
1）确定输入设备
2）设计输入界面
3）输入步骤的细化
①输入步骤的细化
②输入设备的选择
③输入信息表现形式的选择（命令，数据）
（2）设计输出
1）确定输出设备
2）确定输出的内容和形式
3）①输出步骤的细化
②输出设备的选择
③输出信息表现形式的选择
2、命令的组织
不受欢迎的命令组织方式：
（1）一条命令含有大量的参数和任选项
（2）系统有大量命令，不加任何组织和引导
命令的组织措施——分解与组合
（1）分解：
将一条含有许多参数和选项的命令分解为若干命令步
（2）组合：
将基本命令组织成高层命令，从高层命令引向基本命令
基本命令：
使用一项独立的系统功能的命令。
（提取后的用况）
命令步：
在执行一条基本命令的交互过程中所包含的具体输入步骤。
高层命令：
如果一条命令是在另一条命令的引导下被选用的，则后者称作前者的高层命令。
（a）线性结构
图7-3基本命令及其命令的结构
图7-4高层命令及其结构
高层命令按功能组织：
如文件下有：
创建、打开、关闭、打印、删除等。
按子系统组织：
如文本编辑子系统、编译自系统。
在两个命令之间通常要输出信息，如图7-5所示。
图7-5a表示两个命令步之间不存在这输出信息结构。
图7-4b表示连个命令步之间可能存在三种输出信息结构。
第一种为反馈信息，在一个命令需要较长的时间执行时，应该向用户显示当前命令的情况，给出一个进度；第二中处理结果，当前命令执行的结果可能要向用户显示；第三种提示信息，即对下一步可输入的命令的提示。
图7-5c表示两层命令之间的更为复杂的输出信息结构。
图7-5命令之间的输出信息结构
在建立命令树时，应遵循如下策略：
a.把使用最频繁的命令放在前面，按照用户的工作步骤进行排列。
b.在命令中发现整体-部分模式，以帮助对命令的组织与分块。
c.每层命令的个数应遵循7+2原则，命令的层次深度尽量要控制在三层以内。
3、用OO概念表达所有的界面成分
1）每一种窗口对应于一个类。
2）在窗口中，按照命令的逻辑层次，部署所需要的元素，如菜单、工作区和对话框等。
窗口中的部件元素对应窗口类的部分类，部分类与窗口类形成聚合关系。
3）发现窗口类间的共性以及部件类间的共性，定义较一般的窗口类和部件类，分别形成窗口类间以及部件类间的泛化关系。
4）用类的属性表示窗口或部件的静态特征，如尺寸、位置、颜色和选项等。
5）用操作表示窗口或部件的动态特征，如选中、移动和滚屏等。
有的操作要涉及到问题域中的类。
6）发现界面类之间的联系，在其间建立关联。
必要时，进一步地绘制用户与系统会话的顺序图。
7）建立界面类与问题域类之间的联系。
有些界面对象要与问题域中的对象进行通讯，故要对二者之间的通讯进行设计。
在具体设计时，设计人员应该注意以下几点：
（a）人机界面只负责输入与输出和窗口更新这样的工作，并把所有面向问题域部分的请求转发给问题域部分，即在界面对象中不应该对业务逻辑进行处理。
（b）一种常见的作法是，问题域部分的对象不应该主动发起与界面部分对象之间的通讯，而只能对界面部分对象进行响应，也就是说，只有界面部分的对象才能访问问题域部分的对象。
通常把界面对象向问题域部分对象传输的信息或发布命令看作是“请求”，而把从问题域部分对象向界面部分对象传输的信息看作是“回应”或“通知”。
（c）尽量减少界面部分与问题域部分的耦合。
由于界面是易变的，从易于维护和易于复用的角度出发，问题域部分和界面部分应该是低耦合的。
图7-6问题域部分与人机交互部分通过接口进行联系
也可以通过在人机交互部分和问题域部分之间增加控制器或协调类的方式解决这种问题，如可采用下面将要讲述的出版-订阅模式，还有一些相关的模式。
例题1：
出版-订阅模式（观察者模式）
图7-7用三种方式对一组不断变化的数据进行实时地显示
图7-8采用发布—订阅模式衔接问题域部分和人机交互部分
该模型中，订阅者向发布者订阅所感兴趣的事件，出版者向发布者发布事件，发布者维护出版者和订阅者的映射。
当数据变化时，发布者把出版者发布的数据情况利用消息通知给订阅者。
订阅者是人机界面模型中的一部分，出版者是问题域中模型中的一部分，发布者是人机交互部分和问题部分之间的协调器。
例题2用OO概念表达界面成分
图7-9两种方式示例
图7-10两种复用方式示例
在可视化的编程环境下设计工作大为简化，往往不需要建立上面那样的模型。
若有必要建立这样的模型，可以直接使用可视化编程环境或类库所提供的可复用类。
在复用时一种方式是直接使用，即把所复用的类标上{复用}，在类图中直接使用。
另一种方式是对复用类进行继承，已进行扩充。
如图7-10所示。
由于复用类的子类可能要使用祖先类的操作和属性，这样就出现了在图上看不到祖先类的操作和属性。
解决问题的方法是，把所需要的祖先类的操作和属性，在标有{复用}的类中重新列出来，并加上标记，如“√”，表明这些属性和操作是继承而来的，不需要在本系统中实现，这样做仅仅是为了使用方便。
4.人机界面的设计准则
1）易学、易用、操作方便
2）尽量保持一致性
3）及时提供有意义的反馈
4）使用户的注意力集中在当前的任务上而不是界面上
5）尽量减少用户的记忆
6）具有语境敏感的帮助功能
7）减少重复的输入和操作
8）对用户的操作具有容错性,如UNDO
9）防止灾难性的错误
其它：
如艺术性、趣味性、风格、视感等
升级会员 