UML建模语言及工具课件

上传人:20****08 文档编号:242023209 上传时间:2024-08-10 格式:PPT 页数:70 大小:477.58KB
返回 下载 相关 举报
UML建模语言及工具课件_第1页
第1页 / 共70页
UML建模语言及工具课件_第2页
第2页 / 共70页
UML建模语言及工具课件_第3页
第3页 / 共70页
点击查看更多>>
资源描述
,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,-,*,-,UML,建模语言及工具,UML建模语言及工具,面向对象的设计,Object-Oriented Design,面向对象的设计Object-Oriented Design,学习线路图,OO,UML,OOA,OOP,DP,Case-Study,学 习 线 路 图,3,学习线路图OOUMLOOAOOPDP Case-Study,从需求到分析,Analysis workflow,Analysis Class,4,从需求到分析Analysis workflowAnalysi,从分析到设计,Design Class,Subsystem,Analysis Class,Design workflow,5,从分析到设计Design ClassSubsystemAna,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,数据库设计,6,内容安排从分析到设计6,分析 VS.设计,分析:做什么,Analysis emphasized the,business,problem,设计:怎么做,Design focuses on the,technical,or,implementation,concerns of the system,分析模型虽然有效地确定了将要构建的内容,但是却没有包含足够的信息来定义如何构建系统,而面向对象的设计用来填补分析和实现之间的差距,7,分析 VS.设计分析:做什么分析模型虽然有效地确定了将要构,设计模型 VS.分析模型-1,需要维护两个模型吗?,策略,结果,制作分析模型并精化成设计模型,有了单独的设计模型,但失去了分析模型,制作分析模型并精化成设计模型,然后用,CASE,工具重新获得分析模型,有了单独的设计模型,但是用,CASE,工具重新获得的分析模型可能并不令人满意,在细化阶段的某个点将分析模型冻结,然后把分析模型的一份拷贝精化成设计模型,有了两个模型,但是它们步调不一致,维护两个独立的模型,分析模型和设计模型,有了两个模型,并且它们步调一致,但是这增加了维护的负担,8,设计模型 VS.分析模型-1需要维护两个模型吗?策略结果制,设计模型 VS.分析模型-2,需要保留分析模型吗?,易于理解:分析模型提供系统的“大场景”,它可能只包括设计模型中的,1%,到,10%,的类,价值:,介绍新人加入项目,在交付几个月或几年后重新理解系统,理解系统是怎么满足客户需求以及提供可跟踪性,计划维护和增强,理解系统的逻辑架构,外包系统的构造,9,设计模型 VS.分析模型-2需要保留分析模型吗?9,设计模型 VS.分析模型-3,需要分别维护分析模型和设计模型的系统,庞大的,复杂的,战略性的,受经常变更所支配的,期望长期运行的,外包的,10,设计模型 VS.分析模型-3需要分别维护分析模型和设计模型,软件设计的定义,IEEE 1990,:设计是,体系结构,、,构件,、,接口,、以及系统,其它特征,定义的,过程,11,软件设计的定义IEEE 1990:设计是体系结构、构件、接口,更精确定义,软件设计(的结果)必须,描述系统的体系结构(,architecture,),系统如何分解(,decompose,)和组织(,organize,)构件,描述构件间的接口(,interface,),描述构件(,component,):必须详细到可进一步构造的程度,12,更精确定义软件设计(的结果)必须12,ISO/IEC 12207,按,ISO/IEC 12207,软件开发生存周期过程,软件设计由两个活动组成,软件体系结构设计,-software architectural design,顶层设计(,top-level design,),描述系统顶层的结构和组织,标识各个构件,软件详细设计,-software detailed design,充分描述每个构件使之可以编码,13,ISO/IEC 12207按ISO/IEC 12207软件开,软件设计的作用,软件设计在软件系统开发过程中扮演重要角色,开发者作出各种模型,形成实现时解决方案的蓝图,对这些模型进行分析和评价,以判定是否满足各种需求,便于考察备选方案和可行的替换措施,设计模型也可用于规划后续的开发活动,是编码和测试的输入,连接需求和构造的桥梁,14,软件设计的作用软件设计在软件系统开发过程中扮演重要角色连接需,RUP中的分析和设计工作流,分 析,Analysis,设 计,Design,15,RUP中的分析和设计工作流分 析Analysis设 计D,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,数据库设计,16,内容安排从分析到设计16,为什么需要体系结构,我们所定义的类或者对象其关注的重点是定义了一个系统的核心概念和行为,一个系统是由多个子系统组成,每个子系统中的领域对象都不只一个,这些类如何组织、分布并协同完成所需的功能?,因此系统应该要有一个总体的体系结构,它定义了各子系统之间的通信和耦合,体系结构包图(,architecture package diagram,),17,为什么需要体系结构我们所定义的类或者对象其关注的重点是定义了,软件体系结构定义,软件体系结构描述软件系统的子系统和构件及其相互关系,UML Reference Manual,:体系结构是一个系统的组织结构,包括系统分解成的各个部分、它们的连接性、交互机制和通知系统设计的向导规则,软件体系结构将多组类结合起来,形成一个有机的整体,并且展示各部分之间,结构,上的相互,关系,18,软件体系结构定义软件体系结构描述软件系统的子系统和构件及其相,软件体系结构风格,体系结构风格,style,提供软件系统高层组织的元模型,通用结构:,分层,、管道过滤器、黑板,分布式系统:,客户,-,服务器、三层,、中介,交互式系统:,MVC,、表示,-,抽象,-,控制,可适配系统:微内核、反映式,其它:批处理、解释器、进程控制、基于规则,19,软件体系结构风格体系结构风格style19,UML和体系结构,体系结构的全部内容就是复杂性管理:将解决方案划分成多个小的组成部分,再将这些小的部分结合起来,构成更大的、更加一致的结构,包(,package,),包依赖关系图(,package dependency diagram,),子系统(,subsystem,),层(,layer,),20,UML和体系结构体系结构的全部内容就是复杂性管理:将解决方案,包-package,包是一种将模型元素分组的机制,包主要用于,组织模型元素,配置管理单元,分包的原则,职责相似:将一组职责相似、但以不同方式实现的类归为一组有意义的包;如,java,类库中的,javax.swing.border,协作关系:包含了各种不同类型的类,它们之间通过相互协作实现一个意义重大的职责,21,包-package包是一种将模型元素分组的机制21,包依赖关系,包之间存在着依赖关系,如果,Client,包依赖于,Supplier,包:,Supplier,包的改变将影响到,Client,包,Client,包不能够独立的重用,因为它依赖于,Supplier,包,22,包依赖关系包之间存在着依赖关系22,避免循环依赖,循环依赖使得任何一个包都不能独立的重用,修改任何一个包都会引起所有的包的变化,23,避免循环依赖循环依赖使得任何一个包都不能独立的重用,修改任何,体系结构设计过程,1.确立目标,2.将类分组,3.展示技术,4.抽取子系统,5.针对准则和目标对体系结构进行评估,24,体系结构设计过程1.确立目标24,1.确立目标,一个好的体系结构其实是不断权衡、妥协、折衷的产物,可扩展性,可维护性,可靠性,可伸缩性,25,1.确立目标一个好的体系结构其实是不断权衡、妥协、折衷的产,2.将类分组并评估各个类,将分析类划分成几个候选包,并对它们的内聚性进行评估,目标是使每个包具有清晰的且严格定义的目的和职责,结合体系结构模式,考虑分组方式,实体类,用户界面类,控制类,系统接口类,描述包之间的耦合度:包依赖关系图,26,2.将类分组并评估各个类将分析类划分成几个候选包,并对它们,考勤卡系统的体系结构包图,27,考勤卡系统的体系结构包图27,3.展示技术,28,3.展示技术28,4.抽取子系统,29,4.抽取子系统29,5.针对准则和目标进行评估,30,5.针对准则和目标进行评估30,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,数据库设计,31,内容安排从分析到设计31,用例设计,Design workflow,Use Case,32,用例设计Design workflowUse Case32,从分析类到设计元素,33,从分析类到设计元素33,用例实现(设计),将设计应用于用例,1.,结合设计元素,定义设计对象间的交互(交互图),2.,利用,子系统,简化交互图,3.,描述与,持久化,相关的行为,4.,检查用例事件流的实现,5.,评价,类,和子系统,34,用例实现(设计)将设计应用于用例34,交互图的设计:职责分配,利用设计元素,进行类的职责分配,完成用例实现的交互图,职责分配模式:,GRASP,(,General Responsibility Assignment Software Pattern,)模式,专家模式、创建者模式,(,老板原则,),、,高内聚,、,低耦合,、控制者,多态、纯虚构、中介者、,不要和陌生人讲话(可视原则),35,交互图的设计:职责分配利用设计元素,进行类的职责分配,完成用,GRASP,:不要和陌生人讲话(可视原则),解决方案,分配职责给一个客户端的直接对象以使它与一个间接对象进行协作,这样客户端无需知道这个间接对象,这个模式也被称为,Demeter,准则,,在那些你需要在其上发送消息的对象上面放置一些限制条件,它表明在一个方法中,消息只能发往下面的对象:,对象本身;方法的一个参数;对象本身的属性;对象本身的一个属性集合中的元素;该方法内创建的对象,优点,低耦合,36,GRASP:不要和陌生人讲话(可视原则)解决方案36,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,37,内容安排从分析到设计37,子系统与接口,子系统是一种介于包和类之间的一种设计机制,它实现一个或多个接口所定义的行为,具有包的语义:能够包含其它模型元素,具有类的语义:具有行为,38,子系统与接口子系统是一种介于包和类之间的一种设计机制,它实现,子系统的作用,完全封装了行为,利用清晰的接口代表所拥有的能力,可以定义不同的实现,39,子系统的作用完全封装了行为39,子系统 VS.包,子系统:,提供行为,完全封装实现细节,容易替换,包:,不提供行为,不完全封装实现细节,难以替换,关键在于封装,40,子系统 VS.包子系统:包:关键在于封装40,子系统的主要用途,子系统可以将系统划分成独立的部分,以利于:,开发,只要保持接口不变,部署到不同分布的节点上,变更,而不影响到其它系统,在设计阶段,子系统还可用于打包遗留系统,子系统代表了粗粒度的组件,41,子系统的主要用途子系统可以将系统划分成独立的部分,以利于:4,子系统的设计原则,目标,松散耦合,可替换的,,plug-and-play,隔离变更,自身可独立的改进,好的建议,不要暴露细节,只有接口,仅依赖于接口,42,子系统的设计原则目标42,子系统的设计步骤,将子系统的行为分发到各个子系统元素中:分发子系统的,职责,描述子系统中的元素,描述子系统的依赖关系,43,子系统的设计步骤将子系统的行为分发到各个子系统元素中:分发子,接口设计,接口说明了一组操作,隐藏子系统的实现细节,在,GoF,的,23,种设计模式中,,Facade,模式是一种很好的接口的设计模式,确定系统的内聚部分,将这些打包到一个,为该子系统设计接口,44,接口设计接口说明了一组操作,隐藏子系统的实现细节44,考勤卡系统中的子系统设计,利用子系统来打包遗留系统,45,考勤卡系统中的子系统设计利用子系统来打包遗留系统45,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,46,内容安排从分析到设计46,设计类,设计类,设计模型的构造块,设计类是已经完成了规格说明并且达到能够,被实现程度的类,来源于问题域和解域,通过分析类的精化得到的问题域,添加实现细节,解域,提供了能够实现系统的技术工具,47,设计类设计类47,设计类剖析,在分析中,只要尽量捕获系统需要的行为,而完全不必考虑如何去实现这些行为,在设计中,则必须准确地说明类是如何履行它们的职责,完整的属性集合,包括详细说明的名称、类型、可视性和一些默认值,将分析类指定的职责转化成一个或多个方法的完整集合,48,设计类剖析在分析中,只要尽量捕获系统需要的行为,而完全不必考,良好的设计类,类的公共方法定义它和类用户之间的契约,通常要从类用户的角度去评估类的目的,基本特征,完整性和充分性,原始性,高内聚,低耦合,49,良好的设计类类的公共方法定义它和类用户之间的契约49,类设计的主要工作,定义类的操作,类的职责,定义类的方法和状态,方法:操作的实现,状态:对象的状态如何影响它的行为,(,状态图,),定义类的属性,定义类之间的关系,50,类设计的主要工作定义类的操作50,类之间的关系,依赖关系,关联关系,聚合关系,组合关系,泛化关系,低,耦,合,度,高,51,类之间的关系依赖关系低51,关联关系的表示方法,关联具有:名称、多重性表达式、导航符号、角色名称,名,称:动词短语,多重性表达式:*,,1.*,,,1-40,,,5,,,3,5,8,,,导航符号,角色名称,52,关联关系的表示方法关联具有:名称、多重性表达式、导航符号、角,聚合关系示例,一台,Computer,可能连接到,0.n,台,Printers,任何时候一台,Printer,连接到,0.1,台,Computer,随着时间推移,许多台,Computers,可以使用一台给定的,Printer,即使没有所连接的,Computers,,那台,Printer,也可以生存,在非常客观的意义上,那台,Printer,是独立于那台,Computer,的,聚合有时能够不依赖部分而存在,有时又不能,部分可以独立于聚合而存在,如果有一部分遗失,聚合会给人一种不完整的感觉,部分的所有权可以由几个聚合共享,53,聚合关系示例 一台Computer可能连接到0.n台Pri,组合关系示例,Button,离开,Mouse,对象则不能独立存在,销毁,Mouse,则也销毁,Mouse,,因为它们是,Mouse,对象整体的一个部分,每个,Button,只能仅仅属于一个,Mouse,(如树和树叶),部分在某一时刻仅仅只能属于一个组成,组成唯一地负责处理它的所有部分,负责它们的创建和销毁,倘若对于部分的职责有由其他的对象来承担的话,组合也可以放松这些职责,如果一个组成销毁的话,它必须将它所有的部分销毁,或者把负责处理它们的权力交给其他的一些对象,54,组合关系示例 Button离开Mouse对象则不能独立存在部,泛化关系,只有在两个设计类之间存在清晰明确的“,is a”,关系或为了复用代码才使用继承(但是注意不要因此引入耦合),缺点,类间可能耦合的最强形式:派生类会继承基类的属性、方法、关系,类层次中的封装是脆弱的,它会导致“脆弱基类”问题,基类的改动会直接波及底下的层次,在大多数语言中,继承非常不易改变,关系是在编译时确定的,关系在运行时是固定的,55,泛化关系只有在两个设计类之间存在清晰明确的“is a”关系或,可见性问题,动机:对象,A,若要对对象,B,发送消息,那么对象,B,必须对对象,A,可见,可见性(,Visibility,)是一个对象“看到”或者引用另一个对象的能力;更一般地讲,可见性与问题的范围有关:一个资源(如一个实例)是否在另一个资源的范围之内?,从对象,A,到对象,B,通常有四种可见性:,属性可见性(,attribute,),:,B,是,A,的一个属性,参数可见性(,parameter,),:,B,是,A,中一个方法的参数,局部声明可见性(,local,),:,B,在,A,的一个方法中被声明为一个局部对象,全局可见性(,global,),:,B,在某种程度上全局可见,56,可见性问题动机:对象A若要对对象B发送消息,那么对象B必须对,属性可见性,public class Host,private Dog dog;,57,属性可见性public class Host57,参数可见性,从,ShowMails,到,Mails,的参数可见性,public class ShowMails,static int putMails(Mails mail),if(currentMails=maxMails),System.out.println(Mailbox overwhelmed!);,return-1;,showListcurrentMails=mail;,currentMails+;,return currentMails;,58,参数可见性从ShowMails 到Mails的参数可见性58,局部声明可见性,从,Show,到,Mails,的局部声明可见性,public class Show,public static void main(String args),Mails newmail;,.,59,局部声明可见性从Show到Mails 的局部声明可见性59,全局可见性,60,全局可见性60,可见性问题示例,/,属性可见性,class POST,private ProductCatalog prodCatalog;,public void enterItem(int upc,int qty),spec:=prodCatalog.getSpecification(upc);,/,参数可见性,class Sale,public void makeLineItem(ProductSpecification spec,int qty),/,局部声明可见性,class POST,public void enterItem(int upc,int qty),ProductSpecification spec=prodCatalog.getSpecification(upc);,61,可见性问题示例/属性可见性/参数可见性/局部声明可见性,内容安排,从分析到设计,体系结构设计,用例设计,子系统设计,类设计,从设计模型到代码实现,62,内容安排从分析到设计62,设计模型与代码实现,编写代码形成软件,软件最终需要代码来实现,模型只是为代码实现提供支持,目前尚未产生成熟的可执行模型,正向工程(,Forward engineering,),由设计类图导出框架代码,由交互图创建方法实现,逆向工程(,Reverse engineering,),由源代码导出设计模型,63,设计模型与代码实现编写代码形成软件63,正向工程-生存框架代码,什么是框架代码?,代码在设计上的初步实现,类的框架代码包括那些?,属性值定义:名称、类型、缺省值等,方法定义:名称、参数、返回类型等,引用关系,根据设计类图产生框架代码,用方法和简单属性定义一个类,加入引用属性:角色名定义引用属性,64,正向工程-生存框架代码什么是框架代码?64,从设计类图产生框架代码-1,1.,用方法和简单属性定义一个类(,属性、方法、构造函数,),65,从设计类图产生框架代码-11.用方法和简单属性定义一个类(,从设计类图产生框架代码-2,2.,加入引用属性(,引用属性,reference attribute,:关联和导航;角色名,role name,),66,从设计类图产生框架代码-22.加入引用属性(引用属性ref,Rose支持框架代码的导出,利用,Rose,由设计类图生成框架代码(,Java,),新建一个基于,J2SE,的应用程序,选择缺省的语言为,Java,利用,Rose,建模,开始导出工作:,类的语法检查,设置导出路径,ClassPath,导出框架代码,主要问题:,设,计模型开发不够完善,无法导出代码,67,Rose支持框架代码的导出利用Rose由设计类图生成框架代码,其它问题-一对多关系的实现,68,其它问题-一对多关系的实现68,正向工程-创建方法实现,一个,交互图,显示出了响应方法调用而产生的消息传递;这些消息序列可以被翻译成方法实现中的一系列语句,由顺序图产生方法实现,由协作图产生方法实现,69,正向工程-创建方法实现一个交互图显示出了响应方法调用而产生的,示例,-POST,类,enterItem,方法实现,/1.1,创建,Sale,实例,if(isNewSale(),sale=new Sale();,/1.2,获得,ProductSpecification,ProductSpecification spec=,productCatalog.getSpecification(upc);,/1.3,添加销售项,sale.makeLineItem(spec,qty);,public void enterItem(int upc,int qty),if(isNewSale(),sale=new Sale();,ProductSpecification spec=,productCatalog.getSpecification(upc);,sale.makeLineItem(spec,qty);,由顺序图产生实现代码,70,示例-POST类enterItem方法实现/1.1创建Sa,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > PPT模板库


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!