软件构造已经开课两周了,再肝了12h实验后终于有时间简单回顾这两周的内容,记录一下我对一些知识点的理解。
1、Views and Quality Objectives of Software Construction
Muti-dimensional software views
第一章的内容基本围绕这几个视角展开:
编程时(build)&运行时(run)
说到运行时的话,就不得不考虑程序在靶机上的运行情况,比如如何从磁盘中载出程序,如何载入到内存中等等。内存占用量、运行速度等等因素将会成为注意的对象。届时,我们将使用“代码快照”等方式来进行相应的观测。
微观(code)&宏观(component)
代码的视角(源代码):①源代码如何逻辑组成或依赖程序块(如函数、类、方法、借口等等) ②内存中的程序及其之间如何运行与交互;
模块的视角(结构):①源代码如何物理构成或依赖结构(如文件、目录、包、库等等) ②各个程序包如何在物理环境下配置、运行与交互;
时刻(time)&时期(period)
时刻:某一特定的时间点,代码或模块如何,程序如何运行;
时期:随着时间的推移,代码或模块如何变化,程序如何运行;
其实不管上面这些维度怎么组合,只要清楚这些名词所代表的含义,结合我们大一以及上学期所积累的编程以及底层知识,要判断并不是难事。接下来讲一些在授课过程中比较好奇或者说因为砍课时的原因不得不舍弃的部分。
日志(log):
网络设备、系统及服务程序等,在运作时都会产生一个叫log的事件记录;每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。
Windows网络操作系统都设计有各种各样的日志文件,如应用程序日志,安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等等,这些根据你的系统开启的服务的不同而有所不同。我们在系统上进行一些操作时,这些日志文件通常会记录下我们操作的一些相关内容,这些内容对系统安全工作人员相当有用。比如说有人对系统进行了IPC探测,系统就会在安全日志里迅速地记下探测者探测时所用的IP、时间、用户名等,用FTP探测后,就会在FTP日志中记下IP、时间、探测所用的用户名等。
当然,日志数据对于实现网络安全的价值有多大取决于两个因素:第一,你的系统和设备必须进行合适的设置以便记录你需要的数据。第二,你必须有合适的工具、培训和可用的资源来分析收集到的数据。
当前的计算机病毒越来越复杂,对于网上求助这种远程的判断和分析来说,必须借助第三方的软件分析。流行的辅助分析工具有sawmill、Hijackthis 及SREng。
通过专业的日志分析工具的完整性分析,让你从数据的海洋中摆脱出来,并可以直接的以WEB界面的形式查看所需信息,解除专业性烦恼。
在Run-time,period and code-level view下,日志可以执行执行跟踪的功能(Execution tracing)记录在.log文件中。然后呢我就用idea打开了使用idea编程过程中产生的日志,过程如下:
在idea中选择帮助(help):
选择“在Explorer中显示日志”,idea会自动打开目录,底下有idea.log文件,这就是记录编程过程的日志文件
可以看到里面记载了时间,信息等,每一步是编译是加载一目了然。可以从这里进行对程序是如何一步步编译,链接最后执行的过程。
更方便也可以在控制台输出日志信息,详情可以见:
(73条消息) 在idea中如何在控制台输出日志?——用log4j_程序员-小李的博客-CSDN博客_idea 控制台日志
总的来说软件构造的第一张多维视角主要就是以下:
从评价一个程序的角度又可以分为:
可复用性:
稳定性可移植性:
健壮性:
2、Test and Test-First Programming
通过集合论的学习以及大一程序设计课程所积累的经验,要想应付一般的等价分类应该问题不大。就我而言,在老师授课的过程中,主要有几点比较启发我。
其一,要结合计算机底层的特点,以及Java的库中的方法的重载。比如整数计算中,我们知道integer类型是有上限的,超过上限要用字符串储存,整数乘法就会根据值的不同而选用不同乘法,因此划分等价类过程中就得加一个是否大于Integer.MAX_VALUE的划分。
其二,就是边界的处理。我一直追求用一种普遍的方法解决问题从而忽视最有可能出错的Boundary。
此外,上课还提到一个点:分支覆盖与条件覆盖,这两个都是覆盖度的标准或者实现之一。初学的时候很容易混淆,我也是查阅了一些资料才有了比较透彻的了解。
分支覆盖:要求程序中所有判定的分支尽可能得到检验;
条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;
注意这里的不同,条件覆盖于分支覆盖不同,条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值,即每个条件至少有一次真值、有一次假值。有一种更强的形式——条件组合覆盖:组合覆盖也叫做条件组合覆盖。意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然,满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。条件组合覆盖能够同时满足判定、条件和判定条件覆盖,覆盖度较高,但是组合覆盖的测试用例数量相对来说也是比较多的。
然后说明一下Junit如何在idea种启动:
首先选中一个目录作为测试根:
再选中需要测试的类,在类名上按下Alt+Enter,选中创建测试,设置名字即可:
Lab1的P3的test就是这么建立的。
总之,第一篇blog就讲这么多,下一次主要想讲讲git,或者后两周的奇思妙想吧。如果有不正确的地方还请指出。