业务需求和设计的模型

1、第1章业务需求和设计的模型摘要：本章讨论了指导如何设计ConsolidatedRetail.（它属于企业对消费者（B2C），采用Microsoft 商务参考体系结构）的业务需求，并概括了在此应用程序设讣期间确泄的实际业务需求。本章还概要介 绍了 Microsoft解决方案框架（Microsoft Solutions Framework. MSF）三层应用程序模型和阶段式 设计过程。请注意：尽管此处提到的业务需求仅仅局限于一个可轻松安装的参考示例所具有的能力，但是本“开发 人员指南”提供的信息线索非常有用，通过这些线索，您可以对该应用程序进行升级，使其满足生产环 境的需求。简介请Web用户给电子

2、商务站点左义时，一般用户可能会回答电子商务站点就是可以用信用卡购买商品的 在线商店。尽管这个左义相当正确，却没有充分说明目前为Internet开发的各种电子商务站点的特点。 在迅猛发展的Internet商务时代，一个高效率的电子商务绝不仅仅是基于Web的商店。用户对电子商务站点的要求越来越髙，如果某个站点无法满足他们的要求，他们就将弃之而去。那么， 用户对电子商务有哪些要求呢？下表列岀了一些影响应用程序设计的主要问题。易于使用/导航性能髙匿冬购物维护用户配宜文件安全性好能够通过多种设备访问站点通过可管理性提高竞争优势粗略一看，在上述问题中，有些应由应用程序设讣人员负责解决，有些似乎应由企业决策

3、者或基本结构 专家负责解决。不过，如果您仔细思考这些问题，就会明白这些问题为什么都与应用程序的设计有关。易于使用/导航理所当然地应该易于使用和导航。毕竟，企业不希望消费者在购买自己的产品时遇到困难，而消费者也 更愿意在自己能轻松找到结帐页的站点消费。使站点易于使用的一种方法是确保在常见任务上使用大家熟悉的类似方法。这意味着在消费者完成购买 （或“结帐”）之前，可将其选购的商品存储在购物篮或筐中。这种比喻可便于不熟悉计算机的人理解 站点是如何工作的，从而开展购买活动。使站点易于导航比您最初想象的要困难得多°*eb完全是以一种非线性方式工作的，用户单击的顺序经 常无法预料。因此，您应该确

4、保无论用户目前在查看哪一页，站点向用户展示的始终是完全一致的界而, 并确保只需单击一个即可访问重要网页（如主页、购物篮所在页以及用户XX信息所在页等）。在 ConsolidatedRetail.站点上，顶部的标帜始终包含到购物篮所在页、消费者XX所在页和主页的，而 左侧的面板上始终包含搜索和目录。还有一种方法可以确保用户能在站点中找到所需内容，这就是要以逻辑方式编排产品淸单或目录。如果 将目录分成几个类别和许多可能的子类別，即可让消费者轻而易举地找到他们感兴趣的产品。此外，还 应给用户提供搜索功能，以便他们在不太淸楚某种产品的陈列位置时可以进行搜索。如果您的站点易于使用和导航，消费者将乐意使用

5、。相反，如果使用起来比较困难，消费者可能就会弃 之而去，另择站点。性能高在的设汁当中，影响英性能的因素很多。由于不同的人对性能的要求各不相同，因而，对于什么才是可 接受的性能水平也将因人而异。尽疑减少响应时间大多数人认为：提供可接受的响应时间的站点才是性能良好的站点。响应时间是指用户在请求了某个操 作之后、能够看到结果之前需要等待的时间量。在理想情况下，我们都希望站点上的操作瞬时就能得到 执行；但在实际生活中，我们需要接受这样一个事实：有限的带宽、数据库并发性和业务处理任务通常 都会导致轻微的延迟。因此，设汁电子商务站点时，应尽量减少那些对响应时间有负而影响的因素（尽 管不能完全排除它们）。电

6、子商务优化的关键在于减少执行诸如结帐之类的操作所耗费的时间，这样，消费者就不会因排队等待 而放弃自己选购的商品，您也就不会因此而失去订单。尽虽增强可扩展性性能的另一个重要方而就是"可扩展性”。这是指添加资源时站点容量增加的能力。从用户角度来看， 这意味着当大量用户同时访问站点时，站点仍能提供可接受的响应时间。许多开发人员经常会得到这样 令人沮丧的消息：当访问的用户达到一上数量（这个数虽是实际生活要求达到的数虽：）后，在开发机上 性能卓越的测试站点獄无法应付。那么，如何才能最大限度地增强站点的可扩展性呢？两种典型的方法就是“向上扩展”和“向外扩展”。向上扩展第一种方法（“向上扩展”）就

7、是通过采用更好和/或更快的CPU、更大的RAM、更快的磁盘等等来增 强服务器的处理能力。这种方法非常有效，尤其是在数据层上，该层上的一些大型数据库需要相对较强 的处理能力。不过，由于硬件成本随处理能力的加强而按指数增长，因此，服务器越接近顶端，这种方 法就愈加不合算。向外扩展“向外扩展”则从另一个方而来解决问题，即由“群集”(或服务器集合，也称为“Wib领域”)中的 多个服务器来分担处理工作量。Web领域在硬件方而的花费更为合算，而且提供了更为灵活、可扩展的 解决方案。当站点上的负载增加时，可以很轻松地将服务器添加到Web领域中。Microsoft® Windows'

8、4; 2000 Advanced Server 和 Windows 2000 Datacenter Server 以及 Windows 网 络负载平衡(Windows Network Load Balancings NLB)服务一起，将整个Web领域作为一个具有单一 IP的逻辑服务器显示在Internet上。收到请求之后，会根据负载情况将请求分发给领域中的服务器, 这些服务器可使用主干网络进行通信，也可以与数据库服务器进行通信。图1-1显示Web领域的基本 体系结构。图1-1： Web领域管理Web领域中的状态对于商务站点设讣人员而言，最重要的问题之一就是Web领域中的应用程序状态问题。状态就

9、是在两 个用户请求之间必须保留的会话数据：例如，在用户继续浏览站点期间，必须一直维护该用户购物篮中 的物品原状。即使每个用户请求可能是由Web领域中不同的服务器处理的，也须如此。许多ASP开发人员使用“会话”对象来存放状态数据。不过，通常应避免使用此方法。为了优化站点 的软件体系结构以便在服务器领域中加以实现，Web前端禁止维护内存中的用户状态。如果前端服务器 维护用户状态，将出现以下问题： 用户会话将依附于特定服务器（会话相关性），这会破坏动态地将请求分配给服务器的网络负载平 衡策略。此外，还会破坏服务器领域的可靠性，因为当原服务器发生故障（并丢失了苴内存中的会 话状态信息）时，就无法将用户

10、会话转移到其他服务器。内存资源被前端服务器耗费在存放用户会话状态的细节上，从而减少了可用于处理请求和髙速缓存 内容的内存。如果一个受欢迎的站点能够在短时间内吸引大量的用户，则状态维护方而的内存需求 可能非常大。为了部分解决内存需求问题，merce Server大量使用了高速缓存。对配置文件架构、 折扣和商业活动都将进行高速缓存。除了避免会话相关性之外，还应避免使前端操作与长时间运行的操作发生关联，以便将前端操作设 计为快速执行的操作。由于IIS是用一个缓冲池来处理请求而缓冲池包含的工作器线程数量是有 限的，因而当这些线程都已被占用且在等待长时间运行的操作完成时，传入请求等待处理的平均时 间就会

11、增加。匿爼购物（浏览）通常，用户都不愿意仅仅为了了解站点在销售哪些商品而被迫登录到站点。因此，站点应在不需要身份 验证的情况下，允许用户以匿需方式浏览商品，甚至允许他们将一部分商品放入购物篮中。维护用户配置文件当用户再次访问站点时，他们不希望重新输入上次访问时输入过的相同资料。一旦向站点提供了自己的 购物和联系信息后，用户就希望站点能够记住这些数据。为了实现此目的，许多站点会为每个已注册的用户维护英用户“配置文件”信息。在大多数情况下，用 户都需要注册，以便提供最少量的配置文件信息，如用户名和口令。然后，用户会分配到一个唯一标识 符，该标识符可用作其配置文件数据的主密钥。用户在站点上注册之后，

12、其配置文件信息就可以保存在数据库中，以便在以后需要时调用。通常，用户 可以添加一些必备信息，指泄一些细节，如电子地址、发货地址或任何其他允许用户添加的个人信息。保留用户配置文件信息相当有用，其原因如下：使用户在以后访问时不必重新输入数据。可用于分析用户在站点上的活动。可作为个性化的基础，允许您根据特泄的用户群发布标帜广告或开展打折活动。可用于商业分析，如根据特定的配置文件值跟踪购买趋势。通过可管理性提髙竞争优势尽管应用程序设讣人员不负责业务决策（如定价、广告活动等等），电子商务解决方案的设计对企业如 何应对市场趋势和竞争对手活动却有着巨大影响。业务经理开展的管理活动要受电子商务站点管理功能 的

13、制约。要取得成功，电子商务解决方案必须易于使用，还必须具备全而的管理基础结构。为电子商务站点设讣管理界而时有两个基本选择。您可以创建自己自立义的界而，也可以使用一种“现 成的”解决方案，如 Microsoft merce Server 2000 Business Desko如果构建自己的管理界而，您将能完全按照自己的愿望来设计站点的管理功能。不过，这样会给一个已 经很大的软件项目增加大量开发工作量，其工作量几乎等于或大于软件项目本身的工作量。默认情况下, merce Server Business Desk可以满足电子商务站点的大多数管理要求，如果需要还可以通过创建自 定义模块来添加其他功能。

14、本章的其余部分将说明在该项目的规划阶段确认的实际业务需求，以及在ConsolidatedRetail.应用 程序的设计中所使用的应用程序模型和设计过程。参考应用程序业务需求在设汁应用程序之前，应该明确该应用程序必须执行哪些任务。分析业务需求是应用程序开发中最重要 的步骤之一。确认业务需求的目的在于创建一个能同时满足零售商和消费者需要的解决方案。这样，需 求就转换成了业务需求文档，这种文档可作为开发整个项目的指南。本节概括了为参考体系结构应用程序ConsolidatedRetail.确泄的实际需求。请注意：此处所用的业 务需求被有意限制为一个可轻松安装的参考示例具有的能力。功能需求Consoli

15、datedRetail.旨在满足以下功能需求：易于导航站点应易于导航。应该晴晰、易于理解而且实用。用户应能够在页和屏幕之间随意移动。易于使用应用程序应易于使用。应该易于购买产品和访问"结帐”页。站点应使用易于理解的比喻，例如：将选购的物品存储在“购物篮”中，直到购物者准备结帐站点上的每一页都应显示完全一致的界而。重要页或常用页应只需单击一次即可访问。可用性测试站点应使不熟悉汁算机的人易于理解。站点访问用户能通过以下方法访问站点：在浏览器中输入URL从苴他站点或电子的访问维护用户注册/配置文件无论从站点上的任何页，用户都必须能够注册，这样，用户就不必在每次下订单时都重新输入相同的信 息

16、。用户无需注册即可浏览站点：但结帐时必须注册。另外，申请电子时事通讯、特价通知等服务时要 求注册。注册涉及：配置文件信息：用户名、付款地址、主要发货地址、和电子地址。 身份验证信息：用户身份标识（用户ID）和口令应保留在应用程序中。付款信息：用户应可以输入信用卡信息并保存该信息。应用程序应能够保存多个信用卡号。首选项：用户应能够指左是否想得到有关发货状态的电子通知（默认值为“是”），以及是否想得 到有关销售价格和特价的通知（默认值为“否”）。地址簿：用户应能够存储任意多个附加发货地址。保留用户配登文件信息相当有用，苴原因如下：使用户在以后访问时不必重新输入数据。可作为个性化的基础，允许您根据特

17、定的用户群发布标帜广告或开展打折活动。可用于商业分析，例如，根据特左的配巻文件值跟踪购买趋势。用户注册管理用户登录并经过身份验证之后，用户应能够修改、添加或删除注册信息。除“用户ID”字段之外，所 有其他字段都应是可编辑字段。登录/身份验证用户一经注册之后，如果该用户返回到站点，他或她应能够从该站点上的任何页登录。浏览用户应能够浏览目录。在主页上，应向用户显示目录淸单。在用户选择了一个目录之后，应向英显示子 类别或实际产品。匿名浏览用户应能够以匿名方式浏览目录；即：用户应能够在不必登录的情况下即可查看产品。多目录应用程序应支持多目录。多目录产品的汇总对用户应是透明的。产品和类别应用程序应允许将

18、产品与一个或多个目录关联。产品页应用程序应有一产品页，其中包括该产品项目的较大图片和/或该产品项目的详细说明。在此页，应能 够将该产品添加到购物篮中。在此页，用户应能够：将产品项目添加到购物篮中浏览下一个项目浏览上一个项目返回上一页产品搜索主页以及所有类别页和子类别页都应能进行搜索。用户应能够输入多个词。如果用户指定多个词，将根 据这些词构建使用“and”运算符的布尔查询。如果用户在主页上，搜索将默认为“搜索所有类别”。在类别和子类别页执行的搜索将默认为“在'类 别爼X囤内搜索”。用户可以选择要搜索的特左站点区域或特泄类别，以便覆盖这些默认设置。如果站点使用多目录，将对所有目录执行搜索

19、。如果站点展示了多个目录（并有一个分层产品淸单）， 则不会按此规则进行搜索。在类别/产品分层结构中，每个目录都是第一级。在这种情况下，默认为只 搜索用户当前所在的目录。用户可以覆盖默认设宜，选择搜索其他目录或整个站点。这类似于先前描述 的为'多目录”指定的行为。默认情况下，将针对关键词和标题进行搜索。产品搜索结果“搜索结果”页应显示一系列产品项目及英相应类别（或目录）。项目应按类别或目录分组。每个搜索 结果都应提供到相应产品页的超文本。向购物篮中添加项目无论从任何产品页中，用户都应能够将一个或多个项目添加到购物篮中。这些项目可来自不同的目录。 每添加一个项目，篮中的项目数也会相应地增加

20、。该数目显示在该篮子图标旁边。笛理购物篮用户应随时能够管理购物篮。用户可指左项目是"活动的”（实际购买的标记）还是“保留的”（标识 为将来可能购买）。用户查看购物篮时可进行以下选择：删除单个项目。更改每种项目的数量。保留任何项目，以备将来购买。 删除购物篮中的所有项目。保留购物篮中的所有项目，以备将来购买。 将项目移入购物篮的保留（将来购买）区和从中移出项目。检索保留的订单。保留购物篮或项目用户应能够保留选左的项目或购物篮中的所有物品，以备将来购买。只有已注册并登录的用户可以保留 其项目。如果用户尚未登录或注册，将提示他们进行此操作。用户完成此操作之后，将返回到"保留购 物

21、篮”操作。结帐无论从任何屏幕，用户都应能够结帐。结帐时，将向用户显示所有订购的项目（购物篮）。此时，用户 应能够管理购物篮。用户对购物篮中的物品进行确认后，将出现"发货”屏幕。每个项目都将与该用户 的主要发货地址关联。用户可以用地址簿中的一个地址或新地址来替换该地址。如果用户添加了一个新 地址，他或她可以选择将该新地址保存在地址簿中。用户为每个项目指派了地址（或接受了默认的地址）之后，他或她可以转至“发货”屏幕，选择每个地 址的交货方式。默认方式由站点所有者决定。用户选择交货方式后，他或她可以继续到“订单一览表” 屏幕。该屏幕应按发货地址划分。在每个地址下，将列出项目说明、项目价格以

22、及价格合计（若有）。 对该项目的价格合讣进行小计，将装运费用作为明细项目列出并进行小计，最后将列岀该地址下的税金 和总金额。对所有地址下的金额求和之后，会在该页的末尾列出总计。用户可以：接受订单修改订单取消订单继续购物如果用户选择修改订单，他或她将返回到“管理购物篮”页。如果用户选择取消订单，将淸空购物篮。 如果用户选择继续购物，他或她应该返回到主页。如果用户选择接受订单，他或她将转至“付款”页。如果用户已在"注册”页中存储了信用卡信息，则 显示该信息。用戸可选择使用保存的信用卡，也可选择忽略保存的信息，提供新的信用卡信息。如果用 户添加新的信用卡信息，他或她应可以选择将新信息添加到

23、保存的注册信息中。用户选择或输入了信用卡信息之后，他或她可以：取消订单修改订单继续购物提交订单如果用户提交了订单，将收到确认页和订单号。发货选择必须支持以下发货选择：装运港地面交货次日交货隔夜交货国际交货订单状态通知用户可选择接收有关订单状态的电子通知。装运费用的计算装运费用的计算基于承运人的类型（如UPS）或站点所有者规左的其他规则。税金的计算税金的il算必须基于站点所有者规立的规则。这些规则应包括：销售地点发货地址货物类型结帐时，税金信息将显示在“订单一览表”屏幕上。订单一览表该屏幕显示每个订单的地址、项目说明、项目价格、装运费用、税金和费用总计（若有）。地址簿已注册的用户都会保存在地址簿

24、中。尽管站点所有者可设置一些限制，该地址簿仍可存放无限的发货地 址信息。订单的取消用户在提交订单之前必须能够随时取消订单。此操作将导致购物篮中的所有项目都被淸空。但保留的项 目不会受到影响。系统需求站点必须满足以下系统X围的需求：全球化能力应用程序应能够进行自定义以适应不同的文化环境。即：界而颜色、导航布局、页结构和语言都应可以 修改。性能用户在每次访问该站点时都应能体验到始终如一的性能。站点的表现应和其他正在使用的企业电子商务 应用程序一样好。可扩展性站点应既能向上扩展又能向外扩展。如果添加了更快的磁盘和CPU或添加了更大的RAM,响应应更快。 如果给Web领域添加了更多的服务器，响应也应该

25、有所改进领域中的服务器应能正确处理请求。可用性 站点应处于开启和运行状态，且应无任何故障。它应能捕获错误，此功能应不会防止用户访问站点授权 的区域。站点应随时能接受用户的访问。可管理性站点上应有一个管理界而，用于修改和管理公司报表、目录、订单、装运费用、税率和用户XX。安全性站点应保护XX信息，如信用卡号。站点应显示XX政策和任何相关的信息。用户ID和口令应防止未经 授权的人员访问敏感信息。允许通过多种设备访问站点必须能在多种客户端设备上正常运转。站点应能在低版本的浏览器和髙版本的浏览器上工作。以文档形式记录业务需求确左了基本需求之后，应在“构想/X用”文档中捕捉、传递和批准这些需求，该文档标

26、识了应用程序 业务值、需求和限制以及规划、设计和完成项目所需的人员。之后，即可开始设计了。下一肖说明在ConsolidatedRetail.的创建过程中所用的应用程序设计模型和设计过程。MSF应用程序模型ConsolidatedRetail.应用程序的设il遵循Microsoft解决方案框架(MSF)中泄义的三层模型。该模 型将应用程序提供的服务划分成三个抽象层，以便由此得到的应用程序具有一左的灵活性和可扩展性。 任何一层都可以进行更改，且不会对苴他两层产生负面影响，这样将能不断改进应用程序以满足用户需 求和技术方而的新变化。这三层是：表示服务：应用程序的表示服务用于呈现向用户显示的数据和接受

27、用户的输入。业务服务：有时又称为'应用程序服务”，应用程序的业务服务强制执行业务规则。在典型的电子 商务应用程序中，这可能包括：确保用戸在下订单之前必须经过身份验证，根据用户的配苣文件检 索相应的内容，校验在处理订单中涉及的所有步骤都是以正确的顺序执行的。 数据服务：应用程序中的数据服务包括存储、检索和修改数据所需的逻借，以及应用程序必须强制 执行的数据完整性规则。在电子商务应用程序中，这可能包括目录、用户和订单数拯的处理。注意：有关MSF的详细信息，请访问站点 Microsoft./'msf (英文)。为何使用MSF应用程序模型？ 除了以上所述的灵活性和可扩展性优点之外，MSF三层应用程序模型还在减少开发、部署和管理应用程 序时间方而具有明显的优势。在应用程序体系结构上采用MSF三层方式的主要优点体现在：分离：由于服务是相互分离的，因此，应用程序的每一层都可独立于其他两层进行开发、维护和增 强。这样，三个不同的开发小组可以就同一应用程序项目开展工作。分布：由于逻辑层是独立