IEEE-1471

目前我所知道的，被普遍认同的架构描述 (Architecture Description) 的标准是 IEEE 1471 - 2000 标准。经过同其他架构设计方法和框架的比较研究，该标准更确切的说，应该是架构描述的元模型，同 CWM, SPEM 类似，都是处于 MOF 四层模型的第三层， M2 层 ( 如下图 ) 。为了介绍什么是架构，什么是架构描述等基本概念，这里首先引入 IEEE1471-2000 标准，通过对该标准的介绍，能够有助于澄清一些基本概念。

 

IEEE 1471 -2000 的全称是： IEEE's Recommand Practice for Architectural Description of Software-Intensive Systems. 由 IEEE 架构工作组 (Architecture Working Group) ，代表了工业界，其他标准化组织和学术界的意愿，以及通过了超过 150 位国际评审员的评审，而最终发布。 IEEE 建起了在架构描述 (Architecture Description - AD) 的一组内容需求 (content requirements) 。例如：该标准指出了架构描述应该被如何组织的缘由，同时又 :(1) 抽象于特定的媒介（ text, html, xml ） ; (2) 是方法中立的（它将被用于各种现存的和新的架构设计方法和技术）； (3) 并且是记法中立的，认识到需要许多的不同的记法来记录架构的不同方面。

 

该标准通过基于一组架构描述的概念框架来达成上述目的。该框架的广度是值得理解的，相对与架构研究和实践的当前工作而言。对于我来说，在概念框架中的大多 数这些工作专著在什么被刻画成模型，包括架构描述语言和相关工具。同样重要的是，大多数这些工作缺乏一个在大多数实际的、工业级别的应用所需要的更大的上 下文环境。通过正式的称谓，象 Stakeholders 和 Concerns ， IEEE 1471 框架建议了一个基础，来解决在架构描述理论中的问题。

 

系统是为完成特定的功能或功能集合而组织起来的组件的集合。

 

系统的架构是系统组件的基本组织形式，它们之间的以及和环境之间的关系，以及指导其设计和演化的原则。

 

架构描述是为用文档描述架构而得到的一组工作成果的集合。

 

利益相关人是那些具备关键角色，或关心系统的人，例如：用户，开发人员，或管理者。在系统中，具备不同的角色的不同利益相关人会有不同的关注点。利益相关人可以是个人，团队或组织（或一类组织）。

 

关注点是在系统中对利益相关人重要的兴趣点，并且决定系统的可接受性。关注点可能会涉及到系统的任何方面，功能性，可开发性，或可操作性，包括确认如性能，可靠性，安全性，分布式特性，和可发展性等。

 

视图是从相关的一组关注点投射的整个系统的一个表示。

 

为了捕获或表示系统架构的设计，架构设计师一般会创建一个或多个架构模型，可能用不同的工具。视图由这其中选择出来的一个或多个模型组成，选择这些模型是为了展示个一个或一组利益相关人，以便他们的关注点在设计系统架构的过程中获得了主够的关注。

 

视点定义了获得视图的角度。更精确的说法是，视点定义了：如何构造和使用视图（通过指定模式或模板）；那些信息应该在视图中出现；表达和分析信息的建模技术；这样选择的理由（比如描述视图的目的和目标客户。）

 

系统的模型是为了某种目的的对系统及其环境的描述或规格说明。模型常常被表示成图形和文本的组合。可以是建模语言或自然语言。

 

总结上面的称谓：系统的架构应由多个视图来描述（作为架构描述），视图应该符合视点，每个视图的架构描述的文档必须有理论基础（理由）；比如它必须符合一个或多个利益相关人的关注点。

 

IEEE 1471 中的内容需求由概念框架中的称谓来申明。这些需求定义了架构描述符合标准的含义。在这些需求中的原理总结如下：

 

架构描述是兴趣相关的：架构描述的读者是系统不同的利益相关人，每个都有其特定的对架构的关注点（比如安全、性能、或可构造性）。架构描述必须显示的提到这些利益相关人。从而，架构描述必须显示的识别系统的利益相关人和他们对系统的关注点。

 

关注点形成完整性的基础：某个架构描述必须写下所有利益相关人的关注点。如果没有，根据定义，就是不完整的。

 

多视图：某个架构描述被组织成一个或多个视图。每个视图是整个系统的兴趣的表示，从而写下特定的一组利益相关人关注点。

尽管使用视图是新困难，它也推动了使用视图来写下特定利益相关人的特定关注点。

 

视图是模块化的：某个视图可由一个或多个架构模块组成。为了满足由特定视图所诉求的关注点，可以使用多种记法。这是 IEEE 1471 中几处可参数化的其中一处，以适应在软件架构建模实践中最佳实践的广泛。

 

视图间一致性：架构描述必须文档化其所包含的视图中的任何不一致性。这相对来说是较弱的需求 － 基于当前的认同；我想将来我们能够做得更好。

 

视图是形式良好的：每个视图有一个下层的视点，以标示出一组架构关注点和指定架构描述如何满足这些关注点，使用语言和记法，模型，分析技术和方法。视点是一组构建，解释和分析视图的约定。

这是IEEE 1471 中另一个可参数化的地方。组织可以定义并选择他们自己有用的视点。实际上，IEEE 1471 甚至没有指定一组固定的视点；关于视点从哪儿来，标准是“ 不可知论” 。作为替代，可应用下面的原理：

 

关注点驱动视点的选择：每个识别出的利益相关人的关注点必须由其中一个选择的视点来记述。

 

视点是一类的：每个视点在架构描述中使用前都需要先申明（或者在线，或者通过引用）。视点申明建起了由视点记述的利益相关人；利益相关人的关注点由视点记 述；视点的语言，建模技术，或分析方法在其中使用；并作为视点的来源。视点也可以包括：同将应用到视图中的模型上的底层方法相关联的一致性和完整性检查； 同将应用到视图中模型上的任何评估和分析技术；和任何启发式的，模式或在合成相关视图和其模型有帮助的指南。

该原理可能是IEEE 1471 最主要的贡献 － 提供了那些今日使用的许多架构技术的内涵，从而可以被一致的描述，从而可以互用，比较和结合。

 

除了编码在架构描述中的当前最佳实践， IEEE 开发 IEEE 1471 标准的一个目的是提供一个软件架构规程持续进化的一个基础。为了这个结论，我简要的指出几个这样的机会。

 

重用。视点，是独立与系统的，高度可重用。视点构建的目的是捕获一类重要的架构知识：何时应用给定的表达机制来记述特定利益相关人的关注点。然而，只有很 少的当前架构知识是这样捕获的。例如，在建模架构的学术文献中有更多工作是通过组件端口，连接器，角色，和它们的配制，更应该被称为 “ 结构视点。 ” 通过清晰的视点声明，将会更容易的，一致的应用这些知识。对于象 SEI 这样的组织，其中一个有用的角色是作为可重用视点的库。

 

视图检查。 IEEE 1471 在检查和分析个别视图的问题上保持了沉默，除了说视图必须对其视点来说是形式良好的 － 将检查代理给了同视点相关的其他技术。

 

视点在其活力，相关的分析技术等方面不同，这可能是沿用了对视图检查的做法。通过提供一致的申明，就有可能拿起一个为某个记法开发的技术而用于另一个。看看在使用不同的 UML 记法方面的上下文方面的争论。

 

视图集成和视图间一致性 早就认识到，导入多视图到架构描述中会引起集成问题 － 如何保持视图一致性，不重叠？

 

引起不同的记法。 … 这会引起多视图问题：不同的规格说明描述不同，但是重叠的问题。

 

引入视点声明，并每有解决问题，给我们一个工具用来检测重叠和不一致性，并潜在的解决重叠问题。

 

形式化。IEEE 1471 的概念框架是一个非正式的，定性的模型。如果它有用，现在好像是这样，尝试形式化其中蕴涵的概念是明智的。该形式化可能对刚刚提到的几个主题是有益的：视点重用，视图检查，视图集成和试图间分析。

最后，在架构描述中还有其他先进的主题很少被今天的语言和工具所记述。