《基于体系结构的软件开发课件》由会员分享，可在线阅读，更多相关《基于体系结构的软件开发课件（107页珍藏版）》请在金锄头文库上搜索。
1、1,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, 好的解决方案、设计经验，可以一次又一次的使用。 设计模式是面向对象的软件设计的经验总结，是被系统地命名、解释和评价的一个重要的可重现的面向对象的设计方案。 利用设计模式可以方便地重用成功的设计和结构。,2,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述,类比：建筑设计方案,3,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, 模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。 一个软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题
2、，并为它的解决方案提供了一个经过充分验证的通用图示。 解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。,4,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC的背景,软件系统的重要功能之一是从数据存储检索数据，并将其显示给用户。在用户更改数据之后，系统再将更新内容存储到数据存储中。如果将数据存储和界面显示代码放在一起，则可以减少编码量并提高应用程序性能。 但这样做也存在很多问题。,5,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC（model view controller）的背景,用户界面逻辑的更改往往比业务逻
3、辑频繁，尤其是在基于 Web 的应用程序中。基于 Web 的瘦客户端应用程序的优点之一是可以随时更改用户界面，而不必重新分发应用程序。如果将显示代码和业务逻辑组合在一起并放在单个对象中，则每次更改用户界面时，都必须修改包含业务逻辑的对象。,6,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC的背景,在很多情况下，应用程序需要以不同的方式显示同一数据。例如，表格显示，趋势图显示，柱状图显示，饼图显示。 界面开发与业务逻辑开发所需要的技能不同，在这两方面都精通比较困难。 与业务逻辑相比，用户界面代码对设备的依赖性往往更大。例如，要将应用程序从基于浏览器的应用程序迁移到个人
4、数字助理 (PDA) 或支持 Web 的手机上，则必须替换很多用户界面代码，而业务逻辑可能不受影响。,7,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC的背景,如何让 Web 应用程序的用户界面和功能实现模块化，以便可以轻松地单独修改各个部分？,？,8,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC解决方案,MVC模式将建模、显示和操作分为三个独立的类： 模型。模型用于管理应用程序域的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）。 视图。视图用于管理信息的显示。 控制器。控制器用
5、于解释用户的鼠标和键盘输入，以通知模型和/或视图进行相应的更改。,9,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC解决方案,10,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC的处理过程,控制器接收用户的请求，并决定应该调用哪个模型来进行处理； 模型用业务逻辑来处理用户的请求并返回数据； 控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。,11,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, 被动的MVC模型,当控制器以独占方式操作模型时，则为被动模型。控制器将修改模型，然后通知视图：模型已经更改，应该
6、进行刷新。 此情况下的模型完全独立于视图和控制器，这意味着模型无法报告其状态更改。例如，HTTP 协议，浏览器没有从服务器获取异步更新的简单方法。浏览器显示视图并对用户输入作出响应，但是它不会检测服务器上的数据更改。仅当用户显式请求刷新时，才会询问服务器是否发生了更改。,12,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, 主动的MVC模型,当模型更改状态而不涉及控制器时，则为主动模型。当其他资源正在更改数据并且更改必须反映在视图中时，可能会发生这种情况。 例如，股票报价机的显示。当从外部源接收股票数据，并希望当股票数据更改时更新视图。因为在这些更改发生时，只有模型检测对其
7、内部状态的更改，所以模型必须通知视图刷新显示。 使用 MVC 模式的一个目的是使模型独立于视图。如果模型必须将更改通知视图，则会重新带来不希望的依赖性。,13,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, 使用观察者的MVC主动模型,各个视图实现 Observer 接口，并向模型注册。模型将跟踪由所有观察器组成的列表。当模型发生改变时，模型将会遍历所有已注册的观察器，并将更改通知它们。此方法通常称为“发布-订阅“。,14,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC模式的优点,支持多个视图。因为视图与模型分离，而且模型与视图之间没有直接依赖性
8、，所以用户界面可以同时显示同一数据的多个视图。 适应更改。用户界面要求的更改往往比业务规则快。用户可能更喜欢新设备（如手机或 PDA）采用另一颜色、字体、屏幕布局和支持级别。因为模型不依赖于视图，所以将新类型的视图添加到系统中通常不会影响模型。因此，更改的作用范围仅限于视图。,15,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式概述, MVC模式的缺点,复杂性。MVC 模式引入了新的间接级别，因此稍微增加了解决方案的复杂性。还增加了用户界面代码的事件驱动特性，调试用户界面代码会变得更加困难。 频繁更新的成本。将模型与视图分离并不意味着模型的开发人员可以忽略视图的特性。例如，如果模
9、型发生频繁更改，则它可能向视图发出大量更新请求。一些视图（如图形显示）的显示可能需要一定时间。因此，模型可以将多个更新作为单个通知发送到视图。,16,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式的基本成分, 模式名称：通常用来描述一个设计问题、它的解法和后果，由一到两个词组成。 问题：告诉我们什么时候要使用设计模式、解释问题及其背景。 解决方案：描述设计的基本要素，它们的关系、各自的任务以及相互之间的合作。 后果：描述应用设计模式后的结果和权衡。比较与其他设计方法的异同，得到应用设计模式的代价和优点。,17,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式的描述（1
10、）, 如果要理解和讨论模式，就必须以适当形式描述模式。 好的描述有助于我们立即抓住模式的本质，即模式关心的问题是什么，以及提出的解决方案是什么？,18,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式的描述（1）,（1）模式名称和分类：模式名称和一个简短的摘要。 （2）目的：即设计模式的用处、基本原理和目的、它针对的是什么特殊的设计问题。 （3）别名：同一个模式可能会有不同的命名。 （4）动机：描述一个设计问题的方案，以及模式中类和对象的结构如何解决这个问题。,Erich Gamma博士等人采用下面的固定模式来描述：,19,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模
11、式的描述（2）,（5）应用：在什么情况下可以应用本设计模式。 （6）结构：用对象模型技术对本模式进行表示。 （7）成分：组成本设计模式的类和对象及它们的职责。 （8）合作：成分间如何合作实现他们的任务。 （9）后果：该模式如何支持它的对象；如何在使用本模式时进行权衡。,20,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式的描述（2）,（10）实现：在实现本模式的过程中，要注意哪些缺陷、线索或者技术；是否与编程语言有关。 （11）例程代码：说明如何用C+或其他语言来实现该模块的代码段。 （12）已知的应用：现实系统中使用该模式的实例。 （13）相关模式：与本模式相关的其他模式，它们
12、之间的区别，以及本模式是否要和其他模式共同使用。,21,第七章 基于体系结构的软件开发,7.1 设计模式, 模式和软件体系结构, 模式作为体系结构构造块 对软件体系结构而言，模式的一个重要目标就是用已定义属性进行特定的软件体系结构的构造。,模式,22,第七章 基于体系结构的软件开发,7.1 设计模式, 模式和软件体系结构, 构造异构体系结构 单个模式不能完成一个完整的软件体系结构的详细构造，它仅仅帮助设计师设计应用程序的某一方面。 为了有效使用模式，需要将它们组织成模式系统。模式系统统一描述模式，对它们分类，更重要的是，说明它们之间如何交互。,模式1,模式2,23,第七章 基于体系结构的软件开
13、发,7.1 设计模式, 模式和软件体系结构, 模式和方法 好的模式描述也包含它的实现指南，可将其看成是一种微方法，用来创建解决一个问题的方案。 通过提供方法的步骤来解决软件开发中的具体再现问题，这些微方法补充了通用的但与问题无关的分析和设计方法。,24,第七章 基于体系结构的软件开发,7.1 设计模式, 模式和软件体系结构, 实现模式 目前的许多软件模式具有独特的面向对象风格。因此，人们往往认为，能够有效实现模式的唯一方式是使用面向对象编程语言，其实不然。 在设计层次，大多数模式只需要适当的编程语言的抽象机制，如模块或数据抽象。因此，可以用几乎所有的编程范例，并在所有的编程语言中来实现模式。,
14、25,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式方法分类, Coad的面向对象模式 代码模式 框架应用模式 形式合约,26,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式方法分类,1、Coad的面向对象模式 1992年，美国面向对象技术大师Peter Coad从MVC的角度对面向对象系统进行了讨论，设计模式由最底层的构成部分（类和对象）及其关系来区分。他使用了一种通用的方式来描述一种设计模式： （1） 模式所能解决问题的简要介绍与讨论； （2） 模式的非形式文本描述以及图形表示； （3） 模式的使用方针：在何时使用以及能够与哪些模式结合使用。,27,第七章 基于
15、体系结构的软件开发,7.1 设计模式, 设计模式方法分类,1、Coad的面向对象模式 将Coad的模式划分为以下三类： （1）基本的继承和交互模式：主要包括OOPL所提供的基本建模功能，继承模式声明了一个类能够在其子类中被修改或被补充，交互模式描述了在有多个类的情况下消息的传递。 （2）面向对象软件系统的结构化模式：描述了在适当情况下，一组类如何支持面向对象软件系统结构的建模。 （3）与MVC框架相关的模式。,28,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式方法分类,2、代码模式 代码模式的抽象方式与OOPL中的代码规范很相似，该类模式有助于解决某种面向对象程序设计语言中的特
16、定问题。 主要目标在于： （1） 指明结合基本语言概念的可用方式； （2） 构成源码结构与命名规范的基础； （3） 避免面向对象程序设计语言（尤其是C+语言）的缺陷。,29,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式方法分类,2、代码模式 代码模式与具体的程序设计语言或者类库有关，它们主要从语法的角度对软件系统的结构方面提供一些基本的规范。 这些模式对于类的设计不适用，同时也不支持程序员开发和应用框架，命名规范是类库中的名字标准化的基本方法，以免在使用类库时产生混淆。,30,第七章 基于体系结构的软件开发,7.1 设计模式, 设计模式方法分类,3、框架应用模式（“菜谱”） 框架是从特定域中提取出来的一组组件及其相互关系的可重用的体系结构。它定义了整体结构、类和对象的分割，各部分的主要责任，类和对象如何协作，以及控制流程。 框架记录了其应用领域共同的设
