一:Github项目地址:https://github.com/candy07213/WC

二:PSP表格

PSP2.1

Personal Software Process Stages

预估耗时(分钟)

实际耗时(分钟)

Planning

计划

         25

         25

· Estimate

· 估计这个任务需要多少时间

         25

         25

Development

开发

        1555

       1720

· Analysis

· 需求分析 (包括学习新技术)

         110

        125

· Design Spec

· 生成设计文档

          70

         60

· Design Review

· 设计复审 (和同事审核设计文档)

          50

         65

· Coding Standard

· 代码规范 (为目前的开发制定合适的规范)

          25

         40

· Design

· 具体设计

         100

        100

· Coding

· 具体编码

        1000

       1150

· Code Review

· 代码复审

          80

         70

· Test

· 测试(自我测试,修改代码,提交修改)

         120

        110

Reporting

报告

         120

        120

· Test Report

· 测试报告

          70

         60

· Size Measurement

· 计算工作量

          20

         20

· Postmortem & Process Improvement Plan

· 事后总结, 并提出过程改进计划

          30

         40

合计

 

        1700

        1865

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 三:解题思路

1,  刚开始看到题目没有注意好需求,以及有两个点不够明确,首先写一个命令行程序,怎么算一个命令行程序?因为以前也在cmd页面运行过java程序,所以这部分实现方式就比较了解,但是相应的需求格式要求完成的并不好,出现了一些错误,最后还是按照以往的格式完成的项目,其次就是给出某源程序设计语言的相关信息,这一点由于刚开始重点放在了模仿wc.exe的统计文本文件的相关信息,所以在完成基础功能后才突然意识到重点是统计程序文件的信息,就开始做了相应的修改。

2,  基础功能部分之前在java作业中有过练习,所以主要是思考源程序代码与文本文件在统计的过程中的区别,最大的区别就在于单词数的统计上,因为源程序的单词之间不是简单的空格等分开,会有一些别的分隔单词的字符,所以这里就利用了正则表达式来分隔单词,其他计算字符数与行数实现就比较常规。

3, 扩展功能就实现了计算空行,代码行以及注释行的部分,这一部分在判断空行处也利用到了正则表达式的知识,其次由于自己设置的情况总是不能覆盖到所有的地方,也在百度上参考了别的代码,有了新的收获,也设置了两个变量isSign(是注释行)notSign来为之后的代码行和注释行做准备,要注意的是注释行主要是有两种,//形式和/*…*/尤其是多行注释比较麻烦,利用了两个方法startsWith和endsWith方法来判断多行注释,首先就是判断/*是否存在,若出现/*并且没有出现*/标志则表示进入了多行注释处,并且没有出来,注释行数就开始增加,设置isSign为true,就根据是否遇到了*/以及它出现的位置设置加数,isSign的真假,在最后主要计算注释时要减去notSign,就是只出现/*没有*/的部分,以及代码行要加上之前的notSign,除了空行和注释行都是代码行

4, 高级功能不够完善,实现了图形界面,但是不能通过输出x调用,只能在cmd中直接执行图形界面类,或者eclipse的console处,由于在图形界面处要使用到之前的统计方法,所以在设计时有些混乱,测试调用处会出错,出现堆栈溢出的异常,做了尝试后还是没有解决,所以目前只能实现在命令行调用相关的类之后在命令行弹出图形界面,图像界面主要按照设计的按钮分了两个部分,一个是选择文件按钮,利用了JFileChooser,以及上传文件对话框,设置里将之前选择的文件路径通过JTextField的setText方法将路径打印到文本框处,再点击第二个按钮之后,会根据路径调用相应的统计结果将内容返回到JTextArea中,这里设计监听器也有些混乱,最后在第二个按钮的actionPerformed方法中调用之前的方法就可以了。

 

四:设计实现过程 

 

     分类: WC主类,Count基本功能类,Extend扩展类,GraInterface图形界面类,处理按钮ButtonHandler类

    调用:首先WC主类中调用Count以及Extend类来实现对数据的查询,在Count类中利用Count1方法完成了基本功能c,w,l的实现,通过if语句判断输入的字符来实现相应的功能以及对Extend中完成的a参数的扩展功能。然后GraInterface图形界面设置了JTextField文本框,以及两个按钮,按钮1是点击选择文件,按钮1的actionPerformed方法会根据选择的文件把文件路径返回到JTextField文本框中,然后点击按钮2统计结果之后,该文件的相关统计结果就会通过按钮2的actionPerformed方法对ButtonHandler的调用把结果显示在JTextArea中,从而实现了图形界面

流程图:

           

函数代码组织:

 

五:测试运行

1:空文件

 

2:一个字符文件

  

3:一个词的文件

 

4:一行文件

5:典型源文件

图像界面:

 

六:项目总结

不足:首先在java编程能力上就比较弱,平时的代码练习太少,所以即使完成的功能不多,并且一些格式也不规范,没有达到相应的要求,但是还是花了不少的时间去完成项目,包括复习java的内容,主要是在文本输入输出流,正则表达式,图形界面的地方加深了一些认识。面对代码异常以及出错,不能保持好一个平和的心态,以及没有足够的耐心,所以效率也很低。其次这次做项目最大的教训在于没有花费足够的时间去做前期的准备,以及理解项目要求时不够认真,总是以一个大概的态度去做大概的规划,最后也因为没有做好这些,导致之后的代码就比较混乱,结构也就不够清晰,如果是和团队交接,肯定还会因为这样造成更糟糕的后果,所以意识到了前期思考的重要性。最后是认识到正确实现方法的重要性,有时不是你写不出来想要的代码,而是你一开始的想法就是错的,逻辑不对,就会在实现的过程中遇到各种的问题,当方法对了的时候代码就相当于完成了一部分,以及实现的时候一定要一步一步的明确要实现的东西,而不是只是笼统的想一个大概。

收获:完成了基本项目要求,以及掌握了一些其他利用eclipse调试程序时的操作,但还是不太熟练,以及意识到了在整个设计过程中自己的一些问题

有待改进:项目方面还有比较多的地方需要改进,首先在处理模式上不够规范,,其次在统计各种数时只考虑到了英文输入,扩展处的剩下两个部分也没有实现,图像界面虽然实现了,但是没有和主类建立x连接,异常没有处理好所以只能在图形界面类实现,以及操作均为常规正常操作,没有做好出错处理,以及一些错误文件的反馈。个人方面还是要加强编程能力,此次项目还停留在代码设计阶段并且这个阶段完成的也不好,离软件工程还有很大的距离,之后还需要在增强个人技术的同时不断的向软件工程设计的方向靠拢。

 

版权声明:本文为candy07213原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/candy07213/p/11587325.html