USTC《现代软件工程》春季学期——第一次个人作业：词频统计

截止日期

2018年3月29日23:59

要求

1. 对源文件（*.txt,*.cpp,*.h,*.cs,*.html,*.js,*.java,*.py,*.php等，文件夹内的所有文件）统计字符数、单词数、行数、词频，统计结果以指定格式输出到默认文件中，以及其他扩展功能，并能够快速地处理多个文件。

2. 使用性能测试工具进行分析，找到性能的瓶颈并改进

3. 对代码进行质量分析，消除所有警告

http://msdn.microsoft.com/en-us/library/dd264897.aspx

4. 设计10个测试样例用于测试，确保程序正常运行（例如：空文件，只包含一个词的文件，只有一行的文件，典型文件等等）

5. 使用Github进行代码管理

6. 撰写博客

基本功能

1. 统计文件的字符数（只需要统计Ascii码，汉字不用考虑）

2. 统计文件的单词总数

3. 统计文件的总行数（任何字符构成的行，都需要统计）

4. 统计文件中各单词的出现次数，输出频率最高的10个。

5. 对给定文件夹及其递归子文件夹下的所有文件进行统计

6. 统计两个单词（词组）在一起的频率，输出频率最高的前10个。

7. 在Linux系统下，进行性能分析，过程写到blog中（附加题）

注意：

a) 空格，水平制表符，换行符，均算字符

b) 单词的定义：至少以4个英文字母开头，跟上字母数字符号，单词以分隔符分割，不区分大小写。

英文字母：A-Z，a-z

字母数字符号：A-Z，a-z，0-9

分割符：空格，非字母数字符号

例如：”file123”是一个单词，”123file”不是一个单词。file，File和FILE是同一个单词。

如果两个单词只有最后的数字结尾不同，则认为是同一个单词，例如，windows，windows95和windows7是同一个单词，iPhone4和IPhone5是同一个单词，但是，windows和windows32a是不同的单词，因为他们不是仅有数字结尾不同

输出按字典顺序，例如，windows95，windows98和windows2000同时出现时，输出windows2000

词组的定义：windows95 good， windows2000 good123，可以算是同一种词组。按照词典顺序输出。三词相同的情形，比如good123 good456 good789，根据定义，则是 good123 good123 这个词组出现了两次。

c) 输入文件名以命令行参数传入。需要遍历整个文件夹时，则要输入文件夹的路径。

d) 输出文件result.txt

characters: number

words: number

lines: number

<word>: number

<word>为文件中真实出现的单词大小写格式，例如，如果文件中只出现了File和file，程序不应当输出FILE，且<word>按字典顺序（基于ASCII）排列，上例中程序应该输出File: 2

e) 根据命令行参数判断是否为目录

f) 将所有文件中的词汇，进行统计，最终只输出一个整体的词频统计结果。

项目管理

1. 分析整理需求，完成PSP表格

PSP是卡耐基梅隆大学（CMU）的专家们针对软件工程师所提出的一套模型：Personal Software Process (PSP， 个人开发流程，或称个体软件过程)。

一个功能完备的程序不是一蹴而就的。通过将词频统计的需求划分为4个部分，可将一个大任务划分为可操作的小任务，同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此，在动手开发之前，要先估计将在程序各模块开发所需耗费的时间，以及完成整个项目所需的时间，将这个[估计值]记录下来，写成PSP 的形式。

PSP的目的是：记录工程师如何实现需求的效率，和我们使用项目管理工具（例如微软的Project Professional，或者禅道等）进行项目进度规划类似。

有关PSP的更多内容，请自行阅读邹欣老师的博客：

http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html

PSP可用teambition工具制作

https://www.teambition.com/

2. 使用Github进行代码管理

使用PSP做好规划之后，第二步当然是进行编码实现，此时，除了选择合适的编程语言，还需要学会良好的源代码管理。

请阅读邹欣老师的博客：源代码管理，了解源代码管理的10个实践问题。

本次作业要求使用Github进行源代码管理，代码有进展即签入Github。签入记录不合理的项目会被助教抽查询问项目细节。

对代码签入的具体要求如下：根据需求划分功能后，每做完一个功能，编译成功后，应至少commit一次。本例中，至少应区分基本功能和扩展功能，即分别针对基本功能、扩展功能，编译成功后，总共至少应commit两次。具体的功能划分，请自行定义，并在撰写博客时体现出来，遵循自己对需求的功能划分来提交代码即可。

对Commit不是很熟悉的话，请阅读阮一峰的博客：Commit message 和 Change log 编写指南，了解更多细节。

3. 设计测试用例，编写单元测试

作为一门测试的课程，测试才是重点。请根据自己以往积累的测试经验，结合本周介绍的测试用例设计方法，在编码完成之后，提交产品之前，设计测试用例，并编写单元测试，对自己的项目进行测试。

首先，至少应采用白盒测试用例设计方法来设计测试用例，其他测试方法不限。其次，要设计至少10个测试用例，确保你的程序能够正确处理各种情况。最后，结合测试评估的要求，对自己的测试设计进行评价，这些测试用例能满足该程序测试的要求吗？

另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。

推荐阅读邹欣老师关于单元测试和回归测试的博客：

http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html

博客要求

1. 需求分析，估计各部分所需时间，给出PSP表格

2. 记录实际完成各部分时间

3. 对代码质量和性能进行分析

4. 测试用例设计和分析过程

5. 描述你在次项目中获得的经验

评分标准

1. 统计文件的字符数(2分)

2. 统计文件的单词总数(2分)

3. 统计文件的总行数(2分)

4. 统计文件中各单词的出现次数(2分)

5. 对给定文件夹及其递归子文件夹下的所有文件进行统计(4分)

6. 统计两个单词（词组）在一起的频率，输出频率最高的前10个(4分)

以上六个结果输出错误则对应子任务得-2分，全部输出正确则按运行时间确定排名(用时按升序前30%得满分16分，30%-70%得15分，后30%得14分)。

7. 博客撰写(代码实现过程，性能分析、优化报告等)(4分)

8. 在Linux系统下，进行性能分析，过程写到blog中（附加题，2分）

代码提交地址：

https://github.com/eudaem/homework1

注意：作业延迟，1周内补交，0分；不交作业-10分。