高级软件工程-自己整理-研究生期末考

记录于2021年6月23日，2022年3月26日上传至博客

模式设计： 题目结合实际场景，比如某个软件，给出核心功能，对此分析用到了什么模式 8个模式：
工厂、访问者、代理、适配器、组合、桥、观察者、迭代器模式。

1软件设计模式的概念

软件设计模式（Software Design Pattern）

又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

1.1工厂模式：

定义一个创建对象的接口，让其子类自己决定去实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。主要解决接口选择问题。如何使用：明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。创建过程在其子类执行。实例：比如用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时；或者日志记录器，用户可以选择记录日志到什么地方，可能是本地硬盘、远程服务器等。
优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。

1.2访问者（Visitor）模式

定义：将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离，是行为类模式中最复杂的一种模式。

访问者（Visitor）模式是一种对象行为型模式，其主要优点如下。
扩展性好。能够在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
复用性好。可以通过访问者来定义整个对象结构通用的功能，从而提高系统的复用程度。
灵活性好。访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可相对自由地演化而不影响系统的数据结构。
符合单一职责原则。访问者模式把相关的行为封装在一起，构成一个访问者，使每一个访问者的功能都比较单一。
访问者（Visitor）模式的主要缺点如下。
增加新的元素类很困难。在访问者模式中，每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，这违背了“开闭原则”。
破坏封装。访问者模式中具体元素对访问者公布细节，这破坏了对象的封装性。
违反了依赖倒置原则。访问者模式依赖了具体类，而没有依赖抽象类。

1.3代理模式：

为其他对象提供一种代理以控制对这个对象的访问。主要解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。何时使用：想在访问一个类时做一些控制。如何解决：增加中间层。实现与被代理类组合。实例：比如windows里面的快捷方式。
优点： 1、职责清晰。 2、高扩展性。 3、智能化。
缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

1.4适配器模式：

意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
何时使用： 1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。如何解决：继承或依赖，适配器继承或依赖已有的对象，实现想要的目标接口。
实例：充电器或电器转换接口。
优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。
缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

1.5组合模式：

将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。
何时使用： 1、您想表示对象的部分-整体层次结构（树形结构）。 2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
如何解决：树枝和叶子实现统一接口，树枝内部组合该接口。树枝内部组合该接口，并且含有内部属性 List，里面放 Component。

1.6桥模式：

用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
意图：将抽象部分与实现部分分离，使它们都可以独立的变化。
主要解决：在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。
何时使用：实现系统可能有多个角度分类，每一种角度都可能变化。
如何解决：把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。抽象类依赖实现类。
实例：一个类存在两个独立变化的维度，且这两个维度都需要进行扩展，使用桥模式。

1.7观察者模式：

当对象间存在一对多关系时，则使用观察者模式。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。
意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
如何解决：使用面向对象技术，可以将这种依赖关系弱化。在抽象类里有一个 ArrayList 存放观察者们。

1.8迭代器模式：

迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
主要解决：不同的方式来遍历整个整合对象。
何时使用：遍历一个聚合对象。
如何解决：把在元素之间游走的责任交给迭代器，而不是聚合对象。实例：JAVA 中的 iterator

2软件工程的要素：

工具、方法、过程

2.1三要素具体含义：

工具：为软件工程方法提供自动化或半自动化的软件支撑环境和工具。
方法：为软件开发提供“如何做”的技术。
过程：软件过程是方法和工具综合起来以达到合理、高效地进行软件开发 的目的。

2.2常用的方法有：

1.生命周期法（传统方法、结构化方法）
2.面向对象方法
3.原型法
4.其它新方法或综合方法（钮俊重点）

2.2.1结构化方法

2.2.2面向对象方法

2.2.3原型法

软件生命周期包含了软件从概念形成到最终退役的所有活动，而对于一个具体的软件项目，开发人员更加关注的是开发过程中包含的活动以及其具体安排。

软件体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系.

3.软件设计过程的内容

主要活动及各活动的目的。可以精简点
软件设计可能是一个多次反复的过程，所以，软件设计一般都可以被看作是迭代的过程。
迭代有两层含义：

• 第一层含义是，针对给定的需求模型，通过多次从抽象到具体的设计过程，得出足够精细的设计模型以供软件实现之用。
• 在需求模型发生变化并更新完成后，第一层含义的设计过程再随之展开，直至获得最终的目标软件产品。

3.1软件设计的主要活动：

在设计过程中，对设计活动进行计划应该最早进行，然后按照计划实施体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计等活动。

3.1.1软件设计计划的任务：

明确设计过程的输入制品并使其处于就绪状态，定义设计过程的目标、输出制品及其验收准则，确定覆盖设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程中的活动制订工作计划。

3.1.2体系结构设计：

• 软件体系结构设计的目标是建立软件系统的体系结构，有时也称“顶层架构”。
• 这种架构既要明确定义软件各子系统、关键构件、关键类的职责划分及协作关系，同时也要描绘它们在物理运行环境下的部署模型。
• 此外，顶层架构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案往往构成目标软件系统的体系结构的技术基础设施。

3.1.3界面设计：

• 用户界面设计的目标是，为用户使用目标软件系统以实现其所有业务需求而提供友好的人机交互界面。
• 软件界面设计需要考虑以下因素：适用于软件功能、易理解性、一致性、灵敏性、容错性、人性化、国际化、个性化、合理的布局、和谐的色彩

3.1.4模块/子系统设计

• 子系统和模块的区别：一个子系统独立构成系统，不依赖其它子系统提供的服务；一个模块通常是一个能提供一个或多个服务的系统部件。它能利用其它模块提供的服务，一般不被看成一个独立的系统。
• 由于模块和子系统都是软件组成部分，它们一般都有层次结构，相互之间存在接口，其设计方法有很多类似的方面，因此我们统一称为模块设计。
  模块设计的目标：
• 确定模块的具体接口定义，并设计模块的内部结构，即设置包含于其中的（更小粒度的）模块、构件和设计类，
• 明确它们之间的协作关系，确保它们能够协同实现高层模块接口规定的所有功能和行为。
• 在进行模块设计时，要尽量保持模块的功能独立性，遵循“高内聚、低耦合”的设计思想。
• 此外，还要力求将模块的影响限制在模块的控制范围内，使得软件日后的修改和维护工作更加简单。

3.1.5过程/算法设计

• 过程/算法设计的任务就是对模块内部的工作和执行过程进行描述，给出有关处理的精确说明，例如事件的顺序、确切的决策位置、循环操作以及数据的组成等。
• 软件结构与软件过程相互关联，软件结构中任何模块的所有从属模块必将被引用出现在该模块的过程说明中。因此，软件过程对应的结构设计亦构成一个层次结构。

3.1.6数据模型设计

• 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。
• 在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。
• 在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。
  “持久化”：持久（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的数据存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等。
  “持久层”：持久层（Persistence Layer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。
  “对象数据映射（ORM）”：ORM-Object/Relational Mapper，即“对象-关系型数据映射组件”。对于O/R，即 Object（对象）和 Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。

3.2软件体系结构的概念

• 软件体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系；
• 软件体系结构是软件系统的基本组织，包含构件、构件之间、构件与环境之间的关系，以及相关的设计与演化原则；
• 软件体系结构的风格（style）描述某一特定领域中系统组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性；
• 软件体系结构包含以下内容：软件体系结构的描述、软件体系结构的设计方法、软件体系结构的分析方法、软件体系结构的复用。

3.3软件体系结构设计的方法

1）多视图建模；
2）基于评估与转换的设计方法；
3）模式驱动的设计方法；
4）领域特定的软件体系结构设计；
5）软件产品线方法；
6）其它软件体系结构设计方法。
基于目标图推理的体系结构设计方法，基于属性的体系结构设计方法，一些常用的软件开发方法学中也包含了软件体系结构的设计。
例如：面向数据流的软件开发方法，面向对象的软件开发方法，面向方面的软件开发方法。

3.4数据模型设计的内容，过程与环节

• 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。
• 在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。
• 在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。
• 持久数据模型设计步骤：
  a．确定设计模型中需要持久保存的类的对象及其属性，其中实体类是主要关注对象。
  b．确定持久存储的数据之间的组织方式。
  c．确定数据模型中的操作行为，例如数据完整性验证、数据读取、存储与更新、数据求和、求数据平均值等。
  d．进一步优化持久数据操作的性能，例如使用数据索引、存储过程、触发器等方式

3.5结构化方法与面向对象设计共同遵守的原则及其解释

（1）抽象原则
抽象原则是一切系统科学方法都必须遵循的基本原则它注重把握系统的本质内容而忽略与系统当前目标无关的内容它是一种基本的认知过程和思维方式。
（2）模块化
模块化是已经被分为一系列聚集的和耦合的模块的系统特性对于一个给定的问题确定正确的模块集几乎与确定正确的抽象集一样困难通常每个模块应该足够简单以便能够被完整地理解。

4.框架、架构、模式、构建的概念，通过实例来证明理解。（重点）

架构的定义、特点。

架构：软件体系结构通常被称为架构，指可以预制和重构的软件框架结构。简单的说架构就是一个蓝图，是一种设计方案，将客户的不同需求抽象成为抽象组件，并且能够描述这些抽象组件之间的通信和调用。是一系列相关的抽象模式。
软件架构设计要达到：可靠性、安全性、可扩展性、可定制化、可伸缩、可维护性、客户体验、市场时机。

框架：软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架是一个半成品，已经对基础的代码进行了封装并提供相应的API，从而提高工作效率和开发速度。

模式：是一种针对软件生命周期中出现问题而给出的多次适用的解决方案。

首先架构是一个范畴最大的概念，是最高层次的设计。一个架构中会用到多个框架和多个模式。
在做一个项目的时候，首先出来的应该是架构，是对整个问题的一个总体上的设计，之后再考虑运用什么样的框架和模式来实现。

4.1架构和框架的关系：

1. 框架不是架构，框架比架构更具体，更偏重于技术，而架构偏重于设计。
2. 架构可以通过多种框架来实现。

4.2框架和模式的关系：

1.一个模式可以应用于不同的框架和被不同的语言所实现。
2.框架针对某一特定领域，而模式却可适用于各种应用。
3.虽然它们有所不同，但却共同致力于使人们的设计可以被重用

4.3架构和模式的关系：

1.设计模式主要是针对单一问题的解决方法，范畴比较小，而架构是高层次的针对体系结构的一种设计思路，范畴比较大。
2.可以这么说，一个架构中可能会出现多个设计模式来解决多种架构中的问题。

4.4MVC

全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，它强制性的使应用程序的输入、处理和输出分开。
==Model（模型）==用于封装与应用程序业务逻辑相关的数据以及对数据的处理方法
==View（视图）==显示数据（用户界面）
==Controller（控制器）==控制器起到不同层面间的组织作用，用于控制应用程序的流程

使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。

1.耦合性低
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
2.重用性高
MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。
3.部署快，生命周期成本低
MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
4.可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
缺点——》有mvm

5面向对象的分析设计和方法

5.1思维方式，思想，抽象，封装，多态，继承，内聚，耦合

面向对象方法以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结构与客观世界的实际比较接近，容易被人们接受。在面向对象方法中，分析和设计的界面并不明显，它们采用相同的符号表示，能够方便地从分析阶段平滑地过渡到设计阶段。此外，在现实生活中，用户的需求经常会发生变化，但客观世界的对象及对象间的关系比较稳定，因此用面向对象方法分析和设计的结构也相对比较稳定。

==对象和类：==在现实世界中，每个实体都是对象，如学生、书籍、收音机等；每个对象都有它的操作，例如书籍的页数，收音机的频道、按钮等属性，以及收音机的切换频道等操作。
而类则是对具有相同属性和服务的一个或一组对象的抽象。类与对象是抽象描述和具体实例的关系，一个具体的对象被称为类的一个实例。在系统设计过程中，类可以分为三种类型，分别是实体类、边界类和控制类。

==封装：==就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。一个类就是一个封装了数据以及操作这些数据的代码的逻辑实体。在一个对象内部，某些代码或某些数据可以是私有的，不能被外界访问。通过这种方式，对象对内部数据提供了不同级别的保护，以防止程序中无关的部分意外的改变或错误的使用了对象的私有部分。
该公开的就公开话，该私有的就隐藏掉，主要是由public，private实现；作用是便于分工和分模块，防止不必要的扩展。

==多态：==多态（即多种形式）性是指一般类中定义的属性或服务被特殊类继承后，可以具有不同的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的。

==继承：==用来说明特殊类（子类）与一般类（父类）的关系，而通常用泛化来说明一般类与特殊类的关系，也就是说它们是一对多关系。
“交通工具”是“自行车”和“小轿车”的泛化；“自行车”和“小轿车”从“交通工具”中继承。

==内聚：==内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。

==耦合：==简单地说，软件工程中对象之间的耦合度就是对象之间的依赖性。指导使用和维护对象的主要问题是对象之间的多重依赖性。对象之间的耦合越高，维护成本越高。因此对象的设计应使类和构件之间的耦合最小。

5.2面向对象设计方法中概念模型设计的含义

面向对象设计模型解决的是“类与其相互通信的对象之间的组织关系”，包括他们的角色、职责、协作方式等几个方面。
概念模型是对现实世界中问题域内的事物描述，不是软件描述。概念的描述包括：记号、内涵、外延。其中记号和内涵（视图）是最具有实际意义的。
UML中的类图非常适合建立领域的概念模型，描述在问题域中存哪些主要概念和对象，并表示出他们的关系，例如关联、聚合、继承等

5.3面向对象分析（OOA）（重点）

OOA——面向对象的分析，就是运用面向对象方法进行系统分析，对问题域(问题所涉及的范围)和系统责任(所开发的系统应具备的职能)进行分析与理解，找出描述问题及系统责任所需要对象，定义对象的属性、操作以及它们之间的关系。
（1）建立需求模型——用例图
确定系统边界
发现参与者
定义用例
（2）建立基本模型——类图
发现对象、定义它们的类
定义对象的内部特征——属性和操作
定义对象的外部关系——一般-特殊结构、整体-部分结构、关联和消息
（3）建立辅助模型
划分包，建立包图
建立顺序图
建立活动图
建立构件图
建立部署图
建立其他模型图
（4）建立模型规约
对模型中的成分进行规范的定义和文字说明

5.4面向对象设计（重点）

在面向对象分析阶段，已经针对用户需求建立起用面向对象概念描述的系统分析模型。在设计阶段，要考虑为实现系统而采用的计算机设备、操作系统、网络、数据库管理系统以及所采用的编程语言等有关因素，进一步运用面向对象的方法对系统进行设计，最后形成一个可以实现的设计模型，即面向对象设计模型。

5.5面向对象的原则（4个）

开闭原则OCP、单一职责原则SRP、里氏替换原则LSP、接口隔离原则ISP

定义、优缺点、如何实现、用会怎么样，不用会怎么样

5.5.1开闭原则OCP：

软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。
特征：
对于扩展是开放的（Open for extension）
模块的行为可以扩展，当应用的需求改变时，可以对模块进行扩展，以满足新的需求
对于更改是封闭的（Closed for modification）
对模块行为扩展时，不必改动模块的源代码或二进制代码

OCP的关键在于抽象
抽象技术：abstract class, Interface
抽象预见了可能的所有扩展（闭）
由抽象可以随时导出新的类（开）
优点：如果这个原则应用得有效，应用程序就会具有更多的可维护性、可重用性以及可健壮性。

5.5.2单一职责原则SRP：

定义：不要存在多于一个导致类变更的原因，就一个类而言，应该仅有一个引起它变化的原因。通俗地说，即一个类只负责一项职责。
优点：
1.降低类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑肯定要比负责多项职责简单得多。
2.提高类的可读性，提高系统的可维护性。
3.降低变更引起的风险。变更是必然的，如果单一职责原则遵守得好，当修改一个功能的时候可以显著降低对其他功能的影响。
缺点：类的分离使得类的关系更加复杂。 生成具有对其他类的引用太多的类作为成员的倾向。 由于成员很难对其他类引用过多的类很难测试。
单一职责原则的解决方案
遵循单一职责原则，分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1的时候，不会使职责P2发生故障风险。同理，当修改T2的时候，也不会使职责P1发生故障风险。

5.5.3里氏替换原则LSP：

“若对于类型S的任一对象o1，均有类型T的对象o2存在，使得在T定义的所有程序P中，用o1替换o2之后，程序的行为不变，则S是T的子类型”。
如果在任何情况下，子类（或子类型）或实现类与基类都是可以互换的，那么继承的使用就是合适的。为了达到这一目标，子类不能添加任何父类没有的附加约束。
“子类对象必须可以替换基类对象”。
解决方法：在可能的情况下，由抽象类（接口）继承。（图）

5.5.4接口隔离原则ISP：

客户不应该依赖他们不用到的方法，只给每个客户它所需要的接口；
为了避免“肥接口(fat interface)”，应当以一个类实现多个接口，而各客户仅仅获知必须的接口。
ISP本质：
使用多个专门的接口比使用单一的接口好
一个类对另一个类的依赖性应当是建立在最小的接口上的
避免接口污染（Interface Pollution）

5.6任意给出3种面向对象设计原则，并解释其含义，并针对其中1中举例说明。（重点）

5.6.1单一职责原则

其核心思想为：一个类，最好只做一件事，只有一个引起它的变化。单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而大大损伤其内聚性和耦合度。通常意义下的单一职责，就是指只有一种单一功能，不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。专注，是一个人优良的品质；同样的，单一也是一个类的优良设计。交杂不清的职责将使得代码看起来特别别扭牵一发而动全身，有失美感和必然导致丑陋的系统错误风险。

5.6.2开放封闭原则

其核心思想是：软件实体应该是可扩展的，而不可修改的。也就是，对扩展开放，对修改封闭的。
开放封闭原则主要体现在两个方面
1、对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
2、对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对其进行任何尝试的修改。实现开开放封闭原则的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以修改就是封闭的；而通过面向对象的继承和多态机制，又可以实现对抽象类的继承，通过覆写其方法来改变固有行为，实现新的拓展方法，所以就是开放的。
“需求总是变化”没有不变的软件，所以就需要用封闭开放原则来封闭变化满足需求，同时还能保持软件内部的封装体系稳定，不被需求的变化影响。

5.6.3接口隔离原则

其核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。具体而言，接口隔离原则体现在：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。
接口有效地将细节和抽象隔离，体现了对抽象编程的一切好处，接口隔离强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口的所有方法、属性等；而某些时候，实现类型并非需要所有的接口定义，在设计上这是“浪费”，而且在实施上这会带来潜在的问题，对胖接口的修改将导致一连串的客户端程序需要修改，有时候这是一种灾难。在这种情况下，将胖接口分解为多个特点的定制化方法，使得客户端仅仅依赖于它们的实际调用的方法，从而解除了客户端不会依赖于它们不用的方法。
分离的手段主要有以下两种：
1、委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统的开销。
2、多重继承分离，通过接口多继承来实现客户的需求，这种方式是较好的。
里氏替换原则
“子类型必须能够替换掉它们的基类型。“本原则和开放封闭原则关系密切，正是子类型的可替换性，才使得使用基类型模块无需修改就可扩充。里氏替换原则从基于契约的设计演化而来，契约通过为每个方法声明"先验条件"和"后验条件”；定义子类时，必须遵守这些"先验条件"和"后验条件”。当前基于契的设计发展势头正劲，对实现"软件工厂"的"组装生产"梦想是一个有力的支持。

6复用和解耦

7.结合实例，说明解耦的含义及其作用。

6.1耦合

是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。

6.2解耦

就是用数学方法将两种运动分离开来处理问题，常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动，只分析主要的运动。

6.3追求高内聚、低耦合：

软件架构设计的目的简单说就是在保持软件内在联系的前提下，分解软件系统，降低软件系统开发的复杂性，而分解软件系统的基本方法无外乎分层和分割。但是在保持软件内在联系的前提下，如何分层分割系统，分层分割到什么样的力度，并不是一件容易的事，这方面有各种各样的分解方法，比如：关注点分离，面向方面，面向对象，面向接口，面向服务，依赖注入，以及各种各样的设计原则等，

6.4高内聚，低耦合的系统的好处：

事实上，短期来看，并没有很明显的好处，甚至短期内不会影响系统的开发进度，因为高内聚，低耦合的系统对开发设计人员提出了更高的要求。高内聚，低耦合的好处体现在系统持续发展的过程中，高内聚，低耦合的系统具有更好的重用性，维护性，扩展性，可以更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为业务发展的障碍。

6.5软件复用：

软件复用的主要思想是将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具，这样，如果完成各种工作的组件被建立起来以后，编写一特定软件的工作就变成了将各种不同组件组织连接起来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。
==软件复用就是将已有的软件成分用于构造新的软件系统。==可以被复用的软件成分一般称作可复用构件，无论对可复用构件原封不动地使用还是作适当的修改后再使用，只要是用来构造新软件，则都可称作复用。软件复用不仅仅是对程序的复用，它还包括对软件生产过程中任何活动所产生的制成品的复用，如项目计划、可行性报告、需求定义、分析模型、设计模型、详细说明、源程序、测试用例等等。如果是在一个系统中多次使用一个相同的软件成分，则不称作复用，而称作共享；对一个软件进行修改，使它运行于新的软硬件平台也不称作复用，而称作软件移值。

7软件工程基本概念——过程（包括模型）和方法

方法：为构建软件提供技术上的解决方法（如何做），包括沟通、需求分析、设计建模、程序构造、测试和技术支持。方法还依赖一组基本原则。
过程：是工作产品构建时所执行的一系列活动、动作和任务的集合。是方法和工具综合起来以达到合理、高效地进行软件开发的目的。
过程模型：
概念：过程模型为软件工程工作提供了特定的路线图，规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。
重要性：软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。同时，软件过程的灵活性也很重要，即要求软件工程活动、控制以及工作产品适合于项目团队和开发的产品。
步骤：过程模型为软件人员提供了开展软件工程工作需要遵循的步骤。

7.1.惯用过程模型：

7.1.1瀑布模型

（针对需求有准确定义且相对稳定的情况有效、线性工作流方式）
适用于瀑布模型的项目：数据结构、软件架构、程序的细节和接口表征的对象。

7.1.2 V模型

（瀑布模型的一个变体、提供一种将验证和确认动作应用于早期软件工程工作中的直观方法）
上述两周生命周期模型的问题：
1、缺少灵活的迭代方式，变更容易引起混乱
2、无法处理需求阶段的不确定性
3、周期较长

7.1.3增量过程模型：

综合线性过程模型和并行过程模型特征，每个阶段是线性的；
第一个增量一般是核心产品。

7.1.4 演化模型: 原型模型

针对需求不明确的情况；
需要利用已有的程序片段或应用工具快速产生可执行的程序。
适用于采用原型模型的软件项目：人机交互、复杂计算机图形软件应用程序、某些类别的数学算法、命令驱动系统。

7.1.5 演化模型: 螺旋模型

通过循环逐步加深系统定义和实现的深度（而非广度）；
确定一系列里程碑作为支撑点。

7.1.6 演化模型: 并行模型（并发模型/并发开发模型）

下图是并发模型的一个例子，在某一特定时间，建模活动可能处于图中所示的任何一种状态中。其他活动、动作或任务（如沟通或构建）可以用类似的方式表示。所有的软件工程活动同时存在并处于不同的状态。

7.1.7 专用过程模型

基于构件的开发—能够使软件复用
形式化方法—注重需求的数学规格说明
面向方面的软件开发—为定义、说明、设计和构建方面提供过程和方法
统一过程—一种“用例驱动、以构架为中心的迭代和增量”软件过程和统一建模语言(UML)紧密结合

7.1.8 统一过程（模型）

建立一种“用例驱动，以架构为核心，迭代并增量”的软件过程问题。

8. UML，基本概念，有哪些图

UML统一建模语言(unified modeling language)，这种语言包含了大量用于面向对象系统建模和开发的符号。
特点和用途：

• 为使用者提供了统一的、表达能力强大的可视化建模语言；
• 独立于实现语言和方法学，但支持所有的方法学，覆盖了面向对象分析和设计的相关概念和方法学。
• 独立于任何开发过程模型，但支持软件开发全过程
• 支持较高抽象层次开发所需的各种概念，如协同、框架、模式和构件等，便于系统的重用。
  有哪些图，分结构建模（静态建模）和行为建模（动态建模）
• 结构建模：有类图、包图、对象图、构件图、组合结构图、部署图，主要用来描述系统中包含的元素以及元素之间的关系。

结构建模中的视图可以对各个层次和阶段的软件进行刻画，例如软件设计、软件实现、系统部署等等。这些模型对系统的逻辑结构或物理结构进行描述，并不涉及系统的动态行为和过程。

• 行为建模：活动图、顺序图、通信图、交互概览图、时序图、状态图、用例图，它主要用来刻画系统中的动态行为、过程和步骤。

行为建模也常被称为动态建模，它主要用来刻画系统中的动态行为、过程和步骤。UML行为建模中提供的视图可以从不同侧面来描述软件系统的动态过程.
结构建模对系统中的元素及其关系进行描述，而行为建模对这些元素完成特定任务的过程进行描述，两者相互结合就能够完整地描述整个系统的特征。

类图（重点）：

抽象类、关联类、接口，依赖关系、关联关系、整体-部分关系、泛化（继承）关系、实现关系。

• 类图（ClassDiagram）是用来显示系统中的类、接口、协作以及它们之间的静态结构和关系的一种静态模型。它主要用于描述软件系统的结构化设计，帮助人们简化对软件系统的理解，它是系统分析与设计阶段的重要产物，也是系统编码与测试的重要模型依据。
• 类图中的类可以通过某种编程语言直接实现。类图在软件系统开发的整个生命周期都是有效的，它是面向对象系统的建模中最常见的图。
• 下面根据类与类之间的耦合度从弱到强排列。UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

包图：导入关系（图）、合并关系
对象图：类图的实例
构建图：是系统中具有良好封装、可替换的模块。每个构建能够实现一定的功能，为其他构建提供使用接口，方便软件的复用。

活动图：描述一个系统行为（活动）的执行过程或步骤（动作）。有对象节点和控制节点。/泳道，把动作按照执行的对象进行划分，以明确活动中各个参与者的相应职责。
顺序图：交互操作
交互概览图：交互图或对交互图的引用
时序图：关于消息时间的描述，所处状态或条件随着消息发生的变化
状态图：使用有穷状态变迁图的方式刻画系统或元素的离散行为
用例图：被用来描述系统的需求，从用户的角度对系统的功能视点进行建模。刻画了系统包含哪些用例以及用例之间、用例与外部角色之间的关系。有包含关系、拓展关系（图）

案例：银行ATM自动柜员机的需求简述（用例分析与设计） 本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：
取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。
存款服务。顾客可以把现金存入与银行卡对应的账户中。 转账服务。顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。
查询服务。顾客能够查询一个银行卡对应的账户中的余额。

（1）确定用例
采用用例模型描述系统需求时，首先需要开发人员从业务需求描述出发获取参与者（Actor）和场景，对场景进行汇总、分类、抽象，形成用例。
场景是从单个参与者的角度观察目标软件系统的功能和外部行为，这种功能通过系统与用户之间的交互来表示。
场景是用例的实例，而用例是某类场景的共同抽象。
定义用例， 在场景确定之后，通过对场景的汇总、分类归并、抽象即可形成用例。
ATM案例的参与者：顾客”（Customer）
“操作管理人员”（Operator）
“银行服务器”（Bank System）
“读卡器”（Card Reader）
“存款器”（Cash Acceptor）
“取款器”（Cash Dispenser）
“打印机”（Printer）
ATM案例的用例：“取款”（Withdrawal）
“存款”（Deposit）
“转帐”（Transfer）
“查询余额”（Inquiry）
“开机”（System Startup）
“关机”（System Shutdown）
（2）生成用例图
生成用例图是一个逐步精化的过程，首先可以建立初步的用例图，包括前面发现的参与者和用例；
然后对用例图进行细化，定义用例之间“包含”、“扩展”、“继承”等关系，并可能需要定义新的用例，以能够更准确地使用用例图描述系统需求。
（3）用例描述
对用例的完整描述包括用例名称、参与者、前置条件、一个主事件流、0到多个辅事件流、后置条件。
主事件流表示正常情况下参与者与系统之间的信息交互及动作序列，
辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。

补充：
架构框架和模式的关系：比如盖房子，架构就是整个房子的结构，框架是地基，模式是某个部分比如窗户。