对象、视图和交互设计是一种通过对用户、目标和任务的分析,系统地指导人机界面设计以达到用户满意的设计方法。对象模型化(object modeling)和对象分析(object analysis)是将用户和任务分析的结果转化为用户界面设计的第一步。所谓模型化是指将某些概念及其关系用图的方式直观而又综合地表达出来。用户和任务分析往往能够为对象模型化和分析提供非常丰富和有价值的信息,这些信息需要归纳和整理并且用简练的方式表达出来才能够被有效利用。
应用面向对象的设计理念,对系统的表达首先要确认系统的对象并将其抽象为类(class),然后列出对象或类的属性和可能的行为,最后描述出对象或类之间的关系。最直接的列举对象和类的方法是仔细阅读所有用户研究结果的资料,找到所有的名词。对于一个典型的系统设计的用户研究分析往往可以列举出几十个或上百个名词。分析人员需要根据这些名词的关系以及对于系统设计的重要程度分类整理,作为对象模型化的元素和资料。例如,在以上章节中讨论过的课程注册系统,系统的对象可能包括学生、教师、数据库系统、课程等对象或类。
在第3章中所讨论的UML是应用对象、视图和交互设计的有效工具。全面描述一个系统的对象及其关系往往需要通过多个UML图才能完成。每个UML图所描述的内容以及侧重的方面完全取决于系统设计的需要,图4-1所示为一个注册系统对象模型化的示例。图中人物标志代表与系统设计有关的“动作执行者”(actor),在图中有“教师”和“学生”两个“动作执行者”。
图4-1中下面有两条横线的方框表示对象或类。这些对象或类是通过将用户分析时发现的名词归纳提炼而得到的。对于某个特定系统,某些名词可能是具体的对象(例如学生)。但是如果将这些对象推广为一般情况,则对象就变成了类。在对象模型化时,严格区分对象和类往往是不必要的。为了简化文字,在以下的讨论中我们只提及对象。
图4-1中描述了7个对象:计算机系统、课程数据库、课程查询结果(列表)、课程、公告栏、问题和答案。描述“课程”的方框最为复杂,在“课程”对象名下分别列举了课程的若干属性和行为。例如任何课程的属性包括:名称、编号、介绍、水平要求等,与任何课程可能有联系的行为包括:查询、信息打印、教师更改等。由于这一示例图的重点是描述学生、教师和课程之间的关系,所以其他的对象只列出了名称,用于填写属性和行为的地方都是空白。
图4-1 对象模型化的示例
图4-1中的箭头是指动作关系,箭头连线上的文字标出了动作的内容。图中所表达的动作包括:
——学生可以查询数据库,浏览课程查询的结果;
——学生可以对某课程进行与注册有关的操作,例如注册、取消注册、存储、打印等;
——教师可以对某课程进行与内容管理有关的操作,例如增加、删除、更改内容等;
——学生可以向教师提出问题,教师对学生的问题提供答案。
图4-1中一端有一菱形的线段表示从属关系。线段有菱形的一端连接的是含义较大或内容较多的概念,另一端连接的对象从属于菱形一端连接的对象。图中所表达的这类关系包括:
——计算机系统包括课程数据库;
——课程数据库中包括或产生课程查询结果列表;
——课程查询结果列表中包括若干课程;
——某个课程的信息可以包括该课程问题及答案。
在连接课程查询结果列表和课程之间线段上的“1… n ”的标识是指任何课程查询结果列表必须包括至少一个课程。另外,如果课程数据库中没有满足用户输入的查询标准的课程时,则不应当显示课程查询列表。在实际的设计中,用户界面可以显示类似于“在系统中无法找到您所查询的课程,请更改查询标准”的提示信息。
在对象模型化时会经常发现,某些对象既可以被表达为单独的对象,也可以被表达为某对象的属性。例如,在图4-1中,关于某课程的“公告栏”是作为一个与“课程”对象有从属关系的单独对象表示的,而“问题”和“答案”又分别是作为与“公告栏”对象有从属关系的单独对象表示的。从逻辑关系的角度看,公告栏可以作为课程的属性标示在课程对象的方框中而与课程的其他属性并列。但是,如果这样做,则此UML图就很难清晰表达公告栏、课程问题、答案以及教师和学生的关系。所以,在使用UML进行设计时,应当根据表达内容的需要决定图示中的元素内容和关系表达方式。