权鸿
编写软件架构文档说明,第 1 部分： 什么是软件架构,为什么为软件...
引言 软件架构是一门学科，开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。
与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。
在本系列中，您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的；每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关，并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别，存在一些混淆。
正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 （C1）。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。
对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。
作为一门学科，软件架构是非常成熟的。
您可以利用最佳实践和指导...
如何做好架构设计与写好架构设计的文档？
2 一下是我的写文档的一些心得：现代架构设计文档的编写4+1 视图与 UML 软件架构设计已经逐渐成为现代软件开发过程的核心，然而能够清晰表明架构设计并不是一件容易的事，就面向对象开发而言， RUP 的 4+1 视图已在架构设计的撰写中得到了广泛的应用和认可。
对于 4+1 view 的描述有几个不同版本（或包含的视图不同，或视图的名称不同），文中以 Philippe Kruchten, November 1995 提出的 4+1 视图为准。
4+1 视图包括：逻辑视图（ Logic View ），开发视图（ Develop View ），进程视图（ Process View ），物理视图（ Physical View ）和场景视图（ Scenarios ）。
视图间的关系4+1 视图不仅便于我们记录架构设计，实际上它也指导了我们进行架构设计活动的部分过程。
通常我们选择 UML 来表现各种视图，以下列出了 UML 和各视图的对应关系4+1 视图 UML场景视图 use case逻辑视图 类图开发视图 类图，组件图进程视图 无完全对应部署视图 部署图在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。
但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。
在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。
融入 MDA 的思想 对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。
逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。
而开发视图则会与实现技术紧密相关。
随着 MDA 思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把 MDA 的 PIM 和逻辑视图联系起来，而把 MDA 中的 PSM 和开发视图联系起来。
在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。
如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为 EJB 组件（实体 Bean ）。
这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。
用什么工具画 软件架构设计图
可以采用UIDesigner软件结合UIDesigner的实际需求，提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
1.“工具”的关键功能需求，必须包括：磁盘文件读写、异常捕捉、日志记录、安全性管理；非工具所必须，但是UIDesigner本身所要求的，包括：配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
2.“工具”的关键质量需求，质量需求包括开发期质量需求和运行期质量需求两部分，经过分析和权衡，UIDesigner的性能主要取决于设计绘图，而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求，因此，对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
3.“工具”的关键商业需求，因为UIDesigner本身并没有很复杂的业务需求，因此关键商业需求是在设计流程的优化和规范上得到体现，这方面的设计已经属于高层模块和使用流程的设计，对架构的影响非常小，可以暂时性的忽略。
经过关键需求的提取，我们得到了“工具”的设计目标——可以提供通用功能（关键功能需求）的高稳定性、扩展性和维护性的客户端应用。
根据此目标，我们采取DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构，概念架构设计如图2所示。
展开...
java软件开发的架构设计
软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。
从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。
其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展，层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。
依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。
这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。
但软件架构毕竟是建立在当前技术之上的。
而每一代技术都有架构模式。
过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。
我们从三层次架构谈起：因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。
cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。
JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。
推荐作为持久层的首选在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。
而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层，虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。
struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务（tool:jaas）、流程控制服务workflow、动态实现服务IOC，串行化消息服务（tool:jms）、负载平衡服务blance等。
如果我们不采用重量级应用服务器（如weblogic,websphere,jboss等）及重量级组件（EJB），我们必须自己实现其中一些服务。
虽然我们大 多情况下，不需要所有这些服务，但实现起来却非易事。
幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要，一些xml文档操作工具（DOM,Digester,SAX等）的使用愈发重要，而随着 xml schema的java binding工具（jaxb,xmlbean等）工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式，而这又进一步使数据中心向xml转移，使在中小数据量上，愈发倾向于以xquery为查询语言的xml数据库。
现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如（microsoft office之infopath），可以直接从xml schema 生成录入页面等非常实用的功能。
还有web service 的广泛应用，都将对软件的架构有非常重大的影响。
至于面向服务架构（SOA）前景如何，三层次架构什么时候走入历史，现还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。
也许作为一个很好的思想，它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样，广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
软件的架构与设计模式之什么是架构
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。
所有的数字都如日历般严谨，风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。
（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。
与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。
英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。
丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
Party这个词的原意就是＂方＂、＂面＂。
政党起源的要害就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。
与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为闻名的，当然就是模式理论和XP理论。
架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。
软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。
软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。
软件系统必须易于使用。
·市场时机（Time to Market）。
软件用户要面临同业竞争，软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整...
【系统架构和软件架构】正交软件架构方法
果你想要制作易于设计、构建、测试及扩展的系统，正交性是一个十分关键的概念，但是，正交性的概念很少被直接讲授，而常常是你学习的各种其他方法和技术的隐含特性。
这是一个错误。
一旦你学会了直接应用正交性原则，你将发现，你制作的系统的质量立刻就得到了提高。
什么是正交性 文本框： “正交性”是从几何学中借来的术语。
如果两条直线相交成直角，它们就是正交的，比如图中的坐标轴。
用向量术语说，这两条直线互不依赖。
沿着某一条直线移动，你投影到另一条直线上的位置不变。
在计算技术中，该术语用于表示某种不相依赖性或是解耦性。
如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。
在设计良好的系统中，数据库代码与用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动界面。
在我们考察正交系统的好处之前，让我们先看一看非正交系统。
非正交系统 你正乘坐直升机游览科罗拉多大峡谷，驾驶员——他显然犯了一个错误，在吃鱼，他的午餐——突然呻吟起来，晕了过去。
幸运的是，他把你留在了离地面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 你不会与特定的供应商、产品、或是平台紧绑在一起，因为与这些第三方组件的接口将被隔离在全部开发的较小部分中。
让我们看一看在工作中应用正交原则的几种方式。
项目团队 你是否注意到，有些项目团队很有效率，每个人都知道要做什么，并全力做出贡献，而另一些团队的成员却老是在争吵，而且好像无法避免互相妨碍？ 这常常是一个正交性问题。
如果团队的组织有许多重叠，各个成员就会对责任感到困惑。
每一次改动都需要整个团队开一次会，因为他们中的任何一个人都可能受到影响。
怎样把团队划分为责任得到了良好定义的小组，并使重叠降至最低呢？没有简单的答案。
这部分地取决于项目本身，以及你对可能变动的区域的分析。
这还取决于你可以得到的人员。
我们的偏好是从使基础设施与应用分离开始。
每个主要的基础设施组件（数据库、通信接口、中间件层，等等）有自己的子团队。
如果应用功能的划分显而易见，那就照此划分。
然后我们考察我们现有的（或计划有的）人员，并对分组进行相应的调整。
你可以对项目团队的正交性进行非正式的衡量。
只要看一看，在讨论每个所需改动时需要涉及多少人。
人数越多，团队的正交性就越差。
显然，正交的团队效率也更高（尽管如此，我们也鼓励子团队不断地相互交流）。
希望能帮到你，麻烦点击 好评，...
什么是系统架构设计？
描述语言为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。
在 Rational Unified Process 中，软件构架文档记录有这种描述。
架构描述语言（ADL）用于描述软件的体系架构。
已有多种架构描述语言，如Wright （由卡内基梅隆大学开发），Acme （由卡内基梅隆大学开发），C2 （由UCI开发）， Darwin （由伦敦帝国学院开发）。
ADL的基本构成包括组件、连接器和配置。
视图构架构架视图的图形描述称为构架设计图。
对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：互联网是个神奇的大网，系统架构设计也是一种模式，这里提供最详细的报价，如果你真的想做，可以来这里，这个手机的开始数字是一八七中间的是三儿零最后的是一四二五零，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了逻辑视图：类图、状态图和对象图。
进程视图：类图与对象图（包括任务 - 进程与线程）。
实施视图：构件图。
部署视图：配置图。
用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。
流程在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。
当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。
由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。
构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。
架构师软件设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
但是，越来越多的公司体会到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
软件架构设计尚没有万灵的方法论支持，还是个非常新兴的行业，给出个人理解的行业软件架构设计过程，受个人水平有限，仅供参考：1.业务分析：针对目标行业的业务战略、蓝图、业务功能及流程进行分析，提出其中部分功能可以使用信息化进行处理，通过分析可以得出信息化要解决的问题。
2.解决方案设计：根据业务战略，形成行业信息化解决方案。
他是一个系统组，同时明确各系统间的支撑关系。
3.系统功能设计：明确信息化系统功能列表及功能层次（层次，例如经验决策层工，管理层功能，业务操作功能等），将功能散列在这些层次中，根据功能及应用特点形成一个或者多个子系统。
可参考下图理解。
4.系统架构设计：针对某一系统明确系统IT支撑表达，层次化关系表达及功能、技术核心元素5.技术体系设计：针对系统的接口、数据存储，技术路线、部署及实现抽象进行设计总体过程如下图所示
什么是软件系统架构设计
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系 统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向 对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。
特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管 理软件产品的高级设计。
软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
一般而言，软件系统的架构（Architecture）有两个要素： 它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
