OO系统设计师之路--设计模型系列(1)--软件架构和软件框架[从老博客搬家至此]

这一篇讲软件架构和软件框架在UML设计过程中所起的作用。本系列文章不是专门讨论软件架构和软件框架的，所以不会深入讲怎么做软件架构和软件框架。另一个原因是笔者尚无这个自信能够在这里班门弄斧讲软件架构。之所以要讲，是因为在设计过程中，设计类必然会受到软件架构和框架的约束。从分析类到设计类，软件架构和框架是不得不考虑的一个重要因素。

软件架构和软件框架是一回事儿吗？相信有相当一部分人搞不清楚这个问题，也会有相当一部分人认为是一回事儿，只是不同的叫法而已。架构的英文原文是Architecture,而框架呢，则是Framwork。显然这是两个完全不同的词儿。从技术上讲，IT有一个职业是架构师，架构师代表了软件技术人员最高的职业顶峰，却从没有听说过有软件框架师的。所以肯定的说，软件架构和软件框架是两回事儿。

那么什么是软件架构，什么又是软件框架呢？软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。而软件框架是一个实现，一个半成品，是针对一个特定问题的解决方案和辅助工具。因此，架构是一个逻辑的构成，而框架是一个可用的半成品。比如说，J2EE规范描述了一系列逻辑部件，描述了这些部件的职责和它们的规范，约定了这些部件之间交互的接口和协议、标准，规划出一个如何利用这些逻辑部件来实现一个应用系统的蓝图。J2EE是一个软件架构。而根据这一设想，各产商开发出了各自的产品，包括开发工具和应用容器，开发者利用这些工具和容器就能方便的开发出符合J2EE规范的应用程序。这些工具和容器就是软件框架。再比如，MVC是一个设计模式，它将应用程序划分为实体，控制和视图三个逻辑部件，我们可以说它是一个软件架构。而Strus，JSF，WEBWork等分别以自己的方式实现了这一架构，提供了一个半成品，帮助开发人员迅速地开发一个符合MVC架构的应用程序，我们说Strus,JSF,WEBWork是软件框架。

在一个商业软件的开发过程中，如何去设定软件的架构和框架，在设计过程中，软件架构和框架又是如何影响设计的呢？

软件架构在一个商业系统的开发过程中，是由软件架构师这一角色来完成的。架构师要从很高的角度，根据应用环境，用户需求，公司技术发展要求等等来对这一个系统作出逻辑的划分。例如是集中式还是分布式？采用什么中间件？采用何种技术体系？应用什么标准？符合什么规范？软件的层次是什么？传输协议是什么？与公司其它产品如何衔接？如何使公司产生核心竞争力？可见一个架构师对一个公司的重要性。

可惜架构师这一角色在很大程度上被误解，架构师这一称谓也被滥用。知道几个设计模式，用过几个框架，有过几个中间件或应用服务器的经历，就号称是架构师了。也难怪有人说架构师己死。掌握以上技能的，在我看来，只是经验丰富的设计师而已。因为他能做的，只是应用现成的技术。架构师要做的，是发明J2EE规范，是创造SOA架构，是构架出领先于市场的技术产品，是领导软件技术潮流，是引导软件技术发展趋势。这种差别，就如同科学家和工程师的差别。

因此，在一般的中小企业里，如果没有领先于业界的产品，没有引导了市场的思想，没有称霸一方的应用领域，就不需要架构师这个角色，也产生不了架构师。有几个高级设计师，能紧紧跟住技术潮流，把先进技术玩儿转并应用到自己的产品里，也就足够了。也因此，在一般的商业系统开发过程中，软件架构这一个领域，最主要的工作是选择适合自己的现成的软件架构。换句话说是用好现有的技术。比如，决定采用J2EE架构。再能做的一点，是划分软件逻辑层次，决定使用的标准和规范。

作为例子，一个软件架构和商业系统开发过程中可以用这样的形式来表述：

一个软件架构的表述例子：

有的读者可能会说，没什么难的嘛，我也懂，我们的项目也是这样做的。呵呵，是的，在很多人心目的，架构师做的可能就是这样的工作。可是仔细想想，虽然懂得这么多已经不容易了，可这样的人并不少见，那不就是满天都是架构师了么？虽然这个工作的确是在做软件架构，可是我认为并不能称为架构师，顶多是高级设计师，懂得如何应用现有技术而已。

好了，软件架构已经定下来了，现在该由设计师（实际上，绝大多数公司里的架构工作也是由设计师来做的）来决定每一个层次的具体框架设计了。下面的例子，是以Entity层作为例子来表述框架的。

Entity层框架的例子:

这个例子只给出了静态图。为了让开发人没明白这个设计，还应当给出交互图。例如，如果应用程序增加一个VO，Business层怎么调用EntityControl，EntityControl如何分解VO，怎么访问Relationship,怎么处理PO，怎么访问DBControl层。也就是这些框架基类如何交互来完成业务要求。这个图笔者就不再绘制了。建议有兴趣的读者设计自己的框架，并自己绘制这些交互图。自己动手认识会更深。

架构有了，框架也有了，对于设计类来说，架构和框架形成了规范，设计类必须遵守这些规范，并了解如何使用框架的接口。当然，这个架构和框架仅仅是一个例子，现实中的架构和框架可不仅仅这一点，考虑的东西会更多，比如日志如何处理，事务如何处理，异常如何处理。每一个可能又都是一个框架。另外，如果选择了某一个成熟产商的架构，例如Websphere,Weblogic，可能就不需要自己来设计架构和框架了，这些产品已经提供了。

这一篇就到这里。下一篇本来是应当讲如何从分析类到设计类的，不过觉得好象没什么可讲，因为框架既然规定了，并且正常的业务逻辑都已经由框架处理了，分析类转化成设计类应当是一件水到渠成的事情。笔者还在考虑下一篇该写些什么，就暂不预告了。