Java开发网 - Java软件架构设计慨论(转载)--设计模式和系统架构的关系

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

Java软件架构设计慨论(转载)--设计模式和系统架构的关系

九佰

版主

发贴: 983
积分: 126

于 2006-03-22 16:20

系统的架构和设计模式是怎样的关系？请看下面的文章:

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

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

　　比如要开发网站引擎系统，就从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在一起，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具备很灵活的拓展性。

http://www.teamlet.org

海纳百川，有容乃大
壁立千仞，无欲则刚
智者不惑，勇者无惧
止戈为武，仁者无敌

作者

Re:Java软件架构设计慨论(转载)--设计模式和系统架构的关系 [Re:九佰]

floater

Java Jedi

总版主

发贴: 3233
积分: 421

于 2006-03-29 12:21

A software system can be divided into different components according to its functionalities. Though there are many ways to divide a system, the business functionalities are central to the entire system, and thus is a more appropriate way to divide the system (so we have the term - domian driven design, or DDD in short). Each component is more or less self contained and independent(high cohesive and loosely couple, in fancy terms), e.g., we don't want to insert, update, and delete methods for a same single object in seperate components, and we don't want to mix UI and DAO classes in one component unless there is nothing else and the size of the system is very small(and it could grow really large).

Depends on the size of the system, each component itself can be a large subsystem, and so on. Nonetheless, we always try to recursely divide a large system to smaller components so that the smallest components can be handle d by teams of size 8-12 folks(a managable size of a team), or even just one person. So eventually, we convert the communications between components to team communications.

These smallest, managable components are the pivoting points in the entire system because they largely divide the design and implementation. Consequently, their interfaces and above belong to system design, which should be done before any lower implementations start. Because the system design is more relevent to business logic, there is really no room for saying in computer terms, like framework, design patterns. So I call the commnunications at this level "businessman's talk". *A good system design should let us seperate system concerns and application concerns, and further, let us hide the system concerns*. This is the principle that we should follow at this level. For example, Spring has two ejb access factory beans(local/remote) such that we can use them to inject service interfaces to other classes, rather than expose the JNDI lookup. This enable us to use other component services without caring how to get them, so when components communicate with each other, they can just call each other in business manners. Similarly, Spring provides other expose/lookup methods for RMI, HTTP, etc, convenient factory beans. Sometimes, Spring is not enough and we have to write our own classes, and we should follow the same principle as mentioned above.

On the other hand, the implementations for the smallest components can't hide the system concern, instead they should isolate these concerns and make good use of them. This is where the design patterns are used, they are used to design technical implementations, not for business talks. For example, caching is really a system concern, your system should be able to run with or without caches. A better design of the implementation is write a version without caching, then use a decorator pattern or AOP on top of that. Spring MVC is a nice web frameworks, they let us treat some of the common concerns as a system concern, e.g., the view pages can be jsp, vm, fm, so that we can swap out to a different implementation. So at this implementation level, we fix the component interfaces and throw all our energy to make the implementation better, with all the tools we can find.

Even this is largely at the implementation level, we still need designs at this level because it could contains tens or hundreds of classes. The difference between this level and the system design is that we have to consider both business and system concerns.

Finally, everything is relative. The divider between the system design and implementation can shift overtime when complexity changes. The divider between application concerns and system concerns can change to. So constant cleanup/maintanence/refactoring is needed.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring - Improving the Design of Existing Code

已读帖子

新的帖子

被删除的帖子