Page 1 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
前言 UML及建模的简介
? UML是什么
? UML有什么用处
? UML用在系统设计的哪一个阶段
? UML的历史
? UML的组成
? 支持 UML开发的常用工具
? 建模的定义
? 为什么要建模
? 建模的目标
? 建模的误区
? 建模十条原则
Page 3 ?
UML( Unified Modeling Language,统一建模语言 )
是一种可视化的建模语言,它能够让系统构造者用标准的、易于理
解的方式建立起能够表达他们设计思想的系统蓝图,并且提供一种
机制,以便于不同的人之间有效的共享和交流设计成果。
1,UML是一种语言
UML是什么?
2,UML是一种可视化的语言
3,UML是一种可以用于详细描述的语言
4,UML是一种构造语言
Page 4 ?
UML有什么用处?
一个成功的开发项目之所以成功,是因为功能的提出者(客户)和实现功能的开发人员(
程序员)之间有有一座可以很好沟通的桥梁。 UML借助一套图形和符号,可以来完成这
座桥梁的作用。
UML不是一门程序设计语言。但可以使用代码生成器工具将 UML模型转换为
多种程序设计语言代码,或使用反向生成器工具将程序源代码转换为 UML。
UML不是一种可用于定理证明的高度形式化的语言,这样的语言有很多种,但
它们通用性较差,不易理解和使用。
UML是一种通用建模语言。对于一些专门领域,例如用户图形界面( GUI)设
计、超大规模集成电路( VLSI)设计、基于规则的人工智能领域,使用专门的
语言和工具可能会更适合些。
UML是一种离散的建模语言,不适合对诸如工程和物理学领域中的连续系统建
模。它是一个综合的通用建模语言,适合对诸如由计算机软件、固件或数字逻
辑构成的离散系统建模。
Page 5 ?
UML用在系统设计的哪一个阶段?
软件设计几个主要的阶段,
需求分析
概要设计
详细设计
编 码
测 试
结构化的需
求分析方式
和设计方式
例如:数据流
图等
面向对象的需
求分析方式和
设计方式
结构化程序
设计语言,C

面向对象的
程序设计语
言,C++,
JAVA等
结构化测试
方法 面向对象的测试方法
例如,UML
Page 6 ?
UML的历史
Page 7 ?
UML的组成
? 构造块 ? 公共机制 ? 构架
? 建



? 关
系 ? 图
? UML
? 修

? 公



? 规



? 扩



? 五





Page 8 ?
支持 UML开发的常用工具
? PowerDesigner (Sybase)
? Rose (Rational)
? Together (Borland)
? Visio (Microsoft)
? BridgePoint (Project Technology)
? Visual UML (Visual Object Modelers)
Page 9 ?
建 模
建模的定义:
建模是对现实的简化。 就是把复杂的系统变成小的系统,
采用“各个击破”的原则逐一解决。
Page 10 ?
为什么要建模
? 建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。
要生产合格的软件就要有一套关于体系结构、过程和工具
的规范。
Page 11 ?
建模的目标
1)模型帮助我们按照实际情况或按照我们所需要的样式对
系统进行可视化。
2)模型允许我们详细说明系统的结构和行为。
3)模型给出一个知道我们构造系统的模板。
4)模型对我们的决策进行文档化。
Page 12 ?
建模的误区
? 无论你遵从的是重量级的方法,比如 Enterprise Unified
Process(EUP),还是轻量级的开发过程,如 Extreme
Programming(XP),建模在软件开发中都是不可或缺的。
但不幸的是其中充斥着各种谬误与迷思。
这来自于各个方面,有从理论家错误的研究、数十年来信
息技术领域内的文化沉积、软件工具开发商天花乱坠半的
市场宣传以及象 Object Management Group (OMG)和 IEEE
这类组织的标准
Page 13 ?
误区一:建模就等于是写文档
? 事实分析:“模型”与“文档”这二者在概念上是风马牛
不相及的----你可以拥有一个不是文档的模型和不是
模型的文档。
建模很象是作计划:作计划的价值在于计划编制的过程中
而非计划本身;价值体现在建模的活动中,而非模型本身
实际上,模型不是你系统中的一部分正式的文档,而且在
完成它们的使命后可以被丢掉。你会发现值得保留的只有
很少的模型,而且它一定是非常完美。
Page 14 ?
误区二:从开始阶段你可以考虑到所
有的一切
怎么才能走出这个误区呢?
首先,你必须认识到你不能考虑到所有的细枝末节。
第二,认识到不管你的最初所作的规格说明书有多好,但
注定代码会很快地与之失去同步,即便是你自己建模自己
编码。一个基本的道理就是代码永远只会和代码保 持一致。
第三,认识到迭代法(小规模地建模,编一些代码,做一些
测试,可能还会做一个小的工作版本)是软件开发的准则。
它是现代重量级的软件开发过程(如 EUP),以及轻量级
(如 XP)的基本原理。
Page 15 ?
误区三:建模是在浪费时间
? 许多人都这样认为,这主要是因为他们所接受的教育仅仅
局限于如何编写代码,对于完整的开发流程鲜有接触。而
且他们的经验也仅限于如何实现代码,就如初级程序员。
他们放弃了提高效率和学习技能的机会,这些技能能够使
他们很容易地适应不同的项目或组织。
? 事实分析:在大多数情况下,在开始编码之前画一个草图
、开发一个粗率的原型或者制作一些索引卡片都能提高你
的生产效率。高效的开发者在编码之前都要进行建模工作
。另外,建模是一种很好的在项目组成员与项目负责人之
间沟通途径。你们在这个过程中探讨问题,从而对所要的
是一个什么样的东西可以得到更好的 理解,涉及到该 项目
中的每个成员也可得到对该项目有一个从分的了解。
Page 16 ?
误区四:所有的开发人员都知道如何建模
? 我们现在面临照这样一个严重的问题:许多不是开发人员的
人,包括高级经理和用户,不知道软件是如何建 成的。其
结果,他们不能够区分开熟练的开发者和一般的程序员(当
然也分不清高级程序员和一般程序 员),他们想当然地认
为所有的开发人员都具备从头到尾开发整个系统的技能。
? 事实分析:这肯定是不正确的。建模的技能,是只有当一个
开发者通过学习它,并经过长期的实践才能够掌握。一些非
常聪明的程序员常常相信自己无所不能,正因为这样的狂妄
自大,他们承当的一些任务是他们根本就没有相应的技能去
完成的。软件开发是如此的复杂,单单一个人是很难具备所
有的技能去成功地进行开发,甚至也不可能去配置有一定复
杂程度的系统。开发者应该有自知之明,明白他们自己的弱
点,学无止境。通过互相取长补短,建模者可从程序员身上学
到一项技术的具体细节,程序员也可从建模者那里学到有价值
的设计和体系结构的技术。
Page 17 ?
建模十条原则
? 仅有数据模型对于现代软件是不够的。
? 接收变化,并且允许你的模型能够随着时间进行改进。 你不能
冻结它们,然后就期待着成功。
? 模型并不一定就是文档,文档也不一定就是模型。
? 大多数的模型可能也应该被丢弃。
? 只有代码才能与代码保持真正的同步。
? 一些简单的工具,比如白板,就完全足以应付大多数建模工作。
? 思考,然后再编码。
? 你总能从别人身上学到东西。
? 建模可以用一种轻盈的方式。
? 设计直到代码发布以后才算完成。
Page 18 ?
怎样成为优秀的软件模型设计者
? 1,人远比技术重要
? 2,理解你要实现的东西
? 3,谦虚是必须的品格
? 4,需求就是需求
? 5,需求其实很少改变,改变的是你对需求的理解
? 6,经常阅读
? 7,降低软件模块间的耦合度
? 8,提高软件的内聚性
? 9,考虑软件的移植性
? 10,接受变化
Page 19 ?
? 11,不要低估对软件规模的需求
? 12,性能仅仅是很多设计因素之一
? 13,管理接口
? 14,走近路需要更长的时间
? 15,别信赖任何人
? 16,证明你的设计在实践中可行
? 17,应用已知的模式
? 18,研究每个模型的长处和弱点
? 19,在现有任务中应用多个模型
? 20,教育你的听众
? 21,带工具的傻瓜还是傻瓜
? 22,理解完整的过程
Page 20 ?
? 23,常做测试,早做测试
? 24,把你的工作归档
? 25,技术会变,基本原理不会