面向对象应用技术-正版全新
￥ 24.06 4.9折 ￥ 49 全新
库存5件
河北衡水
认证卖家担保交易快速发货售后保障
作者李代平
出版社清华大学出版社
ISBN9787302513933
出版时间2019-02
装帧平装
定价49元
货号9787302513933
上书时间2022-12-27
- 在售商品 暂无
- 平均发货时间 22小时
- 好评率 暂无
- 店主推荐
- 最新上架
商品详情
- 品相描述：全新
- 商品描述
-
商品简介
第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表示法
普通对象(包括被动对象和尚未认定的主动对象)由如图31所示的类符号表示。矩形框的上栏填写类名。这是本章所讲的“发现对象、定义对象类”这一活动的基本要求。矩形框中栏和下栏准备填写对象的属性和服务名。主动对象的类符号如图32所示。它与普通对象的类符号的区别是，在类名之前增加一个主动标记“@”，此外，将来在定义服务时应在服务部分(下栏)用“@”标出至少一个主动服务。
图31类符号
图32主动对象的类符号
3．3研究问题域和用户需求
OOA的基本出发点是问题域和用户要求，分析员的主要工作就是： 通过不断地研究问题域，建立一个能满足用户需求的系统模型。通常，面向对象分析过程从分析陈述用户需求的文件开始。可能由用户(包括出资开发该软件的业主代表及最终用户)单方面写出需求陈述，也可由系统分析员配合用户，共同写出需求陈述。当软件项目采用招标方式确定开发单位时，“标书”往往可以作为初步的需求陈述。
需求陈述通常是不完整、不准确的，而且往往是非正式的。通过分析，可以发现和改正原始陈述中的二义性和不一致性，补充遗漏的内容，从而使需求陈述更完整、更准确。因此，不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础。在分析需求陈述的过程中，反复多次的讲解，快速建立起一个可在计算机上运行的原型系统，非常有助于分析员和用户之间的交流和理解，从而能更正确地提炼出用户的需求。
3．3．1研究用户需求，明确系统责任
系统的需求包括4个不同的层次： 业务需求，用户需求和功能需求，非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能性需求是用户对系统良好运作提出的期望，包括易用性、反应速度、容错性、健壮性等质量属性。用户需求就是用户对所要开发的系统提出的各种要求和期望。它包括系统的功能、性能、可靠性、保密要求、交互方式等技术性要求和资金强度、交付时间、资源使用限制等非技术性要求。在多数情况下，功能需求是分析员考虑最多的因素。
需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性，所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。
作为一种实用的分析技术，OOA应该从当前的现实出发来设定工作的起点。它的工作起点是，能得到一份正确表达用户需求、符合某种标准(如国家标准、行业标准或企业内部规范)的需求文档。如果所得到的材料不能确切地表达用户需求，或者不符合标准规范，则真正的分析工作还不能立刻开始。这种情况是经常会遇到的。因为许多用户(特别是那些首次要求开发一个计算机应用系统的用户)往往不知道怎样正确地表达自己的要求，在这种情况下，分析员需要与用户和其他有关人员配合，完成一份能够正确地反映用户需求并符合标准规范的需求文档。分析员开始一项分析工作首先要研究用户需求，要搞清楚到底要开发一个什么样的系统，包括： 系统需要提供哪些功能，系统的边界在哪里，要达到何种性能指标以及可靠性、安全性要求，人机交互要求等。研究用户需求包括以下活动。
阅读有关文档： 阅读用户提交的需求文档等一切与用户需求有关的书面材料。
与用户交流： 了解用户的需求，搞清有关用户需求的疑点。
进行实地调查： 有些需求问题，通过以上途径仍然不能完全明确，则需要到现场做适当的调查，因为以上资料可能表达得不够准确、清晰。
记录所得认识： 随时记录通过阅读、交流和调查所得到的认识，更要记录所存在的疑点。
整理相关资料： 纠正初始需求文档中不符合的内容，整理出一份确切表达系统责任的需求文档。
上述活动，几乎对所有的分析方法都是必要的。对OOA而言，分析员研究用户需求始终要带着一个问题——系统中要设立哪些对象来满足用户需求。在分析工作开始时，为了明确系统责任而对用户需求的研究不可能使这个问题得到完全解答。但是在分析工作的自始至终，需要反复回顾通过研究用户需求而认识的系统责任，结合对问题域的分析研究，确定系统中所有对象的类，以及它们的内部构成与外部关系。
3．3．2研究问题域
研究问题域是贯穿分析工作始终的基本工作。面向对象的分析比其他分析方法更加强调系统模型与问题域的紧密对应，因此OOA过程中的每一个活动都十分强调对问题域的研究。研究问题域对任何分析方法都是最基本的工作。其目的有两个： 一是进一步明确用户需求，二是为了建立一个符合问题域情况、满足用户需求的分析模型。调查研究问题域的开始阶段，侧重点可以放在第一个目的，随后更深入、更大量地调查研究，重点是第二个目的。不同的分析方法，调查研究的核心问题及工作方式有很大的不同。如结构化分析(数据流法)核心问题是数据流和加工，因此调查跟踪数据流和发现加工。OOA的核心概念是对象，因此调查研究的核心问题是系统中应该设立哪些对象，并进一步研究对象内部的属性与服务，以及对象外部的结构与连接。问题域的定义是： 被开发的应用系统所考虑的整个业务范围。研究问题域，应包括下述工作要点。
1． 认真听取问题域专家的见解
分析员接触一个新的应用领域时应该虚心地向领域专家学习，要积极地与问题域专家(技术人员、管理者和富有经验的职员等)接触，向他们学习、请教。要以恰当的提问正确地引导交谈的内容。这种调查可概括为如下的流程： 提问——倾听——理解消化——反馈自己的理解以求印证——提出进一步的问题。
2． 亲临现场，通过直接观察掌握第一手材料
要了解一个领域，最可靠的办法是身临其境，实践是检验真理的唯一标准，只有自己的亲身体验才是最有效的。比如要开发一个商场的管理系统，分析员最好先作为普通顾客到这个商场去购物。看看售货员怎么开小票，收款台怎样收款，小票的哪一联留到收款台，哪一联返给售货员，哪一联给顾客。当然这只是表层的观察。进一步应该深入商场内部观察一般情况下看不到的业务处理过程。
3． 阅读领域相关资料
向问题域专家学习固然是最重要的，但如果对领域最基本的常识和概念、术语一点儿都不懂，就缺少与问题域专家交流的共同语言，增加了调查的难度，甚至使用户对你的单位承担这个项目的能力缺乏信心。所以在和用户及问题域专家正式接触之前，最好先阅读与问题域有关的科学，学习相应的行业和领域的基本知识，广泛地收集一些与问题域知识有关的书籍或其他书面材料，进行一番闭门苦读，充实自己的知识。这样的突击学习可能使你掌握相当多的知识，进而在日后的分析工作中受益颇多。
4． 借鉴他人经验
查阅相同或相似问题域已有系统的OOA文档，包括自己或同事开发的，以及在教科书、专业论文或技术报告中能找到的相似系统的OOA技术资料，看看别人是怎样分析与研究问题域的，从问题域中抽象了哪些类，“它山之石，可以攻玉”。同时，这种借鉴还可以发现一批可以复用的类。
3．3．3确定系统边界
确定系统边界，就是明确系统是什么以及系统的环境是什么，划出被开发的系统和与该系统打交道的人或物之间的明确界限，并确定它们之间的接口。例如，当准备用一个自动化系统去取代现有的手工劳动或半自动化系统时，新系统的环境与旧系统的环境是一样的，在另外一些情况下，却有许多不确定性，需要在需求分析过程中不断认识。在系统边界以内，是系统本身所包含的对象。在系统边界以外，是系统外部的活动者，主要是人、设备和外部系统三种外部活动者。在许多情况下，系统与环境之间的界限是相对清楚的。
与系统交互的人向系统发出命令，提供输入信息，接受系统的服务或从系统获得信息。设备是指与系统相连并交换信息的设备。外部系统是指与系统相连并交换信息的其他系统。
只有由系统的信息或模拟其行为的人和物才应该被当作系统边界以内的对象，而那些与系统进行信息交换的人员、设备或外部系统，尽管系统中也可能设立一些描述它们的特征并负责与它们交互的对象，但它们本身是通过系统边界与系统交互的活动者。
认识系统边界的目的是为了明确系统的范围以及与外部世界的接口。系统边界以内的事物，由系统中的对象来表达； 边界以外的活动者通过经它们和系统的接口与系统交互； 边界以外不与系统交互的事物统统不必考虑。系统边界的另一个作用是，在定义用例时系统边界是作为观察活动者与系统交互的着眼点。
3．4发现对象
3．4．1发现对象技术概要
利用面向对象软件设计技术可以显著地提高软件开发的质量和生产效率，但它必须在正确识别了对象集合的基础上才能得以体现。对于一个给定的应用领域，一个合适的对象集合能够确保软件的可重用性，提高可扩充性，并能借助面向对象的开发模式，提高软件开发的质量和生产效率。没有一个科学的对象识别的客观方法，就不能充分发挥面向对象程序设计方法的优势。
3．4．2正确地运用抽象原则
OOA用对象映射问题域中的事物，并不意味着对分析员见到的任何东西都在系统中设立相应的对象。在对象识别中最为关键的是正确地运用抽象原则。面向对象分析用对象来映射问题域中的事物，但并不是问题域中的所有事物都需要用对象来进行映射，系统分析员应紧密围绕系统责任这个目标去对问题域中的事物进行抽象。
在OOA中运用抽象原则，先要舍弃与系统责任无关的事物，保留与系统责任有关的事物。其次，还要舍弃与系统责任有关的事物中与系统责任无关的特征。判断事物及其特征是否与系统责任相关的准则是： 该事物是否为系统提供了一些有用的信息或需要系统为其保存和管理某些信息； 该事物是否向系统提供了某些服务或需要系统描述它的某些行为。
正确地进行抽象还需要考虑将问题论域中的事物映射为什么对象以及如何对这些对象进行分类的问题。一个可说明这个问题的例子是： 当开发一个书店的业务管理系统时，不需要把每一本书作为一个对象，在这个系统中把同一版本的一种书从总体上看作一个对象更合理些。只要把一种书看作一项货物，记住它的货源、单价、库存等信息就够了，不需要记录每一本书的信息。但在开发一个图书馆管理系统时设立了“书”这个类，同时把每一本书作为该类的一个对象，因为系统需要记住每一本书借给了哪个读者。但是在类的设置中也可以有不同的决定，例如在一个系统中可以把所有的人员对象都用同一个“人员”类来定义，而在另一个系统中也可以把管理者和工作设置成不同的类。这些例子表明，如何把问题域的事物抽象为对象和类，可以有不同的选择。在不同的系统中，抽象的程度可以有所不同。好的抽象应能清晰而简练地表达问题域，并使系统的开销少，这需要分析员根据不同系统的具体情况恰如其分地运用抽象原则。
3．4．3策略与启发
为了尽可能识别出系统所需要的对象，系统分析员应首先找出各种可能有用的候选对象，尽量避免遗漏； 然后对所发现的候选对象逐个进行严格的审查，筛选不必要的对象，或者将它们进行适当的调整与合并，使系统中的对象和类尽可能地紧凑。这种策略可以称为“先紧后松”策略。寻找各种可能有用的候选对象时，主要的思路是： 从问题域、系统边界和系统责任这三个方面出发，考虑各种能启发自己发现对象的因素，找到可能有用的候选对象。
1． 考虑问题域
在问题域方面，可以启发分析员发现对象的因素包括： 人员、组织、设备、物品、事件、表格、结构等。
人员： 大多数系统的问题域都涉及各种各样的人员，需要考虑的是以下两种情况： 一是需要由系统保存和管理其信息的人员； 二是在系统中提供某些服务的人员，这些都有可能是系统候选的人员对象。
组织： 在系统中发挥一定作用的组织结构。如行政单位、业务部门、办事机构、社会团体、工作班组等。
设备： 是指在系统中动态地运行，由系统进行监控或者供系统使用的各种设备、仪表、机器以及运输工具。分析员只考虑问题域中固有的设备，暂不考虑计算机的相应硬件设备。这是为了使分析模型不受硬件选择的影响。实际上，在大多数情况下计算机设备已被系统软件屏蔽，不需要在被开发的系统中设立相应的对象。
物品： 是指那些需要由系统管理的各种物品。如经营的商品、出厂的产品等。还应注意那些无形的事物，例如企业中的一项生产计划、贸易部门的一项业务等。它们容易被忽视，所以要特别注意。
事件： 指那些需要由系统长期记忆的事件。大部分系统每日每时都会发生许多事件，其中有些(但并非全部)事件的信息需要在系统中长期记忆。对于这样的事件，可考虑设立相应的对象记录其信息。分析员首先要判断哪些事件是需要长期记忆的，然后根据其信息的复杂程度与其他对象的相关情况决定是否为它设立一个对象。
表格： 这里“表格”的概念是广义的，既包括各种业务报表、统计表、登记表、申请表，也包括身份证件、户口簿、商品订单、预支款单、报销单、账目、学生成绩单等。分析员进入问题域，首先容易看到的就是各种各样的表格，也很容易想到设立一些对象来映射这些表格。由于表格在形式上比较规范，因此在系统中设立相应的对象来描述它们是很方便的。但是无节制地设立许多表格对象往往会产生一个臃肿的、畸形的系统，原因如下。
(1) 尽管表格也是问题域中的一种事物，但大多数情况下并不是那种固有的、原始的事物。它们是由人根据对一些原始事物的理解，经过头脑的加工而产生的二手信息，是对一些现实事物的映射。例如，身份证件是对人员对象的一种映射。如果过分依靠这些表格来构造系统，反而看不到它们所描述的那些客观事物固有的属性和行为。
(2) 许多表格的信息，是可以从其他表格(或某些对象)导出的。例如，在我国各个省级的电话管理局中，每年上报到各种政府部门或行业部门的报表有上百种，而手头保存的和日常收集的表格则只有很少几种，所有上报的表格都是依据这几种表格的信息产生的。在这种情况下，如果针对每一种表格设立一类对象，会使系统显得十分凌乱，并会造成大量的信息冗余。
正确的策略是： 不要急于考虑从表格发现对象，把产生的各种表格看成一种用户需求，将它与其他的用户需求结合起来，共同作为发现对象的途径。通过考虑问题域的其他事物发现了许多对象之后，检查能否满足表格的需求。如果不能满足，则考虑是否遗漏了某些对象，或者一些对象中遗漏了某些属性和服务。最后再考虑针对某些表格设立相应的对象。
图33类的关系
结构： 通过考虑结构可以得到一种启发——从已经发现的对象联想到其他更多的对象。例如，考虑“汽车”这个对象的类在一般—特殊结构中的位置，向上可以联想到“车辆”，向下可以联想到“客车”和“货车”，“车辆”向右可以联想到“轮船”。“车辆”和“轮船”又可以向上联想到“交通工具”，如图33所示。
2． 考虑系统边界
在系统边界方面，应该考虑的因素包括人员、设备和外部系统，它们可以启发分析员发现一些系统与外部活动所进行的交互，并处理系统对外接口的对象。
人员： 作为系统以外活动者与系统进行直接交互的各类人员，如系统操作员、直接使用系统的用户等。
设备： 作为系统以外的活动者与系统相连并交换信息的设备。
外部系统： 与系统相连并交换信息的其他系统。
这里讨论的人员和设备，在考虑问题域时也谈到了。分析员可以从不同的角度去观察问题。前面的讨论是从问题域的角度出发，把这些人员和设备看作问题域范畴以内的事物，系统中的对象是对它们的抽象描述。现在是从另一个角度去看： 当计算机应用系统建立之后，它们是在系统边界之外与系统进行交互的活动者(即用例图中的操作者)，系统中需要设立相应的对象处理系统与这些实际的人和设备交互。前一种观点侧重于以系统中的对象模拟现实中的人和设备； 后一种观点侧重于以系统中的对象处理现实中的人和设备与系统的交互。哪种效果更好，要看系统的具体情况。
至于外部系统的接口，无疑只能从系统边界这个角度去考虑。只能说在系统中设立一个对象处理与外部系统的接口，不能说用这个对象去映射外部系统。
3． 考虑系统责任
通过对问题域和系统边界的考察，发现了许多对象，但谁也不敢保证没有疏漏，对基于发现对象识别的遗漏的考虑，对照系统责任所要求的每一项功能，查看是否可以由已找出的对象来完成该功能，如果发现某些功能在现有的任何对象中都不能提供，则可启发我们发现问题域中某些遗漏的对象。
系统责任要求的某些功能可能与实现环境(如图形用户界面系统、数据库管理系统)有关。OOA的对象不提供这些功能是正常的，应该推迟到设计阶段考虑。因为按原则，OOA模型应该独立于具体的实现环境。
系统责任所要求的某些功能，例如系统安装、配置、信息备份、浏览，可能无法从问题域中找到相应的对
— 没有更多了 —
以下为对购买帮助不大的评价