架构师训练营第一章总结

什么是软件架构？

软件架构是整体结构与组件的抽象描述，用于指导大型项目在各个方面的设计；

分析图解：

1、一个架构最重要的是相关方，相关方包括客户、老板、开发人员、测试人员、运维人员，和项目有关的人都可以称之为相关方；

2、相关方的关注点产生架构需求，整个架构基于关注点做分析；

3、整个过程是为相关方做系统，系统提供的能力应该满足相关方；

4、架构是系统的技术支持和实现，所有系统都是由架构支撑；

5、架构升级需要架构文档的支撑，构架文档主要对相关方输出，作为架构的标准支撑；

6、架构文档需要架构视图的组成，包括4+1视图模型，整合关注点；

7、架构主要分为两个要素，架构元素和元素之间的关键，元素包含模块、组件、包、类等；关系包含实现、集成、聚合、关联等;元素建关系又分为静态关系和动态关系；

重新定义架构师

架构师是一个人的职称，是做系统和对系统复制的那个人；架构师不是一个职位而是一个角色，任何人都有可能是公司的架构师，但是职位不一定是负责的那个人。

如何提升做架构师的能力？

1、需要有对应的架构方法去支撑你所做的设计

2、架构模式需要视情况而定，不能为了做架构而做架构，根据公司所承受的能力和业务设计框架，没有最好的架构框架，只有最适合公司的框架；

3、做架构师一定要有足够的实践经验，有真实场景；

4、要学会画图、总结、沟通的能力；

如何去做架构

软件架构是由元素、形式、关系约束组成，单一的视图无法表达整体架构。

4+1架构视图

逻辑视图（Logical View）：设计的对象模型；

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

物理视图（Physical View）：描述软件到硬件的映射，反应部署特征；

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

场景视图（scenarios）：描述用例场景；

逻辑视图

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

元素构成：系统、子系统、功能模块、子功能模块、接口

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

开发视图

相关方：开发测试人员

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

用途：知道开发组织设计和开发实现

物理视图

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

元素构成：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置；

用途：物理节点以及节点通讯功能；

过程视图

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

元素构成：系统进程、线程以及处理队列等；

用途：协助解决性能优化和系统瓶颈点；

场景视图

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

用途：阐明架构的广度或者众多架构元素运行的方式；

如何建立模型

1、模型是整个系统抽象出来的一个概念，解决方式都是基于对模型的理解和认识；

2、具体的模型是为了解决某一个领域的问题，问题的过程就是就是问题映射到模型的一个过程；

3、建立模型的过程为：先确定领域问题，通过分析和抽取的方式构造一个概念模型，从这个模型里面提取架构需求，最后提供解决方案；

4、建造模型的成本比时间开发的成本少很多；

5、便于系统间人员共同和文档资产积累；

6、在讨论场景比较多或者是开会的场景交流使用；

7、可通过白板、绘图工具按照不同场景画不同类型的图；

UML建模

UML全称Unifiled Modeling Language，统一建模语言，成为架构沟通的一种普片认可的语言形式，可以描述某个领域内的特定问题、和设计阶段的架构或者软件实现。

UML 图分类

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

用例图（Use Case Diagrams）、对象图（Object Diagrams）、类图（Calss Diagrams）、组件图（Component Diagrams）、包图（Package Diagrams）、部署图（Deployment Diagrams）

动态图：通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变换过程，常见的动态图有：
协作图（Collaboration Diagrams）、序列图（Sequence Diagrams）、活动图（Activity Diagrams）、状态图（State Diagrams）；

画图的通用模型

通用模型元素：类、对象、节点、包和组件

通用关系：

关联：连接模型元素及链接实例；

依赖：表示一个元素以某种方式依赖另一种元素。

泛化：表示一般与特殊的关系；

聚合：表示整体与部分的关系；