本文将解读标准IEEE Std 1471-2000（密集型软件的体系结构描述推荐实施规程）的概念模型图部分，从中一窥作为软件架构师的进行架构设计的思考角度与策略。如果我们把世界当做一场游戏，现在要玩的就是策略游戏而已。
说明：
IEEE 1471是适用于软件密集的系统，其目标在于：便于体系结构的表达与交流，并通过体系结构要素及其实践标准化，奠定质量与成本的基础。
细读这个标准，可以加强策略游戏的装备，全新上战场。
基本概念
IT框架的设计者必须是杰出的问题驱动者，设计往往是一个模糊的，非理性的过程，基本概念掌握后，相当于准备好攻击的工具了。
什么是密集型系统呢？1471中的框架标准，主要是针对密集型系统（software-intensive 也称作增强型软件），是指软件对于整个系统的设计、构建、部署和评估有重要影响的任何系统。
除了软件体系架构描述的概念贯穿标准始末，还有两个概念：视图（view）和视点（viewpoint），是在整个框架中将大量会使用到。
视图：是指从相关的关注点的角度来看整个系统的表示。
视点：则是构造和使用视图的约定规范。是一种模式和模板。
他们的关系是：view是表达系统架构在viewpoint中所定义的关注点的表达，而viewpoint是定义了一种语言或方法来描述这些view。他们就类似viewpoint探照灯和人们通过探照灯点亮而看到的view。
至于System StakeHolder（SH 利益相关者）、Architectural Description（AD 架构描述）、Acquirer（需方）、Concern（关注点）这样的概念会穿插在概念模型中介绍。
AD架构描述：是指一组用于记录体系结构的产品，如文档集等。
Acquirer：一个从供方那里采购系统、软件产品或软件服务的组织。（需方可以是买家、客户、所有者、用户或购买者）
软件体系架构概念模型
我们说，架构定义阶段一般在软件生命周期中，位于需求分析和设计阶段之间。在这个阶段要考虑到利益以及涉及利益者的利害关系，由此来形成一个均衡的解决方案。
下图是IEEE Std 1471标准的核心，是一张用UML来表达体系架构要素之间关系的一张重要图示，读懂了这张图，作为架构师将具有有居高临下的大览之心。只要会UML语言，我们就可以很轻松的来解读它。
该图将要素以分层的方式，关联和聚合的概念，表述体系结构中不同要素之间的重要关系。让我们来一一分解。
第1层：Mission（任务）
系统的存在是为了在某种环境里履行1个或多个任务。一个任务（mission）是指一种使用或操作，是一个系统想要满足由一个或多名利益相关者的目标。如图所示Mission只关联System，因此其实框架的起点可以看作是下一层的System。
第2层： Environment、System、Architecture
是从System开始的。这里的系统是个广义的统称，包含：应用程序、传统意义的系统、子系统、系统的系统、产品线、产品组、整个企业或其他利益集团等。
任何一个System都是在某个环境（Environment）中的，而环境又影响（influences）着系统，因为环境，有时候是指上下文（context），决定了这个系统的发展、运作、政治和其他影响的设置和情形。环境也会直接或者间接的影响与之交互的其他系统。环境可以确定一个系统的边界以及与其统的交互范围。也就是可以在本系统和与之相关的其他系统之间画一条线，这个线就是边界。
系统有（has an）一个架构。一个架构可以由一个架构描述来记录。
这里的系统和架构虽然是一对一的关系，但是还是有区别的，一个是概念上的是一个实际具体的事物。
第3层：Stakeholder、AD、Rational
1个系统拥有1个或多个利益相关者。利益相关者拥有1个或多个关注点。
关注点是指对于那些操作或其他方面对于一个或多个利益相关者非常重要，且与那些系统发展相关的利益。
通常关注点包括系统的功能要求、性能需求、安全性、可靠性和保密性等。
架构描述是由多个view组合而成的。体系架构描述将1个或多个模型聚合到视图中。
架构描述选择一个或多个视点供使用。这种选择依赖于利益相关者关注点需要通过架构描述来解决。
例如，ISO的（RM-ODP 开放式分布处理的参考模型）所选择5个视点。但是IEEE std 1471-2000中没有提及选择的特定的视点。可以用架构描述来定义一个视点，也可以在其他地方定义在架构描述中使用而已。
架构描述定义1个或多个利益相关者的关注点。
AD需要提供基本原理，也就是AD需要提供选择当前架构的原因，架构设计师如何满足功能性与非功能性需求的。
第4层：Concern，Viewpoint，View
每一个view又涵盖了一个或多个利益相关者的关注点。一个视图是根据视点（viewpoint）中定义的规则和约定所创建的。除了视图中描述的信息之外，一个架构的描述还可以包含其他的信息，例如系统概述和系统原理等。这些信息的来源可能不是某个视点，而是遵循了其他组织文档的实践。
一个视点是通过创建、描述和分析视图而建立的一种约定。也就是说，一个视图遵从一个视点，一个视点决定了描述视图的语言（包括符号、模型或产品类型），任何一种相关的建模方法或者分析技术，都将被应用在视图的表述上。
第5层：Library Viewpoint，Model
外部定义的视点被称作视点库，例如RM-ODP中的那5个视点。
1. 企业视点（Enterprise Viewpoint）：分析系统目的、商业需求、策略和系统范围的试点。处理与企业层面有关的信息，例如组织结构和政策等。
2. 信息视点（Information Viewpoint）：信息的结构，当中包括信息的变化、流程及不同功能上的逻辑分割。
3. 计算视点（Computational Viewpoint）：着重于系统的分解成相对的实体及接口。
4. 工程视点（Engineering Viewpoint）：处理有关分布式系统对象间的交互（interaction），及描述如何支持有关的交互。
5. 技术视点（Technology Viewpoint）：定义有关系的软件及硬件组件。
一个视图可能由1个或多个模型组成，模型可以参与一个或多个视图。
每个这样的模型都是根据对应观点定义中建立的方法来定义的。
换个角度来理解就是：
任何一个系统(System)是为了达成某些利益相关者(Stakeholder)的某些人物(Mission)，在特定环境(Enviroment)中构建的。每一个系统都有一个架构(Architecture)。
架构(Architecture)是对所有利益相关者的关注点(Concern)的响应和回答，通过架构描述(Architecture Description)来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其它方面相关的利益。
架构描述(Architecture Description)本质上是多视图的。每一个视图(View)是从一个特定的视点(Viewpoint)来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。
视点(Viewpoint)的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。
一个视图(View)包括一个或者多个架构模型(Model)，一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。
架构设计有助于系统从最初概念产生到退役的开发、操作和维护的整个生命周期的工作。因此在软件开发中加入架构设计概念后，可以帮助在软件开发中对软件上下文的理解，整体环境和系统的认知，而不仅仅是多增加了一个活动而已。
参考文献：
1. http://www.rm-odp.net
2. http://blog.sina.com.cn/s/blog_5a010cd10100xxiz.html
3. Summary of IEEE 1471 By Jan Øyvind Aagedal, SINTEF Telecom and Informatics