向banq老师请教一组架构问题

09-07-22 bloodrate
              

这些问题之前和别人讨论过,但是一直没有结论,考虑banq是jdon架构设计者,固前来讨论

1、banq在设计架构的时候用什么建模工具?我一直用Rose,后来发现其实Rose不是一个好的架构设计工具,而是一个应用系统设计工具,因为Rose不支持UML2.0,一些复杂的类关系表述不清,事实上多数架构都存在这些复杂的关系,IBM对Rose的定位是:IBM开发人员开发IBM产品的时候从来不用Rose,而Rose是针对购买IBM产品的其他开发商使用IBM产品进行二次开发应用的随产品附赠应用建模工具,可见Rose在架构设计上是疲软的。

2、也是我主要的问题:UML与架构的关系

都说UML相当于设计图纸,只要图纸有了,照着实现就能做出成品,UML是架构设计的精髓,可是太多的架构设计技巧在UML上面展现不出来,所以这其中就具有一个权衡可视化建模和实际架构代码粒度的问题。

banq在jdon下载包中的doc文件夹下赠送了jdon相关时序图,可是jdon这么些类,这几张图就是九牛一毛,在tomcat6的源代码中也是只有几张简单的图,占tomcat数以百计类中的很小一部分,另外在下载的其他apache开源项目代码中鲜有赠送设计图纸,就算有也是简单的几个类。

我说这个的主要意思是一个架构是一个比较精细的东西,比开发应用精密的多,可能为了扩展性,实现一些功能要写一大堆类,每个类都有架构思想和设计模式的体现,这些东西通过指导性的UML很难一应俱全,到底该怎么权衡这些关系,该不该把每个类,每个实例的生命周期都画在图上?

说的有点抽象,举一个具体的例子:

比如java中的HashMap,在HashMap中定义了静态内部类Entry,这样做的好处是

1、根据数据亲密性原则,将HashMap中关联的数据key和value封装起来

2、这个结构只对HashMap本身有用,所以定义成私有的内部类,以免其他类与Entry产生不必要的耦合

根据两个原则,这个“静态内部类Entry”是一个设计非常严谨,几乎找不到更好决定的决定

但是站在设计HashMap当初的角度上考虑,例如banq老师设计这个HashMap作为架构的核心组成部分,banq会不会用UML表现出HashMap与Entry关系以记录自己的设计决定呢?

一、如果是,就说明在架构设计的UML图纸里面画上HashMap和Entry,这其中设计到的问题包括

(1)UML中很难找到方法表演一个类是另一个类的静态内部类,更难找到方法体现这两种类之间的关系,因为一个内部类可以直接调用外部类的方法。

(2)如果把这些画上了,那么意味着很多其他同等细节的东西也需要在UML上面体现,将会产生一个硕大的难以短时间读懂的图纸。

二、如果不是,则产生的主要问题有

(1)HashMap与Entry关系确确实实是你精心设计的结果,是很重要的部分,不是实现架构时候的灵机一动的决定。

(2)你可能确确实实需要在设计而不是开发阶段能够记录下这个决定,并且很有可能实现架构的人不是设计者你,你也需要保证实现者准确的接收到你的意图。

所以,这就陷入了两难的窘境,我也层试图写架构,可是发现总是无法掌握UML粒度,并且达不到UML指导的作用。经常是知道UML怎么画,但是不知道怎么用UML记录下想法,经常画是一套,做则与图脱节。

              

1
banq
2009-07-23 09:10

不谈请教,讨论讨论吧。

首先,UML适合架构描述吗?这个问题也有讨论,所以专门提出ADL:

Is UML an Architectural Description Language:

http://www.sigplan.org/oopsla/oopsla99/2_ap/tech/2d1a_uml.html

关于使用描述语言ADL或UML或模式语言等描述设计粒度问题,这个恐怕没有一个标准。我个人经验,如果你要特别突出内部Entry这样一个重要但细节的设计的话,你就需要以模式概念表达出来,比如取个名称“内部Entry模式”,在相应的上分类图中标注出来。

其实上帝缺省是阻止人沟通的,所以,任何一个沟通表达方式都有一个缺陷,就是沟通表达元素不能太多,一多就陷入大家对沟通表达元素的学习中,你说明一个软件系统,只要几张主要UML图就可以,而不能面面俱到,反而不突出重点,让别人无法理解。

粒度最小单元到模式为止,有的方法学建议到合约Contact为止,一个Contact是两个类之间互动关系和约束,而模式也基本是两个以上类之间的结构或互动关系与约束。模式或COntact以内就作为白盒子了。

bloodrate
2009-07-23 09:19

我记得Evans书中说过,他不止一两次看见一个项目组画了恨不得一整面墙的UML图,这种图一眼看上去根本找不到中心在哪,Evans反对在画设计图期间过早的陷入细节问题,他也提倡简洁,他说一般人们会画一些图,然后给图中无法表示的东西加上标记注视,但是他不这么做,他会写一个文档,然后再文档的某一章中附上图。我理解Evans可能认为UML对于架构的表现终究是非常有限的,甚至比文字弱得多,所以在做架构的时候应该以文字为主导并附加图纸,而不是以图纸主导附加文字。

bloodrate
2009-07-23 09:19

我记得Evans书中说过,他不止一两次看见一个项目组画了恨不得一整面墙的UML图,这种图一眼看上去根本找不到中心在哪,Evans反对在画设计图期间过早的陷入细节问题,他也提倡简洁,他说一般人们会画一些图,然后给图中无法表示的东西加上标记注视,但是他不这么做,他会写一个文档,然后再文档的某一章中附上图。我理解Evans可能认为UML对于架构的表现终究是非常有限的,甚至比文字弱得多,所以在做架构的时候应该以文字为主导并附加图纸,而不是以图纸主导附加文字。

banq
2009-07-23 09:42

有道理,文字也是一种描述,文字+UML只是描述形式不一样,但是多了还是无法突出重点。架构只是几张图就可以,大道至简。

完整架构描述需要文档+架构UML图。比如NGOSS 或J2EE等文档 API和描述都是完整架构描述的范例。

4Go 1 2 3 4 下一页