每个同学要假想自己是一个项目经理,去完成一个软件项目,比如医院管理系统,自动设备控制系统等,以面向结构的软件工程方法,说出完成项目的步骤,涉及到的具体技术。初步了解面向对象的方法的与面向结构的方法的异同,掌握面向对象的分析的主要方法以及文档。
- 1.掌握以下概念:
- 软件危机,
- 软件工程,
- 软件生命周期,
- 软件过程模型(经典瀑布模型,实际的瀑布模型,原型模型,增量模型)
- 2.可行性分析主要回答什么问题?掌握技术可行性分析的工具(系统流程图),会写数据字典
- 3.软件需求需要解决的主要问题是什么?软件需求需要描述的数据模型,功能模型,行为模型分别的目的是为了说明什么?画出他们的目的是什么?会画E-R图,状态转换图,数据流图。
- 4.总体设计的主要任务,面向数据流的设计方法。
- 5.掌握程序流程图,
- 盒图,
- PAD图,
- 判定表,
- 判定树。
- 6.掌握测试步骤的主要任务,掌握黑盒测试方案的设计方法,掌握白盒测试中的的设计方法:
- 语句覆盖,
- 判定覆盖,
- 条件覆盖,
- 判定-条件覆盖,
- 条件组合覆盖
- 7.软件维护的类型,
- 软件维护的流程
- 8.面向对象的方法和面向结构方法的比较。特别是C语言程序的结构,JAVA语言的程序结构。面向对象分析的步骤,所需要完成的三个模型,会画对应的图
题型有简答题,综合应用题。
文章目录
- 掌握以下概念(第一章)
- 可行性分析主要回答什么问题?掌握技术可行性分析的工具(系统流程图),会写数据字典
- 软件需求需要解决的主要问题是什么?软件需求需要描述的数据模型,功能模型,行为模型分别的目的是为了说明什么?画出他们的目的是什么?会画E-R图,状态转换图,数据流图。
- 总体设计的主要任务,面向数据流的设计方法
- 掌握程序流程图,盒图,PAD图,判定表,判定树。
- 掌握测试步骤的主要任务,掌握黑盒测试方案的设计方法,掌握白盒测试中的的设计方法:语句覆盖,判定覆盖,条件覆盖,判定-条件覆盖,条件组合覆盖
- 软件维护的类型,软件维护的流程
- 面向对象的方法和面向结构方法的比较。特别是C语言程序的结构,JAVA语言的程序结构。面向对象分析的步骤,所需要完成的三个模型,会画对应的图
- 时序图
掌握以下概念(第一章)
可行性分析主要回答什么问题?掌握技术可行性分析的工具(系统流程图),会写数据字典
可行性分析主要回答什么问题:
1、技术可行性 使用现有的技术能否实现这个系统?
2、经济可行性 这个系统的的经济效应能够超过开发成本吗?
3、操作可行性 系统的操作方式在这个用户组织内行得通吗?
4、法律可行性
5、社会效应可行性
6、···
根本任务:对以后的行动方针提出建议
系统流程图
系统流程图CSDN
定义 :概括性的描述物理系统的工具
作用 :表达数据在系统各部件之间流动的情况
基本符号 :
例子 :
数据流图
数据流图
作用 :描述信息流和数据从输入移动到输出的过程中所经受的变换
基本符号 :
例子 :
数据字典
作用:供人查阅对不了解的条目的解释
例子:
软件需求需要解决的主要问题是什么?软件需求需要描述的数据模型,功能模型,行为模型分别的目的是为了说明什么?画出他们的目的是什么?会画E-R图,状态转换图,数据流图。
软件需求需要解决的主要问题是什么?
软件需求需要描述的数据模型,功能模型,行为模型分别的目的是为了说明什么?
数据模型
作用:描述系统中使用的数据和数据之间的关系。
说明内容: 定义了系统中的数据实体、它们的属性以及实体之间的关系。这有助于在设计阶段更好地理解系统需要存储、管理和处理的信息。
功能模型
作用:描述系统将提供的功能或服务。
说明内容: 通过用例图、流程图、功能分解图等方式,展示系统的各种功能或服务,帮助识别系统所需的各种操作、用户需求和功能点。功能模型有助于理解系统的各个部分如何协同工作以实现用户期望的功能。
行为模型
作用:描述系统中各个组件或对象的行为方式。
说明内容: 通过状态图、序列图、活动图等方式描述系统中实体的行为、状态转换、对象之间的交互等。行为模型有助于理解系统如何响应不同事件或输入,并展示系统内部的交互和流程。
画出他们的目的是什么?
数据模型
1、使用实体关系图、类图或表格等形式来展示数据模型的结构。
2、以图形化方式呈现系统将如何存储和处理数据。
3、有助于利益相关者理解系统中使用的数据类型、关系和属性。
功能模型
1、展示系统的各种功能或服务。
2、清晰地呈现系统的功能点、用户需求以及系统如何响应不同的操作。
3、有助于利益相关者理解系统的各个功能模块以及它们之间的关联。
行为模型
1、有助于展示系统如何响应不同的事件或输入,对象之间的交互,以及系统内部的状态转换和流程
2、有助于利益相关者更好地理解系统的行为逻辑。
E-R图(实体-联系图)
具体例子看课本P64图3.2
画E-R图的具体步骤:
1、确定实体
实体 指现实世界中的一个具体的事物或概念,如人、物、地点、事件等。在ER图中,实体用一个矩形表示,并在矩形中写明实体名称。
2、确定实体的属性
属性 指实体的特征或属性,如学生的姓名、年龄、性别等。在ER图中,属性用一个椭圆形表示,并在椭圆形中写明属性的名称。
3、确定实体之间的关系
关系 指实体之间的联系或连接,如学生选课、教师授课等。在ER图中,关系用菱形表示,并在菱形中写明关系的名称。
4、绘制E-R图
使用矩形表示实体,椭圆形表示属性,菱形表示关系。在每个矩形、椭圆形和菱形中写明名称。使用箭头表示关系的方向。
5、确定实体之间的基数
确定实体之间的关系,如一对多 、多对多 等。使用箭头表示关系的方向。
状态转换图
具体例子看课本P66图3.3
基本符号
- 初态用实心圆表示,终态用一对同心圆(内圆为实心圆)表示。
- 中间状态用圆角矩形表示 ,可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称,这部分是必须有的;中间部分为状态变量的名字和值,这部分是可选的;下面部分是活动表,这部分也是可选的。
- 活动表有三种标准事件:
- entry:事件指定进入该状态的动作
- exit:事件指定退出该状态的动作
- do:指定该状态下的动作
数据流图
基本符号
- 正方形(或立方体)表示数据的源点或终点;
- 圆角矩形(或圆形)代表变换数据的处理;
- 开口矩形(或两条平行横线)代表数据存储;
- 箭头表示数据流,即特定数据的流动方向。
画图步骤
工厂订单报表
假设一家工厂的采购部每天需要一张订货报表,报表按零件编号排序,表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据:零件编号,零件名称,订货数量,目前价格,主要供应者,次要供应者。零件入库或出库称为事务,通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。
分析题目的四种成分:
画出顶层数据流图(突出表明了数据的源点和终点) :
画出第0层数据流图:
"产生报表" 和 "处理事务" 是该系统必须完成的两个主要功能,它们将代替图顶层数据流图中的"订货系统"。此外,细化后的数据流图中还增加了两个数据存储:处理事务需要"库存清单"数据;产生报表和处理事务在不同时间,因此需要存储"定货信息"。除了2.1节(2.1 数据流图有4种成分分析)的表中列出的两个数据流之外还有另外两个数据流,它们与数据存储相同。这是因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同,也就是说,数据存储和数据流只不过是同样数据的两种不同形式(事务 <--> 库存清单,订货信息 <--> 订货报表)。
画出第1层数据流图:
进一步细化。考虑通过系统的逻辑数据流,当发生一个事务时必须首先接收它;随后按照事务的内容修改库存清单;最后如果更新后的库存量少于库存量临界值时,则应该再次定货,也就是需要处理定货信息。因此,把"处理事务"这个功能分解为下述3个步骤:"接收事务"、"更新库存清单"和"处理订货",这在逻辑上是合理的。
为什么不进一步分解"产生报表"这个功能呢?因为订货报表中需要的数据在存储的订货信息中全都有,产生报表只不过是按一定顺序排列这些信息,再按一定格式打印出来。然而这些考虑纯属具体实现的细节,不应该在数据流图中表现。同样道理,对"接收事务"或"更新库存清单"等功能也没有必要进一步细化。总之,当进一步分解将涉及如何具体地实现一个功能时,就不应该再分解了。
总体设计的主要任务,面向数据流的设计方法
总体设计的主要任务
系统应该如何实现
面向数据流的设计方法
目标:给出设计软件结构的一个系统化的途径
方式:使用数据流图描绘信息在系统中加工和流动的情况
信息流的映射有两种:
1、变换流
信息沿输入通路进入系统,由外部形式变换成内部形式,进入系统的信息通过变换中心,经加工处理以
后再沿输出通路变换成外部形式离开软件系统。当数据流图具有这些特征时,这种信息流就叫作变换流。
2、事务流
数据沿输入通路到达一个处理T,这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这
类数据流应该划为一类特殊的数据流,称为事务流。图中的处理T称为事务中心,它完成下述任务。
(1)接收输入数据(输入数据又称为事务)。
(2) 分析每个事务以确定它的类型。
(3) 根据事务类型选取一条活动通路.
变换分析
1、复查基本系统模型
2、复查并精化数据流图。
3、确定数据流图具有变换特性还是事务特性。
4、确定输入流和输出流的边界,从而孤立出变换中心。
5、完成"第一级分解
软件结构代表对控制的自顶向下的分配,所谓分解就是分配控制的过程。对于变换流的情况,数据流图被映射成一个特殊的软件结构,这个结构控制输入、变换和输出等信息处理过程。位于软件结构最顶层的控制模块Cm协调下述从属的控制功能。输入信息处理控制模块Ca,协调对所有输入数据的接收。变换中心控制模块Ct,管理对内部形式的数据的所有操作。输出信息处理控制模块Ce,协调输出信息的产生过程。
6、完成"第二级分解"
第二级分解就是把数据流图中的每个处理映射成软件结构中一个适当的模块。
7、使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化。
事物分析
数据流具有明显的事务特点时采用事务分析方法。事务分析的设计步骤和变换分析的设计步骤大部分相同或类似,主要差别仅在于由数据流图到软件结构的映射方法不同。由事务流映射成的软件结构包括一个接收分支和一个发送分支。
掌握程序流程图,盒图,PAD图,判定表,判定树。
程序流程图
基本符号
示例
盒图
N-S图,也被称为盒图或NS图,是结构化编程中的一种可视化建模。
示例:
三种基本符号:
循环结构
选择结构
条件结构
多分支选择结构
循环结构
当型循环结构
直到循环结构
PAD图
基本符号
(a) 顺序;
(b) 选择;
© CASE多分支;
(d) WHILE型循环;
(e) UNTIL型循环;
(f) 语句标号;
(g) 定义
判定表
判定表 | 组成 |
---|---|
左上部分 | 所有条件 |
左下部分 | 所有可能做的动作 |
右上部分 | 各种条件组合,每一列表示一种可能组合 |
右下部分 | 每一列对应每一种条件组合的动作 |
题目:假设某航空公司规定,乘客可以免费托运重量不超过30kg的行李。当行李重量超过30kg时,对头等舱的国内乘客超重部分每公斤收费4元,对其他舱的国内乘客超重部分每公斤收费6元,对外国乘客超重部分每公斤收费比国内乘客多一倍,对残疾乘客超重部分每公斤收费比正常乘客少一半。用判定表进行表达。
判定树
判定表能够清晰的表达复杂的条件组合,但是对于初次接触的人来说需要一个理解的学习过程,判定树是判定表的变种,TA也能够清晰地表达复杂的条件组合,TA的优点在于不需要任何的说明,一眼能够看出其中的含义。虽然更加直观但是比起判定表TA的简洁性要差一些,同一个值有可能需要重复写。
假设某航空公司规定,乘客可以免费托运重量不超过30kg的行李。当行李重量超过30kg时,对头等舱的国内乘客超重部分每公斤收费4元,对其他舱的国内乘客超重部分每公斤收费6元,对外国乘客超重部分每公斤收费比国内乘客多一倍,对残疾乘客超重部分每公斤收费比正常乘客少一半。用判定树进行表达。
掌握测试步骤的主要任务,掌握黑盒测试方案的设计方法,掌握白盒测试中的的设计方法:语句覆盖,判定覆盖,条件覆盖,判定-条件覆盖,条件组合覆盖
掌握测试步骤的主要任务
白盒测试中的的设计方法
语句覆盖
每个语句至少执行一遍
判定覆盖
判定的每一个结果至少执行一次
条件覆盖
判定表达式中每一个条件都取到可能的结果
判定-条件覆盖
判定覆盖+条件覆盖
条件组合覆盖
每个判定表达式中条件的各种组合尝试一次
黑盒测试方案的设计方法
等价划分
划分输入数据的等价类,确定有效输入和无效输入
边界值分析
选取等于、稍小于、稍大于等价类边界值的数据作为测试数据
错误推测
列举出程序中可能有的错误和容易发生错误的特殊情况
软件维护的类型,软件维护的流程
软件维护的类型
改正性维护
开发阶段已发生而系统测试阶段尚未发现的错误(开发时候遇到的bug)
适应性维护
软件适应信息技术变化和管理需求变化而进行的修改(旧功能适应新环境)
完善性维护
在使用软件的过程中用户往往提出增加新功能或者修改已有的功能的建议(需要新功能)
预防性维护
为了改进未来的可维护性或者可靠性,或者为了给未来的改进奠定更好的基础而修改软件(为了以后未知的新功能)
软件维护的流程
1、在需求分析阶段:明确维护范围及责任,审查系统要求;研究运行/维护的支持;明确性能要求及变更;明确扩充或收缩;检验关键资源的可扩充性。
2、在设计阶段:考虑系统的扩展、压缩和变更及设计通用性等。
3、在编程阶段:查找源程序错误,度量源程序可理解性等。
4、在测试阶段:维护人员参与集成测试,统计分析错误等。
面向对象的方法和面向结构方法的比较。特别是C语言程序的结构,JAVA语言的程序结构。面向对象分析的步骤,所需要完成的三个模型,会画对应的图
对象模型-类图
对象模型
对象模型 :表示静态的、结构化的系统的"数据"的性质
作用:为动态模型和功能模型提供实质性的框架
类图 :类的图形符号为长方形 ,用两条横线把长方形分上、中、下 3个区域,3个区域分别放类的名字、属性和服务
动态模型-状态图
动态模型
动态模型 :瞬时的 、行为化的 系统的控制性质,它规定了对象模型中的对象的合法变化序列
**状态图:**描绘对象的状态、触发状态转换的事件以及对象的行为。
功能模型-用例图
功能模型:变化的系统的功能性质,它指明了系统应该做什么,因此更直接地反映了用户对目标系统的需求,由一组数据流图 组成
用例图:外部行为者所理解的系统功能 。用例模型的建立是系统开发者和用户反复讨论的结果 ,它描述了开发者和用户对需求规格所达成的共识。