下载文档原格式
二十三种设计模式0 引言谈到设计模式，绝对应该一起来说说重构。
重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题，当然这其中也包括了应用模式的问题。
尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。
换句话说，这时就能写代码了。
这就得益于重构的思想了。
如果没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。
在重构和设计模式的合理应用之下，我们可以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码质量。
所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的理解。
重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提前考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。
1 创建型1.1FactoryMethod思想：Factory Method的主要思想是使一个类的实例化延迟到其子类。
场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者比较容易变化。
此时，如果直接将实例化过程写在某个函数中，那么一般就是if-else或select-case代码。
如果，候选项的数目较少、类型基本确定，那么这样的if-else还是可以接受的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时，这样的if-else代码就会变得比较不那么容易维护了。
此时，应用本模式，可以将这种复杂情形隔离开，即将这类不确定的对象的实例化过程延迟到子类。
uml表达逻辑模型
UML（统一建模语言）是一种可视化的面向对象建模语言，提供了丰富的图形化表示法，使得开发人员能够更加直观地理解和描述软件系统的结构和行为。
在UML中，逻辑模型主要通过以下几种方式来表达：
1. 类图（Class Diagram）：类图是UML中最基本的图之一，用于描述系统中的类、接口以及它们之间的关系。
类图可以展示类的静态结构，包括属性、方法和关系等，从而帮助开发人员理解系统的逻辑结构。
2. 对象图（Object Diagram）：对象图是类图的一个实例，它展示了在某一特定时间点上系统中对象的快照。
对象图可以帮助开发人员理解系统在运行时的状态和行为。
3. 包图（Package Diagram）：包图用于描述系统中的包以及包之间的关系。
包是一种组织类、接口和其他元素的方式，可以帮助开发人员将系统划分为更小、更易于管理的部分。
4. 组件图（Component Diagram）：组件图用于描述系统中的组件以及它们之间的关系。
组件是系统中的可替换部分，可以执行特定的功能。
组件图可以帮助开发人员理解系统的物理结构和部署方式。
除了以上几种图之外，UML还提供了其他类型的图，如
用例图、顺序图、活动图等，这些图也可以用于描述系统的逻辑模型，但侧重点可能有所不同。
例如，用例图主要用于描述系统的功能需求，而顺序图则用于描述系统中对象之间的交互行为。
总的来说，UML提供了多种图形化表示法来描述系统的逻辑模型，开发人员可以根据需要选择合适的图来描述系统的不同方面。
体系结构设计模型的表示方法体系结构设计模型的表示介绍体系结构设计模型是建立软件系统架构的关键步骤之一。
在设计过程中，如何准确地表示和展示系统的架构是十分重要的。
本文将介绍几种常用的体系结构设计模型的表示方法。
1. UMLUML（统一建模语言）是一种常用的软件工程建模语言，用于表示和描述系统的架构。
UML提供了多种图表，如用例图、类图、组件图、部署图等，能够很好地表示系统的结构和关系。
•用例图：用于描述系统功能和用户之间的交互。
•类图：用于描述系统中的类和它们之间的关系。
•组件图：用于描述系统中的模块和它们的依赖关系。
•部署图：用于描述系统的物理架构和部署方案。
2. 架构图架构图是一种更高层次的表示方法，它能够直观地展示系统的组成部分和它们之间的关系。
常见的架构图包括：•静态结构图：用于表示系统的静态组成，如层次结构图、模块图、包图等。
•动态行为图：用于表示系统的动态行为，如时序图、活动图等。
•部署图：用于描述系统的物理架构和部署方案。
3. 代码注释代码注释是一种简单而直接的体系结构表示方法。
通过在代码中添加注释，可以解释和说明代码的结构和设计思路。
代码注释可以采用各种规范和工具，如Javadoc、XML注释等。
4. 文档文档是另一种常用的体系结构表示方法。
通过编写详细的文档，可以描述系统的组成部分、接口细节、设计原理等，从而帮助人们理解和使用系统。
5. 绘图工具绘图工具是一种辅助工具，可以帮助开发人员创建和编辑各种类型的图表。
常见的绘图工具有Visio、Draw.io、Lucidchart等，它们提供了丰富的图形库和编辑功能，能够高效地创建和修改系统架构图。
总结在体系结构设计过程中，合适的表示方法能够更好地帮助开发人员理解和描述系统的架构。
本文介绍了几种常用的体系结构设计模型的表示方法，包括UML、架构图、代码注释、文档和绘图工具。
开发人员可以根据实际需求选择合适的表示方法，从而更好地设计和开发软件系统。
软件工程中的UML建模和设计模式在软件工程领域中，UML（统一建模语言）建模和设计模式是两个重要的概念。
UML建模是一种用于描述、设计和分析软件系统的标准化语言，而设计模式则是一种被广泛应用的解决软件设计问题的经验总结和最佳实践。
UML建模是软件开发过程中必不可少的一环。
它提供了一种通用的语言和符号，使得开发团队能够更好地理解和沟通软件系统的结构和行为。
UML建模包括用例图、类图、时序图等多种图形表示方式，每种图形都有其特定的用途和表达能力。
通过使用UML建模，开发团队可以更好地理解用户需求，设计合理的软件架构，并将其转化为可执行的代码。
设计模式是一种被广泛应用的解决软件设计问题的经验总结和最佳实践。
它们是在实际开发中被证明有效的解决方案，可以帮助开发人员避免重复造轮子，提高代码的可维护性和可扩展性。
设计模式包括创建型模式、结构型模式和行为型模式三大类。
创建型模式用于创建对象，结构型模式用于描述对象之间的关系，行为型模式用于描述对象之间的交互和通信方式。
常见的设计模式有单例模式、工厂模式、观察者模式等。
UML建模和设计模式在软件工程中的应用是相辅相成的。
UML建模提供了一种描述和设计软件系统的通用语言，而设计模式则提供了一种解决软件设计问题的方法。
通过使用UML建模，开发团队可以更好地理解和沟通软件系统的结构和行为，而设计模式则可以帮助开发人员遵循一种经过验证的最佳实践，提高代码的质量和可维护性。
举个例子来说，假设我们正在开发一个电子商务网站。
通过使用UML建模，我们可以绘制用例图来描述用户和系统之间的交互，类图来描述系统中的各个类和它们之间的关系，时序图来描述用户操作和系统响应的时序关系。
这些图形可以帮助开发团队更好地理解用户需求，并将其转化为可执行的代码。
在设计阶段，我们可以运用设计模式来解决一些常见的软件设计问题。
比如，我们可以使用单例模式来确保系统中只有一个购物车实例，使用工厂模式来创建不同类型的商品对象，使用观察者模式来实现用户对商品的关注和通知功能。
model设计方法模型设计是指在构建一个系统或解决一个问题时，设计和定义模型的过程。
以下是几种常用的模型设计方法：1. 基于UML（统一建模语言）：UML 是一种常用的图形化建模语言，用于描述系统的结构和行为。
通过使用UML 的类图、时序图、活动图等，可以对系统进行可视化建模和设计。
2. 数据流程图：数据流程图是一种描述系统中数据流动和处理过程的图形化表示方法。
它可以显示数据的来源、处理过程和输出，有助于识别系统中的主要组件和数据交互。
3. 状态图：状态图用于描述系统中对象或组件的状态和状态之间的转换。
它可以清晰地展示系统的行为流程和状态变化，有助于分析和设计系统的状态转换逻辑。
4. 事件驱动模型：事件驱动模型是一种基于事件和消息的模型设计方法。
它将系统的功能划分为多个独立的事件和事件处理程序，通过事件的触发和处理来实现系统的功能。
5. 面向对象模型：面向对象模型是一种基于对象和类的模型设计方法。
它将系统的功能划分为多个对象，每个对象具有属性和方法，通过对象之间的交互来实现系统的功能。
6. 数据库模型：数据库模型是用于设计和描述数据库结构的方法。
常见的数据库模型包括层次模型、网络模型、关系模型和对象模型等，它们定义了数据的组织方式、关系和约束。
7. 业务流程建模：业务流程建模是将业务流程可视化的方法，通常使用流程图来描述业务活动、任务和决策的顺序和关系。
它有助于理解和分析业务流程，从而进行系统设计和改进。
以上是一些常见的模型设计方法，每种方法都有其适用的场景和优势。
在实际应用中，可以根据具体的问题和需求选择合适的模型设计方法，以实现系统的高效和可靠性。
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
常见的设计模式及应用场景设计模式是软件开发中常用的一种代码组织和重用的技术。
它提供了一种解决问题的方案，能够帮助开发人员有效地解决常见的设计问题，并提供可维护、可扩展和可重用的软件。
下面是一些常见的设计模式及其应用场景。
1. 单例模式（Singleton Pattern）：单例模式保证一个类只有一个实例，并提供一个全局访问点。
常用于需要共享资源的对象，例如线程池、日志类等。
2. 工厂模式（Factory Pattern）：工厂模式用于创建对象，将对象的创建逻辑与客户端代码分离。
常用于创建复杂的对象或者需要隐藏对象创建过程的场景。
3. 观察者模式（Observer Pattern）：观察者模式定义了对象间的一对多关系，使得当一个对象状态改变时，其所有依赖对象都能收到通知并自动更新。
常用于事件处理、消息通知等场景。
4. 装饰者模式（Decorator Pattern）：装饰者模式在不改变对象原有结构的基础上，动态地为对象添加新的功能。
常用于增强对象的功能或者修改对象的外观。
5. 策略模式（Strategy Pattern）：策略模式定义了一系列算法，并将每个算法都封装起来，使得它们可以相互替换。
常用于根据不同的条件选择不同的算法。
6. 适配器模式（Adapter Pattern）：适配器模式将一个类的接口转换成另一个接口，以满足客户端的需求。
常用于将不兼容的接口进行适配。
7. 外观模式（Facade Pattern）：外观模式提供一个统一的接口，用于访问子系统的一群接口。
常用于简化复杂的子系统调用。
命令模式将一个请求封装成一个对象，使得可以用不同的请求对客户进行参数化。
常用于实现撤销、重做、任务队列等功能。
9. 建造者模式（Builder Pattern）：建造者模式通过将复杂对象的构建逻辑与对象本身分离，使得同样的构建过程可以创建不同的表示。
常用于创建复杂的对象。
10. 模板方法模式（Template Method Pattern）：模板方法模式定义了一个操作中的算法框架，把一些步骤推迟到子类实现。
23种设计模式的经典运用介绍设计模式是解决软件设计中常见问题的可重复使用的解决方案。
本文将介绍23种经典的设计模式，并给出它们在实际开发中的应用示例。
通过学习这些设计模式，您将增加对软件设计的理解，并能够更好地解决问题。
创建型设计模式1.工厂方法模式（F a c t o r y M e t h o d）工厂方法模式通过定义一个创建对象的接口，但由子类决定实例化具体类。
这种方法可以延迟实例化过程，具有更高的灵活性和可扩展性。
应用场景：-在一个系统中，希望客户端与具体类的实例化解耦。
-希望通过增加具体类的扩展来增加系统的灵活性。
2.抽象工厂模式（A b s t r a c t F a c t o r y）抽象工厂模式提供一个接口，用于创建相关或依赖对象组。
这种模式将对象的实例化推迟到子类中，从而实现了解耦。
应用场景：-当一个系统独立于其产品的创建、组合和表示时。
-当需要一个系列的相互依赖的对象而无需指定其具体类时。
3.单例模式（S i n gl e t o n）单例模式确保一个类只有一个实例，并提供一个全局访问点。
这种模式常用于控制对资源的访问，例如数据库连接或日志文件。
应用场景：-当需要一个类的唯一实例，并且该实例需要被多个客户端共享时。
-当需要限制系统中特定类的实例数量时。
4.原型模式（P r o to t y p e）原型模式通过复制现有对象来创建新对象。
这种模式对于创建需要消耗大量资源的对象非常有用，可以通过克隆现有对象来提高性能。
应用场景：-当一个系统的某些对象的创建比较昂贵时。
-当需要避免构造函数调用，而直接通过复制现有对象来创建新对象时。
5.建造者模式（B ui l d e r）建造者模式将一个复杂对象的构建过程与其表现分离，使得相同的构建过程可以创建不同的表现。
应用场景：-当想要构建一些复杂对象时，如生成器。
-当需要创建对象的过程具有多个步骤，并且每个步骤都可以按需选择或省略时。
结构型设计模式6.适配器模式（A da p t e r）适配器模式将一个类的接口转换为客户端所期望的另一个接口。
UML类图详解及类图设计UML中定义了⽤例图、类图、时序图、协作图等九种。
设计模式中经常会⽤到的是类图。
类是⾯向对象系统组织结构的核⼼，类可以说是对⼀组具有相同属性、操作、关系和语义的对象的抽象。
在UML中，类使⽤带有分隔线的矩形表⽰，它包含名称部分（Name）、属性部分（Attribute）和操作部分（Operation）。
其中属性的表现形式是[可见性] 属性名:类型 [=默认值]。
操作的表现形式是：[可见性] 名称（参数列表）[：返回类型]。
详细见下图。
1.类图基础属性+表⽰public-表⽰private#表⽰protected~表⽰default,也就是包权限_下划线表⽰static斜体表⽰抽象2.类之间关系在UML类图中，常见的有以下⼏种关系:泛化（Generalization）：带空⼼三⾓箭头的实线来表⽰，箭头由⼦类指向⽗类实现（Realization）：带空⼼的三⾓箭头的虚线来表⽰，箭头从实现类指向接⼝关联（Association)：分为双向关联和单向关联，其中，双向关联可以⽤带两个箭头或者没有箭头的实线来表⽰，单向关联⽤带⼀个箭头的实线来表⽰，箭头从使⽤类指向被关联的类，还可以再关联线的两端标注⾓⾊名，补充说明它们的⾓⾊。
聚合（Aggregation），⽤带空⼼菱形的实线表⽰，菱形指向整体组合(Composition)：⽤带实⼼菱形的实线来表⽰，菱形指向整体。
依赖(Dependency)：使⽤带箭头的虚线表⽰，箭头从使⽤类指向被依赖的类下图为类之间的关系在UML中的图形表达式：2.1泛化泛化(Generalization)表⽰类与类之间的继承关系，接⼝与接⼝之间的继承关系，或类对接⼝的实现关系(1)继承介绍：继承表⽰是⼀个类（称为⼦类、⼦接⼝）继承另外的⼀个类（称为⽗类、⽗接⼝）的功能，并可以增加它⾃⼰的新功能的能⼒。
表⽰⽅法：继承使⽤空⼼三⾓形+实线表⽰。
⽰例：鸟类继承抽象类动物(2)实现实现表⽰⼀个class类实现interface接⼝（可以是多个）的功能。
UML的九种模型图本⽂转⾃，仅供学习交流！⼀、作为⼀种建模语⾔，UML的定义包括UML语义和UML表⽰法两个部分。
UML语义：描述基于UML的精确元模型定义。
UML表⽰法：定义UML符号的表⽰法，为开发者或开发⼯具使⽤这些图形符号和⽂本语法为系统建模提供了标准。
这些图形符号和⽂字所表达的是应⽤级的模型，在语义上它是UML元模型的实例。
⼆、标准建模语⾔UML可以由下列5类图来定义。
⽤例图：从⽤户⾓度描述系统功能，并指出各功能的操作者。
静态图：包括类图和对象图。
类图描述系统中类的静态结构，不仅定义系统中的类，表⽰类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是⼀种静态关系，在系统的整个⽣命周期都是有效的。
对象图是类图的实例，⼏乎使⽤与类图完全相同的标识。
⼀个对象图是类图的⼀个实例。
由于对象存在⽣命周期，因此对象图只能在系统某⼀时间段存在。
⾏为图：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图。
状态图描述类的对象所有可能的状态以及事件发⽣时状态的转移条件，状态图是对类图的补充，活动图描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系，有利于识别并进⾏活动。
交互图：描述对象间的交互关系，包括时序图和协作图。
时序图显⽰对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显⽰对象之间的交互；协作图描述对象间的协作关系，协作图跟时序图相似，显⽰对象间的动态合作关系。
除显⽰信息交换外，协作图还显⽰对象以及它们之间的关系。
如果强调时间和顺序，则使⽤时序图；如果强调上下级关系，则选择协作图。
实现图：包括组件图和部署图。
组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度；部署图定义系统中软硬件的物理体系结构。
采⽤UML来设计系统时，第⼀步是描述需求；第⼆步根据需求建⽴系统的静态模型，以构造系统的结构；第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的，包括⽤例图、类图、对象图、组件图和部署图等5种图形，是标准建模语⾔UML的静态建模机制。
面向对象四要素：对象、类、继承、消息。
建模原因：是为了能够更好地理解正在开发的系统。
建模要达到的4个目的：(1)模型有助于按照实际情况或按照所需要的样式对系统进行可视化。
(2)模型能够规约系统的结构或行为。
(3)模型给出了指导构造系统的模板。
(4)模型对做出的决策进行文档化。
建模基本原理：(1)选择要创建什么模型，对如何动手解决问题和如何形成解决方案有着意义深远的影响。
(2)可以在不同的精度级别上表示每一种模型。
(3)最好的模型是与现实相联系的。
(4)单个模型或视图是不充分的，对每个重要的系统最好用一小组几乎独立的模型从多个视角去逼近。
UML概念：是一种对软件密集型系统的制品进行可视化，详述，构造和文档化的语言。
4种关系：依赖（是两个模型元素间的语义关系）、关联（是类之间的结构关系）、泛化（是一种特殊/一般关系）、实现（是类目之间的语义关系，其中一个类目指定了由另一个类目保证执行的合约）。
3类主要的行为事物：交互，状态机，活动。
UML4种事物：结构事物：是UML模型中的静态部分，描述概念元素或物理元素。
行为事物：是UML模型中的动态部分，代表了跨越时间和空间的行为。
分组事物：是UML模型中的组织部分，是一些由模型分解成的“盒子”。
注释事物：是UML 模型中的解释部分，用来描述，说明和标注模块中的任何元素。
3种构造块：事物、关系、图。
UML的“4+1”视图、作用与意义：是UML从不同角度来观察和描述软件系统的体系结构所建立的五种视图。
每个视图都是整个系统描述的一个投影，说明了系统的一个特殊侧面。
五种视图分别是：用例视图，逻辑视图，数据视图，进程视图、部署视图。
UML的公共机制：(1)规约（提供了对构造块的语法和语义的文字叙述）；(2)修饰；(3)通用划分（三种划分方式：①对类和对象划分②接口和实现的分离③类型和角色的分离）；(4)扩展机制（包括衍型、标记值、约束）。
UML透视图：概念透视图：用图来描述现实世界或关注领域中的事物。
UML 2.0共有10种图，分别为表示系统静态结构的静态模型（包括类图、组合结构图、部署图），以及表示系统动态结构的动态模型（包括用例图、序列图、对象图、协作图、状态图、活动图、组件图），它们各用以表现不同的视图，如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系：
（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。
在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。
当父用例能够被使用时，任何子用例也可以被使用。
如在图2.4中，订票是电话订票和网上订票的抽象。
软件体系结构实验六
利用UML描述常见的几种设计模式
一：实验目的
掌握设计模式在软件设计中的作用，熟悉并了解一些常用的设计模式，进一步熟悉并巩固Rational Rose 2003与Visio2003工具的使用，熟悉并了解IBM Rational Software Architecture 6.0工具的建模方法。
二：实验准备
（1）熟悉利用UMLRose2003与Visio2003建模的方法
（2）熟悉并了解软件设计模式
（3）熟悉并了解IBM Rational Software Architecture 6.0的建模方法。
三：实验内容
设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。
你必须找到相关的对象，以适当的粒度将它们归类，再定义类的接口和继承层次建立对象之间的基本关系。
在设计时，应该对手头的问题有针对性，同时对将来的问题和需求也要有足够的通用性，同时也希望避免重复设计或尽可能少做重复设计。
一个设计模式是软件开发中重复出现问题的解决方案；一种来源于具体问题形式的抽象，这种抽象在特定环境中出现；在给定的问题环境和约束条件下，对通用问题的重复解决方案；一种经过证明的、在给定条件下问题的有效的重复解决方案。
它象一个“大金块”传递了解决方案的本质。
（点石成金的方法）。
经过多次成功使用，已经被证明的“最佳实践方法”；用文字、图表描述的方式来捕捉设计专家的智慧和经验，并把这些经验传递给新手。
对通用设计问题的重复解决方案，对真实世界问题的实践的/具体的解决方案面向特定的问题环境权衡利弊之后得到的“最佳”解决方案，领域专家和设计老手的“杀手锏”，用文档的方式记录的最佳实践，在讨论问题的解决方案时，一种可交流的词汇，在使用（重用）、共享、构造软件系统中，一种有效地使用已有的智慧/经验/专家技术的方式。
在面向对象的软件设计中，可以利用UML对设计进行建模，对设计模式的建模包括建立内部视图和外部视图
①设计模式的内部视图是一组类图和一组交互图。
②设计模式的外部视图是一个参数化协作，协作参数命名。
是模式的用户必须绑定的元素。
本次实验要求同学们理解常见的组合模式（结构类型）、工厂模式（构造类型）、责任链模式（行为类型）。
并能根据具体的案例，选择相应的设计模式，并根据该设计模式所定义的组成元素，组成元素之间的关连关系、约束关系，利用UML作出具体的设计。
在IBM Rational Software Architecture 6.0中，提供了Goff所总结的23种常见模式的模板，我们可以根据这些模板，实例化模板的参数，最后得到一个具体的某种模式的设计。
图1-图3描述了组件的一个设计。
图一：组件的设计模式图（IBM RSA6.0中建模）
图二：组件的设计模式图主题图（IBM RSA6.0中建模）
图三：组件的浏览图（IBM RSA6.0中建模）
一：组合模式：
一个例子：组件可以分为原子组件与组合组件，原子组件是不能再分解的一个组件单元，组合组件则是由多个组件组成，而组成组合组件的这些组件既可以是原子组件，也可以是组合组件。
这样，原子组件可以通过组合构成一个组合组件，原子组件与组合组件又可以通过组合构成更大的组合组件。
我们可以通过组合模式来设计一个组合组件的模型，图三是利用IBM RationalSoftwareArchitecture所提供的组合模式设计出来的组件的结构。
图四是利用Rational Rose类图描述的组件的结构图。
图四：组件类图（Rose2003）
图形可以看成是一些基本图形元素与组合图形元素的组合体，其中基本的图形元素包括点，线，园，矩形，椭圆形，射线等基本元素。
而一个最简单的组合图形元素是这些基本图形元素组合在一块形成的组合。
通过组合，最终可以构成用户所需要的图形。
图五描述了一个构成的例子。
一个文件夹由文件以及文件夹组成，而在这个文件夹里可能也是由文件及文件夹组成，因此，文件夹也是一种组合模式的实例，请根据上面所提供描述内容，利用组合模式画出图
形元素、文件夹的UML结构图。
.
.
图五：一个图形例子
图六：一个文件夹的例子
二：责任链模式：
责任链模式是使多个对象都有机会处理请求，从而避免请求的对象和接收的对象之间的
耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
例如一个图形用户界面中的上下文有关的帮助机制，用户在界面的任一部分上按F1键就应该可以得到帮助信息，所提供的帮助依赖于点击的是界面的哪一部分以及上下文环境。
显然，在这种模式中，我们应根据从最特殊到最普遍的顺序来组织帮助信息，这样，用户所得到的帮助应是最体现了用户的需求。
+handler()
aPrintButton +handler()
aPrintDialog
+handler()
anApplication
+handler()
anOKButton +handler()
aSaveDialog
图七 对象责任链类之间调用图
根据上面的提示，请画出它们之间的对象交互图以及类图。
aPrintButton
aPrintDialog
anApplication
handler()
handler()
图八：帮助责任链序列图
+Handle()+Help()
HelpHandler +help()
+hanlder(aPrintDialog)()
PrintButton +Help()
+hanlder(anApplication)()
PrintDialog +Help()+hanlder()
Application
图九：责任链类图
抽象工厂模式与工厂模式：
抽象工厂模式与工厂模式的区别：抽象工厂模式比工厂模式更复杂，更灵活，一个抽象工厂模式或以先创建出多个具体的工厂，这些具体的工厂再创建出具体的产品。
抽象工厂模式关键在于工厂类是多层次的，有父工厂类和子工厂类，父工厂类可以产生子工厂类，再由子工厂类生产出产品，这样产品也可以是由复杂关系的，也可以说多种的。
创建产品时，它是由具体工厂的实例的操作来完成的。
抽象工厂模式：多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
工厂方法模式：一个抽象产品类，可以派生出多个具体产品类。
由这些类来创建实例
+CreateButton()+CreateTextBox()+CreateLabel()+CreateCombo()+......()
AbstractFactory +CreateButton()+CreateTextBox()+CreateLabel()+CreateCombo()+......()
.NetFactory +CreateuctButton()+CreateTextBox()+CreateLabel()+CreateCombo()+......()
JavaFactory
Button JButton
TextBox JTextBox
Combo
Label JCombo
JLabel
图十：生成不同平台的控件的设计图（简化了的抽象工厂模式）
+Create()+......()
Icon Button TextBox Combo
+Create()+......()
TextIcon +Create()+......()
ButtonIcon +Create()+......()
ComboIcon
图十一：生成不同控件的设计图（工厂模式）
根据上面分析与实例所描述抽象工厂模式与工厂模式的区别及联系，考虑一个游戏中的人物的创建，试着利用这两种模式对游戏中创建人物的方法进行建模。
（提示：为了描述在不同的场景中的人物建立，可以认为不同的场景是不同的具体工厂，而在同一场景中建立一个人物，可以利用工厂模式进行建模）。
实验六实验报告
班级09软件工程2班学号200930690211 姓名江庆青
一：实验过程：
利用RSA6.0设计出组件、文件夹、图形的设计。
并谈谈设计模式的理解
组件
图形
文件夹。
