1 设计目的和任务

该项目旨在开发一个简单的网上交易系统，以便于用户进行商品购买和商家发布商品，模仿知名电商平台如淘宝。通过该系统，用户能够快速方便地找到和购买自己感兴趣的商品，同时为商家提供一个易于管理和发布商品的平台。系统的设计将提高交易效率，简化购物流程，满足用户和商家的基本需求。

2 团队分工与所承担任务的描述

3 开发环境

3.1 硬件环境

一台 PC 台式机或是便携式电脑

3.2 软件环境

Windows10 及以上系统

IBM Rational Rose 2007

4 设计题目

4.1 题目名称

网上交易系统

4.2 题目详细描述

4.2.1 产品类别维护

（1）功能描述：系统需要支持管理员管理商品类别，商品的类别信息是后续发布商品时的基础数据。

（2）管理员功能：

创建、编辑、删除产品类别。

每个类别可以包含多个子类，支持层级化的类别管理。

删除某个类别前，若类别下已有商品，需要先处理商品的关联信息（如移动到其他类别或下架）。

4.2.2 用户注册

（1）功能描述：允许网民通过注册成为用户，分为消费者和商家两类角色。

（2）普通用户注册：

用户通过填写用户名、密码、邮箱等基本信息进行注册。

注册成功后，用户立刻拥有购买商品的权限。

（3）商家申请：

用户如果想成为商家，需要向系统提出申请，填写店铺名称、描述等信息，申请提交后由管理员进行审核。

管理员可以通过或拒绝商家的申请，通过后用户获得发布商品的权限。

4.2.3 商品发布

（1）功能描述：审核通过的商家可以发布商品，填写商品详细信息。

（2）商家功能：

发布商品时，需填写商品名称、类别、价格、库存、描述等信息，并支持上传商品图片。

商品可以设置为上架或下架状态。

商家可以编辑已发布商品的信息，包括修改价格、更新库存或图片。

4.2.4商品购买

（1）功能描述：普通用户可以在系统中浏览商品并直接购买，简化了支付及购物车功能。

（2）商品浏览：

用户可以通过类别筛选或关键字搜索商品。

点击商品后，查看商品详细信息页面，包含图片、描述、价格等。

（3）立即购买：

用户可以点击“立即购买”按钮，下单购买商品。

订单生成后，用户可以在个人中心查看订单状态（如待发货、已发货等）。

4.2.5 商品发货

（1）功能描述：商家在后台查看用户订单并进行发货操作。

（2）商家功能：

商家可以在后台查看所有订单的详细信息，包括购买的商品、买家信息、收货地址等。

当商家准备发货时，更新订单状态为“已发货”，并可以填写物流单号等发货信息。

4.2.6 收货确认

（1）功能描述：用户收到商品后，需要确认收货，完成订单流程。

（2）用户功能：

用户收到商品后，进入个人中心的订单管理页面，点击“确认收货”。

确认收货后，订单状态更新为“已收货”，交易完成。

4.2.7 销售统计

（1）功能描述：系统需提供销售统计功能，供管理员和商家查看某段时间内的销售情况。

（2）统计维度：

系统可以统计某个时间段内的总销售金额。

按商品类别统计销售额，即各类商品的销售总金额。

按商家统计销售额，即每个商家的销售总金额及订单数量。

（3）数据展示：

支持按时间段筛选统计数据，导出统计结果（如Excel或CSV格式）。

系统角色划分：

管理员：负责管理商品类别、审批商家申请、查看系统销售数据。

普通用户（消费者）：可以浏览商品、下订单购买、查看订单状态、确认收货。

商家：可以发布、编辑和管理商品，查看用户订单并发货，查看自己的销售统计数据。

系统设计要求：

用户注册、商品发布及购买等基本功能需要简洁高效。

系统不涉及复杂的支付和物流跟踪功能，主要聚焦于订单生成、发货确认及基础的销售统计功能。

界面友好，适合普通用户与商家操作。

4.3 功能要求

本系统主要六大功能模块。

4.3.1 产品类别维护模块

类别创建：

管理员可以在后台创建新的产品类别，每个类别需要输入类别名称和描述。

创建类别时可以选择该类别是否允许子类别，并设置层级。

类别编辑：

管理员可以编辑现有类别的名称和描述，或将某个类别移动到另一个父类别下。

类别删除：

管理员可以删除不再需要的类别，但若该类别下存在商品或子类别，则需先处理后续关联数据。

子类别管理：

支持多层级的子类别结构，每个子类别可以独立管理，管理员可以为某个类别添加或移除子类别。

4.3.2 用户管理模块

用户注册与登录：

网民通过注册页面输入用户名、密码、邮箱等信息，注册成功后系统生成用户账号。系统提供忘记密码和账户恢复功能，通过用户邮箱进行密码重置。

用户权限管理：

普通注册用户拥有商品浏览、购买功能。

用户可以申请商家资格，申请后用户状态变为“待审核”，由管理员在后台审核处理。

管理员可以审批用户的商家申请，审批通过后用户权限升级为商家，拥有商品发布及管理功能。

用户信息管理：

用户可以登录系统后查看和修改个人信息，如用户名、密码、地址等。

商家可以额外管理店铺信息，如店铺名称、店铺描述、联系方式等。

4.3.3 商品发布模块

商品发布：

商家可以在后台通过商品发布界面添加新商品，填写商品名称、类别、价格、库存、商品描述、上传商品图片等信息。商品类别从系统已创建的类别中选择。商家可以选择商品的状态（如上架、下架、草稿）。

商品编辑：

商家可以编辑已发布商品的信息，修改价格、库存等，或更新商品图片。

商品上下架：

商家可以将商品设置为下架状态，用户将无法购买已下架的商品。

商家可以重新上架商品，使其重新出现在商品列表中。

4.3.4 商品浏览与购买模块

商品搜索与筛选：

用户可以通过关键字搜索商品，或根据类别进行筛选。

提供价格区间、类别、商品发布时间等多条件筛选功能。

商品详情查看：

点击商品后，用户可以查看商品详情页面，显示商品图片、价格、描述、库存等信息。

系统展示商品的发布商家信息，并提供联系商家的渠道（如联系方式或私信功能）。

商品购买流程：

用户选择商品后，点击购买按钮进入订单确认页面。

在订单确认页面，用户可以查看商品信息、选择收货地址并确认订单。

点击确认后，系统生成订单，订单状态为“待发货”。

4.3.5 订单管理模块

订单生成与查看：

用户下单后，系统生成订单，包括商品信息、购买数量、商家信息、收货地址和订单状态。

用户可以在个人账户中的订单历史页面查看所有订单状态，如“待发货”、“已发货”、“已收货”。

订单处理与发货：

商家可以在后台查看所有用户订单，并根据订单信息进行处理。

商家处理订单时，可以更新订单状态为“已发货”，并记录物流信息（如快递单号）。

确认收货：

用户收到商品后，可以在订单页面点击“确认收货”，将订单状态更新为“已收货”。系统支持订单完成后的自动评价功能，允许用户对商品进行评价或反馈。

订单状态更新：

系统支持多种订单状态：待发货、已发货、已收货、已取消等，用户和商家可以实时查看订单状态的变化。

4.3.6 销售统计模块

销售总金额统计：

系统后台可以按时间段统计平台的总销售金额，管理员可以自定义时间段进行查询（如每日、每周、每月等）。

类别销售统计：

系统可以统计不同商品类别下的销售金额，包括各类别商品的销售总额和销售数量。提供按时间段筛选功能，管理员可以查询某个时间段内不同类别的销售数据。

商家销售统计：

系统为管理员提供商家销售额的统计功能，统计每个商家在特定时间段内的销售总额、订单数量和平均订单金额。

数据导出：

支持将销售统计数据导出为Excel或CSV格式，方便管理员进行进一步的数据分析。

4.3.7 其他功能

系统日志：

系统记录重要的操作日志，包括管理员的类别管理、用户的注册、商家的商品发布和订单状态变更等，方便后期维护和审计。

消息通知：

系统向用户发送关键操作通知（如订单状态变更、商品发货等），通过站内信、邮件等形式提醒用户操作。

5 设计

5.1 用例图

本系统是一个餐厅订餐系统，主要功能是为餐厅提供订餐记录和维护功能，同时 扩展了订菜和定时提醒的功能。

下面使用了用例图的方式表现了整个系统的所有功能。

用例名：Publish product information(发布商品信息)

角色：Merchant

描述：

1、 商家在页面上设置好商品名称和价格

2、 商家上传商品图片

3、 商家根据规定设置商品类别

用例名：Approval(审批)

角色：Admin

描述：

1、 网民登录后发送请求“申请成为商家”

2、 管理员接收申请信息

3、 管理员对该内容进行审批

4、 如果审批“通过”，网民成为商家

5、 如果审批“失败”，仍维持网民身份

用例名：Modify order status(修改订单状态)

角色：User，Merchant

描述：

1、 商家查看订单后发货

2、 发货后可修改订单状态

3、 网民收货后查看商品

4、 网民“确认”收货后修改订单状态

用例名：Ship product(发货)

角色：Merchant

描述

1. 网民付款后生成订单
2. 商家查看订单后发货并修改订单状态

用例名：Place orders(下订单)

角色：User

描述：

1. 网民浏览商品
2. 将喜欢的商品加入购物车
3. 网民付款后生成订单
4. 商家可以查看订单

用例名：Request Merchant Approval(申请成为商家)

角色：User

描述：

1、 网民登录后发送请求“申请成为商家”

2、 生成请求发送给管理员

3、 审批“通过”，网民成为商家

4、 审批“不通过”仍维持网民身份

用例名：Maintain category(维护产品类别)

角色：Admin

描述：

1、 管理员产看类别标签是否合适

2、 如果“不合适”，修改标签，将更新后内容保存至数据库

用例名：View order(查看订单)

角色：Merchant

描述：

1. 网民付款成功后生成订单

2、 商家产看订单信息

用例名：Statistical amount(统计金额)

角色：Time Period

描述：

1、 系统进行条件筛选

2、 根据条件筛选统计销售金额

图 5-1 系统用例图

5.2 类图

在类图中类用矩形框来表示，它的属性和操作分别列在分格中。如不需要表达详 细信息时，分格可以省略。一个类可能出现在好几个图中。同一个类的属性和操作可 只在一种图中列出，在其它图中可省略。关系用类框之间的连线来表示，不同的关系 用连线上和连线端头处的修饰符来区别。

5.3 活动图

UML 中的活动图用于描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。活动图实际上就是用来为用例的事件流建模的工具。

图 5-3-1 产品类别维护

图 5-3-1 产品类别维护细化

图5-4 用户申请成为商家

图5-5 用户注册

。。。

详情可以下载，转存图片失败

5.4 顺序图

顺序图表示了对象之间传送消息的时间顺序。每一个类元角色用一条生命线来表示，即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。顺序图可以用来进行一个场景说明——即一个事务的历史过程。顺序图的一个用途是用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。

5.4.1 商家发布商品

商家可以在系统中发布商品。

图5-13 商家发布商品顺序图

5.4.2 商家修改商品

商家可以对已经发布的商品信息进行修改。

图5-4 商家修改商品信息顺序图

。。。

5.6 通信图

通信图和顺序图都可以表示各对象间的交互关系，但它们的侧重点不同。顺序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的。通信图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。在实际中可以根据需要选用这两种图。

一个通信图描述了系统中为实现某些服务所涉及的对象扮演的角色及其相互之间的交互。通信图着重于有协作关系的对象之间的交互和链接（指对象实例之间的物理或概念上的链接，一个链接是某关联的一个实例）。它可用于图示系统中的操作执行、用例执行或一个简单的交互场景。通信图描述了对象及其之间的链接，还描述了链接的对象之间如何发送消息。

5.6.1 商家发布商品

商家可以在系统中发布商品。

图5-20 商家发布商品通信图

5.6.2 商家修改商品

商家可以对已经发布的商品信息进行修改。

图5-21 商家修改商品信息通信图

5.6.3修改订单状态

网民在收到商品后可修改订单状态：

图5-22 网民收货确认通信图

5.8 部署图

部署视图表示运行时的计算资源（如计算机及它们之间的连接）的物理布置。这 些运行资源被称作节点。在运行时，节点包含构件和对象。构件和对象的分配可以是静态的，它们也可以在节点间迁移。如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。

节点是某些计算资源的物理对象，包括计算机、外部设备等。节点可被看作类型，也可看作实例。节点与节点之间是通过物理连接发生关联，以便从硬件方面保证系统各节点之间的协同运行。

餐厅订餐系统的部署图描述如下：

节点：普通 PC 机和移动 PC 机作为终端设备， 1 台应用程序服务器，和多台 Web服务器。

节点属性

该系统各节点计算机的性能指标

节点之间联系

客户机节点是简单通信联系，采用 TCP/IP 通信协议；客户通过 Internet与 Web服务器相连接，利用浏览器进行查询。

图5-37部署图

7. 设计总结

在完成上机作业之后，再去做大作业确实感觉轻松了许多，因为通过上机作业能够更好地掌握系统设计的基础。但对于我来说，最困难的部分依然是业务分析。由于经验不足，在分析业务时经常会陷入思维的误区，感觉自己绕了很多弯路。不过幸运的是，在老师和小组成员的帮助下，我逐渐理清了思路，最终能够有条理地进行设计和绘图。

工作内容总结：

从用户交互层面入手，我根据大家在5.1讨论中共同设计的用例图，分析了系统的核心功能和不同用户的行为模式。用例图不仅帮助我们明确了用户需求，还为系统功能的合理分配提供了清晰的框架，确保每个功能模块都能符合用户期望。

在此基础上，我结合面向对象的设计理念，选择了商家相关的行为进行顺序图和用例图的设计工作。同时，我也设计了用户相关的交互流程。通过这些图表，不仅细致地分析了用户和商家如何在系统中完成操作，还具体化了对象之间的消息传递和时间顺序，确保了业务逻辑的可行性和操作的效率。

除了图表设计，我还投入了时间在文档撰写和排版上，确保各类设计图（如用例图、类图、顺序图、通信图）的内容准确且易于理解。这不仅提升了设计的可读性，也帮助团队其他成员能够快速理解每个功能模块的设计细节和逻辑结构。在文档排版中，我特别关注了细节，确保排版简洁清晰，方便后续开发人员在实施过程中保持一致性。

通过这种有条理的文档撰写与团队协作方式，我们有效减少了沟通中的误解和重复讨论的时间，大大提升了项目的开发效率。总体来说，虽然遇到了一些业务分析的困难，但在团队合作与老师的指导下，我逐渐掌握了设计技巧，并且完成了多个关键部分的设计工作。