转自：http://blog.chinaunix.net/uid-26847614-id-3159126.html
3.体系结构文档模板
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的表达。
3.2.3 非功能性需求
主要描述功能之外的、但是和系统相关的。可以包含三个部分：
（1）质量。包括服务的质量（性能、产量、可用性、安全性）和系统开发的质量（可维护性、可移植性、支持性）。通常这里只是概述含义和措施，而将细节留给系统需求文档和架构需求文档。
（2）系统运行环境的约束。如系统运行相关的环境、服务质量相关。这里的约束指的是架构需求说明中约束的一个摘要。
（3）协议。描述了解决特定需求的方法（可能在质量和约束中提到过）。比如电子商务的易用性，可以通过增加购物手推车来完成、开发中的约束可以通过购买来完成。
3.3 structure部分
主要依照逻辑组件和接
口沟通来描述静态结构。组件具有一定的抽象级别，可以对应一个类或一组类主要指逻辑组件。可以分为三个部分overview、每个组件的描述、所有组件接口的描述。
3.3.1 概览部分
一个structure有一个或多个框架图表和注释组成。描述了框架结构。
（1）图表。主要通过类图和接口来进行表示。
（2）注释。描述了框架基本原理、框架风格和样式、指定框架约束，可能其他可选的架构（可选）
基本原理：为何选择此种拓扑结构和框架风格？与商业对象的关联，解释框架是如何满足框架需求文档和约束的（3.2.3）？还包含3.4.1的部分；
框架约束：是管理组件行为和交互的重要规则，他们和体系结构的风格选择紧密相关；
可选框架：给出这些框架的概念说明，并指明没有选择此种架构的原因；
框架风格：层：高级和低级的抽象组件被分成很多层。
管道和过滤器：数据被封装在过滤器中，通过连接在过滤器间的管道传输；
经纪人：由经纪人连接客户和服务；
数据和操作分离：分别放在model和interface中。
基于通信的事件：
3.3.2组件部分
（1）Component：名字、版本号、包含对组件设计文档和实现文档的参考；
（2）组件的功能和提供的接口；
（3）Collaborators：列出相关联的组件；
（4）NOTE:多样性：有多少组件实例存在于系统中？实例创建和销毁是动态的吗？什么条件下创建和 销 毁；
并发性：组件包含的数据是否需要同步读取和写入，
持续性：组件和它的数据需要一直存在系统的整个生命周期吗？
参数化：描述了组件的可变性。
（5）Issues争论点，系统还有哪些实现策略，以及对其它组件的影响。随着系统的深入，此部分会放空。
3.3.3接口部分
（1）Interface：名字和版本号，接口可以理解为一系列操作的组合；
（2）Description：根据接口的功能描述接口的目的；
（3）Services：对系统来说是services,对组件是一系列操作。
（4）Protocol：services和operator的一些限制。复杂协议状态机要使用
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.参考文献
3058
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
