第10章面向对象分析.ppt

《第10章面向对象分析.ppt》由会员分享，可在线阅读，更多相关《第10章面向对象分析.ppt（65页珍藏版）》请在三一办公上搜索。

1、第10章 面向对象分析10.1 面向对象分析的基本过程10.2 需求陈述10.3 建立对象模型10.4 建立动态模型10.5 建立功能模型10.6 定义服务作业,不论采用哪种方法开发软件，分析的过程都是提取系统需求的过程。面向对象分析的关键是识别出问题域内的类与对象，分析确定它们之间的关系，最终建立起问题域的对象模型、动态模型和功能模型，它们是软件需求规格的重要组成成分。分析工作主要包括3项内容：理解、表达、验证首先，分析员通过与用户及领域专家的充分交流，力求充分理解用户需求和该应用领域的关键性背景知识。接下来用某种无二义性的方式把这种理解表达成文档资料。（软件需求规格说明）,由于问题复杂，而

2、且人与人之间的交流带有随意性和非形式化的特点，上述理解过程通常不能一次就达到理想的效果。因此，还必须进一步验证软件需求规格说明的正确性、完整性和有效性，如果发现了问题则进行修正。显然，需求分析过程是系统分析员与用户及领域专家反复交流和多次修正的过程。也就是说，理解和验证的过程通常交替进行，反复迭代，而且往往需要利用原形系统作为辅助工具。,10.1 面向对象分析的基本过程10.1.1 概述面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。通常，面向对象分析过程从分析陈述用户需求的文件开始。需求陈述往往是不完整、不准确的，而且往往是非正式的。通过分析，应该改正原始陈述中的二义性和不一

3、致性，补充遗漏的内容，从而使需求陈述更完整、更准确。在分析需求陈述的过程中，需要反复多次地与用户协商、讨论、交流信息，还应该通过调研了解现有的类似系统。快速地建立起一个能在计算机上运行的原型系统，非常有助于分析员与用户之间的沟通，从而能更正确地提取出用户的需求。,接下来，分析员应该在深入理解用户需求的基础上，抽象出目标系统的本质属性，并利用模型精确地表示出来：通过建立模型能够纠正在开发早期对问题域的误解在面向对象建模的过程中，分析员必须认真向领域专家学习此外，还应该仔细研究以前针对相同的或类似的问题域进行面向对象分析得到的结果，这些结果在当前项目中往往有许多是可以重用的,10.1.2 3个子模

4、型与5个层次面向对象建立起来的模型包含系统的3个要素，即：静态结构(对象模型)交互次序(动态模型)数据变换(功能模型)解决的问题不同，这3个子模型的重要程度也不同：几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型当问题涉及交互作用和时序时，动态模型是重要的解决运算量很大的问题，则涉及重要的功能模型动态模型和功能模型中都包含了对象模型中的操作(即服务)。,复杂问题的对象模型的5个层次,复杂问题（大型系统）的对象模型通常由下述5个层次组成：,复杂问题的对象模型的5个层次对应着在面向对象分析过程中建立对象模型的5项主要活动：找出类与对象，识别结构，识别主题，定义属性

5、，定义服务。强调：这5项工作完全没有必要顺序完成，也无须彻底完成一项工作以后再开始另外一项工作。,在概念上可以认为，面向对象分析大体上按照下列顺序进行：寻找类与对象识别结构识别主题定义属性建立动态模型建立功能模型定义服务但是，分析不可能严格地按照预定顺序进行，大型复杂系统的模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后逐渐扩充，直到充分地理解了整个问题，才能最终把完整的模型建立起来,10.2 需求陈述通常包括：问题范围，功能需求，性能需求，应用环境及假设条件等应该阐明“做什么”而不是“怎么做”应该描述用户的需求而不是提出解决问题的方法应该指出哪些是系统必要的性质，哪些是任选的性质

6、应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，否则将限制实现的灵活性对系统性能及外界环境交互协议的描述是合适的需求,对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求书写需求陈述时，要尽力作到语法正确，而且应该慎重选用名词、动词、形容词和同义词系统分析员必须与用户及领域专家密切配合协同工作，共同提炼和整理用户需求在这个过程中，很可能需要快速建立起原型系统，以便与用户更有效地交流,ATM系统,10.3 建立对象模型对象模型描述了现实世界中的“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构：静态数据结构对应用细节依赖较少，比

7、较容易确定当用户的需求变化时，静态数据结构相对来说比较稳定因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。建立对象模型是面向对象分析首要的工作,对象模型的主要信息来源：需求陈述、应用领域的专业知识以及关于客观世界的常识10.3.1 确定类与对象1.找出候选的类与对象对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述5类：可感知的物理实体，例如，飞机、汽车、书、房屋等等,人或组织的角色，例如，医生、教师、雇主、雇员、信息系、教务处等等应该记忆的事件，例如，飞行、演出、访问、交通事故等等 两个或多个对

8、象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等需要说明的概念，例如，政策、保险政策、版权法等等在分析所面临的问题时，可以参照上列5类常见事物，找出在当前问题域中的候选类与对象。,另一种更简单的分析方法，是所谓的非正式分析，即：以用自然语言书写的需求陈述为依据把陈述中的名词作为类与对象的候选者用形容词作为确定属性的线索把动词作为服务(操作)的候选者,2.筛选出正确的类与对象依据以下6个标准，删除不正确或不必要的类与对象：冗余如果两个名词(或名词短语)代表同样的事物，则应该仅保留在此问题域中最富于描述力的名称。无关现实世界中存在许多对象，不能把它们都纳入到系统中去，仅需要把本问

9、题密切相关的对象放在目标系统中。笼统在陈述需求时往往使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事物，因此，通常把这些笼统的或模糊的对象去掉。,属性在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选对象中去掉。当然，如果某个性质具有很强的独立性，则应该把它们作为对象而不是作为属性。操作在需求陈述中有时可能使用一些既作为名词，又可作为动词的词，应该慎重考虑它们在问题中的含义，以便正确地决定把她们作为对象还是作为对象的操作。一般说来，本身具有属性需要独立存在的

10、操作，应该作为对象；反之，应该作为对象的操作。实现在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选对象。,10.3.2 确定关联两个或多个对象之间相互作用、相互依赖的关系就是关联。在分析确定关联的过程中，不必花过多精力去区分关联和聚集。1.初步确定关联在需求陈述中使用的描述性动词或动词词组，通常表示关联关系：大多数关联可通过直接提取需求中的动词词组得出分析需求陈述，还能发现一些隐含的关联分析员还应该与用户及领域专家讨论问题域实体间的相互依赖、相互作用关系，根据领域知识再进一步补充一些关联,2.筛选候选关联需经过进一步筛选，以去掉不正确的或不必要的关联。依据以下5个标

11、准：已删去的对象之间的关联如果在分析确定对象的过程中已经删掉了某个候选对象，则与这个对象有关的关联也应该删去，或用其他对象重新表达这个关联。与问题无关的或应在实现阶段考虑的关联应该把处在本问题域之外的关联或与实现密切相关的关联删去。,瞬时事件关联应该描述问题域的静态结构，而不应该描述一个瞬时事件。三元关联三个或三个以上对象之间的关联，大多可以分解为二元关联。派生关联应该删除那些可以用其他关联定义的冗余关联。,3.进一步完善正名应该仔细选择含义更明确的名字作为关联名。分解为了能适用于不同的关联，必要时应该分解以前确定的类与对象。补充发现了遗漏的关联就应该及时补上。标明重数应该初步判断各个关联的类

12、型并粗略地确定关联的重数。,ATM系统原始的类图,10.3.3 划分主题在开发很小的系统时，可能根本无须引入主题层对于含有较多对象的系统，则往往先识别出类与对象和关联，然后划分主题，并用它作为指导开发者和用户观察整个模型的一种机制对于规模极大的系统，则首先由高级分析员粗略地识别对象和关联，然后初步划分主题，经进一步分析，对系统结构有风深入的了解之后，再进一步修改和精炼主题应该按问题领域而不是用功能分解方法来确定主题此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题,10.3.4 确定属性1.分析 通常，在需求陈述中用名词词组表示属性(例如，汽车的颜色)，用形容词表示可枚举的具

13、体属性：但不可能在需求陈述中找出全部属性，还必须借助于领域知识和常识才能分析得出需要的属性属性的确定既与问题域有关，也和目标系统的任务有关应该仅考虑与具体应用密切相关的属性，不要考虑那些超出所要解决的问题范围的属性,2.选择认真考虑经初步分析而确定下来的那些属性，从中删除不正确的或不必要的属性：误把对象当作属性如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。在具体应用领域中具有自身性质的实体，必然是对象。误把关联类的属性当作一般对象的属性如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性。,把限定误当成属性如果把某个属性值固定下来以后能减少关联的重数，则应该

14、把这个属性重新表述成一个限定词。误把内部状态当成了属性如果某个性质是对象的非公开的内部状态，则应该从对象模型中删除这个属性。过于细化在分析阶段应该忽略那些对大多数操作都没有影响的属性。存在不一致的属性类应该是简单而且一致的。如果得出一些看起来与其他实行毫不相关的属性，则应该考虑把该类分解成两个不同的类。,ATM系统对象模型中的属性,10.3.5 识别继承关系确定了类中应有的属性之后，就可以利用继承机制共享公共性质，并对系统中众多的类加以组织。继承关系的建立实质上是知识抽取过程，它应该反映出一定深度的领域知识，因此必须有领域专家密切配合才能完成。可以使用下述两种方法建立继承关系：自底向上：抽象出

15、现有类的公共属性泛化出父类，这个过程实质上模拟了人类的归纳思维过程。自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。使用多重继承机制时，应该指定一个主要父类，从它继承大部分属性和行为，次要父类再作补充。,带有继承关系的ATM对象模型,10.3.6 反复修改仅仅经过一次建模过程很难得到完全正确的对象模型：事实上，软件开发过程就是一个多次反复修改、逐步完善过程在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回前期阶段进行修改由于面向对象的概念和符号在整个开发过程中都是一致的，因此远比使用结构化分析和设计技术更容易实现反复修改及逐步完善的过程实际上，有些细化工作(例如，定义服

16、务)是在建立了动态模型和功能模型之后才进行的,修改后的ATM对象模型,10.4 建立动态模型步骤：编写典型交互行为的脚本。虽然脚本中不可能包括每个偶然事件，但是，至少必须保证不遗漏常见的交互行为。从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。,10.4.1 编写脚本所谓“脚本”，原意是指“表演戏剧、话剧，拍摄电影、电视剧等所依据的本子，里面记载台词、故事情节等”。在建立动态模型的过程中，脚本是指系统在某一执行期内出现的一系列

17、事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的整正确性和清晰性。,脚本描写的范围并不是固定的，既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。即使在需求陈述中已经描写了完整的交互过程，也还需要花很大精力构思交互的形式。编写脚本的过程，实质上就是分析确定用户对系统交互行为的要求的过程。在编写脚本的过程中，应该与用户充分交换意见，编写后还需要经过他们审查与修改。,编写脚本时：首先编写正常情况的脚本

18、然后考虑特殊情况，例如输入或输出的数据为最大值(或最小值)最后考虑出错情况，例如，输入的值为非法值或响应失败,脚本描述事件序列：每当系统中的对象与用户(或其他外部设备)交换信息时，就发生一个事件所交换的信息值就是该事件的参数(例如，“输入密码”事件的参数是所输入的密码)也有许多事件是无参数的，这样的事件仅传递一个信息该事件已经发生了对于每个事件，都应该指明触发该事件的动作对象(例如，系统、用户或其他外部事物)、接受事件的目标对象以及该事件的参数。,10.4.2 设想用户界面大多数交互行为都可以分为应用逻辑和用户界面两部分：通常，系统分析员首先集中精力考虑系统的信息流和控制流，而不是首先考虑用户

19、界面事实上，采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑应用逻辑是内在的、本质的内容，用户界面是外在的表现形式动态模型着重表示应用系统的控制逻辑,但是，用户界面的美观程度、方便程度、易学程度以及效率等等，是用户使用系统时最先感受到的，用户对系统的“第一印象”往往从界面得来，用户界面的好坏往往对用户是否喜欢、是否接受一个系统起很重要的作用。因此，在分析阶段也不能完全忽略用户界面。在这个阶段用户界面的细节并不太重要，重要的是在这种界面下的信息交换方式。我们的目的是确保能够完成全部必要的信息交换，而不会丢失重要的信息。不经过实际使用很难评价一个用户界面的优劣，因此，软件开发人员

20、往往快速地建立起用户界面的原型，供用户试用与评价。,ATM的界面格式,10.4.3 画事件跟踪图完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。为此首先需要进一步明确事件及事件与对象的关系。,1.确定事件应该仔细分析每个脚本，以便从中提取出所有外部事件：事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断和动作等从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏了异常时价和出错条件传递信息的对象的动作也是事件对象相互之间的交互行为多数都对应着事件,应该

21、把控制流产生相同效果的那些事件组合在一起作为一类事件，并给它们取一个惟一的名字。但是，必须把对控制流有不同影响的那些事件区分开来，不要误把它们组合在一起。经过分析，应该区分出每类事件的发送对象和接受对象：一类事件相对它的发送对象来说是输出事件，但是相对它的接受对象来说则是输入事件。有时一个对象把事件发送给自己。在这种情况下，该事件既是输出事件又是输入事件。,2.画出事件跟踪图从脚本中提取出各类事件并确定了每类事件的发送对象和接受对象之后，就可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。事件跟踪图实质上是扩充的脚本，也可以认为它是UML顺序图的简化形式。,在事件跟踪图中：

22、一条竖线代表一个对象每个事件用一条水平的箭头线表示箭头方向从发送对象指向接受对象时间从上向下递增也就是说，画最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生箭头线之间的间距并没有具体含义，图中仅用箭头线在垂直方向上的相对位置表示事件发生的先后，并不表示两个事件之间的精确时间差,10.4.4 画状态图状态图描绘事件与对象状态的关系：当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件由事件引起的状态改变称为“转换”如果一个事件并不引起当前状态发生转换，则可忽略这个事件通常，用一张状态图描绘一类对象的行为，它指明了由事件序列引出的状态序列：但是，并非任

23、何一类对象都需要一张状态图描绘它的行为很多对象仅响应与过去历史无关的那些输入事件，对于这类对象来说，状态图是不必要的,从一张事件跟踪图出发画状态图，应该集中精力仅考虑影响一类对象的事件，也就是说，仅考虑事件跟踪图中那些箭头线：把这些事件作为状态图中的有向边(即箭头线)，在有向边上标上事件名。两个事件之间处于不同状态：应该给每个状态取一个有意义的名字。通常，从事件跟踪图中当前考虑的竖线射出的箭头线，是这条竖线代表的对象到达某个状态时的行为(往往是导致另一类对象状态转换的事件)。根据一张事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中：为此需要在状态图中找出以前考虑的分支点

24、，然后把其他脚本中的事件序列插入到已有的状态图中，作为一条可选的路径。,考虑完正常事件之后再考虑边界情况和特殊情况，其中包括在不适当时候发生的事件(例如，系统正在处理某个事务时，用户要求取消该事务)：有时用户(或外部设备)不能做出快速响应，然而某些资源又必须及时收回，于是在一定间隔就产生了“超时”事件。对用户出错情况往往需要花费很多精力处理，并且会使原来清晰、紧凑的程序结构变得复杂、繁琐，但是，出错处理是不能省略的。当状态图覆盖了所有脚本，包含了影响某些对象状态的全部事件时，该类的状态图就构造出来了。,ATM类的状态图,总行类的状态图,分行类的状态图,10.4.5 审查动态模型各个类的状态图通

25、过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重要交互行为的类的状态图之后，应该检查系统级的完整性和一致性：一般来说，每个事件都应该既有发送对象又有接受对象，当然，有时发送者和接受者是同一对象对于没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互系列的起点也不是终点，则发现了一个错误应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配,10.5 建立功能模型功能模型描述软件系统的数据处理功能，最直接地反映了用户对系统的需求。通常，功能模型由一组数据流或一组用例图组成。其中的数据处理功能可以用IPO图(表)、PDL语言等多种方式进一步描述。一般说

26、来，应该在建立了对象模型和动态模型之后再建立功能模型。,10.5.1 画出基本系统模型图,基本系统模型由若干个数据源点/终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。ATM系统的数据源点/终点为储户，另一个数据源点是现金兑换卡。,ATM系统的基本系统模型,10.5.2 画出功能级数据流图,把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。,ATM系统的功能级数据流图,10.5.3 描述处理框功能,把数据流图分解细化到一定程度之后，就应该描述图中各个处理框所代表的功能，而不是实现功能的具体算法。描述既可以是说明性的，

27、也可以是过程性的。,10.6 定义服务为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务：通常需要等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地指出了每个类应该提供哪些服务。事实上，在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。,1.常规操作在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。但是，通常无须在类图中显式表示这些常规操作。2.从事件导出的操作状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须提供由消息选择

28、符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。所启动的服务通常就是接受事件的对象在相应状态的行为。,3.与处理或用例对应的操作数据流图中的每个处理或用例图中的每个用例，都与一个对象(也可能是若干个对象)所提供的操作相对应。应该把数据流图或用例图与状态图仔细对照，以便更正确地确定对象应该提供的服务。,4.利用继承减少冗余操作应该尽量利用继承机制以减少所需定义的服务数目。只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。,小组作业一下面是自动售货机系统的需求陈述，试建立它的对象模型、动态模型和功能模型：自

29、动售货机系统是一种无人售货系统。售货时，顾客把硬币投入机器的投币口中，机器检查硬币的大小、重量、厚度及边缘类型。有效的硬币是一元币、五角币、一角币、五分币、二分币和一分币。其他货币都被认为是假币。机器拒绝接受假币，并将其从退币孔退出。当机器接收了有效的硬币之后，就把硬币送入硬币储藏器中。顾客支付的货币根据硬币的面值进行累加。自动售货机装有货物分配器。每个货物分配器中包含零个或多个价格相同的货物。顾客通过选择货物分配器来选择货物。如果货物分配器中有货物，而且顾客支付的货币值不小于该货物的价格，货物将被分配到货物传送孔送给顾客，并将适当的零钱返回到退币孔。如果分配器是空的，则和顾客支付的货币值相等的硬币将被送回到退币孔。如果顾客支付的货币值少于所选择的分配器中货物的价格，机器将等待顾客投进更多的货币。如果顾客决定不买所选择的货物，他投放进的货币将从退币孔中退出。该作业请于本周四上课前上交。,小组作业二 运用本章所学知识，对本组开发的系统（案例）进行分析，列出需求陈述，初步建立对象模型、动态模型和功能模型。（要求基本理顺3种建模的思路与方法）该作业可在实验课阶段完成，具体上交时间另定。,