标签:原因 描述 log 完成 es2017 组成 方法 目标 探讨
1. 小组成员及分工:
陈锋, 刘鑫 (用户故事的细化,即功能设计)
高忠杰, 罗成龙 (参与系统的类图设计及上台汇报)
颜贵荣, 李清灿 (参与用户故事的讨论与设计)
王绍华, 丁天奇, 林伟领(参与系统的类图设计并选定课题)
2.选题讨论
本次选题为电商系统的购物车模块, 其原因在于小组绝大部分成员均使用过电商系统的购物车模块, 对其基本功能有一定了解。
其次, 小组成员一致认为选择购物车作为讨论的模块, 其功能上存在一定复杂性, 有助于我们深入探讨。
3.用户故事讨论
背景: 解决用户一次购买多个商品的需求
描述:用户登入电商系统购买商品时想要购买多个商品, 此时若商品仅支持单个程度上的支付, 会给用户造成不必要的麻烦。
类比超市, 购物时会有购物车作为存放购买的商品的容器, 因此这边在电商系统中也需要引进购物车。
目标:为用户提供一个个人预购买的商品管理中心, 不仅能提高用户的体验, 而且能利用消费者囤货心态来间接增加系统的交易量。
4.功能分析讨论
1.用户浏览商品时发现有想购买的商品可通过点击加入购物车。
2.用户点击我的购物车跳转到购物车模块。
3.用户可点击删除将商品移出购物车。
4.用户可点击可点击商品分类对购物车商品进行过滤, 如点击全部商品则显示全部商品, 点击降价商品则显示所有降价商品。
5.用户可以通过点击全选或者对商进行勾选来选择实际想要购买的商品, 此时界面会实时显示出用户已勾选商品的总价格。
6.用户可点击结算按钮对勾选商品进行结算。
7.用户可在商品操作选项中点击对比来展示相似商品。
5.建模
仅考虑购物车功能正常运作下的初步类图
6.总结
由于使用软件工程规范化分析功能模块的经验不足, 小组成员在就购物车模块的类图设计上产生了不少意见分歧。一部分认为类图所涉及的实体应该尽量简化,即只涵盖与购物车有相关联系的实体即可, 其对象的方法也就要列出使购物车功能正常运作的即可。 拿上面的类图为例, 王经理在上课提到了用户应该再细分, 因为不同用户对商品的操作可能不同, 可个人认为只在考虑购物车功能模块正常运作的前提下, 为用户细分类型实际上会增加复杂度, 多类用户为完成购物车的功能流程上实际上扮演的角色是一致的, 即都以买家的身份去购买东西, 因此上述的用户可以理解为买家。另一部分小组成员认为应该将所有隐含而且与其有联系的对象也包含在类图中, 例如订单等
130242014004-(2)-运用敏捷开发在<<电商某系统模块>>中的初步体验
标签:原因 描述 log 完成 es2017 组成 方法 目标 探讨
原文地址:http://www.cnblogs.com/tangiding/p/7625378.html