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公司。经过三年的共同努力，ＵＭＬ０.９和ＵＭＬ０.９１于１９９６年相继面世。此后ＵＭＬ的创始人Booch等邀请计算机软件工程界的著名人士和著名的企业如IBM，HP，ＤＥＣ，Ｍｉｃｒｏｓｏｆｔ，Ｏｒａｃｌｅ等对ＵＭＬ进行评论，提出修改意见。１９９７年１月Ｒａｔｉｏｎａｌ公司向ＯＭＧ提交了ＵＭＬ１.０标准文本。１９９７年１１月向ＯＭＧ宣布接受ＵＭＬ，认定为标准的建模语言。ＵＭＬ目前还在不断地发展和完善。什么是ＵＭＬ(UnifiedModelingLanguage)统一：表示是一种通用的标准，它被OMG(ObjectManagementGroup)认可，成为软件工业界的一种标准。UML表述的内容能被各类人员所理解，包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。他们可以通过UML充分理解和表达自己所关注的那部分内容。建模：即建立软件系统的模型。为说明建模的价值。Booch给出一个类比：盖一个动物窝棚、修一个乡间别墅和建一栋摩天大楼。建立一个简单的系统，例如盖一个动物窝棚，模型可有可无，修一个乡间别墅，模型的必要性增大，建立一个高度复杂的系统，例如建一座摩天大楼模型必不可少。语言：表明它是一套按照特定规则和模式组成的符号系统，它用半形式化方法定义，即用图形符号、自然语言和形式语言相结合的方法来描述定义的。UML有9中图，它们结构不同，但是对同一领域不同角度的观察。UP(UnifiedProcess)（软件开发过程）UML是建模语言，它的表示和规则能够用来为系统进行面向对象的建模，但并没有定义一种标准的开发过程。开发过程是指实施与软件开发和维护中的阶段、方法、技术、实践及相关产物（计划、文档、模型、代码、测试用例和手册等）的集合。行之有效的软件开发过程可以提高软件开发组织的生产效率、提高软件质量、降低成本并减少风险。UP是目前市场上领先的软件开发过程之一，它提供了一种严谨的途径来分派开发组织的任务和职责。传统的软件开发过程开发一个系统软件，开发组可能希望马上进入编码阶段。但是他们可能对要对什么编码还没有搞清楚。开发组必须要经历一个软件开发过程，遵循一定的步骤。在进行程序设计前开发人员必须要充分理解做要解决的问题，这需要专门有人负责需求的分析。进行了需求分析之后，还必须有人将分析产品转化为设计产品。然后程序员再根据设计产品编制代码，这些代码在经过测试和部署后，最终成为目标系统。在传统的软件开发过程中瀑布模型是使用比较广泛的一种开发方式。它规定了软件生命周期上各阶段的软件工程活动：制定计划、需求分析、软件设计、编码、测试、运行和维护。各阶段严格按顺序进行，前一阶段的任务没有完成，不能进入下一个阶段的工作。传统软件开发过程的缺点这种方式下的开发过程被分割开来，分析人员将分析结果转交给设计人员，设计人员再把设计结果交给开发人员。它不利于各类人员协同工作及共享信息。无论分析人员怎样在开始进行调查研究与分析，都不可能对未来的系统的一切需求都定义的完整无缺。往往在以后的设计阶段或编码阶段，才发现原来对系统的需求定义必须进行修改或补充。越在后期发现问题，越难补救，会导致大量费用的投入，并可能降低软件的质量。UP的核心原则由用例驱动：用例是捕获用户需求的方法，它在整个软件开发过程中起着驱动的作用。分析员使用用例建立需求模型，设计人员根据用例进行设计，测试人员使用用例作为测试的依据。以体系结构为中心：体系结构对于软件如同建筑物的结构对于建筑物一样，体系结构的核心是根据某种规则将内容在宏观上做一个分隔，确保他们在后续的活动中稳定的被充实，同时促进内容更易于被复用。系统的构造、管理均围绕系统的体系结构进行。常见的体系结构有层次结构和MVC结构。迭代化开发：首先介绍迭代的概念。迭代的思想很简单，通常来说，就是将大问题化小，使它们更容易管理和成功完成。每个小项目是一个迭代，每一个迭代产生最终将系统部分完成的版本，最终产生完整的系统。这样，每一个迭代中都必须包含正常软件项目开发的所有元素：需求，分析。设计。实现。测试等。每个迭代都是一个独立完整的开发小单元，都有预先规划的进入准则和产出结果，遇到问题能够及时处理并加入必要的变更。每个迭代结束时都需要对所获得的系统模型进行评价，判断是否已满足预定目标和要求，决定是否需要继续下一轮的迭代。另外每个迭代还可产生一个可以执行的原型系统，可投入试运行，以判断是否符合要求。系统在一次次的迭代中逐渐精化与完善，直至完成系统的开发，形成最终的软件产品。UP的软件开发过程初始阶段：探讨软件开发的必要性和可行性；捕获基本需求以界定系统范围；识别关键任务。细化阶段：细化用例，确定系统的基本架构。细化包括分析、设计、编码和测试文件。通过迭代的方法建造软件系统。每个迭代包括5个核心工作流，每个迭代将得到一个更准确的接近未来系统的模型。构建阶段：完成所有的需求、分析和设计，进行大量的编码。移交阶段：它是系统正式投入运行前的阶段，要做的工作有系统的B测试、系统性能的调整、创作用户手册和其他文档，人员培训等支持UML开发的工具—RationalRose工具由于UML本身是一个以图形化图符为主的建模方法，因此UML支持工具就显得更为重要了。工具的作用不仅在于它可以帮助人们很方便的实现图示模型的绘制，实现模型的更改，更重要的是，工具使得人们可以全面地对模型进行整个开发过程的管理，当软件规模迅速扩大时，工具的作用就显得更为突出，因为人们自己已经无法管理非常庞大的模型了。RationalRose正是这样的一种工具。根据实现环境的不同，RationalRose有支持不同语言的add-in版本，可以支持VisualC++、VisualBasic、SmallTalk、Ada、Java、Oracle8等。并且可以适用于Windows系列等多个平台。RationalRose详细描述系统的内容和工作方法，包括许多不同的框图，使小项目组成员（包括客户、设计人员、项目经理、测试人员等）可以从不同的角度观察系统，例如客户和项目管理员用用例图确定项目范围项目管理员用用例图和文档将项目分解成可管理的小块分析人员和开发人员用顺序图和协作图了解系统的逻辑流程、系统中的队象及对象间的消息开发人员用类图和状态图取得系统各部分的细节及其相互关系的信息部署人员用组件图和部署图显示要创建的可执行文件、DLL文件和其他组件，以及网络上的进程和设备及其相互间的连接整个小项目小组用模型来确保代码遵循了需求，代码可以回溯到需求RationalRose是由Rational公司在Booch，Rumbaugh，Jacobson三位软件工程专家的主持下研制的面向对象的CASE（Computer-AidedSoftwareEngineering）产品，由于有三位大师及Rational公司的鼎力相助，是得RationalRose可以随着UML的改版随时更新，因此它是目前最流行、使用最广泛的CASE工具。UML简化了建模方法，它扬弃了Booch、OMT或OOSE等方法中的糟粕，而代之以其它方法中的精华。UML一般不引入新的概念和符号，只有在没有现有的解决方法可以借鉴时，UML的开发者们才考虑加入新的概念。UML的开发者们是在设计一种语言（尽管只是一种图形化语言），因此必须在简明（所有元素一律用方框和文字表示）和繁琐（为每个元素设计单独的符号）之间权衡。尽管如此，UML中还是增添了衍型和扩展机制等一些新的元素，因为这些元素在其它建模语言的实践中已经被证明是非常有用的。UML定义了5类，10种模型图五种类图定义1.用例图：从用户角度描述系统功能，并指各功能的操作者。2.静态图：包括类图，包图，对象图。类图：描述系统中类的静态结构包图：是包和类组成的，表示包与包之间的关系，包图描述系统的分层结构对象图：是类图的实例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.一个或多个终止点：内部包含实心圆的圆【