面向对象方法学引论.PPT

1、1,第9章 面向对象方法学引论,9.1 面向对象方法学概述9.2 面向对象的概念9.3 面向对象建模9.4 对象模型9.5 动态模型9.6 功能模型9.7 3种模型之间的关系,2,面向对象的概念起源于20世纪60年代中期的Simula 67。80年代中期OOP模式进入主流。80年代中后期，面向对象分析与设计的研究开始发展。进入90年代，面向对象软件工程成了许多软件产品的开发模式。,1 面向对象方法学概述,3,面向对象方法学OOM(Object-Oriented Methodology),特点：尽可能模拟人类习惯的思维方式，即问题域与求解域在结构上尽可能一致。与传统方法相反，OOM把数据和处理结

2、合构成统一体 对象。这时程序不再是一系列工作在数据上的函数集合，而是相互协作又彼此独立的对象的集合。,4,成都,北 京,Message,Send by method,对象Object,Object,= 属性Attribute,Attributes: location; employee; ,+ 操作Method,Methods: send; sell; ,注意：对象内部的属性不允许外部用户直接改动，只有当它提供了相应的服务操作时，用户才能通过发送消息来提请它执行。,我想把邮局搬到我家门口，多加几个邮递员，24小时都开门,对不起，本邮局不提供此类服务,唉，那就先送束花吧 Post_office.

3、Send (request, payment),例：,5,OOM的四要素：,对象(object)：世界由对象组成。, 类 (class) ：具有相同属性和操作的对象可划分为类；单个对象可视为某一类的实例 (instance)。, 继承(inheritance)：类可分层，下层子类与上层父类有相同特征，称为继承。,OOM = Object+Class+Inheritance+Communication with messages, 消息(message)：对象间只能通过发送消息进行联系，外界不能处理对象的内部数据，只能通过消息请求它进行处理（如果它提供相应消息的话）。,6,OOM：以object

4、 为核心，强调对现实概念的模拟而不强调算法。“面向对象方法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可能直观、自然地表现求解方法的软件系统”。 Class：由特殊到一般的归纳 Inheritance：由一般到特殊的演绎,OOM相比传统方法的优点：, 传统方法：面向过程设计，以计算为核心，数据与操作分离，不易理解。,7,OOM：以object模拟实体，需求变化不会引起结构的整体变化，因为实体相对稳定，故系统也相应稳定。, 传统方法：结构依赖于功能，不稳定。,传统方法：通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”，难以适应不同场合的不同需要。,OOM：一个cl

5、ass所有的 instances 都可重用它的代码；由 inheritance 派生出的新的 class 可重用其父类的代码，并且可以修改、扩充而不影响其父类的使用。,8,稳定性好：软件功能需求的变化不牵动全局，只需局部修改；Class 独立性强：只要修改不涉及class的对外接口，则内部修改完全不影响外部调用；Inheritance和多态性(polymorphism)使其很容易被修改和扩充；容易理解；, 传统方法：可维护性是最令人头痛的问题。 OOM：从以下几方面改善了可维护性 ,注：OOM并不是减少了开发时间，而是通过提高可重用性、可维护性，进行扩充和修改的容易程度等，从长远角度改进了软件

6、的质量。OOM与Prototyping结合使用效果好。,9,特点： 以数据为中心，不设与数据无关的操作； Object主动处理而不 被动地等待被处理，外部只能通过message请求操作； 具有封装性：外部操作时，无须知道该object内部的数据结构及算法； 具有并行性：不同object各自独立地处理自身数据，彼此间仅通过传递message完成通信； 模块独立性好：内聚强、耦合松,2 面向对象的概念,1、对象,10,3、消息: object_ID. method_ID (parameter(s)；4、方法（操作）: object能做的操作，亦称为service, 在 class 中须定义相应的代

7、码；5、属性 ：object 的固有数据；,2、类：具有相同数据和相同操作的一组对象； 实例：某个class描述的具体对象；,6、封装：把内部实现细节隐藏起来，使其他外部对象无法访问，仅仅提供某些功能。使对象形成接口部分和实现部分,11,例：,7、继承：子类自动共享父类的attributes 和methods ，而不必重复定义。,特点： 若成都人的 methods中有与中国人的同名，则李四执行该 method 时以成都人为准，不执行中国人中定义的同名 method。, 传递性：AB、BC AC 一个 class 继承了上层全部 classes 的一切性质。,12,注意：多重继承在定义中应避免二

8、义性，即两二个父类中定义重名，但各具不同性质。,例：,CardDeck,GraphicalObject,GraphicalDeck,Method:Draw := take a card from a deck,Method:Draw := displaya graphical object,Method:Draw := ?,例：, 修改与扩充可以很容易地通过派生子类来完成。, 一个子类只 有 一 个父类称为单 继 承, 一个子类可有多个父类称为多重继承。,13,8、多态性与动态联编多态性是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。不同层次的 clas

9、ses 可共享一个method名，但按各自的方式来实现这种 method。,9、重载在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字。在C+语言中函数重载通过静态联编(也叫先前联编)实现。,如虚函数机制能在一个类等级中使用相同函数的多个不同版本，在运行时刻才根据接收消息的对象所属于的类，决定到底执行哪个特定的版本，称为动态联编，也叫滞后联编。,14,模型：为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。3种面向对象的模型： 描述系统数据结构的对象模型。 描述系统控制结构的动态模型。 描述系统功能的功能模型。一个典型的软件系统组合了上述3方面内容：它使用数据结构

10、(对象模型)，执行操作(动态模型)，并且完成数据值的变化(功能模型)。,3 面向对象建模,15,几种面向对象开发方法:,Booch方法 Booch是面向对象方法最早的提出者之一，提出了面向对象软件工程的概念。 Booch认为软件开发是一个螺旋上升的过程。Coad-Yourdon方法 著名的OOA/OOD方法，也是最早的面向对象的分析与设计方法之一。简单、易学。Rumbaugh方法（简称OMTObject Modeling Technology） 该方法强调了三种模型，并将软件开发过程划分为系统分析、系统设计、对象设计等几个阶段。Jacobson 方法（简称OOSE） 最大特点是强调使用用例（U

11、se-Case)，每一个用例就是一个使用系统的方式，用例的执行将引发执行一系列与行为相关的事务。,16,统一建模语言UML,由Rumbaugh、Booch、Jacobson提出的统一建模语言（Unified Modeing Language ） ，简称UML。 产生于90年代中期。它不仅统一了Booch、OMT和OOSE方法中的概念和表示法，而且对其作了进一步扩展，最终成为在面向对象技术领域占主导地位的、并被大众所接受的标准建模语言。UML不是一个开发过程，也不是一个方法，但允许任何一种开发过程和面向对象方法使用它。,17,类图用来描述系统中的类及类和类之间的静态关系。,类的表示：,例如：,可

12、访问性通常有3种：公有的(public)私有的(private) 保护的(protected)，分别用加号（+）、减号（-）和井号（#）表示。,类的完整表示,对象模型表现了客观世界实体对象的相互关系。通常使用UML提供的类图来建立对象模型。,4 对象模型,类图的基本符号,18,类图由类及类与类之间的关系组成。定义了类之后就可以定义类与类之间的各种关系了。类与类之间通常有关联、泛化（继承）、依赖和细化等4种关系。,表示关系的符号,19,类1,类2,角色,角色,关联名,角色表示该类在这个关联中的作用。如果没有显式标出角色名，则意味着用类名作为角色名。重数：该类有多少个对象与对方的一个对象连接。,关

13、联表示两个类的对象之间存在某种语义上的联系。,重数,1、关联,20,在表示关联的直线两端可以写上重数（multiplicity），它表示该类有多少个对象与对方的一个对象连接。重数的表示方法通常有：01表示0到1个对象0*或*表示0到多个对象1+或1*表示1到多个对象115表示1到15个对象3表示3个对象如果图中未明确标出关联的重数，则默认重数是1。,21,（1） 普通关联最常见的关联关系。,例如：,22,（2）递归关联即一个类与它本身有关联关系。,例如：,23,（3） 限定关联也叫受限关联，两个类及一个限定词组成，限定词是一种特定的属性，用来有效地减少关联的重数。在类图中把限定词放在关联关系末

14、端的一个小方框内。,限定关联通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或从多对多简化成多对一。,24,例如，某操作系统中一个目录下有许多文件，一个文件仅属于一个目录，在一个目录内文件名确定了惟一一个文件。图9.8利用限定词“文件名”表示了目录与文件之间的关系，可见，利用限定词把一对多关系简化成了一对一关系。,图9.8 一个受限的关联,25,限定提高了语义精确性，增强了查询能力。在图9.8中，限定的语法表明，文件名在其目录内是惟一的。因此，查找一个文件的方法就是，首先定下目录，然后在该目录内查找指定的文件名。由于目录加文件名可惟一地确定一个文件，因此，限定词“文件

15、名”应该放在靠近目录的那一端。,26,在一些情况下关联可能需要记录一些信息，但这些信息不能放在任何一个类中，可引入一个关联类记录这些信息。关联类通过一条虚线与关联连接。,（4） 关联类,27,2、聚集：,组合是一种强类型的聚集，整体类和部分类共存亡，如果整体类被撤销，部分类也不存在。,表示“整体-部分”的特殊关联,例如：,28,（1） 共享聚集如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集称为共享聚集。例如，一个课题组包含许多成员，每个成员又可以是另一个课题组的成员，则课题组和成员之间是共享聚集关系，。（2） 组合聚集如果部分类完全隶属于整体类，部分与整体共存，整

16、体不存在了部分也会随之消失（或失去存在价值了），则该聚集称为组合聚集（简称为组成）。例如，在屏幕上打开一个窗口，它就由文本框、列表框、按钮和菜单组成，一旦关闭了窗口，各个组成部分也同时消失，窗口和它的组成部分之间存在着组合聚集关系。,29,3. 泛化UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。注意，泛化针对类型而不针对实例，一个类可以继承另一个类，但一个对象不能继承另一个对象。实际上，泛化关系指出在类与类之间存在“一般

17、-特殊”关系。泛化可进一步划分成普通泛化和受限泛化。,30,由一个超类和几个直接子类构成的结构通常称为泛化 。表示一般-特殊关系或继承关系。,例如：,（1）普通泛化,31,需要特别说明的是，没有具体对象的类称为抽象类。抽象类通常作为父类，用于描述其他类（子类）的公共属性和行为。图示抽象类时，在类名下方附加一个标记值abstract，如图9.12所示。图下方的两个折角矩形是模型元素“笔记”的符号，其中的文字是注释，分别说明两个子类的操作drive的功能。抽象类通常都具有抽象操作。抽象操作仅用来指定该类的所有子类应具有哪些行为。抽象操作的图示方法与抽象类相似，在操作标记后面跟随一个性质串abstr

18、act。,32,图9.12 抽象类示例,33,与抽象类相反的类是具体类，具体类有自己的对象，并且该类的操作都有具体的实现方法。图9.13给出一个比较复杂的类图示例，这个例子综合应用了前面讲过的许多概念和图示符号。,34,图9.13 复杂类图示例,35,（2） 受限泛化可以给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法，这样的泛化关系称为受限泛化。预定义的约束有4种： 多重、不相交、完全和不完全。这些约束都是语义约束。多重继承指的是，一个子类可以同时多次继承同一个上层基类，例如图9.14中的水陆两用类继承了两次交通工具类。与多重继承相反的是不相交继承，即一个子类不能多次继承同

19、一个基类（这样的基类相当于C+语言中的虚基类）。如果图中没有指定多重约束，则是不相交继承，一般的继承都是不相交继承。,36,图9.14 多重继承示例,37,完全继承指的是父类的所有子类都已在类图中穷举出来了，图示符号是指定完全约束。不完全继承与完全继承恰好相反，父类的子类并没有都穷举出来，随着对问题理解的深入，可不断补充和维护，这为日后系统的扩充和维护带来很大方便。不完全继承是一般情况下默认的继承关系。,38,4、依赖和细化（1） 依赖关系描述两个模型元素（类、用例等）之间的语义连接关系： 其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素。,友元关系使得类B的操作可以

20、使用A类中私有的或保护的成员。,39,（2） 细化关系当对同一个事物在不同抽象层次上描述时，这些描述之间具有细化关系。假设两个模型元素A和B描述同一个事物，它们的区别是抽象层次不同，如果B是在A的基础上的更详细的描述，则称B细化了A，或称A细化成了B。细化用来协调不同阶段模型之间的关系，表示各个开发阶段不同抽象层次的模型之间的相关性，常常用于跟踪模型的演变,B,A,40,表示属于该类的对象,也可对类和对象用有区别的画法：,41,动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。一旦建立起对象模型之后，就需要考察对象的动态行为。所有对象都具有自己的生命周期（

21、或称为运行周期）。对一个对象来说，生命周期由许多阶段组成，在每个特定阶段中，都有适合该对象的一组运行规律和行为规则，用以规范该对象的行为。生命周期中的阶段也就是对象的状态。,动态模型：表示系统瞬时的控制性质,5 动态模型,42,注：当描述循环运行过程时，通常不关心是怎样启动的。,三要素： 事件 ：引发 object 状态改变的控制信息（瞬时）。 状态：即 object 的 attributes 所处的情形（可持续）。 活动：Object 要达到某种 status 所做的操作（耗时）。,状态图,43,通常，用UML提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为（对事件的响应）。每

22、个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型。也就是说，动态模型是基于事件共享而互相关联的一组状态图的集合。,44,例：电话的 状态图,45,UML提供的用例图也是建立功能模型的强有力工具。在UML中把用用例图建立起来的系统模型称为用例模型，一个用例模型由若干幅用例图组成。,6 功能模型,功能模型：表明系统应该做什么,通常的表示方法：数据流图（DFD）,用例图仅仅从参与者使用系统的角度描述系统，不反映内部的处理方式。因此用例图定义的是系统的功能需求。其主要目的是以一种可视化的方式理解系统的功能需求。 一幅用例图包含的模型元素有系统、行为者、用例及

23、用例之间的关系。,46,用例建模的主要步骤：首先定义一个系统；并在该系统中确定执行者；确定用例，描述每一个用例；确定关系（包括用例与执行者之间的关系，执行者之间的关系，用例之间的关系）；最后确认所建的模型。,47,1. 系统系统被看作是一个提供用例的黑盒子，内部如何工作、用例如何实现，这些对于建立用例模型来说都是不重要的。代表系统的方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能。描述该系统功能的用例置于方框内，代表外部实体的行为者置于方框外。,9.6.1 用例图,48,例如：,49,又如：,50,2. 用例一个用例是可以被行为者感受到的、系统的一个完整的功能。在UML

24、中把用例定义成系统完成的一系列动作，动作的结果能被特定的行为者察觉到。这些动作除了完成系统内部的计算与工作外，还包括与一些行为者的通信。用例通过关联与行为者连接，关联指出一个用例与哪些行为者交互，这种交互是双向的。用例具有下述特征：（1） 用例代表某些用户可见的功能，实现一个具体的用户目标；,51,（2） 用例总是被行为者启动的，并向行为者提供可识别的值；（3） 用例必须是完整的。注意，用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。脚本是系统的一次具体执行过程，例如，在自动售货机系统中，张三投入硬币购买矿泉水，系统收到

25、钱后把矿泉水送出来，上述过程就是一个脚本；李四投币买可乐，但是可乐已卖完了，于是系统给出提示信息并把钱退还给李四，这个过程是另一个脚本。,52,3. 行为者行为者是指与系统交互的人或其他系统，它代表外部实体。使用用例并且与系统交互的任何人或物都是行为者。行为者代表一种角色，而不是某个具体的人或物。事实上，一个具体的人可以充当多种不同角色。,53,在用例图中用直线连接行为者和用例，表示两者之间交换信息，称为通信联系。行为者触发（激活）用例，并与用例交换信息。单个行为者可与多个用例联系；反之，一个用例也可与多个行为者联系。对于同一个用例而言，不同行为者起的作用也不同。可以把行为者分成主行为者和副行

26、为者，还可分成主动行为者和被动行为者。实践表明，行为者对确定用例是非常有用的。面对一个大型、复杂的系统，要列出用例清单往往很困难，可以先列出行为者清单，再针对每个行为者列出它的用例。这样做可以比较容易地建立起用例模型。,54,4. 用例之间的关系UML用例之间主要有扩展和使用两种关系，它们是泛化关系的两种不同形式。（1） 扩展关系向一个用例中添加一些动作后构成了另一个用例，这两个用例之间的关系就是扩展关系，后者继承前者的一些行为，通常把后者称为扩展用例。例如，在自动售货机系统中，“售货”是一个基本的用例，如果顾客购买罐装饮料，售货功能完成得很顺利，但是，如果顾客要购买用纸杯装的散装饮料，则不能

27、执行该用例提供的常规动作，而要做些改动。,55,我们可以修改售货用例，使之既能提供售罐装饮料的常规动作又能提供售散装饮料的非常规动作，但是，这将把该用例与一些特殊的判断和逻辑混杂在一起，使正常的流程晦涩难懂。图9.18中把常规动作放在“售货”用例中，而把非常规动作放置于“售散装饮料”用例中，这两个用例之间的关系就是扩展关系。在用例图中，用例之间的扩展关系图示为带版类扩展的泛化关系。,56,图9.18 含扩展和使用关系的用例图,57,（2） 使用关系当一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般说来，如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个

28、用例（称为抽象用例）。这样，当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例中的所有动作。在用例图中，用例之间的使用关系用带版类使用的泛化关系表示，如图9.18所示。,58,请注意扩展与使用之间的异同： 这两种关系都意味着从几个用例中抽取那些公共的行为并放入一个单独的用例中，而这个用例被其他用例使用或扩展，但是，使用和扩展的目的是不同的。通常在描述一般行为的变化时采用扩展关系；在两个或多个用例中出现重复描述又想避免这种重复时，可以采用使用关系。,59,几乎在任何情况下都需要使用用例，通过用例可以获取用户需求，规划和控制项目。获取用例是需求分析阶段的主要工作之一，而且是首先要做的工作。大

29、部分用例将在项目的需求分析阶段产生，并且随着开发工作的深入还会发现更多用例，这些新发现的用例都应及时补充进已有的用例集中。用例集中的每个用例都是对系统的一个潜在的需求。,9.6.2 用例建模,60,一个用例模型由若干幅用例图组成。创建用例模型的工作包括： 定义系统，寻找行为者和用例，描述用例，定义用例之间的关系，确认模型。其中，寻找行为者和用例是关键。1. 寻找行为者为获取用例首先要找出系统的行为者，可以通过请系统的用户回答一些问题的办法来发现行为者。下述问题有助于发现行为者：谁将使用系统的主要功能（主行为者）？谁需要借助系统的支持来完成日常工作？谁来维护和管理系统（副行为者）？系统控制哪些硬

30、件设备？,61,系统需要与哪些其他系统交互？哪些人或系统对本系统产生的结果（值）感兴趣？2. 寻找用例一旦找到了行为者，就可以通过请每个行为者回答下述问题来获取用例：行为者需要系统提供哪些功能？行为者自身需要做什么？行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？系统中发生的事件需要通知行为者吗？行为者需要通知系统某些事情吗？从功能观点看，这些事件能做什么？,62,行为者的日常工作是否因为系统的新功能而被简化或提高了效率？还有一些不是针对具体行为者而是针对整个系统的问题，也能帮助建模者发现用例，例如：系统需要哪些输入输出？输入来自何处？输出到哪里去？当前使用的系统（可能是人工系统）

31、存在的主要问题是什么？注意，最后这两个问题并不意味着没有行为者也可以有用例，只是在获取用例时还不知道行为者是谁。事实上，一个用例必须至少与一个行为者相关联。,63,可用的构造型元素： 当描述一般行为时有例外、任选或异常处理时，采用extend（或扩展 ）。 当在两个或多个用例中出现重复描述（有共用行为）而又想避免重复时，采用include （或使用 ） 。,64,又如：,注：“设置边界”用例是指对某个特定用户规定最大贸易量,65,这三种模型都涉及到数据、控制和操作等概念，只是每种模型描述的侧重点不同。它们各自从不同的侧面反映了系统的实质性内容，综合起来则全面反映了对目标系统的需求。对象模型是最

32、基本、最核心、最重要的。,7 三种模型之间的关系,FM：做什么 What,DM：何时做 When,OM：操作的实体How,4）三者关系,66,OM,DM,FM,Object,DM,Action,Process,Method,Data storage,Data flow,Attribute,Event,对每个object (class) 建立DM;,Action对应DFD中的 process 以及OM中的 method;,FM中的 process 对应OM中的method;,FM中的数据存储及数据的源/终点对应OM中的 object;,FM中的数据流对应OM中的attribute，或是整个 object;,FM中的 process 产生DM中的 event;,OM描述了FM中的动作对象、数据存储及数据流的结构。,建立顺序：,67,用面向对象观点建立系统的模型，能够促进和加深对系统的理解，有助于开发出更容易理解、更容易维护的软件。通常，使用UML的类图来建立对象模型，使用UML的状态图来建立动态模型，使用数据流图或UML的用例图来建立功能模型。在UML中把用用例图建立起来的系统模型称为用例模型。,