设计建模指南

1、北方民族大学计算机学院软件工程系北方民族大学计算机学院软件工程系第三章第三章系统概要设系统概要设计中的架构设计计中的架构设计于千城 yu2 提纲提纲3.13.1 概要设计概要设计 3.2 软件架构设计 3.3 系统架构实践 3 1 1、什么是系统设计什么是系统设计所谓系统设计就是通过某种特定的平台，而达到所谓系统设计就是通过某种特定的平台，而达到完成项目的整体软件的功能和性能。完成项目的整体软件的功能和性能。从工程管理的角度来看，软件设计分两步完成。从工程管理的角度来看，软件设计分两步完成。（1 1）概要设计（概要设计（静态结构静态结构）将软件需求转化为数据结构和软件

2、的系统结构。将软件需求转化为数据结构和软件的系统结构。划分出组成系统的物理元素：程序、数据库、过程、划分出组成系统的物理元素：程序、数据库、过程、文件等。文件等。（2 2）详细设计（详细设计（动态结构动态结构） 通过对结构表示进行细化，得到软件的详细的数通过对结构表示进行细化，得到软件的详细的数据结构和算法、关键性问题的解决等。据结构和算法、关键性问题的解决等。 一、系统设计一、系统设计 4 结构结构 5 为什么要进行系统设计为什么要进行系统设计 对于用例的分析我们可以产生一个分析模型，但是我们对于用例的分析我们可以产生一个分析模型，但是我们很少有直接根据这个分析模型去完成程序的实现。为什么？

3、很少有直接根据这个分析模型去完成程序的实现。为什么？1.1. 首先我们应该了解用例得到的首先我们应该了解用例得到的分析模型，只是表达了系统分析模型，只是表达了系统中的一些关键性的概念中的一些关键性的概念，而不能表达系统中的性能和系统，而不能表达系统中的性能和系统的外观。的外观。2.2. 同时同时分析模型往往对于系统的结构设计来说又往往过于简分析模型往往对于系统的结构设计来说又往往过于简单，单，复用和调试等等都不能在这个模型中被考虑完成。复用和调试等等都不能在这个模型中被考虑完成。 因此，我们有必要对前面的分析模型再进一步地进行设因此，我们有必要对前面的分析模型再进一步地进行设计，以最终产生出我

4、们系统的设计模型计，以最终产生出我们系统的设计模型 我们不要幻想直接我们不要幻想直接把分析类图画好后，就把分析类图画好后，就直接按照其去编码。直接按照其去编码。 6 分析和设计应该是合作的分析和设计应该是合作的设计中所需要的各种信息，主要来自于分析。设计中所需要的各种信息，主要来自于分析。分析面向问题，是明确动力的过程，重在理解和翻分析面向问题，是明确动力的过程，重在理解和翻译，灵活性高。译，灵活性高。设计面向方案，是排除阻力的过程，重在精化和适设计面向方案，是排除阻力的过程，重在精化和适应，受约束大。应，受约束大。从整体上看，分析和设计的对立是保障问题和方案从整体上看，分析和设计的对立是保障

5、问题和方案趋于一致的基本动力。就像两个相反方向的张力，使软趋于一致的基本动力。就像两个相反方向的张力，使软件朝着正确的方向前进。件朝着正确的方向前进。 7 软件设计的软件设计的“3W”3W”原则原则pWhoWho为谁设计，用户是谁为谁设计，用户是谁pWhatWhat要解决用户的哪些问题要解决用户的哪些问题-功能方面、性能方面功能方面、性能方面pWhyWhy为什么要解决这些问题为什么要解决这些问题-为用户带来价值、降低开为用户带来价值、降低开发方的成本等发方的成本等 8 在什么时期进行概要设计（结构设计）在什么时期进行概要设计（结构设计）在需求在需求“明确明确”并对需求进行域建模之后，并对需求进

6、行域建模之后，要做概要设计要做概要设计概要设计对后面的开发、测试、实施、维护概要设计对后面的开发、测试、实施、维护工作起到关键性的影响。工作起到关键性的影响。概要设计的重要性主要体现在概要设计的重要性主要体现在它是把需求转化它是把需求转化为软件系统的最重要的环节为软件系统的最重要的环节，并且系统设计的优劣，并且系统设计的优劣在根本上决定了软件系统的质量。在根本上决定了软件系统的质量。 9 概要设计中所涉及的主要内容概要设计中所涉及的主要内容（1 1）制定规范制定规范p代码体系、接口规约、命名个风格等规则代码体系、接口规约、命名个风格等规则p规定设计文档的编制标准。规定设计文档的编制标准。p规定

7、与硬件、操作系统的接口规约，命名规则规定与硬件、操作系统的接口规约，命名规则 因为，这些是项目小组今后共同开发的基础。并且使整个软因为，这些是项目小组今后共同开发的基础。并且使整个软件开发工作可以协调有序地进行。件开发工作可以协调有序地进行。（2 2）体系结构设计（架构设计）体系结构设计（架构设计）体系结构是对复杂事物的一种抽象，如体系结构是对复杂事物的一种抽象，如C/SC/S和和B/W/SB/W/S结结构。构。（3 3）划分系统中的各个模块及组件类的设计划分系统中的各个模块及组件类的设计p根据用户的需求实现从功能上来划分各个功能模块，在模根据用户的需求实现从功能上来划分各个功能模块，在模块设

8、计中保持块设计中保持“功能独立功能独立-单一职责原则单一职责原则SRP”SRP”是模块化是模块化设计的基本原则。设计的基本原则。p因为，因为，“功能独立功能独立”的模块可以降低开发、测试、维护等的模块可以降低开发、测试、维护等阶段的代价。阶段的代价。 10 概要设计中所涉及的主要内容概要设计中所涉及的主要内容（4 4）数据结构与算法设计数据结构与算法设计q设计高效率的程序是基于良好的数据结构与算法，设计高效率的程序是基于良好的数据结构与算法，而不是基于编程小技巧的。一般说来，数据结构与而不是基于编程小技巧的。一般说来，数据结构与算法就是一类数据的表示及其相关的操作。算法就是一类数据的表示及其相

9、关的操作。q确定软件涉及的文件系统的结构以及数据库的模确定软件涉及的文件系统的结构以及数据库的模式、子模式，进行数据完整性和安全性的设计，并式、子模式，进行数据完整性和安全性的设计，并确定输入，输出文件的详细的数据结构确定输入，输出文件的详细的数据结构 （5 5）数据库的逻辑设计数据库的逻辑设计（6 6）其它其它-如可靠性、安全性设计等如可靠性、安全性设计等 11 概要设计中所涉及的系统设计的一些基本的原则概要设计中所涉及的系统设计的一些基本的原则（1 1）先进性和实用性）先进性和实用性（2 2）可靠性和开放性）可靠性和开放性（3 3）可维护性和可伸缩性）可维护性和可伸缩性（4 4）可移植性）

10、可移植性 12 概要设计的重要输出概要设计的重要输出（1 1）概要设计说明书）概要设计说明书p编码规范：信息形式、接口规约、命名规则；编码规范：信息形式、接口规约、命名规则；p物理模型：组件图、配置图；物理模型：组件图、配置图；p不同角度的构架视图：用例视图、逻辑视图、不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图进程视图、部署视图、实施视图、数据视图（可选）；（可选）；p系统总体布局：哪些部分组成、各部分在物系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；理上、逻辑上的相互关系；（2 2）数据库设计说明书）数据库设计说明书（3 3）用户手册）用户

11、手册（4 4）制定初步的测试计划和方案）制定初步的测试计划和方案 13 概要设计说明书参考格式 14 概要设计说明书参考格式 15 概要设计说明书参考格式 16 概要设计说明书参考格式 17 概要设计说明书参考格式 18 概要设计阶段的工作重点概要设计阶段的工作重点（1 1）工作的重点内容是工作的重点内容是设计软件的体系结构设计软件的体系结构（2 2）核心问题核心问题-能否使用重复的体系结构模式能否使用重复的体系结构模式 也就是能否达到结构级的软件重用也就是能否达到结构级的软件重用-即能否在不同即能否在不同的软件体系中，使用同一体系结构。的软件体系中，使用同一体系结构。（3 3）这个阶段是这个

12、阶段是系统架构师系统架构师发挥作用的主要阶段。发挥作用的主要阶段。 19 提纲提纲3.1 概要设计 3.23.2 软件架构设计软件架构设计 3.3 系统架构实践 20 软件架构的一般概念软件架构的一般概念（1 1）什么是架构）什么是架构-在在ITIT，架构普遍指通过某种特定的平，架构普遍指通过某种特定的平台，而达到完成整体软件的功能的设计过程。台，而达到完成整体软件的功能的设计过程。（2 2）ArchitectureArchitecture其英文的本意是来源于建筑行业的建筑艺术、建其英文的本意是来源于建筑行业的建筑艺术、建筑（风格）和结构。筑（风格）和结构。就像高楼大厦的钢骨结构就像高楼大厦的

13、钢骨结构, , 将无数个将无数个“Part”Part” 组合成为和谐的组合成为和谐的“Whole”Whole” 21 架构是一组有关如下要素的重要决策架构是一组有关如下要素的重要决策（1 1）软件系统的组织）软件系统的组织p构成系统的结构化元素的选择构成系统的结构化元素的选择p接口和它们相互协作的行为的选择接口和它们相互协作的行为的选择p结构化元素和行为元素组合成粒度更大的子结构化元素和行为元素组合成粒度更大的子系统的方式的选择系统的方式的选择（2 2）指导这一组织（元素及其接口、协作）指导这一组织（元素及其接口、协作和组合方式）的架构风格的选择和组合方式）的架构风格的选择 22 体系结构关注

14、的问题体现在“不变”因素上体系结构从更高的层面上考虑问题体系结构从更高的层面上考虑问题-关关注的问题就体现在注的问题就体现在“不变不变”因素上因素上p体系结构一般关心应用程序的模式，更加体体系结构一般关心应用程序的模式，更加体现在通过技术去解决这些业务差异带来的影现在通过技术去解决这些业务差异带来的影响。响。p比如，关心是否是分布式应用程序，关心系比如，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全统分层是如何设计，也关心性能和安全-因此在这样的情况之下，会考虑集群，负载因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术的使用。平衡，故障迁移等等一系列技术的

15、使用。 23 系统架构是一个软件系统从整体到部分的最高层次的划分系统架构是一个软件系统从整体到部分的最高层次的划分一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括：1.架构元件（Architecture Component） 架构元件，也就是组成系统的核心砖瓦2.联结器（Connector） 联结器描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果3.任务流（Task-flow）。任务流描述系统如何使用这些元件和联结器完成某一项需求。 24 在软件开发中，在软件开发中，架构既可以是架构既可以是名词名词，也可以是，

16、也可以是动词动词（1 1）架构作为名词来理解）架构作为名词来理解 是指提供一个统一的共享的框架或者是是指提供一个统一的共享的框架或者是FrameworkFramework，这种架构事实上是系统的一个层，这种架构事实上是系统的一个层，这里的架构是名词。这里的架构是名词。（2 2）架构作为动词来理解）架构作为动词来理解是指设计构造系统或者是是指设计构造系统或者是ArchiectureArchiecture，这，这里的架构更多的是动词（此时的架构一部分是里的架构更多的是动词（此时的架构一部分是调研工作，一部分是设计等工作）调研工作，一部分是设计等工作） 25 当做名词时，也称当做名词时，也称软件体系

17、结构软件体系结构软件体系结构至少有十几种思想流派。Zachman框架开放分布式处理领域分析Rational41视图模型软件体系结构风格供应商驱动的方案Sun Enterprise JavaBeansMS .Net 体系 26 软件体系结构风格软件体系结构风格MVC风格管道过滤器风格客户服务器风格层次系统仓储（数据库和黑板）风格面向对象风格基于消息广播且面向图形用户界面的Chiron2风格基于事件的隐式调用风格 27 当做动词时，指进行当做动词时，指进行架构设计架构设计 28 没有进行架构设计的结果没有进行架构设计的结果 29 软件架构在软件系统开发中的位置软件架构在软件系统开发中的位置（1 1

18、）一般的位置）一般的位置p架构设计往往发生在细节需求尚未完成的时候进架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。可能变更。原先的架构肯定会有不足或错误的地方。p为了实现不断的改进，我们将在开发流程中引入为了实现不断的改进，我们将在开发流程中引入迭代的概念。迭代的概念。 （2 2）必要性）必要性-架构是软件设计中非常重要的一架构是软件设计中非常重要的一个环节个环节在软件开发的过程中，只要需求和架构确定之后，在软件开发的过程中，只要需求和架构确定之后，我们认为这个软件

19、也就基本上可以定型了我们认为这个软件也就基本上可以定型了-这就好这就好比骨骼确定了，这个人的体形就不会有很大的变化一比骨骼确定了，这个人的体形就不会有很大的变化一样！样！ 30 软件架构设计的一些特点软件架构设计的一些特点处于软件系统建设的上游需要全面考虑多方面的因素对于同一个问题，可以有多种设计结果是在各种制约条件下取得的较好折衷方案科学 + 经验 + 艺术“系统架构”往往被滥用需求分析需求分析架构设计架构设计系统设计系统设计系统开发系统开发测试上线测试上线 31 架构设计的重要性架构设计的重要性建造一个系统所作出的最高层次的、以后难建造一个系统所作出的最高层次的、以后难以更改的，商业的和技

20、术的决定。以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决这样的决定必定是有关系统设计成败的最重要决定，必须经过慎重的研究和考察。定，必须经过慎重的研究和考察。 32 软件系统架构的主要工作内容软件系统架构的主要工作内容（1 1）架构调研）架构调研-广义上，是对系统的重大设计广义上，是对系统的重大设计决策有特别影响的需求进行分

21、析决策有特别影响的需求进行分析p是指识别对系统存在或可能存在重大影响的功能性是指识别对系统存在或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求）。或非功能性需求（特别是非功能性需求）。p例如市场趋势、性能、成本、维护和系统演进等。例如市场趋势、性能、成本、维护和系统演进等。（2 2）架构设计）架构设计-主要包括体系结构设计和各个主要包括体系结构设计和各个层模块设计层模块设计 是指对软件、硬件、网络、运营、政策等软件设是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。计中的需求和要素进行决策。 在统一过程（在统一过程（RUPRUP）中，架构调研和架）中，架构调研和架

22、构设计统称为架构分析。构设计统称为架构分析。 33 架构设计工作的基本流程 34 架构的两要素架构的两要素-元件划分和设计决定元件划分和设计决定逻辑元件：一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。设计决定：进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。 35 系统架构设计时所应考虑的问题（1 1）何时开展架构）何时开展架构-需求分析和建模完成后需求分析和建模完成后这需要项目经理以

23、具体的经验判断来评估此时是否足以能这需要项目经理以具体的经验判断来评估此时是否足以能够开始构建软件架构的工作。够开始构建软件架构的工作。（2 2）架构设计工作不仅要依据静态的系统目标，也）架构设计工作不仅要依据静态的系统目标，也要考虑动态的开发过程要考虑动态的开发过程静态的系统目标静态的系统目标一般为：功能需求、非功能需求和变化的用例等一般为：功能需求、非功能需求和变化的用例等动态的开发过程动态的开发过程一般为：如人力资源的情况，进度要求的情况，开发环境一般为：如人力资源的情况，进度要求的情况，开发环境的满足情况。的满足情况。（3 3）针对不同需求进行架构设计）针对不同需求进行架构设计软件架构

24、师必须全面把握各种各样的需求、权衡需求之间软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。有可能的矛盾之处，分门别类地将不同需求一一满足。 36 软件架构的层次软件架构的层次层次层次特征特征说明说明Enterprise 关注 整个机构、企业所有 IT 系统的整体能力 从整体着眼、与业务紧密相关、与IT 规划相关最高层，人数极少Application 负责应用系统的架构，奠定系统建设的基础 关注系统内部的构成和子系统/模块的分划 需要负责与外部相关系统的互联互通系统架构最高层，大型系统需要有一个架构组System/Sub-System 根据应用系

25、统的逻辑架构制定相应的技术实现方式，设计系统的物理架构一个系统建设项目中常常有多个Component 负责系统模块的实现机制和详细结构设计 为系统开发建设奠定基础常常由系统工程是担任Data/Information 负责应用系统的信息和数据模型和结构 通常包括数据库模型和结构设计常常由数据库专家负责Security 负责系统的安全架构设计 涉及系统所有层面的安全措施需要由安全专家负责，极缺Network 系统内部、外部的网络拓扑设计常常由网络集成商负责Others 不同建设项目常常有一些特殊需求 37 软件架构的分类分类分类特征特征说明说明概念架构 关注 整个机构、企业所有 IT 系统的整体能

26、力 从整体着眼、与业务紧密相关、与IT 规划相关逻辑架构 系统子系统、模块分划 功能边界的确定 分布式计算系统设计的特点物理架构 针对代码开发 与采用的语言、技术平台紧密相关数据架构 数据库设计部署架构 针对系统硬件部署 与逻辑架构不同 分布式系统有许多特别的性能和安全考虑 38 逻辑架构逻辑架构软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件等等。 39 物理架构物理架构软件元件是怎样放到硬件上的下图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、

27、主机等等。 40 系统架构系统架构系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作是架构设计工作中最困难的工作。 41 提问提问结合以下观点，谈谈你对软件架构的认识1. 架构既是一个动词也是一个名词；2. 架构是做出一系列重大决策；3. 架构是找出相对稳定的一些特质；4. 架构是站在较高层面对系统进行划分5. 架构研究元件、连接器以及它们的组合6. 架构是一门科学7. 架构是一门艺术8. 架构是有经验可借鉴的 42 关于关于“什么是架构什么是架构”的笑话的笑话 43 Architecture ViewArch

28、itecture View 44 通过这样通过这样5 5种视图可以完整地展示系统的架构，同时不同的视种视图可以完整地展示系统的架构，同时不同的视图也是面对不同的人员的。图也是面对不同的人员的。RUP 中将中将“4+1 View”称为称为 Architecture View 45 不同的视图所代表的含义逻辑视图：逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型并当采用面向对象的设计方法时，逻辑视图即对象模型并关注功能。关注功能。 实现视图：实现视图：描述软件在开发环境下的静态组织；关注程序包，不仅描述软件在开发环境下的静态组织；关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三

29、方包括要编写的源程序，还包括可以直接使用的第三方SDKSDK和现成框架、类库，以及开发的系统将运行于其上和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件的系统软件或中间件进程视图：进程视图：描述系统的并发和同步方面的设计。描述系统的并发和同步方面的设计。 部署视图：部署视图：描述软件如何映射到硬件，反映系统在分布方面的设计。描述软件如何映射到硬件，反映系统在分布方面的设计。 46 为什么对架构要采用多视图为什么对架构要采用多视图架构要涵盖的内容和决策太多了，并且涉及不架构要涵盖的内容和决策太多了，并且涉及不同方面的内容，不能采用某一种形式的图来描同方面的内容，不能采用某一种形式的

30、图来描述，因此采用述，因此采用“分而治之分而治之”的办法从不同视角的办法从不同视角分别设计；分别设计；同时，由于也涉及不同方面的人员理解、交流同时，由于也涉及不同方面的人员理解、交流和归档提供了方便。和归档提供了方便。 47 经典经典“4+1 View”4+1 View” 48 其他多视图方法其他多视图方法 49 温昱温昱 ADMEMS ADMEMS方法中的方法中的5 5视图视图 50 温昱温昱 ADMEMS ADMEMS方法中的方法中的5 5视图视图 51 温昱温昱 ADMEMS ADMEMS方法中的方法中的5 5视图视图 52 成为软件架构师的途径成为软件架构师的途径软件架构 巨大的知识海

31、洋门槛相对较高、职业生涯非常长相对独立于技术的新陈代谢适合于喜欢学习的人不断学习、增加积累、注重经验注意学习方法论、框架不断增加各种系统架构的知识经验积累非常重要在与高手和同行合作中提高水平与高手的合作是最佳途径同行之间的交流也非常有效在每一个项目中进行创新 53 架构师一定要有高超的需求思维 54 架构师一定要有高超的需求思维 55 架构师一定要有高超的需求思维 56 第1步：需求结构化业务目标、及业务愿景：业务目标、及业务愿景：网站定位：B2C零售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：商业质量：新功能上线快，随需应变商

32、业约束：商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）用户用户开发开发组织组织功功 能能质质 量量约约 束束 57 第1步：需求结构化用户：用户： 终端用户 各种员工角色运行期质量：运行期质量： 易用性：最便捷的选择方式用户级约束：用户级约束： 便捷的购物流程 客户群大：多国语言 客户群大：关注范围差异，须个性化 消费心理：营造集市效应，“别人也买了”、“别人还买了”开发方约束：开发方约束： 新组建的团队用户用户开发开发组织组织功功 能能质质 量量约约 束束 58

33、 第2步：分析约束影响业务目标、及业务愿景：业务目标、及业务愿景：网站定位：B2C零售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：商业质量：新功能上线快，随需应变商业约束：商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）开发方约束：开发方约束： 网站发展路线图用户用户开发开发组织组织功功 能能质质 量量约约 束束 59 第2步：分析约束影响业务目标、及业务愿景：业务目标、及业务愿景：网站定位：B2C零

34、售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：商业质量：新功能上线快，随需应变商业约束：商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）用户：用户：终端用户各种员工角色管理员功能：管理员功能：灵活的打折设置频率极高的新货上架开发期质量：开发期质量： 可扩展性用户用户开发开发组织组织功功 能能质质 量量约约 束束 60 第2步：分析约束影响用户：用户：终端用户各种员工角色终端用户功能：终端用户功能：最快

35、的全库搜索评价功能（Web2.0）多角度关联信息管理员功能：管理员功能：灵活的打折设置频率极高的新货上架用户级约束：用户级约束： 便捷的购物流程 客户群大：多国语言 客户群大：关注范围差异，须个性化 消费心理：营造集市效应，“别人也买了”、“别人还买了”用户用户开发开发组织组织功功 能能质质 量量约约 束束 61 第2步：分析约束影响业务目标、愿景：业务目标、愿景：网站定位：B2C零售当前经营：图书未来经营：商业质量：商业质量：新功能上线快，随需应变商业约束：商业约束：投资2000万集成约束：集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）运行期质量：

36、运行期质量：可伸缩性：几乎没有上限性能：即强调速度，又强调吞吐量安全性：数据安全持续可用性：不停机 互操作性：含公司各系统间互操作开发期质量：开发期质量：可扩展性用户用户开发开发组织组织功功 能能质质 量量约约 束束62架构设计的目标之一架构设计的目标之一-希望能够最大化地重用希望能够最大化地重用1.如何能达到最大化的重用？如何能达到最大化的重用？答：在系统架构设计中灵活地使用各种共享的，特别答：在系统架构设计中灵活地使用各种共享的，特别是开源的框架技术是开源的框架技术2.为什么要在系统架构设计中应用成熟的框架？为什么要在系统架构设计中应用成熟的框架？答：软件系统已经发展的很复杂，一些基础性的

37、工作答：软件系统已经发展的很复杂，一些基础性的工作没有必要重复去做；框架一般是成熟、稳健的；框没有必要重复去做；框架一般是成熟、稳健的；框架本身的结构比较好，使用框架会使软件系统的可架本身的结构比较好，使用框架会使软件系统的可扩展性很好扩展性很好3.采用采用SSH框架技术架构框架技术架构J2EE的轻量级系统的轻量级系统63架构设计的目标之二架构设计的目标之二-使软件系统实现可扩展性使软件系统实现可扩展性1.软件系统开发必须要考虑的一个问题软件系统开发必须要考虑的一个问题-如何尽可能如何尽可能延长软件系统的生命期，降低投资成本？延长软件系统的生命期，降低投资成本？2.如何使软件系统具有最灵活的扩

38、展性？如何使软件系统具有最灵活的扩展性？答：灵活应用各种架构模式和代码的设计模式答：灵活应用各种架构模式和代码的设计模式 64 不同层次的模式不同层次的模式 区别：在于三种不同的模式存在于它们各自的抽象层次和具体层次。 架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质。架构模式的好坏可以影响到总体布局和框架性结构。 设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。 代码模式是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内

39、部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。 65 架构模式架构模式(Architectural Pattern)(Architectural Pattern) 软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解。 众多软件架构概念都是围绕“组成”和“决策”两个视角展开的。66架构设计的目标之三架构设计的目标之三-设计出设计出“高内聚低耦合高内聚低耦合”的应用系的应用系统统l内聚度：是指程序中的操作之间联

40、系紧密的程度。描述了一个子程序的内部成分之间相互联系的强度。 l耦合度：是指两个子程序联系的强度。描述了一个子程序与其他子程序之间的联系强度。 l耦合度与内聚度成反比。 l目标：具有内部完整性（强内聚）的子程序，以及小的、直接的、可见的、灵活的与其他子程序之间的联系（ 松耦合）67内聚类型内聚类型内聚类型内聚类型描描 述述功能内聚 完成一个单一功能单一功能，各个部分协同工作，缺一不可顺序内聚 处理元素相关，而且必须顺序执行顺序执行通信内聚 所有处理元素集中元素集中在一个数据结构的区域上过程内聚 处理元素相关，而且必须按特定的次序执行特定的次序执行瞬时内聚 所包含的任务必须在同一时间间隔内执行同

41、一时间间隔内执行（如初始化模块）逻辑内聚 完成逻辑上相关逻辑上相关的一组任务偶然内聚 完成一组没有关系没有关系或松散关系松散关系的任务低68耦合类型耦合类型高耦合类型描 述非直接耦合没有直接联系，互相不依赖对方数据耦合借助参数表传递简单数据标记耦合一个数据结构的一部分借助于模块接口被传递控制耦合模块间传递的信息中包含用于控制模块内部逻辑的信息外部耦合与软件以外的环境有关公共耦合多个模块引用同一个全局数据区内容耦合一个模块访问另一个模块的内部数据一个模块不通过正常入口转到另一模块的内部两个模块有一部分程序代码重叠一个模块有多个入口 69 架构的目标架构的目标可靠性（Reliable）：软件系统对

42、于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。安全性（Secure） ：软件系统所承担的交易的商业价值极高，系统的安全性非常重要。可伸缩性（Scalable） ：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。 70 架构的目标架构的目标可定制化（Customizable） ：同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。可扩展性（Extensible）：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可维护性（Maintainable）：软件系统的维护包括两

43、方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。 71 架构的目标架构的目标客户体验（Customer Experience）：软件系统必须易于使用。市场时机（Time to Market）：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。 72 没有一个统一的没有一个统一的“万能（通用）万能（通用）”的系统架构的系统架构因为软件的系统架构设计是和千差万别的具因为软件的系统架构设计是和千差万别的具体软件系统的要求、所应用的技术和开发平台等体软件系统的要求、所应用的技术和开发平台等因素是密切相关

44、的，因此在此无法给出一个通用因素是密切相关的，因此在此无法给出一个通用的的“系统架构设计系统架构设计”解决方案。解决方案。尽管存在上面的原因，但我们认为在尽管存在上面的原因，但我们认为在“系统系统架构设计架构设计”中还是会有一些共性的东西，以及能中还是会有一些共性的东西，以及能够说明哪些因素是需要考虑的。够说明哪些因素是需要考虑的。对于每个因素的设计策略和具体的解决方对于每个因素的设计策略和具体的解决方法还需要我们的软件架构设计师在具体开发实法还需要我们的软件架构设计师在具体开发实践中灵活把握践中灵活把握-不同因素之间有时是矛盾的，不同因素之间有时是矛盾的，架构设计时需要根据具体情况进行平衡。

45、架构设计时需要根据具体情况进行平衡。 73 提纲提纲3.1 概要设计 3.2 软件架构设计 3.33.3 系统架构实践系统架构实践 74 软件框架软件框架 什么是框架 框架与架构的区别 常见的框架 75 框架框架 什么是框架？框架，即framework。是某种应用的半成品，就是一组组件，供选用完成自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。 框架与架构的区别？并无明确的定义，但一般从层的观点看，认为框架是底层的，接近系统的。软件开发者在其上构建自己的软件架构，开发自己的运用程序。 76 为什么要用框架为什么要用框架 因为软件系统发展到今天已经很

46、复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用成熟的框架，可以避免重复做已有的基础工作，而只需要集中精力完成系统的业务逻辑设计。 框架一般是成熟，稳健的，可以处理系统很多细节问题，比如，事物理，安全性，数据流控制等问题。 框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，使用框架的开发者可以直接享受别人升级代码带来的好处。 框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。 77 常见的框架常见的框架 常见的JAVA框架 常见的.Net框架 其它基于C+的框架 78 常见的常见的JAVAJAVA框架框架 EJB WAF St

47、ruts Turbine COCOON ECHO JATO TCF Spring Hibernate IBatis JSF 79 架构模式架构模式 不同层次的软件模式 架构的主流的定义 80 不同层次的模式不同层次的模式 架构模式(Architectural Pattern) 设计模式(Design Pattern) 代码模式(Coding Pattern)又称为成例(Idiom) 81 一些主流的架构定义一些主流的架构定义 Booch、Rumbaugh和Jacobson的定义 Woods的观点 Garlan和Shaw的定义 Perry和Wolf的定义 Boehm的定义 IEEE的定义 Bas

48、s的定义 82 BoochBooch、RumbaughRumbaugh和和JacobsonJacobson的定义的定义 架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织包括这些元素及其接口、它们的协作和它们的组合架构风格。 83 GarlanGarlan和和ShawShaw的定义的定义 架构包括组件（Component）、连接件（Connector）和约束（Constrain）三大要素。组件可以是一组代码（例如程序模块），也可以是独立

49、的程序（例如数据库服务器）。连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系。“约束” 一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。 84 IEEEIEEE的定义的定义 IEEE 610.12-1990软件工程标准词汇中是这样定义架构的： 架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理（Principle）。 85 架构组件交互架构组件交互 Shaw的定义：“软件系统的架构将系统描述

50、为计算组件及组件之间的交互”。 86 软件架构模式软件架构模式 软件架构模式(Architectural pattern)又称软件体系结构风格(Architectural style)一种体系结构风格以结构组织模式定义了一个系统家族关于构件和连接件类型的术语一组约束它们组合方式的规定一个或多个语义模型，规定了如何从各成分的特性决定系统整体特性 概括地说，一种软件体系结构风格刻划一个具有共享结构和语义的系统家族。 87 几种典型的架构模式几种典型的架构模式 系统软件分层(Layer)管道和过滤器(Pipes and Filters)黑板(Blackboard) 开发分布式软件经纪人(Broker

51、) 客户/服务器（Client/Server）点对点（Peer to Peer） 交互软件模型-视图-控制器（Model-View-Controller）显示-抽象-控制（Presentation-Abstraction-COntrol） 88 其它其它 面向对象风格(ADT) 基于消息广播且面向图形用户界面的Chiron2风格 基于事件的隐式调用风格(Event-based, Implicit Invocation) 89 分层分层(Layer)(Layer) 从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中。 软件为什么要分层？为了实现“高内聚、低耦合”。把问题划分开来各个

52、解决，易于控制，易于延展，易于分配资源 面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个部分。完成这一目标的一种好方法就是在层上工作，将一个应用程序的主要功能分离到不同的层或者级中。 90 分层模型分层模型 从本质上讲，层代表了一个应用程序主要的功能。一般地，我们将应用程序功能分为三个方面，对应3层架构模式。它们是数据层（data layer）、商务层（business layer）和表示层（presentation layer）。 数据层：包含数据存储和与它交互的组件或服务。这些组件和服务在功能上和中间层相互独立（尽管在物理上不必一定相互独立-它们可以在同一台服务器上）。 中

53、间层：包括一个或者多个组件服务，它们应用商务规则、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一部分，中间层负责处理来自数据存储或者发送给数据存储的数据。 表示层：从中间层获得信息并显示给用户。该层同时也负责和用户进行交互，比较返回的信息并将信息回送给中间层进行处理。 91 数据层从数据库中获得较为原始的数据，商务层把数据转换成符合商务规则的有意义的信息，表示层把信息转换成对于用户有意义的内容。 这种分层设计方式很有用，因为每一层都可以独立地修改。我们可以修改商务层，不断地从数据层接受相同的数据，并把这些数据传递到表示层，而不用担心出现歧义。我们也可以修改表示层，使得对于

54、站点外观的修改不必改动下面的商务层逻辑。 92 管道和过滤器（管道和过滤器（Pipes and FiltersPipes and Filters） 管道和过滤器架构模式是为处理数据流的系统提供的一种模式。它是由过滤器和管道组成的.每个处理步骤都被封装在一个过滤器组件中，数据通过相邻过滤器之间的管道进行传输。每个过滤器可以单独修改，功能单一，并且它们之间的顺序可以进行配置。 93 一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。 94 问题： 一个必须处理或转换输入数据流的系统。把这样

55、的系统作为单个组件实现是不容易的：系统必须由几个开发人员同时进行协作开发，整个系统任务自然就被分解为几个处理阶段，而且需求很容易变动。因此你就要通过替换或重新排序处理步骤来为将来的灵活性作规划。通过加入这样的灵活性，采用现有处理组件构建是可以办到的。 系统的设计尤其是处理步骤的内部连接，必须考虑以下因素：未来系统的升级通过替换某些处理步骤，或重组步骤。不同的语境中小的处理步骤要比大的组件更易于重用。不相连的处理步骤不可共享信息。存在不同的输入数据源，可以用多种方式输出或存放最终结果。 95 解决方案与结构解决方案与结构 管道和过滤器体系架构模式把系统任务分成为几个独立的处理步骤。这些步骤采用通

56、过系统的数据流连接。一个步骤的输出是下一个步骤的输入。每个处理步骤由一个过滤器组件实现，它处理或者转化数据，并且系统的输入可以是多种数据源。 这种体系架构模式具有许多特性：过滤器是独立运行的部件。也就是除了输入和输出外，每个过滤器不受任何其他过滤器运行的影响。在设计上，过滤器之间不共享任何状态信息。独立性还表现在它对其处理的上游和下游连接的过滤器是无知的.它的设计和使用不对与其连接的任何过滤器施加限制，唯一关心的是其输入数据的，然后进行加工处理，最后产生数据输出。 96 优点与缺点优点与缺点 优点：结构简单：系统的行为是所有过滤器行为的简单复合。系统易于维护和增强：增加新过滤器，替换旧过滤器。

57、支持复用：过滤器只同其输入、输出端口的数据相关。各过滤器可以并发运行。 缺点：容易导致批处理方式：每个过滤器从输入数据到输出数据的转换是一个整体。转换通常不适合交互式的应用。有时必须维护两个分离而又相关的流之间的对应关系。同实现有关，过滤器之间的数据传输率较低，而且每个过滤器都要作类似的数据打包和解包的工作。 97 黑板黑板(Blackboard)(Blackboard) 又称看板模式：在这种架构中，有两种不同的构件：一种是表示当前状态中心数据结构；另一种是一种相互独立的构件，这些构件对中心数据进行操作。这种架构主要用于数据库和人工智能系统的开发。 模式识别、数据挖掘。 98 经纪人经纪人(B

58、roker)(Broker) 客户和服务器通过一个经纪人部件进行通信，经纪人负责协调客户和服务器之间的操作，并且为客户和服务器发送请求和结果信息。 99 客户客户/ /服务器（服务器（Client/ServerClient/Server） 系统分为客户和服务器，服务器一直处于侦听的状态，客户主动连接服务器，每个服务器可以为多个客户服务。 100 优缺点优缺点 优点：结构简单，系统中不同类型的任务分别由客户和服务器承担，有利于发挥不同机器平台的优势；支持分布式、并发环境，特别是当客户和服务器之间的关系是多对多时，可以有效地提高资源的利用率和共享程度；服务器集中管理资源，有利于权限控制和系统安全。

59、 缺点：在大多数client-server风格的系统中，构件之间的连接通过（远程）过程调用，接近于代码一级，表达能力较弱。 101 点对点（点对点（Peer to PeerPeer to Peer） 系统中的节点都处于平等的地位，每个节点都可以连接其他节点。在这种架构中，一般需要由一个中心服务器完成发现和管理节点的操作。ICQ以及Web Service技术的大多数应用，都是典型的点对点结构。 102 模型模型- -视图视图- -控制器（控制器（MVCMVC） 当应用程序的用户界面非常复杂，且关于用户界面的需求很容易变化时，我们可以把交互类型的软件抽象成模型、视图和控制器这三类组件单元，这种抽象

60、可以很好地分离用户界面和业务逻辑，适应变化的需求。大多数现代交互软件都在一定程度上符合这一架构模型的特点。 MVCMVC模式最吸引人之处在于它迫使用户必须抽象自己的代码，把项模式最吸引人之处在于它迫使用户必须抽象自己的代码，把项目分为表示、逻辑和控制三部分目分为表示、逻辑和控制三部分, ,每部分间的关联较小。每部分间的关联较小。 以MVC模式构造软件,可以使得软件结构灵活、重用性好、扩展性佳。 103 模型模型视图视图控制器交互的示意图控制器交互的示意图 104 模型：视图：控制器模型：视图：控制器: : 模型： 模型表示应用的数据及操作这些数据的逻辑方法。任何和整个应用有关的持久性数据都应该