面向对象设计设计方法以及设计工具分享PPT文件格式下载.pptx

1、用例的本质是系统中各个相关人员之间就系统的行为所达成的契约，是系统的功能性需求。用例是面向对象系统设计的起点，是类、对象、操作的来源用例图包括角色、系统边界、用例以及元素间的关联。首先识别出角色，根据角色再识别用例。51.1 用例模型-识别角色角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。角色应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。角色之间存在继承关系。通过回答以下6个问题来识别系统的角色。61.1 用例模型-识别角色谁使用系统的主要功能？无谁需要系统的支持以完成日常工作？无谁负责维护、管理并保持系统正常运行？运维人员系统需要应付哪些设备？不需要系统需要和哪

2、些外部系统交互？艺龙接口，畅联接口谁或什么对系统运行结果感兴趣？酒店模块71.1 用例模型-识别用例根据角色来识别用例，识别用例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大。一般通过回答3个问题来识别用例。我们以角色“酒店模块”为例，根据这个角色来识别相关的用例。81.1 用例模型-识别用例某个角色要求系统为其提供什么功能？酒店模块主要调用UIP完成外联访问功能。该角色需要做哪些工作？该模块需要配置引用UIP的类库，并配置对UIP的访问地址。角色需要阅读、创建、销毁、更新或存储系统中某些信息吗？酒店模块需要查询酒店房型信息，创建订单，撤消订单和对订单

3、历史进行查询。91.1 用例模型-用例图Q1 用例抽象原则 Q2 关于SystemBoundary101.2 用例模型-用例描述用例描述是通过文字语言描述用户的实际需求，用例采用自然语言描述角色和系统进行交互时双方的行为，不追求形式化的语言一般应该包括以下的内容：用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状态；其他需要描述的内容。111.2 用例模型-用例描述用例名称用例名称酒店酒店查询综述酒店模块通过调用UIP，来访问外联接口，取得查询结果前置条件类库引用正确，访问地址配置正确后置条件发起查询接口调用基本操作流1、U

4、IP提供查询接口供引用；2、酒店业务创建查询接口对象；3、酒店业务创建查询请求对象；4、酒店业务调用查询接口对象的酒店查询方法；5、酒店业务取回查询结果可选操作流可选流1：可选流2：121.3 用例模型-界面设计界面建模是需求工作中重要的步骤，同时又属于设计工作的内容界面建模放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易理解。1）完整的体现出用户需求的表现形式；2）符合用户群的习惯、感官、感觉；3）符合用户习惯性的工作过程131.3 用例模型-界面设计确定界面元素设计目的是让最终用户能够获得美感、提高工作效率、易于

5、操作使用系统针对用户设计行业特点、用户的使用水平、喜好建立用户界面模型，并且同用户进行交互用户对功能需求相对明确，对界面需求比较模糊，通过交互挖掘界面需求141 需求模型-小结用例建模推荐用Rose，方便直观用例描述推荐用Table，整体性强，层次分明界面建模推荐用Visio，能可视化操作，并可以发布成网页用20%的用例描述80%的需求识别角色角色识别用例用例画用例画用例图用例描述用例描述界面界面设计152 分析模型2.1 架构设计分层架构设计4+1视图方法2.2 获取分析类2.3 用例实现活动图/状态图时序图/协作图2.4 整理分析类绘制类图162 分析模型分析是一个十分关键的过程，它是把需

6、求转化为代码实现的中间阶段。软件分析是将自然语言表达的软件需求进一步进行解析的过程。软件设计就是从分析到软件实现的过程。172.1 架构设计架构设计决定了各子系统如何组织以及如何协调工作。常用的架构技术有分层架构和4+1视图方法182.1 架构设计-分层架构分层架构：不需要去了解层的实现细节；可以使用另一种技术来改变基础的层，而不会影响上层的应用；可以减少不同层之间的依赖；容易制定出层标准；底下的层可以用来建立顶上层的多项服务；分层有利于标准化工作的执行坏处：层次不能封装所有东西，有时候会带来级联修改；过多的层间数据传递会影响性能；困难：分层架构中最困难的问题就是决定建立哪些层以及每层的职责1

7、92.1 架构设计-分层架构202.1 架构设计-4+1视图212.1 架构设计-4+1视图逻辑视图（Logical View），设计的对象模型。进程视图（Process View），捕捉设计的并发和同步特征。部署视图（Deployment View），描述了软件到硬件的映射，反映了分布式特性。实现视图（Implementation View），描述了在开发环境中软件的静态组织结构。用例视图（Use-Case View），该视图是其他视图的冗余（因此1）。222.1 架构设计-4+1视图232.1 架构设计-4+1视图是多个视图，不是多个架构。多个视图组成一个架构保持架构视图之间的同步，也就是

8、要保证不同视图之间是相互解释的、而不是相互矛盾的视图数量由具体实践状况决定242.2 获取分析类类图的获取是一个不断细化的过程，一般我们先从分析类开始。分析类是概念层面上的类，是进行类设计的基础，获取分析类是系统分析中一项很重要的工作。获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类252.2 获取分析类用例描述中出用例描述中出现了哪些了哪些实体？体？用例的完成需要哪些实体的合作？用例执行过程中会产生并存储哪些信息？用例要求与之相关联的每个角色的输入是什么？用例返回与之相关联的每个角色的输出是什么？用例需要操作哪些硬件设备？262.2 获取分析类272.3 用例实现-活动

9、图/状态图282.3 用例实现-时序图/协作图292.4 整理分析类整理分析类主要是依据用例实现部分的一系列的交互图。我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。但是这些类还没有属性、职责。我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来302.4 整理分析类-示例312 分析模型-小结类之间并不是孤立的，利用类之间的关系就可以找到另一个类属性是分析类的基本内容。属性的基本来源是用例的事件流描述。类不仅仅是从选择建设项目这个用例获取的信息，它是综合了所有相关的用例分析的结果。所以要考虑每个用例的情况，进行归纳总结323 设计模型3.1

10、映射分析类到设计类3.2 整理设计类3.3 更新用例实现333.1 映射分析类到设计类设计类是指设计层面的类，映射分析类到设计类的过程实际上就是细化分析类的属性、方法，使类达到可以进行面向对象编程的程度。类的属性和方法应该按照UML中的格式表示：属性格式和操作格式可见性属性名：类型多重性次序初始值特性可见性操作名（参数列表）：返回类型特性343.1 映射分析类到设计类353.2 整理设计类在最终的类图上并不是所有的类都是由分析类映射而来的，系统中的绝大部分类都是由分析类映射而来的。在完成映射之后，还需要对已有的类根据设计原则进行优化。363.2 整理设计类开放-封闭原则（OCP）对于扩展是开放

11、的，对于更改是封闭的Liskov替换原则（LSP）子类型（subtype）必须能够替换掉它们的基类型（base type）依赖倒置原则（DIP）高层模块不应该依赖于低层模块。二者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象接口隔离原则（ISP）不要强迫客户依赖于它们不用的方法373.3 更新用例实现当完成了类的设计后，需要根据类的设计更新在分析阶段的用例实现383 设计模型-小结一般完成了类的属性、方法的设计就可以了，由开发人员在程序编写过程中设计类中方法的具体实现。如果条件允许在设计阶段尽量对类的重要方法进行设计，因为概要设计和详细设计一气呵成，设计中的问题会相对较少。通过自然

12、语言、伪代码、流程图来实现详细设计，开发人员很容易理解设计者的意图，并很快将其实现。394 物理架构模型组件图主要目的是显示系统组件间的结构关系部署图描述系统硬件的物理拓扑结构以及在此结构上运行的软件405 代码导出41PS 1:重要输出编码规范：信息形式、接口规约、命名规则物理模型：组件图、部署图不同角度的构架视图：用例视图、逻辑视图、进程视图、实施视图、数据视图（可选）系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类42PS 2:数据库设计在面向对象中，是没有数据流这一说法的。业务的完成是由对象及消息来完成的，只有“对象流”，没有数据流先忘记数据库的存在，采用对象分析方法，先把对象分析和定义出来，保证业务执行逻辑能够被这些对象很好的完成然后考虑对象持久化的问题。依据数据库的三大范式以及性能要求来把对象持久化面向对象设计解决业务执行逻辑问题，数据库设计解决数据高效的问题43THANKS.2011年年10月月 AHPO 7722434