软件及系统的交流设计与评估。尽管有这么多的优点，但是主流的软件开发并未能在日常工作中充分利用建模这项技术。本书探讨了建模时如何同时提供可视化内容和文本内容，以及这二者结合的重要性。它还解释了如何将建模贯穿于软件开发生命周期中的各个阶段，并且在每阶段使用哪些建模类型最为合适。尽管统建模语言的中心是将建模本身作为个学科，但是它还是用来表示模型的公共方法。引言本书将讨论建模在软件开发过程中的价值。建模的概念并非新鲜出炉，资深软件专业人士已经有过多年的建模实践。但是在主流软件开发社区中，只有部分软件开发人员对他们的软件开发进行了建模。本书将考查什么是促进软件建模实践的基础。本书旨在为精通软件建模的人员无所知的人员，以及听说过但从未实践过的人员阐述建模实践所能带来的利益和价值。什么是建模多年以来，业务分析人员工程师科学家，以及其他构建复杂结构或系统的专业人员已经为他们所研发的系统创建了模型。有时是物理模型，例如，飞机房子或者汽车的按定比例制作的实物大模型，有时候模型并不是那么明确，如商业金融模型市场贸易模拟以及电子电路图。在所有情况下，模型作为种抽象即被构建的真实事物的近似代表。为什么建模为什么在构建些事物之前首先要建模或许不需要。简单的事物不需要在创建之前进行建模例如，个简单的支票簿签发记录简单的货币换算工具间犬舍或者用于打开组常规文件的字处理程序中的宏。这样的项目具有下列全部或大部分特点问题域很清楚。相对来说易于构建解决方案。需要很少人进行协作来构建或使用该解决方案通常只有个人。该解决方案需要最少量的持续维护。未来需要的范围不会有实质性的扩大。但是如果假设这些特点都不具备呢为什么些专业人员要费心去创建模型呢为什么他们不直接构建具体事物呢答案在于复杂性和风险，并且最初的专业人员并不是直适合开发任务，甚至根本不能完成任务。如果不先创建项设计个蓝图或者另个抽象表示，就直接构建种复杂系统，在技术上是不明智的在经济上也是行不通的。尽管专业建筑师无需设计图就可以建造间犬舍，但是如果他们不首先开发批计划图和种可视化实物模型，那么就不能建造幢层的办公大楼。为什么对软件进行建模多年以来，软件开发实践置于建模话题之外。由于其本质属性，软件易于创建和变更。几乎不需要固定设备，并且实际上没有制造成本。这些属性孕育了种文化每当需要时才进行构思构建及变更。总之没有最终系统，那么为什么在编写代码之前还要进行构思呢今天，软件系统已经变得非常复杂。它们必须与其他系统进行集成，来运行日常生活中用到的对象。例如，汽车现在大规模装备了计算机及相关软件，用来控制从引擎和定速控制到所有新的车载导航和通讯系统的各个方面。软件还经常用于自动处理各种业务流程诸如客户看见并经历过的那些业务流程和后台办公的业务流程。些软件支持有关健康或财产的重要功能，这就使得开发测试以及维护必定很复杂。甚至那些对健康或者财产不是特别关键的系统对于业务来说却非常关键。在许多组织中，软件开发已经不再是居于成本中心的孤立事物而成为公司战略性业务流程的个整体部分。对这些公司来说，软件已经成为市场竞争中个关键的鉴别标志。由于很多方面的原因，开发者需要更好的理解他们正在构建什么，建模为此提供了有效的方法。同时，建模定不要影响开发速度。客户和业务用户始终希望软件能够按时交付以及能够像所期望的那样具有随需应变的功效。的主要领导者引领了最初的发展。今天，由对象管理组织，管理，该组织由来自全世界的代表组成，确保它的规格说明能够不断满足软件社区的动态需要。采用标准的表示法，例如，是将模型驱动方法引入软件开发中的个重要步骤。不仅仅是个图形化的表示法标准它是种建模语言。同所有语言样，定义了语法包括图形和文本和语义符号和文本的根本含意。将作为种真正的建模语言而不仅仅是标准的表示法，对于两个方面来说都很重要，方面是标准化的使用，另方面是确保自动化工具能够正确实施符号背后的规则。是种真正的建模语言已经成为软件行业最公认的及最广泛使用的建模标准。趋势和未来如果您问下软件开发专家，软件行业向何处发展您可能得到大量不同的回答。但是有个趋势是相当致的软件开发的复杂性继续增长，并且开发人员必须工作在个更高的层次上来处理这种复杂性。无论是现在还是将来，为软件建模都是开发人员在更高的层次上工作的主要方法。当前下面的这些特定趋势值得关注。超越可视化建模传统上是与描述软件工件的图形化方法联系在起的。尽管现在仍维持这特点，但是，建模方面变得越来越重要。元建模是对模型的模型的描述。元建模技术最明显最实际的应用可以参考版本，它形成了关于自动化工具如何共享数据以及相互之间互相操作的基础。这不仅可以应用在建模工具上，还可以应用在需求管理工具编译器测试配置管理以及软件开发生命周期的其他方面。所有这些方面由于元模型的公共含义而变得更加完整，例如提供的与其相关的建模标准。统软件数据和业务建模本书重点主要集中在建模软件的价值。但是在实践中数据建模和业务建模以种形式使用的时间更长些。问题是这些类型的建模传统上在建模语言和开发人员文化上属于完全不同的世界。现在统这三个世界的可能变得明显了没有必要成为种简单的建模语言或者工具，但是可以使用种多样的集中的开放行业标准的组合。贯穿生命周期的建模随者标准的不断演进，建模将应用到贯穿整个软件开发生命周期的活动的更广阔的范围。建模的应用程序已经在项目生命周期中更早地驱动测试和其他的质量保证方面。并且由于业务建模变得更加标准化并且同数据软件的集成度越来越高，种模型驱动的业务集成学科可能将要崭露头脚。特定领域的建模语言和其他的建模语言令开发人员能够将注意力集中到实施细节之上的抽象层次上。正如早在图中描述的那样，建模包含的层次范围很广，甚至当我们离开实际的代码也是样。对于抽象的最高层次，业务模型或域模型并不集中于软件，而是正在考虑的问题的本质。在这里，模型应该使用特定的业务和应用领域中人们和系统所熟悉的术语和图标。软件行业正朝向领域特定语言目的特定的建模语言方向发展，这样的建模语言专用于它们使用的各自领域。然而更通常的情况是，般目的建模语言，特别是，以标准的方法进行了扩展，通过诸如方面的革新来满足特定领域建模的需要。这两种方法和般的建模价值致以更有效及高效的方式为特定问题和解决方案提供抽象。软件开发业务许多人将软件开发称为团队运动。伴随而来的的个概念是国际团队运动。借助于当今的技术，软件开发已经摆脱了地理上的束缚。软件开发业务将变得越来越分布化和全球化。建模和其他更高形式的抽象对帮助开发人员处理相关的复杂性来说具有决定作用。模型驱动的构架，下步的计划是由对象管理组织领导的。当还处在早期的试用阶段时，就被认为是建模和模型驱动开发技术演进的下个逻辑步骤。基于和其他相关的标准，主要关注的是在抽象的不同层次上定义模型，和在不同层次之间的定义转换。自动工具支持对于的发展及成功应用来说具有决定意义。结论本文的目的是要确定建模的最根本途径，并强调运用建模进行软件开发的价值。建模是关于思想方法和工作，在更高层次上的抽象概念。这些都是经得起考验的技术，已经得到证明并且多年来成功运用于所有形式的工程技术学科。模型驱动形式的软件发展已经证明在软件产业的投入是有效的，较先进的，进步的。基于日益复杂的现代软件系统，和本文论述的几种趋势，我们坚信建模进入主流的软件开发社区的时机已经到来了达到这种速度与质量并重的目标，提出了软件开发的四项必要措施迭代开发重视构架持续的质量保证以及管理变更。其他复杂的高风险系统建模的相同理由同样适用于软件管理复杂性并理解设计和相关的风险。尤其是通过软件建模，开发人员能够在提交额外的资源之前创建并交流软件设计。从设计追溯到需求阶段，有助于确保构建正确的系统。进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。为什么些开发人员不选择软件建模尽管建模有许多原因和优点，但是仍然有很大部分软件开发人员不在源代码更高的层次上进行任何形式的抽象。这是为什么呢正如前面描述的那样，有时候问题或者解决方案的实际复杂度无需建模。再次重申，如果您准备建造间犬舍，您根本就不需要雇佣个建筑师或者聘请位建造者来做系列的设计规格说明。但是在软件世界中，系统经常是开始时简单并且易于理解，在