概要设计建模指南

第三章系统概要设计中的架构设计于千城yu_computer纲§3.1

概要设计§3.2软件架构设计§3.3系统架构实践21、什么是系统设计 所谓系统设计就是通过某种特定的平台，而达到完成项目的整体软件的功能和性能。 从工程管理的角度来看，软件设计分两步完成。（1）概要设计（静态结构） 将软件需求转化为数据结构和软件的系统结构。划分出组成系统的物理元素：程序、数据库、过程、文件等。（2）详细设计（动态结构） 通过对结构表示进行细化，得到软件的详细的数据结构和算法、关键性问题的解决等。

一、系统设计

3结构4为什么要进行系统设计

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

我们不要幻想直接把分析类图画好后，就直接按照其去编码。5分析和设计应该是合作的设计中所需要的各种信息，主要来自于分析。分析面向问题，是明确动力的过程，重在理解和翻译，灵活性高。设计面向方案，是排除阻力的过程，重在精化和适应，受约束大。从整体上看，分析和设计的对立是保障问题和方案趋于一致的基本动力。就像两个相反方向的张力，使软件朝着正确的方向前进。6软件设计的“3W”原则Who

为谁设计，用户是谁What

要解决用户的哪些问题----功能方面、性能方面Why

为什么要解决这些问题----为用户带来价值、降低开发方的成本等7在什么时期进行概要设计（结构设计）在需求“明确”并对需求进行域建模之后，要做概要设计概要设计对后面的开发、测试、实施、维护工作起到关键性的影响。概要设计的重要性主要体现在它是把需求转化为软件系统的最重要的环节，并且系统设计的优劣在根本上决定了软件系统的质量。8概要设计中所涉及的主要内容（1）制定规范代码体系、接口规约、命名个风格等规则规定设计文档的编制标准。规定与硬件、操作系统的接口规约，命名规则

因为，这些是项目小组今后共同开发的基础。并且使整个软件开发工作可以协调有序地进行。（2）体系结构设计（架构设计） 体系结构是对复杂事物的一种抽象，如C/S和B/W/S结构。（3）划分系统中的各个模块及组件类的设计根据用户的需求实现从功能上来划分各个功能模块，在模块设计中保持“功能独立---单一职责原则SRP”是模块化设计的基本原则。因为，“功能独立”的模块可以降低开发、测试、维护等阶段的代价。

9概要设计中所涉及的主要内容（4）数据结构与算法设计设计高效率的程序是基于良好的数据结构与算法，而不是基于编程小技巧的。一般说来，数据结构与算法就是一类数据的表示及其相关的操作。

确定软件涉及的文件系统的结构以及数据库的模式、子模式，进行数据完整性和安全性的设计，并确定输入，输出文件的详细的数据结构

（5）数据库的逻辑设计（6）其它----如可靠性、安全性设计等10概要设计中所涉及的系统设计的一些基本的原则（1）先进性和实用性（2）可靠性和开放性（3）可维护性和可伸缩性（4）可移植性11概要设计的重要输出（1）概要设计说明书编码规范：信息形式、接口规约、命名规则；物理模型：组件图、配置图；不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；（2）数据库设计说明书（3）用户手册（4）制定初步的测试计划和方案

12概要设计说明书参考格式13概要设计说明书参考格式14概要设计说明书参考格式15概要设计说明书参考格式16概要设计说明书参考格式17概要设计阶段的工作重点（1）工作的重点内容是设计软件的体系结构（2）核心问题-----能否使用重复的体系结构模式也就是能否达到结构级的软件重用---即能否在不同的软件体系中，使用同一体系结构。（3）

这个阶段是系统架构师发挥作用的主要阶段。18提纲§3.1概要设计§3.2

软件架构设计

§3.3系统架构实践19软件架构的一般概念（1）什么是架构-----在IT，架构普遍指通过某种特定的平台，而达到完成整体软件的功能的设计过程。（2）Architecture 其英文的本意是来源于建筑行业的建筑艺术、建筑（风格）和结构。 就像高楼大厦的钢骨结构,将无数个“Part”

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

21体系结构关注的问题体现在“不变”因素上体系结构从更高的层面上考虑问题-----关注的问题就体现在“不变”因素上体系结构一般关心应用程序的模式，更加体现在通过技术去解决这些业务差异带来的影响。比如，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全----因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术的使用。22系统架构是一个软件系统从整体到部分的最高层次的划分一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括：架构元件（ArchitectureComponent）

架构元件，也就是组成系统的核心"砖瓦"联结器（Connector）

联结器描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果任务流（Task-flow）。任务流描述系统如何使用这些元件和联结器完成某一项需求。23在软件开发中，架构既可以是名词，也可以是动词（1）架构作为名词来理解 是指提供一个统一的共享的框架或者是Framework，这种架构事实上是系统的一个层，这里的架构是名词。（2）架构作为动词来理解 是指设计构造系统或者是Archiecture，这里的架构更多的是动词（此时的架构一部分是调研工作，一部分是设计等工作）

24当做名词时，也称软件体系结构软件体系结构至少有十几种思想流派。Zachman框架开放分布式处理领域分析Rational4＋1视图模型软件体系结构风格供应商驱动的方案SunEnterpriseJavaBeansMS.Net体系25软件体系结构风格MVC风格管道－过滤器风格客户－服务器风格层次系统仓储（数据库和黑板）风格面向对象风格基于消息广播且面向图形用户界面的Chiron2风格基于事件的隐式调用风格26当做动词时，指进行架构设计27没有进行架构设计的结果28软件架构在软件系统开发中的位置（1）一般的位置架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。为了实现不断的改进，我们将在开发流程中引入迭代的概念。

（2）必要性---架构是软件设计中非常重要的一个环节

在软件开发的过程中，只要需求和架构确定之后，我们认为这个软件也就基本上可以定型了-----这就好比骨骼确定了，这个人的体形就不会有很大的变化一样！29软件架构设计的一些特点处于软件系统建设的上游需要全面考虑多方面的因素对于同一个问题，可以有多种设计结果是在各种制约条件下取得的较好折衷方案科学+经验+艺术“系统架构”往往被滥用需求分析架构设计系统设计系统开发测试上线30架构设计的重要性建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过慎重的研究和考察。31软件系统架构的主要工作内容（1）架构调研----广义上，是对系统的重大设计决策有特别影响的需求进行分析是指识别对系统存在或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求）。例如市场趋势、性能、成本、维护和系统演进等。（2）架构设计----主要包括体系结构设计和各个层模块设计

是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。

在统一过程（RUP）中，架构调研和架构设计统称为架构分析。32架构设计工作的基本流程33架构的两要素---元件划分和设计决定逻辑元件：一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。设计决定：进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。34系统架构设计时所应考虑的问题（1）何时开展架构----需求分析和建模完成后这需要项目经理以具体的经验判断来评估此时是否足以能够开始构建软件架构的工作。（2）架构设计工作不仅要依据静态的系统目标，也要考虑动态的开发过程静态的系统目标一般为：功能需求、非功能需求和变化的用例等动态的开发过程一般为：如人力资源的情况，进度要求的情况，开发环境的满足情况。（3）针对不同需求进行架构设计软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。35软件架构的层次层次特征说明Enterprise

关注整个机构、企业所有IT系统的整体能力从整体着眼、与业务紧密相关、与IT规划相关最高层，人数极少Application

负责应用系统的架构，奠定系统建设的基础关注系统内部的构成和子系统/模块的分划需要负责与外部相关系统的互联互通系统架构最高层，大型系统需要有一个架构组System/Sub-System

根据应用系统的逻辑架构制定相应的技术实现方式，设计系统的物理架构一个系统建设项目中常常有多个Component负责系统模块的实现机制和详细结构设计为系统开发建设奠定基础常常由系统工程是担任Data/Information负责应用系统的信息和数据模型和结构通常包括数据库模型和结构设计常常由数据库专家负责Security负责系统的安全架构设计涉及系统所有层面的安全措施需要由安全专家负责，极缺Network

系统内部、外部的网络拓扑设计常常由网络集成商负责Others…不同建设项目常常有一些特殊需求36软件架构的分类分类特征说明概念架构

关注整个机构、企业所有IT系统的整体能力从整体着眼、与业务紧密相关、与IT规划相关逻辑架构

系统子系统、模块分划功能边界的确定分布式计算系统设计的特点物理架构针对代码开发与采用的语言、技术平台紧密相关数据架构数据库设计部署架构针对系统硬件部署与逻辑架构不同分布式系统有许多特别的性能和安全考虑37逻辑架构软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件等等。38物理架构软件元件是怎样放到硬件上的下图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。39系统架构系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作是架构设计工作中最困难的工作。40提问结合以下观点，谈谈你对软件架构的认识架构既是一个动词也是一个名词；架构是做出一系列重大决策；架构是找出相对稳定的一些特质；架构是站在较高层面对系统进行划分架构研究元件、连接器以及它们的组合架构是一门科学架构是一门艺术架构是有经验可借鉴的41关于“什么是架构”的笑话42ArchitectureView43通过这样5种视图可以完整地展示系统的架构，同时不同的视图也是面对不同的人员的。RUP中将“4+1View”称为ArchitectureView44不同的视图所代表的含义逻辑视图：

当采用面向对象的设计方法时，逻辑视图即对象模型并关注功能。实现视图：

描述软件在开发环境下的静态组织；关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件进程视图：

描述系统的并发和同步方面的设计。部署视图：

描述软件如何映射到硬件，反映系统在分布方面的设计。45为什么对架构要采用多视图架构要涵盖的内容和决策太多了，并且涉及不同方面的内容，不能采用某一种形式的图来描述，因此采用“分而治之”的办法从不同视角分别设计；同时，由于也涉及不同方面的人员理解、交流和归档提供了方便。46经典“4+1View”47其他多视图方法48温昱–ADMEMS方法中的5视图49温昱–ADMEMS方法中的5视图50温昱–ADMEMS方法中的5视图51成为软件架构师的途径软件架构—巨大的知识海洋门槛相对较高、职业生涯非常长相对独立于技术的新陈代谢适合于喜欢学习的人不断学习、增加积累、注重经验注意学习方法论、框架不断增加各种系统架构的知识经验积累非常重要在与高手和同行合作中提高水平与高手的合作是最佳途径同行之间的交流也非常有效在每一个项目中进行创新52

架构师一定要有高超的需求思维53

架构师一定要有高超的需求思维54

架构师一定要有高超的需求思维55第1步：需求结构化业务目标、及业务愿景：网站定位：B2C零售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：新功能上线快，随需应变商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）用户开发组织功能质量约束56第1步：需求结构化用户：终端用户各种员工角色运行期质量：易用性：最便捷的选择方式用户级约束：便捷的购物流程客户群大：多国语言客户群大：关注范围差异，须个性化消费心理：营造集市效应，“别人也买了”、“别人还买了”开发方约束：新组建的团队用户开发组织功能质量约束57第2步：分析约束影响业务目标、及业务愿景：网站定位：B2C零售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：新功能上线快，随需应变商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）开发方约束：网站发展路线图用户开发组织功能质量约束58第2步：分析约束影响业务目标、及业务愿景：网站定位：B2C零售当前经营：图书未来经营：图书、软件、音乐制品、电子产品、玩具、婴儿用品、化妆品、宠物、艺术品、杂货。商业质量：新功能上线快，随需应变商业约束：投资2000万用于初期开发、运营、市场，之前须取得一定成功并融资成功集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）用户：终端用户各种员工角色管理员功能：灵活的打折设置频率极高的新货上架开发期质量：可扩展性用户开发组织功能质量约束59第2步：分析约束影响用户：终端用户各种员工角色终端用户功能：最快的全库搜索评价功能（Web2.0）多角度关联信息管理员功能：灵活的打折设置频率极高的新货上架用户级约束：便捷的购物流程客户群大：多国语言客户群大：关注范围差异，须个性化消费心理：营造集市效应，“别人也买了”、“别人还买了”用户开发组织功能质量约束60第2步：分析约束影响业务目标、愿景：网站定位：B2C零售当前经营：图书未来经营：……商业质量：新功能上线快，随需应变商业约束：投资2000万……集成约束：物流、银行、海关、实体店、各类提供商（包括工厂等生产企业、以及代理商等经销企业）运行期质量：可伸缩性：几乎没有上限性能：即强调速度，又强调吞吐量安全性：数据安全持续可用性：不停机互操作性：含公司各系统间互操作开发期质量：可扩展性用户开发组织功能质量约束61架构设计的目标之一

---希望能够最大化地重用如何能达到最大化的重用？答：在系统架构设计中灵活地使用各种共享的，特别是开源的框架技术为什么要在系统架构设计中应用成熟的框架？答：软件系统已经发展的很复杂，一些基础性的工作没有必要重复去做；框架一般是成熟、稳健的；框架本身的结构比较好，使用框架会使软件系统的可扩展性很好采用SSH框架技术架构J2EE的轻量级系统62架构设计的目标之二

---使软件系统实现可扩展性软件系统开发必须要考虑的一个问题---如何尽可能延长软件系统的生命期，降低投资成本？如何使软件系统具有最灵活的扩展性？答：灵活应用各种架构模式和代码的设计模式63不同层次的模式区别：在于三种不同的模式存在于它们各自的抽象层次和具体层次。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质。架构模式的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。代码模式是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。64架构模式(ArchitecturalPattern)软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解。众多软件架构概念都是围绕“组成”和“决策”两个视角展开的。65架构设计的目标之三

---设计出“高内聚低耦合”的应用系统内聚度：是指程序中的操作之间联系紧密的程度。描述了一个子程序的内部成分之间相互联系的强度。耦合度：是指两个子程序联系的强度。描述了一个子程序与其他子程序之间的联系强度。耦合度与内聚度成反比。目标：具有内部完整性（强内聚）的子程序，以及小的、直接的、可见的、灵活的与其他子程序之间的联系（松耦合）66内聚类型内聚类型描述功能内聚完成一个单一功能，各个部分协同工作，缺一不可顺序内聚处理元素相关，而且必须顺序执行通信内聚所有处理元素集中在一个数据结构的区域上过程内聚处理元素相关，而且必须按特定的次序执行瞬时内聚所包含的任务必须在同一时间间隔内执行（如初始化模块）逻辑内聚完成逻辑上相关的一组任务偶然内聚完成一组没有关系或松散关系的任务低67耦合类型高耦合类型描述非直接耦合没有直接联系，互相不依赖对方数据耦合借助参数表传递简单数据标记耦合一个数据结构的一部分借助于模块接口被传递控制耦合模块间传递的信息中包含用于控制模块内部逻辑的信息外部耦合与软件以外的环境有关公共耦合多个模块引用同一个全局数据区内容耦合一个模块访问另一个模块的内部数据一个模块不通过正常入口转到另一模块的内部两个模块有一部分程序代码重叠一个模块有多个入口68架构的目标可靠性（Reliable）：软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。安全性（Secure）：软件系统所承担的交易的商业价值极高，系统的安全性非常重要。可伸缩性（Scalable）：软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。69架构的目标可定制化（Customizable）：同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。可扩展性（Extensible）：在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展可维护性（Maintainable）：软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。70架构的目标客户体验（CustomerExperience）：软件系统必须易于使用。

市场时机（TimetoMarket）：软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。71没有一个统一的“万能（通用）”的系统架构因为软件的系统架构设计是和千差万别的具体软件系统的要求、所应用的技术和开发平台等因素是密切相关的，因此在此无法给出一个通用的“系统架构设计”解决方案。尽管存在上面的原因，但我们认为在“系统架构设计”中还是会有一些共性的东西，以及能够说明哪些因素是需要考虑的。对于每个因素的设计策略和具体的解决方法还需要我们的软件架构设计师在具体开发实践中灵活把握-----不同因素之间有时是矛盾的，架构设计时需要根据具体情况进行平衡。72提纲§3.1概要设计§3.2软件架构设计§3.3

系统架构实践

73软件框架什么是框架框架与架构的区别常见的框架74框架什么是框架？框架，即framework。是某种应用的半成品，就是一组组件，供选用完成自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。框架与架构的区别？并无明确的定义，但一般从层的观点看，认为框架是底层的，接近系统的。软件开发者在其上构建自己的软件架构，开发自己的运用程序。75为什么要用框架因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用成熟的框架，可以避免重复做已有的基础工作，而只需要集中精力完成系统的业务逻辑设计。框架一般是成熟，稳健的，可以处理系统很多细节问题，比如，事物理，安全性，数据流控制等问题。框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，使用框架的开发者可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。76常见的框架常见的JAVA框架常见的.Net框架其它基于C++的框架77常见的JAVA框架EJBWAFStrutsTurbineCOCOONECHOJATOTCFSpringHibernateIBatisJSF78架构模式不同层次的软件模式架构的主流的定义79不同层次的模式架构模式(ArchitecturalPattern)设计模式(DesignPattern)代码模式(CodingPattern)又称为成例(Idiom)80一些主流的架构定义Booch、Rumbaugh和Jacobson的定义Woods的观点Garlan和Shaw的定义Perry和Wolf的定义Boehm的定义IEEE的定义Bass的定义81Booch、Rumbaugh和Jacobson的定义架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。82Garlan和Shaw的定义架构包括组件（Component）、连接件（Connector）和约束（Constrain）三大要素。组件可以是一组代码（例如程序模块），也可以是独立的程序（例如数据库服务器）。连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系。“约束”一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。83IEEE的定义IEEE610.12-1990软件工程标准词汇中是这样定义架构的：架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理（Principle）。84架构＝组件＋交互Shaw的定义：“软件系统的架构将系统描述为计算组件及组件之间的交互”。85软件架构模式软件架构模式(Architecturalpattern)又称软件体系结构风格(Architecturalstyle)一种体系结构风格以结构组织模式定义了一个系统家族关于构件和连接件类型的术语一组约束它们组合方式的规定一个或多个语义模型，规定了如何从各成分的特性决定系统整体特性概括地说，一种软件体系结构风格刻划一个具有共享结构和语义的系统家族。86几种典型的架构模式系统软件分层(Layer)管道和过滤器(PipesandFilters)黑板(Blackboard)开发分布式软件经纪人(Broker)客户/服务器（Client/Server）点对点（PeertoPeer）交互软件模型-视图-控制器（Model-View-Controller）显示-抽象-控制（Presentation-Abstraction-COntrol）87其它面向对象风格(ADT)基于消息广播且面向图形用户界面的Chiron2风格基于事件的隐式调用风格(Event-based,ImplicitInvocation)…88分层(Layer)从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中。

软件为什么要分层？

为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个部分。完成这一目标的一种好方法就是在层上工作，将一个应用程序的主要功能分离到不同的层或者级中。89分层模型从本质上讲，层代表了一个应用程序主要的功能。一般地，我们将应用程序功能分为三个方面，对应3层架构模式。它们是数据层（datalayer）、商务层（businesslayer）和表示层（presentationlayer）。数据层：包含数据存储和与它交互的组件或服务。这些组件和服务在功能上和中间层相互独立（尽管在物理上不必一定相互独立--它们可以在同一台服务器上）。中间层：包括一个或者多个组件服务，它们应用商务规则、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一部分，中间层负责处理来自数据存储或者发送给数据存储的数据。表示层：从中间层获得信息并显示给用户。该层同时也负责和用户进行交互，比较返回的信息并将信息回送给中间层进行处理。90数据层从数据库中获得较为原始的数据，商务层把数据转换成符合商务规则的有意义的信息，表示层把信息转换成对于用户有意义的内容。这种分层设计方式很有用，因为每一层都可以独立地修改。我们可以修改商务层，不断地从数据层接受相同的数据，并把这些数据传递到表示层，而不用担心出现歧义。我们也可以修改表示层，使得对于站点外观的修改不必改动下面的商务层逻辑。91管道和过滤器（PipesandFilters）管道和过滤器架构模式是为处理数据流的系统提供的一种模式。它是由过滤器和管道组成的.每个处理步骤都被封装在一个过滤器组件中，数据通过相邻过滤器之间的管道进行传输。每个过滤器可以单独修改，功能单一，并且它们之间的顺序可以进行配置。92一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。93问题：一个必须处理或转换输入数据流的系统。把这样的系统作为单个组件实现是不容易的：系统必须由几个开发人员同时进行协作开发，整个系统任务自然就被分解为几个处理阶段，而且需求很容易变动。因此你就要通过替换或重新排序处理步骤来为将来的灵活性作规划。通过加入这样的灵活性，采用现有处理组件构建是可以办到的。系统的设计尤其是处理步骤的内部连接，必须考虑以下因素：未来系统的升级通过替换某些处理步骤，或重组步骤。不同的语境中小的处理步骤要比大的组件更易于重用。不相连的处理步骤不可共享信息。存在不同的输入数据源，可以用多种方式输出或存放最终结果。94解决方案与结构管道和过滤器体系架构模式把系统任务分成为几个独立的处理步骤。这些步骤采用通过系统的数据流连接。一个步骤的输出是下一个步骤的输入。每个处理步骤由一个过滤器组件实现，它处理或者转化数据，并且系统的输入可以是多种数据源。这种体系架构模式具有许多特性：过滤器是独立运行的部件。也就是除了输入和输出外，每个过滤器不受任何其他过滤器运行的影响。在设计上，过滤器之间不共享任何状态信息。独立性还表现在它对其处理的上游和下游连接的过滤器是"无知"的.它的设计和使用不对与其连接的任何过滤器施加限制，唯一关心的是其输入数据的，然后进行加工处理，最后产生数据输出。95优点与缺点优点：结构简单：系统的行为是所有过滤器行为的简单复合。系统易于维护和增强：增加新过滤器，替换旧过滤器。支持复用：过滤器只同其输入、输出端口的数据相关。各过滤器可以并发运行。缺点：容易导致批处理方式：每个过滤器从输入数据到输出数据的转换是一个整体。转换通常不适合交互式的应用。有时必须维护两个分离而又相关的流之间的对应关系。同实现有关，过滤器之间的数据传输率较低，而且每个过滤器都要作类似的数据打包和解包的工作。96黑板(Blackboard)又称看板模式：在这种架构中，有两种不同的构件：一种是表示当前状态中心数据结构；另一种是一种相互独立的构件，这些构件对中心数据进行操作。这种架构主要用于数据库和人工智能系统的开发。模式识别、数据挖掘。97经纪人(Broker)客户和服务器通过一个经纪人部件进行通信，经纪人负责协调客户和服务器之间的操作，并且为客户和服务器发送请求和结果信息。98客户/服务器（Client/Server）系统分为客户和服务器，服务器一直处于侦听的状态，客户主动连接服务器，每个服务器可以为多个客户服务。99优缺点优点：结构简单，系统中不同类型的任务分别由客户和服务器承担，有利于发挥不同机器平台的优势；支持分布式、并发环境，特别是当客户和服务器之间的关系是多对多时，可以有效地提高资源的利用率和共享程度；服务器集中管理资源，有利于权限控制和系统安全。缺点：在大多数client-server风格的系统中，构件之间的连接通过（远程）过程调用，接近于代码一级，表达能力较弱。100点对点（PeertoPeer）系统中的节点都处于平等的地位，每个节点都可以连接其他节点。在这种架构中，一般需要由一个中心服务器完成发现和管理节点的操作。ICQ以及WebService技术的大多数应用，都是典型的点对点结构。101模型-视图-控制器（MVC）当应用程序的用户界面非常复杂，且关于用户界面的需求很容易变化时，我们可以把交互类型的软件抽象成模型、视图和控制器这三类组件单元，这种抽象可以很好地分离用户界面和业务逻辑，适应变化的需求。大多数现代交互软件都在一定程度上符合这一架构模型的特点。MVC模式最吸引人之处在于它迫使用户必须抽象自己的代码，把项目分为表示、逻辑和控制三部分,每部分间的关联较小。以MVC模式构造软件,可以使得软件结构灵活、重用性好、扩展性佳。102模型—视图—控制器交互的示意图103模型：视图：控制器:模型：模型表示应用的数据及操作这些数据的逻辑方法。任何和整个应用有关的持久性数据都应该放在模型中。对于模型,它所提供的API不能只针对某一个专门的视图或控制器,应该更一般化以适应不同客户的需求。视图：视图将模型的当前状态展示给用户,具体的显示方法由视图负责,因此一个模型可以适用多个不同的视图。在模型状态改变后,通过模型和视图之间的协议,视图得知这种改变并修改自己的显示。对于用户的输入,视图将它们交给控制器处理。控制器:控制器负责交互和将用户输入的数据导入模型,它还利用用户的输入将应用转向其他视图。一些非持久的临时数据也应该在视图中存取。104采用MVC的好处显示、逻辑和数据分开,这样一方面的改变不会影响另一方面。更新视图：如原来用的是CLI(CommandLineInterface)的,后来要改成GUI,只要了解原来的模型和控制器的接口,然后构造GUI,把它按过去的协议和模型关联起来就可以了,这样做增加了组件的重用性和灵活性。复用视图：假设针对某个模型数据开发了一套View,那么在其他访问该模型数据的地方,完全可以再次使用该套件或将现在的View组合成一个复合视图。每个单视图有自己和模型的连接协议和自己的响应控制器,这样开发就仅仅变成了简单的组合。更新控制器：以在不更改视图显示的情况下,更改控制器,以达到更改视图与用户交互的响应模式的目的。105显示-抽象-控制（PAC）是MVC的一种变形。106Event-based风格优点：支持复用，构件通过登记它所感兴趣的事件被引入系统；便于系统演化，构件可以容易地升级或更换。缺点：系统行为难以控制，发出事件的构件放弃了对系统的控制，因此不能确定系统中有无或有多少其它构件对该事件感兴趣，系统的行为不能依赖于特定的处理顺序。同事件关联的会有少量的数据，但有些情况下需要通过共享区传递数据，这时就涉及到全局效率和资源管理问题。107SOA的架构的特点服务（Service）定义良好的，自包含的，不依赖于上下文和其它服务的一组功能SOA（Service-OrientedArchitecture）本质上是一组服务的集合服务之间相互沟通可以是简单的数据传输，或者是由两个或多个服务共同参与的一些活动，SOA也包括Service之间的连通技术。108OOvs.SOA–OO的扩展遇到了挑战随着时间的推移，接口继承的复杂度在累积随着系统间距离的延伸，调用成本在上升，类型系统的不同步扩展组件的功能成本高，不可确定未来需求，不可堆叠的扩展方式重用与标准化，重用是OO的第一原则，难以维持和维护复杂的重用标准和机制109–OOvs.SOAOO仍然适用于服务的开发