面向对象的分析设计之UML基础

3,702 views

Published on

面向对象的分析设计之UML基础

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,702
On SlideShare
0
From Embeds
0
Number of Embeds
86
Actions
Shares
0
Downloads
123
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

面向对象的分析设计之UML基础

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

×