3.10 Web应用系统的需求建模

Web开发过程必须使用敏捷方法，但需求分析常常是非常耗时的，然而，解决错误的问题甚至更花时间。在开发Web应用系统时，能否确保理解了问题的需求？如果答案是“是”，那么可以跳过需求建模，但如果是“否”，就应该实施需求建模。

Web应用需求建模的重视程度依据以下几个因素。

●Web应用的规模和复杂度的增长。

●相关利益者的人数（所做的分析能帮助识别不同来源的需求冲突）。

●Web应用团队的人数。

●Web应用团队成员的经验（所做的分析有助于达成对项目的共同理解）。

●组织成功的程度直接依赖于Web应用的成功。

与之相反的观点是，当这个项目规模更小，干系人更少，开发团队更有内聚力，应用系统并非十分重要，则采用更轻量级的分析方法是合理的。

虽然在开始设计前做问题分析是一个好主意，但并不见得所有的分析一定要在所有的设计之前进行。事实上，Web应用系统中仅有特定部分的设计会要求分析对其有影响的需求。例如SafeHome，对所有网站做符合要求的美学设计（版面布局、色彩框架等）不需要分析电子商务能力的功能需求。为了提高交付成果，软件分析师只需要分析与递增式交付相关的设计工作部分。

3.10.1 需求建模的输入

当Web应用系统已经工程化时，可以采用常规软件过程的敏捷版本。这个过程包含的沟通活动可以识别干系人和用户类别、业务环境、界定信息和可用的目标、普通的Web应用系统需求和使用场景，这些都能成为需求建模输入的信息。这些信息以自然语言的描述、概要大纲、草图及其他非正式形式表达。

分析这类信息，并使用（所适用的）正规定义的表达模式构造它，接着生成更缜密的模型作为输出。需求模型提供了揭示问题真实结构的详细指导，并提供洞察其特性的解决方案。

虽然沟通活动提供了很好的理解基础，但是需求分析通过提供额外的解释会使理解更精确。当把问题的结构描述成需求模型的部分内容时，新问题又出现了。这就是弥补理解差距的问题，实际上这些问题也帮助人们在第一时间发现这些差距。

总之，在沟通活动中收集到的信息作为需求模型的输入，即从非正规的电子邮件到包括综合使用场景和产品规格说明书中详细项目概述的任何内容。

3.10.2 需求建模的输出

需求分析提供了严格规定的机制来描述和评估Web应用系统的内容和功能、用户将遇到的交互模式，以及Web应用系统所处的环境和基础设施。

每种特性都能表示成一套模型，这套模型允许以结构化方式分析Web应用系统的需求。当特定模型很大程度上依赖于Web应用系统的性质时，会有5种主要的模型类型。

●内容模型，给出由Web应用系统提供的全部系列内容。内容包括文本、图表和图像、视频和音频数据。

●交互模型，描述了用户与Web应用系统采用了哪种交互方式。

●功能模型，定义了将用于Web应用系统内容并描述其他处理功能的操作，这些处理功能不依赖于内容却是最终用户所必需的。

●导航模型，为Web应用系统定义所有导航策略。

●配置模型，描述Web应用系统所在的环境和基础设施。

分析师可以使用描述模式开发每一种模型，这种“语言”描述模式考虑到其意图和结构，使Web工程团队的成员和相关利益者之间更容易进行沟通和评估。结果是识别出关键问题列表（例如错误、遗漏、不一致性、供增强和更改的建议、澄清观点）并照此行动。

3.10.3 Web应用系统内容建模

内容模型包含结构元素，它为Web应用系统的内容需求提供了一个重要的视图。这些结构元素包含内容对象和所有分析类，在用户与Web应用系统交互时生成并操作用户可见的实体。

内容开发可能发生在Web应用系统的实现之前、构建之中，或者投入运行以后的很长一段时间里。在每种情况下，它都通过导航链接合并到Web应用系统的总体结构中。内容对象可能是产品的文本描述、描述新闻事件的一篇文章、在体育运动事件中拍摄的一张动作照片、在一次论坛讨论中某个用户的回答、公司徽标（logo）的一种生动演示、一个演讲的简短视频，或者是一套演示幻灯片中的音频插曲。这些对象内容可能存储于分离的文件中，直接嵌入Web页中，或从数据库中动态获得。换句话说，内容对象是呈现给最终用户具有汇聚信息的所有条目。

通过检查直接或间接引用内容的场景描述，可以根据用例直接确定出内容对象。内容模型必须具备描述内容对象构件的能力。在许多实例中，用一个简单的内容对象列表，并给出每个对象的简短描述就足以定义设计和实现所必需的内容需求。但是在某些情况下，内容模型可以从更丰富的分析中获得好处，即在内容对象之间的关系和（或者）Web应用系统维护的内容层次中采用图形化表示其关系。

例如，考虑图3-22中为SafeHomeAssured.com构件建立的数据树。该树表述了常用于描述某个构件的一种信息层次。不带阴影的长方形表示简单或复合数据项（一个或多个数格值），带阴影的长方形表示内容对象。在此图中，描述说明（description）是由5个内容对象定义的。在某些情况下，随着数据树的扩展，其中的一个或多个对象将会得到进一步细化。

由多项内容对象和数据项组成的任何内容都可以生成数据树。开发数据树尽量在内容对象中定义层级关系，并提供一种审核内容的方法，以便在开始设计前发现遗漏和不一致的内容。此外，数据树可以作为内容设计的基础。

图3-22 SafeHomeAssured.com构件的数据树

3.10.4 Web应用系统的交互模型

绝大多数Web应用系统都能使最终用户与应用系统的功能、内容及行为之间进行“会话”。可以使用交互模型描述会话，这种交互模型由一种或多种元素组成：用例、顺序图、状态图；和（或）用户界面原型。

在许多实例中，一套用例足以描述在分析阶段的所有交互活动（在设计阶段引入更细化的细节）。然而当遇到复杂的交互顺序并包含多个分析类或多任务时，有时更值得采用严格的图解方式去描述它们。

用户界面的布局、介绍的内容、实现的交互机制，以及用户与Web应用系统连接上的总体审美观，都与用户的满意度和Web应用系统的整体成功密切相关。虽然创建用户界面原型是一种设计活动，但在创建分析模型期间就开始创建用户界面原型仍是一个好办法，对用户界面的物理表示评估得越早，就越有可能满足最终用户的需求。

Web应用系统的构造工具种类繁多且功能强大，可以用于创建界面原型。原型应该实现主要的导航链接，并采用同样的构造方式表现总体的屏幕布局。例如，如果为用户提供5种主要系统功能，当用户看到这些原型第一次使用Web应用系统时，这些原型就表示了这些系统功能，至于图形链接、导航菜单和显示信息等，可以由原型来回答以上类似的问题。

3.10.5 Web应用系统的功能模型

许多Web应用系统提供大量的计算和操作功能，这些功能与内容直接相关（既能使用又能生成内容）。这些功能常常以用户Web应用系统的交互活动为主要目标。正因如此，必须分析功能需求，并且当需要时也可以用于建模过程。

功能模型描述Web应用系统的两个处理元素，每个处理元素代表抽象过程的不同层次：①用户可观察到的功能是由Web应用系统传递给最终用户的；②分析类中的操作实现与类相关的行为。

用户可观察到的功能包括直接由用户启动的任何处理功能。例如一个金融Web应用系统可以执行多种财务功能（例如计算器）。这些功能实际上可能使用分析类中的操作完成，但是从最终用户的角度看，这些功能是可以看见的结果。

在抽象过程的更低层次，分析模型描述了由分析类操作执行的处理。这些操作可以操纵类的属性，并参与类之间的协作来完成所需要的行为。

不管抽象过程的层次如何，UML的活动图可用来表示处理细节。在分析阶段，仅在功能相对复杂的地方才会使用活动图。许多Web应用系统的复杂性不是出现在提供的功能中，而是与可访问信息的性质及操作的方式相关。

3.10.6 Web应用系统的配置模型

在某些情况下，配置模型只不过是服务器端和客户端的属性列表。但是，对更复杂的Web应用系统来说，多种配置的复杂性（例如，多服务器之间的负载分配、高速缓存的体系结构、远程数据库、同一网页上服务于不同对象的多个服务器）可能对分析和设计产生影响。在必须考虑复杂配置体系结构的情况下，可以使用UML部署图。

3.10.7 导航建模

导航建模考虑了每一类用户如何从一个Web应用系统元素（如内容对象）导航到另一个元素。把导航机制定义为设计的一部分。在这个阶段，分析人员应该关注总体的导航需求，应该考虑以下问题。

●某些元素比其他元素更容易得到吗（即需要更少的导航步骤）？表示的优先级别是什么？

●为了促使用户以他们自己的方向导航，应该强调某些元素吗？

●应该怎样处理导航错误？

●导航到相关元素组的优先权应该高于某个特定元素的优先权吗？

●应该通过链接方式、基于搜索的访问方式还是其他方式来实现导航？

●根据前面的导航行为，某些确定的元素应该展现给用户吗？

●应该为用户维护导航日志吗？

●在用户交互的每一点处，（与单个“返回”链接或有方向的指针相比）一个完整的导航地图或菜单都可用吗？

●导航设计应该由大多数普遍期望的用户行为来驱动，还是由已定义的Web应用系统元素可感知的重要性来驱动？

●为了促进将来使用快捷，一个用户能否“存储”他以前对Web应用系统的导航？

●应该为哪类用户设计最佳导航？

●应该如何处理Web应用系统外部的链接？应该覆盖现有的浏览器窗口吗？该导航能否作为一个新的浏览器窗口，还是作为一个单独的框架？

软件工程师和其他干系人必须决定导航的总体需求。例如，提供的“站点图”能让用户全面纵览整个Web应用系统的结构吗？“导游”将突出显示可以使用的最重要的元素（包括内容对象和功能）吗？用户能够访问内容对象或者由其元素属性所决定的功能吗（例如，用户可能想要访问一个特定建筑的所有图片）？