1 如何定义架构师？



架构师是一定帽子，而不是一把椅子。

架构师不一定要与很多年经验，最重要的是要有悟性。要知道我们面临的是什么样的问题，我们该如何去解决它，解决它的过程中有哪些困难和挑战。尽量尽自己的能力将所要设计的软件进行清晰地表达出来。同时也要理解这些问题、困难的本质是什么。再使用方法解决问题时就能立刻明白这样做好，还是那样做好，还有没有更好的解决方案。

2 什么是软件架构？





软件架构是由架构元素和元素间关系组成的。架构关联文档，架构文档由一些架构视图组成。架构视图关联一些关注点，系统有一些相关方，每个相关方都有自己的一些关注点。最终的架构文档是给相关方看的，这些相关方可以是客户、项目经理、工程师等。

上图中最重要的是相关方，因为架构视图最终要给相关方看。相关方可以是工程师、需求方、测试、老板等。所以对于不同的相关方，最终呈现的架构文档一定是不一样的。



2.1 什么是架构元素？

架构元素即是系统的组成部分，比如系统可以由一些服务器、模块、类组成。将这些组成部分之间的关系进行设计，得到元素间的关系。



2.2 架构元素之间的关系有哪些？

可以分为两类：静态关系和动态关系。组合、聚合、关联、依赖都属于静态关系，组件、子系统之间的交互和协作即为动态关系。

架构元素和元素间关系要反应到架构文档中，架构文档中由多个架构视图组成，比如组件图、部署图、时序图、类图和状态图等。

3 UML软件架构设计与建模

3.1 什么是模型 ？

模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴含在模型中。



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



软件设计就是软件建模，直接撸代码就缺乏完整的设计。模型是系统完整的的抽象，根据抽象进行系统设计开发。架构师需要一定的抽象能力，通过模型进行表达。



架构师在系统还未开发时，就要有业务问题、系统整体关系的抽象，最终抽象并反映出来。



3.2 为什么要建模?

软件建模目的是为了与他人沟通，有了统一建模语言，每个人都能理解模型内在的机理。同时也保存了软件设计的最终成果，为软件的二次开发和重构提供详细的说明文档。



3.2 UML图的分类

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

• 用例图（Use Case Diagrams）

• 对象图（Object Diagrams）

• 类图（Class Diagrams）

• 组件图（Component Diagrams）

• 包图（Package Diagrams）

• 部署图（Deployment Diagrams）

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



• 协作图（Collaboration Diagrams）

• 序列图（Sequence Diagrams）

• 活动图（Activity Diagrams）

• 状态图（State Diagrams）



常用的是以上字体加粗的七种模型



3.3 UML图在各个阶段的应用



（1）需求分析阶段

用例图可以描述使用者与功能之间的关系，从执行者的角度理解系统，用于捕获系统的需求，规划和控制项目。

（2）概要设计阶段

此阶段需要抽象出系统的整体架构，可以使用部署图和组件图进行阐述。部署图可以清楚地看到哪些系统部署到哪些服务器上，对整体的物理结构有了初步的定位。组件图则可以解释各个模块或者子系统之间的调关联依赖关系，通过组件图可以进行人员分配和投入时间预估。

（3）详细设计阶段

进一步细化，将组件图中各个组件内部的运行机制进行静态和动态分析。

类图可以对各个类的方法变量进行静态描述，时序图可以对类或模块执行的先后顺序进行动态分析，活动图可以详细解释某一组活动之间交互的方式，状态图则是描述一个特定对象的所有可能的状态及其引起状态转移的事件。



以上动态模型不仅可以在详细阶段进行设计，比如时序图、活动图均可以在以上三个阶段使用，状态图也可以在需求分析阶段使用。