《2022年第章业务需求和设计方案模型.docx》由会员分享，可在线阅读，更多相关《2022年第章业务需求和设计方案模型.docx（15页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选学习资料 - - - - - - - - - 第 1 章 业务需求和设计模型摘要：本章争论了指导如何设计ConsolidatedR 网站,采纳 Microsoft 商务参考体系结构）的业务需求,并概括了在此应用程序设计期间确定的实际业务需求；本章仍概要介绍了 Microsoft 解决方案框架 Microsoft Solutions Framework,MSF 三层应用程序模型和阶段式设计过程；请留意：尽管此处提到的业务需求仅仅局限于一个可轻松安装的参考示例所具有的才能,但是本“ 开发人员指南” 供应的信息线索非常有用,通过这些线索,您可以对该应用程序进行升级,使其满意生产环境的需求；简介请
2、 Web 用户给电子商务站点定义时,一般用户可能会回答电子商务站点就是可以用信用卡购买商品的在线商店；尽管这个定义相当正确,却没有充分说明目前为 Internet 开发的各种电子商务站点的特点；在迅猛进展的 Internet 商务时代,一个高效率的电子商务网站绝不仅仅是基于 Web 的商店；用户对电子商务站点的要求越来越高,假如某个站点无法满意他们的要求,他们就将弃之而去；那么,用户对电子商务有哪些要求呢？下表列出了一些影响应用程序设计的主要问题；易于使用 / 导航性能高匿名购物爱护用户配置文件安全性好能够通过多种设备拜访站点通过可治理性提高竞争优势粗略一看,在上述问题中,有些应由应用程序设计
3、人员负责解决,有些好像应由企业决策者或基本结构专家负责解决；不过,假如您认真摸索这些问题,就会明白这些问题为什么都与应用程序的设计有关；易于使用 / 导航网站理所当然地应当易于使用和导航；究竟,企业不期望消费者在购买自己的产品时遇到困难,而消费者也更情愿在自己能轻松找到结帐页的站点消费；使站点易于使用的一种方法是确保在常见任务上使用大家熟识的类似方法；这意味着在消费者完成购买 或“ 结帐” ）之前,可将其选购的商品储备在购物篮或筐中；这种比如可便于不熟识运算机的人懂得站点是如何工作的,从而开展购买活动；使站点易于导航比您最初想象的要困难得多；Web 完全是以一种非线性方式工作的,用户单击链接的
4、次序常常无法预料；因此,您应该确保无论用户目前在查看哪一页,站点向用户展现的始终是完全一样的界面,并确保只需单击一个链接即可拜访重要网页 如主页、1 / 12 名师归纳总结 - - - - - - -第 1 页,共 12 页精选学习资料 - - - - - - - - - 购物篮所在页以及用户帐户信息所在页等）；在 ConsolidatedR 站点上,顶部的标帜始终包含到购物篮所在页、消费者帐户所在页和主页的链接,而左侧的面板上始终包含搜寻和目录链接；仍有一种方法可以确保用户能在站点中找到所需内容,这就是要以规律方式编排产品清单或目录；假如将目录分成几个类别和很多可 能的子类别,即可让消费者轻
5、而易举地找到他们感爱好的产品；此外,仍应给用户供应搜寻功能,以便他们在不太清晰某种产品的陈 列位置时可以进行搜寻；假如您的站点易于使用和导航,消费者将愿意使用；相反,假如使用起来比较困难,消费者可能就会弃之而去,另择站点；性能高在网站的设计当中,影响其性能的因素很多；由于不同的人对性能的要求各不相同,因而,对于什么才是可接受的性能水平也将因人 而异；尽量削减响应时间大多数人认为：供应可接受的响应时间的站点才是性能良好的站点；响应时间是指用户在恳求了某个操作之后、能够看到结果之前需 要等待的时间量；在抱负情形下,我们都期望站点上的操作瞬时就能得到执行；但在实际生活中,我们需要接受这样一个事实：有
6、限 的带宽、数据库并发性和业务处理任务通常都会导致稍微的推迟；因此,设计电子商务站点时,应尽量削减那些对响应时间有负面影 响的因素 尽管不能完全排除它们）；电子商务优化的关键在于削减执行诸如结帐之类的操作所耗费的时间,这样,消费者就不会因排队等待而舍弃自己选购的商品,您也 就不会因此而失去订单；尽量增强可扩展性性能的另一个重要方面就是“ 可扩展性” ；这是指添加资源时站点容量增加的才能；从用户角度来看,这意味着当大量用户同时拜访 站点时,站点仍能供应可接受的响应时间；很多开发人员常常会得到这样令人懊丧的消息：当拜访的用户达到肯定数量 这个数量是实 际生活要求达到的数量）后,在开发机上性能杰出的
7、测试站点就无法应对；那么,如何才能最大限度地增强站点的可扩展性呢？两种典型的方法就是“ 向上扩展” 和“ 向外扩展” ；向上扩展第一种方法 “ 向上扩展” ）就是通过采纳更好和 / 或更快的 CPU、更大的 RAM、更快的磁盘等等来增强服务器的处理才能；这种方法 特别有效,特别是在数据层上,该层上的一些大型数据库需要相对较强的处理才能；不过,由于硬件成本随处理才能的加强而按指数 增长,因此,服务器越接近顶端,这种方法就愈加不合算；向外扩展“ 向外扩展” 就从另一个方面来解决问题,即由“ 群集” 服务一起,将整个 Web 领域作为一个具有单一 IP 的规律服务器显示在 Internet 上；收到
8、恳求之 2 / 12 名师归纳总结 - - - - - - -第 2 页,共 12 页精选学习资料 - - - - - - - - - 后,会依据负载情形将恳求分发给领域中的服务器,这些服务器可使用主干网络进行通信,也可以与数据库服务器进行通信；图 1-1 显示 Web 领域的基本体系结构；图 1-1 ：Web 领域治理 Web 领域中的状态对于商务站点设计人员而言,最重要的问题之一就是 Web 领域中的应用程序状态问题；状态就是在两个用户恳求之间必需保留的会话数据；例如,在用户连续浏览站点期间,必需始终爱护该用户购物篮中的物品原状；即使每个用户恳求可能是由 Web 领域中不同的服务器处理的,
9、也须如此；很多 ASP 开发人员使用“ 会话” 对象来存放状态数据；不过,通常应防止使用此方法；为了优化站点的软件体系结构以便在服务器领域中加以实现, Web 前端禁止爱护内存中的用户状态；假如前端服务器爱护用户状态,将显现以下问题：用户会话将依附于特定服务器 会话相关性）,这会破坏动态地将恳求安排给服务器的网络负载平稳策略；此外,仍会破坏服务器领域的牢靠性,由于当原服务器发生故障 并丢失了其内存中的会话状态信息）时,就无法将用户会话转移到其他服务器；内存资源被前端服务器耗费在存放用户会话状态的细节上,从而削减了可用于处理恳求和高速缓存内容的内存；假如一个受欢迎的站点能够在短时间内吸引大量的用
10、户,就状态爱护方面的内存需求可能特别大；为了部分解决内存需求问题,Commerce Server 大量使用了高速缓存；对配置文件架构、折扣和商业活动都将进行高速缓存；3 / 12 名师归纳总结 - - - - - - -第 3 页,共 12 页精选学习资料 - - - - - - - - - 除了防止会话相关性之外,仍应防止使前端操作与长时间运行的操作发生关联,以便将前端操作设计为快速执行的操作；由于IIS 是用一个缓冲池来处理恳求而缓冲池包含的工作器线程数量是有限的,因而当这些线程都已被占用且在等待长时间运行的操作完成时,传入恳求等待处理的平均时间就会增加；匿名购物 浏览）通常,用户都不情愿
11、仅仅为了明白站点在销售哪些商品而被迫登录到站点；因此,站点应在不需要身份验证的情形下,答应用户以匿名方式浏览商品,甚至答应他们将一部分商品放入购物篮中；爱护用户配置文件当用户再次拜访站点时,他们不期望重新输入上次拜访时输入过的相同资料；一旦向站点供应了自己的购物和联系信息后,用户就希望站点能够记住这些数据；为了实现此目的,很多站点会为每个已注册的用户爱护其用户“ 配置文件” 信息；在大多数情形下,用户都需要注册,以便供应最少量的配置文件信息,如用户名和口令；然后,用户会安排到一个唯独标识符,该标识符可用作其配置文件数据的主密钥；用户在站点上注册之后,其配置文件信息就可以储存在数据库中,以便在以
12、后需要时调用；通常,用户可以添加一些必备信息,指定一些细节,如电子邮件地址、电话号码、发货地址或任何其他答应用户添加的个人信息；保留用户配置文件信息相当有用,其缘由如下：使用户在以后拜访时不必重新输入数据；可用于分析用户在站点上的活动；可作为个性化的基础,答应您依据特定的用户群发布标帜广告或开展打折活动；可用于商业分析,如依据特定的配置文件值跟踪购买趋势；通过可治理性提高竞争优势尽管应用程序设计人员不负责业务决策 如定价、广告活动等等）,电子商务解决方案的设计对企业如何应对市场趋势和竞争对手活动却有着庞大影响；业务经理开展的治理活动要受电子商务站点治理功能的制约；要取得胜利,电子商务解决方案必
13、需易于使用,仍必须具备全面的治理基础结构；为电子商务站点设计治理界面时有两个基本挑选；您可以创建自己自定义的界面,也可以使用一种“ 现成的” 解决方案,如Microsoft Commerce Server 2000 Business Desk；假如构建自己的治理界面,您将能完全依据自己的愿望来设计站点的治理功能；不过,这样会给一个已经很大的软件工程增加大量开发工作量,其工作量几乎等于或大于软件工程本身的工作量；默认情形下,Commerce Server Business Desk 可以满意电子商务站点的大多数治理要求,假如需要仍可以通过创建自定义模块来添加其他功能；本章的其余部分将说明在该工程
14、的规划阶段确认的实际业务需求,以及在 ConsolidatedR 应用程序的设计中所使用的应用程序模型和设计过程；参考应用程序业务需求4 / 12 名师归纳总结 - - - - - - -第 4 页,共 12 页精选学习资料 - - - - - - - - - 在设计应用程序之前,应当明确该应用程序必需执行哪些任务；分析业务需求是应用程序开发中最重要的步骤之一；确认业务需求的目的在于创建一个能同时满意零售商和消费者需要的解决方案；这样,需求就转换成了业务需求文档,这种文档可作为开发整个工程的指南；本节概括了为参考体系结构应用程序 ConsolidatedR 确定的实际需求；请留意：此处所用的业
15、务需求被有意限制为一个可轻松安装的参考示例具有的才能；功能需求ConsolidatedR 旨在满意以下功能需求：易于导航站点应易于导航；链接应当清晰、易于懂得而且有用；用户应能够在页和屏幕之间随便移动；易于使用应用程序应易于使用；应当易于购买产品和拜访“ 结帐” 页；站点应使用易于懂得的比如,例如：将选购的物品储备在“ 购物篮” 中,直到购物者预备结帐站点上的每一页都应显示完全一样的界面；重要页或常用页应只需单击一次即可拜访；可用性测试站点应使不熟识运算机的人易于懂得；站点拜访用户能通过以下方法拜访站点：在浏览器中输入 URL 从其他站点或电子邮件的链接拜访爱护用户注册 / 配置文件无论从站点
16、上的任何页,用户都必需能够注册,这样,用户就不必在每次下订单时都重新输入相同的信息；用户无需注册即可浏览站点；但结帐时必需注册；另外,申请电子邮件时事通讯、特价通知等服务时要求注册；注册涉及：配置文件信息：用户名、付款地址、主要发货地址、电话号码和电子邮件地址；身份验证信息：用户身份标识 用户 ID ）和口令应保留在应用程序中；付款信息：用户应可以输入信用卡信息并储存该信息；应用程序应能够储存多个信用卡号；5 / 12 名师归纳总结 - - - - - - -第 5 页,共 12 页精选学习资料 - - - - - - - - - 首选项：用户应能够指定是否想得到有关发货状态的电子邮件通知 通
17、知 默认值为“ 否” ）；地址簿：用户应能够储备任意多个附加发货地址；保留用户配置文件信息相当有用,其缘由如下：使用户在以后拜访时不必重新输入数据；默认值为“ 是” ）,以及是否想得到有关销售价格和特价的可作为个性化的基础,答应您依据特定的用户群发布标帜广告或开展打折活动；可用于商业分析,例如,依据特定的配置文件值跟踪购买趋势；用户注册治理用户登录并经过身份验证之后,用户应能够修改、添加或删除注册信息；除“ 用户登录 / 身份验证 ID ” 字段之外,全部其他字段都应是可编辑字段；用户一经注册之后,假如该用户返回到站点,他或她应能够从该站点上的任何页登录；浏览用户应能够浏览目录；在主页上,应向
18、用户显示目录清单；在用户挑选了一个目录之后,应向其显示子类别或实际产品；匿名浏览用户应能够以匿名方式浏览目录；即：用户应能够在不必登录的情形下即可查看产品；多目录应用程序应支持多目录；多目录产品的汇总对用户应是透亮的；产品和类别应用程序应答应将产品与一个或多个目录关联；产品页应用程序应有一产品页,其中包括该产品工程的较大图片和 此页,用户应能够：将产品工程添加到购物篮中浏览下一个工程浏览上一个工程/ 或该产品工程的具体说明；在此页,应能够将该产品添加到购物篮中；在6 / 12 名师归纳总结 - - - - - - -第 6 页,共 12 页精选学习资料 - - - - - - - - - 返回
19、上一页产品搜寻主页以及全部类别页和子类别页都应能进行搜寻；用户应能够输入多个词；假如用户指定多个词,将依据这些词构建使用“and” 运算符的布尔查询；假如用户在主页上,搜寻将默认为“ 搜寻全部类别” ；在类别和子类别页执行的搜寻将默认为“ 在类别名范畴内搜寻” ；用户可以挑选要搜寻的特定站点区域或特定类别,以便掩盖这些默认设置；假如站点使用多目录,将对全部目录执行搜寻；假如站点展现了多个目录 并有一个分层产品清单）,就不会按此规章进行搜寻；在类别/ 产品分层结构中,每个目录都是第一级；在这种情形下,默认为只搜寻用户当前所在的目录；用户可以掩盖默认设置,挑选搜寻其他目录或整个站点；这类似于从前描
20、述的为“ 多目录” 指定的行为；默认情形下,将针对关键词和标题进行搜寻；产品搜寻结果“ 搜寻结果” 页应显示一系列产品工程及其相应类别 文本链接；向购物篮中添加工程或目录）；工程应按类别或目录分组；每个搜寻结果都应供应到相应产品页的超无论从任何产品页中,用户都应能够将一个或多个工程添加到购物篮中；这些工程可来自不同的目录；每添加一个工程,篮中的工程数也会相应地增加；该数目显示在该篮子图标旁边；治理购物篮用户应随时能够治理购物篮；用户可指定工程是“ 活动的”实际购买的标记）仍是“ 保留的”标识为将来可能购买）；用户查看购物篮时可进行以下挑选：删除单个工程；更换每种工程的数量；保留任何工程,以备将
21、来购买；删除购物篮中的全部工程；保留购物篮中的全部工程,以备将来购买；将工程移入购物篮的保留 将来购买）区和从中移出工程；检索保留的订单；保留购物篮或工程7 / 12 名师归纳总结 - - - - - - -第 7 页,共 12 页精选学习资料 - - - - - - - - - 用户应能够保留选定的工程或购物篮中的全部物品,以备将来购买；只有已注册并登录的用户可以保留其工程；假如用户尚未登录或注册,将提示他们进行此操作；用户完成此操作之后,将返回到“ 保留购物篮” 操作；结帐无论从任何屏幕,用户都应能够结帐；结帐时,将向用户显示全部订购的工程 购物篮）；此时,用户应能够治理购物篮；用户对购物
22、篮中的物品进行确认后,将显现“ 发货” 屏幕；每个工程都将与该用户的主要发货地址关联；用户可以用地址簿中的一个地址或新地址来替换该地址；假如用户添加了一个新地址,他或她可以挑选将该新地址储存在地址簿中；用户为每个工程指派了地址 或接受了默认的地址）之后,他或她可以转至“ 发货” 屏幕,挑选每个地址的交货方式；默认方式由站点全部者打算；用户挑选交货方式后,他或她可以连续到“ 订单一览表” 屏幕；该屏幕应按发货地址划分；在每个地址下,将列出工程说明、工程价格以及价格合计 如有）；对该工程的价格合计进行小计,将装运费用作为明细工程列出并进行小计,最终将列出该地址下的税金和总金额；对全部地址下的金额求
23、和之后,会在该页的末尾列出总计；用户可以：接受订单修改订单取消订单连续购物假如用户挑选修改订单,他或她将返回到“ 治理购物篮” 页；假如用户挑选取消订单,将清空购物篮；假如用户挑选连续购物,他或她应当返回到主页；假如用户挑选接受订单,他或她将转至“ 付款” 页；假如用户已在“ 注册” 页中储备了信用卡信息,就显示该信息；用户可挑选使用储存的信用卡,也可挑选忽视储存的信息,供应新的信用卡信息；假如用户添加新的信用卡信息,他或她应可以挑选将新信息添加到储存的注册信息中；用户挑选或输入了信用卡信息之后,他或她可以：取消订单修改订单连续购物提交订单假如用户提交了订单,将收到确认页和订单号；发货挑选必需
24、支持以下发货挑选：8 / 12 名师归纳总结 - - - - - - -第 8 页,共 12 页精选学习资料 - - - - - - - - - 装运港地面交货次日交货隔夜交货国际交货订单状态通知用户可挑选接收有关订单状态的电子邮件通知；装运费用的运算装运费用的运算基于承运人的类型 如 UPS）或站点全部者规定的其他规章；税金的运算税金的运算必需基于站点全部者规定的规章；这些规章应包括：销售地点发货地址货物类型结帐时,税金信息将显示在“ 订单一览表” 屏幕上；订单一览表该屏幕显示每个订单的地址、工程说明、工程价格、装运费用、税金和费用总计 中定义的三层模型；该模型将应用程序供应的服务划分成三个
25、抽象层,以便由此得到的应用程序具有肯定的敏捷性和可扩展性；任何一层都可以进行更换,且不会对其他两层产生负面影 响,这样将能不断改进应用程序以满意用户需求和技术方面的新变化；这三层是：表示服务：应用程序的表示服务用于出现向用户显示的数据和接受用户的输入；业务服务：有时又称为“ 应用程序服务” ,应用程序的业务服务强制执行业务规章；在典型的电子商务应用程序中,这可能包 括：确保用户在下订单之前必需经过身份验证,依据用户的配置文件检索相应的内容,校验在处理订单中涉及的全部步骤都是以 正确的次序执行的；10 / 12 名师归纳总结 - - - - - - -第 10 页,共 12 页精选学习资料 -
26、- - - - - - - - 数据服务：应用程序中的数据服务包括储备、检索和修改数据所需的规律,以及应用程序必需强制执行的数据完整性规章；在电子商务应用程序中,这可能包括目录、用户和订单数据的处理；留意：有关 MSF 的具体信息,请拜访站点 英文）；为何使用 MSF 应用程序模型？除了以上所述的敏捷性和可扩展性优点之外,MSF 三层应用程序模型仍在削减开发、部署和治理应用程序时间方面具有明显的优势；在应用程序体系结构上采纳 MSF 三层方式的主要优点表达在：分别：由于服务是相互分别的,因此,应用程序的每一层都可独立于其他两层进行开发、爱护和增强；这样,三个不同的开发小组可以就同一应用程序工程
27、开展工作；分布：由于规律层是独立的,因此,可将它们以分布式方式部署在多个服务器上；重新使用：不同的客户端设备可以使用每一层供应的服务；例如,电子商务站点的业务服务可被一组表示服务使用,以便给网站供应 HTML 接口；也可被另一组表示服务用于支持 WAP 的手机；某些业务服务仍可被各种行业 LOB 应用程序或贸易合作伙伴供应的补充应用程序配置为 Web 服务；除遵循三层设计模型之外,ConsolidatedR 的设计人员和开发人员仍遵循了 MSF 设计过程；下面叙述此过程；MSF 应用程序的设计过程无论构建何种类型的有效应用程序,第一步都是确保在设计上是合理的；软件设计的方法有多种,每一种都有自
28、己的优点和缺点；决定要使用的设计过程时,应确保该过程供应了明确的阶段,这些阶段是按实际软件的实现步骤来划分的；确保该过程能依据各个阶段的需求变化进行调整；MSF 应用程序设计模型不仅为分布式应用程序定义了基于服务的体系结构,仍定义了一种循环的设计过程,在每一轮循环中,软件是按“ 概念” 阶段、“ 规律” 阶段、“ 物理” 阶段这样的次序设计的；概念阶段：在概念阶段,将从用户和 / 或企业的角度看待面临的挑战；概念阶段的主要目标在于定义挑战和解决方案的概念；“ 功能说明书” 文档是概念阶段的最终成果；规律阶段：在规律阶段,将从工程开发小组的角度看待设计目标和挑战；规律阶段的主要目标在于将概念设计
29、映射为规律组件；小组使用概念阶段中标识的用户方案 或用户案例）来构建面对对象的软件解决方案中各组件的规律模型；面对对象的解决方案将业务功能装入实际对象的软件表示法中,这由面对对象的设计中的“ 类” 定义；物理阶段：在物理阶段,将从开发人员的角度看待目标和挑战；物理阶段的主要目标在于将规律设计应用到实际需求和约束；由于物理阶段是从开发人员的角度考虑设计问题,而且任务就是定义物理实现方案,因此物理设计阶段的成果是技术规范文档；总结本章包含电子商务需求的一般性概述,并概括了 ConsolidatedR 应用程序的特定需求；本章仍对 MSF 应用程序模型和设计过程进行了概要说明；下一章将更为具体地争论“ 概念” 、“ 规律” 和“ 物理” 设计阶段以及各个阶段的最终成果；11 / 12 名师归纳总结 - - - - - - -第 11 页,共 12 页精选学习资料 - - - - - - - - - 12 / 12 名师归纳总结 - - - - - - -第 12 页,共 12 页