软件工程导论class14面向对象方法学引论.ppt

软件工程导论第 14 课,9.4.2 表示关系的符号,9.4.2 表示关系的符号,类与类之间通常有关联、泛化（继承）、依赖和细化等4种关系1 关联关联表示两个类的对象之间存在某种语义上的联系,9.4.2 表示关系的符号,普通关联：最常见的关联关系，只要在类与类之间存在连接关系就可以用普通关联表示。例如，作家使用计算机，我们就认为在作家和计算机之间存在某种语义连接，因此在类图中应该在作家类和计算机类之间建立关 联关系,黑三角表示关联方向,(2)关联的角色,在任何关联中都会涉及到参与此关联的对象所扮演的角色，在某些情况下显式标明角色名有助于别人理解类图例：一个人与另一个人结婚，必然一个人扮演丈夫的角色，另一个人扮演妻子的角色。如果没有显式标出角色名，则意 味着用类名作为角色名。,(3)限定关联(3)限定关联(3)限定关联,限定关联通常在一对多或多对多的关联关系中，可以把模型中的 重数从一对多变成一对一，或从多对多简化成多对一例如，某操作系统中一个目录下有许多文件，一个文件仅属于一 个目录，在一个目录内文件名确定了惟一一个文件。可见，利用限定词把一对多关系简化成了一对一关系图9.7查找 目录-文件名-文件,(4)关联类,为了说明关联的性质可能需要一些附加信息，可以引入一个关联类来记录这些信息。关联中的每个连接与关联类的一个对象相联系。关联类通过一条虚线与关联连接。,图9.8 有4个连接，每个连接都对应一个队列,2 聚集,聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体和部分的关系。在陈述需求时使用的“包含”、“组成”、“分为部分”等字句，往往意味着存在聚集关系。除了一般聚集之外，还有两种 特殊的聚集关系，分别是共享聚集和组合聚集。,(1)共享聚集,如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集称为共享聚集。一般聚集和共享聚集的图示符号，都是在表示关联关系的直线未端，紧挨整体类的地方画一个空心的菱形,(2)组合聚集,如果部分类完全隶属于整体类，部分与整体共存，整体不存在了 部分也会随之消失（或失去存在的价值了），则该聚集称为组合聚集（简称为组成）。例如，在屏幕上打开一个窗口，它由文本框、列表框、按钮和菜 单组成，一旦关闭了窗口，各个组成部分也同时消失，窗口和它的组成部分之间存在着组合聚集关系组成关系用实心菱形表示,3 泛化,在UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。泛化针对类型而不针对实例，一个类可以继承另一个类，但一个对象不能继承另一个对象。实际上，泛化关系指出在类与类之间存在“一般特殊”关系。泛化可进一步划分成普通泛化和受限泛化。,(1)普通泛化,需要特别说明的是没有具体对象的类称为抽象类抽象类通常作为父类，用于描述其他类（子类）的公共属性和 行为。图示抽象类时，在类名下方附加一个标记值abstract操作的图示方法，在标记后面跟一个性质串abstract,例子：一副工程蓝图由许多图形组成，图形可以是直线，圆，多边形或组合图，而多边形由直线组成，组合图由各种线型混合而成,(2)受限泛化,可以给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法，这样的泛化关系称为受限泛化预定义的约束有种：多重，不相交，完全和不完全，这些约束都是语义约束。,多重继承指的是，一个子类可以同时多次继承同一个上层基类。与多重继承相反是不相交继承 完全继承指的是父类的所有子类都已在图中穷举不完全继承指的是父类的所有子类没有都穷举出来,4 依赖和细化,(1)依赖关系：依赖关系描述两个模型元素之间的语义连接关系，其 中一个模型元素是独立的，另一个模型元素不是独立的，如果独立的模型元素改变，将影响依赖于它的模型元素。箭头指向独立的类(2)细化关系：当对同一个事物在不同抽象层次上描述时，这些描述之间具有细化关系。箭头由更详细层指向上层,9.5 动态模型,动态模型表示瞬时的，行为化的系统的“控制”性质,它规定了对象模型中的对象的合法变化序列。状态是任何可以被观察到的系统行为模式，每个类的动态行为用一张状态图来描绘 各个类的状态图通过共享事件合并起来，从而构成系统 的动态模型 动态模型是基于事件共享而互相关联的一组状态图的集 合,动态模型的三要素：事件(event)：引发对象状态改变的控制信息（瞬时）状态(status)：即对象的属性所处的情形（可持续）行为(action)：对象要达到某种状态所做的操作（耗时）,注意：状态图：适合描述跨越多个用例的单个对象的行为，不适合描述多个对象之间的协作行为 不应对系统中的每个类都画状态图，而只应对某些 关键类建立状态图；而且应将状态图与其它技术组 合使用,9.6 功能模型,表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求功能模型由一组数据流图组成，在面向对象方法学中，数据流图 远不如在结构分析设计方法中那样重要 一般说来，与对象模型和动态模型比较，数据流图并没有增加新 的信息UML提供的用例图也是进行需求分析和建立功能模块的强有力工具，在UML中把用用例图建立起来的系统模型成为用例模型。,9.6.1 用例图,用例图包含的模型元素:系统，行为者，用例及用例之间的关 系图中的方框代表系统，椭圆代表用例，线条人代表行为者，它们之间的连线表示关系,系统,系统被看作是一个提供用例的黑盒子，内部如何工作，用例如何实现，这些对于建立用例模型来说都是不重要的。系统的方框边线表示系统的边界，划定系统的功能范围描述系统功能的用例置于方框内。行为者置于方框外。,用例,用例是可以被行为者感受到的，系统的一个完整的功能在UML中把用例定义成系统完成的一系列动作，动作的结果能被特定的行为者察觉到。用例具有下述特征：(1)用例代表某些用户可见的功能，实现一个具体用户目标(2)用例总是被行为者启动的，并向行为者提供可识别的(3)用例必须是完整的,用例,用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。脚本是系统的一次具体执行过程例如，在自动售货机系统中，张三投入硬币购买矿泉水，系统收到钱后把矿泉水送出来，上述过程就是一个脚本；李四投币买可乐，但是可乐卖完了，于是系统给出提示信息并把钱退还给李四，这个过程是另一个脚本。,行为者,行为者是指与系统交互的人或其他系统，它代表外部实体。使用用例并且与系统交互的任何人或物都是行为者。行为者代表一种角色，而不是某个具体的人或物例如，在自动售货机系统中，使用售货功能的人既可以是张三（买矿泉水）也可以是李四的（买可乐），但是不能把张三或李四这样的个体对象称为行为者。直线连接行为者和用例，表示两者之间交换信息，称为通信联系。行为者触发用例，并与用例交换信息,用例之间的关系,uml1.1中有两种用例关系关系和关系它们都是泛化（generalization）关系的构造型（stereotype）uml1.3之后，提供了三种用例关系关系、关系都是依赖（dependency）关系的构造型（stereotype）泛化关系（generalization）,(1)扩展关系,向一个用例中添加一些动作后构成了另一个用例,这两个用例之间的关系就是扩展关系,后者称为扩展用例。例如,在自动售货机系统中,”售货”是一个基本的用例,如果顾客购买罐装饮料,顺利实现。而买散装饮料则不行，买散装饮料是非常规动作。把非常规动作放置于”售散装饮料”用例中,这两个用例之间关系就是扩展关系,(2)使用关系,当一个用例使用另一个用例时,这两个用例之间就构成了使用关系一般说来,如果在若干个用例中有某些相同的动作,则可以把这些相同的动作提取出来单独构成一个用例(成为抽象用例)。例如,在自动售货机系统中,”供货”和”取货款”都要先打开机器，结束后关闭机器。把打开机器抽象成”打开机器”用例,把最后的动作抽象成”关闭机器”用例。注意：通常在描述一般行为的变化时采用扩展关系;在两个或多个用例中出现重复描述又想避免这种重复时,可以采用使用关系,9.6.2 用例建模,一个用例模型由若干幅用例图组成创建用例模型的工作包括:定义系统,寻找行为者和用例 描述用例,定义用例之间的关系 确认模型。其中,寻找行为者和用例是关键。,1.寻找行为者,通过请系统的用户回答一些问题的办法来发现行为者，下述问题有助于发现行为者:谁将使用系统的主要功能(主行为者)?谁需要借助系统的支持来完成日常工作?谁来维护和管理系统(副行为者)?系统控制哪些硬件设备?系统需要与哪些其他系统交互?哪些人或系统对本系统产生的结果(值)感兴趣?,2.寻找用例,一旦找到了行为者,就可以通过请每个行为者回答下述问题来获取用例:行为者需要系统提供哪些功能?行为者自身需要做什么?行为者是否需要读取,创建,删除,修改或存储系统中的某类信息?系统中发生的事件需要通知行为者吗?行为者需要通知系统某些事情吗?从功能观点看,这些事件能做什么?行为者的日常工作是否因为系统的新功能而被简化或提高了效率?系统需要哪些输入输出?输入来自何处?输出到哪里去?当前使用的系统(可能是人工系统)存在的主要问题是什么?,9.6.2 用例建模,9.6.2 用例建模,9.7 三种模型之间的关系,三种模型之间关系FM：功能模型做什么WhatDM：动态模型何时做WhenOM：对象模型操作的实体How,9.7 三种模型之间的关系,(1)针对每个类建立的动态模型,描述了类实例的生命周期或运行周期。(2)状态转换驱使行为发生,这些行为在数据流图中被映射成处理,在用例图中被映射成用例,它们同时与类图中的服务相对应。(3)功能模型中的处理(或用例)对应于对象模型中的类所提供的服务。(4)数据流图中的数据存储,以及数据的源点/终点,通常是对象模型中的对象。,9.7 三种模型之间的关系,(5)数据流图中的数据流,往往是对象模型中对象的属性值,也可能是整个对象。(6)用例图中的行为者,可能是对象模型中的对象。(7)功能模型中的处理(或用例)可能产生动态模型中的事件。(8)对象模型描述了数据流图中的数据流,数据存储以及数据源点/终点的结构。,第10章 面向对象分析,分析的过程是提取系统需求的过程分析凶包括3项内容：理解、表达、验证面向对象分析的关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。由对象模型、动态模型、和功能模型组成。,10.1 面向对象分析的基本过程,10.1.1 概述,10.1.2 3个子模型与5个层次,Requirement statement=Rapid prototype=Models 3个模型Object model：最重要，开发任何系统都需要；Dynamic model：对于开发交互式系统(interactive system)很重要；Function model：对于开发大运算量问题（如科学计算、编译系统等）很重要5个层次,复杂问题的对象模型通常由5个层次组成：主题层 类与对象层 结构层 类与对象间的关系 属性层 服务层主题是指导读者理解大型、复杂模型的一种机制。通过划分主题把一个大型、复杂的对象分解成几个不同的概念范畴。从高层次描述总体模型，指导读者的注意力,5个层次对应5项主要活动：找出类与对象，识别结构、识别主题、定义属性、定义服务。工作顺序：寻找类与对象，识别结构、识别主题、定义属性、建立动态模型、建立功能模型、定义服务。,面向对象分析的基本过程,10.2 需求陈述,第三章中已介绍过，需求陈述的内容包括：问题范围、功能需求、性能要求、应用环境、假设条件等等。陈述方式可繁可简，说明What 而不是How。见教材对Automated Teller Machine(ATM)的需求陈述。,10.2.2 例子,10.3 建立对象模型,面向对象分析的首要工作，是建立问题域的对象模型。典型的工作步骤：确定Class-&-Object 确定关联结构层 完善 确立属性 识别继承关系及其它修改,10.3.1 确定类与对象Class-&-Object,第1步：列出所有候选对象(candidates)，它们可能是：(1)物理实体，(2)人或组织，(3)要处理的事件，(4)对象间的活动，(5)抽象概念 等等；另一种方法非正式分析：从需求陈述中挑出名词Class-&-Object形容词Attribute动词Method,2 去粗取精 筛选出正确的类与对象,2、确定关联结构层,两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类与对象。,1 初步确定关联,需求陈述中使用的描述性动词或动词词组，通常表示关联关系。大多数关联可以通过直接提取需求陈述中的动词词组得出。,ATM例子有下列关联,(1)直接提取动词短语得出的关联 ATM、中央计算机、分行计算机及柜员终端组成网络 总行拥有多台ATM ATM设在主要街道上 分行提供分行计算机和柜员终 端 柜员终端设在分行营业厅及储 蓄所内 分行分摊软件开发成本 储户拥有账户 分行计算机处理针对账户的事务,分行计算机维护账户 柜员终端与分行计算机通信 柜员输入针对账户的事务 ATM与中央计算机交换关于事务的信息 中央计算机确定事务与分行的对应关系 ATM读现金兑换卡 ATM与用户交互 ATM吐出现金 ATM打印账单 系统处理并发的访问,(2)需求陈述中隐含的关联 总行由各个分行组成 分行保管账户 总行拥有中央计算机 系统维护事务日志 系统提供必要的安全性 储户拥有现金兑换卡(3)根据问题知识得出的关联 现金兑换卡访问账户 分行雇用柜员,2 筛选,