第章业务需求和设计方案模型.docx
《第章业务需求和设计方案模型.docx》由会员分享，可在线阅读，更多相关《第章业务需求和设计方案模型.docx（16页珍藏版）》请在冰点文库上搜索。
第章业务需求和设计方案模型
第1章业务需求和设计模型
摘要：
本章讨论了指导如何设计ConsolidatedR<它属于企业对消费者（B2C>网站，采用Microsoft商务参考体系结构）的业务需求，并概括了在此应用程序设计期间确定的实际业务需求。
本章还概要介绍了Microsoft解决方案框架（MicrosoftSolutionsFramework，MSF>三层应用程序模型和阶段式设计过程。
请注意：
尽管此处提到的业务需求仅仅局限于一个可轻松安装的参考示例所具有的能力，但是本“开发人员指南”提供的信息线索非常有用，通过这些线索，您可以对该应用程序进行升级，使其满足生产环境的需求。
简介
请Web用户给电子商务站点定义时，一般用户可能会回答电子商务站点就是可以用信用卡购买商品的在线商店。
尽管这个定义相当正确，却没有充分说明目前为Internet开发的各种电子商务站点的特点。
在迅猛发展的Internet商务时代，一个高效率的电子商务网站绝不仅仅是基于Web的商店。
用户对电子商务站点的要求越来越高，如果某个站点无法满足他们的要求，他们就将弃之而去。
那么，用户对电子商务有哪些要求呢？
下表列出了一些影响应用程序设计的主要问题。
∙易于使用/导航
∙性能高
∙匿名购物
∙维护用户配置文件
∙安全性好
∙能够通过多种设备访问站点
∙通过可管理性提高竞争优势
粗略一看，在上述问题中，有些应由应用程序设计人员负责解决，有些似乎应由企业决策者或基本结构专家负责解决。
不过，如果您仔细思考这些问题，就会明白这些问题为什么都与应用程序的设计有关。
易于使用/导航
网站理所当然地应该易于使用和导航。
毕竟，企业不希望消费者在购买自己的产品时遇到困难，而消费者也更愿意在自己能轻松找到结帐页的站点消费。
使站点易于使用的一种方法是确保在常见任务上使用大家熟悉的类似方法。
这意味着在消费者完成购买<或“结帐”）之前，可将其选购的商品存储在购物篮或筐中。
这种比喻可便于不熟悉计算机的人理解站点是如何工作的，从而开展购买活动。
使站点易于导航比您最初想象的要困难得多。
Web完全是以一种非线性方式工作的，用户单击链接的顺序经常无法预料。
因此，您应该确保无论用户目前在查看哪一页，站点向用户展示的始终是完全一致的界面，并确保只需单击一个链接即可访问重要网页<如主页、购物篮所在页以及用户帐户信息所在页等）。
在ConsolidatedR站点上，顶部的标帜始终包含到购物篮所在页、消费者帐户所在页和主页的链接，而左侧的面板上始终包含搜索和目录链接。
还有一种方法可以确保用户能在站点中找到所需内容，这就是要以逻辑方式编排产品清单或目录。
如果将目录分成几个类别和许多可能的子类别，即可让消费者轻而易举地找到他们感兴趣的产品。
此外，还应给用户提供搜索功能，以便他们在不太清楚某种产品的陈列位置时可以进行搜索。
如果您的站点易于使用和导航，消费者将乐意使用。
相反，如果使用起来比较困难，消费者可能就会弃之而去，另择站点。
性能高
在网站的设计当中，影响其性能的因素很多。
由于不同的人对性能的要求各不相同，因而，对于什么才是可接受的性能水平也将因人而异。
尽量减少响应时间
大多数人认为：
提供可接受的响应时间的站点才是性能良好的站点。
响应时间是指用户在请求了某个操作之后、能够看到结果之前需要等待的时间量。
在理想情况下，我们都希望站点上的操作瞬时就能得到执行；但在实际生活中，我们需要接受这样一个事实：
有限的带宽、数据库并发性和业务处理任务通常都会导致轻微的延迟。
因此，设计电子商务站点时，应尽量减少那些对响应时间有负面影响的因素<尽管不能完全排除它们）。
电子商务优化的关键在于减少执行诸如结帐之类的操作所耗费的时间，这样，消费者就不会因排队等待而放弃自己选购的商品，您也就不会因此而失去订单。
尽量增强可扩展性
性能的另一个重要方面就是“可扩展性”。
这是指添加资源时站点容量增加的能力。
从用户角度来看，这意味着当大量用户同时访问站点时，站点仍能提供可接受的响应时间。
许多开发人员经常会得到这样令人沮丧的消息：
当访问的用户达到一定数量<这个数量是实际生活要求达到的数量）后，在开发机上性能卓越的测试站点就无法应付。
那么，如何才能最大限度地增强站点的可扩展性呢？
两种典型的方法就是“向上扩展”和“向外扩展”。
向上扩展
第一种方法<“向上扩展”）就是通过采用更好和/或更快的CPU、更大的RAM、更快的磁盘等等来增强服务器的处理能力。
这种方法非常有效，尤其是在数据层上，该层上的一些大型数据库需要相对较强的处理能力。
不过，由于硬件成本随处理能力的加强而按指数增长，因此，服务器越接近顶端，这种方法就愈加不合算。
向外扩展
“向外扩展”则从另一个方面来解决问题，即由“群集”<或服务器集合，也称为“Web领域”）中的多个服务器来分担处理工作量。
Web领域在硬件方面的花费更为合算，而且提供了更为灵活、可扩展的解决方案。
当站点上的负载增加时，可以很轻松地将服务器添加到Web领域中。
Microsoft®Windows®2000AdvancedServer和Windows2000DatacenterServer以及Windows网络负载平衡（WindowsNetworkLoadBalancing，NLB>服务一起，将整个Web领域作为一个具有单一IP的逻辑服务器显示在Internet上。
收到请求之后，会根据负载情况将请求分发给领域中的服务器，这些服务器可使用主干网络进行通信，也可以与数据库服务器进行通信。
图1-1显示Web领域的基本体系结构。
图1-1：
Web领域
管理Web领域中的状态
对于商务站点设计人员而言，最重要的问题之一就是Web领域中的应用程序状态问题。
状态就是在两个用户请求之间必须保留的会话数据；例如，在用户继续浏览站点期间，必须一直维护该用户购物篮中的物品原状。
即使每个用户请求可能是由Web领域中不同的服务器处理的，也须如此。
许多ASP开发人员使用“会话”对象来存放状态数据。
不过，通常应避免使用此方法。
为了优化站点的软件体系结构以便在服务器领域中加以实现，Web前端禁止维护内存中的用户状态。
如果前端服务器维护用户状态，将出现以下问题：
∙用户会话将依附于特定服务器<会话相关性），这会破坏动态地将请求分配给服务器的网络负载平衡策略。
此外，还会破坏服务器领域的可靠性，因为当原服务器发生故障<并丢失了其内存中的会话状态信息）时，就无法将用户会话转移到其他服务器。
∙内存资源被前端服务器耗费在存放用户会话状态的细节上，从而减少了可用于处理请求和高速缓存内容的内存。
如果一个受欢迎的站点能够在短时间内吸引大量的用户，则状态维护方面的内存需求可能非常大。
为了部分解决内存需求问题，CommerceServer大量使用了高速缓存。
对配置文件架构、折扣和商业活动都将进行高速缓存。
∙除了避免会话相关性之外，还应避免使前端操作与长时间运行的操作发生关联，以便将前端操作设计为快速执行的操作。
由于IIS是用一个缓冲池来处理请求而缓冲池包含的工作器线程数量是有限的，因而当这些线程都已被占用且在等待长时间运行的操作完成时，传入请求等待处理的平均时间就会增加。
匿名购物<浏览）
通常，用户都不愿意仅仅为了了解站点在销售哪些商品而被迫登录到站点。
因此，站点应在不需要身份验证的情况下，允许用户以匿名方式浏览商品，甚至允许他们将一部分商品放入购物篮中。
维护用户配置文件
当用户再次访问站点时，他们不希望重新输入上次访问时输入过的相同资料。
一旦向站点提供了自己的购物和联系信息后，用户就希望站点能够记住这些数据。
为了实现此目的，许多站点会为每个已注册的用户维护其用户“配置文件”信息。
在大多数情况下，用户都需要注册，以便提供最少量的配置文件信息，如用户名和口令。
然后，用户会分配到一个唯一标识符，该标识符可用作其配置文件数据的主密钥。
用户在站点上注册之后，其配置文件信息就可以保存在数据库中，以便在以后需要时调用。
通常，用户可以添加一些必备信息，指定一些细节，如电子邮件地址、电话号码、发货地址或任何其他允许用户添加的个人信息。
保留用户配置文件信息相当有用，其原因如下：
∙使用户在以后访问时不必重新输入数据。
∙可用于分析用户在站点上的活动。
∙可作为个性化的基础，允许您根据特定的用户群发布标帜广告或开展打折活动。
∙可用于商业分析，如根据特定的配置文件值跟踪购买趋势。
通过可管理性提高竞争优势
尽管应用程序设计人员不负责业务决策<如定价、广告活动等等），电子商务解决方案的设计对企业如何应对市场趋势和竞争对手活动却有着巨大影响。
业务经理开展的管理活动要受电子商务站点管理功能的制约。
要取得成功，电子商务解决方案必须易于使用，还必须具备全面的管理基础结构。
为电子商务站点设计管理界面时有两个基本选择。
您可以创建自己自定义的界面，也可以使用一种“现成的”解决方案，如MicrosoftCommerceServer2000BusinessDesk。
如果构建自己的管理界面，您将能完全按照自己的愿望来设计站点的管理功能。
不过，这样会给一个已经很大的软件工程增加大量开发工作量，其工作量几乎等于或大于软件工程本身的工作量。
默认情况下，CommerceServerBusinessDesk可以满足电子商务站点的大多数管理要求，如果需要还可以通过创建自定义模块来添加其他功能。
本章的其余部分将说明在该工程的规划阶段确认的实际业务需求，以及在ConsolidatedR应用程序的设计中所使用的应用程序模型和设计过程。
参考应用程序业务需求
在设计应用程序之前，应该明确该应用程序必须执行哪些任务。
分析业务需求是应用程序开发中最重要的步骤之一。
确认业务需求的目的在于创建一个能同时满足零售商和消费者需要的解决方案。
这样，需求就转换成了业务需求文档，这种文档可作为开发整个工程的指南。
本节概括了为参考体系结构应用程序ConsolidatedR确定的实际需求。
请注意：
此处所用的业务需求被有意限制为一个可轻松安装的参考示例具有的能力。
功能需求
ConsolidatedR旨在满足以下功能需求：
易于导航
站点应易于导航。
链接应该清晰、易于理解而且实用。
用户应能够在页和屏幕之间随意移动。
易于使用
应用程序应易于使用。
应该易于购买产品和访问“结帐”页。
站点应使用易于理解的比喻，例如：
将选购的物品存储在“购物篮”中，直到购物者准备结帐
站点上的每一页都应显示完全一致的界面。
重要页或常用页应只需单击一次即可访问。
可用性测试
站点应使不熟悉计算机的人易于理解。
站点访问
用户能通过以下方法访问站点：
∙在浏览器中输入URL
∙从其他站点或电子邮件的链接访问
维护用户注册/配置文件
无论从站点上的任何页，用户都必须能够注册，这样，用户就不必在每次下订单时都重新输入相同的信息。
用户无需注册即可浏览站点；但结帐时必须注册。
另外，申请电子邮件时事通讯、特价通知等服务时要求注册。
注册涉及：
∙配置文件信息：
用户名、付款地址、主要发货地址、电话号码和电子邮件地址。
∙身份验证信息：
用户身份标识<用户ID）和口令应保留在应用程序中。
∙付款信息：
用户应可以输入信用卡信息并保存该信息。
应用程序应能够保存多个信用卡号。
∙首选项：
用户应能够指定是否想得到有关发货状态的电子邮件通知<默认值为“是”），以及是否想得到有关销售价格和特价的通知<默认值为“否”）。
∙地址簿：
用户应能够存储任意多个附加发货地址。
保留用户配置文件信息相当有用，其原因如下：
∙使用户在以后访问时不必重新输入数据。
∙可作为个性化的基础，允许您根据特定的用户群发布标帜广告或开展打折活动。
∙可用于商业分析，例如，根据特定的配置文件值跟踪购买趋势。
用户注册管理
用户登录并经过身份验证之后，用户应能够修改、添加或删除注册信息。
除“用户ID”字段之外，所有其他字段都应是可编辑字段。
登录/身份验证
用户一经注册之后，如果该用户返回到站点，他或她应能够从该站点上的任何页登录。
浏览
用户应能够浏览目录。
在主页上，应向用户显示目录清单。
在用户选择了一个目录之后，应向其显示子类别或实际产品。
匿名浏览
用户应能够以匿名方式浏览目录；即：
用户应能够在不必登录的情况下即可查看产品。
多目录
应用程序应支持多目录。
多目录产品的汇总对用户应是透明的。
产品和类别
应用程序应允许将产品与一个或多个目录关联。
产品页
应用程序应有一产品页，其中包括该产品工程的较大图片和/或该产品工程的详细说明。
在此页，应能够将该产品添加到购物篮中。
在此页，用户应能够：
∙将产品工程添加到购物篮中
∙浏览下一个工程
∙浏览上一个工程
∙返回上一页
产品搜索
主页以及所有类别页和子类别页都应能进行搜索。
用户应能够输入多个词。
如果用户指定多个词，将根据这些词构建使用“and”运算符的布尔查询。
如果用户在主页上，搜索将默认为“搜索所有类别”。
在类别和子类别页执行的搜索将默认为“在‘类别名’范围内搜索”。
用户可以选择要搜索的特定站点区域或特定类别，以便覆盖这些默认设置。
如果站点使用多目录，将对所有目录执行搜索。
如果站点展示了多个目录<并有一个分层产品清单），则不会按此规则进行搜索。
在类别/产品分层结构中，每个目录都是第一级。
在这种情况下，默认为只搜索用户当前所在的目录。
用户可以覆盖默认设置，选择搜索其他目录或整个站点。
这类似于先前描述的为“多目录”指定的行为。
默认情况下，将针对关键词和标题进行搜索。
产品搜索结果
“搜索结果”页应显示一系列产品工程及其相应类别<或目录）。
工程应按类别或目录分组。
每个搜索结果都应提供到相应产品页的超文本链接。
向购物篮中添加工程
无论从任何产品页中，用户都应能够将一个或多个工程添加到购物篮中。
这些工程可来自不同的目录。
每添加一个工程，篮中的工程数也会相应地增加。
该数目显示在该篮子图标旁边。
管理购物篮
用户应随时能够管理购物篮。
用户可指定工程是“活动的”<实际购买的标记）还是“保留的”<标识为将来可能购买）。
用户查看购物篮时可进行以下选择：
∙删除单个工程。
∙更改每种工程的数量。
∙保留任何工程，以备将来购买。
∙删除购物篮中的所有工程。
∙保留购物篮中的所有工程，以备将来购买。
∙将工程移入购物篮的保留<将来购买）区和从中移出工程。
∙检索保留的订单。
保留购物篮或工程
用户应能够保留选定的工程或购物篮中的所有物品，以备将来购买。
只有已注册并登录的用户可以保留其工程。
如果用户尚未登录或注册，将提示他们进行此操作。
用户完成此操作之后，将返回到“保留购物篮”操作。
结帐
无论从任何屏幕，用户都应能够结帐。
结帐时，将向用户显示所有订购的工程<购物篮）。
此时，用户应能够管理购物篮。
用户对购物篮中的物品进行确认后，将出现“发货”屏幕。
每个工程都将与该用户的主要发货地址关联。
用户可以用地址簿中的一个地址或新地址来替换该地址。
如果用户添加了一个新地址，他或她可以选择将该新地址保存在地址簿中。
用户为每个工程指派了地址<或接受了默认的地址）之后，他或她可以转至“发货”屏幕，选择每个地址的交货方式。
默认方式由站点所有者决定。
用户选择交货方式后，他或她可以继续到“订单一览表”屏幕。
该屏幕应按发货地址划分。
在每个地址下，将列出工程说明、工程价格以及价格合计<若有）。
对该工程的价格合计进行小计，将装运费用作为明细工程列出并进行小计，最后将列出该地址下的税金和总金额。
对所有地址下的金额求和之后，会在该页的末尾列出总计。
用户可以：
∙接受订单
∙修改订单
∙取消订单
∙继续购物
如果用户选择修改订单，他或她将返回到“管理购物篮”页。
如果用户选择取消订单，将清空购物篮。
如果用户选择继续购物，他或她应该返回到主页。
如果用户选择接受订单，他或她将转至“付款”页。
如果用户已在“注册”页中存储了信用卡信息，则显示该信息。
用户可选择使用保存的信用卡，也可选择忽略保存的信息，提供新的信用卡信息。
如果用户添加新的信用卡信息，他或她应可以选择将新信息添加到保存的注册信息中。
用户选择或输入了信用卡信息之后，他或她可以：
∙取消订单
∙修改订单
∙继续购物
∙提交订单
如果用户提交了订单，将收到确认页和订单号。
发货选择
必须支持以下发货选择：
∙装运港地面交货
∙次日交货
∙隔夜交货
∙国际交货
订单状态通知
用户可选择接收有关订单状态的电子邮件通知。
装运费用的计算
装运费用的计算基于承运人的类型<如UPS）或站点所有者规定的其他规则。
税金的计算
税金的计算必须基于站点所有者规定的规则。
这些规则应包括：
∙销售地点
∙发货地址
∙货物类型
结帐时，税金信息将显示在“订单一览表”屏幕上。
订单一览表
该屏幕显示每个订单的地址、工程说明、工程价格、装运费用、税金和费用总计<若有）。
地址簿
已注册的用户都会保存在地址簿中。
尽管站点所有者可设置一些限制，该地址簿仍可存放无限的发货地址信息。
订单的取消
用户在提交订单之前必须能够随时取消订单。
此操作将导致购物篮中的所有工程都被清空。
但保留的工程不会受到影响。
系统需求
站点必须满足以下系统范围的需求：
全球化能力
应用程序应能够进行自定义以适应不同的文化环境。
即：
界面颜色、导航布局、页结构和语言都应可以修改。
性能
用户在每次访问该站点时都应能体验到始终如一的性能。
站点的表现应和其他正在使用的企业电子商务应用程序一样好。
可扩展性
站点应既能向上扩展又能向外扩展。
如果添加了更快的磁盘和CPU或添加了更大的RAM，响应应更快。
如果给Web领域添加了更多的服务器，响应也应该有所改进。
Web领域中的服务器应能正确处理请求。
可用性
站点应处于开启和运行状态，且应无任何故障。
它应能捕获错误，此功能应不会防止用户访问站点授权的区域。
站点应随时能接受用户的访问。
可管理性
站点上应有一个管理界面，用于修改和管理公司报表、目录、订单、装运费用、税率和用户帐户。
安全性
站点应保护机密信息，如信用卡号。
站点应显示保密政策和任何相关的版权信息。
用户ID和口令应防止XX的人员访问敏感信息。
允许通过多种设备访问
站点必须能在多种客户端设备上正常运转。
站点应能在低版本的浏览器和高版本的浏览器上工作。
以文档形式记录业务需求
确定了基本需求之后，应在“构想/范围”文档中捕捉、传递和批准这些需求，该文档标识了应用程序业务值、需求和限制以及规划、设计和完成工程所需的人员。
之后，即可开始设计了。
下一节说明在ConsolidatedR的创建过程中所用的应用程序设计模型和设计过程。
MSF应用程序模型
ConsolidatedR应用程序的设计遵循Microsoft解决方案框架（MSF>中定义的三层模型。
该模型将应用程序提供的服务划分成三个抽象层，以便由此得到的应用程序具有一定的灵活性和可扩展性。
任何一层都可以进行更改，且不会对其他两层产生负面影响，这样将能不断改进应用程序以满足用户需求和技术方面的新变化。
这三层是：
∙表示服务：
应用程序的表示服务用于呈现向用户显示的数据和接受用户的输入。
∙业务服务：
有时又称为“应用程序服务”，应用程序的业务服务强制执行业务规则。
在典型的电子商务应用程序中，这可能包括：
确保用户在下订单之前必须经过身份验证，根据用户的配置文件检索相应的内容，校验在处理订单中涉及的所有步骤都是以正确的顺序执行的。
∙数据服务：
应用程序中的数据服务包括存储、检索和修改数据所需的逻辑，以及应用程序必须强制执行的数据完整性规则。
在电子商务应用程序中，这可能包括目录、用户和订单数据的处理。
注意：
有关MSF的详细信息，请访问站点
为何使用MSF应用程序模型？
除了以上所述的灵活性和可扩展性优点之外，MSF三层应用程序模型还在减少开发、部署和管理应用程序时间方面具有明显的优势。
在应用程序体系结构上采用MSF三层方式的主要优点体现在：
∙分离：
由于服务是相互分离的，因此，应用程序的每一层都可独立于其他两层进行开发、维护和增强。
这样，三个不同的开发小组可以就同一应用程序工程开展工作。
∙分布：
由于逻辑层是独立的，因此，可将它们以分布式方式部署在多个服务器上。
∙重新使用：
不同的客户端设备可以使用每一层提供的服务。
例如，电子商务站点的业务服务可被一组表示服务使用，以便给网站提供HTML接口；也可被另一组表示服务用于支持WAP的手机。
某些业务服务还可被各种行业（LOB>应用程序或贸易合作伙伴提供的补充应用程序配置为Web服务。
除遵循三层设计模型之外，ConsolidatedR的设计人员和开发人员还遵循了MSF设计过程。
下面讲述此过程。
MSF应用程序的设计过程
无论构建何种类型的有效应用程序，第一步都是确保在设计上是合理的。
软件设计的方法有多种，每一种都有自己的优点和缺点。
决定要使用的设计过程时，应确保该过程提供了明确的阶段，这些阶段是按实际软件的实现步骤来划分的；确保该过程能根据各个阶段的需求变化进行调整。
MSF应用程序设计模型不仅为分布式应用程序定义了基于服务的体系结构，还定义了一种循环的设计过程，在每一轮循环中，软件是按“概念”阶段、“逻辑”阶段、“物理”阶段这样的顺序设计的。
∙概念阶段：
在概念阶段，将从用户和/或企业的角度看待面临的挑战。
概念阶段的主要目标在于定义挑战和解决方案的概念。
“功能说明书”文档是概念阶段的最终成果。
∙逻辑阶段：
在逻辑阶段，将从工程开发小组的角度看待设计目标和挑战。
逻辑阶段的主要目标在于将概念设计映射为逻辑组件。
小组使用概念阶段中标识的用户方案<或用户案例）来构建面向对象的软件解决方案中各组件的逻辑模型。
面向对象的解决方案将业务功能装入实际对象的软件表示法中，这由面向对象的设计中的“类”定义。
∙物理阶段：
在物理阶段，将从开发人员的角度看待目标和挑战。
物理阶段的主要目标在于将逻辑设计应用到实际需求和约束。
由于物理阶段是从开发人员的角度考虑设计问题，而且任务就是定义物理实现方案，因此物理设计阶段的成果是技术规范文档。
总结
本章包含电子商务需求的一般性概述，并概括了ConsolidatedR应用程序的特定需求。
本章还对MSF应用程序模型和设计过程进行了概要说明。
下一章将更为详细地讨论“概念”、“逻辑”和“物理”设计阶段以及各个阶段的最终成果。
升级会员 