文档库 最新最全的文档下载
当前位置:文档库 › 软件工程复习总结

软件工程复习总结

《软件工程》期末复习

第一章软件工程概述

软件:软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据,加上描述程序的操作和使用的文档。

可见,软件的定义由三部分组成:

(1)在运行中能提供所希望的功能和性能的指令集(即程序);

(2)使程序能够正确运行的数据结构;

(3)描述程序研制过程、方法所用的文挡。

软件是一种产品,同时又是开发和运行产品的载体。作为一种产品,它表达了由计算机硬件体现的计算潜能。作为开发运行产品的载体,软件是计算机工作的基础、信息通信的基础,也是创建和控制其他程序的基础。

软件的特征:(1)软件是一种逻辑实体,而不是具体的物理实体,因而它具有抽象性。(2)软件是通过人们的智力活动,把知识与技术转化成信息的一种产品,是在研制、开发中被创造出来的。(3)软件成为产品后,其生产只是简单的拷贝,不同于硬件制造。(4)在软件的运行和使用期间,没有硬件那样的机械磨损、老化问题,但维护过程比硬件复杂的多,甚至会引发新的错误。

软件危机:指的是软件开发和维护过程中遇到的一系列严重问题。

出现软件危机的原因:

(1)软件维护费用急剧上升,直接威胁计算机应用的扩大。

(2)软件生产技术进步缓慢,大大落后于需求的增长,进一步加剧了软件危机。

软件工程:是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

程序设计方法的两次飞跃:

(1)结构化程序设计的出现,程序设计风格从“追求技巧与效率”;变为“清

晰第一、效率第二”;

(2)从结构化程序设计到面向对象的程序设计。

面向过程的程序设计思想:程序=数据结构+算法;

面向对象的程序设计思想:程序=对象+消息。

软件生存周期:一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。软件生存周期一般可分为以下阶段:

1.问题定义:项目策划

2.可行性研究:有没有解决的方法

3.需求分析:目标系统做什么

4.总体(概要)设计:应该怎样实现目标系统

5.详细设计:实现细节设计

6.编码与单元测试:实现

7.综合测试:找错误

8.软件维护:持久地满足用户需要

软件生存期也可以分为三个大的阶段:定义阶段、开发阶段和维护阶段。

软件开发模型:软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的结构框架。

-为软件项目的管理提供里程碑和进度表

-为软件开发提供原则和方法

瀑布模型即生存周期模型,由B.M.Boehm提出,是软件工程的基础模型。其核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作。采用结构化的分析与设计方法,将逻辑实现与物理实现分开。在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。

瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛

弃,其主要问题在于:

(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;

(2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;

(3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

快速原型模型的主要做法是:

快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。

通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。

增量模型

又称演化模型。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:(1)由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

(2)在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改,从而是软件过程的控制失去整体性。

在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

螺旋模型将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:(1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

(2)风险分析:分析评估所选方案,考虑如何识别和消除风险;

(3)实施工程:实施软件开发和验证;

(4)客户评估:评价开发工作,提出修正建议,制定下一步计划。

螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。但是,螺旋模型也有一定的限制条件,具体如下:

(1)螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。

(2)如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。

(3)软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

各种模型的优点和缺点

瀑布模型文档驱动系统可能不满足客户的需求

快速原型模型关注满足客户需求可能导致系统设计差、效率低,难于维护增量模型开发早期反馈及时,易于维护需要开放式体系结构,可能会设计差、效率低

螺旋模型风险驱动风险分析人员需要有经验且经过充分训练

第二章可行性研究

可行性研究是压缩简化了的系统分析和设计的过程,也就是说在较高层次上以较抽象的方式进行设计的过程。

可行性研究的任务:不是解决问题,而是确定问题是否可解和是否值得解

可行性的主要方面:

(1)技术可行性:在现有的资源条件下,技术风险有多大,项目是否能实现。要考虑的情况包括:

①开发的风险

②资源的有效性

③技术方案可行性

(2)经济可行性:进行开发成本的估算以及了解取得效益的评估,确定要开发的项目是否值得投资开发。要考虑的情况包括:

①成本——效益分析

②公司长期经营策略

③开发所需的成本和资源

④潜在的市场前景

(3)社会可行性

研究要开发的项目是否存在任何侵犯、妨碍等责任问题,要开发项目的运行方式在用户组织内是否行得通,现有的管理制度、人员素质和操作方式是否可行。包括合同、责任、侵权、用户组织的管理模式及规范,其他技术人员常常不了解的陷阱等。

系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序,文档,数据库,人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程,因此尽管系统流程图的某些符号和程序流程图的符号形式相同,但是它却是物理数据流图而不是程序流程图。了解一下基本符号和画法。

系统流程图实例——库存处理

结构化的分析方法:结构化分析方法是面向数据流进行需求分析的方法。结构化分析方法使用数据流图DFD与数据字典DD来描述,面向数据流问题的需求分析适合于数据处理类型软件的需求描述。其核心思想是分解化简问题,将物理与逻辑表示分开,对系统进行数据与逻辑的抽象。具体来说,结构化分析方法就是用抽象模型的概念,按照软件内部数据传递、变换的关系,

自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止。概括一下,结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

DFD、DD:这是早期结构化分析模型的基本组成部分;

E-R图:适应于描述具有复杂数据结构的软件数据模型;

数据流图:

是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件,它只是描绘数据在软件中流动和被处理的逻辑过程。

符号,画法:

如练习:

银行计算机储蓄系统的工作过程大致如下:储户填写的存款单或取款单由业务员键入系统,如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息,并印出存单给储户;如果是取款而且存款时留有密码,则系统首先核对储户密码,若密码正确或存款时未留密码,则系统计算利息并印出利息清单给储户。

数据字典:

作用:对软件中的每个数据规定一个定义条目,以保持数据在系统中的一致性。

出现在软件中的数据,可分为3种情况:

(1)只含一个数据的数据项(或数据元素);

(2)由多个数据项组成的数据流;

(3)数据文件或数据库。

加工说明:是对DFD中每个加工所作的说明。由输入数据、加工逻辑或输出数据等部分组成。加工说明通常用结构化语言、判定表或判定树作为描述工具。需要注意的是:加工说明的作用是说明“做什么”,而不是“怎么做”。

第三章需求分析

需求分析的任务:它的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析所要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其它系统元素的接口细节,定义软件的其它有效性需求。需求分析的任务不是确定系统如何完成它的工作,而是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

一般说来,需求分析阶段的任务及工作:

1、确定对系统的综合要求

⑴功能要求:系统必须做什么?

⑵性能要求:做得怎样?

例:响应时间,安全性等

⑶运行要求:运行环境、软硬件配臵等。

⑷未来可能的扩充要求

(5) 可靠性和可用性需求

(6) 出错处理与安全需求

(7) 接口需求

(8) 约束因素等

2、分析系统的数据要求

⑴建立概念模型: E-R Diagram

⑵形象描绘数据结构:

⑶数据结构规范化

3、导出逻辑模型:抽取其“做什么”的本质

4、修正计划:重估成本、进度等

5、开发原型系统以检验方案的正确性及系统是否满足需求

需求分析的原则:其基本原则可概括为: (1)必须能够表达和理解问题的数据域和功能域;(2)按自顶向下、逐层分解问题;(3)要给出系统的逻辑视图和物理视图。

常用的工具及方法:

ER图和数据规范化

(同数据库课程的设计)

第四章概要设计

软件设计的任务:把分析阶段产生的软件需求说明转换为用适当方法表示的软件设计文档。不管采用何种软件设计方法,软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计等内容。

软件设计任务从工程管理的角度来看,软件设计任务分两个阶段完成:第一个阶段是概要设计(总体设计),包括结构设计和接口设计,并编写概要设计文档;

第二个阶段是详细设计阶段,其任务是确定各个软件组件的数据结构和操作,产生描述个软件组件的详细设计文档。

结构化设计方法:是一种面向数据流的设计方法,中心任务就是把用DFD图表示

的系统分析模型转换为软件结构的设计模型,确定软件的体系结构与接口。

数据流的类型:

面向数据流的设计方法把信息流映射成软件结构,信息流的类型决定了映射的方法。信息流有下述两种类型:变换流和事务流。

信息沿输入通路进入系统,同时由外部形式变换成内部形式,进入系统的信息通过变换中心,经加工处理以后再沿输出通路变换成外部形式离开软件系统。当数据流图具有这些特征时,这种信息流称为变换流。

数据沿输入通路到达一个处理,这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这类数据流应该划为一类特殊的数据流,称为事务流。

结构化分析方法:

模块:是一个拥有明确定义的输入、输出和特征的程序实体。模块的所有输入都是实现功能必不可少的,所有输出都有动作产生。

模块化:就是把程序划分成若干个模块,每个模块具有一个子功能,把这些模块集总起来组成一个整体,可以完成指定的功能,实现问题的要求。

模块化设计:把大型软件按照规定的原则划分成一个个较小的、相对独立但又相互关联的模块。分解和模块独立性,是实现模块化设计的重要指导思想。

抽象:就是抽出事物的本质特性而暂时不考虑它们的细节。

信息隐藏:模块中所包括的信息不允许其它不需要这些信息的模块调用。

模块独立性:是软件系统中每个模块只涉及软件要求的具体子功能,而和软件系统中其他的模块接口是简单的。模块独立的概念是模块化、抽象、信息隐藏等概念的直接结果。独立性从两个方面来衡量:即模块本身的内聚和模块之间的耦合。

内聚:标志一个模块内各个元素彼此结合的紧密程度。按照从弱到强的顺序,分为:偶然性内聚、逻辑性内聚、时间性内聚、过程性内聚、通信性内聚、顺序性内聚、功能性内聚。

耦合:是对一个软件结构内各个模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度,调用模块的方式,以及通过接口的信息。按照从弱到强的顺

序,分为:非直接耦合、数据耦合、特征耦合、控制耦合、外部耦合、公共耦合、内容耦合。

深度

表示软件结构中控制的层数,它往往能粗略地标志一个系统的大小和复杂程度。深度和程序长度之间应该有粗略的对应关系,当然这个对应关系是在一定范围内变化的。如果层数过多则应该考虑是否有许多管理模块过分简单了,能否适当合并。

宽度是软件结构内同一个层次上的模块总数的最大值。一般说来,宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。

扇出

是一个模块直接控制(调用)的模块数目,扇出过大意味着模块过于复杂,需要控制和协调过多的下级模块;扇出过小(例如总是1)也不好。经验表明,一个设计得好的典型系统的平均扇出通常是3或4(扇出的上限通常是5~9)。扇出太大一般是因为缺乏中间层次,应该适当增加中间层次的控制模块。扇出太小时可以把下级模块进一步分解成若干个子功能模块,或者合并到它的上级模块中去。当然分解模块或合并模块必须符合问题结构,不能违背模块独立原则。

一个模块的扇入

表明有多少个上级模块直接调用它,扇入越大则共享该模块的上级模块数目越多,这是有好处的,但是,不能违背模块独立原理单纯追求高扇入。

软件设计的基本原理:

(1)模块化

(2)抽象

(3)信息隐蔽

(4)模块独立性

软件设计的基本经验:

模块独立性,低耦合,高内聚,公共模块。

第五章详细设计

为每一个模块确定使用的算法和数据结构:

⑴确定模块内算法,用某种工具来表达

⑵确定模块内的数据结构

⑶确定模块间的接口细节

⑷为每个模块设计测试

主要是过程设计和模块设计

结构设计的优化规则:

(1)对模块分割、合并和变动调用关系的指导规则:以提高模块独立性为首要标准,除此之外,适当考虑模块的大小。

(2)保持高扇入/低扇出原则。

(3)作用域/控制域规则:

1、作用域不要超出控制域的范围;

2、软件系统的判定,其位臵离受它控制的模块越近越好。

过程设计的原则与方法:

(1)清晰第一的设计风格,可读性:大多数情况下,应该优先考虑程序的清晰度,把效率的考虑放在第二位。(除开少数使用特别频繁,或者

实时程序)

(2)结构化的控制结构:所有的模块都只使用单入口单出口的3种基本控制结构—顺序、选择和循环。

(3)GOTO语句不应滥用,但也不必完全禁止。

(4)逐步细化的实现方法。

过程设计中常用的表达工具:程序流程图(PFC)、N-S图、PAD图,PDL语言,判定表和判定树;

程序流程图:程序流程图又称之为程序框图,它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言,比较直观和清晰地描述过

程的控制流程,易于学习掌握。在流程图中只能使用下述的五种基本控制结构。①顺序型;②选择型;③ while型循环;④ until型循环;⑤多情况型选择。

N-S图:Nassi和Shneiderman提出了一种符合结构化程序设计原则的图形描述工具,称为盒图,又称为N-S图。在N-S图中,为了表示五种基本控制结构,规定了五种图形构件。①顺序型;②选择型;③ WHILE重复型;④UNTIL重复型;⑤多分支选择型。

PAD图,日立公司采用的一种图形。

PDL伪代码的特点;

要求:能熟练使用这几种表达工具表示模块的逻辑过程,并能相互转换。

判定表和判定树:

当算法中包含多重嵌套的条件选择时,用程序流程图、盒图、PAD图或 PDL 都不易清楚地描述。然而判定表和判定树却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

环形复杂度:

对于简单逻辑的PDL,程序流程图及其他图形表示的算法,求出它的环形复杂度。(之前忘记了)

第六章实现-编码

编码的目的:使用选定的程序设计语言,把模块的过程性描述翻译为用该语言书写的源程序(或源代码)。程序的质量主要是由设计的质量决定的。但是,编码的风格和使用的语言,对编码的质量也有重要的影响。

编码的风格:

(1)使用标准的控制结构

(2)避免使用容易引起混淆的结构和语句:

1、模糊的“then-if”结构

2、冗余的空“then”语句和空“else”语句

3、费解的深层嵌套结构

(3)有限制地使用GOTO语句

(4)实现源程序的文档化

(5)注意输入输出风格

要求能根据程序源代码对代码的可读性做出分析、比较和判断。

第七章实现——测试

测试与调试:测试是为了发现程序中的错误而执行程序的过程。具体地说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计出一批测试用例,并利用测试用例来运行程序,以发现程序错误的过程。

调试通过定位和纠正错误,消除软件故障,保证程序的可靠运行。

测试的种类:按照测试过程是否在实际应用环境中来分,有静态分析与动态测试。

静态分析技术:不执行被测软件,可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。一般用人工方式脱机完成,称为人工测试或代码评审;也可借助静态分析器自动完成。

动态测试:执行被测软件。

测试方法:

黑盒测试法,根据程序的功能来设计测试用例;

白盒测试法,根据被测程序的内部结构设计测试用例。通常的做法是,用黑

盒法设计基本的测试方案,再用白盒法补充一些方案。

测试用例的设计是软件测试的中心内容。测试一个程序要使用多个测试用例,而每一个测试用例都应包括一组测试数据和一个相应的预期的测试结果。

黑盒测试法中的3种常用技术:等价划分(等价分类)法、边界值分析法、错误推测(猜测)法。要求能熟练运用等价划分和边界分析方法设计测试用例。

白盒测试法:常用逻辑覆盖测试和路径测试法。

逻辑覆盖测试法:基于流程图或其他算法描述工具来设计测试用例,考察的重点是图中的判断框。按差错能力由弱到强分为5种覆盖标准:语句覆盖---每条语句至少执行一次;判定覆盖---每一判定的每个分支至少执行一次;条件覆盖---每一判定中的每个条件,分别按“真”、“假”至少各执行一次;判定/条件覆盖---同时满足判定覆盖和条件覆盖的要求;条件组合覆盖---求出判定中所有条件的各种可能组合值,每一可能的条件组合至少执行一次。要求能根据题目要求的覆盖条件设计测试用例。

测试的步骤:

1.单元测试

又称模块测试。每个程序模块完成一个相对独立的子功能,所以可以对该模块进行单独的测试。由于每个模块都有清晰定义的功能,所以通常比较容易设计相应的测试方案,以检验每个模块的正确性。

2.集成测试

在单元测试完成后,要考虑将模块集成为系统的过程中可能出现的问题,例如,模块之间的通信和协调问题,所以在单元测试结束之后还要进行集成测试。这个步骤着重测试模块间的接口,子功能的组合是否达到了预期要求的功能,全程数据结构是否有问题等。

3.有效性测试

集成测试通过后,应在用户的参与下进行有效性测试。这个时候往往使用实际数据进行测试,从而验证系统是否能满足用户的实际需要。

4.系统测试

系统测试是把通过有效性测试的软件,作为基于计算机系统的一个整体元素,与整个系统的其他元素结合起来,在实际运行环境下,对计算机系统进行一系列的集成测试和有效性测试。

5. 平行运行

为了降低风险,进行试运行

测试驱动模块:在单元测试中,代替被测模块上级模块的测试软件。

测试桩模块:在单元测试中,代替被测模块下级模块的测试软件。

集成测试的策略:自顶向下、由底向上和从两头逼近的混合方式。

根据实际需要设计测试用例:白盒,方法,达到什么样的标准,黑盒的设计方法,边界,等价类划分;见练习题目

软件可靠性的定义

软件可靠性是程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

第八章软件维护

软件维护:软件运行阶段对软件产品所进行的修改就是维护。

软件维护的种类:以加强软件功能为目标的完善性维护;为了适应运行环境变化而进行的适应性维护;纠正软件遗留错误的调试性维护和为改进软件的可维护性、减小将来的维护工作量而进行的预防性维护。

软件可维护性:衡量软件维护容易程度的一种软件属性。

定性的说,可维护性取决于软件的下列属性:可理解性、可修改性与可测试性。

软件配臵:软件在生存周期内,它的各种形式、各种版本的文档与程序的总称。

软件再工程:运用逆向工程、重构等技术,在充分理解原有软件的基础上,进行分解、综合,并重新构建软件,用以提高软件的可理解性、可维护性、可复用性或演化性。

软件工程中---面向对象部分

1. UML图

为了对系统进行可视化,可以从不同的角度画图。

在理论上,图可以包含任何事物及其关系的组合。

在UML中包含9类图:

①类图(class diagram)

②对象图(object diagram)

③用例图(use case diagram)

④顺序图(sequence diagram)

⑤协作图(collaboration diagram)

⑥状态图(statechart diagram)

⑦活动图(activity diagram)

⑧组件图(component diagram)

⑨部署图(deployment diagram)

2. 如何使用UML对需求建模呢?

我们可以使用用例(use case)作为着手进行需求建模的良好起点。用例按照系统的使用方式组织系统。以用例为起点进行需求建模,可以使我们的关注焦点集中于客户身上。

用例图是显示一组用例、参与者以及它们之间关系的图。

用例图包括以下三方面的内容。

1.参与者。

2.用例。

3.依赖、泛化和关联关系。

用例之间的关系:

?下图显示了用例间的包含关系。在图书管理系统中,用例“删除书籍”

和“修改书籍信息”与用例“图书查询”之间是一种包含关系。不管是删除书籍还是修改书籍信息,都必须先进行该书籍的查询工作。

3. 什么是活动图?其用途是什么?基本要素?

在用例模型中,可以利用文本来描述用例的业务流程,但如果业务流程较为复杂的话,则可能会难以阅读和理解,这时需要用更加容易理解的方式(图形)来描述业务过程的工作流,在UML中将这类描述活动流程的图形称为活动图(Activity Diagram)。

活动指一个状态机中进行的非原子的执行单元,它由一系列的可执行的原子计算组成,这些原子计算会导致系统状态的改变或返回一个值。

状态机是展示状态与状态转换的图。

状态机有两种可视化的建模方式。分别为活动图和状态图。

活动图可以用作以下目的:

(1)描述一个操作执行过程中所完成的工作(动作),这是活动图最常见的用途。

(2)描述对象内部的工作。

(3)显示如何执行一组相关的动作,以及这些动作如何影响它们周围的对象。

(4)显示用例的实例如何执行动作以及如何改变对象状态。

(5)说明一次业务流程中的人(参与者)和对象是如何工作的。

活动图中的基本要素包括状态、转移、分支、分叉和汇合、泳道、对象流等。

4. 什么是状态图?其用途是什么?

状态图(Statechart Diagram)是UML中对系统的动态方面进行建模的五种图之一。状态图显示了状态机。活动图是状态图的一个特例,状态图中的多数状

相关文档
相关文档 最新文档