赞
踩
介绍:是一款工程设计建模软件, 跨平台、使用最便捷、直观的UML建模和CASE工具(计算机辅助软件工程)
UML:Unified Modeling Language(统一建模语言)
使用UML进行建模的作用有哪些:1方便沟通交流项目;2指导编程设计(防止遗漏、便于理解、发现错误)
Visual Paradigm for UML可以支持多种图表类型,比如:类图、例图、序列图、通信图、状态机设计图、动态图、组件图、部署图、包裹图、对象图、综合结构图、定时图、交互概述图、使用案例详细编辑器、支持使用事件案例流、生成事件案例流序列图、需求管理、需求图、文本分析、CRC卡图。
UML 规格定义了两大类UML图:结构图( structure diagrams )和行为图(behavior diagrams)
结构图( structure diagrams )
结构图从不同的抽象和实现程度上描述了一个系统和系统构建的静态结构,并且描述了他们直接是如何关联到一起的。
行为图(behavior diagrams)
行为图展示了一个系统中的对象的动态行为,它描述了一个系统中的对象如何随着时间变化而变化。
为了描述如何完成一个任务而制定的一系统活动行为以及执行顺序的例图即活动图。
用例活动图会包括以下几个个要素:开始点、活动、判断、同步以及结束点。
开始(inital)和结束状态(final)
活动(action):标示动作
控制流(control flow):链接活动
决策(decison):条件判断
合并(merge):任意一个节点到达该点都继续往下走,不管其他分支
游泳道(swimlanes):模型中存在多个对象时候使用比较适合分为水平和垂直
分岔汇合(join):所有分支都到该点时候才继续往下走,类似CountDownLatch.await后在继续往下走
分流(fork):类似fork多个线程执行放入线程池执行。
接受信号(acceptsignal)
泳道图的使用主要为了帮助分析业务时,更好地厘清层次和各层之间的边界
在软件生命周期的整个过程中,用例图是软件需求分析到软件交付的第一步,用例图的主要目的是说明这个软件的使用者是谁,使用者要使用那些功能,以及使用者需要向软件提供什么功能。通过用例视图一来可以让使用者清楚的理解这个软件到底能提供什么功能,是不是满足自己的需求,另外一方面对应开发者来说,可以更好地理解需求,从而能更好的去实现这些需求。
参与者与用例为基本元素。
通过不同视角展示功能性需求。
便于人们通过用例视图了解一个系统是干什么的,总体的逻辑是什么等
用例图主要有六个元素,分别是:参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
包含关系强调整体与部分之间关系;扩展关系则强调是在基础功能的基础上添加新的功能;泛化关系则强调复用的关系;
参与者(Actor)
参与者在uml中用下面带有名字的小人来标示,主要表示与您的软件系统交互的人,组织或者外部软件系统。
用例(Use Case)
用例在uml中用使用椭圆标示,主要说明你的软件系统的功能,是使用文字描述的形式说明你的系统的功能。
包含关系(Include)
在uml中包含关系表示为虚线箭头交<>字样,有时候一个用例很大,那么我们可以把用例分块,把复杂的用例分解为几个小用例来描述
【箭头指向】:箭头指向被包含的用例
扩展(Extend)
在uml中扩展关系表示为虚线箭头加<>字样,扩展是指在基础用例功能的基础上插入新的功能点,新的功能点可以看做是对基础用例的扩
【箭头指向】:箭头指向基础用例
泛化(Inheritance)
在uml中用例泛化用一个空心三角箭头从子用例指向父用例,泛化就是继承关系,子用例可以使用父亲用例中的属性,行为和关系。
【箭头指向】:箭头指向父用例
【案例】
从用例的角度对业务边界和参与者进行界定
业务用例视图使用业务主角在业务中使用哪些业务用例来达成业务目标
【案例】
用户在线下商户消费,结账时通过使用支持扫描二维码的手机客户端(不限于支付宝手机客户端)扫描收银台屏幕上或收银小票上的二维码,使用支付宝账户即可完成支付
系统用例视图展示系统范围,将对业务用例进行分析以后得到的系统用例展现出来。
系统用例视图就是系统的开发范围。
一个业务可能通过多个系统的配合才可以实现
一个系统用例也可以在多个业务用例中被使用
类图=抽象对象的结构化、概念化、逻辑化描述。
UML类图就是要将对象的概念层、说明层和实现层描述的一种例图,帮助进一步细化抽象层次,逐步细化。
类的继承结构表现在UML中为:泛化(generalize)与实现(realize):
泛化关系用一条带空心箭头的实线直接表示;如下图表示(A继承自B);
eg:汽车在现实中有实现,可用汽车定义具体的对象;汽车与SUV之间为泛化关系;
注:最终代码中,泛化关系表现为继承非抽象类;
实现关系用一条带空心箭头的虚线表示;
eg:”车”为一个抽象概念,在现实中并无法直接用来定义对象;只有指明具体的子类(汽车还是自行车),才可以用来定义对象(”车”这个类在C++中用抽象类表示,在JAVA中有接口这个概念,更容易理解)
注:最终代码中,实现关系表现为继承抽象类;
聚合关系用一条带空心菱形箭头的直线表示,如下图表示A聚合到B上,或者说B由A组成;
聚合关系用于表示实体对象之间的关系,表示整体由部分构成的语义;例如一个部门由多个员工组成;
与组合关系不同的是,整体和部分不是强依赖的,即使整体不存在了,部分仍然存在;例如, 部门撤销了,人员不会消失,他们依然存在;
组合关系用一条带实心菱形箭头直线表示,如下图表示A组成B,或者B由A组成;
与聚合关系一样,组合关系同样表示整体由部分构成的语义;比如公司由多个部门组成;
但组合关系是一种强依赖的特殊聚合关系,如果整体不存在了,则部分也不存在了;例如, 公司不存在了,部门也将不存在了;
关联关系是用一条直线表示的;它描述不同类的对象之间的结构关系;它是一种静态关系, 通常与运行状态无关,一般由常识等因素决定的;它一般用来定义对象之间静态的、天然的结构; 所以,关联关系是一种“强关联”的关系;比如,乘车人和车票之间就是一种关联关系;学生和学校就是一种关联关系;
关联关系默认不强调方向,表示对象间相互知道;如果特别强调方向,如下图,表示A知道B,但B不知道A;
注:在最终代码中,关联对象通常是以成员变量的形式实现的;
依赖关系是用一套带箭头的虚线表示的;如下图表示A依赖于B;他描述一个对象在运行期间会用到另一个对象的关系;
与关联关系不同的是,它是一种临时性的关系,通常在运行期间产生,并且随着运行时的变化,依赖关系也可能发生变化;显然,依赖也有方向,双向依赖是一种非常糟糕的结构,我们总是应该保持单向依赖,杜绝双向依赖的产生;
注:在最终代码中,依赖关系体现为类构造方法及类方法的传入参数,箭头的指向为调用关系;依
赖关系除了临时知道对方外,还是“使用”对方的方法和属性;
时序图(Sequence Diagram)是显示对象之间交互的图,这些对象是按时间顺序排列的。时序图中显示的是参与交互的对象及其对象之间消息交互的顺序。
时序图包括的建模元素主要有:对象(Object)、生命线(Lifeline)、控制焦点(Focus ofcontrol)、消息(Message)、Combined Fragments等等。
序列图将交互关系表示为一个二维图。纵向是时间轴,时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列
生命线名称可带下划线。当使用下划线时,意味着序列图中的生命线代表一个类的特定实例。 生命线头上那个方正的框里面存放的就是对象,对象有自己的名字;生命线标示一个对象存在的生命周期,两条生命线中间通过消息连接起来;
发送人在它继续之前,将等待同步消息响应。
在发送方继续之前,无需等待响应的消息。
返回消息:标示发送消息后返回的动作
自关联消息:一个对象内自调用的情况。
标示有一定条件的消息发送;
- Alternative fragment(denoted “alt”) 标示 if…then…else
- Option fragment (denoted “opt”) 标示Switch
- Parallel fragment (denoted “par”) 标示同时发生
- Loop fragment(denoted “loop”) 标示for
- Break标示退出循环
约束的符号很简单;格式是: [Boolean Test]
抉择用来指明在两个或更多的消息序列之间的互斥的选择,相当于经典的if..else..。
抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。 else 的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else,则不执行任何片段
包含一个可能发生或不发生的序列 ,相当于switch
片段重复一定次数。 可以在临界中指示片段重复的条件 。
当没有指定循环边界默认范围为[0,无穷大]:
如果只指定了一个值,那么默认执行该值次数:
指定了循环边界,则最少执行最小值值,最多执行最大值次数:
实现dowhile方式,至少执行一次,如果size<0则退出:
同时进行,比如多个线程同时执行任务;
n=10时候执行save并退出循环
状态图就是为了显示一个状态机的视图。而状态机用于对模型元素的动态行为进行建模,更具体就是对系统行为中受事件驱动的方面进行建模
通常状态图用来描述一个实体的状态转换事件以及引起转换的操作行为。
状态在切换过程中,状态的转换不一定都是单线的,有时会出现需要描述两种状态可切换同一种状态,或者一种状态因为某些原因有两种状态的转换 。
简单状态(Simple State)
简单状态没有子状态机和域,UML中使用带拐点的矩形标示简单状态,并且状态名字写在矩形内部。
组合状态(Composite State)
组合状态被定义为用用子状态或者嵌套状态的状态行为,子状态可以是顺序发生的也可以是并发发生,组合状态里至少有一个域,如下图含有一个域
如图黑色实心为起始状态,末端双环圆为终止状态,中间连接线为行为转移,其中isAuthed为一个guard说明满足该条件才会进行状态转移,然后执行函数auidt。
包图一般用来展示高层次的观点的图片。比如模块与模块之间的关系的描述,或者描述代码模块(包)与代码模块(包)
之间的依赖关系。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。