一、面向对象

1、基本概念

软件对象，是一种将状态和行为有机集合起来形成软件构造模型

对象和类

对象是状态和行为构成的

类是相同属性和操作的一组对象的组合

消息和事件

消息是指描述事件发生的信息，是对象间相互联系和作用的方式

事件是指一种由系统预先定义而由用户或系统发出的动作

2、基本特征

抽象

封装

通过公共访问控制器来限制对象的私有属性的好处：

避免对封装数据的未授权访问

帮助保护数据的完整性

当类的私有方法必须修改时，限制了在整个应用程序内的影响

继承

继承的目的：

使派生类能够比不使用继承直接进行描述的类更加简洁

能够重用和扩展现有类库资源

使软件易于维护和修改

多态

3、方法论

获取问题域陈述

建立系统的对象模型

标实和确定类

准备数据字典

确定关联

确定属性

使用继承来细化类

完善对象模型

建立对象的动态模型

准备脚本

确定事件

准备事件跟踪表

构造状态图

建立系统的功能模型

4、面向对象的设计准则

模块化

抽象

信息隐藏—对象的封装

低耦合-有助于类的维护

高内聚-一个对象类中应尽量多地汇聚逻辑上相关的计算资源

5、面向对象的实用规则

设计的结果应该清晰易懂

避免模糊的定义

一般到具体结构的深度应适当

尽量设计小而简单的类

使用简单的消息协议

使用简单的函数或方法

把设计变动减至最小

6、系统设计

子系统分解

确定并发性

处理器及任务分配

数据存储管理

全局资源的处理

选择软件控制机制

人机交互接口设计

二、面向对象建模

1、Unified Modeling Language

统一建模语言UML

2、开发模式

瀑布模型

项目计划->需求分析->软件设计->软件实现->软件测试->软件运行和维护

缺点：

开发模式呈线性，开发成果尚未经过测试时，用户无法看到软件效果，增加项目的风险(数据概览)

瀑布模型强制固定的完成日期和里程碑进行项目跟踪，项目开发过程中缺乏足够的灵活性

软件需求分析阶段，要完全确定系统用户所需要的所有需求是一件比较困难的事情

喷泉模型

分析->设计->实现->维护->演化

缺点：

大量开发，不利于管理

严格的文档管理，审核难度加大

基于构件的开发模式

软件计划->需求分析和定义->软件的快速原型->原型评审->软件设计和实现

缺点：

自定义的组装结构标准，引入了较大的风险

可重用性和软件高效性不易协调

过分依赖构件

XP方法

核心思想：

交流、简单、反馈、进取

Communication、Simplicity、FeedbackAggressiveness

优点：

采用简单计划策略，不需要长期计划和复杂模型，开发周期短

全过程采用迭代增量的开发，反馈修正和反复测试的方法，软件质量有保证

能够适应用户经常变化的需求，提供用户满意的高质量软件

三、Unified Modeling Language概述

1、视图

静态视图

关联

泛化

依赖->使用、实现

用例视图

交互视图

状态机视图

活动视图

物理视图

模型管理视图

2、图

用例图

帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于流程的”角色"关系以及系统用例之间的关系

表达系统或者系统范畴的高级功能

类图

显示了系统的静态结构，表示不同的实体是如何彼此相关联的

序列图

显示一个具体用例或者用例一部分的详细流程

状态图

某个类所处的不同状态以及该类在这些状态中的转换过程

初始状态：使用一个实心圆来绘制

状态之间转换：开箭头的线段

状态：圆角矩形

判断点:空心圆

一个或多个终止点:内部包含实心圆来绘制

活动图

表示二个或者更多的对象之间在处理某个活动时的过程控制流程

构件图

指出某些功能实际存在于那些地方

部署图

该软件系统如何部署到硬件环境中的

3、模型元素

事物

结构事物

分组事物

注释事物

关联

依赖

关联

泛化

实现

4、UML的通用机制

规格说明

修饰

这里表示class2对class是1对多的关系

通用划分

5、UML的扩展机制

构造型

比如：

<><><>

标记值

约束

四、总结

主要讲了面向对象的一些基本概念和设计的方法论(获取限定上下文，建立对象模型，动态模型，功能模型)和原则，包括设计准则(低耦合高内聚、抽象、模块化和封装)和实用原则，介绍了软件开发的四种模式(瀑布、喷泉、构件、XP)，最后简单介绍了一下UML，包括了UML的视图、图、模型元素三个方面，后面还有一部分UML的公共机制，包含了通用机制和扩展机制。

谈谈自己的一些感悟吧，在平时的工作中，用到比较多的是用例图、类图、时序图、状态越迁图，类图现在其实用到的也不多了，现在有个很概念叫做领域驱动设计(DDD)，类图画的越来越少，工作上都在用领域图。以前都是野路子画法，2019年的第一个月，我准备把UML系统的学习一遍。还是发现之前画的图还是很不规范的，比如说类的约束和修饰，之前的详细设计中都没有体现，至于构件图、活动图、部署图，之前也有画过，不过画成了四不像，后期主要会针对这些没有涉及过的UML模型进行学习。

最后分享一下本章的思维导图