UML图的种类
- 格式:doc
- 大小:874.50 KB
- 文档页数:18
浅谈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科普⽂,⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式,其中有⼏个UML类图,有的读者反馈看不懂了,我们今天就来解决⼀哈。
什么是UML?UML是Unified Model Language的缩写,中⽂是统⼀建模语⾔,是由⼀整套图表组成的标准化建模语⾔。
为什么要⽤UML?通过使⽤UML使得在软件开发之前,对整个软件设计有更好的可读性,可理解性,从⽽降低开发风险。
同时,也能⽅便各个开发⼈员之间的交流。
UML提供了极富表达能⼒的建模语⾔,可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的,如下:1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔,以便他们开发和交换有意义的模型。
2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3. 独⽴于特定的编程语⾔和开发过程。
4. 为了解建模语⾔提供⼀个正式的基础。
5. ⿎励⾯向对象⼯具市场的发展。
6. ⽀持更⾼层次的开发概念,如协作,框架,模式和组件。
7. 整合最佳的⼯作⽅法 (Best Practices)。
UML图有哪些?UML图分为结构图和⾏为图。
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
⾏为图⼜分活动图、⽤例图、状态机图和交互图。
交互图⼜分为序列图、时序图、通讯图、交互概览图。
UML图概览什么是类图?【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。
类图描述了系统中对象的类型以及它们之间存在的各种静态关系。
【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。
在类图中,常见的有以下⼏种关系。
泛化(Generalization)【泛化关系】是⼀种继承关系,表⽰⼦类继承⽗类的所有特征和⾏为。
【箭头指向】带三⾓箭头的实线,箭头指向⽗类。
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流程图的概念、种类、结构和使用方法。
概念UML流程图,也称UML活动图,是一种图形化的表示算法、流程和业务过程的工具,它可以直观地表达系统中的任务、动作、决策和控制流程。
UML流程图常用于软件开发过程中的需求分析、业务流程设计、系统架构设计等领域。
种类UML流程图包含四种基本类型:1.基本活动图基本活动图可以用来表示操作的顺序或并行方式,其中每个操作都是基本动作,例如读取、写入、计算等。
基本活动图通常用于领域建模和系统流程的初步设计。
2.流程状态图流程状态图是对系统中复杂操作的一种表示,可以用来展示操作的状态和转换方式。
流程状态图主要包括状态、转换和起始状态,它通常用于描述系统中的复杂业务流程。
3.并发活动图并发活动图可以用来表达系统中多个处理程序的并发执行过程,它通常使用平行线表示并发执行的多个处理程序。
4.条件活动图条件活动图是一种用于表示系统中动态交互的活动图,其中条件是关键的组成部分。
条件活动图通常用于强制执行程序在满足一定条件的情况下才能执行,例如软件开发中经常用到的循环结构和分支结构等。
结构UML流程图的结构由一系列基本元素组成:1.开始节点开始节点,在UML流程图中表示整个活动图的起点。
一般情况下,开始节点在活动图的左侧上方,使用一个表示圆圈中心的空心点表示。
2.结束节点结束节点,在UML流程图中表示整个活动的结束点。
一般情况下,结束节点位于活动图的右侧下方,使用一个表示实心点的圆圈表示。
3.动作节点动作节点是一种执行操作的元素,可以进行计算、赋值、IO操作等。
动作节点在UML流程图中通常用长方形表示。
4.决策节点决策节点用于表示一个条件分支,并根据条件的结果选择一个或多个分支行动。
在UML流程图中,它通常使用菱形表示。
UML的逻辑模型图UML(Unified Modeling Language)是面向对象设计和开发中使用的一种标准化建模语言,其中逻辑模型图是其中的一种类型。
逻辑模型图是用于描述系统功能和行为的非物质结构模型,主要包括用例图、类图、对象图、状态图、活动图和序列图。
本文将重点介绍逻辑模型图中的用例图、类图和对象图三种。
用例图用例图通过描述用户和软件系统之间的交互来表示系统的功能和行为,是面向用户的一个模型。
用例图中包括参与者和用例两个主要元素。
参与者表示使用系统的人、人群或其他系统,用例则表示系统所提供的服务。
参与者与用例通过关系进行连接,分为关联关系、扩展关系、包含关系和泛化关系等。
以一个在线商城为例,客户、管理员、游客可以作为参与者,登录、注册、购物、添加物品等则是对应的用例。
客户可以通过购物车购买物品,可以查看订单状态,而管理员则可以修改物品、审核订单和退货等。
类图类图是用于描述系统内部静态结构的一种模型,它表示系统中的类、接口和它们之间的关系。
类图中包括类、接口、属性、方法等主要元素。
以一个汽车销售系统为例,车辆、销售员和客户都可以作为类。
而车辆包括品牌、型号、颜色、价格等属性,还有加速、制动等方法。
销售员则包括姓名、电话、销售量等属性,还有售车、联系客户等方法。
对象图对象图是用于描述系统中对象间的相对位置和关系的一种模型。
它可以表示对象在特定状态下的关系和属性,有助于表示对象之间的交互、通信和连接。
对象图中包括对象、属性、关系等主要元素。
以一个图书馆系统为例,书架、馆藏书、借阅者都可以作为对象。
借阅者可以借阅馆藏书,而馆藏书则可以属于不同的书架,还有编号、价格、作者等属性。
总结UML的逻辑模型图是面向对象设计和开发中使用的一种标准化建模语言,其中包括用例图、类图和对象图三种。
用例图主要用于描述系统功能和行为,类图用于描述系统内部静态结构,对象图则用于描述系统中对象之间的相对位置和关系。
通过应用这些模型,可以更加深入地了解系统的结构和功能,从而为系统的设计和开发奠定坚实的基础。
1.用例图:用例图是从用户的观点描述系统的功能,它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件,这些事件最终对参与者产生有价值的可观测结果参与者(Actor):代表与系统交互的外部实体用例(Use-Case):表示系统能提供的功能,如:登录,查询等关联关系:当参与者与用列进行交互时,用例与参与者之间有关联关系,用一条直线表示这种关系参与者之间可能存在泛化关系,类似的参与者可以用泛化关系组成一般与特殊的层析结构如:经理初次之外,用例之间还存在一定的关系,具体包括包含(include)、扩展(extend)、泛化(Generalization)等3种关系(1)包含关系一个复杂系统中,不同用例之间可能存在一些相同的行为,这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时,用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示,虚线指向被包含的用例注册新用户(2)扩展关系在用例的执行过程中,可能会出现异常行为,也可能在不同的流程分支中选择执行,这时可将异常行为或可选分支抽象成一个单独的扩展用例,它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示,箭头指向被扩展的用例注册(3)泛化关系与参与者之间的泛化关系一样,用例之间的泛化关系是描述用例之间一般与特殊关系的,不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构,表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示,方框被分成3部分,最上面显示类名,中间部分显示类的属性,最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联(Association)是一种结构定义,表达模型元素间的一种语义联系,它是对具有共同的结构特性、行为特性、关系和语义链的描述,使用一条连接在两个类之间的实线表示,关系的每一端用数字表示关系的重数。
UML中数据流图,⽤例图,类图,对象图,⾓⾊图,活动图,序列图详细讲述保存供参考这个⽂章,是我在急需的情况下在园⼦⾥搜索到的,原创作者是:DO-websoftware,为了⾃⼰看⽅便,所以复制到我的空间,希望原创者不要介意哦~~~~很详细的介绍,对我的帮助很⼤,谢谢哦。
类图,对象图,⾓⾊图:⼀、UML中基本的图范畴:在 UML 2 中有⼆种基本的图范畴:结构图和⾏为图。
每个 UML 图都属于这⼆个图范畴。
结构图的⽬的是显⽰建模系统的静态结构。
它们包括类,组件和(或)对象图。
另⼀⽅⾯,⾏为图显⽰系统中的对象的动态⾏为,包括如对象的⽅法,协作和活动之类的内容。
⾏为图的实例是活动图,⽤例图和序列图。
⼆、UML中的类图:1.类图的表⽰:类的 UML 表⽰是⼀个长⽅形,垂直地分为三个区,如图 1 所⽰。
顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
描述:顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
·类名:如果是抽象类,则采⽤斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0,这是带有默认值的表达形式·类⽅法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
银行系统UML 图一、用例图1.银行职员用例图登录管理账户修改账户2.客户与银行职员用例图Bank取款转账二、类图holder:String number:int type:Stringname:String ID:int数目:日期:数目:日期:ID:intname:String数目:日期:三、时序图1.登录时序图:LoginForm :MainForm Clerk2.创建登录对话框4.系统身份验证5.通过创建主界面2.存款时序图Clerk:MainForm:WithdrawForm:Account:Deposit2.请求存款操作3.修改账户时序图Clerk:LoginForm:QueryForm:AccountForm:Customer:Account1.进入主界面2.请求查询账户3.创建查询界面4.提交账号5.获得指定账户的信息6.创建账户界面7.修改账户信息8.更新账户信息9.更新账户信息Clerk:LoginForm :QueryFormCreateAccountAccount:Customer四、活动图1.银行职员登录活动图提示错误信息验证信息进入主界面N2.取款活动图验证账户是否存在且有效修改账户信息保存交易记录创建交易记录不存在或无效3.转账活动图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行五、状态图六、协作图1.修改账户协作图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行2.删除账户协作图Clerk:QueryForm:LoginForm七、系统组件图八、系统部署图。
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.每个类图包括类,关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图,可以把类组合成包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:图的分类及作⽤(共5类图,有9种图形)第⼀类:⽤例图:从⽤户⾓度描述系统功能,并指出各功能的操作者。
第⼆类:静态图:包括类图、对象图和包图。
1、类图:表⽰类之间的联系如关联、依赖、聚合等,包括类的内部结构(类的属性和操作)。
在系统的整个⽣命周期都是有效的 2、对象图:表⽰类图的⼀个实例,对象图只能在系统某⼀时间段存在。
3、包图:表⽰包与包之间的关系。
包图⽤于描述系统的分层结构。
第三类:⾏为图:状态图、活动图。
描述系统的动态模型和组成对象间的交互关系。
1、状态图:是对类图的补充,描述类的对象所有可能的状态以及事件发⽣时状态的转移条件。
在实⽤上并不需要为所有的类画状态图,仅为那些有多个状态其⾏为受外界环境的影响并且发⽣改变的类画状态图。
2、描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系,有利于识别并⾏活动。
第四类:交互图:包括顺序图 ,协作图(即合作图) 1、顺序图:强调的是时间和顺序的关系 2、协作图:强调的是上下级关系第五类:实现图:构件图,描述代码部件的物理结构及各部件之间的依赖关系。
从应⽤的⾓度看,当采⽤⾯向对象技术设计系统时,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构;第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的,包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语⾔UML的静态建模机制。
其中第三步中所建⽴的模型或者可以执⾏,或者表⽰执⾏时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语⾔UML的动态建模机制。
因此,标准建模语⾔UML的主要内容也可以归纳为静态建模机制和动态建模机制两⼤类。
总结:1、静态图:包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构; 2、动态图:包括状态图、活动图、顺序图和合作图等四个图形,是描述系统的⾏为;。
第1章UML简介在本章中,你将学习如下内容:●为什么需要UML?●UML的诞生。
●如何用图表示UML模型的各个部分?●为什么使用UML提供的不同类型的图对我们来说很重要?统一建模语言(Unified Modeling Language,UML)是当今世界上面向对象系统开发领域中最激动人心的工具之一。
为什么?UML是一种可视化的建模语言,它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图,并且提供一种机制,以便于不同的人之间有效地共享和交流设计结果。
交流思想是极为重要的。
在UML出现以前,系统开发往往是无计划的议题。
系统分析员尽力去获取客户的需求,用某种他自己能够理解(但客户不一定总能理解)的表示法来产生需求分析文档,然后将这个分析转交给一个程序员或者一个程序员小组,并且期待着最后所开发出的系统正是客户所需要的。
由于系统开发需要人与人之间的交流,因此在开发过程的每个阶段中都很可能潜伏着错误。
系统分析员可能没有正确理解客户的需求。
他编制的文档客户可能不能理解。
系统分析员经常编写出语句冗长、内容庞大的需求文档,项目组的其他成员很难用上这些文档,这真是添乱。
可笑的是,这些无足轻重的文档常常把重要的需求(以及需求之间的相关性)挤出人们的脑海之外。
因此,系统分析的结果对程序员来说可能很不明确,随后程序员据此构造出的程序很可能不仅难以使用而且根本不是客户所需要的最初问题的解决方案。
难道你不奇怪,为什么今天很多已经运行了很长时间的那些老系统既笨重、麻烦,而且又难以使用吗?1.1 在纷繁复杂中寻求解决问题的办法在计算机时代的早期,程序员们在编制程序之前几乎很少对手头问题进行详细的分析。
4 UML基础、案例与应用如果他们真地对问题进行了充分分析的话,问题也就不是如此了。
通常他们一开始就自底向上地编写程序,随着时间的进展代码不断扩充。
这种大胆进行尝试的做法添加了一丝浪漫色彩,但是在今天这样一个高商业风险的社会里,这样做被证明是不适当的。
如今,一个经过深思熟虑的计划至关重要。
客户必须理解开发组做什么,如果开发组没有充分理解客户需求的话(或者如果客户在半路改变了自己的想法),客户必须能够指出需求所发生的变化。
不仅如此,系统开发还是一个典型的群组工作,因此小组的每个成员必须要知道自己的那部分作品应该放到整体作品中的哪个位置(当然还得要知道这个整体作品是什么)。
随着世界变得越来越复杂,存在于这个世界中的基于计算机的系统也增加了复杂性。
这些计算机系统通常包括多个硬件和软件单元、跨越长距离的网络设施,还要连接到信息量堆积如山的数据库上。
如果你要创建一个成功的系统,怎么来对付这些问题的复杂性呢?最关键的一点是要用一种系统分析员、客户、程序员和其他系统开发所涉及到的人员能够理解和达成一致的方式来组织系统的设计过程。
UML就提供了这种组织方式。
不首先建立一个详细的蓝图,你不会马上开始建造一个诸如办公大楼这样的复杂建筑物。
同样,不首先编制一个详细的设计计划,那么你也不大可能马上就在这栋办公大楼中建立起一个复杂的系统。
拿给客户看的设计计划就如同建筑设计师拿给楼的买主的建筑物设计蓝图。
设计计划应该源于对客户需求的细致分析。
短的开发周期是当今系统开发的又一个显著特征。
当所要求的截止日期一个又一个地接踵而来时,可靠的系统设计是绝对必要的。
现代社会频繁发生的公司兼并使可靠的设计显得尤为必要。
当一个公司收购了另一个公司,新成立的组织可能要对正在进行中的开发项目的许多重要方面(实施工具、编程语言及其他)进行修改。
具有自我调整能力的“防弹项目蓝图”能够适应项目的大规模变更。
如果设计是稳定可靠的,即使实施过程中遇到了变化,实施过程照样能够平稳地进行。
可靠的设计需要一种能被系统分析员、开发人员和客户接受为标准的设计表示法,就像电子工程师在绘制电路图时所用的标准表示法以及在物理学中被作为标准的冯诺依曼图所用的表示法那样。
UML就是这样的表示法。
1.2 UML的诞生UML是Grady Booch、James Rumbaugh和Ivar Jacobson智慧的结晶,他们被人们称为“三个好朋友”。
这几位先生在20世纪80年代和90年代的初期分别在不同的组织里工作,各自设计他们自己的面向对象分析与设计方法学。
他们的方法学和其他同行竞争者相比取得了卓越的成果。
到20世纪90年代中期,他们开始相互借鉴,然后决定相互合作共同推进这项工作。
1994年,Rumbaugh加入到Rational 软件公司工作,而Booch早已经在那里工作。
第二年Jacobson也加入了Rational公司。
第1章UML简介5后面的事情,正如他们所说的,是具有历史意义的。
UML草案版开始在软件工业界流传开来,并且根据大量的反馈信息做了大幅度修改。
由于许多公司感到UML能够适应它们的战略目标,因此一个UML联盟蓬勃发展起来。
联盟的成员包括DEC、Hewlett-Packard、Intellicorp、Microsoft、Oracle、Texas Instruments、Rational和其他一些公司。
1997年,应“对象管理组”(Object Management Group,OMG)向外界征求标准建模语言的建议,联盟制订了UML 1.0版并提交给OMG。
后来联盟继续发展,产生了UML 1.1版,提交给OMG后,于1997年被OMG采纳为标准。
1998年OMG接管了UML标准的维护工作,并且又制订了两个新的UML修订版。
UML 成为软件工业界事实上的标准,并且仍在不断发展。
UML 1.3版、1.4版和1.5版先后诞生,最近OMG正式批准了2.0版。
大多数的面向对象模型和UML建模的相关图书,都是基于UML的早期版本,也就是说1.X版的。
在本书中,我将向你展示UML的新旧版本之间的区别。
1.3 UML的组成UML包括了一些可以相互组合为图表的图形元素。
由于UML是一种语言,所以UML 具有组合这些元素的法规。
这里先不介绍这些元素和规则,而是直接介绍UML各种图的用法,因为这些图是进行系统分析时要用到的。
UML提供这些图的目的是用多个视图来展示一个系统,这组视图被称为一个模型(model)。
一个系统的UML模型有点像一个建筑物按照比例缩小并经艺术家粉饰后的建筑模型。
在这里要注意的重要一点是一个UML模型只描述了一个系统要做什么,它并没告诉我们系统是如何被实施的。
下一小节将简单介绍UML中最常见的图和它们所表达的概念。
在第一部分的后部,你将能更仔细地审视每种图。
记住,由这些图再混合组图也是可以的,UML提供了扩展这些图1.3.1 类图考虑一下你周围的世界。
你周围的事物大部分都可能具有某些属性(特性),并且它们以某种方式体现出各自的行为。
我们可以认为这种行为是一组操作。
6 UML基础、案例与应用你还会发现,事物很自然地都有其各自所属的种类(汽车、家具、洗衣机……)。
我们把这些种类称为类。
一个类(class)是一类或者一组具有类似属性和共同行为的事物。
举一个例子,属于洗衣机(washing machine)类的事物都具有诸如品牌(brand name)、型号(model name)、序列号(serial number)和容量(capacity)等属性。
这类事物的行为包括“加衣物(accept clothes)”、“加洗涤剂(accept detergent)”、“开机(turn on)”和“关机(turn off)”等操作。
图1.1是一个用UML表示法表示的洗衣机属性和行为的一个例子。
矩形方框代表类的图标,它被分成3个区域。
最上面的区域中是类名,中间区域是类的属性,最下面区域里列出的是类的操作。
类图就是由这些类框和表明类之间如何关联的连线所组成。
图1.1 UML类图标注意类名、属性名和操作名之间的间隔。
在UML中,由多个单词组成的类名,每个单词的首字母要大写,并且单词和单词之间不用空格(例如,WashingMachine)。
属性名和操作名也遵从相同的约定,但其首字母不用大写(例如,acceptClothes)。
每个操作名的后面都有一对括号,我们将在第3章中解释其原因。
在第4章中,你将会看到有许多线条连接的矩形符号组成的类图,这些线条表示类之间是如何相关联的。
为什么要如此麻烦地考虑事物的分类和它们的属性及行为呢?为了与我们所处的这个复杂世界进行交互,大部分现代软件都模拟现实世界的某些方面。
几十年的经验告诉我们,当软件代表了现实世界中的事物的类时,采用这种模拟方式开发软件最容易。
类图就能为开发人员提供这种模仿现实世界的表达方式。
类图对系统分析也有很大帮助。
它可以让分析员使用客户所采用的术语和客户交流,这样就可以促使客户说出所要解决的问题的重要细节。
1.3.2 对象图对象(object)是一个类的实例,是具有具体属性值的一个具体事物。
例如,你的洗衣机的品牌可能是“Laundatorium”,型号为“Washmeister”,序列号为“GL57774”,容量为16磅。
图1.2中的图标说明了如何用UML来表示对象。
注意对象的图标也是一个矩形,和类的图标一样,但是对象名下面要带下划线。
在左边的这个图标中,具体实例的名字位于冒号的左边而该实例所属的类名位于冒号的右边。
实例的名字以一个小写字母开头。
也可能是一个匿名的对象,如图1.2右边的图标所示。
这仅仅意味着尽管你指明了对象所属的类,但你并没有提供一个具体的对象名。
第1章 UML 简介 7图1.2 UML 对象图标,左边的图标代表一个具名的对象,右边的图标代表一个匿名的对象1.3.3 用例图用例(use case )是从用户的观点对系统行为的一个描述。
对于系统开发人员来说,用例是一个有价值的工具:它是用来从用户的观察角度收集系统需求的一项屡试不爽的技术。
这对于那些试图建立一个供人使用的(而不是计算机设备使用的)系统是很重要的。
我们在第6章“介绍用例”、第7章“用例图”、第18章“收集系统需求”和第19章“开发用例”中还要详细讨论用例。
这里先举一个简单的例子。
你使用一台洗衣机,显然是为了洗衣服(wash clothes )。
图1.3说明了如何用UML 用例图来描述这个需求。
图1.3 UML 用例图代表洗衣机用户的直立小人形被称为参与者(actor )。
椭圆形代表用例。
注意参与者(它是发起用例的实体)可以是一个人也可以是另一个系统。
还应该注意,用例位于一个代表着系统的矩形中,而参与者在矩形之外。
1.3.4 状态图在任一给定的时刻,一个对象总是处于某一特定的状态。
一个人可以是新生儿、婴儿、儿童、少年、青年或者成人。
一个电梯可以处于上升或停止状态。
一台洗衣机可以处于浸泡(soaking )、洗涤(washing )、漂洗(rinsing)、脱水(spinning )或者关机(off )状态。