2018（秋）软工作业 5：结对项目之词频统计——增强功能
0、阶段2 - 结对项目（词频统计——增强功能）
1、目标
- 接口封装
- 增加新功能
- 编写单元测试
2、要求
Task 1. 接口封装
在写了一些代码开胃之后，大家都完成了一份满足基本功能的代码。
大家的代码都各有特色，如果现在我们要把这个功能放到不同的环境中去（例如，命令行、Windows图形界面程序，网页程序，手机App），就会碰到困难：代码散落在各个函数中，很难剥离出来作为一个独立的模块运行以满足不同的需求。
同时我们也看到，不同的代码解决不同层面的问题：
- 有些是计算数据的（例如统计单词）
- 有些是控制输入的（例如scanf，cin，图形界面的输入字段）
- 有些是数据可视化的（例如printf，cout，println，DrawText）
- 有些则更为特殊，是架构相关的（例如main函数，并不是所有的程序都需要某个特定格式的main）
这些代码的种类不同，混杂在一起对于后期的维护扩展很不友好，所以它们的组织结构就需要精心的整理和优化。
我们希望把基本功能里的：
- 统计单词数
- 统计最多的10个单词及其词频
这三个功能独立出来，成为一个独立的模块(class library, DLL, 或其它)，这样的话，命令行和GUI的程序都能使用同一份代码。为了方便起见，我们称之为计算核心"Core模块"，这个模块至少可以在几个地方使用：
命令行测试程序使用
在单元测试框架下使用
与数据可视化部分结合使用
把计算核心在单元测试框架中做过完备的测试后，我们就可以在算法层级保证了这个模块的正确性。
但我们知道软件并非只有计算核心，实际的软件是交付给最终用户的软件，除了计算核心外，还需要有一定的界面和必要的辅助功能。
这个Core模块和使用它的其他模块之间则要通过一定的API来交流。
- API应该怎么设计呢？
为了方便起见，我们可以从下面的最简单的接口开始（仅举例，你的代码里可能没有这个函数）：
int countChar(File *file)
这个函数表示输出一个文件指针，返回这个文件的字符数。
假设我们用Core封装了这个接口，那么我们的测试程序可以是这样：
# 测试脚本
...
File *in = fopen("input.txt","r");
int count = 100;
Assert(countChar(in) == count);
...
当然，这样的测试程序并不充分，希望大家测试时不要像这样偷懒
Task 2. 增加新功能
我们希望各位在第一步的基础上，添加一些新的功能：
-
词组统计：能统计文件夹中指定长度的词组的词频
-
自定义输出：能输出用户指定的前n多的单词与其数量
为了实现上述软件，我们首先要在个人项目基础上增量改进，实现一个Core模块，并基于Core模块实现在命令行测试程序中支持下述命令行参数（原有命令行参数不变） -
-i 参数设定读入的文件路径
格式如下
wordCount.exe -i [file]
一个例子如：
wordCount.exe -i input.txt
- -m 参数设定统计的词组长度
格式如下
wordCount.exe -m [number]
词组定义：m个由分隔符隔开的单词组成一个词组
-m参数与数字配套使用，用于设置词组长度
命令行中使用-m参数，例：
wordCount.exe -m 3 -i input.txt
/*
*要求程序统计input.txt中长度为3的词组，最终输出
*例：input文件中内容为"Monday Tuesday Wednesday Thursday"
*则输出如下
*/
characters: 33
words: 4
lines: 1
Monday Tuesday Wednesday: 1
Tuesday Wednesday Thursday: 1
- -n 参数设定输出的单词数量
格式如下
wordCount.exe -n [number]
-n参数与数字搭配使用，用于限制最终输出的单词的个数
表示输出最多的前[number]个单词
命令行中使用-n参数，例：
wordCount.exe -n 1 -i input.txt
/*
*程序会输出文件中出现次数最多的那个单词
*/
- -o 参数设定生成文件的存储路径
格式如下
wordCount.exe -o output.txt
则将统计信息输出到文件 output.txt中。
- 多参数的混合使用
在实际测试时，-i 与 -o 参数一定会出现（但文件路径不一定正确），但-n或-m 参数可能不出现，参数之间的顺序并不固定，一个完整例子如下
wordCount.exe -i input.txt -m 5 -n 3 -o output.txt
3、提交
提交内容包括：
- 提交 V2.0 版本 到github 或码云（gitee）（3分）
- 确保结果正确
- 不要有警告
- 良好的性能
- 确保单元测试代码通过
- 提交博客 （博客标题：
作业 n：词频统计——增强功能）(7分）
- git项目仓库地址，程序接口设计介绍（2分）
- 程序每项新增功能运行案例截图，共计5张（2分）
- PSP 表格（2分）
- 描述结对讨论过程，提供非摆拍的两人在讨论的结对编程照片（1分）
4、附录
- PSP 表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | ||
| Development | 开发 | ||
| · Analysis | · 需求分析（含学习新技术） | ||
| · Design Spec | · 编写设计文档 | ||
| · Design Review | · 设计复审 | ||
| · Coding Standard | · 代码规范 | ||
| · Design | · 具体设计 | ||
| · Coding | · 具体编码 | ||
| · code review | · 代码复审 | ||
| · test | · 测试 | ||
| Reporting | 报告 | ||
| · Test report | · 测试报告 | ||
| · Size measurement | · 计算工作量 | ||
| · Postmortem | · 事后总结 | ||
| 合计 |
