UML核心元素.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,UML,核心元素,版型,(stereotype),有些书也称类型、构造型,对,UML,中元素基础定义的扩展,UML,中每一种元模型很多版型,如，用例有“业务用例”、“业务用例实现”等,类，“接口”、“边界类”、“实体类”,参与者,以人为本,基本概念,参与者,在建模过程中处于核心地位,UML,官方文档的定义：,actor,是在系统之外与系统交互的某人或事物,参与者,系统有一个边界，参与者在边界外，边界内的都不是参与者,问题：谁是参与者,例如：小王去银行开户，向大堂经理询问如何办理手续，填写表但，参给柜台职员，拿存折,通过回答以下两个问题来确定,谁对系统有明确目标和要求并且主动发出动作,系统为谁服务,参与者,官方文档，参与者有另一种叫法：主角,主动启动了业务的，才是参与者,那么刚才问题中的经理和职员呢？,业务工人,参与者可以非人,定时器,发现参与者,情况,1,：机票购买者通过登陆网站购买机票,情况,2,：机票购买者通过呼叫中心购买机票,发现参与者,情况,3,：购买者通过呼叫中心自动语音预定机票,情况,4,：扩大系统边界,业务主角,软件项目中，业务范围和系统范围不同,业务范围,指这个项目所涉及的所有客户业务，这些业务,没有计算机参与都可观存在,系统范围,指软件要实现的那些对应业务功能的,系统功能,，从功能性需求看，是业务范围的一个子集,有些系统功能可以超出业务范围,业务主角,业务主角,(business actor),是参与者的一个版型，用于定义业务的参与者,状对的业务人员，非计算机用户,在初始需求阶段，需要获得客户的业务模型，根据业务模型建立计算机模型，,此时如何引入计算机系统的概念，就会混淆,要建立一个符合客户需要的计算机系统，首要条件是,完全彻底搞清楚客户的业务,，而,不是预先假设,已有一个计算机系统，再让客户假象计算机系统帮他们做什么,业务主角,业务主角的重要性,建立业务模型，查找业务用例都必须,使用业务主角,，而不是普通参与者,初始需求阶段,业务主角是客户,实际业务里,的参与者,没有计算机，没有抽象的计算机角色,业务主角是在实际业务里能找到对应的岗位或人员,业务工人,参与者,位于系统边界外，如果把边界内和外的参与业务的人都作为参与者建模，会混乱,主角和配角,参与者,主角,业务工人,配角,如何区分,是否主动向系统发出工作,是否有完整的业务目标,系统是否为他服务,参与者与用户,参与者与用户的关系,用户,系统的使用者,系统的操作员,用户,参与者的代表,问题,是否所有的参与者都是用户？,参与者与角色的关系,角色,参与者的职责,是一个抽象的概念,一个角色代表了系统中的一类职责,问题,参与者、用户、角色什么关系,用例,UML,建模中,最最,重要的一个元素,除了用例之外，其他所有元素都是“封装”的，“独立”的,那些元素在没有“外力”的情况下，“老死不相往来”,用例就是施加这一“外力”的元素,用例,用例概述,1987,年才有了一个正式的名字：,Use Case,一种把现实世界的,需求捕获,下来的方法,一个系统是由各种各样的愿望组成的，各种各样的人为了各自的目的作各种各样的事情，组成了一个系统,如果需要描述一个系统的功能性需求，就要找对这个系统有愿望的人，说明会在这个系统作什么，想要什么。所有想做的事情都找全了，系统的功能性就确定下来了,用例,概述,所谓用例，就是一件事情，要完成这件事情，需要一系列活动,做一件事情可以有很多不同的方法和步骤，也可能会有各种各样的意外情况，因此这件事情由很多不同情况的集合构成，在,UML,中称为,场景,一个场景就是一个用例的实例,例子：做一顿饭,用例,做一顿饭,需要完成什么主要事情,需要什么原材料才能做,成果是什么,用例,做一顿饭,煮饭,电饭锅,蒸笼,炒菜,启动用例需要条件,米,水,结果,生米,熟饭,一个完整的用例：参与者、前置条件、场景、后放条件,两种不同场景,用例特征,特征,1,：用例相对独立,不意味不与其他用例交互而独立完成参与者目的，从,“功能”上是完备,的,体现系统,参与者的愿望,例如：取钱,有效用例；填写取款单,非有效用例,特征,2,：用例的执行结果对参与者来说可,观测和有意义,后台进程监控,：在需求阶段不应该作为用例出现，应该作为系统需求在补充规约中定义,例如：登陆系统,有效用例,输入密码,非有效用例,用例特征,用例特征,特征,3,：这件事由一个参与者发起。,特征,4,：用例必然是以动宾形式出现,用例特征,特征,4,：一个用例就是需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元,用例的粒度,规则,业务建模阶段,一个用例描述一,项,完整的业务流程,例如：取钱，报装电话，借书,而不是填写申请单、查找书目,概念建模阶段,用例能描述,一个,完整的事件流,可以理解为一个用例描述一项完整业务中的,一个步骤,需要归纳和抽象出业务用例中的,关键概念模型,并为之建模,如：宽带业务中有申请报装和申请迁移地址用例，在分析时，可归纳和分解：提供申请资料、受理业务、现场安装等多个业务流程,系统建模阶段,用例视角是针对计算机，用例的粒度以一个用例能够描述操作,与,计算机的一次完整交互,为宜,如：填写申请单、审核申请单、派发任务,可以理解为一个操作界面或者一个页面流,用例的粒度,例子,描述一栋建筑,这栋楼有,10,层，下水道在厨房东南角，预留,15,个插座，共有,5,个单元,问题在哪里？,用例的粒度,用例的粒度,系统管理员修改订单的目的是服务于购买商品用例的，并不是一个完整的目标，它只是购买商品过程的一个步骤而已,用例的获取,用例的,来源,参与者对系统的期望,发现用例的,前提,发现参与者,确定参与者的同时就确定了系统边界,原则,主角在,系统外,主角对系统有,明确期望和明确回报,主角的期望和回报要求,在系统之内,获取用例,对主角,(,业务代表,),访谈,不需要,描述整个业务流程,不要,涉及填写表单,只需要,让业务代表从本职工作谈谈愿望,问题如,您对系统有什么期望,您打算在这个系统作什么事,你做这件事的目的是什么,做完这件事希望有一个什么样的结果,通过访谈结果，从中找出用例,确保,一个用例有,明确有效,的目标,一个真实的目标应完备地,表达主角的期望,一个有效的目标应当在系统边界之内，由主角发动，具有明确后果,获取用例,判断一下哪些是有效用例,支持跨行业务,插入卡片,输入密码,选择服务,取钱,存钱,挂失卡片,缴纳费用,警示骗子,三次错误吞没卡片,获取用例,判断一下哪些是有效用例,支持跨行业务,N,，这是一个业务规则，限定业务范围,插入卡片,N,，这是一个过程步骤，不是完整目标,输入密码,N,，这是一个过程步骤，不是完整目标,选择服务,N,，这是一个过程步骤，不是完整目标,取钱,Y,，这是一个有效的完整目标,存钱,Y,，这是一个有效的完整目标,挂失卡片,Y,，这是一个有效的完整目标,缴纳费用,Y,，这是一个有效的完整目标,警示骗子,N,，超出业务范围,三次错误吞没卡片,N,，这是一个业务规则，限定业务条件,用例与功能,实际中一种普遍的错误：用例,=,功能,功能描述：输入,-,计算,-,输出。,用例不是功能,用例与功能,描述事物,这个事物是什么,结构性观点,，从结构上说，一个圆环，用在汽车上是方向盘，用在自行车上，是轮子。所以结构性观点不足够,这个事物能做什么,功能性观点,，说明事物可利用的价值，但不够说明事物在某种情形下的真正价值，因为缺乏了上下文，没有人来使用，事物的价值就可能没有意义,人能能用这个事物做什么,使用者观点,，说明事物对于使用者的意义，以及使用者如何使用它，获得什么利益。,用例与功能,对于,熟悉的事物,，我们可以从这三方面描述，把事物解释清楚，例如自行车,但是对于我们,并不熟悉的事物,，从不可能从结构去解释它，最可能是,通过观察假定这个事物能做什么,进一步地，如果这个事物,还不存在,，就不能从结构上去解释它，也不能确定它能做什么,对于创造一种还不存在的事物，,最好的方式是从使用者的角度出发,，描述希望这个事物的使用者能用它做什么，能获得什么,软件就是一种,还不存在的事物,，对于正准备开发的软件，我们无法从结构观点描述它，也不能从功能观点描述它，最好的发法就是,从使用者的观点描述它,用例与功能,从使用者观点出发描述软件是非常适合的,使用者观点告诉需求收集人员，它希望这个系统是什么样，他将怎样使用这个系统，希望获得什么结果，那么软件按照使用者要求提供实现，就,不会偏离使用者的预期,使用者的观点实际上就是,用例的观点,，一个用例就是一个参与者如何使用系统，获得什么结果的一个集合,通过分析用例，得出结构性和功能性的内容，最终实现用例，也就实现了用例的观点,用例与功能,总结：,功能是脱离使用者愿望存在的,我们常常说工具具有某个功能，描述的是,工具,，不是站在使用者角度描述使用者的愿望的,功能用来描述某某东西能做什么，与使用者的愿望无关，描述的是,事物固有的性质,用例描述的是使用者的愿望，对系统的使用要求,功能是孤立的,给一个输入，通过计算就有一个,固定的输出,性能描述是,一个个点,，如何要达成一个特定目标，需要额外加上一个顺序的过程把点串起来,用例描述的事一个系统性的工作，这个系统性的工作非常明确区达成一个系统性的目标,目标和步骤,一个用例是使用者对目标系统的一个愿望，,一个完整的事件,为了完成这些事件，需要经过很多步骤，但是这些步骤不能完整地反映参与者的目标，不能作为用例,业务用例,业务用例时用例版型中的一种，专门用于,需求阶段的业务建模,针对客户业务的模型，也就是现在客户的业务是怎么来建立的,严格来说，业务建模,与计算机模型无关,，只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在业务层面上和客户达成共识,例如：图书馆借书系统。我们明明知道计算机可以自动提示读者逾期没有归还图书，但是在业务建模时候不应该将计算机包括进来,之所以不能把计算机引入，是因为,业务范围不等于系统范围，,不是所有的业务都能用计算机来实现，不在计算机中实现的业务就,不进入系统范围，就不能作为一个需求,业务用例实现,也称为用例实例,专门用于需求阶段的业务建模,业务用例实现就是业务用例的一种实现方式,根据业务用例实现得出关键业务对象，再从业务对象转化为设计对象,概念用例,用来获取业务模型中的,关键概念,，分析出业务模型中的核心业务,系统用例,系统用例,就是我们所说的用例,定义系统范围、获取功能性需求的,系统用例是软件系统开发的全部范围,业务实体,业务实体是类的一种版型,业务实体来自,现实世界,，建模的问题领域里一定能找到与它相对应的事物，这个事物是参与者在完成目标的过程中使用到的或创建,例如,请找出饭店中的业务实体,请找出机场中的业务实体,业务实体不一定对应具体事物，也可以表示一个现实中的,概念,业务实体,机场,机票、登机牌等等,饭店,菜单、饮料等等,业务实体,业务实体一定是在分析,业务流程,中发现的,业务流程实际上就是业务场景,这意味着业务实体,至少被一个业务用例场景使用或创建,，如果对业务场景没有贡献的事物，即使它是客观存在的，也不应当为它建模,例子,一个寄信人到邮局寄信：到达邮局，购买信封，将信装入信封，写上地址，称重，计算邮资，购买邮票，贴上邮票，邮寄信件，拿回执,问题：这里面哪些是实体,从业务用例场景中逐个分析出动词后面的名词，它们就是候选业务实体,邮局、信、信封、地址、邮资、邮票、信件、回执,邮局是一个场所，去掉,邮资作为邮票的属性,地址作为信封的属性,业务实体,包,包是一种,容器,，如同文件夹一样，将某些信息分类，形成逻辑单元,好的分包具有高内聚，低耦合的性质,分包有一些指导性原则,假设将元素分为三个包：,A,B,C,，那么被分入同一个包种的元素应到具有,互相联系紧密,，甚至密不可分，这些元素具有某些相同的性质，使得包可以抽象出一些接口来代表包内事物与包外事物交互，避免包外的事物频繁地直接访问包内元素,包最理想的情况是修改,A,，,B,，,C,三个包中的任意一个包的元素，其他任何一个包的内容,都不受到影响,，此时，称,A,B,C,三个包之内无依赖关系或松耦合关系，他们之间可以保持消息通信,实际中，完全解决依赖关系难以做到，至少保证包之间的依赖关系不会被传递。如,B,依赖于,A,，,C,依赖于,B,，当,A,修改导致,B,要做出修改时，,C,不会受到影响，如果做不到这点，当一个包发生变动时，会引起大范围连锁反应,包之内的依赖关系应当是,单向的,，避免双向依赖和循环依赖,包,包的版型,领域包,用于分类,业务领域内,的业务单元，每个包代表业务的一个领域,领域包视图可用于展示这些,业务领域,的高层次关系,包,子系统,用于分类系统内的,逻辑对象,并形成子系统。子系统包视图可用于展示,系统的高层次逻辑结构,关系,包,组织结构,用于分类业务领域中的,组织结构,，直接用来描述企业的组织结构,包,层,用于分类软件中的层次，层次用于展示软件的架构信息,包,可以自定义需要的版型，从特定角度分类元素,包是,UML,中随意性最大的，好包将帮助你更好地组织元素,分析类,分析类代表系统中主要的“职责簇”,，意味着分析类是从功能性需求向计算机实现转化过程的“第一个关口”,分析类可以产生系统的设计类和子系统，意味着计算机实现时可以通过某种途径“产生”出来的，而不是拍脑袋出来的,分为,边界类，控制类，实体类,分析类,边界类,用于对系统,外部,环境与其,内部,运作之间的,交互,进行建模的类,现实世界中，边界类实例可以是：窗口、通信协议、打印机接口、传感器、终端,计算机世界里，边界类可以使一个消息中间件，一个驱动程序，一组对象接口甚至任意一个类,参与者与用例之间,应当建立边界类,用例与用例,之间如何有交互，应当建立边界类,控制类,控制类,用于对一个或几个用例所特有的,控制行为,进行建模,通常控制其他对象，因此它们的行为具有,协调,性,控制类将用例的,特有行为进行封装,也就是说，控制类来源于对用例场景中,动词的分析和定义,例子,一个寄信人到邮局寄信：到达邮局，购买信封，将信装入信封，写上地址，称重，计算邮资，购买邮票，贴上邮票，邮寄信件，拿回执,其中哪些可以成为控制类的来源,控制类,例子,一个寄信人到邮局寄信：到达邮局，购买信封，将信装入信封，写上地址，称重，计算邮资，购买邮票，贴上邮票，邮寄信件，拿回执,其中哪些可以成为控制类的来源,购买、装入、写上、计算、称重、购买、贴上、邮寄，拿,其中的人工行为可以舍去：装入、写上、称重、贴上、邮寄，拿,UML,定义中，控制类主要起,协调对象,的作用，如从边界类通过控制类访问实体类，或者实体类通过控制类访问另一个实体类,实体类,实体类用于对必须,存储,的信息和相关行为建模的类,出于系统结构优化需要，一些业务实体可以在后续的过程中被分拆、合并,设计类,设计类是系统实施中一个或者多个对象的,抽象,设计类所对应的对象取决于,实施语言,设计类用于设计模型中，直接使用与编程语言相同的语言描述,设计类已经直接映射到实现代码，设计类依赖于实现语言,设计类,来源于前期的系统分析,，类不是凭空想出来的，可以一一映射到前期系统分析的成果物上,关系,在,UML,中，关系是重要的语义,关联关系,用一条直线表示，,AB,，描述不同类的对象之间的结构关系,关联关系表示一个对象了解其他对象，即关联关系描述了某个对象在一段时间内一直“,知道,”另一个对象的存在,例如：,A,对象保存了,B,对象的,ID,，因此，,A,对象“知道”,B,对象存在,在,Rose,中，为了区分相互“知道”和单向“知道”的关系，定义了关联关系的另一个变体，即单向关联关系，如,A,B,，说明,A”,知道”,B,，而,B”,不知道”,A,在用例模型中，单向关联关系用于连接参与者和用例，箭头由参与者之相用例，表示,参与者“知道”用例存在,关系,依赖关系,用带箭头的虚线表示，如,A-,B,（,A,，依赖于,B,），描述这样一种关系：,一个对象的修改会导致另一个对象的修改,与关联不同，依赖关系除了“知道”其他对象存在，还会“,使用,”其他对象的属性或方法,如,A,对象,使用,了,B,对象的属性或方法，则,B,的修改会导致,A,的修改，此时,A,依赖于,B,双向依赖是一种不好的结构，应该保持单项依赖，,杜绝双向依赖,关系,扩展关系,A-B(A,扩展出,B),，用于在用例模型中说明,向基本用例中的某个扩展点插入扩展用例,扩展用例带有抽象性质，表示用例场景中的某个“,支流,”，由特定的扩展点,触发而被启动,与包含关系不同，扩展表示“,可选,”，而不是“,必需,”，这意味即使没有扩展用例，基本用例也是,完整,的，如果没有基本用例，扩展用例,不能单独存在,如果有多个扩展用例，同一时间用例实例也只会使用其中一个,例子，通话过程中收到另外一个呼叫，可以将当前通话保留而接听另一个通话,关系,包含关系,A-,B(A,包含,B),，特别用于用例模型，说明在执行基本用例的用例实例,过程中插入的行为段,包含用例带有抽象性质，基本用例可以,控制,与包含用例的关系，并可,依赖于,执行包含用例所得的结果，但基本用例和包含用例,都不能访问对方的属性,包含用例是被封装的，代表可在各种不同基本用例中,复用,的行为,与扩展用例不同，包含用例表示的是“,必需,”，而不是“可选”，这意味不包含用例，基本用例就不完整，同时如果没有基本用例，包含用例就,不能单独存在,例如：银行办业务，取钱、转账和修改密码，都需要核对帐号和密码，那么这个行为可以抽取出来，形成一个包含用例，这个包含用例带有复用的意义,如果缺少包含用例，取钱，转账等业务用例不完整，核对帐号也不能脱离取钱、转账等业务用例而单独存在,关系,实现关系，,A-|B(A,实现,B),，用于用例模型中连接用例和用例实现，说明基本用例的一个实现方式,基本用例描述一个业务目标，该业务目标,有多种可能的实现途径,，每一种途径可以用用例实现来表示，用例实现和基本用例之间构成实现关系。即，每个实现途径都实现了基本用例的目标,关系,精化关系,特别用于用例模型,一个基本用例可以分解出许多更小的关键精化用例，这些小的精化用例展示了基本用例的,核心业务,与泛化关系不同，精化关系表示由基本对象可以分解更明确、精细的子对象，这些子对象,并没有增加、减少、改变基本对象的行为和属性,，仅仅是更加细致和明确化了,从业务模型中分析出实现业务目标的那些核心行为和实体，从而描述从一个关键的业务结构得到一个易于理解的业务框架，这些关键概念就是对业务用例的精化,关系,泛化关系,表示一个类对另外一个类的继承关系,聚合关系,表示实体对象之间的关系，表达整体由部分构成的语义，例如，一个部门由许多人员构成,组合关系,表示实体对象关系，整体拥有部分的语义，例如，车轮是汽车的一部分,