第一周课后练习题
作业一：食堂就餐卡系统设计
系统中每个消费者都有一张卡，在管理中心注册缴费，卡内记着消费者的身份、余额。
使用时将卡插入收款机则显示卡上金额，服务员按收款机上数字键，收款机自动计算并显示消费额及余额。
管理中心的管理员监视每一笔消费，可打印出消费情况的相关统计数据。
请设计系统用例图，组件图，组件时序图，部署图。
系统用例图
组件图
组件时序图
部署图
第一周：学习总结
1.1 招聘JD解读
职位职责
进公司做什么？
编写架构设计文档（week 1）
开发编写框架（week 2）
重构软件代码（week 3）
设计系统架构（week 4）
进行技术选型，解决技术应用中的问题（week 5）
优化系统性能（week 6）
模块分解与微服务架构重构（week 7）
保障系统安全与高可用（week 8）
大数据应用（week 9）
技术创新（week 10）
沟通管理，良好的沟通协调能力，协调各种利益和诉求（week 11）
职位要求
需要什么样的资历，什么样的背景，才能获得这个职位
项目经历是否匹配？技术广度和深度是否匹配公司当前和未来发展
-
关于经验的【HR筛选简历】
学历/学校
工作经验
年龄等客观要求
-
具体的技能能力【专业面试】
应该有什么能力
应该做过什么项目
有没有做过相关的项目
可能遇到的问题
如何做架构设计
无法对关键技术点做出判断
找不到对应的解决方案
对系统性能无法进行评估
业务无法快速扩展
如何在团队中构建技术影响力和领导力？
如何引导团队去按照正确的架构方法去开发？
如何做好架构设计
架构设计包含： 1、业务逻辑设计，开发人员根据技术逻辑来实现 2、系统执行过程和维护设计，用于快速定位系统问题点以及方便运维维护系统 3、物理部署设计，方便运维维护以及定位系统问题点，同时能知道系统的可用性、稳定性是否有足够保障 4、场景设计，更多的是提供给产品、老板等懂业务不太懂技术的人看 5、这些设计有时候会有部分相似或一致，但是给不同的人看会有不同的效果 6、架构设计的目的是清晰业务方向以及未来维护时不至于没接触过系统的人抓瞎
根据技术团队去构建框架
能不能开发框架，基于框架去解决问题
如何判断性能指标
约束系统开发过程
1.2 常见面试题解读
掌握哪些关键技术点？
- 什么是软件架构，如何写一个架构设计文档，文档中应该包含哪些方面内容？
有没有自己的一系列架构方法论？
软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计
架构由8个部分组成：
1、任何一个系统都有一个架构，架构由架构元素、元素间关系组成，元素间的关系有静态和动态两种关系
2、架构的落地应该有一系列的架构文档，开发工程、测试工程师、运维工程师、合作部门、老板等关注点都不一样，所以需要一系列架构文档，需要由架构文档来体现你的架构设计
3、架构文档是由一系列架构视图组成，由哪些视图来描述架构？给相关方看，相关方要有一个统一的认知
4、架构视图要将关注点表达清楚
5、不同的相关方，提供不同的架构视图，提供他们想要的信息
- 子类override 父类的方法后，想要修改跑出的异常，那么子类方法抛出的异常类应该是父类方法抛出异常类的子类还是父类
设计模式：里氏替换原则
- Spring是如何实现单例，和设计模式中的单例实现方式有什么不同
设计模式：单例模式
- 淘宝这样的大规模分布式互联网应用系统使用了哪些技术方案和手段
主要解决什么问题？对于大型互联网应用有没有一个整体的认知
- 什么是CAP原理？请描述某个你熟悉的NoSQL产品是如何解决CAP问题的
一致性、可用性，分区容错性是无法同时满足的，具体产品中是如何去跟CAP相关联？如何做取舍？
如何进行性能测试，性能测试的流程是什么？性能测试的主要指标有哪些？
为什么系统性能测试的时候，随着并发请求数的逐渐增加，错误响应（或者超时响应）的比例快速增加？请从操作系统的线程与进程调度原理以及计算机内部资源使用角度进行分析
为什么支持异步I/O的web服务器（比如Nginx）要比阻塞式的Web服务器（比如Apache）性能好很多，前者要比后者可以处理的并发连接请求多几十倍或者百倍？请从异步I/O的线程阻塞特性进行分析
给定一个Key，为什么可以再Hash表中快速查找到Value？
数据库索引是如何存储的？
Java虚拟机的垃圾回收原理是什么？
性能相关在第六周学习
- 你怎么理解领域驱动设计DDD?
DDD的优缺点是什么？
在微服务相关模块学习
- 导致系统故障无法正常访问的原因有哪些？保障系统稳定高可用的方案有哪些？请列举并简述
高可用相关
如何保护数据库中存储的用户密码，请用时序图表示用户密码加密存储与登录验证的过程
Spark 为什么比MapReduce快？
大数据相关
各自的运行原理
- 淘宝，头条这些应用会针对不同用户推荐不同的商品和内容。他们是如何做到的？用了哪些算法？
大数据相关
推荐引擎如何实现的？
- Google搜索结果页面试如何排序的，正好使用户最想看到的页面排前面？
大数据相关
- 区块链是如何保证数据无法被篡改？
技术创新
- 什么是边缘计算？
技术创新
- 如果你觉得系统需要进行重构，但老板和团队成员都觉得没有必要，你如何说服大家？
沟通是你对事务认知的规律
如何认知问题，发现问题，解决问题
培养自己的主要能力
技术基础是地基，决定技术人员的成长速度和高度
编程能力
基础技术掌握能力：操作系统、数据库、网络、虚拟机、算法、数据结构
常用技术产品的理解与应用能力：分布式消息队列、分布式缓存、分布式数据、Nosql
性能优化与分析故障的能力
常用架构模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
关于软件开发的几个事实
软件技术的进步使得程序员不需要了解技术细节和原理就能开发出能用的软件
让程序员关注更少的事情有助于提高软件开发效率和质量
如何方程序员关注更少的事情？架构师能够为此做些什么？
什么是架构师？
架构师其实是一名超级整合人员，整合技术、产品、老板、客户等等人的思维，然后设计业务模型、监督落地
架构师是做架构设计、对系统架构负责的那个人
架构师是一顶帽子，而不是一把椅子
架构师是一个角色而不是职位
推动架构的落地，让其它工程师写好代码，有效的组织起来
什么都懂，什么都会，但不一定会写代码；关注知识的广度
1.3 4+1视图模型
不同相关方，关注点不一样，需要用不同的视图模型去表达你的架构设计
要去描述我们的架构，不能单一的通过一种架构视图或者是某一个方面的架构视图，就能够完整的呈现我们的架构；而是要通过多维度的进行描述和呈现，4+1视图模型提供一种思路
软件架构
软件架构 = {元素，形式，关系/约束}
单一的视图无法完整的表达架构，因此需要具备完整的视图集
逻辑视图（Logical View）,设计的对象模型
过程视图（Process View），捕捉设计的并发和同步特征
物理视图（Physical View），描述了软件到硬件的映射，反映了部署特性
开发视图（Development View），描述了在开发环境中软件的静态组织结构
场景视图（Scenarios VIew），描述用例场景
逻辑视图
系统有哪些功能模块，有哪些子系统，子系统之间的一些逻辑关系
相关方：客户、用户、开发组织管理者
视角：系统的功能元素、以及它们接口、职责、交互
主要元素：系统、子系统、功能模块、子功能模块、接口
用途：开发组织划分、成本/进度的评估
功能模块图是逻辑视图的一种
过程视图
了解系统运行过程中的情况
相关方：性能优化、开发相关人员
视角：系统运时线程、进程的情况
主要元素：系统进程、线程以及处理队列等
Apache的过程视图
物理视图
最终系统的物理呈现，物理部署是什么样的
-
相关方：系统集成商、系统运维人员
视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置
主要元素：物理节点以及节点的通信
image-20200920164007360.png
物理部署视图
开发视图
与开发相关的元素，以及元素之间的关
主要指导开发过程中，开发工程师如何进行开发，如何实现系统进行落地
相关方：开发相关人员按，测试人员
视角：系统如何开发实现
主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架
-
用途：指导开发组织设计和开发实现
image-20200920163715316.png
类图
场景视图
相关方：用户、设计和开发人员
-
视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式
image-20200920164736805.png
**用例图**
什么是模型？
模型是一个系统的完整抽象，人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在这个模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程就是从领域问题到计算机系统的映射。
- 通过模型进行抽象，业务领域问题抽象出来领域模型
- 解决方案抽象出来一个设计模型，
- 软件架构设计同时要做领域模型设计和系统设计
为什么要建造模型？
我们画架构图、做架构设计，其实就是在建模，建造一个软件的模型，软件还没有代码的时候，系统还没有运行的时候，我们就通过这个模型与大家进行分析和评审，然后看这个模型本身能不能满足我们的业务需求，能不能实现我们的业务目标，能不能解决我们的领域问题，对这个模型的分析和设计对象评审，就能够看到未来的远景是什么样子的，就能够验证我们的系统未来能不能工作
建造传统模型的目的
为了证明某件事物能否工作
前提：建造模型的成本远远低于建造实物的成本
造飞机
造高楼
建造软件模型的目的
为了与它人沟通
为了保存软件设计的最终成果
前提：除非模型比代码更说明问题
何时、何处画图？
何时画图？
讨论、交流时
自己思考时
最终设计文档* 只保留少量的、重要的图
避免涉及过多内容和实现细节
何处画图？白板
绘图工具，如：Visio、Aastah
draw.io
第一周：学习总结
1.1 招聘JD解读
职位职责
进公司做什么？
编写架构设计文档（week 1）
开发编写框架（week 2）
重构软件代码（week 3）
设计系统架构（week 4）
进行技术选型，解决技术应用中的问题（week 5）
优化系统性能（week 6）
模块分解与微服务架构重构（week 7）
保障系统安全与高可用（week 8）
大数据应用（week 9）
技术创新（week 10）
沟通管理，良好的沟通协调能力，协调各种利益和诉求（week 11）
职位要求
需要什么样的资历，什么样的背景，才能获得这个职位
项目经历是否匹配？技术广度和深度是否匹配公司当前和未来发展
-
关于经验的【HR筛选简历】
学历/学校
工作经验
年龄等客观要求
-
具体的技能能力【专业面试】
应该有什么能力
应该做过什么项目
有没有做过相关的项目
可能遇到的问题
如何做架构设计
无法对关键技术点做出判断
找不到对应的解决方案
对系统性能无法进行评估
业务无法快速扩展
如何在团队中构建技术影响力和领导力？
如何引导团队去按照正确的架构方法去开发？
如何做好架构设计
架构设计包含： 1、业务逻辑设计，开发人员根据技术逻辑来实现 2、系统执行过程和维护设计，用于快速定位系统问题点以及方便运维维护系统 3、物理部署设计，方便运维维护以及定位系统问题点，同时能知道系统的可用性、稳定性是否有足够保障 4、场景设计，更多的是提供给产品、老板等懂业务不太懂技术的人看 5、这些设计有时候会有部分相似或一致，但是给不同的人看会有不同的效果 6、架构设计的目的是清晰业务方向以及未来维护时不至于没接触过系统的人抓瞎
根据技术团队去构建框架
能不能开发框架，基于框架去解决问题
如何判断性能指标
约束系统开发过程
1.2 常见面试题解读
掌握哪些关键技术点？
- 什么是软件架构，如何写一个架构设计文档，文档中应该包含哪些方面内容？
有没有自己的一系列架构方法论？
软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计
架构由8个部分组成：
1、任何一个系统都有一个架构，架构由架构元素、元素间关系组成，元素间的关系有静态和动态两种关系
2、架构的落地应该有一系列的架构文档，开发工程、测试工程师、运维工程师、合作部门、老板等关注点都不一样，所以需要一系列架构文档，需要由架构文档来体现你的架构设计
3、架构文档是由一系列架构视图组成，由哪些视图来描述架构？给相关方看，相关方要有一个统一的认知
4、架构视图要将关注点表达清楚
5、不同的相关方，提供不同的架构视图，提供他们想要的信息
- 子类override 父类的方法后，想要修改跑出的异常，那么子类方法抛出的异常类应该是父类方法抛出异常类的子类还是父类
设计模式：里氏替换原则
- Spring是如何实现单例，和设计模式中的单例实现方式有什么不同
设计模式：单例模式
- 淘宝这样的大规模分布式互联网应用系统使用了哪些技术方案和手段
主要解决什么问题？对于大型互联网应用有没有一个整体的认知
- 什么是CAP原理？请描述某个你熟悉的NoSQL产品是如何解决CAP问题的
一致性、可用性，分区容错性是无法同时满足的，具体产品中是如何去跟CAP相关联？如何做取舍？
如何进行性能测试，性能测试的流程是什么？性能测试的主要指标有哪些？
为什么系统性能测试的时候，随着并发请求数的逐渐增加，错误响应（或者超时响应）的比例快速增加？请从操作系统的线程与进程调度原理以及计算机内部资源使用角度进行分析
为什么支持异步I/O的web服务器（比如Nginx）要比阻塞式的Web服务器（比如Apache）性能好很多，前者要比后者可以处理的并发连接请求多几十倍或者百倍？请从异步I/O的线程阻塞特性进行分析
给定一个Key，为什么可以再Hash表中快速查找到Value？
数据库索引是如何存储的？
Java虚拟机的垃圾回收原理是什么？
性能相关在第六周学习
- 你怎么理解领域驱动设计DDD?
DDD的优缺点是什么？
在微服务相关模块学习
- 导致系统故障无法正常访问的原因有哪些？保障系统稳定高可用的方案有哪些？请列举并简述
高可用相关
如何保护数据库中存储的用户密码，请用时序图表示用户密码加密存储与登录验证的过程
Spark 为什么比MapReduce快？
大数据相关
各自的运行原理
- 淘宝，头条这些应用会针对不同用户推荐不同的商品和内容。他们是如何做到的？用了哪些算法？
大数据相关
推荐引擎如何实现的？
- Google搜索结果页面试如何排序的，正好使用户最想看到的页面排前面？
大数据相关
- 区块链是如何保证数据无法被篡改？
技术创新
- 什么是边缘计算？
技术创新
- 如果你觉得系统需要进行重构，但老板和团队成员都觉得没有必要，你如何说服大家？
沟通是你对事务认知的规律
如何认知问题，发现问题，解决问题
培养自己的主要能力
技术基础是地基，决定技术人员的成长速度和高度
编程能力
基础技术掌握能力：操作系统、数据库、网络、虚拟机、算法、数据结构
常用技术产品的理解与应用能力：分布式消息队列、分布式缓存、分布式数据、Nosql
性能优化与分析故障的能力
常用架构模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
关于软件开发的几个事实
软件技术的进步使得程序员不需要了解技术细节和原理就能开发出能用的软件
让程序员关注更少的事情有助于提高软件开发效率和质量
如何方程序员关注更少的事情？架构师能够为此做些什么？
什么是架构师？
架构师其实是一名超级整合人员，整合技术、产品、老板、客户等等人的思维，然后设计业务模型、监督落地
架构师是做架构设计、对系统架构负责的那个人
架构师是一顶帽子，而不是一把椅子
架构师是一个角色而不是职位
推动架构的落地，让其它工程师写好代码，有效的组织起来
什么都懂，什么都会，但不一定会写代码；关注知识的广度
1.3 4+1视图模型
不同相关方，关注点不一样，需要用不同的视图模型去表达你的架构设计
要去描述我们的架构，不能单一的通过一种架构视图或者是某一个方面的架构视图，就能够完整的呈现我们的架构；而是要通过多维度的进行描述和呈现，4+1视图模型提供一种思路
软件架构
软件架构 = {元素，形式，关系/约束}
单一的视图无法完整的表达架构，因此需要具备完整的视图集
逻辑视图（Logical View）,设计的对象模型
过程视图（Process View），捕捉设计的并发和同步特征
物理视图（Physical View），描述了软件到硬件的映射，反映了部署特性
开发视图（Development View），描述了在开发环境中软件的静态组织结构
场景视图（Scenarios VIew），描述用例场景
逻辑视图
系统有哪些功能模块，有哪些子系统，子系统之间的一些逻辑关系
相关方：客户、用户、开发组织管理者
视角：系统的功能元素、以及它们接口、职责、交互
主要元素：系统、子系统、功能模块、子功能模块、接口
用途：开发组织划分、成本/进度的评估
功能模块图是逻辑视图的一种
过程视图
了解系统运行过程中的情况
相关方：性能优化、开发相关人员
视角：系统运时线程、进程的情况
主要元素：系统进程、线程以及处理队列等
**Apache的过程视图**
## 物理视图
> 最终系统的物理呈现，物理部署是什么样的
* 相关方：系统集成商、系统运维人员
* 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置
* 主要元素：物理节点以及节点的通信
**物理部署视图**
## 开发视图
> 与开发相关的元素，以及元素之间的关系
>
> 主要指导开发过程中，开发工程师如何进行开发，如何实现系统进行落地
* 相关方：开发相关人员按，测试人员
* 视角：系统如何开发实现
* 主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架
* 用途：指导开发组织设计和开发实现
**类图**
场景视图
相关方：用户、设计和开发人员
-
视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式
 **用例图**
什么是模型？
模型是一个系统的完整抽象，人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在这个模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程就是从领域问题到计算机系统的映射。
通过模型进行抽象，业务领域问题抽象出来领域模型
解决方案抽象出来一个设计模型，
软件架构设计同时要做领域模型设计和系统设计
为什么要建造模型？
我们画架构图、做架构设计，其实就是在建模，建造一个软件的模型，软件还没有代码的时候，系统还没有运行的时候，我们就通过这个模型与大家进行分析和评审，然后看这个模型本身能不能满足我们的业务需求，能不能实现我们的业务目标，能不能解决我们的领域问题，对这个模型的分析和设计对象评审，就能够看到未来的远景是什么样子的，就能够验证我们的系统未来能不能工作
建造传统模型的目的
为了证明某件事物能否工作
前提：建造模型的成本远远低于建造实物的成本
造飞机
造高楼
建造软件模型的目的
为了与它人沟通
为了保存软件设计的最终成果
前提：除非模型比代码更说明问题
何时、何处画图？
何时画图？
讨论、交流时
自己思考时
最终设计文档
只保留少量的、重要的图
避免涉及过多内容和实现细节
何处画图？
白板
绘图工具，如：Visio、Aastah
draw.io
1.4 UML：软件架构建模的一般方法和工具
建模、画图、写设计文档
什么样的阶段，画什么样的图，表达什么样的意图
简介
ＵＭＬ的目标和价值是表达设计意图，规范不规范不重要
通过UML来做模型建设
什么是UML？
- Unified Modeling Language，或统一建模语言
- 以图形方式描述软件的概念
UML可用来描述
- 某个问题领域
- 构思中的软件设计
- 描述已经完成的软件实现
分类-静态图
通过描述类、对象和数据结构以及他们之间存在的关系，来描述软件要素中不变的逻辑结构
用例图（User case Diagrams）
对象图（Object Diagrams）
类图（Class Diagrams）
组件图（Component Diagrams）
包图（Package Diagrams）
部署图（Deployment Diagrams）
分类-动态图
通过描绘执行流程或者实体状态变化的方式，来展示软件实体正在执行过程中的变化过程
- 协作图（Collaboration Diagrams）
- 序列图（Sequence Diagrams）【时序图】
- 活动图（Activity Diagrams）
- 状态图（State DIagrams）
常用UML图
类图、用例图、组件图、部署图、时序图、活动图、状态图
通用模型元素
可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等
注释可以针对所有元素
模型元素与模型元素纸质件的连接关系也是模型元素，常见的关系有关联（association）、泛华（generalization）、依赖（dependency）和聚合（aggregation）。这些关系图示符号如图所示。
- 关联：连接（connect）模型元素及链接（link）实例
- 依赖：表示一个元素以某种方式依赖于另一种元
依赖和关联都是表达两个元素、两个对象之间的关系，关联关系紧密一点，依赖关系相对来说松散一点
；一个对象的成员变量是关联关系，成员方法内的局部变量依赖于另外一个对象，那么就是依赖关系
- 泛化：表示一般与特殊的关系，即："一般"元素是"特殊"关系的泛化
- 聚合：表示整体与部分的关系，一个成员变量是由其他两个对象聚合而成，当成员变量不存在时，其它两个对象依然是独立存在的，如：车和轮胎的关系
- 组合：当组合起来的对象不存在时，那么它的各个组成部分也是不存在的，如：人个胳膊的关系
- 继承与实现
继承我们一般说继承了一个父类，父类有自己的方法和成员变量；实现通常实现的是一个接口，接口只有方法的描述，而没有方法的实
用例建模[用例图]
用例建模技术，用于描述系统的功能需求，在宏观上给出模型的总体轮廓，通过对典型用例的分析，使开发者能够有效地了解用户的需求
用例图有自己的边界，用例的集合
用例之间可以扩展
用例之间可以使用，一个用例使用另外一个用例
用例图是在需求分析阶段的主要模型视图
用例的关键角色
执行者
用例总是由执行者启动的
执行者是指用户在系统中所扮演的角色，执行者在用例图中是用类似人的图形来表示，但执行者可以是人，也可以使一个外界系统
如何确定执行者
1、谁使用系统的主要功能（主执行者）
2、谁需要从系统获得对日常工作的支持和服务
3、需要谁维护管理系统的日常运行（副执行者）
4、系统需要控制那些硬件设备
5、系统需要与其它那些系统交互
6、谁需要使用系统产生的结果（值）
类与对象[类图、对象图]
面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础，UML中的类图（Class Diagram ）与对象图（Object Diagram） 表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型
类图一般产生与详细设计阶段，开发人员按照类图开发，一定是符合架构师的设计的
包图
包图和组件图差不多，一般采用组件图
一个最古老的软件方法问题是：怎样将大系统拆分成小系统。解决该问题的思路之一是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包（Package）。引入包是为了降低系统的复杂性。
动态建模
动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为了满足用例要求所进行的活动以及活动间的约束关系。
在动态模型中，对象间的交互是通过对象间消息的传递来完成的，对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。
动态模型
动态模型主要描述系统的动态行为和控制结构
包括四类图：状态图、活动图、时序图、合作图
状态图：状态用来描述对象、子系统、系统的生命周期
活动图：着重描述操作实现中完成的工作以及用例实例或者对象中的活动，活动图是一个状态图的一个变种
时序图：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为
合作图：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系
UML中的消息
简单消息（simple）
表示控制流，描述控制如何从一个对象传递到另外一个对象，但不描述通信的细节。
简单消息是包含同步消息和异步消息的
同步消息（synchronious）
- 是一种嵌套的控制流，用操作调用实。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。
异步消息（asynchronous）
- 是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理
时序图
用来描述对象之间动态的交互行为，着重体现对象间的消息传递的时间顺序
时序图存在两个轴
水平轴表示一组对象
垂直轴表示时间
时序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。
对象间的通信通过在对象的生命线之间消息来表示，消息的箭头类型指明消息的类型。
对象是广义的，可以是类的对象，也可以是一个组件，也可以是一个子系统，也可以是一个服务器
时序图可以描述不同维度，系统之间的对象之间的交互
可以是对象时序图、组件时序图、系统时序图等
子系统、组件图可能存在异步消息
适用于需求分析、概要设计、详细设计三个阶段
需求分析：可以用时序图描述系统之间的关系，依赖关系是什么样？调用关系是什么样？这些消息可能是同步的，也可以时异步的
概要设计：服务器与子系统之间的调用关系，调用关系是什么样？组件之间的调用和时序关系
详细设计：主要描述类之间、对象之间的调用关系
活动图
UML中没有流程图，想要表达一些流程时可用活动图
活动图的应用非常广泛。它即可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行的过程
活动图描述了系统中各种活动的执顺序，刻化一个方法中所要进行的各项活动的执行流程
活动图中的一个活动结束后将立即进入下一个活动（状态图中的状态的变迁可能需要事件的出发）
泳道图
泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方法，描述擦爱去何种动作，做什么（对象状态改变）,何时发生（动作序列），以及在何处发生（泳道）
泳道也是一种分组机制
在一个业务处理时，可能跨越多个领域时，可以泳道图描述由哪些领域协作共同完成
状态图
用来描述状态的变迁
合作图
没有时序的时序图
通过时序图生成合作图
合作图，也成为协作图，用于描述相互合作的对象间的交互关系和连接（Link）关系。虽然顺序图和合作图都用来描述对象间的交互关系，但侧重点不一。顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态连接
组件图[componet]
组件定义：系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时它是一个重要的构造块
组件可以看着包与类对应的物理代码模块，逻辑上与包、类对应，实际上是一个文件，可以有下列几种类型的构件：
源代码构件
二进制构件
可执行构件
组件之间的依赖关系是指结构之间在编译、连接、执行时的依赖关系。用虚线箭头表示组件图符：