面向对象应用技术

《面向对象应用技术》系统地介绍面向对象的基本应用方法，主要包括面向对象分析与设计的基本概念、主要步骤、典型特点、关键问题等，以及面向对象的表示法和开发过程。每章都包含一节应用领域实例。

本书是讲述面向对象应用技术的教学用书。全书共分9章，系统地介绍了面向对象的基本应用方法，主要包括面向对象分析与设计的基本概念、主要步骤、典型特点、关键问题等，以及面向对象的表示法和开发过程。每章都包含一节应用领域的实例。 本书论述浅显易懂，书中内容翔实、立论严谨、实例丰富、图文并茂。本书适合作为高等学校软件工程、计算机及相关专业的教材，也可作为工程技术人员的参考书。

目录 第1章面向对象方法论 1．1面向对象概念 1．1．1对象 1．1．2类 1．1．3对象图 1．1．4属性 1．1．5操作和方法 1．1．6封装 1．1．7继承 1．1．8多重继承 1．1．9消息 1．1．10结构与连接 1．1．11多态性 1．1．12较为对象 1．1．13主动对象 1．1．14对象类的表示方法 1．2链接与关联 1．2．1一般概念 1．2．2重数 1．2．3关联的重要性 1．2．4三元关联 1．2．5关联的候选关键字 1．2．6异或关联 1．2．7资格符 1．2．8链接属性 1．2．9用关联模型化为类 1．2．10角色名 1．2．11排序 1．2．12资格关联 1．3聚合 1．3．1聚合与关联 1．3．2聚合和概括 1．3．3递归聚合 1．3．4操作的传播 1．3．5物理聚合与分类聚合 1．3．6物理聚合的语义扩展 1．3．7分类聚合的语义扩展 1．4面向对象实例 1．4．1问题概述 1．4．2对象及其类的分析 1．4．3类的属性与方法分析 1．4．4类的描述(C++) 1．4．5类的描述(C++)实验 1．5对象、类描述实验 1．5．1实验问题域概述 1．5．2实验1 小结 综合练习 第2章面向对象建模 2．1统一建模语言 2．1．1UML的发展 2．1．2统一建模语言的内容 2．1．3统一建模语言的主要特点 2．1．4统一建模语言的应用领域 2．2UML的基本图标 2．3基本规则 2．3．1UML的基本元素 2．3．2UML的语法规则 2．3．3UML的词别 2．4对象模型技术 2．4．1对象模型 2．4．2动态模型 2．4．3功能模型 2．4．4三种模型的联系 2．5软件体系结构 2．6用UML描述ATM机 2．6．1问题概述 2．6．2系统模型 2．7面向对象UML实验 2．7．1实验问题域概述 2．7．2实验2 小结 综合练习 第3章发现对象、建立对象类 3．1对象、主动对象以及它们的类 3．2表示法 3．3研究问题域和用户需求 3．3．1研究用户需求，明确系统责任 3．3．2研究问题域 3．3．3确定系统边界 3．4发现对象 3．4．1发现对象技术概要 3．4．2正确地运用抽象原则 3．4．3策略与启发 3．4．4审查和筛选 3．4．5发现对象方法 3．5对象分类，建立类图的对象层 3．5．1异常情况的检查和调整 3．5．2类的命名 3．5．3建立类图的对象层 3．6电梯控制系统的对象 3．6．1功能需求 3．6．2发现对象 3．6．3对象层表示 3．7发现对象实验 3．7．1实验问题域概述 3．7．2实验3 小结 综合练习 第4章定义属性与服务 4．1对象的属性和服务 4．2表示法 4．3定义属性 4．3．1策略与启发 4．3．2审查与筛选 4．3．3推迟到OOD考虑的问题 4．3．4属性的命名和定位 4．3．5属性的详细说明 4．4定义服务 4．4．1对象的状态与状态转换图 4．4．2行为分类 4．4．3发现服务的策略与启发 4．4．4审查与调整 4．4．5认识对象的主动行为 4．4．6服务的命名和定位 4．4．7服务的详细说明 4．5建立类图的特征层 4．6电梯例子 4．6．1电梯系统的属性描述 4．6．2电梯系统的服务定义 4．6．3电梯系统的特征层 4．7对象的属性与服务实验 4．7．1实验问题域概述 4．7．2实验4 小结 综合练习 第5章定义结构与连接 5.1整体—部分结构 5.1.1整体—部分结构及其用途 5.1.2表示法 5.1.3如何发现整体—部分结构 5.1.4审查与筛选 5.1.5简化对象的定义 5.1.6支持软件复用 5.1.7整体—部分结构的进一步运用 5.1.8调整对象层和属性层 5.2一般—特殊结构 5.2.1一般—特殊结构及其用途 5.2.2表示法 5.2.3如何发现一般—特殊结构 5.2.4审查与调整 5.2.5多继承及多态性问题 5.2.6一般—特殊结构的简化 5.2.7调整对象层和特征层 5.3实例连接 5.3.1简单的实例连接 5.3.2复杂的实例连接及其表示 5.3.3三元关联问题 5.3.4如何建立实例连接 5.3.5对象层、特征层的增补及实例连接说明 5.4消息连接 5.4.1消息的定义 5.4.2顺序系统中的消息 5.4.3并发系统中的消息 5.4.4消息对OOA的意义 5.4.5OOA对消息的表示——消息连接 5.5如何建立消息连接 5.5.1建立控制线程内部的消息连接 5.5.2建立控制线程之间的消息连接 5.5.3对象分布问题及其消息的影响 5.6消息的详细说明 5.7电梯控制系统部分关系结构 5.7.1一般—特殊关系 5.7.2整体—部分关系 5.7.3连接 5.7.4电梯控制系统的关系层 5.8结构与连接实验 5.8.1实验问题域概述 5.8.2实验5 小结 综合练习 第6章控制驱动部分的设计 6.1类型一致性原则 6.2闭合行为原则 6.3什么是控制驱动部分 6.4相关技术问题 6.4.1系统总体方案 6.4.2软件体系结构 6.4.3分布式系统的体系结构风格 6.4.4系统的并发性 6.5如何设计控制驱动部分 6.5.1选择软件体系结构风格 6.5.2确定系统分布方案 6.5.3识别控制流 6.5.4用主动对象表示控制流 6.5.5把控制驱动部分看作一个主题 6.6医院的信息管理 6.6.1系统概述 6.6.2设计约束 6.6.3设计策略 6.6.4系统总体结构 6.6.5逻辑设计 6.6.6物理设计 6.6.7子系统的结构与功能 6.7系统结构设计实验 6.7.1实验问题域概述 6.7.2实验6 小结 综合练习 第7章对象设计 7.1对象设计综述 7.1.1从分析和系统结构着手 7.1.2对象设计的步骤 7.1.3对象模型工具 7.2组合三种模型 7.3设计算法 7.3.1选择算法 7.3.2选择数据结构 7.3.3定义内部类和操作 7.3.4指定操作的职责 7.4设计优化 7.4.1添加冗余关联获取有效访问 7.4.2重新安排执行次序以获得效率 7.4.3保存导出属性避免重复计算 7.5控制实现 7.5.1在程序内进行状态设置 7.5.2状态机器引擎 7.5.3控制作为并发任务 7.6继承的调整 7.6.1重新安排类和操作 7.6.2抽象出公共的行为 7.6.3使用授权共享实现 7.7关联设计 7.7.1分析关联遍历 7.7.2单向关联 7.7.3双向关联 7.7.4链接属性 7.8对象的表示 7.9物理打包 7.9.1信息隐藏 7.9.2实体的相关性 7.9.3构造模块 7.10设计决策文档 7.11ATM的对象设计实例 7.11.1问题概述 7.11.2ATM系统类图 7.12对象设计实验 7.12.1实验问题域概述 7.12.2实验7 小结 综合练习 第8章数据库及其接口设计 8.1数据管理系统及其选择 8.2数据库系统 8.2.1面向对象技术 8.2.2面向对象数据库的应用 8.2.3应用程序设计程序 8.2.4面向对象数据库的很好化 8.3技术整合 8.4数据接口 8.5对象存储方案和数据接口的设计策略 8.5.1针对文件系统的设计 8.5.2针对RDBMS的设计 8.5.3使用OODBMS 8.6数据库设计实验 8.6.1实验问题域概述 8.6.2实验8 小结 综合练习 第9章人机交互部分的设计 9.1什么是人机交互部分 9.2人机交互部分的需求分析 9.2.1分析活动者——与系统交互的人 9.2.2从Use Case分析人机交互 9.2.3分析处理异常事件的人机交互 9.2.4命令的组织 9.2.5输出信息的组织结构 9.2.6总结与讨论 9.3人机界面的设计准则 9.4人机界面OO设计 9.4.1界面支持系统 9.4.2界面元素 9.4.3设计过程与策略 9.5可视化编程环境下的人机界面设计 9.5.1问题的提出 9.5.2设计的必要性 9.5.3基于可视化编程环境的设计策略 9.6人机界面设计实验 9.6.1实验问题域概述 9.6.2实验9 小结 综合练习 附录A习题参考答案 参考文献

    第3章发现对象、建立对象类 分析和研究问题域及用户要求，认识其中的对象，从而确定系统中应该设立哪些对象类是OOA的核心工作。所以，本章首先从发现对象开始对OOA过程进行介绍。 3．1对象、主动对象以及它们的类 1． 对象 从一般意义上讲，现实世界中的任何事物均可称作对象，但OOA只注意那些与问题域和系统责任有关的对象，它是在应用领域中有意义的、与所要解决的问题有关系的事物。通过分析、认识这些对象，抽象出它们的主要特征，用系统中的对象来表示它们。 对象的定义是： 对象是对问题域中某个实体的抽象，这种抽象反映了系统保存有关这个实体的信息或与它交互的能力。它既可以是具体的物理实体的抽象，也可以是人为的概念，或者是任何有明确边界和意义的东西。例如，一名职工、一家公司、一个窗口、一座图书馆、一本图书、贷款、借款等，都可以作为对象。总之，对象是对问题域中某个实体的抽象，设立某个对象就反映了软件保存有关它的住处及与它进行交互的能力。 由于客观世界中的实体通常都既具有静态的属性，又具有动态的行为，因此，面向对象方法学中的对象是由描述该对象属性的数据以及可以对这些数据施加的所有操作封装在一起而构成的统一体。对象可以做的操作表示它的动态行为，在面向对象分析和面向对象设计中，通常把对象的操作称为服务或方法。 2． 类 现实世界中存在的客观事物有些是彼此相似的，例如，张三、李四……虽说每个人的职业、性格、爱好、特长等各有不同，但是，他们的基本特征是相似的，都是黄皮肤、黑头发、黑眼睛，于是把他们统称为“中国人”。人类认识现实世界的思维活动并不是逐个地认识和描述每一个对象实体，而是通过抽象把具有共同特征的对象归结为一类，形成一般概念。在面向对象的软件开发中，也是用类作为对象的抽象描述。 在面向对象的软件技术中，“类”就是对具有相同数据和相同操作的一组相似对象的定义，也就是说，类是对具有相同属性和行为的一个或多个对象的描述，通常在这种描述中也包括对怎样创建该类的新对象的说明。例如，一个面向对象的图形程序在屏幕左下角显示一个半径3cm的红颜色的圆，在屏幕中部显示一个半径大小和颜色均不相同的圆，是两个不同的对象。但是，它们都有相同的数据(圆心坐标、半径、颜色)和相同的操作(显示自己、放大缩小半径、在屏幕上移动位置等)。因此，它们是同一类事物，可以用“Circle类”来定义。 在面向对象的编程语言中，对象和类是两种不同的语法成分。前者是后者的实例，后者是前者的定义模板。编程中需要确切地给出所创建的每个对象。但是在OOA和OOD中，分析员和设计人员一般不需要定义(更谈不上创建)每个具体的对象。尽管属于同一个类的对象可以有很多，乃至成千上万，但在OOA模型中只用一个类符号表示这个类以及由它创建的全部对象。所以OOA模型涉及的主要概念是类，它是可能由它创建的全部对象的代表。系统中也可能设立一些不创建任何对象实例的类，它们的作用是在一般—特殊结构中描述特殊类的共性，通过继承简化特殊类的描述。OOA不必专门为对象实例规定一种表示符号，因为系统中总有描述该对象的类，不需要单独地描述每个对象。尽管如此，对象的概念对于OOA仍然是重要的，因为OOA的每个类都是通过考察它们的对象而得到的，分析员需要从对象着眼来分析、认识问题，才能正确地抽取它们的类。 3． 主动对象 在此之前，人们所理解的对象概念实际上只是被动对象，即： 对象的每个服务都是响应从外部发来的消息才被动执行的。这样理解和定义对象，有两点不足： 一是客观世界中的一些事物具有主动行为，对象的行为局限于被动响应，难以准确地描述事物的主动行为，例如，物体按自然规律进行的运动，人由自己的思想所支配的行动等； 二是从系统开发的角度看，现今大量的系统具有并发执行的多个任务，用响应消息而被动执行的对象服务难以准确地表达任务的并发性与主动性。 根据（1.1.13）主动对象的定义，不需要接收消息就能主动执行的服务可称为主动服务，在编程时它将对应一个并发执行的程序单位。相比之下，被动对象的服务在编程时对应的是被动的程序成分，如函数、过程、例程等。应该指出主动对象的主动服务是可以接收消息的，只是，它们并不是必须由消息触发才能执行，而是首先主动地执行，然后在执行中接收消息。 主动对象的类称作主动类(Active Class)，它和主动对象的关系就像前面所说的类和它们的对象一样： 前者是后者的抽象描述，后者是前者的实例。 关于在OOA中运用主动对象，有如下两点认识。 (1) 不提倡脱离系统开发的实际需要漫无目标地去发掘每个对象的主动行为。在现实中几乎每种对象都具有某些主动行为，但未必都需要在系统中表达。因为系统中的对象，是对实际事物的抽象，实际事物如果只有某些属性和被动行为需要在系统中表示，则应该用一个被动对象来表达； 如果它确实有一些主动行为需要在系统中表示，才将其表示为主动对象。 (2) 往往由设计决策决定是否应该把一个对象定义为主动对象，设计者可以为提高或减低系统的并发难度而人为地增加或减少主动对象的种类与数量。OOA与OOD方法所采用的原则是： 在OOA阶段提供主动对象的表示法，使分析员能够表示他们所认识的主动对象； 如果分析员暂时不能决定某类对象是否该定义为主动对象，则允许他们把这种决策留给设计人员。在OOA中，找出所有的对象类并用类符号表示它们是首要任务，然后是把能够认识的主动对象标识出来。一些主动对象在被认识之前，暂时用普通的类符号表示，在逻辑上也并不矛盾。 3．2表示法 普通对象(包括被动对象和尚未认定的主动对象)由如图31所示的类符号表示。矩形框的上栏填写类名。这是本章所讲的“发现对象、定义对象类”这一活动的基本要求。矩形框中栏和下栏准备填写对象的属性和服务名。主动对象的类符号如图32所示。它与普通对象的类符号的区别是，在类名之前增加一个主动标记“@”，此外，将来在定义服务时应在服务部分(下栏)用“@”标出至少一个主动服务。 图31类符号 图32主动对象的类符号 3．3研究问题域和用户需求 OOA的基本出发点是问题域和用户要求，分析员的主要工作就是： 通过不断地研究问题域，建立一个能满足用户需求的系统模型。通常，面向对象分析过程从分析陈述用户需求的文件开始。可能由用户(包括出资开发该软件的业主代表及最终用户)单方面写出需求陈述，也可由系统分析员配合用户，共同写出需求陈述。当软件项目采用招标方式确定开发单位时，“标书”往往可以作为初步的需求陈述。 需求陈述通常是不完整、不准确的，而且往往是非正式的。通过分析，可以发现和改正原始陈述中的二义性和不一致性，补充遗漏的内容，从而使需求陈述更完整、更准确。因此，不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础。在分析需求陈述的过程中，反复多次的讲解，快速建立起一个可在计算机上运行的原型系统，非常有助于分析员和用户之间的交流和理解，从而能更正确地提炼出用户的需求。 3．3．1研究用户需求，明确系统责任 系统的需求包括4个不同的层次： 业务需求，用户需求和功能需求，非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能性需求是用户对系统良好运作提出的期望，包括易用性、反应速度、容错性、健壮性等质量属性。用户需求就是用户对所要开发的系统提出的各种要求和期望。它包括系统的功能、性能、可靠性、保密要求、交互方式等技术性要求和资金强度、交付时间、资源使用等非技术性要求。在多数情况下，功能需求是分析员考虑最多的因素。 需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性，所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。 作为一种实用的分析技术，OOA应该从当前的现实出发来设定工作的起点。它的工作起点是，能得到一份正确表达用户需求、符合某种标准(如国家标准、行业标准或企业内部规范)的需求文档。如果所得到的材料不能确切地表达用户需求，或者不符合标准规范，则真正的分析工作还不能立刻开始。这种情况是经常会遇到的。因为许多用户(特别是那些首次要求开发一个计算机应用系统的用户)往往不知道怎样正确地表达自己的要求，在这种情况下，分析员需要与用户和其他有关人员配合，完成一份能够正确地反映用户需求并符合标准规范的需求文档。分析员开始一项分析工作首先要研究用户需求，要搞清楚到底要开发一个什么样的系统，包括： 系统需要提供哪些功能，系统的边界在哪里，要达到何种性能指标以及可靠性、安全性要求，人机交互要求等。研究用户需求包括以下活动。 阅读有关文档： 阅读用户提交的需求文档等一切与用户需求有关的书面材料。 与用户交流： 了解用户的需求，搞清有关用户需求的疑点。 进行实地调查： 有些需求问题，通过以上途径仍然不能接近明确，则需要到现场做适当的调查，因为以上资料可能表达得不够准确、清晰。 记录所得认识： 随时记录通过阅读、交流和调查所得到的认识，更要记录所存在的疑点。 整理相关资料： 纠正初始需求文档中不符合的内容，整理出一份确切表达系统责任的需求文档。 上述活动，几乎对所有的分析方法都是必要的。对OOA而言，分析员研究用户需求始终要带着一个问题——系统中要设立哪些对象来满足用户需求。在分析工作开始时，为了明确系统责任而对用户需求的研究不可能使这个问题得到接近解答。但是在分析工作的自始至终，需要反复回顾通过研究用户需求而认识的系统责任，结合对问题域的分析研究，确定系统中所有对象的类，以及它们的内部构成与外部关系。 3．3．2研究问题域 研究问题域是贯穿分析工作始终的基本工作。面向对象的分析比其他分析方法更加强调系统模型与问题域的紧密对应，因此OOA过程中的每一个活动都十分强调对问题域的研究。研究问题域对任何分析方法都是最基本的工作。其目的有两个： 一是进一步明确用户需求，二是为了建立一个符合问题域情况、满足用户需求的分析模型。调查研究问题域的开始阶段，侧重点可以放在第一个目的，随后更深入、更大量地调查研究，重点是第二个目的。不同的分析方法，调查研究的核心问题及工作方式有很大的不同。如结构化分析(数据流法)核心问题是数据流和加工，因此调查跟踪数据流和发现加工。OOA的核心概念是对象，因此调查研究的核心问题是系统中应该设立哪些对象，并进一步研究对象内部的属性与服务，以及对象外部的结构与连接。问题域的定义是： 被开发的应用系统所考虑的整个业务范围。研究问题域，应包括下述工作要点。 1． 认真听取问题域专家的见解 分析员接触一个新的应用领域时应该虚心地向领域专家学习，要积极地与问题域专家(技术人员、管理者和富有经验的职员等)接触，向他们学习、请教。要以恰当的提问正确地引导交谈的内容。这种调查可概括为如下的流程： 提问——倾听——理解消化——反馈自己的理解以求印证——提出进一步的问题。 2． 亲临现场，通过直接观察掌握第一手材料 要了解一个领域，最可靠的办法是身临其境，实践是检验真理的专享标准，只有自己的亲身体验才是有效的。比如要开发一个商场的管理系统，分析员优选先作为普通顾客到这个商场去购物。看看售货员怎么开小票，收款台怎样收款，小票的哪一联留到收款台，哪一联返给售货员，哪一联给顾客。当然这只是表层的观察。进一步应该深入商场内部观察一般情况下看不到的业务处理过程。 3． 阅读领域相关资料 向问题域专家学习固然是最重要的，但如果对领域最基本的常识和概念、术语一点儿都不懂，就缺少与问题域专家交流的共同语言，增加了调查的难度，甚至使用户对你的单位承担这个项目的能力缺乏信心。所以在和用户及问题域专家正式接触之前，优选先阅读与问题域有关的科学，学习相应的行业和领域的基本知识，广泛地收集一些与问题域知识有关的书籍或其他书面材料，进行一番闭门苦读，充实自己的知识。这样的突击学习可能使你掌握相当多的知识，进而在日后的分析工作中受益颇多。 4． 借鉴他人经验 查阅相同或相似问题域已有系统的OOA文档，包括自己或同事开发的，以及在教科书、专业论文或技术报告中能找到的相似系统的OOA技术资料，看看别人是怎样分析与研究问题域的，从问题域中抽象了哪些类，“它山之石，可以攻玉”。同时，这种借鉴还可以发现一批可以复用的类。 3．3．3确定系统边界 确定系统边界，就是明确系统是什么以及系统的环境是什么，划出被开发的系统和与该系统打交道的人或物之间的明确界限，并确定它们之间的接口。例如，当准备用一个自动化系统去取代现有的手工劳动或半自动化系统时，新系统的环境与旧系统的环境是一样的，在另外一些情况下，却有许多不确定性，需要在需求分析过程中不断认识。在系统边界以内，是系统本身所包含的对象。在系统边界以外，是系统外部的活动者，主要是人、设备和外部系统三种外部活动者。在许多情况下，系统与环境之间的界限是相对清楚的。 与系统交互的人向系统发出命令，提供输入信息，接受系统的服务或从系统获得信息。设备是指与系统相连并交换信息的设备。外部系统是指与系统相连并交换信息的其他系统。 只有由系统的信息或模拟其行为的人和物才应该被当作系统边界以内的对象，而那些与系统进行信息交换的人员、设备或外部系统，尽管系统中也可能设立一些描述它们的特征并负责与它们交互的对象，但它们本身是通过系统边界与系统交互的活动者。 认识系统边界的目的是为了明确系统的范围以及与外部世界的接口。系统边界以内的事物，由系统中的对象来表达； 边界以外的活动者通过经它们和系统的接口与系统交互； 边界以外不与系统交互的事物统统不必考虑。系统边界的另一个作用是，在定义用例时系统边界是作为观察活动者与系统交互的着眼点。