2021年软工-第二次结对作业

2021年软工-第二次结对作业

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	博客要求、第二次作业指导书
我在这个课程的目标是	了解软件开发工程的具体流程，学习项目实践开发的方法与步骤。
这个作业在哪个具体方面帮助我实现目标	第二次进行结对编程实践，进一步体会结对编程的便利，并进行相互间的交流与学习。
结对项目Gitlab地址	2021_Qixiang_He-Mingxin_Li_pair_work
学号后四位	6161，3339

结对编程体会总结

• 本次作业中主要体会之一就是交流的重要性。对于指导书中相当多不是非常明确的需求，我们会在issue区参考其他同学的提问以及助教的回复，或者自己主动提出issue与同学助教们进行交流，而这些交流部分的内容则很大程度上帮助我们进一步理解了指导书中一部分指令的标准。
• 此外，由于本次作业的内容量较大，且逻辑分支较为复杂，因而单元测试在本次作业中具有极其重要的作用。我们也在本次的单元测试中检测出了相当多的疏漏以及理解上的错误。

结对编程方式及记录

• 开展结对编程的主要方式

  由于上次结对编程方式的合作效率比较高，尤其是讨论确定程序的具体结构设计这一环节，很大程度上确保了我们二人的编程标准相对一致，所以我们这次依旧采用了上次作业的结对编程方式，大致包含以下流程。

  • 约定时间见面，共同阅读结对作业指导书，讨论确定程序的具体结构设计。同时确定编程分工，以及任务推进时间点。
  • 分工完成程序编程内容，随时交流编程遇到的问题，定期对完成的代码进行合并。

• 开展结对编程的记录

  

  

程序设计

• UserSystem用户系统

  • 设计综述

    用户系统涉及到的类主要包含用户User，用户组Group及用户系统控制UserSystemControl，这三个类之间涉及到的具体关系可用如下UML类图表示。

    

  • 设计细节

    • User用户
      • 每个User用户对象都具有三个主要特征，包括用户名、所属的主组和所属的全部用户组。
      • 其中，所属全部用户组用 String -> Group 类型的映射容器来存储，确保每个用户都能够根据所属用户组名高效获取对应的用户组对象。
    • Group用户组
      • 每个Group用户组对象也具有三个主要特征，包括用户组名、包括的全部用户和主组索引计数。
      • 其中，包括的全部用户也采用类似 String -> User 类型的映射容器来存储，确保每个用户组都能根据用户名高效获取对应的用户对象，或者判断相应的用户对象是否存在。
      • 主组索引计数主要代表的含义是将本用户组作为主组的用户个数，在删除特定用户并判断是否同时删除所属用户组时，作为主要的判断依据。

• FileSystem文件系统

  • 设计综述

    文件系统通过继承FileSystem的FileSystemControl类进行控制，文件File与目录Document通过实现MetaFile来向外提供统一接口，硬链接HardLinkFile与软连接SoftLinkFile继承自File。UML类图如下：

    

  • 设计细节

    • SoftLinkFile软链接

      • 较FIle类，新增linkedPath字段，用来储存被链接到的绝对路径。
      • 在设计中不直接使用SoftLink进行文件/目录的读写等操作，而是通过redirect方法得到链接的对象时，再通过得到的对象进行操作。也因此，对于继承下来的有关File内容操作的方法都覆写为assert false来警告自己不要误操作。

• HardLinkFile硬链接

  • 较File类，新增linkedFile字段，用来指向被链接到的文件。且在实现中，多个HardLinkFile若链接到同一个File，不论是以何种方式实现这种链接，最终HardLinkFile与File都是呈星形结构，星行的中间是File，周围是HardLinkFile。

    • HardLinkFile基本上视作与File等同，但根据info的输出的信息，HardLinkFile需要保留自己的路径。所以除了与路径有关的getAbsPath, getName, getFather方法保留输出自己的信息，其他方法都与被指向的File保持一致。

    • FileSystemControl

      • 对于之前实现的方法，做出了以下修改：

        • makeDirectoryRecursively: 针对新增的异常类型做出了修改

    • 对于所有在上一版本实现的方法，根据指导书的要求对得到的文件/目录是否需要进行重定向进行了更新。

      • 对于readLink，暂时的实现是对于失效的软链接进行报错。
      • 对于linkSoft, linkHard, move, copy，由于在当前的设计中要直接根据指导书的分支形式进行实现有一定困难且冗杂，所以在我的实现中，先将情况分为了dstpath未匹配文件/目录，dstpath匹配到文件，dstpath匹配到目录，然后在间接实现指导书的分支。

• Document/File

  • 对于size，因为上一版的系统并不复杂，所以所以size都是通过传播来实时更新的，但这一版的实现由于复杂了很多导致使用这种办法容易因为疏忽导致很多错误。所以在这一版中，每次获取size都重新自顶向下计算得到。

  • 对于modifyTime, 划分为了内部更新与外部更新。例如对于目录，增删其子文件/目录属于内部更新，直接移动这个目录属于外部更新，文件也同理。

PSP表格时间统计

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划
· Estimate	· 估计这个任务需要多少时间	960	800 \(\pm\) 60
Development`	开发
· Analysis	· 需求分析 (包括学习新技术)	120	200
· Design Spec	· 生成设计文档	20	25
· Design Review	· 设计复审 (和同事审核设计文档)	15	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0（直接采用OO课程规范）	0
· Design	· 具体设计	60	65
· Coding	· 具体编码	480	500
· Code Review	· 代码复审	240	240
· Test	· 测试（自我测试，修改代码，提交修改）	120	150
Reporting	报告
· Test Report	· 测试报告	30	45
· Size Measurement	· 计算工作量	30	35
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	45
	合计	2105	2125