UML建模与分析.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,UML,建模与分析,UML,概述,UML,定义：,统一建模语言是一种表示法；它是可以安排用于描述软件系统设计的图和图元素的集合。,UML,既不是过程，也不是由表示法和过程组成的方法。,为什么使用,UML?,在软件环境中，随着项目的规模以及复杂度的提高，尤其是涉及到的人员的增多，形式设计将越来越重要。模型设计表示法在以下方面非常重要：,-,根据具体应用设计蓝图；,-,估计和规划时间及用料；,-,小组之间以及小组内部进行合作和沟通；,-,编写项目文档；,UML,概述,Conceptual-,同人类语言关联,Specification-,对将要形成的源代码的描述,Implementation-,对已经存在的源代码的描述,UML,概述,UML,概述,模型的基本组织结构：,基本内容：,概念上，,UML,用于描述模型的基本词汇（,UML,元模型,metamodel,）,有三种,:,要素,(Things):-,表述结构的要素：,Use Case,、,Class,、,Interface,和,Collaboration-,表述行为的要素：,Interaction,、,StateMachine,-,用于组织的要素：,Package-,用于辅助说明的要素：,Notes,UML,概述,关系（,Relationships,）,-Association,：,表达两个类的实例之间存在连接。,Aggregation,和,Composition,是关联关系的强化形式。,-Dependency,：,依赖者“使用”被依赖者的关系。,-Generalization,：,表达“特殊的”是“一般”的一种。,-Realization,：”,被实现者”是对要求的说明，“实现者”是针对要求的解决方案。,图（,Diagrams,）,-Use Case Diagram,：,一种静态图，主要用于展示,Use Case,、,Actor,及其关系。,-Class Diagram,：,一种静态图，主要用于展示类、接口、包及其关系,UML,概述,-Sequence Diagram,：,一种动态图，用于按时序展示对象间的消息传递。,-Collaboration Diagram,：,一种动态图，其核心内容与序列图相对应，强调,(,收发消息的,),对象间的结构组织。序列图和协作图统称为,Interaction Diagram,。,-,Statechart,Diagram,：,一种动态图，主要用于展示对象在其生命周期中可能经历的状态以及在这些状态上对事件的响应能力。,-Activity Diagram,：,一种动态图，用于展示系统从一个活动流转到另一个活动的可能路径与判断条件。,-,其他静态图：,Object Diagram,、,Component Diagram,和,Deployment Diagram,UML,概述,语义扩展作为一种语言，,UML,除了提供基本的词汇，还给出了对自身描述的能力的三种扩展机制：,-,构造型,(Stereotype)-,标注值,(Tagged Value)-,约束,(Constraint),组织方式：,模型的内容通过包以及包的层层嵌套组织在一起。包将一堆零散的模型内容简单地组织在一起，目的是更易于理解和管理。模型应该能够反映建模者和使用者的特定视角。即所谓的构架视图,(View),UML,概述,视图由多个图来描述，图中包含了强调系统某个特定方面的信息。从不同的视图来观察系统，可以使人们在某段时间内能够集中注意系统的一个方面。一个特定视图中的图应该足够简单、便于交流，但是一定要与其他图和视图连贯一致，这样，所有视图结合在一起就描述了系统的完整画面。,UML,中,4+1,视图,(View),Use Case View,由专门描述可被最终用户、分析人员和测试人员看到的系统行为的,Use Case,组成。,Use Case View,实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。,UML,中，该视图的静态方面由,Use Case Diagram,表现；动态方面由交互图、状态图和活动图表现。,Design View,系统的设计视图包含了类、接口和协作，它们形成了问题及其对问题解决方案的术语词汇。这种视图主要支持系统的功能需求，即系统提供给最终用户的服务。在,UML,中，该视图的静态方面由类图和对象图表现；动态方面有交互图、状态图和活动图表现。,Process View,包含了形成系统并发与同步机制的线程和进程。该视图主要针对性能、可伸缩性和系统的吞吐量。在,UML,中，对进程视图的静态方面和动态方面的表现与设计视图像图，但侧重于描述线程和进程的主动类,UML,概述,Implementation View,包含了用于装配与发布物理系统的构件和文件。这种视图主要针对系统发布的配置管理，它由一些独立的构件和文件组成；这些构件和文件可以用各种方法装配，以产生运行系统。在,UML,中，该视图的静态方面由构件图表现；动态方面由交互图、状态图和活动图表现,deployment view,包含了形成系统硬件拓扑结构的节点（系统在其上运行）。这种视图主要描述对组成物理系统的部件的分布、交付和安装。在,UML,中，该视图的静态方面由部署图表现；动态方面由交互图、状态图和活动图表现,UML,概述,设计视图,实现视图,进程视图,实施视图,用例视图,词汇功能,行为,性能,可伸缩性,吞吐量,系统拓扑,分布,交付,安装,系统装配,配置管理,UML,概述,UML2.0,新特性,UML1.x,中的协作图变成了通信图,允许在一个顺序图上显示更复杂的选择,新增两种交互图：时序图和交互概观图，为用户查看系统的动态行为提供新工具,活动图不再与状态机合在一起。新的活动图包括对大量附加的流特征的支持，并且不再把重点放在各种状态的转换上，而是放在沿着各个活动边沿流动的令牌流上。,UML,模型不再利用,UML,语言来定义，而是利用一种更抽象的，用来具体说明各种模型语言的语言,MOF,来定义。,UML,概述,常见图的用法与内容：,用例图：描述拟建系统与外部环境的关系,-Use Case,图主要用于描述拟建系统和外部环境的关系，概念上，,Use Case,的集合表达拟建系统，,Actor,的集合表达外部环境，,Use Case,和,Actor,之间的连线的集合则表达拟建系统和外部环境的边界。,-Actor,代表拟建系统外部和系统进行交互的某类人或系统,-Use Case,定义了一组相关的由系统执行的动作序列，将有价值的可见结果提供给某个,Actor,。,Use Case,与外部的交互活动中可能涉及若干个,Actor,但是只有一个,Actor,主动要求得到有价值的可见结果。通常称之为主导,(Primary)Actor,。,Primary Actor,是,触发交互活动的,Actor,，,它到相应的,Use Case,之间的连线标有箭头。,-Actor,和,Use Case,之间的连线称为通信关联，表示,Actor,和相应的,Use Case,之间的交互。无论有没有箭头，通信关联都表示介于,Actor,和相应的,Use Case,之间的双向会话。,UML,概述,-,用例之间的关系包含关系,(include),，,最常用的关系之一。表示两个用例有包含关系，后者是前者的一部分。系统在每次调用前一个用例时，也都回调用后一个用例。扩展关系,(extend),，,最常用的关系之一。表示后者是前者信息或者业务功能的扩展。系统在每次调用前一个用例时，可能会调用后一个用例。通信关系,(communicate),，,表示两个用例有信息沟通，但没有互相调用的关系。实现关系,(Realize),，,表示两个用例之间有实现关系。一般用于业务用例,(business use case),和用例,(use case,包括：,business use case realization,和,use case realization),之间。,不要使用,UML,概述,用例图：描述需求模型与设计模型的关系可以用,Use Case,图描述功能需求的局部,(,即,Use Case),与相应分析和设计内容,(Use Case,实现,),之间的可追溯关联。,Use Case,同前,Use Case Realization,表现为虚线边框的椭圆，用于表达基于设计视角的,Use Case,内容，及相关的分析和设计元素的协作关系。用例实现包括动态描述内容,(,交互图组,),和静态描述内容,(,类图,),。,Use Case Realization,和,Use Case,之间有可能是多对一的关系。通俗讲，一种要求可以通过多种办法解决。,UML,概述,活动图：描述,Use Case,的事件流结构活动,(Activity),决策点,(Decision),序列图：描述局部分析和设计的场景序列图用于描述动态行为，直观易懂，是最常用的一种交互图。通常，,Use Case,中的每一个事件序列对应,Use Case,实现中的一张序列图。对象消息,序列图：描述构架机制的典型场景,UML,概述,协作图：描述局部分析和设计的场景协作图是另一种形式的交互图。协作图的本质内容（对象和消息）与相关的序列图存在明确的对应关系。在协作图中，传递消息的对象之间存在一条连线，表示它们之间的“连接”,(Link),，,即消息传递通道。协作图主要用于描述局部分析和设计中的特定场景，其特点是强调对象间的结构关系。通常只关注那些对应重要事件序列的协作图。,类图：描述类、接口和子系统之间的关系类图是广泛应用的一种图，描述拟建系统各个层面的静态结构，主要用于表述类、接口和子系统之间的关系。,UML,概述,分为三种情形：其一、表述参与某一特定协作的类、接口和子系统之间的关系。这种情形的类图被称为“参与类图”,(VOPC,，,View of Participating Classes),。,Use Case,实现和架构机制是两种典型的协作，参与类图隶属于这两种类型的协作内容。其二、表述同一包中的类、接口和子系统之间的关系，这种类图通常出现在相应的包中。其三、针对上述两种情形以外的其他目的，表述类、接口和子系统之间的关系，这种情形的类图可以出现在任何需要的位置。,UML,概述,类：类用于描述一组具有相同属性、操作、关系和语义的对象。接口：接口用来说明一个类或者子系统应该提供的服务，形式上是一组操作的集合。接口一种规范的形式表述多态的概念。子系统：是一组元素的集合，其中一部分元素说明这组元素能够提供那些行为，而另外一部分元素则具体提供相应的行为。子系统所具有的行为特征在概念上和类相似。关系,UML,概述,状态图：描述具有明显状态特征的类用于展示对象,(,类实例,),生命周期中可能处于的状态、在这些状态中的行为、发生状态转换的事件及其相关的动作。一个类所处的全部可能状态及其相关行为构成了这个类的状态机,(State Machine),。,描述类状态特征的状态图隶属于该类的状态机。一个状态机可以由多张状态图来描述。状态（,State,）,是一个对象在生命周期内处于某一种情形（,Condition or Situation,）,限定了该对象对事件的响应能力。对象在某个状态中有两种类型的行为：动作,(Action),是与状态转换相关原子化的行为，不可能被打断；活动（,Activity,）,是与某一状态相关的非原子化的行为，有可能被打断。转移,(Transition),是指在某种激励作用下从一个状态转到另一个状态。转移通常是满足特定条件,(Guard Condition),时对某种事件,(Event),的响应。,UML,概述,补充说明：每种图都显示同一个应用设计的不同方面，所以我们应该采用这些图，并把它们作为一个整体而不是独立的个体来看待。各图中命名的一致性很重要，因为设计是否正确以及是否完整都取决于图之间的一致性。检查一致性的一些规则：,-,每个用例是否至少有一个描述其实现的顺序图或协作图？如果没有，则说明设计不完整。,-,静态结构图中的每一个类是否至少都描绘一个顺序图或静态图？如果不是这样，说明可能缺少用例实现，甚至缺少整个用例，因为你从未有效地使用过该类。,-,所有有状态的类是否都有一个与其相对应的状态图？如果没有，允许状态改变的有关规则将变得不明确或者未知。,-,状态图中的每个事件是否都在顺序图,(,提供事件的实际发生环境,),中有一条对应的消息？如果没有，则说明可能从未发生过状态转换。,应用,UML,建模过程,任务和活动：有步骤、分层次地演进系统构架将软件需求逐渐转变为软件的设计方案保障软件的设计方案能够适应实施环境,总体框架：全局分析,-,局部分析,-,全局设计,-,局部设计,-,细节设计,应用,UML,建模过程,Use Case,实现,设计模型,层次构架,软件需求,Use Case,报告,词汇表,Use Case,补充规约,设计模型的内容与演进,广义的设计模型包括在分析和设计活动中得到的所有结果。设计模型由,3,部分组成：,“,Use Case,实现”：反映软件需求对设计内容的驱动,层次构架,(Layers),：,一种典型的构架模式，它将分析和设计的结果按照特殊到一般的等级分组，层次构架中的内容是后续开发活动的直接依据。,构架机制,(Mechanism),描述可复用的设计经验,应用,UML,建模过程,应用,UML,建模过程,逻辑上，层次构架依赖,Use Case,实现和构架机制。层次构架中的内容代表了分析和设计活动的实质结果，处于设计模型的核心地位。,整个设计模型对软件需求的依赖关系主要体现在两个方面：一方面，,Use Case Realization,通过一组协作实现,Use Case,描述的功能需求，“,Use Case,实现”是软件功能需求内容过渡到层次构架中内容的桥梁；另一方面，“构架机制”主要实现作为非功能需求载体的“补充规约”，“构架机制”是软件非功能需求得以体现的主要形式。,应用,UML,建模过程,需求分析,-,用例建模,需求规格说明的目的,:,在系统应该做什么以及为什么这么做的问题上，客户和其他项目相关人员达成协议，并维护这个协议。,为系统开发人员提供对系统需求的更好理解,定义系统边界,为计划迭代过程中的技术内容提供基础,为评估开发系统需要的成本和时间提供基础,定义系统的用户界面，主要关注用户需求和目标,应用,UML,建模过程,需求规范,需求规范涉及到为了获取、确认和维护一个系统的需求制品而执行的一系列活动。实际上，可以把需求看作客户和软件组织的一个合同。需求为软件经理提供了一种参考基准，是系统的发展可控。它们还可以作为设计团队、软件测试人员、质量保证小组以及准备用户文档的人们的输入。,应用,UML,建模过程,需求规范包括,5,个活动,-,理解问题分析人员 引出风险承担者的请求,找出参与者和用例,应用,UML,建模过程,-,定义系统分析人员 结构化用例模型,详细描述一个用例,-,评审,评审人员,评审需求,应用,UML,建模过程,制品需求制品也称为功能规格说明、需求定义和软件需求规格说明,SRS,。,需求制品用于,3,个目的：首先，它们建立了使客户和用户达成系统应当干什么的协议的基础；其次，它们是系统开发者更好地理解有关系统的需求；最后，它们确定了系统的边界。,应用,UML,建模过程,制品分成,3,组：,-,输入制品 构想 术语表,-,描述性制品软件需求规格说明,SRS,术语表 补充规格说明,-,建模制品用例用例模型,使变更的影响最小有效地分析问题和获取用户的需要与客户或者用户取得对产品需求的一致意见建立用户和系统间交互的模型建立一个基准和变更控制过程维护需求的前后可追踪性使用迭代过程执行评审：快速检查、审查、正式评审,应用,UML,建模过程,应用,UML,建模过程,什么是需求？,需求是系统必须满足的条件或具备的能力。,需求的类型：需求按照,FURPS+,模型分类,功能性,(Functional):,特性、能力、安全性,可用性,(Usability):,人性化因素、帮助、文档可靠性,(Reliability),：,故障周期、可恢复性、可预测性,性能,(Performance):,响应时间、吞吐量、准确性、有效性、资源利用率,可支持性,(Supportability),：,适应性、可维护性、国际化、可配置性,应用,UML,建模过程,“,+”,是指一些辅助性的和次要的因素，比如：,实现,(Implementation),：,资源限制、语言和工具、硬件等,接口,(Interface),：,与外部系统接口所加的约束,操作,(Operations),：,系统操作环境中的管理,包装,(Packaging),授权,(Legal),：,许可证或其他方式,使用,FURPS+,分类方式是一种有效的需求范围检查表，可以降低考虑系统时遗漏某些重要方面的风险,在一般使用中，需求按照功能性,(,行为的,),和非功能性来分类,应用,UML,建模过程,功能性需求,功能性或行为性需求详细描述了系统必须能够执行的动作。也称为系统功能。,功能性需求应该进行分类，以便分开各类功能的优先次序和识别出哪些是理所当然应该具备的系统功能。,分类包括：明显的：应该履行的功能，并且用户应该知道这个功能是否已经被履行,隐藏的：应该履行的功能，但功能的履行对用户不可见。很多使用底层技术的服务符合这种情况,修饰性的：可选的，增加这样的功能不会对成本和其他系统造成重要影响,应用,UML,建模过程,比如一个,POS,机的功能描述：,基本功能,标号,(Ref#),功能 分类,R1.1,记录在线的销售,-,卖出的商品 明显的,R1.2,计算当前的销售总额，包括税和优惠折算 明显的,R1.3,从条形码中获取被购买商品信息，从条形码,扫描仪中输入或人工录入产品代码 明显的,R1.4,当一次销售被提交给系统后，则消减库存量 隐藏的,R1.5,记录完整的销售信息 隐藏的,R1.6,出纳员要使用系统，必须输入,ID,号和密码才能登陆进入系统 明显的,R1.7,提供一个持久化存储机制 隐藏的,R1.8,提供过程间的和系统间的通信机制 隐藏的,R1.9,显示记录下来的商品说明、商品价格 明显的,应用,UML,建模过程,处理支付的功能,标号,Ref#,功能 分类,R2.1,处理现金支付，记录实付款额，计算应还款额 明显的,R2.2,处理信用卡支付，从读卡机中读入信用卡信息或,人工录入信用卡信息，通过调制解调器远程连接,到商店外部的信用卡授权服务机构来为顾客的信,用卡支付提供授权服务 明显的,R2.3,处理支票支付，人工录入信息并为支付授权,通过调制解调器远程连接到商店外部的支票授权,服务机构来为顾客的支票提供授权服务 明显的,R2.4,将信用卡支付的款项记录到应收款系统中去，,因为信用卡授权服务机构应支付给商店这些款项 隐藏的,应用,UML,建模过程,功能性需求使用两种工具进行研究和记录，一种是用例模型，另一种工具是构想工件中的系统特性列表,非功能性需求也称为质量属性、质量需求或系统属性。这些需求包括可用性、可靠性、性能和可支持性。,属性 细节和边界约束,响应时间,(,边界约束,),记录一个销售项时，被售商品的描述和价格必 须在,5,秒钟之内显示出来,界面形式,(,细节,),基于表的窗口和对话框,（细节）尽量方便的键盘导航，而不是指针导航,容错 （边界约束）即使电源或设备发生故障，也必须在,24,小时内将授权的信用卡支付记录到应收款系统中去,操作系统平台 （细节）,Microsoft Windows 98,和,NT,应用,UML,建模过程,非功能性需求被记录在与之相关的用例中或“补充规范”中,用例模型,用例是代表系统中各个项目相关人员之间就系统行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。提出请求的项目相关人员称为,Primary actor,。,Primary actor,通过发起与系统的一次交互来实现某个目标。系统对任一执行者所作出的响应，要保证所有项目相关人员的利益不受侵犯。根据,Actor,作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景,(scenario,应用,UML,建模过程,用例重要概念：,范围,(scope),：,真正被讨论的系统是什么？,primary actor,：,谁有要实现的目标？,层次,(Level),：,目标的层次是高，还是低？,用例的常用定义：,actor,：,任何具有行为的人或物,项目相关人员,(stakeholder),：,对被讨论系统,(,SuD,),的行为有特定兴趣的人或物,primary actor,：,启动与被讨论系统的一次交互活动，从而达到某一目标的人或物,use case,：,规定被讨论系统行为的契约,范围,(scope),：,界定被讨论的系统,前置条件和保证,(precondition and guarantee),：,在用例执行之前和之后必须满足的条件,主成功场景,(main success scenario),：,一切顺利的情况,扩展,(extension),：,场景执行过程中出现的不同情况,应用,UML,建模过程,需求和用例,用例就是需求：用例可以准确地对系统不需要做什么进行详细描述，即用例是功能性需求，按照,FURPS+,需求类型来分，用例强调了,F,（,功能性或行为性）用例不是所有的需求，用例不详细描述外部接口、数据格式、业务规则和复杂公式。用例只是需要收集的所有需求中的一部分。,如何发现,Actor,？,谁是你的系统的主要客户？谁从你的系统取得信息？谁为你的系统提供信息？谁安装系统,?,谁操作系统？谁关闭系统？有什么其他系统与该系统进行交互？在某一预设时间，是否会有什么事情自动发生？谁提供、使用或删除来自系统的信息？系统从什么地方得到信息？,应用,UML,建模过程,如何确定用况？,扮演这种角色的用户希望完成什么工作？为了充当这一角色，用户需要具备什么能力？充当这一角色的用户的主要任务是什么？充当这种角色的用户需要检查、产生和改变什么信息？系统需要提供给这种角色的用户什么信息？充当这种角色的用户需要向系统提供什么信息？,细化,Actor,和,Use Case(,见详细例子,),Use Case,的目标和范围（如何发现有效用例）：用例应该在什么级别和范围上表述呢？指导原则：应专注于基本业务过程,(EBP),级别的用例。,Actor,都有自己的目标（或需要），并使用系统来帮助自己实现目标。因此，一个,EBP,级别上的用例通常称为一个用户目标级别上的用例，以强调用例应该帮助系统用户：找出用户的目标为每一个目标定义一个用例,应用,UML,建模过程,用例建模常见问题,没有系统用例：提取现金范围：,ATM,系统级别：用户目标级主执行者：储户,1.,储户插入,ATM,卡，并键入密码,2.,储户按取款按钮，并键入取款数目,3.,储户取走现金、,ATM,卡并拿走收据,4.,储户离开,没有主执行者用例：提取现金范围：用户目标级主执行者：储户,1.,收集,ATM,卡，键入密码,2.,收集取款事务类型,3.,收集提取金额,4.,验证帐户上是否有足够储蓄金额,5.,输出现金、收据和,ATM,卡,6.,复位,应用,UML,建模过程,过多的用户接口细节用例：买东西级别：用户目标级主执行者：顾客,1.,系统显示输入,ID,及密码屏幕,2.,顾客键入,ID,及密码，然后,OK3.,系统验证顾客,ID,及密码，并在屏幕上显示个人信息,4.,顾客键入姓名、街道地址、城市、省、邮编、电话号码，然后按,OK5.,系统验证是否为老客户,6.,系统显示可用商品列表,7.,顾客选取要购买的商品及数量，完成时按,Done8.,系统通过库存辅助系统验证购买商品是否有足够库存,.,过低的目标级别,目标和内容不符,应用,UML,建模过程,用例的合并用例的合并是将一些同类或相似的用例合并起来的过程，这样使系统看上去更有层次感，更为明确，也更易于管理。功能性合并合并的过程就是按照相同的功能对业务用例进行合并，然后提取公共的名称和功能性描述词汇形成用例名称。如电子邮件撰写和合同录入合并为文档录入，邮件查看和合同查看合并为文档查看等。,应用,UML,建模过程,业务性合并合并的过程按照业务相关性，将同一业务相关的操作过程合并起来，提取业务名称加上“管理”两个字，形成用例名称。如：把电子邮件撰写、邮件查看等邮件相关的合并为邮件管理，把合同录入、合同修改、合同删除、合同查看等合并为合同管理。,用例的拆分,用例分包,分包的目的：,1.,为了让系统用例图能更清晰地表现出系统的业务逻辑关系和层次，让用户能够通过开发人员的描述看到他们自己的业务结构，并对此认可。,2.,为了对系统进行模块的分割，这种分割将影响到系统今后的开发及系统的最终表现形式。,应用,UML,建模过程,分包的基本原则：,1.,业务相关性：根据业务所属关系对用例进行分割划分，形成系统的业务包和子系统,2.,功能相似性：根据用例的功能关联关系，将功能实现相似的用例组合在一起形成系统的业务包和子系统。,分包的过程：第一步先考虑业务相关性原则，进行第一层分包。对于较大系统，可以考虑功能相似性原则进行第二层分包。在完成了业务相关性分包之后，在进行同一业务的功能相似性划分可以提高系统某一模块的内聚性，同时，对于较大系统才可以划出比较有效的子系统，提高开发效率和成果。,应用,UML,建模过程,关于用例部分请参考：编写有效用例,Cockburn,有效用例模式,SteveAdolph,需求可追踪性,可追踪性就是理解怎样把高层的需求，即目标、渴望、期望、需要如何转换为下层需求，主要关注的是信息层次之间的关系在业务背景下，人们可能关心：业务远景目标如何解释为业务目标业务目标如何实现为业务组织和过程在工程背景下，人们可能关心：,stakeholder,需求如何被系统需求满足系统需求如何划分为子系统子系统如何实现为组件,利用可追踪性可以在以下方面获得收益：,应用,UML,建模过程,更有把握达到目标。建立和构造可追踪性，可更好地反映目标是如何被满足的。,能够评估变更的影响。只有在存在可追踪性信息的情况下，各种形式的影响分析才有可能,改进下级机构的可审计性。可以清晰地反映供应商对整体的贡献,能够跟踪进度。如果所作的只是创建和修改文档，则很难度量进展。围绕可跟踪性的过程能够精确度量早期阶段的进展,能够平衡成本与收益。将组件与需求关联起来，可以针对成本评估收益,应用,UML,建模过程,可追踪性实际上是多对多关系,-,即一个下层需求可能与多个上层需求关联，一个上层需求也可能与多个下层需求关联,。,可追踪性分析的类型影响分析来源分析覆盖率分析,全局分析,全局分析侧重于定义拟建系统所采用的构架以及影响构架的要素。全局分析充分利用相似或问题中的经验，避免在确定构架上浪费人力和物力。,选用架构模式,识别关键抽象：寻找那些无论在问题域或方案领域都具有普遍意义的概念点。,标识分析机制：将那些问题领域（应用逻辑）没有直接关联的计算机概念及相应的复杂行为表述为支撑分析工作的“占位符”。,选定分析局部：针对拟建系统的整体架构，找出那些蕴含相对高风险的局部作为工作内容。,全局分析,识别“关键抽象”活动的主要依据是词汇表、,Use Case,报告和既往的经验。,关键抽象的含义：业务需求和软件需求中通常会揭示拟建系统必须处理的核心概念，这些概念同样将成为设计模型中的核心要素。关键抽象，就是那些能够始终贯穿分析和设计的类及相应对象。关键抽象往往对应重要的实体信息。,全局分析,确定分析机制,确定分析机制的主要依据是“补充规约”、既往的经验以及关键抽象（概念模型）；结果是一组被识别出来的“分析机制”。,什么是分析机制？,在分析过程中，“分析机制”向设计人员提供复杂行为的简明表述，降低（全局）分析活动的复杂性并提高（局部）分析活动的一致性。通过这些机制，可以使分析工作更有重点。借助分析机制，可以姑且不深究那些用于支撑核心功能（应用逻辑）但其自身并非核心功能的复杂行为，这些内容通常是解决特定软件技术问题的设计经验。分析机制提供概念化的服务模式，“分析类”将使用这些服务模式的实例。分析机制的实例在系统架构中充当某些复杂行为的“占位符”。运用分析机制，可以避免分散全局分析的任务工作重点。一个比较典型,例子是数据存取问题，事实上这并不是一个简单的问题，但却是一个很普遍的问题，如果在分析和设计的初期就陷入数据存取功能的细节，势必严重影响设计人员对整体架构的把握。在全局分析任务中，可以利用一个称作“留存”（,Persistency,）,的分析机制封装相关的技术细节。分析机制通常与应用逻辑中的特定内容关系松散，分析机制大多只涉及计算机软件技术的概念和要素。分析机制为那些与应用逻辑密切相关的要素提供必要的软件技术支撑，根据层次架构的基本原则，用于实现分析机制的涉及内容大多位于构架的中低层。,全局分析,常见的分析机制,留存分布式处理安全性进程间通信消息路由进程控制与同步交易事务管理信息交换信息的冗余错误检测、处理和报告数据格式转换,全局分析,安全,留存,分布处理,信息交换,报销单,报销记录,员工,经理,工资户头,全局分析,选定分析局部：选定分析局部活动的主要依据是整体的,Use Case,模型和基于以往经验的风险判断。,Use Case,优先级 风险,调整策略,结算当月报销费用,批复报账申请,审核报账申请,提交报销申请,提交借款申请,完成日常维护,制作报表,登录系统,1,数据库的响应速度,2,数据库的容量,3,与内部邮件系统的连接,4,与银行系统连接,5,与人事管理数据库连接,6,内部网有足够的带宽,7,数据备份,局部分析,提取分析类,转述需求场景,整理分析类,局部分析,提取分析类,针对用例模型中每一个,Use Case,定义系统的分析元素如何为,Use Case,提供相应的行为。分析类的定义和描述与,Use Case,流建模是同时进行的。,确定分析类分析类是概念层面的内容，与应用逻辑直接相关。分析类的实例所具备的行为，用于捕获拟建系统对象模型的雏形。分析类直接针对软件的功能需求，因而分析类的实例的行为来自于对软件功能需求的描述,(Use Case),。,在使用分析类的时候，姑且不必关注某些与应用逻辑不直接相关的细节，特别是那些纯粹的软件技术问题。在某种意义上，可以认为分析类是技术解耦的。,局部分析,分析类的类型划分,众多实践表明，如果立足于软件功能需求，拟建系统往往在三个维度易于发生变化：一、拟建系统和外部要素之间交互的边界；第二，拟建系统要记录和维护的信息；第三，拟建系统在运行中的控制逻辑。通常按照这三个变化因素的维度，将分析类划分为三种类型：边界类、控制类、实体类,系统边界,Use Case,行为协调,基本信息,局部分析,边界类的含义,用于描述拟建系统外部环境与内部运作之间的交互，主要负责内容的翻译和形式的转换，并表达相应的结果。边界类主要用于描述三种类型的内容：拟建系统和用户的界面，拟建系统和外部系统的接口以及拟建系统与设备的接口。不同类型边界的建模工作有所不同。如与外部系统接口主要关注通信协议；用户界面的建模主要关注交互内容，在概念上表达整个界面，而不是具体窗口体构件。,控制类含义：通常控制类用于描述一个,Use Case,所特有的事件流控制行为。控制类相当于协调人，被那些提出具体任务要求的类所共知：它自己通常不处理具体的任务，但它知道哪些类有能力完成具体的任务。控制类将,Use Case,所特有的行为进行封装，具有良好的隔离作用概念上，拟建系统的其他部分（边界类和实体类）将与,use Case,具体执行逻辑形成松散耦合。,局部分析,实体类的含义,实体类用于描述必须存储的信息，同时描述相关的行为。实体类代表拟建系统的核心信息，是拟建系统的重要部分，通常需要长期保存。,提取分析类就是确定一组备选的、能够执行,Use Case,中行为的分析类。从文字说明的软件需求过渡到图形描述的设计内容是一个渐进的过程，提取一组备选的分析类是这个过程的第一步。为了获得高内聚、低耦合的设计，使用三种不同的构造型识别和划分候选的分析类边界类：通常一个,Actor,和,Use Case,之间的通信关联对应一个边界类控制类：通常一个,Use Case,对应一个控制类实体类：在全局分析中的概念模型（关键抽象）集合,局部分析,分析类在模型中的位置,在全局分析任务中，“关键抽象”位于一般应用层的关键抽象包；在局部分析任务中，分析类通常分布在特定应用层和一般应用层,-,控制类通常放在特定应用层,-,从特定的分析局部中发掘的实体类通常放在特定应用层,-,表述用户界面的边界类放在特定应用层,-,表述外部系统接口的边界类放在一般应用层,局部分析,边界类的复用边界类实例的适用范围和生命周期可能超越特定的,Use Case,的时间流内容。如果两个,Use Case,同时和一个外部因素,(Actor),交互，它们往往可以共用同一边界类，因为它们表现的行为和承担的责任有可能存在很多复用的内容,局部分析,控制类的变通控制类实例的适用范围和生命周期通常和特定,Use Case,的事件流内容匹配。一个特定的,Use Case Realization,对应一个控制类是典型的情况。,-,如果不同,Use Case,包含的任务之间有比较紧密的联系，某些控制类可以参与多个,Use Case Realization,。,局部分析,换言之，不同的控制类可以参与同一个,Use Case Realization,。,注意，这只是一种可能性，目的是重复利用相似部分从而降低整体的复杂性。通常，在明确多个,Use Case Realization,之后，才有可能发现它们之间的相通之处，在此基础上，这种做法才可能带来积极效果。不应该以此为目标，否则会适得其反。,局部分析,-Use Case Realization,未必一定需要控制对象。在,Use Case,事件流的逻辑结构非常简单的情况，边界类有可能在相关实体类的协助下实现相应,Use Case,的行为。简言之，如果,Use Case Realization,中的控制逻辑过于简单，那么（承担这类责任）控制类的必要性明显降低。,局部分析,实体类的建议实体类实例的适用范围和生命周期可能超越特定,Use Case,的事件流内容。实体类通常不是某一特定,Use Case Realization,所专有。以下是针对提取实体类的一些建议：,-,充分利用关键抽象和已经被识别出来的分析类，可能是以往迭代中识别出的分析类，或者是当前迭代中从其它分析局部识别出的分析类,局部分析,-,有时，和,Use Case,相关的,Actor,会在系统内部有一个实体类与之对应，尤其当该,Actor,的相关信息（属性、操作和关联）对实现拟建系统行为有直接贡献的时候。当然，,Actor,和与之相应的实体类在概念上截然不同，通俗讲，就是“内外有别”。,-,实体类不仅仅包含数据信息，还包含面向数据操作的行为，甚至是相当复杂的行为。,局部分析,-,如果有一个拟建的实体类,A,仅仅被另一个类,B,引用，并且实体类,A,不具有明显的行为特征；那么可以考虑将实体类,A,作为类,B,的属性；相反，如果需求中的某一实体信息有可能被多个类引用，或者该实体信息具有显著的行为特征，通常将其建模为一个独立的实体类。,局部分析,构造型的可选性分析类的构造型有助于更加清晰地展现分析活动的结果，目的是显式地提高团队对模型内容的管理和理解效率。但是，这并不意味着在局部分析活动中一定要使用分析类的构造型。从逻辑上讲，每个分析类都会归属于边界、控制或者实体中的某一维度。但是，如果从事分析的人员对不同分析类所属维度有清楚的理解，分析类构造型可以被隐含，不做显式表达。客观上，顺利地进入设计阶段后，分析类的狗造型将不再起实质作用。,局部分析,转述需求场景转述需求场景活动的主要依据是,Use Case,报告中的用文字描述的事件序列（需求场景）；该活动