具体描述
编辑推荐
在整本书中，Lahman都为理论问题进行了例证，解释为什么事情应该这样完成，但对读者没有很高的数学要求。他关注于创建实现无关的模型，该模型可以完全地、精确地、无二义性地解决功能性需求。无论你是开发人员、团队的领导、架构师或者设计师，书中介绍的技术都将帮助你构建更加健壮、易于维护、支持大规模重用的软件。
内容简介
当今世界，软件变得越来越复杂，软件的用户对软件性能、可靠性、功能性以及交付市场的速度等方面的期望也在呈指数增长。本书通过将经过证实有用的面向对象技术与一种强大的新方法学相结合，为我们展示了应对这些挑战的方法。
《基于模型的软件开发》详细介绍了基于模型的软件开发的核心原则，展示如何分离每一个项目的关注点，使得参与者能够为每个域特有的需要和特征进行优化，通过实例展示如何实施更有效的面向对象的分析、强调抽象、严格的分区、不变量建模、有限状态机和程序单元之间的高效通信。通过阅读本书，你将学到：
回顾面向对象方法诞生的历史背景及面向对象开发的基础。
讲解用于反映设计中用户和计算机环境之间重要区别的问题域和计算域。
为什么应用分区很重要以及如何很好地进行应用分区。
构建描述基本应用结构的静态模型。
为类、类的职责、关联、引用完整性和知识完整性建模。
创建动态模型，用于通过有限状态机描述行为。
成功地使用抽象动作语言（Abstract Action Language，AAL）和动作数据流图（Action Data Flow Diagram，ADFD）。
《基于模型的软件开发》共分三部分，共有18章。第一部分（第1～6章）重点介绍面向对象方法诞生的历史背景，阐述面向对象的方法旨在解决的问题。第二部分（第7～13章）讨论面向对象开发的基本原则如何应用于MDB方法学中，如何定义稳定的应用结构或框架。第三部分（第14～18章）讲述如何利用动态模型描述动态计算需要。
??
作者简介
H.S. Lahman，1957年在插件板上写了他的第一个软件程序。在接下来的十年，他作为勘探地球物理学家在很多重要的沼泽、沙漠和苔原的丛林中使用尖端技术，这些磨练了他的意志。然后，他回到学校学习经济学、运筹学和计算学。在接下来的30年中，他为MIS系统、科学和R-T/ E环境开发软件。1982年，他成为一名面向对象开发的倡导者。20世纪90年代，他成为一名软件质量和开发过程改进的倡导者。
廖彬山，先后就读于南京大学数学系和北京航空航天大学计算机科学与技术系。现在是美国CMU／SEI认证CMMI主任评估师（CMU／SEI-certified SCAMPI Lead Appraiser），北京国信普道科技有限公司CMMI首席顾问，北京航空航天大学软件学院客座教授。目前主要从事CMMI的培训、咨询和评估工作及软件工程理论与方法的研究工作。迄今为止，已经成功地为几十家不同类型、不同规模、不同应用领域的企业进行了基于CMM和CMMI的咨询与评估工作，积累了丰富的实践经验，有效地解决了企业实际存在的问题。已经成功地为国内近百家企业提供了软件估算、软件度量与量化管理、功能点、统计过程控制、高成熟度组织的过程改进、个体软件过程（PSP）、团队软件过程（TSP）、需求工程、缺陷管理、软件测试、同行评审、持续风险管理、统一软件开发过程等专题培训，有效地提高了国内企业的项目管理和工程开发能力。
王慧，毕业于北京航空航天大学计算机学院，工学博士，研究方向为软件工程和过程工程。她曾从事大型软件过程建模与模拟系统的需求开发、软件设计与实现、系统测试等工作。目前是一名咨询师，成功地为多家不同类型、不同规模、不同应用领域的企事业单位进行了敏捷开发方法、软件项目管理、CMMI、TSP和PSP等咨询工作，有效地解决了企业实际存在的问题。
马苏宏，毕业于北京航空航天大学计算机学院，工学硕士，研究方向为过程工程的建模、模拟与正向工程。曾就职于IBM公司，担任软件工程师，有丰富的软件设计与开发经验。目前是一名业余的翻译爱好者。
目录
译者序
前言
引言
第一部分 面向对象开发的根本
第1章 历史的视角 2
1.1 历史 2
1.2 结构化开发 3
1.3 宝贵教训 8
1.3.1 全局数据 9
1.3.2 巨程序单元 9
1.3.3 软件结构 10
1.3.4 缺乏内聚性 10
1.3.5 耦合 10
1.4 技术革新 12
1.4.1 图灵机 13
1.4.2 语言和方法学 13
1.4.3 集合和图 16
1.4.4 范式 16
1.4.5 数据流 18
1.4.6 状态机 20
第2章 对象技术 22
2.1 基本理念 22
2.1.1 可维护性 22
2.1.2 问题域抽象 23
2.1.3 OOA、OOD和OOP 24
2.1.4 主题 25
2.1.5 关注点分离 26
2.1.6 抽象层次 26
2.1.7 问题域抽象 28
2.1.8 封装 29
2.1.9 内聚性 29
2.1.10 逻辑不可分性 30
2.1.11 通信模型 31
2.2 广度优先处理（又称对等协作） 32
2.2.1 细化与转化 33
2.2.2 消息范式 35
2.2.3 对象特征 36
第3章 泛化、继承、泛型和多态 39
3.1 泛化 39
3.2 继承 42
3.3 多态 42
3.4 泛型 45
第4章 MBD路线图 46
4.1 问题域和计算域 46
4.1.1 问题域 48
4.1.2 计算域 49
4.1.3 转换 50
4.2 可维护性 50
4.2.1 领域分析 50
4.2.2 不变量建模 51
4.2.3 应用分区 52
4.2.4 静态视图 52
4.2.5 动态视图 52
第5章 不变量建模 55
5.1 什么是不变量建模 55
5.1.1 不变量 56
5.1.2 数据 57
5.2 好处 58
5.3 例子 60
5.3.1 银行ATM软件 60
5.3.2 硬件接口 64
5.3.3 折旧 67
5.3.4 远程POS输入示例 72
第6章 应用分区 76
6.1 为什么我们要关注 76
6.2 应用分区的基本概念 77
6.2.1 主题 79
6.2.2 客户端/服务关系 82
6.2.3 抽象层次 84
6.2.4 接口 85
6.3 识别子系统 86
6.3.1 将相同的实体抽象为其他子系统时，当前子系统是否存在不同的视角 86
6.3.2 是否存在客户端/服务的关系 86
6.3.3 服务是否比客户端更加详细 87
6.3.4 是否与其他子系统知识共享 87
6.3.5 是否与其他子系统行为共享 87
6.3.6 主题是否内聚 87
6.3.7 边界定义是否清晰 88
6.3.8 能否重用 88
6.3.9 是否被分布式网络环境绑定 88
6.3.10 是否针对不同的问题域 88
6.4 桥 89
6.4.1 消息范式，又是消息范式 89
6.4.2 桥模型 91
6.5 描述子系统 92
6.5.1 子系统描述 93
6.5.2 关系描述 94
6.5.3 需求分配 94
6.6 一个例子：宠物保健中心 94
6.7 过程 106
第二部分 静?态?模?型
第7章 第二部分路线图 112
7.1 什么是静态模型 113
7.2 知识和行为 114
7.3 实用的注释 115
第8章 类 117
8.1 抽象表示 117
8.1.1 为真实的东西建模 118
8.1.2 局限于子系统或组件中 119
8.1.3 逻辑不可分性 119
8.1.4 委托 120
8.2 类表示法 121
8.3 识别类及其职责 122
8.3.1 对象“突击” 123
8.3.2 用例变异 124
8.4 例子 125
8.4.1 传奇的银行ATM控制器 125
8.4.2 宠物保健中心：处置 131
8.5 使用序列图和协作图 134
第9章 类的职责 137
9.1 属性：一个类对象应该知道什么 137
9.1.1 定义和表示法 137
9.1.2 与数据存储不同 138
9.1.3 状态 139
9.1.4 抽象数据类型 140
9.2 操作和方法：对象必须做什么 142
9.2.1 定义和表示法 142
9.2.2 识别行为 144
9.2.3 拟人化 148
9.3 过程 149
9.4 例子 150
9.4.1 ATM 150
9.4.2 宠物保健中心：处置 158
第10章 关联 165
10.1 定义与基础 165
10.2 表示法 170
10.3 逻辑连接的性质 172
10.3.1 导航到知识与导航到行为 173
10.3.2 关联角色 174
10.3.3 关联路径 175
10.4 条件性 178
10.5 多重性 182
10.5.1 使用“一个”模型替换问题域的“一个或更多个”模型 183
10.5.2 为问题域关联提供二次关联 184
10.5.3 选择和参与 185
10.6 约束 187
10.7 关联类 189
10.8 识别关联 192
10.9 例子 195
10.9.1 ATM控制器 195
10.9.2 宠物保健中心：处置 198
第11章 引用完整性和知识完整性 200
11.1 知识完整性 200
11.1.1 及时性 201
11.1.2 一致性 201
11.1.3 快照和实时访问 202
11.1.4 依赖属性 202
11.1.5 属性标准化 204
11.2 引用完整性 207
11.2.1 标识与引用属性 207
11.2.2 关联循环 209
11.2.3 关系和面向对象范式：完全不同 211
第12章 泛化归来 213
12.1 子类化 213
12.1.1 表示法和规则 215
12.1.2 泛化和特定化 216
12.1.3 分类 219
12.1.4 包含多态 223
12.1.5 为什么是{相交，完整}的子集 225
12.2 多方向子类、多重继承与组合 227
12.3 泛化的备选 235
12.3.1 委托 236
12.3.2 参数多态 238
12.3.3 基本抽象 238
第13章 识别知识 239
13.1 面向对象知识的性质是什么 239
13.2 抽象聚合 241
13.3 挑选适合的抽象 245
13.3.1 抽象人们做什么 246
13.3.2 潜在实体知道哪些 247
13.3.3 对象抽象应当知道哪些实体知识的子集 248
13.3.4 主题是什么 248
13.3.5 抽象层次是什么 251
13.4 抽象是否需要结合实体知识 252
第三部分 动?态?模?型
第14章 第三部分路线图 258
14.1 第三部分路线图 258
14.1.1 一切都关乎行为 259
14.1.2 对象生命周期 261
14.1.3 异步解决方案 262
14.1.4 同步服务 266
14.2 动作语言 269
14.3 Mealy机、Moore机和Harel机 270
14.4 学习曲线 272
第15章 有限状态机 273
15.1 基本的有限状态自动机 273
15.1.1 表示法 277
15.1.2 契约设计的作用 280
15.2 寻找状态机 283
15.2.1 知识和行为 283
15.2.2 管理序列 286
15.3 一些例子 295
15.3.1 车库门遥控器 295
15.3.2 自动家庭厨房 297
15.3.3 空中交通管制系统 297
15.3.4 岩石 298
第16章 状态、转换、事件和动作 300
16.1 状态 300
16.2 转换 305
16.3 事件 306
16.4 动作 309
16.5 执行模型 311
16.6 命名约定 313
第17章 开发状态模型 316
17.1 设计状态机 316
17.2 例子 325
17.2.1 ATM控制器：字符显示 326
17.2.2 ATM控制器：调度器 331
17.2.3 ATM控制器：存款 340
第18章 抽象动作语言 344
18.1 AAL和ADFD 345
18.2 AAL语法 346
18.3 例子 348
18.3.1 车库门遥控器 348
18.3.2 ATM：字符显示 351
术语表 354
前言/序言
软件开发是一项极其复杂的智力活动，它是一门朝气蓬勃并且仍在迅速发展的学科。软件开发还不够完善，因此迄今人们仍然在试图找出开发软件的好方法。 尽管如此，多年来软件开发方法仍然获得了大幅提升。许多设计方法学不断发展以促进软件设计的各个方面。其中之一是结构化设计方法，该方法提供了一种非常直观的方式，用以很好地匹配图灵和冯·诺依曼的硬件计算模型。 问题尽管结构化设计明显优于它之前的特定方法，但它存在着一个致命的弱点：当用户需求随着时间的推移改变时，软件往往很难随之修改，大型的应用尤其如此。与此同时，应用的规模和复杂性迅速膨胀。另外，新的语言、技术、操作系统、数据存储范式、用户界面范式、硬件等以惊人的速度出现在计算领域中。然而，商业条件一直在要求软件产品更快、成本更低地投入市场。 希望因此，一些新的设计方法出现了，这些方法从实践中吸取了来之不易的经验和教训。同时，计算领域提出了一些革命性的新观点。其中之一就是面向对象的范式，其主要目标为：在软件产品的生命周期中，随着需求出现不可避免的变更，保证大型应用的可维护性。 本书介绍一种特定软件设计方法的实践，该方法称为基于模型的开发方法，其主要基础是Shlaer-Mellor方法。通常情况下应用OO范式，特定情况下应用MBD方法能够使大型应用获得更强的健壮性和可维护性。 本书主要内容尽管本书使用UML（Unified Modeling Language，统一建模语言）作为表示法，但其应用是很浅显的。有很多非常优秀的书籍描述了如何使用UML进行软件设计，因此本书没有过多地描述UML的语法。同样，本书遵循了MBD的设计方法，但是该设计方法主要为下列真正目的提供背景支持： 本书的主要目标在于描述，为什么在一般情况下使用OO方法和在特殊情况下使用MBD方法是在宣传一种做事情的特殊方法。 不存在一种唯一正确的方法可以设计和开发所有软件。设计更多地依赖于特定的开发环境，包括从业务目标到工具再到团队文化等所有内容。最终，企业将决定在它的环境中哪一组工具是最高效的。为了做到这一点，决策者应当了解为什么MBD的方法工具集得以应用在许多常见的环境中。更重要的是，相关人员需要充分理解基本原理，从而能够根据特定的环境加以调整进而应用。 实现面向对象的设计需要一种独特的思维，该思维在硬件计算模型中很不直观。本书真正关心的是设计软件时如何思考，特定的表示法和方法学不是本书的侧重点。因此，本书以大量的篇幅探索好的软件设计的思考过程，甚至故意提供了一些不好的初步设计，用以证明该方法的自我纠正能力。 为了获得这样的理解，有必要描述软件开发的传统方法（面向对象方法之前）在某些方面如何失败，以及面向对象范式如何改正这些缺点。尽管结构化方法为1970年之前软件开发的混乱带来了切实的秩序，但它不是万能的。到20世纪80年代，软件明确显示，严重的可维护性问题仍然存在，这些问题正是面向对象范式要解决的。 同样，如果不讨论一种方法学的某些基础理论，那么就没有办法描述该方法学是否能够很好地工作。然而，这是一本软件开发人员写给软件开发人员的书，因此本书有意识地使用了不具有数学严谨性的实践术语来描述理论问题。 因为本书的主要内容是抽象OOA（Object Oriented Analysis，面向对象分析）模型的建立，因此书中没有很多OOPL（Object Oriented Programming Language，面向对象编程语言）代码。从方法学的名称顾名思义，其重点在于抽象建模而不是编写传统的源语言代码。实际上，当一个具有“转化质量”的OOA模型开发完成后，模型就是代码。换句话说，OOA建模使用的表示法是一种扩展的UML符号，其中增加了符合MDA的抽象动作语言（Abstract Action Language，AAL）的内容。表示法是4GL（Fourth Generation Language，第四代语言）而不是3GL（Third Generation Language，第三代语言），但是模型像任何一个3GL程序一样可执行。模型是独立实现的，它是一个针对功能需求解决方案的完整、准确而清晰的规格说明。 我们需要指出的最后一点是，作者的实践开发经验是以几十年而不是几年来衡量的。尽管本书的重点在于解释为什么这样做事情，但它绝对不是一本理论书。本书的基础是在现实世界中行之有效的方法。 路线图本书的主题限定于OOA层的应用开发，主要分为三部分。第一部分回顾了历史并介绍了基本的面向对象的原则。引言部分包括对结构化开发问题的讨论，这些问题正是OO范式想要解决的。第二部分关乎为问题的解决方案构造一个静态的结构。这一部分描述了OO范式与其他方法的最大不同，主要表现了OO范式在问题域抽象方面的独特视角。第三部分描述了解决方案的动态方面，尤其是积极地使用有限状态机进行行为描述。 读者对象本书的主要受众人群为具有较少OO经验的人。本书假定读者具有一些粗略的UML知识。本书还假定读者具有一些软件开发经验，接触过类似C语言的课程项目等。这里假设的经验层次包括：基本具备有关计算机和编程的一些知识，基本熟悉一些常见的缩略语，例如KISS等。 第二类读者是从传统的程序开发环境向OO范式转变的大量人群。他们中的许多开发者直接跃进到使用面向对象的编程语言写程序，因为他们已经具有了丰富的编程经验（即，相信如果一个人已经了解了一种编程语言，就能了解全部的编程语言）。可悲的是，这样的开发者往往会开发出大量不好的OO代码，因为没有人告诉他们为什么面向对象的分析和设计与结构化的分析和设计之间存在着巨大的差异。如果你是其中之一，那么你需要忘掉之前所学过的所有关于设计软件的内容，从零开始。 转化的作用MBD的一个主要特点是，它是基于转化（translation）的一系列方法之一。也就是说，MBD是一种这样的方法，在该方法中，一个解决方案使用某种表示法（例如UML）抽象为模型，然后使用一个完整的代码发生器将模型自动转化为一种实现。转化具有一些明显的优势，因为它代表了计算领域的一种自动化的逻辑扩展，能够提高生产力、实现规模经济并增加可靠性。缺点在于这并不容易做到。模型编译器面临的优化问题比3GL编译器面临的优化问题更加复杂。无论如何，当前已经存在一些商业代码生成器能够为基于转化的方法提供100％的代码生成。 尽管大部分转化方法出现于对象管理组织（Object Management Group，OMG）成立之前，由OMG所规范的模型驱动架构（Model-Driven Architecture，MDA）还是极大地推动了这些方法。MDA为即插即用工具提供急需的标准，为生成完整的代码提供概念框架。从一个抽象的、独立于实现的模型获得第三代语言代码或者程序集是一项重要的工作，特别是对当前复杂的IDE（Integrated Development Environment，集成开发环境）来说。这项工作大大受益于MDA的概念及其形式化。 然而，MBD并不依赖于转化。MBD中产生的模型与传统开发中OOA产生的模型本质是相同的，可以通过手工的方式生产OOD模型和3GL代码。MBD模型的构建只是比典型的OOA模型更加严格，因为代码生成器是没有想象力的，它们处理命令中的内容，而不是暗示的内容。开发者必须手工实现转化。 致谢非常感谢Steve Mellor和Sally Shlaer的工作，他们的方法是MBD的基础。他们是软件开发转化方法的开创者，并为OOA模型提供了急需的设计严谨性。除此之外，Steve Mellor是我见过的最好的OO建模者，他提供的例子让人受益匪浅。 同样感谢Rebecca Wirfs-Brock对手稿一丝不苟和悉心的审校。 Pathfinder Solutions为本书的方法提供了优秀的试验场，Greg Eakman、Carolyn Duby和Peter Fontana提供了特别的支持。 还要感谢Addison-Wesley出版社的Chris Guzikowski和Raina Chrobak的耐心与信心。谢谢Elizabeth Ryan、Diane Freed和Chris Zahn的编辑工作。 尽管这本书于我退休之后开始撰写，我还是要感谢Teradyne/ATB公司，他们提供了世界一流的软件开发工厂，其中充满了明星开发人员，他们为本书中的许多想法提供了原型。 最后，我要感谢30多年以来因特网上的大量用户为本书中概念的解释提供的共鸣版。读者读到的清晰描述大部分精炼自公共论坛上的描述。 引 言历史是一场噩梦，我试图从中清醒。 ——乔伊斯40年前，百万行的程序被认为是巨型程序，仅供美国国防部（Department of Defense，DoD）内部巨大的主机系统使用。按常规估计，开发这样的程序需要1000名工程师工作10年。今天，大多数PC上的应用都超过百万行，并且有许多在千万行范围之内。而且，人们期望它们能在几年甚至更短的时间之内开发完成。因此，在程序规模不断增长的同时，客户期望开发费用能越来越少。 在高科技日新月异的当今社会，软件快速老化已经成为常态。在公司的经济发展模式中，增长的要求比以往任何时代都更受重视。诸多因素促使公司在短时间内创造出更多、更好、更与众不同的产品。由于这些新产品的研发制造都需要依赖日渐庞大的各式软件，因此软件开发人员完成工作、缩短上市时间的压力不断增大。 软件开发人员同时奋战在软件开发的另外一条战线上。40年以前，对于发布的代码，全美的平均缺陷率为150个/KLOC。但是该数据没有人关注，因为大好形势之时，没有人去研究如何写“好的”软件。GOTO语句和全局数据占主流地位，设计在黑板上或者鸡尾酒餐巾上完成，DEL键永远是程序员们的最爱。软件开发如同一些电气专业一样晦涩难懂，因此，坦率地说，那时没有人在意这些。 但是，这样一个乌托邦式的情况不可能永久持续。在20世纪70、80年代发生了两次变革。第一，一场由日本方面开始的质量革新出现，亚洲其他国家纷纷效仿，随后缓慢波及到西方工业国家。此次变革使得用户进入了一个新时代，他们不用再把每周六分之一的时间花在修理车子或者电视上，这才是用户真正喜欢的。第二，在此次质量革新之后，软件的影响逐渐渗透到生活的方方面面，突然间软件就成为经常出错的典型。现在用户逐渐意识到了还有更好的质量革新方式，于是对于这些经常出错的软件，他们不再喜欢了。 因此，要求软件开发人员在更短的时间之内开发规模更大的程序，同时还要求将缺陷率控制在5西格玛的范围之内。更大的挑战是，20世纪80年代市场流行的口号是“质量是免费的”。虽然每一位软件开发人员都知道这是一派胡言，因为软件质量与开发时间是此消彼长的一种平衡。但是，市场压力的影响远远大于软件开发人员的影响，没有人听到软件开发人员的呐喊。因此20世纪80年代对于“软件危机”一词更新更深层的含义是以软件开发人员的健康为代价的。 第二个重大事件是关于计算的技术大爆炸。以前技术进步的主要特征是新的语言或者操作系统的出现。但是PC软件数量的不断增长，程序互操作性的需求和万维网的出现，促使计算技术创新不断。从以架构策略为基础的计划工作到测试过程，现在的软件开发人员在方方面面都有多种选择。更夸张的是，当开发人员还在熟悉旧技术的时候，新的技术已经出现了，速度之快令人咂舌。 最终，软件开发人员面临着不断产生的需求变更。计算域不是唯一面对创新和变革的领域。美国联邦会计标准局（Federal Accounting Standards Bureau，FASB）的核心管理信息系统IRS以及各式各样的其他美国政府机关不定期在颁布变更指令。产品的激烈竞争迫使市场支持者不断推陈出新，以保持与竞争对手步伐一致。同样，在学术界，标准、技能和工程学科的技术方面也日新月异，逐渐摆脱混乱形成统一。“需求万年不变”和项目瀑布模型的日子一去不复返了。 总之，现代的软件开发人员都面临着一个古老的问题，即：如何把5磅的东西尽快放到一个容量仅3磅的袋子里，并保证没有任何遗漏。今天，和半个世纪前相比，我们有着更好的工具、方法、过程和技术，但问题也是成比例增长的。基本汇编语言（Basic Assembly Language，BAL）要解决的软件危机问题仍然如影随形，这也是本书的第一条忠告。 软件开发是一个不可能完成的任务，开发人员唯一要做的就是不断应对并保持微笑。 1.?研究现状1995年的某次会议上，主讲人要求当时的与会人员中使用微软Windows操作系统的人员举手示意，数百人举起了手。然后，他要求过去一周内系统崩溃过的人再次举手，大半以上的人仍然举手。接下来，他让那些认为微软在将来会被市场淘汰的人继续举手，结果所剩寥寥无几。该主讲人用此次实例来说明和验证自己的说法，那就是，软件质量不是一个事关公司生存的必要条件。 这一结论在今天很难保证是对的，尤其是在微软与Linux的市场大战中可见一斑。决定一个软件公司在市场中生存的关键因素，其实是他们是否能够提供用户想要的东西。从广义上讲，这一点可大致从产品的可靠性、功能性、易用性和可用性（即市场时效性）四个方面评估，当然开发人员花费在这四个方面的成本是不同的，如图I-1所示。用户总是希望各方面都得到满足，但是毕竟预算有限，因此供应商决定综合的总成本，然后由市场来检验用户的满意度。 图I-1 权衡冲突的开发优先级如何满足这四个方面基本上是一项市场决策。在一个既定市场给定价格下，市场支持者总是期望通过一个最佳营销战略来赚取他们的第一桶金。而成本最小化的关键在于软件开发人员。这种开发成本的降低会直接影响产品市场竞争优势的确立。这种优势的价值将取决于特定的市场地位。因此，衡量软件开发现状的问题是：运用什么样的工具才能有效降低成本且满足这四个方面的要求。 我们有各种各样的软件工具来帮助我们，如版本控制系统。我们也有大量的过程，从XP到正式方法。我们还有很多种软件设计方式方法。我们有像RUP和CMM这样的过程框架，还有汇编语言、集成开发环境（IDE）、度量系统、估计模型和其他各种各样的工具。 我们有各种珍贵的数据，可以整理出可用的方法、技术和实践经验，形成最佳的组合。 一帮黑客宅在他们的卧室里，经过数月消耗掉无数可乐和披萨后黑掉某一应用的日子一去不复返了。如果工作面试时，你告诉招聘经理去年你总共写了100KLOC，那你可以跟这份工作“拜拜”了。因为招聘经理都明白效率如此低下的原因是编写的代码最后都不可靠，并且是一堆无法维护的烂摊子。有效降低满足这四个方面的成本，需要的是有组织、有系统地进行软件开发。 目前业界有太多口惠而不实的软件工程。作为一门工程学科我们可能还需要走很长的路。软件开发是一门艺术，尽管非常晦涩难懂。其精髓在于这是一个在给定环境下运用各种不同方法和工具的大杂烩，即一个协调统一的开发系统。除了提供这种集成系统的规则外，我们的“软件工程”只不过是“这里有一个框架和一些可选择的组合。寻找正确的候选者并在特定开发环境中把它们恰当地组合在一起，则是留给学生的练习。” 2.?什么在起作用然而现实情况是，软件开发的艺术在过去的半个世纪里有了长足的发展。同样数目的开发人员能够在更短的时间内更高质量地完成更大规模的项目，因此我们更应该去做一些更有帮助的事情。其中棘手的问题是，如何弄清哪些事情是正确的。 早在1970年之前，人们就有基于几十年实践经验总结的宝贵教训。例如，曾几何时FORTRAN的GOTO语句和COBOL的ALTER语句被视为处理复杂编程问题的强大工具，然而10年后，编程经理不再使用这些语句，因为使用这些功能的程序在需求变更时很难维护。 所有这些来之不易的教训形成了开发者经验的概念。当一个程序员犯过足够多的错误并在错误中吸取了各种教训后，他就会逐渐成长为软件开发的行家。遗憾的是，软件开发人员总是会重新经历这些错误，因为没有一个关于这些软件开发经验教训的系统总结或者统一标准。 20世纪60年代末，第三代编程语言中出现了各种各样的编程方法，软件设计方法开始兴起。早期，大家只是把一些经常犯的错误和实践经验公布于众。不过，很快软件专家们开始将这些实践经验总结成系统的设计方法学。这些方法学在细节上各有不同但是很多特征是有共同点的，所以它们都属于结构化开发（Structured Development，SD）。因为它们是相当抽象的视图——有关软件设计的一张大图，而且读者会发现它能够很方便地使用专门的表示法。很多倡导者也很学术化，表示法往往倾向于图形化，这使集合论和图论中的理论约束也得以应用。 结构化开发是20世纪中期最简单也是最重要的软件开发成果。毫不夸张地说，它让软件开发摆脱了杂乱无章的状态。除此之外，它是数据处理的增长动力，数据处理在20世纪80年代演变为重要的信息技术。在企业界，很多入门级的COBOL程序员艰难地做出了大量的报表，从而为日常的企业运行提供了前所未有的可视性。更好的是，这些报告通常相当准确。 当然，结构化开发在软件开发的漫漫长路上仅是第一步。正如所预期的，它是新的，但不是万能的，从20世纪70年代起它的一些缺陷就开始显现了。只有理解这些缺陷是什么，才能理解20世纪80年代面向对象开发的发展原因和发展方式。用户评价
作为一个在软件行业摸爬滚打多年的老兵，我见过太多的项目因为沟通不畅、需求模糊而最终走向失败。团队成员之间对需求的理解存在偏差，是导致这些问题的重要原因之一。这本书的书名“基于模型的软件开发”，让我眼前一亮。我猜测，它可能提供了一种解决上述问题的有效途径。通过构建清晰、标准的模型，可以作为团队成员之间沟通的“共同语言”，确保大家对软件的各个方面都有统一的认识。我特别期待书中能够深入探讨模型在需求获取和沟通环节中的作用。它是否能帮助我们更早地发现需求的遗漏和冲突？是否能让非技术人员也能够理解和参与到软件的设计过程中？我还对模型在代码生成和自动化测试方面的应用很感兴趣。如果模型能够直接驱动代码的生成，那么开发效率是否会得到极大的提升？如果模型本身就可以作为测试用例的来源，那么软件的质量是否会更有保障？这本书的名字给我一种“规范、严谨、高效”的感觉，我希望它能够真正地为软件开发的实践带来一些革命性的改变。
评分这本书的封面设计就足够吸引眼球了，深邃的蓝色背景，简洁而现代的字体，仿佛预示着这本书将带领读者进入一个严谨而充满智慧的领域。我一直对软件开发的理论性部分很感兴趣，虽然我是一名从业多年的程序员，每天都在与代码打交道，但总觉得在宏观层面，对软件构建的本质缺乏更深刻的理解。这本书的书名“基于模型的软件开发”，正是我一直以来寻找的方向。我期待它能提供一种系统性的方法论，让我能够跳出日常编码的细节，从更高层次去审视软件的设计、构建和演进。我希望这本书不仅仅是堆砌理论，而是能够提供清晰的逻辑框架，让我理解模型在软件开发生命周期中的作用，它如何指导我们进行需求分析、架构设计，甚至是后期的维护和演化。尤其是模型驱动开发（MDD）和模型驱动架构（MDA）等概念，我一直觉得它们是软件工程领域非常有潜力的方向，但相关的实践和落地案例往往比较零散。我希望这本书能在这方面提供一些详实的指导，让我能够理解如何将模型有效地转化为可执行的代码，以及在实际项目中如何评估和选择合适的模型驱动方法。同时，我也对书中的案例分析部分充满期待，理论的学习离不开实践的支撑，希望通过真实的案例，我能够更好地理解书中提出的概念和方法。
评分最近在技术社区里，听了不少关于“软件架构演进”的讨论，也看到很多文章在谈论“领域驱动设计”（DDD）和“微服务”的结合。虽然这些话题听起来很吸引人，但总感觉缺少一个贯穿始终的、更底层的原理来指导。这本书的出现，似乎正是填补了这一空白。“基于模型的软件开发”这个名字，让我联想到一种更加规范、更加可预测的开发方式。我猜想，这本书可能会探讨如何将业务需求、系统设计等抽象概念，用一种标准化的“模型”来表示，然后通过对这些模型的操作，自动生成代码，或者至少是辅助代码的生成。这听起来有点像“所见即所得”的开发模式，但又更加侧重于软件的内在逻辑和结构。我特别好奇，书中会如何处理模型与代码之间的映射关系，以及如何保证这种映射的正确性和效率。另外，在快速迭代的敏捷开发环境中，如何有效地运用基于模型的开发方法，避免模型本身的更新滞后于业务需求的变化，也是我非常关心的问题。我希望这本书能提供一些切实可行的策略，让我能够将模型的力量融入到敏捷的开发流程中，实现更高效、更健壮的软件构建。
评分最近几年，随着人工智能和大数据技术的飞速发展，软件开发的复杂度也在不断攀升。传统的开发模式，在面对如此庞杂的需求和技术挑战时，显得有些捉襟见肘。我一直在寻找一种能够提升开发效率、保证软件质量的“新范式”。“基于模型的软件开发”这个书名，恰好触动了我内心的期待。我猜测，这本书不仅仅是关于某个具体的模型工具或技术，而是关于一种全新的软件开发哲学。它可能强调的是“以模型为中心”的设计和开发流程，将模型视为软件的“灵魂”，而代码只是“躯壳”。我希望书中能够深入探讨模型在软件生命周期各个阶段的贯穿性作用，从最初的概念验证，到详细的设计，再到最后的部署和维护。我尤其对书中关于“模型复用”和“模型驱动的系统演化”的章节充满好奇。如何在不同的项目之间共享模型？当业务需求发生变化时，如何通过修改模型来驱动整个系统的升级和演化，而不是进行大规模的重写？这些都是我非常关心的问题。这本书的出现，让我看到了软件开发走向更加智能化、自动化和可预测化的可能。
评分说实话，我一直觉得软件开发领域，尤其是在一些大型、复杂的项目中，存在着很大的“经验主义”成分。很多时候，我们依靠的是开发者的直觉和过往的经验来做决策，这虽然在小项目里问题不大，但一旦项目规模上来，就会出现各种难以预料的难题，比如需求变更难以控制，系统集成困难重重，技术债务不断积累等等。这本书的书名“基于模型的软件开发”，给了我一种全新的视角。它似乎在提倡一种更加“工程化”的开发方式，用明确的模型来约束和指导开发过程，减少不确定性。我猜想，这本书会强调“模型”作为软件开发核心的地位，它不仅仅是图纸，而是整个开发流程的驱动力。我希望书中能够详细阐述如何构建不同层次的模型，从高层次的业务模型到低层次的实现模型，以及这些模型之间是如何相互关联、相互转化的。我还对书中关于“模型验证”和“模型转换”的内容非常感兴趣。如何确保模型能够准确地反映业务需求，如何将模型有效地转换为可执行的代码，以及在模型发生变化时如何自动更新代码，这些都是我亟待解决的问题。
评分我基本不评价，实在生气！拿到公司去报销，公司说是盗版的，扫码都扫不上，看来传说中的某东卖假货是真的啊！
评分好
评分好书，顶一个
评分好，东东不错，快递给力，好评！
评分我基本不评价，实在生气！拿到公司去报销，公司说是盗版的，扫码都扫不上，看来传说中的某东卖假货是真的啊！
评分我基本不评价，实在生气！拿到公司去报销，公司说是盗版的，扫码都扫不上，看来传说中的某东卖假货是真的啊！
评分看不懂。。
评分简直无语了 买了一本书打开一看 装订错版 目录和内容全部倒过来了 想找客服也找不到 都不检查就发售 出版商和京东也太不负责了
评分好书，顶一个
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.idnshop.cc All Rights Reserved. 静思书屋 版权所有