UML统一建模语言的简称,是一种标准化的建模语言,由一组集成的图表组成,开发用于帮助系统和软件开发人员指定,可视化,构建和记录软件系统的工件,以及业务建模和其他非软件系统。UML代表了一系列最佳工程实践,这些实践已被证明在大型复杂系统的建模方面取得了成功。UML是开发面向对象软件和软件开发过程中非常重要的一部分。UML主要使用图形符号来表达软件项目的设计。使用UML有助于项目团队进行沟通,探索潜在设计,并验证软件的架构设计。在本文中,我们将为您提供有关什么是UML的详细信息
UML的起源
UML的目标是提供一个标准符号,可以被所有面向对象的方法使用,并选择和集成前缀符号的最佳元素。UML专为广泛的应用而设计。因此,它为广泛的系统和活动(例如,分布式系统,分析,系统设计和部署)提供了构造。
UML是由OMT统一产生的符号
- 对象建模技术OMT [ James Rumbaugh 1991] – 最适合分析和数据密集型信息系统。
- Booch [ Grady Booch 1994] – 非常适合设计和实施。Grady Booch与Ada语言进行了广泛的合作,并且是该语言面向对象技术开发的主要参与者。尽管Booch方法很强大,但这种符号并不太受欢迎(很多云形状占据了他的模型 – 不是很整洁)
- OOSE(面向对象的软件工程[ Ivar Jacobson 1992]) – 以一个名为Use Cases的模型为特色。用例是一种强大的技术,用于理解整个系统(OO传统上一直处于弱势的区域)的行为。
1994年,OMT的创建者Jim Rumbaugh在离开通用电气公司并加入Rational公司的Grady Booch时震惊了软件世界。合作的目的是将他们的想法合并为一个统一的方法(工作标题为方法确实是“统一方法”)。
到1995年,OOSE的创建者Ivar Jacobson也加入了Rational,他的想法(特别是“用例”的概念)被纳入了新的统一方法 – 现在称为统一建模语言1。Rumbaugh,Booch和Jacobson的团队被亲切地称为“三个朋友”
UML也受到其他面向对象的符号的影响:
- Mellor和Shlaer [1998]
- Coad和Yourdon [1995]
- Wirfs-Brock [1990]
- 马丁和奥德尔[1992]
UML还包括当时其他主要方法中没有的新概念,例如扩展机制和约束语言。
UML的历史
- 在1996年期间,对象管理组织(OMG)发布的第一份提案请求(RFP)为这些组织提供了催化剂,以共同制定联合RFP响应。
- Rational与几个愿意将资源用于强大的UML 1.0定义的组织建立了UML Partners联盟。那些对UML 1.0定义贡献最大的人包括:
- 数字设备公司
- 生命值
- I-Logix的
- IntelliCorp
- IBM
- ICON计算
- MCI Systemhouse
- 微软
- 神谕
- Rational软件
- TI
- Unisys公司
- 这种合作产生了UML 1.0,这是一种定义明确,富有表现力,功能强大且通用的建模语言。这是作为最初的RFP响应于1997年1月提交给OMG的
- 1997年1月,IBM,ObjecTime,Platinum Technology,Ptech,Taskon,Reich Technologies和Softeam也向OMG提交了单独的RFP回复。这些公司加入了UML合作伙伴以贡献他们的想法,合作伙伴共同制定了修订后的UML 1.1响应。UML 1.1版本的重点是提高UML 1.0语义的清晰度,并纳入新合作伙伴的贡献。它被提交给OMG供他们考虑并于1997年秋季通过.1并增强了1.1到1.5,随后是从01到06的UML 2.1(现在UML当前版本是2.5)
为何选择UML
随着许多公司软件的战略价值的增加,该行业寻求自动化软件生产和提高质量,降低成本和上市时间的技术。这些技术包括组件技术,可视化编程,模式和框架。企业还在寻求管理系统复杂性的技术,因为它们的范围和规模都在增加。特别是,他们认识到需要解决重复出现的体系结构问题,例如物理分布,并发性,复制,安全性,负载平衡和容错。此外,万维网的开发虽然使一些事情变得更简单,但却加剧了这些架构问题。统一建模语言(UML)旨在满足这些需求。
- 为用户提供即用型,富有表现力的可视化建模语言,以便他们可以开发和交换有意义的模型。
- 提供可扩展性和专业化机制以扩展核心概念。
- 独立于特定的编程语言和开发过程。
- 为理解建模语言提供正式的基础。
- 鼓励OO工具市场的增长。
- 支持更高级别的开发概念,例如协作,框架,模式和组件。
- 整合最佳实践。
UML – 概述
在我们开始研究UML理论之前,我们将简要介绍一下UML的一些主要概念。
关于UML首先要注意的是,有许多不同的图(模型)需要习惯。这样做的原因是可以从许多不同的观点来看待系统。软件开发将使许多利益相关者发挥作用。
例如:
- 分析师
- 设计师
- 编码器
- 测试仪
- QA
- 客户
- 技术作者
所有这些人都对系统的不同方面感兴趣,并且每个方面都需要不同级别的细节。例如,编码人员需要了解系统的设计,并能够将设计转换为低级代码。相比之下,技术作者对整个系统的行为感兴趣,需要了解产品的功能。UML试图提供一种如此富有表现力的语言,以便所有利益相关者都能从至少一个UML图中受益。
以下是UML 2 Diagram Structure中所示的这13个图中的每一个的快速浏览:
结构图显示了系统的静态结构及其在不同抽象和实现级别上的部分以及它们如何相互关联。结构图中的元素表示系统的有意义概念,可能包括抽象,现实世界和实现概念,结构图有七种类型如下:
行为图显示了系统中对象的动态行为,可以描述为系统随时间的一系列变化,有七种类型的行为图如下:
什么是类图?
类图是一种中心建模技术,几乎贯穿所有面向对象的方法。该图描述了系统中对象的类型以及它们之间存在的各种静态关系。
关系
有三种主要的关系是重要的:
- 关联 – 表示类型实例之间的关系(一个人为公司工作,公司有多个办公室。
- 继承 – 在OO中使用的ER图最明显的补充。它与OO设计中的继承有直接对应关系。
- 聚合 – 聚合,面向对象设计中的一种对象组合形式。
类图示例
有关类图的更多详细信息,请阅读文章什么是类图?
什么是组件图?
在统一建模语言中,组件图描绘了组件如何连接在一起以形成更大的组件或软件系统。它说明了软件组件的体系结构以及它们之间的依赖关系。那些软件组件包括运行时组件,可执行组件也是源代码组件。
组件图示例
有关组件图的更多详细信息,请阅读文章什么是组件图?
什么是部署图?
部署图有助于为面向对象的软件系统的物理方面建模。它是一个结构图,显示了系统的体系结构,作为部署目标的软件工件的部署(分发)。工件代表物理世界中作为开发过程结果的具体元素。它在静态视图中对运行时配置进行建模,并可视化应用程序中工件的分布。在大多数情况下,它涉及对硬件配置和生存的软件组件进行建模。
部署图示例
有关部署图的更多详细信息,请阅读文章什么是部署图?
什么是对象图?
对象图是实例的图形,包括对象和数据值。静态对象图是类图的实例; 它显示了某个时间点系统详细状态的快照。不同之处在于,类图表示由类及其关系组成的抽象模型。然而,对象图表示特定时刻的实例,其本质上是具体的。对象图的使用相当有限,即显示数据结构的示例。
类图与对象图 – 一个例子
有些人可能会发现难以理解UML类图和UML对象图之间的区别,因为它们都包含名为“矩形块”,其中包含属性,并且两者之间具有链接,这使得两个UML图看起来相似。有些人甚至认为它们是相同的,因为在UML工具中它们使用类图和对象图的符号都放在同一个图编辑器 – 类图中。
但实际上,类图和对象图代表了代码库的两个不同方面。在本文中,我们将为您提供有关这两个UML图表的一些想法,它们是什么,它们的区别是什么以及何时使用它们。
类图与对象图的关系
您在编程时创建“类”。例如,在网上银行系统中,您可以创建“用户”,“帐户”,“交易”等类。在课堂管理系统中,您可以创建“教师”,“学生”,“作业”等课程。在每个类中,都有表示类的特征和行为的属性和操作。类图是一个UML图,您可以在其中可视化这些类及其属性,操作和相互关系。
UML对象图显示了系统中的对象实例如何在特定状态下相互交互。它还表示该状态下那些对象的数据值。换句话说,UML对象图可以看作是如何在特定状态下使用类(在UML类图中绘制)的表示。
如果您不喜欢这些定义内容,请查看以下UML图示例。我相信你会在几秒钟内理解他们之间的差异。
类图示例
以下类图示例表示两个类 – 用户和附件。用户可以上传多个附件,因此这两个类与一个关联相关联,在附件一侧使用0 … *作为多重性。
对象图示例
以下对象图示例显示了当Peter(即用户)尝试上载两个附件时,User和Attachment类的对象实例如何“看起来像”。因此,要上载的两个附件对象有两个实例规范。
有关对象图的更多详细信息,请阅读文章什么是对象图?
什么是封装图?
包图是UML结构图,显示包之间的包和依赖关系。模型图允许显示系统的不同视图,例如,作为多层(也称为多层)应用程序 – 多层应用程序模型。
包图示例
有关Package Diagram的更多详细信息,请阅读文章什么是Package Diagram?
什么是复合结构图?
复合结构图是添加到UML 2.0的新工件之一。复合结构图类似于类图,是一种主要用于在微观视点下对系统进行建模的组件图,但它描绘的是单个部分而不是整个类。它是一种静态结构图,显示了类的内部结构以及此结构使其可以实现的协作。
该图可以包括内部部件,部件通过其彼此交互的端口,或者类的实例通过其与部件和外部世界交互,以及部件或端口之间的连接器。复合结构是一组互连的元素,它们在运行时协作以实现某些目的。每个元素在协作中都有一些定义的角色。
复合结构图示例
有关复合结构图的更多详细信息,请阅读文章什么是复合结构图?
什么是个人资料图?
通过配置文件图,您可以创建特定于域和平台的构造型,并定义它们之间的关系。您可以通过绘制构造型形状来创建构造型,并通过以资源为中心的界面将它们与构图或概括相关联。您还可以定义和可视化构造型的标记值。
剖面图示例
有关Profile Diagram的更多详细信息,请阅读文章什么是UML中的Profile Diagram?
什么是用例图?
用例模型描述了系统在用例方面的功能需求。它是系统预期功能(用例)及其环境(参与者)的模型。使用案例使您能够将系统所需的内容与系统如何满足这些需求相关联。
将用例模型视为菜单,就像您在餐厅中找到的菜单一样。通过查看菜单,您可以了解可用的菜肴,个别菜肴以及价格。您还知道餐厅提供的菜肴:意大利菜,墨西哥菜,中餐菜等。通过查看菜单,您可以全面了解该餐厅等待您的用餐体验。菜单实际上是“模仿”餐厅的行为。
由于它是一种非常强大的规划工具,因此所有团队成员通常在开发周期的所有阶段使用用例模型。
用例图示例
有关用例图的更多详细信息,请阅读文章什么是用例图?
什么是活动图?
活动图是逐步活动和动作的工作流的图形表示,支持选择,迭代和并发。它描述了目标系统的控制流程,例如探索复杂的业务规则和操作,描述用例以及业务流程。在统一建模语言中,活动图旨在模拟计算和组织过程(即工作流程)。
活动图示例
有关活动图的更多详细信息,请阅读文章什么是活动图?
什么是状态机图?
状态图是UML中用于描述系统行为的一种图表,它基于David Harel的状态图概念。状态图描绘了允许的状态和转换以及影响这些转换的事件。它有助于可视化对象的整个生命周期,从而有助于更好地理解基于状态的系统。
状态机图示例
有关状态机图的更多详细信息,请阅读文章什么是状态机图?
什么是序列图?
序列图根据时间顺序对对象的协作进行建模。它显示了对象在特定用例场景中如何与其他对象进行交互。借助先进的可视化建模功能,您只需点击几下即可创建复杂的序列图。此外,一些建模工具(如Visual Paradigm)可以根据您在用例描述中定义的事件流生成序列图。
序列图示例
有关序列图的更多详细信息,请阅读文章什么是序列图?
什么是通信图?
与序列图类似,通信图也用于模拟用例的动态行为。与序列图比较时,通信图更侧重于显示对象的协作而不是时间序列。它们实际上在语义上是等价的,因此一些建模工具(如Visual Paradigm)允许您从一个到另一个生成它。
通信图示例
有关通信图的更多详细信息,请阅读文章什么是通信图?
什么是交互概述图?
交互概述图侧重于交互控制流的概述。它是活动图的变体,其中节点是交互或交互事件。交互概述图描述了隐藏消息和生命线的交互。您可以链接“真实”图表,并在交互概览图中的图表之间实现高度可导航性。
交互概述图示例
有关交互概述图的更多详细信息,请阅读文章什么是交互概述图?
什么是时序图?
时序图显示了在给定时间段内对象的行为。时序图是序列图的一种特殊形式。时序图和顺序图之间的差异是轴被反转,因此时间从左到右增加,生命线显示在垂直排列的独立隔间中。
时序图示例
有关时序图的更多详细信息,请阅读文章什么是时序图?
学习UML。绘制UML。
获取Visual Paradigm Community Edition,这是一款免费的UML工具,可以帮助您更快,更有效地学习UML。Visual Paradigm Community Edition支持所有UML图表类型。它的UML建模器屡获殊荣,易于使用且直观。
UML术语表和术语
- 抽象类 – 永远不会被实例化的类。这个类的实例永远不会存在。
- Actor – 启动系统所涉及事件的对象或人员。
- 活动:活动图中的步骤或操作。表示系统或Actor采取的操作。
- 活动图:一个美化的流程图,显示流程中的步骤和决策以及并行操作,例如算法或业务流程。
- 聚合 – 是另一个类的一部分。在图表中包含类的旁边显示空心菱形。
- 工件 – 描述设计过程中步骤输出的文档。描述是图形,文本或某种组合。
- 关联 – 模型的两个元素之间的连接。这可能代表代码中的成员变量,或人事记录与其代表的人之间的关联,或两类工人之间的关系,或任何类似的关系。默认情况下,关联中的两个元素都是相同的,并且通过关联彼此了解。关联也可以是可导航关联,意味着关联的源端知道目标端,但反之亦然。
- 关联类:在两个其他类之间表示关联并向其添加信息的类。
- 属性 – 可用于引用其他对象或保存对象状态信息的对象的特征。
- 基类:定义由子类通过泛化关系继承的属性和操作的类。
- 分支:活动图中的决策点。分支中出现多个转换,每个转换都具有保护条件。当控制到达分支时,恰好一个Guard条件必须为真; 和控制遵循相应的过渡。
- 类:类似对象的类别,全部由相同的属性和操作描述,并且所有与赋值兼容。
- 类图 – 显示系统类和它们之间的关系。
- 分类器:具有属性和操作的UML元素。具体来说,是Actors,Classes和Interfaces。
- 协作:通信图中两个对象之间的关系,表示消息可以在对象之间来回传递。
- 通信图 – 显示在强调对象角色的同时如何完成操作的图表。
- 组件:系统中可部署的代码单元。
- 组件图:显示各种组件和接口之间关系的图表。
- 概念 – 要包含在域模型中的名词或抽象概念。
- 构建阶段 – Rational Unified Process的第三阶段,在此阶段,将在构建的系统中构建多个功能迭代。这是主要工作的地方。
- 依赖性:指示一个分类器知道另一个分类器的属性和操作但不直接连接到第二个分类器的任何实例的关系。
- 部署图:显示各种处理器之间关系的图表。
- 域 – 系统所涉及的Universe的一部分。
- 精化阶段 – Rational Unified Process的第二阶段,允许进行额外的项目规划,包括构建阶段的迭代。
- 元素:模型中显示的任何项目。
- 封装 – 对象中的数据是私有的。
- 泛化 – 表示一个类是另一个类(超类)的子类。空心箭头指向超类。
- 事件:在状态图中,这表示导致系统采取操作或切换状态的信号或事件或输入。
- 最终状态:在状态图或活动图中,这表示图完成的点。
- Fork:活动图中的一个点,其中有多个并行控制线程开始。
- 泛化:一种继承关系,其中子类继承并添加到基类的属性和操作。
- GoF – Gang of Four四种设计模式。
- 高凝聚力 – GRASP评估模式,确保课程不太复杂,做不相关的功能。
- 低耦合 – 一种GRASP评估模式,用于衡量一个类依赖另一个类或连接到另一个类的程度。
- 初始阶段 – Rational Unified Process的第一阶段,处理原始概念化和项目的开始。
- 继承 – 子类继承其父(超类)类的属性或特征。可以在子类中重写这些属性。
- 初始状态:在状态图或活动图中,这表示图表开始的点。
- 实例 – 类像模板一样用于创建对象。此对象称为类的实例。可以创建任意数量的类实例。
- 接口:定义构成行为契约的属性和操作的分类器。提供者类或组件可以选择实现接口(即,实现其属性和操作)。然后,客户端类或组件可以依赖于接口,因此使用提供者而不提供提供者的真实类的任何细节。
- 迭代 – 一个迷你项目部分,其中一些小功能被添加到项目中。包括分析,设计和编码的开发循环。
- Join:活动图中的一个点,其中多个并行控制线程同步并重新加入。
- 成员:分类器中的属性或操作。
- 合并:活动图中的一个点,其中不同的控制路径汇集在一起。
- 消息 – 从一个对象到另一个对象的请求,要求接收消息的对象执行某些操作。这基本上是对接收对象中的方法的调用。
- 方法 – 对象中的函数或过程。
- 模型 – 中央UML工件。由包括层次结构排列的各种元素组成,元素之间也有关系。
- 多重性 – 显示在域模型中并在外部概念框中指示,它表示与其他对象的分位数的对象数量关系。
- 导航:指示关系的哪一端知道另一端。关系可以具有双向导航性(每端都知道另一端)或单向导航(一端知道另一端,但反之亦然)。
- 表示法 – 带有创建分析和设计方法规则的图形文档。
- 注意:文本注释添加到图表中以更详细地解释图表。
- 对象 – 对象:在活动图中,一个从活动接收信息或向活动提供信息的对象。在协作图或序列图中,参与图中描述的场景的对象。通常:给定分类器(Actor,Class或Interface)的一个实例或示例。
- 包 – 逻辑上应该组合在一起的一组UML元素。
- 包图:一个类图,其中所有元素都是包和依赖关系。
- 模式 – 用于确定对象交互的责任分配的解决方案。它是成功解决众所周知的常见问题的名称。
- 参数:操作的参数。
- 多态性 – 相同的信息,不同的方法。也用作图案。
- 专用:应用于属性或操作的可见性级别,指示只有包含该成员的分类器的代码才能访问该成员。
- 处理器:在部署图中,这表示可以部署代码的计算机或其他可编程设备。
- 受保护:应用于属性或操作的可见性级别,表示只有包含该成员或其子类的分类器的代码才能访问该成员。
- 公共:应用于属性或操作的可见性级别,指示任何代码都可以访问该成员。
- 读取方向箭头 – 指示域模型中关系的方向。
- 实现:表示组件或类提供给定的接口。
- 角色 – 在域模型中使用,它是关于角色角色的可选描述。
- 序列图:一个图表,显示随时间变化的对象的存在,以及随着时间的推移在这些对象之间传递的消息,以执行某些行为。状态图表 – 显示所有可能的对象状态的图表。
- 状态:在状态图中,它表示系统或子系统的一种状态:它在某个时间点正在做什么,以及它的数据值。
- 状态图:显示系统或子系统的状态,状态之间的转换以及导致转换的事件的图表。
- 静态:属性的修饰符,表示在分类器的所有实例之间只共享了一个属性副本。操作的修饰符,用于指示操作独立且不在分类器的特定实例上操作。
- Stereotype:应用于Model元素的修饰符,表示通常无法用UML表示的某些内容。从本质上讲,刻板印象允许您定义自己的UML“方言”。
- 子类:继承通过泛化关系由子类定义的属性和操作的类。
- Swimlane:活动图的一个元素,指示系统或域的哪些部分执行特定活动。Swimlane中的所有活动都是由Swimlane代表的Object,Component或Actor的责任。
- 时间拳击 – 每次迭代都有一个具有特定目标的时间限制。
- 转换:在活动图中,表示从一个活动或分支或合并或分支或加入到另一个的控制流。在状态图中,表示从一个状态到另一个状态的变化。
- 过渡阶段 – Rational Unified Process的最后阶段,在此阶段,用户接受使用新系统的培训,系统可供用户使用。
- UML – 统一建模语言通过允许对象之间更紧密的关系,利用文本和图形文档来增强软件项目的分析和设计。
- 用例:在用例图中,表示系统响应来自Actor的某些请求而采取的操作。
- 用例图:显示Actors和Use Cases之间关系的图表。
- 可见性:属性或操作的修饰符,指示哪些代码可以访问该成员。可见性级别包括Public,Protected和Private。
- 工作流程 – 产生一些特定结果的一组活动。
流行的UML书籍
下面列出了一些您可以阅读以学习UML的最畅销的UML书籍。
- UML Distilled:标准对象建模语言简要指南
- UML 2和统一过程:实用的面向对象分析和设计
- 学习UML 2.0
- 使用UML构建Web应用程序
- 统一建模语言参考手册
- UML 2.0风格的元素
- 适用于Java程序员的UML
- Schaum的UML概述
- 统一建模语言用户指南
- UML 2认证指南:基础和中级考试
- UML中面向对象设计的基础
- 使用UML应用用例驱动对象建模:带注释的电子商务示例
- 用UML设计灵活的面向对象系统
- 使用案例驱动的对象建模与UML
- 使用UML 2.0版进行系统分析和设计:面向对象的方法
- 坚果壳中的UML 2.0
- 面向对象的分析与应用设计
- UML解释
- 设计模式:可重用面向对象软件的元素
- 对象入门:使用UML 2.0进行敏捷模型驱动开发
相关链接