《软件工程》自考02333重点难点汇集

上传人:y****n 文档编号:137994632 上传时间:2022-08-19 格式:DOC 页数:64 大小:2.89MB
收藏 版权申诉 举报 下载
《软件工程》自考02333重点难点汇集_第1页
第1页 / 共64页
《软件工程》自考02333重点难点汇集_第2页
第2页 / 共64页
《软件工程》自考02333重点难点汇集_第3页
第3页 / 共64页
资源描述:

《《软件工程》自考02333重点难点汇集》由会员分享,可在线阅读,更多相关《《软件工程》自考02333重点难点汇集(64页珍藏版)》请在装配图网上搜索。

1、软件工程串讲讲义 应考指导一、课程介绍1、课程性质软件工程是全国高等教育自学考试计算机及应用(独立本科段)的一门专业课。 软件工程是研究软件开发的一门课程,其主要内容包括:软件开发所需要的过程、活动和任务,以及这些活动和任务的组织、实施和管理。2、指定教材本课程指定教材为软件工程,全国高等教育自学考试指导委员会组编,王立福主编,机械工业出版社出版,2011年版。新版教材与2000年版相比,无论是内容还是内容的组织,都有了很大的变化。整个知识体系、章节安排、内容选取都不一样,这是考生一定要注意的。新版教材的内容组织特点主要体现在:基于对软件开发本质的认识,讲解软件工程的两大技术问题:一是开发逻辑

2、,二是开发途径。开发逻辑涉及软件生存周期过程、软件生存周期模型(有关过程、活动和任务的组织框架)以及项目软件生存周期的规划与监控。开发途径涉及结构化方法和面向对象方法,以及支持软件评估所需要的软件测试技术等。3、章节体系本课程共有8章:第1章:回答什么是软件开发的本质第2章:软件需求与软件需求规约第3章:结构化方法第4章:面向对象方法-UML第5章:面向对象方法-RUP第6章:软件测试。第7章:软件生存周期过程及管理第8章:集成化能力成熟度模型CMMI二、考情分析1. 历年真题的分布情况由于教材刚刚经过改版,新教材刚经过2011年10月、2012年01月、2012年10月三次考试。 通过对20

3、11年10月、2012年01月这两次真题的分析,各章所占分值的分布情况如下表所示: 年 份章名、题型2011-102012-01一、绪论(单项、填空题)3分3分二、软件需求与软件需求规约911三、结构化方法(单、填、简答、综合)25分25分四、面向对象方法-UML(单、填、简答)11分11分五、面向对象方法-RUP(单、填、简答)12分12分六、软件测试(单、填、简答、综合)25分23分七、软件生存周期过程及管理(单、填、简)10分10分八、集成化能力成熟度模型CMMI55从上面的统计数据可以看出:主要的分值分布在第3章和第6章,分别占到总分的25%左右。第1章和第8章的考核知识点相对较少。2

4、. 题型分析本课程的考试题型分为:(1) 单项选择题,共15小题,每小题2分,共30分(2) 填空题,共20个空,每空1分,共20分(3) 简答题,共6小题,每小题5分,共30分(4) 综合应用题,共2题,每题10分,共20分3. 复习方法(1)以教学大纲为准绳。自学考试的原则是:考试范围既不超出大纲又不超出教材范围。所以考生一定根据教学大纲规定的考试内容和考核要求,认真学习教材,要全面、系统了解教材中的基本概念、基本知识。(2)有的放矢。在学习的过程中,为了达到“事半功倍”,要学会“舍”。要用有限的时间去抓重点,对重点内容要进行深入细致的学习。(3)注意学习方法,理论联系实际,注重理解重视理

5、论联系实际,训练并逐渐提高运用所学理论分析和解决实际案例的能力。考生应当注意在全面系统学习教材的基础上,尽可能多地了解和分析实际案例,以便更深刻地领会教材的内容,提高分析和解决实际问题的能力。(4)合理安排时间,抓住学习重点根据实际情况自己安排,利用平时空余时间观看网络课件,形成基本的了解。接下来认真地做一些练习题,不清楚的地方再回过头去看看书,并注意对不同的知识点进行比较,加深印象。第一章 绪论复习建议:本章内容较少,主要是让大家了解软件工程的提出的背景-软件危机以及软件工程研究的内容。考试题目类型主要是单项选择题、填空题,题量在3%5%之间。第一节 软件工程概念的提出与发展1. 软件危机(

6、1) 速度:软件的发展水平远远滞后于硬件的发展水平,生产率低下,软件制造仍然是一种人工集约生产方式(2) 质量:软件的质量低下,不能满足用户的需求、适应性差(3) 成本:软件开发成本居高不下软件开发的速度、软件制品的质量、软件开发成本是软件工程的三个核心问题。2. 软件工程的发展(1)20世纪6080年代瀑布模型;过程化语言;支持工具(2)20世纪80年代今软件复用技术;软件生产管理;面向对象语言(3)近几年软件复用技术:构件技术、平台技术、需求工程技术、领域分析技术、应用集成技术等。第二节 软件开发的本质1. 软件软件=程序+文档2. 软件开发的本质:“映射”,即实现问题空间的概念和处理逻辑

7、到解空间的概念和处理逻辑之间的映射。3. 系统建模运用所掌握的知识,通过抽象,给出系统的一个结构。4. 模型模型是一个抽象。模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述,通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述。5. 系统模型的类型(1) 概念模型:描述软件是什么(2) 软件模型:实现概念模型的软件解决方案。包括设计模型、实现模型和部署模型。第二章 需求获取复习建议:正确定义问题,是解决问题的基础。需求获取是软件开发的第一步,它的工作质量决定了整个软件开发工作的成败,因此本章的内容是考核的重点内容。考核的题目类型主要有:单项选择题、填空题、简答题,

8、分值在10%左右。内容以基本概念、基本原理为主。第一节 需求与需求获取1. 需求的定义一个需求是有关一个“要予构造”的陈述,描述了待开发产品/系统功能能力、性能参数或其它性质。2. 需求的基本性质(1) 必要的(2) 无歧义的(3) 可测的(4) 可跟踪的(5) 可测量的3. 需求的分类 (1) 功能需求,是整个需求的主体。(2) 非功能需求:性能需求、外部接口需求、设计约束和质量属性需求。能够区分哪些是功能需求,哪些是性能需求。4. 接口需求的类别(1) 用户接口(2) 硬件接口(3) 软件接口(4) 通信接口(5) 内存约束(6) 运行(7) 地点需求5. 设计约束需求(1) 法规政策(2

9、) 硬件限制(3) 与其它应用的接口(4) 并发操作(5) 审计能力(6) 控制功能(7) 高级语言要求(8) 握手协议(9) 应用的关键程度(10) 安全和保密6. 质量属性(1) 可靠性(2) 存活性(3) 可维护性(4) 用户友好性7. 需求发现的技术(1) 自悟(2) 交谈(3) 观察(4) 小组会(5) 提炼第二节 需求规约(SRS)1. 需求规约的定义 是一个软件/产品/系统所有需求陈述的正式文档,它表达了一个软件/产品/系统的概念模型。2. 需求规约的基本性质 (1) 重要性和稳定性程度:对需求进行分级(2) 可修改的(3) 完整的:没有被遗漏的需求(4) 一致的:不存在互斥的需

10、求3. 需求规约的格式IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。4. 需求规约(规格说明书)的表达(1) 非形式化的需求规约(2) 半形式化的需求规约(3) 形式化的需求规约5. 需求规约的作用 (1) 需求规约是软件开发组织和用户之间一份事实上的技术合同书,是产品功能及其环境的体现(2) 需求规约是一个管理控制点(3) 对于产品/系统的而设计,需求规约是一个正式的、受控的起始点(4) 需求规约是创建产品验收计划和用户指南的基础第三章 结构化方法复习建议:自顶向下,逐步求精。本章是整个课程的重点内容,其基本思想、基本原理和基本方法是软件工程理论体系中最经典的内

11、容,考核题型涉及单项选择题、填空题、简答题、综合应用题所有题目类型,占分值25%左右。建议考生在牢记基本概念、基本原理的基础上,对综合应用题多下工夫,多做练习。第一节 结构化需求分析1. 需求分析面临的挑战(1) 问题空间理解(2) 人与人之间的通信,“有效沟通”(3) 需求的变化性2. 结构化分析中的基本术语及表示方法(1) 数据流 (2) 加工(3) 数据存储(4) 数据源和数据潭3. 数据流图DFD图 用于建立系统功能模型。是一种描述数据变换的图形化工具,其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。4. 建模过程(绘制流程图的过程)自顶向下、功能分解(1) 建立系统环境

12、图(2) 0层图:从0层图开始对流程图中的要素编号(3) 1层图(4) 【例题】绘制数据流程图(2008年10月真题)41.某个学生成绩管理系统的部分功能如下:(1)基本信息管理:教务管理人员输入或修改学期教学执行计划、学生名单和教师名单;(2)学生选课:学生根据教学执行计划进行选课;(3)分配任课教师:教务管理人员为符合开课条件的课程分配教师,并打印任课通知单给教师;(4)成绩管理:每门课程的教师在考试评分结束后将考试成绩交给教务管理人员,教务管理人员输入、维护成绩,系统可生成成绩单(发给学生)、成绩统计分析表(发给教务管理人员)。请根据要求画出该问题的分层数据流图(要求画出顶层和0层数据流

13、图)。【解析】顶层图:只包含数据源/数据潭以及相关的数据流和一个处理。成绩单学生成绩成绩管理系统学生教师选课信息任课通知单成绩单顶层图任课通知单教师学生成绩单成绩录入选课信息任课安排学生选课基本信息处理 学期教学执行计划 学生名单 学生选课结果 教师信息0层图要注意的问题: 黑洞(black hole),即只有输入而没有输出。只有输出而没有输入。灰洞(gray hole),即输入不足以产生输出。灰洞是经常也是不易被察觉的错误。加工处理只用来表示数据的处理和变化,避免将计算机命令作为处理。数据流必须起于且/或止于处理,即每一个数据流必须有一个处理与之有关,数据流不能起于数据存贮且止于一个数据源/

14、数据潭或另一个数据存贮;也不能起于某个实体且止于另一个数据源/数据潭或数据存贮。5. 数据字典定义数据流程图中所有数据流和数据存储的数据结构。顺序结构:+选择结构:|重复结构: 子界:m.n6. 加工的描述 (1) 判定表判断表(Decision Table)也称为决策表,是一个二维表,它说明了每一种条件组合所产生的结果。该表分为四个象限(quadrants)。a) 左上限代表所有的条件b) 左下限代表可能的结果c) 右上限代表每一种条件的取值(用Y和N来表示)d) 右下限用X表示所对应的条件组合所产生的结果【例题】画出顾客购货的折扣政策的决策表。 销售商在给顾客的折扣时,要考虑付款日期和交易

15、额这两个因素。若付款日期在10天以内(含10天),则当交易额超过¥10,000时,给予5的折扣;当交易额在¥5,000到¥10,000之间(含¥5,000)时,给予3的折扣;当交易额低于¥5,000时,没有折扣。若付款日期超过10天,则无论交易额多少,均不给任何折扣。【解析】(2) 判定树判断树 (Decision Tree)也称为决策树,是用来描述在一组不同的条件下,决策的行动是根据不同条件及其取值来选择的处理过程。业务规则的描述通常可以使用判断树这一过程描述工具。【例题】画出顾客购货的折扣政策的决策树。 销售商在给顾客的折扣时,要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含1

16、0天),则当交易额超过¥10,000时,给予5的折扣;当交易额在¥5,000到¥10,000之间(含¥5,000)时,给予3的折扣;当交易额低于¥5,000时,没有折扣。若付款日期超过10天,则无论交易额多少,均不给任何折扣。解析:(3) 结构化语言【例题】用结构化语言表达:顾客购货的折扣政策。销售商在给顾客的折扣时,要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天),则当交易额超过¥10,000时,给予3的折扣;当交易额在¥5,000到¥10,000之间(含¥5,000)时,给予2的折扣;当交易额低于¥5,000时,没有折扣。若付款日期超过10天,则无论交易额多少,均不给任

17、何折扣。IF 付款日期在10日以上 折扣=0ELSE IF 交易额=10000 折扣=3% ELSE IF交易额=5000 折扣=2% ELSE 折扣=07. 需求验证(1) 验证每一个需求满足5个性质(2) 验证需求规格说明书满足4个性质第二节 结构化设计分为总体设计和详细设计1. 总体设计的任务把系统的功能需求分配到一个特定的软件体系结构中。2. 表达软件体系结构的工具(1)模块结构图(2)层次图(3)HIPO图3. 模块结构图 结构图(Structure Chart)是对软件总体结构的一种图形描述,它显示了软件的层次结构、组织和通讯。也就是说,在结构图中,显示了软件是由哪些模块组成的,这

18、些模块按照什么样的层次结构组织在一起以及模块之间通过什么接口联系在一起。结构图也称之为控制结构图、模块结构图或系统结构图。(1) 模块符号(2) 模块调用关系(3) 模块间的数据传递(4) 模块间的控制信息传递(5) 循环调用结构(6) 选择调用结构(7) 数据存储4. 层次图层次图中一个矩形框代表一个模块,框间的连线表示调用关系(位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块)。5. HIPO图HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了使HIPO图具有可追踪性,在H图(即层次图)里除了顶层的方框之外,每个方框都加了编号。H图+IPO图6. 总

19、体设计步骤将DFD图映射为设计层面的模块及模块调用。(1) 变换流(Transform Flow)。基于变换流的数据流程图是一个线性的顺序结构,由输入臂、输出臂和变换中心三部分组成。其中变换中心使系统数据发生本质的变化,输入臂将物理输入变换成逻辑输入,而输出臂则将逻辑输出变换成物理输出。(2) 事务流(Transaction Flow)。事务流的数据流程图中有一个事务处理中心,它将输入分为许多相互平行的加工路径,然后根据输入的属性,选择某一加工路径。如下图所示。业务中心完成以下任务: 接收事务(即输入数据); 分析每个事务并确定它的类型; 根据事务的类型选取一条活动通路。【例题】控制结构图的绘

20、制根据数据计算的数据流图:输入数据数据求解打印输出画出以转换为中心的控制结构图。【解析】这是一个典型的以“转换为中心”结构的分解,可以转化为:数据计算打印输出数据求解输入数据总结:任何处理都可以划分为两种转换类型之一:以转换为中心的分解和以业务为中心结构的分解。【例题】产生固定资产资料数据流程图如下,做出以业务为中心的模块控制结构图。【解析】这是以业务为中心的处理,根据模板,可以转化为:报表制作报表调度报表类型固定资产卡片资产变动表折旧汇总表固定资产明细表7. 模块执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成:模块接口和模块体。8. 模块化“分而治之”和“抽象”。把一个待

21、开发的软件分解成若干个简单的、具有高内聚低耦合的模块,这一过程称为模块化。模块化是系统设计基本原理/原则之一。9. 内聚(Cohesion)是指一个模块内部个成分之间相互关联程度的度量。也就是说,凝聚是对模块内各处理动作组合强度的一种度量。很显然,一个模块的内聚越大越好。(1)偶然凝聚 可维护性最差 (2)逻辑凝聚(3) 时间凝聚(4)过程内聚(5)通信内聚(6)顺序凝聚(7)功能凝聚 可维护性最好 10. 模块耦合耦合(coupling)是对两个模块之间联接程度的一种度量。模块间的依赖程度越大,则其耦合程度也就越大;反之,模块间的依赖程度越小,则其耦合程度也就越小。很显然,为了使软件具有较好

22、的可维护性和可修改性,模块间的关联程度即耦合程度应越小越好。因为耦合程度越小,表明模块间的独立程度越大,这样在修改一个模块时,对其它模块的影响程度就越小,从而使模块的修改工作局限于一个最小范围之内。(1) 内容耦合(2) 公共耦合(3) 数据耦合(4) 控制耦合(5) 标记耦合原则是:尽量用数据耦合,少用控制耦合,限制公共耦合的范围,避免使用内容耦合。11. 启发式规则高内聚、低耦合。(1) 改进软件结构,提高软件独立性。模块分解(2) 模块规模适中(3) 力求深度、宽度、扇出、扇入适中。深度:表示其控制的层数。宽度:同一层次上模块总数的最大值。扇出:一个模块直接控制的下级模块的数目。扇入:有

23、多少个上级模块直接调用它。原则:顶层模块扇出比较大,中间层模块扇出较小,底层模块具有较大的扇入。(4) 尽量使模块的作用域在其控制域内。模块的控制域:这个模块本身以及所有直接或间接从属它的模块的集合。模块的作用域:受该模块内一个判断所影响的所有模块的集合。(5) 尽力降低模块接口的复杂度(6) 力求模块功能可以预测12. 详细设计具体描述模块结构图中的每一模块,即给出实现模块功能的实施机制,包括一组例程和数据结构。13. 结构化程序设计方法一种基于结构的编程方法,即采用顺序结构、选择结构和重复结构进行编程,其中每一结构只允许一个入口和一个出口。三种基本的控制结构:(a) 顺序结构,先执行A再执

24、行B;(b) IF-THEN-ELSE型选择(分支)结构;(c)DO-WHILE型循环结构14. 详细设计工具(1) 程序流程图程序流程图:程序流程图又称为程序框图,它是历史最悠久使用最广泛的描述过程设计的方法,然而它也是用得最混乱的一种方法。(2) 盒图(N-S图)出于要有一种不允许违背结构程序设计精神的图形工具的考虑,Nassi和Shneiderman提出了盒图,又称为N-S图。(a) 顺序;(b) IF-THEN-ELSE型分支;(c) CASE型多分支;(d) 循环;(e) 调用子程序A (3) PAD图PAD是问题分析图(Problem Analysis Diagram)的英文缩写,

25、自1973年由日本日立公司发明以后,已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流,将这种图翻译成程序代码比较容易。下图给出PAD图的基本符号。(4) 类程序设计语言PDLPDL也称为伪码,它是用正文形式表示数据和处理过程的设计工具。PDL具有严格的关键字外部语法,用于定义控制结构和数据结构;另一方面,PDL表示实际操作和条件的内部语法通常又是灵活自由的,以便可以适应各种工程项目的需要。因此,一般说来PDL是一种“混杂”语言,它使用一种语言(通常是某种自然语言)的词汇,同时却使用另一种语言(某种结构化的程序设计语言)的语法。可以作为注释工具直接插在源程序中间。15. 设计规约完整

26、准确地描述满足需求规约所要求的所有功能模块,以及伴随功能模块而出现的非功能机制。设计规约包括概要设计规约和详细设计规约。(1) 概要设计规约指明高层软件体系结构。 系统环境 软件模块的结构 模块描述 文件结构和全局数据文件的逻辑结构 测试需求(2) 详细设计规约 各处理过程的算法 算法所涉及的全部数据结构的描述【例题】根据下列变换型的数据流图,设计出初始软件结构图。题40图【答案】主控模块F9f5F9f5输出模块G变换模块输入模块输入A输入B变换C变换D变换E变换F【解析】这是一个典型的变换型数据流程图,将其转换为模块控制图时,第一层可以分解为三个模块:输入模块、变换模块、输出模块。每一模块还

27、可以继续分解。第四章 面向对象方法UML复习建议:以不变应万变。统一建模语言(Unified Modeling Language,UML)UML是目前流行的建模语言,特别是在网站开发中广泛应用。UML涉及很多的图,每一种图都有不同的图形符号、作用,在什么情况下用何种图来描述是本章的重点内容。考核题目类型包括单项选择题、填空题、简答题,分值在10%15%之间。需要考生掌握各种UML图的作用。面向对象建模过程的步骤:(1) 需求获取a) 建立用况(use case)模型和用况场景(2) 需求分析a) 建立活动图和状态图b) 类图(建立域模型)c) 顺序图(实现用况)(3) 编写需求规格说明书(4)

28、 需求验证第一节 UML术语表1. 对象(object)对象(object)是系统中用来描述客观事物的一个实体。一个对象由一组属性和对这组属性进行操作的一组方法组成。 对象只描述客观事物本质的与系统目标有关的特征。 对象之间通过消息通信,一个对象通过向另一个对象发送消息激活某一个功能。2. 类类(Class)是具有相同属性、操作、关系和语义的一组对象的集合,它为属于该类的全部对象提供了同一的抽象描述,其内部包括属性和服务两个主要部分。类有超类(Superclass)和子类(Subclass)之分。(相对而言)对象与类的关系犹如程序设计语言中变量和类型的关系。对象是类的实例(Instance)。

29、类在类图上使用包含三个部分的矩形来描述,如下图4-1所示。最上面的部分显示类的名称,中间部分包含类的属性,最下面的部分包含类的操作(或者说方法)。 图4-1:类图中的示例类对象3. 属性对象或类的属性(attributes)描述了对象的具体特征。属性有属性名和属性值(或称属性状态)。每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为:可见性属性名 :类型 = 缺省值性质串可见性:public(+) 、protected(#)、private(-)、包内的()4. 类的操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作名、返回类型

30、和参数表组成操作界面。UML规定操作的语法为:可见性 操作名 (参数表) : 返回类型 性质串例如:+取客户地址(客户名:字符串):字符串5. 接口接口是操作的一个集合,其中每个操作描述了类、构件或子系统的一个服务。(1) 采用具有分栏和关键字的矩形符号来表示(2) 采用小圆圈和半圆圈来表示6. 协作协作是一个交互,涉及交互的三要素:交互各方、交互方式以及交互内容。7. 用况(use case)/用况对一组动作序列的描述,系统执行这些动作应产生对特定参与者有值的、可观察的结果。8. 主动类至少具有一个进程或线程的类。能够启动系统的控制活动,并且其对象的行为通常与其它元素行为并发的。表示方法:两

31、条竖线。9. 构件系统设计中的一种模块化部件,通过外部接口隐藏了它的内部实现。10. 制品系统中包含物理信息的、可替代的物理部件。11. 节点节点是在运行时存在的物理元素,通常表示一种具有记忆能力和处理能力的计算机资源。12. 关联(Association)关联反映了类和类之间的静态关系。关联在模型中,特别是在永久业务对象模型中是最基本的关系。链(link)是对象之间具有特定语义关系的抽象。(1) 关联名(2) 导航(3) 角色(4) 可见性(5) 多重性:多重性(Multiplicity)定义了与一个对象/类相联系的对象/类出现一次,该对象/类可能出现的最小和最大的数目。(6) 限定符(7)

32、 聚合:一个类是另一类的一部分。(8) 组合:是聚合的一种特殊形式(9) 关联类(10) 约束13. 泛化/继承继承:特殊类(子类)的对象拥有其一般类(超类)的全部属性与服务,称作特殊类对一般类的继承(Inheritance) 。利用继承(inheritance),子类可以继承父类的属性和方法。子类父类也可分别叫做特殊类一般类、子类超类、派生类基类等。继承反映了类之间的一种联系或结构:一般-特殊结构,也称分类结构(Classification Structure),是由一组具有继承关系的类所组成的结构。仅由一些单继承关系的类形成的结构又称作层次结构(Hierarchy Structure);由

33、一些存在多继承关系的类形成的结构又称作网格结构(Lattice Structure)。 14. 多态性(Polymorphism)是指一般类中定义的属性或服务被特殊类继承之后,可以具有不同的数据类型或表现出不同的行为。这使得同一属性或服务名在一般类及其各个特殊类中具有不同的语义。多态是指用同一界面形式表示不同对象类中的不同实现的能力。多态性的实现基于两个基本原理:封装和泛化。多态性实现的方法:(1)泛化(2)定义一个抽象类接口类 15. 细化细化是类目之间的语义关系,其中一个类目规约了保证另一类目执行的契约。用空心三角形的虚线表示。16. 依赖依赖是一种使用关系,用于描述一个类目使用另一类目的

34、信息和服务。用有向虚线段表示。17. 包包是模型元素的一个分组,一个包本身可以被嵌套在其它包中,并且可以含有子包和其它类型的模型元素。第二节 UML的模型表达格式图形化工具。图的类别:(一)结构图(1)对象结构建模类图和对象图(2)应用结构建模包图、构件图、部署图、组合结构图(二)行为图对象交互建模顺序图、协作图(通信图、交互综述图、定时图)、状态图(状态机)对象行为建模用况图、活动图1. 类图任何系统都需要从两方面进行描述:结构信息和行为信息。系统的组成表达了系统各组成要素之间的联系,称为结构;这些组成要素的执行逻辑称为行为。在面向对象方法中,系统的结构信息是通过类图(class diagr

35、am)来描述的;而系统行为信息则通过用况图、交互图(包括顺序图和协作图)和状态图来描述的。也就是说,前者说明了系统的组成部分是什么,而后者则说明了系统做什么。类图(class diagram)表达了系统的静态结构信息,即系统是由哪些类组成的,这些类之间的关系是什么。类图显示系统各个部分以及怎样将它们组装起来;但却不能模拟组装后系统的工作情况。构造类图的三个关键问题是:(1) 系统中有哪些需要关心的类?(2) 这些类是如何描述的?(3) 这些类之间的联系是什么?创建一个系统的类图,要涉及4方面的工作:(1) 模型化待建系统中的概念,形成类图中基本元素(2)模型化待建系统中的各种关系,形成该系统的

36、初始关系。(3)模型化系统中的协作,给出该系统的最终类图。(4)模型化逻辑数据库模式2. 用况图(use case 图) 用况是对一个参与者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。用况是系统、子系统或类 与 外部的参与者(actor)交互的动作序列的说明,包括可选的动作序列和会出现异常的动作序列。用况图(Use Case Diagram)是指反映活动者,系统边界所封闭的用况,及活动者与用况之间,用况与用况之间关系的一种图。6个模型元素:(1) 主题(2) 用况(3) 参与者: 系统用户: 是最常见的一种角色。是直接使用系统的人。 另一个系统:如DSS可作为MIS的

37、一个活动者。补货系统可作为定单处理系统的活动者。 时间:当经过一定时间触发系统中的某个事件时,时间就成了角色。例如定期的某些业务处理工作。(4) 关联(5) 泛化(6) 依赖3. 状态图对象或者类的整体行为的某些规则所能适应的对象或类的状况、情况、条件、形式或生存周期。仅当对象的行为规则不同时,才称对象处于不同的状态。 在由对象的全部属性的属性值集合所构成的笛卡儿乘积中的每一个等价集合(即,使对象的服务呈现相同行为规则的属性值的集合)称之为对象的一种状态。 例如,对象发票(invoice)可以根据其付款的情况分为三个状态:未付款(unpaid)、部分付款(partly paid)以及付清款(f

38、ully paid)。状态图(state chart diagram)使用状态、事件和转换来记录对象在其生命周期中所历经的状态序列。 对象的初始状态是图中任何事件都未对该对象起作用时的状态。 状态代表对象生命周期中的某一瞬间。 转换表明作为对事件的响应结果,对象将从一种状态转换到另一种状态并执行某个动作。 触发状态转换的事件在状态转换字符串中命名。双击一个状态转换,除事件签名以外,还可用字符串为其加注临界条件、动作表达式等标签。4. 顺序图顺序图(sequence diagram)表示了对象之间传送消息的时间顺序,也就是对象之间的交互顺序,这些交互是指在场景或用况的事件流中发生的。每一个对象(

39、类)用一条生命线来表示即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。顺序图中的基本元素包括: 活动者,指用况中的活动者。 对象,指在用况中的内部对象。 生命线:在顺序图中的一个对象下面的竖线,用以显示这个对象的生命期。时间从上到下流过。生命线实际上显示了消息的顺序,在生命线之上的消息比在它之下的消息先发生。在生命线中的棒形方框表示的是活动生命线,用以强调一个对象只有在一个场景的部分中处于活动状态。 消息,指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息。 同步消息返回消息。同步消息假定有一个返回消息。同步消息用有实心的箭头表示;返回消息用虚线、箭头

40、也不是实心来表示。 反身消息消息的发送方和接收方是同一个对象。 异步消息没有返回值的消息。用非实心箭头表示。 定时消息对消息附加时间约束条件,包括:发送时间、接收时间、已用时间等。第五章 面向对象方法-RUP复习建议:RUP(Rational Unified Process,统一软件开发过程)。掌握RUP在解决下列三个问题的基本方法。(1) 表达基本信息的术语(2) 用于组织基本信息的表达格式(3) 在不同抽象层之间进行“映射”的过程指导。本章考核题目类型包括单项选择题、填空题、简答题,分值在10%15%之间。重点要掌握基本概念、基本原理。1迭代式开发在软件开发的早期阶段就想完全、准确的捕获用

41、户的需求几乎是不可能的。实际上,我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险,而且每个迭代过程都可以执行版本结束,可以鼓舞开发人员。 2管理需求确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用况和脚本的使用已被证明是捕获功能性需求的有效方法。 3体系结构组件使重用成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于降低管理复杂性,提高重用率。

42、RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。 4可视化建模RUP往往和UML联系在一起,对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模,获取有关体系结构于组件的结构和行为信息。 5验证软件质量在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动,而是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。 6控制软件变更迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品,隔离来自其他

43、工作空间的变更,以此为每个开发人员建立安全的工作空间。第一节 RUP的特点以用况驱动的、以体系结构为中心的迭代、增量式开发。1. 用况驱动(1) 用况是能够向用户提供有价值结果的系统中的一种功能(2) 用况获取的是功能需求在系统的生存周期中,以用况作为基础,驱动系统有关人员对所要建立系统的功能需求进行交流,驱动系统分析、设计、实现和测试等活动,包括制定计划、分配任务、监控执行和进行测试等,并将它们有机地组织在一起,使各个阶段中都可以回溯到用户的实际需求。2. 以体系结构为中心系统体系结构:是对系统语义的概括描述,对所有项目有关人员都是可以理解的。3. 迭代与增量(1) 迭代是重复的部分(2)

44、增量是增加的部分一个迭代是一个完整的开发循环,产生一个可执行的产品版本,是最终产品的一个子集,它增量式地发展,从一个迭代过程到另一个迭代过程到成为最终的系统。图5-1 RUP迭代模型二维开发模型:RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(

45、Workflow)。如图1:RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。 图5-2:RUP二维开发模型(1) 初始阶段初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体

46、,在较高层次上定义交互的特性。本阶段具有非常重要的意义,在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲,初始阶段可能很短。初始阶段结束时是第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。 (2) 细化阶段细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系结构作出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备

47、工具。细化阶段结束时第二个重要的里程碑:生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。 (3)构造阶段在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻

48、,要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。 (4)交付阶段交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。在生命周期的这一点上,用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。第二节 核心工作流RUP中有9个核心工作流

49、,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。 (1)商业建模商业建模(Business Modeling)工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用况模型和商业对象模型中定义组织的过程,角色和责任。 (2)需求需求(Requirement)工作流的目标是描述

50、系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重要的是理解系统所解决问题的定义和范围。 (3)分析和设计分析和设计(Analysis & Design)工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象,由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem),而描述则体现了类的对象如何协同工作实现用况的功能。设计活动以体系结构设计为中心,体系结构由

51、若干结构视图来表达,结构视图是整个设计的抽象和简化,该视图中省略了一些细节,使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介,而且在系统的开发中能提高被创建模型的质量。 (4)实现实现(Implementation)工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。 (5)测试测试(Test)工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并

52、处理。RUP提出了迭代的方法,意味着在整个项目中进行测试,从而尽可能早地发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性和系统性能来进行。 (6)部署部署(Deployment)工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。 (7)配置和变更管理配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来

53、管理演化系统中的多个变体,跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。 (8)项目管理软件项目管理(Project Management)平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。 (9)环境环境(Environment)工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。环境工作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了

54、逐步的指导手册并介绍了如何在组织中实现过程。图5-3 RUP核心概念1. 需求获取RUP运用用况(Use Case)技术来获取需求。(1) 列出候选的需求:特征列表(2) 理解系统语境:领域模型或业务模型(3) 捕获功能需求:用况模型(4) 捕获非功能需求:补充需求或针对一些特定的用况特征:是一个新的项(Item)及其简要描述。领域模型:类图(1) 业务对象(2) 实在对象(3) 事件业务对象模型:交互图、活动图(1) 工作人员(2) 业务实体(3) 工作单元创建系统用况模型的活动和任务:(1) 发现并描述参与者(2) 发现并描述用况(3) 确定用况的优先级(4) 精化用况(5) 构造用户界面

55、原型(6) 用况模型的结构化2. 需求分析在系统用况模型的基础上,创建系统分析模型以及在该分析模型视角下的体系结构描述。分析类:是类的一种衍型,很少有操作和特征标记,而用责任来定义其行为,并且其属性和关系也是概念性的。存在三种不同类型的类:实体类、边界类和控制类。(1)实体类实体类描述要保存到持久存储体中的信息。如:数据库、各种形式的数据文件中的信息。包括:活动者类。活动者类代表出现在用况模型中的活动者。活动者是现实世界中与系统交互的人和/或机构。例如,订单处理系统中客户是一个活动者类。业务类描述业务的地点、物品、概念和事件。例如订单处理系统中的订单、商品等都是业务类。(2)边界类 也称界面类

56、(UI类),是组成系统用户界面的屏幕显示、菜单和报表。例如,订单处理系统中客户登录系统的界面、显示和编辑订单的屏幕等都属于UI类。边界类位于系统与外界的交界处。如:窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。(3)控制类控制类是主要负责其它类工作的类。如:主程序类、主窗体类。分析包:分析包体现了“局部化”、“问题分离”等软件设计原理。分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况,形成一些不同的分析包。服务包和共享包。用况细化:(2)分析模型的表达(3)分析的主要活动活动1:体系结构分析活动2:用况分析3. 设计层定义满足需求规约所需

57、要的软件结构。RUP的设计目标:定义满足系统/产品分析模型所规约需求的软件结构。4个术语:(1) 设计类(2) 用况细化(3) 设计子系统(4) 接口两个角度:(1) 系统设计模型(2) 表达物理分布的系统部署模型4. 设计层的术语(1) 设计类:是对系统实现中一个类或类似构造的一个无缝抽象。了解设计类的主要特征:操作、属性、关系、方法、实现需求、是否为主动类。(2) 用况细化:描述一个特定用况是如何予以细化的。(3) 设计子系统(4) 接口5. 设计模型、部署模型、体系结构描述(1) 设计模型(2) 部署模型(3) 体系结构描述6. 设计的主要活动活动1:体系结构设计(1) 标识节点和它们的

58、网络配置(2) 标识子系统和它们的接口(3) 标识在体系结构方面有意义的设计类和它们的接口(4) 标识一般性的设计机制活动2:用况的设计(1) 标识参与用况细化的设计类(2) 标识参与用况细化的子系统和接口活动3:类的设计(1) 概括描述设计类(2) 标识操作(3) 标识属性(4) 标识关联和聚合(5) 标识泛化(6) 描述方法(7) 描述状态活动4:子系统设计(1) 维护子系统依赖(2) 维护子系统所提供的接口(3) 维护子系统内容7. RUP的实现RUP实现的目标:(1)基于设计类和子系统生成构件(2)对构成进行单元测试(3)进行集成和连接(4)把可执行的构件映射到部署模型RUP实现的主要

59、活动:(1) 实现体系结构(2) 集成系统(3) 实现子系统(4) 实现类(5) 完成单元测试8. RUP的测试包括:内部测试、中间测试和最终测试。RUP测试包括的主要活动:(1) 计划测试(2) 设计测试(3) 实现测试(4) 执行集成测试(5) 执行系统测试(6) 评价测试第六章 软件测试复习建议错误是不可避免的,我们要做的就是发现它,并改正它。软件测试是保证软件过程质量和软件产品质量的基础。因此软件测试也是本课程的重点内容,题目类型涉及单项选择题、填空题、简答题、综合应用题全部题型,分值在25%左右。本章既有基本概念,也有综合应用,要求考生多做练习。第一节 软件测试目标与软件测试过程模型1. 软件测试的对象 软件=程序+文档测试对象:各个阶段产生的源程序和文档。 2. 软件测试的目的基于不同的立场,对软件测试的目的存在着两种完全对立的观点。(1) 一种观点是通过测试暴露出软件中所包含的故障和缺陷(从用户的角度);(2) 另一种是希望测试成为表明软件产品中不存在错误的过程,验证该软件中已正确地实现了用户的要求,因此,它们倾向于选取导致程序失败概率最小的测试实例和数据。显然,第二种观点对完善和提高软件质量和可靠性毫无价值,因此测试的目的应该是通过软件测试尽可能多地发现并改正软件种存

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!