什么是软件架构？
软件架构是整体结构与组件的抽象描述，用于指导大型项目在各个方面的设计；
分析图解：
1、一个架构最重要的是相关方，相关方包括客户、老板、开发人员、测试人员、运维人员，和项目有关的人都可以称之为相关方；
2、相关方的关注点产生架构需求，整个架构基于关注点做分析；
立即学习“Java免费学习笔记（深入）”；
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）；
画图的通用模型
通用模型元素：类、对象、节点、包和组件
通用关系：
关联：连接模型元素及链接实例；
依赖：表示一个元素以某种方式依赖另一种元素。
泛化：表示一般与特殊的关系；
聚合：表示整体与部分的关系；
