Github地址：https://github.com/Emily9901/WC.exe
PSP表格：
| PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| .Estimate | .估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 1540 | 1870 |
| .Analysis | .需求分析 | 30 | 40 |
| .Design Spec | .生成设计文档 | 40 | 60 |
| .Design Review | .设计复审 | 15 | 20 |
| .Coding Standard | .代码规范 | 15 | 20 |
| .Design | .具体设计 | 60 | 90 |
| .Coding | .具体编码 | 1200 | 1400 |
| .Code Review | .代码复审 | 60 | 90 |
| .Test | .测试(自我测试，修改代码，提交修改) | 120 | 150 |
| Reporting | 报告 | 110 | 100 |
| .Test Report | .测试报告 | 60 | 40 |
| .Size Measurement | .计算工作量 | 20 | 20 |
| .Postmortem&Process Improvement Plan | .事后总结，并提出过程改进计划 | 30 | 40 |
| 合计 | 1670 | 2000 |
解题思路：
(1)从整体来看，需要三个模块，一个主模块(Main)，一个功能模块(Option)，一个界面模块(interfram)；
(2)功能分析：
-x：用于从命令行切换到图形界面。由此说明该应用软件应具备两种界面，命令行界面和图形界面。命令行是由用户自己输入命令执行，所以应该有一个函数check()来检查输入的命令格式是否正确，如果正确，则进一步用deal() 函数对命令进行分析，分析完成后，再调用相应函数实现相应的功能；而对于图形界面来说，可以以选项的方式供用户选择想要执行的功能与相应要操作的文件，由于用户的输入是可控制的，所以只需根据用户的输入调用函数 实现相应的功能即可；
-s：用于处理文件夹。非-s是用于处理文件，文件夹与文件的关系是文件夹包括多个文件，文件夹里面可能存在多层嵌套，所以可以有一个函数isDirectory()/is_Direcory()用于从指定的文件夹中递归找出目标文件，并且在找的过程中对是目标文件的文件通过调用Command()函数进行处理；而如果是非-s，则直接调用Command()函数对单个文件进行处理，获得想要的统计结果；
-c,-w,-l：分别用于计算字符数，词数，行数，这三个功能可以放在一个函数BaseOption()中实现；
-a：用于计算空行，注释行，代码行的数目，可以放在一个函数ExtendOption()中实现。其中，对于注释行的统计，在代码实现过程中花了比较多的时间去处理。一开始本来是想用正则表达式对每一行进行匹配处理，后来发现其对应的情况比较多，实现起来比较麻烦，最后决定采用从每一行的第一个非空字符开始判断的方式，利用嵌套if语句处理三种不同的注释形式，"//"，"/* */"(同一行)，"/* */"(不同行，利用notetag进行标记)，具体细节在代码中有做详细的解释；
(3)对于用户所要执行的功能，-c/-w/-l/-a，由于用户每次输入这些功能时顺序可能不一样，或者数目也可能不同，如果要对每一种进行匹配，会比较麻烦，所以利用了一个标记数组，对于用户所要执行的功能可相对应置为1，否则为0；
设计思路：
• Main类：程序执行的入口，用于从命令行接收用户的命令并执行，此外还有命令格式检查函数check()，命令分析函数deal()；
• Option类：实现功能函数，包括基本功能函数BaseOption()，扩展功能函数ExtendOption()，文件夹处理函数isDirectory()，单个文件统计函数Command()；
• interfram类：实现图形界面交互，同样有文件夹处理函数is_Directory()，单个文件统计函数Command()；
测试分析：
• 命令行界面
正常测试
a. 空文件
b. 单个字符文件
c.单个词文件
d. 单个.c文件
e. 单个.java文件
f. 指定后缀的文件夹
g. 不指定后缀的文件夹
输入命令错误测试
a. 功能输入错误
b. 文件路径不存在
c.指定文件不存在
d. 指定文件路径错误
e. 没有指定目标文件的属性
f. 目录不存在
g. 目录为空
h. -s下输入单个文件路径
• 图形界面
PS：(对Option模块进行了覆盖率测试)
总结：
每当做完一个项目之后，其实最令人开心的是可以从这个过程中又学到了一些新的知识与技能，并且从中看到了自己的不足之处。通过这个项目的开发，让我感受较深的是自己在如何设计这个软件的思考上比以往花的时间多，如果是在以往的情况下，会比较急于动手写代码，而不会在此之前花较多的时间去考虑如何设计的问题，这也使得后来要修改代码的时候会比较困难，感觉这也是学习软工之后有明显进步的一个方面。另外，通过这个项目的开发，以下是我的一些心得体会：1. 要有一个全局思维，比如在写代码之前应该想好需要哪些模块，模块之间的调用关系是什么，以及各个模块需要实现什么功能；2. 函数之间功能尽量相互独立，其实现的功能范围不要太大也不要太小，太大 的话代码修改起来会比较麻烦，太小的话会导致函数过多；3. 在实现一个函数的时候要注意瞻前顾后，它会被谁调用以及它会调用谁；4. 在基本代码实现之后要进一步思考有什么改进的措施；5. 测试的时候应该从一个最小的功能开始测起，边写代码边测试比较好，不会到时候Debug的时候难以判断是哪里出问题。