《面向对象方法学.pptx》由会员分享,可在线阅读,更多相关《面向对象方法学.pptx(74页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 面向对象方法学的出发点和基本原则,是尽可能模拟人类习惯的思维方式,使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程,也就是使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。1、面向对象方法学概述第1页/共74页概括地说,面向对象方法具有下述4个要点:(1)认为客观世界是由各种对象组成的,任何事物都是对象,复杂的对象可以由比较简单的对象以某种方式组合而成。按照这种观点,可以认为整个世界就是一个最复杂的对象。因此,面向对象的软件系统是由对象组成的,软件中的任何元素都是对象,复杂的软件对象由比较简单的对象组合而成。由此可见,面向对象方法用对象
2、分解取代了传统方法的功能分解。第2页/共74页(2)把所有对象都划分成各种对象类(简称为类,class),每个对象类都定义了一组数据和一组方法。数据用于表示对象的静态属性,是对象的状态信息。因此,每当建立该对象类的一个新实例时,就按照类中对数据的定义为这个新对象生成一组专用的数据,以便描述该对象独特的属性值。类中定义的方法,是允许施加于该类对象上的操作,是该类所有对象共享的,并不需要为每个对象都复制操作的代码。第3页/共74页(3)按照子类(或称为派生类)与父类(或称为基类)的关系,把若干个对象类组成一个层次结构的系统(也称为类等级)。在这种层次结构中,通常下层的派生类具有和上层的基类相同的特
3、性(包括数据和方法),这种现象称为继承(inheritance)。但是,如果在派生类中对某些特性又做了重新描述,则在派生类中的这些特性将以新描述为准,也就是说,低层的特性将屏蔽高层的同名特性。第4页/共74页(4)对象彼此之间仅能通过传递消息互相联系。对象与传统的数据有本质区别,它不是被动地等待外界对它施加操作,相反,它是进行处理的主体,必须发消息请求它执行它的某个操作,处理它的私有数据,而不能从外界直接对它的私有数据进行操作。也就是说,一切局部于该对象的私有信息,都被封装在该对象类的定义中,就好像装在一个不透明的黑盒子中一样,在外界是看不见的,更不能直接使用,这就是“封装性”。第5页/共74
4、页1.与人类习惯的思维方法一致 传统的程序设计技术是面向过程的设计方法,这种方法以算法为核心,把数据和过程作为相互独立的部分,数据代表问题空间中的客体,程序代码则用于处理这些数据。面向对象方法学的优点第6页/共74页2.稳定性好 传统的软件开发方法以算法为核心,开发过程基于功能分析和功能分解。用传统方法所建立起来的软件系统的结构紧密依赖于系统所要完成的功能,当功能需求发生变化时将引起软件结构的整体修改。事实上,用户需求变化大部分是针对功能的,因此,这样的软件系统是不稳定的。第7页/共74页3.可重用性好 用已有的零部件装配新的产品,是典型的重用技术,例如,可以用已有的预制件建筑一幢结构和外形都
5、不同于从前的新大楼。重用是提高生产率的最主要的方法。第8页/共74页4.较易开发大型软件产品 在开发大型软件产品时,组织开发人员的方法不恰当往往是出现问题的主要原因。用面向对象方法学开发软件时,构成软件系统的每个对象就像一个微型程序,有自己的数据、操作、功能和用途,因此,可以把一个大型软件产品分解成一系列本质上相互独立的小产品来处理,这就不仅降低了开发的技术难度,而且也使得对开发工作的管理变得容易多了。这就是为什么对于大型软件产品来说,面向对象范型优于结构化范型的原因之一。第9页/共74页5.可维护性好 用传统方法和面向过程语言开发出来的软件很难维护,是长期困扰人们的一个严重问题,是软件危机的
6、突出表现。第10页/共74页 在应用领域中有意义的、与所要解决的问题有关系的任何事物都可以作为对象,它既可以是具体的物理实体的抽象,也可以是人为的概念,或者是任何有明确边界和意义的东西。,对象是对问题域中某个实体的抽象,设立某个对象就反映了软件系统具有保存有关它的信息并且与它进行交互的能力。2、面向对象的概念(1)对象第11页/共74页由于客观世界中的实体通常都既具有静态的属性,又具有动态的行为,因此,面向对象方法学中的对象是由描述该对象属性的数据以及可以对这些数据施加的所有操作封装在一起构成的统一体。对象可以作的操作表示它的动态行为,在面向对象分析和面向对象设计中,通常把对象的操作称为服务或
7、方法。1.对象的形象表示为有助于读者理解对象的概念,下图形象地描绘了具有3个操作的对象。第12页/共74页对象的形象表示第13页/共74页 一个对象很像一台录音机。当在软件中使用一个对象的时候,只能通过对象与外界的界面来操作它。对象与外界的界面也就是该对象向公众开放的操作。使用对象向公众开放的操作就好像使用录音机的按键,只须知道该操作的名字(好像录音机的按键名)和所需要的参数(提供附加信息或设置状态,根本无须知道实现这些操作的方法。事实上,实现对象操作的代码和数据是隐藏在对象内部的,一个对象好像是一个黑盒子,表示它内部状态的数据和实现各个操作的代码及局部数据,都被封装在这个黑盒子内部,在外面是
8、看不见的,更不能从外面去访问或修改这些数据或代码。第14页/共74页(2)类(class)现实世界中存在的客观事物有些是彼此相似的,例如,张三、李四、王五虽说每个人职业、性格、爱好、特长等等各有不同,但是,他们的基本特征是相似的,都是黄皮肤、黑头发、黑眼睛,于是人们把他们统称为“中国人”。人类习惯于把有相似特征的事物归为一类,分类是人类认识客观世界的基本方法。第15页/共74页 在面向对象的软件技术中,“类”就是对具有相同数据和相同操作的一组相似对象的定义,也就是说,类是对具有相同属性和行为的一个或多个对象的描述,通常在这种描述中也包括对怎样创建该类的新对象的说明。以上先详细地阐述了对象的定义
9、,然后在此基础上定义了类。也可以先定义类再定义对象,例如,可以像下面这样定义类和对象:类是支持继承的抽象数据类型,而对象就是类的实例。第16页/共74页(3)实例(instance)实例就是由某个特定的类所描述的一个具体的对象。类是对具有相同属性和行为的一组相似的对象的抽象,类在现实世界中并不能真正存在。实际上类是建立对象时使用的“样板”,按照这个样板所建立的一个个具体的对象,就是类的实际例子,通常称为实例。当使用“对象”这个术语时,既可以指一个具体的对象,也可以泛指一般的对象,但是,当使用“实例”这个术语时,必然是指一个具体的对象。第17页/共74页(4)消息(message)消息就是要求某
10、个对象执行在定义它的那个类中所定义的某个操作的规格说明。通常,一个消息由下述3部分组成:接收消息的对象;消息选择符(也称为消息名);零个或多个变元。(5)方法(method)方法就是对象所能执行的操作,也就是类中所定义的服务。方法描述了对象执行操作的算法,响应消息的方法。在C+语言中把方法称为成员函数。第18页/共74页(6)属性(attribute)属性就是类中所定义的数据,它是对客观世界实体所具有的性质的抽象。类的每个实例都有自己特有的属性值。在C+语言中把属性称为数据成员(7)封装(encapsulation)从字面上理解,所谓封装就是把某个事物包起来,使外界不知道该事物的具体内容。把数
11、据和实现操作的代码集中起来放在对象内部。一个对象好像是一个不透明的黑盒子,表示对象状态的数据和实现操作的代码与局部数据,都被封装在黑盒子里面。第19页/共74页封装也就是信息隐藏,通过封装对外界隐藏了对象的实现细节。对象类实质上是抽象数据类型。类把数据说明和操作说明与数据表达和操作实现分离开了,使用者只需知道它的说明(值域及可对数据施加的操作),就可以使用它。7.继承(inheritance)广义地说,继承是指能够直接获得已有的性质和特征,而不必重复定义它们。在面向对象的软件技术中,继承是子类自动地共享基类中定义的数据和方法的机制。第20页/共74页实现继承机制的原理第21页/共74页当一个类
12、只允许有一个父类时,也就是说,当类等级为树形结构时,类的继承是单继承;当允许一个类有多个父类时,类的继承是多重继承。多重继承的类可以组合多个父类的性质构成所需要的性质,因此功能更强、使用更方便;但是,使用多重继承时要注意避免二义性。继承性使得相似的对象可以共享程序代码和数据结构,从而大大减少了程序中的冗余信息。在程序执行期间,对对象某一性质的查找是从该对象类在类等级中所在的层次开始,沿类等级逐层向上进行的,并把第一个被找到的性质作为所要的性质。因此,低层的性质将屏蔽高层的同名性质。第22页/共74页(9)多态性(polymorphism)多态性一词来源于希腊语,意思是“有许多形态”。在面向对象
13、的软件技术中,多态性是指子类对象可以像父类对象那样使用,同样的消息既可以发送给父类对象也可以发送给子类对象。也就是说,在类等级的不同层次中可以共享(公用)一个行为(方法)的名字,然而不同层次中的每个类却各自按自己的需要来实现这个行为。当对象接收到发送给它的消息时,根据该对象所属于的类动态选用在该类中定义的实现算法。第23页/共74页(10)重载(overloading)有两种重载:函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字;运算符重载是指同一个运算符可以施加于不同类型的操作数上面。当然,当参数特征不同或被操作数的类型不同时,实现函数的算法或运算符的语义是不相同的
14、。第24页/共74页 为了更好地理解问题,人们常常采用建立问题模型的方法。所谓模型,就是为了理解事物而对事物作出的一种抽象,是对事物的一种无歧义的书面描述。通常,模型由一组图示符号和组织这些符号的规则组成,利用它们来定义和描述问题域中的术语和概念。更进一步讲,模型是一种思考工具,利用这种工具可以把知识规范地表示出来。模型可以帮助我们思考问题、定义术语、在选择术语时作出适当的假设,并且可以帮助我们保持定义和假设的一致性。3、面向对象建模第25页/共74页 一个典型的软件系统组合了3方面内容:它使用数据结构(对象模型),执行操作(动态模型),并且完成数据值的变化(功能模型)。用面向对象方法开发软件
15、,在任何情况下,对象模型始终都是最重要、最基本、最核心的。在整个开发过程中,3种模型一直都在发展、完善。在面向对象分析过程中,构造出完全独立于实现的应用域模型;在面向对象设计过程中,把求解域的结构逐渐加入到模型中;在实现阶段,把应用域和求解域的结构都编成程序代码并进行严格的测试验证。第26页/共74页 对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射,描述了系统的静态结构。对象模型为建立动态模型和功能模型,提供了实质性的框架。4、对象模型第27页/共74页 在建立对象模型时,我们的目标是从客观世界中提炼出对具体应用有价值的概念。为了建立对象
16、模型,需要定义一组图形符号,并且规定一组组织这些符号以表示特定语义的规则。也就是说,需要用适当的建模语言来表达模型,建模语言由记号(即模型中使用的符号)和使用记号的规则(语法、语义和语用)组成。第28页/共74页类图描述类及类与类之间的静态关系。类图是一种静态模型,它是创建其他UML图的基础。一个系统可以由多张类图来描述,一个类也可以出现在几张类图中。定义类UML中类的图形符号为长方形,用两条横线把长方形分成上、中、下3个区域(下面两个区域可省略),3个区域分别放类的名字、属性和服务。4.1 类图的基本符号第29页/共74页 表示类的图第30页/共74页如前所述,类图由类及类与类之间的关系组成
17、。定义了类之后就可以定义类与类之间的各种关系了。类与类之间通常有关联、泛化(继承)、依赖和细化等4种关系。1.关联关联表示两个类的对象之间存在某种语义上的联系。例如,作家使用计算机,我们就认为在作家和计算机之间存在某种语义连接,因此,在类图中应该在作家类和计算机类之间建立关联关系。4.2 表示关系的符号第31页/共74页(1)普通关联普通关联是最常见的关联关系,只要在类与类之间存在连接关系就可以用普通关联表示。普通关联的图示符号是连接两个类之间的直线。通常,关联是双向的,可在一个方向上为关联起一个名字,在另一个方向上起另一个名字(也可不起名字)。为避免混淆,在名字前面(或后面)加一个表示关联方
18、向的黑三角。第32页/共74页 普通关联示例第33页/共74页在表示关联的直线两端可以写上重数(multiplicity),它表示该类有多少个对象与对方的一个对象连接。重数的表示方法通常有:01表示0到1个对象0*或*表示0到多个对象1+或1*表示1到多个对象115表示1到15个对象3表示3个对象如果图中未明确标出关联的重数,则默认重数是1。第34页/共74页(2)关联的角色在任何关联中都会涉及到参与此关联的对象所扮演的角色(即起的作用),在某些情况下显式标明角色名有助于别人理解类图。例如,下图是一个递归关联(即一个类与它本身有关联关系)的例子。一个人与另一个人结婚,必然一个人扮演丈夫的角色,
19、另一个人扮演妻子的角色。如果没有显式标出角色名,则意味着用类名作为角色名。第35页/共74页 关联的角色第36页/共74页(3)限定关联限定关联通常用在一对多或多对多的关联关系中,可以把模型中的重数从一对多变成一对一,或从多对多简化成多对一。在类图中把限定词放在关联关系末端的一个小方框内。例如,某操作系统中一个目录下有许多文件,一个文件仅属于一个目录,在一个目录内文件名确定了惟一一个文件。利用限定词“文件名”表示了目录与文件之间的关系,可见,利用限定词把一对多关系简化成了一对一关系。第37页/共74页 一个受限的关联第38页/共74页限定提高了语义精确性,增强了查询能力。限定的语法表明,文件名
20、在其目录内是惟一的。因此,查找一个文件的方法就是,首先定下目录,然后在该目录内查找指定的文件名。由于目录加文件名可惟一地确定一个文件,因此,限定词“文件名”应该放在靠近目录的那一端。(4)关联类为了说明关联的性质可能需要一些附加信息。可以引入一个关联类来记录这些信息。关联中的每个连接与关联类的一个对象相联系。关联类通过一条虚线与关联连接。第39页/共74页 例如,一个电梯系统的类模型,队列就是电梯控制器类与电梯类的关联关系上的关联类。从图中可以看出,一个电梯控制器控制着4台电梯,这样,控制器和电梯之间的实际连接就有4个,每个连接都对应一个队列(对象),每个队列(对象)存储着来自控制器和电梯内部
21、按钮的请求服务信息。电梯控制器通过读取队列信息,选择一个合适的电梯为乘客服务。关联类与一般的类一样,也有属性、操作和关联。第40页/共74页关联类示例第41页/共74页2.聚集聚集也称为聚合,是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。在陈述需求时使用的“包含”、“组成”、“分为部分”等字句,往往意味着存在聚集关系。除了一般聚集之外,还有两种特殊的聚集关系,分别是共享聚集和组合聚集。第42页/共74页(1)共享聚集 如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成,则该聚集称为共享聚集。例如,一个课题组包含许多成员,每个成员又可以是另一个课题组的成员,则课题组和
22、成员之间是共享聚集关系。一般聚集和共享聚集的图示符号,都是在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形。第43页/共74页图9.10 共享聚集示例第44页/共74页(2)组合聚集 如果部分类完全隶属于整体类,部分与整体共存,整体不存在了部分也会随之消失(或失去存在价值了),则该聚集称为组合聚集(简称为组成)。例如,在屏幕上打开一个窗口,它就由文本框、列表框、按钮和菜单组成,一旦关闭了窗口,各个组成部分也同时消失,窗口和它的组成部分之间存在着组合聚集关系,组成关系用实心菱形表示。第45页/共74页图9.11 组合聚集示例第46页/共74页3.泛化UML中的泛化关系就是通常所说的继承关
23、系,它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息,并且还可以附加一些其他信息。在UML中,用一端为空心三角形的连线表示泛化关系,三角形的顶角紧挨着通用元素。注意,泛化针对类型而不针对实例,一个类可以继承另一个类,但一个对象不能继承另一个对象。实际上,泛化关系指出在类与类之间存在“一般-特殊”关系。泛化可进一步划分成普通泛化和受限泛化。第47页/共74页(1)普通泛化 需要特别说明的是,没有具体对象的类称为抽象类。抽象类通常作为父类,用于描述其他类(子类)的公共属性和行为。图示抽象类时,在类名下方附加一个标记值abstract,如下图所示。图下方的两个折角矩形是模型元
24、素“笔记”的符号,其中的文字是注释,分别说明两个子类的操作drive的功能。第48页/共74页图9.12 抽象类示例第49页/共74页(2)受限泛化可以给泛化关系附加约束条件,以进一步说明该泛化关系的使用方法或扩充方法,这样的泛化关系称为受限泛化。多重继承指的是,一个子类可以同时多次继承同一个上层基类,例如下图中的水陆两用类继承了两次交通工具类。第50页/共74页4.依赖和细化(1)依赖关系依赖关系描述两个模型元素(类、用例等)之间的语义连接关系:其中一个模型元素是独立的,另一个模型元素不是独立的,它依赖于独立的模型元素,如果独立的模型元素改变了,将影响依赖于它的模型元素。在UML的类图中,用
25、带箭头的虚线连接有依赖关系的两个类,箭头指向独立的类。在虚线上可以带一个版类标签,具体说明依赖的种类,例如,下图表示一个友元依赖关系,该关系使得B类的操作可以使用A类中私有的或保护的成员。第51页/共74页友元依赖关系第52页/共74页(2)细化关系 当对同一个事物在不同抽象层次上描述时,这些描述之间具有细化关系。假设两个模型元素A和B描述同一个事物,它们的区别是抽象层次不同,如果B是在A的基础上的更详细的描述,则称B细化了A,或称A细化成了B。细化的图示符号为由元素B指向元素A的、一端为空心三角形的虚线(注意,不是实线)。第53页/共74页 细化关系示例第54页/共74页动态模型表示瞬时的、
26、行为化的系统的“控制”性质,它规定了对象模型中的对象的合法变化序列。一旦建立起对象模型之后,就需要考察对象的动态行为。所有对象都具有自己的生命周期(或称为运行周期)。对一个对象来说,生命周期由许多阶段组成,在每个特定阶段中,都有适合该对象的一组运行规律和行为规则,用以规范该对象的行为。生命周期中的阶段也就是对象的状态。5、动态模型第55页/共74页所谓状态,是对对象属性值的一种抽象。当然,在定义状态时应该忽略那些不影响对象行为的属性。各对象之间相互触发(即作用)就形成了一系列的状态变化。我们把一个触发行为称作一个事件。对象对事件的响应,取决于接受该触发的对象当时所处的状态,响应包括改变自己的状
27、态或者又形成一个新的触发行为。状态有持续性,它占用一段时间间隔。状态与事件密不可分,一个事件分开两个状态,一个状态隔开两个事件。事件表示时刻,状态代表时间间隔。第56页/共74页通常,用UML提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为(对事件的响应)。每个类的动态行为用一张状态图来描绘,各个类的状态图通过共享事件合并起来,从而构成系统的动态模型。也就是说,动态模型是基于事件共享而互相关联的一组状态图的集合。第57页/共74页功能模型表示变化的系统的“功能”性质,它指明了系统应该“做什么”,因此更直接地反映了用户对目标系统的需求。通常,功能模型由一组数据流图组成。在面向对象方
28、法学中,数据流图远不如在结构分析、设计方法中那样重要。一般说来,与对象模型和动态模型比较起来,数据流图并没有增加新的信息,但是,建立功能模型有助于软件开发人员更深入地理解问题域,改进和完善自己的设计。因此,不能完全忽视功能模型的作用。6、功能模型第58页/共74页UML提供的用例图也是进行需求分析和建立功能模型的强有力工具。在UML中把用用例图建立起来的系统模型称为用例模型。用例模型描述的是外部行为者(actor)所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果,它描述了开发者和用户对需求规格所达成的共识。第59页/共74页一幅用例图包含的模型元素有系统、行为者、用例及用例之间
29、的关系。1.系统系统被看作是一个提供用例的黑盒子,内部如何工作、用例如何实现,这些对于建立用例模型来说都是不重要的。代表系统的方框的边线表示系统的边界,用于划定系统的功能范围,定义了系统所具有的功能。描述该系统功能的用例置于方框内,代表外部实体的行为者置于方框外。6.1 用例图第60页/共74页自动售货机系统用例图第61页/共74页2.用例一个用例是可以被行为者感受到的、系统的一个完整的功能。在UML中把用例定义成系统完成的一系列动作,动作的结果能被特定的行为者察觉到。这些动作除了完成系统内部的计算与工作外,还包括与一些行为者的通信。用例通过关联与行为者连接,关联指出一个用例与哪些行为者交互,
30、这种交互是双向的。用例具有下述特征:(1)用例代表某些用户可见的功能,实现一个具体的用户目标;第62页/共74页(2)用例总是被行为者启动的,并向行为者提供可识别的值;(3)用例必须是完整的。注意,用例是一个类,它代表一类功能而不是使用该功能的某个具体实例。用例的实例是系统的一种实际使用方法,通常把用例的实例称为脚本。脚本是系统的一次具体执行过程,例如,在自动售货机系统中,张三投入硬币购买矿泉水,系统收到钱后把矿泉水送出来,上述过程就是一个脚本;李四投币买可乐,但是可乐已卖完了,于是系统给出提示信息并把钱退还给李四,这个过程是另一个脚本。第63页/共74页3.行为者行为者是指与系统交互的人或其
31、他系统,它代表外部实体。使用用例并且与系统交互的任何人或物都是行为者。行为者代表一种角色,而不是某个具体的人或物。事实上,一个具体的人可以充当多种不同角色。第64页/共74页在用例图中用直线连接行为者和用例,表示两者之间交换信息,称为通信联系。行为者触发(激活)用例,并与用例交换信息。单个行为者可与多个用例联系;反之,一个用例也可与多个行为者联系。对于同一个用例而言,不同行为者起的作用也不同。可以把行为者分成主行为者和副行为者,还可分成主动行为者和被动行为者。实践表明,行为者对确定用例是非常有用的。面对一个大型、复杂的系统,要列出用例清单往往很困难,可以先列出行为者清单,再针对每个行为者列出它
32、的用例。这样做可以比较容易地建立起用例模型。第65页/共74页4.用例之间的关系UML用例之间主要有扩展和使用两种关系,它们是泛化关系的两种不同形式。(1)扩展关系向一个用例中添加一些动作后构成了另一个用例,这两个用例之间的关系就是扩展关系,后者继承前者的一些行为,通常把后者称为扩展用例。例如,在自动售货机系统中,“售货”是一个基本的用例,如果顾客购买罐装饮料,售货功能完成得很顺利,但是,如果顾客要购买用纸杯装的散装饮料,则不能执行该用例提供的常规动作,而要做些改动。第66页/共74页我们可以修改售货用例,使之既能提供售罐装饮料的常规动作又能提供售散装饮料的非常规动作,但是,这将把该用例与一些
33、特殊的判断和逻辑混杂在一起,使正常的流程晦涩难懂。图9.18中把常规动作放在“售货”用例中,而把非常规动作放置于“售散装饮料”用例中,这两个用例之间的关系就是扩展关系。在用例图中,用例之间的扩展关系图示为带版类扩展的泛化关系。第67页/共74页图9.18 含扩展和使用关系的用例图第68页/共74页(2)使用关系当一个用例使用另一个用例时,这两个用例之间就构成了使用关系。一般说来,如果在若干个用例中有某些相同的动作,则可以把这些相同的动作提取出来单独构成一个用例(称为抽象用例)。这样,当某个用例使用该抽象用例时,就好像这个用例包含了抽象用例中的所有动作。在用例图中,用例之间的使用关系用带版类使用
34、的泛化关系表示,如图9.18所示。第69页/共74页请注意扩展与使用之间的异同:这两种关系都意味着从几个用例中抽取那些公共的行为并放入一个单独的用例中,而这个用例被其他用例使用或扩展,但是,使用和扩展的目的是不同的。通常在描述一般行为的变化时采用扩展关系;在两个或多个用例中出现重复描述又想避免这种重复时,可以采用使用关系。第70页/共74页几乎在任何情况下都需要使用用例,通过用例可以获取用户需求,规划和控制项目。获取用例是需求分析阶段的主要工作之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着开发工作的深入还会发现更多用例,这些新发现的用例都应及时补充进已有的用例集中。
35、用例集中的每个用例都是对系统的一个潜在的需求。6.2 用例建模第71页/共74页一个用例模型由若干幅用例图组成。创建用例模型的工作包括:定义系统,寻找行为者和用例,描述用例,定义用例之间的关系,确认模型。其中,寻找行为者和用例是关键。1.寻找行为者为获取用例首先要找出系统的行为者,可以通过请系统的用户回答一些问题的办法来发现行为者。下述问题有助于发现行为者:谁将使用系统的主要功能(主行为者)?谁需要借助系统的支持来完成日常工作?谁来维护和管理系统(副行为者)?系统控制哪些硬件设备?第72页/共74页系统需要与哪些其他系统交互?哪些人或系统对本系统产生的结果(值)感兴趣?2.寻找用例一旦找到了行为者,就可以通过请每个行为者回答下述问题来获取用例:行为者需要系统提供哪些功能?行为者自身需要做什么?行为者是否需要读取、创建、删除、修改或存储系统中的某类信息?系统中发生的事件需要通知行为者吗?行为者需要通知系统某些事情吗?从功能观点看,这些事件能做什么?第73页/共74页感谢您的观看!第74页/共74页