1.面向对象技术
面向对象技术基于对象概念，以对象为中心，以类、组合、继承为构造机制，充分利用接口和多态提供灵活性，来认识、理解、刻画客观世界和设计、构建相应的软件系统。
面向对象=对象 + 类 + 消息 + 继承 + 多态
面向对象方法是一种把面向对象的思想运用于软件开发过程，指导开发活动的系统方法，包括分析、设计和实现等活动
面向对象是软件方法学的返璞归真：面向用户
2.面向对象技术优点
沟通
稳定
复用
改善软件结构（模块化与封装），提高软件灵活性
增加可扩展性
支持增量式开发，支持大型软件开发
3.面向对象vs过程
4.UML建模工具
4.1 UML（统一建模语言）
Unified Modeling Language（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）。
4.2 UML结构
构造块：基本UML建模元素、关系和图
事物：建模元素本身
关系：把物件联系在一起，关系说明两个或多个物件时如何语义相关的
图：UML模型的视图，它们展现物件的集合，“讲述关于软件系统的故事”，是我们可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法
公共机制：达到特定目标的公共UML方法
架构：系统架构的UML视图
4.2.1 UML事物
模型中最具有代表性的成分的抽象
结构事物
类：类是具有相同属性、相同方法、相同语义和相同关系的一组对象的集合。一个类可以实现一个或多个接口。在UML图中，类用包括类名、属性和方法的矩形来表示。
接口：描述了一个类或构件的向外提供的操作集；仅仅是定义了一组操作的规范，它并没有给出这组操作的具体实现；通常，一个类实现一个或多个接口。
协作：协作定义了交互的操作，表示一些角色和其他元素一起工作，提供一些合作的动作。一个给定的类可能是几个协作的组成部分，这些协作代表构成系统的模式的实现。
用例：用例定义了系统执行的一组操作，对特定的用户产生可以观察的结果，在UML图中，用例通常用一个实线椭圆来表示。
活动类：类对象有一个或多个线程或进程的类。活动类和类相似，只是它的对象代表的元素的行为和其他的元素同时存在。在UML图中，活动类的表示方法和普通类的表示方法相似，也是使用一个矩形，只是最外面的边框使用粗线。
组件：组件是物理上可替换的，实现了一个或多个接口的系统元素。
节点：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，比如一台数据库服务器。在UML中，节点使用一个立方体来表示。节点通常包括处理器和设备。
行为事物：行为事物也称为动作事物，是UML模型中的动态部分，代表时间和空间上的动作。行为事物主要有两种：交互、状态机（UML模型中最基本的两个动态事物元素，通常和其他的结构元素、主要的类、对象连接在一起。）
交互：交互由在特定环境中共同完成一定任务的一组对象之间交换的消息组成。
状态机：状态机是对象的一个或多个状态的集合。在UML图中，状态机通常用一个椭圆矩形来表示。状态机是一个行为，它说明对象在它的生命周期中响应时间所经历的状态序列以及它们对那些事件的响应。
分组事物
包：包是用来组织 UML 模型的基本事物
注释事物
注释：注释是依附于一个元素或一组元素之上，对其进行约束或解释的简单符号。
4.2.2 关系
关联：关联是一种结构关系，它描述了一组对象之间的静态连接
聚合：是一种特殊形式的关联，它表示类之间的整体与部分的关系 组合：是一种特殊形式的聚集，组合关系中的整体与部分具有同样的生存期。
依赖：依赖是一种使用关系，它说明一个事物的变化可能影响到使用它的另一个事物
泛化：一个元素是另一个元素的特化
实现：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
2.2.3 图
用例图：说明和定义软件系统的功能需求；从系统外部观看系统功能，并不描述系统内部对功能的具体实现；展现一组用例、参与者及其它们之间的关系
参与者：与系统交互的外部实体
用例：从用户角度描述系统的行为
参与者之间的泛化关系：参与者之间的一般与特殊的关系
用例之间的泛化关系：用例之间的一般与特殊关系
用例之间的包含关系：一个用例是对另一个用例描述的活动序列的某个活动的细化
用例之间的扩展关系：一个用例是对另一个用例（被扩展用例）描述内容的补充（被扩展用例的某个活动出现异常、分支等）
类图：描述系统的静态结构；展示系统中的类、类的属性和操作、以及类与类之间的关系(关联、依赖、聚合等)；在系统的整个生命周期都是有效的。
对象图：描述系统在某一刻对象和它们之间的联系；实质上是类图的实例。
构件图：描述构件以及它们之间的关系；表示系统的静态实现视图。
部署图：描述节点、以及节点和节点之间的关系；反映系统中软件和硬件的物理配置情况和系统体系结构。
序列图：描述了一组交互对象间的交互方式；强调完成某项行为的对象和这些对象之间传递消息的时序性。
通信图：描述了对象与周围对象之间的交互，以及它们之间的链接；序列图和协作图两者之间可以相互转换；序列图侧重消息之间的时序性，通信图侧重对象间的联系。
活动图：描述由不同对象所执行的一组活动、以及活动之间的关系；反映系统中各种活动的执行顺序。
状态图：描述一组状态、以及状态之间的迁移；反映一个特定对象的所有可能状态以及引起状态迁移的事件。
4.2.4 公共机制
规格说明：UML的图形表示用来对系统进行可视化，UML的规格说明用来描述系统的细节。规格说明提供了对构造块的语法和语义的文字叙述。
修饰：UML表示中每一个元素都有一个基本符号，可将各种修饰细节加到这个符号上。
公共分类：对类和对象的划分；对接口和实现的划分。
扩展机制：
衍型：也称构造型，常用《衍型名》表示
约束：增加新的语义或改变已有的规则
标记值：详述与代码生成或配置管理有关的特性，用{(标记)= (值)}表示
UML的规则
UML有用于描述如下事物的语义规则：
命名：任何一个UML基本图素和模型图都必须命名
作用域：UML成员所定义的内容起作用的上下文环境
可见性：UML成员能被其它成员引用的方式
完整性：UML成员之间互相关联的合法性和一致性
运行属性：UML成员在运行时的特性，如进程、线程、同步等
4.2.5 架构
5.面向对象建模
一般的建模顺序：
对象模型：定义实体，描述系统数据，定义“对谁做”
动态模型：描述系统控制结构，规定“何时做”
功能模型：描述系统功能，指明系统应“做什么”
六、面向对象分析
1.面向对象思想的实质：不从功能和处理算法上考虑，而是从系统的组成上进行分解；尽可能直接描述现实世界。
2. 面向对象方法学的优点：与人类习惯的思维方法一致；稳定性好；可重用性好；较易开发大型软件产品；可维护性好。
3.面向对象的过程模型：喷泉模型，是典型的面向对象的软件过程模型
4.面向对象分析：找出并规定该问题域中根据系统各项要求而行动并相互作用的对象，并依据这些对象及其关系建立问题域模型。
面向对象分析过程从分析陈述用户需求的文件开始。
用例建模
对象建模：识别分析类、定义交互行为
评审分析模型
4.1 用例建模
用例模型由用例图来表示
用例建模的具体过程：定义系统、确定参与者、确定用例、描述用例、确定用例之间的关系、评审用例模型
4.1.1 定义系统
是由一组用例所描述的一个系统或子系统。其中的这些用例描述了该主题的完整行为，而参与者则表示与该主题进行交互的另一种类。
4.1.2 确定参与者
参与者是一组高内聚的角色，当用户与用例交互时，该用户扮演了这一角色。
确定谁会直接使用该系统。这些都是参与者(Actor)。
选取其中一个参与者， 定义该参与者希望系统做什么，参与者希望系统做的每件事成为一个用例。
4.1.3 确定用例
用例总是被参与者启动的，参与者必须参与到用例所描述的系统执行场景
用例必须是完整的，描写一个完整的执行过程，并向参与者返回可见的有价值的结果
用例之间的关系：泛化、包含、扩展
4.1.4 描述用例
用例的描述模版：
开户用例描述：
取款用例描述：
4.2 对象建模
对象建模就是建立系统的对象模型
对象模型反映了系统类与类之间的关系，体现了系统的静态结构
对象模型由类图来表示
4.2.1工具——类图
类图由类、接口等模型元素以及它们之间的关系构成。类图的目的在于描述系统的构成方式，而不是系统如何协作运行。
4.2.2 类
描述类的信息有：名称、属性、操作、职责、约束、注释。
属性（Attribute）在UML类图标的矩形框中用文字串说明
可视性（Visibility）标记表示：
+公共:公共属性，可以被外部对象访问
＃保护:可以被本类或子类的对象访问
-私用:不可以被外部对象访问，只能为本类的对象使用
属性类型表示：冒号“：”后跟属性值的数据类型。
属性初始值设置：可以通过在属性名称和数据类型之后添加等于号（＝）来为属性指定默认值。
属性多重性：多重性为可选项，它表达该类的每个实例的属性值的个数。可以像应用于类之间的关系中那样把多重性应用于属性。
派生的属性：另一种可以为属性提供的信息是派生值，它可以使用数学函数、字符串函数或者将要在应用程序中实现的其他商务逻辑。要想指出一个属性是派生的，需要在属性名之前添加一个前斜线（／），并且要附加一个注释，其中包含了派生属性值的指令。
操作（Operation）表示类能够提供的功能服务。它在UML类矩形框中用文字串说明。
操作名指示类可提供的功能服务，它后跟圆括号中的参数列表是可选项，即一个操作可以有参数，也可以没有参数。参数列表由逗号分隔的操作的形式参数组成，其格式为：参数名：类型=缺省值，…
返回列表是返回给调用者的单个变量值，它可以表示该操作程序运行的一个成功标志或者计算的值。
4.2.3 接口
接口是在没有给出对象的实现和状态的情况下对对象行为的描述。接口包含操作但不包含属性，且它没有对外界可见的关联。在UML中，接口是用一个带有名称的小圆圈表示的，并且通过一条实线与它的模型元素相连接。
关联和属性：在类关联和类属性之间存在精密的联系。源类和目标类之间的关联意味着源类的对象能够承载到目标类对象的引用。
4.2.4 类之间的关系
依赖关系、泛化关系、关联关系、实现关系
关联的约束：是各种模型元素的一种语义条件或限制。一条约束只能应用于同一类的元素。
约束可分为：对泛化的约束、关联的约束
对泛化的约束
应用于泛化的约束，显示在大括号里，若有多个约束，用逗号隔开。如果没有共享，则用一条虚线通过所有继承线，并在虚线的旁边显示约束，如图所示：
对泛化有以下常用的约束：
complete: 说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。
disjoint: 父类对象不能有多于一个型的子对象。
incomplete: 说明不是泛化中所有子元素都已说明，允许再增加其它子元素。
overlapping: 给定父类对象可有多于一个型的子对象，表示重载。
关联的约束
对关联有以下常用的约束：
implicit:该关联是概念性的，在对模型进行精化时不再用。
ordered:具有多重性的关联一端的对象是有序的。
changeable:关联对象之间的链(Link)是可变的（添加、修改、删除）。
addonly:可在任意时刻增加新的链接。
frozen:冻结已创建的对象，不能再添加、删除和修改它的链接。
xor: “或约束”，某时刻只有一个当前的关联实例。
关联类：OO建模的一个普遍问题是，当类之间具有多对多关系时，一些属性不能容易地放人任何一个类中。例如，下图所示的公司与员工的类关系。
UML允许你使用关联类来建模这种情况，如下图所示。
4.3 对象建模过程
理解用例描述、识别类和类的属性、识别类的操作、确定类与类之间的关系、评审 4.3.1 识别分析类
分析类：分析类是概念层次上的内容；在功能需求分析过程中，描述系统较高层次的对象。
三种分析类：
边界类：描述与参与者直接打交道的对象，一般是一些UI界面
用于对系统外部环境与其内部运作直接的交互进行建模的类。
控制类：描述系统的行为，即系统做什么
用于对一个或几个用例所持有的控制行为进行建模的类。
实体类：描述系统的中的数据信息（有些数据是实体类，而有些是实体类的属性）
用于对必须存储的信息和相关行为进行描述的类。
边界类和实体类都对应于用例描述中的名词，而控制类对应于用例描述中的动词
识别对象的准则：搜寻准则、判别准则、检验准则
三种分析类之间的交互规则
参与者只能与边界对象交互
边界对象只能和控制对象、用例的参与者进行交互
实体对象只能与控制对象进行交互
控制对象可以和边界对象、实体对象交互，但不能和用例的参与者进行交互。
即：参与者<->边界类<->控制类<->实体类
根据需求分析阶段获得的系统用例图，可以创建如下所示的分析类图：
4.3.2 定义交互行为
识别类的操作的方法：建立对象之间的交互模型
主要手段：为每一个用例建立时序图（序列图、顺序图）
主要任务：分配控制类所代表的系统行为到各个前面所识别的系统类中（一般包括边界类、实体类、以及某些控制类）
顺序图：表达对象之间的基于时间的动态交互关系，着重体现对象间消息传递的时间顺序。
顺序图存在两个轴：
水平轴：表示不同的对象
垂直轴：表示时间
顺序图由对象、生命线、激活和消息等构成。
建立用例对应的顺序图的主要过程：
将参与者、边界类、实体类等添加到顺序图的顶部
将用例的内容复制到顺序图的左侧
针对用例的每句描述，建立对象之间的消息交互
在识别类、以及类的操作过程中，还要识别类的属性
识别类、属性和操作之后，识别类之间的关系，那么对象模型基本就建立起来了
（时间线应为虚线）
4.4 评审分析模型
从四个方面：“正确性”评审、“完整性”评审、“一致性”评审、“可行性”评审
对象建模的实际过程：领域建模->对象建模
4.4.1 领域模型
识别出一个领域的常见的类与类之间的关系
（1）发现参与者
（2）建立用例模型：用例图+用例描述（规约）
（3）建立静态视图：分析类图
（4）建立动态视图：序列图
七、面向对象设计
1.OOD概述
面向对象设计（Object-Oriented Design，OOD）就是运用面向对象方法进行系统设计。
OOD特点：
以OOA为基础，一般不依赖于结构化分析。
与相应的OOA方法共同构成一种OOA&D方法体系。
较全面地体现了面向对象方法的概念和原则。
大多数OOD方法独立于编程语言，但具体应用OOD时，要考虑特定的编程语言。
OOA和OOD采用一致的概念和表示法——不存在分析与设计之间的鸿沟
OOA和OOD有不同的侧重点和不同的策略：
OOA主要针对问题域，识别有关的对象以及它们之间的关系，产生一个映射问题域，满足用户需求，独立于实现的OOA模型。
OOD主要解决与实现有关的问题，基于OOA模型，针对具体的软、硬件条件（如机器、网络、OS、GUI、DBMS、编程语言等）产生一个可实现的OOD模型。
OOA与OOD可适合不同的生命周期模型——瀑布模型、螺旋模型、增量模型、喷泉模型
2.系统设计
系统设计一般包括：
概要设计：包括如何把整个系统分解为子系统、子系统的软硬件布局等策略性决策
详细设计：根据具体的实现策略，对分析模型进行扩充，包括了对象设计和对象持久化设计
设计评审：对所设计的系统和系统设计规格说明报告逐一进行严格审查，检查是否达到系统设计功能要求
2.1概要设计
概要设计主要是对系统的体系结构进行设计
系统体系结构也称为系统架构，是指一个或一组结构，它包含组成系统的软件元素、这些元素对外可见的性质以及它们之间的关系。 体系结构设计的两部分：系统架构是最高层次的系统分解，包括软件体系结构设计和硬件体系结构设计两部分
体系结构设计的常见策略：分层
在信息系统中软件架构通常采用典型的三层结构：
表示层――用户界面
业务层――业务处理流程
数据层――持久化存储
数据层在业务层中是可见的，业务层在表示层中是可见的，反之则不可见
2.1.1软件体系结构的建模工具：包
包（package）是一种逻辑分组手段，可以取UML模型中的任何一种事物，将相关成分聚在一起，以构成更高层的组织单元
最常用的方法是将类以包为单位进行分组，比如三层结构中的每一层中的所有类组成一个包
包图：包图用来描述包及其依赖关系，用来标识一个完整系统的主要部分
在包图中只使用两个符号：一个包的标识符，一个虚线箭头，虚线箭头表示依赖关系，箭头的尾部表示被依赖的包，头部是独立的包。
包依赖关系可以是直接的，也可以间接的，依赖关系可以传递;
三层架构的包图
每层对应一个包：用户界面包、业务处理包、数据访问包
再把各层中的一些公共部分提出来：权限管理包、异常处理包
2.1.2 硬件体系结构设计
指出系统中的类和对象涉及的具体程序或进程。
指明系统中配置的计算机和其他硬件设备。
指明系统中各种计算机和硬件设备如何进行相互连接。
明确不同代码文件之间的相互依赖关系。
硬件体系结构设计：部署图
并不是所有的系统都需要建立配置图，一个单机系统只需建立包图或构件图
2.2 详细设计
主要包括对象设计和对象持久化设计（数据库设计）
2.2.1 对象设计
对属性和操作进行建模
属性建模：确定属性的类型和数据结构、可见性等
操作建模：确定操作的可见性、参数、返回值、算法等
2.2.2 对象持久化设计
关注的是对象数据如何存储
对象持久化设计的方法：基于关系数据库存储
关系数据库与面向对象中的概念存在一定的对应
3.面向对象设计原则
单一职责原则
一个类只完成某一类功能(职责)；尽可能避免出现一个“复合”功能的类——在同一个类中完成多个不同的功能
开放-封闭原则
软件实体类(类、模块、函数等)应该是可以扩展、但是不可修改的
基本思想：不用修改原有类就能扩展一个类的行为
接口隔离原则
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口更好
Liskov替换原则
子类应当可以替换父类并出现在父类能够出现的任何地方
核心思想：子类型必须能够替换它们的基类型，该原则能够知道设计人员正确地进行类的继承与派生
依赖倒置原则
应用系统中的高层模块不应依赖于底层模块；抽象不应该依赖于细节实现，实现细节应该依赖于抽象
如何遵守设计原则：一些成熟的设计模式可以帮助我们解决实际问题，并且符合设计原则
4.设计模式
设计模式：描述一个在我们周围不断重复发生的问题，以及该问题的解决方案。
使用设计模式，我们就能一次一次地利用已有方案而不必做重复劳动。
广义上讲：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。
狭义上讲：设计模式就是对特定问题的描述或解决方案，往往直接对应一段程序代码。
作用：记录和提炼了软件人员在面向对象软件设计中的成功经验和问题的解决方案，是系统可复用的基础。正确地使用设计模式，有助于快速开发出可复用的系统。
意义：优化的设计经验、极高的复用性、丰富的表达能力、极低的耦合度
设计模式的四个基本要素：
模式名称：一个助记名
问题：描述了应该在何时使用模式
解决方案：描述了设计的组成成分，解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
效果：描述了模式应用的效果及使用模式应权衡的问题。
GOF之23种设计模式：
创建型模式：创建型模式关注的是如何创建对象而不是直接实例化对象
抽象工厂模式、工厂方法模式、单例模式、建造者模式、原型模式
结构型模式：结构型模式关注的是如何将一组对象组合成更大的结构
适配器模式、外观模式、桥接模式、组合模式、装饰模式、享元模式、代理模式
行为型模式：行为型模式关注的是如何定义系统内对像间的通信，以及复杂程序中的流程控制
迭代器模式、观察者模式、策略模式、职责链模式、命令模式、解释器模式、中介者模式、备忘录模式、状态模式、模板方法模式、访问者模式
