软件工程导论class14面向对象方法学引论
合集下载
软件工程导论第章面向象方法学引论
第9章面向对象方法学引论传统地软件工程方法学曾经给软件产业带来巨大进步,部分地缓解了软件危机,使用这种方法学开发地许多中、小规模软件工程都获得了成功。
但是,人们也注意到当把这种方法学应用于大型软件产品地开发时,似乎很少取得成功。
在20世纪60年代后期出现地面向对象编程语言Simdla_67中首次引入了类和对象地概念,自20世纪80年代中期起,人们开始注重面向对象分析和设计地研究,逐步形成了面向对象方法学。
到了20世纪90年代,面向对象方法学已经成为人们在开发软件时首选地范型。
面向对象技术已成为当前最好地软件开发技术。
9.1面向对象方法学概述9.1.1 面向对象方法学地要点面向对象方法学地出发点和基本原则,是尽可能模拟人类习惯地思维方式,使开发软件地方法与过程尽可能接近人类认识世界解决问题地方法与过程,也就是使描述问题地问题空间(也称为问题域)与实现解法地解空间(也称为求解域)在结构上尽可能一致。
客观世界地问题都是由客观世界中地实体及实体相互间地关系构成地。
我们把客观世界中地实体抽象为问题域中地对象(object)。
因为所要解决地问题具有特殊性,因此,对象是不固定地。
一个雇员可以作为一个对象,一家公司也可以作为一个对象,到底应该把什么抽象为对象,由所要解决地问题决定。
从本质上说,用计算机解决客观世界地问题,是借助于某种程序设计语言地规定,对计算机中地实体施加某种处理,并用处理结果去映射解。
我们把计算机中地实体称为解空间对象。
显然,解空间对象取决于所使用地程序设计语言。
例如,汇编语言提供地对象是存储单元；面向过程地高级语言提供地对象,是各种预定义类型地变量、数组、记录和文件等等。
一旦提供了某种解空间对象,就隐含规定了允许对该类对象施加地操作。
从动态观点看,对对象施加地操作就是该对象地行为。
在问题空间中,对象地行为是极其丰富多彩地,然而解空间中地对象地行为却是非常简单呆板地。
因此,只有借助于十分复杂地算法,才能操纵解空间对象从而得到解。
软件工程 第九章面向对象方法学引论
第九章面向对象方法学引论
2．结构化技术的缺点 ． 用这种技术开发出的软件，其稳定性、 用这种技术开发出的软件，其稳定性、可修改 性和可重用性都比较差。 性和可重用性都比较差。 围绕实现处理功能的“过程”来构造系统的。 围绕实现处理功能的“过程”来构造系统的。 然而用户需求的变化大部分是针对功能的— 然而用户需求的变化大部分是针对功能的 —稳定性差； 稳定性差； 稳定性差 清楚地定义了目标系统的边界， 清楚地定义了目标系统的边界，软件通过界 面与客观世界通信。系统结构依赖于对系统 面与客观世界通信。系统结构依赖于对系统 边界的定义， 边界的定义，很难把这样的系统扩展到新的 边界——系统较难修改和扩充； 系统较难修改和扩充； 边界 系统较难修改和扩充 把处理分解成子处理的过程多少带些任意性， 把处理分解成子处理的过程多少带些任意性， 并且把数据和操作作为分离的实体——可重 并且把数据和操作作为分离的实体 可重 用性差。 用性差。
第九章面向对象方法学引论
存在的问题 1．生产率提高的幅度远不能满足需要 •生命周期方法学强调需求分析的重要性，强调 生命周期方法学强调需求分析的重要性， 生命周期方法学强调需求分析的重要性 在每个阶段结束之前必须进行评审， 在每个阶段结束之前必须进行评审，从而提高 了软件开发的成功率，减少了重大返工的次数； 了软件开发的成功率，减少了重大返工的次数； •开发过程中实行严格的质量管理，采用先进的 开发过程中实行严格的质量管理， 开发过程中实行严格的质量管理 技术方法（主要是结构分析、设计、编程技术） 技术方法（主要是结构分析、设计、编程技术） 和软件工具，也都加快了软件开发的速度。 和软件工具，也都加快了软件开发的速度。 •但开发效率的提高仍然很有限，提高的幅度远 但开发效率的提高仍然很有限， 但开发效率的提高仍然很有限 远赶不上对软件产品的需要。 远赶不上对软件产品的需要。 •从用户提出要求到他们最终得到所需要的目标 从用户提出要求到他们最终得到所需要的目标 系统，往往需要经过几年甚至更长的延迟时间。 系统，往往需要经过几年甚至更长的延迟时间。
第6章 面向对象方法学引论
例2：发送消息 MyCircle.Show(Green)
18
《 软件工程导论》
第6章 面向对象方法学引论
消息
注意 倒置 区别：
call turnLeft(hom1,40)
传统软件技术
先 申请一个过 程单元
然后 向其提供操 作的对象
消息 hom1.turnLeft(40)
面向对象技术
先 申请一个对象 然后 执行其中一
已存在的类通常称作超类，新的类通常称作子类。
继承（从C到D） 是指：
类D在类C中隐式的定义其每个属性和操作，就好像这 些属性和操作是在类D本身中定义一样。
C称为D的超类；D称为C的子类。
对象类D可以充分利用类C对象的属性和操作。
21
《 软件工程导论》
第6章 面向对象方法学引论
继承（inheritance）
消息是一个实例对象与另一个实例对象的通信单元，是 要求某个实例对象执行类中定义的某个操作。
发送给一个实例对象的消息定义了一个操作名和一个参 数表（可能是空的），并指定某一个实例对象。
一个实例对象接收的消息则调用消息中指定的操作，并 将形式参数与参数表中相应的值结合起来。
17
《 软件工程导论》
第6章 面向对象方法学引论
3
《 软件工程导论》
第6章 面向对象方法学引论
6.1 面向对象方法学概述
90年代，以OOA/OOD方法逐渐走向实用。一些专家按 照面向对象思想，对系统分析和系统设计工作的步骤、 方法、图形工具等进行了详细的研究，提出了许多不同 的实施方案。其中最有影响的有： 1988年 Shlaer 和 Mellor发表第一本OOA书； 1990年 Coad 和 Yourdon 发展出更简单的合作行 为思想； Booch 进行综合工作； Rumbaugh 提出的 OMT（对象模型化技术）； Jacobson 的 OOSE（面向对象的软件工程）；
18
《 软件工程导论》
第6章 面向对象方法学引论
消息
注意 倒置 区别：
call turnLeft(hom1,40)
传统软件技术
先 申请一个过 程单元
然后 向其提供操 作的对象
消息 hom1.turnLeft(40)
面向对象技术
先 申请一个对象 然后 执行其中一
已存在的类通常称作超类，新的类通常称作子类。
继承（从C到D） 是指：
类D在类C中隐式的定义其每个属性和操作，就好像这 些属性和操作是在类D本身中定义一样。
C称为D的超类；D称为C的子类。
对象类D可以充分利用类C对象的属性和操作。
21
《 软件工程导论》
第6章 面向对象方法学引论
继承（inheritance）
消息是一个实例对象与另一个实例对象的通信单元，是 要求某个实例对象执行类中定义的某个操作。
发送给一个实例对象的消息定义了一个操作名和一个参 数表（可能是空的），并指定某一个实例对象。
一个实例对象接收的消息则调用消息中指定的操作，并 将形式参数与参数表中相应的值结合起来。
17
《 软件工程导论》
第6章 面向对象方法学引论
3
《 软件工程导论》
第6章 面向对象方法学引论
6.1 面向对象方法学概述
90年代，以OOA/OOD方法逐渐走向实用。一些专家按 照面向对象思想，对系统分析和系统设计工作的步骤、 方法、图形工具等进行了详细的研究，提出了许多不同 的实施方案。其中最有影响的有： 1988年 Shlaer 和 Mellor发表第一本OOA书； 1990年 Coad 和 Yourdon 发展出更简单的合作行 为思想； Booch 进行综合工作； Rumbaugh 提出的 OMT（对象模型化技术）； Jacobson 的 OOSE（面向对象的软件工程）；
面向对象的方法学导论
游戏开发
游戏开发中，面向对象方 法学可以用于游戏对象的 设计和管理。
Web开发
移动应用开发
Web开发中，面向对象方 法学可以用于设计和开发 Web应用程序和Web服务。
移动应用开发中，面向对 象方法学可以用于设计和 开发各种移动应用程序。
02
面向对象的基本原则
抽象原则
01 定义
抽象原则是指将对象的共同属性和行为抽象出来， 形成一个通用的抽象类，以减少重复的代码。
与传统的过程式或函数式编 程相比，面向对象编程可能 会带来一定的性能开销，尤 其是在处理大量数据时。
可维护性问题
由于面向对象编程鼓励使用 大量的类和对象，这可能导 致代码结构变得复杂，从而 增加维护的难度。
06
面向对象方法学的未来发展
面向对象方法学的局限性
过度抽象
面向对象方法学强调抽象，但过度抽象可能导致代码难以理解和 维护。
简化问题复杂度。
封装性
封装隐藏了对象的内 部实现细节，提高了 代码的安全性和可维
护性。
继承性
通过继承，子类可以 继承父类的属性和行 为，提高了代码的复
用性。
多态性
多态提高了代码的灵 活性和可扩展性，可 以实现动态绑定和接 口的多种实现方式。
面向对象方法学的应用领域
软件工程
面向对象方法学适用于软 件工程领域，特别是大型 软件系统的设计和开发。
实现
在面向对象编程中，通过访问控 制修饰符（如private、 protected、public）来控制对象 的属性和方法的访问权限，实现 封装。
优点
封装原则可以提高代码的安全性 和稳定性，减少外部对内部细节 的干扰和破坏。
继承原则
01 定义
09面向对象方法学引论
Booch方法（1991） Coad-Yourdon方法（1991） Rumbaugh 方法(简称OMT）（Object Modeling Technology，1991） Jacobson 方法（简称OOSE，1992） 由Rumbaugh、Booch、Jacobson提出的统一建模语言 (简称UML) (Unify Modeing Language，1994)
对象模型
表示关系的符号
关系种类 – 关联
–
–
关联的属性
进一步说明对象间关联的性质
对象模型
表示关系的符号
关系种类 – 聚合（聚集）
– – 一种“整体与成员”的关系。表示整体类的那一端增加一个菱形框。 包括共享聚合和组合聚合。
对象模型
表示关系的符号
关系种类 – 泛化
– – 继承性的体现。 通常包含一个基类和几个子类。基类表示较为一般、普通的概念； 子类则继承基类的属性和操作，但又具有自身的属性和操作。
面向对象方法学概述
面向对象软件的工程
按人类习惯的思维方法，以现实世界中客观存在的事 物（即对象）为中心来思考和认识问题。 采用的思想方法与原则：抽象、分类、继承、聚合、 封装等。 以易于理解的方式表达软件系统，建立问题域模型， 使设计出的软件尽可能直接地描述现实世界，具有更 好的可维护性。 面向对象＝对象＋类＋继承＋通信 如果一个软件系统采用这些概念来建立模型并予 以实现，那么它就是面向对象的。
面向对象概念
其他概念
继承(inheritance) – 在现存类定义的基础上，建立新定义类的技术。 – 新类的定义可以是现存类所声明的数据、定义与新 类所增加的声明的组合。新类复用现存类的定义， 而不要求修改现存类。 – 现存类可当作父类（泛化类、基类或超类）来引用 ， 则新类相应地可当作子类（特化类、子女类或派生 类）来引用。 – 实现继承机制的原理
对象模型
表示关系的符号
关系种类 – 关联
–
–
关联的属性
进一步说明对象间关联的性质
对象模型
表示关系的符号
关系种类 – 聚合（聚集）
– – 一种“整体与成员”的关系。表示整体类的那一端增加一个菱形框。 包括共享聚合和组合聚合。
对象模型
表示关系的符号
关系种类 – 泛化
– – 继承性的体现。 通常包含一个基类和几个子类。基类表示较为一般、普通的概念； 子类则继承基类的属性和操作，但又具有自身的属性和操作。
面向对象方法学概述
面向对象软件的工程
按人类习惯的思维方法，以现实世界中客观存在的事 物（即对象）为中心来思考和认识问题。 采用的思想方法与原则：抽象、分类、继承、聚合、 封装等。 以易于理解的方式表达软件系统，建立问题域模型， 使设计出的软件尽可能直接地描述现实世界，具有更 好的可维护性。 面向对象＝对象＋类＋继承＋通信 如果一个软件系统采用这些概念来建立模型并予 以实现，那么它就是面向对象的。
面向对象概念
其他概念
继承(inheritance) – 在现存类定义的基础上，建立新定义类的技术。 – 新类的定义可以是现存类所声明的数据、定义与新 类所增加的声明的组合。新类复用现存类的定义， 而不要求修改现存类。 – 现存类可当作父类（泛化类、基类或超类）来引用 ， 则新类相应地可当作子类（特化类、子女类或派生 类）来引用。 – 实现继承机制的原理
软件工程-面向对象方法学引论
行为者触发(激活)用例，并与用例交换信息。 实践表明，行为者对确定用例是非常有用的。 可先列出行为者清单，再针对每个行为者列出它的用例。
这样做就比较容易地建立起用例模型。
4．用例之间的关系 扩展关系和使用关系，它们是泛化关系的两种不同形式。
1) 扩展关系 向一个用例中添加一些新的动作后构成了另一个用例，
三种模型之间的关系
1）针对每个类建立的动态模型， 描述了类实例的生命周期或运行周期。
2）状态转换驱使行为发生， 这些行为在数据流图中被映射成处理，
在用例图中被映射成用例， 它们同时与类图中的服务相对应。 3）功能模型中的处理(或用例)对应于对象模型中的
类所提供的服务。 有时一个处理(或用例)对应于多个服务， 也有一个服务对应多个处理（或用例）的时候。
通常下层的派生类具有和上层的基类相同的特性 （包括数据和方法）。
4) 对象彼此之间仅能通过传递消息互相联系。
6.1.2面向对象方法学的优点
• 1. 与人类习惯的思维方法一致 • 2. 稳定性好 • 3. 可重用性好 • 4. 较易开发大型软件产品 • 5. 可维护性好
9.2面向对象的概念
• 9.2.1对象 • 1. 对象的形象表示
对象模型为建立动态模型和功能模型，提供了实质 性的框架。
国际上UML（Unified Modeling Language；统一建 模语言）作为面向对象技术的标准建模语言。
通常，使用UML提供的类图来建立对象模型。
9.4对象模型
9.4.1类图的基本符号 • 1. 定义类
类名
Circle（圆）
属性 操作(服务)
接口），符合高内聚、低耦合的设计原则。
9.2.2其他概念
• 1. 类(class) • 2. 实例(instance) • 3. 消息(message) • 4. 方法(method) • 5. 属性(attribute) • 6. 封装(encapsulation) • 7. 继承(inheritance) • 8. 多态性(polymorphism) • 9. 重载(overloading)
这样做就比较容易地建立起用例模型。
4．用例之间的关系 扩展关系和使用关系，它们是泛化关系的两种不同形式。
1) 扩展关系 向一个用例中添加一些新的动作后构成了另一个用例，
三种模型之间的关系
1）针对每个类建立的动态模型， 描述了类实例的生命周期或运行周期。
2）状态转换驱使行为发生， 这些行为在数据流图中被映射成处理，
在用例图中被映射成用例， 它们同时与类图中的服务相对应。 3）功能模型中的处理(或用例)对应于对象模型中的
类所提供的服务。 有时一个处理(或用例)对应于多个服务， 也有一个服务对应多个处理（或用例）的时候。
通常下层的派生类具有和上层的基类相同的特性 （包括数据和方法）。
4) 对象彼此之间仅能通过传递消息互相联系。
6.1.2面向对象方法学的优点
• 1. 与人类习惯的思维方法一致 • 2. 稳定性好 • 3. 可重用性好 • 4. 较易开发大型软件产品 • 5. 可维护性好
9.2面向对象的概念
• 9.2.1对象 • 1. 对象的形象表示
对象模型为建立动态模型和功能模型，提供了实质 性的框架。
国际上UML（Unified Modeling Language；统一建 模语言）作为面向对象技术的标准建模语言。
通常，使用UML提供的类图来建立对象模型。
9.4对象模型
9.4.1类图的基本符号 • 1. 定义类
类名
Circle（圆）
属性 操作(服务)
接口），符合高内聚、低耦合的设计原则。
9.2.2其他概念
• 1. 类(class) • 2. 实例(instance) • 3. 消息(message) • 4. 方法(method) • 5. 属性(attribute) • 6. 封装(encapsulation) • 7. 继承(inheritance) • 8. 多态性(polymorphism) • 9. 重载(overloading)
第9章面向对象方法学引论
面向对象方法学的引入
面向对象方法学的优点：
与人类习惯的思维方法一致； 系统稳定性好； 可重用性好； 较易开发大型软件产品； 可维护性好。
面向对象方法学的引入
（1）与人类习惯的思维方法一致
传统的程序设计技术：
以算法为核心，数据和过程相分离。
面向对象的软件技术：
以对象为核心。对象是封装了描述内部状态表 示静态属性的数据及这些对数据施加的操作。
9.1 基本概念
对象 抽象成
对象：山地自行车
型号：28 ……
对象：公主自行车
型号：24 ……
类
类：自行车
型号 轮子尺寸 排挡 材料
换档 移动 修理
基本概念
练习：
1.分析下列对象之间的关系 家具、沙发、衣柜、电视柜 服装、衬衣，裤子 家用电器、电视、DVD机、组合音响
2.为什么说夏利牌汽车是小汽车类的特化，而发 动机不是小汽车类的特化？
公有的 + 私有的 保护的 #
表示属性的数据类型 该属性所有可能取值
对象模型
定义服务：
UML描述操作的语法格式如下：
可见性 操作名（参数表）： 返回值类型{性质串}
公有的
逗号分隔
私有的
的形式参
保护的
数序列
描述参数的语法如下：
参数名：类型名=默认值
对象模型
9.3.2 表示关系的符号
类图由类及类与类之间的关系组成
类与类之间有4种关系： 关联；泛化(继承)；依赖；细化。
对象模型
（1）关联
两个类的对象之间存在某种语义上的联系 ① 普通关联：只要类与类之间存在连接关 系就可以用普通关联表示。
符号：连接两个类之间的直线。
普通关联示例 注：、：关联方向。通常关联是双向的，关联方向上可以起名字。
软件工程导论第十四章
UML的表示法 UML的表示法
② 图 – 图是用来表达一个视图的内容的，通常，一 图是用来表达一个视图的内容的，通常， 个视图由多张图组成。 个视图由多张图组成。 – 一幅图包含了系统某一特殊方面的信息，阐 一幅图包含了系统某一特殊方面的信息， 明了系统的一个特定部分或方面。 明了系统的一个特定部分或方面。 – UML语言共定义了9种不同的图，把它们有机 UML语言共定义了9种不同的图， 语言共定义了 地结合起来就可以描述系统的所有视图。 地结合起来就可以描述系统的所有视图。
UML历史 UML历史
UML已经迅速成长为一个事实上的工业标准。 UML已经迅速成长为一个事实上的工业标准。 已经迅速成长为一个事实上的工业标准
不论在计算机学术界、软件产业界还是在商业界， 不论在计算机学术界、软件产业界还是在商业界， UML已经逐渐成为人们为各种系统建模、 UML已经逐渐成为人们为各种系统建模、描述系统 已经逐渐成为人们为各种系统建模 体系结构、 体系结构、商业体系结构和商业过程时使用的统一 工具，而且在实践过程中人们还在不断扩展它的应 工具， 用领域。 用领域。 1996年底，UML已稳定占领OO技术市场的85%。 1996年底，UML已稳定占领OO技术市场的85%。 年底 已稳定占领OO技术市场的85%
统一建模语言UML 统一建模语言UML
梁文新
办公室：综合楼108 电 话： 87571625 liang@
UML的历史 UML的历史
面向对象分析与设计方法的发展在20世纪80年代末到90年 面向对象分析与设计方法的发展在20世纪80年代末到90年 20世纪80年代末到90 代中出现了一个高潮，统一建模语言UML就是这个高潮的 代中出现了一个高潮，统一建模语言UML就是这个高潮的 UML 产物。 产物。 UML是由面向对象方法领域的 UML是由面向对象方法领域的Three Amigos:James Rumbaugh, Ivar Jacobson和Grady Booch共同提出 Jacobson和 Booch共同提出
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程导论 第 14 课
9.4.2 表示关系的符号
9.4.2 表示关系的符号
类与类之间通常有关联、泛化（继承）、依 赖和细化等4种关系
1 关联
关联表示两个类的对象之间存在某种语义上的联 系
9.4.2 表示关系的符号
普通关联：
最常见的关联关系，只要在类与类之间存 在连接关系就可以用普通关联表示。
(1)针对每个类建立的动态模型,描述了类实 例的生命周期或运行周期。
(2)状态转换驱使行为发生,这些行为在数据 流图中被映射成处理, 在用例图中被映射成 用例,它们同时与类图中的服务相对应。
(3)功能模型中的处理(或用例)对应于对象模 型中的类所提供的服务。
(4)数据流图中的数据存储,以及数据的源点/ 终点,通常是对象模型中的对象。
不应对系统中的每个类都画状态图，而只 应对某些 关键类建立状态图；而且应将状态 图与其它技术组 合使用
9.6 功能模型
表示变化的系统的“功能”性质，它指明了 系统应该“做什么”，因此更直接地反映了 用户对目标系统的需求
功能模型由一组数据流图组成，在面向对象方法学中 ，数据流图 远不如在结构分析设计方法中那样重要
1.寻找行为者
通过请系统的用户回答一些问题的办法来发现行为 者，下述问题有助于发现行为者: 谁将使用系统的主要功能(主行为者)? 谁需要借助系统的支持来完成日常工作? 谁来维护和管理系统(副行为者)? 系统控制哪些硬件设备? 系统需要与哪些其他系统交互? 哪些人或系统对本系统产生的结果(值)感兴趣?
不完全继承指的是父类的所有子类没有都穷举出来
4 依赖和细化 (1)依赖关系：依赖关系描述两个模型元素之间 的语义连接关系，其 中一个模型元素是独立的， 另一个模型元素不是独立的，如果独立的模型 元素改变，将影响依赖于它的模型元素。
箭头指向独立的类
(2)细化关系：当对同一个事物在不同抽象层次 上描述时，这些描述之间具有细化关系。
行为者代表一种角色，而不是某个具体的人或物
例如，在自动售货机系统中，使用售货功能的人 既可以是张三 （买矿泉水）也可以是李四的（买 可乐），但是不能把张三或李四这样的个体对象 称为行为者。
直线连接行为者和用例，表示两者之间交换信息 ，称为通信联系。行为者触发用例，并与用例交 换信息
４用例之间的关系
箭头由更详细层指向上层
9.5 动态模型
动态模型表示瞬时的，行为化的系统的“控 制”性质,它规定了对象模型中的对象的合法 变化序列。
状态是任何可以被观察到的系统行为模式，
每个类的动态行为用一张状态图来描绘
各个类的状态图通过共享事件合并起来， 从而构成系统 的动态模型
动态模型是基于事件共享而互相关联的一 组状态图的集 合
例如，在自动售货机系统中，张三投入硬币购买 矿泉水，系统收到钱后把矿泉水送出来，上述 过程就是一个脚本；李四投币买可乐，但是可 乐卖完了，于是系统给出提示信息并把钱退还 给李四，这个过程是另一个脚本。
３行为者
行为者是指与系统交互的人或其他系统， 它代表外部实体。使用用例并且与系统交 互的任何人或物都是行为者。
系统需要哪些输入输出?输入来自何处?输出到哪里去?
当前使用的系统(可能是人工系统)存在的主要问题是什么?
9.6.2 用例建模
9.6.2 用例建模
9.7 三种模型之间的关系
三种模型之间关系 FM：功能模型做什么What DM：动态模型何时做When OM：对象模型操作的实体How
9.7 三种模型之间的关系
组成关系用实心菱形表示
3 泛化
在UML中的泛化关系就是通常所说的继承关系， 它是通用元素和具体元素之间的一种分类关系。
具体元素完全拥有通用元素的信息，并且还可 以附加一些其他信息。
③ 泛化针对类型而不针对实例，一个类可以 继承另一个类，但一个对象不能继承另一个对 象。
④ 实际上，泛化关系指出在类与类之间存在 “一般－特殊”关系。
(4)关联类
①为了说明关联的 性质可能需要一些 附加信息，可以引 入一个关联类来记 录这些信息。
②关联中的每个连 接与关联类的一个 对象相联系。关联 类通过一条虚线与 关联连接。
图9.8 有4个连接，每个 连接都对应一个队列
2 聚集
聚集也称为聚合，是关联的特例。聚集表 示类与类之间的关系是整体和部分的关 系。
(3)限定关联
限定关联通常在一对多或多对多的关联关系中， 可以把模型中的 重数从一对多变成一对一，或 从多对多简化成多对一
例如，某操作系统中一个目录下有许多文件，一 个文件仅属于一 个目录，在一个目录内文件名 确定了惟一一个文件。
可见，利用限定词把一对多关系简化成了一对一 关系
图9.7查找 目录->文件名->文件
(1)扩展关系
向一个用例中添加一些动作后构成了另一个 用例,这两个用例之间的关系就是扩展关系, 后者称为扩展用例。
例如,在自动售货机系统中,”售货”是一个 基本的用例,如果顾客购买罐装饮料, 顺利实 现。而买散装饮料则不行，买散装饮料是非 常规动作。把非常规动作放置于”售散装饮 料”用例中,这两个用例之间关系就是扩展关 系
② 一般说来，与对象模型和动态模型比较，数据流图 并没有增加新 的信息
UML提供的用例图也是进行需求分析和建立 功能模块的强有力工具，在UML中把用用例 图建立起来的系统模型成为用例模型。
9.6.1 用例图
用例图包含的模型元素: 系统 ， 行为者，用例及用例之间 的关 系．
图中的方框代表系统， 椭圆代表用例， 线条人代表行为者，它们之间的连线表示关系
Requirement statement =>
Rapid prototype => Models 3个模型 Object model：最重要，开发任何系统都
需要；
Dynamic model：对于开发交互式系统 (interactive system)很重要；
Function model：对于开发大运算量问题 （如科学计算、编译系统等）很重要
分析的过程是提取系统需求的过程 分析凶包括3项内容：理解、表达、验证 面向对象分析的关键是识别出问题域内的类
与对象，并分析它们相互间的关系，最终建 立起问题域的简洁、精确、可理解的正确模 型。由对象模型、动态模型、和功能模型组 成。
10.1 面向对象分析的基本过程
10.1.1 概述
10.1.2 3个子模型与5个层次
2.寻找用例
一旦找到了行为者,就可以通过请每个行为者回答下 述问题来获取用例:
行为者需要系统提供哪些功能?行为者自身需要做什么?
行为者是否需要读取,创建,删除,修改或存储系统中的某类 信息?
系统中发生的事件需要通知行为者吗?行为者需要通知系统 某些事情吗?
从功能观点看,这些事件能做什么?
行为者的日常工作是否因为系统的新功能而被简化或提高 了效率?
动作的结果能被特定的行为者察觉到。
用例具有下述特征： (1)用例代表某些用户可见的功能，实现一个具体
用户目标
(2)用例总是被行为者启动的，并向行为者提供可 识别的
(3)用例必须是完整的
２用例
用例是一个类，它代表一类功能而不是使用该功 能的某个具体实例。
用例的实例是系统的一种实际使用方法，通常把 用例的实例称为脚本。 脚本是系统的一次具体 执行过程
(2)组合聚集
如果部分类完全隶属于整 体类，部分与整体共存， 整体不存在了 部分也会随 之消失（或失去存在的价 值了），则该聚集称为组合聚集（简称为组成）。
例如，在屏幕上打开一个窗口，它由文本框、列表框、按钮 和菜 单组成，一旦关闭了窗口，各个组成部分也同时消失， 窗口和它的组成部分之间存在着组合聚集关系
Байду номын сангаас
(2)使用关系
当一个用例使用另一个用例时,这两个用例之 间就构成了使用关系
一般说来,如果在若干个用例中有某些相同的 动作,则可以把这些相同的动作提取出来单独 构成一个用例(成为抽象用例)。
例如,在自动售货机系统中,”供货”和”取货款”都要先 打开机器，结束后关闭机器。把打开机器抽象成”打开 机器” 用例,把最后的动作抽象成”关闭机器”用例。
注意：通常在描述一般行为的变化时采用扩展关系;在两 个或多个用例中出现重复描述又想避免这种重复时,可以 采用使用关系
9.6.2 用例建模
一个用例模型由若干幅用例图组成 创建用例模型的工作包括:
定义系统,寻找行为者和用例 ② 描述用例,定义用例之间的关系 ③ 确认模型。 其中,寻找行为者和用例是关键。
5个层次
复杂问题的对象模型通常由5个层次组成： 主题层 类与对象层 结构层 类与对象间的关系 属性层 服务层
主题是指导读者理解大型、复杂模型的一种 机制。通过划分主题把一个大型、复杂的对 象分解成几个不同的概念范畴。
从高层次描述总体模型，指导读者的注意力
9.7 三种模型之间的关系
(5)数据流图中的数据流,往往是对象模型中 对象的属性值,也可能是整个对象。
(6)用例图中的行为者,可能是对象模型中的 对象。
(7)功能模型中的处理(或用例)可能产生动态 模型中的事件。
(8)对象模型描述了数据流图中的数据流,数 据存储以及数据源点/终点的结构。
第10章 面向对象分析
uml1.1中有两种用例关系 <<uses>>关系和<<extends>>关系 它们都是泛化（generalization）关系的构造
型（ stereotype） uml1.3之后，提供了三种用例关系 <<include>>关系、<<extend>>关系都是依
赖（ dependency）关系的构造型（ stereotype） 泛化关系（generalization）
9.4.2 表示关系的符号
9.4.2 表示关系的符号
类与类之间通常有关联、泛化（继承）、依 赖和细化等4种关系
1 关联
关联表示两个类的对象之间存在某种语义上的联 系
9.4.2 表示关系的符号
普通关联：
最常见的关联关系，只要在类与类之间存 在连接关系就可以用普通关联表示。
(1)针对每个类建立的动态模型,描述了类实 例的生命周期或运行周期。
(2)状态转换驱使行为发生,这些行为在数据 流图中被映射成处理, 在用例图中被映射成 用例,它们同时与类图中的服务相对应。
(3)功能模型中的处理(或用例)对应于对象模 型中的类所提供的服务。
(4)数据流图中的数据存储,以及数据的源点/ 终点,通常是对象模型中的对象。
不应对系统中的每个类都画状态图，而只 应对某些 关键类建立状态图；而且应将状态 图与其它技术组 合使用
9.6 功能模型
表示变化的系统的“功能”性质，它指明了 系统应该“做什么”，因此更直接地反映了 用户对目标系统的需求
功能模型由一组数据流图组成，在面向对象方法学中 ，数据流图 远不如在结构分析设计方法中那样重要
1.寻找行为者
通过请系统的用户回答一些问题的办法来发现行为 者，下述问题有助于发现行为者: 谁将使用系统的主要功能(主行为者)? 谁需要借助系统的支持来完成日常工作? 谁来维护和管理系统(副行为者)? 系统控制哪些硬件设备? 系统需要与哪些其他系统交互? 哪些人或系统对本系统产生的结果(值)感兴趣?
不完全继承指的是父类的所有子类没有都穷举出来
4 依赖和细化 (1)依赖关系：依赖关系描述两个模型元素之间 的语义连接关系，其 中一个模型元素是独立的， 另一个模型元素不是独立的，如果独立的模型 元素改变，将影响依赖于它的模型元素。
箭头指向独立的类
(2)细化关系：当对同一个事物在不同抽象层次 上描述时，这些描述之间具有细化关系。
行为者代表一种角色，而不是某个具体的人或物
例如，在自动售货机系统中，使用售货功能的人 既可以是张三 （买矿泉水）也可以是李四的（买 可乐），但是不能把张三或李四这样的个体对象 称为行为者。
直线连接行为者和用例，表示两者之间交换信息 ，称为通信联系。行为者触发用例，并与用例交 换信息
４用例之间的关系
箭头由更详细层指向上层
9.5 动态模型
动态模型表示瞬时的，行为化的系统的“控 制”性质,它规定了对象模型中的对象的合法 变化序列。
状态是任何可以被观察到的系统行为模式，
每个类的动态行为用一张状态图来描绘
各个类的状态图通过共享事件合并起来， 从而构成系统 的动态模型
动态模型是基于事件共享而互相关联的一 组状态图的集 合
例如，在自动售货机系统中，张三投入硬币购买 矿泉水，系统收到钱后把矿泉水送出来，上述 过程就是一个脚本；李四投币买可乐，但是可 乐卖完了，于是系统给出提示信息并把钱退还 给李四，这个过程是另一个脚本。
３行为者
行为者是指与系统交互的人或其他系统， 它代表外部实体。使用用例并且与系统交 互的任何人或物都是行为者。
系统需要哪些输入输出?输入来自何处?输出到哪里去?
当前使用的系统(可能是人工系统)存在的主要问题是什么?
9.6.2 用例建模
9.6.2 用例建模
9.7 三种模型之间的关系
三种模型之间关系 FM：功能模型做什么What DM：动态模型何时做When OM：对象模型操作的实体How
9.7 三种模型之间的关系
组成关系用实心菱形表示
3 泛化
在UML中的泛化关系就是通常所说的继承关系， 它是通用元素和具体元素之间的一种分类关系。
具体元素完全拥有通用元素的信息，并且还可 以附加一些其他信息。
③ 泛化针对类型而不针对实例，一个类可以 继承另一个类，但一个对象不能继承另一个对 象。
④ 实际上，泛化关系指出在类与类之间存在 “一般－特殊”关系。
(4)关联类
①为了说明关联的 性质可能需要一些 附加信息，可以引 入一个关联类来记 录这些信息。
②关联中的每个连 接与关联类的一个 对象相联系。关联 类通过一条虚线与 关联连接。
图9.8 有4个连接，每个 连接都对应一个队列
2 聚集
聚集也称为聚合，是关联的特例。聚集表 示类与类之间的关系是整体和部分的关 系。
(3)限定关联
限定关联通常在一对多或多对多的关联关系中， 可以把模型中的 重数从一对多变成一对一，或 从多对多简化成多对一
例如，某操作系统中一个目录下有许多文件，一 个文件仅属于一 个目录，在一个目录内文件名 确定了惟一一个文件。
可见，利用限定词把一对多关系简化成了一对一 关系
图9.7查找 目录->文件名->文件
(1)扩展关系
向一个用例中添加一些动作后构成了另一个 用例,这两个用例之间的关系就是扩展关系, 后者称为扩展用例。
例如,在自动售货机系统中,”售货”是一个 基本的用例,如果顾客购买罐装饮料, 顺利实 现。而买散装饮料则不行，买散装饮料是非 常规动作。把非常规动作放置于”售散装饮 料”用例中,这两个用例之间关系就是扩展关 系
② 一般说来，与对象模型和动态模型比较，数据流图 并没有增加新 的信息
UML提供的用例图也是进行需求分析和建立 功能模块的强有力工具，在UML中把用用例 图建立起来的系统模型成为用例模型。
9.6.1 用例图
用例图包含的模型元素: 系统 ， 行为者，用例及用例之间 的关 系．
图中的方框代表系统， 椭圆代表用例， 线条人代表行为者，它们之间的连线表示关系
Requirement statement =>
Rapid prototype => Models 3个模型 Object model：最重要，开发任何系统都
需要；
Dynamic model：对于开发交互式系统 (interactive system)很重要；
Function model：对于开发大运算量问题 （如科学计算、编译系统等）很重要
分析的过程是提取系统需求的过程 分析凶包括3项内容：理解、表达、验证 面向对象分析的关键是识别出问题域内的类
与对象，并分析它们相互间的关系，最终建 立起问题域的简洁、精确、可理解的正确模 型。由对象模型、动态模型、和功能模型组 成。
10.1 面向对象分析的基本过程
10.1.1 概述
10.1.2 3个子模型与5个层次
2.寻找用例
一旦找到了行为者,就可以通过请每个行为者回答下 述问题来获取用例:
行为者需要系统提供哪些功能?行为者自身需要做什么?
行为者是否需要读取,创建,删除,修改或存储系统中的某类 信息?
系统中发生的事件需要通知行为者吗?行为者需要通知系统 某些事情吗?
从功能观点看,这些事件能做什么?
行为者的日常工作是否因为系统的新功能而被简化或提高 了效率?
动作的结果能被特定的行为者察觉到。
用例具有下述特征： (1)用例代表某些用户可见的功能，实现一个具体
用户目标
(2)用例总是被行为者启动的，并向行为者提供可 识别的
(3)用例必须是完整的
２用例
用例是一个类，它代表一类功能而不是使用该功 能的某个具体实例。
用例的实例是系统的一种实际使用方法，通常把 用例的实例称为脚本。 脚本是系统的一次具体 执行过程
(2)组合聚集
如果部分类完全隶属于整 体类，部分与整体共存， 整体不存在了 部分也会随 之消失（或失去存在的价 值了），则该聚集称为组合聚集（简称为组成）。
例如，在屏幕上打开一个窗口，它由文本框、列表框、按钮 和菜 单组成，一旦关闭了窗口，各个组成部分也同时消失， 窗口和它的组成部分之间存在着组合聚集关系
Байду номын сангаас
(2)使用关系
当一个用例使用另一个用例时,这两个用例之 间就构成了使用关系
一般说来,如果在若干个用例中有某些相同的 动作,则可以把这些相同的动作提取出来单独 构成一个用例(成为抽象用例)。
例如,在自动售货机系统中,”供货”和”取货款”都要先 打开机器，结束后关闭机器。把打开机器抽象成”打开 机器” 用例,把最后的动作抽象成”关闭机器”用例。
注意：通常在描述一般行为的变化时采用扩展关系;在两 个或多个用例中出现重复描述又想避免这种重复时,可以 采用使用关系
9.6.2 用例建模
一个用例模型由若干幅用例图组成 创建用例模型的工作包括:
定义系统,寻找行为者和用例 ② 描述用例,定义用例之间的关系 ③ 确认模型。 其中,寻找行为者和用例是关键。
5个层次
复杂问题的对象模型通常由5个层次组成： 主题层 类与对象层 结构层 类与对象间的关系 属性层 服务层
主题是指导读者理解大型、复杂模型的一种 机制。通过划分主题把一个大型、复杂的对 象分解成几个不同的概念范畴。
从高层次描述总体模型，指导读者的注意力
9.7 三种模型之间的关系
(5)数据流图中的数据流,往往是对象模型中 对象的属性值,也可能是整个对象。
(6)用例图中的行为者,可能是对象模型中的 对象。
(7)功能模型中的处理(或用例)可能产生动态 模型中的事件。
(8)对象模型描述了数据流图中的数据流,数 据存储以及数据源点/终点的结构。
第10章 面向对象分析
uml1.1中有两种用例关系 <<uses>>关系和<<extends>>关系 它们都是泛化（generalization）关系的构造
型（ stereotype） uml1.3之后，提供了三种用例关系 <<include>>关系、<<extend>>关系都是依
赖（ dependency）关系的构造型（ stereotype） 泛化关系（generalization）