|
|
|
特定领域软件架构（Domain Specific Software Architecture，DSSA）是在一个特定应用领域中为一组应用提供组织结构参考的标准软件架构，是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标是支持在一个特定领域中多个应用的生成。
|
|
|
|
关于DSSA中“领域”的含义，从功能覆盖的范围角度可以有两种理解方式：
|
|
|
|
（1）垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件架构。
|
|
|
|
（2）水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，但无法为系统提供完整的通用架构。
|
|
|
|
：在垂直域上定义的DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足；若将领域分割成较小的范围，则更相对容易，也容易得到一个一致的解决方案。
|
|
|
|
|
|
实施DSSA的过程中包含了一些基本的活动。虽然具体的DSSA方法可能定义不同的概念、步骤、产品等，但这些基本活动是大体上一致的。以下将分3个阶段介绍这些活动。
|
|
|
|
（1）领域分析。这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求。我们称领域模型所描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界，从而明确分析的对象；识别信息源，即领域分析和整个领域工程过程中信息的来源。在此基础上，就可以分析领域中系统的需求，确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。领域分析的机制如下图所示。
|
|
|
|
|
|
|
|
（2）领域设计。这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA。由于领域模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示多选一的、可选的解决方案等来做到这一点。由于重用基础设施是依据领域模型和DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的规约。
|
|
|
|
（3）领域实现。这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
|
|
|
|
：以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。
|
|
|
|
如上图所示，参与DSSA的人员可以划分为4种角色：领域专家、领域分析师、领域设计人员和领域实现人员。
|
|
|
|
|
|
因所在的领域不同，DSSA的创建和使用过程也各有差异，Tracz曾提出了一个通用的DSSA应用过程，这些过程也需要根据所应用到的领域来进行调整。DSSA的建立过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准。DSSA的建立过程是并发的、递归的、反复的，或者可以说，它是螺旋型的。
|
|
|
|
（1）定义领域范围：确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。
|
|
|
|
（2）定义领域特定的元素：编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块图将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。
|
|
|
|
（3）定义领域特定的设计和实现需求约束：描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
|
|
|
|
（4）定义领域模型和架构：产生一般的架构，并说明构成它们的模块或构件的语法和语义。
|
|
|
|
（5）产生、搜集可重用的产品单元：为DSSA增加构件使得它可以被用来产生问题域中的新应用。
|
|
|
|
DSSA的建立过程的目的是将用户的需要映射为基于实现限制集合的软件需求，这些需求定义了DSSA。下图是DSSA的一个三层次系统模型。
|
|
|
|
|
|
|
|
DSSA的建立需要架构设计师对所在特定应用领域（包括问题域和解决域）必须精通，他们要找到合适的抽象方式来实现DSSA的通用性和可重用性。通常DSSA以一种逐渐演化的方式发展。
|
|
|
|
|
|
在软件架构的发展过程中，因为研究者的出发点不同，出现了两个互相正交的方法和学科分支：以问题域为出发点的DSSA和以解决域为出发点的软件架构风格。因为两者侧重点不同，它们在软件开发中具有不同的应用特点。
|
|
|
|
DSSA只对某一个领域进行设计专家知识的提取、存储和组织，但可以同时使用多种架构风格；而在某个架构风格中进行架构设计专家知识的组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。
|
|
|
|
DSSA的特定领域参考架构通常选用一个或多个适合所研究领域的架构风格，并设计一个该领域专用的架构分析设计工具。但该方法提取的专家知识只能用于一个较小的范围（所在领域中）。不同参考架构之间基础和概念的共同点较少，所以为一个领域开发DSSA及其工具在另一个领域中是不适应的或不可重用的，而工具的开发成本是相当高的。
|
|
|
|
架构风格的定义和该风格应用的领域是正交的，提取的设计知识比用DSSA提取的设计专家知识的应用范围要广。一般的、可调整的系统基础可以避免涉及特定的领域背景，所以建立一个特定风格的架构设计环境的成本比建立一个DSSA参考架构和工具库的成本要低得很多。因为对特定领域内的专家知识和经验的忽略，使其在一个具体的应用开发中所起的作用并不比DSSA要大。
|
|
|
|
DSSA和架构风格是互为补充的两种技术。在大型软件开发项目中基于领域的设计专家知识和以风格为中心的架构设计专家知识都扮演着重要的角色。
|
|
|
