引言本白皮书将讨论建模在软件开发过程中的价值。建模的概念并非新鲜出炉——资深软件专业人士已经有过多年的建模实践。但是在主流软件开发社区中，只有一部分软件开发人员对他们的软件开发进行了建模。本白皮书将考查什么是促进软件建模实践的基础。本白皮书旨在为精通软件建模的人员、一无所知的人员，以及听说过但从未实践过的人员，阐述建模实践所能带来的利益和价值。
　
　　什么是建模？
　
　　多年以来，业务分析人员、工程师、科学家，以及其他构建复杂结构或系统的专业人员已经为他们所构建的系统创建了模型。有时是物理模型，例如，飞机、房子或者汽车的按一定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型、市场贸易模拟以及电子电路图。在所有情况下，模型作为一种抽象——即被构建的真实事物的近似代表。
　
　　为什么建模？
　
　　为什么在构建某些事物之前首先要建模？或许不需要。简单的事物不需要在创建之前进行建模——例如，一个简单的支票簿签发记录、简单的货币换算工具、一间犬舍或者用于打开一组常规文件的字处理程序中的宏。
　
　　这样的项目具有下列全部或大部分特点：问题域很清楚。
　
　　相对来说易于构建解决方案。
　
　　需要很少的人进行协作来构建或使用该解决方案（通常只有一个人）。
　
　　该解决方案需要最少量的持续维护。
　
　　未来需要的范围不会有实质性的扩大。
　
　　但是如果假设这些特点都不具备呢？为什么一些专业人员要费心去创建模型呢？为什么他们不直接构建具体事物呢？答案在于复杂性和风险，并且最初的专业人员并不是一直适合开发任务，甚至根本不能完成任务。
　
　　建模使架构师及其他人员能够可视化整个系统，评估不同选择，并且更清晰地交流设计，从而避免了技术风险、财务风险或实际的构建风险。如果不先创建一项设计、一个蓝图或者另一个抽象表示，就直接构建某种复杂系统，在技术上是不明智的、在经济上也是行不通的。尽管专业建筑师无需设计图就可以建造一间犬舍，但是如果他们不首先开发一批计划、图和某种可视化实物模型，那么就不能建造一幢15层的办公大楼。
　
　　为什么对软件进行建模？
　
　　多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了一种DIY（do-it-yourself）文化——每当需要时才进行构思、构建及变更。总之没有“最终”系统，那么为什么在编写代码之前还要进行构思呢？
　
　　今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程——诸如客户看见并经历过的那些业务流程，和后台办公的业务流程。
　
　　一些软件支持健康有关或财产有关的重要功能，这就使得开发、测试以及维护必定很复杂。甚至那些对健康或者财产不是特别关键的系统对于业务来说却非常关键。在许多组织中，软件开发已经不再是居于成本中心的孤立事物——而成为公司战略性业务流程的一个整体部分。对这些公司来说，软件已经成为市场竞争中一个关键的鉴别标志。
　
　　在许多组织中，软件开发已经不再是居于成本中心的孤立事物－―而成为公司战略性业务流程的一个整体部分。
　
　　由于很多方面的原因，开发者需要更好的理解他们正在构建什么，建模为此提供了有效的方法。同时，建模一定不要影响开发速度。客户和业务用户始终希望软件能够按时交付以及能够像所期望的那样具有随需应变的功效。为了达到这种“速度与质量并重”的目标，IBM 提出了软件开发的四项必要措施：迭代开发、重视构架、持续的质量保证以及管理变更和资产。
　
　　其他复杂的高风险系统建模的相同理由同样适用于软件——管理复杂性并理解设计和相关的风险。尤其是通过软件建模，开发人员能够：在提交额外的资源之前创建并交流软件设计。
　

[1] [2] [3] [4] 下一页

【责编:Lili】