使用UML图attribute表达property如下：（引自Is UML out of date一文)
这样的图从表面上看不错，但是问题来了：一些建模工具的代码产生器根本无法识别这是一种POJO的Properties表示，因此我们可能无法产生普通POJO代码（进而无法使用POJO的优点了），那么只有画图者使用手工来实现，这很烦琐，失去了使用UML工具帮助我们设计的目的了。
Borland的 Together是通过拓展UML核心概念，引入Properties这样一个和attributes类似新的定义来表达。 如图（引自Is UML out of date一文)：
左边是Property表达，右图是Together可自动展开的Property表达，setXXX和getXXX方法都会自动产生。
Services vs Operations
UML和Java不匹配之处还在于UML无法区分表达Services和Operations区别，在当今SOA面向服务为主要概念的 Java实现领域，UML竟然无法清晰地表达Service接口和普通接口的区别，让我们来仔细看个究竟：
首先，我们看看Operations的定义：在接口中的一个行为Operations可能代表一段业务事务处理过程，供外部客户端调用（如供表现层调用等，这些行为这时称为提供服务Services），但是，一些public行为可能只是用于业务层内部系统之间相互调用，而不是展现给外部，供外部 系统或客户端调用的，一些行为也许只是为主要业务逻辑提供辅助技术帮助的，根本不是主要业务逻辑方法，还有一些行为只不过提供对内部属性attribute的访问方法罢了。
UML如何区别同样的行为Operations不同的内外调用目的呢？实际也就是供外部调用的Service和内部调用的普通Operations 区别呢？
例如，我们有两个服务Service接口Class1Services和Class2Services，这是对外暴露，不仅可供表现层客户端调用，还可通过Web Services向 外部系统提供，另外还有两个类Class1和Class2是供内部调用的，当使用UML表达时，如下图（引自Is UML out of date一文)：
UML复杂的继承关系已经扰乱我们的视线，我们已经无法区分这两种类（Services和普通Operations）区别；而下图中是使用 Java Design and Streamlined Object Modeling 一书中简化的表示方法，我们可以分清这两种区别。
所以，对于同样是POJO的两种类不同功能实现Services和普通Operations UML已经表现得无能为力了，那么对于服务Service概念 起源组件EJB，UML更加苍白，笔者猜想，怪不得UML设计界拼命诋毁EJB，包括Matin Fowler还亲自出场，原来UML和EJB之间是一场不是你死就是我活的战斗，总算EJB发展到EJB3也变成了一个纯粹的POJO，但是EJB带来的Service概念还是在POJO中保留下来，同时基于Web Services的SOA 概念的兴起将服务Service概念推向更深处，尽管Matin Fowler等UML设计派还在对SOA说“风凉话”，但是UML如果自身不象Java那样与时俱进地更新换代，那么它与Java之间的阻抗不仅仅是表达形式的不匹配，恐怕就变成先进与落后
文章来源于领测软件测试网 https://www.ltesting.net/
