案例——在线购物.pptVIP

可视化建模与UML ——综合案例 综合案例——在线购物 在线购物—用例建模 综合案例——在线购物 在线购物—参与者 综合案例——在线购物 综合案例——在线购物 在线购物—用例 综合案例——在线购物 在线购物—用例图 综合案例——在线购物 为用例编写文档 简述 涉及的参与者 用例开始的前提条件 事件流的详细描述 事件的主流 事件的子流 定义例外情景的替换流 定义系统在用例结束后的后置条件 综合案例——在线购物 在线购物—活动建模 综合案例——在线购物 在线购物—活动 综合案例——在线购物 在线购物—活动图 在线购物—类建模 综合案例——在线购物 综合案例——在线购物 在线购物—实体类 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 在线购物—交互建模 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 综合案例——在线购物 分析：第十一步 参照以前分析的步骤，考虑25页和29页幻灯片的模型，想一想你如何在现存的类中抽取公共属性到更高层次的类上，在这个类模型中增加泛化。 分析：第十二步 参照以前分析的步骤，考虑25页和31页幻灯片的模型，来显示一个完整的类图，通过层次化的引入，是累得属性的内容成为是必要的。 分析：第十三步 参照以前分析的活动模型(第六步)，考虑图中的第一步，Display Current Configuration， 为该步构造一个序列图。 活动 Display Current Configuration 的序列图 分析：第十四步 参照以前分析的类图和序列图，对于序列图中的每条交互消息，在类图中相关的类上增加操作。不要画出完整的类图，只显示用操作扩展了的类。 分析：第十五步 参照活动图并为它构造序列图，为了简化这个序列图，不需要显示Computer和ConfigurationItem对象之间的消息交换。 还有，不需要可视化子类对象：假设一个Computer对象要么使StandardComputer, 要么是ConfiguredComputer. 只显示消息的激活。消息的返回是隐式的，不需要指出操作参数或其他控制信息。 活动Order Configured Computer 序列图 分析：第十六步 考虑在县购物应用中的类Invoice。我们从用例模型中已知，在填好购买表格并提交给供货商品后，客户要声明一种付款方式。然而，用例模型没有指明与该订单准备的发票相关的付款在什么时候能收到。 从类模型中我们知道，订单的发票是由销售人员准备的，但他总是要交给仓库的，仓库将发票和计算机一起送给客户。将发票的付款情况维护在系统中以使得发票能够恰当地注释是重要的。 画出捕获可能的发票状态以及能设计付款情况的状态图。 类Invoice的状态和事件 分析：第十七步 参照以前分析的各步，考虑这个在线购物应用中的类Order。想一想Order可以有的状态——从它提交给系统开始，一直到它完成。 考虑一个订购的计算机可以在库存中，它可能需要单独配置以满足你的需求。你还可以制定在将来的某个日期你想要收到这台计算机，即使计算机已经在库存中。 你允许在计算机运送给你之前取消你的预定。你不需要考虑任何由于取消迟了而带来的惩罚。 给类Order画一个状态图。 类Order 的状态图 * * * 问题陈述： 一个计算机制造厂商提供了通过因特网购买计算机的可能性，客户可以在制造厂商的Web叶面上选择一台计算机，计算机分为服务器、台式机和笔记本。客户可以选择标准配置，或者可以在线建立自己希望的配置。可配置的构件（如内存）显示在一个可供选择的表中。对每个新的配置，系统可以计算价格。 要发出订单，客户必须添上运送和付款信息，可接收的付款方式为信用卡和支票，一旦订单被输入，系统向客户发送一个确认e-mail 消息，并附上订单的细节，在等待计算机送到的时候，客户可以在任何时候在线查到订单的状态。 后端订单处理包含下面所需的步骤： 验证客户的信任度和付款方式 向仓库请求所订购的配置 打印发票并且请求仓库将计算机运送给客户 分析：第一步 参照上述问题陈述并考虑如下扩展的需求来发展在线购物应用中的参与者 1. 客户使用制造厂商的Web页面来查看所选择的服务器、台式机或笔记本的标准配置，价钱也同时显示出来。 2. 客户选择察看配置的细节，也许带有购