软件的架构设计

RealArthur

好的开始相当于成功一半

开始之初的架构设计决定着软件产品的生死存亡。“好的开始相当于成功一半”。

开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持。再结合自己项目的特点(需要透彻的系统分析)，才能逐步形成自己项目的架构蓝图。

比如要开发网站引擎系统，就从Yahoo的个人主页生成工具 到虚拟主机商提供的网站自动生成系统，以及IBM Webphere Portal的特点和局限 从而从架构设计角度定立自己产品的位置。

好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法

由于在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还需要对方案进行修改，属于那种螺旋上升的方式，显然这是通过测试第一的思想和XP工程方法来实现的。

如果我们开始的架构设计在技术平台定位具有一定的世界先进水平，那么，项目开发实际有一半相当于做实验，是研发，存在相当的技术风险。

因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍（加入人工干预），以检验各个技术环节是否能协调配合工作(非常优秀先进的两种技术有时无法在一起工作)，同时也可以探知技术的深浅，掌握项目中的技术难易点。这个过程完成后，我们就对设计方案做出上面的重大修改，丰富完善了设计方案。

设计模式是支撑架构的重要组件

架构设计也类似一种工作流，它是动态的，这点不象建筑设计那样，一开始就能完全确定，架构设计伴随着整个项目的进行过程之中，有两种具体操作保证架构设计的正确完成，那就是设计模式(静态)和工程项目方法(RUP或XP 动态的)。

设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物建立设计需要建筑架构设计，在具体施工中，有很多建筑方面的规则和模式。

我们从J2EE蓝图模式分类http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE这样一个框架软件的架构与设计模式的关系。

架构设计是骨架，设计模式就是肉

这样，一个比较丰富的设计方案可以交由程序员进一步完成了，载辅助以适当的工程方法，这样就可保证项目的架构设计能正确快速的完成。

时刻牢记架构设计的目标

由于架构设计是在动态中完成的，因此在把握架构设计的目标上就很重要，因此在整个项目过程中，甚至每一步我们都必须牢记我们架构设计的总体目标，可以概括下面几点：

1. 最大化的重用：这个重用包括组件重用 和设计模式使用等多个方面。

比如，我们项目中有用户注册和用户权限系统验证，这其实是个通用课题，每个项目只是有其内容和一些细微的差别，如果我们之前有这方面成功研发经验，可以直接重用，如果没有，那么我们就要进行这个子项目的研发，在研发过程中，不能仅仅看到这个项目的需求，也要以架构的概念去完成这个可以称为组件的子项目。

2. 尽可能的简单明了：我们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。但是在具体实施设计过程中，我们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，因此如何尽可能的做到设计的简单明了是不容易的。

我认为落实到每个类的具体实现上要真正能体现系统事物的本质特征，因为事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了，越简单明了，你的系统就越可靠。更多情况是，一个类并不能反应事物本质，需要多个类的组合协调，那么能够正确使用合适的设计模式就称为重中之重。

我们看一个具备好的架构设计的系统代码时，基本看到的都是设计模式，宠物店(pet store)就是这样的例子。或者可以这样说，一个好的架构设计基本是由简单明了的多个设计模式完成的。

3. 最灵活的拓展性：架构设计要具备灵活性 拓展性，这样，用户可以在你的架构上进行二次开发或更加具体的开发。

要具备灵活的拓展性，就要站在理论的高度去进行架构设计，比如现在工作流概念逐步流行，因为我们具体很多实践项目中都有工作流的影子，工作流中有一个树形结构权限设定的概念就对很多领域比较通用。

树形结构是组织信息的基本形式，我们现在看到的网站或者ERP前台都是以树形菜单来组织功能的，那么我们在进行架构设计时，就可以将树形结构和功能分开设计，他们之间联系可以通过树形结构的节点link在一起，就象我们可以在圣诞树的树枝上挂各种小礼品一样，这些小礼品就是我们要实现的各种功能。

有了这个概念，通常比较难实现的用户级别权限控制也有了思路，将具体用户或组也是和树形结构的节点link在一起，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具备很灵活的拓展性。

无双

好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法


没有完美的设计
所以只要能达到一定要求后就可以了

我觉得好的设计是随着设计者经验的增加而增加的

RealArthur

是啊，所以我们现在大多数的设计开始都可以去参考一些现有的模式，了解相关产品、项目的架构，理解成熟的设计模式，结合实际选取你需要的，由简单到复杂过反复修改验证，没有完美，实际中也不要去追求完美，只要能达到一定要求后就可以了 。
这其中，系统分析、设计师的经验是很重要的！

无双

所以软件是不断进化的
而不是一下子就OK了 这是与建筑的不同

也就是演进模型存在的必要性

无双

楼上的总结很有深度啊 总结了软件各阶段的发展
很高兴能看到这样的发言
看到软件以后的发展方向

无双

我觉得早期是过程语言的原因也是想依照那时工作流水线形式的
并且是机器语言

想使用OO是不可能的

后来系统的复杂和需求变化很快使OO设计出现 在这个方面过程式设计不能满足要求

再后来随着网络的发展
大家对电脑的分工明确了

会使用专门的电脑解决专门的问题
所以这时C/S B/S开始出现 想想以前学习的foxpro可以用来做一个工资管理系统或是数据库系统 并且数据库引擎与程序结合在一起
但现在一般都是使用专门数据库 客户也是专门的客户端

再以后 应该是软件无处不在的时候 每一个软件都会和其它系统上的软件互相通信 由于厂家广泛 所以接口标准的制定就决定了自己的竞争地位 很多标准都是公开的 但为什么还有那么多厂家参与呢
因为他们希望自己能在竞争中掌握主动权

以后的软件应该是使用统一接口开发 实现plug &play的时候 也就是随便把其它厂家软件拿下来也可以运行

这是我想的

也想看看大家对这的看法

无双

B/S一般用于广域网或是INTERNET上

但是由于开放
我想在安全方面不好控制
还有就是性能

所以特定部分或是区域使用的软件还应该还是C/S

无双

主要是因为web都是以明文传送的

所以不是很安全