作业二：根据当周学习情况，完成一篇学习总结

架构师基本功（设计）.md

架构师主要能力

1.          编程能力

2.          基础技术掌握能力（操作系统、软件工程、数据结构....）

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

4.          性能优化与分析故障的能力

5.          常用架构模式和框架的理解与应用能力

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

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

8.          快速学习能力

9.          沟通与领导能力

架构设计开始前的准备

1.          相关方是谁，这点是重中之重，搞不清楚相关方是谁，你的设计就完全没有意义。相关方是指，你的设计是给谁看的。例如，叫架构师（你）开个会，说两周之内要出某某的架构设计（或方案），这时候，就要首先关注你的设计是给谁看，这个“谁”的关注重点在哪

1.          给领导看的，那你的设计可能就偏于PPT的表现形式，或者逻辑视图类的，偏于功能或者整体视角的设计方案，说明优缺点，说明对比优势等等。不要拖泥带水，不要过份关注技术细节。后面会举例子

2.          给同级别架构师看的，这时候的关注重点是你们要讨论哪一个层次的图，架构设计图示是分层的，每一层是上层内容的细化和分解，这时就要确定，你要和这个架构师或这群架构师讨论的是哪一个层级的。至于表现形式，直接UML图，外加标注就可以讨论了。

3.          给外部厂家的宣传类，这种PPT里面一般会有一些逻辑视图类方案设计图，在结合一些软件操作图及技术细节差异的图示，但往往不会暴露技术实现方式。在设计这种方案时，美观度和优势说明是重点

4.          给工程师（研发）人员看的，这个视图的层次就要相对细化，需要可以落地，工程师看完你这个设计方案，就可以直接进行开发，这时候类图，状态图，时序图等直接说明细节的图示会更合适一些。

2.          架构元素之元素之间的关系

1.          上一阶段确定的读者是谁，同时也确定的这个（些）读者关注的是哪一个层次的设计。到这个阶段就要考虑，这个层次里面，要说明的架构元素有哪些，这个元素是如何交互的。

2.          同时也己确定具体的架构视图及表现形式了（架构文档）

软件架构设计基础知识

软件架构

 是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计

架构师

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

 架构师是一顶帽子，而不是一把椅子（意思是说，不是屁股决定的，是脑袋决定的）；

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

4+1 视图模型

 软件架构 = {元素、形式、关系/约束}

 单一的视图无法完整的表达架构，因此需要具备完整的视图集

1.          逻辑视图（Logical View），设计的对象模型

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

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

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

5.          场景视图（scenarios），描述用例场景





逻辑视图

 相关方：客户、用户、开发组织管理者

 视角：系统的功能元素，以及它们接口，职责，交互

 主要元素：系统，子系统，功能模块，子功能模块，接口

 用途：开发组织划分，成本/进度的评估



开发视图

 相关方：开发相关人员，测试人员

 视角：系统如何开发实现

 主要元素：描述系统的分层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架

 用途：指导开发组织设计和开发实现

物理视图

 相关者：系统集成商，系统运维人员

 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

 主要元素：物理节点以及节点的通信



过程视图

 相关者：性能优化，开发相关人员

 视角：系统运行时线程，进程的情况

 主要元素：系统进程，线程以及处理队列等

场景视图

 相关者：用户，设计和开发人员

 视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。



UML 建模

模型的概念

 模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴含在模型中

 通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射



UML 基础概念

 Unified Modeling Language，统一建模语言

 以图形方式描述软件的概念

UML 图的分类

UML 静态图：用于描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构

 用例图（Use Case Diagrams）

 部署图（Deployment Diagrams）

 组件图（Component Diagrams）

 类图（Class Diagrams）

 对象图（Object Deagrams） 不常用

 包图（Package Diagrams） 不常用

UML 动态图：通过描述执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程

 动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系

 在动态模型中，对象间的交互是通过对象间消息的传递来完成的。对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态

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

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

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

 协作图（Collaboration Diagrams） 不常用

UML 画图软件

 Visio、ProcessOn、draw.io

通用模型元素



通用模型元素之间的关系



 关联关系：类的成员变量

 依赖关系：方法内的变量依赖、模块之间的依赖

 继承关系：父子关系

 实现关系：接口实现

 聚合关系：生命周期独立，车轮与车

 组合关系：生命周期是全局，组件不独立存在

图示说明

用例建模

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



 用例模型描述的是外部执行者（Actor）所理解的系统功能。它描述了待开发系统的功能需求。

 它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型

 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中，构成用例图的主要元素是用例和执行者及其它们之间的联系

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

* 用例图也是分层的，可以对每一个用例在进行细化。并非每一个用例都需要画图，而是重要的用例或者需要单独说明的用例，才需要进行用例绘制。如果用例比重要，则可以进行第二层的分解 *

* Use Case 是自顶向下逐渐细化的过程，可以抽象出不同层次的 Use Case 图 *

* 部署图 => 组件图 => 类图 => 时序图 *

Actor（执行者）

 是指用户在系统中所扮演的角色，可以是系统，也可以是人。

 用例总是由执行者启动的

 执行者的确认：

1.          谁使用系统的主要功能（主执行者）

2.          谁需要从系统获得对日常工作的支持和服务

3.          需要谁维护管理系统的日常运行（副执行者）

4.          系统需要控制哪些硬件设备

5.          系统需要与其它哪些系统交互

6.          谁需要使用系统产生的结果（值）

类图



UML 中的消息

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

 同步消息（synchronous）：是一种嵌套的控制流，用操作调用实现。操作的灵执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。方法调用，类之间调用都是同步消息

 异步消息（asynchronous）：是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。系统之间调用，服务器之间多为异步消息

时序图

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



活动图（与流程图功能类似）

 既可以用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程。

 活动图描述了系统中各种活动的执行的顺序。刻化一个方法中所要进行的各项活动的执行流程。

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

活动

 是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移

 活动的解释依赖于作图的目的和抽象层次，在概念层描述中，活动表示要完成的一些任务；在说明层和实现层中，活动表示类的方法

 活动图用圆角框表示，标注活动名

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



转移

 转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初态、终态、判断、同步线）。

 转移用带箭头的直线表示，可标注执行转移的条件，无标注表示顺序执行。

泳道

 泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）

 泳道也是一种分组机制



对象流

 活动图中可以出现对象，对象作为活动的输入/输出，用虚箭头表示



控制图符

 活动图中可发送和接收信号，发送符号对应于与转移联系在一起的发送短句。接收符号也同转移联系在一起

状态图

 状态图，用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移

状态

 所以对象都具有状态，状态是对象执行了一系列活动的结果。当某个事件发生后，对象的状态将发生变化。状态图中定义的状态有：

 初态 - 状态图的起始点，一个状态图只能有一个初态

 终态 - 是状态图的终点，而终态则可以有多个

 中间状态 - 可包括三个区域：名字域、状态变量与活动域

 复合状态 - 可以进一步细化的状态称作复合状态

实现模型

 实现模型描述了系统实现时的一些特性，又称为物理体系结构建模。包括源代码的静态结构和运行时刻的实现结构

实现模型包括：

 组件图：显示代码本身的逻辑结构，它描述系统中存在的软构件以及它们这间的依赖关系

 部署图：描述了系统中硬件和软件的物理配置情况和系统体系结构。显示系统运行时刻的结构，部署图中的简单结点是指实际的物理设备以及在该结点上运行构件或对象。部署图还描述结点之间的连接以及通信类型。

组件图

 组件定义：系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。

 组件可以看作包与类对应的物理代码模块，逻辑上与包，类对应。实际上是一个文件，可以有下列几种类型的构件：源代码构件、二进制构件、可执行构件



部署图

 用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。部署图可以显示计算机结点的拓扑结构和通信路径，结点上执行的组件，特别是分布式系统，部署图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种构件和对象的配置。因此，部署图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，部署图的元素有结点和连接。



补充

软件设计三个阶段：需求分析、概要设计、详细设计

需求分析：用例图、活动图、系统级状态图、系统级时序图

概要设计：部署图、组件图、组件时序图、活动图（说明流程）

详细设计：类图、类的时序图、状态图、方法级活动图

C4 Model

C4 模型由一系列分层的软件架构图组成，这些架构图用于描述上下文、容器、组件和代码。C4 图的层次结构提供了不同的抽象级别，每种抽象级别都与不同的受众有关。