实验三-电子公文传输系统-个人贡献

发布时间 2023-12-16 22:47:09作者: 20211309宁心宇

(一)简述你完成的工作

我的工作主要是项目整体结构的搭建设计,和公文系统功能的实现

一 mvc模式和服务实现逻辑链设计

在设计初期,我们确定好了分工和系统编写的基调。我认为电子公文系统中,可以采用MVC模式进行设计,得到了其他组员的支持,我们的分工也基本根据这个方式而来。其中我主要完成的是模型层的、以及控制器的一部分。
前后端分离:前后端分离是一种它将前端和后端的职责明确分开,前端负责展示和交互,后端负责数据处理和业务逻辑。这种设计方式有助于进行小组的分工。比如在后期代码更改时,负责前端的同学可以直接跟我进行沟通,确定整体设计的方式。

二 模型层:服务

数据处理
服务直接负责数据的存储、查询、更新和删除等操作。类似于上学期在web课程中完成的项目,这些操作通常与数据库或其他数据源进行交互。这部分我主要和数据库设计组建的同学共同完成。
业务逻辑实现
除了基本的数据操作,服务还实现了与业务相关的逻辑。例如,在电子公文系统中,可能有一个服务用于处理公文的流转逻辑,包括公文的创建、归档等,这部分功能基本由我进行设计和实现,同时还有伴随的异常处理系统等形式也由我实现。

三 工具类,实体类,验证码

对于这么一个大的系统,我认为工具类是很必要的。在我们的系统设计中我们导入了很多外部库,包含一系列静态方法,这些方法执行特定的、不依赖于对象状态的操作。外部库的导入是其他组员负责的,我主要进行了各种类的功能实现
例如,在本系统开发中,我对上传的公文文件处理进行了代码的编写,包括字符串操作等功能。在之后的部署和局域网访问中,我也借助相关的网络请求工具类完成了功能。
我们的登录中使用到了验证码的设计,用户需要识别并输入图像中显示的扭曲或混淆的文本。本来是打算使用阿里云的手机短信验证码的,不过感觉太复杂了就没有进行下去。
在功能实现中,我利用工具类设计了提供生成随机验证码的方法,并生成为图片展示给用户,验证用户输入的验证码是否正确的方法同时我也使用了相关的实体类,定义了验证码相关属性,如验证码字符串、过期时间,包括验证是否通过、错误信息等。这些功能和上面的工具类是并行的。

四 异常处理机制

在系统整体架构的设计中,我认为为了代码的健壮性,对各种异常进行检查和提示是非常重要的。

  1. 异常的处理方式
    在系统上层,我认为这些异常是需要捕获并处理的。比如在我同时期开展的课设项目中,主机扫描就经常遇到一些类似防火墙阻止的错误。在电子公文系统中,我定义了多种异常类型,如运行时异常、业务逻辑异常等。对于运行时的异常,如文件找不到、网络连接中断等。对于这类异常,我一般设计为直接抛出,由于它们是外部因素导致的,我只能直接抛出,让用户知道发生了什么错误然后自行解决。
    对于业务逻辑异常,这类异常是因为程序内部的业务逻辑错误导致。例如,当用户尝试创建一个已经存在的公文编号时,系统会抛出一个业务逻辑异常。对于这类异常,基本是需要进行特定的处理的。我通常会根据具体的业务需求进行相应的处理,因此代码的测试部分也由我来完成。例如,当用户尝试创建一个已经存在的用户名时,返回一个错误信息给前端页面,提示用户该用户名已经存在。这样,用户就能知道发生了什么错误,并采取相应的操作。
    在各种功能模块中,加入类似这样的代码:
    try {
    // 具体操作,如创建公文
    } catch (BusinessLogicException e) {
    System.out.println("发生业务逻辑异常: " + e.getMessage());
    logger.error("发生业务逻辑异常", e);
    } catch (RuntimeException e) {
    System.out.println("发生运行时异常: " + e.getMessage());
    logger.error("发生运行时异常", e);
    }
  2. 日志记录
    为了更好地追踪和定位问题,我认为还需要对异常进行详细的日志记录。这不仅是管理员端里对功能进行的简单记录,在后台的日志中还需要包含异常的类型、信息、发生的调用链路等详细信息。这样,当出现问题时才能可以迅速定位到具体的错误位置和原因,这些在我的实验报告里也有所体现。

五 项目功能测试

在电子公文系统中,项目功能测试是非常重要的一环。我们小组的功能模块测试也是由我来完成的。
1.测试环境的搭建
为了确保测试的顺利进行和结果的准确性,生产环境与测试环境尽量相似或者一致。由于我们组的代码最后是集成到我的电脑上的,因此生产环境和测试环境一致,方便于功能测试。

2.测试用例的编写
我们需要根据项目的需求和功能模块的划分编写详细的测试用例,包括正常情况下的测试用例和异常情况下的测试用例。

3.自动化测试工具的使用
为了提高测试的效率和准确性,我们可以使用自动化测试工具进行测试操作。在这里我使用的是专业版IDEA,它自带的测试方式还是比较完善的。
回归测试:在后期,我们新增或修改功能后,每次修改后我都进行了回归测试,确保系统的稳定性。
安全测试:对于加密的过程,我们进行了安全测试,这部分是和进行加密通信以及数据库组建的同学共同完成的。
性能测试:为了确保系统在高负载下的稳定性和性能,我进行了一些性能测试。不过除了启动的时候比较慢,基本都是即时响应,没有什么测试的必要。

(二)你们小组总共的代码行数,你贡献的代码行数?相关代码链接?

我们小组总共约前端4500行,后端6000行。(这里的统计是主目录下的,还有很多外部库没算在里面)。
其中我的工作是系统功能实现,约占3500后端,1500行前端,以及数据库组件部分。

后端页面,只统计了src文件夹下的代码总行数

前端页面,只统计了src文件夹下的代码总行数

(三)你们小组总共的文档数?你贡献的文档数?相关链接?

我们小组共发布11篇博客
我们小组是采用了合作的方式,因此我参与了全部的文档

团队作业(一):团队展示需求规格说明书
团队作业(二)需求分析
团队作业(三)确定分工
团队作业(四)描述设计

在这部分,我参与了其中部分架构设计以及流程图绘制的工作,对系统整体的状态图进行了描写。

冲刺总结(一)
冲刺总结(二)
冲刺总结(三)
冲刺总结(四)
冲刺总结(五)
冲刺总结(六)
冲刺总结(七)

在这部分,我在每天的冲刺报告里加入了自己今日遇到的问题和完成代码的进度。