uml建模语言及工具(李妮娅)umlVIP

UML建模语言及工具,第四章用例分析技术Use-CaseAnalysis,-3-,Review:Use-CaseModeling,基于用例的需求获取过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包,-4-,学习线路图,第二章,第三章,第四章,-5-,本章目录,4.1面向对象分析设计过程4.2面向对象分析基础4.3面向对象分析原则4.4开始分析之前4.5用例分析技术,-6-,4.1面向对象分析设计过程,IBMRUPRUP中的分析和设计工作流分析阶段的主要工作从需求到分析的工作输出转化,-7-,IBMRUP,-8-,RUP中的分析和设计工作流,分析Analysis,设计Design,软件构架文档,用例实现规约,-9-,分析阶段主要工件,逻辑视图：分析(概念)模型体系结构包图,-10-,AnalysisandDesignOverview,-11-,本章目录,4.1面向对象分析设计过程4.2面向对象分析基础4.3面向对象分析原则4.4开始分析之前4.5用例分析技术,-12-,4.2面向对象分析基础,OOA目标从需求到分析的工作输出转化OOA与用例模型分析模型与用例模型从用例开始分析风险分析重要性分析适合性分析,-13-,OOA目标,开发一系列模型，以描述计算机软件，从而满足客户定义的需求：分析模型包括两种图，描述对象及其交互这些图按照用例模型来组织，每个用例图都会产生数张图类图（classdiagram）：描述了构成一类对象特征的状态和行为（描述软件架构）交互图（interactiondiagram）：描述对象之间的交互行为（描述系统行为）,-14-,从需求到分析,Analysisworkflow,AnalysisClass,-15-,OOA与用例模型,分析是建立在需求收集的基础上分析模型建立在用例模型的基础上用例模型确定了分析模型的结构（通过用例来组织分析模型）用户视角理解用户问题过渡到开发团队视角分析用户问题与需求一样，它还是在问题域中用例分析也是分析的一个阶段，而OOA是分析的后期阶段，从这个阶段开始，我们从用户域跨入开发团队域分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析,-16-,分析模型与用例模型,用例：外观,类图：内部机理,-17-,如何开始？,从用例开始！,-18-,从用例开始-1,根据高层用例图和文档来确认需求定义是可靠的、一致的可靠的每个用例都包含对正常事件流和异常事件流的描述存在备选事件流、异常事件流的描述完备的如果在分析过程中发现一些新的用例，说明需求是不完备的，此时应对用例进行重构在分析过程中，还有可能精化对每一个用例的理解,-19-,从用例开始-2,根据风险、重要性以及项目组的能力确定用例的优先级：用例分级风险重要性团队能力以及团队建设等在迭代开发中，通过一次全面的需求收集来获得所有的用例；之后找出一个用例集，开发一个符合这些需求的最小系统，完成一次迭代过程；在此基础上，进行后续的增量开发过程,相对来说，策划一系列的小胜利和接受一些小的失误总要好一点。策划一个巨大的胜利经常会导致灾难性的失败！,-20-,从用例开始-风险分析-1,项目本身风险（risk）：项目的风险清单无法接受的系统性能无法应付新的需求不确定的进度以及开发周期无法接受的用户界面,-21-,从用例开始-风险分析-2,团队解决问题的能力：结合团队能力分析用例风险，即团队是否有能力解决用例中的问题1-当然可以，我们的项目团队以前解决过这种问题2-没问题，我们机构以前解决过这种问题3-可以采用第三方提供的产品、培训、书或者其他的技术资料，但我们内部没有任何经验4-可能吧，我们听过类似的可以解决的问题5-我们希望可以，但我们得作一些开创性的工作,-22-,从用例开始-重要性,对用户以及架构的重要性（significance）一个重要的用例应该能够体现系统的特性和目标；其他的用例可能很重要，但只是扮演支持的角色；评估用例的重要性1-用户几乎不注意用例的存在，在没有它的情况下系统不会有什么影响2-用户注意用例的存在，但稍加想象，系统仍然可以很好的使用3-系统的大部分可以独立于这个用例4-系统的一部分可以独立于这个用例5-没有它，就不可能使用这个系统,-23-,用例图：考勤卡系统,体现系统的特性和目标,扮演重要的支持的角色,-24-,从用例开始-其它问题,合适性（suitability）：这个用例是否适合你的团队1-这个团队绝对需要一段培训时间来开发这个用例2-对于这个用例来说，团队可能有足够的能力，但是在一次迭代之后，团队的能力将需要有本质的提高3-团队可能有了足够的能力，但在一次迭代之后这个能力不需要怎么提高4-不需要很多的培训，要么是团队的能力已经绰绰有余，要么是这个用例相当简单5-不需要很多的培训，团队有足够的经验，用例也很简单，手到擒来,-25-,建立第一个迭代周期,1-风险2-重要性3-合适性,-26-,本章目录,4.1面向对象分析设计过程4.2面向对象分析基础4.3面向对象分析原则4.4开始分析之前4.5用例分析技术,-27-,分析的基本原则,把分析限制在问题域词汇的那部分类,保持分析模型是一个对系统结构和行为的精确和简单陈述,-28-,经验法则-1,分析模型总是使用业务语言分析模型中的抽象应该是业务领域词汇的部分创建“讲故事”的模型每幅产生的图应该阐明系统期望行为的一些重要部分注重于捕获大的场面不限于系统将如何工作的细节（这是设计的工作）清晰地区分问题域（业务需求）和解域（详细的设计考虑）总是关注存在于问题域的抽象,-29-,经验法则-2,总是尽力最小化耦合类之间的每个关联都是在它们之间建立耦合继承关系继承是类间耦合的最强形式如果看起来存在自然的、强迫的抽象层次，则可探索继承关系分析中，永远不要仅为了复用代码而使用继承“该模型对所有项目干系人有用吗？”,保持模型简单！,-30-,本章目录,4.1面向对象分析设计过程4.2面向对象分析基础4.3面向对象分析原则4.4开始分析之前4.5用例分析技术,-31-,4.4开始分析之前,RUP中的“定义备选构架”经典三层构架多层体系结构的动机MVC架构,-32-,开始分析之前：定义备选构架,RUP中的“定义备选构架”创建系统构架的初始草图初步定义一组在构架方面具有重要意义的元素，以用作分析的基础初步定义一组分析机制初步定义系统的分层与组织定义要在当前迭代中处理的用例实现从在构架方面具有重要意义的用例中确定分析类通过分析类交互来更新用例实现,-33-,经典的三层构架,数据库,记录销售信息,支付授权,表示层,应用逻辑层,存储层,-34-,多层体系结构的动机,将应用逻辑作为单独的构件从系统中分离出来，以便这些构件在其他系统中能得到重用将各个层次分配到各个不同的物理计算节点，或者分配给不同的进程。这样可以改善系统性能、更好地支持客户和服务器系统中的信息共享和协调将不同层的开发任务在开发者之间适当地分配，这可以有效地利用开发人员的专长和开发技巧，并且能够提高并行开发能力,-35-,模型视图控制器构架MVC,模型，即相关的数据，它是对象的内在属性视图是模型的外在表现形式，一个模型可以对应一个或者多个视图，视图还具有与外界交互的功能控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息转化成相应事件，然后由对应的控制器对模型进行更新；相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性,-36-,MVC备选构架示意图,-37-,本章目录,4.1面向对象分析设计过程4.2面向对象分析基础4.3面向对象分析原则4.4开始分析之前4.5用例分析技术,-38-,4.5用例分析技术,4.5.1分析类概述4.5.2用例分析过程1.寻找候选对象2.描述对象间的交互3.描述类4.5.3分析模型的检验,-39-,4.5.1分析类概述,分析类概念分析类划分一个手表的例子分析类的图形表示,-40-,“分析类”概念,“分析类”是概念层的内容，从它们可捕获系统对象模型的雏形；“分析类”相当粗略，并且不要往其中添加技术细节。,-41-,“分析类”划分,划分原则：要尽量减小需求变化的影响“高内聚、低耦合”。实体类：系统要记录和维护的信息；边界类：系统和外部要素间交互的边界；控制类：UseCase中行为的协调；,-42-,“分析类”的例子：手表,时、分、秒是实体类；按钮和液晶屏是边界类；改变日期是控制类，代表通过组合按钮改变时间的活动；,-43-,“分析类”的表示,可以用构造型表示：、；也可以用特殊图示表示：,-44-,4.5用例分析技术,4.5.1分析类概述4.5.2用例分析过程1.寻找候选对象2.描述对象间的交互3.描述类4.5.3分析模型的检验,-45-,用例分析过程,用例分析技术是一种面向对象的分析方法用例分析技术是基于用例的，在每一次迭代中针对每一个用例：1.寻找候选对象对象清单(提取分析类)2.描述对象间的交互交互图/顺序图(转述UseCase)3.描述类类图(整理分析类),-46-,1.寻找候选对象,(提取分析类)寻找用于解决某个用例的一组对象寻找对象的准则准则1：限制职责准则2：采用清楚一致的命名准则3：保持简单寻找对象的步骤(MVC构架)步骤1：实体对象（Entity）步骤2：边界对象（Boundary）步骤3：控制对象（Control）,-47-,（一）寻找对象的准则,准则1：限制职责限制每一个分析类（analysisclass）的职责准则2：采用清楚一致的命名对类和方法采用一致的命名准则3：保持简单保持分析类的简单,-48-,准则1：限制职责,SRP（TheSingleResponsibilityPrinciple）：就一个类而言，应该仅有一个引起它变化的原因是否每一个类都有一个清楚的目标？是否可以用一个文本段落清楚地描述这个目标？是否每一个方法都符合这个类的职责？,-49-,准则2：采用清楚一致的命名,类的名字和职责必须是清楚的和明确的类和方法的清晰的命名可以让其他开发人员和相关人员理解并验证分析模型，并可以捕获其中的误解和错误，避免其发展到足以威胁项目的成功的地步对象命名检查表（checklist-1）,-50-,对象命名检查表checklist-1,对于每一个类的名字是否是一个名词？对那些对系统不怎么熟悉的人来说，每一个类及其方法的名字是否都是明确的？你是否为了得到一个能将意思描述清楚的名词而采用诸如“manager”之类的无意义的补白？每一个方法的名字是否是一个动词或动词与名词的组合短语？,-51-,准则3：保持简单,分析只是对高层次解决方案的第一次尝试不要试图去确定对象之间的关系不要命名角色或者创建详细的继承层次没必要花太多的时间来使你的第一稿草案看起来很完美发现一些对象，评审一下这些结果，然后在寻找对象行为的时候再来确定它的细节,-52-,（二）寻找对象的步骤（MVC构架）,步骤1：实体对象（Entity）步骤2：边界对象（Boundary）步骤3：控制对象（Control）,寻找三种对象的过程同时也就确定了相应的分析类。,-53-,步骤1：实体对象,实体对象（entityobject）对系统的业务数据和业务逻辑进行封装解决问题所需要的全部数据和行为，然后将这些数据按相关性分组识别出重要的名词，并将它们作为实体对象，之后确定每一个实体对象包含的数据和行为识别实体对象检查表（checklist-2）,-54-,识别实体对象检查表checklist-2,实体对象是否是某个问题中的重要名词？实体对象是否包含用来解决系统问题的重要的信息？实体对象是否包含可以解决系统问题的计算或验证逻辑？那些了解这个系统目标的专家是否会理解这些实体对象？,-55-,检查表构造思路,过滤需求文档中的名词，列出名词表，然后对表中名词逐个判断剔除不需要的和重复的实体对象；判断有些名词是否不适合作为一个独立的对象，而更应该作为一个属性,-56-,寻找实体对象示例1：RecordTime,正常事件流：雇员查看当前时间段之前输入的数据；雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；雇员从当前的时间段选择一个日期；雇员输入以正整数表示的工时；系统在视图中显示这个数据，并在以后的视图中看到这个数据。备选事件流1：雇员更改他的时间雇员查看当前时间之前输入的数据；雇员选择一个已有的条目；雇员改变工时和/或支付号码；在视图中更新这个信息，并在以后的视图中都可以看到。备选事件流1：雇员提交考勤卡,-57-,名词分析,收费项目代码支付号码同义词，前者更为常用，因此舍弃后者。客户实体对象日期更像是对象中的数据雇员实体对象已有的条目可能保存日期，暂列为实体对象。,时间数工时工时更有意义，是条目中的一个数据以前输入的数据即条目，舍弃该词项目考勤卡实体对象时间段考勤卡对象的数据视图边界对象,雇员已有条目收费项目代码客户项目工时考勤卡,-58-,检查实体对象,客户项目收费项目代码雇员考勤卡工时已有条目,-59-,步骤2：边界对象,边界对象（boundaryobject）描述系统将如何用参与者交互通过检查在用例图中的参与者与用例之间的关系，可以识别出边界对象在分析模型中，每一对参与者/用例都构成了一个边界对象边界对象可分为两种：用户界面：允许系统与人交互系统接口：允许系统与其他系统交互识别边界对象检查表（checklist-3）,-60-,标识边界对象的试探法,确定用户需要将数据输入系统的窗口或表格；确定系统对用户的响应或消息；不要用边界对象对界面的可视方面建模（用户模型更适于做这件事）；总是使用用户的术语而不是实现技术的术语来描述界面。,-61-,标识边界对象的试探法,一个用例中，每个Actor至少与一个边界对象进行交互；边界对象从Actor收集信息，并将这些信息存入一张与接口无关的表格，该表格可被实体对象或控制对象使用；注意，系统对用户的响应或消息是一类边界对象；,-62-,寻找边界对象示例,-63-,识别边界对象检查表checklist-3,用户界面类是否描述了必须显示的信息以及必须提供的服务？用户界面类是否可以推迟所有的接口设计细节？系统接口是否描述了与外部系统的交互？系统接口是否推迟所有的协议细节？,-64-,步骤3：控制对象,控制对象（controlobject）为其他对象提供工作流和会话服务在边界对象访问实体对象的时候，控制对象将一系列复杂的请求封装成通用的工作流，使这种访问变得简单从边界对象发出的高级的消息将被转换成一系列从控制对象发往实体对象的消息通常，每一个用例都应该有一种控制对象识别控制对象检查表（checklist-4）,-65-,标识控制对象的试探法,为每个UseCase标识一个控制对象，如果UseCase比较复杂并且能分解成更短的事件流，则为该UseCase标识多个控制对象；为UseCase中的每个Actor标识一个控制对象；一个控制对象的生命周期应该是对应UseCase的范围或一个用户界面的范围。如果很难确定一个控制对象活动的开始和结束，则表明对应的UseCase可能没有一个明确定义的入口和退出条件。,-66-,寻找控制对象示例,-67-,识别控制对象检查表checklist-4,控制对象是否对用例的作用或者工作流逻辑进行建模？控制对象是否将真正的业务逻辑提交给实体对象？,-68-,用例分析过程,用例分析技术是一种面向对象的分析方法用例分析技术是基于用例的，在每一次迭代中针对每一个用例：1.寻找候选对象对象清单(提取分析类)2.描述对象间的交互交互图/顺序图(转述UseCase)3.描述类类图(整理分析类),-69-,2.描述对象间的交互,描述对象间的交互，从而寻找对象行为寻找对象行为的准则确保方法之间的内聚性采用清楚明确的方法名完全满足用例要求保持简单描述行为的步骤将已识别的参与对象加到顺序图中从参与者开始，一步步寻找行为验证行为序列,-70-,描述行为要用到的两种表达形式,（一）描述行为检查表（二）顺序图,-71-,（一）描述行为检查表checklist-6,是否每一个方法都有清楚的目标？是否每一个方法的命名都是名词和动词的强组合？是否避免采用模棱两可的名字？是否从调用对象的角度来清楚地命名每一个方法？对其他开发人员来说，这些名字是否是明确的？方法的名字是否表明了它的返回类型？在每一个类中的方法，它们之间是否存在密切关系？是否每一个类中的方法都符合这个类所声明的职责？是否每一个类仍然还保持一个具体的目标？,-72-,（二）顺序图SequenceDiagram,顺序图组成回顾顺序图的试探画法典型的顺序图对象布局两个顺序图示例顺序图推荐的使用场合基于用例建立顺序图的步骤两个基于用例分析的顺序图建立示例,-73-,顺序图组成回顾,描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序对象（Object）：对象、对象的生命线、激活的对象和对象的删除消息（Message）：简单消息、同步消息、异步消息、返回消息条件（Condition）、注释体和注释连接,-74-,顺序图的试探画法,第一列对应UseCase的主动Actor；第二列是主动Actor对应的边界对象；第三列是管理UseCase剩余部分的控制对象；控制对象由初始化UseCase的边界对象来创建；边界对象被控制对象创建；实体对象被控制对象和边界对象访问；实体对象从不去访问控制对象和边界对象。,-75-,典型的顺序图对象布局,顺序图明确了对象的“职责”应该响应的消息；,-76-,顺序图示例1,正常事件流：雇员查看当前时间段之前输入的数据；雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；雇员从当前的时间段选择一个日期；雇员输入以正整数表示的工时；系统在视图中显示这个数据，并在以后的视图中看到这个数据。,-77-,正常事件流顺序图,-78-,备选事件流：雇员提交考勤卡雇员看到当前时间段之前输入的数据；雇员选择提交考勤卡；系统要求雇员确认他的选择，并提醒他将不能再编辑这些条目；考勤卡被提交，再也不能对它进行编辑。,-79-,备选事件流顺序图,-80-,顺序图推荐的使用场合,顺序图是一种交互图，交互图主要用于描述对象之间的动态协作关系（协作图）以及协作过程中的行为次序（顺序图）常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况,-81-,认真分析用例所完成的功能；识别为完成用例的功能，用例叙述的事件流;分析人机交互过程；识别参与交互过程的相关对象;,基于用例建立顺序图的步骤,从引发交互的初始消息开始,在对象生命线上依次画出交互的消息;,画出顺序图。,-82-,示例1：绘制酒店订房管理“会员登录”的顺序图,-83-,认真分析用例所完成的功能；,-84-,功能:会员登录系统。,-85-,参与者：会员,酒店经营者事件流：会员输入电子邮件地址和密码。系统确认会员身份后，出现欢迎信息。替代事件流：*数据不完整：客户端提醒会员填入数据，直到数据完整才传送给服务器端。*验证失败：累计5次登录失败，既锁定，并出现请会员主动联系系统管理员的信息业务规则：BR1：以会员电子邮件作为会员代号BR2：会员累计5次登录失败，即锁定该会员账号。只要登录成功，则失败次数归零。,识别为完成用例的功能，用例叙述的事件流;,-86-,识别参与交互过程的对象；,-87-,从引发交互的初始消息开始,在对象生命线上依次画出交互的消息绘制顺序图,-88-,酒店预订管理会员登录顺序图,-89-,示例2：绘制图书馆“借书”的顺序图,-90-,认真分析用例所完成的功能；,-91-,功能:读者凭自己的借书证在图书馆借书。,-92-,参与者：管理员,借阅者事件流：管理员进入图书借阅界面，用例开始。系统要求输入借阅者的借书证编码。系统检验借书证编码,如果正确,则显示借阅者的信息。A1：借书证编码有错。A2:如果该借阅者所借图书已经超期,则提示,本次拒借.系统要求输入所借图书的条码。系统显示所借图书的信息。确认借书。,识别为完成用例的功能，用例叙述的事件流;,-93-,分析人机交互过程；,图书馆借书处理的活动图,-94-,识别参与交互过程的对象；,-95-,从引发交互的初始消息开始,在对象生命线上依次画出交互的消息绘制顺序图,-96-,-97-,用例分析过程,用例分析技术是一种面向对象的分析方法用例分析技术是基于用例的，在每一次迭代中针对每一个用例：1.寻找候选对象对象清单(提取分析类)2.描述对象间的交互交互图/顺序图(转述UseCase)3.描述类类图(整理分析类),描述类的过程也是整理分析类的过程，即确定类的属性、方法，以及类之间的关系，并画出类图。,-98-,3.描述类,顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系描述类的准则完整保持简单维持类的一致性描述类的步骤将对象的行为合并到类中重构类，使其符合规则发现类之间的关系完成该用例“参与类类图”（VOPC,ViewofParticipatingClassesClassDiagram）,-99-,“参与类类图”的含义,“分析类”具有某一特定的“职责”和“属性”。“分析类”之间的关联关系所涉及的范围则不局限于某一个“分析类”。“参与类类图”是表述这些关联关系的方式。“参与类类图”中包含一组类和它们之间的关系，这组类参与特定用例的动态交互内容，即特定用例的交互图组所反映的内容。“参与类类图”的主要目的是从用例中挖掘出参与类间的关系。,-100-,从顺序图到类图,（一）从动态图到静态图（二）确定“分析类”的职责（三）确定“分析类”间的关联关系（四）确定“分析类”的属性,-101-,（一）从动态图到静态图,“分析类”的一条职责有可能响应多条消息；“分析类”间的关联关系有可能为多条消息提供传递路径；动态图一点一滴地为静态图收集着素材，而静态图则是动态图的综合和结晶；系统在这个从动态到静态的过程中不断充实；这种过程一般需要选择某种辅助建模工具软件来支撑，否则不易实用。,-102-,（二）确定“分析类”的职责,“职责”是“分析类”实例响应消息并完成特定任务的能力，包括为外部（其他对象）提供必要的服务和维护自身的信息。职责在后续的设计活动中将演化为“设计类”的一个或多个操作。确定“分析类”的职责，主要包括两个动作：,-103-,第一步，找出“职责”。鉴于“职责”和“消息”的简明对应关系，转述UseCase或场景的过程既是用“消息”分解和转述需求的过程，也是找出“职责”的过程；“消息”和“职责”并不是一回事，所谓找出“职责”是根据“消息”的要求定义“职责”，即用“职责”满足“消息”提出的要求；不需要针对每一条消息定义一个新的职责，很多时候，利用已有的职责即可满足消息的要求；,（二）确定“分析类”的职责,-104-,第二步，简要描述“职责”。为了获得简明的图示，“职责”的名称通常比较简短，“职责”的实例将取代“消息”出现在顺序图或协作图中。建议给“职责”附加简要的文字说明，描述该“职责”可能对应的操作逻辑以及该“职责”被调用之后将返回何种结果。,（二）确定“分析类”的职责,-105-,（三）确定“分析类”间的关联关系,“分析类”之间的关联关系通过参与类图（VOPC）直观地表达出来。确定“分析类”之间的关联关系，主要有两步：首先，建立VOPC，将所有“参与”该用例的“分析类”添加到该类图中。一般情况下，根据该用例的基本事件流的交互图（协作图），已可获得大部分（甚至是全部）的“参与类”；然后，确定关联关系。协作图中对象之间的“连接”是VOPC中相应“分析类”之间关联关系的动态表现形式；,-106-,RecordTime用例中类的关系,-107-,（四）确定“分析类”的属性,属性是“分析类”的基本内容，属性的取值使得“分析类”的实例具有必要的“知识”，从而履行其承担的“职责”。在分析阶段的任务中，确定属性的工作主要围绕实体类展开，也包括两个动作：,-108-,首先，找出属性。属性的基本来源是用例的事件流描述，并通过“分析类”的职责来间接地获取。如果对“分析类”的“职责”的简要描述比较明确，属性比较容易获取；然后简要描述属性。属性名称应当是一个简短的名词，说明其保存的信息。分析活动中，属性应该是粗线条的，通常没必要在属性的数据类型和相关细节上耗费过多精力。为了使模型易于理解和沿用，通常建议给含义相对复杂的属性附加必要的上下文说明。,（四）确定“分析类”的属性,-109-,4.5用例分析技术,4.5.1分析类概述4.5.2用例分析过程1.寻找候选对象2.描述对象间的交互3.描述类4.5.3分析模型的检验,-110-,4.5.3分析模型的检验,分析模型的检验思想实体对象检验边界对象检验控制对象检验类与属性的差异性检验类与属性的转换检验类关系检验继承关系检验分析检验总结,-111-,分析模型的检验思想,分析模型用渐进循环方式构建。在第一次构建中，分析模型很少是正确的，甚至是不完整的；在分析模型形成一个正确的说明、从而能被用来进行后面的设计和实现之前，与客户和用户间的多次循环是必要的；一旦分析模型变得稳定，应该首先由开发人员检查它，然后是开发方与客户的联合检查。检查针对的目标就是确保需求说明的几种特性：正确性、完整性、一致性、可测试性、现实性等。,-112-,实体对象检验,标识实体对象时，要考虑到分析模型处于不断变化中，不必花费太多时间来处理对象或其属性的细节。如果它们是显而易见的，应该记录下来，否则，对每个对象进行试验性的命名和简短描述即可。然而，一旦分析模型稳定下来，每个对象的描述就应该尽可能详细。,-113-,标识边界对象时，是对用户界面的粗略建模，它并不详细描述用户界面的可见方面，那些工作应放在用户模型去做。用户界面的设计将不断演化，甚至在系统的功能性说明稳定下来以后仍会变。如果分析模型和界面的可视部分的变动互相影响，将耗费很多时间在它们间做协调。,边界对象检验,-114-,控制对象通常在现实世界没有具体的对应部分。控制对象通常在一个用例的开始被创建，当用例终止时它就不复存在。若很难确定一个控制对象活动的开始和结束，则表明对应的用例可能没有一个定义明确的入口和出口条件。,控制对象检验,-115-,注意实体类与属性的差异：类的属性和独立的实体类有所不同。但是，客观地讲，它们之间的界限并不十分清晰。在以下两种情况下，通常将特定客体（信息）建模为独立的实体类：客体具有比较复杂的自身行为；客体具有独立标识（Identification），有可能被多类对象共享或传递。相反，在以下情形，通常将特定客体建模为类的属性：客体除了非常简单的取赋值操作（set，get等），不具备更多其他行为；客体不需要独立标识，仅供一类对象使用。,类与属性的差异性检验,-116-,