这是上学期选修的一门课,延期到现在考试,但是上课期间全程摸鱼,对内容完全不了解,距离考试还有两天,尝试快速入门......

据说有五个大题,全是应用设计题,为什么据说呢,因为网课睡过去了,没参加。如果是应用分析的话,那么题目是相当灵活的,因此做题是十分看感觉的,不好把握,希望考试能顺利通过吧!

一、基于给定的需求绘制DFD图

掌握结构化分析的方法,按照数据流图的一般步骤基于给定的需求绘制DFD图,绘制DFD图要遵循DFD的守恒、封闭和父子平衡的原则。

先了解一下数据流图是啥.......

数据流图(DFD):描述软件系统逻辑模型的技术。

功能:描绘信息在系统中的流动加工处理的情况。

然后还需要知道这个图的一些符号是怎样画的......

那知道了数据流图的作用和画法之后以教材销售为例,帮助学习和掌握画图的流程......

例:教材销售系统。

售书过程:

  1. 学生找系办公室的张秘书开一个购书单

  1. 凭购书单找教材科的王会计开购书发票

  1. 向李出纳员交书费开领书单

  1. 学生拿着领书单到书库找赵保管员领

当前系统流程图:

目标系统流程图:

【画数据流图的步骤】

(1)从系统流程图出发,明确系统范围和流程

i 系统处理的范围

ii 信息处理流程

(2)识别并从问题中提取数据流图的元素

i 源与目的

数据源——学生

数据目的——学生

ii数据流

购书单、发票、领书单

iii 加工处理

审查并开发票、开领书单

iv数据存储

各班学生用书表、教材存量表、售书登记表

(3)根据信息处理流程依次连接各个图上的元素

i 外部实体、加工、数据存储之间的数据流

ii 调整布局

DFD图:

数据流必须是名词或者名词短语,这个问题我在交作业时犯过错误被老师指出来了。

二、用判定表描述加工逻辑

基于给定的需求利用判定表描述加工逻辑,要掌握判定表的一般表现形式。

先了解一下判定表的作用,以及画法......

例:某单位工资制度规定如下:

  1. 技术干部的职务工资标准为(月):

技术员5000元

助理工程师7000元

工程师9000元

高级工程师12000元

工龄>10年并受聘高级工程师的职务工资为14000元

  1. 工龄补助

10年以下加10/年

10~20年加20/年

20年以上加30/年

(两种画法都可)

判定表的变形(判定树)

优点:比判定表更加直观,易于理解和使用。

三、过程模型应用

基于给定的系统开发需求选择合适的模型进行系统开发,要掌握常用的过程模型,例如瀑布模型快速原型模型增量模型螺旋模型等。在回答问题时重点阐述模型的特点,然后针对待开发系统的需求详细阐述选择模型的理由

首先我们需要了解以下几个过程模型都是什么......

  1. 边做边改模型

【开发过程】

(1)开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本;

(2)提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止;

【问题】

(1)忽略需求环节,给软件开发带来很大的风险;

(2)缺少规划和设计环节,软件的结构随着不断地修改越来越糟,导致无法继续修改。

  1. 瀑布模型

优点:

(1)“线性”是人们最容易掌握并能熟练应用的思想方法。

(2)线性是一种简洁,简洁就是美。

缺点:

(1)瀑布模型要求用户一开始清楚地给出所有需求,以后也不能再发生任何变化。

不可能实现!因为开始阶段必然会存在很多不确定的情况。

(2)由于开发模型是线性的,程序的运行版本一直要等到项目开发周期的晚期才能得到

客户必须有耐心等待;

如果大的错误直到运行程序时才被发现,后果可能是灾难性的。

还存在将错误积累和放大的问题......

  1. 快速原型模型

开发项目出现以下两个问题,原型模型可能是最好的选择。

(1)用户难以清楚的给出所有的需求

不能标识出详细的输入、处理及输出需求;

(2)开发者不能确定以下问题

算法的有效性

操作系统的适应性

人机交互的形式

原型模型可以分为四个步骤

(1)收集用户需求

(2)建立原型集中于用户可见的部分——输入、输出

(3)用户评估原型,并进一步精化软件的需求

(4)逐步调整原型使其满足客户的需求

  1. 增量模型

  1. 演化模型

主要针对需求不是很明确的软件项目,从需求较清楚的部分开始,根据用户的建议逐渐向系统中添加功能。因此,最终的系统是一步一步添加功能完成的。

  1. 喷泉模型

开发活动常常需要重复多次,分析、设计等活动之间迭代进行,不具有活动之间清晰的界限,相互融合。

适应与面向对象的软件开发过程。

  1. 螺旋模型

=瀑布模型+原型模型

强调了其它模型所忽视的风险分析

特别适合于大型复杂的系统

例:

四、测试用例设计

掌握逻辑结构覆盖法等价类划分法设计测试用例。逻辑覆盖法设计测试用例时需要给出每种覆盖粒度对应的测试用例,以及该用例对应的执行路径。等价类划分设计测试用例时,需要按照等价类划分的步骤:(1)划分有效及无效等价类;(2)基于给定的有效和无效等价类分别设计测试用例及预期输出

首先需要知道什么是逻辑结构覆盖法和等价类划分法......

测试用例={输入数据+期望结果}

包括白盒测试用例设计和黑盒测试用例设计......

白盒测试用例设计

程序内部逻辑结构为基础设计迹测试用例。

(1)逻辑覆盖法:使用程序流程图设计测试用例

  1. 语句覆盖

将程序中每个语句至少执行一次

  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)

条件覆盖不一定符合判定覆盖

  1. 判定\条件覆盖

每个条件的真假两种情况至少执行一次。

每个判定的每个分支路径至少要执行一次。

  1. 条件组合覆盖

每个判定所有条件的各种可能组合至少执行一次

所谓的条件组合覆盖,就是一个判定的所有子条件的组合情况都出现一次。一般使用列表法,把子条件的所有组合情况都列出来,然后填表:

(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)系统前置条件和后置条件

例:绘制邮购公司管理系统用例图

问题描述:

我们在为一家邮购公司开发订单处理软件,从供应商那里购买产品、再销售。这家公司每年发布两次产品目录,并将其邮递给客户和其他感兴趣的人。客户以提交商品列表并向邮购公司付费的方式购买商品。邮购公司填写账单并把商品运送到客户的地址。

订单处理软件记录从收到订单直到商品被运送给客户的整个过程。邮购公司将提供快提的服务,以最快,最有效的方法来运送客户订购的产品。客户可以退货,要求重新进货,但有时要付费。

了解一下什么是类图......

一些概念:

接口:一组操作的集合,只有操作的声明而没有实现

抽象类:不能被实例化的类,一般至少包含一盒抽象操作

模板类:一种参数化的类,在编译时把模板参数绑定到不同的数据类型,从而产生不同的类

一些关系:

【对象之间的关系】:

关联关系

聚合关系 组合关系

依赖关系

泛化关系

【对象与接口之间的关系】:

实现关系

  1. 关联关系

一个类的对象(实例)作为另一个类的对象的变量成员时,两个类之间有关联关系。

  1. 聚合关系

表示两个类的对象之间有“整体”于“部分”的关系。

组合关系【强化形式】

  1. 依赖关系

表示“使用”的语义,是一种比较弱的关系。

对象作为参数、全局变量或者局部变量被另外一个对象使用

友元依赖:授权一个对象访问对象的私有或者保护成员

  1. 泛化关系

类A(特殊)到类B(一般)的泛化关系表示“类A是类B的一种”。

类A——子类

类B——父类

  1. 对象与接口的实现关系

例、识别·类图中对象之间的关系

了解以下什么是顺序图......

强调消息的时间顺序的交互图

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐