软件架构设计实践教程 软件架构设计

系统架构设计师如何应用实践呢？

开始之初的架构设计决定着软件产品的生死存亡。

“好的开始相当于成功一半”。

开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持。

再结合自己项目的特点（需要透彻的系统分析），才能逐步形成自己项目的架构蓝图。

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

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

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

因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍（加入人工干预），以检验各个技术环节是否能髋浜瞎ぷ？非常优秀先进的两种技术有时无法在一起工作），同时也可以探知技术的深浅，掌握项目中的技术难易点。

这个过程完成后，我们就对设计方案做出上面的重大修改，丰富完善了设计方案。

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

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

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

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

软件架构设计的三个维度是什么？

构设计是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。

这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。

架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。

这三个维度分别为面向对象、面向方面、面向服务。

这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。

图：架构三维度结构图 面向对象 面向对象技术最初是从面向对象的程序设计开始的，它的出现以上世纪60年代Simula语言为标志，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前思想的重新注解。

上世纪80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。

直到现在，面向对象已经成为一种非常流行的编程方式，以及软件设计的架构。

面向对象提出有三个主要目标：重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。

它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。

在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。

面向方面 面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。

面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。

如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。

简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。

面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。

我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。

当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。

当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。

这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。

面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。

面向服务 面向服务可以说是最近炒得比较火热的概念。

包括现在提到的SaaS(Softwae as a sevice)，软件即服务。

准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。

社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。

最早社会的主要产业是第一产业农业，将近有几万年的历史。

十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。

现在仍然属于工业时代，或者有人说的“后工业时代”。

而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。

面向服务其实是社会经济体制重心的一种迁移。

还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。

面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。

而说到架构层面，面向服务是系统发布功能的一种方式。

并且基于这种方式下不同的系统之间能有效地通信、协作。

常见的实现技术就是We Sevice。

软件全局观 软件架构设计的三个维度：面向对象、面向方面、面向服务。

最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。

它解决的问题是系统内部结构的设计。

面向方面思想的提出能够弥补面向对象的缺陷。

面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。

面向方面与面向对象一样都是解决系统内部结构的设计。

面向服务更多的是涉及到系统的外部，简单地说就是发布功能。

它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。

这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。

我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。

软件架构的设计应该遵循什么样的开发过程？

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系 统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向 对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。

软件体系结构是构建计算机软件实践的基础。

与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。

特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。

结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。

构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。

它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。

一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管 理软件产品的高级设计。

软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

一般而言，软件系统的架构（Architecture）有两个要素： 它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。

显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

用什么工具画 软件架构设计图

2，必须包括：磁盘文件读写、异常捕捉、日志记录，包括：配置管理、国际化服务可以采用UIDesigner软件结合UIDesigner的实际需求，提取出属于“工具”范畴的关键功能需求.“工具”的关键质量需求，因此，对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。

3.“工具”的关键商业需求，因为UIDesigner本身并没有很复杂的业务需求，因此关键商业需求是在设计流程的优化和规范上得到体现，这方面的设计已经属于高层模块和使用流程的设计。

1、缓存管理、线程服务，对架构的影响非常小，而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求.“工具”的关键功能需求、安全性管理，质量需求包括开发期质量需求和运行期质量需求两部分，经过分析和权衡，UIDesigner的性能主要取决于设计绘图；非工具所必须，但是UIDesigner本身所要求的、服务器和客户端通讯管理、关键质量需求和关键商业需求 展开...

【系统架构和软件架构】正交软件架构方法

果你想要制作易于设计、构建、测试及扩展的系统，正交性是一个十分关键的概念，但是，正交性的概念很少被直接讲授，而常常是你学习的各种其他方法和技术的隐含特性。

这是一个错误。

一旦你学会了直接应用正交性原则，你将发现，你制作的系统的质量立刻就得到了提高。

什么是正交性 文本框： “正交性”是从几何学中借来的术语。

如果两条直线相交成直角，它们就是正交的，比如图中的坐标轴。

用向量术语说，这两条直线互不依赖。

沿着某一条直线移动，你投影到另一条直线上的位置不变。

在计算技术中，该术语用于表示某种不相依赖性或是解耦性。

如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。

在设计良好的系统中，数据库代码与用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动界面。

在我们考察正交系统的好处之前，让我们先看一看非正交系统。

非正交系统 你正乘坐直升机游览科罗拉多大峡谷，驾驶员——他显然犯了一个错误，在吃鱼，他的午餐——突然呻吟起来，晕了过去。

幸运的是，他把你留在了离地面100英尺的地方。

你推断，升降杆控制总升力，所以轻轻将其压低可以让直升机平缓降向地面。

然而，当你这样做时，却发现生活并非那么简单。

直升机的鼻子向下，开始向左盘旋下降。

突然间你发现，你驾驶的这个系统，所有的控制输入都有次级效应。

压低左手的操作杆，你需要补偿性地向后移动右手柄，并踩右踏板。

但这些改变中的每一项都会再次影响所有其他的控制。

突然间，你在用一个让人难以置信的复杂系统玩杂耍，其中每一项改变都会影响所有其他的输入。

你的工作负担异常巨大：你的手脚在不停地移动，试图平衡所有交互影响的力量。

直升机的各个控制器断然不是正交的。

正交的好处 如直升机的例子所阐明的，非正交系统的改变与控制更复杂是其固有的性质。

当任何系统的各组件互相高度依赖时，就不再有局部修正（local fix）这样的事情。

提示13 Eliminate Effects Between Unrelated Things 消除无关事物之间的影响 我们想要设计自足（self-contained）的组件：独立，具有单一、良好定义的目的（Yourdon和Constantine称之为内聚（cohesion）[YC86]）。

如果组件是相互隔离的，你就知道你能够改变其中之一，而不用担心其余组件。

只要你不改变组件的外部接口，你就可以放心：你不会造成波及整个系统的问题。

如果你编写正交的系统，你得到两个主要好处：提高生产率与降低风险。

提高生产率 l 改动得以局部化，所以开发时间和测试时间得以降低。

与编写单个的大块代码相比，编写多个相对较小的、自足的组件更为容易。

你可以设计、编写简单的组件，对其进行单元测试，然后把它们忘掉——当你增加新代码时，无须不断改动已有的代码。

l 正交的途径还能够促进复用。

如果组件具有明确而具体的、良好定义的责任，就可以用其最初的实现者未曾想象过的方式，把它们与新组件组合在一起。

l 如果你对正交的组件进行组合，生产率会有相当微妙的提高。

假定某个组件做M件事情，而另一个组件做N件事情。

如果它们是正交的，而你把它们组合在一起，结果就能做M x N件事情。

但是，如果这两个组件是非正交的，它们就会重叠，结果能做的事情就更少。

通过组合正交的组件，你的每一份努力都能得到更多的功能。

降低风险 正交的途径能降低任何开发中固有的风险。

l 有问题的代码区域被隔离开来。

如果某个模块有毛病，它不大可能把病症扩散到系统的其余部分。

要把它切掉，换成健康的新模块也更容易。

l 所得系统更健壮。

对特定区域做出小的改动与修正，你所导致的任何问题都将局限在该区域中。

l 正交系统很可能能得到更好的测试，因为设计测试、并针对其组件运行测试更容易。

l 你不会与特定的供应商、产品、或是平台紧绑在一起，因为与这些第三方组件的接口将被隔离在全部开发的较小部分中。

让我们看一看在工作中应用正交原则的几种方式。

项目团队 你是否注意到，有些项目团队很有效率，每个人都知道要做什么，并全力做出贡献，而另一些团队的成员却老是在争吵，而且好像无法避免互相妨碍？ 这常常是一个正交性问题。

如果团队的组织有许多重叠，各个成员就会对责任感到困惑。

每一次改动都需要整个团队开一次会，因为他们中的任何一个人都可能受到影响。

怎样把团队划分为责任得到了良好定义的小组，并使重叠降至最低呢？没有简单的答案。

这部分地取决于项目本身，以及你对可能变动的区域的分析。

这还取决于你可以得到的人员。

我们的偏好是从使基础设施与应用分离开始。

每个主要的基础设施组件（数据库、通信接口、中间件层，等等）有自己的子团队。

如果应用功能的划分显而易见，那就照此划分。

然后我们考察我们现有的（或计划有的）人员，并对分组进行相应的调整。

你可以对项目团队的正交性进行非正式的衡量。

只要看一看，在讨论每个所需改动时需要涉及多少人。

人数越多，团队的正交性就越差。

显然，正交的团队效率也更高（尽管如此，我们也鼓励子团队不断地相互交流）。

希望能帮到你，麻烦点击 好评，...

进行软件架构设计有什么样的益处？

一般来说，软件架构设计是降低成本，改进质量，按时交付产品和按需交付产品的关键因素。

在这篇文章中，我将会把讨论的焦点放在实现这些目标所能带来的好处上面。

作为一个构架师，证明我们的存在是没有任何意义的。

这个部分将会提供一些方法，这些方法对于把处理架构设计作为一个软件开发过程的关键部分是很有用处的。

架构设计能够满足系统的品质 系统的功能性是软件构架师通过组成体系架构的多种元素之间的交互作用来支持的。

然而，架构设计的一个关键特性是，系统的品质是通过某些手段来实现的。

软件的品质，例如性能，安全性和可维护性等，它们在缺少统一的架构设计视图时是无法实现的，因为这些品质并不是被限制在一个单一的架构设计元素中，而是渗透在整个架构设计体系中的。

例如，为了满足性能要求，可能需要考虑体系架构中的每一个组件的实现时间，同时还要考虑各组件之间通讯所花费的时间。

同样地，为了满足安全性要求，可能需要考虑两个组件之间自然的通讯，并且要在需要的特定的地方引入安全性提示组件。

所有的这些关系都属于体系架构，在上面的例子中，这些关系包括组件自身的和组件之间的。

转载请注明出处51数据库 » 软件架构设计实践教程