面向对象思维导图模板_ProcessOn思维导图、流程图

面向对象理论

类

属性

指类具有的特征

属性最小化原则，即"属性不可再分"

方法

指类具有的功能

方法单一化原则，即"一个方法只做一件事"

对象

一个具体的类，有一个真实存在的类

接口

接口中的功能点实时定义，并不涉及具体实现

接口是一个交互协议，是交互双方的一个约定，具体实现，由具体的交互实体各自实现即可

抽象类

抽象类只能用于继承，不能被实例化为具体对象

抽象类是基于类而抽象出来的

抽象类有的存在抽象方法(方法只有声明，没有定义)，子类必须自己定义这些抽象方法，而不能像普通的方法一样，通过继承就可以获取父类的方法

抽象类本质上还是类，强调一组事物的相似性，包括属性和方法的相似性；而接口只强调方法的相似性，并且仅仅体现在方法声明省的相似性，而没有方法定义上的相似性

三大核心特征

封装

public

protected

private

继承

类似生物学上的"遗传"

多态

使用指向父类的指针或者引用，能够调用子类的对象

需求模型

通过和客户沟通，结合行业经验和知识，明确客户端的需求

目的

 了解客户需要什么？？

需求分析目的

记录员

记录客户的需求

分析员

和客户一起分析问题，完善需求

引导员

能够引导客户的需求

需求分析的方法

5W

When

季节信息

日期信息

作息时间

Where

国家、地区

室内、室外、街道

建筑物

Who

常见的参与者信息

投资者、管理者

使用者、维护者

监督者、评估者

其他系统

举例：ATM

顾客：使用ATM取款、存款

银行维护人员:每天将钱放进ATM

质检机构：根据XX法律对ATM进行检查

What

一个文档

一份报告

一个系统

Why(最关键)

1H

How

使用用例分析

8C

性能

成本

时间

可靠性

安全性

合规性

技术性

兼容性

用例方法

用例方法三段法

正常处理

异常处理

代替处理

完整的用例

简单的样例：POS机

为什么要将功能点单独提取出来呢？

一个功能列表肯定比一长篇用例文档方便的多

从项目管理的角度来说，功能列表更易于管理，例如任务分配时不可能基于用例进行分配，因为不同用例可能存在大量重复的功能点

从开发的角度来说，开发时基于工功能点的，而不是基于用例的

从测试角度来说，虽然最后的验收测试时基于用例的，但产品测试主要还是基于功能点进行测试的

用例图

Actor

系统外的用户，对应5W中的Who，包括但不限于用户、外系统

Use  Case

用例，对应前面讲到的用例

System

系统，所有用例的集合就是系统了

SSD

用于描述在某个用例的某个分支场景下，外部参与者与系统的交互过程

SSD不是标准的UML图形，UML只有顺序图、用例图，但是没有专门的"系统顺序图"；之所以叫作"系统顺序图"，是因为这个顺序图中只有两类对象。系统与系统交互的对象。

SSD用来描述某个用例的分支，而不是描述系统的结构

画SSD的时候，整个系统被当作一个黑盒，不涉及系统的分解

不需要为每个用例的每个分支都画一个SSD，调出关键的用例和分支即可

领域模型

找名词

例如：买单

顾客

收银员

收银台

商品

扫描仪

条形码

子主题

加属性

连关系

问题

为什么在POS机的领域模型的类中没有看到类的方法呢?

如果没有用例，是否就没法得到领域模型？

设计模型

静态模型

第一步（照猫画虎）: 领域类映射

类筛选

名称映射

将领域类转换为软件类，一对一转换

属性映射

直接从领域明星搬过来

提炼方法

分配

将从用例中提炼出来的动词，分配给已经有有了属性的软件类

第二步（精雕细琢）:应用设计原则和设计模式

设计原则

单一职责原则

开闭原则

里氏替换原则

接口隔离原则

依赖反转原则

第三步(照本宣科)：拆分辅助类

比如常见的MVC模式（Control、Model、View）

动态模型

状态模型

活动模型

顺序图

实现模型

面向对象技巧

设计原则

内聚

耦合

什么是模块？

函数

类

包

子模块

子系统

什么是依赖？

就是某个模块用到了另外一个模块的一些元素

耦合的分类

消息耦合

消息？？

系统/子系统

类

数据耦合

通过参数传递，而不是通过去哪聚文件、配置文件、共享内存等其他方式

传递的基本数据类型，例如在java中传递Integer、double/String 等类型，而不是传递数据结构

数据结构耦合

传递的是数据结构数据

控制耦合

通过传入一个控制参数来控制函数的处理流程或者输出

外部耦合

两个模块依赖相同的外部数据格式、通信协议、设备接口时

全局耦合

当两个模块共享相同的全局数据时，称为全局耦合

高内聚低耦合

为什么要高内聚低耦合？？

高内聚低耦合是否意味着内聚越高越好、耦合越低越好？？

为什么该内聚和低耦合是冲突的？？

类设计原则

单一职责原则

只负责一组相关的事情

一个类有多个方法，这些方法是相关的