中文类名

彩色UML图可以用即时贴在白板上设计，也可以使用支持UML图的工具画出。但是使用工具要注意一点，就是设计好的模型应该打印出来，贴在墙上，让经过的人都可以驻足观看，发表意见。这就是敏捷方法学中的信息辐射原理。沟通无时无处不在。

这样做的好处是明显的。每个人都有机会熟悉全部的业务流程，以达到对系统的一致理解。有疑问，早提出。特别是领域（业务）专家，可以不断想起点什么要补充的。

但是有一个问题：类名应该使用英文吗？

和用户沟通有一个重要的原则，要使用用户熟悉的语言和图表。画用户看得懂的UML图。如果用户英文不好，如果用户平时都讲中文，所有的领域词汇都是中文，那么用英文的类名画出的彩色UML图挂在墙上就有点小麻烦了。

有一个改进方案，在类名后面用括号注明中文意义，如：OrderMaking（下订单）类，这是一个红色的时刻-时段。

还留着英文类名是为了写程序的方便。这样我们维护了一个映射关系，即中文领域词汇和英文类名的映射。当然，也可以创造性地使用拼音，如：XiaDingDaning（下订单）。

但是我记得以前试过，在Java里可以直接使用中文类名。所以又试了一下。

public class Main {

public static void main(String[] args) {
下订单 这次下订单 = new 下订单();
这次下订单.确定();
}

}

class 下订单 {
public void 确定() {
System.out.println("Good!");
}
}

哈，可以运行！也许业务层代码这样写更好玩。

用例和特征

Alistair Cockburn在他的《编写有效用例》一书中指出，“海平面用例”的特点如下：

• 一个人、一个地点、一个时间（2至20分钟）
• 完成了就高兴地离开
• 参与者（如果是职员）做了很多这样的事，可以要求获得加薪或升职

在特征驱动开发中，特征集是

• [action](ing) a(n) [object]

例如，“进行一次产品销售”

所以在大致上，我们可以将特征集与“海平面级用例”对应起来。因为如果“销售员”完成了很多“进行一次产品销售”或做得很好（销售额大），就有理由提出升职或加薪要求。

在特征驱动开发中，特征是

• [action] the [result] [by|for|of|to] a(n) [object]

例如，“计算一次销售总额”。

虽然做很多的“计算一次销售总额”不能导致升职或加薪，但这个特征对于客户来说显然是有价值的。所以在大致上，我们可以将特征与“水下级用例”对应起来。

在特征驱动开发中，主特征集是

• [object] management

例如，“产品销售管理”。

“天空或汇总级用例”反映了多个人的目标，例如“保险购买、支付和理培”。所以大致上，我们可以把主特征集和“天空级用例”对应起来。

彩色书中文版上市了

彩色书中文版终于上市了！

Peter Coad是我仰慕的前辈大师。大约在1997年，朋友李亮向我介绍了他和Edward Yourdon合作的《面向对象设计》。那是一本小册子，我一看就喜欢上了。全是经验之谈，没有东抄西抄。原书是1991年出版的，中文译本是1994年出版的。

没想到多年以后，以这样的方式接近大师。彩色书的原书是1999年出版的，距现在也快10年了。一年以前，我向推荐华章推荐引进这本书。今天，终于与中国的开发者见面。

在2000年左右，敏捷方法学开始兴起。过了几年，我注意到了敏捷方法学中有一枝是特征驱动开发（FDD）。这种敏捷开发方法有一个特别的地方，它强调整体对象建模，即前端设计。而且采用了一种极有特点的彩色UML建模的方法。然后我看到这种方法背后大师的名字。

网上关于彩色UML的内容不多，但我还是设法搜集了一些。这些年，我一直在研究Java、工作流、开发方法学、UML建模方面的内容。等到我看到FDD和彩色UML，这些内容忽然就贯通了，有一种醍醐灌顶、任督二脉打通的感觉。

好的东西就是你从未想过拥有，但是一旦拥有，就别无所求。彩色UML给我这样的感觉。

有一年Martin Fowler到上海，在交大和林德彰教授讨论软件开发方法学，还发生了一件趣事。林教授把传统方法学比喻为楷书，把XP比喻为草书，认为先要打好楷书基础，然后才能学草书。当时我提出，敏捷方法中的FDD注重前端设计，同时又保持轻量级方法学的特点为，可能是行书。会后，一个白人老外专门跑过来跟我交流，说谢谢我提到彩色UML和FDD，并说他们的公司在张江，在开发时就采用这套方法学，效果很好！

曾经跟华章的编辑开玩笑说，这本书不引进，是中国计算机出版界的羞耻啊。现在我要对他说，功德一件！

服务治理

几年前，为了尝试JDK 1.5中的并发包，我写了一个多线程的爬虫程序，利用线程池来分析B2C网站上的商品价格，希望可以做一个shopping.com那样的比价网。

并发200个线程，每个线程从待爬URL队列中取得一个URL，取回网页，进行分析，找出其中的价格信息，再找出其中的URL链接。开发过程很正常，但在测试中遇到了问题。在爬了7万多个网页之后，程序开始越来越慢。凭感觉判断，有一些线程“死”掉了。

多线程的调试并不是件容易的事。这个问题很“难”再现。不是普通意义上的难再现，它每次都会出现。但要跑到7万多URL时，才会出现。我试过将线程池退化到1，想找出什么样的URL会导致线程死掉，但这个代价太大了，因为速度很慢。当时的IDE也缺乏对多线程调试的一些支持。而且即便有支持，可能也不太适合这种情况。后来因为种种原因，那个程序就不了了之了。

最近接触的SOA治理和彩色UML的内容给了我一些启发。我们需要关注服务执行的健康状况和服务执行的时间。例如，我们可以进行这样的改动：

在每个线程领取URL时，记录一个时间戳。在它完成这个URL处理时，再记录一个时间戳。再利用一个线程，对未完成的URL定时检查它的健康程度。如果在很长的一段时间内它还没完成，那么它就有问题。这样我们可以找到嫌疑URL。我们可以对这种URL单独测试，看看是否因为程序的原因，不能处理这样的URL。

或者，我们可以把对应的线程任务杀掉，直接跳过这些有问题的URL。

程序在设计时，要考虑运营维护需求，其中包括迅速故障疹断和纠正能力。这就是传说中的“可用性”需求吧。