Uml的发展史.docx
- 文档编号:25009198
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:12
- 大小:793.25KB
Uml的发展史.docx
《Uml的发展史.docx》由会员分享,可在线阅读,更多相关《Uml的发展史.docx(12页珍藏版)》请在冰豆网上搜索。
Uml的发展史
Uml的发展史
UML的发展史
公认的建模语言出现在二十世纪七十年代中期,到八十年代末发展极为迅速。
据统计,从1989年到1994年,面向对象建模语言的数量从不到10增加到50多种。
各类语言的创造者极力推崇自己的语言,并不断地发展完善它。
但由于各种建模语言所固有的差异和优缺点,使得使用者不知道该选用哪种语言。
其中比较流行的有Booch,Rumbaugh(OMT),Jacobsom(OOSE),Coad-Yourdon等方法。
OMT擅长分析,Booch擅长设计。
OOSE擅长业务建模。
Rumbaugh于1994年离开GE加入Booch所在的Rational公司,他们一起研究一种统一的方法,一年后,UnifiedMethod0.8诞生,同年,Rational收购了Jacobson所在的ObjectoryAB公司。
经过三年的共同努力,UML0.9和UML0.91于1996年相继面世。
此后UML的创始人Booch等邀请计算机软件工程界的著名人士和著名的企业如IBM,HP,DEC,Microsoft,Oracle等对UML进行评论,提出修改意见。
1997年1月Rational公司向OMG提交了UML1.0标准文本。
1997年11月向OMG宣布接受UML,认定为标准的建模语言。
UML目前还在不断地发展和完善。
什么是UML(UnifiedModelingLanguage)
统一:
表示是一种通用的标准,它被OMG(ObjectManagementGroup)认可,成为软件工业界的一种标准。
UML表述的内容能被各类人员所理解,包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。
他们可以通过UML充分理解和表达自己所关注的那部分内容。
建模:
即建立软件系统的模型。
为说明建模的价值。
Booch给出一个类比:
盖一个动物窝棚、修一个乡间别墅和建一栋摩天大楼。
建立一个简单的系统,例如盖一个动物窝棚,模型可有可无,修一个乡间别墅,模型的必要性增大,建立一个高度复杂的系统,例如建一座摩天大楼模型必不可少。
语言:
表明它是一套按照特定规则和模式组成的符号系统,它用半形式化方法定义,即用图形符号、自然语言和形式语言相结合的方法来描述定义的。
UML有9中图,它们结构不同,但是对同一领域不同角度的观察。
UP(UnifiedProcess)(软件开发过程)
UML是建模语言,它的表示和规则能够用来为系统进行面向对象的建模,但并没有定义一种标准的开发过程。
开发过程是指实施与软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。
行之有效的软件开发过程可以提高软件开发组织的生产效率、提高软件质量、降低成本并减少风险。
UP是目前市场上领先的软件开发过程之一,它提供了一种严谨的途径来分派开发组织的任务和职责。
传统的软件开发过程
开发一个系统软件,开发组可能希望马上进入编码阶段。
但是他们可能对要对什么编码还没有搞清楚。
开发组必须要经历一个软件开发过程,遵循一定的步骤。
在进行程序设计前开发人员必须要充分理解做要解决的问题,这需要专门有人负责需求的分析。
进行了需求分析之后,还必须有人将分析产品转化为设计产品。
然后程序员再根据设计产品编制代码,这些代码在经过测试和部署后,最终成为目标系统。
在传统的软件开发过程中瀑布模型是使用比较广泛的一种开发方式。
它规定了软件生命周期上各阶段的软件工程活动:
制定计划、需求分析、软件设计、编码、测试、运行和维护。
各阶段严格按顺序进行,前一阶段的任务没有完成,不能进入下一个阶段的工作。
传统软件开发过程的缺点
这种方式下的开发过程被分割开来,分析人员将分析结果转交给设计人员,设计人员再把设计结果交给开发人员。
它不利于各类人员协同工作及共享信息。
无论分析人员怎样在开始进行调查研究与分析,都不可能对未来的系统的一切需求都定义的完整无缺。
往往在以后的设计阶段或编码阶段,才发现原来对系统的需求定义必须进行修改或补充。
越在后期发现问题,越难补救,会导致大量费用的投入,并可能降低软件的质量。
UP的核心原则
●由用例驱动:
用例是捕获用户需求的方法,它在整个软件开发过程中起着驱动的作用。
分析员使用用例建立需求模型,设计人员根据用例进行设计,测试人员使用用例作为测试的依据。
●以体系结构为中心:
体系结构对于软件如同建筑物的结构对于建筑物一样,体系结构的核心是根据某种规则将内容在宏观上做一个分隔,确保他们在后续的活动中稳定的被充实,同时促进内容更易于被复用。
系统的构造、管理均围绕系统的体系结构进行。
常见的体系结构有层次结构和MVC结构。
◆迭代化开发:
首先介绍迭代的概念。
迭代的思想很简单,通常来说,就是将大问题化小,使它们更容易管理和成功完成。
每个小项目是一个迭代,每一个迭代产生最终将系统部分完成的版本,最终产生完整的系统。
这样,每一个迭代中都必须包含正常软件项目开发的所有元素:
需求,分析。
设计。
实现。
测试等。
每个迭代都是一个独立完整的开发小单元,都有预先规划的进入准则和产出结果,遇到问题能够及时处理并加入必要的变更。
每个迭代结束时都需要对所获得的系统模型进行评价,判断是否已满足预定目标和要求,决定是否需要继续下一轮的迭代。
另外每个迭代还可产生一个可以执行的原型系统,可投入试运行,以判断是否符合要求。
系统在一次次的迭代中逐渐精化与完善,直至完成系统的开发,形成最终的软件产品。
UP的软件开发过程
●初始阶段:
探讨软件开发的必要性和可行性;捕获基本需求以界定系统范围;识别关键任务。
●细化阶段:
细化用例,确定系统的基本架构。
细化包括分析、设计、编码和测试文件。
通过迭代的方法建造软件系统。
每个迭代包括5个核心工作流,每个迭代将得到一个更准确的接近未来系统的模型。
●构建阶段:
完成所有的需求、分析和设计,进行大量的编码。
●移交阶段:
它是系统正式投入运行前的阶段,要做的工作有系统的B测试、系统性能的调整、创作用户手册和其他文档,人员培训等
支持UML开发的工具—RationalRose工具
包图:
是包和类组成的,表示包与包之间的关系,包图描述系统的分层结构
对象图:
是类图的实例
3.行为图:
描述系统动态模型和对象组成的交换关系。
包括状态图和活动图
活动图:
描述了业务实现用例的工作流程
状态图:
是描述状态到状态控制流,常用于动态特性建模
4.交互图:
描述对象之间的交互关系
顺序图:
对象之间的动态合作关系,强调对象发送消息的顺序,同时显示对象之间的交互
合作图:
描述对象之间的协助关系
5.实现图:
配置图:
定义系统中软硬件的物理体系结构
UML提供的基本模型图包括:
(1)、用例图:
展示系统外部的各类执行者与系统提供的各种用例之间的关系
(2)、类图:
展示系统中类的静态结构(类是指具有相同属性和行为的对象,类图用来描述系统中各种类之间的静态结构)
(3)、对象图:
是类图的一种实例化图(对象图是对类图的一种实例化)
(4)、包图:
是一种分组机制。
在UML1.1版本中,包图不再看作一种独立的模型图)
(5)、状态图:
描述一类对象具有的所有可能的状态及其转移关系(它展示对象所具有的所有可能的状态以及特定事件发生时状态的转移情况)
(6)、时序图/顺序图:
展示对象之间的一种动态协作关系(一组对象组成,随时间推移对象之间交换消息的过程,突出时间关系)
(7)、合作图:
从另一个角度展示对象之间的动态协作关系(对象间动态协作关系,突出消息收发关系)
(8)、活动图:
展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程)
(9)、构件图:
展示程序代码的物理结构(描述程序代码的组织结构,各种构件之间的依赖关系)
(10)、配置图:
展示软件在硬件环境中(特别是在分布式及网络环境中)的配置关系(系统中硬件和软件的物理配置情况和系统体系结构)
1、用例图(usecasediagrams)
【概念】描述用户需求,从用户的角度描述系统的功能
【描述方式】椭圆表示某个用例;人形符号表示角色
【目的】帮组开发团队以一种可视化的方式理解系统的功能需求
【用例图】
2、静态图
1.类图(classdiagrams)
【概念】显示系统的静态结构,表示不同的实体是如何相关联的
用途:
类图显示了一组类、接口、协作以及他们之间的关系。
在UML中问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。
类加上他们之间的关系就构成了类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例
【描述方式】三个矩形
【目的】表示一个逻辑类或实现类,逻辑类通常是用户的业务所涉及的事物;实现类是程序员处理的实体
【类图】
2.对象图(objectdiagrams)
【概念】类图的一个实例,描述系统在具体时间点上所包含的对象以及各个对象的关系
【对象图】
3、交互图
用来描述对象之间的交互关系
1.序列图(顺序图)
【概念】描述对象之间的交互顺序,着重体现对象间消息传递的时间顺序
【描述方式】横跨图的顶部,每个框表示每个类的实例或对象;类实例名称和类名称使用冒号分开
【目的】显示流程中不同对象之间的调用关系,还可以显示不同对象的不同调用。
【序列图】
2.协作图(Collaborationdiagrams)
【概念】描述对象之间的合作关系,侧重对象之间的消息传递
4、行为图:
描述系统的动态模型和对象之间的交互关系
1.状态图(Statechartdiagrams)
【概念】描述对象的所有状态以及事件发生而引起的状态之间的转移
【描述方式】
1.起始点:
实心圆
2.状态之间的转换:
使用开箭头的线段
3.状态:
圆角矩形
4.判断点:
空心圆
5.一个或多个终止点:
内部包含实心圆的圆
【目的】表示某个类所处的不同状态以及该类在这些状态中的转换过程
2.活动图(Activitydiagrams)
【概念】描述满足用例要求所要进行的活动以及活动时间的约束关系
【描述方式】
6.起始点:
实心圆
7.活动:
圆角矩形
8.终止点:
内部包含实心圆的圆
9.泳道:
实际执行活动的对象
【目的】表示两个或多个对象之间在处理某个活动时的过程控制流程
【活动图】
活动图和状态图区别:
5、实现图
10.构件图(Componentdiagrams)
【概念】描述代码构件的物理结构以及各构件之间的依赖关系
【描述方式】构件
【目的】提供系统的物理视图,根据系统的代码构件显示系统代码的整个物理结构
【构架图】
11.部署图(Deploymentdiagrams)
【概念】系统中硬件的物理体系结构
【描述方式】
12.三维立方体表示部件
13.节点名称位于立方体上部
【目的】显示系统的硬件和软件的物理结构
【部署图】
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Uml 发展史