网站建设与管理做什么,提供服务好的网站归档系统,wordpress微信链接地址,wordpress分类别名【本章学习建议】
根据考试大纲#xff0c;本章不仅考查系统架构设计师单选题#xff0c;预计考12分左右#xff0c;而且案例分析和论文写作也是必考#xff0c;对应第二版教材第7章#xff0c;属于重点学习的章节。 软考高级系统架构设计师VIP课程https://edu.csdn.net/…【本章学习建议】
根据考试大纲本章不仅考查系统架构设计师单选题预计考12分左右而且案例分析和论文写作也是必考对应第二版教材第7章属于重点学习的章节。 软考高级系统架构设计师VIP课程https://edu.csdn.net/course/detail/40283
11.1 软件架构概念
11.1.1 软件架构的定义
软件架构Software ArchitectureSA一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件构件的外部可见属性以及它们之间的相互关系。从需求分析到软件设计之间的过渡过程
架构并非可运行软件。确切地说它是一种表达使软件工程师能够
1分析设计在满足所规定的需求方面的有效性
2在设计变更相对容易的阶段考虑体系结构可能的选择方案
3降低与软件构造相关联的风险。
软件架构设计包括提出架构模型产生架构设计和进行设计评审等活动是一个迭代的过程。
架构设计主要关注软件构件的结构、属性和交互作用并通过多种视图全面描述特定系统的架构。
软件架构是项目干系人进行交流的手段明确了对系统实现的约束条件决定了开发和维护组织的组织结构制约着系统的质量属性。研究软件架构的根本目的是解决好软件的复用、质量和维护问题。
软件架构是可传递和可复用的模型通过研究软件架构可能预测软件的质量。
11.1.2 软件架构设计与生命周期
1. 需求分析阶段
需求分析和SA设计面临的是不同的对象一个是问题空间另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。
2. 设计阶段
设计阶段是SA研究关注的最早和最多的阶段这一阶段的SA研究主要包括SA模型的描述、SA模型的设计与分析方法以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次SA的基本概念构件和连接子、体系结构描述语言ADL、SA模型的多视图表示。
SA模型的多视图表示从不同的视角描述特定系统的体系结构从而得到多个视图并将这些视图组织起来以描述整体的SA模型。多视图体现了关注点分离SOC的思想。典型的多视图的方案包括41模型逻辑视图、进程视图、开发视图、物理视图加上统一的场景。Philippe Kruchten在1995年提出了一个“41”的视图模型。“41”视图模型从5个不同的视角包括逻辑视图、进程视图、开发视图、物理视图和统一的场景来描述软件架构。每一个视图只关心系统的一个侧面5个视图结合在一起才能反映系统的软件架构的全部内容。
软件架构设计的41视图 逻辑视图也称设计视图主要描述系统的功能需求。
进程视图也称过程视图主要关注一些非功能性的需求例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力以及逻辑视图中的主要抽象的进程结构。
开发视图也称实现视图侧重于软件模块的组织和管理。
物理视图主要描述如何把软件映射到硬件上通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
统一的场景可以看作是那些重要系统活动的抽象它使4个视图有机地联系起来从某种意义上说场景是最重要的需求抽象。在开发架构时它可以帮助设计者找到架构的构件以及它们之间的作用关系。逻辑视图和开发视图描述系统的静态结构而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说侧重的角度也有所不同。例如对于管理信息系统来说比较侧重于从逻辑视图和开发视图来描述系统而对于实时控制系统来说则比较注重于从进程视图和物理视图来描述系统。
3. 实现阶段
最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换实现阶段的体系结构研究表现在以下几个方面。
1研究基于SA的开发过程支持如项目组织结构、配置管理等。
2寻求从SA向实现过渡的途径如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等。
3研究基于SA的测试技术。
4. 构件组装阶段
在SA设计模型的指导下可复用构件的组装可以在较高层次上实现系统并能够提高系统实现的效率。在构件组装的过程中SA设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。
1如何支持可复用构件的互联即对SA设计模型中规约的连接子的实现提供支持。
2在组装过程中如何检测并消除体系结构失配问题。
在构件组装阶段的失配问题主要包括由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。
5. 部署阶段
SA对软件部署作用如下
1提供高层的体系结构视图来描述部署阶段的软硬件模型。
2基于SA模型可以分析部署方案的质量属性从而选择合理的部署方案。
6. 后开发阶段
后开发阶段是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
1动态软件体系结构。现实中的软件具有动态性体系结构会在运行时发生改变。运行时变化包括两类软件内部执行所导致的体系结构改变软件系统外部的请求对软件进行的重配置。动态软件体系结构包括两个部分的研究体系结构设计阶段的支持、运行时刻基础设施的支持。
2体系结构恢复与重建。对于现有系统在开发时候没有考虑SA的情况从这些系统中恢复或重构体系结构。从已有的系统中获取体系结构的重建方法分为4类手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术如数据挖掘等。
构件补充
构件是面向软件体系架构的可复用软件模块。构件Component是可复用的软件组成成份可被用来构造其他软件。它可以是被封装的对象类、功能模块、软件框架Framework、中间件等。
构件是一个独立可交付的功能单元外界通过接口访问其提供的服务。
构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署但是它也能够被单独部署。
构件和原子构件之间的区别在于大多数原子构件永远都不会被单独部署尽管它们可以被单独部署。相反大多数原子构件都属于一个构件家族一次部署往往涉及整个家族。
模块是不带单独资源的原子构件是一组类和可能的非面向对象的结构体比如过程或者函数。
构件的特性
1独立部署单元具有原子性是不可拆分的
2作为第三方的组装单元
3没有外部的可见状态。
一个构件可以包含多个类元素但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
对象的特性
1一个实例单元具有唯一的标志。
2可能具有状态此状态外部可见。
3封装了自己的状态和行为。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合而是关注输入输出的消息的标准化它强调当机器在网络中互连时标准的消息模式、格式、协议的重要性。
面向构件的编程COP
关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持
--多态性可替代性
--模块封装性高层次信息的隐藏
--后期的绑定和装载部署独立性
--安全性类型和模块安全性。
构件技术就是利用某种编程手段将一些人们所关心的但又不便于让最终用户去直接操作的细节进行了封装同时对各种业务逻辑规则进行了实现用于处理用户的内部操作细节。目前国际上常用的构件标准主要有三大流派
·EJBEnterprise Java Bean规范由Sun公司制定有三种类型的EJB分别是会话BeanSession Bean、实体BeanEntity Bean和消息驱动BeanMessage-driven Bean。EJB实现应用中关键的业务逻辑创建基于构件的企业级应用程序。
·COM、DCOM、COM组件对象模型COM是微软公司的。DCOM是COM的进一步扩展具有位置独立性和语言无关性。COM并不是COM的新版本是COM的新发展或是更高层次的应用。
·COBRA标准是由OMG制定的一种面向对象分布式应用程序体系规范。主要分为三个层次对象请求代理、公共对象服务和公共设施。最底层是对象请求代理ORB规定了分布对象的定义接口和语言映射实现对象间的通讯和互操作是分布对象系统中的“软总线”在ORB之上定义了很多公共对象服务可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务最上层的公共设施则定义了组件框架提供可直接为业务对象使用的服务规定业务对象有效协作所需的协定规则。
11.2 基于架构的软件开发方法
11.2.1 概述
基于架构的软件设计Architecture-Based Software DesignABSD方法是由架构驱动即由构成架构的商业、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构采用用例和质量属性场景来描述需求。进一步来说用例描述的是功能需求质量属性场景描述的是质量需求(或侧重于非功能需求)。
使用ABSD方法设计活动可以从项目总体功能框架明确就开始这意味着需求获取和分析还没有完成就开始了软件设计。
ABSD方法有三个基础。第一个基础是功能的分解使用已有的基于模块的内聚和耦合技术第二个基础是通过选择架构风格来实现质量和商业需求第三个基础是软件模板的使用软件模板利用了一些软件系统的结构。
ABSD方法是递归的且迭代的每一个步骤都是清晰定义的。因此不管设计是否完成架构总是清晰的有助于降低架构设计的随意性。
11.2.2 概念和术语
1. 设计元素
ABSD方法是一个自顶向下递归细化的方法软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。
ABSD方法中使用的设计元素如下图所示。在最顶层系统被分解为若干概念子系统和一个或若干个软件模板。在第2层概念子系统又被分解成概念构件和一个或若干个附加软件模板。 2. 视角与视图
考虑体系结构时要从不同的视角Perspective来观察对架构的描述这需要软件设计师考虑体系结构的不同属性。例如展示功能组织的静态视角能判断质量特性展示并发行为的动态视角能判断系统行为特性因此选择的特定视角或视图如逻辑视图、进程视图、实现视图和配置视图可以全方位的考虑体系结构设计。使用逻辑视图来记录设计元素的功能和概念接口设计元素的功能定义了它本身在系统中的角色这些角色包括功能、性能等。
3. 用例和质量场景
用例己经成为推测系统在一个具体设置中的行为的重要技术用例被用在很多不同的场合用例是系统的一个给予用户一个结果值的功能点用例用来捕获功能需求。
在使用用例捕获功能需求的同时人们通过定义特定场景来捕获质量需求并称这些场景为质量场景。
11.2.3 基于架构的开发模型
传统的软件开发过程是问题定义需求分析软件设计实现测试。ABSD把整个软件过程分成六个部分架构需求架构设计架构文档化架构复审架构实现和架构演化六个步骤。 1架构需求重在掌握标识构件的三步如下图。架构需求一般来自3个方面分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
2架构设计将需求阶段的标识构件映射成构件进行分析如下图。
3架构文档化主要产出两种文档即架构规格说明和测试架构需求的质量设计说明书。文档是至关重要的是所有人员通信的手段关系开发的成败。 4架构复审由外部人员独立于开发组织之外的人如用户代表和领域专家等参加的复审复审架构能否满足需求、质量需求是否在设计中得到体现、构件的划分是否合理等。若复审不过则返回架构设计阶段重新进行架构设计、文档化和复审。
5架构实现用实体来显示出架构。实现构件构件组装成系统如下图。
6架构演化对架构进行改变按需求增删构件使架构可复用如下图。 11.2.4 体系结构的演化
体系结构演化是使用系统演化步骤去修改应用以满足新的需求。主要包括以下6个步骤。
1.需求变化归类
首先必须对用户需求的变化进行归类使变化的需求与已有构件对应。对找不到对应构件的变动也要做好标记在后续工作中将创建新的构件以对应这部分变化的需求。 2.制订体系结构演化计划 在改变原有结构之前开发组织必须制订一个周密的体系结构演化计划作为后续演化开发工作的指南。
3.修改、增加或删除构件
在演化计划的基础上开发人员可根据在第1步得到的需求变动的归类情况决定是否修改或删除存在的构件、增加新构件。最后对修改和增加的构件进行功能性测试。
4.更新构件的相互作用
随着构件的增加、删除和修改构件之间的控制流必须得到更新。
5.构件组装与测试
通过组装支持工具把这些构件的实现体组装起来完成整个软件系统的连接与合成形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。 6.技术评审
对以上步骤进行确认进行技术评审。评审组装后的体系结构是否反映需求变动、符合用户需求。如果不符合则需要在第2到第6步之间进行迭代。
在原来系统上所做的所有修改必须集成到原来的体系结构中完成一次演化过程。
11.3 软件架构风格
11.3.1 软件架构风格概述
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族即一个体系结构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
软件架构设计的一个核心目标问题是能否达到架构级的软件复用。
11.3.2 数据流体系结构风格
数据流体系结构风格面向数据流按照一定的顺序从前向后执行程序主要包括批处理风格和管道-过滤器风格。
1. 批处理体系结构风格
构件为一系列固定顺序的计算单元构件之间只通过数据传递交互。每个处理步骤是一个独立的程序每一步必须在其前一步结束后才能开始数据必须是完整的以整体的方式传递。构件是独立的应用程序连接件是某种类型的媒介。
2. 管道-过滤器体系结构风格
每个过滤器处理步骤都有一组输入和输出过滤器从管道数据传输中读取输入的数据流经过内部处理产生输出数据流并写入管道中。前一个过滤器的输出作为后一个过滤器的输入前后数据流关联。构件就是过滤器连接件就是管道。早期编译器就是采用的这种架构要一步一步处理的均可考虑此架构风格。
二者区别在于批处理前后构件不一定有关联并且是作为整体传递即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入前面执行到部分可以开始下一个的执行。
典型实例传统编译器、网络报文处理。 11.3.3 调用/返回体系结构风格
调用/返回风格是指在系统中采用了调用与返回机制。其主要思想是将一个复杂的大系统分解为若干子系统以便降低复杂度并且增加可修改性。构件之间存在互相调用的关系一般是显式的调用主要包括主程序/子程序风格、面向对象风格、层次型风格、客户端/服务器风格以及浏览器/服务器体系结构风格。
1. 主程序/子程序风格
采用单线程控制把问题划分为若干个处理步骤构件即为主程序和子程序子程序通常可合成为模块。过程调用作为交互机制充当连接件的角色。
2. 面向对象体系结构风格
构件是对象或者说是抽象数据类型的实例连接件是对象间交互的方式。对象是通过函数和过程的调用来交互的。
3. 层次型体系结构风格
构件组成一个层次结构连接件通过决定层间如何交互的协议来定义。每一层为上层提供服务并作为下层的客户只对与自己相邻的层可见。修改某一层最多影响其相邻的两层通常只能影响上层。
·层次型结构优点
1支持基于可增加抽象层的设计允许将一个复杂问题分解成一个增量步骤序列的实现。
2不同的层次处于不同的抽象级别越靠近底层抽象级别越高。
3每一层最多只影响两层为软件复用提供了强大的支持。
·层次型结构缺点
1并不是每个系统都可以很容易地划分为分层的模式。
2很难找到一个合适的、正确的层次抽象方法。 4. 客户端/服务器体系结构风格
C/S客户端/服务器软件体系结构是基于资源不对等且为实现共享而提出的。两层C/S体系结构有3个主要组成部分数据库服务器、客户应用程序和网络。服务器后台负责数据管理客户机前台完成与用户的交互任务称为“胖客户机瘦服务器”。 与两层C/S结构相比三层C/S结构增加了一个应用服务器。整个应用逻辑驻留在应用服务器上只有表示层存在于客户机上故称为“瘦客户机”。应用功能分为表示层、功能层和数据层三层。表示层是应用的用户接口部分通常使用图形用户界面功能层是应用的主体实现具体的业务处理逻辑数据层是数据库管理系统。以上三层逻辑上独立。表示层在客户机上功能层在应用服务器上数据层在数据库服务器上。 5. 浏览器/服务器体系结构风格
B/S架构是三层C/S架构的变种将客户端变为用户客户端上的浏览器将应用服务器变为网络上的WEB服务器又称为零客户端架构。其三层结构为浏览器、Web服务器和数据库服务器。虽然不用开发客户端但有很多缺点
·对动态页面的支持能力较弱没有集成有效的数据库处理功能
·安全性难以控制
·在数据查询等响应速度上要远远低于C/S架构
·数据提交一般以页面为单位数据的动态交互性不强不利于OLTP应用。
11.3.4 以数据为中心的体系结构风格
以数据为中心的体系结构以数据为中心所有的操作都是围绕建立的数据中心进行的主要包括仓库体系结构风格和黑板体系结构风格。
1. 仓库体系结构风格
仓库Repository是存储和维护数据的中心场所。仓库架构风格由中央数据结构说明当前数据状态和一组独立构件对中央数据进行操作组成。连接件是仓库与独立构件之间的交互。 2. 黑板体系结构风格
包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元提供解决问题的知识。知识源响应黑板的变化修改黑板黑板是一个全局数据库包含问题域解空间的全部状态是知识源相互作用的唯一媒介知识源响应是通过黑板状态的变化来控制的。黑板架构风格适用于解决复杂的非结构化的问题能在求解过程中综合运用多种不同知识源使得问题的表达、组织和求解变得比较容易如信号处理、问题规划和编译器优化等。 11.3.5 虚拟机体系结构风格
虚拟机体系结构风格的基本思想是人为构建一个运行环境在这个环境之上可以解析与运行自定义的一些语言这样来增加架构的灵活性。自定义了一套规则供使用者使用使用者基于这个规则来开发构件能够跨平台适配主要包括解释器风格和规则系统风格。
1. 解释器体系结构风格
通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机可以仿真硬件的执行过程和一些关键应用缺点是执行效率低。典型的例子是专家系统。
2. 规则系统体系结构风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存一般用在人工智能领域和决策支持系统DSS中。
11.3.6 独立构件体系结构风格
独立构件体系结构风格主要强调构件之间是互相独立的不存在显式的调用关系而是通过某个事件触发、异步的方式来执行以降低耦合度提升灵活性。主要包括进程通信和事件系统风格隐式调用。
1. 进程通信体系结构风格
构件是独立的进程连接件是消息传递。构件通常是命名过程消息传递的方式可以是点对点、异步或同步方式以及远程过程方法调用等。
2. 事件系统体系结构风格
基于事件的隐式调用风格。构件不直接调用一个过程而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册当某个事件被触发时系统自动调用在这个事件中注册的所有过程这样一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点是为软件复用提供了强大的支持为构件的维护和演化带来了方便缺点是构件放弃了对系统计算的控制。
C2体系结构风格补充
C2体系结构风格可以概括为通过连接件绑定在一起按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下
1系统中的构件和连接件都有一个顶部和一个底部
2构件的顶部应连接到某连接件的底部构件的底部则应连接到某连接件的顶部而构件与构件之间的直接连接是不允许的
3一个连接件可以和任意数目的其他构件和连接件连接
4当两个连接件进行直接连接时必须由其中一个的底部到另一个的顶部。 11.4 软件架构复用
1. 软件架构复用的定义及分类
软件架构复用是系统化的软件开发过程开发一组基本的软件构件模块以覆盖不同的需求/体系结构之间的相似性提高系统开发的效率、质量和性能。
软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中只要发现有可复用的资产就对其进行复用。系统复用是指在开发之前就要进行规划以决定哪些需要复用。
2. 软件架构复用的原因
减少开发工作、减少开发时间、降低开发成本、提高生产力、提高产品质量更好的互操作性使产品维护变得更加简单。
3. 软件架构复用的对象及形式
可复用的资产包括需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
一般形式的复用包括函数的复用、库的复用、面向对象开发中的类、接口和包的复用。
4. 软件架构复用的基本过程
1构造/获取可复用的软件资产复用的前提。首先需要构造恰当的、可复用的资产并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。
2管理可复用资产。该阶段最重要的是构件库Component Library其对可复用构件进行存储和管理是支持软件复用的必要设施。构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等以及支持使用者有效地、准确地发现所需的可复用构件。
3使用可复用资产。在最后阶段通过获取需求检索复用资产库获取可复用资产并定制这些可复用资产修改、扩展、配置等最后将它们组装与集成形成最终系统。 11.5 特定领域软件体系结构
11.5.1 DSSA的定义
DSSADomain Specific Software ArchitectureDSSA就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构即用于某一类特定领域的标准软件构件的集合。
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础其目标就是支持在一个特定领域中多个应用的生成。
从功能覆盖的范围的角度有两种理解DSSA中领域的含义的方式。
1垂直域定义了一个特定的系统族包含整个系统族内的多个系统结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。即在一个特定领域中的通用软件架构。
2水平域定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。如购物和教育都有收费系统收费系统即是水平域。
11.5.2 DSSA的基本活动
1. 领域分析
这个阶段的主要目标是获得领域模型领域需求。识别信息源即整个领域工程过程中信息的来源可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等在此基础上就可以分析领域中系统的需求确定哪些需求是领域中的系统广泛共享的从而建立领域模型。
2. 领域设计
这个阶段的主要目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案它不是单个系统的表示而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后就可以派生出满足这些被建模的领域需求DSSA。
3. 领域实现
这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到也可能需要通过新的开发得到。 11.5.3 参与DSSA的人员
参与DSSA的人员可以划分为4种角色
1领域专家包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。主要任务包括提供关于领域中系统的需求规约和实现的知识帮助组织规范的、一致的领域字典帮助选择样本系统作为领域工程的依据复审领域模型、DSSA等领域工程产品等。
2领域分析人员由具有知识工程背景的有经验的系统分析员来担任。主要任务包括控制整个领域分析过程进行知识获取将获取的知识组织到领域模型中。
3领域设计人员由有经验的软件设计人员来担任。主要任务包括根据领域模型和现有系统开发出DSSA并对DSSA的准确性和一致性进行验证。
4领域实现人员由有经验的程序设计人员来担任。主要任务包括根据领域模型和DSSA开发可重用的构件。
11.5.4 DSSA的建立过程
DSSA的建立过程分为5个阶段
1定义领域范围领域中的应用要满足用户一系列的需求。
2定义领域特定的元素建立领域的字典归纳领域中的术语识别出领域中相同和不相同的元素。
3定义领域特定的设计和实现需求的约束识别领域中的约束记录这些约束对领域的设计和实现会造成什么后果。
4定义领域模型和架构产生一般的架构并描述其构件说明。
5产生、搜集可复用的产品单元为DSSA增加复用构件使其可用于新的应用系统。
DSSA的建立过程是并发的、递归的、反复的和螺旋型的。 DSSA的三层次系统模型
·领域开发环境领域架构师决定核心架构产出参考结构、参考需求、架构、领域模型、开发工具。
·领域特定的应用开发环境应用工程师根据具体环境来将核心架构实例化。
·应用执行环境操作员实现实例化后的架构。
