软件工程第十二讲-UML.ppt

统一建模语言UML,UnifiedModelingLanguage,UML概述,为何研究UML结束方法大战发展历史1994年Booch和Rumbaugh在RationalSoftwareCorporation开始了UML的工作，其目标是创建一个“统一的方法”，1995年OOSE的创始人Jacobson加盟到这项工作中，工作重点转移到创建一种统一的建模语言UML1996年6月、10月、1997年1月、11月分别推出了UML0.9、UML0.91、UML1.0、UML1.1,UML概述,1997年11月，OMG(ObjectManagementGroup)批准把UML1.1作为基于面向对象技术的标准建模语言之后，UML进行了持续的修订和改进，先后产生了UML1.2、1.3、1.4、1.5版本2004年推出了UML2.0，UML2.0对UML1.x作了重大的修改,UML模型元素(V1.3),模型中的实体以及实体间相互连接的关系,UML模型元素(V2.0),模型中的实体以及实体间相互连接的关系,UML2.0的13种图-1,用况图(usecasediagram)类图(classdiagram)对象图(objectdiagram)构件图(componentdiagram)组合结构图(compositestructurediagram)顺序图(sequencediagram)通信图(communicationdiagram),交互图(interactiondiagram),UML2.0的13种图-2,状态机图(statemachinediagram)活动图(activitydiagram)部署图(deploymentdiagram)制品图(artifactdiagram)包图(packagediagram)时间图(timingdiagram)交互概览图(interactionoverviewdiagram),UML图1-用况图,描述参与者与用况(参与者使用系统以实现某一特定目标的情形)之间的关联关系，以及用况之间的扩展、继承等关系,UML图2-类图,展现一组类、接口以及它们相互之间的关系,2条或2条以上的线交于0个或1个点,UML图3-对象图,展现一组对象以及相互之间的关系，是依照类图所建立的一组事物(实例)的静态快照,UML图4-构件图,描述构件、接口以及构件间的组装关系的静态视图，复合构件本身可以由内部的子构件图描述,UML图5-组合结构图,UML2.0新增的图，展示了类或协作的内部结构，与构件差别不大，经常认为与构件图等同,UML图6-顺序图,描述特定场景下交互各方消息发送和接收的顺序,UML图7-通信图,另一种交互图，强调交互上下文：参与交互的对象或角色的结构组织,UML图8-状态机图,以状态机的形式描述目标对象在各种事件作用下的行为,UML图9-活动图,描述一系列活动之间的控制流和数据流,UML图10-部署图,描述系统运行时各相关处理单元结点、各结点上部署的构件、以及相互间的通信协议,UML图10-部署图变体:制品图,部署图的变体：描述系统实现制品的物理结构，制品包括文件、数据库等,这两个物理文件“承载了”逻辑类HelloWorld的实现,UML图11-包图,描述包(一种模型分解单位)以及包之间的关系,UML图12-时间图,UML2.0新增的图，描述对象间的交互，但关注于关于时间的推理，而不仅仅是相对顺序,添水,加热,UML图13-交互概览图,UML2.0新增的图可认为是：活动图+顺序图的混合体使用活动图的表示法，其中的节点或者是一个交互或者是一个交互引用,UML2.0的视图和图,需求,设计,实现部署,UML视图1-用况视图,描述可被最终用户、分析人员和测试人员看到的系统(外部)行为不涉及系统的内部结构，但却是系统体系结构设计的驱动力静态方面：用况图动态方面：交互图、状态机图、活动图,UML视图2-设计视图,描述系统设计方案，主要包括类、接口以及相互之间的协作关系静态方面：类图、对象图动态方面：交互图、状态机图、活动图,UML视图3-交互视图,展示系统不同部分之间的控制流，包括并发和同步机制主要针对系统的非功能性方面，例如性能、可伸缩性、吞吐量等静态方面：类图、对象图动态方面：交互图、状态机图、活动图与设计视图的区别：突出控制系统的主动类以及各部分间消息的流动,UML视图4-实现视图,描述组成最终产品发布的相关制品及其关系，实现单元体现为可装配、打包并发布的文件体现了逻辑单元(类和构件)到物理制品(物理构件、文件等)的映射静态方面：构件图动态方面：交互图、状态机图、活动图,UML视图5-部署视图,描述最终产品物理部署的拓扑结构包括组成整个系统的各种分布式硬件设备，以及各个软件模块在这些设备上的部署和运行关系静态方面：部署图动态方面：交互图、状态机图、活动图,内容摘要,面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模,用况建模,用况：文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形用况建模用于描述一个系统应该做什么，用用况图来描述(可能有多幅)用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能,用况图,用框图展示各类外部执行者(actor)与系统所提供的用况之间的参与关系，包括：系统边界、用况执行者(参与者)：可能使用这些用况的人或外部系统，参与者与用况连接表示参与者使用了该用况模型元素间关系：关联、扩展、包含、泛化等每个用况的细节通常用文字描述，也可以用活动图来描述,用况之间的关系-1,用况之间的关系-2,电话订购系统用况图,客户,售票员,送货员,主管,建立信用,供应订单,订单支付,提供客户数据,产生订单,信用卡支付,现金支付,设置订单,请求目录,电话订购,include,include,include,extend,核对身份,关联,扩展,包含,泛化,包含,泛化,参与者之间的泛化关系,用况图对于各方的作用,客户：用况模型指明了系统的功能，描述了系统能如何使用开发者：用况模型帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据集成测试和系统测试人员：根据用况来测试系统，以验证系统是否完成了用况指定的功能,用况建模步骤,定义系统(总体范围)确定参与者确定用况描述用况定义用况间的关系确认模型,用况建模定义系统范围/边界,根据项目的总体目标/任务以及基本的开发决策决定做什么不做什么总体目标/任务：实现出版社书籍的网上销售开发决策：网上支付采用银联支付系统、书籍的基本信息来自于出版社已有的编辑和发行管理系统(遗产系统)边界外的人或系统(第三方系统、遗留系统等)成为候选的参与者,用况建模确定参与者,参与者是指与系统交互的人、组织或其它系统参与者代表一种角色，而不是具体的人可分成主参与者和辅助参与者主参与者是用况的直接执行者，例如保险系统中业务员处理保险的注册和管理辅助参与者对于用况的执行起辅助作用，例如保险系统中管理员负责分配业务员权限,确定参与者的启发式问题,谁使用系统的主要功能(主执行者)谁需要从系统中得到对他们日常工作的支持谁需要维护、管理和维持系统的日常运行系统需要控制哪些硬件设备系统需要与哪些其它系统交互哪些人或哪些系统对系统产生的结果(值)感兴趣,用况建模确定用况,用况的特征用况总是由参与者启动的执行者必须直接或间接地指示系统去执行用况用况向参与者提供服务或返回结果，这些结果必须是可识别的用况是完整的，一个用况必须是一个完整的描述(有开始、有结果),用况(UseCase),文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形例：顾客携带所购商品到达收银台，收银员使用POS系统记录每件商品，系统连续显示累计金额并逐行显示细目，顾客输入支付信息，系统对支付信息进行验证和记录，成功后更新库存信息，顾客从系统得到购物小票然后离开,场景(Scenario),使用系统的一个特定情节或用况的一条执行路径，即用况实例(UseCaseInstance)主成功场景：顾客携带商品到收银台，顺利地完成商品扫描及信用卡付款等全过程替代场景1：商品扫描失败，提示输入商品唯一码替代场景2：信用卡划账通讯失败，提示客户使用现金结帐替代场景n：用户信用卡支付成功后要求退货因此用况就是一系列可能的场景集合,确定用况的启发式问题,执行者需要系统提供哪些功能？执行者需要系统做什么?执行者是否需要读、创建、删除、修改或储存系统中的某类信息?执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情?从功能观点看，这些事件表示什么?执行者的日常工作是否因为系统的新功能(尤其是目前尚未自动化的功能)而被简化或提高效率,用况建模描述用况,使用文本描述用况的目的用况是如何启动的：哪个参与者在什么情况下启动(前提)参与者和用况之间的消息流(步骤)主消息流和其它消息流是什么根据条件或异常情况等选择不同的流程分支系统中哪些实体被使用或修改(结果)，如何确定用况执行结束使用活动图描述,用况的简要文字描述,执行者的简要描述，如客户：向公司订购商品的人客户代表：公司处理客户请求的雇员库存系统：记录公司库存的软件用况的简要描述，如订购货物：客户创建一个新的请求商品的订单，并为那些商品付费取消订单：客户取消一个已经存在的订单,用况的详细描述,用况名称、参与者用况的前置条件和后置条件：用况开始和结束的条件事件流：一系列陈述句，从参与者的角度出发的一系列步骤一般有多个事件流：主要流程、其它流程特殊需求：相关的非功能性需求,用况的详细描述结构,POS系统收银用况详细说明-1,POS系统收银用况详细说明-2,POS系统收银用况详细说明-3,确定用况之间的关系,关联：参与者与用况扩展：用况与用况包含：用况与用况泛化：用况与用况,实例,本实例实现一个简化了的银行储蓄账户管理系统，该系统是在银行的柜台上对客户办理活期储蓄业务。系统的需求陈述如下：一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户。客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行间转账）。系统管理员负责系统的账户管理及业务报表的生成。,识别执行者客户：到银行办理储蓄业务的人，负责输入密码银行职员（客户代理）：银行工作人员，代表客户进行储蓄业务的操作银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成,识别用况从系统的需求陈述可知，银行职员（客户代理）需要系统提供开户、存款、取款、转账、注销账户等功能，这些功能都包含了校验密码的功能。系统管理员需要系统提供账户管理和报表生成功能。银行职员（管理人员）则参与了账户管理中的更新账户的功能。此外，转账功能可分为银行内转账和银行间转账，我们可将它们设计成三个用况，其中银行内转账用况和银行间转账用况都继承了基本转账用况。据此分析，得到该系统的用况图如下图所示。,开户用况描述用况名称：开户参与的执行者：银行职员（客户代理），客户前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流：1.当选择开户功能时用况开始2.输入客户信息（姓名、地址、身份证号等）3.从账户管理系统获取新的账号4.请客户输入密码5.请客户再次输入密码6.如果两次密码不一致则回到第4步，否则继续7.在账户库中添加新账户8.打印存折，用况结束后置条件：在账户库中增加了一个新账户，得到一张新存折,取款用况描述用况名称：取款参与的执行者：银行职员（客户代理）前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流：基本路径：1.当选择取款功能时用况开始2.当输入客户信息（姓名、账号等）后a）如果客户信息与账户不一致，显示错误信息，可以重新输入或结束用况b）如果该账户被冻结（如因挂失而冻结），显示冻结信息并结束用况3.输入并校验密码,4.输入取款金额，如果该账户的余款小于取款金额，显示错误信息，要求重新输入5.打印取款单，交客户签字6.建立取款事件记录，更新账户信息7.打印存折，用况结束可选路径：1.在第5步客户签字之前的任何时刻，客户可以取消本次取款，用况结束2.第3步校验密码时，如发现密码不一致，则重新输入密码，或用况结束后置条件：如果取款成功，客户账户中的余额被更新（减少），否则余额不变。,取款用况的活动图描述,内容摘要,面向对象的基本概念面向对象的分析和设计过程UML概述用况建模静态建模动态建模物理体系结构建模,类图和对象图,类和对象模型的基本模型元素有类、对象以及它们之间的关系对象图是类图的实例，描述某一时刻类图中类的特定实例以及这些实例之间的特定链接对象图使用了与类图相同的符号，只是在对象名下附加下划线，对象名后可接以冒号和类名，即object-name:class-name系统中的类和对象模型描述了系统的静态结构,类图和对象图的基本元素,类图和对象图(例),类图中类之间的关系,关联关系,从参与方数量分：二元关联、多元关联从参与限制：受限关联整体和部分的关联：聚集和组合,二元关联,二元关联表示为在两个类之间用一条直线连接，直线上可写上关联名,关联的重数限制和角色,与自身的关联,自身关联中的角色,多元关联(例),多元关联的对象图(例),受限关联,受限关联用于一对多或多对多的关联限定符用来区分关联“多”端的对象集合，它指明了在关联“多”端的某个特殊对象,聚集,聚集(aggregation)是表示整体-部分关系的一种关联聚集中的“部分”对象可以是多个“整体”对象的一部分(共享非独占),组合,组合(composition)是一种更强形式的关联代表整体的组合对象有管理它的部分对象的特有责任，如部分对象的生成和释放组合关联具有强的物主身份，即“整体”对象拥有“部分”对象，“部分”对象生存在“整体”对象中,关联类,某些关联关系本身具有复杂的性质，可以独立为一个类关联类往往可以转换为多元关联,关联类间的导航,导航可理解为从一个类的对象访问到另一个类的对象,关联类间的导航(例),泛化关系,泛化表示类间的一般特殊关系(is-a)一般类定义了它的特殊类的公共属性和操作对一般类扩展一些属性和/或操作后，可以特化(specialize)成特殊类一般类是特殊类的父类，特殊类是一般类的子类特殊类可以继承一般类的属性和操作子类可以定义自己的属性和操作，也可重新定义父类中的操作，但重新定义的操作必须与父类具有相同的型构(signature),泛化关系例,泛化关系例,泛化是一种分类学关系，一个一般类可以从不同的维或方面进行特化例如学生可以从性别、学习阶段(研究生、本科生、中学生等)等不同维度进行特化用类元(用作分类符)来表示分类的维度或方面，对应的特殊类组成一个泛化集在泛化集中可对其元素应用约束，在UML中提供以下约束，见下表,泛化集的约束,泛化集的约束(例),实现关系表示一个模型元素对于一个行为规约(specification)的实现关系例如类对于接口的实现，设计类对于分析类的实现泛化和实现都可以将一般描述与具体描述联系起来，其区别是：泛化是同一语义层(例如都是类)上的元素之间的连接实现是不同语义层中的元素之间的连接，通常建立在不同的模型内，如设计类到分析类的实现关系,实现关系,实现关系(例),依赖关系,依赖表示两个或多个模型元素之间语义上的依赖关系例如网上书店中的交易通知依赖于邮件发送依赖关系用一个虚线箭头表示，箭头上可附加说明依赖类型的关键字UML2.0中的依赖种类如下：Access(访问),bind(绑定),call(调用),create(创建),derive(派生),instantiate(实例化),permit(允许),realize(实现),refine(精化),send(发送),substitute(替换),trace(追踪依赖),use(使用),依赖关系(例),约束和派生(constraintpublicvoiddoOne()myB.doTwo();myB.doThree();,顺序图中的生存线(例),attribute=name(argument-list):return-valueattribute是生命线的属性(对象名)，用以存储返回值name是消息名(信号或操作名)argument-list是一个参数值的表，每个参数值可以是：argument-valueparameter-name=argument-value：表示任何参数值name可以用“*”替代，此时表示任何消息,顺序图中消息的表示,简单消息表示消息类型未知或与消息类型无关，或是一个同步消息的返回同步消息表示发送对象必须等接收对象完成消息的处理后才能继续执行异步消息表示发送对象在消息发送后立即继续执行，而不必等待接收对象的返回传送延迟可用倾斜的箭头表示，意思是消息发送后需经历一段延迟时间才被接收(可以注明最大延迟时间),顺序图中的消息类型,顺序图中的条件和分支,消息上可附加条件，当条件为真时消息才被发送或接收。条件可用于描述分支，当几个消息箭头上的条件互斥时，表示某一时刻只有一个消息被发送。如果条件不是互斥的，则消息会并行地发出。,顺序图中的循环和约束,顺序图中的递归,顺序图中的创建和消亡,一个对象可以通过一条消息创建另一个对象。当需要显式地表示对象的销毁(没有垃圾自动回收机制或特别指明不再使用)时，在图中用一个符号表示。创建或消亡一个对象的消息通常是同步消息。,顺序图的结构化控制结构,对于复杂的控制流可以用组合片段来表示一个组合片段有一个关键字和一或多个子片段关键字指明片段类型子片段指出操作对象,ref(引用)：对另一交互的引用loop(循环)：当循环的警戒条件为真时循环执行子片段alt(选择)：两个或多个子片段之间的选择执行每个子片段有一个警戒条件，为真时执行该子片段如果多个子片段的警戒条件为真，则无确定性地选择它们中的一个执行如果没有一个子片段的警戒条件为真，则不执行,组合片段的类型-1,opt(可选)：选择的带单个子片段的特殊情况，警戒条件为假时省略该子片段par(并发)：两个或多个子片段的并发执行在不同片段中消息的相关顺序是不确定的当所有子片段完整地并发执行后，控制流又连接到一起成为单一的流,组合片段的类型-2,引用,循环,选择(嵌套),通信图,通信图展示了链接的对象之间如何发送消息，可用于描述系统中的操作执行、用况执行或一个简单的交互场景通信图画成对象图，图中的消息箭头表示对象之间的消息流消息上可标以标记，说明消息发送的顺序，还可指明条件、重复和回送值等一个通信图从一个引起整个交互或协作的消息开始，如用户界面上的操作与顺序图相比，通信图更强调交互对象之间的关系(context),链：连接两个对象的交互路径,消息传递的方向,消息及消息顺序编号,不带顺序编号的起始消息,同步调用中的嵌套消息,电梯运行过程的通信图,链是类关联的实例，是连接两个对象的路径，指明了对象间某种可能的导航和可见性。通信图中的消息在链上流转，多个消息可以共享一条单链。链角色上可以附加相应的约束，包括：global（全局）表示该角色是全局的；local（局部）表示该角色是一个操作中的局部变量；parameter（参数）表示该角色是一个操作中的参数；self（自身）指出对象可以向自身发送消息。,通信图