2012年4月5日 天气阴 星期四
1.概览
系统的软件架构是由软件组件、外部可见的属性以及组件之间的关联组成。IEEE将架构定义为系统的基础设施，主要由组件、组件之间的关联、组件与外部环境的关联、以及引导设计和演化的规则组成。软件架构是非常重要的，因为是系统结构的抽象，对于相关人员（产品团队、硬件和市场工程师、高级管理者、合作伙伴）理解和协作非常重要。
此文档主要讲述架构如何被文档化，是架构文档的一个模板。它记述了如何将系统目的、系统概念、系统上下文和系统接口文档化，如何根据组件、组件的接口和它们的连接来详细说明系统结构以及如何描述系统行为。
第2部分主要对架构文档的不同内容、目的和关系作出了表述。
架构的组织和内容在第3部分给出。
附录A给出了架构文档的概览；
附录B给出了架构模版和IEEE推荐的做法的关联；
附录C给出了术语表。
2.架构文档的角色和内容
（1）这个模版可以用来生成两种类型的文档：架构预览文档和架构参考手册。
架构预览文档目标是提供给开发者、市场、管理人员以及其他潜在终端用户等广泛人群一个共享理解；一般在软件开发的早期，作为软件开发的开始时较为理想的。架构预览应该高度抽象。架构的功能和组件应该得到表述，但由于使用自然语言而非正式的格式所以不需要细节和精确。
架构参考手册从细节上和精确度上描述了系统架构。架构参考手册并不对应生命周期的某一时间点。为了跟踪软件开发进度，同时为了反应新提议的需求以及实时性，随着开发进度的推进，变化一产生架构参考手册也要同步构建。架构参考手册是系统维护和扩展的基础。架构参考手册记录了架构的方方面面，是对抽象的进一步细化，但是不同的项目和架构精确度有所不同。如果架构中有大的组件可能要被进一步细化为一个参考手册。对于架构特定方面的完成度、形式、细节、精确度等都要依赖于相关的技术和商业风险。
(2)范围
并非所有的架构文档都需要模版中的所有部分。附录A给出了一个预览以及可选性。即使对于必须的部分不同的项目、预览和参考手册等的信息量也不一样。引言部分列出了相关人员的关注点。架构文档只要能够满足各方需求就算完成了。
（3）架构模版所涵盖的视图
这个模版按照4 1视图进行组织。逻辑视图主要在结构部分和动态行为部分，进程视图、物理视图和开发视图在其他的视图部分。
对于每一个视图，组件的结构和动态行为也即显示组件交互的场景被模型化。对于进程视图、开发视图、物理视图主要在相应部分完成。对于逻辑视图，它被分成两部分：结构部分和动态行为部分。当然，不同视图中的动态模型必须一致。
3.体系结构文档模板
3.1到3.7描述了架构文档的结构和内容，对于文档的每一个部分做了描述、解释，重要的地方做了示例。
3.1引言部分
这部分确定体系架构和相关的人员。记录架构文档的创建和修改时间。细节部分如下：
（1）架构的名字，是架构总览还是具体的参考手册；
（2）设计团队和架构文档的作者信息，以及哪些相关人员会架构和文档做出反馈；
（3）创建和修改历史；
（4）受众和文档目的；
（5）一些可选性的观点；
（6）记录与其它软件开发相关文档的关联，如需求说明、架构说明、设计说明、内部参考说明等等。
（7）可选的观点，包括观点描述和模型
（8）如果此架构文档与某个项目关联可罗列项目名、发布日期、项目团队以及产品团队等（可选）
3.2系统目的
此部分主要说明系统的目的和它要解决的问题，这部分是一个概览性的说明，不需要关心内部结构实现，且不能满足需求说明的功能要记录。
（1）系统在何种上下文中使用和它解决的问题；
（2）系统提供的服务也即功能的接口；
（3）服务的属性特征
通常这部分给予了一个系统上下文、系统接口和被其它文档说明书所包含的非功能需求部分的概要说明
3.2.1 系统上下文
（1）描述系统运行环境和解决的问题。主要描述与系统通信的关键实体的角色而非系统本身。
（2）描述系统和运行环境的边界。主要可以使用如下三种模型：
用例图、类图、数据流图
3.2.2 系统接口部分
依据系统的任务描述接口，通常系统接口可以被组织成很多子接口。每个子接口相应的对应特定的用途，根据抽象度不同有所不同，在架构概览文档可能抽象级别就高，只有一些简单的操作和use case；在架构参考文档中所有的接口的use case和系统操作都要给出，并给出简短的描述，顺序也可能被指定。（关于组件接口的细节部分参照3.3.3。关于每个use case和operation的细节部分参照3.4）
3.2.3 非功能性需求
主要描述功能之外的、但是和系统相关的需求概要。非功能需求可以分三个部分：
（1）服务的质量。包括服务的质量（性能、产量、可用性、安全性）和系统开发的质量（可维护性、可移植性、支持性）。通常这里只是概述服务质量的含义和措施，而将细节留给系统需求文档和架构需求文档。
（2）系统运行环境的约束。与系统运行相关的环境和条件的限制、服务质量相关。这里的约束指的是架构需求说明中约束的一个摘要。
（3）规则。描述了解决特定需求的方法和策略（可能在质量和约束中提到过）。比如电子商务的易用性，可以通过增加购物手推车来完成、开发中的约束可以通过购买来完成。
3.3 structure部分
主要依照逻辑组件和接口 交流来描述架构的静态结构。组件具有一定的抽象级别，可以对应一个类或一组类主要指逻辑组件。高抽象级别的组件称为子系统。在此文档里组件指的是逻辑组件。可以分为三个部分overview、每个组件的描述、所有组件接口的描述。
3.3.1 overview部分
一个overview有一个或多个框架图表和注释组成。描述了框架结构。
（1）图表。主要通过类图和接口来进行表示。
（2）注释。描述了框架基本原理、框架风格和样式、指定框架约束，可能其他可选的架构（可选）
基本原理：为何选择此种拓扑结构和框架风格？与商业对象的关联，解释框架是如何满足框架需求文档和约束的（3.2.3）？还包含3.4.1的部分；
框架约束：是管理组件行为和交互的重要规则，他们和体系结构的风格选择紧密相关；
可选框架：给出这些框架的概念说明，并指明没有选择此种架构的原因；
框架风格：层：高级和低级的抽象组件被分成很多层。
管道和过滤器：数据被封装在过滤器中，通过连接在过滤器间的管道传输；
经纪人：由经纪人连接客户和服务；
数据和操作分离：分别放在model和interface中。
基于通信的事件：
3.3.2组件部分
这个部分描述了架构中的每一个组件
（1）Component：包含名字、版本号。也包含对组件设计文档和实现文档的参考,如果复杂的组件拆分成小的组件，还要增加相应文档参考；
（2）依据组件的任务和组件的接口描述组件具有的功能或目的。任务：一个任务是一组功能，并指定组件的目的，可以是组件必须知道的信息和组件的运行行为；接口：可以通过3.3.3部分或者通过罗列组成接口的use case和operations罗列,参考的接口促进了组件的热插拔；给出组件为何这样设计也是很有用的。
（3）Collaborators：组件要达到目的需要向其它组件请求服务，这些组件也要列出，除此之外，用到的合作方组件的use case和操作或接口也要列出。
（4）NOTE:组件的设计必须要进一步满足如下部分的需求：
多样性：有多少组件实例存在于系统中？实例创建和销毁是动态的吗？什么条件下创建和 销 毁；
并发性：组件包含的数据是否需要同步读取和写入，
持续性：组件和它的数据需要一直存在系统的整个生命周期吗？
参数化：描述了组件的可变性。
（5）Issues争论点，系统还有哪些实现策略，以及对其它组件的影响。随着系统的深入，此部分会放空。
3.3.3接口部分
接口描述允许不依赖于组件和系统。如果一组use case或操作（接口）被很多组件使用，或者组件的任务有很多接口组成那么这部分是很方便的。这部分可以用模版来表述:
（1）Interface：名字和版本号，接口可以理解为一系列操作的组合；
（2）Description：根据接口的功能描述接口的目的；
（3）Services：服务可以从系统或组件进行申请。对系统来说是services可以是use case或操作,而对组件是一系列操作。对于接口的每个服务至少包含一个名字和关于它的任务的简短描述。还可以提供一些其他方面的信息。可以从外部观点看来做一个细节描述，不用描述内部实现和细节。同时也要指定服务如何被触发。
（4）Protocol：services和operator的一些限制。主要是服务的一些调用次序。对于复杂的可以使用状
态机；对于简单的用文字描述即可。
（5）note:记录提供这个接口的组件。
3.4动态行为
系统行为可以用use case或系统操作来模型化。use case包括一个或多个外部actors和系统为了完成特定目标的多个步骤和交互。系统操作包括一个输入作为触发事件，
Scenarios Specification主要从外部观点对系统操作和用例的细节说明，定义了框架如何动作来响应外部的触发动作，；
mechanisms提供了Scenarios没有覆盖到的系统内部的行为模型，描述了组件如何协作来产生场景定义的行为。
3.4.1Scenarios
（1）Scenarios Specification主要从外部观点看actors和system的交互
（2）Component Interaction Model：从内部组件之间的交互来描述
3.4.2 Mechanisms
主要是对前面未涉及的部分的补充。比如关于非功能性需求的组件和约束等有争议的问题
3.5其它视图
3.5.1进程视图
主要是将逻辑视图映射为进程相关。可以用类图和对象图来表示。
3.5.2开发视图
逻辑视图中组件到目录的映射
3.5.3部属视图
3.6概念框架
3.7结论
4.结论和感谢
5.参考文献
