引言
本白皮书将讨论建模在软件开发过程中的价值。建模的概念并非新鲜出炉——资深软件专业人士已经有过多年的建模实践。但是在主流软件开发社区中，只有一部分软件开发人员对他们的软件开发进行了建模。本白皮书将考查什么是促进软件建模实践的基础。本白皮书旨在为精通软件建模的人员、一无所知的人员，以及听说过但从未实践过的人员，阐述建模实践所能带来的利益和价值。
什么是建模？
多年以来，业务分析人员、工程师、科学家，以及其他构建复杂结构或系统的专业人员已经为他们所构建的系统创建了模型。有时是物理模型，例如，飞机、房子或者汽车的按一定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型、市场贸易模拟以及电子电路图。在所有情况下，模型作为一种抽象——即被构建的真实事物的近似代表。
为什么建模？
为什么在构建某些事物之前首先要建模？或许不需要。简单的事物不需要在创建之前进行建模——例如，一个简单的支票簿签发记录、简单的货币换算工具、一间犬舍或者用于打开一组常规文件的字处理程序中的宏。
这样的项目具有下列全部或大部分特点：
问题域很清楚。
相对来说易于构建解决方案。
需要很少的人进行协作来构建或使用该解决方案（通常只有一个人）。
该解决方案需要最少量的持续维护。
未来需要的范围不会有实质性的扩大。
但是假如假设这些特点都不具备呢？为什么一些专业人员要费心去创建模型呢？为什么他们不直接构建具体事物呢？答案在于复杂性和风险，并且最初的专业人员并不是一直适合开发任务，甚至根本不能完成任务。
建模使架构师及其他人员能够可视化整个系统，评估不同选择，并且更清楚地交流设计，从而避免了技术风险、财务风险或实际的构建风险。假如不先创建一项设计、一个蓝图或者另一个抽象表示，就直接构建某种复杂系统，在技术上是不明智的、在经济上也是行不通的。尽管专业建筑师无需设计图就可以建造一间犬舍，但是假如他们不首先开发一批计划、图和某种可视化实物模型，那么就不能建造一幢15层的办公大楼。
为什么对软件进行建模？
多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了一种DIY（do-it-yourself）文化——每当需要时才进行构思、构建及变更。总之没有“最终”系统，那么为什么在编写代码之前还要进行构思呢？
今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程——诸如客户看见并经历过的那些业务流程，和后台办公的业务流程。
一些软件支持健康有关或财产有关的重要功能，这就使得开发、测试以及维护必定很复杂。甚至那些对健康或者财产不是非凡要害的系统对于业务来说却非常要害。在许多组织中，软件开发已经不再是居于成本中心的孤立事物——而成为公司战略性业务流程的一个整体部分。对这些公司来说，软件已经成为市场竞争中一个要害的鉴别标志。
在许多组织中，软件开发已经不再是居于成本中心的孤立事物－―而成为公司战略性业务流程的一个整体部分。
由于很多方面的原因，开发者需要更好的理解他们正在构建什么，建模为此提供了有效的方法。同时，建模一定不要影响开发速度。客户和业务用户始终希望软件能够按时交付以及能够像所期望的那样具有随需应变的功效。为了达到这种“速度与质量并重”的目标，IBM 提出了软件开发的四项必要措施：迭代开发、重视构架、持续的质量保证以及治理变更和资产。
其他复杂的高风险系统建模的相同理由同样适用于软件——治理复杂性并理解设计和相关的风险。尤其是通过软件建模，开发人员能够：
在提交额外的资源之前创建并交流软件设计。
从设计追溯到需求阶段，有助于确保构建正确的系统。
进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。
为什么一些开发人员不选择软件建模？
尽管建模有许多原因和优点，但是仍然有很大一部分软件开发人员不在源代码更高的层次上进行任何形式的抽象。这是为什么呢？正如前面描述的那样，有时候问题或者解决方案的实际复杂度无需建模。再一次重申，假如您预备建造一间犬舍，您根本就不需要雇佣一个建筑师或者聘请一位建造者来做一系列的设计规格说明。但是在软件世界中，系统经常是开始时简单并且易于理解，在通过一系列成功实施的自然演进，就变得越来越复杂。在其他情况中，开发人员不采用建模的简单理由是没有熟悉到建模的需要，直到很迟的时候才察觉到建模的必要。
许多人争论，软件建模的阻力更多的是来自文化上的因素而不是其他的。传统的程序员对于通常的编写代码的技术非常擅长。甚至遭碰到不希望的复杂情况的时候，大多数开发人员仍然坚持使用他们的集成开发环境（IDE）和调试工具，以及在问题上花费更多的时间。因为建模需要额外的培训和工具，并且相应地需要额外的时间、财力和工作量上的投资―－不是正式开发工作的时间，而是在项目开发生命周期早期的时间。传统开发人员在这方面不超前的原因在于，他们认为建模将减慢他们的速度。在下一节中将帮助人们消除这种观念。
何时建模？
为复杂的应用程序建模有几项一般获益。在某些特定情况下，建模工作是值得的，这包括：
为了更好理解手头上的业务情况或工程情况（“as-is”模型）并且为了设计更好的系统（“to-be”模型）
为了构建和设计系统的构架
为了创建可视化代码和其他实施形式
建模不主张全有或全无（all-or-nothing）。模型可以在软件开发过程的很多方面发挥作用。图1描述了实践模型驱动开发的方法的使用范围。
集成的开发环境
在建模的最自由的概念中，集成开发环境（IDE）可以看作是模型驱动开发实践的入口点。现在的集成开发环境在创建和维护代码方面提供了许多提高抽象层次方面的机制。有许多工具，例如，诸如语言敏感的编辑器、导航器、表单生成器和其他GUI控制，在更严格的术语上讲都不算是模型。但是，它们能够提高源代码之上的抽象层次，提高开发人员的生产率，帮助创建更可靠的代码，以及提供更高效的维护过程。所有的这些属性都是模型驱动开发的本质。
图1 时间、地点及建模方法的范围图
QQRead.com 推出数据恢复指南教程 数据恢复指南教程
数据恢复故障解析
常用数据恢复方案
硬盘数据恢复教程
数据保护方法
数据恢复软件
专业数据恢复服务指南
引言
本白皮书将讨论建模在软件开发过程中的价值。建模的概念并非新鲜出炉——资深软件专业人士已经有过多年的建模实践。但是在主流软件开发社区中，只有一部分软件开发人员对他们的软件开发进行了建模。本白皮书将考查什么是促进软件建模实践的基础。本白皮书旨在为精通软件建模的人员、一无所知的人员，以及听说过但从未实践过的人员，阐述建模实践所能带来的利益和价值。
什么是建模？
多年以来，业务分析人员、工程师、科学家，以及其他构建复杂结构或系统的专业人员已经为他们所构建的系统创建了模型。有时是物理模型，例如，飞机、房子或者汽车的按一定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型、市场贸易模拟以及电子电路图。在所有情况下，模型作为一种抽象——即被构建的真实事物的近似代表。
为什么建模？
为什么在构建某些事物之前首先要建模？或许不需要。简单的事物不需要在创建之前进行建模——例如，一个简单的支票簿签发记录、简单的货币换算工具、一间犬舍或者用于打开一组常规文件的字处理程序中的宏。
这样的项目具有下列全部或大部分特点：
问题域很清楚。
相对来说易于构建解决方案。
需要很少的人进行协作来构建或使用该解决方案（通常只有一个人）。
该解决方案需要最少量的持续维护。
未来需要的范围不会有实质性的扩大。
但是假如假设这些特点都不具备呢？为什么一些专业人员要费心去创建模型呢？为什么他们不直接构建具体事物呢？答案在于复杂性和风险，并且最初的专业人员并不是一直适合开发任务，甚至根本不能完成任务。
建模使架构师及其他人员能够可视化整个系统，评估不同选择，并且更清楚地交流设计，从而避免了技术风险、财务风险或实际的构建风险。假如不先创建一项设计、一个蓝图或者另一个抽象表示，就直接构建某种复杂系统，在技术上是不明智的、在经济上也是行不通的。尽管专业建筑师无需设计图就可以建造一间犬舍，但是假如他们不首先开发一批计划、图和某种可视化实物模型，那么就不能建造一幢15层的办公大楼。
为什么对软件进行建模？
多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了一种DIY（do-it-yourself）文化——每当需要时才进行构思、构建及变更。总之没有“最终”系统，那么为什么在编写代码之前还要进行构思呢？
今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程——诸如客户看见并经历过的那些业务流程，和后台办公的业务流程。
一些软件支持健康有关或财产有关的重要功能，这就使得开发、测试以及维护必定很复杂。甚至那些对健康或者财产不是非凡要害的系统对于业务来说却非常要害。在许多组织中，软件开发已经不再是居于成本中心的孤立事物——而成为公司战略性业务流程的一个整体部分。对这些公司来说，软件已经成为市场竞争中一个要害的鉴别标志。
在许多组织中，软件开发已经不再是居于成本中心的孤立事物－―而成为公司战略性业务流程的一个整体部分。
由于很多方面的原因，开发者需要更好的理解他们正在构建什么，建模为此提供了有效的方法。同时，建模一定不要影响开发速度。客户和业务用户始终希望软件能够按时交付以及能够像所期望的那样具有随需应变的功效。为了达到这种“速度与质量并重”的目标，IBM 提出了软件开发的四项必要措施：迭代开发、重视构架、持续的质量保证以及治理变更和资产。
其他复杂的高风险系统建模的相同理由同样适用于软件——治理复杂性并理解设计和相关的风险。尤其是通过软件建模，开发人员能够：
在提交额外的资源之前创建并交流软件设计。
从设计追溯到需求阶段，有助于确保构建正确的系统。
进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。
为什么一些开发人员不选择软件建模？
尽管建模有许多原因和优点，但是仍然有很大一部分软件开发人员不在源代码更高的层次上进行任何形式的抽象。这是为什么呢？正如前面描述的那样，有时候问题或者解决方案的实际复杂度无需建模。再一次重申，假如您预备建造一间犬舍，您根本就不需要雇佣一个建筑师或者聘请一位建造者来做一系列的设计规格说明。但是在软件世界中，系统经常是开始时简单并且易于理解，在通过一系列成功实施的自然演进，就变得越来越复杂。在其他情况中，开发人员不采用建模的简单理由是没有熟悉到建模的需要，直到很迟的时候才察觉到建模的必要。
许多人争论，软件建模的阻力更多的是来自文化上的因素而不是其他的。传统的程序员对于通常的编写代码的技术非常擅长。甚至遭碰到不希望的复杂情况的时候，大多数开发人员仍然坚持使用他们的集成开发环境（IDE）和调试工具，以及在问题上花费更多的时间。因为建模需要额外的培训和工具，并且相应地需要额外的时间、财力和工作量上的投资―－不是正式开发工作的时间，而是在项目开发生命周期早期的时间。传统开发人员在这方面不超前的原因在于，他们认为建模将减慢他们的速度。在下一节中将帮助人们消除这种观念。
何时建模？
为复杂的应用程序建模有几项一般获益。在某些特定情况下，建模工作是值得的，这包括：
为了更好理解手头上的业务情况或工程情况（“as-is”模型）并且为了设计更好的系统（“to-be”模型）
为了构建和设计系统的构架
为了创建可视化代码和其他实施形式
建模不主张全有或全无（all-or-nothing）。模型可以在软件开发过程的很多方面发挥作用。图1描述了实践模型驱动开发的方法的使用范围。
集成的开发环境
在建模的最自由的概念中，集成开发环境（IDE）可以看作是模型驱动开发实践的入口点。现在的集成开发环境在创建和维护代码方面提供了许多提高抽象层次方面的机制。有许多工具，例如，诸如语言敏感的编辑器、导航器、表单生成器和其他GUI控制，在更严格的术语上讲都不算是模型。但是，它们能够提高源代码之上的抽象层次，提高开发人员的生产率，帮助创建更可靠的代码，以及提供更高效的维护过程。所有的这些属性都是模型驱动开发的本质。
图1 时间、地点及建模方法的范围图
