DSSA(Domain Specific Software Architecture) 特定领域软件架构
与软件体系结构风格的区别
DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发，后者从解决域出发。
DSSA只对某个领域进行专家知识的提取、存储、组织，但可以同时使用多种软件体系结构风格；而在某个软件体系结构风格中进行专家知识组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。
DSSA通常选用一个或多个适合所研究的领域的体系结构风格，并设计一个该领域专用的体系结构分析设计工具。但该方法提取的专家知识只能应用于一个较小的范围－－所在领域。一个领域的DSSA及其工具在另一个领域中是不适应的，或不可以重用的。
体系结构风格避免设计到特定的应用领域或背景，所提取的知识比DSSA提取的知识应用范围要广。但在一个特定领域中，正是由于体系结构风格对领域知识、领域背景的忽略，使其在一个具体领域的开发中的作用并不比DSSA要大。
DSSA与体系结构风格是互为补充的两种技术。
http://iknow.seforge.org/sewiki/DSSA_e6_96_b9_e6_b3_95
作为DARPA的DSSA计划的一部分，Will Tracz在DSSA-ADAGE项目中提出了DSSA领域工程方法，与基于构架的系统开发过程相配合，应用于航空电子设备自动导航领域。
在DSSA方法中，进行领域工程的主要方式是领域工程师与领域专家的会谈，其中领域专家要就领域工程师提出的一系列问题进行报告，领域工程师对这些报告进行综合和整理，然后与领域专家一起对结果进行复审。
DSSA的领域工程过程是并发的 (concurrent)、递归的(recursive)和迭代的(iterative)。或者可以说，它是螺旋型的(spiral)。完成这个过程可能需要对每个阶段都经历几遍，每次增加更多的细节。对每个阶段的描述中包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证准则。
该方法分为五个主要阶段，在此之前还需要进行一些准备工作。其中前三个阶段集中于领域分析，即显式地把握领域特定的知识，这些知识时常被领域专家看作普通的知识。后两个阶段处理DSSA的设计、分析以及实现。
准备工作
在与领域专家会谈之前，领域工程师应尽可能熟悉该领域。理想情况下，领域工程师应对该领域具有一定经验。领域工程师应对DSSA方法指南中的问题回答有一定的想法，以便在会谈过程中诱导领域专家的答案，或者由领域专家对这些想法进行确认。领域工程师要确定DSSA方法的指南文档中哪些问题是与本次领域工程相关的，并对指南中的领域工程过程进行相应的裁剪。领域工程师还要理解本次领域工程所要达到的目标和实施这项工作的原因。
第一个阶段――定义领域分析的范围
本阶段集中于在感兴趣的领域之内有哪些事物。本步骤的输出包括感兴趣的领域与其它领域间的关系图、领域中应用的用户的需求列表、作为信息源的人的列表、作为信息源的项目的列表。
第二个阶段――定义特定于领域的元素并限制范围
本阶段的目标是编辑特定于领域的术语字典和同义词词典。在高级别块图的基础上，增加更多的细节，其中重点是在领域中的应用之间识别共同性，分离差异性。应特别重视对领域中的基本元素进行标准化和分类。
第三个阶段――定义和精化特定于领域的设计和实现约束
DSSA方法的一个特色是区别“需求”和“约束”。在DSSA方法中，“需求”描述一组在问题空间中的特性。“约束”描述一组在解空间中的特性。本阶段的目标是描述解空间中的特征。不但要识别约束，而且要记录它们对设计和实现决定的影响，以及对处理它们时产生的问题的讨论。
第四个阶段――开发领域构架/模型 领域设计
本阶段的目标是提出一般的构架，并说明构成构架的模块或构件的语法和语义。为满足前面识别的需求和约束，在一个应用领域中可能需要设计几个DSSA。
第五个阶段――产生或搜集复用产品 领域实现
本阶段的目标是为DSSA充实构件使得它可以被用来产生问题域中的新应用。参与这个阶段的领域专家是开发过这个领域中应用的软件工程师。他们最适合识别现有的可复用构件，或可以作为产生可复用构件的基础的构件。
参见:
