架构师训练营第一周学习总结

        通过对架构师训练营课程一周的学习，有这样一些总结和想法。

        每一个信息系统的实现，都必须经过需求分析、架构设计与开发三个过程，在实际过程中，开发编码是必须的，没有编码就没有信息系统的成果，需求分析和架构设计的文档则或有或无、或繁或简。需求分析师获取与分析现实世界的用户需求，程序员编码开发信息系统满足用户需求。而需求如何被满足？系统如何组织？程序员如何将需求与系统对应？功能性需求、非功能性需求、约束条件，如高可用、大并发、可扩展、快速迭代、工期紧、经费有限。。。这些条件之间如何平衡？如何合理选择技术栈？如何有效组织程序员协作？等等这些问题，如果没有架构师从中发挥作用，系统开发将陷入一个个的泥潭，或许爬得出来，或许项目就烂尾了。如果项目成功了，其中一定是有人或多或少地，自觉或无意地发挥了架构师的作用。

        架构师要从全局到细节，完全把控系统的技术实现，需要很强的抽象能力、很广的知识面，也要有很深的编程功底，既能够总览全局，又能够对技术细节精准定位，找到解决问题的关键或有效途径。架构师需要快速理解需求的关键点，编写面对不同相关方的架构文档并与之交流，在需求理解、资源分配、系统开发上达成共识。

        架构师工作，产出工作成果，架构师的成果有架构设计文档、编程框架、解决技术问题、协调相关方确保架构与开发工作顺利进行。

        架构师需要掌握的技能有：扎实的编码功底、掌握基础技术知识、对常用技术产品的理解与运用、对常用框架模式与框架的理解与运用、建模与设计架构文档、快速并深刻理解业务并进行分类、优化系统性能与分析故障、快速学习、沟通与领导。想成为合格的架构师，就需要有意识地在这些方面训练自己。

        每一个系统都有架构，架构由架构元素以及元素间的关系组成。每一个系统也都有相关方，如发起人、项目经理、需求分析师、架构师、程序员、客户与用户，不同的相关方有不同的关注点，如发起人关注系统的效益，项目经理关注项目控制过程，需求分析师关注需求的获取、描述与跟踪，架构师关注如何实现系统满足需求，程序员关注用什么语言、什么框架、库、表、字段，客户关注投资收益，用户关注使用是否方便，系统是否稳定，反应是否迅速，与旧系统的差异是什么？因此，架构师的架构文档，面对不同相关方的关注点，要有不同的架构视图。这么一个关系，李智慧老师用一个图来表示：





相关笔记：



4+1 架构视图

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

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

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

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

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

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

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

逻辑视图主要面向终端用户，开发视图主要面向程序员，过程视图在描述子系统、模块、角色、类、程序内等都会用到，物理视图主要描述系统部署拓扑关系，这些视图都围绕业务场景进行，用不同的视角来描述如何满足业务场景。



逻辑视图

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

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

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

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



开发视图

相关者：开发相关人员，测试人员。

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

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

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



物理视图

相关者：系统集成商，系统运维人员。

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

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



过程视图

相关者：性能优化，开发相关人员。

视角：系统运行时现成、进程情况。

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



场景视图

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

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



问题求解过程：

模型解决抽象的问题，也是思维转化的过程，抽象后，更容易理解和分析，再演化出具体的解决方案，实施并解决问题。



UML是一种统一建模语言，解决建模的问题，并提供思考问题的模式、自我交流以及与相关方交流的工具。



UML图的分类：

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

用例图（Use Case Diagrams）

对象图（Object Diagrams）

类图（Class Diagrams）

组件图（Component Diagrams）

包图（Package Diagrams）

部署图（Deployment Diagrams）



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

协作图（Collaboration Diagrams）

序列图（Sequence Diagrams）

活动图（Activity Diagrams）

状态图（State Diagrams）



对象间关系：

依赖、关联

继承、实现

聚合、组合

一般规则：实线比虚线关系更强，实心比虚心关系更强。



用例图：



类图：



UML中的消息：

简单消息（simple）：表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。

同步消息（synchronous）：是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。

异步消息（asynchronous）：是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。



时序图：



活动图：



状态图：



合作图：



组件图：



部署图:



架构设计文档

架构设计主要是概要设计和详细设计两部分，用4+1视图（逻辑、开发、物理、过程、场景）来表现。

在概要设计阶段，主要用到部署图、时序图、活动图和组件图，这些图主要作用在服务器、子系统、模块上。

在详细设计阶段，主要用到类图、时序图、状态图、活动图，这些图主要作用在类与方法上。

UML在需求分析阶段，主要会用到用例图、活动图、状态图和时序图，这些图主要作用在功能、业务对象、内外部系统上。