极客大学 -- 架构师训练营 1 期 - 第一周总结（vaik）

关注
发布于: 2020 年 09 月 20 日
本周概要本周讲述的是关于架构，架构师，架构设计的一些根本概念，从架构师的JD和实际工作中架构师面临的问题出发，讲解了架构师的基本职能职责，专业技术和个人能力素养，输出内容要求。介绍了训练营的课程体系，从课程大纲上可以看出完全是根据架构师的主要职责要点来对应每周课程内容。接下来重点是关于架构师的核心输出--架构设计文档的方法、工具，从4+1视图模型，到使用UML抽象建模，最后如何写架构设计文档。
基本概念什么是软件架构软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统的各个方面的设计。
我的理解：软件架构是为满足当下及未来一定时间的业务需求及人力，效率等的增长，对软件整体系统的规划和设计，从系统功能边界、业务流程，角色职能、开发规范与约束，性能指标等方面，对各相关方匹配的维度视图进行指导和沟通。
﻿
什么是架构师架构师是做架构设计、对系统架构负责的那个人。
架构师是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。
我的理解：
架构师是团队的技术领路人，架构师设计的架构应该是不断演进优化和创新的，架构师应该保证软件系统稳定可靠高性能的前提下，不断追求技术创新，为系统产品为企业带来持续的技术竞争力。
架构师的职责编写架构设计文档
开发编程框架
重构软件代码
设计系统架构
进行技术选型，解决技术应用中的问题
优化系统性能
模块分解与微服务架构重构
保障系统安全与高可用
大数据应用
技术创新
沟通管理
我的补充：
营造团队技术文化氛围，提升团队整体技术素养
提升技术影响力和领导力
架构师主要能力编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化和分析故障的能力
常用架构模式与框架的理解与应用能力
建模以及设计文档的方法与能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
4+1视图模型软件架构 =（元素，形式，关系/约束）
单一的视图无法完整的表达架构，因此需要具备完整的视图集
逻辑视图相关方：客户，用户，开发组织管理者。
视角：系统的功能元素，以及它们的接口，职责，交互。
主要元素：系统，子系统，功能模块，子功能模块，接口。
用途：开发组织划分，成本/进度评估。
我的思考：
逻辑视图中的逻辑指的是什么，我理解指整体组成结构（系统，子系统，功能模块，子模块）和组成元素间的关系（接口，交互），这里的逻辑是相对物理的一种抽象。
开发视图相关者：开发相关人员，测试人员。
视角：系统如何开发实现。
主要元素：描述系统的层，分区，包，框架，系统能用服务，业务能用服务，类和接口，系统平台和相关基础框架。
我的理解：
数据库设计，主要实现算法，业务流程图，数据流向这些也属于开发视图的元素，可能具体的设计细节实现不是架构师本人，架构师应该主导和规范这些的设计
物理视图相关者：系统集成商、系统运维人员。
视角：系统逻辑组件到物理节点的物理部署和节点这间的物理网络配置。
主要元素：物理节点及节点的通信。
我的思考和问题：
作为架构师，肯定不是自己直接进行运维工作，运维对于系统的稳定性可靠性及高性能都至关重要，架构师需要在运维这个领域，需要达到什么样的程度，或者说掌握哪些基本的运维技能，或者说如何更好帮助指导运维人员高效的解决问题？
过程视图相关者：系统性能、开关相关人员。
视角：系统运行时线程、进程的情况。
主要元素：系统进程，线程以及队列处理。
我的问题：
某个业务实体在不同场景下的各种状态，比如订单的状态，是否属于过程视图？
场景视图相关者：用户、设计和开发人员
视角：概括了架构上最重要的场景（最典型或最有风险的场景）及非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素的运行方式。
小结实践的开发中，并不是按照4+1视图模块来做架构设计的，它主要提供一个维度方面的启发。实践中，更多的使用UML建模来进行架构设计。
UML建模什么是模型模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴含在模型当中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，是从领域问题到计算机系统的映射。
﻿
我的理解：
模型抽象是架构设计至关重要的环节，是架构师最最核心的能力，直接决定整个架构的优劣，智慧老师提到的把握系统的关键点和关键关系在这里就显得特别重要，那么如何把握关键点和关键关系，我觉得这要在系统需求上面下足功夫了，相关的行情知识，影响因素，数据指标，类似案例，竞品分析都需要足够了解，邀请有专业背影的各方参与评审，提出意见。
什么是UMLUnified Modeling Language,或统一建模语言
以图形方式描述软件的概念
uml可用来描述
某个问题领域
构思中的软件设计
描述已经完成的软件实现
UML图的分类-静态图描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构。
用例图（Use Case Diagrams)
对象图（Object Diagrams)
类图（Class Diagrams)
组件图（Component Diagrams)
包图（Package Diagrams)
部署图（Deployment Diagrams)
UML图的分类-动态图通过描绘执行流程或者实体状态变化的方式,来展示软件执行过程中的动态变化。
协作图（Collaboration Diagrams）
序列图（Sequence Diagrams）
活动图（Activity Diagrams）
状态图（State Diagrams）
通用模型元素类、对象、结点、包、组件、用例、状态、注释 
关联：连接（connect）模型元素及链接(link)实例。
依赖：表示一个元素以某种方式依赖另一个元素。
泛化：表示一般与特殊的关系，即“一般”元素是“特殊地”关系的泛化。
聚合：表示整体与部分的关系
用例建模和用例图用例建模用于描述系统的功能需求。在宏观上给出模型的整体轮廓。通过对典型用例的分析，有效的了解用户的需求
用例模型由若干个用例图构成，用例图用来描述执行者与用例之间的关系。
创建用例模型的工作包括：定义系统，确定执行者和用命，描述用例，定义用例间的关系，确认模型
执行者（Actor)
指用户在系统中所扮演的角色，可以是人也可以是外界系统
用例总是由执行者启动的
用例图可以自顶而下不断精化，抽象出不同层次的用例图。
﻿
我的思考:
用例图体现的是执行者的功能需求，以及用例之间的关系，在实际开发工作中，一般是在需求阶段的产物，直观的体现了各种需求，可以是产品经理也可以是架构师来完成用例图，从而确定整个系统的功能边界，为后续的概要设计和详细设计以及测试用例提供基础参照，需要分层自顶而下来构建用例图，从而对整体系统有更清晰的层次认知。
静态建模指对象之间以属性互相关联，这种关系不会随时间而变化。
类和对象的建模，是UML建模的基础，静态建模主要包括用例图、类图、对象图、组件图、包图、部署图
类和对象图面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础。UML中的类图与对象图表达了对象模型的静态结构，能够有效的建立专业领域的计算机系统对象模型。
我的扩展：
对象是类的实例，所以对象图描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以看作是类图在某一时刻的实例。以下网上参考的类图与对象图的区别
动态建模动态模型主要描述系统的动态行为和控制结构
动态模型包括状态图、活动图、时序图、合作图
动态模型中，对象间的交互是通过对象间消息的传递来完成的。
UML中的消息分为简单消息（simple),同步消息（synchronous），异步消息（asynchronous）
时序图描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序
活动图描述操作（类的方法）的行为，也可描述用例和对象内部的工作过程，并可用于表示并行过程。
活动图描述系统中各种活动的执行的顺序，或刻化一个方法中所要进行的各项活动的执行流程。
活动图中的一个活动结束将立即进入下一个活动
构成活动图的模型元素有：活动、转移、对象、信号、泳道等
活动还有其他的图符：初态、终态、判断、同步。
状态图描述一个特定对象的所有可能状态及其引起状态转移的事件，一个状态图包括一系列状态以及状态之间的转 移
状态分：初态、终态、中间状态、复合状态。
组件图系统中遵从一组接口且提供的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。
常用的构件有：源代码构件、二进制构件、可执行构件
部署图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时间的结构
包图、协作图包图的主要目的是为了解决如何将大系统拆分成小系统，从而形成高内聚、低耦合的集合，同时也降低了系统的复杂性
协作图又称合作图，用于描述相互全合的对象间的交互关系和链接（Link)关系。重点体现交互对象间的静态链接关系
﻿
我的计划：
UML这一块整体学下来，我感觉自己都懂一样，但实际深入到细节，每种图在实际使用时，又发现概念不是很清晰，所以决定用心读一下根据智慧老师的推荐书《UML精粹》
架构设计文档架构设计文档一般分，概要设计，详细设计。
基本模板格式：
设计概述：系统简介，解决的问题和目标任务
功能概述：主要功能包括...，系统使用者包括...
非功能约束：
查询性能目标
下单性能目标
...性能目标
系统核心功能可用性目标
系统安全性目标
数据持久化目标
系统部署图和整体设计
部署图：图+简单说明
相关子系统简介
相关子系统设计
子系统组件图
组件序列图
核心组件设计
组件类图
类序列图
对象状态图
没有设计文档就没有软件设计
没有软件设计就没有技术进步
﻿
我的思考：
架构设计文档是架构师的核心作品，好的架构设计就是一种艺术创业，相当于诗人笔下的诗，文人笔下的文章，值得我们反复推敲，不断打磨，匠心创造，技术人一辈子地追求。