软件架构设计标准 (IEEE 1471 2000) ——极简教程

原创

禅与计算机程序设计艺术 2022-06-07 19:46:21 ©著作权

文章标签 java 人工智能机器学习大数据编程语言 文章分类 架构后端开发

©著作权归作者所有：来自51CTO博客作者禅与计算机程序设计艺术的原创作品，请联系作者获取转载授权，否则将追究法律责任

What Is Architecture?

软件系统的架构是一个隐喻，类似于建筑物的架构。

架构(Architecture)这个词来源于建筑学。

IT这个行业中的词汇许多都来源于传统行业。传统行业发展了很多年，有一套成熟的理论，而软件设计这个行业才几十年，在实践中，为了提高生产效率和品质，工程化是一个必然化的趋势，于是传统行业工程化的理论和实践就有了在软件设计这个行业移植的可能性。

在建筑行业或者机械设计行业，在建筑建造出来或者产品加工出来之前，设计人员用图纸来表达自己的设计意图。当然成熟的设计人员在取得认证之前，需要到施工单位或者到加工车间实习很长时间，以防止设计出来之后，无法建造或加工。

Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
架构：一个系统的基本组织，体现在它的组件中，它们之间的关系，以及与环境的关系，以及指导其设计和进化的原则。

“软件架构”一词直到 1990 年代才得到广泛使用。计算机科学领域自形成以来就遇到了与复杂性相关的问题。

开发人员通过选择正确的数据结构、开发算法和应用关注点分离的概念来解决早期的复杂性问题。尽管“软件架构”这个词对业界来说相对较新，但自 1980 年代中期以来，该领域的基本原则已被软件工程应用。

软件架构作为一个概念起源于1968 年的Edsger Dijkstra和1970 年代初的David Parnas的研究。这些科学家强调，软件系统的结构很重要，正确的结构至关重要。在 1990 年代，人们齐心协力定义和编纂该学科的基本方面，研究工作集中在架构风格(模式)、架构描述语言、架构文档和形式化方法上。

研究机构在推动软件架构作为一门学科方面发挥了重要作用。卡内基梅隆大学的Mary Shaw和 David Garlan在 1996 年写了一本名为《软件架构：新兴学科的观点》的书，其中推广了组件、连接器和样式等软件架构概念。加州大学欧文分校软件研究所在软件架构研究方面的工作主要针对架构风格、架构描述语言和动态架构。

IEEE 1471 -2000，“软件密集型系统架构描述的推荐实践”，是软件架构领域的第一个正式标准。它于 2007 年被 ISO 采用为ISO/IEC 42010:2007。2011 年 11 月，IEEE 1471–2000 被ISO/IEC/IEEE 42010:2011取代，“系统和软件工程 – 架构描述”(由 IEEE 和 ISO 联合发布)。

在IEEE 1471中，软件架构是关于“软件密集型系统”的架构，定义为“软件对整个系统的设计、构建、部署和演化产生重要影响的任何系统”，

2011 年版更进一步，包括ISO /IEC 15288和ISO/IEC 12207对系统的定义，这些定义不仅包括硬件和软件，还包括“人、流程、程序、设施、材料和自然发生的实体”。这反映了软件架构、企业架构和解决方案架构之间的关系。

关于软件架构的范围

宏观系统结构：这是指架构作为软件系统的更高层次的抽象，它由一组计算组件以及描述这些组件之间交互的连接器组成。
识别关键问题：这是指软件架构师应该关心那些对系统及其利益相关者有重大影响的决策。
一组架构设计决策：软件架构不应仅被视为一组模型或结构，而应包括导致这些特定结构的决策及其背后的基本原理。
软件架构与设计和需求工程之间没有明显的区别，它们都是从高级意图到低级细节的“意图链”的一部分。

软件系统架构概念框架

软件架构设计标准 (IEEE 1471 2000) ——极简教程_java

图中的方框表示架构设计文档中需要描述的要素，要素之间的连线表示这些要素之间的关系。整个图分五层：

第一层：Mission

第二层：Environment，System，Architecture

第三层：Stakeholder，Architectural Description，Rationale

第四层：Concern，Viewpoint，View

第五层：Library Viewpoint，Model

第一层：Mission

Mission, 翻译成中文就是任务，使命。也就是为什么我们要做这个系统。可能的原因是为了更大的赢利，市场占有率更高，完善产品系列等等。

第二层： System/Environment/Architecture

System, 翻译成中文就是系统。具体的定义是：一系列组件，组织在一起，相互作用从而完成一个或者一些特殊的功能。

Environment：系统不可能单独存在，它总是存在在一个环境之中。我们将系统范围之外的东西，对系统有影响，有交互的客观存在定义为环境(Environment).有时也称为系统的上下文(context)。

Architecture：系统架构。每个系统有一个架构。无论你是有意设计而形成，或者自发形成。

第三层：System stakeholder/AD/Rationale

系统利益攸关方。(An individual, team, or organization with interests in, or concerns relative to, a system)。从图中我们可以看出一个系统有一个到多个利益攸关方。

Architectural Description：简称为AD。直译为系统描述。从图中我们可以看出，一个系统架构，有一个系统描述和它对应。系统描述是由stakeholder来识别出来并整理成文。

Rationale：从字典上查下来的含义是：基本原理，根本原因。那么在架构描述文件中要出现那些“基本原理”和“根本原因”呢？个人以为：

在设计软件架构时，我们做了许多取舍，选择。我们需要列出之所以选择A而不是B的理由
架构设计是如何满足功能性需求和非功能性需求。

第四层：Concern/Viewpoint/View

Concern：翻译成中文是关心点，关注点。从图中，我们可以看出concern是和stakeholder联系在一起。利益攸关方有一个或多个concern。通常不同的利益攸关方其关注点不尽相同。有时甚至是矛盾的。抄录一段英文：concerns are those interests which pertain to the system’s development , its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, distribution and evolvability.

Viewpoint：我将它直译成观察点。就是你站在什么地方来看这个系统。不同的stakeholder可能有不同的concern，从而导致不同的观察点。

View：我将它直译成视图。就是stakeholder站在某个观察点，他看到系统是个什么样子。视图和观察点一一对应。