• Like
面向对象的分析设计之UML基础
Upcoming SlideShare
Loading in...5
×
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,200
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
122
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 面向对象的分析设计之 UML基础 出家如初,成佛有余 http://www.yeeach.com 2009年1月
  • 2. 面向对象的分析设计培训大纲 2
  • 3. 目 录 UML概述 UML静态建模 UML动态建模 3
  • 4. 什么是模型? 模型是对系统的完整的抽象表示,建模是在不同层次上对 系统的描述。 人们对某个领域特定问题的求解及解决方案,对它们的理 解和认识都蕴涵在模型中。 通常,开发一个计算机系统是为了解决某个领域特定问题 ,问题的求解过程,就是从领域问题到计算机系统的映射 4
  • 5. 建模的意义 模型是对现实的简化,建模是为了更好地理解系统。 模型帮助我们按照实际情况或需求对系统可视化; 模型允许我们详细说明系统的结构、行为; 模型给出了一个构造系统的模板; 模型对我们作出的决策进行文档化; 5
  • 6. 建模的原理 选择创建什么模型对如何动手解决问题和如何形成解决方 案有意义深远的影响。 每一种模型可以在不同的精度级别上表示。 好的模型可以让你根据观察的角色及原因选择它的详细程 度 对每个系统最好用一组几乎独立的模型去处理 6
  • 7. 谁应该建模 业务建模:以领域专家为主,需求分析人员是主力,系统分析员、 架构师可参与 需求模型:以需求分析人员为主,系统分析员是主力,领域专家提 供指导,架构师和资深开发人员参与 设计模型:高层设计模型以架构师为主,系统分析员从需求方面提 供支持,资深开发人员从技术实现方面提供支持。详细设计模型则以 资深开发人员为主,架构师提供指导 实现模型: 实现模型:以资深开发人员(设计人员)为主,架构师提供总体指 导 数据库模型:以数据库开发人员为主,架构师提供指导,资深开 发人员(设计人员)予以配合。 7
  • 8. UML概述 UML(Unified Modeling Language)是软件界第一个统一 的建模语言,该方法结合了Booch, OMT, 和OOSE方法的优 点,统一了符号体系,并从其它的方法和工程实践中吸收 了许多经过实际检验的概念和技术。 UML是一种标准的表示,已成为国际软件界广泛承认的标准 。是一种基于面向对象的可视化的通用(General)建模语 言。为不同领域的用户提供了统一的交流标准 — UML图 UML应用领域很广泛,可用于软件开发建模的各个阶段, 商业建模(Business Modeling), 也可用于其它类型的 系统。 8
  • 9. UML历史 1994年10月Jim Rumbaugh和Grady Booch共同合作把他们 的OMT和Booch方法统一起来,到1995年成为“统一方法” (Unified Method)0.8版本。随后,Ivar Jacobson加入 ,并采用他的用例(User case)思想,到1996年,成为UML (Unified Modeling Language)0.9版本。 1997年1月,UML版本1.0被提交给OMG(Object Management Group)组织,作为软件建模语言标准的候选。其后的半年 多时间里,一些重要的软件开发商和系统集成商都成为 “UML伙伴”,如IBM,Mircrosoft,HP等.1997年11月7日被 正式采纳作为业界标准。 9
  • 10. UML历史 <documents> <documents> 2000年 UML 2.0 UML 1 4 1.4 (计划的较小修订) <documents> 1999 UML 1.3 2001年 计划的重要修订 <documents> 1998 UML 1.2 文字上的修改 1997年9月最后 <documents> 没有显著的技 提交给OMG UML 1.1 术变化 1997年1月最 <documents> 初提交给 OMG UML1.0 精华相关 <documents> 1996 UML 0.9 <documents> 文档版类 Unified Method 1995 0.8 10
  • 11. UML的特点 统一标准 UML统一了Booch、OMT和OOSE等方法中的基本概念,已成为OMG的 正式标准,提供了标准的面向对象的模型元素的定义和表示。 面向对象 UML还吸取了面向对象技术领域中其它流派的精华。删除了大量易 引起混乱的、多余的和极少使用的符号,也添加了一些新符号。 可视化、表示能力强 系统的逻辑模型或实现模型都能用UML模型清晰的表示,可用于复 杂软件系统的建模。 易掌握、易用 UML的概念明确,建模表示法简洁明了,图形结构清晰,易于掌握 11 使用。
  • 12. UML深入理解 UML是一种语言 遵循特定的规则 允许创建各种模型 并不告诉设计者需要创建哪些模型 并不提供开发过程 UML是可视化语言 UML是图形化语言 图形便于交流(一幅图抵上千文字) 12
  • 13. UML深入理解 UML是用于构造系统或理解系统的语言 UML既支持正向工程,又支持反向工程 UML是文档化语言 将所建造的系统记录下来 便于新程序员跟进 开发产品新版本时很有用处 13
  • 14. 关于UML理解的误区 UML是一种方法论? 只是规范、标准,没有方法指南,只有方法的概念 UML是一堆图形? 还有文字 UML只能应用与面向对象开发? 还可以建模业务、数据库、工作流等等 UML是Rational Rose里的建模符号? Rational Rose只是其中一种建模工具? 14
  • 15. UML组成 15
  • 16. UML组成 构造块: 也就是建模元素,是模型的主体 UML规则: 也就是支配基本构造块如何 放在一起的规则 公共机制: 运用于整个UML模型中的公共机制、 扩展机制 16
  • 17. UML组成-事物构造块 事物构造块是对模型中最具有代表性的成分的抽象 结构事物:UML中的名词,它是模型的静态部分,描述概念或物理 元素。包括:类(class)、对象(object)、接口(interface )主动类(active class)、用例(use case)、协作( collaboration)、组件(component)、节点(node) 行为事物:UML中的动词,它是模型中的动态部分,是一种跨越时 间、空间的行为。主要包括:交互(intercation)、状态机( state machine) 分组事物:UML中的容器,用来组织模型,使模型更加的结构化。 主要包括:包(Package) 注释事务:UML中的解释部分,和代码中的注释语句一样,是用来 描述模型的。 17
  • 18. UML常用模型元素 可以在图中使用的概念统称为模型元素。 对象 类 状态 属性 属性 操作 操作 接口 用例 结点 组件 包 注释 18
  • 19. UML模型元素关系 模型元素与模型元素之间的连接关系也是模型元素,常 见的关系有: 关联(association) :连接(connect)模型元素及链接 (link)实例。 依赖(dependency) :表示一个元素以某种方式依赖于另一种元素 泛化(generalization) :表示一般与特殊的关系,即“一般” 元素是“特殊”关系的泛化。 实现关系(realization):通过实现关系将一种模型元素(如类 )与另一种模型元素(如接口)连接起来,其中接口只是行为的 说明而不是结构或者实现 19
  • 20. UML模型元素关系图例 20
  • 21. UML规则 命名:也就是为事物、关系和图起名字。和任何语言一样,名字都 是一个标识符 范围:与类的作用域相似,包括所有者作用域(owner scope)和目 标作用域(target scope)两类 可见性: 21
  • 22. 公共机制-规格描述 规格描述在图形表示法的每个部分后面都有一个规格描述 ,它用来对构造块的语法和语义进行文字叙述。这种构思 ,也就使可视化视图和文字视图的分离 22
  • 23. 公共机制- UML修饰 UML修饰在为了更好的表示这些细节,UML中还提供了一些 修饰符号,例如不同可视性的符号、用斜体字表示抽象类 23
  • 24. 公共机制-UML通用划分 类与对象的划分:类是一种抽象,对象是一个具体的实例 接口与实现的分离:接口是一种声明、是一个契约,也是 服务的入口;实现则是负责实施接口提供的契约 24
  • 25. 公共机制- UML扩展机制 构造型(版型,stereotype): 在实际的建模过程中,可能会需要定义一些特定于某个领域或某 个系统的构造块 25
  • 26. 公共机制- UML扩展机制 标记值(tagged value) 标记值则是用来为事物添加新特性的。标记值的表示方法是用形 如“{标记信息}”的字符串 模型元素附加的命名信息,任何元素都可使用。 26
  • 27. 公共机制- UML扩展机制 约束(constraint) 约束是用来增加新的语义或改变已存在规则的一种机制(自由文 本和OCL两种表示法)。 约束的表示法和标记值法类似,都是使用花括号{}括起来的串来 表示,不过它是不能够放在元素中的,而是放在元素关系中 27
  • 28. UML的视图(views) 一个系统应从不同的角度进行描述,从一个角度观察到的 系统称为一个视图(view)。 视图由多个图(Diagrams)构成,它不是一个图表( Graph),而是在某一个抽象层上,对系统的抽象表示。 如果要为系统建立一个完整的模型图,需定义一定数量的 视图,每个视图表示系统的一个特殊的方面。 另外,视图还把建模语言和系统开发时选择的方法或过程 连接起来。 28
  • 29. UML的“4+1”视图 •Logical View •Implementation View •Analysts/Designers •Programmers g •End-user End user •Structure •Functionality •Software management •Use-Case View •Process View •Deployment View •System Integrators •System Engineering •Performance •System topology •Scalability •Delivery, installation •Throughput •communication
  • 30. UML的4+1视图 视图名称 视图内容 静态表现 动态表现 观察角度 1 用户模型视图 系统行为,动 用例图 交互图、状 用户、 力 态图、活动 (用例视图) 分析员、 图 测试员 2 结构模型视图 问题及解决方 类图、对象 交互图、状 类、 案 图 态图、活动 (逻辑视图) 接口、 图 协作 3 行为模型视图 性能、可伸缩 类图、对象 交互图、状 线程、 性,吞吐量 图 态图、活动 (进程视图) 进程 图 4 实现模型视图 组件、文件 组件图 交互图、状 配置、 态图、活动 (实现视图) 发布 图 5 环境模型视图 部件的发布、 配置图 交互图、状 拓扑结构 交付、安装 态图、活动 (实施视图) (实施图) 的节点 图
  • 31. UML的图(Diagrams) UML语言定义了五种类型,9种不同的图,把它们有机的结 合起来就可以描述系统的所有视图。 用例图(Use case diagram) :从用户角度描述系统功能,并指出 各功能的操作者。 静态图(Static diagram):表示系统的静态结构。包括类图、对 象图、包图。 行为图(Behavior diagram):描述系统的动态模型和组成对象间 的交互关系。包括状态图、活动图。 交互图(Interactive diagram): 描述对象间的交互关系。包括 顺序图、合作图。 实现图( Implementation diagram ): 用于描述系统的物理实 现。包括组件图、部署图。 31
  • 32. UML的9种图 图名称 图定义 图性质 1 类图 一组类、接口、协作及它们的关系 静态图 2 对象图 一组对象及它们的关系 静态图 3 用例图 一组用例、参与者及它们的关系 静态图 4 顺序图 一个交互,强调消息的时间顺序 动态图 5 协作图 一个交互,强调消息发送和接受的对象的结构组织 动态图 状态图 一个状态机,强调对象按事件排序的行为 动态图 6 活动图 一个状态机,强调从活动到活动的流动 动态图 7 组件图 一组组件及关系 静态图 8 配置图 一组接点及它们的关系 静态图 9 (实施图) 32
  • 33. RUP开发过程-动态模型及静态模型 33
  • 34. 目 录 UML概述 UML静态建模 UML动态建模 34
  • 35. UML静态建模机制 任何建模语言都以静态建模机制为基础,标准建模语言UML 也不例外。所谓静态建模是指对象之间通过属性互相联系 ,而这些关系不随时间而转移。 UML的静态建模机制包括: 用例图(Use case diagram) 类图(Class diagram) 对象图(Object diagram ) 包图(Package diagram) 组件图(Component diagram) 部署图(Deployment diagram) 35
  • 36. 用例图-用例关系 参考《面向对象的分析设计之RUP基础及用例建模》 36
  • 37. 类图 类图包含3个组成部分。 类名 属性 操作 37
  • 38. 类图-属性语法 标准格式: [可见性] 属性名[: 类型] [‘[’多重性[次序]‘]’][=初始值][{特性}] 可见性:可访问性 多重性:属性值个数格式 次序:属性值顺序 特性:属性约束 属性可见性 38
  • 39. 类图-属性例子 举例: + size: Area = (100,100) # visibility: Boolean = false -origin : Point; Colors : color[3] Points : Point[2..* ordered] Name: String[0..2] 39
  • 40. 类操作的语法 类操作的标准格式: [可见性] 操作名[(参数列表)] [:返回类型][{约束特征}] 例子: + display() # create() -attachXWindow(xwin:XWindowPtr) + getname() : String 40
  • 41. 类图-接口 41
  • 42. 类图-类之间关系 42
  • 43. 类图-泛化(Generalization)关系 泛化:表示类与类之间的继承关系,接口与接口之间的继 承关系,或类对接口的实现关系。一般化的关系是从子类 指向父类的,与继承或实现的方法相反。 例子: class Animal{} class Tiger extends Animal{} 43
  • 44. 类图-依赖关系(Dependency) 对于两个相对独立的对象,当一个对象负责构造另一个对 象的实例,或者依赖另一个对象的服务时,这两个对象之 间主要体现为依赖关系。 例子: public class Person{ public void screw(Screwdriver screwdriver){ screwdriver.screw(); } } 44
  • 45. 类图-关联(Association)关系 关联:对于两个相对独立的对象,当一个对象的实例与另 一个对象的一些特定实例存在固定的对应关系时,这两个 对象之间为关联关系。 public class Company{ private Employee employee; public Employee getEmployee(){ return employee; } public void setEmployee(Employee employee){ this.employee=employee; } public void run(){ employee.startWorking(); } 45
  • 46. 类图-实现关系 实现关系将一种模型元素(如类)与另一种模型元素(如 接口)连接起来,其中接口只是行为的说明而不是结构或 者实现。客户必须至少支持提供者的所有操作(通过继承 或者直接声明)。虽然实现关系意味着要有像接口这样的 说明元素,它也可以用一个具体的实现元素来暗示它的说 明(而不是它的实现)必须被支持。例如,这可以用来表 示类的一个优化形式和一个简单低效的形式之间的关系。 46
  • 47. 类图-实现关系例子 47
  • 48. 类图-聚合(Aggregation)关系 聚合(Aggregation):当对象A被加入到对象B中,成为对象B的组成部 分时,对象B和对象A之间为聚集关系。聚合是关联关系的一种,是较 强的关联关系,强调的是整体与部分之间的关系 组合(Composition):组合是聚合的变种,整体与部分之间有很强的 所有关系,也就是说,在组合关系中,一个对象一次只是一个组合的 一部分,而在聚合关系中,一个部分可以被好几个整体共享。 48
  • 49. 关联 vs. 聚合 关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车 就是一种关联关系,而不是聚合关系,因为人不是由自行车组成的。 聚合关系涉及的两个对象处于不平等的层次上,一个代表整体,一个 代表部分。比如电脑和它的显示器、键盘、主板以及内存就是聚集关 系,因为主板是电脑的组成部分。 对于具有组成关系(聚合关系的一种)的两个对象,整体对象会制约 它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周 期依赖于整体类的对象的生命周期,当整体消失,部分也就随之消失 。比如张三的电脑被偷了,那么电脑的所有组件也不存在了,除非张 三事先把一些电脑的组件(比如硬盘和内存)拆了下来。 49
  • 50. 组成 VS. 聚合 聚合:指的是整体与部分的关系。通常在定义一个整体类后,再去分 析这个整体类的组成结构。从而找出一些组成类,该整体类和组成类 之间就形成了聚合关系。 组合:也表示类之间整体和部分的关系,但是组合关系中部分和整体 具有统一的生存期。一旦整体对象不存在,部分对象也将不存在。部 分对象与整体对象之间具有共生死的关系。 聚合和组合的区别在于:聚合关系是“has-a”关系,组合关系是 “contains-a”关系;聚合关系表示整体与部分的关系比较弱,而组 合比较强;聚合关系中代表部分事物的对象与代表聚合事物的对象的 生存期无关,一旦删除了聚合对象不一定就删除了代表部分事物的对 象。组合中一旦删除了组合对象,同时也就删除了代表部分事物的对 象。 50
  • 51. IS-A VS. HAS-A 关联关系: ... has a ... 依赖关系: ... has a(uses a) ... 聚合关系: ... has a(owns a) ... 组合关系: ... has a(is a part of) ... 继承关系: ... is a ... 51
  • 52. 类图-约束条件 约束可以用来表示各种非局部的关系,如关联路径上的限 制。约束尤其可以用来表述存在特性(存在X则C条件成立 )和通用特性(对于Y中的所有y,条件D必须成立)。 约束用大括弧内的文字表达式来表示,可以使用形式语言 或自然语言。文字字符串可以写成注释或附加在依赖关系 的箭头旁。 52
  • 53. 对象图(Object Diagram) 对象图是显示了一组对象和他们之间的关系。使用对象图来说明数据 结构,类图中的类或组件等的实例的静态快照。对象图和类图一样反 映系统的静态过程,但它是从实际的或原型化的情景来表达的。 对象图显示某时刻对象和对象之间的关系。一个对象图可看成一个类 图的特殊用例,实例和类可在其中显示。对象也和合作图相联系,合 作图显示处于语境中的对象原型(类元角色)。 对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同 点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图 是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统 某一时间段存在。 53
  • 54. 对象图-表示方法 对象名 : 类 类 : 对象(记名对象) 匿名对象 54
  • 55. 对象图-例子 55
  • 56. 包图 包的表示法: 名称:每个包都必须有一个与其它包相区别的名称 拥有的元素:在包中可以拥有各种其它元素,包括类、接口、组 件、节点、协作、用例,甚至是其它包或图 包图目的: 描述需求高阶概述。 描述设计的高阶概述。 在逻辑上把一个复杂的图模块化。 组织程序源代码。 56
  • 57. 包图-包的版型 《system》:表示正在建模的整个系统 《subsystem》:表示正在建模的系统中某个独立的部分 《facade》:只是某个其它包的视图,它主要用来为其它一些复 杂的包提供简略视图 《stub》:是一个代理包,它服务于某个其他包的公共内容,这通 常应用于分布式系统的建模中 《framework》:用来表示一个框架的,框架是一个领域内的应用 系统提供可扩充模板的体系结构模式 57
  • 58. 设计类包的原则 复用等价原则 把类放入包时,应把包作为可复用的单元。 共用闭包原则 把需要同时改变的类放在一个包中。 共用使用原则 不会一起使用的类不要放在一个包中。 非循环依赖原则 包之间的依赖关系不要形成循环。 包也可以被创建来表示物理或逻辑关系. 58
  • 59. 包图-例子 59
  • 60. 组件图(Component diagram) 组件图系统中遵从并实现一组接口的物理的、可替换的软 件模块。组件图的主要目的是显示系统组件间的结构关系 在 UML 2 中,组件被认为是独立的,在一个系统或子系 统中的封装单位,提供一个或多个接口。虽然 UML 2 规 范没有严格地声明它,但是组件是呈现事物的更大的设计 单元,这些事物一般将使用可更换的组件来实现。 以组件为基础的开发(CBD)的主要思想是,你能容易地 在你的设计中重用及/或替换一个不同的组件实现,因为 一个组件封装了行为,实现了特定接口 60
  • 61. 组件表示法 61
  • 62. 组件的类型 一个系统往往由几个不同类型的软件模块组成,每一个软 件模块可以表示为一个组件 类型 部署组件:如dll文件、exe文件、com+对象、corba对象、ejb、 动态web页、数据库表等; 工作产品组件:如源代码文件、数据文件等,用来产生部署组件 执行组件:系统执行后产生的组件; 62
  • 63. 组件间的关系 依赖关系 一个组件如果使用另外一个组件的操作,则也可以在该组件和另 外一个组件的接口间建立依赖关系; 对象和源码间 两个组件中的类如果存在泛化关系,则组件间可以加依赖关系; 两个组件中的类如果存在使用关系,则组件间可以加依赖关系; 实现关系 63
  • 64. 子系统 子系统是具有单独说明和实现部分的包。通常表示按照一定的功能要 求或实现要求对系统进行的划分。 在 UML 2 中,子系统分类器是组件分类器的一个 特别版本。子系统符号元素象组件符号元素一样 继承所有的组件符号集规则。唯一差别是,一个 子系统符号元素由subsystem关键字代替了component, 在 UML 1. x 中,一个子系统被认为是一个软件包,但这很容易对许 多 UML 实践者造成困惑;因此,UML 2中把子系统作为特殊的组件 64
  • 65. 子系统-由包组成的子系统 65
  • 66. 部署图(Deployment diagram) UML部署图描述了一个运行时的硬件结点,以及在这些结 点上运行的软件组件的静态视图。 部署图显示了系统的 硬件,安装在硬件上的软件,以及用于连接异构的机器之 间的中间件。 创建部署模型的目的: 探究系统投产的相关问题. 探究你的系统和生产环境中的其它系统的依赖关系,这些系统可 能是已经存在,或是将要引入的。 描述一个商业应用主要的部署结构。 设计一个嵌入系统的硬件和软件结构。 描述一个组织的硬件/网络基础结构。 66
  • 67. 部署图-节点 节点是存在于运行时的代表计算资源的物理元素,可以代 表一种物理硬件设备或软件元素。 节点类型: 处理机(Processor): computer , pc , pc client , pc 处理机(Processor):«computer»,«pc», «pc client», «pc server»,«server», «unix server»,«user pc» 设备(Device): cdrom , cd-rom , disk array», 设备(Device):«cdrom», «cd-rom» ,«disk array , «secure»,«storage» 67
  • 68. 部署图-通信关联 通信关联,经常称为连接,被描述为连接结点间的线条。 组件间的依赖则被建模成虚线箭头,这和其他UML图上使 用的符号是一样的。可以象类图中一样加入角色、多重性 、约束等 为了更好地表示两个节点之间的关系,我们可以通过“约 束”来对连接进行描述。 68
  • 69. 部署图-例子 69
  • 70. 目 录 UML基础 UML静态建模 UML动态建模 70
  • 71. UML动态建模 交互图( Interaction Diagrams ) 顺序图( Sequence Diagrams ) 协作图( Collaboration Diagrams ) 状态图( State Diagrams ) 活动图( Activity Diagrams ) 71
  • 72. CRC(类-责任-协作) 72
  • 73. 顺序图(序列图) 顺序图主要用于按照交互发生的一系列顺序,显示对象之 间的这些交互。 顺序图的主要用途是把用例表达的需求,转化为进一步、 更加正式层次的精细表达。用例常常被细化为一个或者更 多的序列图。 顺序图的构成 参加交互的各对象在顺序图的顶端沿水平方向排列,对象之间传 递的消息用箭头表示,水平放置,沿垂直方向排列 在垂直方向上越靠近顺序图顶端的消息越先发送,从而给出了消 息被执行的先后顺序的明确而直观的表示 顺序图有两个主要的标记符:活动对象和这些活动对象之 间的通信消息。 73
  • 74. 顺序图-组成 活动者(actor) 对象(object) 生命线(lifeline) 控制焦点(focus of control )/激活期 消息(message) 交互片断(Interaction Frame) 74
  • 75. 顺序图-活动者或对象 一般活动者和对象按照从左到右的顺序排列,主要活动者 排在最左边; 75
  • 76. 顺序图-对象的命名方式 顺序图中对象的命名方式有三种: 包括对象名和类名 类名(匿名对象) 对象名(不关心类) 76
  • 77. 顺序图-生命线 每个对象的底部中心都绘有一个垂直虚线,当一个对象向另一个对象 发送消息时,消息始于发送对象底部的虚线,终止于接受对象底部的 虚线, 这条虚线被称为对象生存线(object lifeline)。 如果在顺序图上某一对象收到了创建消息或销毁消息,则此对象的生 存期始于它收到创建消息的时刻,终止于收到销毁消息的时刻 对象生存线代表一个对 象在一个时间段内的存在 77
  • 78. 顺序图-控制焦点 在UML里,由消息引发的动作的执行过程被描述为控制焦 点 控制焦点代表一个对象直接地或通过一个子过程间接地执 行一个动作的那段时间 绘制:它由位于对象生存线上的一个窄长方形代表,控制 焦点长方形的顶端代表动作的开始时刻,底端代表动作的 结束时刻。 控制焦点可以理解为是C语言中一对花括弧(“{}”)内 的内容 78
  • 79. 顺序图-控制焦点的嵌套 动作的执行过程可以引起其它消息的发送,从而对应子动 作的执行,就产生了控制焦点的嵌套 控制焦点的嵌套的表示: 另一个控制焦点向右叠放在父控制焦点上,子控制焦点中消息发 送的顺序号可以用过程顺序号表示 对象生存线和控制焦点,是顺序图所特有的,它不在协同图里出 现 79
  • 80. 顺序图-控制焦点例子 : V ie w c : C o n tr o ll e r : C a tc h e 控制焦点的嵌套 1 . c l i c k A t( p ) 1 .1 . I= f n d A t( p ) fi ( 控制焦点 1 .2 . p u tR e c e n tP ic k ( I) 对象生存线 80
  • 81. 交互图-顺序图 81
  • 82. UML消息 在面向对象技术中,对象间的交互是通过对象间消息的传 递来完成的。在UML的四个动态模型中均用到消息这个概 念。通常,当一个对象调用另一个对象中的操作时,即完成 了一次消息传递。当操作执行后,控制便返回到调用者。 对象通过相互间的通信(消息传递)进行合作,并在其生命 周期中根据通信的结果不断改变自身的状态。 在UML中,消息的图形表示是用带有箭头的线段将消息的 发送者和接收者联系起来,箭头的类型表示消息的类型 82
  • 83. UML消息-消息分类 依据通信性质的不同, UML将对象间交互信息的消息分为 五种:对象创建、同步调用、返回、异步消息、交叉异步 消息、对象销毁 83
  • 84. UML消息-消息分类例子 84
  • 85. UML消息-同步消息(Synchronous UML消息 同步消息(Synchronous Message) 同步消息(Synchronous Message) 表示嵌套的控制流。操 作的调用是一种典型的同步消息。调用者发出消息后必须 等待消息返回,只有当处理消息的操作执行完毕后,调用者 才可继续执行自己的操作。 85
  • 86. UML消息-异步消息( UML消息 异步消息( Asynchronous Message) 异步消息(Asynchronous Message) 表示异步控制流。当 调用者发出消息后不用等待消息的返回即可继续执行自己 的操作。异步消息主要用于描述实时系统中的并发行为。 86
  • 87. UML消息-返回消息(Return UML消息 返回消息(Return Message) 返回(Return Message):表示消息的返回。一般同步( 过程调用)的返回不需画出,直接隐含,而异步返回则可 用它。 87
  • 88. UML消息-自调用(Self Call) 自调用消息是从源生命线发送至它自身的一种消息。自调 用消息可以是递归调用或者对属于同一个对象的另一项操 作或信号的调用。 88
  • 89. 顺序图-分析级顺序图 89
  • 90. 顺序图-设计级顺序图 90
  • 91. 协作图(Collaboration Diagram) 协作图(也叫合作图)是一种交互图(interaction diagram) ,强调的是发送和接收消息的对象之间的组织结构。协作 图显示了一系列的对象和在这些对象之间的联系以及对象 间发送和接收的消息。对象通常是命名或匿名的类的实例 ,也可以代表其他事物的实例,例如协作、组件和节点。 使用协作图来说明系统的动态情况。 协作图组成 活动者(Actor) 对象(Object) 连接(Link) 消息(Message) 91
  • 92. 协作图-例子 92
  • 93. 顺序图 VS. 协作图 协作图与顺序图。协作图和顺序图都表示出了对象间的交 互作用,但是它们侧重点不同。 顺序图清楚地表示了交互作用中的时间顺序,但没有明确 表示对象间的关系。 协作图清楚地表示了对象间的关系,但时间顺序必须从顺 序号获得。 顺序图常常用于表示方案,而协作图用于过程的详细设计 。 93
  • 94. 活动图(Activity Diagrams) 活动图是一种特殊形式的状态机,用于对计算流程和工作 流程建模。活动图中的状态表示计算过程中所处的各种状 态,而不是普通对象的状态。通常,活动图假定在整个计 算处理的过程中没有外部事件引起的中断,否则,普通的 状态机更适于描述这种情况。 活动图包含活动状态。活动状态表示过程中命令的执行或 工作流程中活动的进行。与等待某一个事件发生的一般等 待状态不同,活动状态等待计算处理工作的完成。当活动 完成后,执行流程转入到活动图中的下一个活动状态。当 一个活动的前导活动完成时,活动图中的完成转换被激发 94
  • 95. 活动图-组成 活动(Activity) 决策(Decision ) 转换(Transition) 同步(Synchronizations) 泳道(Swimlanes) 对象流(Object Flow) 信号发送和接收 引脚(Pin) 95
  • 96. 活动图-例子 96
  • 97. 活动图-泳道图(分区) 97
  • 98. 活动图-对象流(Object Flow) 对象流(Object Flow)用来描述活动和活动所创建的(输出)或所 使用(输入)的对象之间的关系。 对象流状态表示活动中输入或输出的对象。对输出值而言,虚线箭头 从活动指向对象流状态。对输入值而言,虚线箭头从对象流状态指向 活动。如果活动有多个输出值或后继控制流,那么箭头背向分叉符号 98
  • 99. 活动图-带对象流的活动图 99
  • 100. 活动图-引脚(Pin) 引脚(Pin) 是一个对象节点,代表活动连接输入、输出值的连接点 用来标明每个活动节点所需输入的数据或者所产生的数据(建模 业务流时则可表示产生或者消耗的资源) 100
  • 101. 绘制活动图 绘制时首先决定是否采用泳道:主要根据活动图中是否要 体现出活动的不同实施者 然后尽量使用分支、分岔和汇合等基本的建模元素来描述 活动控制流程 如果需要,加入对象流以及对象的状态变化,利用一些高 级的建模元素(如辅助活动图、汇合描述、发送信号与接 收信号、引脚、扩展区)来表示更多的信息 活动图的建模关键是表示出控制流,其它的建模元素都是 围绕这一宗旨所进行的补充 101
  • 102. 活动图用于业务建模 在业务建模时候为了照顾阅读者的水平,建议使用比较直 观易懂的泳道活动图而不是分析模型常用的顺序图来表达 用于业务建模的时候,可以使用垂直实线将活动图划分为 泳道。每一条泳道表示一个职责单位,该图能够有效地体 现出所有职责单位之间的工作职责,业务范围及之间的交 互关系、信息流程 泳道之间的排序并不会影响语义。每个活动状态都指派了 一条泳道,而转移则可能跨越数条泳道。 102
  • 103. 泳道图用于业务建模 103
  • 104. 状态图(State Diagram) 状态图(State Diagram)用来描述一个特定对象的所有可 能状态及其引起状态转移的事件。大多数面向对象技术都 用状态图表示单个对象在其生命周期中的行为。一个状态 图包括一系列的状态以及状态之间的转移。 104
  • 105. 状态图-组成 状态图组成: 状态 转换 事件 105
  • 106. 状态图-状态 什么是状态(state) 对象生命期中的某个条件或状况,在此期间对象将满足某些条件 、执行某些活动或等待某些事件。 理解 对象在任何时候都会处于某种状态中,所有对象都有状态。 对象所处的状态决定了它如何响应所检测到的事件或所接收的消 息。 通常,事件使对象从一个状态转向另一个状态(即状态的转移) 106
  • 107. 状态图-状态类型 状态类型: 初态 终态 中间状态 复合状态 历史状态 107
  • 108. 状态图-初态、终态 初态 中间状态 108
  • 109. 状态图-复合状态 109
  • 110. 状态图-子状态机 110
  • 111. 状态图-历史状态 历史状态:一种伪状态。可以存储退出组合状态时所处的 子状态,则返回组合状态时可以直接回到到相应的子状态 。 111
  • 112. 状态图-转换 转换(Transition) 两个状态之间的一种关系,表示对象在第一个状态中执行一定的 动作,并在某个特定事件发生而且满足某个条件时进入第二个状 态。每个转换只允许一个事件,一个事件只允许一个动作 转换的五要素 源状态 目标状态 触发事件 监护条件 动作 112
  • 113. 状态图-事件 事件(Event) 是对一个时间和空间上占有一定位置的有意义的事情的规格说明 事件触发状态的转移 四类主要事件 信号事件 调用事件 变化事件 时间事件 113
  • 114. 状态图-用途 状态图用途 对对象生命周期建模:主要描述对象能够响应的事件、对这些事 件的响以及过去对当前行为的影响 对反应型对象建模:这个对象可能处于的稳定状态、从一个状态 到另一个状态之间的转换所需的触发事件,以及每个状态改变时 发生的动作 状态机图既可以用来表示一个业务领域的知识,也可以用 来描述设计阶段对象的状态变迁 典型应用:工作流引擎(workflow) 114
  • 115. 状态机-例子 115
  • 116. 状态图 vs. 交互图及活动图 状态机图与交互图的区别: 交互图不显示对象所有可能的动态行为,只显示特定交互(一个 具体的用例)中对象的行为。 状态机图可以显示对象所有的动态行为。 状态图机与活动图的区别: 状态机图只建模一个对象的行为,活动图可以建模多个对象的活 动 活动图中也允许建模特定活动中对象的某个状态 116
  • 117. 参考文档 UML精粹(第3版)Martin Fowler著 UML和模式应用(第2版)Craig Larman著 UML参考手册 James Rumbugh, IvarJacobson, Grady Booch 117
  • 118. 谢 谢! 118