uml第五课(精品).ppt
面向对象技术面向对象技术Object-Oriented TechniquesObject-Oriented Techniques谭火彬谭火彬82339316-806第第 5 5 章用例分析技术章用例分析技术Use-Case AnalysisUse-Case AnalysisReview:Use-Case Modeling基于用例的需求获取过程基于用例的需求获取过程1.获取原始需求获取原始需求2.开发一个可以理解的需求开发一个可以理解的需求2.1 识别参与者识别参与者2.2 识别用例识别用例2.3 构建用例图构建用例图3 详细、完整地描述需求详细、完整地描述需求进行用例阐述进行用例阐述4 重构用例模型重构用例模型4.1 识别用例间的关系识别用例间的关系4.2 对用例进行组织和分包对用例进行组织和分包3学习线路图学习线路图OOOOUMLUMLOOAOODDP Case-Study 学学 习习 线线 路路 图图4ReferencesArri02CT Arrington,Enterprise Java with UML（马波，李雄锋译，（马波，李雄锋译，Enterprise Java with UML中文版，机械工业出版社，中文版，机械工业出版社，2003年）年）Larm01,Craig Larman,Applying UML and Patterns,2e（姚淑珍、李虎等译，（姚淑珍、李虎等译，UML和模式应用和模式应用-面向对象分析与设计导论，机械工业出版社，面向对象分析与设计导论，机械工业出版社，2002年）年）DEV475,IBM Rational,Mastering Object-Oriented Analysis and Design with UML,2003Kruc00,Philippe Kruchten,The Rational Unified Process:An Introduction(Second Edition)（周伯生等译，（周伯生等译，Rational统一过程引论，机统一过程引论，机械工业出版社，械工业出版社，2002.5）5下一步？下一步？需求需求用例用例面向对象面向对象分析设计分析设计结构化结构化分析设计分析设计其它方法其它方法自己的自己的土方法土方法系统系统6内容安排内容安排面向对象分析设计过程面向对象分析设计过程面向对象分析基础面向对象分析基础面向对象分析原则面向对象分析原则开始分析之前开始分析之前用例分析技术用例分析技术7内容安排内容安排 面向对象分析设计过程面向对象分析设计过程面向对象分析基础面向对象分析基础面向对象分析原则面向对象分析原则开始分析之前开始分析之前用例分析技术用例分析技术8面向对象分析、设计面向对象分析、设计基于面向对象的分析和设计理论，产生基于面向对象的分析和设计理论，产生了许多开发过程实践了许多开发过程实践RUP：Ration Unified ProcessMSF：Microsoft Solution FrameworkALM：Application Lifecycle Manage9IBM RUP10RUP中的分析和设计工作流中的分析和设计工作流分分分分 析析析析AnalysisAnalysis设设设设 计计计计DesignDesign软件构架文档软件构架文档软件构架文档软件构架文档用例实现规约用例实现规约用例实现规约用例实现规约11分析阶段主要工件分析阶段主要工件用例视图用例视图用例视图用例视图：用例模型用例模型用例模型用例模型用例实现用例实现用例实现用例实现(分析分析分析分析):逻辑视图逻辑视图逻辑视图逻辑视图：分析分析分析分析(概念概念概念概念)模型模型模型模型体系结构包图体系结构包图体系结构包图体系结构包图12MSF13Borland ALM14内容安排内容安排面向对象分析设计过程面向对象分析设计过程 面向对象分析基础面向对象分析基础面向对象分析原则面向对象分析原则开始分析之前开始分析之前用例分析技术用例分析技术15面向对象分析面向对象分析OOA?当一个新的产品或系统将被建造时：当一个新的产品或系统将被建造时：我们如何以遵从面向对象软件工程的方式来我们如何以遵从面向对象软件工程的方式来刻画它？刻画它？是否存在我们需要问询客户的问题？是否存在我们需要问询客户的问题？什么是相关的对象？什么是相关的对象？它们如何相互关联？它们如何相互关联？对象如何在系统的语境内运转？对象如何在系统的语境内运转？我们如何刻画或建模问题域以使得我们可以我们如何刻画或建模问题域以使得我们可以创建一个有效的设计创建一个有效的设计16OOA目标目标开发一系列模型，以描述计算机软件，开发一系列模型，以描述计算机软件，从而满足客户定义的需求：从而满足客户定义的需求：分析模型分析模型包括两种图，描述对象及其交互包括两种图，描述对象及其交互这些图按照用例模型来组织，每个用例图都这些图按照用例模型来组织，每个用例图都会产生数张图会产生数张图类图（类图（class diagram）：描述了构成一类对象）：描述了构成一类对象特征的状态和行为（特征的状态和行为（描述软件架构描述软件架构描述软件架构描述软件架构）交互图（交互图（interaction diagram）：描述对象之）：描述对象之间的交互行为（间的交互行为（演示用例实现演示用例实现演示用例实现演示用例实现）（）（描述系统行为描述系统行为描述系统行为描述系统行为）17从需求到分析从需求到分析Analysis workflowAnalysis workflowAnalysis Class18OOA与用例模型与用例模型分析是建立在需求收集的基础上分析是建立在需求收集的基础上分析模型建立在用例模型的基础上分析模型建立在用例模型的基础上用例模型确定了分析模型的结构（通过用例来组织用例模型确定了分析模型的结构（通过用例来组织分析模型）分析模型）用户视角理解用户问题用户视角理解用户问题用户视角理解用户问题用户视角理解用户问题过渡到过渡到开发团队视角分析用开发团队视角分析用开发团队视角分析用开发团队视角分析用户问题户问题户问题户问题与需求一样，它还是在与需求一样，它还是在问题域问题域问题域问题域中中用例分析也是分析的一个阶段，而用例分析也是分析的一个阶段，而OOA是分析的后期阶段，是分析的后期阶段，从这个阶段开始，我们从从这个阶段开始，我们从用户域跨入开发团队域用户域跨入开发团队域用户域跨入开发团队域用户域跨入开发团队域分析与需求捕获在很大程度上重叠，这两个活动常分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析求，常常需要在需求之上作一些分析19分析模型与用例模型分析模型与用例模型用例：外观用例：外观用例：外观用例：外观类图：内部机理类图：内部机理类图：内部机理类图：内部机理20如何开始？如何开始？从从 用用 例例 开开 始！始！21从用例开始从用例开始-1根据高层用例图和文档来确认需求定义是可靠根据高层用例图和文档来确认需求定义是可靠的、一致的的、一致的可靠的可靠的每个用例都包含对正常事件流和异常事件流的描述每个用例都包含对正常事件流和异常事件流的描述存在备选事件流、异常事件流的描述存在备选事件流、异常事件流的描述完备的完备的如果在分析过程中发现一些新的用例，说明需求是不完备如果在分析过程中发现一些新的用例，说明需求是不完备的，此时应对用例进行重构的，此时应对用例进行重构在分析过程中，还有可能精化对每一个用例的理解在分析过程中，还有可能精化对每一个用例的理解22从用例开始从用例开始-2根据风险、重要性以及项目组的能力确定用例的优先根据风险、重要性以及项目组的能力确定用例的优先级：用例分级级：用例分级风险风险重要性重要性团队能力以及团队建设团队能力以及团队建设在迭代开发中，通过一次全面的需求收集来获得所有在迭代开发中，通过一次全面的需求收集来获得所有的用例；之后找出一个用例集，开发一个符合这些需的用例；之后找出一个用例集，开发一个符合这些需求的最小系统，完成一次迭代过程；在此基础上，进求的最小系统，完成一次迭代过程；在此基础上，进行后续的增量开发过程行后续的增量开发过程相对来说，策划一系列的小胜利和接受一些小的相对来说，策划一系列的小胜利和接受一些小的相对来说，策划一系列的小胜利和接受一些小的相对来说，策划一系列的小胜利和接受一些小的失误总要好一点。策划一个巨大的胜利经常会导失误总要好一点。策划一个巨大的胜利经常会导失误总要好一点。策划一个巨大的胜利经常会导失误总要好一点。策划一个巨大的胜利经常会导致灾难性的失败！致灾难性的失败！致灾难性的失败！致灾难性的失败！23用例图：考勤卡系统用例图：考勤卡系统24从用例开始从用例开始-风险分析风险分析-1项目本身风险（项目本身风险（risk）：项目的风险清单）：项目的风险清单无法接受的系统性能无法接受的系统性能无法应付新的需求无法应付新的需求不确定的进度以及开发周期不确定的进度以及开发周期无法接受的用户界面无法接受的用户界面25从用例开始从用例开始-风险分析风险分析-2团队解决问题的能力：结合团队能力分析用例团队解决问题的能力：结合团队能力分析用例风险，即团队是否有能力解决用例中的问题风险，即团队是否有能力解决用例中的问题1-当然可以，我们的项目团队以前解决过这种问题当然可以，我们的项目团队以前解决过这种问题2-没问题，我们机构以前解决过这种问题没问题，我们机构以前解决过这种问题3-可以采用第三方提供的产品、培训、书或者其他可以采用第三方提供的产品、培训、书或者其他的技术资料，但我们内部没有任何经验的技术资料，但我们内部没有任何经验4-可能吧，我们听过类似的可以解决的问题可能吧，我们听过类似的可以解决的问题5-我们希望可以，但我们得作一些开创性的工作我们希望可以，但我们得作一些开创性的工作26从用例开始从用例开始-重要性重要性对用户以及架构的重要性（对用户以及架构的重要性（significance）一个重要的用例应该能够体现系统的特性和目标；一个重要的用例应该能够体现系统的特性和目标；如：如：Record Time、Export Time Entries其他的用例可能很重要，但只是扮演支持的角色；其他的用例可能很重要，但只是扮演支持的角色；如：如：Change Password评估用例的重要性评估用例的重要性1-用户几乎不注意用例的存在，在没有它的情况下系统不用户几乎不注意用例的存在，在没有它的情况下系统不会有什么影响会有什么影响2-用户注意用例的存在，但稍加想象，系统仍然可以很好用户注意用例的存在，但稍加想象，系统仍然可以很好的使用的使用3-系统的大部分可以独立于这个用例系统的大部分可以独立于这个用例4-系统的一部分可以独立于这个用例系统的一部分可以独立于这个用例5-没有它，就不可能使用这个系统没有它，就不可能使用这个系统27从用例开始从用例开始-其它问题其它问题合适性（合适性（suitability）：这个用例是否适合你）：这个用例是否适合你的团队的团队1-这个团队绝对需要一段培训时间来开发这个用例这个团队绝对需要一段培训时间来开发这个用例2-对于这个用例来说，团队可能有足够的能力，但对于这个用例来说，团队可能有足够的能力，但是在一次迭代之后，团队的能力将需要有本质的提是在一次迭代之后，团队的能力将需要有本质的提高高3-团队可能有了足够的能力，但在一次迭代之后这团队可能有了足够的能力，但在一次迭代之后这个能力不需要怎么提高个能力不需要怎么提高4-不需要很多的培训，要么是团队的能力已经绰绰不需要很多的培训，要么是团队的能力已经绰绰有余，要么是这个用例相当简单有余，要么是这个用例相当简单5-不需要很多的培训，团队有足够的经验，用例也不需要很多的培训，团队有足够的经验，用例也很简单，手到擒来很简单，手到擒来28建立第一个迭代周期建立第一个迭代周期1-1-风险风险风险风险2-2-重要性重要性重要性重要性3-3-合适性合适性合适性合适性29内容安排内容安排面向对象分析设计过程面向对象分析设计过程面向对象分析基础面向对象分析基础 面向对象分析原则面向对象分析原则开始分析之前开始分析之前用例分析技术用例分析技术30分析的基本原则分析的基本原则把分析限制在问题域词汇的那部分类把分析限制在问题域词汇的那部分类保持分析模型是一个对系统结构和行为保持分析模型是一个对系统结构和行为的精确和简单陈述的精确和简单陈述31经验法则经验法则-1分析模型总是使用业务语言分析模型总是使用业务语言分析模型中的抽象应该是业务领域词汇的部分分析模型中的抽象应该是业务领域词汇的部分创建创建“讲故事讲故事”的模型的模型每幅产生的图应该阐明系统期望行为的一些重要部每幅产生的图应该阐明系统期望行为的一些重要部分分注重于捕获大的场面注重于捕获大的场面不限于系统将如何工作的细节（这是设计的工作）不限于系统将如何工作的细节（这是设计的工作）清晰地区分问题域（业务需求）和解域（详细清晰地区分问题域（业务需求）和解域（详细的设计考虑）的设计考虑）总是关注存在于问题域的抽象总是关注存在于问题域的抽象32经验法则经验法则-2总是尽力最小化耦合总是尽力最小化耦合类之间的每个关联都是在它们之间建立耦合类之间的每个关联都是在它们之间建立耦合继承关系继承关系继承是类间耦合的最强形式继承是类间耦合的最强形式如果看起来存在自然的、强迫的抽象层次，则可探如果看起来存在自然的、强迫的抽象层次，则可探索继承关系索继承关系分析中，永远不要仅为了复用代码而使用继承分析中，永远不要仅为了复用代码而使用继承“该模型对所有项目干系人有用吗？该模型对所有项目干系人有用吗？”保持模型简单！保持模型简单！33题外话：分析模式题外话：分析模式-1分析模式（分析模式（analysis pattern）：描述通用业）：描述通用业务务/分析问题解决方案的一种模式分析问题解决方案的一种模式例：例：“游戏者击中白球，它以一定的速度前进，并游戏者击中白球，它以一定的速度前进，并以特定的角度碰到红球，于是红球在某个特定的方以特定的角度碰到红球，于是红球在某个特定的方向上前进一段距离向上前进一段距离”除了这些表面现象，还必须了解背后的本质，那就除了这些表面现象，还必须了解背后的本质，那就是和质量有关的运动定律，速度，动量，等等。了是和质量有关的运动定律，速度，动量，等等。了解这些规律将更容易看到软件可以怎样建立解这些规律将更容易看到软件可以怎样建立我们建造应用系统的时候，需要大量的了解和研究，我们建造应用系统的时候，需要大量的了解和研究，才能接触到问题的本质才能接触到问题的本质 34分析模式分析模式-2分析模式更接近系统的概念模型，如果系统概分析模式更接近系统的概念模型，如果系统概念模型经过抽象，可以应用在多个相似的环境念模型经过抽象，可以应用在多个相似的环境中，那么，它就变成了模式中，那么，它就变成了模式在代码实现层面，我们很容易看到和理解重用在代码实现层面，我们很容易看到和理解重用的概念，从最开始的函数库，到类库，到设计的概念，从最开始的函数库，到类库，到设计模式，到应用框架，我们的对代码的重用程度模式，到应用框架，我们的对代码的重用程度越来越高越来越高在业务领域的分析层面，重用的可能性依然存在业务领域的分析层面，重用的可能性依然存在，分析模式，就是这种重用的一部分，如果在，分析模式，就是这种重用的一部分，如果我们都可以利用以往的经验，得到业务领域的我们都可以利用以往的经验，得到业务领域的通用解决方案，它们将直接影响到应用系统的通用解决方案，它们将直接影响到应用系统的设计，因而这种重用的价值将更加显著设计，因而这种重用的价值将更加显著35分析模式分析模式-3Analysis Patterns:Reusable Object ModelsMartin Fowlerhttp:/ 开始分析之前开始分析之前用例分析技术用例分析技术37开始分析之前：定义备选构架开始分析之前：定义备选构架RUP中的中的“定义备选构架定义备选构架”创建系统创建系统 构架的初始草图构架的初始草图初步定义一组在构架方面具有重要意义的元素，以用作分初步定义一组在构架方面具有重要意义的元素，以用作分析的基础析的基础初步定义一组分析机制初步定义一组分析机制初步定义系统的分层与组织初步定义系统的分层与组织定义要在当前迭代中处理的用例实现定义要在当前迭代中处理的用例实现从在构架方面具有重要意义的用例中确定分析类从在构架方面具有重要意义的用例中确定分析类通过分析类交互来更新用例实现通过分析类交互来更新用例实现38经典的三层构架经典的三层构架-1数据库数据库记录销售信息记录销售信息支付授权支付授权表示层表示层表示层表示层应用逻辑层应用逻辑层应用逻辑层应用逻辑层存储层存储层存储层存储层39多层体系结构的动机多层体系结构的动机将应用逻辑作为单独的构件从系统中分离出来，将应用逻辑作为单独的构件从系统中分离出来，以便这些构件在其他系统中能得到重用以便这些构件在其他系统中能得到重用将各个层次分配到各个不同的物理计算节点，将各个层次分配到各个不同的物理计算节点，或者分配给不同的进程。这样可以改善系统性或者分配给不同的进程。这样可以改善系统性能、更好地支持客户和服务器系统中的信息共能、更好地支持客户和服务器系统中的信息共享和协调享和协调将不同层的开发任务在开发者之间适当地分配，将不同层的开发任务在开发者之间适当地分配，这可以有效地利用开发人员的专长和开发技巧，这可以有效地利用开发人员的专长和开发技巧，并且能够提高并行开发能力并且能够提高并行开发能力40模型视图控制器构架模型视图控制器构架MVC模型，即相关的数据，它是模型，即相关的数据，它是对象的内在属性对象的内在属性视图是模型的外在表现形式，视图是模型的外在表现形式，一个模型可以对应一个或者一个模型可以对应一个或者多个视图，视图还具有与外多个视图，视图还具有与外界交互的功能界交互的功能控制器是模型与视图的联系控制器是模型与视图的联系纽带，控制器提取通过视图纽带，控制器提取通过视图传输进来的外部信息转化成传输进来的外部信息转化成相应事件，然后由对应的控相应事件，然后由对应的控制器对模型进行更新；制器对模型进行更新；相应相应的，模型的更新与修改将通的，模型的更新与修改将通过控制器通知视图，保持视过控制器通知视图，保持视图与模型的一致性图与模型的一致性41关于关于MVCMVC是一种处理交互式行为的模式，不仅仅可是一种处理交互式行为的模式，不仅仅可以用于以用于user interface处理，只要是处理，只要是“若干对若干对象协作，使得整体上对另一个对象而言表现出象协作，使得整体上对另一个对象而言表现出可交互性可交互性”，就可以运用，就可以运用MVC模式。所以，几模式。所以，几乎可以说乎可以说MVC能够运用在大多数场合能够运用在大多数场合MVC的关键要处理好职责分配、交互方式设计的关键要处理好职责分配、交互方式设计和交互协议的设计和交互协议的设计在非交互式系统中同样可以于用，要点在于抽在非交互式系统中同样可以于用，要点在于抽象地看待象地看待View42MVC备选构架示意图备选构架示意图43内容安排内容安排面向对象分析设计过程面向对象分析设计过程面向对象分析基础面向对象分析基础面向对象分析原则面向对象分析原则开始分析之前开始分析之前 用例分析技术用例分析技术44面向对象分析过程面向对象分析过程面向对象的分析方法：用例分析技术面向对象的分析方法：用例分析技术用例分析技术是基于用例的，在每一次用例分析技术是基于用例的，在每一次迭代中针对每一个用例：迭代中针对每一个用例：1.寻找候选对象寻找候选对象对象清单对象清单2.描述对象间的交互描述对象间的交互交互图（交互图（顺序图）顺序图）3.描述类描述类类图（类图（VOPC）451.寻找候选对象寻找候选对象寻找用于解决某个用例的一组对象寻找用于解决某个用例的一组对象寻找对象的准则寻找对象的准则限制每一个分析类（限制每一个分析类（analysis class）的职责）的职责对类和方法采用一致的命名对类和方法采用一致的命名保持分析类的简单保持分析类的简单寻找对象的步骤（寻找对象的步骤（MVC构架）构架）实体（实体（Entity）边界（边界（Boundary）控制（控制（Control）生命周期（生命周期（Lifecycle）46准则准则1：限制职责：限制职责SRP（The Single Responsibility Principle）：就一个类而言，应该仅有）：就一个类而言，应该仅有一个引起它变化的原因一个引起它变化的原因是否每一个类都有一个清楚的目标？是否每一个类都有一个清楚的目标？是否可以用一个文本段落清楚地描述这个目是否可以用一个文本段落清楚地描述这个目标？标？是否每一个方法都符合这个类的职责？是否每一个方法都符合这个类的职责？47准则准则2：采用清楚一致的命名：采用清楚一致的命名类的名字和职责必须是清楚的和明类的名字和职责必须是清楚的和明确的确的类和方法的清晰的命名可以让其他开类和方法的清晰的命名可以让其他开发人员和相关人员理解并验证分析模发人员和相关人员理解并验证分析模型，并可以捕获其中的误解和错误，型，并可以捕获其中的误解和错误，避免其发展到足以威胁项目的成功的避免其发展到足以威胁项目的成功的地步地步对象命名检查表（对象命名检查表（checklist-1）48对象命名检查表对象命名检查表checklist-1对于每一个类的名字是否是一个名词？对于每一个类的名字是否是一个名词？对于每一个类的名字是否是一个名词？对于每一个类的名字是否是一个名词？对那些对系统不怎么熟悉的人来说，每一个类对那些对系统不怎么熟悉的人来说，每一个类对那些对系统不怎么熟悉的人来说，每一个类对那些对系统不怎么熟悉的人来说，每一个类及其方法的名字是否都是明确的？及其方法的名字是否都是明确的？及其方法的名字是否都是明确的？及其方法的名字是否都是明确的？你是否为了得到一个能将意思描述清楚地名词你是否为了得到一个能将意思描述清楚地名词你是否为了得到一个能将意思描述清楚地名词你是否为了得到一个能将意思描述清楚地名词而采用诸如而采用诸如而采用诸如而采用诸如“manager”manager”之类的无意义的补白之类的无意义的补白之类的无意义的补白之类的无意义的补白？每一个方法的名字是否是一个动词或动词与名每一个方法的名字是否是一个动词或动词与名每一个方法的名字是否是一个动词或动词与名每一个方法的名字是否是一个动词或动词与名词的组合短语？词的组合短语？词的组合短语？词的组合短语？49准则准则3：保持简单：保持简单分析只是对高层次解决方案的第一次尝分析只是对高层次解决方案的第一次尝试试不要试图去确定对象之间的关系不要试图去确定对象之间的关系不要命名角色或者创建详细的继承层次不要命名角色或者创建详细的继承层次没必要花太多的时间来使你的第一稿草没必要花太多的时间来使你的第一稿草案看起来很完美：案看起来很完美：发现一些对象，评审一下这些结果，然后在发现一些对象，评审一下这些结果，然后在寻找对象行为的时候再来确定它的细节寻找对象行为的时候再来确定它的细节50步骤步骤1：实体对象：实体对象实体对象（实体对象（entity object）对系统的业）对系统的业务数据和业务逻辑进行封装务数据和业务逻辑进行封装解决问题所需要的全部数据和行为，然后将解决问题所需要的全部数据和行为，然后将这些数据按相关性分组这些数据按相关性分组识别出重要的名词，并将它们作为实体对象，识别出重要的名词，并将它们作为实体对象，之后确定每一个实体对象包含的数据和行为之后确定每一个实体对象包含的数据和行为识别实体对象检查表（识别实体对象检查表（checklist-2）51识别实体对象检查表识别实体对象检查表checklist-2实体对象是否是某个问题中的重要名词？实体对象是否是某个问题中的重要名词？实体对象是否是某个问题中的重要名词？实体对象是否是某个问题中的重要名词？实体对象是否包含用来解决系统问题的重要的实体对象是否包含用来解决系统问题的重要的实体对象是否包含用来解决系统问题的重要的实体对象是否包含用来解决系统问题的重要的信息？信息？信息？信息？实体对象是否包含可以解决系统问题的计算或实体对象是否包含可以解决系统问题的计算或实体对象是否包含可以解决系统问题的计算或实体对象是否包含可以解决系统问题的计算或验证逻辑？验证逻辑？验证逻辑？验证逻辑？那些了解这个系统目标的专家是否会理解这些那些了解这个系统目标的专家是否会理解这些那些了解这个系统目标的专家是否会理解这些那些了解这个系统目标的专家是否会理解这些实体对象？实体对象？实体对象？实体对象？52寻找实体对象寻找实体对象-Record Time正常事件流：正常事件流：1.1.雇员雇员雇员雇员查看当前时间段之前输入的数据时间段之前输入的数据时间段之前输入的数据时间段之前输入的数据；2.雇员从已有的支付号码支付号码支付号码支付号码中选择一个，这些收费代码收费代码收费代码收费代码是按客户客户客户客户和项目项目项目项目组织的；3.雇员从当前的时间段时间段时间段时间段选择一个日期日期日期日期；4.雇员输入以正整数表示的工时工时工时工时；5.系统在视图视图视图视图中显示这个数据数据数据数据，并在以后的视图中看到这个数据。备选事件流备选事件流1：雇员更改他的时间雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目已有的条目已有的条目已有的条目；3.雇员改变工时工时工时工时和/或支付号码支付号码支付号码支付号码；4.在视图中更新这个信息，并在以后的视图中都可以看到。备选事件流备选事件流1：雇员提交雇员提交考勤卡考勤卡考勤卡考勤卡1.雇员雇员雇员雇员已有条目已有条目已有条目已有条目收费代码收费代码收费代码收费代码客户客户客户客户项目项目项目项目工时工时工时工时考勤卡考勤卡考勤卡考勤卡53检查实体对象检查实体对象雇员雇员雇员雇员已有条目已有条目已有条目已有条目收费项目代码收费项目代码收费项目代码收费项目代码客户客户客户客户项目项目项目项目工时工时工时工时考勤卡考勤卡考勤卡考勤卡管理员用户管理员用户管理员用户管理员用户54步骤步骤2：边界对象：边界对象边界对象（边界对象（boundary object）描述系）描述系统将如何用参与者交互统将如何用参与者交互通过检查在用例图中的参与者与用例之间的通过检查在用例图中的参与者与用例之间的关系，可以识别出边界对象关系，可以识别出边界对象在分析模型中，每一对参与者在分析模型中，每一对参与者/用例都构成用例都构成了一个边界对象了一个边界对象边界对象可分为两种：边界对象可分为两种：用户界面：允许系统与人交互用户界面：允许系统与人交互系统接口：允许系统与其他系统交互系统接口：允许系统与其他系统交互识别边界对象检查表（识别边界对象检查表（checklist-3）55识别边界对象检查表识别边界对象检查表checklist-3用户界面类是否描述了必须显示的信息以及必用户界面类是否描述了必须显示的信息以及必用户界面类是否描述了必须显示的信息以及必用户界面类是否描述了必须显示的信息以及必须提供的服务？须提供的服务？须提供的服务？须提供的服务？用户界面类是否可以推迟所有的接口设计细节用户界面类是否可以推迟所有的接口设计细节用户界面类是否可以推迟所有的接口设计细节用户界面类是否可以推迟所有的接口设计细节？系统接口是否描述了与外部系统的交互？系统接口是否描述了与外部系统的交互？系统接口是否描述了与外部系统的交互？系统接口是否描述了与外部系统的交互？系统接口是否推迟所有的协议细节？系统接口是否推迟所有的协议细节？系统接口是否推迟所有的协议细节？系统接口是否推迟所有的协议细节？56寻找边界对象寻找边界对象57步骤步骤3：控制对象：控制对象控制对象（控制对象（control object）为其他对）为其他对象提供工作流和会话服务象提供工作流和会话服务在边界对象访问实体对象的时候，控制对象在边界对象访问实体对象的时候，控制对象将一系列复杂的请求封装成通用的工作流，将一系列复杂的请求封装成通用的工作流，使这种访问变得简单使这种访问变得简单从边界对象发出的高级的消息将被转换成一从边界对象发出的高级的消息将被转换成一系列从控制对象发往实体对象的消息系列从控制对象发往实体对象的消息通常，每一个用例都应该有一种控制对象通常，每一个用例都应该有一种控制对象识别控制对象检查表（识别控制对象检查表（checklist-4）58识别控制对象检查表识别控制对象检查表checklist-4控制对象是否对用例的作用或者工作流逻辑进控制对象是否对用例的作用或者工作流逻辑进控制对象是否对用例的作用或者工作流逻辑进控制对象是否对用例的作用或者工作流逻辑进行建模？行建模？行建模？行建模？控制对象是否将真正的业务逻辑提交给实体对控制对象是否将真正的业务逻辑提交给实体对控制对象是否将真正的业务逻辑提交给实体对控制对象是否将真正的业务逻辑提交给实体对象？象？象？象？59寻找控制对象寻找控制对象60步骤步骤4：对象生命周期类：对象生命周期类对象生命周期类（对象生命周期类（object lifecycle classes）跟踪实体对象）跟踪实体对象对象的创建、定位，以及销毁对象的创建、定位，以及销毁控制对象或者实体对象需要根据不同的准则控制对象或者实体对象需要根据不同的准则来定位一个实体对象来定位一个实体对象常见的生命周期对象有常见的生命周期对象有factory、container等，当然这些名字不适合分析模等，当然这些名字不适合分析模型型识别生命周期类检查表（识别生命周期类检查表（checklist-5）61识别生命周期类检查表识别生命周期类检查表checklist-5生命周期类是否定位、创建和销毁实体对象？生命周期类是否定位、创建和销毁实体对象？生命周期类是否定位、创建和销毁实体对象？生命周期类是否定位、创建和销毁实体对象？生命周期类是否只专用于一类实体对象？生命周期类是否只专用于一类实体对象？生命周期类是否只专用于一类实体对象？生命周期类是否只专用于一类实体对象？622.描述对象间的交互描述对象间的交互描述对象间的交互，从而寻找对象行为描述对象间的交互，从而寻找对象行为寻找对象行为的准则寻找对象行为的准则确保方法之间的内聚性确保方法之间的内聚性采用清楚明确的方法名采用清楚明确的方法名完全满足用例要求完全满足用例要求保持简单保持简单描述行为的步骤描述行为的步骤将以识别的参与对象加到顺序图中将以识别的参与对象加到顺序图中从参与者开始，一步步寻找行为从参与者开始，一步步寻找行为验证行为序列验证行为序列63描述行为检查表描述行为检查表checklist-6是否每一个方法都有清楚的目标？是否每一个方法都有清楚的目标？是否每一个方法都有清楚的目标？是否每一个方法都有清楚的目标？是否每一个方法的命名都是名词和动词的强组合？是否每一个方法的命名都是名词和动词的强组合？是否每一个方法的命名都是名词和动词的强组合？是否每一个方法的命名都是名词和动词的强组合？是否避免采用模棱两可的名字？是否避免采用模棱两可的名字？是否避免采用模棱两可的名字？是否避免采用模棱两可的名字？是否从调用对象的角度来清楚地命名每一个方法？是否从调用对象的角度来清楚地命名每一个方法？是否从调用对象的角度来清楚地命名每一个方法？是否从调用对象的角度来清楚地命名每一个方法？对其他开发人员来说，这些名字是否是明确的？对其他开发人员来说，这些名字是否是明确的？对其他开发人员来说，这些名字是否是明确的？对其他开发人员来说，这些名字是否是明确的？方法的名字是否表明了它的返回类型？方法的名字是否表明了它的返回类型？方法的名字是否表明了它的返回类型？方法的名字是否表明了它的返回类型？在每一个类中的方法，它们之间是否存在密切关系？在每一个类中的方法，它们之间是否存在密切关系？在每一个类中的方法，它们之间是否存在密切关系？在每一个类中的方法，它们之间是否存在密切关系？是否每一个类中的方法都符合这个类所声明的职责？是否每一个类中的方法都符合这个类所声明的职责？是否每一个类中的方法都符合这个类所声明的职责？是否每一个类中的方法都符合这个类所声明的职责？是否每一个类仍然还保持一个具体的目标？是否每一个类仍然还保持一个具体的目标？是否每一个类仍然还保持一个具体的目标？是否每一个类仍然还保持一个具体的目标？64描述对象交互描述对象交互正常事件流：正常事件流：1.雇员查看当前时间段之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。备选事件流备选事件流2：雇员提交考勤卡雇员提交考勤卡1.雇员看到当前时间段之前输入的数据；2.雇员选择提交考勤卡；3.系统要求雇员确认他的选择，并提醒他将不能再编辑这些条目；4.考勤卡被提交，再也不能对它进行编辑。65顺序图顺序图Sequence Diagram描述对象之间的描述对象之间的动态交互动态交互关系，着重体关系，着重体现对象间消息传递的时间顺序现对象间消息传递的时间顺序对象（对象（Object）：对象、对象的生命线、）：对象、对象的生命线、激活的对象和对象的删除激活的对象和对象的删除消息（消息（Message）：简单消息、同步消息、）：简单消息、同步消息、异步消息、返回消息异步消息、返回消息条件（条件（Condition）、注释体和注释连接）、注释体和注释连接66顺序图顺序图-推荐的使用场合推荐的使用场合顺序图是一种交互图，交互图主要用于顺序图是一种交互图，交互图主要用于描述对象之间的动态协作关系（协作图）以描述对象之间的动态协作关系（协作图）以及协作过程中的行为次序（顺序图）及协作过程中的行为次序（顺序图）常常用来描述一个常常用来描述一个用例的行为用例的行为用例的行为用例的行为，显示该用例，显示该用例中所涉及的对象以及这些对象之间的中所涉及的对象以及这些对象之间的消息传消息传消息传消息传递递递递情况情况673.描述类描述类顺序图描述了用例中对象间的交互关系；而对顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系象间的交互要用到类的方法以及类之间的关系描述类的准则描述类的准则完整完整保持简单保持简单维持类的一致性维持类的一致性描述类的步骤描述类的步骤将对象的行为合并到类中将对象的行为合并到类中重构类，使其符合规则重构类，使其符合规则发现类之间的关系发现类之间的关系完成该用例完成该用例“参与类类图参与类类图”（VOPC,View of Participating Classes Class Diagram）68Record Time用例中类的关系用例中类的关系69总结：用例分析过程总结：用例分析过程评估用例，确定迭代周期评估用例，确定迭代周期在每一次迭代中的每一个用例：在每一次迭代中的每一个用例：1.寻找候选对象寻找候选对象获得各类对象清单：实体类、控制类、边界类获得各类对象清单：实体类、控制类、边界类2.描述对象间的交互描述对象间的交互-顺序图顺序图针对每个事件流，通过顺序图演示用例的实现过程针对每个事件流，通过顺序图演示用例的实现过程3.描述类描述类-类图类图完成类图，描绘类图中的关系完成类图，描绘类图中的关系重构类图，构造整个系统的分析模型重构类图，构造整个系统的分析模型70作业作业2：用例分析：用例分析-题目要求题目要求总分：总分：10分分在作业在作业1所构建的用例模型基础上，完成分析所构建的用例模型基础上，完成分析过程过程确定第一个迭代周期（提供该周期的用例图）确定第一个迭代周期（提供该周期的用例图）简单描述系统的体系构架，并将分析过程所发现的简单描述系统的体系构架，并将分析过程所发现的类（对象）放入到相应的层次结构中类（对象）放入到相应的层次结构中对作业对作业1中已经完成用例规约的一个用例
