软件工程导论实验报告——商品管理系统（黑龙江大学）

面向对象分析与设计

实验一 软件需求分析

1.1 业务需求描述

该系统在商家和顾客之间搭建了一个桥梁，需要实现商家对商品的售卖和修改，以及顾客的购买商品需求，期间还需要实现对商品和商家的管理以及对顾客的评估和管理。系统本身还需要对商家和顾客的请求和投诉进行处理。

1.2 系统功能性需求分析

本系统包含三类核心参与者：顾客、商家和系统管理员，各自承担不同的职责，共同保障平台的正常运行与良好秩序。

顾客作为平台的使用者和消费者，能够自由浏览系统内所有已上架的商品，通过关键词搜索、分类筛选等方式快速找到所需商品，并查看其详细信息，包括价格、规格、库存、用户评价等。在确认购买意向后，顾客可将商品加入购物车或直接下单，选择合适的收货地址与支付方式完成交易。订单生成后，顾客可随时查看其状态，如待付款、待发货、已发货或已完成等。若收到的商品存在质量问题或与描述不符，且符合平台规定的退换货条件，顾客有权发起退货或换货申请。此外，顾客还可对自己的收货地址进行灵活管理，包括添加新地址、修改已有地址信息、设置默认地址或删除不再使用的地址，以满足不同场景下的配送需求。订单完成后，顾客还可对商品和商家服务进行评价，为其他用户提供参考，同时也能向平台反馈使用体验或提出建议。

商家是商品的提供者和销售主体，负责商品的上架、维护及订单履约。商家可在平台上发布新商品，填写完整的商品信息并提交审核；对于已上架的商品，可根据市场情况或库存变化调整售价、更新描述、更换图片或修改库存数量；当商品不再销售时，也可主动将其下架。在订单方面，商家需及时处理归属本店的订单，包括确认订单、安排发货、填写物流单号，并跟进物流状态。若顾客发起售后申请，商家需在规定时间内响应，审核退货理由并作出同意或拒绝的决定。此外，商家还能查看自身店铺的销售数据，如订单量、销售额、热销商品排行等，辅助其优化经营策略。同时，商家可通过站内信与顾客沟通，解答疑问、处理投诉，提升服务质量与用户满意度。

系统管理员则从平台整体运营和合规角度出发，承担监督、审核与治理职责。管理员负责审核新注册商家的资质，确保其具备合法经营资格；对商家提交的商品信息进行内容审查，防止违禁品、虚假宣传或侵权商品上架；若发现已上架商品存在问题，有权强制下架并视情节对商家进行处罚。在用户管理方面，管理员可对违规用户（包括恶意差评、刷单、欺诈等行为）采取警告、限制功能、冻结账户等措施。同时，管理员还负责处理各类投诉与纠纷，如顾客举报商品质量问题、商家投诉恶意退货等，通过调查核实后作出公正裁决。此外，管理员还需维护系统基础配置，如商品分类、物流模板、支付接口等，并监控平台运行状态与安全风险，确保系统稳定、数据安全与用户体验的持续优化。三类角色各司其职、相互配合，共同构建一个高效、可信、可持续发展的电商生态系统。

1.3用例分析

1.3.1 系统参与者

顾客：可以进行购货、退货、管理地址、投诉等操作。商家：可以进行商品的上架和下架操作，修改商品信息，处理订单等操作。系统管理员：可以对顾客和商家进行管理，审核商品和处理用户的投诉。

1.3.2 系统用例图

系统总用例图如图所示。

1.3.3 用例描述

1.3.3.1购买商品用例描述

1.3.3.2 投诉商家用例描述

1.3.3.3 上架商品用例描述

1.3.3.4 更新商品信息用例描述

1.3.3.5 审核上架商品用例描述

1.3.3.6 处理顾客投诉用例描述

1.4 用例活动图描述

1.4.1 购买商品用例活动图

1.4.2 投诉商家用例活动图

1.4.3 上架商品用例活动图

1.4.4 更新商品信息用例活动图

1.4.5 审核上架商品用例活动图

1.4.6 处理投诉用例活动图

1.5 系统非功能需求

1. 安全

恰当的安全策略，既让客户舒适的登陆，又要保证安全，数据加密、防止ddos攻击、sql注入式攻击等方式。

2. 异步

通过异步消息传递，将进行不同微结构之间传递，让数据分阶段处理，系统结构更清晰

3. 业务逻辑清晰

模块划分的功能单一，充分实现mvc的分离，单职责的模块可扩展性、可维护性都要强过复杂模块。

1.6本次实验小结

本次实验电商系统开展了全面的软件需求分析工作，从业务需求出发，明确了系统在连接商家与顾客之间的核心价值，并详细梳理了三类关键参与者——顾客、商家和系统管理员的功能性职责与交互场景。通过用例分析，识别出包括“购买商品”“投诉商家”“上架商品”“更新商品信息”“审核上架商品”和“处理顾客投诉”等核心用例，并对每个用例的主事件流与备选事件流进行了结构化描述，为后续系统设计奠定了坚实基础。同时，结合非功能性需求，强调了系统在安全性、异步处理能力以及业务逻辑清晰性等方面的技术要求，确保系统不仅功能完备，而且具备良好的可扩展性、可维护性与用户体验。本章内容为面向对象分析与设计提供了清晰的需求输入和建模依据。

实验二 领域模型

2.1 概念类分析

2.1.1购买商品用例概念类分析

主事件流：

1. 从系统查询商品显示到界面

2. 顾客选择所需商品

3. 从系统查询收货地址供顾客选择

4. 顾客选择收货地址

5. 顾客付款

6. 付款成功

7. 将顾客购物记录记录到系统

8. 修改商品结余数量

候选概念类：系统、商品、界面、顾客、收货地址、购物记录、结余数量

概念类：商品、顾客、购物记录

2.1.2投诉商家用例概念类分析

主事件流：

1. 商家查询系统中是否已含有该商品，查询结果为无

2. 商家编辑商品信息

3. 商家添加商品图片

4. 商家设置价格

5. 商家提交上架申请

6. 将申请记录录入系统，等待管理员审核

候选概念类：系统、顾客、商家、投诉内容、照片、投诉记录

概念类：商品、顾客、投诉记录

2.1.3上架商品用例概念类分析

主事件流：

1. 在系统中输入商家查询该商家已经上架的商品

2. 商家在已上架的商品中选择需要修改的商品

3. 商家修改需要修改的信息

4. 商家提交更新申请

5. 系统自动审核更新的内容中是否含有违规信息

6. 若无违规信息，则将系统中该商品的信息修改保存

候选概念类：商家、系统、商品、查询结果、商品信息、价格、上架申请、申请记录、管理员

概念类：商家、商品信息、申请记录

2.1.4更新商品信息用例概念类分析

主事件流：

1. 在系统中输入商家查询该商家已经上架的商品

2. 商家在已上架的商品中选择需要修改的商品

3. 商家修改需要修改的信息

4. 商家提交更新申请

5. 系统自动审核更新的内容中是否含有违规信息

6. 若无违规信息，则将系统中该商品的信息修改保存

候选概念类：商家，系统，商品，更新申请

筛选后：更新申请，商家，商品

2.1.5审核上架商品用例概念类分析

主事件流：

1. 系统查询上架申请

2. 管理员选择一个提交的申请

3. 管理员该商品内容进行审核

4. 若无违规信息求产品合格，则管理员通过此申请

5. 商品记录保存到系统

6. 系统将申请结果返回给商家

候选概念类：上架申请，管理员，商品内容，商品记录，申请结果

筛选后：上架申请，管理员，商品

2.1.6 处理顾客投诉用例概念类分析

主事件流：

1. 从系统查询顾客投诉记录

2. 管理员查看用户提交的投诉信息并判断商家违规情况

3. 管理员根据违规情况对商家做相应的处罚

4. 将处罚记录存入系统

5. 将处理结果反馈给顾客

候选概念类：投诉记录，管理员，处罚记录，处理结果，处罚，违规情况，商家

筛选后：投诉记录，管理员，处罚记录，商家

2.2 领域模型（概念类图）

2.2.1 购买商品用例领域模型

2.2.2 投诉商家用例领域模型

2.2.3 上架商品用例领域模型

2.2.4 更新商品信息用例领域模型

2.2.5 审核上架商品用例领域模型

2.2.6 处理顾客投诉用例领域模型

2.3 系统领域模型

2.4 本次实验小结

本次实验围绕电商系统的核心业务用例，开展了系统的领域建模工作。通过对“购买商品”“投诉商家”“上架商品”“更新商品信息”“审核上架商品”以及“处理顾客投诉”六个关键用例进行深入的概念类分析，识别并提炼出与业务逻辑密切相关的概念类，如顾客、商家、商品、购物记录、投诉记录、上架申请、处罚记录等，并剔除了界面、系统等非领域核心的候选类，确保了模型的业务聚焦性与抽象合理性。在此基础上，初步构建了各用例对应的局部领域模型，并为后续整合形成统一的系统级领域模型奠定了基础。

实验三 软件设计

3.1 购买商品用例详细设计

3.1.1 购买商品用例顺序图

3.1.2 购买商品用例类图

3.2 投诉商家用例详细设计

3.2.1投诉商家用例顺序图

3.2.2 投诉商家用例类图

3.3 上架商品用例详细设计

3.3.1 上架商品用例顺序图

3.3.2 上架商品用例类图

3.4 更新商品信息用例详细设计

3.4.1 更新商品信息用例顺序图

3.4.2 更新商品信息用例类图

3.5 审核上架商品用例详细设计

3.5.1 审核上架商品用例顺序图

3.5.2 审核上架商品用例类图

3.6 处理顾客投诉用例详细设计

3.6.1 处理顾客投诉用例顺序图

3.6.2 处理顾客投诉用例类图

3.7 系统类图

3.8 本次实验小结

本次实验基于前期的需求分析与领域建模成果，对电商系统中的六个核心用例——“购买商品”“投诉商家”“上架商品”“更新商品信息”“审核上架商品”和“处理顾客投诉”——进行了详细的面向对象设计。通过绘制顺序图，清晰地刻画了各参与者与系统对象之间的交互流程与时序关系；通过构建用例级类图，明确了每个用例所涉及的关键类、属性、方法及其关联关系，体现了职责分配与封装原则。在此基础上，进一步整合各用例设计元素，形成了覆盖全系统的统一类图，实现了业务逻辑、数据结构与行为接口的有机统一。整个设计过程遵循高内聚低耦合、单一职责和关注点分离等面向对象设计原则，为后续的编码实现、测试与系统演化提供了清晰、可维护且可扩展的架构基础。

结构化分析与设计

实验四 商品管理系统需求分析

4.1 系统相关者

顾客、商家、系统管理员。

4.2 数据流分析

（1）顶层DFD

（2）功能层DFD如图4-2所示。

（3）细节层DFD

1. 购物细节层DFD

2. 顾客投诉细节层DFD

3. 审核申请细节层DFD

4. 更新商品信息细节层DFD

5. 上架商品细节层DFD

6. 处理投诉细节层DFD

4.3 数据字典

（1）数据项定义

表4-1 数据项“商品价格”的条目

表4-2 数据项“投诉内容”的条目

（2）数据流定义

表4-3 数据流“购物信息”的字典条目

表4-4 数据流“投诉信息”的字典条目

（3）数据存储

表4-5 数据存储“投诉申请表”的字典条目

表4-6 数据存储“商品表”的字典条目

4.4 加工逻辑

（1）加工1.2订单支付的加工逻辑

输入订单信息

根据订单信息中的用户id检索用户当前账户余额，检索订单信息中的订单总额

begin

如果余额大于订单总额则

支付成功，产生并保存购物清单

否则

支付失败，不保存当前订单

End

（2）加工6.1选择投诉的加工逻辑

输入投诉申请信息表

根据投诉申请表查看所有投诉申请记录

Begin

如果投诉申请表不为空则

选择其中一项；

对其进行处理；

将处理结果保存；

End

4.5 软件非功能需求

这部分内容根据系统的具体情况而定。在大多数的情况下，一般时段响应时间不超过1.5秒。严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。对输入有提示，数据有检查，防止数据异常。系统应支持IOS，Android，Windows操作系统。

4.6 本次实验小结

本次实验围绕商品管理系统进行了全面的需求分析，通过结构化分析方法，明确了系统相关者包括顾客、商家和系统管理员，并对系统的数据流进行了多层次的分析与设计，从顶层数据流图到功能层、细节层的数据流图，确保了各业务流程的清晰理解。此外，详细定义了数据字典中的数据项、数据流和数据存储，以及关键加工逻辑的设计，为后续软件开发提供了坚实的基础。同时，考虑到了非功能需求如响应时间、权限控制、输入提示及跨平台支持等，以确保系统的实用性、安全性和用户体验。通过这次实验，我们不仅细化了商品管理系统的具体需求，还提升了团队在系统分析与设计方面的能力，为项目的成功实施奠定了良好的基础。

实验五 商品管理系统设计

5.1 软件结构设计

将功能层数据流图化分边界，如图5-1所示。

图5-1划分边界的数据流图

按SD方法将数据流图转换为软件结构图，如图5-2所示。

图5-2 功能层的SC图

投诉层SC图画分边界的DFD如图5-3所示。

图5-3 化分边界的投诉层DFD

根据化分边界的DFD画出的SC图如图5-4所示。

图5-4 投诉层的SC图

购物层的SC图，这一层的数据流图为事务型，划分边界的DFD如图5-5所示。

图5-5 化分边界的购物层的DFD

根据划分边界的DFD画出的SC图如图5-6所示。

图5-6 购物层的SC图

审核上架商品的划分边界的DFD如图5-7所示。

图5-7 划分边界的审核上架商品层DFD

根据划分边界的DFD画出的SC图如图5-8所示。

图5-8 审核上架的SC图

更新商品信息划分边界的DFD如图5-9所示。

图5-9 划分边界的更新商品信息的DFD

根据划分边界的DFD画出的SC图如图5-10所示。

图5-10 更新商品信息SC图

申请上架商品划分边界的DFD如图5-11所示。

图5-11划分边界的申请上架商品DFD图

根据划分边界的DFD画出的SC图如图5-12所示。

图5-12 申请上架商品SC图

处理投诉划分边界的DFD如图5-13所示。

图5-13 划分边界的处理投诉DFD

图5-14 处理投诉SC图

5.2 详细设计-程序流程图

（1）支付程序流程图，如图5-15所示。

图5-15 购物程序流程图

（2）投诉程序流程图，如图5-16所示。

图5-16 投诉程序流程图

5.3 本次实验小结

本次实验通过将商品管理系统分解为多个功能层，并采用结构化设计（SD）方法，基于数据流图（DFD）完成了从高层抽象到详细软件结构图（SC图）的转换，具体包括功能层、投诉层、购物层、审核上架商品层、更新商品信息以及申请上架商品等多个层面的设计。这一过程不仅细化了各业务流程的数据处理逻辑和交互模式，还通过程序流程图进一步明确了关键操作如支付与投诉处理的具体实现步骤。整个设计强调了模块间的独立性和接口定义的清晰性，旨在提高系统的可维护性和扩展性。此外，通过对各个层次进行细致划分和深入分析，确保了系统设计的全面覆盖和深度探索，为后续的系统实现奠定了坚实的基础。同时，这样的设计方式也便于团队成员之间的沟通和协作，提高了项目的开发效率和质量。

​​若觉得有帮助，欢迎点赞关注，一起成长进步~
声明​​：本文仅供学习交流，禁作商用；禁篡改、歪曲及有偿传播，引用需标明来源。侵权必究。