UML建模案例分析-会员下订单的时序图

目录

概要

需求

分析

时序图


概要

"交互序列图(sequence diagram) 也称顺序图,捕捉一段时间范围内多个对象之间的交互信息,强调消息交互的时间顺序,将一个用例详细的记录出来。用于处理行为较为简单的用例。"

描述的内容近乎代码实现。

需求

一个电子商务系统,会员可通过电子商务系统购买零件。具体功能需求如下:

会员请求结账时,系统验证会员的账户是否处于登录状态;系统验证订单是否完整以及各零件库存是否充足;最后,系统合计订单总价(订单总价=所有订单项价钱合计+税金+运费);

分析

这一次交互从请求结账开始,用MVC架构的话,需要界面类和控制器类,但这两个类不是重点,重点是实体类之间的交互;

结算之前要进行三种验证;

系统没说什么时候下的订单,所以默认订单已经下完,不用再考虑下单的交互过程;

时序图

有几个要点:

  • 需求说检查订单完整性和检查库存,主语都是系统,所以这里有个变数,按上图是从界面主动发起两个检查动作。如果界面设计要求是全部自动地进行这两项检查,则5号消息和7号消息要合并到3号消息之下,如下图所示。

控制焦点连在一起成为一个控制焦点,3、5、7号消息都要写在一个函数里。相应地代码:

结账控制::检查()

{会员.检查账户状态();

订单.检查订单完整性();

订单.检查库存();

}

  • 如果上图控制焦点是断开的,如下图所示,程序员开发的时候,需要写一个独立的函数完成两个检查功能。但是这个独立的函数缺少一个消息触发来源,所以可以考虑在控制器里增加一个自反消息。

相应地代码:

结账控制::检查()

{会员.检查账户状态();}

结账控制::订单检查()

{订单.检查订单完整性();

订单.检查库存();

}

写代码时,倾向于分开,因为以后需要重用。但建模时,这个新增的订单检查消息建议省略。原因是:建模的目的是描述事物的主要特征,而不是全部内容,模型太繁琐失去可读性,也就失去了它用于沟通的属性。

  • 33
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值