UML面向对象方法

UML知识点归纳笔记

面向对象基本概念

什么是分析和设计
分析（analysis）*：强调的是对问题和需求的调查研究，而不是解决方案。
设计（design）*：强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。
什么是面向对象分析和设计
面向对象分析：强调的是在问题领域内发现和描述对象（或概念）
面向对象设计：强调的是定义软件对象以及它们如何协作以实现需求。
什么是面向对象方法：
面向对象方法（Object-Oriented Method）是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO方法，是建立在“对象”概念基础上的方法学。
什么是UML
统一建模语言（Unified Modeling Language）：是描述、构造和文档化系统制品的可视化语言。
UML介绍*：
用例图*、类图、对象图、构件图、部署图、包图、组合结构图、顺序图、通信图、状态图、活动图、交互概述图、时间图

面向对象方法解决问题的基本思路

面向对象方法的解决问题思路是从现实世界中的客观对象（如人和事物）入手，尽量运用人类的自然思维方式来构造软件系统。

强调直接以问题域（现实世界）中的事物为中心来思考问题、认识问题，并根据这些食物的本质特征把它们抽象地表示为系统中的对象，作为系统构成的基本单位。（对象）
用对象的属性表示事物的性质，用对象的操作表示事物的行为。（属性与操作）
对象的属性与操作结合为一体，成为独立不可分的实体，对外屏蔽细节。（封装）
对事物进行分类。把有相同属性和相关操作的对象归为一类，每个对象是它的类的一个实例。（分类）
复杂的对象可以用简单的对象作为其构成部分。（聚合）
通过不同程度上运用抽象原则，可以得到一般的类和特殊的类。特殊类继承一般类的属性与操作，从而简化系统的构造过程及其文档。（继承）
对象之间通过消息进行通讯，以实现对象之间的动态联系。（消息）
通过关联表示类（一组对象）之间的静态关系。（关联）

另一个说法：

一、定义用例
二、定义领域模型
三、分配对象职责并绘制交互图
四、定义设计类图

UML视图解析及使用场景

静态视图：
- 类图：是显示一组类、接口、协作以及它们之间关系的图。
- 对象图：是表示在某一时间点上一组对象以及它们之间的关系的图。
- 包图：是包和包之间的关系构成，是维护和控制系统总体结构的重要建模工具，用于描述系统的分层结构。
行为视图：
- 用例图：表现一组用例、参与者以及它们之间的关系。
设计视图：
- 状态图：显示了一个状态机，它强调从状态到状态的控制流。
- 活动图：显示从活动到活动的流（本质流程图，不同情况下的动作）。
- 交互图：属于行为图形的子集合，强调系统模型中的资料流程。
- 通信图：强调发送和接收消息的对象的结构组织的交互图。
- 时序图：显示对象之间的关系，强调对象之间消息的时间顺序，显示对象之间的交互。
实现视图：
- 组件图：描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。
- 部署图：是一种展示运行时进行处理的结点和在结点上生存的制品的配置的图。

用例图

参与者、用例、关联（—>）、包含（-《include》->强调整体与部分的关系）、扩展（-《extend》->）、泛化（子—▶️父继承关系）

用例规约（用例文本）
注：每个用例名称唯一，且格式为[动词+名词短语]，如：登陆xx系统

类图

Java大白话讲解设计模式之—UML类图

顺序图（时序图）

是一种强调消息时序的交互图，它主要描述系统中对象和对象之间的交互，它将这些交互建模成消息交换。
顺序图显示具体用例（或者是用例的一部分）的详细流程
–显示了流程中不同对象之间的调用关系
–显示对不同对象的不同调用

角色Actor
对象Object
生命线LifeLine
控制焦点Activation
消息Message（同步消息、异步消息、返回消息）
自关联消息
组合片段

实例:

通信图转顺序图:

活动图

业务建模

业务建模实践：实例分析
•研究对象：某旅店
•业务现状：
–某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣
–旅客可以直接入住房间(如果有空房)，也可提前预订；入住和预订都需要登记个人信息
–旅客提前预订房间时，需提交一定的订金；入住时间24小时之外的旅客可以取消预订，并退回所有订金，24小时以内则不退还订金
–退房时缴纳全部的住宿费用
–服务员每月为经理提供房间的预订情况和入住情况的详细信息

GRASP（通用职责分配软件原则）原则

全称：General Responsibility Assignment Software Pattern通用职责分配软件原则
共9种原则，描述了对象设计和职责分配的基本原则

Information Expert信息专家
- 把职责分配给具有完成该职责所需要信息的类（单一职责）。
Creator创造者
- A是B的聚合/容器/A持有初始化B的数据创建B是会传递给B/A记录B的实例/A频繁使用B时，A创建B。
- 创造者模式与简单工厂模式、工厂方法模式和抽象工厂模式相对应
Low coupling低耦合
- 尽可能的减少类之间的连接、依赖：
  - 不需要通信的两对象之间不要进行无所谓的连接
  - 如果A已经连接B，分配A的职责给B不合适就把B的职责分配给A
  - 两个不同模块的内部类之间不能建立连接
High cohesion高内聚
- 功能性紧密相关的职责应该放在一个类里，并共同完成有限的功能。
Controller控制器
- MVC分层架构
- 优点：增加了可复用和接口可插拔的能力；获得推测用例状态的机会。
Polumorphism多态
- 一个接口，多个实现。
- 多态模式在多个GoF设计模式中都有所体现，如适配器模式、命令模式、组合模式、观察者模式、策略模式等等。
Pure Fabrication纯虚构
- 将一组高内聚的职责分配给一个虚构的或处理方便的“行为”类，它并不是问题域中的概念，而是虚构的事务，以达到支持高内聚、低耦合和重用的目的。
- 在系统中引入抽象类或接口来提高系统的扩展性也可以认为是纯虚构模式的一种应用。
- 在很多设计模式中都体现了纯虚构模式，例如适配器模式、策略模式等等。
Indirection间接
- 分配职责给中间对象以协调组件或服务之间的操作，使得它们不直接耦合。中间对象就是在其他组件之间建立的中介。
- 在外观模式、代理模式、中介者模式等设计模式中都体现了中介模式
Protected Variations受保护变化
- 找出预计有变化或不稳定的元素，为其创建稳定的“接口”而分配职责。即：对系统进行抽象化设计，定义系统的抽象层，再通过具体类来进行扩展。如果需要扩展系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，在不修改已有代码的基础上扩展系统的功能。
- 大多数设计原则和GoF模式都是受保护变化模式的体现。

领域模型建模

领域模型与设计类图的区别

领域模型，也叫领域类图：产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。
（实现/设计）类图：产生于设计阶段，由系统设计师绘制，其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。

软件分析(OOA)与设计(OOD)是编码前的两个阶段，其中分析仅与业务有关，而与技术无关。设计以分析为基础，主要与具体技术有关。
分析阶段由分析师绘制领域类图，设计阶段由设计师绘制实现类图。
领域类图表示系统的静态领域结构，其中的类可能不与最终程序中的类对应；设计类图表示系统的技术架构，是程序员的编码依据，其中的类与系统中的类对应。
领域类图中类的属性与操作仅关注与业务相关的部分，实现类图中的属性与操作要包括最终需要实现的全部方法与操作。

相同点及不同点：
领域模型与设计类图都是使用UML类图表示。领域模型启发设计类图中的对象及名称。

领域模型是领域中的概念对象及其相互间的关系可视化表示，关注的是业务，而设计类图表示的是系统中软件对象及其的关联，是代码的可视化表示。
领域模型中类没有定义操作，展示领域对象或概念类，概念类之间的关联，概念类的属性。而设计类图需要明确各个类属性及其类型，职责及其参数、返回值。
领域模型中表示类的关系用直线连接，有多重性，没有方向，没有角色名，需要增加关联名明确二者的关系。而设计类图需要明确关联的多重性、方向、角色名，不需要关联名。

DDD(Domain Driven Design)

领域建模:

我们设计一个系统，总是希望它能解决一些问题，这些问题总是会映射到现实问题和概念。
对这些问题进行归纳、分析的过程就是领域建模（这个域，指的就是问题域）。

创建：

寻找概念类
将其绘制为UML类图中的类
添加关联和属性

实例：

GoF23种设计模式

见一下篇

分层架构优点：

好的分层体系结构使系统易于扩展和维护
在各层之间限制消息流动，减少层次耦合，增加移植性
某些层可以分布式实现
利于在中间层实施安全特性