一、在MDSD背景下的软件体系结构
专有名词“软件体系结构”非常重要，但遗憾的是它的定义却很含糊。
注意：软件体系结构在某种细节层次上描述的是软件系统的结构（分层、模块化等）和分类（模式、惯例等）。
软件体系结构这个课题在MDSD的各个子背景下发挥了一定的作用：
- 首先，一种软件体系结构用来想尽地组织要生成或要创建的软件系统。
- 一种MDSD域体系结构也是一种软件体系结构。它定义了整个元模型、DSL、平台和变换。域体系结构为一个软件系统族的产品提供了基础。
- 在MDSD背景下，软件体系结构与平台有关，其中它描述了最重要的平台组件、它们之间的相互作用以及它们的非功能性特征，这就是在这种背景下称它为平台体系结构的原因。
- 软件体系结构也在MDSD的变换中起到一定的作用，因为它确实定义了生成的代码的软件腿结构--正如前面解释过的。
- 最后，通用的MDSD工具也必须符合某种体系结构的标准，我们称之为工具体系结构。
二、什么是合理的体系结构
要创建的应用程序必须有一个合理的体系结构。从我们角度出发，一个合理的体系结构应具有下面的特征：
- 首先，体系结构必须充分支持应用程序的功能需求，它正式为该应用程序创建的。
- 此外，它必须实现预期的非功能性需求。
- 体系结构应该由一组尽可能小的被明确定义的构件组成，因此体系结构变得更加简单、更容易理解和更实用。
- 体系结构海应该允许应用程序的特殊增长/发展途径。
- 一个合理的体系结构也是记录良好的，这包括上面所列出的所有要点的一份简洁和简明的文档、说明如何基于该体系结构实现应用程序的一个编程模型和详细描述为什么要用那种方式创建体系结构及为什么可供选择的其他可能方法会落选的基本原理。
在MDSD背景下，还有两个其他的方面需要考虑：
- 首先，体系结构必须能够支持软件系统族的所有产品。
- 体系结构的概念必须被定义的更加清楚，否则不能通过变换从模型中自动生成它们。
三、如何获得一个合理的体系结构
在软件技术中，人们知道的工作良好的体系结构设计图是非常有限的。人们已经用各种形式对它们进行了描述，其中如模式或风格。
使用一个已经被尝试过病被测试过的模式或风格作为自己的体系结构的基础，已被证实是获得好的体系结构的一种方法。这里给出一些例子：
- 并发的联网对象模式描述了分散的多线程系统。
- 资源管理模式提出了资源管理在体系结构上的重要方面。
- 服务器组件模式描述了组件基础设施的内部体系结构，如EJB、CCM或COM+；
- 远程模式描述了远程中间件的内部体系结构，如CORBA、远程.net或web服务。
- 企业体系结构模式通常描述大型企业系统的体系结构。
- 企业集成模式描述了EAI系统和消息中间件的体系结构。
四、软件体系结构的基本构件
1.架构
架构是能够通过系统性的扩展或配置被调整成或扩展的任何事物。
MDS D在一定范围内可以起到辅助作用，因为它允许通过一种适当的DSL指定需要的特征。然后可以根据DSL构建的模型继续生成各种架构，因此架构和DSL是一对理想的组合：在架构的帮助下可以很好地实现MDSD平台。
2.中间件
中间件可以被看作是一种架构。在大多数情况下，它是针对某个技术领域的，例如分布式系统、信息或事务，并为某个目标体系结构提供技术基础。由于它聚焦在技术方面，所以中间件可以应用在许多功能性的专业领域中，而且经常是标准化的。著名的例子有CORBA、DCOM、MQSeries和CICS。
3.组件
组件基础设施是一种功能特别强大而且特别流行的中间件类型。
因此组件构成了整齐模块化和可汇编的系统的基础。许多域体系结构会定义组件或装配预制的组件来构造应用程序。
五、体系结构的参考模型
在实践中，一个分层的模型被证实在软件体系结构中是最有用的。在几乎所有结构良好的软件系统中都可以找到某种形式的这种结构。
一个体系结构的参考模型
操作系统和编程语言形成了每个体系结构的基础。在这种基础上，通常用一种技术架构，它提供基本的技术服务而经常用中间件实现。
典型的是找到一个基于该层的架构来为功能性的/专业的域提供基础。
- 实体代表了拥有一个身份特征和一个生命周期的那些概念。
- 值对象代表述职。
- 业务规则和约束。
- 服务。这里定义基本服务不能被分配给一个实体，例如执行一次交易，或在编辑系统中验证一个复杂文档的结构。
六、衡量MDSD平台
在参考模型范围内，目前已经有几个基本选项可以减少域和平台之间的概念上的差距：
- MDSD域和平台位于参考模型的技术平台层。
- MDSD域和平台位于目标体系结构的概念层。
- MDSD域和平遥位于参考体系结构的功能性/专业的平台层。
1例子
建议在项目过程中逐渐扩展自己的MDSD平台的功能，同时保持不断提高对该域的理解，这将降低代码开发者们必须写入定制架构的代码的范围和复杂度，该定制的构架必须是生成的活部分是手写的。
一般的规则是通用而且可归纳的代码段必须是MDSD平台的一部分。现有的架构通常是为MDSD平台中的集成量身订做的。
2.架构集成
复杂架构的使用可以被极大地简化并通过定制的DSL对其进行加速，这经常被纯架构论者所忽视。在另一方面，高度可配置的通用架构会使它们的实现具有负载过大的危险，这使得很难对它们进行维护和调试。应该在MDSD的平台建设中考虑它。一种重复的、增加的方法是成功地设计MDSD平台的关键，在与现实应用程序开发项目没有直接重复练习的大型、独立项目中开发功能强大的架构将不可避免地导致时报。反之，与代码生成结合在一起的小型架构为迭代开发提供了坚固的基础。
七、体系结构的一致性
只有在不被忽略或者没有日常事务所包围时，一种好的目标体系结构才能表现出的优势。在做大型的项目的时，传统的方法是不容易测量的，如复审和过量的文档。MDSD确实问生成的代码提供了解，特别是因为以变换规则的形式放弃了用模型描述的侧重体系结构的方面。
现在开发者不能再独立地获取任意的引用--它们只能访问在组件上下背景中存在存取器操作的那些引用。这些访问操作是从模型生成的。如果开发者希望访问其他接口，则必须在模型中包括这些借口，否则代码中就没必要的存取器方法可供使用，这保证了一个组件只具有在模型中明确声明的那些依赖关系。当然需要一个更加全面的基础设施：例如，“某人”必须调用init（）操作并提供正确的上下背景对象，在基于组件的系统中，这是容器的工作--在这种情况下就是负责组件生命周期的运行时间系统。
这种方法有着讨人喜欢的副作用，即在现代IDE中，通过代码完成化可以方便地告知哪种方法出现在组件上下背景中-因此可以直接在代码中找到有关合法依赖关系的信息，使得开发者观察体系结构的规则更加方便。
八、MDSD和CBD
就像面向服务的体系结构（SOA）一样，基于组件的开发（Component-Based。Development，CBD）是建造复杂系统的一种流行的象征。根据在开发项目中的经验，我们发现自己几乎总是首先对要构建的系统的组件结构进行建模。为此，我们从定义一个组件到底是什么开始---即，通过为基于组件的开发定义一个元模型。除了开发项目驻留的域，这些模型在应用程序的其他域--保险业、电子商务、无线天文学等内是很相似的。因此，这里给出这些元模型的一部分能够使读者在定义自己的组件体系结构时领先一步。
1.3个方面
1）类型方面
类型方面描述了组件的类型、接口和数据结构。一个组件提供了许多接口并引用了许多需要的接口。一个接口拥有很多操作，每一个都有一个返回类型、多个参数和例外。
为了描述组件使用的数据结构，从抽象类型出发，既使用基本类型，也使用复杂类型。一个复杂类型有许多名字和类型的属性。有两种复杂类型：数据传输对象用来在组件之间交换数据的简单工作。而实体有一个唯一ID而且可以固定不变。实体可以彼此引用并构成更加复杂的数据图。每个引用必须指定它是可双向操作的还是只能单向操作的。引用还指定了在各自终端的实体的基数。
2）组合方面
这个方面描述了组件实例及它们是如何连接的。配置由许多组件实例组成，每一个实例都知道自己的类型。一个实例有许多的连接线：一个连接线就是组件接口需求的一个实例。
使用类型和组合的方面，可以定义组件类型和它们之间的相互协作。可以定义应用程序的逻辑模型。例如，应该使用UML描述这两种模型，生成骨架类，然后在子类中实现应用程序逻辑。从组合方面出发，可以生成或者配置一个对组件的实例进行实例化的容器。这里可以运行验证应用程序逻辑的单元测试。
3）系统方面
描述了系统的基础设施，用前面两个方面定义的逻辑系统是在它的基础上展开的。
一个系统是由许多节点组成的，每个节点都有容器。一个容器可以容纳许多的组件实例。注意容器也定义自己的种类--这可以是类似CCM、J2EE、Ecipse或Sping的。基于这些信息，可以生成必要的“粘合”代码以便运行在那种容器中的组件。
由节点信息和定义在组合模型中的连接可以生成任何事物，从远程通信基架代码和配置到构建和打包脚本。
2、方面之间的依赖关系
模型间的依赖关系是构造良好的。要用相同的组件和接口定义几种组合，在几个基础设施上运行相同的组合。
方面模型之间的依赖关系
3、侧重面模型
上面描述的3中观点是建模和构建基于组件的系统的一个很好的起点。不过，在大多数情况下着个模型是不够的。必须用被安排在这3个核心方面周围的特定侧重面的模型描述系统的其他方面。
在独立的侧重面模型中应典型处理如下方面：
- 持久性
- 授权和身份验证
- 表格、布局、页面流
- 定时、调度和其他服务方面的质量
- 包装和配置
- 诊断和监控
侧重面模型的思想是信息并不是要加在3个主要观点上，而是要用带有一种合适的具体语法的独立模型描述。此外元模型的依赖关系是重要的：侧重面可以依赖于核心方面模型，甚至可能依赖于另一个侧重面，不过核心方面不依赖于任何侧重面模型。
4、变型形式
在每个项目中，不能完全按照这种方式使用上面描述的元模型。在许多情况下需要对构成一个组件的概念进行扩展。因此这种元模型由很多的变型形式。不过，从经验中判断，这些变型形式是有限的
- 可能不需要接口
- 通常会需要不同种类的组件，如域组件、数据访问组件、过程组件或业务规则组件。
- 另一种管理依赖关系的方法是用一个层标签标记每个组件，如域、服务、GUI或正面，并定义对这些层中组件如何相互i来的约束
- 层结构组件是一种功能强大的工具。
- 一个组件可能有许多的配置形参
- 有人可能会问组件是无状态的还是有状态的，它们是否是线程安全的以及它们的生命周期是怎样的。
- 使用简单的同步通信并不总是充分的。
- 除了通过接口通信，还需要使用一种静态或动态发布者/用户基础设施的事件。
- 组合模型静态连接组件的实例。
- 最后，提供其他的方法对复杂系统进行结构化是必要的。
5、组件实现
组件实现通常是手工完成的，这表明开发者是通过将代码直接加入生成的类，或者用一种更好的方法，通过使用其他组合方式，如继承或部分类，将手写的代码加入组件骨架中。主要原因是支持模型层应用程序的通用表达的动作语言仍然没有收到广泛地支持。但是，使用一种通用的动作语言来描述结构化工件的行为只是选项之一。还有其他描述应用程序逻辑的方法，下面概括了其中几种。所有方法的相同支持是它们使用应该指定的针对那种行为的表示法，而不是提供一种通用的方式对模型中的各种行为进行建模。
- 在通过设置少量定义好的可变点确定有规律的行为在模型中的参数之后，可以用生成器实现它。
- 对于基于状态的行为，可以使用状态机。
- 对诸如业务规则的行为，可以定义一个直接表达这些规则的DSL，并使用一个规则引擎对它们进行评估。
- 对特定域计算，如保险域中普遍存在的那些，要为该域提供一种支持数学操作的特定文本表示法。
既然组件实现是关于行为的，因此使用一个封装在组件哪的解释程序通常在技术上是有用的。这种“解释程序组件”还是一种和其他组件一样的组件。
九、SOA、BPM和MDSD
面向服务的体系结构（SOA）和业务流程管理（Business Process Management，BPM），是目前在IT业内被大肆宣传的两个话题。
1、SOA
实际上，SOA至少是一种web服务技术驱动的，包括业务流程执行语言（business process execution language，bpel）。从我们的角度出发，SOA与特定的技术（WSDL、SOAP、Http）无关，但是它是由一些构建大型、可测量并可组合系统体系结构方面的最好时间组成的。有理由将一个结构良好的基于组件的体系结构视为SOA，该体系结构具有定义良好的接口和明确的组件职责。组件用于构建提供和消费服务的基本构件，行业意识到了这一点并且目前定义了一个服务组件体系结构（SCA）的标准。
服务应该是设计简略的而且封装从商业的角度看相关的功能---尽管没有人可以说这究竟意味着什么！服务一般是被显式建模的业务流程使用的，补货却不是只能被它使用。最后，和所有好的IT系统一样，它们是安全的、事务的和可管理的。
人们对这些特征与目前构造良好的商业系统是否真的差别这么大持有不同的观点。不过，在我们看来，很明显模型在面向服务的系统定义和操作中发挥了重要的作用。
因此，在SOA的主要思想是首先确立一个接口契约。开发系统的时候要指定的第一件事情是通信双方实际上是如何相互作用的--它独立于通信技术，也独立于实现平台。更确切的说，在一个抽象的正是层次上指定消息格式、相互作用的模式和服务契约的质量。
2、BPM
和SOA一样，BPM也没有普遍认可的定义。不过在行业权威中有一种大多数人同意的说法。
BPM处理业务流程和设计的控制，这产生的任务是这些工件的构造、自动化和优化。
- 业务流程用可用的信息技术和物质来连接我们。
- 过程定义和实现必须是灵活的，这样才能改变它们来满足自己的业务的价值创造链。
- BPM遵守完整的业务流程生命周期，它由定义、创建、执行、健康和优化组成。
- BPM不是一个产品而且下面任何一个单独的产品分类都不能说完全覆盖BPM：工作流程、企业应用集成（EAI）、流程活动监控（BAM）、规则引擎、过程仿真。在理想情况下，它们可以是支持BPM的系统（BPMS）的一部分。
BPM的一个独立的MDSD观点是很明显的：为了实现目标，模型和变换已经成为BPM的基本概念。
3、SOA和BPM
SOA和BPM存在一个交集：一方面是业务流程的建模和规范，另一方面是各自的基础设施软件（中间件）。SOA用构建在web服务技术基础上并与之耦合的业务流程执行语言来完成业务流程的建模。BPM用跟腱抽象的语言概念和表示法来完成业务流程的建模。因此从某个特定的角度出发，可以说SOA是一种从下到上的发展过程，而BPM是自顶向下。SOA放在交集的中间件主要被看作是企业服务总线ESB，它应该被看作是消息、服务组合和协调指挥的一条逻辑总线，还给出了业务流程引擎或BPMS。
MDSD/MDA放在SOA和BPM结合在一起的背景下来总结本小节内容：
- MDSD/MDA提供对业务流程进行基于标准的建模（即标准化的基于MOF的BPM元模型的定义）和各自“通用”的表示法。OMG已经建立了相应的活动。
- MDSD/MDA能够提供一条合理的、完整的而且以体系结构为中心的MDSD产品线，它以一种连贯的、定义好的方式支持一个企业体系结构的所有层（业务流程、服务/组件、实体、持久化）。
- 有人声称MDSD使服务成为可能--即为了使它们对BPM有帮助而重新设计面向SOA单片集成的传统应用程序--很有帮助，因为从现有的应用程序中得到的模型可以用作那些应用程序的基础。因而这种思想是需要付出很多努力的，至少是值得一提的。