【软考系统架构设计师】DSSA特定领域软件架构

一、何为DSSA

DSSA（Domain Specific Software
Architecture）是特定领域软件架构，它为一个特定应用领域的多应用开发提供了一种组织结构参考的标准软件框架。
是一种有效实现特定领域软件重用的手段。简单地说，DSSA就是在一个特定应用领域为一组应用提供组织结构参考的标准软件体系结构。按照Tracz的说法，DSSA就是一个特定的问题领域中由领域模型、参考需求、参考架构等组成的开发基础架构，其目标就是支持一个特定领域中多个应用的生成。特定领域软件架构可以看作开发产品线的一个方法或理论，它的目标就是支持在一个特定领域中有多个应用的生成。

看了定义之后，还是不知道说什么，其实DSSA可以被理解为特定领域中的一种“模板”或“样板”，这个领域中的多个应用程序可以基于这个模板或样板进行构建和发展。

首先，DSSA不是针对某一个具体的应用程序，而是针对一个特定领域的多个应用程序。在这个领域中，应用程序可能有很多共同的功能和特点，比如医疗、教育、金融等领域。

其次，DSSA是一个标准的软件框架，它提供了一套通用的结构和规范，这个结构和规范可以用来组织和管理领域中的多个应用程序。它不是具体的应用程序，而是应用程序的“样板”。

再次，DSSA具有可重用的特点。在领域中，不同的应用程序可能有很多共通的功能和模块，这些功能和模块可以在DSSA中得到定义和封装，方便在不同的应用程序中进行重用。这样可以减少开发工作量，提高开发效率和质量。

最后，DSSA的目的是为了支持领域中多个应用程序的开发。它不是一个独立的程序，而是为应用程序开发提供支持和指导的工具。通过使用DSSA，开发人员可以更快地开发出符合领域需求的高质量软件。

总之，DSSA可以被理解为特定领域中的一种模板或样板，它提供了一套通用的结构和规范，用于支持领域中多个应用程序的开发，并方便应用程序的重用和组织。
这样应该容易理解多了吧！

二、DSSA的特征

• 对整个领域适度的抽象。
• 具有严格定义的问题域或解决方案域。
• 具备该领域固有的、典型的在开发过程中可重用元素。
• 具有普遍性，即可用于领域中某个特定应用的开发。

三、分类

从功能覆盖的范围角度通常有两种理解DSSA中领域的含义的方式。

（1）垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。

（2）水平域：定义了在多个系统和多个系统族中功能区域的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

在垂直域上定义的DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足：若将领域分割成较小的范围，则更相对容易，也容易得到一个一致的解决方案。
看定义是比较猛的，这里举个栗子简单描述下，不知是否恰当：

垂直域（Vertical Domain）相当于一个特定行业或领域中的系统，比如医疗、教育、金融等。在医疗领域中，可能包括许多不同的系统，如电子病历、影像诊断、医嘱系统等，这些系统都具备自己独特的功能和特性。在垂直域中，会研究所有这些系统的共同点，抽取出一个通用的软件体系结构，这样就可以为该领域中的任何一个系统提供可重用的组件和框架。

水平域（Horizontal
Domain）则是不同系统或系统族之间的共有部分。比如在医疗、教育和金融三个领域中，可能都有一个共有的部分，如用户管理、数据存储、报表生成等。这些功能可能在不同的系统中都会用到，因此可以在水平域中定义一个通用的软件体系结构，来支持这些共有的功能。

四、DSSA的基本活动

4.1 领域分析

这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求，即领域模型所描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界。从而明确分析的对象；识别信息源，整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领城需求的一个变化范围。一些需求对所有被考察的系统是共同的，一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享。

4.2 领域设计

这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案。不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA，由于领域模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示多选一的（alternative）、可选的（optional）解决方案等来做到这一点。因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的规约。

4.3 领域实现

主要目标是依据领域模型和DSSA开发和组织可重用信息。领域模型和DSSA定义了这些可重用信息的重用时机。从而支持了系统化的软件重用。这个阶段也可以看作重用基础设施的实现阶段

TIPS：
值得注意的是，以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

五、参与DSSA的人员

参与DSSA的人员可以划分为4种角色：领域专家、领域分析师、领域设计人员和领域实现人员。

5.1 领域专家

领域专家可能包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等。领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。

5.2 领域分析人员

领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。领域分析人员应熟悉软件重用和领域分析方法；熟悉进行知识获取和知识表示所需的技术、语言和工具；应具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互；应具有较高的进行抽象、关联和类比的能力；应具有较高的与他人交互和合作的能力。

5.3 领域设计人员

领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制核个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。领域设计人员应熟悉软件重用和领域设计方法；熟悉软件设计方法；应有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互。

5.4 领域实现人员

领域实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件间的联系。领域实现人员应熟悉软件重用、领域实现及软件再工程技术；熟悉程序设计；具有一定的该领域的经验。

六、DSSA的建立过程

因所在的领域不同，DSSA的创建和使用过程也各有差异，Tract曾提出了一个通用的DSSA应用过程，这些过程也需要根据所应用到的领域来进行调整。一般情况下，需要用所应用领域的应用开发者习惯使用的工具和方法来建立DSSA模型。同时Tracz强调了DSSA参考体系结构文档工作的重要性。因为新应用的开发和对现有应用的维护都要以此为基础。

DSSA的建立过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准。本过程是并发的（concurrent）、递归的（recursive）、反复的（iterative）。或者可以说，它是螺旋模型（spiral）。完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节。

6.1 定义领域范围

本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。
这是DSSA（领域特定软件体系结构）过程的初始阶段。在此阶段，领域专家和系统架构师确定DSSA的关注领域。他们识别出关键的业务、系统和技术方面，这些方面是DSSA需要支持的。此外，该阶段还定义了DSSA的边界和范围，以避免与不相关的系统或业务领域产生混淆。

6.2 定义领域特定的元素

本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块圈将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。
在这个阶段，领域专家和系统架构师定义了DSSA中所需的领域特定元素。这些元素可能包括数据模型、功能需求、服务、业务流程、用户界面模式、交互模式等等。这些元素是DSSA的核心，因为它们将用于构建DSSA的各个组成部分。

6.3 定义领域特定的设计和实现需求约束

本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
在这个阶段，架构师和开发人员定义了在设计和实现DSSA时需要考虑的需求约束。这些约束可能包括性能、安全性、可用性、可扩展性、可维护性、可重用性等。这些约束在设计和实现DSSA的过程中提供了方向，以确保系统满足特定的要求和标准。

6.4 定义领域模型和体系结构

本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。
在这个阶段，架构师和领域专家定义了DSSA的领域模型和体系结构。领域模型是一个概念模型，它描述了DSSA所关注的领域的核心概念和关系。体系结构则描述了DSSA的组件、模块、接口和关系，以及它们如何一起工作以实现所需的功能。

6.5 产生，搜集可重用的产品单元

本阶段的目标是为DSSA增加构件，使它可以被用来产生问题域中的新应用。
这是最后一个阶段，架构师和开发人员根据在前面的阶段中定义的元素、设计和实现需求约束以及领域模型和体系结构，创建或收集可重用的产品单元。这些产品单元可以是现有的软件组件、库、工具、框架等，也可以是新开发的组件。这些产品单元将被组装成最终的DSSA，以满足业务需求并实现所需的性能和功能。

DSSA的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需要映射为基于实现限制集合的软件需求，这些需求定义了DSSA。在此之前的领域工程和领域分析过程并没有对系统的功能性需求和实现限制进行区分，而是统称为“需求”。