学习笔记: 架构师训练营 - 第一周

 关注
发布于: 2020 年 10 月 04 日
1、4+1架构视图﻿
软件架构 = {元素，形式，关系/约束}
逻辑视图（Logical view）, 设计的对象模型。
过程视图（Process View），捕捉设计的并发与同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了部署特效。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
场景视图（Scenarios，Use-Case View），描述用例场景。
1.1 逻辑视图：设计满足功能需求的架构相关方: 客户、用户、开发组织管理者。
视角：系统的功能元素以及他们的接口、职责、交互
主要元素：系统、子系统、功能模块、子功能模块、接口
用途：开发组织划分、成本/进度的评估，对系统职责的的逐级划分
下面TensorFlow的逻辑视图示例，这里描述了TensorFlow中各个功能组件，从这个图中，基本可以对TensorFlow有一个大颗粒度的了解
﻿
﻿
1.2 过程视图：设计满足运行期质量属性的架构相关方：性能优化、开发相关人员
视角：系统运行时线程、进程的情况，以及相关的并发、同步、通信等问题
主要元素：系统进程、线程以及处理队列
常见设计工具中的时序图(序列图)
1.3 物理视图：和部署相关的架构决策相关方：系统集成商、系统运维人员
视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置
主要元素：物理节点以及节点的通信
用途：指导运维人员部署系统以及系统运维重点
1.4 开发视图：设计满足开发期质量属性的架构相关方：开发相关人员，测试人员
视角：视图如何开发实现
主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和先关基础框架
用途：指导开发组织设计和开发实现
类图是开发视图的一种
1.5 场景视图相关方：用户、设计和开发人员
视角：概括了架构上最重要的场景(最典型或者最有风险)及其非功能性需求，通过这些场景的实现，阐明了架构的广度或者众多架构元素运行的方式
为4+1视图的核心，它确定了以下信息，而其它4个视图都是需要围绕着这些信息进行设计：
系统边界：有了边界，才能够确定系统的设计范围；同时，通过边界能够识别出系统需要与用户或其它系统进行交互；
系统用户：明确的用户定义是系统需求分析的先决条件；
功能和场景：通过识别出系统与用户或其它系统的交互，可以分析出系统需要提供哪些功能，以及这些功能存在哪些应用场景；
2、模型2.1、什么是模型模型是一个系统的完整的抽象。人们对某个领域特定问题的求解以及解决方案，对它们的理解和认识都蕴含在模型中
开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射
﻿
﻿
2.2、统一建模语言（UML unified modeling language）静态图：通过描述类、对象、数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构。其包含用例图、对象图、类图、组件图、包图、部署图
﻿
动态图：通过描绘执行流程或者实体状态变化的方式，来展现软件实体在执行过程中的变化过程。其包含协作图、序列图、活动图、状态图
2.3 通用模型元素
﻿
泛化关系：A是B和C的父类，B,C具有公共类（父类）A，说明A是B,C的一般化，也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛 化关系用带空心三角形的直线来表示
关联关系：类之间的联系，类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系，
聚合关系：表示的是整体和部分的关系，整体与部分可以分开，通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系
组合关系：表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。强调的是整体与部分不可以分开
2.4 各种图例﻿
1、用例图
﻿
描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
﻿
2、类图
﻿
类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。
﻿
3、对象图
﻿
与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。
﻿
4、活动图
﻿
描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
﻿
5、状态图
﻿
描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。
﻿
6、序列图（顺序图）
﻿
序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
﻿
7、协作图
﻿
和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
﻿
8、构件图 （组件图）
﻿
描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。
﻿
9、部署图 （配置图）
﻿
是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。
2.5、各种建模在不同阶段的使用
﻿