UML中数据流图介绍(doc 21页)
管理信息系统第06章 关于数据流图的一些说明

1、数据流程图的逐层扩展最上层的数据流程图应概括地反映信息系统最主要的逻辑功能、外部实体和数据存储,并且能让用户一看就明白这个系统的主要功能、外部实体以及与环境的主要联系是什么。
逐层扩展数据流程图是对父图中某些处理框加以分解。
随着处理的分解,功能越来越具体,数据存储、数据流越来越多。
逐层扩展数据流程图时应注意保持系统的完整性和一致性:✓子图是父图中某个处理框的“放大”。
✓子图上应用虚线长方框表示所放大的处理框。
✓凡与这个处理框有关系的外部实体、数据流、数据存储都必须在子图中反映出来。
逐层扩展数据流程图的目的是把一个复杂的功能逐步分解为若干较为简单的功能。
2、分层应遵循的原则分层应遵循的原则:✓(1)一个处理框经过展开,一般以分解为3~8个处理框为宜。
✓(2)展开的层次与管理层次一致,也可以划分得更细。
处理块的分解要自然,注意功能的完整性。
✓(3)数据流程图分层细化时必须保持信息的连续性,即当把一个处理分解为一系列处理时,分解前和分解后的输入、输出数据流必须相同。
3、检查数据流程图的正确性(1)数据流是指处理的输入或输出,任何一个数据流至少一端是处理框。
也就是说,数据流不能从外部实体直接到数据存储,不能从数据存储到外部实体,也不能在外部实体之间或数据存储之间流动。
(2)父图中某一处理框的输入、输出数据流必须出现在相应的子图中,否则就会出现父图与子图的不平衡,这样的分层将使用户无法理解。
因而,检查父图与子图是否平衡尤为重要。
父图的某框扩展时,在子图中可以用虚线框表示出来,有利于这种检查。
(3)数据守恒,即输入数据要与输出数据相匹配。
数据不守恒有两种情况:一种情况是可能遗漏了某些输入数据流,从而导致某个处理过程在没有输入的情况下产生了输出的数据;另一种情况是某些输入在处理过程中没有使用,虽然这种情况不一定是错误,但也可以研究一下为什么会产生这种情况,是否可以简化。
(4)在绘制数据流程图时,应注意处理框与数据存储之间数据流的方向。
选课系统的UML的环境图,数据流图,结构图,数据库设计,程序流程图

列 名
数据类型
宽度
字段描述
ID
Int
4
教师-课程记录的惟一ID号,设为主键
Teacher id
Varchar
50
教师号
Course id
Varchar
50
教师所任课程号
Teacher_class
Varchar
50
教师所教班级号
Course_year
(4)正选:学生根据预选课课表进行跨专业选修和补退选。
(5)成绩:教务处输入考试安排,考试完成后老师输入学生成绩,学生可以查询自己的成绩。
四、数据库设计
表1用户信息数据表(Manger)
列 名
数据类型
宽度
字段描述
Manger_id
Char
10
用户名,设为主键
Manger_Passwod
Char
20
用户登录本系统时的用户密码
(d)加工名:成绩管理
编号:3
简述:根据学生已选修的课程教秘安排考试并输入到教务管理中。学生进行考试,成绩合格的同学可以打印自己的成绩,成绩不合格的教务管理安排补考。对于不能考试的学生须向教秘申请,获得批准后和正考成绩不合格的学生一起进行补考。补考成绩最高为60分。补考不合格的学生需进行重修。功能进行学生成绩管理
模块说明:
(1)登录:进入登录界面,选择用户的类型:教务处老师学生。输入用户名和密码进入系统。
(2)信息输入:教务处输入教师信息和学生信息和推荐课表。学生根据实际情况选择对应的课程。选定后,系统显示具体学科上课时间和教师教室信息,学生选课完成后。若选择情况有误,可点击退选进行修改。
UML的流程图

UML的流程图UML是一种面向对象的统一建模语言,用于快速地描述软件系统的结构、行为和交互。
而流程图是UML中的一种图形语言,用于对系统中的流程进行描述和设计。
本文将为大家介绍UML流程图的概念、种类、结构和使用方法。
概念UML流程图,也称UML活动图,是一种图形化的表示算法、流程和业务过程的工具,它可以直观地表达系统中的任务、动作、决策和控制流程。
UML流程图常用于软件开发过程中的需求分析、业务流程设计、系统架构设计等领域。
种类UML流程图包含四种基本类型:1.基本活动图基本活动图可以用来表示操作的顺序或并行方式,其中每个操作都是基本动作,例如读取、写入、计算等。
基本活动图通常用于领域建模和系统流程的初步设计。
2.流程状态图流程状态图是对系统中复杂操作的一种表示,可以用来展示操作的状态和转换方式。
流程状态图主要包括状态、转换和起始状态,它通常用于描述系统中的复杂业务流程。
3.并发活动图并发活动图可以用来表达系统中多个处理程序的并发执行过程,它通常使用平行线表示并发执行的多个处理程序。
4.条件活动图条件活动图是一种用于表示系统中动态交互的活动图,其中条件是关键的组成部分。
条件活动图通常用于强制执行程序在满足一定条件的情况下才能执行,例如软件开发中经常用到的循环结构和分支结构等。
结构UML流程图的结构由一系列基本元素组成:1.开始节点开始节点,在UML流程图中表示整个活动图的起点。
一般情况下,开始节点在活动图的左侧上方,使用一个表示圆圈中心的空心点表示。
2.结束节点结束节点,在UML流程图中表示整个活动的结束点。
一般情况下,结束节点位于活动图的右侧下方,使用一个表示实心点的圆圈表示。
3.动作节点动作节点是一种执行操作的元素,可以进行计算、赋值、IO操作等。
动作节点在UML流程图中通常用长方形表示。
4.决策节点决策节点用于表示一个条件分支,并根据条件的结果选择一个或多个分支行动。
在UML流程图中,它通常使用菱形表示。
UML中数据流图说明

·单向关联在一个单向关联中,两个类是相关的,然而只有一个类明白这种联系的存在。
一个单向的关联,表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形,用于标志继承)的实线。
如同标准关联,单向关联包括一个角色名和一个多重值描述,然而与标准的双向关联不同的时,单向关联只包含已知类的角色名和多重值描述。
简单的讲确实是OverdrawAccountReport中包含了BankAccount 属性,而BankAccount中不需要包含OverdrawnAccountsReport 对象6.聚合的表示:聚合是一种特不类型的关联,用于描述“总体到局部”的关系。
在差不多的聚合关系中,部分类的生命周期独立于整体类的生命周期。
举例来讲,我们能够想象,车是一个整体实体,而车轮轮胎是整辆车的一部分。
轮胎能够在安置到车时的前几个星期被制造,并放置于仓库中。
在那个实例中,Wheel类实例清晰地独立于Car类实例而存在。
然而,有些情况下,部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。
举例来讲,考虑公司与部门的关系。
公司和部门都建模成类,在公司存在之前,部门不能存在。
那个地点Department类的实例依靠于Company类的实例而存在。
让我们更进一步探讨差不多聚合和组合聚合。
注意:聚合与一般的关联的区不在于:一般的关联可能只是一个简单的“包含、引用”关系,关联和被关联类之间在逻辑概念上不一定有紧密的联系,而聚合则不同,它表示的是一种内在关系紧密,相互依存,相互包含的概念,其中的一部分是构成另外一部分的不可或缺的成分。
·差不多聚合有聚合关系的关联指出,某个类是另外某个类的一部分。
在一个聚合关系中,子类实例能够比父类存在更长的时刻。
为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。
图中清晰的表明了类Car对象包含了另一类Wheel的4个实例,这两者在概念上是密不可分的,其中的一个类是另一个类的构成成分。
数据流图(DataFlowDiagram,简称DFD)

数据流图(DataFlowDiagram,简称DFD)声明:本资料来源于个⼈对⽹上相关资料的整理;在信息处理系统中应⽤数据流图,通过对系统中数据、数据加⼯的全⾯分析,准确勾画出系统的框架,系统开发⼈员问以此为交流平台,共同分析可⾏性、合理性等,有助于系统缺陷在分析阶段被及时的发现和消除,为系统的设计、实现、测试阶段提供准确⽽充分的分析,是确保系统及产品质量的必要条件.采⽤语⾔描述、控制流图、程序框图分析是不是⽐⽤数据流图更好呢?⽤语⾔描述进⾏分析,分析的结果是⽆形的,只有对这个系统需要完成功能的描述.是否对所有数据的输⼈、输出、数据的处理过程进⾏分析是不可见的,也就⽆法考证分析的正确性和充分性,分析是不可控的,必然导致软件的缺陷,要到软件开发阶段后期才能发现,有可能对系统产⽣⼀定危害.⽤控制流图进⾏分析,分析关注的重点是控制,通过标识其状态描述系统的⾏为;标识这些状态是如何达到的,并定义状态间的变迁.信息处理领域的系统S是通过数据驱动的,⽤控制流图的分析不能涵盖所有数据,只对能产⽣系统⾏为的数据被分析,分析是不充分的,那么某些软件的缺陷在软件开发阶段早期不会被发现.⽤程序框图进⾏分析,分析关注的重点是如何实现系统的功能,注重的是细节,它应使⽤在软件开发的设计阶段.在分析阶段要注重系统的框架,⽤程序框图的分析不能清楚地看出系统的框架,将分析和设计过程混在⼀起,容易掩盖软件的缺陷.⽤数据流图进⾏分析,分析关注的重点是数据,将⾯向控制的信息作为数据进⾏处理,涵盖系统的所有数据,能准确的抽象系统的信息处理过程.概括的描述信息流和当数据从输⼈移动到输出时被应⽤的变换,每⼀层都明确强调“⼲什么“,“需要什么”,“给出什么”;可以反映出数据的流向和处理过程;数据流图分层进⾏分析,对顶层图的分析可以发现是否有输⼊信息或需要输出的信息被遗漏,容易及早发现系统各部分的逻辑错误,也容易修正.这样逐层分解下去,系统被严密的展开,系统的框架被展现出来.数据流图还有助于消除通常存在于软件开发⼈员与系统总体及硬件⼈员的交流隔阂.系统开发⼈员通过数据流图更容易理解软件要完成什么功能,数据来源于哪⾥,结果要输出到哪等等,他们可以给软件⼈员更多合理的建议.由于采⽤数据流图进⾏分析,提⾼分析的可见性和可控性,有助于软件的缺陷在软件开发阶段早期被及时的发现和消除.⼀,数据流图的基本元素数据流图中只能有四种基本元素,如下:描述⼀个处理.输⼊数据在此进⾏变换产⽣输出数据.其中注明处理的名称.描述⼀个输⼊源点或输出汇点.其中注明源点或汇点的名称.描述⼀个数据流.被加⼯的数据及其流向.流线上注明数据名称,箭头代表数据流动⽅向.描述⼀个数据存储.通常⽤于代表⼀个数据表,其中注明数据表的名称.⼆,分层数据流图为了表达数据处理过程的数据加⼯情况,⽤⼀个数据流图往往是不够的.稍为复杂的实际问题,在数据流图上常常出现⼗⼏个甚⾄⼏⼗个加⼯.这样的数据流图看起来很不清楚.层次结构的数据流图能很好地解决这⼀问题.按照系统的层次结构进⾏逐步分解,并以分层的数据流图反映这种结构关系,能清楚地表达和容易理解整个系统.下图给出分层数据流图的⽰例.数据处理S包括三个⼦系统1,2,3.顶层下⾯的第⼀层数据流图为DFD/L1.第⼆层数据流图DFD/L2.1,DFD/L2.2及DFD/L2.3分别是⼦系统1,2和3的细化.对任何⼀层数据流图来说,我们称它的上层图为⽗图,在它下⼀层的图则称为⼦图.三,画数据流图的步骤和原则基本步骤:⾃外向内,⾃顶向下,逐层细化,完善求精.基本原则:①数据流图上所有图形符号只限于前述四种基本元素.②顶层数据流图必须包括前述四种基本元素,缺⼀不可.③顶层数据流图上的数据流必须封闭在外部实体之间.④每个加⼯⾄少有⼀个输⼊数据流和⼀个输出数据流.⑤在数据流图中,需按层给加⼯框编号.编号表明该加⼯处在哪⼀层,以及上下层的⽗图与⼦图的对应关系.⑥规定任何⼀个数据流⼦图必须与它上⼀层的⼀个加⼯对应,两者的输⼊数据流和输出数据流必须⼀致.此即⽗图与⼦图的平衡.⑦可以在数据流图中加⼊物质流,帮助⽤户理解数据流图.⑧图上每个元素都必须有名字.数据流和数据⽂件的名字应当是"名词"或"名词性短语",表明流动的数据是什么.加⼯的名字应当是"名词+宾语",表明做什么事情.⑨数据流图中不可夹带控制流.⑩初画时可以忽略琐碎的细节,以集中精⼒于主要数据流.四,数据流图应⽤举例例⼦待续。
UML中数据流图,用例图,类图,对象图,角色图,活动图,序列图详细讲述保存供参考

UML中数据流图,⽤例图,类图,对象图,⾓⾊图,活动图,序列图详细讲述保存供参考这个⽂章,是我在急需的情况下在园⼦⾥搜索到的,原创作者是:DO-websoftware,为了⾃⼰看⽅便,所以复制到我的空间,希望原创者不要介意哦~~~~很详细的介绍,对我的帮助很⼤,谢谢哦。
类图,对象图,⾓⾊图:⼀、UML中基本的图范畴:在 UML 2 中有⼆种基本的图范畴:结构图和⾏为图。
每个 UML 图都属于这⼆个图范畴。
结构图的⽬的是显⽰建模系统的静态结构。
它们包括类,组件和(或)对象图。
另⼀⽅⾯,⾏为图显⽰系统中的对象的动态⾏为,包括如对象的⽅法,协作和活动之类的内容。
⾏为图的实例是活动图,⽤例图和序列图。
⼆、UML中的类图:1.类图的表⽰:类的 UML 表⽰是⼀个长⽅形,垂直地分为三个区,如图 1 所⽰。
顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
描述:顶部区域显⽰类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。
·类名:如果是抽象类,则采⽤斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0,这是带有默认值的表达形式·类⽅法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
数据流图和数据流程图

数据流图和数据流程图⼀、数据流图1.(Data Flow Diagram):简称DFD,它从数据传递和加⼯⾓度,以图形⽅式来表达系统的逻辑功能、在系统内部的逻辑流向和逻辑变换过程,是的主要表达⼯具及⽤于表⽰软件模型的⼀种图⽰⽅法。
2.包括:a.指明数据存在的数据符号,这些数据符号也可指明该数据所使⽤的媒体;b.指明对数据执⾏的处理的处理符号,这些符号也可指明该处理所⽤到的机器功能;c.指明⼏个处理和(或)数据媒体之间的数据流的流线符号;d.便于读、写数据流程图的特殊符号。
3.中有以下⼏种主要元素:→:数据流。
数据流是数据在系统内传播的路径,因此由⼀组成分固定的数据组成。
□:数据源或宿(“宿”表⽰数据的终点)。
代表系统之外的实体,可以是⼈、物或其他软件系统。
○:对数据的加⼯(处理)。
加⼯是对数据进⾏处理的单元,它接收⼀定的数据输⼊,对其进⾏处理,并产⽣输出。
〓:数据存储。
表⽰信息的静态存储,可以代表⽂件、⽂件的⼀部分、数据库的元素等。
⼆、数据流程图1.数据流程图(Data Flow Diagram,DFD/Data Flow Chart),是描述系统数据流程的⼯具,它将数据独⽴抽象出来,通过图形⽅式描述信息的来龙去脉和实际流程。
它是⼀种能全⾯地描述信息系统逻辑模型的主要⼯具。
它可以利⽤少数⼏种符号综合的反映出信息在系统中的流动、处理和存储的情况。
2.数据流程图具有抽象性和概括性。
3.数据流程图的基本成分系统部件包括系统的外部实体、处理过程、数据存储和系统中的数据流四个组成部分a,外部实体外部实体指系统以外⼜和系统有联系的⼈或事物,它说明了数据的外部来源和去处,属于系统的外部和系统的界⾯。
通常外部实体在数据流程图中⽤正⽅形框表⽰,框中写上外部实体名称b,处理过程处理指对数据逻辑处理,也就是数据变换,它⽤来改变数据值。
⽽每⼀种处理⼜包括数据输⼊、数据处理和数据输出等部分。
在数据流程图中处理过程⽤带圆⾓的长⽅形表⽰处理,长⽅形分三个部分,标识部分⽤来标识⼀个功能,功能描述部门是必不可少的,功能执⾏部门表⽰功能由谁来完成。
(完整word版)数据流图

3.3 数据流图(DFD)数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程,由于它只反映系统必须完成的逻辑功能,所以它是一种功能模型。
下图是一个飞机机票预订系统的数据流图,它反映的功能是:旅行社把预订机票的旅客信息(姓名、年龄、单位、身份证号码、旅行时间、目的地等)输入机票预订系统。
系统为旅客安排航班,打印出取票通知单(附有应交的账款)。
旅客在飞机起飞的前一天凭取票通知单交款取票,系统检验无误,输出机票给旅客。
3.3.1 基本图形符号数据流图有四种基本图形符号::箭头,表示数据流;〇:圆或椭圆,表示加工;= :双杠,表示数据存储;□:方框,表示数据的源点或终点。
(1) 数据流。
数据流是数据在系统内传播的路径,因此由一组成分固定的数据组成。
如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。
由于数据流是流动中的数据,所以必须有流向,除了与数据存储之间的数据流不用命名外,数据流应该用名词或名词短语命名。
(2)加工(又称为数据处理)。
对数据流进行某些操作或变换。
每个加工也要有名字,通常是动词短语,简明地描述完成什么加工。
在分层的数据流图中,加工还应编号。
(3)数据存储(又称为文件),指暂时保存的数据,它可以是数据库文件或任何形式的数据组织。
(4)数据源点或终点,是本软件系统外部环境中的实体(包括人员、组织或其他软件系统),统称外部实体。
一般只出现在数据流图的顶层图。
3.3.2画数据流图的步骤(1)首先画系统的输入输出,即先画顶层数据流图。
顶层流图只包含一个加工,用以表示被开发的系统,然后考虑该系统有哪些输入数据、输出数据流。
顶层图的作用在于表明被开发系统的范围以及它和周围环境的数据交换关系。
下图为飞机机票预订系统的顶层图。
(2)画系统内部,即画下层数据流图。
不再分解的加工称为基本加工。
一般将层号从0开始编号,采用自顶向下,由外向内的原则。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
·单向关联在一个单向关联中,两个类是相关的,但是只有一个类知道这种联系的存在。
一个单向的关联,表示为一条带有指向已知类的开放箭头(不关闭的箭头或三角形,用于标志继承)的实线。
如同标准关联,单向关联包括一个角色名和一个多重值描述,但是与标准的双向关联不同的时,单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性,而BankAccount中不需要包含OverdrawnAccountsReport对象6.聚合的表示:聚合是一种特别类型的关联,用于描述“总体到局部”的关系。
在基本的聚合关系中,部分类的生命周期独立于整体类的生命周期。
你想到的问题在小组里交流,每举例来说,我们可以想象,车是一个整体实体,而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造,并放置于仓库中。
在这个实例中,Wheel类实例清楚地独立于Car类实例而存在。
然而,有些情况下,部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。
举例来说,考虑公司与部门的关系。
公司和部门都建模成类,在公司存在之前,部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
注意:聚合与普通的关联的区别在于:普通的关联可能只是一个简单的“包含、引用”关系,关联和被关联类之间在逻辑概念上不一定有紧密的联系,而聚合则不同,它表示的是一种内在关系紧密,相互依存,相互包含的概念,其中的一部分是构成另外一部分的不可或缺的成分。
·基本聚合有聚合关系的关联指出,某个类是另外某个类的一部分。
在一个聚合关系中,子类实例可以比父类存在更长的时间。
为了表现一个聚合关系,你画一条从父类到部分类的实线,并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例,这两者在概念上是密不可分的,其中的一个类是另一个类的构成成分。
菱形表示“包含”,箭头表示被包含的对象,数字4表示包含的数目。
·组合聚合组合聚合关系是聚合关系的另一种形式,但是子类实例的生命周期依赖于父类实例的生命周期。
注意:组合关系如聚合关系一样绘制,不过这次菱形是被填充的。
7.反射关联的表示:类也可以使用反射关联与它本身相关联。
起先,这可能没有意义,但是记住,类是抽象的。
当一个类关联到它本身时,这并不意味着类的实例与它本身相关,而是类的一个实例与类的另一个实例相关。
图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。
然而,因为“manages”的关系角色有 0..*的多重性描述;一个雇员可能不受任何其他雇员管理。
三、UML中的对象图:实例的记号和类一样,但是取代顶端区域中仅有的类名,它的名字是经过拼接的: Instance Name : Class Name 如 Donald : Person因为显示实例的目的是显示值得注意的或相关的信息,没必要在你的模型中包含整个实体属性及操作。
相反地,仅仅显示感兴趣的属性及其值是完全恰当的。
UML 2 也允许在实体层的关系/关联建模。
绘制关联与一般的类关系的规则一样,除了在建模关联时有一个附加的要求。
附加的限制是,关联关系必须与类图的关系相一致,而且关联的角色名字也必须与类图相一致。
四、UML中的角色图:建模类的实例有时比期望的更为详细。
有时,你可能仅仅想要在一个较多的一般层次做类关系的模型。
在这种情况下,你应该使用角色记号。
角色记号类似于实例记号。
为了建立类的角色模型,你画一个方格,并在内部放置类的角色名及类名,作为实体记号,但是在这情况你不能加下划线。
注意:角色图和对象图的一个明显区别就是:对象图每个对象名称下面都加了下划线,而角色图没有以下是:序列图序列图主要用于按照交互发生的一系列顺序,显示对象之间的这些交互。
很象类图,开发者一般认为序列图只对他们有意义。
然而,一个组织的业务人员会发现,序列图显示不同的业务对象如何交互,对于交流当前业务如何进行很有用。
除记录组织的当前事件外,一个业务级的序列图能被当作一个需求文件使用,为实现一个未来系统传递需求。
在项目的需求阶段,分析师能通过提供一个更加正式层次的表达,把用例带入下一层次。
那种情况下,用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现,序列图在记录一个未来系统的行为应该如何表现中,非常有用。
在设计阶段,架构师和开发者能使用图,挖掘出系统对象间的交互,这样充实整个系统设计。
序列图的主要用途之一,是把用例表达的需求,转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外,它们还能用来记录一个存在系统(称它为“遗产”)的对象现在如何交互。
当把这个系统移交给另一个人或组织时,这个文档很有用。
Java应用程序由许多类所构成,是Java实现面向对象应用程序的核心。
类图主要描述Java应用程序中各种类之间的相互静态关系,如类的继承、抽象、接口以及各种关联。
要利用UML设计Java应用程序,仅仅使用类图来描述这些静态关系,利用可视化工具,要实现Java应用程序的代码自动生成,是远远不够的。
我们还必须描述各种类相互之间的协作关系、动态关系,如时间序列上的交互行为。
其中UML序列图就是用来描述类与类之间的方法调用过程(或消息发送)是如何实现的。
一、UML中的新元素-框架:在UML 2中,框架元件用于作为许多其他的图元件的一个基础,但是大多数人第一次接触框架元件的情况,是作为图的图形化边界。
当为图提供图形化边界时,一个框架元件为图的标签提供一致的位置。
在UML 图中框架元件是可选择的。
除了提供一个图形化边框之外,用于图中的框架元件也有描述交互的重要的功能, 例如序列图。
在序列图上一个序列接收和发送消息(又称交互),能通过连接消息和框架元件边界,建立模型(如图 2 所见到)。
对于序列图,图的标签由文字“sd”开始。
当使用一个框架元件封闭一个图时,图的标签需要按照以下的格式:图类型图名称。
UML 规范给图类型提供特定的文本值。
(举例来说,sd代表序列图,activity代表活动图,use case代表用例图)。
二、UML中的序列图:序列图主要用于按照交互发生的一系列顺序,显示对象之间的这些交互。
在项目的需求阶段,分析师能通过提供一个更加正式层次的表达,把用例带入下一层次。
那种情况下,用例常常被细化为一个或者更多的序列图。
序列图的主要用途之一,是把用例表达的需求,转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外,它们还能用来记录一个存在系统(称它为“遗产”)的对象现在如何交互。
序列图的主要目的是定义事件序列,产生一些希望的输出。
重点不是消息本身,而是消息产生的顺序;不过,大多数序列图会表示一个系统的对象之间传递的什么消息,以及它们发生的顺序。
图按照水平和垂直的维度传递信息:垂直维度从上而下表示消息/调用发生的时间序列,而且水平维度从左到右表示消息发送到的对象实例。
1.生命线:生命线画作一个方格,一条虚线从上而下,通过底部边界的中心(图3)。
生命线名字放置在方格里。
UML 的生命线命名标准按照如下格式: 实体名:类名生命线名称带下划线。
当使用下划线时,意味着序列图中的生命线代表一个类的特定实体,不是特定种类的实体(例如,角色)。
序列图的实例名称有下划线,而角色名称没有。
一个生命线能用来表现一个匿名的或未命名的实体。
当在一个序列图上,为一个未命名的实例建模时,生命线的名字采用和一个命名实例相同的模式;但是生命线名字的位置留下空白,而不是提供一个例图名字。
2.消息体:为了显示一个对象(例如,生命线)传递一个消息给另外一个对象,你画一条线指向接收对象,包括一个实心箭头(如果是一个同步调用操作)或一个棍形箭头(如果是一个异步讯号)。
消息/方法名字放置在带箭头的线上面。
正在被传递给接收对象的消息,表示接收对象的类实现的一个操作/方法。
返回消息是可选择的;一个返回消息画作一个带开放箭头的虚线,向后指向来源的生命线,在这条虚线上面,你放置操作的返回值。
为了要画一个调用本身的对象,如你平时所作的,画一条消息,但是不是连接它到另外的一个对象,而是你把消息连接回对象本身。
三、UML中的约束:约束的符号很简单;格式是: 【Boolean Test】四、UML中的新元素-组合碎片(变体方案、选择项、循环):一个组合碎片用来把一套消息组合在一起,在一个序列图中显示条件分支。
1.变体:试卷,计算机走向,据去年进行高中语文,语文试卷,计算机一项调查显示,%高变体用来指明在两个或更多的消息序列之间的、互斥的选择。
一个变体的组合碎片元件使用框架来画。
单词“alt”放置在框架的namebox里。
然后较大的长方形分为 UML 2 所称的操作元。
操作元被虚线分开。
每个操作元有一个约束进行测试,而这个约束被放置在生命线顶端的操作元的左上部。
如果操作元的约束等于“true”,然后那个操作元是要执行的操作元。
识。
3.使学生主动参加收集数据、整理数据等统计活动,体会统计是图 8作为一个变体的组合碎片如何阅读的例子,显示序列从顶部开始,即bank对象获取支票金额和帐户结余。
此时,序列图中的变体组合碎片接管。
因为约束“[balance >= amount]”,如果余额超过或等于金额,然后顺序进行bank对象传递 addDebitTransaction 和storePhotoOfCheck 消息给account对象。
然而,如果余额不是超过或等于金额,然后顺序的过程就是bank传递addInsuffientFundFee 和 noteReturnedCheck 消息给account对象,returnCheck 消息给它自身。
因为“else”约束,当余额不大于或者等于金额时,第二个序列被调用。
在变体的组合碎片中,不需要“else”约束;而如果一个操作元,在它上面没有一个明确的约束,那么将假定“else”约束。
文试卷,计算机,现在这个样子!为什么每一个中国人都在活着,因为每一个人2.选择项:一个选择项用来为简单的“if then”表达式建模。
(例如,如果架上的圈饼少于五个,那么另外做两打圈饼)。
选择项组合碎片符号与变体组合碎片类似,除了它只有一个操作元并且永不能有“else”约束以外(它就是如此,没有理由)。
要画选择项组合,你画一个框架。
文字“opt”是被放置在框架的 namebox 里的文本,在框架的内容区,选择项的约束被放置在生命线顶端上的左上角。
然后选择项的消息序列被放在框架的内容区的其余位置内。