据说国外做架构一般用两种工具，一个是大名鼎鼎的IBM Rational Rose，还有一个就是Enterprise Architect。虽然第三方也有很多建模工具很好的支持了UML规范，并且提供了全面的架构功能，但考虑到产品更新换代和IDE契合度上，第三方开源产品缺乏的是专业定期的维护，所以我们最终还是选择相对比较适中的EA来做架构。
首先我们找到EA的破解码，这个还是比较容易做到的。毕竟EA只是一个建模工具，我简单阅读了一下Help文档就自己操作了起来。很直接的想到去Create a new Project，EA提供了很多成型的Model可以选择，例如Business Process、User Case、Domain、Class、Testing、Deployment等等。不过我还是喜欢白手起家，什么都没选，建立一个空的Project之后自己添加Package；我先试着添加了Client和Server两个Package，然后分别对它们建了Domain Model，画了一些Class Diagram，发现EA的设置还是挺死板的，给Class和Interface添加Attributes和Operations比较繁琐，如果要在参数列表中用一些第三方的类或者接口签名，导入的时候居然只支持class和java后缀名，连JAR包都不支持。也就是说要晚上这个Class Model，我不得不把第三方引用的JAR包中的class提取出来，两个字，恶劣！
接着，我试用了一下关联关系的设定，这个EA还是做的相当不错的，很全面！选择Realize的话会自动把Interface的方法添加到实现它的Class中，各种标识static、protected、final、abstract等的设定也很方便，在Class图上也表意很明确。针对Domain Model中的所有Class/Interface，还可以添加其他的Model和Diagram，参考了UML2.1的一些新语法，之后我主要完善了一个Sequence Diagram，它生成的Lifeline很奇怪，在中间没有通信和调用发生的时候都是空的，难道属于无生命周期状态？还是我的理解有错误？不解！
按照之前对项目的需求分析，我就没有再建User Case Model了，其实正规的开发流程应该是从User Case开去驱动下去。模型建立最终还是要跟IDE契合才能发挥作用，否则做的架构就完成只是一张设计图纸而已。EA提供了跟各种IDE进行契合的工具，这些个工具才真EA真正赚钱的地方，在网上找了N久，跟Eclipse契合的插件叫MDG Link for Eclipse，死活搜索不到有可用的License，全部都是.Net的License。难道.Net开发架构人员也经常用EA么？
没有办法只好在Try Version的情况下用了起来，最重要的当然就是把刚才架构的Model按照包结构和约束定义生成在Eclipse的Project里面去。EA支持双向导入，由于本人比较熟悉Eclipse的视图于是就在Eclipse视图下连接EA的建模eap文件，link之后尝试着Generate Package/Code，结果开始是生成的package总是以folder的图标出现，接着调试好不容易整成package图标之后发现EA Project的顶层package（例如是com），会按照规范生成com.**.**包，但是包里面的class和interface居然都是红色的报错状态，所有import语句都把com给丢失了。不断的unlink，再link，偶尔发现在EA关联Eclipse不同步的情况下能生成正确的import语句，但同步之后再生成的还是错误的。
无奈之下回头再研究官方文档，清清楚楚的写着从EA里Merge Eclipse的过程，这回到EA的视图下面进行Merge，Guess what?一切顺利，包名和import语句都准确无误，生成的注释也非常规范，基本上可以用于直接产生JavaDoc。惭愧自己没有按官方推荐的流程操作，同时也感叹EA能很好的契合Eclipse，但从Eclipse的角度未必能完美的配合EA的建模。
初次试用EA做架构，谈不上用得怎么样，只是觉得EA还是一款不错的UML建模工具，能够很好的跟各种语言的IDE契合，生成项目的大致框架和文档，剩下的事情就是按照注释的说明把方法实现而已。我能够看到这样在二次开发的时候会节约大量的人力物力，毕竟靠人的脑子不可能记住所有的细节，但图纸和设计文档可以，而EA可以把你的图纸和设计文档生成程序的完整框架，编码就成了一种给房子装修的劳动了而已。