软件工程第九讲--面向对象引论.ppt

第九章 面向对象方法学引论 9.1 面向对象方法学引论 9.2 面向对象概念 9.3 面向对象建模 9.4 对象模型 9.5 动态模型 9.6 功能模型 目标 了解面向对象概念 掌握类及类的关联关系 掌握用例及用例之间的关系 重用性差 开发周期长 经常不能满足用户的需要 很难维护 开发效率低 传统软件工程方法与面向对象方法 Conventional methods 部分缓解了软件危机 适用于中、小规模的项目开发 Object-oriented Methodology 20世纪60年代提出（Simula-67） 20世纪70年代出现很多面向对象编程语言 80年代形成了面向对象方法学，被广泛应用 90年代成为首选的开发方法 面向对象方法学 （Object-oriented Methodology，OOM） 语言解空间对象 汇编语言存储单元、寄存器 面向过程的高级语言各种预定义类型的变量、数组、记录、文件等 计算机系统求解问题的过程 问题 空间 限定抽象、符号化机器求解 现实世现实世 界问题界问题 解解 解 空间 语义断层 问题空间对象 行为丰富 复杂的算法 解空间对象 行为简单 语义断层语义断层 数据 操作操作 模拟“行为” 静态属性静态属性 动态行为动态行为 解空间 对象 OOM的特点 尽可能模拟人类习惯的思维方式 问题空间与求解空间在结构上尽可能一致 以数据或信息为主线，把数据和处理结合构成统一体 对象 软件系统：一系列离散的 集合 程序 一系列工作在一系列工作在数据数据上的上的函数函数集合集合CMCM OOMOOM 相互协作又彼此独立的相互协作又彼此独立的对象对象的集合的集合 解空间对象 OOM的四要素 n n 对象（对象（objectobject） n n 类（类（classclass）：）：data + methodsdata + methods 中国人中国人 类：对具有相同属性和行为的一个或多个对象的描述类：对具有相同属性和行为的一个或多个对象的描述 OOM的四要素 n n 对象（对象（objectobject） n n 类（类（classclass）：）：data + methodsdata + methods n n 继承（继承（inheritanceinheritance） n n 消息通信消息通信（communication with messagescommunication with messages） Coad emp_type employee ; public : void send (req_type request, money_type payment); void sell (int goods, money_type payment) ; ; main ( ) Post_office My_PO ; req_type My_request ; money_type My_payment ; My_PO.Send ( My_request, My_payment) ; 【例】 8. 继承（Inheritance） 子类自动地共享基类中定义的数据和方法的机制 类等级 chair table desk“chable“ instances of chair furniture (superclass) subclasses 类的继承机制 类A A的操作 A的变量 A的实例a1 类A A的实例变量 类B：A的子类 B的操作 B的变量 从A继承的特性 B的实例b1 继承来的A的实例变量 继承来的B的实例变量 类B 【例】类的继承机制 Class 中国人 中国人 methods 中国人 attributes instance 张三 Class 中国人 张三 attributes Class 武汉人(子类) 武汉人 methods 武汉人 attributes Class 中国人 instance 李四 中国人李四的attributes 武汉人李四的attributes Class 武汉人 低层性质低层性质overrideoverride高层性质高层性质 继承的传递性（transitivity） CB，BA CA 一个 class 继承了上层全部 classes 的一切性质 A A B B C C 单继承和多重继承 单继承 (single inheritance) 一个类只允许有一个父类 类等级为树形结构 多重继承（multiple inheritance) 一个子类可有多个父类 功能更强，使用更方便 注意避免二义性 汽 车 运 货 车 救 火 车 小 轿 车 起 重 车 退休者教师 退休教师 多重继承的二义性(ambiguity) 多个父类中定义重名，但各具不同性质的方法 CardDeckGraphicalObject GraphicalDeck Method: Draw := take a card from a deck Method: Draw := display a graphical object Method: Draw := ? 继承的优点 共享程序代码和数据结构，大大 减少了冗余信 息 修改方便 扩充：调用基类方法并增加代码 改变：改写同名方法 新增：定义新方法 软件重用 9. 多态性（Polymorphism） 不同层次的 classes 可共享一个method名，而 按各自的方式来实现该method 发送消息的对象不需要知道接受对象的类，接收 方决定消息的解释。即同一消息可以用不同方法 解释，方法的解释依赖于接收消息的类，而不依 赖于消息的发送者。 虚函数(virtual function)：一个method有多个 版本，运行时才决定执行哪一个 动态联编(dynamic binding)/滞后联编 (late binding) 虚函数(virtual function)：一个method有多个版本，运 行时才决定执行哪一个 把函数调用与目标代码块的连接延迟到运行时运行时进行 使系统更灵活 提高了系统的可重用性和可扩充性 多边形 四边形 矩形 三角形 draw 10. 重载（Overloading） 函数重载（function/parameter overloading ） 参数特征不同 算法不同 运算符重载（operator overloading） 操作数（operand）类型不同 运算符语义不同 double avg (const double a , int size) ; double avg (const int a , int size) ; double avg (const double a , int size) ; double sum = 0.0 ; for ( int i = 0; i size; +i ) sum += ai ; return ( sum / size ) ; double avg (const int a , int size) ; int sum = 0 ; for ( int i = 0; i size; +i ) sum += ai ; return ( (double) sum / size ) ; main() int k3 = 1, 2, 3 ; double x3 = 1.1, 2.2, 3.3 ; cout avg(k, 3) “ int average n” ; cout avg(x, 3) “ double average n” ; 重载 静态联编静态联编 (static binding) 先前联编先前联编 (early binding) 编译编译阶段阶段就决定了使 用类型及执行代码 不同函数共用一个名字， 而调用参数的特征不同 9.3、OOM的主要优点 与人类习惯的思维方法一致 稳定性好 可重用性好 可维护性好 较易开发大型软件产品 1与人类习惯的思维方法一致 CM 面向过程设计，以算法为核心，送数据到函数 数据与操作分离，不易理解 数据 程序代码程序代码 处理 DataData CodesCodes 一致一致! ! 问题空间解空间 语义断层语义断层 不一致不一致 Object 1与人类习惯的思维方法一致 OOM 以object 为核心，强调对现实概念的模拟而不强调算 法 “面向对象方法学的基本原则，是按照人们习惯的思维 方式建立问题域的模型，开发出尽可能直观、自然地表 现求解方法的软件系统” 数据和操作封装成统一体，送消息到对象 Object Attributes Methods 特殊特殊一般一般 归纳(induction) ：class 演绎(deduction)： Inheritance message 2稳定性好 CM 结构依赖于功能，不稳定 功能需求变，易引起软件结构整体修改 OOM 软件系统结构根据问题域模型建立 以object模拟实体，实体相对稳定，故系统也相应稳 定 需求变化不会引起结构的整体变化，只需局部性修改 3可重用性好 CM 过程（函数）是重用层 建立标准函数库来重用软构件 标准函数缺乏“柔性”，难以适应不同场合的不同需要 功能内聚的模块不是自含和独立的 OOM object具有较强的自含性和独立性 object和class提供了理想的模块化机制和可重用的软件成分 继承性为OOM提供了比CM更广泛、更规范、更简单的重用机制 4可维护性好 CM 开发出来的软件难维护 OOM 稳定性好：功能需求变化不牵动全局，只需局部修改 容易修改 Class 独立性强，修改完全不影响软件的其他成分。 Inheritance和多态性(polymorphism)，是修改和扩充容易 实现。 容易理解 容易测试、调试 5较易开发大型软件产品 CM 组织开发人员的方法不恰当 强调自顶向下功能分解，限制了可重用性，重复工作，生产率低 好的SD将控制集中在高层模块，因而对于复杂系统、GUI的交互 式系统、控制要求突出的系统，不能适应需求的变动 OOM 把一个大型产品看作是一系列本质上相互独立的小产品来处理 降低了开发的技术难度，而且也使得对开发工作的管理变得容易 自底向上分析和设计，自顶向下实现（继承），可重用性好 可见，OOM的主要优点并不是减少了开发时间，而是通过提高可 重用性、可维护性，进行扩充和修改的容易程度等，从长远角度 改进了软件的质量 实例01-01：“东北一家人？” 东北人都是活雷锋 人、东北人、雷锋 老张开车去东北 撞啦！ 老张、汽车、开车 撞啦 class 人 Region 籍贯； class Region interface 雷锋 helpPeople() class 东北人 extends 人 implements 雷锋 籍贯 = 东北； helpPeople() class Car DriveTo(Region) throws Exception (撞车) 人 Driver; Main Program 人 老张； Car 夏利； 夏利.Driver = 老张； try 夏利.DriveTo(东北); catch (Exception) 面向对象的表示 实例01-02：BOM单成本计算 问题： 根据BOM（Bill of Materials）单进行产品 原料成本的计算 分别用面向过程和面向对象的方式解决 目的： 体会过程式的思维方式与面向对象思维方式 之间的区别，体会面向对象“模拟现实世界”的 思维特色 实例01-02：问题描述 某产品BOM单如下，计算总价格 零部件零部件编编号号零部件名称零部件名称采采购购价格价格 00147零件110.00 00235零件221.50 10221组合件138.15 00772零件320.00 10039组合件219.90 实例01-02：问题难点分析 零件（Piece）、组合件（Assembly）、 部件（Part）的关系 零件和组合件都属于部件 组合件有零件和更小的组合件组成，而更小 的组合件最终由零件组成 组合件与零件之间存在递归关系，如何在程如何在程 序中体现这个递归关系序中体现这个递归关系，是本系统的关键 实例01-02：思考？ 用结构化的设计思路解决以上问题 用对象化的设计思路解决以上问题 将解决思路用自己认为合适的方式记录下来， 可以是伪码，可以是图形 思考： 结构化的设计与对象化的设计有什么本质的不同？体 现了怎样的思维差异？面向对象思想有何优势？ 表达设计思想用代码合适吗？方便吗？图形表示有何 优势？ 实例01-02：结构化设计 关键：用算法来描述递归关系 totalCost = 0.0 初始化iterator 是否计算完毕？ 是 返回totalCost 否 totalCost += calcPartCost(partIDcalcPartCost(partID) ) 实例01-02：结构化设计- calcPartCost getType(partID) 入口 PIECE c = cost(partID) ASSEMBLY c =calcAssemblyCost(partIDcalcAssemblyCost(partID) ) 出口 return c; calcPartCost(partIDcalcPartCost(partID) ) 实例01-02：结构化设计- calcAssemblyCost calcAssemblyCost(partIDcalcAssemblyCost(partID) ) iter.hasNext() 入口 NO YES c += calcPartCostcalcPartCost(iter.next().partID) 出口 return c; List partList = getPartsOfAssembly(partID); Iterator iter = partList.iterator(); 实例01-02：结构化小结 针对过程抽象 calcPartCostcalcPartCost (partID)函数与 calcAssemblyCostcalcAssemblyCost (partID)函数描述了 前述的递归关系 实例01-02：面向对象设计 关键：通过对象间的关系描述递归关系 实例01-02： API package BOM;package BOM; class BOMAPI class BOMAPI static final static final intint PIECE = 0; / PIECE = 0; / 零件零件 static final static final intint ASSEMBLY = 1; / ASSEMBLY = 1; / 组合件组合件 static final static final intint getType(StringgetType(String id); / id); / 判断是零件还是组合件判断是零件还是组合件 / / 返回零件的价格，如果不是零件，抛出返回零件的价格，如果不是零件，抛出NotPieceExceptionNotPieceException异常异常 static final double static final double cost(Stringcost(String id) throws id) throws NotPieceExceptionNotPieceException; ; / / 返回一个列表，其中包含组成组合件的零件返回一个列表，其中包含组成组合件的零件 static final List static final List getPartsOfAssembly(StringgetPartsOfAssembly(String id) id) throws throws NotAssemlyExceptionNotAssemlyException; ; 实例01-02：类图体现代码结构 abstract class Part abstract class Part public double cost(); public double cost(); class class PiecePartPiecePart extends Part extends Part public double cost(); public double cost(); class Assembly extends Part class Assembly extends Part private private LinkedListLinkedList itsPartsitsParts; / ; / 以链表结构存放组合件的组成部件以链表结构存放组合件的组成部件 public double cost();public double cost(); 实例01-02：代码: PiecePart.cost() public double cost() public double cost() double c = 0.0; double c = 0.0; try try c = c = BOMAPI.getCost(this.myIDBOMAPI.getCost(this.myID);); return c; return c; catch ( catch (NotPieceExceptionNotPieceException e) e) assert false : “Piece identify assertion error”; assert false : “Piece identify assertion error”; 实例01-02：代码: Assembly.cost() public double cost() public double cost() try try double c = 0.0; double c = 0.0; List parts = BOMAPI. List parts = BOMAPI. getPartsOfAssembly(this.myIDgetPartsOfAssembly(this.myID) ) IteratorIterator iteriter = = parts.iteratorparts.iterator();(); while ( while (iter.hasNextiter.hasNext() () Part p = ( Part p = (Part)iter.nextPart)iter.next();(); c += c += p.costp.cost();(); return c; return c; catch ( catch (NotAssemblyExceptionNotAssemblyException e) e) assert false : “Assembly identify assertion error”; assert false : “Assembly identify assertion error”; 实例01-02：代码：计算BOM总价 double double totalCosttotalCost = 0.0; = 0.0; IteratorIterator iteriter = = partsList.iteratorpartsList.iterator(); / (); / 把整个把整个BOMBOM当成一个大的当成一个大的 AssemblyAssembly while (while (iter.hasNextiter.hasNext() () Part Part partpart = (Part) = (Part) iter.nextiter.next();(); totalCosttotalCost += += part.costpart.cost();(); return return totalCosttotalCost; ; 实例01-02：顶级代码 BOM BOM bombom = new = new BOM(“BOM.xlsBOM(“BOM.xls”);”); totalCosttotalCost = = bom.calculateCostbom.calculateCost();(); 关键代码只有一行，因为关键代码只有一行，因为bombom知道怎么计算它自己的总成本知道怎么计算它自己的总成本 9.4、对象模型技术（Object Modeling Technique, OMT） OOM的工作重点在分析阶段，确定objects 1991，美国通用电气公司，Rambaugh等 用于分析、系统设计和对象级设计 把分析活动收集的信息构造在三类模型中 对象模型 对象、类、层次和关系 动态模型 对象和系统的行为 功能模型 类似于高层的DFD，描述穿越系统的信息 流 1. OMT的三种模型 功能模型（计算，功能）功能模型（计算，功能） 动态模型（控制结构）动态模型（控制结构） 对象模型（数据结构）对象模型（数据结构） 2. 对象模型（Object Model） 描述系统的静态结构 OOM强调围绕对象而不是围绕功能来构造系统 OOM可在不同开发阶段使用一致的表示方法 Peter Coad & Ed Yourdon提出的表示方法 （1）类-&-对象 一个类及属于该类的对象 Class Name Attributes Methods Class Class Name Attributes Methods Class-&-Object 表示属于该类 的对象 类图的基本符号(I) 1. 定义类 UML中类的图形符号为长方形，用两条横 线把长方形分成上、中、下3个区域,3个 区域分别放类的名字、属性和服务 类图的基本符号(II) 属性用来描述类的特征，表示需要处理的数据。 定义如下： 2. 定义属性 visibility attribute-name : type = initial-value property-string 可见性 属性名 ：类型 = 缺省值 性质串 其中：可见性(visibility)表示该属性对类外的元素是否可见。 分为： public（+） 公有的，即模型中的任何类都可以访问该属性。 private（-） 私有的，表示不能被别的类访问。 protected（#） 受保护的，表示该属性只能被该类及其子类访 问。 如果可见性未申明，表示其可见性不确定。 类图的基本符号(III) 3. 定义操作 对数据的具体处理方法的描述则放在操作部分， 操作说明了该类能做些什么工作。UML描述操 作的语法格式如下： 操作可见性的定义方法与属性相同。 参数表是用逗号分隔的形式参数的序列。描述一 个参数的语法如下： 参数名： 类型名=默认值 visibility operating-name(parameter-list): return-type property- string 可见性 操作名（参数表）：返回类型性质串 (2) 表示关系的符号(I) 类与类之间关系有： 关联 聚集 泛化（继承） 依赖 细化 (3) 关联(I) 关联表示两个类的对象之间存在某种语义 上的联系。 （1） 普通关联 普通关联示例 (3) 关联(II) 在表示关联的直线两端可以写上重数（ multiplicity），它表示该类有多少个对象与对方 的一个对象连接。重数的表示方法通常有： 01表示0到1个对象 0*或*表示0到多个对象 1+或1*表示1到多个对象 115表示1到15个对象 3表示3个对象 如果图中未明确标出关联的重数，则默认重数是1 。 (3) 关联(III) （2） 关联的角色 在任何关联中都会涉及到参与此关联的对 象所扮演的角色（即起的作用），在某些 情况下显式标明角色名有助于别人理解类 图。如果没有显式标出角色名，则意味着 用类名作为角色名。 递归关联 (Recursive association) 一个类与本身 有关联关系 (3) 关联(IV) （3） 限定关联 限定关联通常用在一对多或多对多的关联 关系中，可以把模型中的重数从一对多变 成一对一，或从多对多简化成多对一。在 类图中把限定词放在关联关系末端的一个 小方框内。 (3) 关联(V) 在银行环境中，帐号确定唯一的帐户。 (3) 关联(VI) 下图是否合适？ 文件夹与文件的关联 书架与书的关联 (3) 关联(VII) (3) 关联(VIII) （4） 关联类 为了说明关联的性质可能需要一些附加信息。可以引 入一个关联类来记录这些信息。 关联中的每个连接与关联类的一个对象相联系。关联 类通过一条虚线与关联连接。 关联类是一种关联，也是一个类。关联类的实例从组 成类的实例中派生出标识。 (3) 关联(IX) 图3-19显示了如何将一对一和一对多关联 的属性折叠进对着“一”那端的类。通常， 不应该将这种属性折叠到类中，因为关联 的多重性可能会变化。如果WorksFor的 多重性变成多对多的话，下图就不正确。 (3) 多元关联(例) 项目 程序语言 程序员 (3) 多元关联的对象图(例) CAD程序 : 项目 C : 语言 记账系统 : 项目 COBOL : 语言 张三 : 开发人员 三重关联对象图 (4) 聚集(I) 聚集是一种特殊的关联，它指出类间的“整体- 部分”关系。 （1） 共享聚集 如果在聚集关系中处于部分方的对象可同时参 与多个处于整体方对象的构成，则该聚集称为 共享聚集。 (4) 聚集(II) （2） 组合聚集 如果部分类完全隶属于整体类，部分与整体共 存，整体不存在了部分也会随之消失，则该聚 集称为组合聚集。 (5) 泛化(I) UML中的泛化关系就是通常所说的继承关系。 （1） 普通泛化 附加标记 注释 普通泛化 (5) 泛化(II) （2） 受限泛化 可以给泛化关系附加约束条件，以进一步说明该泛化 关系的使用方法或扩充方法，这样的泛化关系称为受 限泛化。预定义的约束有4种： 多重、不相交、完全 和不完全。下图：多重继承 (5) 泛化(III) 完全继承指的是父类的所有子类都已在类图中 穷举出来了，图示符号是指定完全约束。 不完全继承与完全继承恰好相反，父类的子类 并没有都穷举出来，不完全继承是一般情况下 默认的继承关系。 complete 人 女人男人 性别 图9.13 复杂类图示例 组合聚集 组合聚集 抽象类 组合聚集 抽象操作 泛化 具体实现 (6) 依赖(I) 依赖关系表示： 其中一个模型元素是独立的 ，另一个模型元素不是独立的，它依赖于独立 的模型元素，如果独立的模型元素改变了，将 影响依赖于它的模型元素。 (6) 依赖(II) UML2.0中的依赖种类如下： Access(访问) bind(绑定) call(调用) create(创建) derive(派生) instantiate(实例化) permit(允许) realize(实现) refine(精化) send(发送) substitute(替换) trace(追踪依赖) use(使用) (7) 细化 当对同一个事物在不同抽象层次上描述时，这 些描述之间具有细化关系。假设两个模型元素 A和B描述同一个事物，它们的区别是抽象层 次不同，如果B是在A的基础上的更详细的描 述，则称B细化了A，或称A细化成了B。 注意是虚线， 实线就成了泛化 类的命名 使用标准术语 使用具有确切含义的名词 名词短语 3. 动态模型（Dynamic Model） 基于事件共享而互相关联的一组状态图的集合 表示系统瞬时的控制性质 三要素 事件 (event)：引发 object 状态改变的控制信息（瞬时） 状态(status):即 object 的 attributes 所处的情形（可持续） 行为(action): Object 要达到某种 status 所做的操作（耗时） Event 0Status 1 do: Action 1 Status 2 do: Action 2 Event 1Event 2 Start End Condition 1 【例】电话系统的状态转换图 闲置 拨号音 do：响拨号音 拨号 接通中 do：试接通 振铃 do：振铃 通话 断线 忙音 do：响忙音 超时 do：响蜂鸣音 提示信息 do：播放信息 挂 机 数字 占线 摘机 数字 有效号码 已接通 受话人摘机应答 受话人挂机 超时 超时 无效号码 挂 机 信 息 播 完 4. 功能模型（Function Model） 表明系统应该“做什么” 数据流图（DFD） IPO Pseudocode (1) 用例图（Use Case） 一幅用例图包含的模型元素有系统、行为 者、用例及用例之间的关系。 1. 系统 系统被看作是一个提供用例的黑盒子 代表系统的方框的边线表示系统的边界，用 于划定系统的功能范围，定义了系统所具有 的功能 描述该系统功能的用例置于方框内 代表外部实体的行为者置于方框外 图9.17 自动售货机系统用例图 (1) 用例图（Use Case） 2. 用例 一个用例是可以被行为者感受到的、系统 的一个完整的功能。用例具有下述特征： （1） 用例代表某些用户可见的功能，实现一 个具体的用户目标； （2） 用例总是被行为者启动的，并向行为 者提供可识别的值； （3） 用例在功能上必须是完整的。 注意，用例是一个类，它代表一类功能而不是使用该 功能的某个具体实例。用例的实例是系统的一种实际 使用方法，通常把用例的实例称为脚本。 (1) 用例图（Use Case） 3. 行为者 执行者是指用户在系统中所扮演的角色。 执行者在用例图中是用类似人的图形来表 示, 但执行者可以是人，也可以是一个外 界系统。 注意：用例总是由行为者启动的。 如何识别角色？ 可以通过向用户提出以下问题来识别角色 谁使用系统的主要功能 谁需要系统的支持以完成其日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付或处理那些硬设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 (1) 用例图（Use Case） 4. 用例之间的关系 UML用例之间主要有扩展和包含(使用)两 种关系，它们是泛化关系的两种不同形式 。 使用或者包含也是用例间的一种关系，它实质 上还是类之间的一种继承关系。如用例A使用了 用例B，本质上就是用例A完全继承了用例B所 描述的行为，同时增加专属自己的行为。 扩展实质上是用例间的一般/特殊化关系 ，扩展可以用例间的继承符号并标注上扩 展模版类型来表示。 当发现已经存在的两个用例间具有某种相 似性时，可以把这个相似的部分抽取出来 作为抽象用例。 (1.1) 包含关系(I) 包含(include)关系将一个用例合并到另一 个用例的行为序列中。被包含的用例就像 是子程序表示那些必须要重复描述的行 为。 包含关系UML的表示法从源(包含)用例指 向目标用例(被包含)用例的一个带虚线的 箭头，并用关键词include来注释箭头 。 (1.1) 包含关系(II) 也可以使用表示法include use-case- name将用例穿插到文本描述当中。 不要用包含关系来组织行为的细节结构。 用例建模的目的是确定系统的功能，以及 参与者与系统之间通用的控制流。 当片段可以表示重要的行为单元时，把用 例分解成片段的做法是适宜的。 (1.2) 扩展关系(I) 扩展(extend)关系给用例添加增量行为。 从反方向来看，它很像是包含关系，扩展 用例会把自己加入到基用例中，而不是基 用例显式地合并扩展用例。 它表示这样的常见的场合，首先定义某个 初始功能，随后在模块化地增加特性。 包含和扩展关系都给基用例添加行为。 (1.2) 扩展关系(II) 扩展关系连接扩展用例和基用例。扩展用 例经常也是片段-即它不能作为行为序列 单独出现。 基用例在缺少任何扩展用例的情况下也必 须是合法用例。 扩展用例要确定在基用例行为序列中的插 入位置。 多数情况下，扩展关系有一个附加条件： 只有当控制到达插入位置时条件为真，才 会发生扩展行为。 (1.3) 泛化(I) 泛化(generalization)可以显示通用用例的 一个特定变体。父用例表示用例的行为序