软件工程第二章课件.ppt
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 从三方面进行分析:
– 技术可行性 – 经济可行性 – 操作可行性
• 任务:对以后的行动方针提出建议。
2021/2/14
2
2.2 可行性研究过程
•复查系统规模和目标 •研究目前正在使用的系统 •导出新系统的高层逻辑模型 •进一步定义问题 •导出和评价供选择的解法 •推荐行动方针 •草拟开发计划 •书写文档提交审查
名字、别名、描述、数据类型、长度、结构、值的范 围、使用方式、控制信息、分组信息等
(3) 数据存储 (4) 处理（结合IPO图或PDL ）
2021/2/14
28
2.5.2 定义数据的方法
2021/2/14
3
2.3 系统流程图
•概括地描绘物理系统的传统工具。
•用图形符号以黑盒子形式描绘组成系统 的每个部件(程序，文档，数据库，人工 过程等)。
•表达的是数据在系统各部件之间流动的 情况（物理数据流图），而不是对数据 进行加工处理的控制过程(程序流程图) 。
2021/2/14
4
基本符号
(6) 分层的数据流图
7+/-2个加工 编号要一致
(7) 父图与子图的平衡：保证数据流图的 一致性
2021/2/14
16
数据流命名3 父图与子图的平衡
图 2
b 2.2
图 2.1 e
a1 2.1.2 b
a 2.1
d
a 2.1.1
c 2.3
a2 2.1.3 c
2021/2/14
17
数据流命名3
父图与子图的平衡
(2) 名字应该反映整个处理的功能，而不 是它的一部分功能。
(3) 名字最好是“及物动词+宾语”结构 。应该尽量避免使用“加工”、“处 理”等。
2021/2/14
15
处理的命名2 2.4.3 命名
(4) 如果必须用两个动词才能描述整个处 理的功能，则可能需要再分解。
(5) 如果某个处理不好命名，应考虑重新 分解。
2021/2/14
12
数据流命名1
2.4.3 命名
• 为数据流(或数据存储)命名
(1) 是名词或名词短语，画数据流而不是 控制流，一般不画物质流（人民币） 。
(2) 名字应代表整个数据流(或数据存储) 的内容，而不是仅仅反映它的某些成 分。
(3) 不要使用空洞的、缺乏具体含义的名
字(如“数据”、“信息”、“输入
2021/2/14
20
0层DFD
储户
存款/取 款单
储蓄系统
存款/取款 信息
储户
存款/取 款单
1层DFD
存款 p1 信息
接收并分类 取款 信息
p2
存款
p3
取款
存款 信息
取款 信息
p4
打印
存款/取款 信息
取款 信息
2层DFD
2021/2/14
取款
P3.1 信息 P3.2
P3.3
验证身份
验证帐户 取款 更新帐户 信息
2.3.1 符号
2021/2/14
5
库存清单系统的系统流程图
2021/2/14
6
2.4 数据流图
•数据流图(DFD)是是系统逻辑功能的图 形表示，描绘信息流和数据从输入移动 到输出的变换过程。
•不涉及具体的物理部件，只描绘数据在 软件中流动和被处理的逻辑过程。
•不需要考虑怎样具体地实现这些功能
•是分析员与用户之间极好的通信工具
2021/2/14
10
分层的数据流图
2021/2/14
11
• 在多层数据流图中，顶层流图仅包含一 个加工，它代表被开发系统。它的输入 流是该系统的输入数据，输出流是系统 所输出数据
• 底层流图是指其加工不需再做分解的数 据流图，它处在最底层
• 中间层流图则表示对其上层父图的细化 。它的每一加工可能继续细化，形成子 图。
第2章 可行性研究
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结
2021/2/14
1
2.1 可行性研究的任务
• 目的:确定问题是否值得去解决。 • 实质:在较高层次上以较抽象的方式进
行的系统分析和设计的过程。
父图
子图 4 客户4.1
4.2 提货 单
4
订货 单
提货 单
帐号
4.3
数量
2021/2/14
18
其它元素
2.4.3 命名
(1) 数据源点/终点是目标系统的外部项（人员 、外设、传感器）。
(2) 局部数据存储只有当它作为某些加工的数 据接口或某个加工特定的输入或输出时， 就把它画出来（信息隐蔽）
局部数据存储：不是父图中相应加工的 外部接口，只是本图中某些加工之间的 数据接口。
”之类)。
2021/2/14
13
数据流命名2
2.4.3 命名
• 为数据流(或数据存储)命名
(4) 如果命名有困难，则很可能是因为对 数据流图分解不恰当，试试重新分解 。
(5) 每个加工至少有一个输入数据流和一 个输出数据流。
2021/2/14
14
处理的命名1 2.4.3 命名
• 为处理命名
(1) 通常先为数据流命名，然后再为与之 相关联的处理命名。
取款 信息
帐户信息
21
DFD案例 定货系统基本系统模型
2021/2/14
22
定货系统的功能级数据流图
2021/2/14
23
进一步分解后的数据流图
2021/2/14
24
2.4.4 用途
•分析员与用户交流信息的工具
– 直观 – 易理解 – 避免自然语言歧义性
•分析和设计的工具
– 根据系统的逻辑模型考虑系统的物理实现
2021/2/14
7
2.4.1 DFD符号
2021/2/14
8
2.4.1 符号
2021/2/14
9
2.4.1 符号
•箭头表示数据流的流动方向 •程序流程图箭头表示控制流 •应该描绘所有可能的数据流向 •不能描绘出现某个数据流的条件 •忽略出错处理，打开或关闭文件之类的 内务处理。
•是描绘“做什么”而不考虑“怎样做” 。
(3) 提高可理解性：加工功能相对独立，减少 数据流的数目。
2021/2/14
19
DFD案例 储蓄系统数据流图
• 一个储蓄系统，完成以下功能：
– 储户存款
• 根据存款单检查帐户信息，如果是新开户，则添 加此储户信息，并更新帐户；否则更新储户的帐 户信息
– 储户取款
• 检查取款单，如果是合法用户，更新帐户信息。
2021/2/ቤተ መጻሕፍቲ ባይዱ4
25
自动化边界——批量方式更新库存清单
2021/2/14
26
自动化边界——联机方式更新库存清单
2021/2/14
27
2.5 数据字典
•定义数据流图中包含的所有元素 •与数据流图共同构成系统的逻辑模型 •分别对DFD中元素的定义：
(1) 数据流 (2) 数据流分量(即数据元素)
– 技术可行性 – 经济可行性 – 操作可行性
• 任务:对以后的行动方针提出建议。
2021/2/14
2
2.2 可行性研究过程
•复查系统规模和目标 •研究目前正在使用的系统 •导出新系统的高层逻辑模型 •进一步定义问题 •导出和评价供选择的解法 •推荐行动方针 •草拟开发计划 •书写文档提交审查
名字、别名、描述、数据类型、长度、结构、值的范 围、使用方式、控制信息、分组信息等
(3) 数据存储 (4) 处理（结合IPO图或PDL ）
2021/2/14
28
2.5.2 定义数据的方法
2021/2/14
3
2.3 系统流程图
•概括地描绘物理系统的传统工具。
•用图形符号以黑盒子形式描绘组成系统 的每个部件(程序，文档，数据库，人工 过程等)。
•表达的是数据在系统各部件之间流动的 情况（物理数据流图），而不是对数据 进行加工处理的控制过程(程序流程图) 。
2021/2/14
4
基本符号
(6) 分层的数据流图
7+/-2个加工 编号要一致
(7) 父图与子图的平衡：保证数据流图的 一致性
2021/2/14
16
数据流命名3 父图与子图的平衡
图 2
b 2.2
图 2.1 e
a1 2.1.2 b
a 2.1
d
a 2.1.1
c 2.3
a2 2.1.3 c
2021/2/14
17
数据流命名3
父图与子图的平衡
(2) 名字应该反映整个处理的功能，而不 是它的一部分功能。
(3) 名字最好是“及物动词+宾语”结构 。应该尽量避免使用“加工”、“处 理”等。
2021/2/14
15
处理的命名2 2.4.3 命名
(4) 如果必须用两个动词才能描述整个处 理的功能，则可能需要再分解。
(5) 如果某个处理不好命名，应考虑重新 分解。
2021/2/14
12
数据流命名1
2.4.3 命名
• 为数据流(或数据存储)命名
(1) 是名词或名词短语，画数据流而不是 控制流，一般不画物质流（人民币） 。
(2) 名字应代表整个数据流(或数据存储) 的内容，而不是仅仅反映它的某些成 分。
(3) 不要使用空洞的、缺乏具体含义的名
字(如“数据”、“信息”、“输入
2021/2/14
20
0层DFD
储户
存款/取 款单
储蓄系统
存款/取款 信息
储户
存款/取 款单
1层DFD
存款 p1 信息
接收并分类 取款 信息
p2
存款
p3
取款
存款 信息
取款 信息
p4
打印
存款/取款 信息
取款 信息
2层DFD
2021/2/14
取款
P3.1 信息 P3.2
P3.3
验证身份
验证帐户 取款 更新帐户 信息
2.3.1 符号
2021/2/14
5
库存清单系统的系统流程图
2021/2/14
6
2.4 数据流图
•数据流图(DFD)是是系统逻辑功能的图 形表示，描绘信息流和数据从输入移动 到输出的变换过程。
•不涉及具体的物理部件，只描绘数据在 软件中流动和被处理的逻辑过程。
•不需要考虑怎样具体地实现这些功能
•是分析员与用户之间极好的通信工具
2021/2/14
10
分层的数据流图
2021/2/14
11
• 在多层数据流图中，顶层流图仅包含一 个加工，它代表被开发系统。它的输入 流是该系统的输入数据，输出流是系统 所输出数据
• 底层流图是指其加工不需再做分解的数 据流图，它处在最底层
• 中间层流图则表示对其上层父图的细化 。它的每一加工可能继续细化，形成子 图。
第2章 可行性研究
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结
2021/2/14
1
2.1 可行性研究的任务
• 目的:确定问题是否值得去解决。 • 实质:在较高层次上以较抽象的方式进
行的系统分析和设计的过程。
父图
子图 4 客户4.1
4.2 提货 单
4
订货 单
提货 单
帐号
4.3
数量
2021/2/14
18
其它元素
2.4.3 命名
(1) 数据源点/终点是目标系统的外部项（人员 、外设、传感器）。
(2) 局部数据存储只有当它作为某些加工的数 据接口或某个加工特定的输入或输出时， 就把它画出来（信息隐蔽）
局部数据存储：不是父图中相应加工的 外部接口，只是本图中某些加工之间的 数据接口。
”之类)。
2021/2/14
13
数据流命名2
2.4.3 命名
• 为数据流(或数据存储)命名
(4) 如果命名有困难，则很可能是因为对 数据流图分解不恰当，试试重新分解 。
(5) 每个加工至少有一个输入数据流和一 个输出数据流。
2021/2/14
14
处理的命名1 2.4.3 命名
• 为处理命名
(1) 通常先为数据流命名，然后再为与之 相关联的处理命名。
取款 信息
帐户信息
21
DFD案例 定货系统基本系统模型
2021/2/14
22
定货系统的功能级数据流图
2021/2/14
23
进一步分解后的数据流图
2021/2/14
24
2.4.4 用途
•分析员与用户交流信息的工具
– 直观 – 易理解 – 避免自然语言歧义性
•分析和设计的工具
– 根据系统的逻辑模型考虑系统的物理实现
2021/2/14
7
2.4.1 DFD符号
2021/2/14
8
2.4.1 符号
2021/2/14
9
2.4.1 符号
•箭头表示数据流的流动方向 •程序流程图箭头表示控制流 •应该描绘所有可能的数据流向 •不能描绘出现某个数据流的条件 •忽略出错处理，打开或关闭文件之类的 内务处理。
•是描绘“做什么”而不考虑“怎样做” 。
(3) 提高可理解性：加工功能相对独立，减少 数据流的数目。
2021/2/14
19
DFD案例 储蓄系统数据流图
• 一个储蓄系统，完成以下功能：
– 储户存款
• 根据存款单检查帐户信息，如果是新开户，则添 加此储户信息，并更新帐户；否则更新储户的帐 户信息
– 储户取款
• 检查取款单，如果是合法用户，更新帐户信息。
2021/2/ቤተ መጻሕፍቲ ባይዱ4
25
自动化边界——批量方式更新库存清单
2021/2/14
26
自动化边界——联机方式更新库存清单
2021/2/14
27
2.5 数据字典
•定义数据流图中包含的所有元素 •与数据流图共同构成系统的逻辑模型 •分别对DFD中元素的定义：
(1) 数据流 (2) 数据流分量(即数据元素)