J2EE项目实训UML及设计模式——第3章 系统概要设计中的架构设计（第1部分）

1、杨教授工作室 精心创作的优秀程序员 职业提升必读系列资料第3章 系统概要设计中的架构设计（第1/3部分）系统分析的目的就是把需求转换为未来系统的设计，分析与设计是一个前后相互关联的过程。读者通过对本章中的内容学习，将进入软件开发的设计阶段。而软件系统的设计一般分为概要设计和详细设计，在概要设计中最重要的设计工作是系统的架构设计。从软件系统的开发实现的角度来看系统的架构设计，主要可以分为逻辑架构与物理架构两个紧密相关的设计内容。系统的逻辑架构设计结果定义了应用系统中的基本逻辑组成元素、以及这些逻辑元素之间的关系，这在uml中主要是通过架构包图来表示；而系统的物理架构设计则主要关注“目标程序及其依

2、赖的运行库和系统软件”最终如何安装或部署到客户的最终环境的物理主机中，以及如何部署机器（如各种形式的服务器主机）和网络配置来保证软件系统的可靠性、可伸缩性和稳定地运行等方面的要求，这主要是通过uml中的部署图来表示。在系统的架构设计中，尽可能地分析清楚系统中哪些逻辑元素是稳定的需求，哪些是经常变化的需求。以便在进行系统设计时，能够将软件系统的核心部分建立在稳定的需求上。本章主要介绍系统概要设计中与“架构设计”有关的各个方面的内容，并通过网上商城项目中的系统架构设计的示例来阐述与架构设计有关的思想、原则和方法以及模式的具体应用。1.1 概要设计1.1.1 软件系统设计1、软件系统设计概述（1）什

3、么是系统设计所谓系统设计就是通过某种特定的平台，而达到完成软件系统的整体功能（也就是把软件需求转变为软件的具体方案）的实现。从工程管理的角度来看，软件设计分为如下的两个阶段：概要设计和详细设计。在下面的图3.1中示例了概要设计和详细设计中所应该进行的具体的工作内容。需求分析概要设计l 制定规范l 体系结构设计l 模块和组件类的设计l 数据结构与算法设计l 数据库的逻辑设计l 其它如可靠性等方面的设计等详细设计l 用户界面的设计l 各个层中的组件类的设计l 数据库的物理设计l 测试计划的制定等系统编程实现图3.1概要设计和详细设计中所应该进行的具体的工作内容概要设计的工作重点在于进行系统的静态结

4、构或者高层架构设计；而详细设计的工作重点在于系统的用户界面、动态结构设计以及测试计划的制定等。（2）系统的概要设计将软件系统的功能性需求和非功能性需求转化为数据结构和软件的系统结构，并合理地设计和规划出组成软件系统的物理元素：程序、数据库、过程、文件等内容。分析设计人员一般可以利用uml中的包图来建立和体现软件系统的体系架构。下面的图3.2所示为某图书馆管理系统项目中的包图。图3.2 某图书馆管理系统项目中的架构包图从上面的包图中，很明显地能够看出，该系统采用标准的四层架构实现：表示层、控制层、业务处理层和数据访问层；并且也能够了解每层中的各个核心的组件及其关系。（3）系统的详细设计（重点在系

5、统的动态结构设计）通过对软件系统的结构表示进一步地细化和完善，最后获得软件系统的详细数据结构和算法、关键性问题的解决等方面的解决方案。为此，分析设计人员可以利用uml中的类图建立相应的体系结构、同时再辅助于uml中的四种动态分析的图如顺序图、活动图、状态图和协作图等，进一步地描述和体现系统中的各个用例的实现行为。下面的图3.3中所示为某图书馆管理系统项目中业务层的类图。图3.3 某图书馆管理系统项目中业务层的类图在分析阶段，软件系统的开发者通过建立出特定的软件系统的模型来表示真实的世界中的问题，以便理解业务过程以及这个过程中所要用到的各种信息（业务数据和数据之间的关系）。图3.4所示为某图书馆

6、管理系统项目中的管理员的各种可能的活动状态的图示。图3.4 某图书馆管理系统中管理员的各种可能的活动状态在具体实施系统的分析时，首先是要学会对问题的分解，把复杂的软件系统中的各种信息和需求进行综合考虑，然后分解成多个易于理解的小问题。最后通过建立出软件系统的需求模型来对问题领域进行组织、构造和模拟并且编制出相应的技术文档。在对软件系统进行分析建模的过程中，必须要邀请用户方的有关人员参与，并且需要用户进一步地解释这些需求。当然，其目的不外乎是能够验证开发者所建立出的软件模型是否是正确的、合理的、可行的！因为软件系统的设计本身，实际上也是个建模过程，它把分析阶段得出的信息也就是需求模型，转换为称之

7、为解决方案的设计模型。下面的图3.5所示为某图书馆管理系统项目中的各个组件的图示，利用组件图能够帮助客户理解最终的系统结构，并使开发人员的实现工作有一个明确的目标；同时组件图还有利于帮助开发组中的其他人员（如帮助文档人员）理解系统。图3.5 某图书馆管理系统项目中的各个组件的图示2、为什么要进行软件系统的设计（1）主要的原因由于在建立软件系统的逻辑模型中的用例及用例图并不是分析模型的、或者说能够满足系统的分析需要。它们只是形成分析模型的其中的素材，而对于用例的分析，开发者可以产生出一个分析的模型，但是很少有开发者直接根据这个分析模型去完成软件系统的程序编程实现的。为什么呢？开发者首先应该了解到

8、这样的一个事实，从用例及用例图得到的分析模型，只是表达了软件系统中的一些关键性的概念，而不能表达软件系统中的性能和系统的外观（如用户界面gui）等方面的内容。同时所产生出的系统分析模型往往对于最终的软件系统的结构设计来说又往往过于简单和粗糙，而在软件开发中所倡导的“组件复用”、“模块分离”和“面向接口编程实现”等等都不能在这个系统分析模型中被考虑和加以完成。因此，软件系统的分析设计人员有必要再对前面所产生出的分析模型，再进一步地进行设计和完善，以最终产生出开发者所期望的软件系统的设计模型。有利于指导软件系统的编程实现。（2）进行软件系统设计的目的对软件系统进行全面地设计的主要目的，是希望能够指

9、明一种易转化成软件系统的功能代码的解决方案,是对系统分析工作的进一步地细化和具体的实现。也就是进一步细化分析阶段所提取的各个类(包括其操作和属性)，并且增加新的类以处理诸如系统中所需要涉及的数据库系统、用户接口、与其它设备的通信、控制和驱动其它的设备等技术领域的问题。3、系统设计时的基本要求（1）系统的分析和系统的设计两者之间应该是相互合作的其中的系统分析是面向问题的，是明确和了解问题的过程，重在理解和翻译，灵活性一般会比较高；而系统的设计则是面向解决方案的，是排除技术困难和解决问题的过程，重在精化和适应，受约束性和限制条件一般比较多。因此，从整体上看，分析和设计是不同的，在分析阶段更关注的是

10、对需求的描述和理解，而在设计阶段，更主要的是考虑具体的技术实现方案！它们是保障问题和针对该问题进行解决的方案趋于合理和有效的基本动力。（2）在进行软件系统设计时所应该注意的一些要点l 应该考虑能否使用重复的体系结构模式或者重用成熟的系统架构也就是要考虑本系统能否达到在体系结构级别上的软件重用，即能否在不同的软件体系结构中，使用同一个体系结构。比如，我们经常提及的客户服务器模式的c/s架构体系和浏览器服务器模式的b/s体系结构等的具体应用问题。l 体系结构从更高的层面上所应该考虑的问题主要是体现在“不变”的因素上软件系统的体系结构一般关心应用系统中的设计模式，更加体现在通过技术去解决这些业务差异

11、所带来的影响。比如，关心是否是分布式应用程序、关心系统分层是如何设计和实现的，也关心系统的性能和安全性等方面的要求是如何满足的。当然，软件系统的设计者，为了能够达到该设计的目标。必须要了解和分离系统中的“不变”和“可变”部分，然后将它们分离开！对“不变”部分或者是稳定的部分，尽可能地加以重用。4、软件设计中的“3w”原则软件设计既是面对软件工程的具体应用的技术，同时也是聚焦于大量的开发者相互协作的结果的艺术，成功的软件系统产品应该是来自于合理的系统设计。当然，什么是合理的系统设计呢？软件系统的开发者在进行软件系统开发时最需要考虑的问题，就是他们所开发和设计出的软件系统或者产品必须是满足客户企业

12、的发展战略规划的需求的，并且是应该能够帮助企业解决实际经营中的问题、提高本企业在同行业的竞争力的。因此一个合理的软件系统的设计，应该是遵守软件设计中的“3w”原则的。（1）who（为谁而设计，应该明确软件系统的真正的用户是谁。）为谁设计其实表达的是软件系统的开发者必须认真研究客户企业的业务领域、研究企业本身的工作特点，从而最终使开发者对于企业本身的业务规则和流程有深刻的理解，最后形成针对这个企业的业务经营状态的解决方案。（2）what（要解决用户在应用系统时的哪些方面的问题，功能方面有哪些？性能方面又有哪些？）要解决用户的什么问题，表达的是开发者必须把企业存在的问题提取出来，分析研究哪些问题是

13、可以用信息化技术或者特定的软件系统和工具可以帮助解决的；同时还应该搞清楚，企业应用了该信息化的技术以后，企业的业务流程需要做什么样的更改，以及这些更改会带给企业什么样的正面和负面的影响。（3）why（为什么要解决这些方面的问题？将这些问题解决后，能否为系统的用户带来价值、降低开发方的成本等。）为什么要解决这些用户问题，表达的是如何帮助企业产生可度量的价值，而这些价值是在研究企业目前存在的问题的基础上产生的，没有这些价值的产生，对软件系统的投资是没有意义的。价值不可度量，企业领导者是不可能积极的支持应用该软件系统或者开发出某套软件系统的。另外，还要注意的是，设计必须是便于用户使用的。减少维护和培

14、训的资源消耗，而且操作简单和应用方便。其实“3w” 原则的本质，就是要求软件系统的设计者围绕着“用户”而不是围绕着“开发者”或者“时髦的技术”来开展软件系统的设计和开发工作的。因此满足“用户的需求、便于用户的使用、同时又能使开发出的软件系统在应用新技术方面尽可能简单而相应地降低开发的成本”，这就是软件系统的开发者所要追求的设计目标。软件系统设计过程中的各项活动，其实就是权衡“利与弊”的过程，设计人员需要在“简单”与“复杂”之间权衡、在“功能实现”与“系统性能”之间进行权衡、在一种“技术方案”与另一种也可行的“技术方案”之间进行权衡。因此，好的设计方案，一定是“中庸”的设计。5、软件系统常用的设

15、计方法（1）面向过程的设计方法 面向过程的设计方法的基础建立在三种能够构成结构化程序的逻辑构造方面，顺序、选择和重复上；并且面向过程的设计方法采用的是“自顶向下、逐步精化”的经典的瀑布式设计方法，而由于瀑布式设计方法是“自顶而下”的顺序进行的，这就要求设计者在一开始就要对系统所应该要解决的各个问题有一定的、并且全面的、周密的了解。（2）面向对象的设计方法面向对象的设计方法主要是定义出系统中的各种可能类型的对象，并对每种类型的对象进行细化以找出彼此之间的关系；在面向对象的设计中，关注点变成了消息和响应机制。1.1.2 面向对象设计方法1、面向对象设计方法（ood，object-oriented

16、design）（1）面向对象设计方法的特点在面向对象的设计方法中，可以充分地利用对象所具有“抽象性、封装性、继承性、多态性”等特性，同时面向对象设计方法是一种“自下而上”的设计方法，而这与面向过程的设计方法中的“自上而下”刚好相反。另外，在面向对象设计方法中的最基本的概念是类、职责、状态、角色等概念，及与这些相关的耦合度、聚合度、可重用性、可扩展性、可维护性等关注点。（2）“自下而上”的设计方法所带来的优点是能够形成一种螺旋上升的软件开发方式不像面向过程式设计那样，在设计的开始阶段就需要明确整个软件系统本身，面向对象的设计往往是从问题的一部分（局部）着手，一点一点地构建出整个软件系统中的各个模

17、块。随着开发者在开发过程中逐步加深对软件系统的需求的理解，将分阶段和分层次地添加对这些新的功能的具体实现。这些新的理解以及开发中如果遇到的需求变化，都会再作用到软件系统开发本身（也包括设计阶段），从而能够形成一种螺旋式上升的开发方式和开发过程。在这种开发方式中，对于已有的系统设计或者部分编程实现的代码，只需要进行局部地进行修改或者调整以体现系统的变化。2、面向对象的设计方法与面向过程设计方法的最根本的区别（1）面向对象的设计方法是将整个软件系统看成为对象集把软件系统看成是一起工作来完成某项任务的对象集合，而对象是软件系统中对消息作出响应的事物。对象之间的关系体现出问题之间的关系，对象中的属性体

18、现问题的特征，而对象中的方法体现出问题的行为或者功能服务。因此，在面向对象的设计中所产生出的各个逻辑对象其实就是对软件系统所在的问题域中的各个问题的映射，设计的结果是有指导意义的！（2）面向对象的设计方法关注的核心是“它如何做出反应”而不是“它应该做什么”面向对象设计方法中最值得关注的不是它该做什么（而这在面向对象的分析中已经明确了！），而是它如何做出反应，也就是对消息的响应，这是和面向过程方法的根本不同。由于面向对象方法把对象看成软件系统对消息做出响应的事物，这种与面向过程完全不同的看待计算机软件系统的方法，必然会导致出完全不同的分析、设计和编程实现方式。（3）在面向对象设计（当然也包括编程

19、实现）中更多地看重类之间的关系从面向对象的角度来看各个对象之间的关系时，一般有“关联”、“继承”和“内聚”等形式。面向对象编程的过程就是将各个类按以上的各种关系组合在一起，这些关系本身都非常简单，不过组合在一起却能提供强大的设计能力。例如在下面的【例31】的代码示例中，体现了客户和订单之间的关联关系，因为每个订单对应特定的客户，而每个客户对应一些特定的订单。【例31】体现了客户和订单之间的关联关系的代码示例public class userinfoprivate arraylist orders;/ 。 其它的成员定义，在此加以省略public class orderprivate useri

20、nfo someoneuser;/ 。 其它的成员定义，在此加以省略面向过程中的结构化设计历来备受责备的主要原因，就是由于软件系统的需求和系统的设计之间存在一定的分离和鸿沟，因为在结构化设计中的模块和模块之间的关系，被紧紧局限于信息流，这限制了对模块之间众多关系（比如继承和内聚等关系）的表达，也无法体现模块和模块之间其它的众多关系，包含各种各样的结构、行为、依赖、包含（在结构化设计中这种关系隐含在分层中）、继承、关联关系等等。（4）面向对象的设计是适应性过程，而面向过程的设计更多的是预测的而不是适应性的面向对象设计由于更多地将重点放在“职责”的划分、“变化点”的隔离、“交互机制”的确定等问题上

21、，并且面向对象的设计认为变化是不可避免的驱动因素，并且整个设计是在迭代变更中完成的。3、面向对象设计的应用场合（1）设计中强调的是软件系统的重用和重构的软件系统面向对象的设计，更倾向于建立一种灵活机变，便于修改、便于升级的体系结构要求的软件系统，设计中强调的是软件系统中的各种组件的重用和重构。（2）设计中强调的是软件系统的可扩展性同时由于面向对象设计的技术成熟和不断地发展，已经形成了一系列的重要设计原则和方法、设计模式。这些原则和方法可以大大地提高系统的设计质量；从而使得应用面向对象设计的方法能够设计和建立一个大型的、分布式的、可升级、可维护而且是安全的软件系统成为可能。1.1.3 系统设计中

22、的概要设计1、概要设计又称为系统的结构设计（1）在什么时候应该进行系统的概要设计在系统的需求相对比较明确并对需求进行域建模之后，要做系统的概要设计。概要设计对随后进行的编程实现、单元测试和集成测试、系统安装部署实施和维护工作都起到关键性的影响作用因为通过对系统进行概要设计，从而实现将系统开发过程中“做什么”的逻辑模型变换为“如何做”的物理模型。（2）系统概要设计的重要性在进行系统分析过程中所产生出的分析模型和在系统设计过程中所产生出的设计模型两者应该是交错、并且是迭代进行的；概要设计的重要性，主要体现在它是把系统需求转化为软件系统的实现过程中最重要的开发环节，并且系统概要设计的优劣在根本上会决

23、定软件系统的整体质量和性能。2、系统概要设计中所涉及的主要内容（1）制定本软件系统的开发规范制定本软件系统中的各种开发规范是项目小组今后共同开发的基础，有了开发规范和程序模块之间、项目成员彼此之间的接口规则、方式和方法，开发团队中的各个成员就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调而有序地进行。制定规范所涉及的主要内容包括：1) 代码体系、模块之间的接口、命名规则2) 规定设计文档的编制标准。3) 规定与硬件，操作系统的接口规约，命名规则。（2）体系结构设计（架构设计）体系结构是对复杂的软件系统的一种抽象，如客户/服务器（c/s）和浏览器web 服务器数据库服务器（b/w

24、/s）结构等的应用。同时在架构设计中还应该考虑采用什么形式的框架技术和服务器的平台类型等内容。（3）划分系统中的各个模块并进行组件类的设计根据用户的需求，实现从功能上来划分各个功能模块。在模块设计中应该遵守功能独立的单一职责原则（srp，single-responsibility principle）。因为，“功能独立”的模块可以降低开发、测试、维护等阶段的代价，而且被重用的可能性更高。（4）数据结构与算法设计设计高效率的程序是基于良好的数据结构与算法的，而不是基于编程小技巧的。因为数据结构与算法就是一类数据的表示及其相关的操作。而确定出软件系统所涉及的文件系统的结构、以及数据库中的数据访问的

25、模式，进行数据完整性和安全性的设计，并确定出输入，输出文件的详细数据结构是本阶段所要考虑的问题。（5）数据库的逻辑设计根据在模块设计和划分出的各个实体类、实体类之间的关系、实体类中的各个成员属性等确定出数据库表中的各个字段和字段的数据类型。当然，构造数据库的表结构必须遵循一定的规则。在关系数据库中，这种规则就是范式。一般说来，数据库只需满足到第三范式（3nf）就行了-通常被认为在性能、扩展性和数据完整性方面达到了比较好的平衡。（6）其它如可靠性等方面的设计等软件系统在运行过程中，为了能够适应环境的变化和用户新的功能要求，需经常对软件进行改造和修正、完善。在软件开发的一开始就要确定软件可靠性和其

26、它质量指标，考虑相应措施，以使得软件易于修改和易于维护。3、概要设计中所涉及的系统设计的一些基本的原则软件系统设计的主要任务是什么、如何正确地进行系统的各个子模块的功能划分?在模块划分时要遵守怎样的原则和方法、设计的目标是什么？评价一个软件系统设计的优劣，主要是考查下面的一些指标是否达到或者满足。（1）先进性在设计思想、系统构架、采用技术和选用平台上均要有一定的先进性、前瞻性和扩充性。特别要考虑一定时期内业务的增长和应用的变化趋势。在充分考虑技术上先进性的同时，尽量采用技术成熟、市场占有率比较高的产品，从而保证建成的网站系统具有良好的稳定性、可扩展性和安全性。（2）实用性在尽量满足业务功能需求

27、的前提下，要适应各业务角色的工作特点，做到简单、使用和人性化。（3）可靠性由于企业应用中不可避免地要涉及不同的用户群（操作层、管理层和业务层等人员），所以建设的信息服务网站系统必须在建设平台上保证系统的可靠性和安全性。系统设计中，应有适量冗余及其他保护措施，平台和应用软件应具有容错性和容灾性。（4）开放性在系统架构、所采用的技术实现和选用的平台等方面都必须要有较好的开放性。特别是在选择产品上，要符合开放性要求，遵循国际标准化组织的技术标准，对选定的产品既有自己独特优势，又能与其他多家优秀的产品进行组合，共同构成一个开放的、易扩充的、稳定的和统一软件的系统。（5）可维护性系统设计应标准化和规范化

28、，按照分层设计、模块化实现并遵守面向接口编程实现的基本原则。（6）可伸缩性考虑到一般的企业应用的网站系统的网上业务建设是一个循序渐进、不断扩充的过程，系统要采用积木式结构，整体构架的考虑要与现有系统进行无缝连接，为今后系统扩展和集成留有扩充余量。（7）可移植性在选择开发的应用平台上，应该考虑能够建设出一套与平台无关，以统一的服务接口规范和与各种数据库都能够相连的应用组件。4、概要设计后的重要输出（1）概要设计说明书1) 编码规范：信息形式、接口规约、命名规则；2) 物理模型：组件图、配置图；3) 不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；4) 系统

29、总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；（2）数据库设计说明书，主要给出所使用的dbms简介、数据库的概念模型、逻辑设计、结果（3）用户手册，并对需求分析阶段中所编写出的用户手册进行补充（4）制定初步的测试计划，并对测试策略、方法、步骤提出明确要求1.2 软件架构设计 1.2.1 软件架构及架构设计1、什么是架构在it业，软件的系统架构是指通过某种特定的技术平台，而达到完成软件系统的整体功能的开发过程。也可以通俗地理解为：总体设计和总体结构布局。（1）“架构”架构普遍指通过某种特定的平台，而达到完成整体软件的功能。也即软件体系结构通常被称为架构，指可以预制和可重构的软件框架结

30、构。并最终产生出本软件系统的体系结构设计报告的开发过程。（2）架构的英文architecture 其英文的本意是来源于建筑行业的建筑艺术、建筑（风格）和结构。下面是摘录ieee-std-1471-2000 recommended practice for architectural description of software-intensive systems中有关对“achitecture”一词的解释。achitecture：the fundamental organization of a system embodied in its components, theirrelation

31、ships to each other, and to the environment, and the principles guiding its design and evolution. ieee std 1471-2000(architecture 是一个系统的基本组织，它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。)。软件架构可以有多种定义，不管对软件架构如何定义和说明，但所有的定义都有一个共同的主题，那就是必须考虑软件系统中诸如技术方向、开发平台的选择、组件的构建、设计风格的确定、设计模式的具体应用、系统中的各个模块的职责划分

32、、协作、连接等要素方面的问题。2、架构是一组有关如下软件系统要素的重要决策（1）决定软件系统的组织结构1) 构成系统的结构化元素的选择，对目标软件系统实现从整体到部分的最高层次的划分2) 接口和它们相互协作的行为的选择3) 将结构化元素和行为元素再次组合成粒度更大的子系统的方式的选择（2）指导这一组织结构（元素及其接口、协作和组合方式）的架构风格的选择也就是要选择包括架构中的组成组件、组件之间的联结器等组成元素，同时还要决策出建造本应用系统时所应该采用的具体技术的决定。（3）在软件开发中的架构既可以是名词，也可以是动词因此，软件系统的架构实际上应该是两个层面方面的事情。架构作为名词来理解时，则

33、是指为软件系统设计并提供出一个统一的共享的框架（framework），这种架构事实上是系统的一个层，这里的架构是名词；而将架构作为动词来理解时，则是指设计构造系统或者是框架（archiecture），这里的架构更多的是动词。3、软件架构的重要性主要体现在以下几方面强调软件架构的最主要的目的是希望本软件项目能够达到重用因为开发者希望系统能够重用以前的代码和系统设计，从而提高本次项目的开发效率，这也将是分析设计人员在进行架构实践是所应该把握的原则；另一个目的则是希望能够达到扩展同样开发者也还希望在系统保持结构稳定的前提下，能够很容易地扩充系统的功能和性能，希望能够“以静制动”，当然这可以通过合理地

34、应用一些其它比较成熟的框架。最后是希望能够达到简洁好的架构一定易于理解，易于学习，易于维护，开发者希望能够通过一个简洁的架构来把握系统。因为一个复杂的架构不论是测试还是维护都是困难的，因此开发者希望架构能够在满足目标的前提下尽可能地简单明了。（1）软件架构是软件各相关方联系的载体l 软件系统开发过程中是需要涉及许多相关方面的人员它们包括软件系统的使用者、项目管理人员、分析和设计人员、编码人员、测试人员、维护人员等。由于各类人员都有自己的独特见解和思想、要求和技术水平高低等，因此他们一般都会从自己的视角来了解和理解所要开发的软件系统。从而导致不同层次和不同角色的开发人员对软件系统的了解和技术理解

35、是不同的，这将给以后再开发过程中的沟通、交流带来一定的困难。l 软件架构是沟通和联系各类人员的特殊载体在各种要求和理解通常存在矛盾的情况下，此时的软件架构又成为协调和沟通各相关方人员的共同语言。因为各个方面的人员，都应该围绕系统架构而开展各自的工作。（2）软件架构代表了软件系统设计早期阶段中一系列重要的决策1) 软件架构提供了如何满足软件系统的各项功能要求、并为各个部件的设计和其相互关系提供了必须遵守的约束。通过软件架构可以为后面的详细设计工作和系统的维护工作的组织、实施提供一定的依据。2) 软件架构可以提出软件系统应该实现的质量目标和性能指标，当然，根据这些质量目标，开发者也能够预测出软件系

36、统的某些质量属性和等级。3) 软件架构为开发人员的技术培训提供了基础，因为，当开发团队中的人员对在系统架构中所应用的技术或者所应用的某种形式的框架不熟悉的情况下，技术培训是一个比较快捷的方法。（3）一个成熟的软件架构可以为今后开发类似的软件产品或者软件项目提供一定的参照。4、软件系统架构的主要工作内容（1）架构调研（架构分析）面向对象的设计并不是简单地把需求分析中的领域分析模型转换成软件系统的设计模型就可以了，系统架构师在具体进行软件系统的架构设计之前还必须从需求分析的结果中获取架构因素。架构调研的本质，是识别出可能会影响系统架构的各种因素，并了解它的易变性和优先级，最终解决这些问题。架构调研

37、是对系统的重大设计决策有特别影响的需求进行分析，从而识别出对系统存在或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求），例如市场趋势、系统性能、开发的成本、维护和系统演进等方面的内容。其主要的重点在于应该了解提出了什么问题？并权衡这些问题，和掌握解决影响架构重要因素的众多方法。（2）架构设计主要包括体系结构设计和各个层中的模块设计，是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。在统一过程里面，架构调研和架构设计统称为架构分析。5、统一过程（rup）中所称的架构视图(architecture view)（1）“4+1 view”模型1995年，philippe

38、kruchten在ieee software上发表了题为the 4+1 view model of architecture的论文，引起了业界的极大关注，并最终被rup（rational unified process）采纳。主要指逻辑视图、实现视图、进程视图、部署视图，再加上用例视图，这些视图在rup 中被称为“架构视图(architecture view)”，即通过这样几种视图可以完整地展示系统的架构。因为软件系统中的架构结果同样也可以组织成各种不同的视图，并且需要从不同的视角来了解系统。图3.6所示为在rose2003中所支持的各种视图。图3.6 在rose2003中所支持的各种视图比如

39、逻辑架构则主要是描述系统中的各个层、包、主要框架、类、接口和子系统的概念组织方式；而部署架构则是描述系统的进程如何分配给处理单元和网络配置。同时不同的视图也是面对不同的人员的，如分析设计人员一般比较关心逻辑视图，而程序员则更多地关心实现视图。（2）用例视图用例视图描述系统应该交付的功能，也就是外部参与者所看到的功能；用例视图的使用者是客户、设计人员、开发人员以及测试人员。（3）逻辑视图描述如何实现用例视图中提出的那些系统功能，它的使用者主要是设计人员和开发人员。与用例视图相比，逻辑视图关注系统的内部，它既描述系统的静态结构（类、对象以及它们之间的关系），也描述系统内部的动态协作关系。这种协作发

40、生在为了实现既定功能，各对象之间进行消息传递的时刻。（4）组件（实现）视图组件视图描述系统的实现模块以及它们之间的依赖关系。它的使用者主要是开发人员。（5）进程（并发）视图并发视图处理的是将系统划分为进程和处理器。这是系统的非功能特性，该视图主要考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理。除了将系统划分为并发执行的控制线程以外，并发视图也必须处理这些线程之间的通信和同步。并发视图的使用者是开发人员和系统集成人员，并且该视图由动态图（状态图、协作图，以及活动图）和实现图（组件图和部署图）组成。（6）部署视图部署视图显示系统的物理部署，例如计算机和设备（节点），以及它们之间是如

41、何连接的。部署视图的使用者是开发人员、系统集成人员和测试人员。（7）对系统的架构设计为什么要采用多视图来表达因为系统的架构所要涵盖的内容和决策太多了，并且还涉及到不同方面的内容，是不能采用某一种单一形式的图来描述，而且也不能表达完整的内涵。因此需要采用从不同的层次和不同的视角分别设计；同时，由于在系统开发过程中也将涉及到不同方面的开发人员，多视图来表达为开发团队中的各个层次的人员理解和交流也提供了方便。但应用架构视图的核心问题，应该是要展示应用系统中少数值得注意的重要的设计元素，而屏蔽次要的设计元素。因此，统一过程的架构视图给系统的开发者提供了这样的设计原则方面的信息：“选择一小组有意义的设计

42、元素来传达主要的设计思想。”6、系统架构设计时所应明确的一些问题（1）何时开展架构设计工作一般应该在应用系统的需求分析和域建模完成后开展。当然，这需要项目经理以具体的经验判断来评估此时是否合适开始构建软件架构的工作。（2）架构设计工作不仅要依据静态的系统目标，也要考虑动态的开发过程1) 静态的系统目标：一般为系统的功能方面的需求、非功能的需求和变化的用例等2) 动态的开发过程：一般为如人力资源的情况，开发进度的要求，开发环境的满足。（3）没有一个统一的“万能”的系统架构因为，软件的系统架构设计是和千差万别的具体软件系统的功能要求、所应用的技术和具体的开发平台等实现因素是密切相关的，因此在此无法

43、给出一个通用的“系统架构设计”解决方案；尽管存在上面的原因，但一般在“系统架构设计”中还是会有一些共性的内容可以参考，以及能够说明哪些因素是需要考虑的。当然，对于每个因素的设计策略和具体的解决方法还需要软件系统的架构设计师在具体开发实践中灵活把握。但要注意的是，不同的因素之间有时是相互矛盾的，架构设计时需要根据具体情况进行平衡和统筹协调。7、架构设计的基本依据是什么?（1）架构设计的主要依据首先是应用系统中的需求应用系统的设计人员主要应该是根据需求规格说明书中的功能性需求和非功能性需求来进行系统的架构方面的设计工作。比如在系统的体系架构设计中为什么要应用b/s体系架构、为什么要应用轻量级的j2

44、ee框架而不应用重量级的框架，而在每一层中为什么要用这种技术实现以及各种设计模式等等方面的策略考虑。设计人员对于这些问题的思考，其实都是基于为了能够更好地满足应用系统中的“需求”，同时也是为了很好地实现需求和面对今后的需求变化；另外，系统的架构设计不仅要满足功能性的需求，也还应该满足非功能性的需求如性能等方面的要求；而且也应该权衡各种性能指标的优先级别，否则我们的系统架构设计结果也会很复杂、系统实现的总体代价将会很高！（2）其次在进行具体的架构设计的同时还应该遵循j2ee平台中所倡导的两个主要的设计原则“多层架构、松藕合” 采用分层设计方案后，系统中的各个模块功能相互独立并被封装，同时层与层之间的关联性大大地减弱了，并能够保持松耦合的关联；另外系统的稳定性也能够进一步得