论UML在程序开发中的重要作用.docx
《论UML在程序开发中的重要作用.docx》由会员分享，可在线阅读，更多相关《论UML在程序开发中的重要作用.docx（11页珍藏版）》请在冰豆网上搜索。
论UML在程序开发中的重要作用
经典的软件工程思想将软件开发分成5个阶段:
需求分析\系统分析与设计;系统实现\测试及维护五个阶段。
序言
如果想搭一个狗窝,备好木料、钉子与一些基本工具（如锤子、锯与卷尺）之后,就可以开始工作了。
从制定一点初步计划到完成一个满足适当功能的狗窝,可能不用别人帮助,在几个小时内就能够实现。
只要狗窝够大且不太漏水,狗就可以安居。
如果未能达到希望的效果,返工总就是可以的,无非就是让狗受点委屈。
如果您要建造一座高层办公大厦,若还就是先备好木料、钉子与一些基本工具就开始工作,那将就是非常愚蠢的。
因为您所使用的资金可能就是别人的,她们会对建筑物的规模、形状与风格做出要求。
同时,她们经常会改变想法,甚至就是在工程已经开工之后。
由于失败的代价太高了,因此必须要做详尽的计划。
负责建筑物设计与施工的就是一个庞大的组织机构,您只就是其中的一部分。
这个组织将需要各种各样的设计图与模型,以供各方相互沟通。
只要得到了合适的人员与工具,并对把建筑概念转换为实际建筑的过程进行积极的管理,将会建成这座满足使用要求的大厦。
如果想继续从事建筑工作,那么一定要在使用要求与实际的建筑技术之间做好平衡,并且处理好建筑团队成员们的休息问题,既不能把她们置于风险之中,也不能驱使她们过分辛苦地工作以至于精疲力尽。
奇怪的就是,很多软件开发组织开始想建造一座大厦式的软件,而在动手处理时却好像她们正在仓促地造一个狗窝。
有时您就是幸运的。
如果在恰当的时间有足够的合适人员,并且其她一切事情都很如意,您的团队有可能（仅就是可能）推出一个令用户眼花缭乱的软件产品。
然而,一般的情况下,不可能所有人员都合适（合适的人员经常供不应求）,时间并不总就是恰当的（昨天总就是更好）,其她的事情也并不尽如人意（常常由不得自己）。
现在对软件开发的要求正在日益增加,而开发团队却还就是经常单纯地依靠她们唯一真正知道如何做好的一件事——编写程序代码。
英雄式的编程工作成为这一行业的传奇,人们似乎经常认为更努力地工作就是面对开发中出现的各种危机的正常反应。
然而,这未必能产生正确的程序代码,而且一些项目就是非常巨大的,无论怎样延长工作时间,也不足以完成所需的工作。
如果真正想建造一个相当于房子或大厦类的软件系统,问题可不就是仅仅编写许多软件。
事实上,关键就是要编出正确的软件,并考虑如何少写软件。
要生产合格的软件就要有一套关于体系结构、过程与工具的规范。
即使如此,很多项目开始瞧起来像狗窝,但随后发展得像大厦,原因很简单,它们就是自己成就的牺牲品。
如果对体系结构、过程或工具的规范没有作任何考虑,总有一天狗窝会膨胀成大厦,并会由于其自身的重量而倒塌。
狗窝的倒塌可能使您的狗恼怒;同理,不成功的大厦则将对大厦的租户造成严重的影响。
不成功的软件项目失败的原因各不相同,而所有成功的项目在很多方面都就是相似的。
成功的软件组织有很多成功的因素,其中共同的一点就就是对建模的采用。
一、项目开发中模型就是什么以及建模的重要性。
那么,模型就是什么？
简单地说:
模型就是对现实的简化。
模型提供了系统的蓝图。
模型既可以包括详细的计划,也可以包括从很高的层次考虑系统的总体计划。
一个好的模型包括那些有广泛影响的主要元素,而忽略那些与给定的抽象水平不相关的次要元素。
每个系统都可以从不同的方面用不同的模型来描述,因而每个模型都就是一个在语义上闭合的系统抽象。
模型可以就是结构性的,强调系统的组织。
它也可以就是行为性的,强调系统的动态方面。
为什么要建模？
一个基本理由就是:
建模就是为了能够更好地理解正在开发的系统。
通过建模,要达到4个目的:
（1）模型有助于按照实际情况或按照所需要的样式对系统进行可视化。
（2）模型能够规约系统的结构或行为。
（3）模型给出了指导构造系统的模板。
（4）模型对做出的决策进行文档化。
建模并不只就是针对大的系统。
甚至像狗窝那样的软件也能从一些建模中受益。
然而,可以明确地讲,系统越大、越复杂,建模的重要性就越大,一个很简单的原因就是:
因为不能完整地理解一个复杂的系统,所以要对它建模。
人对复杂问题的理解能力就是有限的。
通过建模,缩小所研究问题的范围,一次只着重研究它的一个方面,即把一个困难问题划分成一系列能够解决的小问题;解决了这些小问题也就解决了这个难题。
此外,通过建模可以增强人的智力。
一个适当选择的模型可以使建模人员在较高的抽象层次上工作。
每个项目都能从一些建模中受益。
即使在一次性的软件开发中——由于可视化编程语言的支持,可以轻而易举地扔掉不适合的软件。
建模也能帮助开发组更好地对系统计划进行可视化,并帮助她们正确地进行构造,使开发工作进展得更快。
如果根本不建模,项目越复杂,就越有可能失败或者构造出错误的东西。
所有实用系统都有一个自然趋势:
随着时间的推移变得越来越复杂。
虽然今天可能认为不需要建模,但随着系统的演化,终将会对这个决定感到后悔,但那时为时已晚。
在项目开发中如何建模,接下来我将详细讲解一下建模工具UML。
二、UML介绍
UML（UnifiedModelingLanguage）又称统一建模语言或标准建模语言,就是始于1997年一个OMG标准,它就是一个支持模型化与软件系统开发的图形化语言,为软件开发的所有阶段提供模型化与可视化支持,包括由需求分析到规格,到构造与配置。
UML就是一种功能强大的,面向对象的可视化系统分析的建模语言,它的各个模型可以帮助开发人员更好地理解业务流程,建立更可靠,更完善的系统模型、从而使用户与开发人员对问题的描述达到相同的理解,以减少语义差异,保障分析的正确性。
UML建模分为需求建模与设计建模,需求建模的目的就是确定系统边界并明确系统需要实现的功能。
而设计建模主要目的就是用于开发团队中的设计思想交流;以及后续程序设计的依据;后续测试与验收程序的依据。
）
三、UML应用领域
UML的目标就是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域。
其中最常用的就是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。
总之,UML就是一个通用的标准建模语言,可以对任何具有静态结构与动态行为的系统进行建模。
此外,UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。
在需求分析阶段,可以用用例来捕获用户需求。
通过用例建模,描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。
分析阶段主要关心问题域中的主要概念（如抽象、类与对象等）与机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。
为实现用例,类之间需要协作,这可以用UML动态模型来描述。
在分析阶段,只对问题域的对象（现实世界的概念）建模,而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯与并行性等问题的类）。
这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。
编程（构造）就是一个独立的阶段,其任务就是用面向对象编程语言将来自设计阶段的类转换成实际的代码。
在用UML建立分析与设计模型时,应尽量避免考虑把模型转换成某种特定的编程语言。
因为在早期阶段,模型仅仅就是理解与分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。
UML模型还可作为测试阶段的依据。
系统通常需要经过单元测试、集成测试、系统测试与验收测试。
不同的测试小组使用不同的UML图作为测试依据:
单元测试使用类图与类规格说明;集成测试使用部件图与合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果就是否满足在分析阶段确定的需求。
总之,标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试与维护。
四、UML图形种类介绍
UML从考虑系统的不同角度出发,定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图,按其特点可分成五大类,1、用例图;2、静态图:
（类图、对象图）;3、行为图:
（活动图、状态图）;4、交互图:
（顺序图、协作图）;5、实现图:
（构件图、部署图）。
这些图从不同的侧面对系统进行描述。
系统模型将这些不同的侧面综合成一致的整体,便于系统的分析与构造。
1、用例图
描述角色以及角色与用例之间的连接关系。
说明的就是谁要使用系统,以及她们使用该系统可以做些什么。
一个用例图包含了多个模型元素,如系统、参与者与用例,并且显示了这些元素之间的各种关系,如泛化、关联与依赖。
2、类图
类图就是描述系统中的类,以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图就是一种模型类型,确切的说,就是一种静态模型类型。
3、对象图
与类图极为相似,它就是类图的实例,对象图显示类的多个对象实例,而不就是实际的类。
它描述的不就是类之间的关系,而就是对象之间的关系。
4、活动图
描述用例要求所要进行的活动,以及活动间的约束关系,有利于识别并行活动。
能够演示出系统中哪些地方存在功能,以及这些功能与系统中其她组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图
描述类的对象所有可能的状态,以及事件发生时状态的转移条件。
可以捕获对象、子系统与系统的生命周期。
她们可以告知一个对象可以拥有的状态,并且事件（如消息的接收、时间的流逝、错误、条件变为真等）会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态与复杂行为的类;该图可以确定类的行为,以及该行为如何根据当前的状态变化,也可以展示哪些事件将会改变类的对象的状态。
状态图就是对类图的补充。
6、序列图 （顺序图）
序列图就是用来显示您的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间就是如何进行交互的。
顺序图将显示的重点放在消息序列上,即强调消息就是如何在对象之间被发送与接收的。
7、协作图
与序列图相似,显示对象间的动态合作关系。
可以瞧成就是类图与顺序图的交集,协作图建模对象或者角色,以及它们彼此之间就是如何通信的。
如果强调时间与顺序,则使用序列图;如果强调上下级关系,则选择协作图;这两种图合称为交互图。
8、构件图 （组件图）
描述代码构件的物理结构以及各种构建之间的依赖关系。
用来建模软件的组件及其相互之间的关系,这些图由构件标记符与构件之间的关系构成。
在组件图中,构件时软件单个组成部分,它可以就是一个文件,产品、可执行文件与脚本等。
9、部署图 （配置图）
就是用来建模系统的物理部署。
例如计算机与设备,以及它们之间就是如何连接的。
部署图的使用者就是开发人员、系统集成人员与测试人员。
以上图形中由于类图之间的关系相对比较复杂,所以对于类图之间的关系进行一个大致的讲解。
其关系种类有关联、聚合、组合、泛化、依赖。
1、 泛化（Generalization）
【泛化关系】:
就是一种继承关系, 表示一般与特殊的关系, 它指定了子类如何特化父类的所有特征与行为、 例如:
老虎就是动物的一种, 即有老虎的特性也有动物的共性、
【箭头指向】:
带三角箭头的实线,箭头指向父类
2、 实现（Realization）
【实现关系】:
就是一种类与接口的关系, 表示类就是接口所有特征与行为的实现、
【箭头指向】:
带三角箭头的虚线,箭头指向接口
3、 关联（Association）
【关联关系】:
就是一种拥有的关系, 它使一个类知道另一个类的属性与方法;如:
老师与学生,丈夫与妻子
关联可以就是双向的,也可以就是单向的。
双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
【代码体现】:
成员变量
【箭头及指向】:
带普通箭头（或实心三角形箭头）的实心线,指向被拥有者
上图中,老师与学生就是双向关联,老师有多名学生,学生也可能有多名老师。
但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程就是个抽象的东西她不拥有学生。
4、 聚合（Aggregation）
【聚合关系】:
就是整体与部分的关系, 且部分可以离开整体而单独存在、 如车与轮胎就是整体与部分的关系, 轮胎离开车仍然可以存在、
聚合关系就是关联关系的一种,就是强的关联关系;关联与聚合在语法上无法区分,必须考察具体的逻辑关系。
【代码体现】:
成员变量
【箭头及指向】:
带空心菱形的实心线,菱形指向整体
5、 组合（Composition）
【组合关系】:
就是整体与部分的关系, 但部分不能离开整体而单独存在、 如公司与部门就是整体与部分的关系, 没有公司就不存在部门、
组合关系就是关联关系的一种,就是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期
【代码体现】:
成员变量
【箭头及指向】:
带实心菱形的实线,菱形指向整体
6、 依赖（Dependency）
【依赖关系】:
就是一种使用的关系, 即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖、
【代码表现】:
局部变量、方法的参数或者对静态方法的调用
【箭头及指向】:
带箭头的虚线,指向被使用者
各种关系的强弱顺序:
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
UML图形实例
由于开发的项目复杂程度不一,所以在真正的开发上以上九类图形并不就是都会用上,一般情况下使用频率最高的就三种图形:
用例图、类图、时序图。
接下来实例也只列出此三种图形实例
1类图 :
2、用例图 :
、3、时序图 :
UML建模工具
Powerdesignrose
附录:
2、对象图 :
描述一组对象之间的关系,就是具有具体属性值与行为的一个具体事物,其就是类图中所建事物实例的静态快照,其与类图的主要区别就是一个就是抽象的,而对象图就是具体的。
如下图（摘自网络）:
协作图:
5、状态图 :
展示了一个状态机,由状态、转换、事件与活动组成。
强调事件行为的顺序。
如下图（摘自网络）:
6、活动图 :
就是一种特殊的状态图,实现一个活动到另一个活动的流程。
如下图（摘自网络）:
7、构件图与部署图 :
构件图展示一组构件之间的组织与依赖关系,并以全局的模型展示出来。
部署图就是构件的配置及描述系统如何在硬件上部署。
如下图（摘自网络）:
升级会员 