uml第五章.ppt

uml第五章.ppt

《uml第五章.ppt》由会员分享，可在线阅读，更多相关《uml第五章.ppt（63页珍藏版）》请在冰豆网上搜索。

第5章用例分析技术Use-CaseAnalysis,-2-,Review:

Use-CaseModeling,基于用例的需求获取过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包,-3-,References,Arri02CTArrington,EnterpriseJavawithUML（马波，李雄锋译，EnterpriseJavawithUML中文版，机械工业出版社，2003年）Larm01,CraigLarman,ApplyingUMLandPatterns,2e（姚淑珍、李虎等译，UML和模式应用-面向对象分析与设计导论，机械工业出版社，2002年）DEV475,IBMRational,MasteringObject-OrientedAnalysisandDesignwithUML,2003Kruc00,PhilippeKruchten,TheRationalUnifiedProcess:

AnIntroduction（SecondEdition）（周伯生等译，Rational统一过程引论，机械工业出版社，2002.5）,-4-,下一步？

需求,用例,面向对象分析设计,结构化分析设计,其它方法,自己的土方法,系统,-5-,内容安排,面向对象分析设计过程面向对象分析基础面向对象分析原则开始分析之前用例分析技术,-6-,面向对象分析、设计,基于面向对象的分析和设计理论，产生了许多开发过程实践RUP：

RationUnifiedProcessMSF：

MicrosoftSolutionFrameworkALM：

ApplicationLifecycleManage,-7-,IBMRUP,-8-,RUP中的分析和设计工作流,分析Analysis,设计Design,软件构架文档,用例实现规约,-9-,分析阶段主要工件,逻辑视图：

分析（概念）模型体系结构包图,-10-,MSF,-11-,BorlandALM,-12-,内容安排,面向对象分析设计过程面向对象分析基础面向对象分析原则开始分析之前用例分析技术,-13-,面向对象分析OOA?

当一个新的产品或系统将被建造时：

我们如何以遵从面向对象软件工程的方式来刻画它？

是否存在我们需要问询客户的问题？

什么是相关的对象？

它们如何相互关联？

对象如何在系统的语境内运转？

我们如何刻画或建模问题域以使得我们可以创建一个有效的设计,-14-,OOA目标,开发一系列模型，以描述计算机软件，从而满足客户定义的需求：

分析模型包括两种图，描述对象及其交互这些图按照用例模型来组织，每个用例图都会产生数张图类图（classdiagram）：

描述了构成一类对象特征的状态和行为（描述软件架构）交互图（interactiondiagram）：

描述对象之间的交互行为（演示用例实现）（描述系统行为）,-15-,从需求到分析,Analysisworkflow,AnalysisClass,-16-,OOA与用例模型,分析是建立在需求收集的基础上分析模型建立在用例模型的基础上用例模型确定了分析模型的结构（通过用例来组织分析模型）用户视角理解用户问题过渡到开发团队视角分析用户问题与需求一样，它还是在问题域中用例分析也是分析的一个阶段，而OOA是分析的后期阶段，从这个阶段开始，我们从用户域跨入开发团队域分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析,-17-,分析模型与用例模型,用例：

外观,类图：

内部机理,-18-,如何开始？

从用例开始！

-19-,从用例开始-1,根据高层用例图和文档来确认需求定义是可靠的、一致的可靠的每个用例都包含对正常事件流和异常事件流的描述存在备选事件流、异常事件流的描述完备的如果在分析过程中发现一些新的用例，说明需求是不完备的，此时应对用例进行重构在分析过程中，还有可能精化对每一个用例的理解,-20-,从用例开始-2,根据风险、重要性以及项目组的能力确定用例的优先级：

用例分级风险重要性团队能力以及团队建设在迭代开发中，通过一次全面的需求收集来获得所有的用例；之后找出一个用例集，开发一个符合这些需求的最小系统，完成一次迭代过程；在此基础上，进行后续的增量开发过程,相对来说，策划一系列的小胜利和接受一些小的失误总要好一点。

策划一个巨大的胜利经常会导致灾难性的失败！

-21-,用例图：

考勤卡系统,-22-,从用例开始-风险分析-1,项目本身风险（risk）：

项目的风险清单无法接受的系统性能无法应付新的需求不确定的进度以及开发周期无法接受的用户界面,-23-,从用例开始-风险分析-2,团队解决问题的能力：

结合团队能力分析用例风险，即团队是否有能力解决用例中的问题1-当然可以，我们的项目团队以前解决过这种问题2-没问题，我们机构以前解决过这种问题3-可以采用第三方提供的产品、培训、书或者其他的技术资料，但我们内部没有任何经验4-可能吧，我们听过类似的可以解决的问题5-我们希望可以，但我们得作一些开创性的工作,-24-,从用例开始-重要性,对用户以及架构的重要性（significance）一个重要的用例应该能够体现系统的特性和目标；如：

RecordTime、ExportTimeEntries其他的用例可能很重要，但只是扮演支持的角色；如：

ChangePassword评估用例的重要性1-用户几乎不注意用例的存在，在没有它的情况下系统不会有什么影响2-用户注意用例的存在，但稍加想象，系统仍然可以很好的使用3-系统的大部分可以独立于这个用例4-系统的一部分可以独立于这个用例5-没有它，就不可能使用这个系统,-25-,从用例开始-其它问题,合适性（suitability）：

这个用例是否适合你的团队1-这个团队绝对需要一段培训时间来开发这个用例2-对于这个用例来说，团队可能有足够的能力，但是在一次迭代之后，团队的能力将需要有本质的提高3-团队可能有了足够的能力，但在一次迭代之后这个能力不需要怎么提高4-不需要很多的培训，要么是团队的能力已经绰绰有余，要么是这个用例相当简单5-不需要很多的培训，团队有足够的经验，用例也很简单，手到擒来,-26-,建立第一个迭代周期,1-风险2-重要性3-合适性,-27-,内容安排,面向对象分析设计过程面向对象分析基础面向对象分析原则开始分析之前用例分析技术,-28-,分析的基本原则,把分析限制在问题域词汇的那部分类,保持分析模型是一个对系统结构和行为的精确和简单陈述,-29-,经验法则-1,分析模型总是使用业务语言分析模型中的抽象应该是业务领域词汇的部分创建“讲故事”的模型每幅产生的图应该阐明系统期望行为的一些重要部分注重于捕获大的场面不限于系统将如何工作的细节（这是设计的工作）清晰地区分问题域（业务需求）和解域（详细的设计考虑）总是关注存在于问题域的抽象,-30-,经验法则-2,总是尽力最小化耦合类之间的每个关联都是在它们之间建立耦合继承关系继承是类间耦合的最强形式如果看起来存在自然的、强迫的抽象层次，则可探索继承关系分析中，永远不要仅为了复用代码而使用继承“该模型对所有项目干系人有用吗？

”,保持模型简单！

-31-,题外话：

分析模式-1,分析模式（analysispattern）：

描述通用业务/分析问题解决方案的一种模式例：

“游戏者击中白球，它以一定的速度前进，并以特定的角度碰到红球，于是红球在某个特定的方向上前进一段距离”除了这些表面现象，还必须了解背后的本质，那就是和质量有关的运动定律，速度，动量，等等。

了解这些规律将更容易看到软件可以怎样建立我们建造应用系统的时候，需要大量的了解和研究，才能接触到问题的本质,-32-,分析模式-2,分析模式更接近系统的概念模型，如果系统概念模型经过抽象，可以应用在多个相似的环境中，那么，它就变成了模式在代码实现层面，我们很容易看到和理解重用的概念，从最开始的函数库，到类库，到设计模式，到应用框架，我们的对代码的重用程度越来越高在业务领域的分析层面，重用的可能性依然存在，分析模式，就是这种重用的一部分，如果我们都可以利用以往的经验，得到业务领域的通用解决方案，它们将直接影响到应用系统的设计，因而这种重用的价值将更加显著,-33-,分析模式-3,AnalysisPatterns:

ReusableObjectModelsMartinFowlerhttp:

/,-34-,开始分析之前：

定义备选构架,RUP中的“定义备选构架”创建系统构架的初始草图初步定义一组在构架方面具有重要意义的元素，以用作分析的基础初步定义一组分析机制初步定义系统的分层与组织定义要在当前迭代中处理的用例实现从在构架方面具有重要意义的用例中确定分析类通过分析类交互来更新用例实现,-35-,经典的三层构架-1,数据库,记录销售信息,支付授权,表示层,应用逻辑层,存储层,-36-,多层体系结构的动机,将应用逻辑作为单独的构件从系统中分离出来，以便这些构件在其他系统中能得到重用将各个层次分配到各个不同的物理计算节点，或者分配给不同的进程。

这样可以改善系统性能、更好地支持客户和服务器系统中的信息共享和协调将不同层的开发任务在开发者之间适当地分配，这可以有效地利用开发人员的专长和开发技巧，并且能够提高并行开发能力,-37-,模型视图控制器构架MVC,模型，即相关的数据，它是对象的内在属性视图是模型的外在表现形式，一个模型可以对应一个或者多个视图，视图还具有与外界交互的功能控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息转化成相应事件，然后由对应的控制器对模型进行更新；相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性,-38-,关于MVC,MVC是一种处理交互式行为的模式，不仅仅可以用于userinterface处理，只要是“若干对象协作，使得整体上对另一个对象而言表现出可交互性”，就可以运用MVC模式。

所以，几乎可以说MVC能够运用在大多数场合MVC的关键要处理好职责分配、交互方式设计和交互协议的设计在非交互式系统中同样可以于用，要点在于抽象地看待View,-39-,内容安排,面向对象分析设计过程面向对象分析基础面向对象分析原则开始分析之前用例分析技术,-40-,面向对象分析过程,面向对象的分析方法：

用例分析技术用例分析技术是基于用例的，在每一次迭代中针对每一个用例：

1.寻找候选对象对象清单2.描述对象间的交互交互图（顺序图）3.描述类类图（VOPC）,-41-,1.寻找候选对象,寻找用于解决某个用例的一组对象寻找对象的准则限制每一个分析类（analysisclass）的职责对类和方法采用一致的命名保持分析类的简单寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）,-42-,准则1：

限制职责,SRP（TheSingleResponsibilityPrinciple）：

就一个类而言，应该仅有一个引起它变化的原因是否每一个类都有一个清楚的目标？

是否可以用一个文本段落清楚地描述这个目标？

是否每一个方法都符合这个类的职责？

-43-,准则2：

采用清楚一致的命名,类的名字和职责必须是清楚的和明确的类和方法的清晰的命名可以让其他开发人员和相关人员理解并验证分析模型，并可以捕获其中的误解和错误，避免其发展到足以威胁项目的成功的地步对象命名检查表（checklist-1）,-44-,对象命名检查表checklist-1,对于每一个类的名字是否是一个名词？

对那些对系统不怎么熟悉的人来说，每一个类及其方法的名字是否都是明确的？

你是否为了得到一个能将意思描述清楚地名词而采用诸如“manager”之类的无意义的补白？

每一个方法的名字是否是一个动词或动词与名词的组合短语