随笔 - 34, 文章 - 1, 评论 - 2, 引用 - 0
数据加载中……

2011年1月7日

产品经理编写MRD和PRD

MRD(market requirement document )和PRD(production requirement document)区分

 
http://hi.baidu.com/%D9%DC%D5%BC%BE%FD/blog/item/937c921603e2220c4a90a794.html

正确编写PRD产品需求文档
http://hi.baidu.com/wenlym%CD%E5/blog/item/8fff94ac81727d1c4b36d6db.html




posted @ 2011-06-07 17:21 河马虎 阅读(305) | 评论 (0)编辑 收藏

需求分析谁来写?很不错的文章


http://news.ccidnet.com/art/1032/20060829/884159_1.html

posted @ 2011-03-16 14:30 河马虎 阅读(262) | 评论 (0)编辑 收藏

Java静态检测工具的简单介绍


转自
http://qa.taobao.com/?p=9015

静态检查:静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人
        工进行,充分发挥人的逻辑思维优势,也可以借助软件工具自动进行。
        代码检查代码检查包括代码走查、桌面检查、代码审查等,主要检查代码和
        设计的一致性, 代码对标准的遵循、可读性,代码的逻辑表达的正确性,代
        码结构的合理性等方面;可以发现违背程序编写标准的问题,程序中不安全、
        不明确和模糊的部分,找出程序中不可移植部分、违背程序编程风格的问题,
        包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构
        检查等内容。”。看了一系列的静态代码扫描或者叫静态代码分析工具后,
        总结对工具的看法:静态代码扫描工具,和编译器的某些功能其实是很相似的,
        他们也需要词法分析,语法分析,语意分析...但和编译器不一样的是他们可
        以自定义各种各样的复杂的规则去对代码进行分析。

静态检测工具:
  1. PMD
     1)PMD是一个代码检查工具,它用于分析 Java 源代码,找出潜在的 问题:
1)潜在的bug:空的try/catch/finally/switch语句
2)未使用的代码:未使用的局部变量、参数、私有方法等
3)可选的代码:String/StringBuffer的滥用
4)复杂的表达式:不必须的if语句、可以使用while循环完成的for循环
5)重复的代码:拷贝/粘贴代码意味着拷贝/粘贴bugs
2)PMD特点:
1)与其他分析工具不同的是,PMD通过静态分析获知代码错误。也就是说,在
不运行Java程序的情况下报告错误。
2)PMD附带了许多可以直接使用的规则,利用这些规则可以找出Java源程序的许
多问题
3)用户还可以自己定义规则,检查Java代码是否符合某些特定的编码规范。
3)同时,PMD已经与JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、
CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、
IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs
集成在一起。
4)PMD规则是可以定制的: 可用的规则并不仅限于内置规则。您可以添加新规则:
可以通过编写 Java 代码并重新编译 PDM,或者更简单些,编写 XPath 表
达式,它会针对每个 Java 类的抽象语法树进行处理。
5)只使用PDM内置规则,PMD 也可以找到你代码中的一些真正问题。某些问题可能
很小,但有些问题则可能很大。PMD 不可能找到每个 bug,你仍然需要做单元测
试和接受测试,在查找已知 bug 时,即使是 PMD 也无法替代一个好的调试器。
但是,PMD 确实可以帮助你发现未知的问题。
  1. FindBugs
     1)FindBugs是一个开源的静态代码分析工具,基于LGPL开源协议,无需
运行就能对代码进行分析的工具。不注重style及format,注重检测真正
的bug及潜在的性能问题 ,尤其注意了尽可能抑制误检测(false positives)
的发生。以bytecode(*.class、*.jar)为对象进行检查。除了单独动作,还可
以用作Eclipse 的plug-in,以及嵌入Ant作为task之一 进行利用。
2)findbugs自带检测器的介绍:  findbugs自带60余种Bad practice,80余种
Correntness,1种Internationalization,12种Malicious code
vulnerability,27种Multithreaded correntness,23种Performance,
43种Dodgy。
3)Findbugs的一些特点:
1)FindBugs主要着眼于寻找代码中的缺陷,这就与其他类似工具有些区别了,
直接操作类文件(class文件)而不是源代码。
2)FindBugs可以通过命令行、各种构建工具(如Ant、Maven等)、独立的
Swing GUI或是以Eclipse和NetBeans IDE插件的方式来运行。                
3)FindBugs输出结果既可以是XML的,也可以是文本形式的。
4)开发者可以通过多种方式来使用FindBugs,最常见的是在新编写模块的代码
分析以及对现有代码进行更大范围的分析。   
5)不注重style及format,注重检测真正的bug及潜在的性能问题,
尤其注意了尽可能抑制误检测(false positives)的发生。    
4)FindBugs可检测的bug pattern举例:
检测java programing中容易陷入的bug pattern,equals() 实现时的一般规约违反
Null pointer的参照 ,Method的返回值的check遗漏 ,初始化前field的访问,
Multi-thread的正确性, 同期化处理的矛盾, 无条件的wait(),  Code的脆弱性 ,
可以变更的静态object ,内部数列参照的return等
  1. Checkstyle
     1)定义: Checkstyle是一款检查Java程序源代码样式的工具。
2)特点:
1)它可以有效的帮助我们检视代码以便更好的遵循代码编写标准,特
别适用于小组开发时彼此间的样式规范和统一。
2)Checkstyle提供了高可配置性,以便适用于各种代码规范,所以
除了使用它提供的几种常见标准之外,你也可以定制自己的标准。
3)Checkstyle提供了支持大多数常见IDE的插件,大部分插件中就含有
最新的Checkstyle,就不用费心再部署一份了。
4)Checkstyle可以检查代码的很多方面,从传统观点看,它主要是用来
检查代码层面的,自从第三版以后,它的内部架构作了重大改变,很多
其它意图的检测加了进来,现在Checkstyle可以检查像类设计的问题,
重复代码,如锁的双重检查的bug模式。
3)CheckStyle的主要流程是:
1)对Java文件进行词法语法分析,生成语法树。
2)载入配置文件(checkstyle-metadata.xml以及自定义的配置文件)
register check事件。
3)按照深度优先遍历对语法树进行解析,按照注册的事件,在到达某些节点
( AST ) 时进行style检查(AST,A child-Sibling Tree,是语法
树中的某个节点,其类型在TokenTypes类中定义。)
4)我们所说的自定义Style的检查,就是在第二步设定的。
这里牵涉到一个叫com.puppycrawl.tools.checkstyle.api.Check 的类,
我们通常需要重载其中的两个函数: public int[] getDefaultTokens()
        public void visitToken(DetailAST ast). 这两个函数的含义为,
在遍历语法树的过程中,每当到达getDefaultTokens函数所返回的AST类型,
程序就进入visitToken进行具体的检查和分析,即,真正的分析检查过程是在
visitToken中实现的。
  1. Hammurapi
     1)定义: Hammurapi它是一个开源的代码审查/评审(review)工具。它可以帮助改进
Java代码的质量。它可以基于一套设计规范来分析代码库。当它碰到违反规
范的地方,会在报告中标识。就像Checkstyle一样,它与Ant无缝集成并且
由基于XML配置文件来驱动。
2)特点:
1)Hammurapi是用来强制代码设计规范的。
2)Hammurapi是一个遵循设计的工具,提供了自动而且一致的方式来实现设计规范,
因此使代码评审更加有效而轻松。
3)Hammurapi如何工作:
         Hammurapi这样的代码分析工具都带有语言分析器。语言分析器是一种输入
语言代码并输出抽象语法树的工具。这个树上的节点代表语言标识。例如,考
虑一下简单的算术表达式:3+4. 语言分析器会解析他成为一个如图5所示的语
法树。在这个树中,节点+代表操作符标识。节点3和4是操作数标识Hammurapi
使用ANTLR(另一个语言识别工具)作为语言分析器。然而ANTLR API是相当底层的。
为改善可用性,Hammurapi使用另一个API,基于ANTLR 的JSEL(Java源程序
工程类库),来访问抽象语法树。 一旦树构建完成,一种树遍历算法就被用来访
问树中每一个节点。每次访问到一个节点,一种回调机制(Visitor模式)被用来
提示相应的检查器。在这些回调方法中,检查器收集相关的信息来确定是否有违反
规范的地方存在。  
  1. Lint4j
     1)定义:Lint4J是一个针对Java的源代码分析工具,它可以对Java源码和字节
码进行静态分析,判断其中是否存在死锁、性能问题或者伸缩性问题。
它可以集成到任何IDE种或构建系统
2)特点:
1)检测代码语法规则
2)潜在的bug
3)检测编码模式对代码可读性及大小的影响
4)检测是否违反EJB规范
  1. Sonar
     1)定义:代码质量管理工具Sonar提供了设计与架构度量。Sonar 2.0引入了
针对Java应用的设计分析、架构与面向对象的度量,Sonar 2.1可以
检测到未使用的方法以及对不建议使用方法的调用。是一个集成了
CheckStyle,PMD,Findbugs的代码校验规则 ,重复代码发现,
代码测试覆盖率, 代码注释率,及所有的检测率变化追踪的完美
代码质量检查工具。它包含了代码质量检测的七个方面,如下图
2)特点:
        1)代码覆盖:通过单元测试,将会显示哪行代码被选中。
2)改善编码规则。
3)搜寻编码规则:按照名字,插件,激活级别和类别进行查询。
4)项目搜寻:按照项目的名字进行查询。
5)对比数据:比较同一张表中的任何测量的趋势。
6)单元测试
3)Sonar2.1:
Sonar还基于Squid引入了一个全新的规则引擎、Sonar解析器既可以处
理源代码,也可以处理字节码,解析器带有内建的规则,可以检测未使用
的私有与保护方法以及客户端对不建议使用的方法的调用。
Squid通过分析应用源代码、Java API和外部程序库
的字节码来决定哪些方法、类和属性是不建议使用的。
Sonar 2.1的新特性:
1)一个全新的“Libraries”页面,显示了项目中所有的程序库和依赖,该特性要求使用
Maven来构建项目。
一旦在Sonar站点的主页上选择了一个项目,该服务就会以
可视化的树形结构展示出项目依赖。此外,还有一个可选的
动态过滤器,可以根据名称过滤程序库以便在应用的依赖间导航。
2)用于搜索程序库使用情况的“Dependencies”页面。比如说,可以
搜索到使用了第三方框架如Commons Logging 1.1的所有项目。
3)可以使用各种插件扩展Sonar的功能。现在有一个全新的
“System Info”页面显示了系统属性、已装插件和Java虚拟机内存
统计信息。该页面还给出了关于Sonar配置和数据库统计的详细信息。
4)一个用于管理已装插件和系统信息的管理控制台。
最新版的Sonar为这些插件引入了一个测试框架和一个客户化的Maven
生命周期管理工具。它还带有一个用于集成项目事件的
Web Service并在项目的size widget中增加了一个新的度量模块。
  1. JDepend
     1)JDepend一个开放源代码的可以用来评价Java程序质量的优秀工具,
它遍历Java class的文件目录,以Java包(package)为
单位,为每一个包/类自动生成 包的依赖程度,稳定性,可靠度等
的评价报告,根据这些报告,我们可以得到包或类之间的依赖关
系,并分析出包的稳定程度,抽象程度,是否存在循环依耐关系等 。
可以根据JDepend给出的报告数据,分析出我们的包是否是
可靠的,稳定的,健壮的包,是否符合面向对象的设计原则。
2)特点:
1)评价设计质量
2)翻转依赖性
3)支持并行开发和极限编程
4)独立的发布模块
5)识别package的循环依赖
3)Depend生成的Java包的质量评价报告主要包括:    
1)Number of Classes and Interfaces:实现类与抽象接口的数目
2)Abstractness (A):包的抽象度。指一个包内包含的抽象类或接口
占整个包中的类的比重。
3)Afferent Couplings (Ca):向心耦合。依赖该包(包含的类)的外
部包(类)的数目(i.e. incoming dependencies),该数值越大,
说明该包的担当的职责越大,也就越稳定。
4)Efferent Couplings (Ce):离心耦合。被该包依赖的外部包的数目
(i.e. outgoing dependencies),该数值越大, 说明该包越不独
立(因为依赖了别的包),也越不稳定。
5)Instability (I):衡量一个包的不稳定程度。I=Ce/(Ce+Ca)。它的值处于
[0,1]之间。I=0时说明包是最稳定的,反之I=1则说明包极不稳定。
6)Distance from the Main Sequence (D): 该指标主要用来评价包的抽象
程度与稳定程度的平衡关系,它可以用二维直线图 A + I = 1 来表示。
7)Package Dependency Cycles:包的循环依赖度。
8.  IBM Checking Tool for Bugs Errors and Mistakes(简称BEAM)
1) 定义:是 IBM 开发的一个静态分析工具,可以用于分析并查找出 C, C++ 和 Java
代码中的一些不容易发现的潜在错误,从而达到提高代码质量的目的。同动态
分析工具和其它静态分析工具相比,它拥有一些可贵的特性。
2)特点:
1)对代码进行语法扫描,通过算法对代码进行检查分析
2)和一些 bug 模式进行比较,最终标明问题区域,输出分析结果
3)使用了额外的定理证明(theorem proving)技术来判断一个潜在的错误是否
是真正的错误,从而减轻了程序员判断错误真伪所需的工作量
 9. LDRA Testbed  
1)定义:LDRA Testbed为应用软件的确认和验证提供强大的源代码测试和分析功能,
是独特的质量控制工具。 它有助于提高计算机软件必需的可靠性,健壮性和尽
可能的零缺陷,它的使用带来时间、成本和效率上真实的节省,这些都是无法衡
量其价值的。它是强大和完整的集成工具包,使先进的软件分析技术应用在开发生
命周期的关键阶段。
2)LDRA Testbed提供强大的分析功能,用于两个主要的测试领域,静态分析和动态分析。
1)静态分析: 分析代码,并且提供对代码结构的理解。
2)动态分析: 利用源代码的插装版本,使用测试数据执行,在运行时发现软件
缺陷
3) 使用LDRA testbed 的好处
软件开发和测试过程的成本效率分析工具
单元、集成和系统测试的理想工具 
贯穿于软件开发的整个生命周期
LDRA Testbed应用于许多不同的领域 
过程改进
软件测试
软件维护
LDRA Testbed的优点:
改进软件质量
定位软件缺陷
强制执行工业标准
减少维护费用40%以上
减少开发和测试成本75%以上
通过自动化过程提高员工动力
10.   Yasca 
1) 定义:yasca是一个开源静态代码分析工具插件框架, 集成流行的多语言静态分析工
具如findbugs/pmd/jlint/rats/cppcheck,由于插件本身多样故可支持java
c++等语言静态分析.Yasca是一个用来寻找安全漏洞,在程序的源代码中检测代
码质量、性能以及一致性的软件。它集成了其他开源项目,其中包括FindBugs
PMD ,JLint , Cppcheck ,并扫描某些文件类型,以及自定义扫描书面的
Yasca 这是一个命令行工具,与报告中生成的HTML , CSV格式, XML的,的
SQLite ,和其他格式。

posted @ 2011-03-01 17:12 河马虎 阅读(2103) | 评论 (1)编辑 收藏

Servlet 工作原理解析

Servlet 工作原理解析
http://www.ibm.com/developerworks/cn/java/j-lo-servlet/

posted @ 2011-02-26 09:47 河马虎 阅读(350) | 评论 (0)编辑 收藏

JAVA操作WORD EXECEL PDF等文档

 http://danadler.com/jacob/
  http://jakarta.apache.org/poi/
  http://www.onjava.com/pub/a/onjava/2003/01/22/poi.html
  http://www.csdn.net/develop/article/15/15311.shtm
  http://forum.java.sun.com/thread.jsp?forum=40&thread=382666&tstart=0&trange=15

  Java Excel API 文档

  http://www.andykhan.com/jexcelapi/

posted @ 2011-01-07 10:47 河马虎 阅读(264) | 评论 (0)编辑 收藏

界面设计总结

界面设计时应考虑几个问题;

1、界面的布局一定要合理,首先根据应用行业和业务特点,把整个界面切成几个大块,每个块的承担的功能或者任务一定要明确。

2、界面的可不配置化,通过界面的可配置化来屏蔽或者启用一些功能。如果你做的产品或系统被用到同行业的许多项目现场,十几个或者几十个项目现场,那么在界面设计时候就一定要考虑到界面的可配置化。作为特定行业产品或者系统一般都实现了行业的核心的共性功能,但多个项目现场会提出自己本地化或者个性化的需求,在只有一个开发团队维护一个版本情况下,尽量在界面设计的时候,实现界面可配置化,这样A项目现场的本地化需求就不会扩散到B项目的现场,这样有效的控制的需求扩散。另外,产品在不同的产品现场销售或者客户的时候,通过界面的可配置化来屏蔽非本地化的功能,避免无偿将系统功能提供给客户。

3、界面客户配置化,在实现的时候一定要考虑到性能问题,一般为了界面实现可配置,界面是动态生成的,如果界面生成的配置参数放在数据库,那么在系统参与者很多的情况先,界面生成就会很慢,可以考虑将界面配置参数存放在文件中,
 
4、对于界面配置参数文件存放位置,界面配置参数文件一般不要放在客户机上,这样在客户端更新的时候,有可能覆盖了以前的界面配置参数文件,  因此,界面配置参数文件可存放在应用服务器上(例如部署tomcat或者JBOSS服务器上),工程人员或者系统维护人员在系统升级之后,更新该界面配置参数文件, 客户端在启动的时候,从应用服务器上统一读取,这样保持了各个客户端的一致性和可配置性。

5、界面可配置化的程度问题,界面上大块要可配置、数据项或者指标项也要实现可配置。因为不同的项目现场会对大的功能有不同的要求甚至对数据项也有不同的要求。


以上界面设计经验适用于,一个研发团队开发一个产品部署到各个客户现场的情况。如果是小的项目或者各个现场本地化要求不多的,则不适用。

posted @ 2011-01-07 09:51 河马虎 阅读(661) | 评论 (0)编辑 收藏