第一周：架构方法 - 架构师如何做架构学习总结
1. 如何成为架构师
1.1 架构的思维方式
业务千差万别，同一个系统在一个公司能成为银弹，在另一个公司却有可能成为累赘。做架构首先要看到问题在哪里，看到问题本质是什么，清楚解决问题的思路是什么，用哪些方法可以解决。一旦拆解出问题的本质，就可以突破业务界限，灵活运用各种技术做出一个合理的架构。业务不是共通的，但是技术是可以共通的。
1.2 架构师的主要职责
编码：
开发编程框架
重构软件代码
设计：
设计系统架构
进行技术选型,解决技术应用中的问题
大数据应用
模块分解与微服务架构重构
编写架构设计文档
保障，优化与创新：
优化系统性能
技术创新
保障系统安全与高可用
沟通：
沟通管理
1.3 架构师主要能力
编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化与分析故障的能力
常用架构模式和框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习
能力沟通与领导能力
1.4 什么是软件架构
系统会有架构
架构由架构元素和元素间关系组成的
架构元素：指系统由什么组成，按照不同维度，可以为服务器，模块，组件，类等等。
元素间关系：
静态关系：组合，聚合，关联，依赖，继承，实现等等
动态关系：类和类如何交互，组件与组件如何交互，子系统与子系统如何交互，服务器之间如何交互，架构要把这些交互关系表达出来
架构设计的输出为架构文档
系统有一些相关方，每个相关方都有一些关注点，架构文档就是为相关方服务
架构文档由一些架构视图组成，不同架构视图有不同的关注点，对应不同的相关方
核心：相关方
系统的架构能否落地取决于相关方，取决于你输出的架构文档是否包含相关方的关注点，能否满足相关方诉求。
2. 如何构建架构视图
2.1 4+1 架构视图
为什么用 4+1 种视图，不是一种？因为各个相关方关注点不一样，需要从多个方面，不同视角，不同维度描述系统，对系统的描述由平面到立体。
分类：以场景视图为中心
逻辑视图(Logical View) ,设计的对象模型。
相关:客户,用户,开发组织管理者。
视角:系统的功能元素,以及它们接口,职责,交互。
主要元素:系统,子系统,功能模块,子功能模块,接口。
用途:开发组织划分,成本/进度的评估。
过程视图(Process View) ,捕捉设计的并发和同步特征。
相关者:性能优化,开发相关人员。
视角:系统运行时线程,进程的情况。
主要元素:系统进程,线程以及处理队列等。
物理视图(Physical View) ,描述了软件到硬件的映射,反映了部署特性
相关者:系统集成商,系统运维人员。
视角:系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。
主要元素:物理节点以及节点的通信。
开发视图(Development View) ,描述了在开发环境中软件的静态组织结构
相关者:开发相关人员,测试人员。
视角:系统如何开发实现。
主要元素:描述系统的层,分区,包,框架,系统通用服务,业务通用服务,类和接口,系统平台和相关基础框架。
用途:指导开发组织设计和开发实现。
场景视图(scenarios) ,描述用例场景。
相关者:用户,设计和开发人员。
视角:概括了架构上最重要的场景(最典型或者最有风险)及其非功能性需求,通过这些场景的实现,阐明了架构的广度或众多架构元素运行的方式。
2.2 UML 建模
2.2.1 什么是模型
完整的抽象，即是对业务的抽象，也是对系统的抽象。先对现实中业务进行抽象，通过对业务进一步分析，得到系统的抽象。
2.2.2 UML 分类
静态图：
用例图(Use Case Diagrams)
对象图(Object Diagrams )
类图(Class Diagrams)
组件图(Component Diagrams)
包图(Package Diagrams)
部署图(Deployment Diagrams)
动态图：
协作图(Collaboration Diagrams)
序列图(Sequence Diagrams)
活动图(Activity Diagrams)
状态图(State Diagrams)
常用 7 种：用例图，类图，组件图，部署图，序列图，活动图，状态图
2.2.3 模型元素与元素关系
模型元素：可以在图中使用的概念统称为模型元素，比如类、对象、结点、包和组件等
元素间关系：依赖，继承，实现，关联，聚合，组合等
2.2.4 UML 使用
用例图：
用途：系统能做什么，描述系统功能
元素：角色，用例，系统边界，线条
使用阶段：需求分析
粒度：细化到相关方可以理解即可
类图：
用途：表达对象模型的静态结构
元素：类，关系（常见关系: 泛化, 实现，关联，聚合，组合，依赖）
使用阶段：详细设计
粒度：细化到开发人员可以理解即可
时序图：
用途：描述对象之间的动态合作关系以及合作过程中的行为次序
元素：简单消息，同步消息，异步消息，对象，生命线，激活
使用阶段：需求分析（系统之间交互），概要设计（服务器和组件之间交互），详细设计（类之间交互）
粒度：画出核心逻辑
活动图
用途：描述流程与顺序，一种流程图
元素：活动、转移、对象、信号、泳道等。
使用阶段：需求分析（业务流程），概要设计（不同领域，模块，子系统流程顺序），详细设计（一个方法内部的执行顺序）
粒度：细化到相关方可以理解
状态图
用途：描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。用于有复杂状态变迁的场景。
元素：状态、转移和事件
使用阶段：主要为需求分析（比如业务订单状态），详细设计（状态枚举值，对应逻辑与变量变更触发状态变化可以写在线上）
粒度：细化到相关方可以理解
组件图（组件图设计里面最重要的图，组件动态关系用组件时序图）
用途：表达对象模型的静态结构
元素：组件、接口、依赖关系
使用阶段：主要在概要设计阶段，表述静态关系
粒度：概念上的组件是可复用的物理意义上的组件，比如一个 jar 包。一个物理组件又可以分为若干个逻辑组件。在组件图中，可以拆分至差不多一个人能负责一个组件的开发。图中组件之间的依赖关系以及调用关系需要明细，因为描述组件之间的关系，也能体现工程师之间的关系，体现谁先开发，谁后开发等工程师之间的依赖关系
部署图（作为设计文档里的第一张图）
用途：物理部署，服务器之间的关系，承担什么职责
元素：物理节点（节点内部可以包含软件组件）、关系
使用阶段：概要设计阶段
粒度：细化到相关方可以理解
2.2.5 UML 使用场景总结
需求分析：用例（核心），时序（和外部系统调用关系），活动（业务流程），状态（关键业务对象变迁）
概要设计：部署图，子系统级时序图，组件时序图，组件图，活动图
详细设计：类图，时序图，状态图，方法的活动图
还未添加个人签名 2018.01.24 加入
还未添加个人简介
评论