UML各种图详解

合集下载

UML图(类图)各元素解释

UML图(类图)各元素解释

UML图(类图)各元素解释
普通类图
属性/⽅法的表⽰其实都是: 符号属性名/⽅法名: 返回类型
符号:+(public) 公开⽅法及属性; -(private) 私有⽅法及属性; #(protected) protected⼀样的效果属性名/⽅法名: 说⽩了就是属性名或者⽅法名的名称,如果是⽅法的话,要多个(),内容就是参数类型返回类型: ⽅法独有的,没返回值的话写voide即可,有返回值就写上相对应的返回值的类型
若要表⽰是接⼝的话, 在类名上⽅加上 <<interface>> 即可
关联类型
单向关联
单实⼼箭头实线: 说明的是A关联了B,A对象中持有B对象
双向关联
⽆箭头实线:说明是A和B对象互相关联,A持有B对象,B也持有A对象⾃关联
指向⾃⾝的单实⼼箭头:表明是A对象持有了A对象
实现接⼝
虚线空⼼箭头:说明B实现了A接⼝
泛化关系
实线空⼼箭头:说明B继承了A。

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language ™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)标准文档角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图,可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

UML类图,常用符号小计

UML类图,常用符号小计

UML类图,常用符号小计UML类图,常用符号小计1、首先看该图中的动物矩形框,它代表的是一个类,类图分三层,第一层是类名(动物),第二层是特性(通常我们说的属性或是字段),第三层是操作(通常我们说的方法或行为),注意特性和操作前面的+,“+”代表public,“-“代表private,“#”代表protected。

在这里需要注意一下,动物类的名称是斜体,这就表示该类是抽象类。

同样的鸟类也是抽象类。

2、再看左下角的飞翔,它是一个接口图,与类图的不同就在于,顶部有一个<<interface>>,第一行是接口名称,第二行是接口方法。

接口还有一种表示方法是棒棒糖表示法,如图中的唐老鸭实现讲人话的接口。

3、鸟继承自动物类,鸭继承自鸟类,唐老鸭又继承自鸭类,继承的关系用空心三角形+实线来表示。

4、大雁实现了飞行的接口,接口用虚线+空心三角来实现5、企鹅需要了解天气情况,气候的变化,那么如果一个类“知道”另一个类时,可以用关联(association)。

关联关系要用实线箭头来表示6、一个雁群可以包括很多只雁,但雁并不是雁群的一部分,像这样的关系就满足聚合(aggregation)关系,聚合是一种弱的拥有关系,体现的是A对象可以包含B对象,但B对象不是A对象的一部分。

聚合关系用空心菱形+实线表示。

7、合成(composition)是一种强的拥有关系,体现的严格的部分与整的关系,部分和整的生命周期一样。

上图中鸟和翅膀就是合成的关系,其中图中标注的1,2被称为基数。

表明这一端的类可以有多个实例,鸟肯定是两个翅膀喽,一个是没法飞的,哈哈。

8、动物与氧气、水之间是依赖的关系,没有氧气和水,动物(当然也包括人)根本是无法生存的,所以嘛。

不管是动物还是植物还是高级动物人也好,都要依赖于氧气和水的,依赖(dependency)关系,用虚线箭头来表示。

或许还有好多好多其他的常用符号,欢迎朋友们和我一起沟通。

UML中的活动图和状态图的区别与实际应用案例解析

UML中的活动图和状态图的区别与实际应用案例解析

UML中的活动图和状态图的区别与实际应用案例解析UML(Unified Modeling Language)是一种用于软件系统建模的标准化语言,它提供了一套丰富的图形符号和规范,帮助开发人员更好地理解和设计软件系统。

在UML中,活动图和状态图是两种常用的图形表示方式,用于描述系统中的活动流程和对象状态。

本文将探讨这两种图形的区别,并通过实际应用案例来解析它们的具体应用。

活动图是一种用于描述系统中活动流程的图形表示方式。

它主要由活动(Action)、控制流(Control Flow)和决策节点(Decision Node)等元素组成。

活动图可以清晰地展示系统中的各种活动以及它们之间的关系和顺序。

活动图通常用于描述业务流程、系统交互和软件系统中的算法等。

例如,在一个在线购物系统中,我们可以使用活动图来描述用户选择商品、添加到购物车、填写订单信息、确认支付等流程。

通过活动图,我们可以更好地理解和设计系统中的各个步骤,从而提高系统的可靠性和可维护性。

与活动图相比,状态图主要用于描述系统中对象的状态和状态之间的转换。

状态图由状态(State)、转移(Transition)和事件(Event)等元素组成。

状态图可以清晰地展示对象在不同状态之间的转换和触发条件。

状态图通常用于描述系统中的状态机、对象的生命周期和系统中的并发操作等。

例如,在一个自动售货机系统中,我们可以使用状态图来描述售货机的工作状态,如待机状态、售货状态和故障状态等。

通过状态图,我们可以更好地理解和设计系统中对象的状态变化,从而提高系统的可靠性和性能。

活动图和状态图在应用上有一些区别。

活动图主要用于描述系统中的活动流程,强调活动之间的顺序和关系。

它更适合于描述系统中的业务流程和交互流程等。

而状态图主要用于描述系统中对象的状态和状态之间的转换,强调对象状态的变化和触发条件。

它更适合于描述系统中的状态机和对象的行为。

下面通过一个实际应用案例来进一步解析活动图和状态图的具体应用。

UML用例图的基本概念

UML用例图的基本概念
UML通过统一的符号和图形表示,将复杂的软件系统分解为 更小、更易于理解的组件,帮助开发人员更好地理解和管理 复杂的软件系统。
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求,通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计,通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一:简单登录系统用例图分析
总结词:简单明了
详细描述:简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中,可以清晰地表示出系统的主要功能和参与者的角色。
案例二:网上购物系统用例图分析
总结词:复杂多样
详细描述:网上购物系统涉及到多个参与者,如顾客、管理员和供应商等,以及多种复杂的业务功能,如商品展示、购物车 管理、订单处理和支付等。在UML用例图中,需要对各个功能进行详细的描述和分类,以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计,通过分析用例之间 的关系和交互,设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口,明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程,通 过分析用例的执行顺序和交互逻辑, 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示,可以作为沟通 工具,帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图,可以与利益相关者讨论和确认 系统的需求,确保对需求的理解和期望是一致的。

UML中共有5种静态图

UML中共有5种静态图

UML中共有5种静态图:用例图,类图,对象图,组件图和配置图。

(1)用例图Use Case Diagram用例图展现了一组用例、参与者以及它们之间的关系可以用来描述系统的静态使用情况。

上图中小人形状的用户和ATM是参与者、椭圆形状的如插入卡、输入密码等是用例(2)类图Class Diagram类图展示了一组类、接口、子类以及他们之间的关系,在建模中最常用到的图就是类图;可以用类图说明系统的静态设计视图,包含主动类的类图。

上图中反应了5个类之间的关联关系,人民币账户和美元帐户从账户继承,账户和ATM相关联,两种账户和用户相关联(3)对象图Object Diagram对象图展示了一组对象和他们间的关系,可以用来说明类图中翻译的事物实例的数据结构和静态快照,表达了系统的静态设计视图和静态过程视图,除了显示和原型方面的因素外,它与类图的作用是相同的。

(4)组件图Component Diagram组件图,又名构件图,展现了一组组件之间的组织和依赖,用于对源代码、可执行的发布、物理数据库和可调整的系统建模。

上图中组件1和组件3依赖于组件2(5)配置图Deployment Diagram配置图展现了对运行时处理节点以及其中组件的配属,它描述系统硬件的物理拓扑结构,以及在此结构上执行的软件。

用配置图说明系统结构的静态配置视图,即说明分布、交互和安装的物理系统。

上图中,三个处理机与两个涉笔,相互之间是关联的关系UML中动态图有四种,分别是:时序图、协作图、状态图和活动图。

(1)时序图Sequence Diagram时序图展现了一组对象和由这组对象收发的信息,用于按时间顺序对控制流建模。

可以用时序图来说明系统的动态视图。

这里貌似有不同的说法Visual Paradigm里面叫时序图为Timing Diagram,而我参照的教材里边没有这种图,按理说是应该有的。

上图反应了用户与ATM交互的整个过程。

(2)协作图Collaboration Diagram协作图展现了一组对象之间的链接以及这组对象收发的消息,强调收发消息对象的组织结构,按组织结构对控制流建模。

UML序列图总结

UML序列图总结

UML序列图总结序列图主要用于展示对象之间交互的顺序。

序列图将交互关系表示为一个二维图。

纵向是时间轴,时间沿竖线向下延伸。

横向轴代表了在协作中各独立对象的类元角色。

类元角色用生命线表示。

当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。

箭头以时间顺序在图中从上到下排列。

序列图中涉及的元素:1.生命线:生命线名称可带下划线。

当使用下划线时,意味着序列图中的生命线代表一个类的特定实体。

2.同步消息发送人在它继续之前,将等待同步消息响应3.异步消息在发送方继续之前,无需等待响应的消息4.注释5.约束约束的符号很简单;格式是: [Boolean Test]6.组合片段组合片段用来解决交互执行的条件及方式。

它允许在序列图中直接表示逻辑组件,用于通过指定条件或子进程的应用区域,为任何生命线的任何部分定义特殊条件和子进程。

常用的组合片段有:a.抉择(Alt)抉择用来指明在两个或更多的消息序列之间的互斥的选择,相当于经典的if..else..。

抉择在任何场合下只发生一个序列。

可以在每个片段中设置一个临界来指示该片段可以运行的条件。

else的临界指示其他任何临界都不为True 时应运行的片段。

如果所有临界都为False 并且没有else,则不执行任何片段。

b.选项(Opt)包含一个可能发生或不发生的序列c.循环(Loop)片段重复一定次数。

可以在临界中指示片段重复的条件。

d.并行(Par)下表列出了常用的组合片段:。

UML活动图的图形表示与常用符号解析

UML活动图的图形表示与常用符号解析

UML活动图的图形表示与常用符号解析在软件开发过程中,UML(统一建模语言)活动图是一种常用的工具,用于描述系统中的业务流程和操作步骤。

活动图以图形的形式展示了系统中的各个活动和它们之间的关系,使得开发人员能够更清晰地理解和设计系统的行为。

本文将对UML活动图的图形表示和常用符号进行解析。

1. 活动节点(Activity Node)活动节点是活动图中的基本元素,用于表示系统中的各个活动或操作步骤。

活动节点可以是一个动作(Action),如发送邮件、保存数据等;也可以是一个控制节点(Control Node),如判断条件、循环等。

活动节点通常用矩形表示,矩形内部写明活动的名称。

2. 控制流(Control Flow)控制流用于表示活动之间的顺序关系,即一个活动的执行是否依赖于另一个活动的完成。

控制流通常用带箭头的直线表示,箭头指向下一个活动节点。

例如,如果活动A的完成依赖于活动B的完成,则可以用控制流连接这两个活动节点。

3. 分支(Decision)分支用于表示系统中的决策点,即根据不同的条件选择不同的活动路径。

分支通常用菱形表示,菱形内部写明条件表达式。

从分支出发的控制流可以有多个,分别指向不同的活动节点。

4. 合并(Merge)合并用于表示系统中的合并点,即多个活动路径汇合成一个路径。

合并通常用菱形表示,与分支相反,合并节点的控制流可以有多个,分别来自不同的活动节点。

5. 并发(Fork和Join)并发用于表示系统中的并行执行,即多个活动可以同时进行。

并发通常用带有多个连续箭头的竖线表示。

Fork表示并发的起点,Join表示并发的终点。

例如,如果系统中有两个活动A和B需要并行执行,可以使用Fork将控制流分成两条,分别指向A和B,然后使用Join将两条控制流合并。

6. 异常处理(Exception Handler)异常处理用于表示系统中的异常情况处理,即在某个活动节点发生异常时,系统如何处理。

UML中数据流图介绍

UML中数据流图介绍

·单向关联在一个单向关联中,两个类是相关的,但是只有一个类知道这种联系的存在。

一个单向的关联,表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形,用于标志继承)的实线。

如同标准关联,单向关联包括一个角色名和一个多重值描述,但是与标准的双向关联不同的时,单向关联只包含已知类的角色名和多重值描述。

简单的说就是OverdrawAccountReport中包含了BankAccount属性,而BankAccount中不需要包含OverdrawnAccountsReport对象6.聚合的表示:聚合是一种特别类型的关联,用于描述“总体到局部”的关系。

在基本的聚合关系中,部分类的生命周期独立于整体类的生命周期。

举例来说,我们可以想象,车是一个整体实体,而车轮轮胎是整辆车的一部分。

轮胎可以在安置到车时的前几个星期被制造,并放置于仓库中。

在这个实例中,Wheel类实例清楚地独立于Car类实例而存在。

然而,有些情况下,部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。

举例来说,考虑公司与部门的关系。

公司和部门都建模成类,在公司存在之前,部门不能存在。

这里Department类的实例依赖于Company类的实例而存在。

让我们更进一步探讨基本聚合和组合聚合。

注意:聚合与普通的关联的区别在于:普通的关联可能只是一个简单的“包含、引用”关系,关联和被关联类之间在逻辑概念上不一定有紧密的联系,而聚合则不同,它表示的是一种内在关系紧密,相互依存,相互包含的概念,其中的一部分是构成另外一部分的不可或缺的成分。

·基本聚合有聚合关系的关联指出,某个类是另外某个类的一部分。

在一个聚合关系中,子类实例可以比父类存在更长的时间。

为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。

图中清楚的表明了类Car对象包含了另一类Wheel的4个实例,这两者在概念上是密不可分的,其中的一个类是另一个类的构成成分。

13种uml简介、工具及示例

13种uml简介、工具及示例

13种uml简介、工具及示例UML(Unified Modeling Language)是一种用于软件开发的标准化建模语言,它使用图形表示法来描述软件系统的不同方面。

在软件开发过程中,使用UML可以帮助开发人员更清晰地理解系统的结构和行为,从而更好地进行设计和实现。

UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式,其中每种模型都有各自的符号和语法规则。

通过使用这些模型,开发人员可以将系统分解成不同的部分,然后逐步细化这些部分的设计,以便更好地组织和管理项目。

在UML中,最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。

每种图表都有其特定的用途和表达能力,开发人员可以根据实际需要选择合适的图表进行建模。

除了建模元素外,UML还定义了一系列的建模工具,这些工具可以帮助开发人员更高效地进行建模和分析。

其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。

下面将对13种UML简介、工具及示例进行详细介绍:1. 用例图(Use Case Diagram)用例图是UML中描述系统功能和用户交互的基本图表之一。

它用椭圆表示用例,用直线连接用例和参与者,展示了系统外部用户和系统之间的交互。

用例图可以帮助开发人员更清晰地理解系统的功能需求,从而指导系统的设计和实现。

示例:一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等,以及参与者“顾客”和“管理员”。

2. 类图(Class Diagram)类图是UML中描述系统结构和静态关系的基本图表之一。

它用矩形表示类,用线连接类之间的关系,包括关联关系、聚合关系、继承关系等。

类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系,从而支持系统的设计和重构。

示例:一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等,以及它们之间的关系如“选修”、“授课”等。

2.设计模式常用的UML图分析(用例图、类图与时序图)

2.设计模式常用的UML图分析(用例图、类图与时序图)

2.设计模式常⽤的UML图分析(⽤例图、类图与时序图)1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。

2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况,⽤于建⽴需求模型。

⽤例特征保证⽤例能够正确捕捉功能性需求,判断⽤例是否准确的依据。

1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中,参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务,于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中,⼀个实际⽤户可能对应系统的多个参与者。

不同⾓⾊也可以只对应⼀个参与者,从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。

系统的功能由系统单元所提供,并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。

系统单元⽤椭圆表⽰,椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信,任何⼀⽅都可发送或接受消息。

箭头指向:指向消息接收⽅:⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系,⼦⽤例和⽗⽤例相似,但表现出更特别的⾏为;⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为,也可以重载它。

⽗⽤例通常是抽象。

箭头指向:指向⽗⽤例2-类图描述系统中的类,以及各个类之间的关系的静态试图。

表⽰类、接⼝以及它们之间的协作关系,⽤于程序设计阶段。

注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝,则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图,类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性,则每⼀个属性都必须有⼀个名字,另外还可以有其它的描述信息,如可见性、数据类型、缺省值等2. 操作:如果有操作,则每⼀个操作也都有⼀个名字,其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类,则⼈类类中应包含头类及⾝体类这两个属性,则⼈类类与头类和⾝体的关系即为组合关系。

UML 类图详解

UML 类图详解

UML类图在UML的静态机制中类图是一个重点,它不但是设计人员关心的核心,更是实现人员关注的核心。

建模工具也主要根据类图来产生代码。

类图在UML的9个图中占据了一个相当重要的地位。

James Rumbaugh对类的定义是:类是具有相似结构、行为和关系的一组对象的描述符。

类是面向对象系统中最重要的构造块。

类图显示了一组类、接口、协作以及他们之间的关系。

在UML中问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。

类加上他们之间的关系就构成了类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例。

接口在类图中通过版型来表示<<interfac e>>,下面的介绍将主要介绍类,接口和类类似。

A. 类的UML表示类的命名尽量应用领域中的术语,应明确、无岐义,以利于相互交流和理解。

类的属性、操作中的可见性使用+、#、-分别表示public、protected、private。

B.类之间的关系类之间的关系是类图中比较复杂的内容。

有关联、聚合、组合、范化、依赖。

关联:是模型元素之间的一种语义联系,是类之间的一种很弱的联系。

关联可以有方向,可以是单向关联,也可以是双向关联。

可以给关联加上关联名来描述关联的作用。

关联两端的类也可以以某种角色参与关联,角色可以具有多重性,表示可以有多少个对象参与关联。

可以通过关联类进一步描述关联的属性、操作以及其他信息。

关联类通过一条虚线与关联连接。

对于关联可以加上一些约束,以加强关联的含义。

如下图所示:聚合是一种特殊的关联,聚合表示整体与部分的关系。

通常在定义一个整体类后,再去分析这个整体类的组成结构。

从而找出一些组成类,该整体类和组成类之间就形成了聚合关系。

例如舰队是由一系列的舰船组成。

需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。

组合也是一种特殊的关联,也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。

UML各种图画法总结

UML各种图画法总结

一.用例图用例模型是把应满足用户需求的基本功能(集) 聚合起来表示的强大工具。

用例模型的基本组成部件是用例角色和系统。

引入用例的主要目的是:确定系统应具备哪些功能这些功能是否满足系统的需求开发者与用户协商达成共识的东西为系统的功能提供清晰一致的描述,以便为后续的开发工作打下良好的交流基础,方便开发人员传递需求的功能为系统验证工作打下基础通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致保证系统的实用性从需求的功能用例出发提供跟踪进入系统中具体实现的类和方法检查其是否正确的能力特别是为复杂系统建模时常用用例模型构造系统的简化版本(也就是精化系统的变化和扩展能力使系统不要过于复杂)然后利用该用例模型跟踪对系统的设计和实现有影响的用例简化版本构造正确之后通过扩展完成复杂系统的建模图示用例图时既要画出三种模型元素,同时还要画出元素之间的各种关系(通用化关联依赖)用例代表的是一个完整的功能。

如何发现用例实际上从识别角色起发现用例的过程就已经已开始了对于已识别的角色通过询问下列问题就可发现用例●角色需要从系统中获得哪种功能角色需要做什么●角色需要读取产生删除修改或存储系统中的某种信息吗●系统中发生的事件需要通知角色吗或者角色需要通知系统某件事吗这些事件功能能干些什么●如果用系统的新功能处理角色的日常工作是简单化了还是提高了工作效率●还有一些与当前角色可能无关的问题也能帮助建模者发现用例例如●系统需要的输入/输出是什么信息这些输入/输出信息从哪儿来到哪儿去●系统当前的这种实现方法要解决的问题是什么也许是用自动系统代替手工操作UML 中的用例UML 中的用例用椭圆形表示用例的名字写在椭圆的内部或下方用例位于系统边界的内部角色与用例之间的关联关系或通信关联关系用一条直线表示用例和角色之间有连接关系用例和角色之间的关系属于关联association 又称作通信关联communication association,这种关联表明哪种角色能与该用例通信,关联关系是双向的一对一关系,即角色可以与用例通信,用例也可以与角色通信。

UML各种图总结-精华

UML各种图总结-精华

UML各种图总结-精华UML(UnifiedModelingLanguage)是一种统一建模语言,为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。

一、基本概念如下图所示,UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图,又可以静动分为静态视图和动态视图。

静态图分为:用例图,类图,对象图,包图,构件图,部署图。

动态图分为:状态图,活动图,协作图,序列图。

1、用例图(UseCaseDiagrams):用例图主要回答了两个问题:1、是谁用软件。

2、软件的功能。

从用户的角度描述了系统的功能,并指出各个功能的执行者,强调用户的使用者,系统为执行者完成哪些功能。

2、类图(ClassDiagrams):用户根据用例图抽象成类,描述类的内部结构和类与类之间的关系,是一种静态结构图。

在UML类图中,常见的有以下几种关系:泛化(Generalization),实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)。

各种关系的强弱顺序:泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何继承父类的所有特征和行为。

例如:老虎是动物的一种,即有老虎的特性也有动物的共性。

2.2.实现【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现。

2.3.关联【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。

双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。

【代码体现】:成员变量2.4.聚合【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。

UML 10 种图的总结

UML 10 种图的总结

UML 2.0共有10种图,分别为表示系统静态结构的静态模型(包括类图、组合结构图、部署图),以及表示系统动态结构的动态模型(包括用例图、序列图、对象图、协作图、状态图、活动图、组件图),它们各用以表现不同的视图,如表1-1所示。

用例之间也可以存在包含、扩展和泛化等关系:
(1)包含关系:用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为做为自身行为的一部分,这被称作包含关系。

(2)扩展关系:扩展关系是从扩展用例到基本用例的关系,它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。

它是以隐含形式插入的,也就是说,扩展用例并不在基本用例中显示。

在以下几种情况下,可使用扩展用例:
a.表明用例的某一部分是可选的系统行为(这样,您就可以将模型中的可选行为和必选行为分开);
b.表明只在特定条件(如例外条件)下才执行的分支流;
c.表明可能有一组行为段,其中的一个或多个段可以在基本用例中的扩展点处插入。

所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

(3)泛化关系:用例可以被特别列举为一个或多个子用例,这被称做用例泛化。

当父用例能够被使用时,任何子用例也可以被使用。

如在图2.4中,订票是电话订票和网上订票的抽象。

uml的十三种图形

uml的十三种图形

uml的⼗三种图形
1.⽤例图:对系统的使⽤⽅式分类.
2.类图:显⽰类和它们的相互关系。

3。

对象图:只显⽰对象及它们的相互关系。

4。

活动图:显⽰⼈或对象的活动,其⽅式类似于流程图。

5。

状态机图:显⽰⽣命周期⽐较有趣或复杂的对象的各种状态。

6。

通信图:显⽰在某种情形下对象之间发送的消息。

7。

顺序图:显⽰与通信图类以的信息,但强调的是顺序,⽽不是连接。

8。

包图:显⽰相关的类如何组合,对开发⼈员有⽤。

9。

部署图:显⽰安装已完成系统的机器、过程和部署制品。

10。

组件图显⽰可重⽤的组件(对象或⼦系统)及期接⼝。

11。

交互总图:使⽤顺序图喧⾚活动的务个步骤。

12。

时间图:显⽰消息和对象状态的准确时间限制。

13。

复合结构图:显⽰对象在聚合或复合中的相互关系,显⽰接⼝和协作的对象。

各种图(流程图,思维导图,UML,拓扑图,ER图)简介概要

各种图(流程图,思维导图,UML,拓扑图,ER图)简介概要

各种图(流程图,思维导图,UML,拓扑图,ER图)简介流程图1.定义:流程图是对过程、算法、流程的一种图像表示,在技术设计、交流及商业简报等领域有广泛的应用。

2.案例3.计算机语言只是一种工具。

光学习语言的规则还不够,最重要的是学会针对各种类型的问题,拟定出有效的解决方法和步骤即算法。

有了正确而有效的算法,可以利用任何一种计算机高级语言编写程序,使计算机进行工作。

因此,设计算法是程序设计的核心。

对同一个问题,可以有不同的解题方法和步骤。

例如,求1+2+3+…+100,可以先进行1+2,再加3,再加4,一直加到100,也可采取100+(1+99)+(2+98)+…+(49+51)+50=100+50+49×100=5050。

还可以有其它的方法。

当然,方法有优劣之分。

有的方法只需进行很少的步骤,而有些方法则需要较多的步骤。

一般说,希望采用方法简单,运算步骤少的方法。

因此,为了有效地进行解题,不仅需要保证算法正确,还要考虑算法的质量,选择合适的算法。

一个计算问题的解决过程通常包含下面几步:a.确立所需解决的问题以及最后应达到的要求。

必须保证在任务一开始就对它有详细而确切的了解,避免模棱两可和含混不清之处。

b.分析问题构造模型。

在得到一个基本的物理模型后,用数学语言描述它,例如列出解题的数学公式或联立方程式,即建立数学模型。

c.选择计算方法。

如定积分求值问题,可以用矩形法、梯形法或辛普生法等不同的方法。

因此用计算机解题应当先确定用哪一种方法来计算。

专门有一门学科“计算方法”,就是研究用什么方法最有效、最近似地实现各种数值计算的,换句话说,计算方法是研究数值计算的近似方法的。

d.确定算法和画流程图。

在编写程序之前,应当整理好思路,设想好一步一步怎样运算或处理,即为“算法”。

把它用框图画出来,用一个框表示要完成的一个或几个步骤,它表示工作的流程,称为流程图。

它能使人们思路清楚,减少编写程序中的错误。

[UML]UML系列——状态机图statechartdiagram

[UML]UML系列——状态机图statechartdiagram

[UML]UML系列——状态机图statechartdiagram系列⽂章引⾔状态机图和顺序图、通信图有哪些区别?顺序图、通信图:描述多个对象间的交互状态机图:描述单个对象的状态及引起状态变化的原因实例分析:⼤学⽣学籍管理系统按国家招⽣规定录取的新⽣,持录取通知书,按学校有关要求和规定的期限到校办理⼊学⼿续。

因故不能按期⼊学者,应当向学校请假,假期⼀般不得超过2周。

未请假、请假未准或者请假逾期者,除因不可抗⼒等正当事由意外,视为放弃⼊学资格。

新⽣⼊学后,学校在三个⽉内按照国家招⽣规定对其进⾏复查。

复查合格者予以注册,取得学籍。

复查不合格者,学校区别情况予以处理,直⾄取消⼊学资格。

......学⽣有如下情况之⼀者,应予休学:(⼀)因伤病经学校指定医院诊断,须停课治疗、休养⼀学期1/3时间;(⼆)⼀学期请假缺课超过该学期总学时的1/3;(三)传染性肝炎、肺结核等传染性疾病;(四)因某种特殊原因,学校认为必须休学。

.....学⽣休学⾄少⼀学期,⼀般以⼀年为限。

学⽣复学后,休学之前已记⼊成绩档案的考核成绩继续有效,并作为学籍处理依据.学⽣复学按下列规定办理:(⼀)学⽣因伤病休学申请复学时,须持有⼆级甲等以上医院诊断书,证明⾝体健康,并经学校指定医院复查合格,⽅可复学;(⼆)学⽣休学期满后应于学期的注册期内持有关证明,经教务处核准后编⼊原专业相应班级选课学习;........学⽣有下列情况之⼀者,应予退学:(⼀)学⽣在读期间,3次出现在⼀学期中取得的课程学分不⾜10学分(不含重修和补考学分;毕业学期除外;第⼀次提出警告,第⼆次提出退学警告,由教务处公布名单,院系负责通知学⽣家长);(⼆)休学、保留学籍期满,在规定期限内不办理复学⼿续;(三)休学累计满⼆年,经复查不合格;(四)因伤病需要休学,经学校动员后仍不办理休学⼿续;(五)经学校指定医院确诊患有疾病,或意外伤残⽆法继续在校学习;(六)未请假离校连续2周末参加学校规定的教学活动;(七) 超过学校规定期限未注册⽽⼜⽆正当事由;(⼋)本⼈要求退学。

UML 各种图总结精华

UML 各种图总结精华

UML 各种图总结精华UML(Unified Modeling Language)是一种统一建模语言,为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。

一、基本概念如下图所示,UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图,又可以静动分为静态视图和动态视图。

静态图分为:用例图,类图,对象图,包图,构件图,部署图。

动态图分为:状态图,活动图,协作图,序列图。

1、用例图(UseCase Diagrams):用例图主要回答了两个问题:1、是谁用软件。

2、软件的功能。

从用户的角度描述了系统的功能,并指出各个功能的执行者,强调用户的使用者,系统为执行者完成哪些功能。

2、类图(Class Diagrams):用户根据用例图抽象成类,描述类的内部结构和类与类之间的关系,是一种静态结构图。

在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)。

各种关系的强弱顺序:泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖2.1.泛化【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何继承父类的所有特征和行为。

例如:老虎是动物的一种,即有老虎的特性也有动物的共性。

2.2.实现【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现。

2.3.关联【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。

双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。

【代码体现】:成员变量2.4. 共享聚合【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

UML用例图
用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块。

展示了一个外部用户能够观察到的系统功能模型图。

用例图中涉及的关系:
1》泛化(Inheritance)
就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。

子用例可以使用父用例的一段行为,也可以重载它。

父用例通常是抽象的。

2》包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

3》扩展(Extend)
扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。

包含(include)、扩展(extend)、泛化(Inheritance)的区别:
条件性:泛化中的子用例和include中的被包含的用例会无条件发生,而extend中的延伸用例的发生是有条件的;
直接性:泛化中的子用例和extend中的延伸用例为参与者提供直接服务,而include中被包含的用例为参与者提供间接服务。

对extend而言,延伸用例并不包含基础用例的内容,基础用例也不包含延伸用例的内容。

对Inheritance而言,子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系;
UML类图
类名:如果是抽象类,则采用斜体(继承用实线)
1》接口的表示:
一个类和一个接口不同:一个类可以有它形态的真实实例,然而一个接口必须至少有一个类来实现它。

在 UML 2 中,一个接口被认为是类建模元素的特殊化。

因此,接口就象类那样绘制,但是长方形的顶部区域也有文本“interface”。

2》UML 支持的可见性类型的标志
标志可见性类型
+Public
#proteted
-private
~package
3》多重值和它们的表示
可能的多重值描述
表示含义
0..1 0个或1个
1只能1个
0..*0个或多个
* 0个或多个
1..*1个或多个
3只能3个
0..50到5个
5..15 5到15个
4》类图之间的关系有:泛化(继承),依赖,关联,聚合/组合。

1.聚合/组合
聚合是一种特别类型的关联,用于描述“总体到局部”的关系。

在基本的聚合关系中,部分类的生命周期独立于整体类的生命周期。

举例来说,我们可以想象,车是一个整体实体,而车轮轮胎是整辆车的一部分。

轮胎可以在安置到车时的前几个星期被制造,并放置于仓库中。

在这个实例中,Wheel类实例清楚地独立地Car类实例而存在。

然而,有些情况下,部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。

举例来说,考虑公司与部门的关系。

公司和部门都建模成类,在公司存在之前,部门不能存在。

这里Department类的实例依赖于pany类的实例而存在。

·基本聚合(聚合)
有聚合关系的关联指出,某个类是另外某个类的一部分。

在一个聚合关系中,子类实例可以比父类存在更长的时间。

为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。

图中清楚的表明了类Car对象包含了另一类Wheel的4个实例,这两者在概念上是密不可分的,其中的一个类是另一个类的构成成分。

菱形表示“包含”,箭头表示被包含的对象,数字4表示包含的数目。

·组合聚合(组合)
组合聚合关系是聚合关系的另一种形式,但是子类实例的生命周期依赖于父类实例的生命周期。

注意:组合关系如聚合关系一样绘制,不过这次菱形是被填充的。

2.依赖
依赖可以说是要完成C5里的所有功能,一定要有C6的方法协助才行
3.关联
可以分为单向关联,双向关联
双向关联:
C1-C2:指双方都知道对方的存在,都可以调用对方的公共属性和方法。

单向关联:
C3->C4:表示相识关系,指C3知道C4,C3可以调用C4的公共属性和方法。

没有生命期的依赖。

一般是表示为一种引用。

UML序列图
序列图的主要目的是定义事件序列,产生一些希望的输出。

重点不是消息本身,而是消息产生的顺序;不过,大多数序列图会表示一个系统的对象之间传递的什么消息,以及它们发生的顺序。

1》生命线:
生命线名称可带下划线。

当使用下划线时,意味着序列图中的生命线代表一个类的特定实例。

序列图的实例名称有下划线,而角色名称没有。

2》注释
3》约束
约束的符号很简单;格式是: [Boolean Test]
4》抉择(Alt)
抉择用来指明在两个或更多的消息序列之间的互斥的选择,相当于经典的if..else..。

5》选项(Opt)
包含一个可能发生或不发生的序列
6》循环(Loop)
片段重复一定次数。

可以在临界中指示片段重复的条件。

相关文档
最新文档