模型驱动软件开发:技术、工程与管理(国外计算机科学经典教材)
点此进入淘宝搜索页搜索分類: 图书,计算机与互联网,软件工程及软件方法学,软件过程,
品牌: 斯多
基本信息·出版社：清华大学出版社
·页码：381 页
·出版日期：2009年
·ISBN：7302189145/9787302189145
·条形码：9787302189145
·包装版本：1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：国外计算机科学经典教材
产品信息有问题吗？请帮我们更新产品信息。
内容简介模型驱动的软件开发（MDSD）是当前受到开发人员和研究人员高度关注的开发范型。随着OMG的MDA和Microsoft的SoftwareFactories的出现，MDSD方法已经越来越受到程序员的关注，并且成为一些国际协会（例如OOPSLA、JAOO和OOP）的重点讨论议题。
MDSD使用域特定语言创建模型，这种模型以有效的、域特定方式表达应用程序结构或行为。通过一系列模型转换过程，这些模型随后被转换为可执行的代码。
《模型驱动软件开发:技术、工程与管理》是一本面向软件架构师和开发人员的实践指南，包括了大量实践范例和丰富的案例研究。
作者简介Thomas Stahl，是b+m Informatik AG的首席架构师，主要研究模型驱动的软件开发，并且是这方面的专家，具有广泛的实践经验。Thorrlas还是期刊作家，IT会议的演讲者，以及开放源代码的、MDSD平台的openArchitectureWare的创始者。
Markus Volter，是软件技术和工程方面的独立顾问，关注于软件体系结构和模型驱动的软件开发，并且是这些方面广泛认可的权威。Markus是Wiley出版社软件设计模式系列图书的作者。
编辑推荐《模型驱动软件开发:技术、工程与管理》特色
·全面介绍了MDSD，以及它如何与一些行业标准关联，例如MDA和Software Factorles。
·关于元建模、DSL一构造、模型之间以及模型和代码之间的转换、软件体系结构方面的技术细节
·深入了解软件开发过程以及一些工程问题（例如版本化、测试和产品线工程）
·涉及经济和企业主题的基本管理知识(从全局的观点进行介绍）
目录
目录
第Ⅰ部分 导论
第1章 绪论3
1.1 本书的主题3
1.2 目标读者4
1.2.1 软件体系结构5
1.2.2 软件程序员5
1.2.3 经理和项目主管5
1.3 本书的目标5
1.4 本书的范围6
1.5 本书的结构及读者指南6
1.6 关于作者7
1.7 关于封面8
1.8 致谢8
第2章 MDSD的基本思想和术语11
2.1 挑战11
2.1.1 历史回顾12
2.1.2 现状12
2.2 MDSD目标13
2.3 MDSD方法14
2.4 基本术语15
2.5 以体系结构为中心的MDSD20
2.5.1 动机21
2.5.2 生成软件体系结构21
2.5.3 以体系结构为中心的设计23
2.5.4 开发过程25
2.5.5 以体系结构为中心的MDSD属性26
第3章 一个典型的Web应用案例分析29
3.1 应用程序开发29
3.1.1 应用程序实例30
3.1.2 MDSD工具32
3.1.3 例1：模型的简单变化32
3.1.4 例2：模型的变化和保护区35
3.1.5 例3：使用动态模型37
3.1.6 开发和体系结构之间的相互作用39
3.1.7 中间结果39
3.2 体系结构开发39
3.2.1 UML配置文件40
3.2.2 变换41
3.2.3 MDSD生成器的运行模式46
3.2.4 引导程序47
3.2.5 调整生成软件体系结构47
3.2.6 基架代码的边界51
3.2.7 结构化元程序52
3.3 结论和展望52
第4章 概念形成53
4.1 MDSD通用概念和术语53
4.1.1 建模53
4.1.2 平台57
4.1.3 变换58
4.1.4 软件系统族59
4.2 模型驱动体系结构60
4.3 以体系结构为中心的MDSD61
4.4 生成编程62
4.5 软件工厂64
4.5.1 软件工厂大纲64
4.5.2 软件工厂模板65
4.5.3 DSL的作用以及它与MDSD的关系65
4.6 模型集成计算66
4.7 面向语言编程66
4.8 特定域建模67
第5章 分类69
5.1 比较MDSD与CASE、4GL和向导69
5.2 比较MDSD与双向工程70
5.3 MDSD和模式71
5.3.1 模式和变换71
5.3.2 模式和配置文件72
5.3.3 作为一种DSL源的模式语言72
5.4 MDSD和域驱动设计72
5.5 MDSD、数据驱动开发和解释程序73
5.6 MDSD和敏捷软件开发73
5.6.1 敏捷宣言和MDSD74
5.6.2 敏捷技术75
第Ⅱ部分 域体系结构
第6章 元建模79
6.1 元模型的定义79
6.2 比较元层和抽象层82
6.3 MOF和UML82
6.4 扩展UML83
6.4.1 基于元模型扩展83
6.4.2 用UML 1.x的类别模板扩展85
6.4.3 用UML 2.0的配置文件扩展86
6.5 UML配置文件86
6.6 元建模和OCL89
6.7 元建模：例190
6.8 元建模：例292
6.9 工具支持的模型验证94
6.10 元建模和行为98
6.11 一个更加复杂的例子100
6.11.1 基础100
6.11.2 值类型101
6.11.3 物理量103
6.12 元建模中的缺陷105
6.12.1 接口105
6.12.2 依赖性106
6.12.3 ID106
6.12.4 基本键107
6.12.5 元层和Instanceof108
第7章 可以使用MDSD的目标体系结构111
7.1 在MDSD背景下的软件体系结构111
7.2 什么是合理的体系结构112
7.3 如何获得一个合理的体系结构113
7.4 软件体系结构的基本构件114
7.4.1 架构114
7.4.2 中间件115
7.4.3 组件115
7.5 体系结构的参考模型116
7.6 衡量MDSD平台117
7.6.1 例子118
7.6.2 架构集成119
7.7 体系结构一致性119
7.8 MDSD和CBD121
7.8.1 3个方面121
7.8.2 方面之间的依赖关系124
7.8.3 侧重面模型124
7.8.4 变型形式125
7.8.5 组件实现127
7.9 SOA、BPM和MDSD128
7.9.1 SOA128
7.9.2 BPM130
7.9.3 SOA和 BPM131
第8章 构建域体系结构133
8.1 DSL构造133
8.1.1 选择一种合适的DSL133
8.1.2 配置和构造——变型形式134
8.1.3 建模行为137
8.1.4 具体语法问题138
8.1.5 元模型的连续式验证138
8.2 一般变换的体系结构139
8.2.1 应该生成目标体系结构的哪个部分139
8.2.2 相信再生139
8.2.3 开发模型140
8.2.4 生成漂亮的代码——只要可能141
8.2.5 模型驱动集成142
8.2.6 分离生成的和非生成的代码142
8.2.7 模块变换143
8.2.8 层叠的模型驱动开发146
8.3 建立变换的技术方面148
8.3.1 生成的代码和手工实现部分的显式集成148
8.3.2 虚拟代码152
8.3.3 技术子域154
8.3.4 代理元素155
8.3.5 外部模型标记156
8.3.6 方面定位和MDSD156
8.3.7 描述性元对象157
8.3.8 生成的反射层159
8.4 解释程序的使用160
8.4.1 解释程序161
8.4.2 再次访问MDSD术语162
8.4.3 解释程序的非功能性属性163
8.4.4 在一个系统中集成解释程序164
8.4.5 解释程序和测试165
第9章 代码生成技术167
9.1 代码生成——选择它的原因167
9.1.1 性能167
9.1.2 代码规模167
9.1.3 可分析性168
9.1.4 早期错误检测168
9.1.5 平台兼容性168
9.1.6 （编程）语言的限制168
9.1.7 模块单元168
9.1.8 自我测量168
9.2 分类168
9.2.1 元编程169
9.2.2 程序和元程序的分离/混合169
9.2.3 生成的和非生成的代码的隐式或显式集成170
9.2.4 关系170
9.2.5 程序和元程序混合的例子170
9.3 生成技术171
9.3.1 模板和滤波172
9.3.2 模板和元模型174
9.3.3 框架处理器174
9.3.4 基于API的生成器176
9.3.5 内联的生成179
9.3.6 代码品质180
9.3.7 代码交织181
9.3.8 组合不同的技术183
9.3.9 不同方法间的共同点和不同点183
9.3.10 其他系统185
第10章 使用QVT进行模型转换187
10.1 历史187
10.2 M2M语言需求188
10.3 整体的体系结构190
10.4 转换示例192
10.4.1 QVT Relations语言中的示例195
10.4.2 QVT Operational Mappings语言中的示例199
10.5 OMG标准化过程和工具可用性202
10.6 评估203
第11章 MDSD工具：角色、体系结构、选择标准和指南205
11.1 工具在开发过程中的角色205
11.1.1 建模206
11.1.2 模型验证和代码生成206
11.1.3 构建工具207
11.1.4 处方框架208
11.1.5 IDE工具箱208
11.2 工具体系结构和选择标准209
11.2.1 实现元模型209
11.2.2 忽略具体语法209
11.2.3 模块化的转换211
11.2.4 模型转换的重要性211
11.3 指针211
11.3.1 Eclipse的世界211
11.3.2 UML工具的发展趋势214
11.3.3 UML 2复合结构图214
11.3.4 其他类型的编辑器216
11.3.5 集成的元建模IDE216
第12章 MDA标准221
12.1 目标221
12.2 核心概念222
12.2.1 UML 2.0222
12.2.2 MOF——元对象设施223
12.2.3 XMI224
12.2.4 PIM/PSM/PDM224
12.2.5 多个阶段的转换225
12.2.6 动作语言226
12.2.7 核心模型228
12.2.8 控制PIM到PSM的转换229
12.2.9 可执行的UML231
第Ⅲ部分 过程和工程
第13章 MDSD过程构件和最佳实践235
13.1 简介235
13.2 应用程序和域体系结构开发的分离236
13.2.1 基本原理236
13.2.2 域体系结构开发线程237
13.2.3 应用程序开发线程242
13.3 双轨的迭代开发243
13.4 目标体系结构开发过程244
13.4.1 3个阶段245
13.4.2 阶段1：详细描述246
13.4.3 阶段2：迭代249
13.4.4 阶段3：自动化249
13.5 产品线工程251
13.5.1 软件系统家族和产品线251
13.5.2 与MDSD过程的集成251
13.5.3 方法学252
13.5.4 域建模255
13.5.5 更多的读物255
第14章 测试257
14.1 测试类型257
14.2 模型驱动应用程序开发中的测试258
14.2.1 单元测试259
14.2.2 接受测试264
14.2.3 加载测试265
14.2.4 非功能性测试266
14.2.5 模型确认266
14.3 测试域体系结构267
14.3.1 测试引用实现和MDSD平台267
14.3.2 DSL的接受测试267
14.3.3 MDSD转换的测试268
第15章 版本化271
15.1 版本化的概念271
15.2 项目和相关性272
15.3 应用程序项目的结构272
15.4 混合文件的版本管理和构建过程273
15.5 团队中的建模和部分模型的版本化275
15.5.1 分区与子域275
15.5.2 各种生成的软件体系结构276
15.5.3 DSL的发展276
15.5.4 分区和集成277
第16章 案例研究：嵌入式的组件基础结构281
16.1 概述281
16.1.1 简介和动机282
16.1.2 组件基础结构282
16.1.3 嵌入式系统的组件基础结构282
16.1.4 基本方法283
16.2 生产线工程283
16.2.1 域作用范围283
16.2.2 可变性分析和域结构化284
16.2.3 域设计287
16.2.4 域实现289
16.3 建模289
16.3.1 接口的定义289
16.3.2 组件和端口的定义290
16.3.3 系统的定义291
16.3.4 完整的模型294
16.3.5 处理294
16.4 组件的实现295
16.5 生成器改进297
16.5.1 解析文本语法297
16.5.2 解析系统定义XML299
16.5.3 解析和合并完整的模型300
16.5.4 伪声明的元模型实现302
16.6 代码生成304
16.6.1 引用304
16.6.2 多态性307
16.6.3 元模型中涉及内容的分离309
16.6.4 构建文件的生成311
16.6.5 使用AspectJ312
第17章 案例研究：企业系统315
17.1 概述315
17.2 阶段1：详细描述315
17.2.1 技术无关的体系结构315
17.2.2 编程模型316
17.2.3 技术映射317
17.2.4 模拟平台318
17.2.5 垂直原型318
17.3 阶段2：迭代318
17.4 阶段3：自动化319
17.4.1 体系结构元模型319
17.4.2 粘接代码(glue code)生成320
17.4.3 基于DSL的编程模型320
17.4.4 基于模型的体系结构验证327
17.5 讨论328
第Ⅳ部分 管理
第18章 决策支持331
18.1 业务潜力331
18.2 自动化和重用332
18.3 质量336
18.3.1 良好定义的体系结构336
18.3.2 保存的专家知识336
18.3.3 严格的编程模型336
18.3.4 更新的和可用的文档337
18.3.5 生成代码的质量337
18.3.6 测试工作和可能的错误来源337
18.4 重用338
18.5 可移植性、易变性339
18.6 投资和可能的收益339
18.6.1 体系结构中心的MDSD339
18.6.2 功能/专业MDSD域343
18.7 关键问题344
18.8 结论347
18.9 推荐读物347
第19章 组织方面349
19.1 角色的分配349
19.1.1 域体系结构开发349
19.1.2 应用程序开发352
19.2 团队结构352
19.2.1 角色和人员配备需求的定义353
19.2.2 跨领域团队354
19.2.3 体系结构组的任务354
19.3 软件产品开发模型356
19.3.1 术语356
19.3.2 内部开发356
19.3.3 经典的外部采购357
19.3.4 离岸外包357
19.3.5 激进的离岸外包358
19.3.6 受控制的离岸外包359
19.3.7 与组件有关的决策359
第20章 MDSD的改进策略361
20.1 预备知识361
20.2 开始学习——MDSD试验361
20.2.1 风险分析362
20.2.2 项目初始化362
20.3 已有系统的MDSD改进363
20.4 软件库存的分类364
20.5 构建、购买或开放源代码366
20.6 供应链的设计366
20.7 域体系结构的渐进发展368
20.8 风险管理368
20.8.1 风险：以工具为中心368
20.8.2 风险：开发工具链对MDSD起反作用368
20.8.3 风险：负担过重的域体系结构团队369
20.8.4 风险：瀑布过程模型、以数据库为中心的开发369
20.8.5 风险：脱离实际的个人369
20.8.6 风险：没有分离应用程序和域体系结构370
附录A 模型转换代码371
A.1 完整的QVT alma2db关系数据库示例371
A.2 完整的QVT操作映射alma2db示例377
……[看更多目录]
序言建模是一种关键的工程工具。在分析和设计复杂系统的时候，工程师们通常要创建模型。模型是对一个系统及其环境的一种抽象。模型允许工程师们有效地表达自己对系统的关注，例如回答特定的问题或者对设计做出必要的修改。每个模型的创建都是有目的的。特定的模型也许适合解答一类特定的问题。在这种情况下，对于模型和实际系统而言，这类问题的答案都是一样的。然而，这个特定的模型却不一定适合解答其他类问题。构造模型也比搭建实际系统花费少。例如，为了检查结构的安全性，国内的工程师们建造了静态和动态的桥梁结构模型。这是因为与建造真实的桥梁相比，用建模的方法观察桥梁在何种情况下倒塌的确花费更少且更加有效。
在软件开发中，模型由来已久。在过去的几十年中，软件行业内出现了许多分析和设计方法。每一种方法都有自己的建模方法和表示法。近年来，统一建模语言（Unified Modeling Language，UML）得到了显著的发展。现在，UML对市场的渗入程度要大于以前任何一种建模表示法的渗入程度。尽管如此，分析和设计模型很少能和代码具有相同的地位。绝大多数软件项目的现实使模型并不会随代码的更新而实时更新，因此它们会随时间的过去而被废弃并失去价值。
模型驱动软件开发（Model-Driven Software Development，MDSD）将分析和设计模型与代码同等对待。将该模型和代码更好地集成起来可以通过模型来大大增加有效改进的机会，而不仅仅是直接修改代码。MDSD涉及到许多不同的技术，这些技术贯穿了整个软件开发过程，包括模型驱动需求工程、模型驱动设计、通过模型生成代码、模型驱动测试及模型驱动软件演变等。
对象管理组（Object Management Group，OMG）首次提出的模型驱动体系结构（Model-Driven Architecture，MDA）使人们对软件建模和模型驱动技术越来越感兴趣。然而，这种概念的提出有利有弊。在积极的方面，值得高兴的是，建模已经引起了人们的很大兴趣，并且各个组织正在尝试使用模型驱动技术改进自己目前的实践。与此同时，围绕MDA的大肆市场宣传倾向于产生一些不切实际的期望。不考虑这些宣传，的确可以认为MDSD提供了很多思想，其中许多思想可以用在现今的实际情况中。认识到这些潜在的发展趋势需要深刻地理解目前的MDSD技术、其适用性及其局限性。
本书的作者站在MDSD研究和实践的前沿。在一些OOPSLA会议上，Markus和Jorn曾经组织并参与了一系列MDSD工作室。Simon参与了OMG对模型变换的标准化。所有的作者都在若干领域内倡导将这项技术用于实践，涉及的领域涵盖了诸如b+m、Siemens和BMW等小型公司和大型公司的企业应用和嵌入式软件。
文摘一个组件可能有许多配置形参——与控制台应用程序中命令行的实参相当——用于配置组件的行为。形参和它们的类型是在类型模型中被定义的，随后指定形参的数值，例如在组合或者系统模型中。
有人可能会问组件是无状态的还是有状态的，它们是否是线程安全的以及它们的生命周期是怎样的（例如，它们是被动的还是主动的，它们是否希望被告知生命周期的事件，如激活等）。
使用简单的同步通信并不总是充分的。各种异步通信模式中的某种模式，如在[VKZ04]中描述的，可能也是可以应用的。因为使用这些模式会影响组件的API，因此必须在类型模型中标明要使用的模式，如图7.13所示。
插图：
