第2章 软件建模概述.pptVIP

软件建模与开发过程 第2章 软件建模概述 第2章 软件建模 建模的定义 建模是捕捉系统本质的过程，是对现实的简化。 就是把复杂的系统变成小的系统，采用“各个击破”的原则逐一解决。 把问题从问题领域转移到解决领域 。 第2章 软件建模 为什么要建模？ 建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。 要生产合格的软件就要有一套关于体系结构、过程和工具的规范。 第2章 软件建模 建模的好处？ 使用模型便于从整体上、宏观上把握问题，可以更好的解决问题 建模是使你逐层深入解决问题的办法 确认应用系统的功能需求并为事务处理原则建模 可以加强人员之间的沟通 可以更早的发现问题或疏漏的地方。模型为代码生成提供依据 模型帮助我们按照实际情况对系统进行可视化 模型允许我们详细说明系统的结构或行为 模型给出了一个指导我们构造系统的模板 模型对我们做出的决策进行文档化。 第2章 软件建模 建模的目标 模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。 模型允许我们详细说明系统的结构和行为。 模型给出一个知道我们构造系统的模板。 模型对我们的决策进行文档化。 第2章 软件建模 建模的误区 无论你遵从的是重量级的方法,比如Enterprise Unified Process (EUP)，还是轻量级的开发过程，如Extreme Programming(XP)，建模在软件开发中都是不可或缺的。 但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及像Object Management Group (OMG)和IEEE这类组织的标准。 第2章 软件建模 误区一：建模就等于是写文档 事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的——你可以拥有一个不是文档的模型和不是模型的文档。 建模很像是作计划：作计划的价值在于计划编制的过程中而非计划本身；价值体现在建模的活动中，而非模型本身实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。 第2章 软件建模 误区二：从开始阶段你可以考虑到所有的一切 怎么才能走出这个误区呢？ 你必须认识到你不能考虑到所有的细枝末节。 认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保 持一致。 认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP)的基本原理。 第2章 软件建模 误区三：建模是在浪费时间 许多人都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。 事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的 理解，涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。 第2章 软件建模 误区四：所有的开发人员都知道如何建模 事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非聪明的程序员常常相信自己无所不能，正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。 第2章 软件建模 建模十条原则 仅有数据模型对于现代软件是不够的。 接受变化，并且允许你的模型能够随着时间进行改进。 你不能冻结它们，然后就期待着成功。 模型并不一定就是文档，文档也不一定就是模型。 大多数的模型可能也应该被丢弃。 只有代码才能与代码保持真正的同步。 一些简单的工具，比如白板，就完全足以应付大多数建模工作。 思考，然后再编码。 你总能从别人身上学到东西。 建模可以用一种轻盈的方式。 设计直到代码发布以后才算完成。 第2章 软件建模 怎样