《UML原理与应用》PPT课件.ppt

UML原理与应用,统一建模语言,内容简介,基础知识 用例模型 静态结构 类图 包图 对象图 组成结构图 动态行为 交互图（顺序图、通信图、交互概观图、时序图） 状态图 活动图 物理模型 构件图 部署图,基础知识,什么是UML？ UML发展简史 建模基础知识 UML定义 UML组成 图 视图 使用UML,什么是UML,UML是Unified Modeling Language的首字母缩写，中文通常称为统一建模语言。 UML是一种基于面向对象技术的、可视化的、通用建模语言。不仅可以应用于软件分析、设计，也可应用于其它领域的业务建模。 UML应该与特定的开发过程相关联，如RUP、XP等等。 UML是不是程序设计语言？是文档、程序还是数据？,UML发展简史,人们从二十世纪60年代的软件危机中认识到系统建模的重要性，大型软件系统开发必须以工程学的方法组织。 软件工程的思想使得许多在编程领域首先出现的新技术和新方法，很快拓展到软件生命周期的分析与设计阶段。 因此面向对象编程技术的发展，很快也催生了面向对象建模技术的发展，据统计，到1994年公开发表并有一定影响的OOAOOD方法已达50余种。 各种建模方法客观上都为面向对象技术的发展做出了贡献，但也造成了一定的混乱，急需统一规范。,UML发展简史,UML创始人 Grady Booch是面向对象方法最早的倡导者之一，1984便在著作中讨论了面向对象的基本问题，创建了Booch-91建模方法。 James Rumbaugh提出了面向对象的建模技术即OMT引入了各种独立于程序设计语言的表示符号。 Ivar Jacobson于1994年提出了面向对象软件工程的方法，即OOSE。 同时期的其它建模方法也为UML的诞生做出了贡献，UML是博采众人之长的产物。,UML发展简史,Grady Booch,Grady Booch,Ivar Jacobson,Ivar Jacobson,James Rumbaugh,James Rumbaugh,UML发展简史,1994年10月，同在Rational公司的Booch与Rumbaugh开始致力于统一各种建模语言。1995年秋，Jacobson也加盟到这项工作中。1996年6月发布了UML 0.9。 1997年11月，OMG采纳UML1.1作为面向对象技术的标准建模语言。 此后，OMG的修改任务组（Revision Task Force，RTF）的专家负责对UML不断进行扩充与完善，相继推出了UML1.2、UML1.3（1999年4月），UML1.4（2000年），现在UML的最新版本为UML2.1。 2002年，颁布的UML2.0是UML的一次重大变化，主要是在UML中加入的MDA、SOA的支持。,建模,项目招标 需求分析 概要设计 详细设计 编码和单元测试 集成测试和系统测试 交付实施、系统维护,掐头,去尾,两个月,建模,建模,什么是模型？ 模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在模型中。 通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。 UML作为一种可视化的建模语言，提供了丰富的基于面向对象概念的模型元素及其图形表示元素。,建模,软件开发的过程是将现实业务映射为计算机逻辑的过程，建模在这个过程中越来越重要。,建模,建模功能分解,建模数据流法,建模信息建模,建模面向对象,UML定义,UML定义包括UML语义和UML表示法： UML语义 描述基于UML的精确元模型(meta-model)定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明, 还支持对元模型的扩展定义。 UML表示 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。,UML组成,通常用以下五个概念来说明UML的组成: 图(diagrams) ，UML 2.0划分为两类 结构图（structural diagrams ） 行为图（behavioral diagrams ） 视图(views) ，不是UML的标准内容，即常说的4+1视图 设计视图（Design view ） 实现视图（Implementation view ） 部署视图（Deployment view ） 过程视图（Process view ） 用例视图（Use case view ） 模型元素（Model Element） 通用机制（General Mechanism） 模型驱动体系结构（Model Driven Architecture）,UML组成图,结构图，描述系统系统的物理结构，包括 类图（Class diagrams ） 构件图（Component diagrams ） 复合结构图（Composite structure diagrams） 部署图（Deployment diagrams ） 包图（Package diagrams ） 对象图（Object diagrams ）,UML组成图,UML组成图,行为图，描述系统内元素的行为，包括 活动图（Activity diagrams ） 通信图（Communication diagrams ） 交互概观图（Interaction overview diagrams ） 顺序图（Sequence diagrams ） 状态图（State machine diagrams ） 时序图（Timing diagrams ） 用例图（Use case diagrams ）,UML组成图,UML组成视图,视图 一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图（view）。 视图由多个图（Diagrams）构成，它不是一个图表（Graph）,而是在某一个抽象层上，对系统的抽象表示。 如果要为系统建立一个完整的模型图，需定义一定数量的视图，每个视图表示系统的一个特殊的方面。,UML组成视图,UML组成视图,设计视图 描述系统中类、接口及模式，通常使用类图、对象图、活动图、组成结构图、顺序图等。 部署视图 描述系统如何配置、安装和执行等物理信息，也包括硬件分布、通信等硬件信息。通常由构件图、部署图和交互图组成。 实现视图 描述系统中的构件、文件和资源，主要是指明设计视图中类由谁来实现。,UML组成视图,过程视图 描述系统的并发性、性能以及运算规模等等信息，通常使用活动图、交互图描述系统在运行时的这些信息。 用例视图 描述系统的外部特征、系统功能等。通常由用例图描述。所谓41视图中的1就是指用例视图。其中4个视图描述系统内部的各方面特征，1个视图则站在用户角度描述系统看起来是什么样的。,UML组成视图,模型元素 代表面向对象中的类，对象，关系和消息等概念，是构成图的最基本的常用的元素。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示。 通用机制 用于表示其他信息，比如注释，模型元素的语义等。另外，为了适应用户的需求，它还提供了扩展机制(Extensibility mechanisms) ，包括板型(Stereotype)、标记值(Tagged value)和约束(Constraint).使用UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。,使用UML,你要做什么？ 狗窝？摩天大楼？,使用UML,使用UML,用UML画图是很容易的，但知道要画什么是很困难的,摆脱符号烦恼,全心面对问题,使用UML,实际上，UML必须要结合相关的软件开发过程来使用，否则不会起到作用 RUP，统一软件开发过程 Agile/XP，敏捷建模 CMMI，软件能力成熟度模型集成 其它或者自创过程,总结,你都学到了什么？ 什么是UML 4+1视图 13种图 如何使用UML？,用例模型,需求捕获 用例定义 主题 参与者 用例 用例关系 扩展 泛化 包含 用例规约 总结与练习,需求捕获,需求捕获,需求捕获,需求不仅难于捕获，也难于表达。要保证用户、设计人员、开发人员都能从中得到有用的信息，但最重要的是要保证用户能够看懂需求文档，所以需求应该以用户语言表达。 传统需求描述方式单纯依赖需求规格说明书，将所有用户需求罗列在文档中。主要问题是不直观，并且无法分解需求给特定专家审核。,需求捕获,1992年由Jacobson提出了Use case 的概念及可视化的表示方法Use case图，成为面向对象的系统分析与设计方法的主流。 用例模型由Jacobson在开发AXE系统中首先使用, 自1994年Ivar Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。 用例模型的核心思想是站在用户角度，描述系统能为用户提供哪些功能。,用例定义,用例定义,单纯依赖图形，能否描述清楚需求？,用例定义,用例模型,用例定义,用例图包含以下要素 主题（uml 2.0 new） 参与者 用例 创建用例模型的工作包括： 定义系统边界 确定参与者 确定用例 描述用例（书写用例规约） 定义用例关系 确认模型（界面原型）,主题,主题 UML2.0中增加了主题（Subject）的概念以取代原来的系统边界（System boundary）。 主题可以描述系统中的一个功能模块，并不一定是整个系统。 一个系统可由多个用例图共同描述 定义系统的主要工作是确定整个问题领域中，哪些由系统软件实现，哪些由其它系统或人工实现。 一般只要能够正确识别参与者，系统的边界也随即确定。,参与者,参与者 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的理想化概念 使用名字写在下面的小人表示 可以是人、其它系统甚至是时间,参与者,识别参与者 系统外必须和它交互 系统边界责任边界，非物理边界 系统边界直接与系统交互 有意义的交互属于目标系统的责任 任何事物人、外系统、外部因素、时间,参与者,必须和它交互：,参与者,责任边界，而非物理边界：,参与者,直接与系统交互：,那么他算什么？,参与者,有意义的交互：,参与者,任何事物：,参与者,两个不同的参与者在物理上可以是同一人 依据用户使用了系统的何种功能来判断,参与者,识别参与者 谁使用了系统的主要功能？ 谁改变了系统的主要数据？ 谁从系统获取信息？ 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬件设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件？,参与者,参与者之间只有泛化关系，任何其它形式的关系都是非法的。,等一下,或,用例,用例 用例是系统执行的一组动作序列，这些动作可以产生一个可观察的结果，这个结果往往对系统的一个或多个参与者，或其他投资者来说是具有一定价值的。 Ivar Jacobson（RUP） 用例要点 用例由参与者直接或间接启动 价值结果有意义的目标 系统执行价值结果由系统生成 执行者可见业务语言，用户观点 用例必须是完整的,用例,用例图中不应该存在孤立的用例，它们必须由参与者直接启动，或包含在其它用例中，或做为其它用例的扩展用例。 参与者与用例间存在通信关联 箭头表示谁发起了会话 无箭头表示双方都可以发起会话 箭头不带表数据流，数据永远是双向的。 通信关联仅存在于参与者与用例间，用例与用例间、参与者与参与者之间都不可能存在通信关联。,用例,有意义的目标：,用例,价值结果由系统生成：,用例,业务语言而非技术语言：,用例,用户观点而非系统观点：,用户观点,系统观点,用例,用例是从参与者启动到产生价值结果的一系统动作序列，由于每次执行的条件不同，用例中间执行的步骤也可能不相同。 执行一次具体的用例就是用例的一个实例，用例的实例称为场景（scenario）。所以，用例是一组场景的集合，必须包括所有可能的场景。 用例表征的是使用复杂度，而非内部实现的复杂度。因此用例只需要描述用户使用的步骤，而不应该包含内部实现细节。,用例关系,用例间关系包括 泛化关系 包含关系 扩展关系 应用用例间关系的首要原则是保证用例图清晰，也即关系的使用应不至导致模型复杂化。不要让你的用户看不懂你的模型。,用例关系,泛化关系,泛化关系 用例在泛化关系上不明确，因此使用较少 表明子用例与参与者的关系，和父用例与该参与者的关系相同，具备相同的启动条件和价值结果 表明子用例不是简单使用父用例，而是修改了其中的某些步骤,泛化关系,泛化关系,扩展关系,扩展关系,扩展关系,扩展关系在下列情况下，特别有用 待开发系统可能会有多套不同的可选行为来进行配置 系统用例的配置安排需要功能性用例的部署 基用例描述必要的基本行为，并利用已定义的条件注明特定的扩展点，扩展用例则填充这些位置的细节。 用例的扩展点可以列在名为extension points的分栏内。 当用例实例的执行到达第一个扩展点引用的位置时，条件决定是否执行扩展用例，可执行多次。,扩展关系,扩展关系,包含关系,包含关系 包含关系将基用例和包含用例连接在一起。关系中的包含用例不是能够独立实现的类元，而是显式地描述了插入执行基用例的用例实例中的附加行为序列。 包含位置是被包含用例执行的位置。 包含只执行一次，通过引用包含的基用例行为序列中的循环可以达到多次包含的效果。,包含关系,包含关系,包含关系,包含关系,用例规约,用例规约总体结构 用例名称 执行者 涉众利益 事件流 基本流 备选流 特殊需求 前置条件 后置条件 扩展点,用例规约,描述用例流程应该是用户与系统交互进行的，形成类似如下形式的格式： 执行者XXXX 系统XXXX 执行者XXXX 系统XXXX 其它注意事项： 只写“可观测的” 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节,用例规约,总结,用了用例技术后，我就不会做需求了 其实你原来就不会做需求 症状下面隐含的问题 执行者搞错用例的边界不清楚 用例搞错没有好好思考用例的价值 文档不会写不知道哪些是需求，哪些是设计 ,用例揭破了疮疤使问题无处藏身,总结,步骤 界定系统边界 确定参与者 确定用例 确定用例关系 书写用例规约 建立界面原型 审核用例模型,练习,现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立即更新病历。 要求根据现场情景，对医院病房中央监护系统进行需求分析， 建立系统的用例模型。,练习,请对系统需求进行分析！,产生 病情报告,监视病情,静态结构,需求之后 类图要素 识别类 识别关系 对象图 复合结构图,需求之后,设计第二步系统结构？,需求之后,需求之后,人脑的把握是有限的，必须将系统职责分割到对象中去，否则系统必然失控。,George Miller：人脑的把握度有限,美国心理学会主席（1969）,需求之后,与结构化分析不同，面向对象的分析将数据与行为内聚于对象中。行为与数据是不可分割的。 类是有着相同结构、行为和关系的一组对象的描述符号。类表示被建模的应用领域中的离散概念，如： 物理实体（如飞机） 商业事物（如一份订单） 逻辑事物（如广播计划） 应用事物（如取消键） 计算机领域的事物（如哈希表） 行为事物（如一项任务）。,类图,类用实线边框的矩形来表示，矩形用两条水平线分为三栏。 上面一栏包含类的名称以及其他适用于整个类的特性。 中间一栏包含属性表。 下面一栏包含操作表。中间和下面栏在类符号中可隐藏。,类图,属性： 可见性 名称:类型 = 缺省值约束特性 方法： 可见性 名称(参数表):返回类型 约束特性,类图,阅读用例文档，抽取对应于业务实体或事件的词汇 将词汇进行分类，抽取出合适的类和属性,识别类,识别类,通常先对用例进行分析，将每个用例精化为分析类的协作，这个过程包括 确定分析类 将用例的行为分配给相交互的分析对象 捕获用例实现中的特定需求 用例分析也称为用例精化（use case refinement）。,识别类,分析类代表了对系统设计中的一个或几个类或若干子系统的抽象 分析类侧重于处理功能性需求，而把非功能性需求推迟到后续的设计与实现活动中将这些需求标识为类的具体需求时再实现 分析类很少根据操作及其特征标记来定义或提供接口，而是通过较高的、非形式化层次的职责定义行为。职责是对由类定义行为的内聚子集的文本描述。 分析类定义属性，但这些属性还处于较高的层次，即它们的类型是概念性的，而且从问题领域来考虑 分析类涉及关系，但也是概念性的，而不管在实现时语言是否支持这种关系。,识别类,分析类总能符合三种基本构造型中的一种： 边界类 用于建立系统与其参与者之间交互的模型，对系统中依赖于参与者的部分建模 经常代表窗口、通信接口、打印机接口、传感器、终端或API等的抽象。 边界类至少和一个参与者有关 控制类 代表协调、排序、事务处理以及其他对象的控制，经常用于封装与某个用例相关的控制 系统的动态特征通过控制类建模 实体类 用于对长效且持久的信息建模,识别类,识别类,确定分析类的一般准则 通过用例说明确定实体类 为每个由人充当的参与者确定一个主要边界类 为每个初期建立的实体类确定一个基本边界类 为每个由外部系统充当的参与者定义一个主要边界类，使其代表通信接口 确定一个控制类，负责处理用例实现中的控制和协调关系，然后按照用例实现的需求对该控制类进行精化,识别类,每个类大约有3-5个职责 类应该尽可能保持简单，能够支持的3-5个职责的数目。 不存在独立的类 好的OOAD精华是类相互协作使用户受益 每个类应该同少量的类协作以提供所有的期望的功能 类可以把他们的一些职责托付给专注于特定功能的其他辅助类. 当心一些非常小的类. 将那些只有一两个职责的类整合成一个更大的类 当心几个非常庞大的类 察看职责大于5个的类，合理分解为两个或者多个能够承担恰当数目职责的更小的类.,识别类,当心”伪类” 伪类是一般过程的函数,它伪装成类 Grady Booch讲了一个奇闻轶事,一个非常简单的系统却又成千上万个类.仔细审查,每个类都有一个命名为Dolt()的操作。 当心”万能类” 存在似乎能够承担任何工作的类 应将它们的职责分解给未内聚的子集 这些内聚职责的每一个集合可以分离成独立的类 类进行协作以实现由原来万能类所提供的行为. 避免深度继承树 继承层次中每个层次应该具有良好定义的目的.容易添加很多实际上却不能服务于任何目的的层次. 不要使用继承实现功能分解，即每个抽象层次恰好有一个职责 继承仅用于存在直接产生于问题域的,清晰的,显而易见的继承层次的场合,识别关系,类之间会存在着关联与泛化两大类关系，通过这些关系，可以了解系统中对象间的协作是如何完成的。 通常可先使用对象协作图了解对象的相互关系，以确定类之间的关系。,识别关系,识别关系,关联关系描述了给定类的单独对象之间语义上的连接。 二元关联是有着两个关联端点的关联，它是最常见的一种关联，用一个连接两个类符号的实线路径表示。 N元关系有n个端点，使用一个大菱形表示。,识别关系,识别关系,聚集（aggregation）表示部分与整体关系的关联，它用端点带有空菱形的线段表示，空菱形与聚集类相连接。 组合（composition）是更强形式的关联，整体有管理部分的特有的职责，它用一个实菱形物附在组成端表示。,识别关系,如果一个关联既是类又是关联，即它是一个关联类，那么这个关联可以有它自己的属性,识别关系,如果一个关联的属性在一组相关对象中是唯一的，那么它是一个限定符 限定符是用来在关联中从一组相关对象中标识出独特对象的值,识别关系,识别关系,识别关系,男女平等,男尊女卑,母系社会？,识别关系,泛化反映的是一个较广泛元素和一个较特殊元素之间的类元关系,识别关系,实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说明而不是结构或者实现。 泛化关系将在同一语义层上的元素连接起来（如，在同一抽象层），并且通常在同一模型内。 实现关系将在不同语义层内的元素连接起来（如，一个分析类和一个设计类；一个接口与一个类），并且通常建立在不同的模型内。,识别关系,实现关系用一条带封闭空箭头的虚线来表示 可以用带关键字interface的矩形表示，或用圆圈表示,识别关系,关于实体之间的关系，请参见数据库建模,对象图,对象是类的实例，链是关联的实例。 对象图是对系统的一个快照,复合结构图,复合结构图描述更为复杂结构的组成情况，包括以下要素 部件（part），代表组成结构的一个部分 连接器（connector），连接部件以使它们可以交互 端口（port），描述部件开放出来与其它部件交互的连接点,复合结构图,练习,医院中央监控系统的用例图如下：,练习,依本章所述方法识别类，并给出类图。,总结,你都学到了什么？ 怎么画类图？ 分析类有哪几种？ 如何识别类？ 关联的种类，分别有什么含义？ 对象图？复合结构图？,动态行为,交互图种类 顺序图 分配职责 通信图 活动图 交互概观图 时序图,交互图种类,UML2中交互图包括以下几种 顺序图 显示对象沿其生命线（代表对象存在的时间顺序）所进行的交互 通信图 显示对象之间传递的消息，其关注的是对象的内部结构 交互概观图 把顺序图当作改进的活动图（不显示任何交互细节）的一个单元来对待 时序图 显示沿着一个精确时间轴的交互,顺序图,顺序图以二维图的形式描述对象间的交互，其中纵轴是时间轴，横轴为参与交互的对象。 顺序图描述的重点在消息的序列上，自上而下观察可以非常清晰地了解对象间交互的过程。也可以为消息编号。 顺序图中的对象以矩形表示，并在矩形下面有一条虚线，称为生命线；当对象的过程处于激活状态时，生命线是一个双道线。 消息用从一个对象的生命线到另一个对象生命线的箭头表示，箭头上可以标注消息签名（类似方法名）。箭头以时间顺序在图中从上到下排列。,顺序图,顺序图,顺序图中有主动对象和被动对象的区别： 主动对象拥有一个控制线程并且能初始化控制活动，不在另一个对象的作用域内运行，用具有重边线的矩形表示。 被动对象是自身不具备线程控制的对象，它的操作在主动对象内的线程控制下执行。被动对象是使用单边矩形表示的，其中的对象名称带有下划线。,顺序图,顺序图可以由两种形态来表示： 实例形态：只描述一个特定场景 一般形态：各种场景都要描述 消息是对象间的通信，一般可以是信号、操作调用及其它类似事物（如RMI）。 当对象接收到消息，对象的一项活动就要开始了。这一般称为激活。,顺序图,对象放置在代表生成这个对象的消息的箭头的端点，其垂直位置表示这个对象第一次创建的时间。 如果对象在第一个操作前就存在，则对象符号处在图的顶部。 返回消息使用虚线箭头。 注意递归的表示方法。 主动对象整个生命周期，被动对象被激活期间均使用双实线 大X表示销毁对象，调用以实心箭头表示，返回以虚线显示。,顺序图,State Invariants，保证在余下的生命周期中条件为真。,分配职责,分配职责,背黑锅我来，送死你去，拼全力为众生,分配职责,低耦合,高内聚,分配职责,专家（expert）原则 把责任分配给领域专家 老板（boss）原则 只跟最高领导人打交道 可视（Visibility）原则 不和陌生人讲话,分配职责,会员结帐用例 会员请求结账 系统验证会员的账户处于打开状态 系统验证订单的信息充分 系统找出有足够库存且运费最低的供应商 系统合计订单总价（订单总价=所有订单价钱合计+税金+运费） 系统显示收费明细 会员确认 系统保存订单信息，扣除会员账户金额，通知供货商发货，从库存扣除相应数量。,分配职责,会员？账户？,分配职责,分配职责,会员.检查账户状态() 账户.检查状态() ,分配职责,分配职责,“合计总价”操作分配给哪个类？ 目的：统计所有订单的总价钱 所需信息：每一个订单项的价钱及其总和 考虑：谁知道这些？ 答案：订单,分配职责,分配职责,“计算订单项价钱”操作分配给哪个类？（零件？订单？订单项？） 统计某个订单的价钱需要用到的信息： 订单项.购买数量 X 零件.价格 考虑：谁知道以上的所有信息？零件？订单项？ 答案：订单项,零件不知道订单项，订单项知道零件,价格从哪来？,谁来计算税金？,专家原则,“计算税金”需要用到的信息： 税金=价钱X相应税率 考虑：订单知道所有这些吗？ 解决方法：添加一个“计费”类，负责计算各种附加费用。 计算运费也是如此。,增加计费类,通信图,通信图描述对象间交互的同时，也反映了对象间关联。 顺序图侧重于在时间顺序上对象间交互的次序，而通信图侧重于在空间上描述对象间链接，同时反映交互关系，但不直观。 大多数UML工具支持顺序图与通信图的自动变换。 通信图在1.x中称为协作图。,通信图,通信图,消息：带有标签的箭头表示。 每个消息包括 一个顺序号 一张可选的前任消息的表 一个可选的监护条件 一个名字和参量表 可选的返回值表。 前任消息表可选监护条件可选 序列号 返回值列表:=可选 消息名(参数列表),状态机图,状态机图描述一个对象在其生命周期中可以拥有哪些状态，该对象在这些状态下的行为，以及什么样的事件会导致状态发生变化。 一个状态机由两类元素组成： 1、状态（state） 2、转换（transition）,状态机图,一个状态由三部分组成 状态名称 内部活动（entry/do/exit） 内部转换,状态机图,状态机图,状态分为三种 简单状态 组合状态 区域（regions）：以平行的虚线表示，区域内可以有自己的独立状态转换过程，各区域状态转换全部完成时，整个状态转换完成。一个区域的复合状态是顺序组合状态，多个区域的复合状态是并发组合状态 子状态：嵌于状态内部的状态 子机状态 等同于组合状态，但并不具体描述内部实现，便于重用,状态机图,伪状态,状态机图,状态机图,状态机图,转换的要素包括： 源状态：源状态是被转换所影响的状态。 目标状态：目标状态是转换结束后的主动状态，它是主对象要转向的状态。 事件触发器（Event trigger)：事件触发器是一个事件，它被处于源状态的对象所接受后，转换只要得到监护条件的满足即可激发。 监护条件（guard condition)：在触发事件发生后，判断是否可进行转换的阀门。 动作（action）：在转换时施加的一个行为,状态机图,状态机图,事件是发生在时间和空间上的一点的值得注意的事情。一个事件的具体发生叫做事件的实例。 触发器事件是引起转换的事件。事件可以有参数，以供转换的动作使用。 分类:调用事件、改变事件、信号事件、时间事件,状态机图,信号事件：发送者不会等待接收者如何处理信号而是独立地做它自己的工作 调用事件：调用对象要等待被调用者返回信息，与普通调用不同，调用事件中调用结束后被调用对象还继续执行 改变事件：依赖于特定属性值的布尔表达式所表示的条件满足时，事件发生改变。 时间事件：代表时间的流逝。,状态机图,监护条件是一个布尔表达式，它于一个事件的操作触发了转换时计算。 监护条件可以引用对象的属性值和触发事件的参数。当一个触发器事件被触发时，监护条件被赋值。 如果布尔表达式的值为“真”，那么触发事件，即使转换有效。如果布尔表达式的值为“假”，则不会引起转换。监护条件只能在触发事件发生时被赋值一次。,状态机图,赋值动作：导致一个对象或对象集合的属性值被改变。 调用动作：导致一个对象或对象集合上操