第一周：课程笔记及总结

一、课程总览

1、什么是架构师？



• 架构师是做架构设计，对系统架构负责的那个人；

• 架构师是一顶帽子，而不是一把椅子；

• 架构师是一个角色而不是一个职位；

• 架构师在信息系统研发中，负责依据需求来确定主要的技术选择、设计系统的主体框架结构，并负责搭建实施的人，参与系统的主体架构和实现方向，并负责指导软件工程师等开发人员的编码开发工作



2、架构师的主要职责：



• 编写架构设计文档

• 开发编程框架

• 重构软件代码

• 设计系统架构

• 技术选型，解决技术应用中的问题

• 优化系统性能

• 模块分解与微服务架构重构

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 沟通管理



3、架构师的主要能力：



• 编程能力

• 基础技术掌握能力

• 常用技术产品的理解与应用能力

• 性能优化与分析故障的能力

• 常用架构模式和框架的理解应用能力

• 建模以及设计文档的方法和能力

• 业务理解与功能模块及非功能模块拆解能力

• 快速学习能力

• 沟通与领导能力



4、如何训练提高自己：



• 即使还不是一名架构师，工作中也需主动参与架构设计，储备架构知识，训练架构方法、架构模式、关键知识点；积极主动就已经成功了一大半。

• 一定要多实践，一定要关注场景，架构不仅需多学习积累理论知识，还要多练习，多实践。

• 通过训练营中的技术例子多训练，练就架构思维，构建知识体系；

• 通过例子，总结模式，通过模式，构建知识体系；



二、架构建模基础



1、4+1视图模型

概念：软件架构={元素、形式、关系、约束}，单一的视图无法完整的表达架构，因此需要具备完整的视图集。



逻辑视图（Logical View）：设计的对象模型

过程视图（Process View）：捕捉设计的并发和同步特征

物理视图（Physical View）：描述了软件到硬件的映射，反映了部署特征

开发视图（Development View）：描述了在开发环境中软件的静态组织结构

场景视图（scenarios）：描述用例场景



通过4+1视图模型就应形成一种思维，不能通过一种视图来呈现架构的所有部分，因为每一种视图关注的面是不相同的，所需要表达的信息也不相同。因此不同的相关者关注的视图不同，就需要架构根据不同的场景不同的需求来选择设计不同的视图模型。

一个系统多个方面，每个相关者关注的点不一样，则需要架构师根据不同场景来判断使用哪个建模。4+1建模与UML建模可以一一对应，架构师较常用的建模语言还是UML建模。



2、软件建模语言-UML

模型的定义：

模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对他们的理解和认识都蕴含在模型中。通常，开发一个计算机系统是为了解决某个领域特定的问题，问题的求解过程，就是从领域问题到计算机系统的映射；



建模的目的

为了便于沟通理解

为了评估方案及设计的可行性

为了保存软件设计的最终成果



建模工具

visio，plantuml，startuml

processon.com，draw.io



UML简介

统一建模语言（Unified Modeling Language）,用图形的方式描述软件的概念，包括如下：

某个问题领域

构思中的软件设计

描述已经完成的软件实现



UML图的分类-静态图

任何建模语言都已静态建模机制为基础，标准建模语言UML也不例外，所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。类与对象的建模是UML建模的基础。

通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构。

用例图（Use Case Diagrams）：

对象图（Object Diagrams）：

类图（Class Diagrams）：

组件图（Component Diagrams）：

包图（Package Diagrams）：

部署图（Deployment Diagrams）：



UML图的分类-动态图

通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程。

合作图（Collaboration Diagrams）：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。合作图一般相当于没有序列的时序图，故很少用到。

时序图（Sequence Diagrams）：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。

活动图（Activity Diagrams）：着重描述操作实现中完成的工作以及用例实例或者对象中的活动，活动图是状态图的一个变种。

状态图（State Diagrams）：状态图用来描述对象，子系统，系统的生命周期。



动态图之间通过消息来传递，UML中的消息如下：

简单消息：表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。

同步消息：是一种嵌套的控制流，用于操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。

异步消息：是一种异步的控制流，消息的发送者在消息发送后继续执行，不等待消息的处理。

通用模型元素

可以在图中使用的概念统称为模型元素。常用元素符号：类、对象、结点、包和组件等。



通用模型元素-元素间关系

模型元素与模型元素之间的连接关系也是模型元素。

关联：连接模型元素及链接实例

依赖：表示一个元素以某种方式依赖于另一种元素

泛化：表示一般与特殊的关系，即一般元素是特殊关系的泛化

聚合：表示整体与部分的关系，聚合与组合的区分可以用生命周期来区别。

组合而成的东西，当整体灭亡，个体生命周期也结束。

聚合而成的事物，当整体生命周期结束，个体生命周期依然存在。





三、UML建模实例

1、用例图：

用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能有效地了解用户的需求。

用例图描述了系统的功能需求，它是从执行者的角度来理解系统，用于捕获系统的需求，规划和控制项目；

用例图主要描述执行者和用例之间的关系，在UML中构成用例图的主要元素是用例和执行者及他们之间的关系。

创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确定模型。





2、类和对象图：

对象是对客观事物的抽象，但是类是对对象的抽象，类是一种抽象的数据结构，它们的关系是，对象是类的实例，类是对象的模板。他们的元素如下：







3、组件图：

系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。虽然很不理解啊，还是写上了。。。

通俗点组件可以看做包与类对应的物理代码模块，逻辑上与包，类对应，实际上是一个文件，也就是很多包，类一同组成了一个整体组件，比如一个java中的jar包。

组件之间的依赖关系是指结构之间在编译，连接或执行时的依赖关系。用虚线箭头表示组件图符。





4、包图：

UML中将大系统拆分成小系统思路之一就是将许多类集合成一个更高层次的单位，形成一个高内聚，低耦合的类的集合。这种解决方法就是包。



5、部署图：

用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件。部署图可以显示计算机结点的拓扑结构和通信路径，结点上执行的组件。

部署图是描述任务基于计算机应用系统的物理配置或逻辑配置的有力工具，部署图的元素有结点和连接。

结点：代表某种计算机或者硬件。同时结点里面还会包含在上面运行的软件组件，软件组件代表可执行的物理代码模块。







6、时序图

用来描述对象之间动态的交互行为，着重体系对象间消息传递的时间顺序。

时序图存在两个轴，水平轴表示对象，垂直轴表示时间。



7、活动图

活动图描述了系统中各种活动的执行顺序，它既可用来描述操作（类的方法）的行为， 也可以描述用例和对象内部的工作过程，并可用户表示并行过程。

构成活动图的模型元素有：活动、转移、对象、信号、泳道等。















8、状态图

状态图用来描述一个特定对象的所有可能的状态及其引起状态转移的事件，一个状态图包括一系列的状态以及状态之间的转移。一般用户需求分析，详细设计阶段。





9、合作图

合作图用于描述相互合作的对象间的交互关系和链接关系，合作图可以认为一种无序的时序图，合作图与时序图侧重点不一样，时序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系。





四、所思所想

感觉自己的知识太零散，没有形成一个知识体系，总感觉这个也懂，那个也懂，但是真正深究却发现其实都还不懂；比如对UML建模，以前也看了很多这方面的文章，也画了很多架构图，但是都不成体系，感觉就是为了画图而画图，而没搞明白其中真正的目的与价值，通过本次基础课的学习，对架构师有了一个新的认识，作为一名合格的系统架构师就应该在还未开发之前在脑海中对整个系统有一个整体的抽象，系统有哪些类，有哪些模块，需要哪些服务器，他们之间的关系等等。脑海中有了这些抽象后才会根据不同的场景利用UML等建模工具，呈现不同的模型图，可能这就是胸有成竹的样子。只有深思熟虑后，零散的知识才会更容易形成体系，为我所用。