UML的种图例的定义用途、画法总结
- 格式:doc
- 大小:1.15 MB
- 文档页数:40
3、UML的9种图分类及运用UML中的图可以分成两大类·结构图·行为图UML结构图UML结构图表示系统的静态方面,描述系统的主要结构因此而稳定的那部分,静态结构图主要包括·类图·对象图·组件图·部署图UML类图·类图描述系统中的类,以及各个类之间的关系,类图能够让我们在编码前对系统有个全面的认识。
·类图是一种静态模型,类图代表面向对象系统,类图其他图定义的基础。
·哪里需要用类图是一个静态图,描述一个系统的静态视图,用于前期部署UML对象图·对象图与类图类似,它是类图的实例化,显示类的多个实例化,不是实际的类,描述对象间的关系,用来建立系统原型。
·对象图显示某一时刻对象和对象间的关系·类图代表整个系统模型的抽象,对象图代表系统中某一时刻某一部分的抽象·哪里需要用运行的系统某一时刻的快照•UML组件图•·组件图用来描述系统的物理结构及相互间的关系,模型化和文档化了一个系统的架构·构件可以是一个文件,产品,可执行脚本,库等·组件图= 构件(Component)+接口(Interface)+关系(Relationship)+端口(Port)+连接器(Connector)·哪里需要用架构师在建立项目初期就要建立的图UML部署图·部署图用来建模系统的物理部署,如计算机和设备,及它们之间的关联关系·部署图的使用者为开发人员,系统集成人员和测试人员·部署图由节点以及节点之间的关系组成·哪里需要用主要用于系统工程师UML行为图行为图属于系统的动态部分,另一部分是系统的结构图。
行为图捕捉系统的静态方面。
UML中的行为图主要包括:·用例图·时序图·协作图·状态图·活动图UML用例图·用例图描述角色以及角色与用例之间的连接关系。
浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图(用例)4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图(Collaboration Diagram/communication Diagram)/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言(Unified Modeling Language,UML)又称标准建模语言,是始于1997年的一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
‘UML感兴趣的可以阅读UML 1规范,包含了UML 的所有知识内容。
注:OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发,定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类:面向对象动态建模,用于建立行为的实体间行为交互的四种图:状态图(Stage Diagram),序列图(Sequence Diagram),协作图(Communication Diagram),活动图(Activity Diagram) 。
“序列图”与“协作图”表述的是相似的消息,“活动图”是“状态图”的一种。
•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图(用例)用例图,展现了一组用例、参与者(actor)以及它们之间的关系。
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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
1.用例图:用例图是从用户的观点描述系统的功能,它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件,这些事件最终对参与者产生有价值的可观测结果参与者(Actor):代表与系统交互的外部实体用例(Use-Case):表示系统能提供的功能,如:登录,查询等关联关系:当参与者与用列进行交互时,用例与参与者之间有关联关系,用一条直线表示这种关系参与者之间可能存在泛化关系,类似的参与者可以用泛化关系组成一般与特殊的层析结构如:经理初次之外,用例之间还存在一定的关系,具体包括包含(include)、扩展(extend)、泛化(Generalization)等3种关系(1)包含关系一个复杂系统中,不同用例之间可能存在一些相同的行为,这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时,用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示,虚线指向被包含的用例注册新用户(2)扩展关系在用例的执行过程中,可能会出现异常行为,也可能在不同的流程分支中选择执行,这时可将异常行为或可选分支抽象成一个单独的扩展用例,它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示,箭头指向被扩展的用例注册(3)泛化关系与参与者之间的泛化关系一样,用例之间的泛化关系是描述用例之间一般与特殊关系的,不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构,表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示,方框被分成3部分,最上面显示类名,中间部分显示类的属性,最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联(Association)是一种结构定义,表达模型元素间的一种语义联系,它是对具有共同的结构特性、行为特性、关系和语义链的描述,使用一条连接在两个类之间的实线表示,关系的每一端用数字表示关系的重数。
1UML 的9种图例的总结一、 用例图1、 定义用例定义:用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。
(这是UML 对用例的正式定义,可以这样去理解,用例是参与者想要系统做的事情,用例在画图中用椭圆来表示,椭圆下面附上用例名称)。
用例图定义:由参与者(Actor )、用例(Use Case )以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、 用途用例图(User Case )是被称为参与者的外部用户所能观察到的系统功能的模型图,呈现了一些参与者和一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用。
3、 组成元素以及元素之间的关系说明用例图由参与者(Actor )、用例(Use Case )、系统边界(用矩形表示—注明系统名称)、箭头组成,用画图的方法来完成。
参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。
还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分,边界外表示系统外部。
系统边界在画图中用方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。
因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。
元素之间的关系:用例图中包含的元素除了系统边界、角色和用例,另外就是关系。
关系包括用例之间的关系,角色之间的关系,用例和角色之间的关系。
角色之间的关系:角色之间的关系。
UML:图的分类及作⽤(共5类图,有9种图形)第⼀类:⽤例图:从⽤户⾓度描述系统功能,并指出各功能的操作者。
第⼆类:静态图:包括类图、对象图和包图。
1、类图:表⽰类之间的联系如关联、依赖、聚合等,包括类的内部结构(类的属性和操作)。
在系统的整个⽣命周期都是有效的 2、对象图:表⽰类图的⼀个实例,对象图只能在系统某⼀时间段存在。
3、包图:表⽰包与包之间的关系。
包图⽤于描述系统的分层结构。
第三类:⾏为图:状态图、活动图。
描述系统的动态模型和组成对象间的交互关系。
1、状态图:是对类图的补充,描述类的对象所有可能的状态以及事件发⽣时状态的转移条件。
在实⽤上并不需要为所有的类画状态图,仅为那些有多个状态其⾏为受外界环境的影响并且发⽣改变的类画状态图。
2、描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系,有利于识别并⾏活动。
第四类:交互图:包括顺序图 ,协作图(即合作图) 1、顺序图:强调的是时间和顺序的关系 2、协作图:强调的是上下级关系第五类:实现图:构件图,描述代码部件的物理结构及各部件之间的依赖关系。
从应⽤的⾓度看,当采⽤⾯向对象技术设计系统时,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构;第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的,包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语⾔UML的静态建模机制。
其中第三步中所建⽴的模型或者可以执⾏,或者表⽰执⾏时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语⾔UML的动态建模机制。
因此,标准建模语⾔UML的主要内容也可以归纳为静态建模机制和动态建模机制两⼤类。
总结:1、静态图:包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构; 2、动态图:包括状态图、活动图、顺序图和合作图等四个图形,是描述系统的⾏为;。
UML中各种图的画法(全)UML中各种图的画法(全)一、UML中基本的图范畴:在 UML 2 中有二种基本的图范畴:结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类,组件和(或)对象图。
另一方面,行为图显示系统中的对象的动态行为,包括如对象的方法,协作和活动之类的内容。
行为图的实例是活动图,用例图和序列图。
二、UML中的类图:1.类图的表示:类的 UML 表示是一个长方形,垂直地分为三个区,如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。
描述:顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。
·类名:如果是抽象类,则采用斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0,这是带有默认值的表达形式·类方法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。
2.继承的表示:为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。
UML九种图之⽤例图和类图前⾔近期写UML⽂档,看视频的时候感觉掌握的还能够,当真正写⽂档的时候才发现不是⼀件easy的事。
写⽂档⾃⼰⼜翻开⾃⼰的笔记看了⼀遍⼜⼀遍。
以下就给⼤家介绍⼀下我画的⼏张图:⽤例图1. ⽤例图的构成(⽤例,⾓⾊,关系)⽤例:指功能的描写叙述⾓⾊:触发起某种事件关系:⽤例图的关系(依赖,泛化,关联)2. ⽤例图的作⽤(1)⽤例视图是整个UML设计的关键,影响到整个UML设计的过程(2)⽤例模型驱动了需求分析后各个阶段的开发(3)⽤例模型⽤于需求分析阶段,表明了开发⼈员和⽤户针对需求达成的某种共识注意⼏个keyword:开发⼈员,⽤户,共同商讨达成某种共识3.设计原则将系统看做⿊盒⼦,从⽤户⾓度理解系统,不须要考虑某个功能是怎样实现的。
仅仅须要考虑系统由谁来运⾏和怎样交互和运⾏。
以下是我画的⽤例图:以⽤户的权限为基础画出来的。
类图1.类图的构成类、接⼝、协作、关系、包2.类的构成2.类图的作⽤类图⼀般在具体设计过程中出现,主要⽤来描写叙述系统中各个模块中类之间的关系,包含类或者类与接⼝的继承关系,类之间的依赖、聚合等关系。
通过类图,就能实际的把系统中的各个类,即对象描写叙述清楚,下⼀步就是依照这个具体的设计编码了。
3.类图的设计Use case——>class(要点,抽象名词得到类)——>确定类的属性和⽅法——>属性是静态⾏为描写叙述,⽅法是动态⾏为的描写叙述——>正确表达类与类之间的关系以下是我对机房收费系统设计的类图,理解的不是⾮常清楚,可定存在诸多问题,希望⼤家积极指正。
以上是我看完UML之后对⽤例图和类图的理解,感觉理解的不是⾮常清楚,若有什么问题希望⼤家积极指正。
UML中的类图详解及其应用场景在软件开发过程中,UML(统一建模语言)被广泛应用于需求分析、系统设计和软件开发等各个阶段。
其中,类图作为UML的核心图表之一,用于描述系统中的类、对象以及它们之间的关系。
本文将详细介绍UML中的类图,并探讨其在实际应用中的场景。
一、类图的基本概念类图是一种静态结构图,用于表示系统中的类、接口、关联、继承、依赖等元素及其之间的关系。
在类图中,类用矩形表示,类名位于矩形顶部,类的属性位于矩形中部,类的操作(方法)位于矩形底部。
类之间的关系通过连线表示,如关联关系用实线箭头表示,继承关系用空心三角箭头表示,依赖关系用虚线箭头表示等。
二、类图的元素及其关系1. 类(Class):类是对象的抽象表示,用于描述具有相同属性和行为的一组对象。
类图中的类用矩形表示,类名位于矩形顶部。
2. 接口(Interface):接口是一组方法的集合,用于描述类的行为。
接口在类图中用带有<<interface>>标记的矩形表示。
3. 属性(Attribute):属性是类的特征,描述了类的状态。
属性在类图中用名称:类型的形式表示,例如“name:String”。
4. 操作(Operation):操作是类的行为,描述了类的方法。
操作在类图中用名称(参数列表):返回类型的形式表示,例如“getName():String”。
5. 关联关系(Association):关联关系描述了类之间的连接,表示一个类与另一个类之间的关联。
关联关系在类图中用实线箭头表示。
6. 继承关系(Inheritance):继承关系描述了类之间的继承关系,表示一个类继承自另一个类。
继承关系在类图中用空心三角箭头表示。
7. 依赖关系(Dependency):依赖关系描述了类之间的依赖关系,表示一个类依赖于另一个类。
依赖关系在类图中用虚线箭头表示。
三、类图的应用场景1. 系统设计:类图是系统设计的重要工具之一。
UML九种建模图--类图⼝令泛化、实现、关联、依赖、组合、聚合泛化是实线加空⼼三⾓形,实现是虚线加空⼼三⾓形。
关联是实线加箭头,依赖是虚线加箭头。
组合是实⼼棱形加实线箭头,聚合是空⼼棱形加实线箭头。
思维导图作⽤在软件⼯程中,类图是⼀种静态的结构图,描述了系统的类的集合,类的属性和类之间的关系,可以简化了⼈们对系统的理解。
类图是系统分析和设计阶段的重要产物。
UML的介绍和画法类的UML使⽤包含类名、属性、⽅法名以及参数。
相互之间使⽤带分割线的长⽅形表⽰。
类名根据java命名规范类名⾸字母⼤写。
属性表⽰⽅式:可见性名称:类型 [ = 缺省值 ]可见性的值:+表⽰ public属性, - 表⽰ private属性, # 表⽰ protected属性⽅法表⽰⽅式:可见性名称(参数列表) [ : 返回类型]接⼝接⼝的UML⽐类多了⼀个圆圈和横线其他类似。
类与类的六种关系泛化(Generalization)、实现(Realization)、依赖(Dependence)、关联(Association)、聚合(Aggregation)、组合(Composition)泛化关系表⽰类与类之间的继承关系,由⼦类指向⽗类。
实现关系实现关系就是java中的⼀个类和接⼝之间的关系,接⼝中⼀般是没有成员变量。
所有操作都是抽象的,只有声明没有具体的实现。
关联关系关联关系表⽰⼀个类和另⼀类有联系。
关联关系通常将⼀个类的对象作为另⼀个类的属性。
依赖关系假设A类的变化引起了B类的变化,则说名B类依赖于A类。
1、A类是B类中的(某中⽅法的)局部变量;2、A类是B类⽅法当中的⼀个参数;3、A类向B类发送消息,从⽽影响B类发⽣变化;组合关系也是整体与部分的关系。
“整体”负责“部分”的⽣命周期,他们之间是共⽣共死的;并且“部分”单独存在时没有任何意义。
聚合关系整体和部分的关系,是⼀种强的关系,但是部分可以脱离整体⽽存在。
是关联关系的⼀种。
UML类图的画法及含义2008-05-19 09:29写点定义先:抽象:只定义你想要的属性和操作,不相关的可以省去不写.继承:类之间的特性传承多态性:类的名字不同,但有相同的操作名封装:非公开的属性和操作,这样可以降低类之间的耦合消息传递:类之间协作的方式关联:类之间发生关系时的术语.两个类之间可以有多种关联.多重性:一个类和多个类之间有关联.聚集:1个类包含N个类,那么主和子之间就有聚集关系.组成:聚集的加强版,即组成的每个成员都必须存在,缺一不可.类的可视化例子:类名:WashingMachine包名:有包的情况下,可能要把包名写在类名前面,比如:PackageName::WashingMachine属性: brandName , 更全的例子是 + brandName:String = "TNND"对象名:myWasher:WashingMachine操作: +addClothes(C:String)void职责:写在类图的最下面,记述这个类它要做什么约束:用{}的格式写在类国的边上,指定个别属性的取值范围.关系:关联:类A要在类B 中发挥什么作用时,就用带方向的关联来表示, 关联相关的概念:关联名,角色名,关联上的约束,多重性.关联类:类A和类B之间的关联,是通过类C来体现的,那么类C就是关联类. 链:相对于类,对象之间的关系叫链.多重性: 可能1个类A对应N个类B. 例子有 1 1・・*0,1限定关联:在多重关联时,类A可能要通过一个指定的属性来识别类B.此时那个属性,就叫做限定符自身关联:一个类可能同时代表多种角色,那在类图中就可能表现为自已和自己关联继承:子类继承父类, 用实线空三角形指向父类.用――――――――△(这个三角要右转90度)来表示相关概念:基类,根类,叶类,单继承,多继承.依赖:当类A的操作里用到类B时,就说类A依赖类B 用------->来表示聚集:上面讲过了.图示为: 部分类―――――◇ 总的类组成:同上.图示为: 部分类―――――◆ 总的类接口:听说有两种:1)在类图的类名上面写<<interface>>, 2)把类名写成IClassName的格式.实现:是说类和接口之间的关系,用-------△(这个三角要右转90度)来表示另外,接口可以简化成一个圆圈.可见性: + 公有 # 保护 - 私有有点搞的地方:1,关联和依赖:简单的说,关联是指把类B定义成类A的属性. 依赖是指,类A的一个方法,用到了类B.2,聚集和组成:聚集,少几个没问题. 组成,少一个不成. // 其实还是不知道两者有什么实际意义,感觉还是一回事.。
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 2.0共有10种图,分别为表示系统静态结构的静态模型(包括类图、组合结构图、部署图),以及表示系统动态结构的动态模型(包括用例图、序列图、对象图、协作图、状态图、活动图、组件图),它们各用以表现不同的视图,如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系:
(1)包含关系:用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为做为自身行为的一部分,这被称作包含关系。
(2)扩展关系:扩展关系是从扩展用例到基本用例的关系,它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的,也就是说,扩展用例并不在基本用例中显示。
在以下几种情况下,可使用扩展用例:
a.表明用例的某一部分是可选的系统行为(这样,您就可以将模型中的可选行为和必选行为分开);
b.表明只在特定条件(如例外条件)下才执行的分支流;
c.表明可能有一组行为段,其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
(3)泛化关系:用例可以被特别列举为一个或多个子用例,这被称做用例泛化。
当父用例能够被使用时,任何子用例也可以被使用。
如在图2.4中,订票是电话订票和网上订票的抽象。
UML图中的几种图简介(时序图,协作图,状态图,活动图,对象图)1、时序图:时序图用于描述对象之间的传递消息的时间顺序,即用例的行为顺序。
当执行一个用例时, 时序图中的每条消息对应了一个类操作或者引起转换的触发事件.在UML 中, 时序图表示为一个二维的关系图, 其中, 纵轴是时间轴, 时间延竖线向下延伸. 横轴代表在协作中各个独立的对象. 当对象存在时, 生命线用一条虚线表示, 消息用从一个对象的生命线到另一个对象的生命线的箭头表示. 箭头以时间的顺序在图中上下排列.时序图中的基本概念:对象:时序图中对象使用矩形表示, 并且对象名称下有下划线. 将对象置于时序图的顶部说明在交互开始时对象就已经存在了. 如果对象的位置不在顶部, 表示对象是在交互的过程中被创建的.生命线:生命线是一条垂直的虚线. 表示时序图中的对象在一段生命周期内存在. 每个对象底部中心的位置都带有生命线.消息:两个对象之间的单路通信. 从发送方指向接收方. 在时序图中很少使用返回消息.激活:时序图可以描述对象的激活和钝化. 激活表示该对象被占用以完成某个任务. 钝化指对象处于空闲状态, 等待消息.在UML中,对象激活时将对象的生命线拓宽为矩形来表示的. 矩形称为计划条或控制期. 对象就是在激活条的顶部被激活的. 对象在完成自己的工作后被钝化.对象的创建和销毁: 在时序图中, 对象的默认位置是在图的顶部. 这说明对象在交互开始之前就已经存在了. 如果对象是在交互过程中创建的, 那么就应该将对象放到中间部分. 如果要撤销一个对象, 在其生命线终止点处放置“X”符号2、活动图:在UML 中, 活动图本质上就是流程图. 它用于描述系统的活动, 判定点和分支等.活动图的基本概念:动作状态:原子的, 不可中断的动作, 并在此动作完成之后向另一个动作转变.在UML 中动作状态用圆角矩形表示, 动作状态所表示的动作写在圆角矩形内部.分支与合并:分支在软件系统中很常见. 一般用于表示对象类所具有的条件行为. 用一个布尔型表达式的真假来判定动作的流向. 条件行为用分支和合并表达.在活动图中, 分支用空心小菱形表示. 分支包括一个入转换和两个带条件的出转换, 出转换的条件应该是互斥的, 须保证只有一条出转换能够被触发. 合并包含两个带条件的入转换和一个出转换.分叉与汇合:分叉用来描述并发线程, 每个分叉可以有一个输入转换和两个或多个输出转换. 每个转换都可以是独立的控制流. 汇合代表两个或多个并发控制流同步发生, 当所有的控制流都达到汇合点后, 控制才能继续往下进行. 每个汇合可以有两个或多个输入转换和一个输出转换. 在UML 中分叉和汇合用一条粗直线表示泳道:泳道将活动图中的活动划分为若干组, 并将每一组指定给负责这组活动的业务组织. 泳道区分负责活动的对象, 明确地表示哪些活动是由哪些对象进行的. 每个活动指定明确地属于一个泳道. 在活动图中, 泳道用垂直实线绘出, 垂直线分隔的区域即为泳道3、协作图:协作图(也叫合作图)是一种交互图. 时序图主要侧重于对象间消息传递在时间上的先后关系, 而协作图表达对象间的交互过程及对象间的关联关系。
UML建模的六种图解释与应用UML(Unified Modeling Language)是一种用于软件系统开发和设计的标准化语言,由Grady Booch、James Rumbaugh和Ivar Jacobson等大师共同开发。
UML不仅具有图形化表示系统结构的能力,还能够从不同角度分析和设计软件系统的结构。
UML中的图形化表示是UML建模的关键特点之一,下面将解释UML的六种图。
一、用例图用例图是UML建模的第一种图形化表示法,它对系统的功能进行了整体把握,并说明系统和外部环境之间的交互关系。
在用例图中,系统和外部的人员和物体都表示成参与者,而系统和外部参与者之间的交互行为则用用例来描述,用例可以表示系统的内部处理过程或与外界协调完成的事件。
例如,我们可以使用用例图来表示一个在线购物网站的功能,网站本身就是一个系统,用户可以通过在网站上购买商品,而交互行为包括注册、登录、搜索商品、加入购物车、下订单以及查询订单等操作。
在用例图中,网站就是系统,用户是参与者,用例分别表示各种交互功能。
二、类图类图是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. 共享聚合【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。
一.用例图用例模型是把应满足用户需求的基本功能(集) 聚合起来表示的强大工具。
用例模型的基本组成部件是用例角色和系统。
引入用例的主要目的是:确定系统应具备哪些功能这些功能是否满足系统的需求开发者与用户协商达成共识的东西为系统的功能提供清晰一致的描述,以便为后续的开发工作打下良好的交流基础,方便开发人员传递需求的功能为系统验证工作打下基础通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致保证系统的实用性从需求的功能用例出发提供跟踪进入系统中具体实现的类和方法检查其是否正确的能力特别是为复杂系统建模时常用用例模型构造系统的简化版本(也就是精化系统的变化和扩展能力使系统不要过于复杂)然后利用该用例模型跟踪对系统的设计和实现有影响的用例简化版本构造正确之后通过扩展完成复杂系统的建模图示用例图时既要画出三种模型元素,同时还要画出元素之间的各种关系(通用化关联依赖)用例代表的是一个完整的功能。
如何发现用例实际上从识别角色起发现用例的过程就已经已开始了对于已识别的角色通过询问下列问题就可发现用例●角色需要从系统中获得哪种功能角色需要做什么●角色需要读取产生删除修改或存储系统中的某种信息吗●系统中发生的事件需要通知角色吗或者角色需要通知系统某件事吗这些事件功能能干些什么●如果用系统的新功能处理角色的日常工作是简单化了还是提高了工作效率●还有一些与当前角色可能无关的问题也能帮助建模者发现用例例如●系统需要的输入/输出是什么信息这些输入/输出信息从哪儿来到哪儿去●系统当前的这种实现方法要解决的问题是什么也许是用自动系统代替手工操作UML 中的用例UML 中的用例用椭圆形表示用例的名字写在椭圆的内部或下方用例位于系统边界的内部角色与用例之间的关联关系或通信关联关系用一条直线表示用例和角色之间有连接关系用例和角色之间的关系属于关联association 又称作通信关联communication association,这种关联表明哪种角色能与该用例通信,关联关系是双向的一对一关系,即角色可以与用例通信,用例也可以与角色通信。
UML九种图作用简介UML(统一建模语言):是面向对象的可视化建模语言。
UML中有3种构造块:事物、关系和图,事物是对模型中最具有代表性的成分的抽象,关系是把事物结合在一起,图聚集了相关的事物UML中有九种图如下:1、用例图描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统,以及他们使用该系统可以做些什么。
2、类图类图是描述系统中的类,以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型,确切的说,是一种静态模型类型。
3、对象图与类图极为相似,它是类图的实例,对象图显示类的多个对象实例,而不是实际的类。
它描述的不是类之间的关系,而是对象之间的关系。
4、活动图描述用例要求所要进行的活动,以及活动间的约束关系,有利于识别并行活动。
能够演示出系统中哪些地方存在功能5、状态图描述类的对象所有可能的状态,以及事件发生时状态的转移条件。
可以捕获对象、子系统和系统的生命周期。
他们可以告知一个对象可以拥有的状态,并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类;该图可以确定类的行为,以及该行为如何根据当前的状态变化,也可以展示哪些事件将会改变类的对象的状态。
状态图是对类图的补充。
6、序列图(顺序图)序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。
顺序图将显示的重点放在消息序列上,即强调消息是如何在对象之间被发送和接收的。
7、协作图和序列图相似,显示对象间的动态合作关系。
可以看成是类图和顺序图的交集,协作图建模对象或者角色,以及它们彼此之间是如何通信的。
如果强调时间和顺序,则使用序列图;如果强调上下级关系,则选择协作图;这两种图合称为交互图。
8、构件图(组件图)描述代码构件的物理结构以及各种构建之间的依赖关系。
UML的9种图例的总结一、用例图1、定义用例定义:用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。
(这是UML对用例的正式定义,可以这样去理解,用例是参与者想要系统做的事情,用例在画图中用椭圆来表示,椭圆下面附上用例名称)。
用例图定义:由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。
2、用途用例图(User Case)是被称为参与者的外部用户所能观察到的系统功能的模型图,呈现了一些参与者和一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。
用例图主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用。
3、组成元素以及元素之间的关系说明用例图由参与者(Actor)、用例(Use Case)、系统边界(用矩形表示—注明系统名称)、箭头组成,用画图的方法来完成。
参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。
还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。
系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分,边界外表示系统外部。
系统边界在画图中用方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。
因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。
元素之间的关系:用例图中包含的元素除了系统边界、角色和用例,另外就是关系。
关系包括用例之间的关系,角色之间的关系,用例和角色之间的关系。
角色之间的关系:角色之间的关系。
由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在泛化关系(泛化关系可以先简单理解为继承),泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系:●包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
在UML1.1中用例之间是使用和扩展这两种关系,这两种关系都是泛化关系的版型。
在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
●泛化关系:它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段,泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
●扩展关系扩展关系的基本含义和泛化关系类似,但在扩展关系中,对于扩展用例有更多的规则限制,基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样,扩展关系也是依赖关系的版型。
在扩展关系中,箭头的方向是从扩展用例到基本用例,这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。
一般来说可以使用“is a”和“has a”来判断使用那种关系。
泛化和扩展关系表示用例之间是“is a”关系,包含关系表示用例之间是“has a”关系。
扩展与泛化相比多了扩展点,扩展用例只能在基本用例的扩展点上进行扩展。
在扩展关系中基本用例是独立存在。
在包含关系中执行基本用例的时候一定会执行包含用例。
(1)如果需要重复处理两个或多个用例时可以考虑使用包含关系,实现一个基本用例对另一个的引用。
(2)当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。
(3)当描述正常行为的变形希望采用更多的控制方式时,可以在基本用例中设置扩展点,使用扩展关系。
扩展关系比较难理解,如果把扩展关系看作是带有更多规则限制的泛化关系,可以帮助理解。
通常先获得基本用例,针对这个用例中的每一个行为提问:该步骤会出什么差错?该步骤有不同的情况吗?该步骤的工作怎样以不同的方式进行等,把所有的变化情况都标识为扩展。
通常基本用例很容易构造,而扩展用例需要反复分析、验证。
当我们发现已经存在的两个用例间具有某种相似性时,可以把相似的部分从两个用例中抽象出来单独作为一个用例,该用例被这两个用例同时使用,这个抽象出的用例和另外两个用例形成包含关系。
用例之间的关系举例:包含:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。
这时包含关系可以用来理清关系。
扩展:系统中允许用户对查询的结果进行导出、打印。
对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。
导入、打印和查询相对独立,而且为查询添加了新行为。
泛化:子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为,也可以重载它。
父用例通常是抽象的。
4、画法例子二、类图1、定义类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。
类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响。
在系统分析阶段将类分成三种类型:实体类、边界类、控制类边界类用于描述外部参与者与系统之间的交互。
识别边界类可以帮助开发人员识别出用户对界面的需求。
实体类主要是作为数据管理和业务逻辑处理层面上存在的类别;它们主要在分析阶段区分。
实体类的主要职责是存储和管理系统内部的信息,它也可以有行为,甚至很复杂的行为,但这些行为必须与它所代表的实体对象密切相关。
控制类用于描述一个用例所具有的事件流控制行为,控制一个用例中的事件顺序。
2、用途类图的目的是显示建模系统的类型,描述组成系统的对象内容与对象之间的关系。
3、组成元素以及元素之间的关系说明类名类的 UML 表示是一个长方形,垂直地分为三个区,如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。
图 1 显示一个航线班机如何作为 UML 类建模。
正如我们所能见到的,名字是Flight,我们可以在中间区域看到Flight类的3个属性:flightNumber,departureTime 和 flightDuration。
在底部区域中我们可以看到Flight类有两个操作:delayFlight 和 getArrivalTime。
图 1: Flight类的类图类属性列表类的属性节(中部区域)在分隔线上列出每一个类的属性。
属性节是可选择的,要是一用它,就包含类的列表显示的每个属性。
如下格式:name : attribute typeflightNumber : Integer继续我们的Flight类的例子,我们可以使用属性类型信息来描述类的属性,如表 1 所示。
表 1:具有关联类型的Flight类的属性名字属性名称属性类型flightNumber IntegerdepartureTime DateflightDuration Minutes在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。
在类图上显示具有默认值的特定属性,有时是有用的(例如,在银行账户应用程序中,一个新的银行账户会以零为初始值)。
UML 规范允许在属性列表节中,通过使用如下的记号作为默认值的标识:name : attribute type = default value举例来说:balance : Dollars = 0显示属性默认值是可选择的;图 2 显示一个银行账户类具有一个名为balance的类型,它的默认值为0。
图 2:显示默认为0美元的balance属性值的银行账户类图。
类操作列表类操作记录在类图长方形的第三个(最低的)区域中,它也是可选择的。
和属性一样,类的操作以列表格式显示,每个操作在它自己线上。
操作使用下列记号表现:name(parameter list) : type of value returned图3显示,delayFlight 操作有一个Minutes类型的输入参数 -- numberOfMinutes。
然而,delayFlight 操作没有返回值。
1当一个操作有参数时,参数被放在操作的括号内;每个参数都使用这样的格式:“参数名:参数类型”。
图 3:Flight类操作参数,包括可选择的“in”标识。
当文档化操作参数时,你可能使用一个可选择的指示器,以显示参数到操作的输入参数、或输出参数。
这个可选择的指示器以“in”或“out”出现,如图3中的操作区域所示。
一般来说,除非将使用一种早期的程序编程语言,如Fortran ,这些指示器可能会有所帮助,否则它们是不必要的。
然而,在 C++和Java中,所有的参数是“in”参数,而且按照UML规范,既然“in”是参数的默认类型,大多数人将会遗漏输入/输出指示器。
继承在面向对象的设计中一个非常重要的概念,继承,指的是一个类(子类)继承另外的一个类(超类)的同一功能,并增加它自己的新功能(一个非技术性的比喻,想象我继承了我母亲的一般的音乐能力,但是在我的家里,我是唯一一个玩电吉他的人)的能力。
为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。
考虑银行账户的类型:图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。