软件体系结构整理
软件体系结构_529特别整理版
软件体系结构_529特别整理版1、软件体系结构(SA)：–提供了一个结构、行为和属性的高级抽象–从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构–这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。
–反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据此开发的系统能完成系统既定的功能和性能需求。
2、软件体系结构的目标：–外向目标：建立满足最终用户要求的系统需求；–内向目标：建立满足系统设计者需要以及易于系统实现、维护和扩展的系统构件构成。
3、软件体系结构的几个观点：（1）全局观(global viewpoint)–在软件开发过程中，应有一种从全局的角度对软件进行设计的“视图”，而非仅仅关注底层的算法细节；（2）折中观(tradeoff viewpoint)–用户提出的各类功能与非功能需求之间存在着大量的“矛盾”，无法同时“完美”的满足，必须要在彼此之间做出权衡；（3）交流观(communication viewpoint)–参与软件研发的各成员需要有一个公共的“媒介”进行沟通，以应对需求的不明确、频繁变更、复杂度增加；（4）复用观(reuse viewpoint)–不同的软件系统之间是否存在整体风格上的相似性，通过利用已存在的“软件资产”，提高效率、降低成本；4、（名词）(Kruchten)4+1视图模型：逻辑视图：描述系统的抽象概念与功能(类、对象、接口、模式等)，主要图形包括class diagrams, sequence diagrams, and collaboration diagrams等；开发视图：描述系统中的子系统、模块、文件、资源及其之间的关系，主要图形包括component diagrams等；进程视图：描述系统的进程及其之间的通信协作关系，主要图形包括activity diagram, interaction diagram等；物理视图：描述系统如何被安装、部署与配置在分布式的物理环境下，主要图形包括deployment diagram等。
软件体系结构总结
1、软件危机：软件开发维护过程中的遇到一系列严重问题表现：软件成本日益增长，开发进度难以控制，软件质量差，软件维护困难，原因；用户需求不明确，缺乏正确的理论指导，软件规模越来越大，软件复杂度越来越高，软件工程是用工程科学和数学的原则和方法研制，维护计算机软件的有关技术及管理方法软件工程三要素，方法，工具，过程解决方法：管理，采用工程化的开发方法，加大软件重用，采用先进的开放工具2、软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
特点：从高层抽象了软件系统结构、行为、属性。
软件体系结构的意义：体系结构是风险担保者进行交流的手段是早期设计决策的体现是可传递和可重用的模型3、构件是语义完整，语法正确和有可重用价值的单位软件是软件重用过程中可以明确辨识的系统，构件模型是对构件本质特征的抽象描述分类：参考模型，描述模型，实现模型构件分类方法：关键字分类法，刻面分类法，超文本分类法4、软件体系结构模型：结构模型，动态模型，框架模型，过程模型，功能模型5、4+1 视图模型从五个不同的视角包括逻辑视图，开发视图，进程视图，物理视图和场景逻辑视图：主要支持系统功能需求：即系统提供给最终用户的服务开发视图：主要侧重于软件模块的组织和管理进程视图：系统的运行特征，主要关注与一些非功能性的需求物理视图：主要考虑如何把软件映射到硬件上，他通常考虑系统性能，规模，可靠性，解决系统拓扑结构，系统安装，通讯等问题场景：可以看作是那些重要系统活动的抽象，它使四个视图有机联系在一起，6、软件体系结构的核心模型：构件，连接件，配置，端口，和角色7、软件体系风格：是描述某一特定应用领域中系统组织方式的惯用模式最关键的四要素内容：一个词汇表，定义一套配置规则，定义一套语义解释原则定义对基于这种风格的系统所进行的分析经典体系结构风格：数据流风格，调用/返回风格，独立构件风格，虚拟机风格，仓库风格几种软件风格8，为什么使用异构风格不同的结构有不同的处理能力的强项和弱项关于软件包，框架，通信以及其他一些体系结构上的问题一些遗留下来的代码9，体系结构描述方法：图形表达工具有矩形和有向线段组合而成的图形表达工具模块连接语言：采用一种或几种传统程序设计语言的模块连接起来的内连接语言MIL基于软构件的系统描述语言软件体系结构描述语言：ADL 在底层语义模块的支持下，为软件系统的概念体系结构提供了具体的语法和概念框架，基于底层语义的工具为体系结构表示分析演化分化设计构成提供支持三个基本元素构件连接件体系结构配置优点缺点UML ：统一建模语言是一个通用的可视化建模语言，用于对软件精星描述，可视化处理，构造，和建立软件体系的文档，A、状态图B、用例图C、时序图D、配置图E、协作图F、类图。
软件体系结构知识点复习
一、什么是软件系统结构软件体系结构也称为软件构架（有时简称构架），是系统的一个或多个结构，它包括：软件的组成元素（组件），这些元素（组件）的外部可见特性，以及这些元素（组件）之间的相互关系。
含义：(1)系统由一个或多个结构组成，其中任何一个结构并不能与构架等同。
(2)每个系统都有一个体系结构。
(3)软件体系结构是系统的抽象。
(4) 构架定义了软件元素以及各元素间的交互关系。
(5) 以往作为体系结构传递的线框图，事实上并等同于体系结构。
二、构架商业周期(ABC)1.构架由什么决定？构架是否由系统需求决定？×软件构架是技术、商业和社会因素共同作用的结果。
2. 构架从哪里来？(影响构架的因素)影响构架的因素主要包括：❑系统涉众（stakeholder）、主要有：管理者：成本要低，人人都得干活营销人员：特性突出、投放市场快、成本低、可与同类产品相匹敌｡终端用户：行为、性能、安全性、可靠性、易用性｡维护人员：可修改性强｡客户：成本低、及时交付、不要频繁修改｡❑开发组织・组织内对现存构架的重用・对某个基础设施进行长期的商业投资以实现某些战略目标・开发组织本身的机构也会影响构架的形成❑构架师的素质和经验构架师先前的一些经验、教育、培训以及所接触到过的成功构架模式都会影响到他们对某种构架的选择。
❑技术环境当前技术发展水平代表了某个时代的构架师的普遍素质和经验，对架构有很大的影响力。
❑其它因素其它如社会、法律、人文环境等都会对构架产生影响。
3.构架的反影响力・构架会影响开发组织的结构・构架会影响开发组织的目标・构架会影响客户对下一个系统的要求・构建系统的过程丰富了整个开发团队的经验，从而将影响设计师对后继系统的设计・一些系统会影响并实际改变软件工程的环境，也就是系统开发人员学习或实践的技术环境。
4.构架的商业周期软件构架是技术、商业和社会等诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响未来的软件构架。
软件体系结构知识点总结
软件体系结构知识点总结软件体系结构公式体系架构=组件+连接件+约束SoftwareArchitecture=Components+Connectors+Constrains风格决定因素组件类型（例如：数据容器，过程，对象）连接件类型/交互机制（例如：过程调⽤，事件，管道）组件的拓扑分布拓扑和⾏为的约束（例如：数据容器不能⾃⼰改变数据，管道不能是循环的）风格的代价和益处（优缺点）异质的风格 Heterogeneous style）：⼀个系统是由不⽌⼀种风格构建的⼏种软件体系结构风格数据流 Data Flow:实例：流⽔改卷两种⽅法：⽅式1：⼀位⽼师改完1份卷⼦，就传给下⼀位⽼师⽅式2：⼀位⽼师改完整班卷⼦，再传给下⼀位⽼师特点由数据控制计算系统结构由数据在处理之间的有序移动决定数据流系统的结构是⽐较明显的在纯数据流系统中，处理之间除了数据交换，没有任何其他的交互风格组件：数据处理的步骤组件的接⼝是输⼊端⼝还是输出端⼝计算模型：从输⼊中读取数据，计算，然后写到出⼝连接件：数据单向，通常是异步有缓冲的系统：任意的拓扑结构不同组件完成不同的功能模式：我们主要研究近似线性数据流或者是在限度内的循环数据流如果⼀个软件系统的数据流的流向⽆序很可能说明该系统不应采⽤数据流的体系结构例⼦：批处理每个处理步骤是⼀个独⽴的程序每⼀步必须在前⼀步结束后才能开始（有次序）数据必须是完整的，以整体的⽅式传递批处理可以做，管道过滤器做不了：对数据的整体访问，因为管道过滤器的数据分布在不同的组件上管道过滤器特性：每个组件都有⼀组输⼊和输出，组件读取输⼊的数据流，经过内部处理，产⽣输出数据流。
这个过程通常通过对输⼊流的变换及增量计算来完成。
这⾥的组件称为过滤器，连接件像是对输⼊流传输的管道，将⼀个过滤器的输出传到另⼀个过滤器的输⼊。
管道过滤器的通⽤结构：管道：限制了系统的拓扑结构，只能是过滤器的线性序列有界管道：限制了在管道中能够容纳的数据量类型定义管道：要求定义在两个过滤器间传出的数据类型过滤器的⾓⾊：读取数据流，输出处理后的数据流执⾏流式的转换递增地转换数据，数据边到来边处理，不是先收集好，再处理不同过滤器之间是独⽴的管道的⾓⾊移动数据，从⼀个过滤器的输出到另⼀个过滤器的输⼊全部的操作数据传送引起系统动作当没有数据可⽤，没有更多的计算的时候，管道过滤器系统停⽌⼯作读取与处理数据流的⽅式递增地读取和消费数据流在输⼊被完全处理之前，输出便产⽣了优点使软件具有良好的隐蔽性和⾼内聚，低耦合的特点（过滤器可以看做是⿊盒）可将整个系统的I/O特性，理解为各个过滤器功能的简单合成。
软件体系结构整理
1.软件体系结构建模的种类◎结构模型◎框架模型◎动态模型◎过程模型◎功能模型2.4+1模型4+1视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
逻辑视图：逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。
要保持单一内聚的对象模型开发视图开发视图也称模块视图，主要侧重于软件模块的组织和管理。
开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入输出关系的模型图和子系统图来描述。
在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。
设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。
开发视图所用的风格通常是层次结构风格。
进程视图进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。
它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。
它可看成一系列独立的，通过逻辑网络相互通信的程序。
它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。
软件体系结构知识点完整
软件体系结构知识点完整首先，软件体系结构的设计目标是确保软件系统具有良好的可维护性、可扩展性、可重用性和可演化性。
为了达到这些目标，需要考虑以下几个重要的知识点：1.架构风格和模式：软件体系结构可以采用不同的架构风格和模式，如客户/服务器架构、分层架构、微服务架构等。
每种架构风格和模式都有其适用的场景和优缺点，开发人员需要根据具体需求选择适合的架构。
2.组件和接口：软件系统通常由多个组件构成，每个组件负责特定的功能。
组件之间通过接口进行通信和交互。
设计良好的组件和接口可以提高系统的模块化程度，便于测试、维护和重用。
3.数据管理：软件系统通常需要对一定量的数据进行管理和存储。
在软件体系结构设计中，需要考虑数据的组织方式、访问方式和持久化方式。
常见的数据管理技术包括关系型数据库、非关系型数据库和缓存等。
4.并发和分布式处理：现代软件系统通常需要处理大量的并发请求，并且可能分布在不同的机器上。
软件体系结构设计需要考虑如何有效地处理并发请求和如何进行分布式部署，以提高系统的性能和可扩展性。
5.安全和可靠性：软件系统面临各种安全和可靠性风险，如数据丢失、数据泄露和系统故障等。
软件体系结构设计需要考虑如何采取措施保障系统的安全和可靠性，如进行数据备份、访问控制和错误处理等。
6.软件系统的分层：软件体系结构通常采用分层的结构，将系统划分为不同的层次，每个层次负责不同的功能。
常见的分层结构有表示层、业务逻辑层和数据访问层等。
分层结构可以提高系统的可维护性和可扩展性。
7.影响因素和约束：软件体系结构设计还需要考虑相关的影响因素和约束，如成本、时间、技术限制等。
这些因素和约束将直接影响软件体系结构的设计和实施。
总结起来，软件体系结构是软件设计的重要组成部分，它涉及到架构风格和模式的选择、组件和接口的设计、数据管理、并发和分布式处理、安全和可靠性等多个方面。
了解这些知识点对于设计出高质量、可维护和可扩展的软件系统至关重要。
软件体系结构总结
软件体系结构总结引言软件体系结构是指对软件系统概要设计的抽象表示，它定义了系统的结构组成、各个组件之间的关系以及与外部环境的交互方式。
在软件开发过程中，合理的软件体系结构设计能够提高系统的可维护性、扩展性和复用性。
本文将从软件体系结构的概念、常见的体系结构风格以及体系结构设计原则进行总结。
软件体系结构概念软件体系结构是对软件系统进行高层次抽象的表示，能够描述系统的组成部分以及这些部分之间的关系。
它提供了一个框架，用于指导软件系统的开发和演化。
软件体系结构通常包括以下几个方面的描述：1.结构元素：指系统中的组件、连接器和配置。
组件是系统中的可替换部分，连接器是组件之间进行通信和协作的媒介，配置是组件和连接器的物理安排。
2.组件关系：描述组件之间的静态关系，比如依赖关系、聚合关系、继承关系等。
3.交互方式：描述组件和连接器之间的动态交互方式，包括数据流、控制流和事件触发等。
4.分析视图：描述软件体系结构的静态特性，通过分析视图可以发现系统中的潜在问题和风险。
5.设计视图：描述软件体系结构的具体设计方案，包括组件和连接器的具体实现细节。
常见的体系结构风格在软件体系结构设计中，常见的体系结构风格包括以下几种：1.面向对象体系结构：基于面向对象编程思想，将系统分解为一系列的对象，每个对象封装了数据和操作，通过消息传递进行通信和协作。
2.分层体系结构：将系统分为多个层次，每个层次都有特定的功能和责任，上层层次使用下层层次提供的服务。
3.客户端-服务器体系结构：将系统分为客户端和服务器，客户端发送请求，服务器进行处理并返回结果。
4.数据流体系结构：以数据流为中心，将系统划分为一系列的数据流和处理器，数据流通过处理器进行转换和处理。
5.发布-订阅体系结构：基于事件驱动的编程模式，组件之间通过发布者-订阅者模型进行通信。
不同的体系结构风格适用于不同的应用场景，根据系统的需求和特点选择合适的体系结构风格是非常重要的。
软件体系结构复习资料
软件体系结构复习资料软件体系结构复习资料软件体系结构是指软件系统中各个组成部分之间的关系和交互方式。
它是软件系统设计的基础，决定了软件系统的可靠性、可维护性和可扩展性。
在软件体系结构的学习中，我们需要了解不同的体系结构模式、设计原则和关键概念。
本文将从这些方面进行复习，帮助读者更好地理解软件体系结构。
一、体系结构模式1. 分层结构模式分层结构模式是一种常见的软件体系结构模式，它将软件系统划分为多个层次，每个层次负责不同的功能。
这种模式有助于实现模块化、可维护性和可复用性。
例如，一个三层架构的Web应用程序可以分为表示层、业务逻辑层和数据访问层，每个层次都有不同的责任和职责。
2. 客户端-服务器模式客户端-服务器模式是一种常见的分布式体系结构模式，它将软件系统划分为客户端和服务器两个部分。
客户端负责用户界面和用户交互，而服务器负责处理业务逻辑和数据存储。
这种模式有助于实现系统的可伸缩性和可扩展性。
3. 主从模式主从模式是一种常见的并行计算体系结构模式，它将软件系统划分为一个主节点和多个从节点。
主节点负责协调和控制整个系统的运行，而从节点负责执行具体的任务。
这种模式有助于提高系统的处理能力和性能。
二、设计原则1. 单一职责原则单一职责原则要求一个类或模块只负责一项功能。
这样可以提高代码的可读性、可维护性和可测试性。
例如，在一个MVC架构中，控制器只负责处理用户请求，模型只负责数据存储和处理，视图只负责展示数据。
2. 开放封闭原则开放封闭原则要求软件系统应该对扩展开放，对修改封闭。
这意味着当需求变化时，我们应该通过扩展现有的代码来满足新的需求，而不是修改已有的代码。
这样可以提高系统的稳定性和可维护性。
3. 依赖倒置原则依赖倒置原则要求高层模块不应该依赖于低层模块，而是应该依赖于抽象。
这样可以降低模块之间的耦合度，提高系统的灵活性和可扩展性。
例如，使用接口来定义模块之间的依赖关系，而不是直接依赖于具体的实现类。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.软件体系结构建模的种类◎结构模型◎框架模型◎动态模型◎过程模型◎功能模型2.4+1模型4+1视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
逻辑视图：逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。
要保持单一内聚的对象模型开发视图开发视图也称模块视图，主要侧重于软件模块的组织和管理。
开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。
开发视图通过系统输入输出关系的模型图和子系统图来描述。
在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。
设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。
开发视图所用的风格通常是层次结构风格。
进程视图进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。
它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。
它可看成一系列独立的，通过逻辑网络相互通信的程序。
它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。
物理视图物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。
解决系统拓扑结构、系统安装、通讯等问题。
当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。
因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
场景场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。
在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。
同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。
场景可以用文本表示，也可以用图形表示。
4+1模型–小结逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
对于不同的软件系统来说，侧重的角度也有所不同。
例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
1.经典的软件体系结构风格：✧数据流风格：批处理序列；管道/过滤器。
✧调用/返回风格：主程序/子程序；面向对象风格；层次结构。
✧独立构件风格：进程通讯；事件系统。
✧虚拟机风格：解释器；基于规则的系统。
✧仓库风格：数据库系统；超文本系统；黑板系统2.管道与过滤器：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。
这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。
1.从软件危机谈起–软件危机软件危机：在计算机软件开发和维护工程中遇到的一系列严重问题。
软件危机表现：1.软件成本日益增长2.开发进度难以控制3.软件质量差4.软件维护困难软件危机原因：1.用户需求不明确2.缺乏正确的理论指导3.软件规模越来越大4.软件复杂度越来越高2.构件与软件重用构件：指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通讯接口和实现代码的复合体。
（面向对象技术达到类级重用，重用级别小，构件将重用级别提升）软件重用：在2次或多次不同的软件开发过程中使用相同或相近软构件的工程。
（代码，测试用例，设计文档，设计过程，需求文档，领域知识等）3.软件体系结构的定义软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
任务分配：服务器：客户应用程序：3.C/S风格：C/S软件体系结构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。
C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
C/S风格–优点：1.C/S 体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
2.系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
3.在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。
将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
C/S风格–缺点：1.开发成本较高2.客户端程序设计复杂3.信息内容和形式单一4.用户界面风格不一，使用繁杂，不利于推广使用5.软件移植困难6.软件维护和升级困难7.新技术不能轻易应用三层B/S风格4.浏览器/服务器（B/S）风格就是三层应用结构的一种实现方式，其具体结构为：浏览器/Web服务器/数据库服务器。
B/S体系结构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。
从某种程度上来说，B/S结构是一种全新的软件体系结构。
B/S优点：1.基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。
用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
2.B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。
B/S缺点：1.B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
2.B/S体系结构的系统扩展能力差，安全性难以控制。
3.采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。
4.B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理UML结构：1.用例图：静态视图、用于需求分析2.交互图：◆顺序图：表示前后顺序◆通信图：消息流经的数据结构3.状态图：状态转移关系4.构件图：构件之间的相互关系5.部署图：构件的拓扑结构1.什么是设计模式：设计模式（pattern）是从许多优秀的软件系统中总结出的成功的可复用的设计方案。
每一个设计模式描述一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。
这样，你就能一次一次地使用该方案而不必做重复劳动。
记录一个设计模式需有四个基本要素：名称、问题、方案、效果模式分类：1．行为型模式行为模式涉及怎样合理地设计对象之间的交互通信,以及怎样合理为对象分配职责,让设计富有弹性,易维护,易复用。
下列模式属于行为型模式.◆策略模式。
◆状态模式。
◆命令模式。
◆中介者模式。
◆责任链模式。
◆模板方法模式。
◆观察者模式。
◆访问者模式。
2．结构型模式结构型模式涉及如何组合类和对象以形成更大的结构，和类有关的结构型模式涉及如何合理地使用继承机制，和对象有关的结构型模式涉及如何合理地使用对象组合机制。
下列模式属于行结构型模式.◆装饰模式。
◆组合模式。
◆适配器模式。
◆外观模式。
◆代理模式。
◆享元模式。
◆桥接模式。
3．创建型模式创建型模式涉及对象的实例化，这类模式的特点是，不让用户代码依赖于对象的创建或排列方式，避免用户直接使用new运算符创建对象。
下列模式属于创建型模式◆工厂方法模式。
◆抽象工厂模式◆生成器模式。
◆原型模式。
◆单件模式。
2.策略模式：策略模式(别名: 政策)定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。
本模式使得算法可独立于使用它的客户而变化。
策略模式属于行为型模式，结构中包含以下三种角色：◆策略：策略是一个接口，该接口定义若干个算法标识，即定义了若干个抽象方法（如图7.1中的algorithm()方法）。
◆上下文：上下文是依赖于策略接口的类即上下文包含有用策略声明的变量（上下文中提供一个方法该方法委托策略变量调用具体策略所实现的策略接口中的方法。
◆具体策略具体策略是实现策略接口的类具体策略实现策略接口所定义的抽象方法，即给出算法标识的具体算法。