《软件架构设计》
《软件架构设计文档》模板
《软件架构设计文档》模板软件架构设计文档模板1. 引言1.1 背景在当今数字化时代，软件的需求日益增加，对高质量、可维护和可扩展的软件架构需求也越来越高。
软件架构设计文档是为了规划和指导软件开发团队在开发过程中的工作，保证软件系统的稳定性和可靠性。
1.2 目的本文档旨在定义软件架构设计的要素和所需的技术、工具以及规范，以确保软件开发项目的成功实施。
2. 系统架构2.1 设计原则2.1.1 模块化2.1.2 可重用性2.1.3 可扩展性2.1.4 松耦合2.1.5 高内聚2.2 架构风格2.2.1 分层架构2.2.2 客户端-服务器架构2.2.3 事件驱动架构2.3 架构图示在此处插入架构图示，包括主要组件和它们之间的关系。
3. 体系结构设计3.1 模块描述3.1.1 模块一描述模块一的功能和职责，包括输入、输出和内部数据流程等。
3.1.2 模块二描述模块二的功能和职责，包括输入、输出和内部数据流程等。
...3.2 接口设计3.2.1 内部接口描述模块之间的内部接口，包括输入输出参数、数据格式等。
3.2.2 外部接口描述软件系统与外部系统或第三方服务的接口，包括输入输出参数、协议规范等。
3.3 数据库设计描述软件系统的数据库设计，包括表结构、关系、数据类型等。
3.4 数据流程设计描述软件系统的数据流程设计，包括数据的输入、处理和输出流程。
3.5 安全性设计描述软件系统的安全性设计，包括用户验证、数据保护、权限控制等。
4. 技术选型4.1 编程语言选择根据项目需求和开发团队的技术实力，选择适合的编程语言或技术框架进行开发。
4.2 开发工具描述使用的开发工具，包括IDE、版本控制系统等。
4.3 第三方库和组件描述使用的第三方库和组件，包括功能描述、版本信息等。
5. 质量保障计划5.1 单元测试计划描述针对各个模块的单元测试计划和策略，确保软件的稳定性和可靠性。
5.2 集成测试计划描述软件集成测试的计划和策略，确保软件各个模块之间的协同工作。
软件架构设计基础文档
软件架构设计基础知识文档摘要本文件旨在为新加入的软件开发团队成员提供一份关于软件架构设计的基础知识指南。
内容涵盖常见架构模式、设计原则、性能优化策略等基本概念，旨在帮助初级到中级开发人员建立软件架构设计的框架。
通过代码示例和真实项目案例，配合清晰的架构图和流程图，便于阅读和理解。
1. 引言软件架构设计是开发过程中的一项关键工作，好的设计能够提高系统的可维护性、可扩展性和性能。
本指南将帮助新手开发人员理解基础概念，并掌握一些实用的设计原则和模式。
2. 软件架构概念2.1 什么是软件架构软件架构是指软件系统的高层结构和其组件之间的关系。
它定义了系统的组成部分以及它们如何相互作用。
2.2 软件架构的重要性良好的软件架构能够提高开发效率、降低后期维护成本，并且可以让团队在技术和业务变更中保持灵活性。
3. 常见架构模式3.1 单体架构单体架构是将所有功能模块打包为一个整体，适合小型应用。
# 示例：Flask单体应用from flask import Flaskapp = Flask(__name__)@app.route('/')def hello():return "Hello, World!"if __name__ == '__main__':app.run(debug=True)优缺点：•优势：简单，易于部署。
•缺陷：难以扩展，维护成本高。
3.2 微服务架构将应用拆分成多个小服务，每个服务独立运行，适合大型应用。
# 示例：使用 Flask 创建一个微服务from flask import Flaskapp = Flask(__name__)@app.route('/user')def get_user():return {"name": "Alice"}if __name__ == '__main__':app.run(port=5000)优缺点：•优势：可独立部署和扩展。
软件架构课程设计
软件架构课程设计一、课程目标知识目标：1. 让学生理解软件架构的基本概念，掌握常见软件架构模式及其特点。
2. 学会分析软件需求，并能根据需求选择合适的架构模式进行设计。
3. 了解软件架构的评估方法和原则，能够对现有软件架构进行简单分析。
技能目标：1. 培养学生运用软件架构知识解决实际问题的能力，提高软件设计水平。
2. 提高学生的团队协作能力，学会在团队中沟通、协作完成软件架构设计。
3. 培养学生运用相关工具和技术进行软件架构可视化表达的能力。
情感态度价值观目标：1. 培养学生对软件架构设计的兴趣，激发学生的学习热情。
2. 增强学生的责任感，使其认识到软件架构在软件开发过程中的重要性。
3. 培养学生严谨、认真、客观的科学态度，提高学生的创新意识和实践能力。
课程性质分析：本课程为计算机科学与技术专业高年级学生的专业核心课程，旨在帮助学生掌握软件架构的基本知识，提高软件设计能力。
学生特点分析：学生具备一定的编程基础和软件工程知识，具有较强的学习能力和实践能力，但可能对软件架构的理论知识和实际应用存在一定程度的陌生感。
教学要求：1. 结合实际案例，注重理论与实践相结合，提高学生的实际操作能力。
2. 强化团队合作，培养学生的沟通协调能力。
3. 通过课程学习，使学生能够独立完成中小型软件架构设计任务，为后续软件开发课程打下坚实基础。
二、教学内容1. 软件架构基本概念：包括软件架构的定义、作用、分类及发展趋势。
教材章节：第一章 软件架构概述2. 常见软件架构模式：介绍分层架构、客户端-服务器架构、微服务架构、事件驱动架构等，分析各自特点及应用场景。
教材章节：第二章 软件架构模式3. 软件架构设计方法：讲解基于需求的软件架构设计方法，包括需求分析、架构风格选择、架构设计及评估。
教材章节：第三章 软件架构设计方法4. 软件架构评估与优化：介绍软件架构评估方法、原则，探讨如何优化现有软件架构。
教材章节：第四章 软件架构评估与优化5. 软件架构可视化：讲解软件架构可视化方法，如UML图、架构图等，以及相关工具的使用。
软件架构设计说明书
软件架构设计说明书软件架构设计说明书1、引言本文档旨在为软件架构设计提供一个详细的说明，以便团队成员理解软件系统的总体结构和各个组成部分之间的关系。
该文档详细描述了软件系统的各个模块、组件的功能和相互交互方式，旨在为开发人员、测试人员和其他利益相关者提供一个全面的架构设计指南。
2、背景在本章节中，我们将介绍软件系统的目标以及为什么需要进行架构设计。
这包括系统的业务需求、技术需求和非功能性需求。
3、总体架构在本章节中，我们将介绍软件系统的总体架构，包括系统的层次结构、模块划分和各个模块之间的关系。
这将有助于开发人员理解整个系统的组织结构和流程。
4、模块设计在本章节中，我们将逐个介绍软件系统的每个模块的设计和功能。
每个模块的设计应包括该模块的输入、输出、处理逻辑和数据存储，以及与其他模块之间的接口。
5、组件设计在本章节中，我们将介绍软件系统中的各个组件（如数据库、消息队列、缓存等）的设计和功能。
每个组件的设计应包括其使用方式、配置参数和性能指标等。
6、接口设计在本章节中，我们将详细描述软件系统中各个模块和组件之间的接口设计。
这包括接口的输入、输出、数据结构和通信协议，以及接口的安全性和可靠性要求。
7、部署架构在本章节中，我们将介绍软件系统的部署架构，包括服务器的布局、网络拓扑和环境配置。
这将有助于运维人员理解系统的部署和维护方式。
8、性能和扩展性在本章节中，我们将讨论软件系统的性能和扩展性设计。
这包括系统的负载均衡、容灾备份和性能优化等方面，以确保系统能够满足预期的性能要求和可扩展性需求。
9、安全性设计在本章节中，我们将详细描述软件系统的安全性设计。
这包括用户身份验证、访问控制、数据加密和安全审计等方面，以确保系统的安全性和可靠性。
10、测试策略在本章节中，我们将制定软件系统的测试策略，包括单元测试、集成测试和系统测试等方面。
这将确保软件系统在开发过程中被充分测试，以确保其质量和稳定性。
11、运维策略在本章节中，我们将制定软件系统的运维策略，包括日志管理、监控和故障处理等方面。
架构设计师必考知识点
架构设计师必考知识点一、知识概述《软件架构设计原则》①基本定义：软件架构设计原则就像是盖房子时遵循的一些规则。
比如说，像高内聚低耦合原则，就是让软件内部各个模块自身功能紧紧凑在一起（高内聚），不同模块之间联系尽量少（低耦合），这样系统就好维护，就像一家人在自己家里各干各的事（高内聚），和邻居家往来不要太多太复杂（低耦合）。
②重要程度：在架构设计师领域，这就相当于基石，如果不遵循这些原则，软件系统后期肯定问题一堆，比如难以扩展、不好维护等。
③前置知识：得懂点基本的程序设计概念，像函数、变量是什么这些，如果这个都搞不懂，没法理解架构设计原则。
④应用价值：拿企业的ERP系统来说，如果遵循这些原则，随着企业规模扩大，员工、业务流程增加，系统就很容易扩容、修改某些功能。
要是不遵守，可能稍微加点功能，整个系统就崩溃了。
二、知识体系①知识图谱：在架构设计这里面，软件架构设计原则是核心内容。
就好比是人体的骨骼框架构建的规则。
②关联知识：和软件设计模式关系很紧密，原则是大方向，模式是实现这些原则的具体方式。
还有软件工程流程也有关联，不同的流程阶段都要考虑这些原则。
③重难点分析：掌握难度在于理解那些抽象的概念如何在实际中运用。
关键从大量的实践里体会原则的意义，不能光靠理论死记，就像学骑自行车，光看书上描述平衡感是没用的，得真骑上去。
④考点分析：在考试里非常重要，直接考查对这些原则的理解，比如给个系统案例问遵循了哪些原则，或者违背了哪些让改正。
三、详细讲解【理论概念类】①概念辨析：高内聚就是一个模块内元素关联性强，干的事紧凑。
低耦合就是模块和模块间联系松散。
像一个生产汽车的工厂，发动机车间就是高内聚的，发动机车间内部的各个工序和设备联系紧密合作来生产发动机，而发动机车间和车身车间就是低耦合，各自能完成自己主要任务，不过通过一定的方式又能组合成汽车。
②特征分析：可维护性高、扩展性好是遵循这些原则的系统的特性。
比如一个电商系统，要增加一种新的支付方式，如果设计遵循高内聚低耦合等原则，很容易就加上去了，不会影响其他功能。
软件架构设计三篇
软件架构设计三篇篇一：软件架构设计之常用架构模式1.分层架构：分层架构是使用最多的架构模式，通过分层使各个层的职责更加明确，通过定义的接口使各层之间通讯,上层使用下层提供的服务。
分层分为：严格意义上的分层，一般意义的分层。
严格意义的分层是n+1层使用n层的服务。
而一般意义的分层是上层能够使用它下边所有层的服务。
领域驱动设计的分层定义：UI层，UI控制层，服务层，领域层，基础设施层。
2.MVC架构：MVC架构相信做软件的都听说，主要是为了让软件的各部分松耦合，现在好多根据MVC思想构建的框架如：Spring MVC,Structs2, MVC等。
MVC是Model View Control的简写，他的原理是什么那，比如拿web来举例吧。
当一个web请求来了以后View接收这个请求，随即把请求转发给Control进行处理，Control通过分析请求的类型等信息决定加载哪些Model，当Model加载完成以后Control通知Model已经加载完毕，这是View就去读取Model数据进行显示自己。
MVC还有一个衍生架构叫MVP,因为MVC的View跟Control和Model 都有耦合关系所以为了解除View和Model之间的关系，View不直接读取Model 而是通过Control来转发View需要的数据。
还有一个衍生架构叫MVVP,就是增加了一个View Control的层，用来辅助视图的生成，这样View的功能更加简单只是用来显示不包含其它的功能，而且有了View Control使多视图或替换视图很方便。
MVP微软的WPF就是使用这种架构。
3.微内核架构：微内核架构就是做一个稳定通用的内核，也就是给软件设计一个强劲的心脏。
如果需要更多功能通过在内核外部再封装一层对软件进行扩充，微内核提供基本的接口供外部调用，这些接口一定要通用，并且提供事件的机制告诉外部内部发生的事件，这样就是内核与外部完全隔离。
软件架构设计说明书
软件架构设计说明书1.引言本软件架构设计说明书旨在详细描述软件架构的设计思路和实现方法。
软件架构是软件系统的重要组成部分，它决定了系统的组织结构、通信模式、性能表现和可维护性等方面。
良好的软件架构设计对于保证系统的稳定性、可扩展性和可维护性具有至关重要的作用。
2.项目概述本系统是一款面向企业内部使用的办公管理系统，旨在提高企业内部管理效率和管理水平。
系统需要实现的主要功能包括员工管理、考勤管理、公文审批、会议室管理等功能。
系统的用户群体主要包括企业管理人员、员工和第三方合作伙伴。
3.架构原则和指导在软件架构设计中，我们遵循以下原则和指导：3.1 系统分层我们将系统分为表示层、业务逻辑层和数据访问层，实现系统的分层架构。
这种分层架构有利于系统的组织和管理，同时也有利于系统的可维护性和可扩展性。
3.2 模块化设计我们将系统划分为多个模块，每个模块负责实现系统的某一方面功能。
这种模块化设计有利于系统的模块化和复用，同时也有利于系统的可维护性和可扩展性。
3.3 可扩展性我们将系统设计为可扩展的架构，以便在未来添加新的功能和模块。
这种可扩展性设计有利于系统的长期维护和发展。
3.4 高可用性我们将系统设计为高可用的架构，以便在系统中断或故障时仍能保证系统的可用性。
这种高可用性设计有利于提高用户的使用体验和系统的稳定性。
4.架构概述本系统采用分层架构，由表示层、业务逻辑层和数据访问层组成。
其中，表示层负责与用户的交互，业务逻辑层负责实现系统的核心功能，数据访问层负责与数据库的交互。
系统的主要模块包括员工管理模块、考勤管理模块、公文审批模块和会议室管理模块等。
各模块之间相互独立，通过统一的接口进行通信，实现系统的模块化设计。
5.详细架构描述5.1 表示层表示层是系统的最上层，负责与用户进行交互。
表示层主要包括用户界面、输入/输出处理和业务逻辑调用等功能。
在表示层中，我们采用了MVC （Model-View-Controller）模式进行设计，实现了界面、业务逻辑和数据模型的分离，提高了系统的可维护性和可扩展性。
软件架构设计
软件架构设计一、引言在当今IT领域，软件架构设计是软件开发过程中至关重要的一步。
良好的软件架构能够确保软件系统具备良好的可维护性、可扩展性和可靠性。
本文将对软件架构设计的概念、原则以及相关方法进行探讨。
二、软件架构设计概述软件架构设计是指在软件开发过程中对系统进行整体结构设计的过程。
它关注的是系统的组织、各个模块之间的关系以及系统与外部环境之间的交互。
良好的软件架构设计能够为开发团队提供一个清晰的蓝图，指导系统的开发和演化过程。
三、软件架构设计原则1. 模块化：将系统划分为相互独立且可重用的模块，降低系统的耦合性，提高系统的可维护性和可测试性。
2. 分层架构：将系统划分为不同的层次，每一层都有明确的职责和功能。
这样做可以将复杂的系统划分为简单的模块，便于管理和维护。
3. 松耦合：模块之间的依赖应该尽可能地低，以减少系统的风险和增加系统的灵活性。
4. 高内聚：一个模块内部的元素应该具有高度相关性，实现单一职责原则，降低模块的复杂度。
5. 可扩展性：系统的结构应该具备良好的可扩展性，以满足在未来需求变更时的系统扩展需求。
6. 可测试性：架构设计应该考虑到系统的可测试性，便于对系统进行单元测试和集成测试。
四、软件架构设计方法1. 客户需求分析：首先要从客户的需求出发，明确系统的功能和性能需求，为后续的架构设计提供依据。
2. 系统分解：将系统分解为多个模块，建立模块之间的依赖关系和交互关系，形成整体的架构结构。
3. 技术选型：根据系统需求和团队技术实力，选择适合的技术框架和工具，以支持系统的开发和维护。
4. 评估和优化：评估架构设计的可行性和风险，针对系统的性能和可靠性进行优化。
5. 设计文档编写：编写详细的设计文档，包括系统结构图、模块设计、接口定义等内容，以便团队成员理解和参考。
五、实例分析以一个电商平台的软件架构设计为例，该平台包括用户界面、订单管理、库存管理和支付系统等模块。
根据上述的架构设计原则和方法，可以将该系统划分为用户接口层、业务逻辑层和数据层三个层次。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
<Project Name> Software Architecture DocumentVersion <1.0>目录1. 文档简介61.1 文档目的61.2 文档范围61.3 定义、缩写词和缩略语61.4 参考资料72. 架构描述方式72.1 架构视图阅读指南72.2 图表与模型阅读指南73. 架构设计目标83.1 关键功能83.2 关键质量属性83.3 业务需求和约束因素84. 架构设计原则94.1 架构设计原则94.2 备选架构设计方案及被否原因94.3 架构设计对后续工作的限制（详设，部署等）95. 逻辑架构视图105.1 职责划分与职责确定115.2 接口设计与协作机制115.3 重要设计包126. 开发架构视图126.1 Project划分136.2 Project 1 146.2.1 Project目录结构指导146.2.2 程序单元组织146.2.3 框架与应用之间的关系（可选）156.3 Project 2 (15)6.4 Project n (16)7. 运行架构视图167.1 控制流组织167.2 控制流的创建、销毁、通信177.3 加锁设计178. 物理架构视图188.1 物理拓扑188.2 软件到硬件的映射198.3 优化部署199. 数据架构视图209.1 持久化机制的选择209.2 持久化存储方案209.3 数据同步与复制策略2110. 关键质量属性的设计原理211.文档简介[帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。
]1.1文档目的[文档目的，非项目目的。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。
]1.2文档范围[文档的Scope，非项目的Scope。
否则造成同一项目多个文档之间的内容重复，不利于文档维护。
]1.3定义、缩写词和缩略语[集中列举文档中的定义、缩写词和缩略语。
]1.4参考资料[本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用的文件资料，如软件开发标准。
具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。
]2.架构描述方式[为了让读者更好地理解《架构文档》，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。
]2.1架构视图阅读指南[以多视图的方式来组织《架构文档》是大势所趋。
推荐的是经过优化的5视图方法，如下图所示。
]2.2图表与模型阅读指南[对后续文档内容中所用到的建模语言（例如UML）、表格（例如目标-场景-决策表）等进行说明。
]3.架构设计目标[功能、质量、约束，一个都不能少。
]3.1关键功能[对架构设计至关重要的功能，包括如下4类：核心功能、必做功能、高风险功能、独特功能。
所谓独特功能，指这个功能覆盖了上述3类功能没有涉及到的职责。
]3.2关键质量属性[人之所以痛苦，很多时候是因为追求错误的东西。
下图是确定关键质量的5大原则的整体思路图。
]3.3业务需求和约束因素[创造性地提出约束需求的4大类型，这是一种极为实用的分类方式。
特别是业务需求对架构设计而言是一种约束的观点，解决了很多架构师的现实困惑。
下图标明了4类约束在“需求层次-需求方面矩阵”中的位置，可以帮助我们理解产生约束需求的根源。
]4.架构设计原则[投标时经常讲“架构设计原则”，但到了《架构文档》，这些着眼大局的考虑却“丢了”。
推荐的本文档模板，认为应当把它们“找回来”。
]4.1架构设计原则[着重描述重大的权衡取舍考虑。
]4.2备选架构设计方案及被否原因[在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因。
这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设计方案的认可度。
]4.3架构设计对后续工作的限制（详设，部署等）[架构设计不仅应该包含“指导”，也应该包含重要的“限制”。
例如，一份只是说明“性能和可扩展性都重要”的《架构文档》，实际上忽视了“可扩展性和性能之间存在的矛盾关系”。
此时，最有效的办法就是在《架构文档》中明确说明“任何提升可扩展性的架构设计和详细设计，都应通过架构团队的评审才能引入，以确保性能目标不受重大影响”。
]5.逻辑架构视图[关注点：此架构设计视图的关注点是职责划分。
][注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 = 模块 + 接口”等以偏概全的认识。
][参考：任何复杂系统的架构设计都不是一蹴而就的，所以架构师需要理性思维过程的指导。
针对逻辑架构设计这个关键环节，《一线架构师实践指南》一书给出了2条建议：一是“以质疑驱动的螺旋思维”，二是相对分离地考虑“结构方面的切分”和“行为方面的定义”。
下图所示即为推荐的逻辑架构设计理性思维过程。
]5.1职责划分与职责确定[内容：将系统切分成更小的单元，并明确这些单元的职责。
具体而言，职责单元可以是层、子系统、模块、关键类等。
][意义：一句话，职责划分不合理，功能和质量都会受到影响。
也就是说，功能需求和质量需求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完成的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性要求做出相应调整和优化。
很多人认为架构设计就是职责划分的艺术，虽略显片面，但足以表明职责划分的重要性。
][参考：基于对业界大量案例的研究，梳理出了“模块划分的3种必用手段”，如下图所示，更多内容可参考《一线架构师实践指南》一书。
]5.2接口设计与协作机制[内容：本节描述接口的定义，以及协作的方式和规范。
][意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证。
][参考：推荐利用“包-接口”图，来识别接口。
下图为一个“包-接口”图的示例。
][参考：推荐使用序列图，建议少用、甚至杜绝使用协作图。
下图为一个序列图的示例。
]5.3重要设计包[内容：对重要子系统的设计进行“灰盒”级描述。
][意义：“每个子系统在架构设计中都应保持黑盒子”的观点，过于理想化了。
对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。
][参考：类图和灰盒包图，在本节中较多出现。
下图为一灰盒包图示例。
]6.开发架构视图[关注点：此架构设计视图的关注点是程序单元组织。
][注意：此架构设计视图是必须的、不应“剪裁”掉的。
但实际情况却是，很多架构师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架构对编程工作没什么指导性”。
]6.1Project划分[内容：本节说明整个系统将划分成哪几个Project来开发，其中，Project 指开发环境所感知到的“工程”。
][意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了Web应用、桌面应用、嵌入式应用等软件形态，所以此时Project划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单独的Project以进行独立的软件配置管理（SCM），以降低核心代码外泄的风险。
][参考：Project划分必然是属于“架构设计”的工作，严格来讲仅靠“需求分析”划分的业务域（Business Area）直接映射到Project经常意味着工作内容的遗漏。
其实，业界不少有见地的专家已经认识到WBS（工作分解结构）做得太早太草率危害很大，就与“Project划分不到位”不无关系。
]6.2Project 1[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]6.2.1Project目录结构指导[内容：关于该Project一级目录、二级目录等基本目录结构的约定。
][意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。
][参考：不要把所有程序目录的约定都定义得太细，否则这份《架构文档》就要天天更新了。
]6.2.2程序单元组织[内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。
][意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。
君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译源码的开发环境都建不起来——其实，他们“不知道Project所依赖的Library有哪些”是其中重要原因——这本应在《架构文档》中给出明确描述的。
]6.2.3框架与应用之间的关系（可选）[内容：框架（Framework）。
][意义：既然不适用Framework的开发越来越少了，既然程序员犯的很多错误都和对Framework理解不到位有关，架构师就有责任明确说明Framework 和待开发系统之间的关系。
][参考：下图描述了JGraph框架和待开发应用的关系。
][参考：下图描述了Struts框架和待开发应用的关系。
]6.3Project 2……[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]6.4Project n……[内容：对Project划分后的每个Project进行目录结构、程序单元组织、框架与应用关系的说明。
]7.运行架构视图[关注点：此架构设计视图的关注点是控制流组织。
][注意：进程和线程是广为人知的控制流实现技术，但在架构设计思维当中，对于系统软件和嵌入式软件极为重要的中断服务程序也是控制流，这样利于架构师统一利用不同控制流手段设计并行和并发。
]7.1控制流组织[内容：控制流有哪些，每条控制流各是何种形式（例如进程、线程、中断服务程序），哪些软件单元是控制流的起点，整条控制流中分别调用了哪些软件单元。
][意义：这是对系统运行时结构的刻画，主要反映系统的动态结构。
]7.2控制流的创建、销毁、通信[内容：描述进程、线程和中断服务程序的创建和销毁，以及多条控制流之间的通信关系的定义。
][意义：一旦引入了多条控制流，附加工作就产生了——此时控制流的创建和销毁、以及控制流之间的通信关系往往是必须考虑的。
]7.3加锁设计[内容：系统中有多条控制流在同时运行的情况下，一个经典问题是多于一条控制流可能会同时修改某些数据结构，而造成数据的不一致。
为此，架构师需要关注加锁设计，合理引入临界区或同步机制。
][意义：加锁设计事关系统的正确性。
值得注意的是，忽略加锁设计造成的问题往往以“不易重现的Bug”的形式出现，困惑的程序员会对测试人员说，“你看你报的Bug在我机器上根本就不存在呀”。
][参考：对通用组件、通用模块的设计而言，加锁设计应予以专门关注，思维要点是研究未来通用模块的各种可能使用场景。
]8.物理架构视图[关注点：此架构设计视图的关注点是物理节点（Node）分布，以及软件到硬件的具体映射关系。