当前位置：首页 > news >正文

用户界面软件03

news 来源：原创 2025/5/14 21:54:55

一种标准的满足不同的非功能性需求的技术是对子系统进行不同的考虑……但是一个用户
界面要求有大量的域层面的信息，以符合比较高的人机工程标准，所以，这些分开的子系统还是
紧密地耦合在一起的。

一个软件架构师的标准反应是将不同的非功能性需求放在不同的子系统里面。这种方法在优
化自己的子系统时比较自由。如果是用户界面的话，这样子就需要一个子系统管理用户界面，另
一个子系统管理域层面。不过，这种方法好吗？子系统界定的一个主要标准是它们之间的相互传
送的信息量。现代的用户界面给用户提供大量信息：列表框可以提供选择信息，树状示意图帮助
定位特定的对象，灰色菜单和按钮让你避免做蠢事。所有的这些都会使得子系统之间的耦合性很
高。

现代的开发环境通过特定方法可以很方便地操作用户界面……但复杂的系统需要有不同的
界面来满足不同的需求，为了满足这些不同的需求，这些用户界面又可能需要不同的设计。
象SmallTalk 或Java 这些语言，通常需要一行代码来使得某个菜单选择失效，或者弹出一
个简单的对话框来提醒用户。所以，当你的域层面的代码（domain code）里发生了一些奇怪的
事情时就总想提示用户，问：“要不要继续运行？（是/否/帮助）”然而，这真的是一个好主意吗？
或迟或早你就会发现有不同的用户要对系统进行操作。它们必须每天重复上千遍的工作，希望按
尽可能少的键来让这个系统帮他完成工作。一个弹出的对话框反而会妨碍他的工作，相反，他们
希望系统把问题记录在问题记录表中，等以后再看。你就需要一个完全不同的用户界面布局。或
者考虑一下你的系统在批处理运行模式中的情形：当然，如果让一个系统从早上2:30 开始等到
用户的决策，直到9 点钟操作人员来了，看到的是屏幕上一个无成效的提示的话，是没有人会开
心的。最后，你的系统可能在没有任何用户界面的环境中运行，比如，某个荒无人烟的地方的一
个电话交换系统：没有人在现场操作，而是远程操作。这时如果在本地终端上显示一个对话框，
而等待一个300 英里外的操作员去应答，这可就不是一个好主意。类似的情形在全球商业系统中
会出现得越来越多。所以一个远程操作界面就需要一个和需要输入大量数据的系统完全不同的架
构，它需要一个和有高程度交互的系统不同的架构。大部分的开发环境不能很好地支持这些架构。
最后，域层面的软件可能有些抽象，用户不能理解……但是域层面的结构经常将这些显露在
用户界面上。

在进行分析时，大部分系统都会变形，开始时是领域专家们很具体的想法，到了最后就成了
抽象的对象模型，而且对可复用性，可维护性，是否容易设计等进行考虑。如果这个系统要满足
广泛的需求，分析家们甚至可能会决定建立一个元模型。这些是软件专家而不是领域专家们的决
定。通常情况下，最后得到的结果是领域专家看不懂的。为了保证可用性，你又得将抽象的领域
模型转换回用户的角度。不过，这是一个好主意吗？最起码，将对象结构转换成不同的结构是额
外的工作。假如领域层面的模型和你要展示在用户面前的模型不兼容，这个工作量可能就是一场
噩梦。最好的例子就是一个在面向事务的领域模型上的面向对象的用户界面：这些系统通常情况
下直观程度和性能是比较差的。

解决方案所以要将用户界面和领域层面分离，放在两个不同的子系统里面。确保领域层面子系统不对用户界面部分进行任何引用，然后形成一个层状架构。

必须说明的是，这个方案里层状特性非常重要：用户界面层可以调用领域层，但反之则不行。
当一个“回调”无法避免时，我们需要特殊的机制来保证这个层状方案，存取领域层（Access Domain Layer）讲的就是这个。

相关文章：