一、项目背景与目标
本项目为软件工程课程期末大作业，设计并实现了一个“物品复活系统”。所谓“物品复活”，是指将个人闲置但仍具有使用价值的物品进行信息发布、查询和流转，从而促进资源再利用。系统面向两类用户：普通用户与管理员，支持用户注册、物品管理以及管理员对物品类别的统一管理，并通过图形化界面提升系统的易用性。
项目的主要目标包括：
按照软件工程方法完成系统需求分析、设计与实现；
使用 UML 建模工具描述系统结构与行为；
将理论知识（如用例模型、顺序图、类图）应用到具体系统中。
二、需求分析与用例建模体会
在需求分析阶段，我首先从“用户能做什么”出发，抽象出系统的核心用例，包括用户注册、登录、添加物品、查看物品、查看个人物品、删除物品和购买物品等功能。同时，根据加分需求，引入管理员角色，用于管理物品类别。
在绘制用例图时，我逐渐意识到用例图并不是功能罗列表，而是从用户视角描述系统边界内可提供的服务。因此，在建模过程中，我避免过度细化操作步骤（如“填写表单”“点击按钮”），而是聚焦于具有业务意义的用例，并通过 include 和 extend 表达用例之间的复用与扩展关系，例如：
“查看我的物品”包含“查看物品”这一通用功能；
“购买物品”作为对“查看物品”的扩展行为。
这一过程让我对用例建模的抽象层次有了更清晰的认识。
三、顺序图设计的理解
顺序图用于描述系统在运行时对象之间的交互过程。在本项目中，我选择以“添加物品”“管理员新增物品类别”等典型用例作为顺序图示例。
通过绘制顺序图，我发现它在很大程度上起到了“连接需求与实现”的桥梁作用。一方面，顺序图严格对应某一个用例；另一方面，它迫使我思考系统内部对象的职责划分，例如用户对象、界面对象、控制对象以及数据对象之间的协作关系。这一过程也为后续类图设计提供了重要依据。
四、类图建模与设计反思
在类图设计中，我重点对以下几类关系进行了建模：
继承关系
使用继承描述用户角色的差异，例如 Admin 和 NormalUser 继承自 User，体现了“管理员也是用户”的 is-a 关系。
关联关系（Association）
用于描述长期存在的业务关系，例如用户与物品之间的“一对多”关系，以及管理员与物品类别之间的管理关系。
组合关系（Composition）
在物品与物品属性之间采用组合关系，表示属性依附于物品存在，物品删除后其属性也随之消失。这一设计使系统能够支持不同类别物品的动态属性扩展。
通过类图建模，我逐渐理解到 UML 不仅是画图工具，更是一种帮助理清系统结构和约束的思维方式。
五、GUI 与系统实现体会
在系统实现阶段，我为主要功能设计了图形化界面，使用户可以通过直观的操作完成物品添加、查询等任务。GUI 的引入让我意识到，良好的用户体验同样是软件工程的重要组成部分，功能正确并不等同于“好用”。
同时，在实现过程中，我多次回到 UML 图对照代码结构，这种“设计—实现—验证”的循环过程，显著降低了代码结构混乱的风险。
六、对软件工程方法的认识与收获
通过本次物品复活系统的开发，我对软件工程课程中的多个核心概念有了更深刻的理解：
UML 图并非形式化作业，而是服务于系统理解与沟通；
不同模型关注系统的不同视角，用例图关注需求，顺序图关注行为，类图关注结构；
合理的建模能够在实现前暴露设计问题，减少后期返工成本。
总体而言，本项目不仅锻炼了我的建模与设计能力，也让我对“如何从需求出发构建一个可实现的软件系统”有了更加系统的认识。
七、不足与改进方向
受时间和经验限制，本系统在功能完整性和异常处理方面仍有提升空间。例如：
用户权限控制可以更加细化；
物品搜索与分类机制可以进一步优化；
系统架构在扩展性方面仍有改进余地。
未来可以在此基础上引入更完善的架构设计模式和持久化方案，使系统更加健壮和易扩展。