图形用户接口建模系统的制作方法

专利名称：：图形用户接口建模系统的制作方法
技术领域：
：本发明涉及人-计算机交互领域，尤其涉及用户接口建模。
背景技术：
：用户接口的构建和维护对于大而复杂的系统正成为一个核心问题。用户接口是应用和用户之间的桥梁，并因此而须适应两者的复杂性。随着新技术的出现以及以用户为中心的关注，交互系统的用户接口部分日益增大且昂贵。更快、能力更强的机器和网络为用户提供了更多的功能和信息，但同时也用更多的命令和选项淹没了他们。用户接口需要变得更加智能化以帮助用户在执行他们的任务时更加简便、更加直观地学习，并允许用户进行个性化定制，从而能够根据特殊的用户需求和偏好对用户接口进行裁剪。跨越很宽范围设备的应用需为用户提供相同或缩减版本的工作站功能。新的模件如语音、自然语言、手写识别正在成熟起来，可能需要被结合到用户接口中。现代交互技术如直接操作或动态查询要求在用户接口中有很高程度的并行性。所有这些以及更多的因素使得用户接口难以设计和实现。因此很多调查显示软件系统的用户接口部分占整个系统开发努力的很大部分。例如，一项涉及很大范围的项目、平台和开发工具的调查显示，用于用户接口的代码量以及设计、实现和维护的时间在典型的软件项目中所占的百分比约为30-50％。对付用户接口开发的日益增加的困难性要求有新的措施，就是不基于编程。在过去提出了用于不进行编程来描述用户接口的不同方法，包括代数描述、基于语法的语言、推移图、基于规则的系统，以及用演示来描述。然而，这些方法无一被广泛采用。开发组织拒绝采用规则描述因为它们难以理解、不具有足够的表达力、通常无法执行，因此而被认为是不必要的附加劳动。结果是用户接口开发的通常实践仍然主要是基于编程。
发明内容本发明涉及用于不经手工编码而创建用户接口(UI)的建模系统或可视工具。该建模系统用于对用户接口的通用和说明性描述。该系统提供用于以独立于任何实施语境的方式定义用户接口、包括高复杂和动态的用户接口的装置。本发明的一种实施方式涉及以可理解的术语进行用户接口建模的系统，从而使得用户接口设计易读和易交流。优选这样的系统具有足够的表达力，以便能够对任意复杂和动态的用户接口建模。更优选的是，该系统能够自动将用户接口模型翻译成可执行代码，从而可以跳过费力且易出错的编程过程。在一种实施方式中，建模系统满足下述三条原则(i)简单得足以使人能够理解和设计，(ii)具有足够的表达力以描述信息处理应用的各种用户接口，以及(iii)是计算易处理的，即由该系统通过解释、编译或翻译能够产生可执行的用户接口代码。该系统或可视工具是使设计者可以可视地建立UI模型并然后产生运行用户接口的计算机程序，即将可视表示转换为可执行代码。该系统的核心是表示和实现建模元素的各方面(对于设计时间和运行时间)的面向对象类的动态集合。这些类是可扩展的，使得该系统可以扩展并适于各种建模方法、甚至非UI建模应用，如业务工作流、数据库规划，等等。本建模系统的一种实施方式是GUIMachine建模系统(也称为“GUIMachine故事板”或“GM故事板”、“GM建模系统”、或“故事板”)，其是用于建立用户接口的固件。GM建模系统通过使用工具包、连接器，或模型元素库以及考虑不同UI设备和实施技术的特征区别的相关规则而适于不同的用户接口(UI)类型。在本实施例中采用一个适用于多种UI技术(SAPEP5和SAPEP6，HTMLB，WebDynPro，Net，等等)的通用工具包。这使得可以对所有这些UI技术使用一个模型，从而设计者仅需构建一个模型，将其翻译到这些各种技术中而无需调整模型本身。在GM建模系统中，用户接口模型或GM模型通过设计协作过程从用户和应用需求中导出。作为UI的可视表示的用户接口模型通过代码产生过程，对每个用户接口语境都被翻译成用户接口代码。在本发明的实施例中，用于产生业务解决方案程序或iView的方法包括选择程序包和选择与该选择的程序包相关的页。选出的页具有多个与其相关的iView。选择第一业务功能组件。选择第一操作符。为了创建另一iView，第一业务功能组件的输出端口连接到第一操作符的输入端口。第一业务功能组件为第一操作符提供数据以处理或操纵数据。该方法还包括将第一操作符的输出端口连接到第二业务功能组件的输入端口。将第二业务功能组件的输出端口连接到第三业务功能组件。替代地，还可以将第一操作符的输出端口连接到第二操作符的输入端口。一旦选择了期望的业务功能组件和操作符并按照给定的配置来安排，可视工具就产生用于业务解决方案程序的代码或iView。还可以使用单独的编译器来产生代码。所产生的代码不需验证。所产生的代码不需性能调节。在另一个实施例中，提供了用于使用可视工具产生程序的方法，其包括选择与业务层相关联的可重用应用组件。业务层与一个或多个数据库相关联。选择一个配置用来以给定方式处理数据的操作符。可重用应用组件与该操作符链接。根据该可重用应用组件与该操作符之间的关系产生门户内容组件。可重用应用组件是业务应用程序接口(BAPI)或远程函数调用(RFC)。门户内容组件是iView。在另一实施例中，描述了用于产生用户接口的方法。用户接口被配置用于客户机-服务器环境。该方法包括提供一个编辑器，用于设计用户接口的可视表示，该编辑器提供要在前端系统的显示设备上显示的工作空间和任务板，该工作空间用于在其上设计可视表示，该任务板提供多个在设计可视表示中使用的元素，其中一个或多个元素与远离该前端系统的后端系统相关联。从任务板选择第一演员，该第一演员是所述元素之一的数据源对象并包括访问该后端系统中提供的应用层所需的应用逻辑。将该第一演员插入工作空间。将从任务板选出的第二演员插入工作空间。以图表定义该第一演员和第二演员之间的关系。从该第一演员和第二演员以及它们之间的关系产生可执行代码。在另一实施例中，提供了一种利用建模系统产生用户接口的方法，包括提供一个编辑器，用于设计用户接口的可视表示，该编辑器提供要在前端系统的显示设备上显示的工作空间和任务板，该工作空间用于设计其上进行的可视表示，该任务板提供多个在设计可视表示中使用的元素，其中一个或多个元素与远离该前端系统的后端系统相关联；在工作空间中显示由用户选择的情节，该情节与用户对用户接口的需求相一致，该情节包含多个交错的情景；根据从用户接收的输入定义多个情景中的每一个情景，每个情景包含同时活跃和协作的演员，这些演员是表示行为线程的专用计算单元，其中每个情景通过图表地定义与该情景相关联的演员之间的关系而被定义；产生由这些情节和情景表示的模型的规范表达；由该规范表达产生可执行代码。在另一实施例中，提供了一种用于在分布式计算机系统中产生用户接口的方法，包括将第一用户选择的第一业务功能组件显示在前端系统的第一显示区域上，该第一业务功能组件与访问由后端系统提供的第一业务应用的第一应用逻辑相关联；将第一用户选择的第二业务功能组件显示在前端系统的第一显示区域上，该第二业务功能组件与访问由后端系统提供的第二业务应用的第二应用逻辑相关联；形成该第一和第二业务功能组件之间的关系，其中，根据显示步骤和形成步骤建立用户接口的可视表示。在另一实施例中，提供了一种分布式计算机系统，包括用于将第一用户选择的第一业务功能组件显示在前端系统的第一显示区域上的装置，该第一业务功能组件与访问由后端系统提供的第一业务应用的第一应用逻辑相关联；用于将第一用户选择的第二业务功能组件显示在前端系统的第一显示区域上的装置，该第二业务功能组件与访问由后端系统提供的第二业务应用的第二应用逻辑相关联；以及用于形成该第一和第二业务功能组件之间关系的装置，其中，根据显示步骤和形成步骤建立用户接口的可视表示。在另一实施例中，提供了一种包括计算机程序的计算机可读介质，该计算机程序包括用于将第一用户选择的第一业务功能组件显示在前端系统的第一显示区域上的代码，该第一业务功能组件与访问由后端系统提供的第一业务应用的第一应用逻辑相关联；用于将第一用户选择的第二业务功能组件显示在前端系统的第一显示区域上的代码，该第二业务功能组件与访问由后端系统提供的第二业务应用的第二应用逻辑相关联；以及用于形成该第一和第二业务功能组件之间关系的代码，其中，根据显示步骤和形成步骤建立用户接口的可视表示。在另一实施例中，提供了一种计算机系统，其包括在与前端系统耦合的后端系统上提供的应用；以及计算机可读介质。该计算机可读介质包括用于将第一用户选择的第一业务功能组件显示在前端系统的第一显示区域上的代码，该第一业务功能组件与访问由后端系统提供的第一业务应用的第一应用逻辑相关联；用于将第一用户选择的第二业务功能组件显示在前端系统的第一显示区域上的代码，该第二业务功能组件与访问由后端系统提供的一个或多个业务应用的第二应用逻辑相关联；以及用于形成该第一和第二业务功能组件之间关系的代码，其中，根据显示步骤和形成步骤建立用户接口的可视表示。在此描述的用户接口建模系统提供了各种益处。该系统是陈述封闭的，从而使用户接口的所有不同方面都能纯粹地用建模语言的陈述术语来表达。该系统提供了简单得足以由人类读取和交流的表示。该系统是计算易处理的，因此可以自动地从有效模型中确认、仿真并产生工作的用户接口。该系统具有说明在保持可用性的同时能经受使用语境变化的弹性用户接口模型的能力。该系统鼓励可更改性并且不强制于任何开发策略。该系统使得在使用语境内或之间具有很强的并行性。该系统为其表示提供了基于知识的存储机制。该系统允许对其所表示的用户接口模型的各个方面进行扩展。从下面借助附图的描述中可以更好地理解本发明系统和方法的原理和操作，应当理解，附图所示仅为了说明的目的，而非进行限制。其中示出图1示意性示出交互式计算机系统；图2示意性示出根据本发明实施例的用户接口模型；图3A示意性示出根据本发明实施例的用户接口建模系统；图3B示出根据本发明实施例的多个可视表示、规范表达和用户接口代码之间的关系；图3C和3D示出根据本发明实施例的基于模板的建模系统；图4示出根据本发明实施例的可视建模语言的符号结构；图5示出其中可以根据本发明的实施例实现建模系统的企业门户系统；图6示出根据本发明的实施例设计用户接口模型的方法的流程图；图7A示出根据本发明实施例的建模系统的规范表达的建模层；图7B示出根据本发明的实施例用于设计在企业门户环境中使用的用户接口的方法的流程图；图7C示出根据本发明的实施例用于建立门户表示组件的方法的流程图；图7D示出根据本发明实施例的包括数据源层、UI逻辑以及UI布局的门户表示组件；图7E示出根据本发明实施例的包括多个表示组件的门户页；图8示出根据本发明的实施例在安装了GUIMachine时出现的屏幕；图9示出根据本发明的实施例用于打开新的模型以开始创建用户接口的屏幕；图10A示出根据本发明的实施例插入到GUIMachine的工作空间的数据源对象；图10B示出图10A的规范表达；图11A示出根据本发明的实施例对向iView定义UI逻辑；图11B示出图11A的规范表达；图12示出根据本发明的实施例用于定制iView布局的屏幕；图13示出根据本发明的实施例用于预览由iView获得的结果的屏幕；图14示出根据本发明的实施例用于显示已建立的iView的规范表达的屏幕；图15示出根据本发明的实施例显示已由iView的规范表达编译过的可执行代码的屏幕；图16示出根据本发明的实施例利用图15的可执行代码显示的门户内容；图17示出根据本发明的实施例用GUIMachine建立的模型的层次组织。具体实施例方式本发明涉及用于在不用编写代码的情况下建立用户接口(UI)的建模系统或可视工具。该系统提供用于以独立于任何实现语境的方式定义用户接口、包括高度复杂和动态的用户接口的装置。在本发明的优选实施例中，该建模系统来源于用户接口的用户友好的可视表示，通过对用户接口部件的结构和特性方面渐进的详细描述，直至在其所有使用的语境上得到用户接口的严格定义。利用由设计者建立的UI的可视表示，该建模系统可以自动产生完全可工作的用户接口代码。在图1中示出客户机-服务器环境中交互式计算机系统的一般性示图。交互式计算机系统(服务器)100为一个或多个用户(客户机)提供应用并通常可分为后端和前端子系统110和120。后端系统110担当应用的宿主并包括应用软件111以及任意数量的存储、联网及服务器硬件。应用软件是控制后端系统对应用数据进行存储、检索、处理和通信的程序代码。应用软件可以在中央处理器上执行，也可以分布在各种结构的任意数量的处理器中执行。应用软件在本领域也称为中间层或业务逻辑层(BL)。用于应用的数据与数据库层相关联。因此后端系统110包括应用层和数据库层。前端系统120是交互计算机系统中负责系统的用户和在后端系统上运行的应用之间交互的部分。前端系统包括用户接口软件121和任意数量的输入/输出设备。用户接口软件分析和解释输入、设计并给出输出，以及对用户和应用软件之间的交互进行管理。用户接口在本领域还称为人-机接口(MMI)、人-计算机接口(HMI)或表示层(PL)。在本领域中有各种用户接口从简单的单设备、单线程、单用户接口到复杂的多模块、多设备、多线程和多用户的用户接口。前端系统可以包含任意数量的用户接口语境，每个语境是用户类型、输入/输出设备和用户接口技术的不同组合。为图解起见，图1示出三个示例性的用户接口语境122a、122b、122c。用户接口语境122根据用户参数(需求、目标和偏好)、硬件参数(屏幕尺寸、存储器大小、网络带宽、输入设备)、软件参数(图形引擎、程序设计语言)和环境参数(周围噪声、照明条件、用户位置)来定义。通常，开发用户接口需要考虑很多，需要知道用户想用UI做什么、定义用户可能期望执行的不同任务，以及考虑要在后端系统和前端系统处理的不同数据格式。因此，用户接口软件的特殊实现取决于用户接口在其中被使用的语境。因此，不同的用户接口语境导致不同版本的用户接口软件，其以潜在不同的程序设计语言编写、采用不同的软件库、并为不同的用户目标和需求以及不同的设备限制而裁剪。这些用户接口版本最终通过根据应用合同130来回传递信息来与后端系统上的同一应用代码通信。由于这些复杂性，迄今难于提供能够建立可与多平台兼容或结合业务逻辑、或两者都具备的通用UI软件的可视工具。结果，UI软件主要基于编程，而这是慢的、费力的、且是易出错的。此外，由于用户接口逻辑被埋藏在代码中，很难随着时间对其改进和维护。再者，由于用户接口的每个版本均需单独编码，通常只有很少的代码重用，用户接口的开发和维护由于版本、后勤以及一致性因素而日趋困难。图2示出根据本发明实施例的用于基于建模而非编程来开发用户接口的建模系统。通过从用户接口开发过程中消除编程需求，该实施例也消除了大部分与编程相关的问题，因此提供了用于开发和维护用户接口的有成本效益的手段。用户接口模型220是对给定应用的用户接口的说明性描述。UI模型220是由设计者设计的UI的可视表示。在该实施例中，用户接口模型不依赖于任何实现考虑，如硬件设备、计算平台、编程语言、应用协议、公司风格指南，等等。用户接口模型通过设计加工过程211由用户和应用需求210导出。即利用用户和应用需求来建立UI软件的可视表示。用户接口模型通过代码产生过程221a、221b、221c对每个用户接口语境231a、231b、231c被翻译成用户接口代码230a、230b、230c。因此，一个模型或可视表示可用于对不同的语境(如PC语境、PDA语境、电视语境)建立多个不同的用户接口。通过设计验证过程212针对原始需求来比较用户接口模型和由此产生的代码。需求的改变可以很快由用户接口模型的改变反映出来，而模型的改变又迅速传播给用户接口代码。如果用户接口模型在特定用户接口语境下详细包含了用户接口的所有不同方面，则该用户接口模型就该语境来说是全面的。如果用户接口模型包含了应用所要求的所有不同用户接口语境的定义，则该用户接口模型是包含的。如果用户接口模型就每个用户接口语境来说都是包含的和全面的，则该用户接口模型是全包含的。如果用户接口模型包含足够的能够产生实际运行用户接口代码的详细信息，则该用户接口模型是可执行的。为了是可执行的，用户接口模型不必是全面的也不必是包含的。在用户接口模型中缺少详细信息的地方可由代码产生过程来假设适当的缺省特性，虽然是不完全的，但仍然能够产生运行的用户接口代码。在该实施例中，建模系统提供多个用于建立UI的可视表示的基本构件块和连接器。这些构件块(例如业务功能)被选出并相互组合。缺失的信息由建模系统提供以简化建模过程。否则该系统和过程就会相当复杂并且相对手工编程不会有突出的优点。例如描绘连接两个交互器(如患者查找表视图和患者详细形状视图)的单线。该线描述交互器之间的数据绑定；即它们都是同一数据集的同步视图。任何影响它们之一的改变无需显式地声明所有可能的不同交互就会立即反映在另一个中。因此，无论何时选择了患者查找表视图中的一个新记录，它就会被立即显示在患者详细形状视图中；无论何时当形状视图中的一个字段被编辑，表视图中的对应单元就会被新值刷新；无论何时当新的行被添加到表视图中时，形状视图就会显示对应的新的和空的形状；当进行了导致新的患者数据集的新查询时，两个视图都相应地更新。由于这些在两个视图间协作的特性方面已隐含在与它们之间的绑定相关的协议中，因此无需显式地声明，由此使模型大大简化。因此本实施例所采取的措施可能需要最初建立一个初步用户接口模型，对其进行测试并渐进地改进直至得到UI模型的精确定义。所产生的完整UI模型优选为全包含的用户接口模型。这使得快捷和迭代的以用户为中心的设计过程最终得到最好满足用户需求的合格的用户接口。当然较简单的UI模型也许在第一次尝试中就可以得到而无需迭代过程。图3A示出根据本发明实施例的用户接口建模系统(UIMS)300。首先建立用户接口模型的用户友好的可视表示310。该用户接口模型的机器可读规范表达由该可视表示导出。该规范表达被翻译成用户接口代码330、即可执行代码。在本实施例中，单个UI模型或可视表示310被转换为单个规范表达，其在过后可能被翻译成用于多个不同语境或平台的UI代码。还可以如图3B所示，从多个可视表示352和354或从外部继承源356导出单个规范表达350。该单个规范表达然后被用于产生多个用户接口代码358、360、362和其它输入364(如格式化的文档)。在某些情况下，可在产生多个用户接口代码之前将可视表示转换为多个规范表达。按照简单而直观的图形形式的可视表示提供了用于设计用户接口模型的各个方面的和与其它开发团队交流模型设计的用户友好的装置。可视表示是描述UI要实施的功能的图示。详细的描述表格可以附加在可视图示上以提供用户接口部件结构和特性方面的精确定义。在本实施例中，采用UIMS编辑器311(也称为“故事书工具”或“故事板”)来建立可视表示310。该编辑器还用于编辑和改进已建立的可视表示310，使得设计人员可以由应用和以用户为中心的需求来精心制作用户接口模型，并不断验证和更新模型设计。该编辑器还可以将可视模型表示翻译成规范表达320。该规范表达提供了以机器可读方式获取用户接口模型的装置，即不象手工编写的UI代码那样使UI逻辑淹没在代码中。在一种实施方式中，规范表达以称为GUIMachine语言(GML)的适当的语言形式出现。在该实现中，GML是基于XML的语言。规范表达还可以用其它机器可读的语言形式来表达。规范表达使得可以为用户接口模型提供结构化的UIMS知识库321，其包括对纯组织的和知识的管理功能的支持。UIMS知识库可被用作代码产生工具以及在迭代的用户接口设计过程中便利模型修改的工具的来源。此外，UIMS知识库还产生可由副工具340在各种领域使用的、用户接口知识的语义丰富的来源，如文档产生、在线帮助产生、放弃/重试工具、事物处理工具、故障恢复工具、拖拽工具、设计标准(用于验证设计是否满足特定的特性)、模型仿真器(用于模拟终端用户的活动)，以及模型验证工具。一个或多个以伪码或甚至实际程序代码形式存在的UIMS工具包331提供了由用户接口模型的规范表达320产生运行代码的装置。工具包包含将用户接口模型映射到程序代码所需的、并伴随在特定用户接口语境下或语境组中正确实现模型化的用户接口的数据结构的信息和程序。不同的工具包用于根据技术平台或语境产生可执行UI模型代码的不同实例，其中，每个工具包被配制成读取可视表示的规范表达并输出用于特定语境的可执行代码。尽管希望开发如上所述的伴随工具以使建模系统自动化，但要注意的是建模系统的一个或多个元素只能手工实现。例如，通过用笔绘图来建立可视表示、通过填写描述表格来编写详细描述，甚至代码产生也可采用手工编码技术来完成。还需注意的是，不是上述所有建模系统的元素都为本发明的实施例所需要。例如一个仅包括可视表示的实施例可用于为早期设计和建立原型以及与其它开发团队交流来建立(非可执行的)用户接口模型。或另一仅包含规范表达和实现工具包的实施例可被用作继承用户接口变换工具的基础。对于本领域的技术人员来说，显然在不脱离本发明的范围的情况下还可以有其它实施方式。在该实施例中，建模系统基于作为不同模型表示的基础的模型结构的公共集。由于用户接口在很多情况下类似于电影，对模型结构采用相似的电影术语来解释。与电影相似的是，用户接口向观察者讲故事。故事的讲述通过由演员演出的定义情景序列来展现。演员在一个情景中根据规定的脚本演出并在相互间以及与环境进行交流。但与总是向所有观察者讲述相同故事的电影不同，用户接口可能向不同的用户或甚至向同一用户讲述不同的故事。因此用户接口可以被勾画为一种交互的且个性化的电影。建立在电影比喻的基础上，建模系统将用户接口模型构建为一个或多个表示用户接口可能被使用的方式的情节(scenario)的集合。一个情节是一个用例(usecase)，即用户为了完成一项或一组任务可以使用系统的方式。情节由以用户为中心的需求分析导出并取决于用户类型、用户目标以及用户接口语境。参见图4，情节430由多个交错的情景(scene)440构成，其中，每个情景表示用户可能在同一时间执行的一组紧耦合的活动。在本实施例中，一个新的情节实例基于具有预定义嵌入情景集、即基于UI模式的情节原型。因此，给定情节的选择定义随后可被选择的情景的类型。当执行一个情节时，顺序地执行情景使得在任何时刻都只有一个情景是活跃的。执行情景的顺序不是固定的并可由动态转换、包括条件和重复来控制。在另一实施例中，可从零开始创建一个新的情节，并且可将嵌套的子情景和子情节的期望组合添加到所创建的情节中。情景由并发活跃的和协作的演员450构成。演员是专用的表示活动线程的计算单元。演员具有内部状态、具有一定的专门技能(如配制成执行预定的任务或功能)，并可对事件(如处理已收到的数据)作出反应。演员与用户、与所基础应用或相互之间通过消息进行通信。演员根据由人类设计人员规定的动作脚本对消息进行处理和反应。例如，用于医学信息系统的用户接口可以包括若干情节，如A)医生从诊所计算机上查看并编辑其患者的医疗记录；B)医生从诊所计算机或从其家中的个人计算机上查看并编辑其预约时间表；C)患者在家从其个人计算机上查看其个人医疗记录；以及D)急救人员在急救车的移动设备上查看患者的医疗记录。这些情节中的每一个都是一个描述特定的用户组在一定的语境中将如何使用系统的用例。继续该例，医生查看并编辑其患者的医疗记录的情节A可以包括若干情景，如A1)用姓名查找患者；A2)浏览被选患者的医疗记录；A3)提出患者的医疗记录；A4)向被选患者的医疗记录添加新项；等等。这些情景中的每一个都可以在所述情节期间重复任意次数，但在情景之间隐含着一定的顺序。例如，医生可向患者医疗记录添加任意数量的项(A4)，但其必须首先从其所有患者的列表中查找(A1)和选择(A2)该患者。仍继续该例，医生用姓名查找患者的情景A1可由若干演员组成，如A1a)一个与用户交流的演员，用于获得姓名搜索字符串；A1b)一个与应用交流的演员，用于查询和检索与给定姓名匹配的患者的列表；以及A1c)用于将结果患者列表表示给用户的演员。在该实施例中，情景和情节都是组合的演员，即对于其它演员的容器，包括子情景/子情节。情景是空间组合。包含在该情景中的所有元素都是并发活跃或可视的。该情景定义如何在显示表面中安排子元素。情节则是时间组合。在情节中在一个时间只有一个情景是活跃的。情节定义转换流，利用它将控制从一个情景传递到另一个情景。在一种实现中，情节和情景根据特定应用或与需求从零开始创建。在另一实现中，建模系统采用模板并提供情景和情节原型。这些情景和情节原型是具有固定或已知子元素集、如子情景或演员的特殊类型的情景和情节。设计者仅需从该预定义集中选出其在特定情况下需要的特定元素并赋予它们特定的性质。这使得能够重用经常反复的模型构建，并能够进行快速模型组合。UIMS工具包或工具包扩展可用于为某个用户接口类或特定的工业提供一组这样预配置的情景/情节原型。在另一实现中，建模系统使得设计者能够使用该情景和情节原型并从零开始构建情景和情节。图3C和3D示出根据本发明的一个实施例的基于模板的建模系统。从多个情节中选出情节1。情节1具有多个子元素或情景。这些情景是情景原型或外壳程序。定义了情节1的特性。接下来，通过选择情景B并定义其特性建立所选择情节的第一情景。情景B具有多个子元素或演员。选择这些演员中的一个或多个并定义它们的特性。定义所选择的演员之间的关系。一旦建立了第一情景，就可通过选择另一情景原型(例如情景F)并重复上述步骤来建立所选择情节的第二情景。定义第一和第二情景之间的转换或关系，由此建立具有多个情景的情节。可以重复上述步骤以添加情节或可视表示所需的情景。在本实施例中，可视表示是简单的图表标记，用其可以容易地表达用户接口模型。大多数图和一些复杂的符号是包含由路径连接的节点的图。信息主要在拓扑结构中，而不是在符号的大小或位置中。用于定义可视表示的可视关系包括(i)连接(通常是到2D形状的线)；(ii)容器(带有边界的2D形状符号)；(iii)附属(一个“靠近”图中另一个符号的符号)。这些可视关系映射到图中节点的连接、即标记(notation)的解析规范形式。可视标记被绘于二维表面。一些形状是三维形状(如立方体)的二维投影，但仍被作为二维表面上的形状进行处理。有三种用于可视标记中的基本图形构件符号、框图和路径。符号是可视标记中不能再分解的原子形状。符号构成构建模型图的基本构件块。路径是端点相连的线段的序列。概念上路径是单个拓扑实体，尽管其分段可被图形地处理。分段不能脱离其路径存在。通常途径在其两端与符号连接，因此没有悬挂的线。框图是容纳由路径连接的符号的集合的有边界的区域。框图本身是可置于另一框图中的符号。因此可视表示是嵌套的框图的树，其中，根框图表示整个用户接口模型。可视标记当写到纸上时被称为静态可视标记。而当可视标记通过UIMS设计者表示时被称为动态可视标记。静态和动态可视标记在语义上是相等的。虽然动态标记并不添加任何新的信息，但其提供如缩放、扩展、导航、过滤的能力以及其它使得更易查看和处理可视标记的交互和可视技术。可视表示中的元素是可一致标识的。这使得可以在同一框图或其它框图中用来自其它元素的表达和规则来索引元素。对每个元素在拥有该元素的框图中分配唯一的名称。元素的完全合格的标识符通过将元素名连接到其框图标识符以及其所有祖先来构成。图4示出由根据本发明实施例的可视表示使用的具体符号。本领域的技术人员明白，还可以使用其它符号词汇来构建可视表示。因此，本发明不仅限于在此示出的具体符号词汇。信息集(Infoset)是根据应用合同在用户接口和应用之间传递的信息块。信息服务框图420用于定义通过应用合同可供用户接口使用的服务。由特定服务提供的信息集绘于其各自的框图内。服务可以嵌套在其它服务内。服务还可以用作通过继承来定义其它服务的原型。信息集是结构化的信息对象的集合。信息集符号表示信息集的结构。一些公用的信息集包括单元素421(恰好包含一个对象的集合)、列表422(对象的有序列表)、袋423(对象的无序列表)、簇424(对象的嵌套集合)、树425(对象的层次集合)以及图426(对象的链接集合)。信息集中的对象是对象类型的实例。对象类型表示相似对象的类并定义它们的数据字段结构。对象类型由与单元素421相同的符号绘制。对象类型可以用作通过继承来定义其它对象类型的原型。一个信息集可以包含作为任意数量的对象类型的实例的对象。允许位于信息集中的对象类型的符号被绘制在该信息集符号之内。信息集的规则性是有效包含在信息集中的对象类型的混合的度量。一个规则信息集可能只包含那些是同一对象类型的所有实例的对象。一个不规则信息集可能包含是不同对象类型的实例的对象。如果允许在一个信息集中的所有对象类型是从同一基本对象类型继承来的，则该信息集被认为是半规则的。一个信息集本身是一个对象类型并因此而可被包含在另一个信息集中，这使得可以定义任意复杂的信息集结构。可视地，这通过将被包含的信息集符号绘制在包含的信息集符号内来表示。绘制对象类型和信息集的方式导致反映信息集结构和规则性的唯一镶嵌盒形状。该形状称为信息形状(infoshape)，是信息集结构形状的抽象署名。演员通常被设计用来与特定的信息形状一起工作(例如设计用于规则列表信息集的表视图交互演员(tableviewinteractor))。与作为主动对象的演员相反，信息集是被动对象。在本实施例中，信息集总是被恰好一个演员所拥有；因此信息集符号被绘于拥有其的演员的符号内。反之，在本实施例中，一个演员也总是拥有恰好一个信息集。信息集只能由拥有其的演员直接访问。演员450表示具有特定责任的活跃的并发实体。并发意味着一个演员可以与同一环境中的其它演员并行地存在和操作。演员的实现由封装的外壳对其环境和其它演员隐藏。为了使演员与其环境通信，其封装外壳具有称为端口的开口，通过该端口信息可以流入或流出。可视地，演员端口被绘制于演员的边上。端口的方向由其符号指出在输入端口445信息流流入演员；在输出端口446信息流流出演员；而在双向端口447信息流双向流动。要交换的信息被打包成称为消息的离散单元。这些消息是信息集的实例。通常，消息是为演员提供的唯一通信装置。由于封装外壳，演员的举止只能从外部通过观察在其端口上的消息流来推断。相反，演员对其环境的感知则受限于通过其端口接收的信息。演员上的每个端口表示该演员的一个专用接口。端口的属性之一是其相关联的协议，其包括一组被允许通过该端口的有效消息类型和一组在该端口上的有效消息交换序列。消息绑定用于显式地表达和限制演员之间的有效通信关系。在同一层中的两个演员可以直接通信，如果在它们之间存在绑定。绑定是将消息从一个演员携带给另一个演员的基本通信信道的抽象。绑定可以是异步的441或者是同步的442。异步消息绑定是非阻塞的，即发送者在发送消息后仍继续其活动。在同步消息绑定的情况下，发送者被阻塞直至接收者用其自己的消息进行回答。绑定通常被绘于具有相互兼容协议的端口之间。通常，绑定不指示通信的方向，因为其可由端口的方向性推断出来。条件连接器443可用于定义根据某些动态规则路由到不同演员的条件绑定。继续连接器444可用于定义分支到框图的远程区域的绑定。该继续连接器还可以用于定义同时分支到多个演员的绑定。通过基于原型的继承来定义演员。设计者从UIMS工具包中选择适当的演员原型并通过规定性质和通过编写反应的脚本来根据需要修改其行为。以这种方式直接从演员原型定义的演员称为原子演员。原子演员本身可以用作另一个原子演员的原型。通过提供新工具包或扩展现有工具包，可以裁剪或扩充可用演员的选择以满足各种专门需求。一些经常出现的原子演员原型包括信息演员(infoactor)、即与基本应用通信以获得或修改信息集的演员；交互演员(interactor)、即与用户交互以查看或编辑信息集的演员；演示者(presenter)、即用于控制交互演员的演示的几何形状和风格的演员；变换者(transformer)、即用于使用集合运算将一个或多个信息集变换为新信息集的演员；协调员(collaborator)、即用于在多用户环境下并行演员实例之间进行调停的演员。一个演员可以在运行的用户接口中被例示任意次，所有的实例都共享相同的行为，但每个实例都维持其自身的内部状态。例如，表视图演员是经常用到的演员原型。其表示向用户展示相似对象的平直列表的一般能力，并具有一些通用功能，如滚动和选择。用于展示患者列表的演员可以基于该表视图演员通过规定患者属性和表列之间的映射来定义。该演员的在同一工作站或不同工作站上的不同实例可被用于显示患者查找查询的结果。所有实例都示出具有相同列结构的表，但每个表都显示一个不同的患者记录列表并可以分别滚动和选择。但一个任务过于复杂或过于丰富而无法通过单个演员来有效表示时，则可以使用情景440框图将其分解为并发演员的集合。每个包含于其中的演员负责全部功能的一个子集。在这些演员端口间的消息绑定定义这些演员如何协作以将其特定的功能组合成完全的任务功能。一个情景本身是一个演员。包含于一个情景中的演员又可以按照类似的方式被进一步分解为子情景。该分解过程可被执行到任意级。情景还可被用作通过继承定义其它情景的原型。端口可被绘制于情景框图的边缘以定义该情景与模型更高层的接口。情景端口可被连接到等同于代表团概念的内部组件演员。当从模型的较高层观察一个情景时，仅有其端口可见，情景的内部结构、包括其组件演员及它们的消息绑定都被隐藏了。当任务的结构或行为可以动态改变时，则可以使用情节430框图将其分解为交错情景的集合。在该情节中的每个情景都表示一个特定的任务/对话状态。在本实施例中，在任何时刻都仅有一个状态是活跃的。转换箭头431绘于情节状态之间以指示可能的状态转变，以及触发这种转变的事件。转换的方向由箭头来指示。初始和最终状态437和438分别指明情节从哪开始和结束。调用432是转换的特殊类型，其执行目标状态并在该目标状态结束时返回到源状态。这是用于取代绘制两个状态间的对向转变对的简化标记。条件连接器433可用于定义根据某些动态规则分支到不同状态的条件转变。继续连接器434可用于定义分支到框图的远程区域的转变。选项连接器435可用于定义分支到一组可选状态之一的转变。重复连接器436可用于定义重复直至满足某些动态条件的转变。一个情节本身是一个演员。包含在一个情节之中的情景又可按照类似的方式被进一步分解为子情节或子情景。该分解过程可被执行到任意级。情节还可被用作通过继承定义其它情节的原型。端口可被绘制于情节框图的边缘以定义该情节与模型更高层的接口。情节端口可利用分叉/结合连接器448连接到所包含的情景。当从模型的较高层观察一个情节时，仅有其端口可见，情节的内部结构、包括其状态以及它们的转变都被隐藏了。语境选择器451表示特定的用户接口语境或语境组。语境选择器可用一般化箭头454相关联以根据设备类或用户角色来建立层次结构。当将语境选择器用于一个元素时，其将模型对该元素的使用仅限制为使用属于该语境的用户接口。通过将语境选择器置于元素符号内来将该语境选择器用于该元素。可将不止一个语境选择器用于同一元素。多个语境选择器是OR组合的。负语境452选择器可用于将语境从元素中删除。应用到一个元素的语境选择器被所有其包含的元素继承。其它语境选择器可用于所包含的元素，但却以更受限的方式。这使得可以在高层由多个语境共享、而低层严格限制为具体语境的地方建立统一的用户接口模型，。远程语境453选择器用于指定属于用户接口远程实例的元素。通过使用远程语境可以协调多用户环境下多个用户之间的消息及转变。包(package)410框图用于为了组织的目的而将任意模型元素分成组。一个包可以包含任何元素，包括其它包。包通常为了重用目的而被用于对模型元素定义进行组织。注释461可为归档目的而被附加到任何框图元素上。括弧463符号可用于向一组框图元素添加注释。特性462符号可被附加任何框图元素上以索引相应的包含关于该元素其它描述细节的特性表。演员定义功能模块化单元。可以修改演员的内部结构或行为而不影响模型的其余部分。实现复杂功能的演员被分解为组件演员，每个组件演员负责全部功能的一个子集。该分解过程实际上是功能分解过程。演员还定义继承和重用单元。可以使用原子演员和组合演员作为其它演员的原型。由于一个演员只有一个原型，这意味着演员使用单继承。在本实施例中模型不支持多继承。优选地，不是使用多继承，而是将其它演员结合进该演员并将它们的接口部分作为该演员自身的接口。演员还定义处理单元。模型中的每个演员是一个具有其自身的执行线程的活跃对象。演员的状态被如此递归定义一个原子演员的状态是其自身的状态；一个组合的情景演员的状态是所有作为该情景成员的演员(原子的或组合的)状态的联合；一个组合的情节演员的状态是当前活跃的情景的状态。由于状态是由演员在内部维护的，因此与该演员的交互可以根据需要而挂起或恢复。因此可以在服务器或任何客户机工作站的任何处理器上执行演员。执行着的演员实例甚至可被从创建其的处理器移动到不同的处理器上。执行演员实例的位置是一种实现上的考虑并且不影响建模系统。因此，同一用户接口模型可被用于产生完全在客户机工作站上执行的用户接口、完全在应用服务器上执行的等同的用户接口、以及两者的任意组合。在以这种方式查看时，用户接口模型最终是一个在空间(通过情景)上或时间(通过情节)上递归组成的原子演员的集合。用户接口的状态、即最高层情节的状态由活跃演员的当前配置以及它们各自的状态构成。通过在并发和协作的演员之间分布交互状态，建模系统创建了高度并行和模块化的组织。这是用多个模块、访问通道、对话线程、以及用户类型处理复杂用户接口，以及抵挡由用户接口设计的迭代特性造成的不断改变的关键使能因素。图5示出企业门户502，其中，根据本发明的实施例提供了建模系统。门户502将客户机504耦合到多个信息源506。客户机504与前端系统相关联，信息源506与后端系统相关联。后端系统包括将客户机与信息源相连接的应用层。客户机504可以是通过因特网、企业内部网、广域网、局域网等连接到门户502的个人计算机(PC)。门户被配置成为用户提供访问各种应用和信息的公共入口。在本实施例中，门户502集成了多种不同的技术，使得用户可以访问企业内和企业外的应用和信息。信息源506包括外部应用514(相对于给定企业来说)、内部应用516(相对于给定企业来说)、外部文档源518、内部文档源520以及Web(万维网)522。门户包括统一服务器508、门户服务器510、以及知识管理512。统一服务器配置为用于提供能够从各种源动态集成应用和信息的业务统一层。业务统一层使得能够建立统一的对象模型，从而使门户用户可以动态集成应用和信息。在组件系统中提供的逻辑业务对象被用于建立存储在知识库中的统一对象模型。对象通过链接来相互映射，从而使用户可以动态地将内容从一个信息源传递到另一个信息源。逻辑业务对象被用于在机构的运营、管理、计划或账务管理中表示事物、概念、过程或事件。每个业务对象规定属性、关系、以及动作/事件。例如，业务对象可用于表示系统的订单、卖主以及用户。门户服务器包括与客户机通信的Web服务器532和包括多个表示组件、如iView的门户内容目录(PCD)534。在一种实施方式中，PCD包括UIMS知识库321和UIMS工具包331。PCD是基于文件的目录，其还包括与门户交互的角色和系统。在一个实施例中，PCD在Java2EnterpriseEditionTM兼容应用服务器上运行。知识管理(KM)510是一组用于管理知识和协作的服务。KM510提供用于在一种业务管理平台下协调各种业务工具而不管数据在何物理位置的平台。在一种实施例中，KM包括管理文档内容以及相应的文档属性的知识库固件、将内容组织为文件夹或树结构的分类引擎，以及用于管理信息的其它组件。图6示出用于根据本发明的实施例创建用户接口模型的过程600。在步骤601，根据各种方式和现有方法收集对用户接口的特定语境(如语境C)的用户需求。基于这些用户需求对用户接口语境C定义用户任务模型、即确定需采取哪些步骤来满足这些需求(步骤602)。用户任务模型是任务(功能)的层次分解，这些任务是在用户接口语境中支持用户活动所需的。每个任务可以是原子任务或由并行或交错的子任务构成的组合任务。可为多个语境定义用户任务。定义信息模型(步骤603)，例如选择和调用应用/业务函数。该步骤包括以任何现有的方法分析该应用的业务层、为步骤602中的用户任务标识相关的信息服务和对象、以及定义它们的结构和合同。基于此利用服务框图和信息集符号定义信息模型。根据步骤602的用户任务，采用嵌套的情节和情景框图定义模型结构(步骤604)，如选择情节、情景和演员。包含交错的子任务的任务被映射到情节框图中，而包含并行活跃子任务的任务被映射到情景框图。原子任务被映射到适当的原子演员。在步骤504中标识的情节、情景和演员的行为方面在此被更详细地定义(步骤605)，例如定义所选择的情节、情景和演员间的关系。对于每个情节定义相关的转换流。对每个情景定义确切的消息绑定和端口。需要的话，还定义演员特性、表达式和动态规则。每个在步骤604标识的情节、情景和演员被映射到适当的显示表面并定义其布局(步骤606)，例如定义收集的信息的布局视图。需要时定制风格和图。通过仿真或产生用户接口并与在步骤601中收集的用户需求进行比较来验证模型。可以根据需要多次重复步骤602至606以改进模型，直至实现用户需求。对每个需由用户接口支持的语境重复步骤601至607。上述建模系统可以用于建立可在简单和复杂环境中的广泛不同语境中使用的用户接口。本发明成功地在包含多层专用于特殊功能的服务器和计算机的企业门户环境中实现了该建模系统。该在企业门户语境中实现的建模系统称为GUIMachine(“GM”)建模系统。GM建模系统是可以通过拖拽可视对象并建立它们之间的关系而快速并容易地开发UI的可视工具。该工具能够可操作地连接到业务层或在其上工作，而不是直接用数据库工作。因此，该工具被配置用于读取和理解元数据(或数据库结构)并在业务层或应用层处理数据以保护业务逻辑。例如，该工具可被用来跟踪作为业务层的一部分但非数据库的一部分的销售订单的生命周期。业务层确定这样的信息并将其以适当的格式存储在选择的表中。因此，该可视工具连接到业务层以合并业务功能模块或组件，例如远程函数调用(RFC)和业务应用程序接口(BAPI)。业务功能组件是位于业务层并包含业务逻辑的可重用应用组件。该可视工具是能够根据用户接口模式的预配置的选择快速而有效地组合用户接口模型的、基于模式的工具。下述步骤是公知的称为“主详情”模式的用户接口模式的例子(1)获取ABC公司所有客户的数据，(2)按一定的准则可选地对客户数据进行过滤和分类，(3)以表格视图显示结果、即主视图，(4)当在主视图中选择了一个特定的客户时，获取该客户的订单数据，以及(5)在副表视图中显示该订单、即详细视图。同样的主详情模式可在用户接口的许多例子中被识别，它们都共享同样的具有一个或多个链接详细视图的主视图的概念，但各自可能会在主视图和详细视图中替换不同的数据集。该可视工具可以与或不与任何给定的模型相关联。一个模型包括一个或多个为特定业务解决方案裁剪的(软件)包。该包包括一个或多个页，每页又包含多个集成的视图(iView)。iView是门户表示组件或门户片断，用于从应用、存储的文档、或因特网检索数据并在客户机上作为门户内容显示所检索的数据。图7A示出了根据本发明实施例的GM建模系统的规范表达的建模层。规范表达包括三个主要层信息层701、交互模型层703、以及表示模型层705。信息模型层701定义可被检索或发送到底层后端应用的信息对象和可被调用的函数。其实际上定义用户接口和在底层应用之间的合同或协议。信息模型从应用描述中导出。交互模型层703定义预期使用该用户接口的用户的类型、它们要使用该用户接口完成的任务，和完成各个任务所需的具体用户接口对话。交互层由信息模型层以及由用户需求分析导出。表示模型层705定义用户接口将以何种外观出现，包括拓扑结构(元素如何相互嵌套)、几何形状(元素如何被安排在显示表面上)、风格(采用何种颜色、字体、图形等)。表示模型层从交互层导出，但还取决于人体工程学需求以及其它需求，如品牌和公司风格指南。所有上述模型层都还依赖于用户接口语境模型，其是共同定义用户接口语境的硬件、软件和物理参数的集合。用户接口语境模型由于如屏幕尺寸、输入/输出设备的存在等限制因素而可能对其它模型层产生约束。在一个实施例中，为了简化表示并使规范表达更易管理，未显式地表达出规则模型层。更确切地说，每个演员可被认为具有三个方面信息、交互和表示方面。演员的这三个方面集于演员一身中，但演员们本身则是松耦合的。这导致建模层的分布组织，如下面将详细解释的，这种分布组织可以用于并行体系结构并允许快速和渐进地修改模型。图7B示出根据本发明实施例的用于采用GM建模系统而无需手工编码来建立用户接口的过程700。GM建模系统建立组合应用逻辑以访问与企业门户相关联的各种应用和信息源的用户接口。以下利用图8-16中的UI建模系统的示例屏幕显示来解释过程700。当设计者从门户客户机504登录到门户服务器510以访问UI建模系统时，过程700开始(步骤702)。在一个实施例中，该建模系统由一个专用服务器提供，即GUIMachine服务器(“GM服务器”)。由此打开了建模系统或GM故事板。当设计者登录到该GM故事板时出现屏幕802(图8)。屏幕802包括工作空间804和任务板808。该工作空间是设计和显示UI的可视表示的地方。该工作空间包括设计标记(tab)、布局标记、预览标记、和源标记。选择设计标记来在工作空间上设计UI。布局标记用于定制iView的布局。预览标记预览和验证iView逻辑。源标记用于查看由GM故事板自动产生的GUIMachine语言(GML)代码。GML代码对应于规范表达320。任务板806显示与工作空间中执行的任务相关的工具。任务板具有多个用于显示不同工具集的状态。这些状态包括“开始”、“模型浏览器”、“逻辑元素”、“布局风格”、“字段定义”、“元素特性”、“数据源”、“代码编译器”以及“模型调试器”。当在工作空间中没有模型被打开时出现开始状态，其允许设计者打开一现有模型或建立一个空模型。模型浏览器状态显示表示该模型的层次树。该树可被用于修改模型层次结构和在模型中航行。逻辑元素状态用于定义模型的构建块。在逻辑元素任务板中显示表示模型元素的图标。布局风格状态用于定制iView的布局。在定义iView中的信息流时使用字段定义状态。元素特性状态用于定义各种模型元素的特性。数据源状态用于向模型输入业务函数。代码编译器状态用于编译和部署门户业务软件包。模型调试器状态用于验证模型逻辑。回到过程700，打开一个新的或现有的GM模型以建立或修改UI的可视表示(步骤704)。屏幕902示出步骤704(图9)。输入GM模型的名称。该GM模型包括一个或多个页以及一个或多个iView。iView是执行特定任务的门户表示组件，例如从应用和/或数据库检索特定的数据并以指定的方式将数据显示到客户机。iView可用于引用执行所要求的任务的组件以及显示给用户的信息。因此术语iView是从“集成的视图(integratedview)”导出的。页是包含一个或多个iView的容器。iView对应于演员450并包括原子演员(例如业务函数)。页是情节430的特殊类型。一旦打开GM模型，就可用任务板806(步骤706)向GM模型添加高层元素。GM模型定义元素的层次结构。该层次结构可以包含任何下述高层元素页、iView以及模块。GM模型中的页和iView最终被编译成门户页和门户表示组件。模块用于以类似于在文件管理系统中用文件夹组织文件的方式来在模型中组织页和iView。在一个实施例中，模块对应于包410。定义添加到GM模型中的高层模型元素的特性(步骤708)。定义页的名称和行为。页的行为包括一个门户用户是否可以在运行时从该页中删除iView或在运行时在该页上重新安排iView。定义iView的名称和行为。iView行为定义其如何被加载并嵌入到客户机的门户页中。此后，通过创建数据源层、构建UI逻辑以及定制布局来建立在步骤708定义的iView(步骤710)。数据源层将数据源定义添加到定义底层应用元数据的模型中。例如，由iView用来显示客户列表的远程函数调用(RFC)和业务应用程序接口(BAPI)。这些RFC和BAPI是原子演员。如在此使用的，数据源层组件在此称为数据源对象。UI逻辑定义UI组件(例如格式视图、列表视图、网格视图)及其之间的连接。UI逻辑还定义UI组件之间至数据源对象以及如过滤器、分类函数、集合函数的数据操作符的连接。布局定义iView的所有可视方面。图7D示出iView750的例子，其包括数据源层752、UI逻辑754和UI布局756。在步骤712，如果设计者希望建立另一个iView，则重复步骤706-710。图7B示出包含第一iView762、第二iView764、事件766和布局768的页760。事件766引用企业门户通信消息(EPCM)机制以在同一页中的两个iView之间发送消息。在GUIMachine模型中，事件对应于一页/情节430中两个iView情景440之间的异步消息绑定441。每个iView包括数据源层、UI逻辑和UI布局。当GM模型完成时，该模型被编译成可执行代码并部署到门户上，从而其可被用于访问门户内容(步骤714)。在构建GM模型时，自动产生GML代码/模型或规范表达。对可视表示做出的任何改动也会动态反映到GML模型上。因此，正在创建的框图或可视表示是“活框图”。图14示出规范表达的例子，如通过选择源标记可看到的。GML代码被编译成由门户支持的语言，如图15所示。GM编译器还就错误对模型进行检查并将编译后的内容直接部署到门户。通过使用适当的编译器可在任意目标平台上由GML模型产生可执行代码。同一模型可在本实施例的一个实现中同时被编译到不同的平台/语言。图7C更详细地示出根据本发明实施例的用于构建iView的步骤710。iView构建步骤710包括多个子步骤722-728。在子步骤722，向iView添加数据源。GUIMachine(GM)使客户机可以连接到在门户系统景色(landscape)中通过门户连接性框架定义的应用。由该连接可将期望的RFC和BAPI输入到iView中。输入的RFC和BAPI被称为数据源对象。这些数据源对象对应于演员450。通过使用搜索模块或浏览业务对象知识库来选择所期望的RFC和BAPI。通过在工作空间804拖拽所选择的RFC和BAPI来将它们输入到iView中。图10A示出将函数模块BAPIGETLIST和BAPIGETDETAIL从数据源任务条输入到工作空间。当这些数据源对象被插入工作空间时，它们的唯一名称被添加到iView的规范表达中。该数据源对象的唯一名称对应于它们的地址。这些名称被用于随后从门户服务器调用这些业务函数。图10B示出响应于子步骤722而自动产生的GML代码。在附录A中提供了该GML代码的全文。然后定义UI逻辑(步骤724)。通常，UI逻辑定义在运行时对用户展示哪些UI组件(例如iView是以网格视图还是以列表视图显示数据，或显示让用户输入用于搜索特定数据集的搜索参数的输入表格)以及用户可以如何与组件进行交互(例如数据显示是否是静态的，或用户是否可以通过开始搜索特定的数据子集或通过钻进显示的记录以获得更详细的信息来操纵显示在屏幕上的数据)。UI逻辑还定义控制如何从门户应用中检索信息以及数据是否要在显示在客户机上之前例如利用过滤器或分类操作符被操纵的基础数据查询。为了定义UI逻辑，将UI组件对象和操作符添加到模型中。规定在所有iView元素、包括UI组件、基础数据源对象(如SAP函数)以及操作符之间的信息流。图11A示出屏幕1102，UI组件在其上被添加到iView中。屏幕1102包括搜索表格1104、BAPI_GETLIST1106、银行列表1108、BAPI_GETDETAIL1110、银行地址表1112、以及银行详情表1114。搜索表格1104是一个交互演员，其被添加以调用BAPI_GETLIST函数。查询结果被显示在银行列表网格交互演员1108中。当用户选择了银行列表网格1108中的任何行时，BAPI_GETDETAIL1110将由对应的银行码(bankkey)调用。BAPI_GETDETAIL1110的结果将被显示在银行地址和银行详情表格1112和1114中。上述的每一个都是一个配置用于执行或调用特定任务的演员。当它们被插入工作空间时，它们的唯一名称被按照GML代码形式添加到规范表达中，从而它们可以随后在运行时被门户服务器上的代码索引。它们之间的关系由连接1122-1130来定义。连接1122将搜索表格1104的输出端连接到BAPI_GETLIST1106的输入端。连接1124将BAPI_GETLIST的输出端连接到银行列表1108的输入端。连接1126将银行列表1108的输出端连接到BAPI_GETDETAIL1110的输入端。连接1128将BAPI_GETDETAIL的第一输出端连接到银行地址表格1112的输入端。连接1130将BAPI_GETDETAIL的第二输出端连接到银行详情表格1114的输入端。图11B示出屏幕1102的规范表达。与图11B相关的GML代码在附录B中给出。这些连接可以用于数据映射、数据流、或数据绑定。数据映射定义从UI组件或数据源对象到数据源对象的信息流，如连接1122。在这种情况下信息是数据源对象所基于的业务函数所要求的输入。如果iView中一个元素的输出被用作iView中另一个元素的输入，则执行数据映射。数据流定义从数据源对象到UI组件的信息流，如连接1124和1128。由数据源对象所基于的业务函数返回的数据被显示在UI组件中。当数据源对象输出被引向UI组件用于显示时，出现数据流。例如可以定义从一个数据源对象到多个UI组件的数据流。每个输出端可以连接到一个或多个UI组件。UI组件包括表格视图、列表视图、网格视图以及HTML视图。数据绑定定义从一个UI组件到另一个UI组件的信息流。当一个UI组件的输出端连接到另一个UI组件的输入端时，出现数据绑定。在这种情况下，所基于的数据集是相同的。因此对显示在一个UI组件中的数据的改变会影响到另一个UI组件。例如，如果你的iView包括输出雇员列表以及关于他们的详情的函数，你可能会以网格视图显示雇员姓名的列表，它使得能够选择一个记录，然后将该网格视图连接到显示关于(由门户用户)从该网格中选出的雇员的详情的表格视图。可将一个或多个操作符插入UI逻辑以在将返回的数据在UI组件中显示之前处理该数据。例如，可在显示之前对数据进行过滤或分类。操作符连接到数据源对象的输入和输出端。这些操作符包括过滤(Filter)、分类(排序)(Sort)、求和(Sigma)、至顶(Top)、至底(Bottom)、分离(Distinct)。这些数据操作符被显示在数据操作符部分1140。在子步骤726，根据用户偏好或需求定制iView布局。在建立iView逻辑时提供了缺省的iView布局。可以修改该缺省的布局，从而可以按特殊需要裁剪信息显示。在子步骤726之后完成iView。图12示出用于定制iView布局的屏幕1202。在此之后，可以对所建立的iView进行测试(步骤728)。该测试通过在工作空间上选择预览标记来执行。图13示出对所建立的iView的结果进行预览的屏幕1302。图14示出所建立的iView的GML模型或规范表达。图15示出由图14的GML模型编译出的可执行代码。图16示出利用图15的可执行代码在客户机上显示的门户内容。图17示出根据本发明的实施例采用GM故事板建立的GM模型的层次组织。模型1包括用于雇员数据的第一模块，以及用于客户数据的第二模块。每个模块包括一个或多个页。每页包括一个或多个iView。每个iView包括一个或多个业务函数和UI逻辑。例如，用于雇员详细信息的iView2包括输入表格、输出表格、个人数据网格、雇员获取数据、雇员获取列表、雇员修改口令。以上所述使得本领域技术人员能够在特定应用的语境及其需求中实现和使用本发明。对优选实施方式的各种修改对本领域的技术人员是易见的，并且在此定义的一般原则可以应用到其它实施例中。因此，在此示出和描述的特定实施例不是用于限制本发明，而是与在此公开的原理和发明特征保持最大程度的一致。附录A图10A的规范表达附录B图11A的规范表达权利要求1.一种用于产生用户接口的方法，该用户接口被配置成用于客户机-服务器环境，该方法包括提供编辑器，用于设计用户接口的可视表示，该编辑器提供要在客户机系统的显示设备上显示的工作空间和任务板，该工作空间用于在其上进行可视表示设计，该任务板提供多个在设计可视表示中使用的元素，其中一个或多个这样的元素与远离客户机系统的服务器系统相关联；从任务板选择第一演员，该第一演员是所述元素之一、并包括访问服务器系统中提供的应用层所需的应用逻辑的数据源对象；将该第一演员插入工作空间；将从任务板选出的第二演员插入工作空间；图表地定义该第一演员和第二演员之间的关系；以及从该第一演员和第二演员以及它们之间的关系产生可执行的代码。2.根据权利要求1所述的方法，还包括产生所述第一演员和第二演员以及它们之间关系的规范表达，其中，由该规范表达产生可执行代码。3.根据权利要求1或2所述的方法，其中，所产生的可执行代码与第一平台兼容，其中，所述规范表达用于为第二平台产生可执行代码。4.根据权利要求1至3中任一项所述的方法，还包括将一个操作符插入所述工作空间，该操作符被配置成用于以特殊的方式处理数据；图表地定义所述第二演员与该操作符之间的关系。5.根据权利要求1至4中任一项所述的方法，还包括在与所述编辑器的当前实例相关联的工作会话中存储所述第一演员的标识符，其中，该第一演员的标识符用于在运行时调用存储在服务器系统中的第一演员，以使该第一演员执行预定的任务。6.根据权利要求1至5中任一项所述的方法，还包括登录服务器系统以运行所述编辑器。7.根据权利要求6所述的方法，还包括将所产生的可执行代码存储到服务器系统的知识库中。8.根据权利要求6或7所述的方法，其中，所述服务器系统包括一个企业门户，该企业门户包括一个或多个专用于应用层的服务器和一个或多个专用于客户机系统的万维网服务器。9.一种利用建模系统产生用户接口的方法，该方法包括提供编辑器，用于设计从服务器系统到客户机系统的用户接口的可视表示，该编辑器提供要在客户机系统的显示设备上显示的工作空间和任务板，该工作空间用于在其上进行可视表示设计，该任务板提供多个在设计可视表示中使用的元素，其中一个或多个这样的元素与远离客户机系统的服务器系统相关联；显示由用户在工作空间上选择的情节，该情节与用户对用户接口的需求相一致，该情节包含多个交错的情景；根据从用户接收的输入定义多个情景中的每一个情景，每个情景包含并发活跃和协作的演员，该演员是表示行为线程的专用计算单元，其中每个情景通过图表地定义与该情景相关联的演员之间的关系而被定义；产生由该情节和情景表示的模型的规范表达；从该规范表达产生可执行代码。10.一种用于在分布式计算机系统中产生用户接口的方法，该方法包括将由第一用户选择的第一业务功能组件显示到前端系统的第一显示区域上，该第一业务功能组件与访问服务器系统中提供的第一业务应用的第一应用逻辑相关联；将由第一用户选择的第二业务功能组件显示在客户机系统的第一显示区域上，该第二业务功能组件与访问服务器系统中提供的第二业务应用的第二应用逻辑相关联；形成所述第一和第二业务功能组件之间的关系，其中，根据显示步骤和形成步骤建立用户接口的可视表示。11.根据权利要求10所述的方法，还包括产生所述可视表示的规范表达；以及从该规范表达产生可执行的用户接口代码，该用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据。12.根据权利要求11所述的方法，还包括将所述用户接口代码存储到服务器系统的知识库中，其中，所述第一和第二业务应用是不同的应用。13.根据权利要求11或12所述的方法，其中，所述可视表示包括规定表示格式的第三业务功能组件，该方法还包括将所述用户接口代码存储到与服务器系统相关联的知识库中；以及接收第二用户访问该用户接口代码的请求，其中，响应于该请求执行该用户接口代码，该代码用于访问服务器系统中提供的第一和第二应用来检索该第二用户期望的数据，其中，根据由该第三业务功能组件规定的表示格式将为该第二用户检索的数据显示在客户机系统的第二显示区域，所述第一和第二显示区域与不同的客户机系统相关联。14.根据权利要求10至13中任一项所述的方法，还包括与所述显示第一业务功能组件的步骤一起，将所述第一业务功能组件的第一标识符存储在客户机系统中；以及与所述显示第二业务功能组件的步骤一起，将所述第二业务功能组件的第二标识符存储在客户机系统中，其中，所述第一和第二标识符被随后在运行时分别用于访问所述第一和第二应用逻辑。15.根据权利要求14所述的方法，还包括产生所述可视表示的规范表达；以及由该规范表达产生第一可执行用户接口代码，该第一用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据，其中，将所述第一和第二标识符插入该规范表达中。16.根据权利要求15所述的方法，其中，所述规范表达基于一种基于XML的语言，其中，所述第一和第二应用可以是相同的或不同的应用。17.根据权利要求15或16所述的方法，还包括由所述规范表达产生第二可执行用户接口代码，该第二用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据，其中，所述第一代码与第一平台兼容，而所述第二代码与不同于该第一平台的第二平台兼容。18.根据权利要求10至17中任一项所述的方法，还包括将一操作符与所述第二业务功能组件相关联；以及将该第二业务功能组件的输出端连接到该操作符的输入端。19.根据权利要求18所述的方法，还包括产生所述可视表示的规范表达；以及由该规范表达产生可执行的用户接口代码，该第一用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据，其中，对所产生的代码不需验证。20.根据权利要求19所述的方法，其中，对所产生的代码不需进行性能调节。21.根据权利要求19或20所述的方法，其中，所述操作符以这样的方式处理从所述第二业务功能组件接收的数据，即使数据与和该第二业务功能组件相关联的第二应用逻辑保持一致。22.根据权利要求10至21中任一项所述的方法，其中，所述第一和第二业务功能组件是可重用的应用组件。23.根据权利要求22所述的方法，其中，所述可重用的应用组件包括业务应用程序接口(BAPI)和远程函数调用(RFC)。24.一种分布式计算机系统，包括用于将由第一用户选择的第一业务功能组件显示在客户机系统的第一显示区域上的装置，该第一业务功能组件与访问服务器系统中提供的第一业务应用的第一应用逻辑相关联；用于将由第一用户选择的第二业务功能组件显示在客户机系统的第一显示区域上的装置，该第二业务功能组件与访问服务器系统中提供的第二业务应用的第二应用逻辑相关联；以及用于形成所述第一和第二业务功能组件之间关系的装置，其中，根据显示步骤和形成步骤建立用户接口的可视表示。25.根据权利要求24所述的系统，还包括用于产生所述可视表示的规范表达的装置；以及用于由该规范表达产生可执行的用户接口代码的装置，该用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据。26.根据权利要求25所述的系统，还包括用于将所述用户接口代码存储到服务器系统的知识库中的装置。27.根据权利要求24至26中任一项所述的系统，其中，所述可视表示包括规定表示格式的第三业务功能组件，该系统还包括用于将所述用户接口代码存储到与服务器系统相关联的知识库中的装置；以及用于接收第二用户访问该用户接口代码的请求的装置，其中，响应于该请求执行该用户接口代码，该代码用于访问服务器系统中提供的第一和第二应用以检索该第二用户所期望的数据，其中，根据由该第三业务功能组件规定的表示格式将为该第二用户检索的数据显示在客户机系统的第二显示区域，所述第一和第二显示区域与不同的客户机系统相关联。28.一种包括计算机程序的计算机可读介质，该计算机程序包括用于将由第一用户选择的第一业务功能组件显示在客户机系统的第一显示区域上的代码，该第一业务功能组件与访问由服务器系统提供的第一业务应用的第一应用逻辑相关联；用于将由第一用户选择的第二业务功能组件显示在客户机系统的第一显示区域上的代码，该第二业务功能组件与访问由服务器系统提供的第二业务应用的第二应用逻辑相关联；以及用于形成所述第一和第二业务功能组件之间的关系的代码，其中，根据显示步骤和形成步骤建立用户接口的可视表示。29.根据权利要求28所述的计算机可读介质，还包括用于产生所述可视表示的规范表达的代码；以及用于由该规范表达产生可执行用户接口代码的代码，该用户接口代码是可操作的，以访问服务器系统中提供的第一和第二应用来检索所期望的数据。30.一种计算机系统，包括在与客户机系统耦合的服务器系统上提供的应用；以及计算机可读介质，其包括用于将由第一用户选择的第一业务功能组件显示在客户机系统的第一显示区域上的代码，该第一业务功能组件与访问由服务器系统提供的第一业务应用的第一应用逻辑相关联；用于将由第一用户选择的第二业务功能组件显示在客户机系统的第一显示区域上的代码，该第二业务功能组件与访问由服务器系统提供的第二业务应用的第二应用逻辑相关联；以及用于形成所述第一和第二业务功能组件之间的关系的代码，其中，根据显示步骤和形成步骤建立用户接口的可视表示。全文摘要本发明涉及一种对用户接口的通用描述的建模系统。该系统提供用于以独立于任何实现环境的方式定义用户接口、包括高度复杂和动态的用户接口的装置。该建模系统来源于用户接口的用户友好的可视表示，通过对用户接口部件的结构和特性方面渐进的详细描述，直至在其所有使用的语境上得到用户接口的严格定义。利用在模型中包含的信息可以生成自动产生完全可工作的用户接口代码的工具。文档编号G06F9/40GK1711522SQ200380103324公开日2005年12月21日申请日期2003年11月13日优先权日2002年11月14日发明者尤瓦尔·吉尔博申请人:Sap股份公司