架构 = 架构元素 + 元素关系

资深软件系统开发者，需要输出 4+1 视图，对不同人员的关注点进行说明

• logical view 针对终端用户，标明功能性需求。对系统进行功能分解与抽象，抽象来源于问题领域。

逻辑视图需要保持单一内聚的对象模型。逻辑视图属于静态视图。

• process view 针对集成、性能、可扩展性方面的关注者,即系统集成人员。侧重于系统运行时的特性，关注的是非功能需求，如并发性，分布性，系统集成特性，容错能力。

过程视图是动态视图，表现的是逻辑视图中各个功能对象的分布，可以以多层的抽象进行描述，关注每个不同层级的不同方面。

• development view 针对的开发人员，软件管理。侧重于软件系统的模块的组织与管理。系统模型图和子系统图等表达，是静态视图。

• physical view 针对系统工程人员，系统的拓扑，通信，部署。

• 场景将其他视图有机联系起来，可以用文本，也可以用图形表示。

不同的系统侧重点不同，对管理系统来说，侧重于功能与开发，因此关注点在逻辑视图与开发视图。对实时控制系统，侧重控制，过程视图和部署视图是其关注点

4+1 视图于我有何用？

软件系统是一个有多维度系统，这来源于其自身的复杂性。

对个人来说：

• 零开始的架构设计

1. 对系统进行分析，分析收集获取各种使用场景，使其图文化，方便后续进行回溯与参考。

2. 在这个过程中有些场景可能是无效的，因此需要咨询相关方，确定各场景的有效性。

3. 用例视图是重中之重。

• 接手前人项目，在系统文档缺乏，一无所知的情况下

1. 通过使用软件系统和咨询相关人员，描绘其功能性视图和用例场景视图，以作参考。

2. 初步使用与了解后，需要获取其过程视图。这个时候需要对系统的非功能性设计有个总体的认知，一般而言，针对某些接口，由点破面，逐步描绘该视图。

3. 过程视图在一些稍大的系统中，一张图不足以描述，需要多层次图进行描述，重点是对系统有个整体的认知。

• 学习开源项目，关注点在于

1. 能干什么，即系统有什么功能，功能逻辑视图。

2. 模块如何组织，开发视图。

3. 重点是过程视图，系统是如何运行的。

4. 总结项目中使用到的技术，以及问题解决的思路。

5. 开源项目除了查看源代码，使用工具调试运行时情况也是必要的。

如何画图，怎么产出？

架构过程是一个迭代的过程，需要反复确定需求

架构需求

产出用例图文，敲定功能需求点。

关注点有三

• 系统质量目标

• 系统业务目标

• 系统开发人员业务目标

只有让参与评审的相关人员参与进需求架构的过程中，才能最终形成一致的意见。

需求评审的目标

• 确定需求是否合理

• 确定功能组件定义是否合理

问题分析

系统的架构是在对问题分析的基础上进行的，因此，首先需要对问题进行分析与定义，然后可归纳出有效的模型。

1. 在问题定义上达成共识

问题概述：描述问题本质

影响：说明对哪些项目干系人产生的影响

结果：确定产生什么样的影响（商业活动和项目干系人）

优点：概要性提出解决方案，并列出该方案优点

1. 理解问题本质

因果鱼骨图 + 头脑风暴 探究问题本质

1. 确定干系人和用户

系统用户是谁？

系统客户是谁？

哪些人会受到系统输出影响？

谁会对它进行评估？

系统由谁来维护？

1. 定义系统边界

面向对象的用例图（面向对象分析）

上下文范围图（结构化分析）

1. 确定系统实现的约束

进度

投资

人员

预算

环境

操作系统

技术问题

行政问题

公司战略

程序工具语言的选择

分析方法

• 面向数据流结构化分析方法（SA）

• 数据流图（DFD）：针对系统输入输出，处理过程与数据存储，有上到下多层次逐步细化数据处理过程。

• 上下文范围关系图（context 图）：描述系统的输入输出，与外部实体的关系，即系统的上下文范围

• 面向数据结构 jackson 分析方法

• 以数据结构为驱动，映射输出结构与输入结构的关系，这种关系由顺序、循环、条件组成通过图的形式表述。

• 面向对象分析方法（OOA）

• 用于建立动态模型的状态迁移图和 petri 网（基于工作流的问题分析）

如何进行系统设计

1、寻找系统目标间的平衡点，即妥协

2、总结学习参考他人的系统，甄别、取舍、补充来作为新系统的设计

架构设计

针对问题领域建模，产出领域模型，设计模型。避免涉及过多的内容和实现细节。

架构文档化

架构复审

过程总结

1. 态度要端正，知道自己想要什么。

2. 从 JD 中解读面试者传递的信息，做好准备，查漏补缺，从容应对。

3. 架构是对现实世界客观事物的一种建模，模型的好坏决定架构的成败。

4. 架构产出：4+1 视图。根据实际情况，产出架构文档，能针对管理者，开发人员，运维人员的不同关注点进行阐述，说明架构方案。这是一个沟通的过程。

5. 团队中建立自己的技术领导力。

个人思考：

1. 命题作业看似简单，但真正从实际的角度去考虑，从大局去思考，是有着不一样的难度。

2. 对自己这种从未进行过架构思考的人来说，作业的过程，找不到关键点，自己的知识体系零散，不够全面，尤其涉及部署的时候，最能说明问题。

3. 对后端缺少足够全面的认知，系统设计能力欠缺，体系框架凌乱。