建模是管理
软件开发复杂性的有效手段。它能促进需求、构架、软件及系统的交流、设计与评估。尽管有这么多的优点，但是主流的软件开发并未能在日常工作中充分利用建模这项技术。
1.什么是建模？
多年以来，业务分析人员、工程师、科学家，以及其他构建复杂结构或系统的专业人员已经为他们所构建的系统创建了模型。有时是物理模型，例如，飞机、房子或者汽车的按一定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型、市场贸易模拟以及电子电路图。在所有情况下，模型作为一种抽象——即被构建的真实事物的近似代表。
2.为什么建模？
为什么在构建某些事物之前首先要建模？或许不需要。简单的事物不需要在创建之前进行建模——例如，一个简单的支票簿签发记录、简单的货币换算工具、一间犬舍或者用于打开一组常规文件的字处理程序中的宏。
3。为什么对软件进行建模？
多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了一种DIY（do-it-yourself）文化——每当需要时才进行构思、构建及变更。总之没有“最终”系统，那么为什么在编写代码之前还要进行构思呢？
今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从 引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程——诸如客户看见并经历过的那些业务流程，和后台办公的业务 流程。
4.软件建模带来的好处
尤其是通过软件建模，开发人员能够：
在提交额外的资源之前创建并交流软件设计。
从设计追溯到需求阶段，有助于确保构建正确的系统。
进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。
5.何时建模？
为复杂的应用程序建模有几项一般获益。在某些特定情况下，建模工作是值得的，这包括：
为了更好理解手头上的业务情况或工程情况（“as-is”模型）并且为了设计更好的系统（“to-be”模型）
为了构建和设计系统的构架
为了创建可视化代码和其他实施形式
建模不主张全有或全无（all-or-nothing）。模型可以在软件开发过程的很多方面发挥作用。图1描述了实践模型驱动开发的方法的使用范围。
6.建模和双向工程
建模范围的下一步代表了传统模型驱动开发的状态。此处，可视化的模型从方法过程中创建，该方法以需求开始并且延伸到高层构架的设计模型中。然后开发人员创建详细的设计模型，从该模型中骨架生成 IDE。ID E完成详细的编码。任何影响设计模型的对代码所做的变更都会同步的返回给模型；任何模型所作的变更也同步地进入已存在的代码中。
7. 采用标准的表示法（例如 UML），是将模型驱动方法引入软件开发中的一个重要步骤。
随着业务建模变得更加标准化并且同数据、软件的集成度越来越高，一种模型驱动的业务集成学科可能将要崭露头脚。
统一软件、数据和业务建模
本白皮书重点主要集中在建模软件的价值。但是在实践中数据建模和业务建模以某种形式使用的时间更长一些。问题是这些类型的建模传统上在建模语言和开发人员文化上属于完全不同的世界。现在统一这三个世界的可能变得明显了－－没有必要成为一种简单的建模语言或者工具，但是可以使用一种多样的、集中的开放行业标准的组合。
贯穿生命周期的建模
随者标准的不断演进，建模将应用到贯穿整个软件开发生命周期的活动的更广阔的范围。建模的应用程序已经在项目生命周期中更早地驱动测试和其他的质量保证方面。并且由于业务建模变得更加标准化并且同数据、软件的集成度越来越高，一种模型驱动的业务集成学科可能将要崭露头脚。
特定领域的建模语言
UML和其他的建模语言令开发人员能够将注意力集中到实施细节之上的抽象层次上。正如早在图1中描述的那样，建模包含的层次范围很广，甚至当我们离开实 际的代码也是一样。对于抽象的最高层次，业务模型或域模型并不集中于软件，而是正在考虑的问题的本质。在这里，模型应该使用特定的业务和应用领域中人们和 系统所熟悉的术语和图标。
软件行业正朝向领域特定、语言目的特定的建模语言方向发展，这样的建模语言专用于它们使用的各自领域。然 而更通常的情况是，一般目的建模语言，特别是UML，以标准的方法进行了扩展，通过诸如 profile 方面的革新来满足特定领域建模的需要。这两种方法和一般的建模价值一致：以更有效及高效的方式为特定问题和解决方案提供抽象。
软件开发业务
许多人将软件开发称为“团队运动”。伴随的一个陈述是“国际团队运动”。借助于当今的技术，软件开发已经摆脱了地理上的束缚。软件开发业务将变得越来越分布化和全球化。建模和其他更高形式的抽象对帮助开发人员处理相关的复杂性来说具有决定作用。
模型驱动的构架（Model-Driven Architecture ，MDA)
下一步的计划是由对象管理组 织（Object Management Group）领导的MDA。当还处在早期的试用阶段时，MDA 就被认为是建模和模型驱动开发技术演进的下一个逻辑步骤。MDA基于UML和其他相关的标准，主要关注的是在抽象的不同层次上定义模型，和在不同层次之间 的定义转换。自动工具支持对于MDA的发展及成功应用来说具有决定意义。
