1.如何成为架构师

成为架构师一般有两个途径，其一是通过内部晋升，公司把你安排在架构师的职位上或实际上做的是架构师的事情，比如架构设计、软件设计文档编写、技术难点公关等；其二是通过去应聘架构师职位。

2.架构师主要能力

• 编程能力

• 基础技术掌握能力

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

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

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

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

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

• 快速学习能力

• 沟通与领导能力

3.软件架构的定义

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

4 架构设计文档编写

架构师前期产出就是架构文档，根据不同对象编写对应都架构文档。对于老板，架构师要推进一个项目落地，架构师编写都架构文档就没有那么专业化，是那种相对非技术人员通俗易懂的文档或 PPT。对于开发人员设计文档则要编写软件设计文档指导开发人员开发、不偏离架构主体设计

4.1 4+1 视图模型

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

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

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

• 过程视图（Process View）,捕捉设计的并发与同步特征。

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

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

• 场景视图（scenarios）,描述用例场景。

4.1.1 逻辑视图

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

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

• 主要元素：系统、子系统、功能模块、子功能模块、接口。

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

4.1.2 开发视图

• 相关方：开发相关人员、测试人员。

• 视角：系统如何开发实现。

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

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

4.1.3 物理视图

• 相关方：系统集成商、系统运维人员。

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

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

4.1.4 过程视图

• 相关方：性能优化、开发相关人员。

• 视角：系统运行时线程、进程的情况。

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

4.1.5 场景视图

• 相关方：用户、设计和开发人员。

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

5. 软件建模语言

5.1 什么是模型

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

5.2 为什么要建造模型

建造传统模型的目的：

• 为了证明某件事情能否工作。

• 前提：建造模型的成本远远低于建造实体的成本。

建造软件模型的目的：

• 为了它与人沟通

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

• 前提：除非模型比代码更说明问题

5.3 UML

5.3.1 UML 概述

• Unified Modeling Language ，或统一建模语言

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

• 可用来描述：

• 某个问题领域

• 构思中的软件设计

• 描述已经完成了的软件设计

5.3.2 UML 图的分类

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

• 用例图（Use Case Diagrams）

• 对象图 (Object Diagrams)

• 类图（Class Diagrams）

• 组件图（Component Diagrams）

• 包图（Package Diagrams）

• 部署图（Deployment Diagrams）

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

• 协作图（Collaboration Diagrams）

• 序列图（Sequence Diagrams）

• 活动图（Activity Diagrams）

• 状态图（State Diagrams）