软件工程UML.ppt

Unified Modeling Language统一建模语言,参考文献,UML参考手册（第2版）James Rumbaugh,Ivar Jacobson,Grady Booch 机械工业出版社 UML用户指南（第2版）Grady Booch,James Rumbaugh,Ivar Jacobson 人民邮电出版社UML精粹：标准对象语言简明指南 Martin Fowler 清华大学出版社,产生背景,面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮 UML是这个高潮的产物 统一了Booch、Rumbaugh和Jacobson的表示方法 Booch 1993OMT-2OOSEOOA/OOD Coad/Yourdon 统一为大众所接受的统一建模语言,发展历程,什么是UML？,通用的可视化建模语言 用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档 它记录了对必须构造的系统的决定和理解 用于对系统的理解、设计、浏览、配置、维护和信息控制,UML的适用范围,各种软件开发方法 软件生命周期的各个阶段 各种应用领域,UML描述能力,静态结构动态行为模型分解成包的结构用于显示系统实现和组织运行的成分,UML是什么语言？,不是一门程序设计语言 不是一种可用于定理证明的高度形式化的语言 是一种通用建模语言 是一种离散的建模语言 不适合对诸如工程和物理学领域中的连续系统建模 是一个综合的通用建模语言 适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模,UML概念域,静态结构动态行为实现构造模型组织扩展机制,静态结构,静态视图用类构造模型来表达应用 类继承和子类关联：对象与其他对象之间也具有运行时间连接依赖：包括在抽象级上进行模型转换、模板参数的捆绑、授予许可以及通过一种元素使用另一种元素等,动态行为,描述和时间相关的交互图状态图活动图,模型组织,子系统包图,实现结构,组件图部署图,扩展机制,构造性标记值约束,UML视图,视图来划分UML概念和组件 视图只是表达系统某一方面特征的UML建模组件的子集 三个视图域结构分类动态行为模型管理,类元classifier,各种视图的组成用类元（classifier）表示 描述事物的建摸工具 是描述结构和行为特性的一种机制 类元为研究系统动态行为奠定了基础,结构分类,描述了系统中的结构成员及其相互关系 类元视图静态视图用例视图实现视图,动态行为,描述了系统随时间变化的行为 行为用从静态视图中抽取的瞬间值的变化来描述 动态行为视图状态机视图活动视图交互视图,模型管理,说明了模型的分层组织结构 包是模型的基本组织单元,UML视图表,UML视图,用例视图,被称为执行者的外部用户所能观察到的系统功能的模型图 用例是系统中的一个功能单元，可以被描述为执行者与系统之间的一次交互作用 用例模型的用途是列出系统中的用例和执行者，并显示哪个执行者参与了哪个用例的执行。,例子,交互图,描述了执行系统功能的各个角色之间相互传递消息的顺序关系 类元是对在系统内交互关系中起特定作用的一个对象的描述，这使它区别于同类的其他对象 互视图显示了跨越多个对象的系统控制流程 交互视图可用两种图来表示 顺序图协作图(通信图)定时timing交互概图,顺序图,表示了对象之间传送消息的时间顺序 每一个类元角色用一条生命线来表示用垂直线代表整个交互过程中对象的生命期 用来进行一个场景说明即一个事务的历史过程 用来表示用例中的行为顺序 当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件,例子,通信图（协作图）,对在一次交互中有意义的对象和对象间的链建模 对象和关系只有在交互的才有意义 类元角色描述了一个对象 关联角色描述了协作关系中的一个链 一个用途是表示一个类操作的实现 可以说明类操作中用到的参数和局部变量以及操作中的永久链,例子,顺序图 VS 通信图,都可以表示各对象间的交互关系 侧重点不同顺序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的 协作图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系,状态机视图,是一个类对象所可能经历的所有历程的模型图 状态机由对象的各个状态和连接这些状态的转换组成 每个状态对一个对象在其生命期中满足某种条件的一个时间段建模 当一个事件发生时，它会触发状态间的转换，导致对象从一种状态转化到另一新的状态 与转换相关的活动执行时，转换也同时发生,例子,活动视图,是状态机的一个变体 用来描述执行算法的工作流程中涉及的活动 活动状态代表了一个活动 一个工作流步骤或一个操作的执行 描述了一组顺序的或并发的活 动,例子,模型管理视图,对模型自身组织建模 一系列由模型元素（如类、状态机和用例）构成的包组成了模型 一个包(package)可能包含其他的包 整个模型实际上可看成一个根包，它间接包含了模型中的所有内容 子系统是另一种特殊的包,包图,扩展机制,约束用某种形式化语言或自然语言表达的语义关系的文字说明 构造型由建模者设计的新的模型元素 标记 值附加到任何模型元素上的命名的信息块,例子,各种视图间的关系,用例视图,用例模型由Ivar Jacobson在开发AXE系统中首先使用 加入由他所倡导的OOSE和Objectory方法中 描述的是外部执行者(Actor)所理解的系统功能 是获取系统功能需求的一种技术,用例视图的作用,它描述了待开发系统的功能需求 它将系统看作黑盒，从外部执行者的角度来理解系统 它驱动了需求分析之后各阶段的开发工作 不仅在开发过程中保证了系统所有功能的实现 被用于验证和检测所开发的系统影响到开发工作的各个阶段和 UML 的各个模型,用例视图的适用范围,用于需求分析阶段 它的建立是系统开发者和用户反复讨论的结果 表明了开发者和用户对需求规格达成的共识,用例模型的组成,用例模型由若干个用例图描述 用例图中显示执行者、用例和用例之间的关系 用例图包括三种模型元素 系统执行者用例,系统System,用例模型的一个组成部分 代表的是一部机器或一个业务活动 不是真正实现的软件系统 系统的边界用来说明构建的用例模型的应用范围 自动售货机准确定义系统的边界并不总是容易的事 自动还是手工？系统规模有多大？,定义系统的一般方法,先识别出系统的基本功能然后以此为基础定义一个稳定的、精确定义的系统架构以后再不断地扩充系统功能，逐步完善,术语和定义,在建模初期要定义一些术语和定义在描述系统、用例或进行作用域分析时采用统一的术语和定义能够规范表述系统的含义，不致于出现误解,USE CASE用例,代表的是一个完整的功能 是活动序列的集合 系统执行该活动序列来为执行者产生一个可观察的结果 活动是系统的一次执行 一个用例是用户与计算机之间的一次典型交互作用 系统中的每种可执行情况就是一个活动，每个活动由许多步骤组成,用例的图示,自动售货机系统用例图,关联Association,用例和执行者之间的连接关系表示哪种执行者能与该用例通信 关联关系是双向的多对多关系 一个执行者可以与多个用例通信一个用例也可以与多个执行者通信,用例的情景Scenario,用例表示的也是一个类，而不是某个具体的实例 用例的实例（也是一种动作）代表系统的一种实际使用方法这个实例通常叫作情景（scenario）情景是系统的一次具体执行路线,用例的特点,用例总由执行者初始化 用例为执行者提供值 用例具有完全性,用例规格说明,用例规格说明不是UML的一部分 很多开发方法都需要对用例进行文字说明都有一个用例规格说明的模板目的是详细描述用例,用例规格说明模板,用例：用例标示：执行者：。先决条件（preconditions）：事件流：后置条件(post conditions)：,执行者Actor,Actor指用户在系统中所扮演的角色 是与系统交互的人或事 其图形化的表示是一个小人状图案执行者是一个群体概念 代表的是一类能使用某个功能的人或事 执行者不是指某个个体 执行者可以是人，也可以是外界系统执行者对提供用例是非常有用的,主要执行者和次要执行者,主要执行者（primary actor）指的是执行系统主要功能的执行者 次要执行者指的是使用系统次要功能的执行者次要功能是指一般完成维护系统的功能例如管理数据库通信备份等将执行者分级的目的是保证把系统的所有功能表示出来,执行者的泛化关系,执行者是一个类，它拥有与类相同的关联描述 使用泛化（generalization）关系描述若干执行者之间的关系（is-a）将某些执行者的共同行为抽取出来表示成泛化的行为，且将它们描述为超类,泛化的例子,用例间的关联,用例的泛化关系,像类之间的泛化关系一样 子用例继承超用例的行为和含义子用例还可以增加或覆盖新的行为也可以重置超用例中的行为 子用例可以出现在超用例出现的任何位置,用例间泛化关联的例子,扩展关联extend association,和泛化非常类似，一个用例中加入一些新的动作后则构成另一个用例 前者通常称为用基本用例后者常称作扩展用例同一个基本用例的几个扩展用例可以在一起应用基本用例的扩展增加了原有的语义,如何扩展行为,扩展用例是靠向基用例的活动序列插入额外的活动序列来完成扩展的。它允许扩展用例到达基用例中合理的扩展点，且扩展条件满足的时候，延续基用例的活动序列 当扩展用例的活动序列完成的时候，基用例就延伸了,扩展点,候选过程的逻辑替代基本活动过程的部分逻辑 在用例中指出其替代点 仅仅是基用例逻辑中的一个标记，表明哪里允许扩展,扩展用例的例子,引入扩展的好处,便于处理基用例中不易描述的某些具体情况 便于扩展系统 提供系统性能 减少不必要的重复工作,包含关联（include association）,指一个用例包含了其他用例所描述的行为 抽象用例如果若干个用例的某些行为是相同的，则可以把这些相同的行为提取出来单独作为一个用例当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例的所有行为理解包含关联的最好方法是一个用例调用另一个用例,使用关系,包含关联在UML 1.2或更早版本叫做使用关系 一个用例使用另一个用例时，这两个用例之间就构成了使用关系,包含关联的例子,何时使用三种关系,当在两个或多个独立用例中重复自己并希望避免重复是，使用包含当表述关于正常行为的一个变化情形并希望临时表述时使用泛化表述正常行为的一个变化并希望使用更为受控的形式来在基本用例中说明扩展点表示特殊情况时使用扩展,交互图interaction diagram,用来描述对象之间的动态协作关系以及协作过程中的行为次序 它常常用来描述一个用例的行为 显示该用例中所涉及的对象和这些对象之间的消息传递情况,交互图的种类,顺序图(sequence diagram)通信图（communication diagram）交互概图（interaction overview diagram）定时图（timing diagram）,例子描述,订单提交窗口发送一条“prepare”消息给订单。订单发送“prepare”消息给订单上的每个订单项。每个订单项检查其对应的仓库货物。如果检查结果为“true”，即仓库货物的数量足够多时，则订单项，表明仓库中的货物数量低于订购量，这是仓库要求一次新的进货。,顺序图,用来描述对象之间动态的交互关系 着重体现对象间消息传递的时间顺序,通信图（协作图）,也是用来描述对象与对象之间的消息连结关系的 它更侧重于说明哪些对象之间有消息传递，而不像顺序图那样侧重于在某种特定的情形下对象之间传递消息的时序性,顺序图和协作图的比较,不同的软件工程师可能偏好不同形式的交互图 顺序图突出使用执行的时序，能更方便地看出事情发生的次序 因为协作图的布局方法能更清楚的表示出对象之间静态的连结关系,何时使用交互图,交互图能清楚的显示消息机制 当消息中有太多的条件或循环时，交互图就失去其简明性 交互图仅适用于条件判断和循环不太多的时序过程 一旦条件判断或循环太多，交互图就不太实用了 当行为比较简单时，交互图是最好的图 如果想在一张图中表示复杂的行为，则应当使用活动图 交互图擅长显示对象之间的合作关系 如果想描述跨越多个用例的单个对象的行为，应当使用状态图 如果想描述跨越多个用例或多个线程的复杂行为，则需要考虑使用活动图,状态图 State Diagram,用来描述一个特定对象的所有可能状态及其引起状态转移的事件 用状态图表示单个对象在其生命周期中的行为 一个状态图包括一系列的状态以及状态之间的转移,基本概念,所有对象都具有状态 状态是对象执行了一系列活动的结果 当某些事情发生后,对象的状态将发生变化 称改变对象状态的事情为“事件”状态图用来显示对象对事件的反应以及对象状态的改变,状态,初态状态图的起始点一个状态图只能有一个初态 终态状态图的终点 终态则可以有多个 中间状态复合状态,状态的表示,名字状态变量活动,图3-39 状态的三个组成部分：名字、状态变量、活动,在活动表中，常常使用下面三种标准事件：进入、退出、做(do)进入事件用来指定进入一个状态时的活动，退出事件用来指定退出一个状态的活动，做事件用来指定在该状态下的活动,活动表,三种标准事件：进入、退出、做(do)进入事件用来指定进入一个状态时的活动 退出事件用来指定退出一个状态的活动 做事件用来指定在该状态下的活动 活动部分的语法 事件 参数表/活动表达式,转移,状态图中状态间带箭头的连线被称为转移 状态的变迁通常是由事件触发的 此时应在转移上标出触发转移的事件表达式 如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移,转移的语法,事件守卫条件/动作表达式事件的表达 式事件名 参数守卫条件是状态转移的一个布尔表达式如果将守卫条件和事件说明放在一起使用时，则当且仅当事件发生且布尔表达式成立时状态才发生转移 如果状态转移只有守卫条件这一个条件，则只要守卫条件为真，状态就发生转移 动作表达式是一个过程表达式，当状态转移开始时执行,例子,活动图activity diagram,活动图是显示从活动到活动的流 一个活动是一个状态机中进行的非原子的执行单元 活动最终导致一些动作 这些动作由可执行的原子计算组成，这些计算会导致系统状态的改变或一个值得返回,活动图是状态图的变种,活动图的主要目的是描述动作（执行的工作或活动）以及对象状态改变的结果 当状态中的动作被执行时，活动图中的状态（称作动作状态）直接转移到下一阶段 不象正常的状态图，它不需指定任何事件活动图和状态图的另一个区别是活动途中的动作可以放到泳道中去 活动图是另一种描述交互的方式，描述采取何种动作，做什么（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）,活动图的作用,描述成操作执行过程中（操作实现的实例化）所完成的工作（动作）描述对象内部工作 显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象 显示用例的实例是如何执行动作以及如何改变对象状态的,图例,活动的分解,一个活动可以分解成若干子活动这和状态图上的超态与子态很相同可以在父图上示明超态，或者也可以示明超态及其中的内部行为,活动分解,划分partition,划分将一个活动图中的活动状态分组 每一组表示负责那些活动的业务组织 当对业务过程的工作流建模时，划分是很有用的 划分的一个简单一种简单划分是一维划分，这种方式往往称为泳道 在UML2 中，可以用二维的格，所以适用泳道概念就不合适了,划分的例子,划分特点,每个划分在图中都有一个唯一的名称 每个划分代表一个活动图的全部活动中部分活动的高层职责 每个划分最终可能由一个或多个类实施 在一个被分为划分的活动图中，每个活动都明确的属于一个划分，而转移可以跨越划分,对象流,对象可以被包含在与一个活动图相关的控制流,对象流的说明,活动图能表示对象的值流和控制流 对象流状态表示活动中输入或输出的对象 对输出值而言，虚线箭头从活动指向对象流状态 对输入值而言，虚线箭头从对象流状态指向活动,何时使用活动图,用于对系统的动态方面建模 可涉及一个系统体系结构的任意视图中任何类型抽象的活动，包括类（含主动类）、接口、构件和节点 也适合于静态建模几乎任何场合,包图,为什么需要包图？将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合在UML中这种聚集机制称为包(package)不仅仅是类可以运行包的机制，任何模形元素都可以运行包的机制 包以及其间依赖的图称为包图(package diagram),包的依赖关系,如果改变UML一个成分的定义，就会引起另一成分的改变，便说这两个成分之间存在一种依赖(dependency)设有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X,例子,订单获取界面,AWT,邮件发送清单界面,订单获取应用,邮件发送清单应用,订单,顾客,依赖性,包,图 3-46 包图,传递依赖,什么是传递依赖？要避免传递依赖实现非传递依赖，增强包的独立性,领域包,虚包,门面facade,包的泛化,这意味着一个专用包符合其公用包的界面 在使用泛化概念时，公用包可标记为abstract,以表示该包只是定义了一个界面，具体实现则由专用包来完成泛化意味着从子类型到基类型之间存在这依赖关系 把基类型包定义为一个抽象包，即标明abstract 而在其子类型包中定义实现体，可以有效地避免出现循环依赖的情况,泛化的例子,如何使用包图,只要你不能将这个系统的类图压缩到一张A4纸上，你就应该使用包图 依赖产生耦合，因此应该尽量将依赖性减少到最低程度 包的概念对测试也是特别有用的,