第7章 面向对象的分析和设计.ppt

1、软件工程,第7章 面向对象的分析和设计,2/215,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,3/215,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,4/215,Peter Coad和Edward Yourdon提出用下列等式识认面向对象方法： 面向对象 = 对象（object） + 分类（classification） + 继承（inheritance） + 通过消息的通信（communication with messages） 可以说，采用这四

2、个概念开发的软件系统是面向对象的,5/215,面向对象方法的出现很快受到计算机软件界的青睐，并成为20世纪90年代的主流开发方法。我们可以从下列几个方面来分析其原因： 从认知学的角度来看，面向对象方法符合人们对客观世界的认识规律。 面向对象方法开发的软件系统易于维护，其体系结构易于理解、扩充和修改。 面向对象方法中的继承机制有力支持软件的复用。,6/215,面向对象的基本概念,1. 对象（object） 对象是指一组属性以及这组属性上的专用操作的封装体。 属性（attribute）通常是一些数据，有时它也可以是另一个对象。每个对象都有它自己的属性值，表示该对象的状态。对象中的属性只能通过该对象

3、所提供的操作来存取或修改。 操作（operation）（也称方法或服务）规定了对象的行为，表示对象所能提供的服务。,7/215,封装（encapsulation）是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。 一个对象通常可由对象名、属性和操作三部分组成。,8/215,2. 类（class） 类是一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例（instance）。 类是创建对象的模板，从同一个类实例化的每个对象都具有相同的结构和行为。,9/215,10/215,

4、3. 继承（inheritance） 继承是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义其实现方法。,11/215,12/215,有时，我们定义一个类，它把一些类组织起来，提供一些公共的行为，但并不需要使用这个类的实例，而仅使用其子类的实例。我们把这种没有实例的类称为抽象类（abstract class）。在抽象类中可以定义抽象操作，抽象操作指：只定义这个类的操作接口，不定义它的实现，其实现部分由其子类定义。抽象操

5、作操作名用斜体字表示，也可以在操作特征（signature）后面加上特征字符串abstract。,13/215,14/215,如果一个子类只有唯一一个父类，这个继承称为单一继承。如果一个子类有一个以上的父类，这种继承称为多重继承。,15/215,4. 消息（message） 消息传递是对象间通信的手段，一个对象通过向另一个对象发送消息来请求其服务。一个消息通常包括接收对象名、调用的操作名和适当的参数（如果有必要的话）。消息只告诉接收对象需要完成什么操作，但并不指示接收者怎样完成操作。消息完全由接收者解释，接收者独立决定采用什么方法完成所需的操作。,16/215,5. 多态性（polymorph

6、ism） 多态性是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。例如“画”操作，作用在“矩形”对象上，则在屏幕上画一个矩形，作用在“圆”对象上，则在屏幕上画一个圆。也就是说，相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的这个操作去执行，从而产生不同的结果。,17/215,6. 动态绑定（dynamic binding） 动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法连接起来。 传统的程序设计语言的过程调用与目标代码的连接（即调用哪个过程）放在程序运行前（即编译链接时）进行（称为静态绑定），而动态绑定则是把这种连接推迟到运行时才进行。

7、动态绑定是一种在运行时确定被执行代码的技术。,18/215,在一般与特殊关系中，子类是父类的一个特例，所以父类对象可以出现的地方，也允许其子类对象出现。因此在运行过程中，当一个对象发送消息请求服务时，要根据接收对象的具体情况将请求的操作与实现的方法进行连接，即动态绑定。,19/215,if 条件 then p := t ; else p := r ; area := p.getarea ;,Var p : polygon ; Var t : triangle := triangle.new ; Var r : rectangle := rectangle.new ;,20/215,内容摘要,面

8、向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,21/215,面向对象分析Object-Oriented Analysis,获取客户对系统的需求：包括标识场景和用况，以及建造需求模型 用基本的需求为指南，来确定类和对象（包括属性和操作） 定义类的结构和层次(继承关系) 建造对象关系模型 建造对象行为模型 利用用况/场景来复审分析模型,22/215,1.获取客户对系统的需求 需求获取必须让客户与开发者充分地交流，这里介绍一种采用用况来收集客户需求的技术。分析员首先标识使用该系统的不同的执行者（actor），这些执行者代表使用该系统的不同的角

9、色。每个执行者可以叙述他如何使用系统，或者说他需要系统提供什么功能。执行者提出的每一个使用场景（或功能）都是系统的一个用况的实例，一个用况描述了系统的一种用法（或一个功能），所有执行者提出的所有用况构成系统的完整的需求。,分析过程,23/215,注意，执行者与用户是不同的两个概念，一个用户可以扮演几个角色（执行者），一个执行者可以是用户，也可以是其他系统（应用程序或设备）。得到的用况必须进行复审，以使需求完整。,24/215,2.标识类和对象 类和对象来自问题领域 可以先标识候选类，然后进行筛选,25/215,3. 定义类的结构和层次 类的结构主要有两种：一般特殊（generalization

10、specialization）结构和整体部分（wholepart）结构。 一般特殊结构是一种分类结构，反映了类间的一般与特殊的关系。一般类与特殊类之间是一种“is a”的关系，如：汽车是一种交通工具。同样，特殊类还可以分为更特殊的类，这样可形成类的层次结构。 整体部分结构反映了类间的整体与部分关系。值得注意的是，整体部分关系是对对象而言的，而不是对类的。整体部分关系是一种“has a ”的关系，如“汽车”有“发动机”。同样，整体部分结构也具有层次结构。,26/215,4. 建造对象关系模型 对象-关系模型描述了系统的静态结构，它指出了类间的关系（relationship） 类之间的关系有关联、

11、依赖、泛化、实现等,27/215,5. 建立对象行为模型 对象-行为模型描述了系统的动态行为，它们指明系统如何响应外部的事件或激励（stimulus）。 建模的步骤如下： 评估所有的用况，以完全理解系统中交互的序列 标识驱动交互序列的事件，理解这些事件如何和特定的对象相关联 为每个用况创建事件轨迹（event trace） 为系统建造状态机图 复审对象-行为模型，以验证准确性和一致性,28/215,面向对象设计（Object_Oriented Design）,面向对象设计的一般步骤如下： 系统设计 将子系统分配到处理器 选择实现数据管理、界面支持和任务管理的设计策略 为系统设计合适的控制机制

12、复审并考虑权衡（折衷）,29/215,对象设计 在过程级别（procedural lavel）设计每个操作，即设计每个操作的实现细节 定义内部类 为类属性设计内部数据结构 消息设计 使用对象间的协作和对象-关系模型，设计消息模型 复审 复审设计模型并在需要时迭代。,30/215,1. 系统设计 1) 将分析模型划分成子系统 在OO系统设计中，我们把分析模型中紧密相关的类、关系等设计元素包装成子系统。 通常，子系统的所有元素共享某些公共的性质，它们可能都涉及完成相同的功能；它们可能驻留在相同的产品硬件中；或者它们可能管理相同的类和资源。子系统由它们的责任所刻画，即，一个子系统可以通过它提供的服务

13、来标识。在OOD中，这种服务是完成特定功能的一组操作。,31/215,子系统的设计准则是： (1) 子系统应具有定义良好的接口，通过接口和系统的其它部分通信； (2) 除了少数的“通信类” 外，子系统中的类应只和该子系统中的其它类协作； (3) 子系统的数量不宜太多； (4) 可以在子系统内部再次划分，以降低复杂性。,32/215,2) 标识问题本身的并发性，并为子系统分配处理器 通过对对象-行为模型的分析，可发现系统的并发性。如果对象（或子系统）不是同时活动的，则它们不需并发处理，此时这些对象（或子系统）可以在同一个处理器上实现。反之，如果对象（或子系统）必须对一些事件同时异步地动作，则它们

14、被视为并发的，此时，可以将并发的子系统分别分配到不同的处理器，或者分配在同一个处理器，而由操作系统提供并发支持。,33/215,3) 任务管理设计 Coad和Yourdon提出如下管理并发任务对象的设计策略： (1) 确定任务的类型； (2) 必要时，定义协调者任务和关联的对象； (3) 将协调者任务和其它任务集成。 通常可通过了解任务是如何被启动的来确定任务的类型，如事件驱动任务，时钟驱动任务。每个任务应该定义其优先级，并识别关键任务。当有多个任务时还可以考虑增加一个协调者任务，以控制这些任务协同工作,34/215,4) 数据管理设计 通常数据管理设计成层次模式，其目的是将数据的物理存储及操

15、纵与系统的业务逻辑加以分离。 数据管理的设计包括设计系统中各种数据对象的存储方式（如内部数据结构、文件、数据库），以及设计相应的服务，即为要储存的对象增加所需的属性和操作。,35/215,5) 资源管理设计 OO系统可利用一系列不同的资源（如磁盘驱动器、处理器、通信线路等外部实体或数据库、对象等抽象资源），很多情况下，子系统同时竞争这些资源，因此要设计一套控制机制和安全机制，以控制对资源的访问，避免对资源使用的冲突。 6）人机界面设计 对大多数应用系统而言，人机界面本身是一个非常重要的子系统。人机界面主要强调人如何命令系统，以及系统如何向人提交信息。它包括窗口、菜单、报告的设计。,36/215

16、,7) 子系统间的通信 子系统之间可以通过建立客户/服务器连接进行通信，也可以通过端对端（peer to peer）连接进行通信。我们必须确定子系统间通信的合约（contract），合约提供了一个子系统和另一个子系统交互的方式。,37/215,2. 对象设计 对象设计是为每个类的属性和操作作出详细的设计，并设计连接类与它的协作者之间的消息规约。 对象描述 1)协议描述(外部的黑盒描述)：描述对象的接口，即定义对象可以接收的消息以及当对象接收到消息后完成的相关操作； 2)实现描述(内部描述)：描述传送给对象的消息所蕴含的每个操作的实现细节，实现细节包括有关对象私有部分的信息，即关于描述对象属性的

17、数据结构的内部细节和描述操作的过程细节。 对象的使用者只需要关心协议描述,38/215,2）设计算法和数据结构 为对象中的属性和操作设计数据结构和实现算法。 3. 设计模式（design patterns） 在许多面向对象系统中，存在一些类和通信对象的重复出现的模式。这些模式求解特定的设计问题，使面向对象设计更灵活，并最终可复用。这些模式帮助设计者复用以前成功的设计，设计者可以把这些模式应用到新的设计中。,39/215,一个设计模式通常可用四个信息来描述： 1）模式名 设计模式名应具有实际的含义，它能反映模式的适用性和意图。 2）使模式可被应用所必须存在的环境和条件。 3）设计模式的特征 模式

18、特征指出一些设计的属性，调整这些属性使该模式能适应各种不同的问题。这些属性表示设计的特征，这些特征能被用于检索（通过数据库）以找到合适的模式。 4）应用设计模式的结果（consequences） 对于一个设计模式的使用结果表明设计决策的走向。,40/215,Object model 由五个层次组成，相当于把五张透明胶片叠在一起，每一层显示更多的细节。,面向对象设计基本过程,41/215,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,42/215,统一建模语言UML,Unified Modeling Language,43/2

19、15,UML概述,为何研究UML结束方法大战 发展历史 1994年Booch和Rumbaugh在Rational Software Corporation开始了UML的工作，其目标是创建一个“统一的方法”， 1995年OOSE的创始人Jacobson加盟到这项工作中，工作重点转移到创建一种统一的建模语言UML 1996年6月、10月、1997年1月、11月分别推出了UML0.9、 UML0.91、 UML1.0、 UML1.1,44/215,UML概述,1997年11月，OMG(Object Management Group)批准把UML1.1作为基于面向对象技术的标准建模语言 之后，UML进

20、行了持续的修订和改进，先后产生了UML1.2、1.3、1.4、1.5版本 2004年推出了UML2.0，UML2.0对UML1.x作了重大的修改,45/215,UML模型元素(V1.3),模型中的实体以及实体间相互连接的关系,46/215,UML模型元素(V2.0),模型中的实体以及实体间相互连接的关系,47/215,UML2.0的13种图-1,用况图 (use case diagram) 类图 (class diagram) 对象图 (object diagram) 构件图 (component diagram) 组合结构图 (composite structure diagram) 顺序图

21、 (sequence diagram) 通信图 (communication diagram),交互图 (interaction diagram),48/215,UML2.0的13种图-2,状态机图 (state machine diagram) 活动图 (activity diagram) 部署图 (deployment diagram) 制品图 (artifact diagram) 包图 (package diagram) 时间图 (timing diagram) 交互概览图 (interaction overview diagram),49/215,UML图1-用况图,描述参与者与用况(

22、参与者使用系统以实现某一特定目标的情形)之间的关联关系，以及用况之间的扩展、继承等关系,50/215,UML图2-类图,展现一组类、接口以及它们相互之间的关系,2条或2条以上的线交于0个或1个点,51/215,UML图3-对象图,展现一组对象以及相互之间的关系，是依照类图所建立的一组事物(实例)的静态快照,52/215,UML图4-构件图,描述构件、接口以及构件间的组装关系的静态视图，复合构件本身可以由内部的子构件图描述,53/215,UML图5-组合结构图,UML2.0新增的图，展示了类或协作的内部结构，与构件差别不大，经常认为与构件图等同,54/215,UML图6-顺序图,描述特定场景下交

23、互各方消息发送和接收的顺序,55/215,UML图7-通信图,另一种交互图，强调交互上下文：参与交互的对象或角色的结构组织,56/215,UML图8-状态机图,以状态机的形式描述目标对象在各种事件作用下的行为,57/215,UML图9-活动图,描述一系列活动之间的控制流和数据流,58/215,UML图10-部署图,描述系统运行时各相关处理单元结点、各结点上部署的构件、以及相互间的通信协议,59/215,UML图10-部署图变体:制品图,部署图的变体：描述系统实现制品的物理结构，制品包括文件、数据库等,这两个物理文件“承载了”逻辑类HelloWorld的实现,60/215,UML图11-包图,描

24、述包(一种模型分解单位)以及包之间的关系,61/215,UML图12-时间图,UML2.0新增的图，描述对象间的交互，但关注于关于时间的推理，而不仅仅是相对顺序,添水,加热,62/215,UML图13-交互概览图,UML2.0新增的图 可认为是：活动图+顺序图的混合体 使用活动图的表示法，其中的节点或者是一个交互或者是一个交互引用,63/215,UML2.0的视图和图,需 求,设 计,实现 部署,64/215,UML视图1-用况视图,描述可被最终用户、分析人员和测试人员看到的系统(外部)行为 不涉及系统的内部结构，但却是系统体系结构设计的驱动力 静态方面：用况图 动态方面：交互图、状态机图、活

25、动图,65/215,UML视图2-设计视图,描述系统设计方案，主要包括类、接口以及相互之间的协作关系 静态方面：类图、对象图 动态方面：交互图、状态机图、活动图,66/215,UML视图3-交互视图,展示系统不同部分之间的控制流，包括并发和同步机制 主要针对系统的非功能性方面，例如性能、可伸缩性、吞吐量等 静态方面：类图、对象图 动态方面：交互图、状态机图、活动图 与设计视图的区别：突出控制系统的主动类以及各部分间消息的流动,67/215,UML视图4-实现视图,描述组成最终产品发布的相关制品及其关系，实现单元体现为可装配、打包并发布的文件 体现了逻辑单元(类和构件)到物理制品(物理构件、文件

26、等)的映射 静态方面：构件图 动态方面：交互图、状态机图、活动图,68/215,UML视图5-部署视图,描述最终产品物理部署的拓扑结构 包括组成整个系统的各种分布式硬件设备，以及各个软件模块在这些设备上的部署和运行关系 静态方面：部署图 动态方面：交互图、状态机图、活动图,69/215,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,70/215,用况建模,用况：文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形 用况建模用于描述一个系统应该做什么，用用况图来描述(可能有多幅) 用况图给出了用户所感受到的系统

27、行为，但不描述系统如何实现该功能,71/215,用况图,用框图展示各类外部执行者(actor)与系统所提供的用况之间的参与关系，包括： 系统边界、用况 执行者(参与者)：可能使用这些用况的人或外部系统，参与者与用况连接表示参与者使用了该用况 模型元素间关系：关联、扩展、包含、泛化等 每个用况的细节通常用文字描述，也可以用活动图来描述,72/215,用况之间的关系-1,73/215,用况之间的关系-2,74/215,电话订购系统用况图,客户,售票员,送货员,主管,建立信用,供应订单,订单支付,提供 客户数据,产生订单,信用卡 支付,现金支付,设置订单,请求 目录,电话订购,include,inc

28、lude,include,extend,核对身份,关联,扩展,包含,泛化,75/215,包含,泛化,76/215,参与者之间的泛化关系,77/215,用况图对于各方的作用,客户：用况模型指明了系统的功能，描述了系统能如何使用 开发者：用况模型帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据 集成测试和系统测试人员：根据用况来测试系统，以验证系统是否完成了用况指定的功能,78/215,用况建模步骤,定义系统(总体范围) 确定参与者 确定用况 描述用况 定义用况间的关系 确认模型,79/215,用况建模定义系统范围/边界,根据项目的总体目标/任务以及基本的开发决策决定做

29、什么不做什么 总体目标/任务：实现出版社书籍的网上销售 开发决策：网上支付采用银联支付系统、书籍的基本信息来自于出版社已有的编辑和发行管理系统(遗产系统) 边界外的人或系统(第三方系统、遗留系统等)成为候选的参与者,80/215,用况建模确定参与者,参与者是指与系统交互的人、组织或其它系统 参与者代表一种角色，而不是具体的人 可分成主参与者和辅助参与者 主参与者是用况的直接执行者，例如保险系统中业务员处理保险的注册和管理 辅助参与者对于用况的执行起辅助作用，例如保险系统中管理员负责分配业务员权限,81/215,确定参与者的启发式问题,谁使用系统的主要功能(主执行者) 谁需要从系统中得到对他们日

30、常工作的支持 谁需要维护、管理和维持系统的日常运行 系统需要控制哪些硬件设备 系统需要与哪些其它系统交互 哪些人或哪些系统对系统产生的结果(值)感兴趣,82/215,用况建模确定用况,用况的特征 用况总是由参与者启动的 执行者必须直接或间接地指示系统去执行用况 用况向参与者提供服务或返回结果，这些结果必须是可识别的 用况是完整的，一个用况必须是一个完整的描述(有开始、有结果),83/215,用况(Use Case),文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形 例：顾客携带所购商品到达收银台，收银员使用POS系统记录每件商品，系统连续显示累计金额并逐行显示细目，顾客输入

31、支付信息，系统对支付信息进行验证和记录，成功后更新库存信息，顾客从系统得到购物小票然后离开,84/215,场景(Scenario),使用系统的一个特定情节或用况的一条执行路径，即用况实例(Use Case Instance) 主成功场景：顾客携带商品到收银台，顺利地完成商品扫描及信用卡付款等全过程 替代场景1：商品扫描失败，提示输入商品唯一码 替代场景2：信用卡划账通讯失败，提示客户使用现金结帐 替代场景n：用户信用卡支付成功后要求退货 因此用况就是一系列可能的场景集合,85/215,确定用况的启发式问题,执行者需要系统提供哪些功能？执行者需要系统做什么? 执行者是否需要读、创建、删除、修改或

32、储存系统中的某类信息? 执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情?从功能观点看，这些事件表示什么? 执行者的日常工作是否因为系统的新功能(尤其是目前尚未自动化的功能)而被简化或提高效率,86/215,用况建模描述用况,使用文本描述 用况的目的 用况是如何启动的：哪个参与者在什么情况下启动(前提) 参与者和用况之间的消息流(步骤) 主消息流和其它消息流是什么 根据条件或异常情况等选择不同的流程分支 系统中哪些实体被使用或修改(结果)，如何确定用况执行结束 使用活动图描述,87/215,用况的简要文字描述,执行者的简要描述，如 客户：向公司订购商品的人 客户代表：公司处理

33、客户请求的雇员 库存系统：记录公司库存的软件 用况的简要描述，如 订购货物：客户创建一个新的请求商品的订单，并为那些商品付费 取消订单：客户取消一个已经存在的订单,88/215,用况的详细描述,用况名称、参与者 用况的前置条件和后置条件：用况开始和结束的条件 事件流：一系列陈述句，从参与者的角度出发的一系列步骤 一般有多个事件流：主要流程、其它流程 特殊需求：相关的非功能性需求,89/215,用况的详细描述结构,90/215,POS系统收银用况详细说明-1,91/215,POS系统收银用况详细说明-2,92/215,POS系统收银用况详细说明-3,93/215,确定用况之间的关系,关联：参与者

34、与用况 扩展：用况与用况 包含：用况与用况 泛化：用况与用况,94/215,实例,本实例实现一个简化了的银行储蓄账户管理系统，该系统是在银行的柜台上对客户办理活期储蓄业务。系统的需求陈述如下： 一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户。客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行间转账）。系统管理员负责系统的账户管理及业务报表的生成。,95/215,识别执行者 客户：到银行办理储蓄业务的人，负责输入密码 银行职员（客户代理）：银行工

35、作人员，代表客户进行储蓄业务的操作 银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户 管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成,96/215,识别用况 从系统的需求陈述可知，银行职员（客户代理）需要系统提供开户、存款、取款、转账、注销账户等功能，这些功能都包含了校验密码的功能。系统管理员需要系统提供账户管理和报表生成功能。银行职员（管理人员）则参与了账户管理中的更新账户的功能。此外，转账功能可分为银行内转账和银行间转账，我们可将它们设计成三个用况，其中银行内转账用况和银行间转账用况都继承了基本转账用况。据此分析，得到该系统的用况图如下图所示。,97/215,9

36、8/215,开户用况描述 用况名称：开户 参与的执行者：银行职员（客户代理），客户 前置条件：一个合法的银行职员（客户代理）已登录到该系统 事件流： 1.当选择开户功能时用况开始 2.输入客户信息（姓名、地址、身份证号等） 3.从账户管理系统获取新的账号 4.请客户输入密码 5.请客户再次输入密码 6.如果两次密码不一致则回到第4步，否则继续 7.在账户库中添加新账户 8.打印存折，用况结束 后置条件：在账户库中增加了一个新账户，得到一张新存折,99/215,取款用况描述 用况名称：取款 参与的执行者：银行职员（客户代理） 前置条件：一个合法的银行职员（客户代理）已登录到该系统 事件流： 基本

37、路径： 1.当选择取款功能时用况开始 2.当输入客户信息（姓名、账号等）后 a）如果客户信息与账户不一致，显示错误信息，可以重新输入或结束用况 b）如果该账户被冻结（如因挂失而冻结），显示冻结信息并结束用况 3.输入并校验密码,100/215,4.输入取款金额，如果该账户的余款小于取款金额，显示错误信息，要求重新输入 5.打印取款单，交客户签字 6.建立取款事件记录，更新账户信息 7. 打印存折，用况结束 可选路径： 1.在第5步客户签字之前的任何时刻，客户可以取消本次取款，用况结束 2.第3步校验密码时，如发现密码不一致，则重新输入密码，或用况结束 后置条件：如果取款成功，客户账户中的余额被

38、更新（减少），否则余额不变。,101/215,取款用况的活动图描述,102/215,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,103/215,类图和对象图,类和对象模型的基本模型元素有类、对象以及它们之间的关系 对象图是类图的实例，描述某一时刻类图中类的特定实例以及这些实例之间的特定链接 对象图使用了与类图相同的符号，只是在对象名下附加下划线，对象名后可接以冒号和类名，即object-name: class-name 系统中的类和对象模型描述了系统的静态结构,104/215,类图和对象图的基本元素,105/215,类图和

39、对象图(例),106/215,类图中类之间的关系,107/215,关联关系,从参与方数量分：二元关联、多元关联 从参与限制：受限关联 整体和部分的关联：聚集和组合,108/215,二元关联,二元关联表示为在两个类之间用一条直线连接，直线上可写上关联名,109/215,关联的重数限制和角色,110/215,与自身的关联,111/215,自身关联中的角色,112/215,多元关联(例),113/215,多元关联的对象图(例),114/215,受限关联,受限关联用于一对多或多对多的关联 限定符用来区分关联“多”端的对象集合，它指明了在关联“多”端的某个特殊对象,115/215,聚集,聚集(aggre

40、gation)是表示整体-部分关系的一种关联 聚集中的“部分”对象可以是多个“整体”对象的一部分(共享非独占),116/215,组合,组合(composition) 是一种更强形式的关联 代表整体的组合对象有管理它的部分对象的特有责任，如部分对象的生成和释放 组合关联具有强的物主身份，即“整体”对象拥有“部分”对象，“部分”对象生存在“整体”对象中,117/215,关联类,某些关联关系本身具有复杂的性质，可以独立为一个类 关联类往往可以转换为多元关联,118/215,关联类间的导航,导航可理解为从一个类的对象访问到另一个类的对象,119/215,关联类间的导航(例),120/215,泛化关系,

41、泛化表示类间的一般特殊关系(is-a) 一般类定义了它的特殊类的公共属性和操作 对一般类扩展一些属性和/或操作后，可以特化(specialize)成特殊类 一般类是特殊类的父类，特殊类是一般类的子类 特殊类可以继承一般类的属性和操作 子类可以定义自己的属性和操作，也可重新定义父类中的操作，但重新定义的操作必须与父类具有相同的型构(signature),121/215,泛化关系例,122/215,泛化关系例,泛化是一种分类学关系，一个一般类可以从不同的维或方面进行特化 例如学生可以从性别、学习阶段(研究生、本科生、中学生等)等不同维度进行特化 用类元(用作分类符)来表示分类的维度或方面，对应的特

42、殊类组成一个泛化集 在泛化集中可对其元素应用约束，在UML中提供以下约束，见下表,123/215,泛化集的约束,124/215,泛化集的约束(例),125/215,实现关系表示一个模型元素对于一个行为规约(specification)的实现关系 例如类对于接口的实现，设计类对于分析类的实现 泛化和实现都可以将一般描述与具体描述联系起来，其区别是： 泛化是同一语义层(例如都是类)上的元素之间的连接 实现是不同语义层中的元素之间的连接，通常建立在不同的模型内，如设计类到分析类的实现关系,实现关系,126/215,实现关系(例),127/215,依赖关系,依赖表示两个或多个模型元素之间语义上的依赖关

43、系 例如网上书店中的交易通知依赖于邮件发送 依赖关系用一个虚线箭头表示，箭头上可附加说明依赖类型的关键字 UML2.0中的依赖种类如下：Access(访问), bind(绑定), call(调用), create(创建), derive(派生), instantiate(实例化), permit(允许), realize(实现), refine(精化), send(发送), substitute(替换), trace(追踪依赖),use(使用),128/215,依赖关系(例),129/215,约束和派生(constraint public void doOne( ) myB.doTwo( );

44、 myB.doThree( ); ,顺序图中的生存线(例),187/215,attribute=name (argument-list) :return-value attribute是生命线的属性(对象名)，用以存储返回值 name是消息名(信号或操作名) argument-list是一个参数值的表，每个参数值可以是： argument-value parameter-name=argument-value ：表示任何参数值 name可以用“*”替代，此时表示任何消息,顺序图中消息的表示,188/215,简单消息表示消息类型未知或与消息类型无关，或是一个同步消息的返回 同步消息表示发送对象必

45、须等接收对象完成消息的处理后才能继续执行 异步消息表示发送对象在消息发送后立即继续执行，而不必等待接收对象的返回 传送延迟可用倾斜的箭头表示，意思是消息发送后需经历一段延迟时间才被接收(可以注明最大延迟时间),顺序图中的消息类型,189/215,顺序图中的条件和分支,消息上可附加条件，当条件为真时消息才被发送或接收。条件可用于描述分支，当几个消息箭头上的条件互斥时，表示某一时刻只有一个消息被发送。如果条件不是互斥的，则消息会并行地发出。,190/215,顺序图中的循环和约束,191/215,顺序图中的递归,192/215,顺序图中的创建和消亡,一个对象可以通过一条消息创建另一个对象。当需要显式

46、地表示对象的销毁(没有垃圾自动回收机制或特别指明不再使用)时，在图中用一个符号表示。创建或消亡一个对象的消息通常是同步消息。,193/215,顺序图的结构化控制结构,对于复杂的控制流可以用组合片段来表示 一个组合片段有一个关键字和一或多个子片段 关键字指明片段类型 子片段指出操作对象,194/215,ref(引用)：对另一交互的引用 loop(循环)：当循环的警戒条件为真时循环执行子片段 alt(选择)：两个或多个子片段之间的选择执行 每个子片段有一个警戒条件，为真时执行该子片段 如果多个子片段的警戒条件为真，则无确定性地选择它们中的一个执行 如果没有一个子片段的警戒条件为真，则不执行,组合片段的类型-1,195/215,opt(可选)：选择的带单个子片段的特殊情况，警戒条件为假时省略该子片段 par(并发)：两个或多个子片段的并发执行 在不同片段中消息的相关顺序是不确定的 当所有子片段完整地并发执行后，控制流