面向对象设计-设计方法以及设计工具分享.pptx

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2020/2/13,#,面向对象设计,设计方法以及设计工具分享,（,1,）,2025/3/15 周六,1,软件建模,模型是对现实的简化。好的模型包含有广泛影响的主要元素，而忽略与给定不相关的次要元素，形成语义上闭合的系统抽象,。,建模是为了更好理解正在开发的系统。人对复杂问题的理解能力是有限的，通过建模，缩小所研究问题的范围，实现“各个击破”。,好处：,1,）精确表达领域需求；,2,）进行系统设计；,3,）设计分离；,4,）代码生成；,2,2025/3/15 周六,目录,1,需求模型,2,分析模型,3,设计模型,4,物理架构模型,5,代码导出,3,2025/3/15 周六,1,需求模型,1.1,用例模型,识别角色,识别用例,用,例图,1.2,用例描述,1.3,界面设计,基本要求,主要工作,4,2025/3/15 周六,1.1,用例模型,用例,是一个角色使用系统的某项功能时交互过程的文字描述。用例的本质是系统中各个相关人员之间就系统的行为所达成的契约，是系统的,功能性需求,。,用例是面向对象,系统设计的起点，是类、对象、操作的,来源,用,例图包括角色、系统边界、用例以及元素间的关联,。,首先识别出角色，根据角色再识别,用例。,5,2025/3/15 周六,1.1,用例模型,-,识别角色,角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。,角色应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。角色之间存在继承,关系,。,通过回答以下,6,个问题来,识别系统,的,角色。,6,2025/3/15 周六,1.1,用例模型,-,识别角色,谁,使用系统的主要,功能？,无,谁需要系统的支持以完成,日常工作,？,无,谁负责维护、管理并保持系统正常运行？,运维人员,系统,需要应付哪些,设备？,不需要,系统,需要和哪些外部系统,交互？,艺龙接口，畅联接,口,谁,或什么对系统运行结果,感兴趣？,酒店,模块,7,2025/3/15 周六,1.1,用例模型,-,识别用例,根据角色来识别用例，识别用例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大,。,一般通过回答,3,个问题来识别用例。我们以角色“,酒店模块,”为例，根据这个角色来识别相关的用例。,8,2025/3/15 周六,1.1,用例模型,-,识别用例,某个角色要求系统为其提供什么功能,？,酒店模块主要,调用,UIP,完成外联访问功能。,该,角色需要做哪些工作,？,该模块需要,配置引用,UIP,的类库,，并,配置对,UIP,的访问地址,。,角色,需要阅读、创建、销毁、更新或存储系统中某些信息吗,？,酒店模块需要,查询酒店房型信息,，,创建订单,，,撤消订单,和,对订单历史进行查询,。,9,2025/3/15 周六,1.1,用例模型,-,用例图,Q1,用例抽象原则,Q2,关于,SystemBoundary,10,2025/3/15 周六,1.2,用例模型,-,用例描述,用例描述是通过文字语言描述用户的实际需求，用例采用自然语言描述角色和系统进行交互时双方的行为，不追求形式化的,语言,一般应该包括以下的内容：用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状态；其他需要描述的内容。,11,2025/3/15 周六,1.2,用例模型,-,用例描述,用例名称,酒店查询,综述,酒店模块通过调用,UIP,，来访问外联接口，取得查询结果,前置条件,类库引用正确，访问地址配置正确,后置条件,发起查询接口调用,基本操作流,1,、,UIP,提供查询接口供引用；,2,、酒店业务创建查询接口对象；,3,、酒店业务创建查询请求对象；,4,、酒店业务调用查询接口对象的酒店查询方法；,5,、酒店业务取回查询结果,可选操作流,可选流,1,：,可选流,2,：,12,2025/3/15 周六,1.3,用例模型,-,界面设计,界面建模是需求工作中重要的步骤，同时又属于设计工作的,内容,界面建模放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易,理解。,1,）完整的体现出用户需求的表现,形式；,2,）符合用户群的习惯、感官、,感觉；,3,）符合用户习惯性的工作过程,13,2025/3/15 周六,1.3,用例模型,-,界面设计,确定界面,元素,设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用,系统,针对用户设计,行业特点、用户的使用水平、,喜好,建立用户界面模型，并且同用户进行交互,用户对功能需求相对明确，对界面需求比较模糊，通过交互挖掘界面需求,14,2025/3/15 周六,1,需求模型,-,小结,用例建模推荐用,Rose,，方便直观,用例描述推荐用,Table,，整体性强，层次分明,界面建模推荐用,Visio,，能可视化操作，并可以发布成,网页,用,20%,的用例描述,80%,的需求,识别角色,识别用例,画用例图,用例描述,界面设计,15,2025/3/15 周六,2,分析模型,2,.1,架构设计,分层架构设计,4+1,视图方法,2.2,获取分析类,2.3,用例实现,活动图,/,状态图,时序图,/,协作图,2.4,整理分析类,绘制类图,16,2025/3/15 周六,2,分析模型,分析是一个十分关键的过程，它是把需求转化为代码实现的中间阶段。软件分析是将自然语言表达的软件需求进一步进行解析的过程。软件设计就是从分析到软件实现的过程。,17,2025/3/15 周六,2.1,架构设计,架构设计决定了各子系统如何组织以及如何协调工作,。,常用的架构技术有分层架构和,4+1,视图方法,18,2025/3/15 周六,2.1,架构设计,-,分层架构,分层架构：,好处：,不,需要去了解层的实现,细节,；可以,使用另一种技术来改变基础的层，而不会影响上层的,应用；,可以减少不同层之间的,依赖,；,容易制定出层,标准,；底下的层可以用来建立顶上层的多项服务；分层有利于标准化工作的,执行,坏处：,层次,不能封装所有东西，有时候会带来级联修改,；,过多的层间数据传递会影响性能,；,困难：,分层架构中最困难的问题就是决定建立哪些层以及每层的职责,19,2025/3/15 周六,2.1,架构设计,-,分层架构,20,2025/3/15 周六,2.1,架构设计,-4+1,视图,21,2025/3/15 周六,2.1,架构设计,-4+1,视图,逻辑视图（,Logical View,），设计的对象模型。,进程视图（,Process View,），捕捉设计的并发和同步特征。,部署视图（,Deployment View,），描述了软件到硬件的映射，反映了分布式特性。,实现视图（,Implementation View,），描述了在开发环境中软件的静态组织结构。,用例视图（,Use-Case View,），该视图是其他视图的冗余（因此,1,）。,22,2025/3/15 周六,2.1,架构设计,-4+1,视图,23,2025/3/15 周六,2.1,架构设计,-4+1,视图,是多个视图，不是多个架构。多个视图组成一个,架构,保持架构视图之间的,同步，也就是,要保证不同视图之间是相互解释的、而不是相互矛盾,的,视图数量由具体实践状况决定,24,2025/3/15 周六,2.2,获取分析类,类图的获取是一个不断细化的过程，一般我们先从分析类开始。分析类是概念层面上的类，是进行类设计的基础，获取分析类是系统分析中一项很重要的工作。获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类,25,2025/3/15 周六,2.2,获取分析类,用例描述中出现了哪些实体？,用例的完成需要哪些实体的合作？,用例执行过程中会产生并存储哪些信息？,用例要求与之相关联的每个角色的输入是什么？,用例返回与之相关联的每个角色的输出是什么？,用例需要操作哪些硬件设备？,26,2025/3/15 周六,2.2,获取分析类,27,2025/3/15 周六,2.3,用例实现,-,活动图,/,状态图,28,2025/3/15 周六,2.3,用例实现,-,时序图,/,协作图,29,2025/3/15 周六,2.4,整理分析类,整理分析类主要是依据用例实现部分的一系列的交互图。我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。但是这些类还没有属性、职责。我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来,30,2025/3/15 周六,2.4,整理分析类,-,示例,31,2025/3/15 周六,2,分析模型,-,小结,类之间并不是孤立的，利用类之间的关系就可以找到另一个,类,属性是分析类的基本内容。属性的基本来源是用例的事件流描述,。,类不仅仅是从选择建设项目这个用例获取的信息，它是综合了所有相关的用例分析的,结果,。所以要考虑每个用例的情况，进行归纳总结,32,2025/3/15 周六,3,设计模型,3.1,映射分析类到设计类,3.2,整理设计类,3.3,更新用例实现,33,2025/3/15 周六,3.1,映射分析类到设计类,设计类是指设计层面的类，映射分析类到设计类的过程实际上就是细化分析类的属性、方法，使类达到可以进行面向对象编程的程度,。,类的属性和方法应该按照,UML,中的格式,表示,：属性格式和操作格式,可见性属性名：类型,多重性次序,初始值特性,可见性操作名（参数列表）：返回类型,特性,34,2025/3/15 周六,3.1,映射分析类到设计类,35,2025/3/15 周六,3.2,整理设计类,在最终的类图上并不是所有的类都是由分析类映射而来的，系统中的绝大部分类都是由分析类映射而来的。在完成映射之后，还需要对已有的类根据设计原则进行优化,。,36,2025/3/15 周六,3.2,整理设计类,开放,-,封闭原则（,OCP,）,对于扩展是开放的，对于更改是封闭的,Liskov,替换原则（,LSP,）,子类型（,subtype,）必须能够替换掉它们的基类型（,base type,）,依赖倒置原则（,DIP,）,高层模块不应该依赖于低层模块。二者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象,接口隔离原则（,ISP,）,不要强迫客户依赖于它们不用的方法,37,2025/3/15 周六,3.3,更新用例实现,当完成了类的设计后，需要根据类的设计更新在分析阶段的用例实现,38,2025/3/15 周六,3,设计模型,-,小结,一般完成了,类的属性、方法的设计,就可以了，由开发人员在程序编写过程中设计类中方法的具体实现。,如果条件允许在设计阶段尽量对,类的重要方法进行,设计,，因为,概要设计和详细设计一气呵成，设计中的问题会相对,较少,。,通过,自然语言、伪代码、流程图,来实现详细设计，开发人员很容易理解设计者的意图，并很快将其实现。,39,2025/3/15 周六,4,物理架构模型,组件,图,主要目的是显示系统组件间的结构关系,部署图,描述系统硬件的物理拓扑结构以及在此结构上运行的软件,40,2025/3/15 周六,5,代码导出,41,2025/3/15 周六,PS 1:,重要输出,编码规范：信息形式、接口规约、命名,规则,物理模型：,组件图,、部署图,不同角度的构架视图：,用例视图,、逻辑视图、进程视图,、实施,视图、数据视图（可选,）,系统,总体布局,：哪些部分组成、各部分在物理上、逻辑上的相互,关系,与需求功能的关系,：,对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）,逻辑与物理位置,：,每个对象在逻辑上分别落在哪一层、哪个模块、哪个类,42,2025/3/15 周六,PS 2:,数据库设计,在面向对象中，是没有数据流这一说法的。业务的完成是由对象及消息来完成的，只有“对象流”，没有,数据流,先,忘记,数据库的存在，采用对象分析方法，先把对象分析和定义出来，保证业务执行逻辑能够被这些对象很好的,完成,然后,考虑,对象持久化的问题。依据数据库的三大范式以及性能要求来把对象持久,化,面向对象设计解决业务执行逻辑问题，数据库设计解决数据高效的问题,43,2025/3/15 周六,THANKS.,2011,年,10,月,ahpo 7722434,2025/3/15 周六,44,