软件工程ppt10面向对象分析课件.ppt

第十章 面向对象分析,面向对象分析的基本过程需求陈述 建立对象模型建立动态模型建立功能模型定义服务,面向对象分析OOA(Object-Oriented Analysis)的目标是完成对所求解问题的分析，确定系统“作什么”，并建立系统的模型。,面向对象分析的基本过程,1.概述,OOA的基本任务 运用面向对象的方法,对问题域和系统责任进行分析和理解，找出描述它们的类和对象，定义其属性和操作，及其结构、静态联系和动态联系。,通常，面向对象分析过程从分析陈述用户需求的文件开始。可能由用户(包括出资开发该软件的业主代表及最终用户)单方面写出需求陈述，也可能由系统分析员配合用户，共同写出需求陈述。,OOA面临的问题：1、问题域和系统责任问题 问题域(problem domain) 被开发系统的应用领域。 系统责任(system responsibilities) 所开发的系统应具备的职能。2、交流问题（各类人员之间的要求）3、需求的不断变化（用户、竞争因素、经费、技术因素）,OOA分析过程,1、获取用户基本需求用户与开发者之间进行充分交流，常用User case(用例)来收集和描述用户的需求。即先标识使用该系统的不同的行为者(actor)。,2、标识类和对象标识类与对象是一致的。在确定系统的用例后，可标识类及类的属性和操作。,确定最终对象 可根据以下原则确定：需要保留的信息，需要的服务，具有多个属性，具有公共属性及操作。,从问题域或用例描述入手，发现对象。 对象可能的形式有：外部实体 、事物、发生的事件、角色、组织单位、场所、构造物等。,标识属性 从本质上讲，属性定义了对象。可从问题的陈述中或通过对类的理解而标识出属性。,定义操作 操作定义了对象的行为并以某种方式修改对象的属性。操作分为：对数据的操作，计算操作，控制操作。,3、定义类的结构和层次类的结构有： 一般特殊 (generalization - specialization)结构 整体部分(whole-part)结构,构成类图的元素所表达的模型信息，分为三个层次： 对象层给出系统中所有反映问题域和系统责任的对象。 特征层给出类（对象）的内部特征，即类的属性和操作。 关系层给出各类（对象）之间的关系，包括继承、组装、一般特殊 、整体部分、属性的静态依赖关系，操作的动态依赖关系。,对象层,特征层,关系层,图4.8 OOA基本模型,用“对象-关系模型”描述了系统的静态结构。5、建立对象-行为模型 描述了系统的动态行为。,4、建立类(对象)间的关系,面向对象建模得到的模型包含系统的三个要素，即静态结构(对象模型)、交互次序(动态模型)和数据变换(功能模型)。解决的问题不同，这三个子模型的重要程度也不同：几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序时(例如，用户界面及过程控制等)，动态模型是重要的；解决运算量很大的问题(例如，高级语言编译、科学与工程计算等)，则涉及重要的功能模型。动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。,2.三个子模型与五个层次,复杂问题（大型系统）的对象模型通常由下述5个层次组成： 主题层、类与对象层、结构层、属性层和服务层。,上述5个层次对应着在面向对象分析过程中建立对象模型的5项主要活动：找出类与对象，识别结构，识别主题，定义属性，定义服务。,需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。总之，需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户的需求而不是提出解决问题的方法。应该指出哪些是系统必要的性质，哪些是任选的性质。 应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活性。 书写需求陈述时，要尽力做到语法正确，而且应该慎重选用名词、动词、形容词和同义词。,需求陈述,1. 书写要点,系统分析员必须把需求与实现策略区分开，后者是一类伪需求。 需求陈述可简可繁。对人们熟悉的传统问题的陈述，可能相当详细，相反，对陌生领域项目的需求，开始时可能写不出具体细节。 随后进行的面向对象分析的目的，就是全面深入地理解问题域和用户的真实需求，建立起问题域的精确模型。 系统分析员必须与用户及领域专家密切配合协同工作，共同提炼和整理用户需求。在这个过程中，很可能需要快速建立起原型系统，以便与用户更有效地交流。,自动取款机(ATM)系统实例。,2.例子,需求陈述如下： 某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。,银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。,所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码惟一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。,当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。,面向对象分析首要的工作，是建立问题域的对象模型。这个模型描述了现实世界中的“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构。静态数据结构对应用细节依赖较少，比较容易确定；当用户的需求变化时，静态数据结构相对来说比较稳定。因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。需求陈述、应用领域的专业知识以及关于客观世界的常识，是建立对象模型时的主要信息来源。,建立对象模型,类与对象是在问题域中客观存在的，系统分析员的主要任务就是通过分析找出这些类与对象。首先找出所有候选的类与对象，然后从候选的类与对象中筛选掉不正确的或不必要的。,1.确定类与对象,、名词识别法识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。,、系统实体识别法不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。被标识的实体有：系统需要存储、分析、处理的信息实体、系统内部需要处理的设备、与系统交互的外部系统、系统相关人员、系统的组织实体。,1）找出候选的类与对象 对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述5类：(1) 可感知的物理实体，例如，飞机、汽车、书、房屋等等。(2) 人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。(3) 应该记忆的事件，例如，飞行、演出、访问、交通事故等等。,(4) 两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。(5) 需要说明的概念，例如，政策、保险政策、版权法等等。在分析所面临的问题时，可以参照上列5类常见事物，找出在当前问题域中的候选类与对象。,另一种更简单的分析方法，是所谓的非正式分析。这种分析方法以用自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。下面以ATM系统为例，说明非正式分析过程:从需求陈述中找出下列名词，可以把它们作为类与对象的初步的候选者：,银行，自动取款机(ATM)， 系统，中央计算机， 分行计算机， 柜员终端， 网络,总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。,2）筛选出正确的类与对象非正式分析仅仅帮助我们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选时主要依据下列标准，删除不正确或不必要的类与对象：,(1) 冗余以ATM系统为例，上面用非正式分析法得出了34个候选的类，其中储户与用户，现金兑换卡与磁卡及副本分别描述了相同的两类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。,(2) 无关以ATM系统为例，这个系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。(3) 笼统以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。此外还有一些笼统含糊的名词。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。,(4) 属性在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。(5) 操作例如，谈到电话时通常把“拨号”当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但是，在开发电话的自动记账系统时，“拨号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个类。总之，本身具有属性需独立存在的操作，应该作为类与对象。,(6) 实现在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联类的物理实现。总之，应该暂时去掉 “事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类与对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡。,两个或多个类之间的相互依赖关系就是关联,关联通常用描述性动词和动词词组表示,2.确定关联,1）初步确定关联以ATM系统为例，经过分析初步确定出下列关联：,(1) 直接提取动词短语得出的关联ATM、中央计算机、分行计算机及柜员终端组成网络。总行拥有多台ATM。ATM设在主要街道上。分行提供分行计算机和柜员终端。柜员终端设在分行营业厅及储蓄所内。,分行分摊软件开发成本。储户拥有账户。分行计算机处理针对账户的事务。分行计算机维护账户。柜员终端与分行计算机通信。柜员输入针对账户的事务。ATM与中央计算机交换关于事务的信息。中央计算机确定事务与分行的对应关系。ATM读现金兑换卡。ATM与用户交互。ATM吐出现金。ATM打印账单。系统处理并发的访问。,(2) 需求陈述中隐含的关联总行由各个分行组成。分行保管账户。总行拥有中央计算机。系统维护事务日志。系统提供必要的安全性。储户拥有现金兑换卡。(3) 根据问题域知识得出的关联现金兑换卡访问账户。分行雇用柜员。,2）筛选筛选时主要根据下述标准删除候选的关联：(1) 已删去的类之间的关联以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列8个关联也应该删去： ATM、中央计算机、分行计算机及柜员终端组成网络。 ATM设在主要街道上。 分行分摊软件开发成本。 系统提供必要的安全性。,(2) 与问题无关的或应在实现阶段考虑的关联应该把处在本问题域之外的关联或与实现密切相关的关联删去。例如，在ATM系统的例子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事务。, 系统维护事务日志。 ATM吐出现金。 ATM打印账单。 柜员终端设在分行营业厅及储蓄所内。,(3) 瞬时事件以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。如果用动作表述的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表示这个关联。例如，在ATM系统的需求陈述中，“中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系。,(4) 三元关联在ATM系统的例子中，“柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元关联。而“分行计算机处理针对账户的事务”也可以做类似的分解。“ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。,(5) 派生关联例如，在ATM系统的例子中，“总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“分行计算机维护账户”的实际含义是“分行保管账户”和“事务修改账户”。3）进一步完善应该进一步完善经筛选后余下的关联，通常从下述几个方面进行改进：,(1) 正名例如，“分行提供分行计算机和柜员终端”不如改为“分行拥有分行计算机”和“分行拥有柜员终端”。(2) 分解例如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。(3) 补充例如，在ATM系统中把“事务”分解成上述两类之后，需要补充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。,(4) 标明重数下图是经上述分析过程之后得出的ATM系统原始的类图。,图2 银行网络系统的初始对象类图,总行,分行,帐户,储户,中央计算机,ATM,远程事务,分行计算机,柜员,现金卡,柜员终端,柜员事务,通信,通信,拥有,拥有,拥有,雇佣,涉及,涉及,访问,授权,拥有,拥有,拥有,组成,录入,输入,输入,在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。在开发很小的系统时，可能根本无须引入主题层；对于含有较多对象的系统，则往往先识别出类与对象和关联，然后划分主题，并用它作为指导开发者和用户观察整个模型的一种机制；对于规模极大的系统，则首先由高级分析员粗略地识别对象和关联，然后初步划分主题，经进一步分析，对系统结构有更深入的了解之后，再进一步修改和精炼主题。,3.划分主题,应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题。以ATM系统为例，可以把它划分成总行（包含总行和中央计算机这两个类）、分行（包含分行、分行计算机、柜员终端、柜员事务、柜员和账户等类）和ATM（包含ATM、远程事务、现金兑换卡和储户等类）等3个主题。事实上，我们描述的是一个简化的ATM系统，为了简单起见，在下面讨论这个例子时将忽略主题层。,属性是对象的性质，藉助于属性我们能对类与对象和结构有更深入更具体的认识。注意，在分析阶段不要用属性来表示对象间的关系，使用关联能够表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。一般说来，确定属性的过程包括分析和选择两个步骤：1）分析通常，在需求陈述中用名词词组表示属性。,4.确定属性,属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属性。,确定类属性,图3 银行网络系统的部分属性,雇员号,站代码,分行,名字,帐户号,卡片码,中央计算机,银行码,站代码,2）选择认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。通常有以下几种常见情况：,(1) 误把对象当作属性例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。（2）误把关联类的属性当作一般对象的属性如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。（3） 把限定误当成属性正确使用限定词往往可以减少关联的重数。如果把某个属性值固定下来以后能减少关联的重数，则应该考虑把这个属性重新表述成一个限定词。在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。,(4) 误把内部状态当成了属性如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。(5) 过于细化在分析阶段应该忽略那些对大多数操作都没有影响的属性。(6) 存在不一致的属性类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。,可以使用两种方式建立继承(即泛化)关系：自底向上： 抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”泛化出父类“输入站”。自顶向下： 把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。从应用域中常常能明显看出应该做的自顶向下的具体化工作。,5.识别继承关系,图4,使用继承来细化类,仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改。由于面向对象的概念和符号在整个开发过程中都是一致的，因此远比使用结构分析、设计技术更容易实现反复修改、逐步完善的过程。实际上，有些细化工作(例如，定义服务)是在建立了动态模型和功能模型之后才进行的。,下面以ATM系统为例，讨论可能做的修改：1） 分解“现金兑换卡”类实际上，“现金兑换卡”有两个相对独立的功能，它既是鉴别储户使用ATM的权限的卡，又是ATM获得分行代码和卡号等数据的数据载体。因此，把“现金兑换卡”类分解为“卡权限”和“现金兑换卡”两个类，将使每个类的功能更单一：前一个类标志储户访问账户的权限，后一个类是含有分行代码和卡号的数据载体。多张现金兑换卡可能对应着相同的访问权限。,6.反复修改,2）“事务”由“更新”组成通常，一个事务包含对账户的若干次更新，这里所说的更新，指的是对账户所做的一个动作(取款、存款或查询)。“更新”虽然代表一个动作，但是它有自己的属性(类型、金额等)，应该独立存在，因此应该把它作为类。3） 把“分行”与“分行计算机”合并区分“分行”与“分行计算机”，对于分析这个系统来说，并没有多大意义，为简单起见，应该把它们合并。类似地，应该合并“总行”和“中央计算机”。,图5,完善对象模型,图5 修改后的对象模型,建立动态模型的步骤：第一步：编写典型交互行为的脚本。第二步：从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步：排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系并用状态图描绘它们。最后：比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。,建立动态模型,所谓“脚本”，原意是指“表演戏曲、话剧，拍摄电影、电视剧等所依据的本子，里面记载台词、故事情节等”。在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性的和清晰性。,1.编写脚本,脚本描写的范围并不是固定的，既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。在编写脚本的过程中，需要与用户充分交换意见，编写后还应该经过他们审查与修改。编写脚本时，首先编写正常情况的脚本。然后，考虑特殊情况，例如输入或输出的数据为最大值(或最小值)。最后，考虑出错情况。脚本描述事件序列。对于每个事件，都应该指明触发该事件的动作对象(例如，系统、用户或其他外部事物)、接受事件的目标对象以及该事件的参数。,自动取款机与用户交互的正常的脚本如下所示： 自动取款机请求储户插入卡片；用户插入现金卡。自动取款机接受卡片并读出它的卡号。 自动取款机要求密码，用户键入密码“4011”。 自动取款机与总行确认卡号和密码；分行检查它并通知承兑的自动取款机。自动取款机要求选择事务类型（取款、存款、转户及查询），储户选择取款。自动取款机要求现金数量；储户输入￥100。自动取款机要求总行处理事务；总行把要求转给分行，确认事务成功。自动取款机分发现金并且要求储户取现金；储户取现金。自动取款机提示储户是否想继续；储户指出不继续。自动取款机打印收据，退出卡，并请求储户取出它们；储户拿走收据和卡。自动取款机请求储户插入。, 自动取款机请求储户插入卡；储户插入现金卡。 自动取款机接受卡并读它的卡号。 自动取款机要求密码；储户键入：9999：。 自动取款机与总行确认卡号和密码，在咨询分行后拒绝它。 自动取款机指示密码错并要求重新键入；储户键入：4011：，总行确认成功。 自动取款机请求储户选择事务类型；储户选择取款。 自动取款机请求键入现金数量；储户改变选择并键入“CANCEL”（取消）。 自动取款机退出卡并且请求储户拿走卡；储户取出卡。 自动取款机请求储户插入卡。,自动取款机与用户交互的例外的脚本如下所示：,大多数交互行为都可以分为应用逻辑和用户界面两部分。通常，系统分析员首先集中精力考虑系统的信息流和控制流，而不是首先考虑用户界面。事实上，采用不同界面(例如，命令行或图形用户界面)，可以实现同样的程序逻辑。应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。动态模型着重表示应用系统的控制逻辑。,2.设想用户界面,不经过实际使用很难评价一个用户界面的优劣，因此，软件开发人员往往快速地建立起用户界面的原型，供用户试用与评价。下图是初步设想出的ATM界面格式。,完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。为此首先需要进一步明确事件及事件与对象的关系。,3.画事件跟踪图,1）确定事件应该仔细分析每个脚本，以便从中提取出所有外部事件。事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等。从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏了异常事件和出错条件。传递信息的对象的动作也是事件。例如，储户插入现金兑换卡、储户输入密码、ATM吐出现金等都是事件。大多数对象到对象的交互行为都对应着事件。,应该把对控制流产生相同效果的那些事件组合在一起作为一类事件，并给它们取一个惟一的名字。例如，“吐出现金”是一个事件类，尽管这类事件中的每个个别事件的参数值不同(吐出的现金数额不同)，然而这并不影响控制流。但是，应该把对控制流有不同影响的那些事件区分开来，不要误把它们组合在一起。例如“账户有效”、“账户无效”、“密码错”等都是不同的事件。经过分析，应该区分出每类事件的发送对象和接受对象。一类事件相对它的发送对象来说是输出事件，但是相对它的接受对象来说则是输入事件。有时一个对象把事件发送给自己，在这种情况下，该事件既是输出事件又是输入事件。,2）画出事件跟踪图从脚本中提取出各类事件并确定了每类事件的发送对象和接受对象之后，就可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。事件跟踪图实质上是扩充的脚本，可以认为事件跟踪图是简化的UML顺序图。在事件跟踪图中，一条竖线代表一个对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。时间从上向下递增，也就是说，画在最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生。箭头线之间的间距并没有具体含义，图中仅用箭头线在垂直方向上的相对位置表示事件发生的先后，并不表示两个事件之间的精确时间差。,退出,图7系统的事件图,自动取款机的事件流图,图7 银行网络系统的事件图,用户,分行,ATM,总行,确认卡及银行，处理银行事务,分行事务成功、失败，分行帐户正确,事务成功、事务失败、帐户正确、不正确帐户、密码、银行代码,插入卡，输入密码，类型，取现金，取卡,不显示主屏可读卡,要求密码、类型、数量,取消信息，分发现金，要求继续，不正确帐户信息,确认帐户处理事务,状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件。由事件引起的状态改变称为“转换”。如果一个事件并不引起当前状态发生转换，则可忽略这个事件。通常，用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。系统分析员应该集中精力仅考虑具有重要交互行为的那些类。从一张事件跟踪图出发画状态图时，应该集中精力仅考虑影响一类对象的事件，也就是说，仅考虑事件跟踪图中指向某条竖线的那些箭头线。,4.画状态图,根据一张事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中。为此需在事件跟踪图中找出以前考虑过的脚本的分支点(例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”)，然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。考虑完正常事件之后再考虑边界情况和特殊情况，其中包括在不适当时候发生的事件(例如，系统正在处理某个事务时，用户要求取消该事务)。,当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。利用这张状态图可能会发现一些遗漏的情况。测试完整性和出错处理能力的最好方法，是设想各种可能出现的情况，多问几个“如果，则”的问题。以ATM系统为例。“ATM”、“柜员终端”、“总行”和“分行”都是主动对象，它们相互发送事件；而“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。“储户”和“柜员”虽然也是动作对象，但是，它们都是系统外部的因素，无须在系统内实现它们。因此，只需要考虑“ATM”、“总行”、“柜员终端”和“分行”的状态图。,为重要的类建立状态图,图9分行类的状态图,各个类的状态图通过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重要交互行为的类的状态图之后，应该检查系统级的完整性和一致性。对于没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互序列的起点也不是终点，则发现了一个错误。应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。,5.审查动态模型,功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。通常在建立了对象模型和动态模型之后再建立功能模型。,建立功能模型,、确定输入、输出值先列出输入、输出值，输入输出值是系统与外部世界之间的事件的参数。检测问题陈述，从中找出遗漏的所有输入输出值。由于所有系统与外部世界之间的交互都经过自动出纳机，因而所有输入输出值都是自动出纳机事件的参数。图给出了自动出纳机的输入输出值。,自动出纳机顶层数据流图,2、建立数据流图,数据流图说明输出值是怎样从输入值 得来的，数据流图通常按层次组织。最顶层由单个处理组成，也可由收集输入、计算值及生成结果的一个综合处理构成。图给出自动出纳机顶层数据流图。将顶层图中的处理扩展成更低层次的数据流图，如果第二层次图中的处理仍包含一些可细化的处理，它们还可继续扩展，图13是图12中“执行事务”处理的扩展。,图12 自动取款机顶层数据流图,现金卡,储户,读输入,执行事务,产生输出,帐户,结算,银行码,卡码,密码,数量,事务类型,现金,收据,信息,帐户类型,图13 自动出纳机“执行事务”数据流图,“执行事务”加工的分解,3、描述处理,当数据流图已细化到一定程度后，对各处理进行描述，描述方法用自然语言、伪码及判定树等，描述可以是说明的或过程的。说明性描述确定了输入、输出值之间的关系。说明性描述优于过程性描述，因为它隐含实现的考虑。过程性描述确定一个算法来实现处理功能，算法只是用来确定处理干什么。过程性描述实现起来较为容易。下面给出“更新帐户”处理的描述：,IF 取款数目超过当前帐户结算， 退出事务，不发现金 IF 取款数目不超过当前帐户结算， 记帐并分发要求的现金 IF 事务是存款， 建立帐户并无现金分发 IF 事务是状态请求， 无现金分发 在任何情况 收据显示自动取款机编号、日期、时间、帐户编号， 事务类型，数量（若有）以及新的结算。,“对象”是由描述其属性的数据，及可以对这些数据施加的操作(即服务)，封装在一起构成的独立单元。因此，为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地描述了每个类中应该提供哪些服务。在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。,定义服务,1. 常规行为在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。但是，通常无需在类图中显式表示这些常规操作。,2. 从事件导出的操作状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须有由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。例如，在ATM系统中，发往ATM对象的事件“中止”，启动该对象的服务“打印账单”；发行分行的事件“请分行验卡”启动该对象的服务“验证卡号”；而事件“处理分行事务”启动分行对象的服务“更新账户”。可以看出，所启动的这些服务通常就是接受事件的对象在相应状态的行为。,3. 与数据流图中处理框对应的操作数据流图中的每个处理框都与一个对象(也可能是若干个对象)上的操作相对应。应该仔细对照状态图和数据流图，以便更正确地确定对象应该提供的服务。例如，在ATM系统中，从状态图上看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡”，根据实际应该完成的功能看，该对象提供的这个服务应该是“验卡”。,4. 利用继承减少冗余操作应该尽量利用继承机制以减少所需定义的服务数目。只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。,