电子商务应用程序中智能辅助脚本细分的一个示例外文翻译资料

英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料

应用模型 - 视图控制器（MVC）在信息系统的设计和开发中的应用

电子商务应用程序中智能辅助脚本细分的一个示例

关键词：信息系统，软件设计模式，模型 - 视图 - 控制器MVC，脚本细分，电影制作

摘要：信息系统为电子商务各个领域的专业人士提供支持。在本文中，我们专注于我们在设计和开发用于电影制作过程的信息系统方面的经验。在这一领域工作的专业人员既不是计算机专家，也不愿意花太多时间在信息系统上。因此，为了提供有用，可用和令人愉快的应用，该系统必须非常贴合这些专业人员的要求。电影制作开始时最重要的任务之一是将电影剧本分解为其元素和片段，并根据生成的细分数据创建生产成本的可靠估计。生产软件应用程序提供支持此任务的接口。但是，喝多软件都有多种可用性缺陷。因此，许多电影制片人仍然使用脚本打印输出和文本标记来突出显示脚本元素，并将数据手动传输到他们的电影管理软件中。本文提出了一种新颖的方法，使用一种将文本分解为相关元素的新方法，实现不显眼且有效的脚本分解。我们演示了如何使用模型 - 视图 - 控制器（MVC）作为软件开发可信度和用户满意度方面的底层软件设计范例，该接口的实现如何受益。

1.引言

制作电影背后的过程，无论是纪录片，动作片还是动画电影，通常分为开发，预制作，制作（或主要摄影）和后期制作四个阶段。类似于应用项目管理的其他领域，电影制作管理（FPM）过程的第一阶段不仅定义和影响整个制作过程中涉及的所有努力和结果，而且基本上决定项目最终是否会被绿化（克利夫，2005）。制作人在这些第一个定义阶段的主要责任是制定项目（根据查找剧本脚本，获取许可证并可能接收重要人员的承诺）以及获得项目实际实现的资金。对于后一项任务，生产者创建可靠的成本估算至关重要。与实际预算可用的后期阶段相反（Singleton，1996），这些第一次成本估算需要基于脚本中定义元素的成本，通过进行脚本分解来识别和量化（Singleton，1991）。本文将首先介绍主要电影制作管理软件套件的脚本故分解接口观察结果，并激发对不显眼且高效的脚本分解界面的需求。接下来，将讨论模型 - 视图 - 控制器（MVC）模式及其与软件设计的可用性的相关性。随后将提出自动推进快捷键（AAS）标记的提议，并讨论如何采用MVC在系统设计阶段并由开发环境支持。对所提供的解决方案的学习和好处的观察将总结这项工作。

2.电影制作过程中的脚本突破

剧本分解是分析电影制作的脚本（例如电影剧本），识别其定义的相关元素，并将它们分组到类别中的行为（Cleveacute;，2005）。例如，标识脚本中的所有说话角色并分配“Actors”类别。由此产生的细分信息用于创建第一次成本估算。这通常通过咨询公会和制造商提供的所谓人工费率簿和价格表来完成，并将其应用于细分的要素。例如，如果在给定场景中有五个额外的演员注意到（例如代表乘客等待火车），将查阅人工费率簿，其中列出了根据任何可能的特殊要求，例如此类无声表演的典型成本。年龄或拍摄因此，必须在正确的脚本细分数据上构建此类成本估算。此外，为每个场景创建所谓的故障表（Singleton，1991），提供所有包含的元素的表格摘要，以及关于场景发生的时间的其他生产说明，以及类似的。这些细分表对项目的时间安排（时间规划）至关重要。同样在后期阶段，所有参与场景准备和拍摄的人员都将其视为主要参考文件。从历史上看，脚本分解是通过打印脚本并使用文本标记突出显示元素来完成的，这些文本标记根据各自的类别进行颜色编码（Singleton，1991）。显而易见的解决方案是进行故障并将数据传输到故障表，调度计划等以及其容易出错的时间。近年来，电影制作软件应用程序开始采用脚本分解的思想并为其提供交互式界面。但是，由于这些应用程序提供的解决方案存在缺陷，许多生产商仍然会手动编写脚本打印输出和文本标记，以及手动传输和更新数据。五个主要电影制作和管理软件套件（CeltX，Final Draft和Final Draft Tagger，Cinergy MPPS，Movie Magic Sc​​heduling，Movie Magic Sc​​reenwriter）的脚本细分界面提供了以下结果：1。最常支持的是完全手动标记，即通过手动选择或输入文本和类别进行标记，可以使用或不使用单独的标记对话框窗口（所有套件）。 2.按上下文将所选文本标记为类别菜单或类别按钮由三个套件支持。 3.允许一个套件通过快捷键（例如Actors的“a”）为Selected文本分配类别。 4.两个套件提供了可以交互操作的故障表预览。从这些调查结果中得出两个结论。首先，大多数观察到的套件不依赖于一种特定的标记机制，而是提供了三种不同的接口。虽然这个事实本身并没有取消任何解决方案的资格，但它表明软件设计必须是灵活的，并且能够支持不同的工作流程以及独立于底层数据模型的各种涉及的界面元素。根据这一观察，必须指出有关该受抚养人的一些问题被发现。这表面例如在三个套件中使用单独的（不必要的）对话框窗口，或者使用两个或更多窗口的解决方案只允许使用一个窗口这一事实，而其他窗口则被禁用。本文后面介绍的系统架构将采用MVC，并指出如何通过软件设计有效避免这些问题。其次，所有提供的接口都要求用户仔细选择（或者更糟的是，手动输入）文本以便用类别标记元素。通过几十页长的电影剧本，这将使道德变得困难，因此提出了用户沮丧的可能原因。本工作中提出的标记接口将提供智能的文本预选，以缓解此问题。

3.方法和材料

3.1自动前进快捷键标记（AAS）

AAS的想法是基于第2节中提出的研究结果。它结合了使用智能文本预先自动推进的两个主要原则。选择启发式，以及使用快捷键分配类别。

预选启发法负责查找最有可能由用户选择的文本范围，并且顾名思义，预先选择它，有效地减轻之前陈述的问题。启发式本身应该在一个点上定义和实现，因此可用于各种工作流程。这包括例如用户标记元素后触发（程序自动选择下一个可能的元素，即自动前进）以及正常导航。

必须仔细设计和定义启发式实现的规则以适应实际用例。在脚本细分的上下文中，一个重要的规则是用户永远不会选择单个字符或单词部分进行标记。在图1中，用于选择的最小粒度是单词，即在自动前进时（例如在标记之后），启发法将在当前选择之后选择下一个单词。

为了提供更有意义的预选，启发式应该考虑标记的元素，其可以由多个单词组成，并且包括与语言无关的单词边界识别。

后者是一项非平凡的任务，因为例如标点符号的上下文相关含义（如图所示）和定义单词边界的特定语言方式。

图3.1：根据单词边界分割英语句子。顶部的原始句子，底部的提取版本。 [图像提取自（Unicode，2009）。]

此外，可以包括更复杂的特定于语言的处理以获得更好的结果，例如使用专门的停用词过滤器或单词词典。例如，假设以下文本片段作为电影脚本的一部分：

the Tin Man carries an axe

还假设用户当前选择了单词。在前进时，预选启发式将为用户选择单词Tin。现在，假设相同的文本片段，但已经标记了Tin Man，例如，作为演讲角色：

the Tin Man carries an axe

在这种情况下，预选启发式会将单词Tin Man识别为复合令牌，并为用户选择两者。接下来，假设用户再次提升：

the Tin Man carries an axe

在这种情况下，可以应用禁用词过滤来跳过单词an，因为它可以合理地安全地假设它永远不会代表英语脚本中的重要元素。

另一方面，元素的快捷键标记分类是一个更以用户为中心的设计任务。它需要一个简单而灵活的界面来管理类别并为它们分配快捷键（以及可能的格式化信息，例如颜色和下划线或突出显示样式）。

预选和快捷键标记机制都固有地要求软件实现与若干界面元素和控制器交互的工作流，以反映用户在软件及其数据模型中的动作。

3.2开发环境和工具

在运行Mac OS X 10.5或更高版本的Apple Macintosh机器上实现的以下部分中描述了原型。

设计和实现是使用Xcode开发环境完成的，该环境由Apple免费提供给任何Mac OS X所有者或Apple Developers Connection（ADC）的成员。

底层数据模型是使用Xcode的数据模型构建器构建的。所有对象持久性都由其Core Data模块管理。界面设计使用Interface Builder完成。

使用了Mac OS X-native API Cocoa的类和框架，并进行了部分子类化和扩展，以实现实际功能和用户交互。需要注意的是，Xcode和更高级别的Cocoa API框架本身采用MVC并支持并提倡将其用作设计模式。

3.3原型软件

原型开发时使用MVC作为主要的底层设计模式。 MVC是一种建筑软件设计模式和工程概念，遵循Trygve Reenskaug（Reenskaug＆Skaar，1989）（见图3.2）。

图3.2：模型视图控制器的一般概念（MVC）范例，改编自Reenskaug（Reenskaug，2008）

3.3.1模型

分析电影剧本的典型结构和特征（例如，提供）（Cleveacute;，2005））产生了图3.3所示的数据模型。

图3.3：原型的数据模型为摘自现实世界的实体。

Category和Entry共享一个公共超类，它提供持久性和用法作为接口中的大纲项，以及子类需要的属性和方法。类别管理与其元素的关系（即表示添加到此类别的文本的Entry对象）以及它们在脚本视图中的格式。另一方面，条目知道它属于哪个类别，以及其特定文本被标记的场景。

场景对象用于表示将标记范围限制为场景边界。此外，它们存储对其中所有条目的引用，以创建结构细分表等。当脚本加载到原型的细分中时，场景会被自动识别和预处理。 Document类用于存储项目信息，以便保存和加载项目，包括脚本和所有标记元素。

需要注意的是，上面数据模型中定义的实体在代码中由它们各自的模型类表示，例如：类别在Model目录的Category类中实现，并实现仅与自身相关的属性和方法。班级工作流程或接口功能由控制器实现。

3.3.2查看

如上所述，界面设计是使用Xcode的Interface Builder完成的。屏幕上显示的所有控件和界面元素由所谓的视图类实现，这些视图类负责绘制自己以创建用户界面，以及保持对它们可能包含的任何控制器的引用。例如，文本视图不仅绘制文本（即视图代码），还提供文本操作，由视图的文本控制器处理。

必要时，视图和控制器类被子类化以包括新的或覆盖现有行为。例如，文本视图类被扩展为处理快捷键并在按下基础按钮后触发预选择正确。

图3.4：细分原型的主窗口和类别管理窗口，包括上下文菜单和场景选择。

图3.4给出了原型脚本视图和类别管理界面的印象。主窗口支持AAS标记，也可以使用标记上下文菜单。

类别管理窗口具有场景选择菜单，所有类别的轮廓视图及其各自的元素，以及用于操纵和保存/加载类别配置的控件。

3.3.3控制器

细分原型中的两个控制器负责实现工作流并跨接口元素提供其他一般功能，并涉及多个数据模型类。

图3.5显示了如何组织两个控制器之间的职责，包括工作流和数据模型对象的管理。

图3.5：原型控制器的职责。

文档控制器是细分原型的核心单元，因为它实现了项目的保存和加载以及管理文档实例。它还封装了脚本的预处理（用于场景扫描）和使用AAS（包括预选），上下文菜单或标签按钮标记元素。

类别控制器为文档控制器提供了一个用于标记的接口，并处理用户启动的类别管理本身。它还具有场景选择菜单，该菜单由文档控制器的脚本预处理收集的场景数据自动生成，可用于将标记绑定到场景的范围，以及跳转到场景的开头。脚本视图。

因此，场景菜单和实际标记过程都呈现了系统架构如何毫不费力地允许工作流跨越不同控制器，接口和数据模型实体的有效示例。

4.经验教训

之前已经注意到，使用MVC为处理用户可以使用交互式界面操纵的一系列数据模型对象的软件系统提供了益处。为了给用户提供直接操作的印象，如软件可用性工程中经常讨论的那样，原型的实现方式是不需要用户交互或界面元素（例如标记对话框），这些元素本身不是相应工作流程的一部分（与观察到的几部电影制作软件套件相反）。

例如，使用快捷键标记元素首先在文本视图上调用事件，

通知它用户的击键。子类视图知道将事件转发给其委托（即处理这样的用户输入的控制器类，在这种情况下是文档控制器）以进行处理。然后控制器调用AAS算法，该算法本身使用本机库进行字边界扫描。对于每个标记元素，使用创建元素对象所需的信息调用类别控制器。

简而言之，此示例显示不需要人工接口类或模型类中包含任何工作流逻辑。文档控制器解释并处理脚本视图通知的输入，并调用类别控制器以创建适当的模型类对象。同样适用于例如用于脚本预处理步骤，其中文档控制器扫描场景并调用类别控制器以创建场景元素。

如果不使用MVC，系统设计可能需要结合人工伪控制器来处理这些工作流程。在这里给出的系统体系结构中，只有两个控制器负责使用明确定义的接口来实现复杂工作流的一组内容的视图和交互。

另一个重要方面是可重用性。例如，用于标记特定文本的算法还用于取消标记文本（即从类别中删除并取消格式化文本中的所有出现）以及用于重新格式化所有类别的出现（如果类别格式化本

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[19672]，资料为PDF文档或Word文档，PDF文档可免费转换为Word