下载掌阅APP，畅读海量书库
立即打开
视图表达的是在人与系统交互过程中的某一时刻系统的状态，以及用户在这一时刻可能改变系统状态的方法。视图从概念上分为具体视图和抽象视图。对于一个计算机系统的设计，具体视图的典型例子可以理解为屏幕或视窗（window）的最终设计。用户能看到任何一个屏幕的状态就是一个视图。这种视图包括屏幕设计的所有细节，例如，屏幕上有一个按钮，这个按钮的大小、位置、颜色、文字内容、字体等内容都是完全具体的、直观的、可见的。很明显，具体视图是在人机界面设计的后期阶段产生的。在视图设计过程的初级阶段，视图的表达不可能，也没有必要达到百分之百的具体程度。所以，在人机界面设计最终完成之前的不同设计阶段产生的视图都会有不同程度的抽象性。所有相对具体的视图都是从某种程度的抽象视图具体化而得到的。
抽象设计不仅决定了系统运行的方式和方法，为总体系统设计提供至关重要的指导，而且抽象设计还为系统的不同实施方案提供了灵活性。例如，假设以上提到的学生注册系统被实施在视窗系统（Windows）平台上，则屏幕的某个状态可以包括若干个字符段、输入框和按钮等元素。但是，如果同样功能的系统被实施在小屏幕的个人数字助理（PDA）、手机，甚至语音操作的系统上，则以视窗系统为基础的具体视图设计就变得部分地或全部地不适用。但是，抽象视图所描述的内容，包括支持类似功能的系统的运行逻辑和观念，人机交互的行为过程等却相当类似。例如，不论是视窗系统还是语音系统，用户都需要用某种方式输入课程的关键字而对课程进行查询，查询到的课程也具有同样的属性和行为，只是输入和输出方式因不同的实施方式而不同。
抽象设计的一种有效的、系统的方法是仔细研究系统对象模型化的结果并列出其意味的系统状态。用通俗的话讲，就是在审视对象模型时随时提问：这里是否需要一个视图或屏幕？例如，图4-1中讨论的系统对象模型可能就意味着下面的视图：
（1）学生查询课程数据库的视图；
（2）学生查询课程后得到的课程查询结果列表视图；
（3）学生在查询后进行与课程注册有关操作时某课程具体信息的显示视图；
（4）教师进行课程内容管理时某课程具体信息的显示视图；
（5）教师和学生都可以查看的公告栏视图；
（6）学生输入关于某课程问题并向教师发出问题的视图；
（7）教师输入问题答案并发送给学生并发布在公告栏的视图。
在系统对象模型中，与人机交互界面最相关的部分是连接人物（动作执行者）和系统元素的线段，这些线段往往代表了系统不同时刻的状态。从以上分析可以发现，在示例对象模型中任何连接人物和对象之间的线段往往直接对应着某一个视图。
在列出了这些可能的视图后就需要进一步定义这些抽象视图的特征。图4-2分别表达了下面的两个视图：
（1）学生进行与课程注册有关操作时某课程具体信息的抽象视图；
（2）教师进行课程内容管理时某课程具体信息的抽象视图。
比较这两个分别用于学生和教师的关于课程内容的抽象视图就会发现，两个视图之间有很多相似之处。在本例中，“课程”对象与一个以上的人物相联系，而在对象模型化时列出的“课程”的属性和行为并未按其适用的动作执行者进行分离。所以两个视图中的所有属性和行为都是对象模型化中课程类的属性和行为的子集。在学生使用的课程视图中，应当只包括适用于学生的内容，在教师使用的课程视图中应当只包括适用于教师的内容。例如，只有教师可以对课程进行更改内容、发布信息和答案的操作，同时，只有学生可以对课程进行注册。
图4-2 抽象视图的例子
如果将上述的两个抽象视图的所有属性和行为全部合并，也未必能得到对象模型化中课程类的属性和行为的总和。在本例中，两个视图都未包括“查询”这一行为。其原因是，对于学生，这一视图表达的是查询的结果；对于教师，“查询”课程这一功能并不适用。所以“查询”这一功能只会出现在学生得到查询结果的前一个视图的分析中。由于类似的原因，对于教师适用的“提出新课”和“删除课程”的功能也未列在教师进行课程管理时看到的课程具体内容的抽象视图中。这意味着设计者认为这两个功能应表达在显示课程列表的视图中。