用例建模-在线购物（四）

最新推荐文章于 2024-09-26 19:59:26 发布

ChaosMeta博客

最新推荐文章于 2024-09-26 19:59:26 发布

阅读量7.7k

点赞数 10

分类专栏：方法论

本文链接：https://blog.csdn.net/qq_35703848/article/details/102686882

版权

方法论专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一.问题描述

基于Web的“在线购物系统”中，客户可向供应商请求购买一件或多件商品。客户提供个人信息，例如地址和信用卡信息。这些信息被存储在客户账户中。如果信用卡是有效的，那么系统创建一个配送订单并且发给供应商。供应商检查可用的库存，确认订单，并且输入一个计划号的配送日期。当订单完成配送后，系统通知客户并且向客户的信用卡账户收费。

二.用例建模

2.1 浏览目录用例

概述：客户浏览万维网目录，从供应商的目录中查看各种各样的商品项，并且从目录中选择商品

参与者：客户

前置条件：客户的浏览器链接到供应商的目录网站

主序列：

1.客户请求浏览目录

2.系统向客户显示目录信息

3.客户从目录中选择商品

4.系统显示商品列表，包括商品描述、价格及总价

可替换序列：

步骤3：客户没有选择商品并且退出

后置条件：系统显示了所选择的商品列表

2.2 下单请求用例

用例名称：下单请求

概述：客户输入一个订单请求来购买目录商品。客户的信用卡被检查其有效性和是否有足够的额度来支付请求的目录商品

参与者：客户

前置条件：客户选择了一个或多个目录商品

主序列：

1.客户提供订单请求和客户账户ID来支付购买

2.系统检索客户账户信息，包括客户的信用卡详细信息

3.系统根据购买总额检查客户信用卡，如果通过，创建一个信用卡购买授权号码

4.系统创建一个配送订单，包括订单细节、客户ID和信用卡授权号码

5.系统确认批准购买，并向客户显示订单信息

可替换序列：

步骤2：如果客户没有账户，系统提示客户提供信息来创建一个新账户。客户可输入账户信息或取消订单

步骤3：如果客户的信用卡授权被拒绝（例如，无效的信用卡或客户的信用卡账户资金不足），系统提示客户输入一个不同的信用卡号码。客户可输入一个不同的信用卡号码或取消订单

后置条件：系统为客户创建了一个配送订单

2.3 处理配送订单用例

用例名称：处理配送订单

概述：供应商请求一个配送订单；系统确定库存对于满足订单是可用的，并且显示订单

参与者：供应商

前置条件：供应商需要处理一个配送订单并且一个配送订单存在

主序列：

1.供应商请求一个配送订单

2.系统检索并显示配送订单

3.供应商为配送订单请求商品库存检查

4.系统确定库存中的商品对于满足订单是可用的，并且保留这些商品

5.系统给供应商显示库存信息，并且确认商品被保留

可替换序列：

步骤4：如果库存不足，系统显示警告

后置条件：系统为配送订单保留了库存商品

2.4 确认配送和给客户开账单用例描述

用例名称：确认配送和给客户开账单

概述：供应商手工地准备配送并且确认配送订单已经准备好。系统通知客户订单正在配送。系统通过客户的信用卡收取购买商品的款项并且更新相关库存商品的库存

参与者：供应商

前置条件：库存商品已经为客户的配送订单进行了预留

主序列：

1.供应商手工地准备配送并且确认配送订单已经准备好配送

2.系统检索客户的账户信息，包括发货单和客户的信用卡细节

3.系统更新库存，确认购买

4.系统通过客户信用卡收取购买商品款项并且创建一个信用卡收费确认号码

5.系统用信用卡收费确认号码更新配送订单信息

6.系统给客户发送确认邮件

7.系统向供应商显示确认信息来完成配送订单的配送

后置条件：系统提交了库存，向客户收费，并且发送了确认信息

三.静态建模

软件系统上下文建模。
考虑外部类与系统之间的交互关系。
本例中外部类对应于用例图中的参与者，上下文图与用例图相似。

问题域的静态实体类建模：

客户类，包括“客户”、“客户账户”
供应商类，包括"供应商"、“库存”、“目录”
处理订单的类，例如“配送订单”

四.类和对象组织

没有一个统一的方式将一个系统分解为对象，因为做出这些决策都是基于分析员的判断和问题的特性！

上文确定的实体类可通过服务类的形式整合到面向服务的体系结构中

目录服务：使用了“目录”和“供应商”实体
客户账户服务：使用了“客户账户”和“客户”实体类
配送订单服务：使用了“配送订单”和“商品”实体类
库存服务：使用了“库存”实体类

还有一类服务类，不操作实体，但为其他类提供一种服务能力：

“信用卡服务”：处理信用卡的授权和付费
“电子邮件访问”：发送邮件

五.动态建模

对于每一个用例我们需要开发一个通信图，用于描述该用例的对象以及这些对象之间消息传递的顺序。

5.1 浏览目录

用户通过用户交互发出目录请求。
“客户协调者”被实例化来帮助客户。
“客户协调者”向目录服务请求信息。
“目录服务”发送目录给客户协调者。
“客户协调者”把信息转发给“客户交互”。
“客户交互”向客户显示目录信息。
客户通过“客户交互选择一个目录。
”客户交互“传递请求给”客户协调者“。
”客户协调者向”目录服务”请求目录选择。
“目录服务”确认目录商品的可用性并且发送商品价格给“客户协调者”。
“客户协调者”转发信息给“客户交互”。
“客户交互”向客户展示目录信息，包括商品价格和总价。

5.2 下单请求

5.3 处理配送订单

供应商请求一个新的配送订单。
“供应商间交互”向“供应商协调者”发送供应商请求。
“供应商协调者”请求“配送订单服务”选择一个配送订单。
“配送订单服务”发送配送订单给“供应商协调者”。
“供应商协调者管理者”请求检查商品库存。
“库存服务”返回商品信息。
“供应商协调者”发送订单信息给“供应商交互”。
“供应商交互”向供应商显示配送订单信息。
供应商请求系统在库存中保留商品。
“供应商交互”发送供应商的请求给“供应商协调者”保留库存。
“供应商协调者”请求“库存服务”来保留库存中的商品。
“库存服务向“供应商协调者”确认商品的保留。
”供应协调者“发送库存状态给”供应商交互“。
”供应商交互“向供应商显示库存信息。

5.4 确认配送和给客户开账单

5.5 查看订单

六.设计建模

6.1 分层软件体系结构

构建被组织到分层的体系结构中，使得每个构件处于依赖所处位置的下层而不是上层的构建层次。这种分层的体系结构便于在线购物软件体系结构在将来的适应性变化。用户交互层的用户交互构件只与协调者构建通信，而协调者构件与服务通信。可以按照如下分层：

服务层：信用卡服务、电子邮件服务属于“外部服务”其余服务为应用内部服务。

协调层：共3个协调者构件。

用户层：共有3个用户交互构件

6.2 体系结构通信模式

带回复消息的同步通信模式：当客户端需要服务的信息并且在接受响应之前不能继续执行的时候使用这个模式。该模式用于用户交互客户端和协调者之间，也可被用于协调者和各种服务之间。
代理者句柄：每个服务向代理者注册服务信息，包括服务名称、服务描述和位置。“代理者模式”允许客户查询代理者来确定它们应该连接的服务。
服务发现：“服务发现”模式被服务请求者使用来发现新的服务。
双向异步消息通信：被用于“供应商协调者”和“账单协调者”之间的双向异步通信。
两阶段提交：这个模式被用于确认库存、信用卡和配送订单的更新是原子的，即所有的提交不是被提交就是被终止。