软件工程快速复习
中国矿业大学软件工程选修(文章大多数摘抄于刘迎春老师课件,部分来源于网络)习题部分不是标准答案,来源于我写的作业。
这是上学期选修的一门课,延期到现在考试,但是上课期间全程摸鱼,对内容完全不了解,距离考试还有两天,尝试快速入门......
据说有五个大题,全是应用设计题,为什么据说呢,因为网课睡过去了,没参加。如果是应用分析的话,那么题目是相当灵活的,因此做题是十分看感觉的,不好把握,希望考试能顺利通过吧!
一、基于给定的需求绘制DFD图
掌握结构化分析的方法,按照数据流图的一般步骤基于给定的需求绘制DFD图,绘制DFD图要遵循DFD的守恒、封闭和父子平衡的原则。
先了解一下数据流图是啥.......
数据流图(DFD):描述软件系统逻辑模型的技术。
功能:描绘信息在系统中的流动和加工处理的情况。
然后还需要知道这个图的一些符号是怎样画的......
那知道了数据流图的作用和画法之后以教材销售为例,帮助学习和掌握画图的流程......
例:教材销售系统。
售书过程:
-
学生找系办公室的张秘书开一个购书单;
-
凭购书单找教材科的王会计开购书发票;
-
向李出纳员交书费开领书单;
-
学生拿着领书单到书库找赵保管员领书。
当前系统流程图:
目标系统流程图:
【画数据流图的步骤】
(1)从系统流程图出发,明确系统范围和流程
i 系统处理的范围
ii 信息处理流程
(2)识别并从问题中提取数据流图的元素
i 源与目的
数据源——学生
数据目的——学生
ii数据流
购书单、发票、领书单
iii 加工处理
审查并开发票、开领书单
iv数据存储
各班学生用书表、教材存量表、售书登记表
(3)根据信息处理流程依次连接各个图上的元素
i 外部实体、加工、数据存储之间的数据流
ii 调整布局
DFD图:
数据流必须是名词或者名词短语,这个问题我在交作业时犯过错误被老师指出来了。
二、用判定表描述加工逻辑
基于给定的需求利用判定表描述加工逻辑,要掌握判定表的一般表现形式。
先了解一下判定表的作用,以及画法......
例:某单位工资制度规定如下:
-
技术干部的职务工资标准为(月):
技术员5000元
助理工程师7000元
工程师9000元
高级工程师12000元
工龄>10年并受聘高级工程师的职务工资为14000元
-
工龄补助
10年以下加10/年
10~20年加20/年
20年以上加30/年
(两种画法都可)
判定表的变形(判定树)
优点:比判定表更加直观,易于理解和使用。
三、过程模型应用
基于给定的系统开发需求选择合适的模型进行系统开发,要掌握常用的过程模型,例如瀑布模型、快速原型模型、增量模型、螺旋模型等。在回答问题时重点阐述模型的特点,然后针对待开发系统的需求详细阐述选择模型的理由。
首先我们需要了解以下几个过程模型都是什么......
-
边做边改模型
【开发过程】
(1)开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本;
(2)提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止;
【问题】
(1)忽略需求环节,给软件开发带来很大的风险;
(2)缺少规划和设计环节,软件的结构随着不断地修改越来越糟,导致无法继续修改。
-
瀑布模型
优点:
(1)“线性”是人们最容易掌握并能熟练应用的思想方法。
(2)线性是一种简洁,简洁就是美。
缺点:
(1)瀑布模型要求用户一开始清楚地给出所有需求,以后也不能再发生任何变化。
不可能实现!因为开始阶段必然会存在很多不确定的情况。
(2)由于开发模型是线性的,程序的运行版本一直要等到项目开发周期的晚期才能得到。
客户必须有耐心等待;
如果大的错误直到运行程序时才被发现,后果可能是灾难性的。
还存在将错误积累和放大的问题......
-
快速原型模型
开发项目出现以下两个问题,原型模型可能是最好的选择。
(1)用户难以清楚的给出所有的需求
不能标识出详细的输入、处理及输出需求;
(2)开发者不能确定以下问题
算法的有效性
操作系统的适应性
人机交互的形式
原型模型可以分为四个步骤:
(1)收集用户需求
(2)建立原型,集中于用户可见的部分——输入、输出
(3)用户评估原型,并进一步精化软件的需求
(4)逐步调整原型使其满足客户的需求
-
增量模型
-
演化模型
主要针对需求不是很明确的软件项目,从需求较清楚的部分开始,根据用户的建议逐渐向系统中添加功能。因此,最终的系统是一步一步添加功能完成的。
-
喷泉模型
开发活动常常需要重复多次,分析、设计等活动之间迭代进行,不具有活动之间清晰的界限,相互融合。
适应与面向对象的软件开发过程。
-
螺旋模型
=瀑布模型+原型模型
强调了其它模型所忽视的风险分析
特别适合于大型复杂的系统
例:
四、测试用例设计
掌握逻辑结构覆盖法与等价类划分法设计测试用例。逻辑覆盖法设计测试用例时需要给出每种覆盖粒度对应的测试用例,以及该用例对应的执行路径。等价类划分设计测试用例时,需要按照等价类划分的步骤:(1)划分有效及无效等价类;(2)基于给定的有效和无效等价类分别设计测试用例及预期输出。
首先需要知道什么是逻辑结构覆盖法和等价类划分法......
测试用例={输入数据+期望结果}
包括白盒测试用例设计和黑盒测试用例设计......
白盒测试用例设计
以程序内部逻辑结构为基础设计迹测试用例。
(1)逻辑覆盖法:使用程序流程图设计测试用例
-
语句覆盖
将程序中每个语句至少执行一次
-
判定覆盖
每个判定的每个分支路径至少要执行一次
设T1=A>3,T2=B>3;为该判定节点的两个子条件。
所谓的判定覆盖就是让判定的真分支和假分支各执行一次,只要列出的子条件能够满足真假分支各一次就可以了:
例如: A=4,B=3(T1=True,T2=False)走了真分支,A=3,B=3(T1=False,T2=False)走了假分支。
iii.条件覆盖
每个条件的真假两种情况至少执行一次
所谓条件覆盖就是给出的条件组合里面每个子条件的真、假都出现过,也就是T1(True,False),T2(True,False)都出现过。现在如果我们拿过问题(一)的条件组合,那么得到的就是:
A=4,B=3(T1=True,T2=False)
A=3,B=3(T1=False,T2=False)
发现T1(True,False)都有了,T2(__,False)只有False,没有出现True,所以随便补充一个T2=True的条件组合就可以了:
A=3,B=4(T1=False,T2=True)
条件覆盖不一定符合判定覆盖
-
判定\条件覆盖
每个条件的真假两种情况至少执行一次。
每个判定的每个分支路径至少要执行一次。
-
条件组合覆盖
每个判定的所有条件的各种可能组合至少执行一次
所谓的条件组合覆盖,就是一个判定的所有子条件的组合情况都出现一次。一般使用列表法,把子条件的所有组合情况都列出来,然后填表:
(2)路径测试法:使用流程图设计测试用例
路径测试就是设计足够的测试用例,覆盖程序中的所有可能的路径
i.点覆盖=语句覆盖
每个节点至少执行一次
ii. 边覆盖=判定覆盖
每条边至少执行一次
iii.路径覆盖
每条路径都至少要执行一次
最强的白盒测试=条件组合覆盖+路径覆盖
例:请说明A、B、C各组测试用例达到的逻辑覆盖类别
黑盒测试用例
完全不考虑程序的内部结构,只依据程序的功能来设计测试用例。
【穷举测试】——不可行
(1)等价分类法
将所有可能的输入数据划分成若干个等价类,然后从每一类中选取少数有代表性的数据作为测试用例
等价类包括:
①有效等价类
对于程序来说,是合理的、有效的输入数据构成的集合。
②无效等价类
对于程序来说,是不合理的、无效的输入数据构成的集合。
在设计测试用例时,要同时考虑有效等价类和无效等价类的设计。
例:某城市的电话号码由3部分组成。地区码(空白或3位数);前缀(非“0”或“1”开头的3位数字);后缀(4位数字)
①划分等价类
|
输入条件 |
有效等价类 |
无效等价类 |
|
地区码 |
⑴空白 ⑵000~999 |
⑸有非数字字符 ⑹少于三位数字 ⑺多于三位数字 |
|
前缀 |
⑶200~999 |
⑻有非数字字符 ⑼起始位为1 ⑽起始位为2 ⑾少于三位数字 ⑿多于三位数字 |
|
后缀 |
⑷0000~9999 |
⒀有非数字字符 ⒁少于四位数字 ⒂多于四位数字 |
②设计测试用例
设计测试用例原则:
有效等价类尽量选择公用测试用例,以减少测试次数。
无效的每类伊利,以防止漏掉错误。
选取测试用例:
(1)为每一个等价类规定一个唯一编号
(2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止。
(3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效的等价类,重复这一步,直到所有的无效等价类都被覆盖为止。
(2)边界值分析法
对等价分类法的补充
针对各种边界情况设计测试用例
大量的错误发生在输入/输出范围的边界上,而不是在输入范围的内部
步骤:
首先应确定边界情况
选取正好等于、刚刚大于、刚刚小于边界的值作为测试数据。
(3)错误推测法
靠经验和直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误地测试用例
五、面对对象综合应用题
基于给定的需求说明给出USE CASE图、类图及时序图,以及开发该系统时选择何种语言及开发工具进行开发,并阐述选择语言的理由。 首先需要知道用例图的一些相关知识...... 用例图的作用:
用例图的组成:
Use Case的目的:
1、定义清晰的系统行为;
2、不解释系统的内部结构。
Use Case的特征:
①、具有完全性
即不管内部是如何实现的
只有最终产生了返回Actor的结果,Use Case的执行才能完毕。
②、描述系统提供的交互功能
一个Use Case可以被其他的Use Case调用
Use Case可以组合完成某一项更大的功能
③、Use Case说明系统需要提供什么而不是怎么提供
用户不关心你如何给她们提供所需要的功能
④、Use Case一般是用“动宾”短语命名
建立Use Case图的过程
(1)找出拟建系统以外的角色:
与系统交互的人员;
与系统相连并交换信息的设备和其他系统;
(2)使用Use Case来描述角色怎样使用系统以及系统向角色提供什么功能
Use Case表示从外部用户角度观察的系统功能
(3)绘制Use Case图,并编写详细的Use Case描述。
Use Case图只能宏观地描述系统地功能;
每个功能的含义和具体实现步骤则以文本方式描述。
例、学生注册课程系统
(1)教师可以使用该系统查询新学期将开设的课程和选课学生情况,并可以登记成绩单,学生可以存取系统查看自己的电子成绩单。
(2)注册管理员使用该系统维护教师信息、学生信息和课程信息等。
(3)学生可以获得该学期的课程目录表,课程目录表列出每门课程的所有信息,诸如基本信息、教师、开课系和选课条件等。
(4)选课注册期间学生可以选课注册,并且允许改变或取消注册申请。每门课程最多不能超过150人,最少不能低于30人。
(5)注册管理员负责关闭课程注册,低于30人选课的课程将被取消,一旦学生的注册过程完毕,注册系统将有关信息提交收费系统以便学生付费。
建立Use Case图
步骤1:找出拟建系统以外的角色
①、学生,教师
【注意】
新生、老生:
如果新生和系统的交互的方式与老生不一样,则新生和老生不是一个actor;
如果他们和系统的交互操作是一样的,则应该是同一个actor
助教:
即选课、也授课,扮演了学生和教师两个角色。
同样的角色已经被表示为学生和教师两个actor。
因此,不必要再为助教标识一个actor
②、注册管理员
③、收费系统
步骤2:发现Use Case
对于已识别的Actor,通过询问下列问题发现Use Case:
Actor从系统中获得什么功能? Actor需要做什么?
Actor需要读取、产生、删除、修改或存储系统的某些信息吗?
系统中发生事件需要通知Actor吗?
系统需要的输入/输出信息是什么?这些信息从哪儿来到哪儿去?
采用什么实现方法满足某些特殊要求?
如,安全性……
(1)教师可以使用该系统查询新学期将开设的课程和选课学生情况,并可以登记成绩单;
教师:
查询选课
选择所教的课程,并获得学生名册;
登记成绩
在学期结束时,提交学生的课程成绩;
(3)在每个学期的开始,学生可以获得该学期的课程目录表,课程目录表列出每门课程的所有信息,诸如基本信息、教师、开课系和选课条件等。
(4)新学期开始前两周为选课注册时间,在此期间学生可以选课注册,并且允许改变或取消注册申请。每门课程最多不能超过150人,最少不能低于30人。
(6)在学期结束时,学生可以存取系统查看电子成绩单。由于学生成绩属于敏感信息,系统必须提供必要的安全措施以防非法存取。
学生:
注册课程
在学期开始进行选课注册,允许在一段时间内更改或删除,课程目录系统提供当前学期的所有可选课程列表;
查看成绩单
学生可以查看以前学期的电子成绩单。
(2)注册管理员使用该系统维护教师信息、学生信息和课程信息等。
(5)开学两周后注册管理员负责关闭课程注册,低于30人选课的课程将被取消,一旦学生的注册过程完毕,系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满或课程被取消,系统将通知学生在提交课程表之前予以更改。
维护课程信息
在系统中增加、修改和删除课程信息;
维护学生信息
在系统中增加、修改和删除学生信息;
维护教师信息
在系统中增加、修改和删除教师信息;
关闭注册
删除少于30人
步骤3:建立Use Case图
画图规则:
主动角色画在图的左边
被动角色画在图的右边
每个Use Case必须为用户提供确切的功能
Use Case名称必须写在椭圆里面
每一张图里不能有太多的Use Case
为每一个Use Case编号便于检索
为Use Case建立目录(编号和名称)便于管理
保持图面整洁
步骤4:描述用例模型
(1)简要介绍角色、用例的作用和目的
(2)描述事件流——活动和流程,可以通过动态模型直观表示,如状态图、时序图和活动图,包括基本流和备选流
(3)描述非功能性需求和设计约束
(4)系统前置条件和后置条件
例:绘制邮购公司管理系统用例图
问题描述:
我们在为一家邮购公司开发订单处理软件,从供应商那里购买产品、再销售。这家公司每年发布两次产品目录,并将其邮递给客户和其他感兴趣的人。客户以提交商品列表并向邮购公司付费的方式购买商品。邮购公司填写账单并把商品运送到客户的地址。
订单处理软件记录从收到订单直到商品被运送给客户的整个过程。邮购公司将提供快提的服务,以最快,最有效的方法来运送客户订购的产品。客户可以退货,要求重新进货,但有时要付费。
了解一下什么是类图......
一些概念:
接口:一组操作的集合,只有操作的声明而没有实现
抽象类:不能被实例化的类,一般至少包含一盒抽象操作
模板类:一种参数化的类,在编译时把模板参数绑定到不同的数据类型,从而产生不同的类
一些关系:
【对象之间的关系】:
关联关系
聚合关系 组合关系
依赖关系
泛化关系
【对象与接口之间的关系】:
实现关系
-
关联关系
一个类的对象(实例)作为另一个类的对象的变量成员时,两个类之间有关联关系。
-
聚合关系
表示两个类的对象之间有“整体”于“部分”的关系。
组合关系【强化形式】
-
依赖关系
表示“使用”的语义,是一种比较弱的关系。
对象作为参数、全局变量或者局部变量被另外一个对象使用
友元依赖:授权一个对象访问对象的私有或者保护成员
-
泛化关系
类A(特殊)到类B(一般)的泛化关系表示“类A是类B的一种”。
类A——子类
类B——父类
-
对象与接口的实现关系
例、识别·类图中对象之间的关系
了解以下什么是顺序图......
强调消息的时间顺序的交互图
更多推荐

所有评论(0)