本文共 6551 字，大约阅读时间需要 21 分钟。
软件架构设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述了解软件架构的含义和怎样设计软件架构。
一、软件架构师的职责
架构师分为以下几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（J2EE架构师、.NET架构师等）、系统架构师。
1、架构师的职责主要体现
架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面：
1）、负责公司系统的架构设计、研发工作。
2）、承担从业务向技术转换的桥梁作用。
3）、协助项目经理制定项目计划和控制项目进度。
4）、负责辅助并指导系统分析开展设计工作。
5）、负责组织技术研究和攻关工作。
6）、负责组织和管理公司内部的技术培训工作。
7）、负责组织及带领公司内部员工研究与项目相关的新技术。
8）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。
9）、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。
10）、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。
2、构架设计师必须具备的技能
经验：既包括在问题领域的经验（通过彻底了解需求），也包括在软件工程领域的经验。对于一个构架团队，这些素质要求可由各团队成员来分别承担，但其中至少要有一名构架设计师能够把握项目的全局。
领导才能：能够推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻到底。要提高效率，构架设计师和项目经理必须紧密协作。构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。构架设计师必须有权在技术问题上作出决定。
沟通：能够赢得他人的信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必须要赢得项目中其他人员的赞同。为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。
以目标为中心、积极主动：不懈地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师只有将注意力集中在该做的事情上，才能在项目中取得成功。
专业：精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。
二、软件架构、架构模式、参考模型、参考架构
1、对于软件架构定义有很多种，通用的定义是：某个软件或计算机系统的软件架构是该系统的一个或多个结构，他们由软件元素，这些元素的外部可见属性以及这些元素之间的关系组成。
这里所说的某个元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。
其他的定义包括：架构是一种高层设计。架构是系统的总体结构。架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。架构是组件和连接器。
2、架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。
3、参考模型是一种考虑数据流的功能划分。
4、参考架构是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。
5、软件架构、架构模式、参考模型、参考架构之间的关系：
软件结构 | 关系 | 适用环境 |
分解 | 是一个子模块；与之共享秘密 | 资源分配、项目结构化和规划；信息隐藏、封装；配置控制 |
使用 | 要求正确出现 | 设计子集；设计扩展 |
分层 | 要求正确的出现、使用服务、提供抽象 | 增量式开发；在“虚拟机”可移植性之上实现系统 |
类 | 是一个实例；共享访问方法 | 在面向对象的设计系统中，从一个公共的模版中产生快速的、相近的实现 |
客户机-服务器 | 与之通信；依赖于 | 分布式操作；关注点分离；性能分析；负载平衡 |
进程 | 与之并发运行、可能会与之并发运行；排除；优先于等 | 调度分析；性能分析 |
并发 | 在相同的逻辑线程上运行 | 确定存在资源争用，线程可以交叉、连接、被创建或被杀死的位置 |
共享数据 | 产生数据；使用数据 | 性能；数据完整性；可修改性 |
部署 | 分配给；移植到 | 性能、可用性、安全性分析 |
实现 | 存储在 | 配置控制、集成、测试活动 |
工作分配 | 分配到 | 项目管理、最佳利用专业技术、管理通用性 |
注：在＜Pattern-Oriented Software Architecture (面向模式的软件体系架构) ＞中首次提出了8种体系结构模式： 层（Layers）、管道和过滤器(Pipes and Filters) 、黑板(Black board )、代理者（Broker）、模型-视图-控制器（Model-View-Controller）、表示-抽象-控制（Presentation-Abstraction-Control）、微核（Microkernel）、映像（Reflection）。
6、架构定义中指出系统由多种结构构成的，下面列出一些常见的结构。
7、质量属性
系统从设计、实现到部署的整个过程中考虑质量属性的实现。质量属性包括下列三类：
（1）、系统的质量属性。（可用性、可修改性、性能、安全性、可测试性和易用性）
（2）、受架构影响的商业属性。（上市时间、成本和收益、所希望的系统生命期的长短、目标市场、推出计划、与老系统的集成）
（3）、与架构本身相关的一些质量属性。（概念完整性、正确性与完整性、可构建性）
六个质量属性的战术列表：
三、设计架构
几乎在我们遇到的所有成功的面向对象系统中都具有但失败的系统中缺少的两个特性是：存在一个强大的构架构想，应用管理良好的迭代式增量开发周期。功能、质量和商业需求的某个集合“塑造”了构架。我们把这些塑造需求称为“构架驱动因素”。
构架设计必须按需求分析进行，但不需要在需求分析完成后在开始构架设计。实际上，在确定了关键的构架驱动因素后，就可以开始构架设计了。当设计了构架的足够多的部分后，就可以开始开发骨架系统了。该骨架系统在上面进行迭代开发（以及其在任何一个点交付的能力）的框架。组织结构对构架产生影响。
属性驱动的设计(ADD)是一个用于设计构架以满足质量需求和功能需求的方法。ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。
ADD步骤：
（1） 选择要分解的模块。
（2） 根据这些步骤对模块进行求精。
对需要进一步分解的每个模块重复上述步骤。
在设计架构过程中可以重用架构，重用一些技术以方便来实现架构与设计。高层重用技术分类
|
|
| 高层重用 |
| 设计模式 |
| 框架 |
| 软件架构 |
| 架构风格 |
| 架构设计风格 |
| 架构框架 |
| 架构平台 |
框架：提供一组相互协作的类及运行时对象，用于生成某些特定领域的应用软件。我们可以根据特定应用的需求方便地对框架中的抽象和类进行定制，以重用框架的设计和代码。
软件架构：编制软件也称为架构软件。一个可操作的软件内部应具有某种形式的架构。软件架构技术中可重用的实体可以进一步地分为4类：架构风格、架构设计风格、架构框架、架构平台。
架构风格给出了精心设计的软件全局的通用形态。例如，Shaw和Garlan提出了7种架构风格：管道和过滤器、面向对象的组织、隐式调用、分层系统、仓库、状态机、解释器，及过程控制。
架构设计风格给出了软件架构的设计方法论。Shaw将众多的设计风格分类为如下8种：功能分解、数据流、面向对象、状态机、面向事情、过程控制、数据结构及决定表。
架构框架是来为详细而完整的框架，它为开发特定领域的应用系统使用了一系列多种架构设计风格。一个采用了某些设计风格的软件架构制品，只有当它具有完备的文档，并具备包含一个特定的应用领域所需要的充分灵活性时才可以作为软件框架来重用。
架构平台提供了一个可以适应多种应用系统的灵活的底层结构，架构平台的设计目的即是为了应用软件的互操作性提供硬件平台及操作系统平台无关环境。我们可以将它们用做底层结构，以促进对象级的协作和重用。对象管理组织(OMG)的通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）即是一个示例。
四、架构评估方法
软件构架的评估方法：SAAM和ATAM。这里只详细说明ATAM方法。
ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每个高优先场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。
ATAM不是需求评估。
ATAM不是代码评估。
ATAM不包括实际的系统测试。
ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。这些风险包含在敏感点和权衡中。
ATAM活动的4个阶段：
在第0阶段（合作关系和准备）确定细节：人员名单，时间，地点；评估小组获取资料并进行初步了解分析。
第1阶段，评估阶段，决策者参与，小组开始信息收集与分析；耗时约1周。1～2周中断期，评估小组进一步以非正式方式了解构架。
第2阶段，评估阶段，涉众参与，分析继续；约2天。
第3阶段，后续阶段，生成最终报告，进行评估活动总结；1周。
评估阶段的步骤：
第1步：ATAM方法的表述。评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局。
第2步：商业动机的表述。决策者介绍系统商业动机、重要功能、各种限制（任何相关的技术、管理、经济和政治限制）、商业目标和上下文、主要的涉众、驱动因素等。
第3步：构架的表述。首席设计师或架构小组介绍构架，技术限制、所用模式等。
第4步：对构架方法进行分类。评估小组利用所有已知信息对构架方法进行分类。
第5步：生成质量属性效用树。生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；此处场景具备刺激、环境、响应三要素就可以了。
第6步：分析构架方法。评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点。
经过一段中断期，第2阶段开始，此时涉众开始参与；首先仍然需要一个对ATAM方法的介绍，并使涉众了解已有的成果。
第7步：集体讨论并确定场景的优先级。集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度。
第8步：分析构架方法。分析新的高优先级的场景，构架师解释构架是怎么满足各场景的。
第9步：结果表述。总结评估结果，评估负责人展示该结果。
五、软件架构风险管理
1、如何识别软件架构的风险
（1）需求的不断变化
（2）架构师对于技术理解不足
（3）缺乏对行业的研究
（4）经验不足
（5）创造性的架构比重比较重
（6）没有形成一套构架的规范
（7）架构可执行性差
2、如何规避软件架构风险
固化需求
完善的业务原型
完整架构规范
验证架构的可执行性
80%的经验架构+20%的创新架构
六、实用软件体系结构
本部分是提供实用的指南和技术，以更快地得到好的系统结构设计。我们的哲学是不应该致力于设计理想化的系统结构，而是应该仔细地评估和权衡所有技术、市场、人员、成本方面的问题，从而获取一个好的解决方案。
4种视图+全局分析
1、4种视图
1）、一个软件体系结构有4种截然不同的视图：概念视图、模块视图、执行视图、代码视图。
使用这个4种视图提供了一种设计软件系统结构的系统化方法，帮助架构师设置优先级，分析权衡，并保证没有缺漏。
2）、不同视图强调的不同工程关注点：
在概念视图中，问题和解决方案主要通过领域术语来考虑的。对于特定的软件及硬件技术，它们应当是相对独立的。概念视图的工厂关注点包括：
系统如何满足需求？
商用构件怎样组装成整体，怎样在功能层上与系统的其他部分交互？
领域特定的硬件和软件如何融入系统？
功能是如何被分割并进入产品个版本的？
系统如何与之前版本的产品合并？它如何支持未来的版本？
如何支持产品线？
如何将由需求或领域中所做的变动引起的影响最小化？
在模块视图中，概念视图中的构件和连接子被映射为子系统和模块。在这里，架构师强调的是如何用现有的软件平台以及技术实现概念的解决方案。主要的工程关注点有如下几点：
产品是如何映射到软件平台的？
使用了什么样的系统支持或系统服务？具体是在什么地方？
怎么支持测试？
如何降低模块间的依赖性？
如何将模块与子系统的复用最大化？
当商用软件、软件平台或标准发生变动时，采用何种技术在封装产品时可以将它们与产品进行隔离？
执行视图描述模块如何映射到运行时平台说提供的元素，以及这些又如何映射到硬件体系结构。执行视图定义系统的执行时实体及其属性，比如内存使用和硬件分配。对于执行视图，其工程关注点如下：
系统如何满足性能、恢复及重新配置方面的需求？
如何平衡资源的使用（例如：负载平衡）？
如何达到必需的并发、复制及分布，而不过度增加控制算法的复杂度？
如何使运行时平台的改变所引起的影响到达最小？
在代码体系结构视图中，架构师决定执行视图中的执行时实体如何映射到部署构件（例如：可执行构件），决定模块视图中的模块如何映射到源构件，以及部署构件如何从源构件生成。代码视图中重要的工程关注点如下：
如何降低产品升级的时间和费用？
如何管理产品版本及发布？
如何降低构造时间？
需要什么工具支持开发环境？
如何支持集成与测试？
2、全局分析
全局分析是在定义概念、模块、执行和代码系统结构视图之前进行的，并贯穿整个系统结构的设计过程。
全局分析从识别影响体系结构设计的因素来分成3类：组织因素、技术因素、产品因素。
组织因素分成5类：管理；员工技能、兴趣、能力、缺点；过程与开发运行环境；开发进度；开发预算。
技术因素包括：通用和专用的硬件；操作系统、用户界面、设计模式等软件技术；模版和框架等体系结构技术；图像、数据库、数据格式、算法和技术之类的标准。
产品因素是描述了产品的功能需求、用户可见的特征和产品的性能等质量方面的需求。比如：功能特征；用户界面；性能；依赖性；错误监测、报告、修复；服务和价格等。
全局分析是在每一种体系结构设计视图中都要进行的一种行为。在全局分析过程中建立的问题卡片要用在每一个视图设计的核心设计任务中。在进行核心设计任务时，做出的决策应当可以返回到全局分析，以增加和修改因素、问题和策略。
总结策略：
问题 | 应用策略 |
进度紧迫 | 复用内部已有的、领域特性构件 购买而不是建立 使元素容易添加和删除 |
技能不足 | 避免使用多线程 封装多进程 |
通用和领域特定硬件的改变 | 封装领域特定硬件 封装通用硬件 |
软件技术的改变 | 使用标准 为外部构件开发产品特定的接口 |
资源有限 | 限制活动线程个数 用动态的内部线程见通信联系 |
易用增加和删除特性 | 按关联尺度分离构件和模块 特性封装到分开的构件 分离用户交互模块 |
易用增加和删除采集过程和算法 | 为图像处理使用灵活的流水线模块 为采集和图像处理引入构件 分离用户交互模块 |
高吞吐量 | 把独立的控制线程映射到进程 使用新增的CPU |
实时采集性能 | 从没有临界时间构件中分离出有临界时间的 为模块行为开发准则 灵活的分配模块到进程 |