Paulo Pinheiro da silva, Norman W. Paton 著, 李巍 译
摘要
统一建模语言（UML）是对应用程序进行面向对象建模的标准标记语言（notation），因此我们会很自然地将其作为用户界面（UI）建模的选择。但是，我们并不清楚如何使用UML 来进行UI 的建模。本文给出了一个使用UML 进行用户界面建模的案例。该案例指出了那些无法使用UML 标记来进行建模的UI 侧重面，以及一组可用于UI 建模的UML 构建法（constructor）。其中的建模问题说明了使用UML 进行UI 建模的一些缺陷，而采用的这组构建法也同时表明了一些该方面的能力。这些被证实的能力和缺陷可作为公式来表达成一种对UML 进行扩展（extend）的策略，从而对用户界面的设计提供更好的支持。
1 介绍
UML[10,2]是软件应用程序进行面向对象建模的标准语言。用户界面，作为大多数应用程序的一个重要部分[17]，也应该采用UML 来进行建模。事实上，UML 会很自然地被用作UI 建模的标记语言。然而，我们一直就不清楚如何使用UML 来进行用户界面的建模。而对于像用户任务（user task）和表现层（presentation）这样的用户界面元素，是如何在UML 应用模型中得到支持的，这一点并不能很容易进行标识。而且很少有报告能够很明确地描述一个应用UML 来建模UI 的项目。此外，许多UI 设计过程中出现的建模问题，例如本节所描述的案例，并没有全部在基于UML（UML-based）的设计方法或UML 规约（specification）中予以提及（address）。
许多已出台的提议（proposal）使用了一些不同的标记，用来支持UI 元素的设计模型。例如，关于用户任务（user task）设计方面的研究，可参见Kirwan 和Ainsworth 的书[14]以及Johnson 的书[13]。另外，还有一些提议使用其所公布的模型来进行UI 设计，具体描述可参见Griffiths 等人的书[9]和Szekely 的书[19]。因此，最好的情形是，如果目前已有的建模方式能够有效地用来构建UI，那么就不必再发明一种新的方法。进一步说，一种好的方法就是无论对于UI，还是应用程序的其它部分，我们都能使用相同的方式来进行构建。的确，使用单一的标记，对于整合一个面向对象的用户界面的全部设计是非常有用的。这个领域同样也有许多的研究成果，例如Kovacevic[15]，但是仍然未能很清楚地标识出哪些UI 侧重面可以使用UML 来进行描述，而哪些则不能。
本文旨在概括性地描述一个较为全面的用户界面建模的UML 案例。该案例需要说明以下两个意图：（1）使用UML 时的一般UI 建模问题；（2）应用程序开发者在进行UI 设计时，可以使用的一组UML 构造法和UML 图。
从这些建模问题中，我们可以看出哪些UI 侧重面（aspect）是在UML 中所没有涉及到的。从这组构造法中，我们也能看出哪些UI 侧重面已经包含在UML 中。因此，该案例提出了一种简易的方式来使用UML 进行UI 建模。
另外，为了对用户界面的设计提供更好的支持，本文还描述了哪些元素可用于开发一个对UML 进行扩展的策略。
该案例有意地没有描述任何一个在UI 设计过程中使用的方法。的确，为了克服已知的难点，许多方法可以作为一种方式来考虑，并以此找出可供选择的建模方法。这里指的是仅使用UML 来解决那些已确认的UI 建模问题。
该案例只考虑基于窗体（form-based）的用户界面。事实上，一些比较重要的用户界面种类，例如数据库系统的UI 和web 应用的UI，都主要是基于窗体的。基于窗体的用户界面的局限性则是指，像游戏，文字处理软件以及仿真器等应用程序的用户界面并不包含在该案例中。尽管如此，本案例介绍的这个UI 模型可作为一个UI 模型基线（model baseline），来开发基于UML 的更全面的UI 模型。诚如该案例所考虑的那样，对于大多数UI 设计者而言，对可视化组件（窗口组件）的使用进行建模，要比对窗口组件本身进行建模显得更为重要。因此，该案例论述的是窗口组件如何被应用程序使用，而不是如何对窗口组件进行建模。