统一建模语言UML

合集下载

第2章 统一建模语言UML

第2章 统一建模语言UML

UML 2.0
1997年对象管理组织(Object Management Group
,OMG)采纳UML作为其标准建模语言,并通过严 格有序的OMG过程对其进行修订和维护。 1999,UML 1.3,相对稳定成熟阶段 2001-05, UML 1.4 2003年6月宣告完成了UML 2.0 : Infrastructure(底层结构) Superstructure(上层结构) OCL(对象约束语言) Diagram Interchange(图形交换)
关联类
关联类用来记录与关联(关系)有关的信息,提
供与关联有关的操作。
+Employee +Employer
Person
* 1
Company
Employment +Contract
(2)包图
包图在UML中可以看作是类图的一部分。
包用来对一组元素进行划分,是对复杂模型的一
种分而治之的层次划分。 常用来描述一个复杂系统逻辑上的子系统划分。 包图主要由包和包之间的关系组成。 包的划分应遵循高内聚、低耦合的原则,一个包 中可以包含多个类和子包。 包图的图元: 包、依赖关系、导入关系、合并关系
UML 2.0的建模机制
类图 (Class Diagram) 包图 (Package Diagram) 对象图 (Object Diagram) 结构建模 (Structure) 构件图 (Component Diagram)
组合结构图 (Composite Structure Diagram)
UML 2.0 建模机制
* 1
OrderItem
Order
泛化(继承)关系
Person

1.简述统一建模语言

1.简述统一建模语言

简述统一建模语言
统一建模语言(UML):是一种用于对软件密集系统进行可视化建模的标准语言。

它始于1997年,被采纳为OMG标准,是一种非专利的第三代建模和规约语言。

UML独立于任何具体程序设计语言,是面向对象设计的建模工具。

UML为面向对象开发系统的产品进行说明、可视化和编制文档,展现了一系列最佳工程实践,这些实践在对大规模、复杂系统进行建模方面已经被验证有效。

UML可以贯穿软件开发周期中的每一个阶段,从需求分析到规格,到构造和配置。

UML表示法集中了不同的图形表示方法,剔除了其中容易引起的混淆、冗余或者很少使用的符号,同时添加了一些新的符号。

其中的概念来自于面向对象技术领域中众多专家的思想。

总的来说,UML作为一种模型语言,使开发人员专注于建立产品的模型和结构,而不是选用什么程序语言和算法实现。

当模型建立之后,模型可以被UML 工具转化成指定的程序语言代码。

统一建模语言

统一建模语言

统一建模语言统一建模语言(UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

它融入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

1.UML的结构UML的结构包括基本构造块、支配这些构造块如何放在一起的规则(体系架构)和一些运用于整个UML的机制。

(1)构造块。

UML有三种基本的构造块,分别是事物(thing)、关系(relationship)和图(diagram)。

事物是UML中重要的组成部分,关系把事物紧密联系在一起,图是很多有相互相关的事物的组。

(2)公共机制。

公共机制是指达到特定目标的公共UML方法,主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制四种。

●规格说明:规格说明是事物语义的文本描述,它是模型真正的核心。

●修饰:UML为每一个事物设置了一个简单的记号,还可以通过修饰来表达更多的信息。

●公共分类:包括类元与对象(类表示概念,而对象表示具体的实体)、接口和实现(接口用来定义契约,而实现就是具体的内容)两组公共分类。

●扩展机制:包括约束(添加新规则来扩展事物的语义)、构造型(用于定义新的事物)、标记值(添加新的特殊信息来扩展事物的规格说明)。

(3)规则。

UML用于描述事物的语义规则分别是为事物、关系和图命名。

给一个名字以特定含义的语境,即范围;怎样使用或看见名字,即可见性;事物如何正确、一致地相互联系,即完整性;运行或模拟动态模型的含义是什么,即执行。

UML对系统架构的定义是系统的组织结构,包括系统分解的组成部分、它们的关联性、交互、机制和指导原则等这些提供系统设计的信息。

而具体来说,就是指5个系统视图,分别是逻辑视图、进程视图、实现视图、部署视图和用例视图。

●逻辑视图:以问题域的语汇组成的类和对象集合。

●进程视图:可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描绘了所设计的并发与同步结构。

第十一章 统一建模语言UML

第十一章 统一建模语言UML
软件工程(Software Engineer)
计算机科学与工程学院
11.3 用例建模
用例建模描述一个系统应该做什么,描述的 是外部参与者所理解的系统功能。构建用例模型 是通过开发者与客户或最终使用者对需求规格说 明达成的共识,明确系统的基本功能,为后阶段 的工作打下基础。 用例模型的基本组成部件是用例、参与者和 系统。用例用于描述系统的功能,也就是从外部 用户的角度,观察系统应支持哪些功能,帮助分 析人员理解系统的行为,它是对系统功能的宏观 描述。
计算机科学与工程学院 软件工程(Software Engineer)
4)依赖(Dependency) 依赖是两个模型元素间的语义连接,一 个是独立的模型元素,一个是依赖的模型 元素。 5)细化(refinement) 细化是UML中的术语,表示对事物更详 细一层的描述。两个元素A、B描述同一件 事物,它们的区别是抽象层次不同,若元素B 是在元素A的基础上的更详细的描述,则称元 素B细化了元素A,或称元素A细化成元素B。
UML 主要作者提出的目标是: 提供给用户一个易于使用和表达的可视化的建模语言,使他们能 够开发和交流有意义的模型。独立于任何开发语言。独立于任何开发 过程。简单并且可扩展,具有扩展和专有化机制,便于扩展,无需对 核心概念进行修改。提供了解建模语言的一个基本手段。支持面向对 象的设计与开发中涌现出的高级概念,例如协作、框架、模式和构件, 强调在软件开发中对架构、框架、模式和构件的重用。最佳的软件工 程实践经验的集成。有利于面向对象工具的市场成长。
张三 : 作家 姓名 : String = 张三 年龄 : Integer = 28
(b)对象图
计算机科学与工程学院
软件工程(Software Engineer)

UML(UnifiedModelingLanguage统一建模语言)

UML(UnifiedModelingLanguage统一建模语言)

UML(UnifiedModelingLanguage统⼀建模语⾔)UML(Unified Modeling Language 统⼀建模语⾔),⼜称标准建模语⾔。

是⽤来对软件密集系统进⾏可视化建模的⼀种语⾔。

UML是⼀种⾯向对象的建模语⾔,它可以实现⼤型复杂系统各种成分描述的可视化、说明并构造系统模型,以及建⽴各种所需的⽂档,是⼀种定义良好、易于表达、功能强⼤且普遍适⽤的建模语⾔。

UML基本内容详述(1)视图 视图是表达系统的某⼀⽅⾯特征的UML建模元素的⼦集;试图并不是图,它是由⼀个或多个图组成的对系统某个⾓度的抽象。

1)⽤例视图(核⼼视图) 强调从⽤户的⾓度看到的或需要的系统功能。

2)逻辑视图 该视图⽤于描述系统内实现的逻辑功能,展现系统的静态或结构组成及特征。

3)组件视图 该视图从系统实现的⾓度来描述模型对象间的关系。

4)配置视图 该视图⽤于说明系统的物理配置。

(2)图表 图表是描述视图内容的图。

1)⽤例图 ⽤于描述外部项与系统提供的使⽤事件之间的联系。

⼀个使⽤事件是系统提供的功能的具体描述,是系统分析⼈员从⽤户⾓度描述系统的功能,是功能与功能之间以及功能与⽤户之间的关系。

使⽤事件定义了系统的功能需求。

简单理解:⽤来描述系统的功能。

2)类图 ⽤于描述系统的静态结构。

类可以⽤不同⽅式连接,主要包括联合、依赖、独⽴和包装。

⼀个系统⼀般有多张类图,⼀个类可在不同的视图中出现。

3)对象图 ⽤于表述系统在某个时刻的静态结构。

对象图也可作为协作图的⼀部分,说明⼀组对象之间的动态协作关系。

对象图与类图的区别:对象图表⽰的是类中的许多对象实例,⽽不是类本⾝。

4)状态图 ⽤于说明类中的对象可能具有的状态,以及由时间引起的状态的改变。

简单理解:描述了系统元素的状态条件和响应。

5)顺序图(时序图) ⽤于描述对象间的动态协作关系。

表达了对象间发⾏消息的时序,同时也表达出对象间的相互作⽤,以及当系统执⾏到某个特定位置时可能会发⽣的事。

2统一建模语言UML

2统一建模语言UML

出现的方式

多态性
(section 2.3.2)
capturing use of single action word to represent different things,
depending on context根据上下文,捕获单一行为词表示的不同内 容
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

2.1面向对象开发方法
面向对象的目标: 为实现现实世界和设计中的结构单元间提供直接映射。 基本概念: 类,对象,聚集,消息,客户 面向对象方法的优势: 面向对象的特点:继承,多态,接口,封装 简化开发过程 支持软件复用 改善软件结构
面和向对象以前
Real world concepts
第二章 统一建模语言UML
主要内容
面向对象的设计开发方法 面向对象的目标 面向对象的概念 面向对象的特点 面向对象方法的优势
UML概述
UML的产生发展 UML的基本组成
UML建机制
UML静态建模 类图,对象图,包图,构件图,组合结构图,部署图 UML动态建模 活动图,顺序图,通信图,交互图,时序图,状态图,用例
继承
相对于结构化编程中 的模块重用,面向对 象中的继承体系显得 更灵活,对代码的控 制手段更多,从而推 动了代码复用的程度, 但却加大了学习掌握 的难度。
电子邮件创建示例的需求 Page 1 of 4
1. 概要: Produces e-mail text for various types of customers.给不同类型的用户撰写 电子邮件

第二章uml建模语言介绍

第二章uml建模语言介绍

第二章uml 建模语言介绍1.uml (unified modeling language,统一建模语言)Uml 是一种通用的、标准的、可视化的建模语言,能让系统构造者用标准的、易于理解的方式建立起项目中所有的静态结构和动态行为,便于不同的人之间有效地共享和交流工作结果。

2.uml 的特点● 统一了面向对象方法的基本概念● 强大的建模能力● 提出了很多新的概念● 独立于开发过程● 易于掌握使用3.uml 建模语言 的描述方式以标准的图形表示为主。

Uml 模型图由元素、关系和图构成。

4.uml 中常用的十种图:1) 用例图2) 静态图:类图、对象图、包图3) 行为图:状态图、活动图4) 交互图:序列图、合作图5) 实现图:构件图、部署图5.模型元素:基元素和构造型元素1) 基元素:类、对象、节点、包、构件、注释、关联、依赖和泛化等2) 构造型元素6.用例图1) 用例:是系统中的一个功能单元,是从用户的角度对系统行为的一个描述,是从用户角度来描述系统需求。

2) 用例图:是由参与者、用例以及它们之间的关系构成的用于描述系统功能的模型图。

3) 用例图表示方法:用例图表示方法很直观,由用例、参与者和关联线共同组成用例图 用例由一个椭圆形表示,用例的名字可以放在椭圆形里面,也可以放在椭圆形下面。

参与者由直立人形图标,参与者的名字放在参与者图标的下方。

参与者和用例之间用实线连接,表示两者之间有通信关系。

系统的边界用一个矩形表示,系统的名字写在矩形里面。

用例属于系统内部,装入矩形内。

参与者是系统外部实体,放在矩形外面。

7.类图1) 类图:由系统中使用的类以及它们之间的关系组成,描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)2) 类图的表示方法:类在类图上使用包含三个区域的矩形来描述,最上面的区域是类名,中间区域是类的属性,最下面的区域是类的操作。

系统分析与设计——统一建模语言UML

系统分析与设计——统一建模语言UML

北京理工珠海学院
6.1.2统一建模语言特点
(1)面向对象:支持面向对象技术的主要概念,提供 了一批基本的模型元素表示图形和方法,简明表 达面向对象的各种概念. (2)可视化:通过UML的模型图清晰表示系统的逻辑 模型和实现模型,还用于各种复杂系统的建模. (3)独立于过程:独立于开发过程. (4)独立于程序设计语言:建好的系统模型可用任何 面向对象的语言来实现. (5)易于掌握和使用:结构清晰,建模简明易于掌握
五类图
第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者 .
第二类是静态图 ,包括类图、对象图和包图 .
第三类是行为图,描述系统的动态模型和组成对象间的交互关系。行为图 包括:状态图、活动图、顺序图和协作图 第四类是交互图,描述对象间的交互关系。(顺序图显示对象之间的动态 合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互 ;合作图描述对象间的协作关系,显示对象间的动态合作关系和对象以 及它们之间的关系)。如果强调(时间和顺序,则使用顺序图);如果强 调(上下级关系,则选择合作图)。这两种图合称为交互图. 第五类是实现图 ,其中构件图描述代码部件的物理结构及各部件之间的 依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个 可执行部件。它包含逻辑类或实现类的有关信息。构件图有助于分析和 理解部件之间的相互影响程度。
《include》 打印查询结果
(From Use Case View)
(From Use Case View)
北京理工珠海学院
案例:泛化、扩展关系
下面左图给出了一个扩展关系的例子,在还书的过程中, 只有在例外条件(读者遗失书籍)的情况下,才会执行赔 偿遗失书籍的分支流。 泛化关系:用例可以被特别列举为一个或多个子用例,这 被称做用例泛化。当父用例能够被使用时,任何子用例也 可以被使用。如在右图中,订票是电话订票和网上订票的 抽象。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

前述的各种XXX管理功能到哪里去了? 每个业务目标都会有一个边界 每个边界有不同的参与者 在不同的边界内将推导出不同的业务用例。

释疑:

内部管理目标边界
进一步讨论之一

上述划分边界的结果与以前所谓划分子系统有 什么差别?

仅从名称上看,二者非常相似。 仔细考虑可以发现诸多不同:

1.

按这种方式划分存在若干问题: 无法获得明确的业务用例。
无法知道这些涉众对边界的真实目的是什么, 只能盲目的将涉众所有的期望堆积在边界里。 面对诸多的用例,如何进行组织?如何分包?

2.

按这种方式划分存在若干问题: 导致业务用例过多,关联关系混乱。
无法区分业务主角和业务工人。 会出现非常多的用例在边界里,如果都与边界 外的涉众关联上,业务用例视图将混乱一片。
进一步讨论之三

是否任何时候以业务目标为依据来划分边界都 是有效的呢?


当待开发的是计算密集型或者控制密集型系统 时,似乎难以找到明确的业务目标,即使找到, 数量也很少,此时使用业务目标为依据划分边 界似乎很别扭。 例如:玩家->玩游戏


其实,对于非交互密集型系统,即使没有明确 的业务目标,也有明确的功能目标,即系统特 性,可以以这些系统特性为边界,得到不同的 主角与用例: 例如:控制系统、游戏引擎、声效等 控制系统为边界,

情形二:业务范围包括网上办理业务,用电客 户可以直接使用系统进行办理业务。

用电客户本身就是业务主角。

情形三:一些大用电客户,供电企业设置了专 职检查和服务联络人员为其专门服务,这些专 职人员可以直接为大客户办理业务。

专职检查人员成为代表涉众利益的主角。
发现主角—用电客户服务边界
2.

银行涉众主角分析
统一建模语言UML
电力营销系统案例——获取需求
定义边界

对于全新的项目,分析员首先要做的工作就是 定义边界。

边界可大可小,很多时候依靠建模者的经验和 意识。

定义边界的目的是为我们确定一个分析的起点。
定义边界
如何定义边界?

通过前景文档中的业务目标来定义边界? 还是通过业务模块划分的方式来定义边界?
发现主角—用电客户服务边界
1.

在此边界外有两个涉众:用电客户、银行。 用电客户涉众主角分析
情形一:用电客户不直接使用系统,而是通过 到营业大厅填写纸面申请,由营业大厅业务员 代为填写电子申请单并提交。

用电客户不直接与边界所代表的系统交互,营 业大厅业务员成为代表涉众利益的业务主角。
发现主角—用电客户服务边界
划分依据:

子系统划分没有明确的依据,没有明确的判断标准 来决定何种划分方式是合理的。 业务目标划分方式有着明确的依据。针对每个业务 目标,可以明确决定系统内外,明确决定哪些涉众 与此业务目标利益相关,进而得到若干业务用例。
进一步讨论之二

大部分边界 划分的方式 是从谁使用 系统这个角 度来划分的。 这和从业务 目标角度划 分有何区别?



该部门负责管理供电设备,资产管理员负责管 理设备的整个生命周期。 资产出库入库前需要校修人员负责校修。 资产运行中,需要由资产班长制定轮换计划, 资产运行一段时间后按计划轮换资产。 此处业务主角:资产班长。
发现主角-内部管理业务边界

业务服务部门涉众主角分析


该部门由业务员、业务收费员、业务班长组成。 业务员受理客户用电申请;业务收费员负责收 取业务费用;业务班长负责安排工作,评估业 务员服务水平,审批业务。 此处业务主角:业务班长
发现主角-内部管理业务边界

用电检查部门涉众主角分析



该部门定期按计划对用电安全进行检查。 其中用电普查、专项检查由检查班长制定计划, 分派检查员进行现场检查,检查结果由检查内 勤录入计算机。 专职检查员维护自己所负责的用电单位的资料, 自行安排检查计划,但必须通过检查班长审批。 此处业务主角:检查班长
前述分析中,已经取消了实时联网收费的期望, 仅保留离线收费,每日结算收费方式。即银行 的收费行为与系统之间不会有直接的交互。每 日会有某位营业出纳从银行处获得每日收费记 录,并将其导入系统。

此时,营业出纳将代表银行成为系统的一个业 务主角。
发现主角-内部管理业务边界

依据前面的涉众分析报告,内部管理业务边界 之外的涉众有:
发现主角-内部管理业务边界

电费管理部门涉众主角分析


该部门负责计算电费,由发行员来完成。 对于一些特殊客户和特殊情况的电费计算规则 的改变,必须通过电费班长确认签字。 行使了内部管理职能,成为内容管理业务边界 业务主角的是:电费班长。
发现主角-内部管理业务边界

资产管理部门涉众主角分析

通过业务目标定义边界

Hale Waihona Puke 电力营销系统业务目标一:“为用电客户提供 业务办理自动化服务,提高办事效率,方便客 户,为客户提高更好的服务” 分析:

此业务目标为谁服务?

用电客户->得到一个用电客户服务边界
用电客户服务边界
启示


各业务管理部门位于边界以内,是业务工人, 他们的期望可以暂且不考虑。 疑问:

键盘、鼠标、手柄->发出前进动作、发出射击 动作……
发现主角

得到涉众分析报告,已经定义了边界,我们可 以据此寻找业务主角。

主角:代表了涉众利益,站在边界外,直接与 边界代表的系统交互,对系统有明确的要求, 并从系统中获得明确的结果。
发现主角

是否所有的涉众都会成为业务主角?

只有那些直接与系统交互的涉众才能成为业务 主角。
发现主角-内部管理业务边界

电表抄表部门涉众主角分析



该部门大部分工作人员-抄表工,携带抄表机 或抄表单外出工作,他们不直接使用系统,而 是将抄回的结果交给内勤人员,有内勤代他们 将抄表结果导入或者录入计算机。 抄表工作由抄表班长按片区、按变压器线路等 将工作分配给抄表工。 其中抄表班长行使了内部管理职能,是内部管 理业务边界的业务主角。

营业财务管理部门、电表抄表部门、电费管理 部门、资产管理部门、现场施工部门、业务服 务部门、用电检查部门。
发现主角-内部管理业务边界

营业财务管理部门涉众主角分析



该部门设置了营业会计、营业出纳、营业收费 员。这三个角色会按照财会准则各自负责自己 的部份,保障财产安全。 财务管理部门设有财务主任,负责财务工作的 安排、人员工作情况的评估、业务规则的制定。 代表业务目标是规范化和管理职能,行使了内 部管理职能的业务主角是:财务主任。
相关文档
最新文档