系统分析与设计—hw5

使用UMLet建模

##1.根据订旅馆建模文档，Asg-RH.pdf：

  • 绘制用例图模型（到子用例）
  • 给出 make reservation 用例的活动图

绘制订旅馆的用例图模型

对于Asg-RH.pdf给出的订旅馆文档，我们可以简单归纳出以下的用例和子用例的结构关系：

  • 搜索旅馆
    • 输入城市信息
    • 输入日期信息
    • 排序
    • 推荐
  • 预定旅馆
    • 搜索旅馆
    • 选择旅馆
      • 查看详情
    • 选择房间类型
    • 确定预定（加入购物车）
      • 完善客户信息
  • 购物车
    • 添加商品
    • 完善预定商品信息
    • 选择付款
    • 移除商品
  • 支付
    • 选择支付账户
      • 调用外部API
    • 完善账户信息

因此我们可以作出用例图如下:

ALB1DH.png

给出上述用例的活动图

####上例的活动图如下图所示：

ALBMvD.png

补充一些关于活动图的概念：

  1. 系统（System）：图中的大方框，表示系统（程序）或者是子系统（部件），里面包含外部可见的功能。上例中指的就是酒店订房系统。

  2. 开始点（Initial）：系统中最上方的实心点，标志着工作流的开始。

  3. 活动状态图（Activity）：圆角方框，表示一个活动，可以分解成其他子活动或者动作状态。例如找酒店、下订单等。

  4. 动作状态（Actions）：圆角方框，表示一个动作，是原子的、不可中断的动作，是构造活动图的最小单位。此动作完成后通过完成转换转向另一个状态。

  5. 动作流（Control Flow）：动作之间的转换称之为动作流，活动图的转换用带箭头的直线表示，箭头的方向指向转入的方向。

  6. 分支与合并（Decision and Merge Nodes）：菱形，表示当前的步骤具有多个选择和多个后继动作；也可以表示多个动作具有同一个后继动作。例如，选好房型后，可以进入进一步的确认，也可以返回修改成其它房型。

  7. 分叉与汇合（Fork and Join Nodes）：粗线表示，对象在运行时可能会存在两个或多个并发运行的控制流，为了对并发的控制流建模，UML中引入了分叉与汇合的概念。分叉用于将动作流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。例如，查找酒店的方法不止一种，可以搜索栏搜索，也可以查表搜索。但找到酒店后都会进入选择房型的动作。

  8. 终止节点（Final Node）

    • 活动终止节点(activity final nods),图中中心为实心点的同心圆，标志着整个活动的结束。
    • 流程终止节点(flow final nods)，中心为“X”的圆，标志着子流程的结束。

##2、根据课程练习“投递员使用投递箱给收件人快递包裹”的业务场景

  • 分别用多泳道图建模三个场景的业务过程
  • 根据上述流程，给出快递柜系统最终的用例图模型
    • 用正常色彩表示第一个业务流程反映的用例
    • 用绿色背景表述第二个业务场景添加或修改的用例，以及支持 Actor
    • 用黄色背景表述第三个业务场景添加或修改的用例，以及支持 Actor

场景1：x科技公司发明了投递柜，它们自建了投递柜以及远程控制系统。注册的投递员在推广期免费使用投递柜。由于缺乏资源，仅能使用y移动平台向客户发送短信通知。

  • 职能部门：投递柜及OS（x公司）、投递员、移动平台、客户
  • 工作流程：
    1. 投递员（注册并）登陆系统
    2. 投递员投递快递到投递柜
    3. 投递柜存储快件
    4. 移动平台检测快递信息，向客户发送短信通知
    5. 客户收到短信并取件

泳道图如下:

ALBKgO.png

场景2：随着产品推广，x公司与各大快递z公司达成协议。x公司在快递柜上添加了二维码扫描装置，z公司的快递员不仅可在快递柜上登陆（由z公司提供认证服务），且可扫描快递单号，投递入柜后自动由z公司发短信给客户。客户取件后，自动发送给z公司投递完成。

  • 职能部门：投递柜及OS（x公司）、快递员、z公司（认证&短信）、客户
  • 工作流程：
    • 投递员登陆系统
    • 投递员扫描快递号投递
    • 投递柜存储快件
    • z公司检测到快递入柜，发短信通知客户
    • 客户收到信息并取件
    • 取件完成后快递柜系统通知z公司投递完成

泳道图如下:

ALBnC6.png

场景3如下：x公司进一步优化服务，开发了微信小程序实现扫码取快递。如果用户关注了该公司公众号，直接通过过公众号推送给用户取件码等信息。不再发送短信。

  • 职能部门：投递柜及OS（x公司）、快递员、z公司（认证）、客户、微信小程序（公众号）
  • 工作流程：
    • 投递员登陆系统
    • 投递员扫描快递号投递
    • 投递柜存储快件
    • z公司检测到快递入柜，公众号/短信通知客户
    • 客户收到公众号消息/短信，微信小程序扫码取快递
    • 取件完成后快递柜系统通知z公司投递完成

泳道图如下:

ALBu8K.png

根据上述流程，给出快递柜系统最终的用例图模型

  • 用正常色彩表示第一个业务流程反映的用例
  • 用绿色背景表述第二个业务场景添加或修改的用例，以及支持 Actor
  • 用黄色背景表述第三个业务场景添加或修改的用例，以及支持 Actor

用例图如下:

ALBlKe.png

本文标题:系统分析与设计—hw5

文章作者:yezo13

发布时间:2019年04月13日 - 14时49分

最后更新:2019年04月13日 - 18时01分

原始链接:http://yoursite.com/2019/04/13/swsadHw/swsadhw5/

许可协议: "署名-非商用-相同方式共享 3.0" 转载请保留原文链接及作者。

文章目录
  1. 1. 绘制订旅馆的用例图模型
    1. 1.1. 因此我们可以作出用例图如下:
  2. 2. 给出上述用例的活动图
    1. 2.1. 补充一些关于活动图的概念：
  3. 3. 场景1：x科技公司发明了投递柜，它们自建了投递柜以及远程控制系统。注册的投递员在推广期免费使用投递柜。由于缺乏资源，仅能使用y移动平台向客户发送短信通知。
    1. 3.1. 泳道图如下:
  4. 4. 场景2：随着产品推广，x公司与各大快递z公司达成协议。x公司在快递柜上添加了二维码扫描装置，z公司的快递员不仅可在快递柜上登陆（由z公司提供认证服务），且可扫描快递单号，投递入柜后自动由z公司发短信给客户。客户取件后，自动发送给z公司投递完成。
    1. 4.1. 泳道图如下:
  5. 5. 场景3如下：x公司进一步优化服务，开发了微信小程序实现扫码取快递。如果用户关注了该公司公众号，直接通过过公众号推送给用户取件码等信息。不再发送短信。
    1. 5.1. 泳道图如下:
  6. 6. 根据上述流程，给出快递柜系统最终的用例图模型
    1. 6.1. 用例图如下: