1. 什么是软件架构？

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



2. 架构究竟是在做什么？

任何一个系统都有架构，架构是架构元素与元素间关系的描述，并写入架构文档。架构文档是一组架构视图组成的。架构视图反应了相关方的一些关注点。架构是给相关方做的，要让相关方能看的懂。给老板做的架构文档和给测试、工程师看的一定是不一样的，可能最终描述的是同一个东西。架构要满足相关方的诉求。



1. 架构元素是什么？

系统最终由哪些服务器组成，需要哪些软件，开发哪些模块、组件，需要设计哪些类，这些叫做架构元素。

1. 元素间关系是什么？

服务器间的调用关系，相互之间是如何交互的，是同步的还是异步的。类与类之间的关联关系，继承关系，调用关系。

1. 相关方都哪些？

包含但并不局限于客户、老板、开发、测试、运维、产品、运营。

1. 架构文档

元素间的关系是如何表现的？就是通过架构文档表现出来的。

1. 架构视图

架构视图描述元素间的关系，架构视图组成了架构文档。反应了相关方的关注点。

1. 系统是给谁做的？

系统是给相关方做的



作为架构师，就是要把上面的事情做好，满足相关方的利益诉求。



3. 今天讨论的重点内容：

1. 架构元素究竟应该包含哪些东西？

2. 元素间关系如何反应？

3. 架构文档如何写作？

4. 架构视图如何设计？



4. 4+1视图模型

4+1模型，是有IBM提出的一种架构设计方案。逻辑视图，开发视图，过程视图，物理视图，都围绕着场景视图展开。



1. 逻辑视图：

相关方：客户，用户，项目经理。

视角：说明开发的这个系统功能是什么样子的。关注的是功能元素，以及它们的接口，职责，交互。

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

用途：逻辑功能。



1. 开发视图：

相关方：开发人员，测试人员。开发人员根据开发视图进行编码，把系统开发出来。

视角：系统如何实现，涉及到的是具体的东西了，到了这个层面，改确定的东西都已经确定了。比如：系统中要用到消息队列，那么在这里就要说明具体是使用哪个消息队列。

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

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



1. 物理视图：

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

视角：要多少服务器，服务器如何部署的，需要什么的网络节点

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



1. 过程视图

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

视角：系统运行时线程、进程的情况。运行的过程是如何，调用关系是什么样子的，都经过哪些组件最终完成的。

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



1. 场景视图

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

视角：概括了架构上的重要场景，业务场景是什么样子的，功能及非功能性需求。如：用例图。



4+1视图的理念非常好，为什么不用一种视图完成架构设计呢？ 一个东西，只有一面是平的，不立体的，没有根基的，不扎实的，一推就倒。4+1就是说一个系统有多个方面，不同的相关方关注点不同，每一种视图关注的面是不同的，要表达的信息也是不同的。开发者和老板客户关注的都是不同的。



5. 建模语言

使用uml进行建模。uml本身是很简单的，就那么一些语法，常用的模型。怎么用这个图来表达设计意图，这个是比较难的，如果脑子里面一片空白，那么uml是帮不了你的。

后面学习：用什么模型来表达设计意图，给什么人看。



1. 什么是模型？

模型是一个系统的完整抽象。在开发之前如何把要做的系统表达出来，用到的就是模型。根据抽象变成现实。在系统还没开发出来之前，架构师脑子里就应该有一个完整的东西了，这个系统由哪些组件，哪些类。把脑子里面的东西画出来，就是系统的模型，系统的设计。



对现实的问题，进行分析、抽象形成概念模型。通过视图的方式表达出来，分析设计形成解决方案。一方面要抽象最后开发出来的系统，一方面要抽象现实中的业务问题。要设计的系统关系就是存在于现实之中的。如：电子商务，有买家，卖家，商品，订单这些都应该在模型里面。 如果设计的系统和现实是不一致的，那么开发的时候就会遇到问题。开发的时候要理解业务。





1. 为什么要画出来呢？

一方面是自己看，自己验证一下模型是否合适。通过模型验证是否合理，最终的系统能不能达成预期的目标。

另一方面和别人进行沟通。



1. 什么时候画图？

开会的时候，讨论交流时，用白板，白纸，软件画，然后方案就出来了。



1. uml为什么叫统一建模语言？为什么叫语言呢？

语言就是交流和沟通的工具，画出来的图是为了给别人看的。重要的是表达设计意图，交流和沟通。



1. uml分类

2. 静态图

3. 用例图、类图、组件图、部署图

4. 动态图

5. 序列图、活动图、状态图

6. 通用的元素

7. 类、状态、用例、组件

8. 静态模型元素关系

9. 依赖：相当于局部变量，或参数的依赖。有偶然性。关系弱一点

10. 关联：一个类是另一个类的成员变量，关系强一点。

11. 继承：继承了就能直接使用。

12. 实现：要自己实现。

13. 聚合：生命周期不一致，是聚在一起的，聚合出来的对象被销毁后，参与聚合的对象不会被销毁。

14. 组合：类与类生命周期相同，同生共死。



1. uml分类解读

用例建模:(用例图)

主要是功能需求描述，在宏观上给出一个中心轮廓。就是这个系统能做什么，都有什么样的功能，供哪些角色来使用，功能之间的关系是什么。

元素：角色（小人状），用例（椭圆状），要做的事情，边界(矩形的框)。这里面的每一个字都不是多余的。

边界：表示这个用例的边界，都包含了什么功能，有哪些角色，功能和功能之间的关系是什么（使用和扩展）

角色：可以是人，也可以是另一个系统。



使用场景：比原型更抽象，功能更聚焦，工作量也更少一点，一把般是在需求分析阶段，功能需求描述的时候使用。

用例图通常是有许多张的，用多个用例图来描述，一张图包含的元素不需要太多（十几二十个），如果描述不了，就用多张图描述。先来一个总的描述核心的关键功能 ，然后在往下细分成更多的图。





细化试例：



细化到什么程度？

细化到相关方能看懂为止。



类图：

主要是描述类之间的关系，继承，组合，聚合，实现，继承等关系，类包含了哪些方法。



场景：类图主要是在详细设计阶段，类名和方法名都有了。



uml中的消息：

简单消息、同步消息、异步消息



序列图：



任何阶段的可以使用时序图。描述任何对象之间的时序，调用关系。

需求分析阶段：画当前设计的系统和已有的系统之间的关系，调用某些功能，如调用支付系统完成支付功能。系统级的时序图。

概要设计阶段：画组件之间的交互组件时序图，组件和服务器之间的时序图。

详细设计阶段：方法之间的调用关系。

关注的是时序。



活动图：（流程图）



描述流程的。描述整个处理流程是怎么样完成的。使用永道工具，描述跨领域完成的流程。

关注的是流程。



使用场景：

需求分析：描述核心业务的完成流程，业务之间的处理流程。画业务的流程

概要设计：不同的模块，领域，子系统之间的处理流程是怎么样的

详细设计：画一个方法内部的处理流程。

状态图：

主要是描述状态变迁。在不同状态之间的变化关系。如：订单，创建，待支付，取消，待出货，已支付，配送中，已签收，待评价。状态图使用场景单一，效果倍棒。如果用文档描述容易产生分歧，特别是状态比较多的时候，状态变迁冲突。

下面这个是电梯的状态图：



使用场景：

需求分析：订单，创建，待支付，取消

详细设计：状态，假设用枚举表示状态，bool值的变迁。



组件图:

描述模块组件，模块的关系，边界。

设计到底在设计什么？ 就是把功能里面的模块拆分清除，关系缕清楚。关键点组件的大小，组件之间的依赖关系。通常是依赖，关联关系，调用关系。大的功能组件可以继续划分若干个逻辑组件，组件的粒度细化到一个人能开发的粒度。



组件图不光是描述了组件之间的依赖，也描述了开发的过程，开发者的职责分配，和分工，开发依赖关系（模块之间的依赖，就是开发依赖关系），重要的组件可以分配给资深的工程师，工期如何排， 底层依赖的先开发，顶层的后开发。



概要设计阶段画组件图，静态关系。动态关系用组件时序图画。



部署图：

主要是物理部署。

一个立方体表示一个服务器。主要是服务器之间的关系，主要是设计的系统最后要部署到哪些服务器上，有些是现有的服务器，新的系统和其它系统之间的依赖关系。



部署图也是架构设计文档里面的第一张图。



软件设计分3个阶段

1. 需求分析

2. 输出需求文档

3. 概要设计

4. 概要设计文档

5. 详细设计、

6. 详细设计文档



总结

需求分析阶段画的图



1. 用例图：核心的用例图，描述功能、场景。

2. 活动图：业务流程，画不同的领域模型内用例有哪些。描述关键业务流程，处理流程是什么样子的。

3. 状态图：核心对象，核心的业务状态变迁，比如：订单状态，下单，取消，待支付，已支付，退款，超时未付款等状态的变迁。

4. 时序图：当前系统与外部系统的时序图。（外部系统级的依赖关系）



把系统要做的事情，背景约束，其它系统之间的关系，作为需求的一部分，作为一种约束表达出来。



概要设计阶段画的图

1. 部署图：最顶层的，体统是长什么样子的，整体的蓝图，包含了哪些子系统，它们之间的依赖关系是什么样子的。

2. 服务器或子系统级别的时序图：描述服务器的调用关系，依赖关系。部署图可能比较简单，所以并不是一定要有时序图

3. 子系统级的活动图：子系统级处理业务是什么样子的。

4. 组件图：组件之间的关系，依赖。粒度：细化到一个人能开发。

5. 组件时序图：组件一定要画时序图，描述组件之间是如何调用的，依赖的。

6. 组件活动图：关键场景组件之间的流转过程。跟时序图差不多。



详细设计阶段画的图

1. 类图：类的结构，各个类之间的依赖关系。如：组合聚合，依赖关联，继承实现。

2. 类的时序图：

3. 状态图：某场景实际的状态变迁，状态的枚举值，状态变迁bool值。

4. 方法的活动图：方法以及的活动题，一个类内部方法的业务处理流程。



架构师的最终产出就是一些uml模型，给工程师通过代码实现完成架构设计，相关的架构设计文档。和其他架构师交流，和老板交流。



uml工具本身是比较简单的，关键是如何表达出自己的想法，在什么场景下画什么图，如何用好这个是比较难的。脑子里面有没有系统的雏形。



架构设计是跟场景有关的，在现实需求的约束下，头脑里面有一个系统的设计雏形，如何雏形表达出来，一方面给相关的人看（老板），我的这个设计是能达到你的要求的。另一方面落地，开发的时候开发的工程师，能够按照架构设计完成系统。



架构师：把握住整个系统的架构设计，以及过程中的工作人员安排（如何合理完成工作）。理解面对的问题是什么，理解了问题就理解了解决方案为什么是这样子的。架构师是团队的技术核心，负责整体的架构设计，对架构负责，以及架构的落地，落地的过程就是工程师的开发过程，如何保证开发工程师的职责是清晰的，进度是可控的，都是架构师的责任，在架构设计的时候就要考虑这些，还有其他的一些相关方，要考虑到做的事情相关方有哪些，如何对他们负责。