上海财经大学信息管理与工程学院

  文件类型：PPT/Microsoft Powerpoint   文件大小：18099字节

内容摘要：

上海财经大学信息管理与工程学院
第12讲 UML
Chapter 1 Players in the Systems Game
Copyright 2002 Prentice-Hall, Inc.
系统分析与设计
Unified Modeling Language (UML)
UML概要
软件界第一个统一建模语言
UML由OMG与1997年11月批准为标准建模语言.
UML建立在当今国际上最有代表性的三种面向对象方法(Booch方法,OMT方法,OOSE方法)的基础之上.
UML是一种建模语言而不是一种方法,UML本身是独立于过程的.
Unified Modeling Language (UML)
Unified Modeling Language (UML)
面向对象是一 种思想方法
RUP是Rational公司定义的统一软件过程知识库产品.
UML是面向对象思想的统一表达语言.
ROSE是Rational公司开发的运用UML和RUP的CASE工具.
Unified Modeling Language (UML)
注意:
UML不是可视化程序设计语言,而是标准的图形化建模语言;
不是工具或知识库的规格说明,而是建模语言规格说明;
不是过程,也不是方法;但允许任何一种过程或者方法使用它.
与具体实现无关,可应用于任何语言平台和工具平台;
与具体过程无关,可应用于任何软件开发过程;
Unified Modeling Language (UML)

一般而言,我们可以从以下几种常用的视角来描述一个系统:
系统的使用实例:从系统外部的操作者的角度描述系统的功能.
系统的逻辑结构:描述系统内部的静态结构和动态行为,即从内部描述如何设计实现系统功能.
系统的构成:描述系统由哪些程序组件所组成.
系统的并发性:描述系统的并发性,强调并发系统中存在的各种通信和同步问题.
系统的配置:描述系统的软件和各种硬件设备之间的配置关系.
Unified Modeling Language (UML)
场景
设计视图
实现视图
进程视图
实施视图
描述设计的对象模型,关注软件抽象功能性需求
描述设计的并发和同步等特性,关注系统非功能性需求
描述软件和硬件的映射问题,关注系统非功能性需求(性能,可靠性等)
关注软件代码的静态组织与管理
对系统中的重要活动的抽象,使四个视图有机地联系起来
软件体系架构的:"4+1"视图
逻辑视图
物理视图
Unified Modeling Language (UML)
静态图
实现图
行为图
交互图
包图
UML图符
常见模型元素
UML Use Case Diagrams(用例图)
用例图描述系统外部的执行者与系统的用例之间的某种联系.
所谓用例是指对系统提供的功能(或称系统的用途)的一种描述;
执行者是那些可能使用这些用例的人或外部系统;
用例和执行者之间的联系描述了"谁使用哪个用例".
一个用例是用户与计算机之间为达到某个目的的一次典型交互作用:
用例描述了用户提出的一些可见的需求;
用例可大可小;
用例对应一个具体的用户目标
用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能,并且指明了这些功能的执行者是谁;
用例图在UML方法中占有十分重要的地位,人们甚至称UML是一种用例图驱动的开发方法.
UML Use Case Diagrams(用例图)
用例分析的一个好处是它能够展现出系统和外部世界之间的边界.参与者是典型的系统外部实体,而用例是典型的属于系统内部.系统的边界用一个矩形来代表,里面写上系统的名字.系统的用例装入矩形之内.
UML Use Case Diagrams(用例图)
用例图中的图符:
使用:由用例A连向用例B,表示用例A中使用了用例B中的行为或功能.

扩展:由用例A连向用例B,表示用例B描述了一项基本需求,而用例A则描述了该基本需求的特殊情况.

注释体:对UML实体进行文字描述
注释连接:将注释体与要描述的实体连接,说明该注释体是针对该实体进行的描述.
扩展
扩展用例
被扩展用例
使用
使用用例
抽象用例
UML Use Case Diagrams(用例图)
设置边界
风险分析
交易估计
进行交易
超越边界
更新帐目
评价
贸易经理
营销人员
记帐系统
销售人员
使用
使用
扩展
UML Use Case Diagrams(用例图)
用例建模步骤:
1.获取执行者:
谁使用系统的主要功能(主要使用者)
谁需要系统支持他们的日常工作
谁来维护,管理系统使其能正常工作(辅助使用者)
系统需要控制哪些硬件
系统需要与其他哪些系统交互
对系统产生的结果感兴趣的是哪些人
2.获取用例:
执行者要求系统提供哪些功能
执行者需要读,产生,删除,修改或存储系统中的信息有哪些类型
必须提醒执行者的系统事件有哪些
执行者必须提醒系统事件有哪些 怎样把这些事件表示成用例中的功能
3.构造用例模型图
4.记录用例描述
UML Class Diagrams(类图)
静态模型
在面向对象的建模技术中,类,对象和它们之间的关系是最基本的建模元素.对于一个想要描述的系统,其类模型,对象模型以及它们之间的关系揭示了系统的结构.
类图
类图描述了系统中的类及其相互之间的各种关系,其本质反映了系统中包含的各种对象的类型以及对象间的各种静态关系(关联,子类型).
类图中的图符:
其中第一栏是类的名,第二栏是类的属性,第三栏是类的操作.
操作(服务)
属性
类名
UML Class Diagrams(类图)
WashingMachine
brandName
modeName
serialNumber
addClothes(C:String)
removeClothes(C:string)
turnON():Boolean
属性——是类的一个特性,它描叙了类的对象(也就是类的实例)所具有的一系列特性值.
一个类可以具有零个到多个属性.属性名列表放在类名之下,并且和类名之间用分隔号隔开.
UML中属性的语法格式:
可见性 属性名:类型名=初值{性质串}
可见性(可访问性)包括三种:
公有的(+)
私有的(—)
保护的(#)
如果未声明可见性,则表示该属性的可见性尚未定义.
注意,没有默认的可见性.
类图举例
UML Class Diagrams(类图)
WashingMachine
brandName
modeName
serialNumber
addClothes(C:String)
removeClothes(C:string)
turnON():Boolean
操作——是类能够做的事情或者你(或者另一个类)能对类做的事情.
操作名列表要放在属性名列表之下,两者之间用分隔线隔开.
UML中操作的语法格式:
可见性 操作名(参数表):返回值类型{性质串}
可见性定义方法与属性相同.
参数表语法:
参数名:类型名=默认值
当参数的调用者未提供实在参数时,该参数使用默认值.
类图举例
UML Class Diagrams(类图)
类与类的关系——关联关系
(1)普通关联
UML Class Diagrams(类图)
类与类的关系——关联关系
UML Class Diagrams(类图)
类与类的关系——聚合关系
(1)组成聚合:用于表示类的对象之间的关系:整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失.
UML Class Diagrams(类图)
类与类的关系——聚合关系
(2)共享聚合:用于表示类的对象之间的关系是整体与部分的关系.
UML Class Diagrams(类图)
类与类的关系——泛化关系
抽象类:没有具体对象的类
抽象类通常作为父类,用于描述其他子类的公共属性和行为.
抽象类表示:在类名下方附加一个标记值{abstract}
抽象类通常都具有抽象操作.
抽象操作仅用来指定该类的所有子类应具有哪些行为.
抽象操作的表示:在操作标记后面跟随一个性质串{abstract}
交通工具
{abstract}
Drive(){abstract}
汽车
Drive()
轮船
Drive()
驱动车轮转动
转动螺旋桨
UML Class Diagrams(类图)
订单
DateReceived
isPrepaid
number:String
prce:Money
Dispatch()
close()
订单项
Quantity:Integer
price:Money
isSatisfied:Boolean
1
*
项
客户
Name
address
CreditRating():String
团体客户
ContactName
creditRating
creditLimit
Remind()
billforMonth(Intrger)
雇员
产品
个人客户
CreditCard#
{creditRating()
="poor"}
销售代表
1
*
0..1
1
*
*
UML Object Diagrams(对象图)
对象图
对象图是类图的一种变形.除了在对象名下面要加下划线以外,对象图中所使用的符号与类图基本相同.
对象图是类图的一种实例化.一张对象图表示的是与其对应的类图的一个具体实例,即系统在某一时期或者某一特定时刻可能存在的具体对象实例以及它们相互之间的具体关系.
对象图并不象类图那样具有重要的地位,但是利用它可以帮助我们通过具体的实例分析,更具体直观地了解复杂系统类图的丰富内涵.
对象图还常常被用作协作图的一部分,用以展示一组对象实例之间的动态协作关系.
UML Object Diagrams(对象图)
类的属性在该类的每个对象中都有具体值.
对象名首写字母小写,后面根一个冒号,冒号后面是该对象所属的类名,并且整个名字要带下划线.
myWasher:WashingMachine
brandName="海尔"
modeName="小神童"
serialNumber="GL0214"
对象图举例
UML Object Diagrams(对象图)
作者
计算机
名字:String
内存:Ineger
名字:String
年龄:Integer
0..1
Uses
1..*
类图
小王:作者
小王的工作PC:
计算机
名字 = "王小影"
年龄 = 32
小王的工作PC:
计算机
名字 = "Compaq X"
内存 = 32
名字 = "Dell486"
内存 = 64
对象图
UML Object Diagrams(对象图)
对象\类图建立步骤:
1〉研究分析问题领域,确定系统的需求.
2〉发现对象和类,明确他们的含义和责任,确定属性和操作.
3〉发现类之间的静态联系.着重分析找出类之间的一般和特殊关系,部分与整体关系,研究类的继承性和多态性,把类之间的静态联系用关联,泛化,聚合,组合,依赖等联系表达出来.
4〉设计类与联系.调整和细化已得到的对象类和类之间的联系,解决诸如命名冲突,功能重复等问题.
5〉绘制对象类图并编制相应的说明.

UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
某银行拟开发一个自动取款机系统,它是由自动取款机,中央计算机,分行计算机和柜员终端组成的网络系统.ATM和中央计算机由总行投资购买.总行拥有多台ATM机,分别设在全市各主要街道上.分行负责提供分行计算机和柜员终端.柜员终端设在分行营业厅以及分行下属的各储蓄所内.该系统的软件开发成本由各个分行分摊.
银行柜员使用柜员终端处理储户提交的储蓄事务.储户可以用现金或者支票向自己拥有的某个帐户内存款或者开新帐户.储户也可以从自己的账户中取款.通常,一个储户可能拥有多个帐户.柜员负责把储户提交的存款或者取款事务输进柜员终端,接收储户交来的现金或者支票,或者付给储户现金.柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个帐户的事务并且维护账户.
UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
1.分析业务领域术语,作为类和对象的初步候选者.
某银行拟开发一个自动取款机系统,它是由自动取款机,中央计算机,分行计算机和柜员终端组成的网络系统.ATM和中央计算机由总行投资购买.总行拥有多台ATM机,分别设在全市各主要街道上.分行负责提供分行计算机和柜员终端.柜员终端设在分行营业厅以及分行下属的各储蓄所内.该系统的软件开发成本由各个分行分摊.
银行柜员使用柜员终端处理储户提交的储蓄事务.储户可以用现金或者支票向自己拥有的某个帐户内存款或者开新帐户.储户也可以从自己的账户中取款.通常,一个储户可能拥有多个帐户.柜员负责把储户提交的存款或者取款事务输进柜员终端,接收储户交来的现金或者支票,或者付给储户现金.柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个帐户的事务并且维护账户.
UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
2.筛选出正确的类和对象,去掉冗余,无关,笼统,属性,操作,实现.
某银行拟开发一个自动取款机 系统(笼统),它是由自动取款机,中央计算机,分行计算机和柜员终端组成的网络(笼统)系统.ATM和中央计算机由总行投资购买.总行拥有多台ATM机,分别设在全市(无关)各主要街道(无关)上.分行负责提供分行计算机和柜员终端.柜员终端设在分行营业厅(无关)以及分行下属的各储蓄所(无关)内.该系统的软件(笼统)开发成本(无关)由各个分行分摊.
银行柜员使用柜员终端处理用户(冗余)提交的储蓄事务.储户可以用现金(属性)或者支票(属性)向自己拥有的某个帐户内存款或者开新帐户.用户也可以从自己的账户中取款.通常,一个用户可能拥有多个帐户.柜员负责把储户提交的存款或者取款事务输进柜员终端,接收储户交来的现金或者支票,或者付给储户现金.柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个帐户的事务并且维护账户.
UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
3.确定关联.
某银行拟开发一个自动取款机系统,它是由自动取款机,中央计算机,分行计算机和柜员终端组成的网络系统.ATM和中央计算机由总行投资购买.总行拥有多台ATM机,分别(ATM)设在全市各主要街道上.分行负责提供分行计算机和柜员终端.柜员终端设在分行营业厅以及分行下属的各储蓄所内.该系统的软件开发成本由各个分行分摊(软件开发成本).
银行柜员使用柜员终端处理储户提交的储蓄事务.储户可以用现金或者支票向自己拥有的某个帐户内存款或者开新帐户.储户也可以从自己的账户中取款.通常,一个储户可能拥有多个帐户.柜员负责把储户提交的存款或者取款事务输进柜员终端,接收储户交来的现金或者支票,或者付给储户现金.柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个帐户的事务并且(分行计算机)维护账户.
UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
4.分析并筛选候选关联.去掉:已经删除的类之间的关联;与问题无关或需要在实现阶段考虑的事件;三元关联;派生关联.
某银行拟开发一个自动取款机系统,它是由自动取款机,中央计算机,分行计算机和柜员终端组成的网络系统.ATM和中央计算机由总行投资购买.总行拥有多台ATM机(总行拥有中央计算机;ATM机与中央计算机通信),分别(ATM)设在全市各主要街道上.分行负责提供分行计算机和柜员终端.柜员终端设在分行营业厅以及分行下属的各储蓄所内.该系统的软件开发成本由各个分行分摊(软件开发成本).
银行柜员使用柜员终端处理储户提交的储蓄事务(柜员输入事务;事务修改帐户).储户可以用现金或者支票向自己拥有的某个帐户内存款或者开新帐户.储户也可以从自己的账户中取款.通常,一个储户可能拥有多个帐户.柜员负责把储户提交的存款或者取款事务输进柜员终端,接收储户交来的现金或者支票,或者付给储户现金.柜员终端与相应的分行计算机通信,分行计算机具体处理针对某个帐户的事务(分行处理事务;事务修改帐户)并且(分行计算机)维护账户.
UML Object Diagrams(对象图)
对象\类图案例讲解——ATM系统
5.ATM机初始类图草图
总行
柜员终端
分行计算机
ATM
中央计算机
储户
帐户
分行
柜员事务
柜员
6. 进一步修改,并确定属性和操作(略)
UML Packages (包图)
包图
包是一种分组机制,表示一个类图集合.
包图所显示的是类的包以及这些包之间的依赖关系.
如果两个包中的任意两个类之间存在依赖关系,则这两个包之间存在依赖关系.
包的依赖是不传递的.
何时使用包图
在大项目中,包图是一种重要工具;
依赖产生耦合,应该尽量将依赖性减少到最低程度;
包的概念对测试也是特别有用的.
Package
UML Packages(包图)
包图建立步骤:
1〉分析系统模型元素(通常是类),把概念上或语义上相近的模型元素纳入一个包.注意可以从类的功能的相关性来确定纳入包中的类.
分析对象类的功能相关性:
如果一个类的行为和/或结构的变更要求另一个相应的变更,则这两个类是功能相关.
如果删除一个类后,另一个类便变成是多余的,则这两个类是功能相关的,这说明该剩余的类只为那个被删除的类所使用,他们之间有依赖关系.
如果两个类之间大量的频繁交互或通信,则这两个类是功能相关的.
如果两个类之间有一般/特殊关系,则这两个类是功能相关的.
如果一个类激发创建另一个类的对象,则这两个类是功能相关的.
如果两个类不涉及同一个外部参与者,则这两个类不应放在同一个包中.
一个包应当具有高内聚性,包中的类应该是功能相关的.
2〉对于每一个包,标出其模型元素的可视性:公共,保护或私有.
3〉确定包与包之间的依赖关系,特别是输入依赖.
4〉确定包与包之间的泛化关系,确定包元素的多态性和重载.
5〉绘制包图.
UML Packages(包图)
订单获取
界面
订单获取
应用
AWT
邮件发送
清单界面
邮件发送
清单应用
订单
顾客
UML Statechart Diagrams(状态图)
状态图
状态图是对类的一种补充描述,它展示了此类对象所具有的可能的状态以及某些事件发生时其状态的转移情况.
在状态图中,状态由圆角矩形表示.状态的改变称作转移,状态转移由箭头表示,箭头旁可以标出转移发生的条件.状态转移可以伴随有某个动作,它表明当转移发生时系统要做什么.
状态图针对单个对象建立模型.
状态之间怎样转换
状态图中两个状态之间带箭头的连线称为状态转换,箭头指明了转换方向.
状态转换通常是由事件触发的,在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式.
如果在箭头线上未标明事件,则表示在源状态的内部活动执行完之后自动触发转换.
UML Statechart Diagrams(状态图)
状态图基本符号:
初态——用实心圆表示;
终态——用一对同心圆(内圆为实心圆)表示;
中间状态——用圆角矩形表示;
分成上,中,下3个部分.
上面部分为状态的名称,这部分是必须有的;
中间部分为状态变量的名字和值,这部分是可选的;
下面部分是活动表,这部分也是可选的.
活动表的语法格式如下:
事件名(参数表)/动作表达式
"事件名"可以是任何事件的名称.
在活动表中经常使用下述3种标准事件:entry,exit和do.
entry事件指定进入该状态的动作
exit事件指定退出该状态的动作
do事件则指定在该状态下的动作.
需要时可以为事件指定参数表.活动表中的动作表达式描述应做的具体动作.
UML Statechart Diagrams(状态图)
事件表达式的语法如下:
事件说明[守卫条件]/动作表达式
事件说明的语法为:事件名(参数表).
守卫条件是一个布尔表达式.如果同时使用事件说明和守卫条件,则当且仅当事件发生且布尔表达式为真时,状态转换才发生.如果只有守卫条件没有事件说明,则只要守卫条件为真状态转换就发生.
动作表达式是一个过程表达式,当状态转换开始时执行该表达式.
UML Statechart Diagrams(状态图)
UML Statechart Diagrams(状态图)
下降状态
在第一层
上升状态
向第一层下降
空闲状态
上升
到达
到达
上升
超时
下降
到达第一层
课堂练习:根据下列陈述绘制状态图
复印机的工作过程大致如下:未接到复印命令时处于闲置状态,一旦接到复印命令则进入复印状态,完成一个复印命令规定的工作后又回到闲置状态,等待下一个复印命令;如果执行复印命令时发现没纸,则进入缺纸状态,发出警告,等待装纸,装满纸后进入闲置状态,准备接收复印命令;如果复印时发生卡纸故障,则进入卡纸状态,发出警告等待维修人员来排除故障,故障排除后回到闲置状态.
请用状态转换图描绘复印机的行为.
UML Statechart Diagrams(状态图)
UML Statechart Diagrams(状态图)
建立状态图的步骤:
1〉确定状态机的上下文,它可以是一个类,子系统或整个系统.
2〉选择初始状态和终结状态.
注意:一张状态图中只能有一个初态,而终态可以有0个或者多个.
3〉发现对象的各种状态.
4〉确定状态可能发生的装移.注意从一个状态可能转移到哪些状态,对象的哪些行为可引起状态的转移并找出触发状态转移的事件.
5〉找出触发状态转移的事件.
6〉绘制状态图.
7〉细化状态中的可选项(状态变量/活动表等).
UML Sequence Diagrams (顺序图)
顺序图
顺序图描述了对象之间动态的交互关系,着重体现对象间消息传递的时间顺序.
顺序图由一组对象构成,每个对象分别带有一条竖线,称作对象的生命线,它代表时间轴,时间沿竖线向下延伸.顺序图描述了这些对象随着时间的推移相互之间交换消息的过程.消息用从一条垂直的对象生命线指向另一个对象的生命线的水平箭头表示.图中还可以根据需要增加有关时间的说明和其他注释.
UML Sequence Diagrams (顺序图)
顺序图符号
:Name2
激活:表示该对象正在执行某个操作.
激活矩形的长度表示激活的持续时间.
调用消息和返回消息的符号
异步消息的符号
:Name1
对象的生命线
对象之间相互发送的消息
UML Sequence Diagrams (顺序图)
:计算机
:打印服务程序
:打印队列
:打印机
打印文件
[打印机空闲]打印文件
[打印机忙]保存文件
UML Sequence Diagrams (顺序图)
顺序图的建立步骤
1〉 找出参与交互的对象角色,把他们横向排列在顺序图的顶部,最重要的对象安置在最左边,交互密切的对象尽可能相邻.在交互中创建的对象在垂直方向应安置在其被创建的时间点处.
2〉 对每一个对象设置一条垂直的向下的生命线.
3〉 从初始化交互的信息开始,自顶向下在对象的生命线之间安置信息.
注意用箭头的形式区别同步消息和异步消息.
4〉 在生命线上绘出对象的激活期.
5〉 根据消息之间的关系,确定循环结构及循环参数和出口条件.
UML Collaboration Diagrams(协作图)
协作图
与顺序图作用相同,协作图也是用来描述系统中对象之间的动态协作关系.协作图侧重于描述各个对象之间存在的消息收发关系(交互关系),而不专门突出这些消息发送的时间顺序.
在协作图中,对象同样是用一个对象图符来表示,箭头表示消息发送的方向,而消息执行的顺序则由消息的编号来表明.
协作图是对象的扩展,协作图除了展示出对象之间的关联,还显示出对象之间的消息传递.通常在协作图中省略掉关联的名字.
顺序图可以转换成等价的协作图,反之亦然.
UML Collaboration Diagrams(协作图)
协作图符号
:Class1
:Class3
:Class2
1:add()
1:modify()
1:update()
关联线附近的箭头线表示对象之间传递的消息,箭头指向消息接收对象.
消息名称和消息序号附在箭头线附近.
消息的一般含义是触发接收消息的对象执行它的一个操作.
在协作图中,在消息名前面加上消息的序号,它代表该消息在消息序列中的顺序.
消息名和序号之间用冒号隔开.
UML Collaboration Diagrams(协作图)
:计算机
:打印队列
:打印服务程序
:打印机
1. 打印文件
3. 保存文件[打印机忙]
2.打印文件[打印机空闲]
UML Collaboration Diagrams(协作图)
协作图
协作图的布局方法能更清楚地表示出交互对象的整体组织.
顺序图突出执行的时序,能更方便地看出事情发生的次序.
如果要描述在一个用例中的几个对象协同工作的行为,交互图是一种有力的工具.交互图擅长显示对象之间的合作关系,尽管它并不对这些对象的行为进行精确的定义.
如果想要描述跨越多个用例的单个对象的行为,应当使用状态图;如果想要描述跨越多个用例或多个线程的多个对象的复杂行为,则需考虑使用活动图.
UML Collaboration Diagrams(协作图)
绘制协作图的步骤:
1〉找出参与交互的对象角色,把他们作为图形的节点置在协作图中.最重要的对象安置在图的中央,与他有直接交互的对象安置在邻近.
2〉设置对象的初始性质.
3〉说明对象之间的链接.首先给出对象之间的关联连接,然后给出其它连接.
4〉从初始化交互的消息开始,在链接上安置相应的消息,给出消息的序号.
5〉处理一些特殊情况,如循环,自调用,回调,多对象等.
UML Activity Diagrams(活动图)
活动图
活动图描述系统中各种活动的执行顺序,通常用于描述一个操作中所要进行的各项活动的执行流程.
活动图也常被用来描述一个用例的处理流程,或者某种交互流程.
活动图由一些活动组成,图中同时包括了对这些活动的说明.当一个活动执行完毕之后,控制将沿着控制转移箭头转向下一个活动.活动图中还可以方便地描述控制转移的条件以及并行执行等要求.
活动状态表示成带有圆形边线的矩形,它含有活动的描述(普通的状态盒为直边圆角).简单的完成转换用箭头表示.和状态图相似,活动图也有起点和终点符号,表示法和状态图一样.
UML Activity Diagrams(活动图)
加水到容器中
将咖啡放到
过滤器中
点燃咖啡炉
取出咖啡杯
把过滤器放
到咖啡炉上
冲调咖啡
倒咖啡
找饮料
取一听
可口可乐
喝饮料
人
[找到可口可乐]
[没有可口可乐]
[没有咖啡]
[找到咖啡]
熄灭咖啡炉
UML Activity Diagrams(活动图)
UML Activity Diagrams(活动图)
UML Activity Diagrams(活动图)
活动图
活动图最适合支持描述并行行为,这使之成为支持工作流建模的最好工具.
活动图最大的缺点是很难清楚地描述动作与对象之间的关系.
对于以下情况可以使用活动图:
(1)分析用例;
(2)理解牵涉多个用例的工作流;
在下列情况下,一般不要使用活动图:
(1)显示对象间合作;
(2)显示对象在其生命周期内的运转情况.
UML Activity Diagrams(活动图)
活动图建立步骤:
1〉找出负责实现工作流的业务对象.这些对象可以是现实业务领域中的实体,也可以是一种抽象的概念或事物.为每一个重要的业务对象建立一条泳道.
2〉确定工作流的初始状态和终结状态,明确工作流的边界.
3〉从工作流的初始状态开始,找出随时间而发生的活动和动作,把他们表示成活动状态或动作状态.
4〉对于复杂的动作或多次重复出现的一组动作,可以把他们组成一个活动状态,并且用另外一个活动图来展开表示.
5〉给出连接活动和动作的转移(动作流).首先处理顺序动作流,然后处理条件分支.最后处理分支和结合.
6〉在活动图中给出与工作流有关的重要对象,并用虚箭线把他们与活动状态或动作状态相连接.
UML Component Diagrams(组件图)
组件图
组件图描述软件组件以及它们之间的依赖关系,从而便于人们分析和发现当修改某个组件时可能对那些组件产生影响,以便对它们做相应的修改或更新.
组件可以是源代码组件,二进制目标码组件,可执行组件或文档组件.
组件用一边有两个小矩形的一个长方形表示,它可以用实线与代表组件接口的圆圈相连 .
组件图表示了组件之间的依赖关系.每个组件实现(支持)一些接口,并使用另一些接口.如果组件间的依赖关系与接口有关,那么组件可以被具有同样接口的其他组件替代.
UML Component Diagrams(组件图)
Whnd.cpp:
窗口处理器
Graphic.dll:
图形库
Comhnd.cpp:
命令处理器
Main.cpp:
主类
Whnd.obj:
窗口处理器
Comhnd.obj:
命令处理器
Main.obj:
主类
client.exe:
客户程序
UML Component Diagrams(组件图)
UML Component Diagrams(组件图)
绘制组件图的步骤:
1〉确定组件.首先要分解系统,考虑有关系统的组成管理,软件的重用核物理节点的配置等因素,把关系密切的可执行程序和对象库分别归入组件,找出相应的对象类,接口等模型元素.
2〉对组件加上必要的构造型.可以使用uml的标准构造型《executable》,《library》,《table》,《file》,《document》,或自定义新的构造型,说明组件的性质.
3〉确定组件之间的联系.最常见的组件之间的联系是通过接口依赖.一个组件使用某个接口,另一个组件实现该接口.
4〉必要时把组件组织成包.组件和对象,协作等模型元素一样可以组织成包.
5〉绘制组件图.
UML Deployment Diagrams(配置图)
配置图
配置图描述系统中硬件和软件的物理配置情况和系统体系结构.
在配置图中,用节点表示实际的物理设备,如计算机和各种外部设备等,并根据它们之间的连接关系,将相应的结点连接起来,并说明其连接方式.在节点里面,说明分配给该结点上运行的可执行组件或对象,从而说明哪些软件单元被分配在哪些结点上运行.
UML Deployment Diagrams(配置图)
客户A:
个人电脑PC
客户B:
个人电脑PC
数据库服务器:
VAX
服务器:02
TCP/IP协议
TCP/IP 协议
DecNet协议
UML Deployment Diagrams(配置图)
UML Deployment Diagrams(配置图)
配置图建立步骤:
1〉确定节点.注意:标示系统中的硬件设备,包括大型主机,服务器,前端机,网络设备,输入/输出设备等.一个处理机是一个节点,它具有处理功能,能够执行一个组件;一个设备也是一个节点,它没有处理功能,但它是系统和现实世界的接口.
2〉对节点加上必要的构造型.可以使用uml的标准构造型或自定义新的构造型,说明节点的性质.
3〉确定联系.这是关键步骤.配置图中的联系包括节点与节点之间的联系,节点与组件之间的联系,组件与组件之间的联系.把系统的组件如可执行程序,动态连接库等分配到节点上,并确定节点与节点之间,节点与组件之间,组件与组件之间的联系,以及他们的性质.
4〉绘制配置图.
基于UML的系统开发过程
基于UML的系统开发过程——
快速应用工程指导原则(Guidelines for Rapid APPLication Engineering,GRAPPLE)
1.需求收集
2.分析
3.设计
4.实现
5.部署
基于UML的系统开发过程
基于UML的系统开发过程
1.需求收集
了解业务过程,形成描述业务过程的活动图.
进行领域分析,了解客户领域中的主要实体,构造高层类图.
识别协作系统,建立初步的部署图.
发现系统需求,通过联合应用开发计划,细化类图.会议的工作产品是包图.包代表了一个系统功能的高层领域.
将结果提交给客户.需求分析的结果提交给客户,认可后继续.
基于UML的系统开发过程
基于UML的系统开发过程
2.分析
理解系统用法,进行高层用例分析.工作产品是用例图,涵盖了用例与参与者和用例之间的包含,扩展关系.
充实用例,分析每个用例中的步骤序列.工作产品是对每个用例步骤的用例描述.
细化类图,在类图中加入关联名,抽象类,多重性,泛化和聚集.工作产品是一个细化的类图.
分析对象状态变化.进一步细化模型,展示对象状态的变化.工作产品是状态图.
定义对象之间的交互.工作产品是顺序图和协作图.
分析系统与其他协作系统的集成.包括通信类型,网络体系结构等.工作产品是详细的系统部署图和数据类型.
基于UML的系统开发过程
基于UML的系统开发过程
3.设计——细化分析阶段模型
开发和细化对象图,根据类图产生必要的对象图,检查每个操作并开发对应操作的活动图去充实对象图.工作产品是对象图和活动图.
开发构件图.可视化地描绘出构件与构件之间的关系.工作产品是构件图.
制定部署计划.编制系统的部署以及系统和其他协作系统集成的计划,表明每个节点中驻留哪些构件.工作产品是部署图.
设计和开发用户界面原型.包括与用户进行JAD会议.用户界面应该考虑到完成所有用例.分析员和拥护以其开发用户界面原型(按钮,检查框,下拉列表,菜单等).工作产品是屏幕界面原型.
设计测试.用例是进行测试设计的依据,目的是开发的软件能够实现用例所描述的事情.工作产品是测试脚本.
开始编制文档.文档编制人员和开发人员共同编制文档,制定每个文档的高层机构.工作产品是文档的结构.
基于UML的系统开发过程
基于UML的系统开发过程
4.实现
编制代码:根据掌握得类图,对象图,活动图和构件图,程序员编写实现系统的代码.工作产品是编制出的代码.
测试代码:测试专家运行测试脚本,评价代码是否完成了预期的工作.工作产品是测试结果.
构建用户界面和用户界面到代码的连接与测试.GUI专家构建用户界面并将界面连接到代码,进一步测试确保用户界面工作正确.工作产品是带有用户界面的功能系统.
完成文档.开发阶段,文档专家与程序员并行工作,确保文档及时完成和交付.工作产品是文档.
基于UML的系统开发过程
基于UML的系统开发过程
5.部署和配置
编制备份和恢复计划.有系统工程师编制计划,纺织系统崩溃.工作产品是备份和恢复计划.
在硬件上安装最终系统.系统工程师在开发人员协助下,将开发好的系统部署到合适的计算机上运行.工作产品是完全部署好的计算机系统.
测试安装后的系统.开发组对安装好的系统测试.包括功能测试,备份和恢复机制是否能够起作用等.
系统试运行.
案例分析
学生宿舍管理系统
基于UML的系统开发过程
课后练习——请对超市进销存系统进行UML建模.
系统需满足的基本需求如下:
1, 销售:售货员接受顾客订购,输入顾客购买的商品,计算总价
顾客付款并接受清单
售货员保存顾客购买的商品记录
2, 库存:
库存管理员每天进行盘点
库存管理员每天发现库存商品有损坏时,及时到相关部门报损
供应商的商品到货时,超市人员首先检查商品是否合格,并将合格商品入库处理
经理,统计分析员根据需要进行相关商品的模糊查询或详细查询
3, 订货:
订货员用新商品供应商信息更新供应商数据库的信息
订货员统计库存商品是否低于库存下限,然后制作订货单
4, 统计:
经理在促销期间或节日期间,注明相关商品的促销价格和手段
经理按市场情况经常变动商品价格
请根据下列叙述建立类图.以订单系统为例,客户可以划分为团体客户和个人客户.团体客户中有时会设立一名雇员作为销售代表.客户可以对应多个订单,每个订单有多个订单项,每个订单项只能对应一种产品,但一种产品可以在多个订单项中出现.
虽然对象类图表达的是系统的静态结构特征,但是应当把对系统的静态分析与动态分析结合起来,更能准确地了解系统的静态结构特征.
虽然对象类图表达的是系统的静态结构特征,但是应当把对系统的静态分析与动态分析结合起来,更能准确地了解系统的静态结构特征.
通常,在需求陈述中不会一个不漏地写出问题域中所有有关的类和对象,因此,分析员应该根据领域知识或常识进一步把银行的雷和对象提取出来.
通常,在需求陈述中不会一个不漏地写出问题域中所有有关的类和对象,因此,分析员应该根据领域知识或常识进一步把银行的雷和对象提取出来.
初步确定关联时,多数关联通过直接提取需求陈述中的动词词组而得出.然后通过分析需求陈述可以得到一些隐含的关联.最后,再根据领域知识补充一些关联.
初步确定关联时,多数关联通过直接提取需求陈述中的动词词组而得出.然后通过分析需求陈述可以得到一些隐含的关联.最后,再根据领域知识补充一些关联.
三元关联分解为二元关联.
初步确定关联时,多数关联通过直接提取需求陈述中的动词词组而得出.然后通过分析需求陈述可以得到一些隐含的关联.最后,再根据领域知识补充一些关联.
三元关联分解为二元关联.
又叫状态机或者状态表
守卫条件=保护条件guard condition当满足这个条件时,转移才能发生.
将模型中的活动按照职责组织起来通常很有用.例如,可以将一个商业
组织处理的所有活动组织起来.这种分配可以通过将活动组织成用线分
开的不同区域来表示.由于它们的外观的缘故,这些区域被称作泳道.
Teaching Notes
Component diagrams are implementation type diagrams and are used to graphically depict the physical architecture of the software of the system. They can be used to show how programming code is divided into modules (or components) and depict the dependencies between those components.
Teaching Notes
Deployment diagrams are also implementation type diagrams that describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system's architecture.
注意,这5个部分是SEGMENT,而不是阶段.每个SEGMENT由许多动作组成,每个动作能够产生一个,每个动作都是一个特定的执行者的职责.
·上一篇：国家粮食局办公室关于印发粮食系统公文主题词表的...
·下一篇：浙江工业大学研究生会公文格式规范条例