北邮软件工程课件第7章面向对象分析.ppt

《北邮软件工程课件第7章面向对象分析.ppt》由会员分享，可在线阅读，更多相关《北邮软件工程课件第7章面向对象分析.ppt（79页珍藏版）》请在三一办公上搜索。

1、第7章 面向对象分析,退出,面向对象分析(通常缩写为OOA)的关键，是识别出问题域内的对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。在用面向对象观点建立起的三种模型中，对象模型是最基本、最重要、最核心的。,7.1 分析过程7.2 需求陈述7.3 建立对象模型7.4 建立动态模型7.5 建立功能模型7.6 定义服务7.7 面向对象分析实例7.8 小结,7.1 分析过程,7.1.1 概述 面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。,7.1.2 三个子模型与五个层次 正如本书6.4节所述，面向对象建模得到的模型包含系统的三个要素，即静态结构(对象

2、模型)，交互次序(动态模型)和数据变换(功能模型)。解决的问题不同，这三个子模型的重要程度也不同：几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序时(例如，用户界面及过程控制等)，动态模型是重要的；解决运算量很大的问题(例如，高级语言编译、科学与工程计算等)，则涉及重要的功能模型。动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。复杂问题(大型系统)的对象模型由下述五个层次组成：主题层(也称为范畴层)、类&对象层、结构层、属性层和服务层，如图7.1所示。,图7.1 复杂问题的对象模型,综上所述，我们在概念上可以认为，面向对

3、象分析大体上按照下列顺序进行：寻找类&对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。但是，正如前面已经多次强调指出过的，分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。,分析也不是一个机械的过程。大多数需求陈述都缺乏必要的信息，所缺少的信息主要从用户和领域专家那里获取，同时也需要从分析员对问题域的背景知识中提取。在分析过程中，系统分析员必须与领域专家及用户反复交流，以便澄清二义性，改正错误的概念，补足缺少的信息。面向对象建立的系统模型，尽

4、管在最终完成之前还是不准确、不完整的，但对做到准确、无歧义的交流仍然是大有益处的。,7.2 需求陈述,7.2.1 书写要点 通常，需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。总之，需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户的需求而不是提出解决问题的方法。应该指出哪些是系统必要的性质，哪些是任选的性质。应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活性。对系统性能及系统与外界环境交互协议的描述，是合适的需求。此外，对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求。,

5、7.2.2 例子 图7.2 所示的自动取款机(ATM)系统，是本书讲述面向对象分析和面向对象设计时使用的一个实例。,图7.2 ATM系统,下面陈述对ATM系统的需求。某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。,银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。

6、通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。,拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若

7、干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。,当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就

8、要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。,7.3 建立对象模型,7.3.1 确定类&对象 类&对象是在问题域中客观存在的，系统分析员的主要任务，就是通过分析找出这些类&对象。首先，找出所有候选的类&对象；然后，从候选的类&对象中筛选掉不正确的或不必要的。1.找出候选的类&对象,另一种更简单的分析方法，是所谓的非正式分析。这种分析方法以用自然语言书写的需求陈述为依据，把陈述中的名词作为类&对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。下面以ATM系统为例，说明非正式分析过

9、程。认真阅读7.2.2节给出的需求陈述，从陈述中找出下列名词，可以把它们作为类&对象的初步的候选者。,银行、自动取款机(ATM)、系统、中央计算机、分行计算机、柜员终端、网络、总行、分行、软件、成本、市、街道、营业厅、储蓄所、柜员、储户、现金、支票、账户、事务、现金兑换卡、余额、磁卡、分行代码、卡号、用户、副本、信息、密码、类型、取款额、账单以及访问。通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类&对象，因此，分析员应该根据领域知识或常识进一步把隐含的类&对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应

10、该包含这两个实体。,2.筛选出正确的类&对象 显然，仅通过一个简单、机械的过程不可能正确地完成分析工作。非正式分析仅仅帮助我们找到一些候选的类&对象，接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选时主要依据下列标准，删除不正确或不必要的类&对象。,(1)冗余(2)无关(3)笼统(4)属性(5)操作(6)实现 综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类&对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务和现金兑换卡。,7.3.2 确定关联 如前所述，两个或多个对象之间的相互依赖、相

11、互作用的关系就是关联。分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类&对象。在分析确定关联的过程中，不必花过多的精力去区分关联和聚集。事实上，聚集不过是一种特殊的关联，是关联的一个特例。,1.初步确定关联 在需求陈述中使用的描述性动词或动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过直接提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些在陈述中隐含的关联。最后，分析员还应该与用户及领域专家讨论问题域实体间的相互依赖、相互作用关系，根据领域知识再进一步补充一些关联。,2.筛选 经初步分析得出的关联只能作为候选的关联，还需经过进一步筛

12、选，以去掉不正确的或不必要的关联。筛选时主要根据下述标准删除候选的关联。(1)已删去的类之间的关联(2)与问题无关的或应在实现阶段考虑的关联(3)瞬时事件(4)三元关联(5)派生关联,3.进一步完善 应该进一步完善经筛选后余下的关联，通常从下述几个方面进行改进。(1)正名(2)分解(3)补充(4)标明阶数 图7.3是经上述分析过程之后得出的ATM系统原始对象图。,图7.3 ATM系统原始对象图,7.3.3 划分主题 在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。,图7.4 把ATM系统划分成三个主题

13、,7.3.4确定属性 一般说来，确定属性的过程包括分析和选择两个步骤。1.分析 属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属性。,2.选择 认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。通常有以下几种常见情况。(1)误把对象当作属性(2)把链属性误作为属性(3)把限定误当成属性(4)误把内部状态当成了属性(5)过于细化(6)存在不一致的属性,图7.5 ATM对象模型中的属性,7.3

14、.5识别继承关系 确定了类中应该定义的属性之后，就可以利用继承机制共享公共性质，并对系统中众多的类加以组织。一般说来，可以使用两种方式建立继承(即归纳)关系。自底向上：抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。,图7.6 带有继承关系的ATM对象模型,7.3.6 反复修改 仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改。由于面向对象的概念和符号在整个开发过程中都是一致

15、的，因此远比使用结构化分析和设计技术更容易实现反复修改及逐步完善的过程。,图7.7 修改后的ATM对象模型,7.4 建立动态模型,建立动态模型的第一步，是编写典型交互行为的脚本。虽然脚本中不可能包括每个偶然事件，但是，至少必须保证不遗漏常见的交互行为。接下来从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。,7.4.1 编写脚本 所谓“脚本”，原意是指“表演戏曲、话剧，拍摄电影、电视剧等所依据的本子，里面记载台词、

16、故事情节等”。在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性和清晰性。编写脚本时，首先编写正常情况的脚本。然后，考虑特殊情况，例如输入或输出的数据为最大值(或最小值)。最后，考虑出错情况，例如，输入的值为非法值或响应失败。,表7.1和表7.2分别给出了ATM系统的正常情况脚本和异常情况脚本。表7.1ATM系统的正常情况脚本 ATM请储户插卡；储户插入一张现金兑换卡 ATM接受该卡并读它上面

17、的分行代码和卡号 ATM要求储户输入密码；储户输入自己的密码“1234”等数字 ATM请求总行验证卡号和密码；总行要求“39”号分行核对储户密码，然后通知ATM说这张卡有效 ATM要求储户选择事务类型(取款、转账、查询等)；储户选择“取款”ATM要求储户输入取款额；储户输入“880”,ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务；总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额ZK)ATM吐出现金并请储户拿走这些现象；储户拿走现金 ATM问储户是否继续这项事务；储户回答“不”ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡 ATM请储户插卡,表

18、7.2ATM系统的异常情况脚本 ATM请储户插卡；储户插入一张现金兑换卡 ATM接受这张卡并顺序读它上面的数字 ATM要求密码；储户误输入“8888”ATM请求总行验证输入的数字和密码；总行在向有关分行咨询之后拒绝这张卡 ATM显示“密码错”，并请储户重新输入密码；储户输入“1234”；ATM请总行验证后知道这次输入的密码正确 ATM请储户选择事务类型；储户选择“取款”ATM询问取款额；储户改变主意不想取款了，他敲“取消”键 ATM退出现金兑换卡，并请储户拿走它；储户拿走他的卡 ATM请储户插卡,7.4.2 设想用户界面,图7.8 ATM的界面格式,7.4.3 画事件跟踪图 完整、正确的脚本为

19、建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。为此首先需要进一步明确事件及事件与对象的关系。,1.确定事件 应该仔细分析每个脚本，以便从中提取出所有外部事件。事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断和动作等。从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏了异常事件和出错条件。传递信息的对象的动作也是事件。经过分析，应该区分出每类事件的发送对象和接受对象。一类事件相对它的发送对象来说是输出事件，但是相对它的接受对象来说则是输入事件。有时一个对象把事件发送

20、给自己，在这种情况下，该事件既是输出事件又是输入事件。,2.画出事件跟踪图 从脚本中提取出各类事件并确定了每类事件的发送对象和接受对象之后，就可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。事件跟踪图实质上是扩充的脚本。在事件跟踪图中，一条竖线代表一个类&对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。时间从上向下递增，也就是说，画在最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生。箭头线之间的间距并没有具体含义，图中仅用箭头线在垂直方向上的相对位置表示事件发生的先后，并不表示两个事件之间的精确时间差。图7.9是

21、ATM系统正常情况下的事件跟踪图。,图7.9 ATM系统正常情况脚本的事件跟踪图,7.4.4 画状态图 状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件。由事件引起的状态改变称为“转换”。如果一个事件并不引图7.9ATM系统正常情况脚本的事件跟踪图起当前状态发生转换，则可忽略这个事件。通常，用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。但是，也不是任何一个类&对象都需要有一张状态图描绘它的行为。很多对象仅响应与过去历史无关的那些输入事件，或者把历史作为不影响控制流的参数。对于这类对象来说，状态图是不必要的。系统分析员应该集中

22、精力仅考虑具有重要交互行为的那些类。,从一张事件跟踪图出发画状态图时，应该集中精力仅考虑影响一类对象的事件，也就是说，仅考虑事件跟踪图中指向某条竖线的那些箭头线。把这些事件作为状态图中的有向边(即箭头线)，边上标以事件名。两个事件之间的间隔就是一个状态。一般说来，如果同一个对象对相同事件的响应不同，则这个对象处在不同状态。应该尽量给每个状态取个有意义的名字。通常，从事件跟踪图中当前考虑的竖线射出的箭头线，是这条竖线代表的对象达到某个状态时所做的行为(往往是引起另一类对象状态转换的事件)。,根据一张事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中。为此需在事件跟踪图中找出

23、以前考虑过的脚本的分支点(例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”)，然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。考虑完正常事件之后再考虑边界情况和特殊情况，其中包括在不适当时候发生的事件(例如，系统正在处理某个事务时，用户要求取消该事务)。,图7.10 ATM类的状态图,图7.11 总行类的状态图,图7.12 分行类的状态图,7.4.5 审查动态模型,7.5 建立功能模型,7.5.1 画出基本系统模型图 基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。基本系统模型指明了目标

24、系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。,图7.13 ATM系统的基本系统模,7.5.2 画出功能级数据流图 把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。7.5.3 描述处理框功能 把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。应该注意的是，要着重描述每个处理框所代表的功能，而不是实现功能的具体算法。描述既可以是说明性的，也可以是过程性的。,图7.14 ATM系统的功能级数据流图,表7.3对更新账户功能的描述更新账户(账号，事务类型，金额)现金额，账单数据，信

25、息 如果取款额超过账户当前余额，拒绝该事务且不付出现金 如果取款额不超过账户当前余额，从余额中减去取款额后作为新的余额，付出储户要取的现金 如果事务是存款，把存款额加到余额中得到新余额，不付出现金 如果事务是查询，不付出现金在上述任何一种情况下，账单内容都是：ATM号、日期、时间、账号、事务类型、事务金额(如果有的话)和新余额,7.6 定义服务,在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。7.6.1 常规行为 7.6.2 从事件导出的操作,7.6.3 与数据流图中处理框对应的操作 数据流图中的每个处理框都与一个对象(也可能是若干个对象)上的操作相对应。

26、应该仔细对照状态图和数据流图，以便更正确地确定对象应该提供的服务。7.6.4 利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服务数目。只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。,7.7 面向对象分析实例,7.7.1 需求陈述 我们将要讨论的是电梯的控制问题，下面给出对这个问题的描述。在一幢有m层楼的大厦中需要一套控制n部电梯的产品，要求这n部电梯根据下列约束条件在楼层间移动。,C1：每部电梯有m个按钮，每个按钮代表一个楼层。当按下一个按钮时该按钮指示灯亮，同时电梯驶向相应的楼层，当到达由按钮指定的楼

27、层时指示灯熄灭。C2：除了大厦的最低层和最高层之外，每层楼都有两个按钮分别指示电梯上行和下行。当这两个按钮之一被按下时相应的指示灯亮，当电梯到达此楼层时灯熄灭，电梯向要求的方向移动。C3：当电梯无升降动作时，关门并停在当前楼层。,7.7.2 建立对象模型 面向对象分析的第一步是构造对象模型。在这个步骤中将抽象出类和它的属性，并用对象模型图描绘类&对象及它们彼此之间的关系。类所提供的服务将在面向对象分析后期或面向对象设计阶段再确定下来。为了抽象出问题域中包含的类，可以用下述三个过程产生候选类，并对所得到的结果加以精化。1.精确地定义问题 应该尽可能简洁地定义所需要的产品，最好只用一句话来描述目标

28、系统。例如，对电梯系统可以像下面那样描述。在一个m层楼的大厦里，用每层楼的按钮和电梯内的按钮来控制n部电梯的移动。,2.提出非形式化策略 为了提出一种解决上述问题的非形式化策略，必须确定问题的约束条件。在7.7.1小节中已经对电梯问题提出了三种约束。最好能用一小段文字把非形式化策略清楚地表达出来，对电梯问题来说，解决问题的非形式化策略可表达如下。在一幢有m层楼的大厦里，用电梯内的和每个楼层的按钮来控制n部电梯的运动。当按下电梯按钮以请求在某一指定楼层停下时，按钮指示灯亮；当请求获得满足时，指示灯熄灭。当电梯无升降操作时，关门并停在当前楼层。,3.把策略形式化 在以上这段描述非形式化策略的文字中

29、，共有八个不同的名词：按钮、电梯、楼层、运动、大厦、指示灯、请求和门。这些名词所代表的事物可作为类的初步候选者。其中，楼层和大厦是处于问题边界之外的，因此可以忽略；运动、指示灯、请求和门可以作为其他类的属性，例如，指示灯(的状态)可作为按钮类的属性，门(的状态)可作为电梯类的属性。经过上述筛选后只剩下两个候选类，即电梯和按钮。补充了电梯控制器类之后，得到了图7.16所示的对象模型。,图7.15电梯系统对象模型的第一次迭代,图7.16 电梯系统对象模型的第二次迭代,7.7.3 建立动态模型 1.编写脚本 这一步的目的是，决定每一个类应该做的操作。达到这个目的的一种有效的方法，是列出用户和系统之间

30、相互作用的典型情况，即写出脚本(包括正常情况脚本和异常情况脚本)。表7.4和表7.5分别是正常情况脚本和异常情况脚本。,表7.4 电梯系统正常情况脚本 用户A在3楼按上行按钮呼叫电梯，用户A希望到7楼去 上行按钮指示灯亮 一部电梯到达3楼，电梯内的用户B已按下了到9楼的按钮 上行按钮指示灯熄灭 电梯开门 用户A进入电梯,用户A按下电梯内到7楼的按钮 7楼按钮指示灯亮 电梯关门 电梯到达7楼 7楼按钮指示灯熄灭 电梯开门 用户A走出电梯 电梯在等待时间到后关门 电梯载着用户B继续上行到达9楼,表7.5 电梯系统异常情况脚本 用户A在3楼按上行按钮呼叫电梯，但是用户A希望到1楼 上行铵钮指示灯亮

31、一部电梯到达3楼，电梯内用户B已按下了到9楼的按钮 上行按钮指示灯熄灭 电梯开门 用户A进入电梯 用户A按下电梯内到1楼的按钮,电梯内1楼按钮指示灯亮 电梯在等待超时后关门 电梯上行到达9楼 电梯内9楼按钮指示灯熄灭 电梯开门 用户B走出电梯 电梯在等待超时后关门 电梯载着用户A下行驶向1楼,2.画状态转换图 电梯控制器是在电梯系统中起核心控制作用的类，我们将画出这个类的状态转换图。为简单起见，仅考虑一部电梯(即n=1)的情况。电梯控制器的动态模型如图717所示，这个状态图的画法与本书36节讲的画法大同小异，读者可对照电梯系统的脚本来理解它。,图7.17 电梯控制器类的动态模型,7.7.4建立

32、功能模型 结构化范型中使用的数据流图与面向对象范型中使用的数据流图的差别，主要是数据存储的含义可能不同：在结构化范型中数据存储几乎总是作为文件或数据库来保存，然而在面向对象范型中类的状态变量(即属性)也可以是数据存储。因此，面向对象范型的功能模型中包含两类数据存储，分别是类的数据存储和不属于类的数据存储。,7.7.5 进一步完善 根据从功能模型中获得的信息，重新审查对象模型(图7.16)和动态模型(图7.17)，以便进一步完善面向对象分析的结果。增加了“电梯门”类和“请求”类之后，得到对象模型的第三次求精结果，如图7.19所示。修改了对象模型之后，必须重新审查动态模型和功能模型，看看是否需要进

33、一步求精。显然，必须修改功能模型，把数据存储“电梯门”和“请求”标识为类，如图7.20所示。经审查发现，动态模型现在仍然适用。,图7.18 电梯系统功能模型的第一次迭代,图7.19 电梯系统对象模型的第三次迭代,7.8 小结,分析就是提取系统需求并建立问题域精确模型的过程，它包括理解、表达和验证等三项主要工作内容。面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。大型、复杂系统的对象模型通常由下述五个层次组成：主题层、类&对象层、结构层、属性层和服务层。它们对应着在建立对象模型的过程中所应完成的五项工作。,大多数分析模型都不是一次完成的，为了理解问题域

34、的全部含义，必须反复多次地进行分析。因此，分析工作不可能严格地按照预定顺序进行；分析工作也不是机械地把需求陈述转变为分析模型的过程。分析员必须与用户及领域专家反复交流、多次磋商，及时纠正错误认识并补充缺少的信息。分析模型是同用户及领域专家交流时有效的通信手段。最终的模型必须得到用户和领域专家的确认。在交流和确认的过程中，原型往往能起很大的促进作用。,一个好的分析模型应该正确完整地反映问题的本质属性，且不包含与问题无关的内容。分析的目标是全面深入地理解问题域，其中不应该涉及具体实现的考虑。但是，在实际的分析过程中完全不受与实现有关的影响也是不现实的。虽然分析的目的是用分析模型取代需求陈述，并把分析模型作为设计的基础，但是，事实上，在分析与设计之间并不存在绝对的界线。认真阅读并仔细思考本章讲述的自动取款机系统和电梯系统这两个实例，有助于读者更深入、具体地理解面向对象分析的方法与过程。,