UML建模语言及工具
第二章 UML可视化建模实践 A Practice of Visual Modeling with UML
学习线路图 学 习 线 路 图 OO UML …… …… …… …… 第二章 第三章 第四章 OOA OOD DP … Case-Study … …… …… …… …… 学 习 线 路 图 第二章 第三章 第四章
本章目录 2.6 UML图概述 2.1 UML结构 2.7 用例图 2.2 物件 2.8 类图 2.3 关系 构造块 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 构造块
2.1 UML结构 构造块 公共机制 构架 UML Structure 基本UML建模元素、关系和图 达到特定目标的公共UML方法 building blocks 公共机制 common mechanisms 构架 architecture 基本UML建模元素、关系和图 达到特定目标的公共UML方法 系统架构的UML视图
构造块 构造块 公共机制 构架 物件 关系 图 UML Structure 建模元素本身 building blocks 公共机制 common mechanisms 构架 architecture 物件 things 关系 relationships 图 diagrams 建模元素本身 把物件联系在一起,关系说明两个或多个物件时如何语义相关的 UML模型的图,它们展现物件的集合,“讲述关于软件系统的故事”,是我们可视化系统将做什么(分析级图)或者系统如何做(设计级图)的方法
物件 物件 结构物件 行为物件 分组物件 注解物件 构造块 关系 图 things building blocks relationships 图 diagrams 结构物件 行为物件 分组物件 注解物件
关系 物件 关系 构造块 图 关联 依赖 泛化 实现 things relationships association dependency building blocks 物件 things 关系 relationships 图 diagrams 关联 association 依赖 dependency 泛化 generalization 实现 realization
collaboration diagrams 构造块 building blocks 图 物件 things 关系 relationships 图 diagrams 动态模型 (系统行为) 类图 class diagrams 顺序图 sequence` diagrams 对象图 object diagrams 协作图 collaboration diagrams 构件图 component diagrams 状态图 statechart diagrams 部署图 deployment diagrams 活动图 activity diagrams 静态模型 (系统结构) 用例图 use case diagrams
UML 9种图 结 构 行为 类 图:类以及类之间的相互关系 对象图:对象以及对象之间相互关系 构件图:构件及其相互依赖关系 类 图:类以及类之间的相互关系 对象图:对象以及对象之间相互关系 构件图:构件及其相互依赖关系 部署图:构件在各节点上的部署 顺序图:强调时间顺序的交互图 协作图:强调对象协作的交互图 状态图:类所经历的各种状态 活动图:对工作流建模 用例图:需求捕获,测试依据 结 构 静态图 实现图 交互图 行为 行为图 用例图
extensibility mechanisms 公共机制 UML Structure 构造块 building blocks 公共机制 common mechanisms 构架 architecture 规格说明 specifications 修饰 adornments 公共分类 common divisions 扩展机制 extensibility mechanisms
构架 构造块 构架 UML Structure 公共机制 用例视图 逻辑视图 进程视图 实现视图 部署视图 building blocks architecture 公共机制 common mechanisms 用例视图 Use case View 逻辑视图 Logic view 进程视图 Process view 实现视图 Implementation view 部署视图 Deployment view
总结:UML结构 2.2节 2.3节 2.4节 2.5节 2.6节以后
本章目录 2.6 UML图概述 2.1 UML结构 2.7 用例图 2.2 物件 2.8 类图 2.3 关系 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
2.2 物件 物件 结构物件 行为物件 分组物件 注解物件 UML模型中的名词,如类、接口、协作、用例、活动类、组件、节点 things 结构物件 行为物件 分组物件 注解物件 UML模型中的名词,如类、接口、协作、用例、活动类、组件、节点 UML模型的动词,如交互、状态机 包,它用于把语义上相关的建模元素分组为内聚的单元 注解,它附加到模型以捕获特殊信息,同黄色便笺很相像
2.2 物件 2.2.1 类 2.2.2 接口 2.2.3 组件 2.2.4 节点 2.2.5 包 2.2.6 注解 核心的结构物件 分组物件 注解物件
2.2.1 类 类的定义 表示形式 类的名称 类的类型 类的属性 类的操作
类的定义 类是具有相同属性、操作和关系的对象集合的总称。通常在UML中类被画成矩形,包括三个部分:名称、属性和操作。 名称:每个类都必须有一个名字,用来区分其它的类。 属性:类可以有任意多个属性,也可以没有属性。在类图中属性只要写上名字就可以了,也可以在属性名后跟上类型甚至缺省取值。 操作:操作是类的任意一个实例对象都可以调用的,并可能影响该对象行为的实现。
类的标准表示形式 类名 属性 操作
类的其他两种表示形式 ① 简化表示 ② 缩略表示 实体类 界面类 控制类
类的名称 名词或名词短语(动词或动词短语表示控制类) 尽可能明确、简短,业务领域中事物的名称,避免使用抽象、无意义的名词 例如:人,桌子,图形,汇总 尽可能明确、简短,业务领域中事物的名称,避免使用抽象、无意义的名词 例如:帐户,订单 用英文,第1个字母大写 例如:Shape, Person,CheckingAccount 可分为简单类名,带限定名的类名 例如:CheckingAccount, Banking::CheckingAccount
练习 指出下面命名有问题的类。
类的类型 按照其作用,类分为实体类,界面类和控制类三种类型。
实体类 实体类用来表示客观实体,像“图书”、“学生”,“订单”等都属于实体类。 实体类一般对应着在业务领域中的客观事物,或者是具有较稳定信息内容的系统元素。 实体类的名字用名词或名词短语。
界面类 界面类用来描述系统与外界之间交互的系统要素,也称为边界类。 界面类是对外界与系统之间交互的抽象表示,并不表示交互的具体内容,以及交互界面的具体形式。 界面类的名字用名词或名词短语。
一个表示界面的界面类
控制类 控制类表示系统用来进行调度、协调、处理,以及业务处理的系统要素。 控制类的名字用动词或动词短语表示。
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}]
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 第1个英文单词首字母小写,其它单词首字母大写 [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 第1个英文单词首字母小写,其它单词首字母大写 contactName creditLimit isPrepaid
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 该属性对外部实体的显现程度. [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 该属性对外部实体的显现程度. 公有public : + 所有可见 受限protected: # 子类及本身可见 私有private : - 本身可见 包 package : ~ 包内可见
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 属性的数据类型: 字符串:String 日期:Date [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 属性的数据类型: 字符串:String 日期:Date 布尔:Boolean 整型:int 其他
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 表示属性取值的多寡,以及有序性: [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 表示属性取值的多寡,以及有序性: 例如: name:String[0..1] 表示属性”name”可能无值,也可能仅有一个值. points:Point[2..* ordered] 表示有两个或多个值,有序
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 表示属性初始所取的值: [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 表示属性初始所取的值: 例如: #visibility:Boolean=false 表示属性”visibility”初始取”false”
类的属性 属性的含义(attribute) 属性的格式 描述类所表示事物的静态性质。 表示属性约束说明: [可见性]属性名[:类型][‘[ ’多重性[次序]‘]’][=初始值][{特性}] 表示属性约束说明: 例如: #visibility:Boolean=false{读写} 表示属性”visibility”可读,写
练习 指出下面属性名的含义。 +studentName:String=“黎明” #studentBirthDay:Date=1999-10-21 -price:float=12.01{R/W} 教学进程
类的操作 操作的含义 操作(operation): 描述类所表示事物的动态性质。 操作的格式 [可见性]操作名[(参数列表):返回类型]
类的操作 操作的含义 操作的格式 操作(operation): 描述类所表示事物的动态性质。 [可见性]操作名[(参数列表):返回类型] 第1个英文单词首字母小写,其它单词首字母大写 close() creditRecording()
类的操作 操作的含义 操作的格式 操作(operation): 描述类所表示事物的动态性质。 [可见性]操作名[(参数列表):返回类型] 该操作对外部实体的显现程度. 可见public : + 受限protected: # 私有private : - 包 package : ~
类的操作 操作的含义 操作的格式 操作(operation): 描述类所表示事物的动态性质。 [可见性]操作名[(参数列表):返回类型] 该操作的形式参数,可以为空. 例如: #create() +hide() -attachXWindow(xwin: Xwindow)
类的操作 操作的含义 操作的格式 操作(operation): 描述类所表示事物的动态性质。 [可见性]操作名[(参数列表):返回类型] 该操作的返回值的类型. 例如: +display():Boolean
练习 指出下面操作名的含义。 +setName(name:String) +getName():String +creatBook()
2.2.2 接口 接口是未给出实现的对象行为的描述,一个或多个类可以实现接口,每个类实现接口的操作。 Hashable String isEqual(String) : Boolean Hash() : Integer … Hashable Comparable 接口标记
2.2.3 组件 组件代表了一个接口定义良好的软件模块。 一个组件可能是源代码、可执行程序或动态库。 例如:一个DLL,一个JavaBean Student
2.2.4 节点 节点代表系统运行时的物理单元,主要用于系统物理方面的建模。节点可以分为处理器和设备两种。 处理器:任何具有处理功能的机器,如服务器,工作站。处理器用边框为黑色的立方体表示。 设备:没有处理功能的机器,如打印机,扫描仪。设备用边框为白色的立方体表示。
2.2.5 包 包是一个用来将模型单元分组的通用机制。 包可以含有类、接口、组件、用例等物件或其它的包。 包 Package
包的作用 任何大系统都必须划分为较小的单元,以便人们在某一时刻可以和有限的信息工作,使团队的工作不相互影响。
2.2.6 注释 注释用于解释设计的思路,便于理解。 一个好的模型应该有详尽的注释。 注释 Represents an incorporated entity Company …
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.3 关系 关系 关联 依赖 泛化 实现 描述对象之间的一组链接 物件的改变引起依赖物件的语义改变 relationships 关联 association 依赖 dependency 泛化 generalization 实现 realization 描述对象之间的一组链接 物件的改变引起依赖物件的语义改变 一个元素是另一个元素的特化,而且它可以取代更一般的元素 类元之间的关系,一个类元说明一份契约,另一个类元保证实现该契约
2.3 关系 2.3.1 关联 2.3.2 依赖 2.3.3 泛化 2.3.4 实现 2.3.5 关系小结
2.3.1 关联 关联的定义 关联的表示形式 连接 聚合 组合
关联 关联关系描述表示两个类之间的一种结构关系。 关联到类的连接点称为关联端点,很多信息被附在关联端点上,它拥有角色名、重数(多少个类的实例可以关联于另一个类的实例)等。
关联的例子 关系 月老 小伙 姑娘 恋人 玫瑰 干妈 舅妈 撮合者 没关系 干儿子 男友老公 男主角 买送主 外甥女 女友太太 女主角 受主 作品 组合 使用者 信物 受物心意
关联的表示形式 关联名称 重数 Job 1..* Company * Person employer employee 角色名
关联——多重性 多重性(multiplicity):指定了一个类与关联类的单个实例可能相关的实例数目。 “1”、“*”、“0..1”、“3..5” 不要在软件开发早期过度担心多重性。首先确定类和关联,然后再确定多重性。
关联——关联终端名 关联终端名(association end):指定了关联终端的名字。 关联终端名在问题陈述中常以名词形式出现。 关联终端名的使用是可选的,但是对于同一个类的两个对象之间的关联来说,关联终端名是必需的。关联终端名也可以区分同一对类之间的多重关联。 在创建类图时,应该正确使用关联终端名,不应该为每个引用引入一个独立的类。
关联——关联终端名 User Directory Person Parent Child owner authorizedUser * 1 Directory container contents * 0..1 Person 正确的模型 * 0..2 parent child Parent Child 2 * 错误的模型
关联——关联类 关联类(association class):是一种关联,也是一种类。描述了关联的属性和操作。 不应把关联类的属性建模为类的属性。 Person name birthDate address Company * 0..1 WorksFor salary jobTitle
关联——限定关联 限定关联(qualified association):是这样一种关联,其中被称为限定符(qualifier)的属性会消除在“多”关联端上对象的歧义。 限定符在目标对象间进行选择,将多重性从“多”降到“1”。 Bank * 1 Account accountNumber 未限定 Bank Account accountNumber 0..1 1 限定
关联——n元关联 要尽量避免n元关联——大部分关联可以分解成带限定符和属性的二元关联。 n元关联的UML符号是以直线连接相关类的一个菱形。
accountingSystem:Project Language Person * programmer 类图 Cobol:Language Mary:Person accountingSystem:Project name=“accounting system” CADprogram:Project name=“CAD program” name=“Cobol” C:Language name=“C” name=“Mary” 对象图
关联之间的几种表现形式
连接 最弱的关联,只是表示两个类对象之间有导航关系
双向连接的代码表达形式
单向连接的代码表达形式
聚合 具有has a语义,对象A是对象B的一个组成部分
聚合的代码表达形式
组合 强语义的聚合,整体对象消失,部分对象也消失
组合的代码表达形式
思考题 连接、聚合和组合关系在1对多的情况下,其代码怎样表达?
聚合vs组合(UML观点) 整体对象 部分对象 组合 整体对象 部分对象 聚合 例:公司和雇员 例:订单和订单项
2.3.2 依赖 依赖:如果一个模型元素的变化会影响另一个模型元素,那么二者之间存在依赖关系。 依赖类型
2.3.3 泛化 泛化是一般化和具体化之间的一种关系。 继承就是一种泛化关系,更一般化的描述称为双亲,双亲的双亲称为祖先,更具体化的描述称为孩子。 祖先 Tree Person 双亲 Student 孩子 Oak Elm Birch Graduate
<<interface>> 2.3.4 实现 多数情况下,实现关系被用来规定接口和实现接口的类或组件之间的关系 <<interface>> Comparable 实现 特殊的实现标记 isEqual(String) : Boolean Hash() : Integer … String Comparable isEqual(String) : Boolean Hash() : Integer …
2.3.5 关系小结 语义上,所有的关系(包括关联、泛化、实现)都是各种各样的依赖关系,因为这3种关系具有重要的语义,所以在UML中被分离出来成为独立的关系。
本章目录 2.6 UML图概述 2.1 UML结构 2.7 用例图 2.2 物件 2.8 类图 2.3 关系 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
UML结构 UML Structure 构造块 公共机制 构架 基本UML建模元素、关系和图 达到特定目标的公共UML方法 building blocks 公共机制 common mechanisms 构架 architecture 基本UML建模元素、关系和图 达到特定目标的公共UML方法 系统架构的UML视图
extensibility mechanisms 公共机制 公共机制 common mechanisms 规格说明 specifications 修饰 adornments 公共分类 common divisions 扩展机制 extensibility mechanisms
2.4 公共机制 2.4.1 规格说明 2.4.2 修饰 2.4.3 公共分类 2.4.4 扩展机制
2.4.1 规格说明 UML模型至少具有两种维度: 规格说明 图形维度:允许使用图和图标可视化模型 文本维度:由各种建模元素的规格说明所组成 模型元素的特征和语义的文本描述—模型的“肉” 形成了承载模型的语义背板(semantic backplane),赋予模型意义,各种图仅仅是该背板的视图或者可视化投影 death by diagram—由于图形而死亡
Rose中类的规格说明
2.4.2 修饰 修饰:图中建模元素上暴露的信息项以表现某个要点 任何UML图仅是模型的视图,因此,只有在修饰增强了图的整体清晰性和可读性或者突出模型的某些重要特征时,你才应该表示那些修饰 Window
2.4.3 公共分类 公共分类描述认识世界的特殊方法 类元(Classifier)和实例 接口(interface)和实现 类元:一类事物的抽象概念;如bank account 参与者、类、类元角色、组件、数据类型、接口、节点、信号、子系统、用例 实例:一类事物的特定实例;如my bank account 接口(interface)和实现 接口:说明事物行为的契约(做什么) 实现:事物是如何工作的特殊细节(如何做)
2.4.4 扩展机制 约束:允许对模型元素添加新的规则 构造型(stereotypes):基于已有的建模元素引入新的建模元素 扩展机制的三个组成 约束:允许对模型元素添加新的规则 构造型(stereotypes):基于已有的建模元素引入新的建模元素 The means by which to extend the UML Stereotypes convey key properties to the model reader A number of stereotypes are packaged along with the UML Can define your own stereotypes 标记值:允许为模型元素添加新的特性,是带有相关值的关键字
约束 约束是用文字表达式表示的语义限制。 约束用大括弧内的字符串表达式表示。
构造型 UML中元素具有通用的语义,用构造型可以对它们进行专有化和扩展 构造型机制是指在已有的模型元素基础上建立一种新的模型元素。它与现有元素要相差不多,只是多一些特别的语义
标记值 标记值是一组字符串,存储着有关元素的一些信息。
EventQueue 《exception》 Overflow add() remove() flush() {ordered} {version=3.2 Author = egb} add() remove() flush() {ordered}
本章目录 2.6 UML图概述 2.1 UML结构 2.7 用例图 2.2 物件 2.8 类图 2.3 关系 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
UML结构 UML Structure 构造块 公共机制 构架 基本UML建模元素、关系和图 达到特定目标的公共UML方法 building blocks 公共机制 common mechanisms 构架 architecture 基本UML建模元素、关系和图 达到特定目标的公共UML方法 系统架构的UML视图
2.5 构架 构架概述 4+1视图 Use Case View(用例视图) Logical View(逻辑视图) Process View(进程视图) Implementation View(实现视图) Deployment View(部署视图)
构架(Architecture) The organizational structure of a system, including its decomposition into parts, their connectivity, interaction mechanisms, and the guiding principles that inform the design of a system 构架是一个系统的组织结构,包括系统分解成的各个部分、它们的连接性、交互机制和系统设计的指导规则。
4+1视图
Use Case View End-user: Functionality 这些视图由用例视图所统一,它描述项目干系人(stakeholder)的需求;所有其他视图都是从用例视图派生而来,该视图把系统的基本需求捕获为用例,并提供构造其他视图的基础。
Logical View Analysts/Designers: Structure 系统功能和词汇;描述问题域的词汇,构造类和对象的集合。重点是展示对象和类是如何组成系统、实现所需系统行为的。
Process View System integrators: Performance, Scalability, Throughput 系统性能、可伸缩性和吞吐量;将系统中的可执行线程和进程作为活动类来建模。其实,它是逻辑视图面向进程的变体,包含与逻辑视图相同的制品。
Implementation View Programmers: Software Management 系统组装和配置管理;对组成基于系统的物理代码的文件和组件进行建模。它同样展示出组件之间的依赖,展示一组组件的配置管理以定义系统的版本。
Deployment View System engineering: System Topology, Delivery, Installation, Communication 系统的拓扑结构、分布、移交和安装;建模把组件物理地部署到一组物理的、可计算节点上,如计算机和外设上。它允许建模横跨分布式系统节点上的组件分布
总结:UML结构 下面将要学习的知识点
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.6.1 UML图概述 UML1.4版本下图分类 UML2.0版本下图分类
collaboration diagrams UML图(UML1.X) 图 diagrams 静态模型 (系统结构) 动态模型 (系统行为) 类图 class diagrams 顺序图 sequence` diagrams 对象图 object diagrams 协作图 collaboration diagrams 构件图 component diagrams 状态图 statechart diagrams 部署图 deployment diagrams 活动图 activity diagrams 用例图 use case diagrams
UML 9种图 结 构 行为 类 图:类以及类之间的相互关系 对象图:对象以及对象之间相互关系 构件图:构件及其相互依赖关系 类 图:类以及类之间的相互关系 对象图:对象以及对象之间相互关系 构件图:构件及其相互依赖关系 部署图:构件在各节点上的部署 顺序图:强调时间顺序的交互图 协作图:强调对象协作的交互图 状态图:类所经历的各种状态 活动图:对工作流建模 用例图:需求捕获,测试依据 结 构 静态图 实现图 交互图 行为 行为图 用例图
state machine diagrams UML图(UML2.0) 图 diagrams 结构图 行为图 顺序图 sequence diagrams 类图 class diagrams 交互图 interaction diagrams 通信图 communication diagrams 对象图 object diagrams 状态图 state machine diagrams 交互概图 interaction overview diagrams 构件图 component diagrams 活动图 activity diagrams 部署图 deployment diagrams 时序图 timing diagrams 用例图 use case diagrams 包图 package diagrams 复合结构图 composite structure diagrams
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.7 用例图 三个概念 用例图元语 Post系统用例图 图书馆借阅管理用例图
概念1-场景 场景:是用来描述用户和系统之间交互的顺序的步骤 A scenario is a sequence of steps describing an interaction between a user and a system A scenario is an instance of a use case.
概念2-用例 用例:是为了达到某一用户目标而组合在一起的一组场景 A use case, then, is a set of scenarios tied together by a common user goal. web application product
Use-Case Flow of Events In the Maintain Student Information use case, there may be separate sub-flows for adding, deleting, and modifying student information. Don’t be too concerned with the exact definition “basic” versus “alternate or exception.” Readability and understandability are the key here. Note: The colors are not distinguishable in the black-and-white books. That’s okay. The picture still provides value, as the alternate flows are visible. Has one normal, basic flow Several alternative flows Regular variants Odd cases Exceptional flows for handling error situations A use case flow of events: Contains the most important information derived from use-case modeling work. Should describe the use case's flow clearly enough for an outsider to easily understand it. Should present what the system does, not how the system is designed to perform the required behavior. Guidelines for the flow of events. Specify that the content must: Detail the flow of events. All "what“ questions should be answered. Remember that test designers will use this text to identify test cases. Describe how the use case starts and ends. Describe the flow of events, not only the functionality. To reinforce this, start every action with "When the actor. . . .” Describe only the events that belong to the use case and not what happens in other use cases or outside of the system. Describe the data exchanged between the actor and the use case. Avoid describing the details of the user interface unless they are needed to provide an understanding the behavior of the system. Avoid vague terminology such as "for example", "etc.," and "information."
概念3-用例图 用例图:用来显示在系统(或其它实体)内的用例与系统参与者之间的关系 A use case diagram shows the relationship among use cases within a system or other semantic entity and their actors 主要使用场合:需求获取、定义、分析
用例图元语 用例 扩展 包含 参与者 泛化 注释体 系统边界 注释连接 关联 <<extend>> <<include>> 包含 参与者 泛化 注释体 系统边界 注释连接 关联
示例1:POST系统 销售点终端(Point-Of-Sale Terminal,POST)系统 是一个计算机自动化系统 用来记录商品销售信息 处理客户的支付信息 客户可以使用现金、信用卡、支票等多种支付手段 主要用于零售的百货商店 包括计算机和条形码扫描仪等硬件设备和系统运行软件 ……
示例1:POST用例图
用例阐述 Use Case:购买商品 ID UC1 参与者 Cashier,Customer 交叉引用 … 描述 顾客带着所要购买的商品来到付款处,出纳员记录下商品信息并接受付款,付款完成后,顾客带着所购买的商品离开 前置条件 客户购买了若干件商品 基本事件流: 用例起始于顾客带着所要购买的商品到达一个销售点终端 出纳员录入每个商品的商品号,如果出现多个商品,则还需要录入数量 系统确定商品信息输入到正在运行的POST系统,显示当前商品信息和价格 输入完商品信息后,出纳员向POST发出提示,提示商品信息录入完毕 计算和显示顾客的商品价格总额 出纳员将商品价值总额报告给顾客 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额,打印付款收据 出纳员收管好现金并取出要找还给顾客的现金,并支付给顾客打印付款收据 系统记录本次交易 顾客带着所购的商品离开 备选事件流: 第2步:如果输入的商品号码无效,系统显示出错信息 第7步:顾客没有足够的现金,则取消本次交易 后置条件
示例2:借阅管理用例图
示例3:简单手表用例图
用例图练习 图书馆管理系统 一、确定系统的参与者:读者(借阅者)、图书馆管理员、图书馆管理系统维护者 二、确定系统的用例:
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.8 类图 2.8.1 类图概述 2.8.2 类图的阅读方法 2.8.3 类图的抽象层次 2.8.4 类图的构建步骤
2.8.1 类图概述 类图概念 类图元语 类图示例-POST系统
类图 类图:是软件的蓝图,详细描述了系统内各个对象的类型,以及这些类之间的静态关系 A class diagram is a software blueprint -Details the types of objects within a system -Describes the static relationships between classes 主要使用场合:系统分析、设计、代码生成
类图元语-1 类 第一栏是类名,第二栏是类的属性,第三栏是类的操作 包 包表示一个类图的集合 关联 关联用于表示类的对象之间的关系,其特殊形式有组合关联和聚合关联 聚合关联 聚合关联用于表示类的对象之间的关系是整体与部分的关系 组合关联 组合关联用于表示类的对象之间的关系是整体拥有各部分且部分与整体共存亡 Package
类图元语-2 泛化关系 泛化关系(继承关系)定义类和包之间的一般元素和特殊元素之间的分类关系 依赖关系 有两个类或包X、Y,修改X的定义引起对Y的定义的修改,则称Y依赖于X 注释体 注释体用于对UML实体进行文字描述 注释连接 注释连接将注释体与要描述的实体相连
示例:POST系统类图
2.8.2 类图的阅读方法 阅读方法概述 一个电子商务类图的阅读过程 找出类 找出关系 理解多重性 理解方法
如何阅读类图 类: 先看清有哪些类 关系: 然后看类之间的关系 多重性,属性和方法: 结合多重性来理解类图的结构特点以及各属性、方法的含义
OO思想
一个电子商务类图 收件人 消费者 (买家) 卖家
阅读过程1-找出类 Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Product
阅读过程2-找出关系 从图中关系最复杂(也就是线最密集)的类开始阅读,如Order类 OerderItem和Order之间是组合关系,根据箭头方向可知Order包含了OrderItem Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说,一个订单和客户、收货人、送货单是相关的。
阅读过程3-理解多重性 多重性:用来说明关联的两个类之间的数量关系
阅读过程4-理解方法 Order类有两个方法dispatch()和close (),从名字中可以猜出它们分别实现“分发订单生成送货单”和“完成订单”。 DeliveOrder 类中有一个close ()方法,同理,它表示“完成送货”。 而在OrderItem中有一个stateChange ()方法和deliverState,不难猜出它就是用于改变其“是否交给收货人”标志位的。
先调用Order的dispatch ()方法,它将根据其包含的OrderItem中产品信息,来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder,并在执行完成后再调用close ()方法。此时,就将调用OrderItem的stateChange()方法来改变其状态。同时再调用Order的close()方法,判断该Order的所有的OrderItem是否都已经送到了,如果是就将其真正close()掉。
wwshijian
2.8.3 类图的抽象层次 概念层 逻辑层 实现层
类图的抽象层次 在系统的不同开发阶段,类图可以具有不同的抽象程度。随着开发的深入,类图应该越来越详细、具体。 可以分为:概念层,逻辑层,实现层。 概念层 逻辑层 实现层
概念层类图 在概念层,类图一般以抽象的方式描述从业务领域中抽取的业务对象之间的关系。特点是: 抽象反映业务对象之间的关系; 不展开类中的内容; 对类用缩略表示或简化表示。
逻辑层类图 在逻辑层,需要展开类图中类的内容,但对类的内容不需要过于详细,仅列出属性名和操作名就可以。特点是: 逻辑层是对概念层的深化; 展开类中的内容,但可以不包括细节; 对类用一般表示形式。
实现层类图 在实现层,需要展开类的所有内容,包括属性名,类型,可见性,初始值等。实现层中的类应该能够立即用于编程实现。特点是: 实现层是对逻辑层的深化; 展开类中的内容,包括细节; 对类用一般表示形式。
2.8.4 类图的构建步骤 类图的构建步骤 一个关于图书馆图书借阅管理的类图 一个实现旅游宾馆预订的类图
建立类图的一般步骤: ① 研究分析问题领域,确定系统需求; ② 抽取类,明确类的含义和职责,确定类的属性和操作; ③ 确定类之间的关系。关联,泛化,聚合,组合,依赖; ④ 调整和细化类及其关系,解决重复和冲突; ⑤ 绘制类图,并增加相应说明。
示例:绘制图书馆图书借阅管理的类图 每一种图书,包括:书名、作者、ISBN号、出版社、单价。每一册图书对应着一个唯一的图书编号。 有许多注册读者,读者的信息包括读者编号、姓名、出生日期、职业、电话、通信地址、邮政编码、邮箱。 每一个读者拥有一个借书证,借书证包括读者编号、注册日期、读者类型。读者每次可以凭借书证借图书, 图书馆要对读者借书登记借书记录,借书记录中登记读者、所借图书、借出日期、返还日期、管理员等信息。 管理员的信息有:编号、姓名、性别、出生日期、岗位、学历、职称。
1.提取本问题的类 图书;读者;借书证;借书记录;管理员
2.确定各个类的属性
3.确定类之间的关系 ① 读者与借书证的关系? 关联关系 多重性:1对1
② 图书,管理员,借书证与借书记录之间的关系?
4.画出完整类图
无效对象 示例:提取旅游宾馆预订的类图 张博在大学期间为了锻炼职业能力,和几个要好的同学注册了一个提供旅游服务预订业务的公司,该公司负责为在校学生的暑假旅游提供服务 各旅游胜地的宾馆向他们提供在暑假期间可以预订的客房信息,包括客房的大小、设施、价格等。希望旅游的在校学生则通过这个公司提供的房间信息,进行客房预订 学生在预订客房时,需要提供自己的学号、姓名、性别、年龄、身份证号、所在学校等基本信息,并提供希望预订的客房和时间,学生需要交纳一定的预订手续费和预订押金 预订之后,发生特殊情况,学生可以撤除预订或更改预订
1 提取本问题的类 旅游地;宾馆;学生;客房;订单
2 确定各类的属性
3 确定类之间的关系 1 “旅游地”和“宾馆”的关系
2 “客房”分析 客房应该有不同的类型 客房类型
2 “客房”分析 客房应该有不同的状态 客房状态
2 “客房”分析 宾馆记录包含的客房 组合关系
3 客房预订分析 通过 “订单”描述客房的预订信息,“订单”应该有状态,提取“订单状态”
3 客房预订分析 客房预订涉及到“学生”,“订单”,“宾馆”和“客房”几个类 假设一个订单可以预订到多个客房。
4 画出完整类图
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.9 对象图和包图 对象图的概念 对象图的表示 包的概念和作用 包的表示 书店图书管理的包图
对象图的概念 对象图:表示在某一时刻类的对象静态结构和行为 An object diagram represents a concrete situation at a given time, it express both the static structure (found in class diagrams) and behavior 描述类图在某一时刻,各个类中的对象相互之间的关系,相当于对类图在某时刻的一个快照 。
对象图的表式 对应着同一幅类图,在不同时间绘制出来的对象图是不一样的 类图: 对象图:
包的概念和作用 包(Package): 是UML用来组织模型元素的模型元素。 包中存放的模型元素可以是:类、接口、构件、用例、节点、活动、状态、包和图等。
包的表示 名称:每个包都必须有一个与其它包相区别的名称 简单名、路径名
书店图书管理的包图
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.10 顺序图和协作图 2.10.1 交互图概述 2.10.2 顺序图概念 2.10.3 顺序图组成 2.10.4 建立顺序图的步骤 统称为交互图 2.10.1 交互图概述 2.10.2 顺序图概念 2.10.3 顺序图组成 2.10.4 建立顺序图的步骤 2.10.5 顺序模型的准则 2.10.6 一个还书的例子 2.10.7 协作图
2.10.1 交互图概述 Interaction diagram,是描述对象之间的关系和对象之间的信息传递的图; 通常用来描述一个用例的行为,实现一个用例,完成对系统的动态行为建模; 包含两种: 顺序图(或时序图,sequence diagram) 协作图(collaboration diagram)(UML2.0版本之后,协作图被称为通信图。 )
顺序图 面向时间描述对象交互的图 协作图 对象间消息的结构化视图
2.10.2 顺序图概念 按照时间顺序显示对象之间交互的图
2.10.3 顺序图组成 1 活动者(actor)或对象(object) 2 生命线(lifeline) 3 激活(activation)/ 控制焦点(focus of control) 4 消息(message)
1 活动者(actor)或对象(object) 活动者和对象按照从左到右的顺序排列 一般最多两个活动者,他们分列两端。启动这个用例的活动者往往排在最左边;接收消息的活动者则排在最右端; 对象从左到右按照重要性排列或按照消息先后顺序排列。
活动者或对象的命名方式 对象的命名方式有三种: 包括对象名和类名 类名(匿名对象) 对象名(不关心类)
2 生命线(Lifeline) 每个对象都有自己的生命线,用来表示在该用例中一个对象在一段时间内的存在 垂直的虚线 如果对象生命期结束,则用注销符号表示 对象默认的位置在图顶部,表示对象在交互之前已经存在 如果是在交互过程中由另外的对象所创建,则位于图的中间某处。
在交互之前已经存在 在交互过程中由另外的对象所创建 注销符号
3 激活期(activation)/控制焦点(focus of control) 对象在一段时间内获得了焦点,也称激活期 对象执行某个动作的时期 空心矩形条 激活期的长短意味着对象执行某个动作的时间有多长,可以通过约束{10ms}来限制执行时间的长短。
4 消息(message)-1 面向对象方法中,消息是对象间交互信息的主要方式。 结构化程序设计中,模块间传递信息的方式主要是过程(或函数)调用。 对象A向对象B发送消息,可以简单地理解为对象A调用对象B的一个操作(operation)。
4 消息(message)-2 顺序图中,尽力保持消息的顺序是从左到右排列的。 一个顺序图的消息流开始于左上方,消息2的位置比消息1低,这意味着消息2的顺序比消息1要迟。 顺序图中消息编号可显示,也可不显示。 协作图中必须显示。
4 消息(message)-3 UML三种消息: 调用(Procedure Call) 异步(Asynchronous) 返回(Return)
调用(Procedure Call) 发送者把消息发送后,等待直到接收者返回控制,可以表示同步; 实心箭头符号
一种特殊的调用——自调用(Self Call) 某对象自己调用自己的操作 UML标记 (嵌套的矩形条) Rose标记
异步(Asynchronous) 消息发送后,发送者继续操作,不等待,常用于并发;
返回(Return) 表示消息的返回。消息上方放置返回值 虚线箭头表示,和依赖关系不要混淆 同步消息的返回可以画出(如果想明确表达返回值),也可以不画出,直接隐含。 异步消息可以有返回,也可以没有。(可以响应异步消息,也可以不响应该异步消息。)
2.10.4 建立顺序图的步骤 建立顺序图的步骤 存款顺序图 打印顺序图 买入股票的顺序图 买入股票失败的顺序图
建立顺序图的步骤 确定交互的范围; 识别参与交互的对象和活动者; 设置消息; 细化消息;
案例:存款 分析级别的顺序图,粗略,双斜杠 忽略消息同步异步类别也无妨
案例:打印 用户打印文件,计算机向打印服务器发送打印命令,打印机如果空闲,则直接打印,否则把打印文件存储在打印队列中。
买入股票的顺序图 :顾客 :股票经纪人系统 :证券交易所 买入股票的顺序图 输入买入日期 {验证资金} 申请确认 确认买入 下订单 显示订单号 下订单 报告交易结束 {验证资金} {执行订单} 买入股票的顺序图
买入股票失败的顺序图 :顾客 :股票经纪人系统 :证券交易所 输入买入日期 拒绝买入 取消买入 {验证资金:资金不足} 买入股票失败的顺序图
2.10.5 顺序模型的准则 至少为每个用例编写一种场景; 把场景抽象为顺序图; 划分复杂的交互; 为每种错误条件绘制一张顺序图。
2.10.6 一个还书的例子 图书借阅管理用例图 用例描述 用例分析 识别对象 设计类图 设计顺序图
还书用例 用例:还书 参与者:管理员,借阅者 操作流: ①管理员进入图书借阅界面,用例开始。 ②系统要求输入所还图书的条码。 ③系统显示所还图书的图书、读者、借阅等信息。 ④确认还书。 ⑤系统回到上一界面,等待处理下一业务。
用例分析 ① 识别交互过程。 读者在还书时,先由管理员把所借图书的图书编号扫描给系统,系统接收到这个信息,则显示这个该读者信息,以及这本书的信息。 管理员确认还书,则系统登记还书信息,并返回还书成功信息,还书过程完成。
识别对象 ② 识别参与交互过程的对象;
设计类图 ③ 绘制还书处理类图
设计顺序图 ④ 从引发交互的初始消息开始,在对象生命线上依次画出交互的消息
2.10.7 协作图 协作图概述 对象与多对象 存款协作图
协作图概述 描述系统对象(或活动者)如何共同协作实现用例; 强调的是参与交互的对象的组织; 一般,顺序图和协作图可以相互转换,Rose提供了转换工具。 先画顺序图,再转成协作图更容易
对象 协作图中的对象是一组属性和一组方法的封装体 根据是否含有主动方法,分为主动对象和被动对象: 主动对象中至少有一个方法不需要接收消息就能主动执行(称为主动方法)。主动对象是不需接收消息就可自动启动交互的对象 除了含有主动方法外,主动对象和被动对象无区别 UML标记 Rose标记
多对象 多对象是多个对象组成的集合,往往是同一个类的对象; 如果消息同时发给多个对象,则用多对象表示; 在顺序图中仍然显示为单对象一样的图标, rose中multiple instance 协作图中重叠的方框。
案例:存款
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.11 状态图与活动图 2.11.1 状态图 2.11.2 活动图的概念 2.11.3 活动图的作用 2.11.4 活动图组成 2.11.5 活动图示例 2.11.6 几种动态图比较
2.11.1 状态图 状态图概念 状态图元语 状态图示例
2.11.1 状态图概念 状态图:用于利用状态和事件描述对象本身的行为 A statechart diagram can be used to describe formally the behavior of objects in terms of states and events 状态(states): the state of an object 转移(transitions): the passing from one state to another 事件(events): the occurrence of a given situation 主要使用场合:系统分析(类)、设计
2.11.2 状态图元语 状 态 初态 表示状态图的起始点 中间状态 表示状态图的简单状态 终态 表示状态图的终点 转移 状 态 转移 用于说明两个对象间存在某种关系,如满足某个条件并当某一事件发生时,对象将从一个状态变迁到另一个状态并同时执行一些活动 注释体 注释连接
示例:状态图
状态图 Transitions Source State Target State Trigger [ guard ] / Effect
转换(Transitions) 转换表示当一个特定事件发生或者某些条件得到满足时,一个源状态下的对象在完成一定的动作后将发生状态转变,转向另一个称之为目标状态的状态。 转换进入的状态为活动状态,转换离开的状态变为非活动状态。
转换组成: 源状态:即受转换影响的状态 目标状态:当转换完成后对象的状态 触发事件:用来为转换定义一个事件,包括调用、改变、信号、时间四类事件 监护条件:布尔表达式,决定是否激活转换 动作:转换激活时的操作
Idle Menu visible right button down/ display pop-up menu right button up/ erase pop-up menu Cursor moved/ highlight menu item
触发事件(Event Trigger) 触发事件是能够引起状态转换的事件。 转换也可以是非触发的, 非触发转换(Triggerless Transition)也被称为完成转换(Completion Transition),当源状态完成活动时,转换被隐式地触发。
触发事件(Event Trigger) 信号事件:发送或接收信号的事件 调用事件: 对操作的调度 时间事件: 变化事件: 调用事件: 对操作的调度 时间事件: after+计算一段时间的表达式 after (2 seconds) when+时间表达式 when (date=January 1,2000) 变化事件: when+表达式: when (altitude<1000),when (room temperature<heating set point)) -221- 221
监护条件(Guard Condition) 监护条件是触发转换必须满足的条件,它是一个布尔表达式。 布尔表达式由“[ ]”括起,放在触发事件后面。 当触发事件发生后,求监护条件的值,如果值为真,转换可以触发;如果值为假,转换就不能被触发,如果也没有其他的转换被这个触发事件触发,则事件被忽略。 从一个状态引出的多个转换可以有同样的触发器事件,但是每个转换必须具有不同的监护条件。
动作(Action) 动作是一组可执行语句或者计算处理过程。 动作可以包括发送消息给另一个对象、操作调 用、设置返回值、创建和销毁对象等。 动作是原子的,不可中断的,动作或动作序列 的执行不会被同时发生的其他动作影响或终止。 整个系统可以在同一时间执行多个动作。
入口动作与出口动作(Entry/Exit Actions) do:用来指定处于状态时发生的活动; event:用来指定当特定事件触发时发生的动作。
简单手表“设置时间” 的状态图
转换 转换种类: 外部转换 内部转换 自转换
外部转换 外部转换是一种改变对象状态的转换,是最常见的一种转换。 外部转换对事件做出响应,引起状态变化或自身转换,同时引发一个特定动作。 外部转换用从源状态到目标状态的箭头表示。
内部转换 (Internal Transitions) 内部转换对事件做出响应,并执行一个特定的活动,但并不引起状态变化,因此不需要执行入口和出口动作。 内部转换和自转换不同,虽然两者都不改变状态本身,但是自转换会激发入口动作和出口动作的执行,而内部转换却不会。 内部转换:用来处理一些不离开该状态的事件.
简单状态 (Simple State) 简单状态是指不包含其他状态的状态。 简单状态没有子结构,但它可以具有内部转换、入口动作和出口动作等。
组合状态(Composite State) 组合状态是可以包含一些嵌套的子状态的状态。 组合状态可以分解为并发子状态,或者分解为互相排斥的顺序子状态。 组合状态的一个入转换代表对其嵌套子状态区域内的初始状态的入转换;对嵌套子状态区域内的终结状态的转换代表包含它的组合状态的相应活动的完成。
Compound State
嵌套的子状态的分类 1. 顺序子状态(Sequence /Disjoint Substates) 2. 并发子状态(Concurrent Substates)
1. 顺序子状态(Sequence Substate) 如果一个组合状态的子状态对应的对象在其生命期内的任何时刻都只能处于一个子状态,即多个子状态之间是互斥的,不能同时存在,这种子状态称为顺序子状态。 当状态机通过转换从某种状态转入组合状态时,此转换的目的可能是这个组合状态本身,也可能是这个组合状态的子状态。
2. 并发子状态(Concurrent Substate) 有时组合状态有两个或者多个并发的子状态机,此时称组合状态的子状态为并发子状态。 顺序子状态与并发子状态的区别在于后者在同一层次给出两个或多个并发子状态,对象处于同一层次中来自每个并发子状态的一个时序状态中。
并发子状态例子
状态图 History States A History State is used to remember the previous state of a state machine when it was interrupted. 历史状态代表上次离开组成状态时的最后一个活动子状态,它用一个包含字母“H”的小圆圈表示。 每当转换到组成状态的历史状态时,对象便恢复到上次离开该组成状态时的最后一个活动子状态,并执行入口动作。
Example: State Machine Hired Assistant Professor Tenured Applied rejected accepted Hiatus H takeSabbatical retired maxPapers seniority return
Washing Rinsing Spinning H Power Off Power Cut Restore Power
状态图建模技术 建模步骤: 找出适合用模型描述其行为的类。 确定对象可能存在的状态。 确定引起状态转换的事件。 确定转换进行时对象执行的相应动作。 对建模的结果进行相应的精化和细化。 -239-
2.11.2 活动图概念 Activity Diagram 与状态图的区别 用于描述活动流程的图形称为活动图 和结构化方法中的工具——程序流程图——作用基本一致。 是一种特殊的状态图。 与状态图的区别 活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程; 状态图着重描述从一个状态到另一个状态的流程,主要有外部事件的参与。
2.11.3 活动图的作用 业务流程建模 工作流建模 算法流程建模
业务流程建模 可以用活动图对业务流程建模。 处理订单的活动图
工作流建模 工作流是计算机化的业务过程。信息系统开发的业务过程重组需要建立详细的工作流模型,用活动图可以有效地建立工作流模型。 工作流的例子
算法流程建模 可以用活动图描述一个算法的流程,一个类中操作的处理流程。 算法流程
2.11.4 活动图组成 状态 动作状态 活动状态 转换 分支 分叉 汇合 同步 泳道
状态 State 动作状态 状态是指在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状况。 活动图中的状态包括动作状态和活动状态。 动作状态 对象的动作状态是活动图中最小单位的构造块,表示原子动作。 动作状态有三个特性: 原子性 不可中断性 瞬时性
活动状态 活动图中也有初态和终态 表示的是可以分割的动作 特点是:它可以被分解成若干活动状态或动作状态,它能够被中断,占有有限的时间。 活动状态可以理解为一个组合,它的控制流由其他活动状态或动作状态组成。 活动图中也有初态和终态 初态表示一个工作流程的开始,用实心圆点来表示 终态表示了一个活动图的最后和终结状态,用实心圆点外加一个小圆圈来表示
转换(transition) 转换是两个状态间的一种关系,表示对象将在当前状态中执行动作,并在某个特定事件发生或某个特定的条件满足时进入后继状态。
分支(Branch) 分支用于描述基于某个条件的可选择路径。 一个分支可以有一个进入转换和两个或多个输出转换。 在每条输出转换上都有监护条件表达式保护,当且仅当监护条件表达式为真时,该输出路径才有效。 在所有输出转换中,其监护条件不能重叠,而且它们应该覆盖所有的可能性。 分支在图形表示上 用菱形表示
分支示例:打印过程
分叉(fork)和汇合(join) 分叉表示把一个单独的控制流分成两个或多个并发的控制流。一个分叉可以有一个进入转移和两个或多个输出转移,每一个转移表示一个独立的控制流。 汇合表示两个或多个并发控制流的同步发生,一个汇合可以有两个或多个进入转移和一个输出转移。
在UML中使用分叉和汇合表示并行发生的事件流 分叉和汇合在图形上都使用同步条来表示,同步条通常用一条粗的水平线表示
分叉和汇合示例: 描述打电话活动中的并发事件
泳道(swimlane) “泳道”技术,是将一个活动图中的活动状态进行分组,每一组表示一个特定的类、人或部门,他们负责完成组内的活动。 “泳道”技术来描述每个活动是由哪个对象负责完成。 UML中,每个组被称为一个泳道,用一条垂直的实线与邻居分开。 每个活动都明确属于一个泳道,不可以跨越泳道,而转移则可以跨越泳道。
客户、销售员、仓库管理员 泳道示例: 用活动图描述客户在商店中购买物品的过程
对象流(object stream) 对象流是动作状态或活动状态与对象间的依赖关系。 对象流可用于对下列关系建模: 动作状态对对象的使用 动作状态对对象的影响 在UML中,使用矩形表示对象 , 对象和动作之间使用带箭头的虚线连接,带箭头的虚线表示对象流。 工具栏-customize…
用活动图描述客户在商店中购买物品的过程。(使用对象流技术描述购物这个动态过程中系统内对象的状态变化 )
2.11.5 活动图示例 新增读者 找饮料
示例:新增读者 "新增读者"用例属于读者信息管理中的一个功能,主要用于在系统中增加新的读者信息,其具体的办理流程是: 1)"读者"填写申请表,并交给"图书管理员"; 2)"图书管理员"将申请表中的信息通过录入界面,输入到图书管理系统; 3)系统中的"业务逻辑"组件将判断输入的信息是否合法; 4)如果不合法则转入步骤(5),否则转入步骤(6); 5)显示"添加错误信息",转到(8); 6)在“数据库”添加相信的用户信息; 7)显示"添加成功信息"; 8)结束。
练习:删除读者 绘制“删除读者信息”用例的活动图。删除读者信息按照以下步骤进行: 1)管理员在录入界面,输入待删除的读者名; 2)“业务逻辑”组件在数据库中,查找待删除的读者名; 3)如果不存在,则显示出错信息,返回步骤(1),如果存在则继续; 4)“业务逻辑”组件判断“待删除的读者”是否可以删除; 5)如果不可以,则显示出错信息,返回步骤(8),如果可以则继续; 6)在数据库中,删除相关信息; 7)显示删除成功信息; 8)结束。
示例:找饮料
2.11.6 动态图比较 交互图(顺序图、协作图):适合描述单个用例中多个对象之间的协作行为 状态图:适合描述跨越多个用例的单个对象的行为,不适合描述多个对象之间的协作行为 活动图:适合描述多个对象跨越多个用例时的总面貌 不应对系统中的每个类都画状态图,而只应对某些关键类建立状态图;而且应将状态图与其它技术组合使用
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.12 组件图和部署图 2.12.1 组件图概念 2.12.2 组件图作用 2.12.3 组件图组成 2.12.4 组件图建模 2.12.5 部署图概念及组成 2.12.6 部署图建模 2.12.7 小结
2.12.1 组件图 (Component Diagram)概念 组件图是对面向对象系统的物理方面建模时使用的两种图之一(另一种图是部署图),用于描述软件组件以及组件之间的组织和依赖关系。
2.12.2 组件图作用 组件图有利于: 帮助客户理解最终的系统结构。 使开发工作有一个明确的目标。 复用软件组件。 帮助开发组的其他人员理解系统。 例如,编写文档和相关帮助的人员不直接参与系统的分析和设计,然而他们对系统的理解直接影响到系统文档的质量,而组件图是帮助他们理解系统的有力工具。
2.12.3 组件图组成 构成组件图的元素包括: 组件(component) 接口(interface) 关系(relationship) 还可以包括包(package)和子系统(subsystem),它们有助于将系统中的模型元素组织成更大的组块。
组件(Component) 组件是定义了良好接口且提供实现的一个物理部件 是指类的物理实现,表示将类、接口等逻辑元素打包而形成的物理模块。 它具有很广泛的定义,以下的一些内容都可以被认为是组件:程序源代码、子系统、动态链接库等。 组件的图形表示法是把组件画成嵌套了两个小矩形标签的大矩形。
组件与类的异同 组件在许多方面都与类相同: 二者都有名称; 都可以实现一组接口; 都可以参与依赖、泛化和关联关系; 都可以被嵌套; 都可以有实例; 都可以参与交互。
组件与类的异同 组件和类之间也有一些显著的差别: 类表示逻辑抽象,而组件表示存在于计算机中的物理抽象。 组件表示的是物理模块而不是逻辑模块,与类处于不同的抽象级别。 类可以直接拥有属性和操作;而一般情况下,组件仅拥有只能通过其接口访问的操作。
组件类型 组件可以分为以下三种类型: 部署组件(Deployment Component) 如dll文件、exe文件等 工作产品组件(Work Product Component) 源代码文件、数据文件等,用来产生部署组件 执行组件(Execution Component) 系统执行后产生的组件。如ejb、com+对象、corba对象等
<<component>> 接口(Interface) 接口是一组用于描述类或组件的某个服务的操作 它是一个被命名的操作的集合,与类不同,它不描述任何结构(因此不包含任何属性),也不描述任何实现(因此不包括任何实现操作的方法)。 Provided Interface Name Required Interface <<component>> Component Name ComponentName
关系(relationship) 关系是事物之间的联系,在面向对象的建模中,最重要的关系是依赖、泛化、关联和实现,但组件图中使用最多的是依赖和实现关系。 组件图中的依赖关系使用虚线箭头表示 ,如图所示。
实现关系 实现关系使用实线表示。实现关系多用于组件和接口之间。组件可以实现接口。
依赖关系 两个组件中的类如果存在泛化关系,则组件间可以加依赖
依赖关系 两个组件中的类如果存在使用关系,则组件间可以加依赖
2.12.4 组件图建模 使用组件图建模的步骤可按照下列步骤进行: (1)对系统中的组件建模; (2)定义相关组件提供的接口; (3)对它们间的关系建模; (4)对建模的结果进行精化和细化。
实例 在图书馆管理系统中,通过分析可以发现类图中的类应分为4个部分: 1.用户接口模块(UI),主要负责系统和用户的交互,包括Frame类,Dialog类等。 2.业务对象模块(BO),主要负责处理系统中的业务计算,如借书,还书等功能的具体操作。 3.数据存储模块(DB),主要负责处理对数据的存储。 4.通用工具模块(UTIL),包括系统中通用函数。
业务对象BO组件图
2.12.5 部署图概念及组成 (Deployment Diagram) 部署图用于描述系统硬件的物理拓扑结构以及在此结构上运行的软件。 部署图可以显示计算节点的拓扑结构、通信路径、节点上运行的软件、软件包含的逻辑单元(对象、类等)。 构成部署图的元素主要是 节点(node) 组件(component) 关系(relationship)
节点(node) 节点是在运行时并代表计算资源的物理元素,一般至少拥有一些内存,而且通常具有处理能力。 两种类型的节点: 处理器(Processor):能够执行软件组件、具有计算能力的节点。 设备(Device):没有计算能力的节点,通常是通过其接口为外界提供某种服务,例如打印机、扫描仪等都是设备。
Processor
Device
节点和组件的区别 组件是参与系统执行的事物,而节点是执行组件的事物。 组件表示逻辑元素的物理模块,而节点表示组件的物理部署。
关系(relationship) 部署图中也可以包括依赖、泛化、关联及实现关系。部署图中的依赖关系使用虚线箭头表示。它通常用在部署图中的组件和组件之间。
各元素图标 处理器(Processor),表示具有运算能力的节点。 设备(Device),表示没有运算能力的节点 。 通讯路径(Connection),表示节点之间的通讯关系。
2.12.6 部署图建模 使用部署图对系统建模,绘制系统部署图,可以参照以下步骤进行: 对系统中的节点建模; 对节点间的关系建模; 对节点中的组件建模,这些组件来自组件图; 对组件间的关系建模; 对建模的结果进行精化和细化。
实例 图书管理系统目前开发的是一个单机版系统,其中所有的运算均在一台机器上完成,但是由于打印报表的需要,系统还应配备一台打印机。因此得出系统中存在2个节点: 一台主机,其类型是Processor。 一台打印机,其类型是Device。
任务解决
2.12.7 小结 组件图是对面向对象系统的物理方面建模时使用的两种图之一,用于描述软件组件以及组件之间的组织和依赖关系,构成组件图的元素包括组件(component)、接口(interface)和关系(relationship)。 部署图是用于描述系统硬件的物理拓扑结构以及在此结构上运行的软件的图形,部署图可以显示计算节点的拓扑结构、通信路径、节点上运行的软件、软件包含的逻辑单元(对象、类等)。构成部署图的元素主要是节点(node)、组件(component)和关系(relationship)。
本章目录 2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架 2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和协作图 2.11 状态图和活动图 2.12 组件图和部署图 2.13 IBM Rational ROSE解决方案
2.13 IBM Rational ROSE 解决方案 解决方案概述 Rose简介 Rose界面 Rose的使用
解决方案概述 Rational公司提供了一套广泛的软件工程解决方案,它包括: 一个集成的软件产品家族,以实现需求管理、应用设计和建模、编码、软件质量保证和测试、组件管理、过程和项目管理以及软件文档自动生成的自动化。 一整套可配置的用于软件开发的过程和技术:通过Use- Case驱动以获取业务或系统需求,基于控制的迭代开发以及一套针对软件重用的结构化的方法。
版本控制、构件管理、工作空间管理、过程控制 Rational产品一览 配置管理、需求跟踪管理、过程和项目管理 RequisitePro 文档生成 SoDA 可视化建模 ROSE 测试自动化 SQA Suite & Visual Test 代码高级调试 Pure Series 开发工具 组件 版本控制、构件管理、工作空间管理、过程控制 ClearCase
Rational Rose简介 ROSE是美国Rational公司的面向对象建模工具,利用这个工具,我们可以建立用UML描述的软件系统的模型,而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。 Rose通过先建立系统模型,再编写代码,从而提高了软件开发的可靠性。
Rose界面(1) ROSE的界面分为三个部分——Browser窗口、Diagram窗口和Document窗口。
工具栏 Diagram窗口 Browser窗口 Specification对话框 工具箱
Rose界面(2) Browser窗口有四个视图: Use Case Logical Component Deployment
Rose界面(3) 在Use Case视图的图的类型有:用例图、顺序图、协作图、状态图和活动图。
Rose界面(4) 在Logical视图中的类型有:类图、顺序图、协作图、状态图和活动图。
Rose界面(5) 在Component视图的图的类型有:组件图。
Rose界面(6) 在Deployment视图的图的类型有:配置图。
Rose的使用--用例图(1) 新建用例图 打开用例图 删除用例图 File->New->Use Case Diagram Browse->Use Case Diagram或在Browser窗口中双击用例图的名称 删除用例图 在Browser窗口中右键单击某用例图,在弹出菜单中选择“Delete”
Rose的使用--用例图(2) 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加包 添加用例 添加角色 建立角色与用例之间的关联 框图项目之间的相关性 1.用例之间的扩展关系 2.角色之间的继承关系
Rose的使用--顺序图(1) 添加顺序图 删除顺序图 将顺序图中的对象映射到类 右键单击Browse窗口中的“Use Case Model”,选择“New->Sequence Diagram” 或单击工具栏上的“Browse Interaction Diagram”按钮,选择“New” 删除顺序图 右键单击Browse窗口中的顺序图名称,选择“Delete” 将顺序图中的对象映射到类 右键单击某对象,在弹出菜单中选择“Open Specification” 在“Class”下拉框中选择“New”以创建一个新类或选择某个已定义好的类 将对象映射到类后,类名出现在对象名的后面,以冒号隔开
Rose的使用--顺序图(2) 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加对象 添加消息 添加到自身的消息 添加返回消息 对象生命周期的结束
Rose的使用--协作图(1) 合作图的添加、删除、改名的操作和顺序图类似 从顺序图自动生成合作图 从合作图自动生成顺序图 打开一个顺序图 选择菜单“Browse->Create Collaboration Diagram” 生成与顺序图同名的合作图 从合作图自动生成顺序图 打开一个合作图 选择菜单“Browse->Create Sequence Diagram” 生成与合作图同名的顺序图
Rose的使用--协作图(2) 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加对象 生成对象之间的通信路径 显示对象可以自我调用 添加消息 从相反方向添加消息
Rose的使用--类图和包图 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加类 添加接口 关联关系 添加包 类之间的依赖关系 继承关系 类和接口之间的实现关系
Rose的使用--状态图 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加状态 添加开始状态 添加结束状态 添加转换 添加到自身的转换
Rose的使用--活动图 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加活动 添加开始状态 添加结束状态 添加转换 添加到自身的转换 横向同步条 纵向同步条 决策分支 泳道
Rose的使用--组件图 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加组件 添加包 建立组件间的依赖关系
Rose的使用--配置图 取消选定 插入文本 添加注释 建立注释到被注释者之间的连接 添加处理器 建立资源节点之间的连接 添加设备