统一建模语言UML基础教程04(1)

建模十条原则
仅有数据模型，对于现代的软件开发是不够的。 接收变化，并且允许你的模型能够随着时间进行改进。你不 能冻结它们，然后就期待着成功。 模型并不一定就是文档，文档也不一定就是模型。 大多数的模型，最终可能被丢弃。 只有代码才能与代码保持真正的同步。 一些简单的工具，比如白板，可以应付大多数得建模工作。 思考，然后再编码。 你总能从别人身上学到东西。 建模可以用一种轻盈的方式进行。 设计，直到代码发布以后才算完成。
误区四：必须“冻结” 误区四：必须“冻结”需求
这个要求常常来自高级经理，他们确切地想知道他们从这个 项目组能得到什么东西。这样的好处就是在开发周期的早期 确定下需求，就可以确切地知道所要的是一个什么样的东西 ；缺点就是他们可能没有得到实际上所需要问题的全部（可 能不全或夹杂错误的需求）。 事实分析：变化总会发生的。由于优先级的变化和逐渐对系 统有了更进一步的理解，都会引起需求的变化。与冻结需求 相反，估计项目成功的风险，尽量去接受变化而且相应地采 相反，估计项目成功的风险，尽量去接受变化而且相应地采 取行动，就象XP所建议的一样。 取行动，就象XP所建议的一样。
系统分析和设计内容
§ UML建模的认知误区 UML建模的认知误区 § UML建模的应用 UML建模的应用 § 简易教学管理系统的建模
UML建模的应用 UML建模的应用
UML是一种建模语言，而不是方法，因为UML中没有过程的概念， UML是一种建模语言，而不是方法，因为UML中没有过程的概念， 而过程正是方法论的一个重要组成部分。UML本身独立于过程， 而过程正是方法论的一个重要组成部分。UML本身独立于过程， 这意味着用户在使用UML进行建模时，可以选用任何适合的过程 这意味着用户在使用UML进行建模时，可以选用任何适合的过程 进行。 软件开发是个复杂的过程，每个阶段要彻底解决相关问题是不可 软件开发是个复杂的过程，每个阶段要彻底解决相关问题是不可 能的，项目的开发必须要有回溯要求，即重复性开发。在面向对 象过程中，需要重复多次进行分析、设计、开发、测试和部署的 阶段。 Rational统一过程（RUP， Rational统一过程（RUP，Rational Unified Process）就是一 Process） 种重复开发方法。 重复区六：必须使用CASE工具 建模常常被认为是一项复杂的工作，因此需要大量 地使用CASE工具辅助进行。 地使用CASE工具辅助进行。 事实分析：是的，建模可以是很复杂的。但你完全 可以建立一个有效而简单的模型表述其中关键的信 可以建立一个有效而简单的模型表述其中关键的信 息，而不是将一些无关紧要的细节包括进来。 比如，使用UML建立模型来表示类，只标识其有关的 比如，使用UML建立模型来表示类，只标识其有关的 属性及一些关键的业务操作，尽量避免琐碎的实现 细节。通过建模寻找解决问题的方法。
统一建模语言UML 基础教程
主讲教师： 主讲教师：单 红 老师 福州大学 数学与计算机科学学院
第四讲：
软件系统的分析与设计之
UML建模的应用 UML建模的应用
系统分析和设计内容
§ UML建模的认知误区 UML建模的认知误区 § UML建模的应用 UML建模的应用 § 简易教学管理系统的建模
UML建模的认知误区 UML建模的认知误区
RUP开发周期 RUP开发周期
RUP开发周期经历四个阶段：开始、细化、构造和交接。 RUP开发周期经历四个阶段：开始、细化、构造和交接。 开发周期经历四个阶段 和交接
1.
开始阶段就是项目的开头，要收集信息和进行概念验证。 开始阶段就是项目的开头，要收集信息和进行概念验证。 开始阶段得出项目行或不行的决策。 细化阶段要细化使用案例和作出结构性决策。细化包括分 细化阶段要细化使用案例和作出结构性决策。细化包括分 析、设计、编码和测试文件。 构造阶段则进行大量的编码。 构造阶段则进行大量的编码。 交接阶段是系统向用户进行最后准备和部署的阶段。 交接阶段是系统向用户进行最后准备和部署的阶段。
误区九：所有的开发人员都知道如何建模
现在面临照这样一个严重的问题：许多不是开发人员的人，包括 高级经理和用户，不知道软件是如何建成的。其结果是他们不能 够区分开熟练的开发者和一般的程序员，他们想当然地认为所有 的开发人员都具备从头到尾开发整个系统的技能，并一直围绕这 系统的开发过程。 事实分析：这肯定是不正确的。建模的技能，只有当一个开发者 通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程 通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程 序员常常相信自己无所不能，他们终究只能是程序员。正因为这 序员常常相信自己无所不能，他们终究只能是程序员。正因为这 样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技 能去完成的。软件开发是如此的复杂，单靠一个人是很难拥有所 有的技能成功地进行系统开发。 开发者应该有自知之明，明白自己的弱点，学无止境。通过互相 取长补短，建模者可从程序员身上学到一项技术的具体细节，程 序员也可从建模者那里学到有价值的设计和体系结构的技术。合 理的组织人员，有效的推动开发进程，是UML建模的关键。 理的组织人员，有效的推动开发进程，是UML建模的关键。
第一，在开始阶段，你必须认识到你不能考虑到所有的细枝末节。 第二，认识到编码人员可能会对建模的工作不以为然，他们或许会说模型没 有反应出真实的情况。 第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地 与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永 远只会和代码保持一致。 第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会 第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会 做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过 程（如EUP），以及轻量级（如XP)的基本原理。 程（如EUP），以及轻量级（如XP)的基本原理。
误区八：数据模型(Data Model)就是一切 误区八：数据模型(Data Model)就是一切
基于数据模型，许多组织就蹒跚启动新的开发工作，也许正 如你所在的组织。 事实分析：数据模型是一个重要的，但不是最重要的建模， 事实分析：数据模型是一个重要的，但不是最重要的建模， 它最好是建立在另外的模型之上。这即使在象数据仓库这类 面向数据的项目中也如此。 如果没有很好的理解用户是如何使用该数据仓库的（在数据 模型中没有表示出来），这些项目经常是以可悲的失败而告 终。你可以使用的模型有很多用例图（use cases），活动图 终。你可以使用的模型有很多用例图（use cases），活动图 （activity diagrams），类图（class diagrams），组件图 diagrams），类图（class diagrams），组件图 （component diagrams），以及用户界面流程图（user diagrams），以及用户界面流程图（user interface flow diagrams）等等。数据模型仅仅是其中的一 diagrams）等等。数据模型仅仅是其中的一 种。每种模型都有其长处和短处，应该正确地使用。
无论你遵从的是重量级的方法,比如Enterprise 无论你遵从的是重量级的方法,比如Enterprise Unified Process (EUP)，还是轻量级的开发过程，如Extreme (EUP)，还是轻量级的开发过程，如Extreme Programming (XP)，建模在软件开发中都是不可或缺的。 (XP)，建模在软件开发中都是不可或缺的。 但不幸的是其中充斥着各种谬误与迷思，也就是UML建模 但不幸的是其中充斥着各种谬误与迷思，也就是UML建模 的认知误区。
误区二：从开始阶段你可以考虑到所有的一切
对这一点的迷信会导致在前期投入可观的时间去做所有的一 切建模以期把所有一切都弄正确，试图在编码开始前就“ 切建模以期把所有一切都弄正确，试图在编码开始前就“冻 结”所有的需求（见误区四），以致于患上“分析期麻痹症 所有的需求（见误区四），以致于患上“ ”。要等到模型非常完美之后才敢向前进。基于这个观点， 项目组开发了大量的文档，而不是他们真正想要得到的— 项目组开发了大量的文档，而不是他们真正想要得到的—开 发满足需要的软件。 事实分析：怎么才能走出这个误区呢？
误区三：建模意味着需要一个重量级的软 件开发过程
很多人认为UML建模，只适合于大型复杂的应用系统， 很多人认为UML建模，只适合于大型复杂的应用系统， 为此走入一个误区（经常与误区一有联系）的小型项目 组常常是连建模都彻底地放弃了，应为这样的软件开发 过程对他们来说太复杂太沉重而且没有必要。 事实分析：你可以用一种轻灵的方式取而代之，比如： 事实分析：你可以用一种轻灵的方式取而代之，比如： 用简单的工具进行简单地建模的详细内容，而且你可以 在它的使命完成后丢弃你的模型。同样也可以很基本的 方式进行建模（比如，从办公桌起来，来到白板前就开 始构略草图）。只要你愿意，你就可以轻松地建模。
误区五：设计是不可更改的
如同误区四，要求每一个开发人员必须严格遵从“设计“ 如同误区四，要求每一个开发人员必须严格遵从“设计“，导致 开发人员为了符合“设计“ 开发人员为了符合“设计“而去做错误的事情或以错误的方式做 正确的事情，或者是简单地忽略了设计，否定了所有设计可能带 来的好处。冻结了设计，你就不能从项目进程所学到知识进一步 获益。另外一个很大的趋势就是开发出大量的文档而不是实际的 软件，使用面向文档的CASE工具而不是能给项目带来实际价值的 软件，使用面向文档的CASE工具而不是能给项目带来实际价值的 面向应用的工具。 事实分析：事实上，设计会经常根据开发人员和数据库管理员的 反馈进行修改，因为他们是最接近实际应用的人，通常他们对技 术环境的理解要好于建模者。我们必须的面对这样一个事实：人 无完人，他们所作的工作也不可能尽善尽美。 难道您真的想将一个并不完善的设计固定下来而不再去修改其中 的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能 冻结你的设计，因为任何需求的修改势必影响设计。正确的态度 是：只要你的代码还在改动，设计就没完。 是：只要你的代码还在改动，设计就没完。