1 / 86

软件工程

软件工程. 周志钊 zhouzhizhao08@163.com. 结构化分析. 软件需求 是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。 需求分析就是通过对 应用问题及其环境 的分析与理解,采用一系列的分析方法和技术,将 用户的需求 逐步精确化、完全化、一致化,最终形成需求规格说明文档的过程。 系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础,分析人员需从软件的角度对其进行检查和调整,并在此基础上展开需求分析。. 需求工程. 需求开发. 需求管理. 需求获取. 需求分析. 编写需求文档. 需求确认. 软件需求分析. 需求分析过程.

lucian
Download Presentation

软件工程

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 软件工程 周志钊 zhouzhizhao08@163.com

  2. 结构化分析 • 软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。 • 需求分析就是通过对应用问题及其环境的分析与理解,采用一系列的分析方法和技术,将用户的需求逐步精确化、完全化、一致化,最终形成需求规格说明文档的过程。 • 系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础,分析人员需从软件的角度对其进行检查和调整,并在此基础上展开需求分析。

  3. 需求工程 需求开发 需求管理 需求获取 需求分析 编写需求文档 需求确认 软件需求分析 需求分析过程

  4. 程序员 系统分析员 软件需求分析 需求获取 座谈法调查表法观察法 调研 分析 业务需求 功能需求 用户 可行性报告 概要 信息 系统定义报告 用户需求 非功能性需求

  5. 系统分析员 分析、处理 软件需求分析 需求分析 需求获取 获取数据 目标逻辑模型 从数据流和数据结构出发,找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求 见第二章第27页,2.3.2 建立目标系统逻辑模型。

  6. 系统分析员 软件需求分析 需求文档编写 需求规格说明书 编写 目标系统的基本描述系统各项需求系统限制及条件系统数据定义 …… 需求分析结果

  7. 软件需求分析 需求评审与确认 所有需求必须一致,不能前、后和相互矛盾 一致性 说明书应包括用户需求的每一方面 完整性 评审、验证 的四个方面 在现有基础上可实现 现实性 必须证明需求有效,能解决用户提出的问题 有效性

  8. 需求分析方法 面向数据的方法,以数据流为中心 。其核心概念包括:进程、数据流、数据存储、外部实体、数据组和数据元素。有代表性的模拟工具有:数据流图、数据字典、原始进程规格说明。 结构化分析方法 分析 方法 面向对象的分析方法 面向对象分析以对象及其服务作为建模标准,比较自然,对象也具有相对的稳定性。主要模拟的元素有:对象、类、属性、关系、方法、消息传递、用例等。其主要原理包括分类、继承、层次、信息隐藏、汇集关系等。

  9. 软件需求分析 • 需求规格说明和图的目的是什么? • 目的是将所要研制的系统的概述与用户沟通,以保证对所要研制的系统总行为的理解,并指导随后的设计和开发。 • 需求分析的任务是:理解、分析和表达系统(软件)必须做什么,并按要求编写需求规格说明书。

  10. 系统流程图 • 系统流程图的作用 • 系统流程图是描述物理系统的工具。通过画出系统流程图来了解要开发的项目的大概处理流程、 范围和功能等。 系统流程图不仅能用于可行性研究,还能用于需求分析阶段。 • 系统流程图可用图形符号来表示系统中的各个元素, 例如,人工处理、数据处理、数据库、文件和设备等。它表达了系统中各个元素之间的信息流动的情况。

  11. 系统流程图 2. 系统流程图的符号 • 画系统流程图时,首先要搞清业务处理过程以及处理中的各个元素,同时选择相应的符号来代表系统中的各个元素。所画的系统流程图要反映出系统的处理流程。

  12. 系统流程图

  13. 系统流程图 • 【例1】某工厂有一个库房, 存放该厂生产需要的物品, 库房中的各种物品的数量及各种物品库存量临界值等数据记录在库存文件上,当库房中物品数量有变化时,应更新库存文件。若某种物品的库存量少于库存临界值,则报告采购部门以便其订货, 每天向采购部门送一份采购报告。

  14. 系统流程图 物品的发放和接受称为变更记录。 系统中的库存管理模块对变更记录进行处理, 更新存储在磁盘上的库存文件,并把订货信息记录到联机存储中。 每天由报告生成模块读一次订货信息,并打印出订货报告。

  15. 系统流程图 • 【例2】车间填写领料单到仓库领料,库长用料计划审批领料单,未批准的领料单退回车间。 • 库工收到已批准的领料单后,首先查阅库存账,若有货,则通知车间前来领取所需物料,并登记用料流水账,否则将通知采购人员缺货。 • 采购人员根据缺货通知,查阅订货合同单,若已订货,则向供货单位发出催货请求,否则就临时申请补充订货。 • 供货单位发出货物后,立即向订货单位发出提货通知。采购人员收到提货通知单后,就可办理入库手续。 • 库工要依据库存账和用料流水账定期向有关部门生成库存报表。

  16. 系统流程图 • 问题涉及的人员、部门和业务往来 • 人员/部门: 库长、库工、采购员 车间、供货单位、有关部门 • 业务往来: 车间 —— 库长; 库长 —— 库工; 库工 —— 车间; 库工 —— 采购员; 库工 —— 有关部门;采购员 —— 供货单位

  17. 系统流程图 • 上述“业务往来”的流程图: • ① 车间 — 库长 • ② 库长 — 库工

  18. 系统流程图 • ③ 库工 — 车间 • ④ 库工 — 采购员

  19. 系统流程图 • ⑤ 库工 — 有关部门 • ⑥ 采购员 — 供货单位

  20. 系统流程图

  21. 数据流程分析 • 数据流图(Data Flow Diagram,简称DFD):是结构化分析的最基本工具,反映信息在系统中流动和处理情况的图形,它是描述系统逻辑模型的工具之一。 数据流图是便于用户理解系统数据流程的图形表示。它能精确地在逻辑上描述系统的功能、输入、输出和数据存贮等,而摆脱了其物理内容。

  22. 数据流图 • 数据流图符号 见31页图2.2

  23. 数据流与数据加工之间的关系

  24. 数据流图 上图是一个简单的数据流图,它表示数据X从源S流出,经P1加工转换成Y,接着经P2加工转换为Z,在加工过程中从F中读取数据 见31页DFD的附加符号。

  25. 数据流图元素 • 数据流 :数据流由一组确定的数据组成。例如“发票”为一个数据流,它由品名、规格、单位、单价、数量等数据组成。数据流用带有名字的具有箭头的线段表示,名字称为数据流名,表示流经的数据,箭头表示流向。

  26. 数据流图元素 • 加工处理:加工处理是对数据进行的操作,它把流入的数据流转换为流出的数据流。每个加工处理都应取一个名字表示它的含义,并规定一个编号用来标识该加工在层次分解中的位置。名字中必须包含一个动词,例如“计算”、“打印”等。

  27. 数据流图元素 • 文件:文件是存贮数据的工具。文件名应与它的内容一致,写在开口长条内 。从文件流入或流出数据流时,数据流方向是很重要的。 • 数据源或终点 :数据源和终点表示数据的外部来源和去处。它通常是系统之外的人员或组织,不受系统控制。

  28. 自顶向下逐层分解

  29. 画数据流图 • 绘制顶层DFD: 顶层DFD只有一个处理逻辑,用来确定系统与外部环境的关系,其名称应能概括系统的功能。顶层图中输入输出的数据流必须是该系统全部的输入输出数据流,外部实体也应该是与该系统有输入输出联系的全部外部实体。

  30. 画数据流图 • 首先画出顶层数据流程图。只有一张,说明了系统的总的处理功能、输入和输出。 订货单 用户 P1 销售处理 发货单 销售子系统顶层数据流程图

  31. 画数据流图 将销售处理分解为更多的“处理”

  32. 建立数据流模型要遵循的原则 1.每个加工至少应有一个输入数据流(反映被处理数据的来源)和一个输出数据流(反映加工的结果)。 2.数据流图中各构成元素的名称必须具有明确的含义且能够代表对应元素的内容或功能。 3.对某个加工进行细化生成的下层数据流图,称为其上层图的子图。应保证分层数据流图中任意对应的父图和子图的输入/输出数据流保持一致。 4.应按照层次给每个加工编号,用于表明该加工所处的层次及上、下层的父图与子图的关系。编号的规则为:顶层加工不用编号;第一层加工的编号为1,2,…,n。第二层加工的编号为1.1,1.2,…,2.1,2.2,…,n.1,n.2,…,等,以此类推。

  33. 建立数据流模型要遵循的原则 5.在父图中不要出现子图中涉及的局部数据存储文件。通常除底层数据流图中需表明所有数据存储外,为保持画面整洁,各中间层数据流图只需显示处于加工之间的接口文件即可。 6.数据流图只能由四种基本符号组成,是实际业务流程的客观映象,用于说明系统应该“做什么”,而不需要指明系统“如何做”。 7.数据流图的分解速度应保持适中。通常一个加工每次可分解为2~4个子加工,最多不要超过七个,否则会增加用户的理解难度。同时要注意,逐层精化必须适可而止。

  34. 画数据流图 • 【例3】图书管理系统数据流程图 • 顶层数据流图:

  35. 画数据流图

  36. 画数据流图 • 第2层数据流图:(读者借阅)

  37. 画数据流图 • 第2层数据流图:(读者还书)

  38. 画数据流图 • 第2层数据流图:(管理员添加、删除、修改图书信息)

  39. 数据字典 • 数据流图机制没有描述数据流的内容。数据流图必须与描述并组织数据条目的数据字典配套使用。 • 数据字典(DD)是对系统中的数据的详尽描述,描述DFD中数据流、数据存储、处理逻辑等构成和基本特征。

  40. 数据字典 • 数据字典(Data Dictionary):在数据流图的基础上,对其中的每个数据流、文件和数据项加以定义。其主要内容是对数据流程图中的数据项、数据结构、数据流、处理逻辑、数据存储和外部实体等六个方面进行具体定义供设计者和用户双方参照使用。

  41. 数据字典的组成 • 数据字典把数据的最小组成单位看成是数据项(数据元素),若干个数据项可以组成一个数据结构(组合数据项)。数据字典通过数据项和数据结构来描写数据流、数据的存储和属性。即: • 数据项组成数据结构,数据结构组成数据流和数据存储。

  42. 数据字典 (1)数据项:也称数据元素,是具有独立逻辑含义的最小数据单位,即逻辑上不可再分的数据单位。对每个数据项的定义包括以下内容: 数据项编号 数据项名称 别名 简述 长度 取值范围 A—004 库存量 SL 某种配件的库存数量 8个字节 0—999999

  43. 数据项举例

  44. 数据字典 (2)数据结构:由若干个数据项构成的数据组合称为数据结构,它描述了某些数据项之间的关系。 可由若干数据项、数据结构,或数据与数据结构组成(如订货单),包括名称、编号、简述、组成。

  45. 数据结构举例

  46. 数据字典 (3)数据流:数据流是表明系统中数据的逻辑流向,该数据可以是数据项或数据结构。 即数据流可由一个或一组固定的数据项或数据结构组成。不仅要说明数据流的名称,还应指明它的来源、去向和数据流量、高峰流量等。

  47. 数据流举例

  48. 数据字典 (4)处理逻辑:处理逻辑的定义仅对数据流程图中最低层的处理逻辑加以说明。 说明处理中包含的逻辑条件,包括数据来源、去向、计算方法及处理频度等。

  49. 处理逻辑举例

More Related