个性化邮件系统用例设计和实现.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
个性化邮件系统用例设计和实现 首先,让我们來定义什么是“川例的实现? 我们知道在系统设计软件实践过程屮,通常要遵循一定的步骤或迭代。在这个迭代过程 屮,一般而言第一步是创建设计类图的基础版木或为初步模型,然后是开发交互图。通常情 况下,会给每一个用例产生一个交互图。开发交互图是面向对象系统设计的核心,经常会使 用到的是用例图、用例描述、系统顺序图和设计类图。我们称这些设计模型的最终结呆为“用 例的实现”。一言以蔽之,“用例的实现指的是对每个川例的详细系统过程进行说明。 本文我们结合某省邮政局的个性化邮件系统的一些典型用例的实现作一?帝探讨。 一、个性化邮件系统需求概述 个性化邮件系统(以下简称Y系统)主要是市邮票公司提供给市民的特种邮票服务, 它能把客八的个人照片印在特定版而的邮票上,使之具有一种特别的纪念意义。而邮票公司 所提供的两种款式分别是“岁岁平安”和“太阳神鸟”町供客户不同的喜好选择。 经过公司的业务分析和系统分析人员的流程优化后,共同定义了如下的全部页血流程: 1首页,款式展示和流程说明。 2授权书。 3客户录入基木信息并上传身份证 4客户卜?单,输入所选款式、数量并上传相片,系统自动汇总计算订单金额。 5显示客八信息和订单明细信息。 6确认订单。 7显示订单号和金额。 8确认付款。 9输入帐号。 10申请成功,提示领取信息。 总的说来,整个流程就是: 1客户下单 2支付 3审核 4投递或自取 从业务逻辑上看來,如果我们把提供的款式看成产貼,每件款式的单价是确定的,而数 量是需要客户下达的,只是由于业务特点的需求,它的商品“原材料实际上是由客户上传的。 “麻雀虽小,五脏俱全”,丫系统(即前文提到的“个性化邮件系统”)规模不人,但是已经 涵盖了企业客户、订单、生产(服务)、发货全部的运营流程。从丫系统的业务需求看,它 比较类似于购物车的需求实现。从金业运作流程看,丫系统就是一个迷你版的ERP销售系 统。 二、重点用例 按照基于用例的开发流程,原始业务需求一旦确认,我们则进入了确定和提炼用例阶段。 最终,我们给出了如下的对业务起著决定意义的用例。 Use Case ID: 创建订单(Create Order) 主题:UC01创建订单 相关主题:Create Order 需求ID : R01 目的 使用例参少者能确保创建和提交订单并能够添加相关产品(上传照片)到订单行。 描述 参与者想通过订单购买一种或多种产品(服务)。在受理网站上,参与者通过类似于购 物篮的形式,完成产品的添加和订单下达,一旦产品被添加到订单,订单将即时更新订单 总金额。 前提条件 1) 参与者已经登陆到木系统网站,系统首页已能让参与者受理个性化邮票业务。 2) 参与者必须选择至少一件产品给订单,即必须上传一张照片。 参与者 1) 客户 2) 管理员 基木流程 第1步:当参与者决定下达订单,本用例即开始。 笫2步:参与者注册客户信息,系统通过其身份登记和认证。 第3步:参与者创建订单,系统返回其订单创建信息。 第4步:系统处理参与者的创建订单请求,肓到客户完成该订单。 参与者选择一种产品款式(此处可以作为单独用例UC08查看款式目录)。 参与者键入订购数量。 参与者添加商品即上传照片给订单。 系统更新订单行资料,包括数虽、款式、商品和总金额。 第5步:参与者确认已完成订单。 第6步:参与者验证并确认订单和客户明细信息,系统反馈该参与者的提交的订单详 情O 第7步:参与者验证并确认订单付款信息,系统反馈订单编号和付款总金额。 第8步:参与者确认订单付款,系统调用相关付款接口完成付款流程(此处可以作为 单独用例UC 09订单付款)。 第9步:木用例结束,当系统成功返冋给参与者该订单付款悄况,并提示参与者相关订 单发货信息。 附加流程 1) 如果付款或投递被延迟进行,则第7步到第9步将被跳过,本用例在订单被确认和保 存时结束。 2) 如果订单已经存在(was previously deferred): 当先前下达的订单被选择时本用例开始。 第2步则为系统显示Z前创建的订单。 第3步到第9步遵循基木流程的步骤。 3) 如果客户键入了错课的付款信息,系统将通知参与者,然后木用例应从第7步继续。 内涵/扩展 None 实施需求 None 使用频率 经常 特别需求 ID 款式 照片 ID 款式 照片 数量 岁岁平安 1 岁岁平安 1 太阳神舟 1 问题 无 决策点 无 耒来需求 无 修改版本 Da Auth Descripti on te or 用例模型 Use Case ID: 审核订单(Approve Order) 主题:UC02审核订单 相关主题:Approve Order 需求ID : R02 目的 使丿IJ例参与者能查看所有订单并根据具体情况做出审核决定

文档评论(0)

ggkkppp + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档