软件测试开发技术UML和Java的阻抗

软件测试开发技术UML和Java的阻抗  UML模型

关键字：UML

笔者在Jdon已经反复讨论了面向对象的Java和数据库的阻抗不匹配性（mismatch），并提出“数据库时代的终结”。但是，作为同为面向对象的工具实现UML和Java之间也同样存在着阻抗和匹配，在实际应用中，我们常用两种 方式来表达我们的设计意图：Java源码或UML图形，那么哪一个更方便更准确表达设计意图呢？这是仁者见仁智者见智了。 在实际中视使用者爱好。

那么，UML和Java同为表达工具，两者是否一致呢？回答是否定的。 根据Is UML out of date(http://www.step-10.com/objectmodeling/IsUMLOutOfDate.html)一文作者认为两者存在区别，从这篇文章中我们也可以看出UML和Java硝烟战背后的 一些原由，比如由一些UML派的大师在Java领域挑起的EJB和POJO纷争，从该文我们知道这可能是因为UML中无法表达EJB这样的Service性质 特殊operations而引起的；当Java领域争论平息后，UML大师门虽然开始将引导公众焦点转移到其他语言如Ruby on Rails， 但是喧闹过后，遗留下来的是真相，就象潮水退却之后，暴露出来的依然是那些石头一样。

为什么说Is UML out of date一文具有切实性呢？因为作者是参与borland together这类UML建模工具具体实现上的，这是来自实战第一线的疑问和彷徨。在Is UML out of date一文中，作者认为UML和Java阻抗存在两个方面：

UML核闹兄淮嬖赼ttributes属性表达，但是Java从GUI等图形技术创造出了Java Beans概念以后，将这一概念应用到 服务器编程中，将JavaBeans技术推得更远，直至我们最近谈论的POJO，但是你可知道，我们竟然无法方便地使用UML来 表达POJO的属性(Properties)这一概念。

因为JavaBeans的Properties是和UML的attributes是有区别的，例如下面是一个普通POJO代码：

public class A{
　　private String property;

　　public String getProperty(){
　　　　return property;
　　}

　　public void setProperty(String property){
　　　　this.property = property;
　　}
}

A类中属性property其实是一个Properties,Properties定义是：它的值通过一个只读方式获得；通过一个只写方式赋值，而attributes值的获得和更改不一定有如此严格限制。

Properties实际是attribute和类的property访问方法的组合，而且特点就是在访问方法，一般都是通过setXXX赋值；通过getXXX获值，Properties甚至可能根本不需要类内部一定要有一个attribute字段。

原文转自：http://www.ltesting.net