ID #55288

架构设计中的方法学(8)-架构愿景1

从这一篇开始,我们将会进入另一个不同的主题,和前面所讨论的模式专注于组织、过程、方法不同,以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。

架构愿景是一个很简单的模式,在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反,它会是设计过程不可或缺的一环。

Context

在单次的迭代开始阶段,我们已经收集好了单次迭代的需求。

Problem

架构和分析设计是密不可分的,有时候很难说得清楚架构的定义,但架构应该能够描述软件的整体。架构包括了软件的各个方面,但是每一个设计细节总是需要单独考虑,这时候就会出现设计细节之间、以及设计细节和架构之间的不一致。

架构设计的各个部分之间的设计冲突是很容易发生的。发生的概率及频率和团队的规模成正比、和沟通的频度及效果成反比。在很多次的项目开发过程中,我们发现了多处的相同功能的代码,原因是代码的作者并不知道别人已经实现了这个功能了。这可能只是浪费了一点精力,可如果不同模块间的设计冲突导致了软件无法正常运行的时候,我们就需要坐下来好好的审视,究竟发生了什么。

Solution

我们需要建立一个架构愿景。架构愿景应该能够提供软件全局视图,包括所有的重要部分,定义了各个部分的责任和之间的关系,而且还定义了软件设计需要满足的原则。而这个架构愿景的设计,应该是满足源自需求模式的,也就是说,部分的划分和部分的设计,都是根据需求而进行的。同时,架构愿景应该要能够满足架构的其它各种特点,例如简单、可扩展性、抽象性。简单来说,我们把架构愿景当作是一个mini的架构设计。

由于我们是在单次的迭代中讨论架构愿景,因此从整体上考虑,架构愿景是也是在不断的变化的。这是很自然的,因为架构愿景代表了架构的设计,架构愿景的演进代表了架构设计的演进。

架构的愿景是相对于一个范围来说的,在一个特定的软件功能范围之内,谈架构愿景才有实际的意义,例如针对软件的全局或某个子模块。在这个特定的范围中,订立了架构愿景之后,这个范围内的所有设计原则将不能违背架构愿景。这是非常重要的,是架构愿景的最大的用处。有了这样的保证,我们就可以保证设计的一致性和有效性。任何一项设计的加入,都能够融入到原先的架构中,使得软件更加的完善,而不是更加的危险。

当然,要做到这一点并不是一件容易的事情。特别需要指出的是,架构愿景模式仅仅是实现该目的的一条道路,并不是一个充分条件。如果在设计中愿景不能够贯彻其意志,或是愿景制定本身就存在问题,那么要想达到上述的效果,几乎是不可能的事情。此外,该模式仅仅只是达到该目的的第一步,我们在接下去的模式中会发现还需要很多方面的配合。

架构愿景的层次

我们根据架构适用范围的不同,把架构愿景分为几个类别讨论:

软件全局

软件全局的架构是我们所最关心的,因此也会花费最多的笔墨。

软件全局中的架构愿景一般很难具体化到代码级别,其实你会发现,就算是具体化到了代码级别,也会因为实际中存在的问题,导致代码没有太多的价值。因此,为软件全局设置的架构愿景可以以原则、或是模式名的方式体现,并用自然语言或伪代码描述。例如,可以为一个系统规定三层架构作为其愿景,并指出三层的分类原则。注意,我们需要指出分类原则,否则规定三层架构并没有太大的意义,因为三层架构随着实现平台的不同、开发人员的不同而有很大的差异,如果不能够规定一个可操作的规范,那么愿景是没有意义的。在Java环境下,我们可以这样说:

"客户端采用前端浏览器界面,业务逻辑采用servlet,配合JSP编写,浏览器到服务器的数据采用集中处理,具体的方法是在业务逻辑和前端浏览器之间采用Front Control模式,接受前端浏览器传送过来的数据,并指派给相应的业务逻辑处理。数据的合法性检验分为两个部分:和业务逻辑无关的基本合法性验证在前端使用Java Script处理,和业务逻辑相关的合法性验证在业务逻辑层处理,可以使用一个集中的servlet专门处理错误情况。"

而在Windows环境下,我们知道三层结构的分界和Java中的并不相同(关于这一点,下一篇的文章中将会有详细的描述),我们可以在业务逻辑层或显示层直接操纵数据,非常的方便,因此,在Windows中的架构愿景的描述又不一样。另外,在非面向对象的环境中,在分布式的环境中,在Lotus Notes的环境中,其架构的描述都不一样。

注意到,架构愿景的制定是根据不同的应用环境而变化的,这一点我们在文章的一开始就强调过,这里又出现了相同的问题。我们可以通过一个简单的例子来加深对这个问题的理解。在Java的环境下,特别是J2EE的环境下面,经典的设计思路是把数据库的一张表视作一个类,表中的每一行都是这个类的一个具体的实例,表的每一个字段对应了类的一个变量,类一般支持Find方法,来获取数据不同的实例。这是一种很自然的设计思路,而且可以通过CMP等技术来简化设计的繁琐步骤。可是,在Windows环境下,相信没有多少人会这么做。常用的处理方法是使用记录集(RecordSet)的方式,也就是说针对一组的记录来进行操作,而不是单个的记录。这些记录可以是跨表的(使用SQL的连接),也可以是单表的。由于Windows环境下大多数的编程语言都能够支持记录集方式,因此编写基于记录集方式的程序是相当简单的。当然,我们也可以采用J2EE平台的编程方式,但是会导致编程量的激增,同时也难以达到预计的效果。这种平台的差别导致了架构愿景的差别。

此外,我们注意到我们对架构的描述其实还是不够仔细,这是非常正常的,因为随着开发的深入,我们会不断的完善架构的描述。例如,我们可以写出Front Controll的类框架,写出主要的几个Servlet,以及他们之间的关系。这个时候,使用UML类图会是一个不错的选择,实际上,我非常推崇在架构设计中大量的使用类图。不过在实际的运作中,每个软件团队大多数都有自己熟悉的架构设计思路,使用何种工具并不是主要的问题。


2011-07-09 13:08
阅读:
I'm VC , Just U know Y
本站部分文章来源于互联网,版权归原作者所有。

延伸阅读:

架构语言ArchiMate-规范

一次进销存软件架构的实践-概述

基于OEA框架的客户化设计总体设计

如何定义和建立架构

企业数据架构建模