软件工程导论

您所在的位置:网站首页 订货系统流程图怎么做 软件工程导论

软件工程导论

2024-07-10 03:56| 来源: 网络整理| 查看: 265

文章目录 1. 可行性研究1.1. 可行性研究的目的1.2. 可行性研究过程 2. 系统流程图2.1. 系统流程图概述2.2. 系统流程图的图符2.3. 系统流程图的例子2.4. 系统流程图的分层 3. 数据流图 Data Flow Diagram,DFD3.1. 数据流图的概念3.2. 数据流图的基本图符3.3. 绘制数据流图3.3.1. 绘制数据流图的步骤3.3.2. 成分的命名 3.4. 数据流图的例子3.4. 数据流图的分层3.5. 基本加工说明 PSPEC 4. 数据字典 Data Dictionary,DD4.1. 数据字典的概念4.2. 数据字典的内容4.3. 定义数据的方法4.4. 数据字典的实现 5. 成本/效益分析5.1. 成本估算5.2. 成本/效益分析方法5.2.1. 货币的时间价值

1. 可行性研究 1.1. 可行性研究的目的

可行性研究实质上是要进行一次简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。这个过程通常结合了初步的需求分析,不做需求分析,就无法对需求进行可行性分析。它所需要的时间长短取决于工程的规模。一般说来,可行性研究的成本只是预期的工程总成本的5%到10%。

因此,可行性研究的目的不是解决问题,而是确定问题是否能够并且值得去解决。

并非任何问题都有简单明显的解决办法,事实上,许多问题不可能在预定的系统规模或时间期限之内解决。如果问题没有可行的解,那么花费在这项工程上的任何时间、人力、软硬件资源和经费,都是无谓的浪费。可行性研究的目的,就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

如果问题没有可行的解,分析员应该建议停止这项开发工程,以避免时间、资源、人力和金钱的浪费;如果问题值得解,分析员应该推荐一个较好的解决方案,并且为工程制定一个初步的计划。

1.2. 可行性研究过程 首先需要进一步分析和澄清问题定义。在澄清了问题定义之后,分析员应该导出系统的逻辑模型。然后从系统逻辑模型出发,探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性,一般说来,至少应该从下述三方面研究每种解法的可行性: (1)技术可行性:工使用现有的技术能实现这个系统吗? (2)经济可行性:这个系统的经济效益能超过它的开发成本吗? (3)操作可行性:系统的操作方式在这个用户组织内行得通吗? 必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

展开来说,典型的可行性研究过程有下述一些步骤

复查系统规模和目标 分析员对问题定义阶段书写的关于规模种目标的报告书进一步复查确认,改正含糊或不确切的叙述,清晰地描述对目标系统的一切限制和约束研究目前正在使用的系统 现有的系统是信息的重要来源,新的目标系统必须也能完成它的基本功能;另一方面,现有的系统必然有某些缺点,新系统必须能解决旧系统中存在的问题。此外,运行使用旧系统所需要的费用是一个重要的经济指标,如果新系统不能增加收入或减少使用费用,那么从经济角度看新系统就不如旧系统导出新系统的高层逻辑模型 优秀的设计过程通常总是从现有的物理系统出发,导出现有系统的逻辑模型,再参考现有系统的逻辑模型,设想目标系统的逻辑模型,最后根据目标系统的逻辑模型建造新的物理系统; 通过上一步的工作,分析员能够使用数据流图,描绘数据在系统中流动和处理的情况,从而概括地表达出他对新系统的设想。为了把新系统描绘得更清晰准确,还应该有一个初步的数据字典,定义系统中使用的数据中。进一步定义问题 新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标,这次复查应该把数据流图和数据字典作为讨论的基础。可行性研究的前4个步骤实质上构成一 个循环。 分析员定义问题,分析这个问题,导出一个试探性的解。在此基础上再次定义问题,再一次分析这个问题,修改这个解。继续这个循环过程中直到提出的逻辑模型完全符合系统目标。导出和评价供选择的解法 分析员应该从他建议的系统逻辑模型出发,导出若干个较高层次的(较抽象的)物理解法,供比较和选择。导出供选择的解法的最简单的途径,是从技术角度出发考虑解决问题的不同方案。 首先,根据技术可行性的考虑初步排除一些不现实的系统方案。 其次,考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案。 最后考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用,并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。推荐行动方针 根据可行性研究结果应该做出的一个关键性决定是,是否继续进行这项开发工程。如果分析员认为值得继续进行这项开发工程,那么他应该选择一种最好的解法,并且说明选择这个解决方案的理由。 通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程,因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。草拟开发计划 分析员应该为所推荐的方案草拟一份开发计划,除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况,应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本,最后应给出下一个阶段(需求分析)的详细进度表和成本估计。书写文档提交审查 应该把上述可行性研究各个步骤的工作结果写成清晰的文档,请用户、客户组织的负责人及评审组审查,以决定是否继续这项工程及是否接受分析员推荐的方案 2. 系统流程图 2.1. 系统流程图概述

系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序,文档,数据库,人工过程等)。

系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程,因此尽管系统流程图的某些符号和程序流程图的符号形式相同,但是它却是物理数据流图而不是程序流程图。

2.2. 系统流程图的图符

利用符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件(或数据库),把抽象处理具体化为特定的程序或手工操作等。

图符名称说明在这里插入图片描述处理能改变数据值或数据位置的加工或部件,例如,程序、处理机、人工加工等都是处理在这里插入图片描述输入输出表示输入或输出(或既输入又输出),是一个广义的不指明具体设备的符号在这里插入图片描述连接指出转到图的另一部分或从图的另一部分转来,通常在同一页上在这里插入图片描述换页连接指出转到另一页图上或由另一页图转来在这里插入图片描述数据流用来连接其他符号,指明数据流动方向在这里插入图片描述穿孔卡片表示用穿孔卡片输入或输出,也可表示一个穿孔卡片文件在这里插入图片描述文档通常表示打印输出,也可表示用打印终端输入数据在这里插入图片描述磁带磁带输入输出,或表示一个磁带文件在这里插入图片描述联机存储表示任何种类的联机存储,包括磁盘、磁鼓、软盘和海量存储器件等在这里插入图片描述磁盘磁盘输入输出,也可表示存储在磁盘上的文件或数据库在这里插入图片描述磁鼓磁鼓输入输出,也可表示存储在磁鼓上的文件或数据库在这里插入图片描述显示CRT终端或类似的显示部件,可用于输入或输出,也可既输入又输出在这里插入图片描述人工输入人工输入数据的脱机处理,例如填写表格在这里插入图片描述人工操作人工完成的处理,例如会计在工资支票上签名在这里插入图片描述辅助操作使用设备进行的脱机操作在这里插入图片描述通信链路通过远程通信线路或链路传送数据 2.3. 系统流程图的例子

以一个简单的例子进行讲解

某装配厂有一座存放零件的仓库,仓库中现有的各种零件的数量以及每种零件的存量临界值等数据,记录在库存清单主文件中。当仓库中零件数量有变化时,应该及时修改库存清单主文件,如果那种零件的库存量少于它的库存量临界值,则应该报告给采购部门以便订货,规定每天向采购部门送一次订货报告。

该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务,流程如下:

零件库存量的每一次变化称为一个事务,由放在仓库中的CRT终端输入到计算机中;系统中的库存清单程序对事务进行处理,更新存储在磁盘上的库存清单主文件,并且把必要的订货信息写在磁带上;最后,每天由报告生成程序读一次磁带,并且打印出订货报告。如下图所示。

在这里插入图片描述

2.4. 系统流程图的分层

面对复杂的系统时,一个比较好的方法是分层次地描绘这个系统。

首先用一张高层次的系统流程图描绘系统总体概貌,表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度,画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。

3. 数据流图 Data Flow Diagram,DFD 3.1. 数据流图的概念

数据流图(DFD)是一种图形化的交流工具和分析设计工具,它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

在数据流图中没有任何具体的物理部件,它只是描绘数据在软件中流动和被处理的逻辑过程,是系统逻辑功能的图形表示,即使不是专业的计算机技术人员也容易理解它,因此是分析员与用户之间极好的通信工具。

此外,设计数据流图时只需考虑系统必须完成的基本逻辑功能,完全不需要考虑怎样具体地实现这些功能。

下面的顶级DFD高度概括了数据流图的处理过程,数据从外部实体流入目标系统进行加工,然后又流出到外部实体。 在这里插入图片描述

3.2. 数据流图的基本图符

数据流图有四种基本符号:

正方形(或立方体),表示数据的源点或终点;圆角矩形(或圆形),代表数据的加工处理;开口矩形(或两条平行横线),代表数据存储;箭头表示数据流,即特定数据的流动方向。

如下图所示:

图符含义在这里插入图片描述数据的源点或终点在这里插入图片描述数据的加工处理在这里插入图片描述数据存储在这里插入图片描述数据流

除了4个基本符号以外,数据流图还有一个附加符号,如下图所示:

图符含义在这里插入图片描述数据A和B同时输入才能变换成数据C在这里插入图片描述数据A变换成B和C在这里插入图片描述数据A或B,或A和B同时输入变换成C在这里插入图片描述数据A变换成B或C,或B和C在这里插入图片描述只有数据A或只有数据B(但不能A、B同时)输入时变换成C在这里插入图片描述数据A变换成B或C,但不能变换成B和C 3.3. 绘制数据流图 3.3.1. 绘制数据流图的步骤

概括地说:自外向内,自顶向下,逐层细化,完善求精。

首先确定系统的输入和输出,以反映系统与外界环境的接口;顶层数据流图将软件系统描述为一个加工,以反映最主要业务处理流程,它代表系统本身。但它并未明确表达数据加工的要求;从输入端开始,根据系统业务工作流程,画出数据流流经的各加工框,以反映数据的实际处理过程,逐步画到输出端,得到第一层数据流图。对图中的加工分别加以编号;细化每一个加工框。如果加工框内还有数据流,可将这个加工框再细分成几个“子加工框”,并在各子加工框之间画出数据流;一次细化一个加工。

数据流图的细化可以连续进行,直到每一个加工只执行一个简单操作为止。就是说,直到每一个加工执行一个可以用程序实现的功能为止。

3.3.2. 成分的命名

数据流图中每个成分的命名是否恰当,直接影响数据流图的可理解性。在命名时应注意的问题:

为数据流(或数据存储)命名 (1)名字应代表整个数据流(或数据存储)的内容,而不是仅仅反映它的某些成分; (2)不要使用空洞的、缺乏具体含义的名字(如"数据"、“信息”、"输入"之类); (3)如果在为某个数据流(或数据存储)起名字时遇到了困难,则很可能是因为对数据流图分解不恰当造成的,应该试试重新分解,看是否能克服这个困难。为处理命名 (1)通常先为数据流命名,然后再为与之相关联的处理命名。这样命名比较容易,而且体现了人类习惯的"由表及里"的思考过程。 (2)名字应该反映整个处理的功能,而不是它的一部分功能; (3)名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用"加工"、"处理"等空洞笼统的动词作名字; (4)通常名字中仅包括一个动词,如果必须用两个动词才能描述整个处理的功能,则把这个处理再分解成两个处理可能更恰当些。 (5)如果在为某个处理命名时遇到困难,则很可能是发现了分解不当的迹象,应考虑重新分解。为数据源点/终点命名 数据源点/终点并不需要在开发目标系统的过程中设计和实现,它并不属于数据流图的核心内容,只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常,为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如"采购员"、"仓库管理员"等)。 3.4. 数据流图的例子

假设一家工厂的采购部每天需要一张订货报表,报表按零件编号排序,表中列出所有需要再次订货的零件。

对于每个需要再次订货的零件应该列出下述数据:零件编号、零件名称、订货数量、目前价格、主要供应者、次要供应者。

零件入库或出库称为事务,通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。

按步骤对题干进行分析,提取数据流图的四种成分:

首先考虑数据的源点和终点,从上面对系统的描述可以知道"采购部每天需要一张订货报表",“通过放在仓库中的CRT终端把事务报告给订货系统”,所以采购员是数据终点,而仓库管理员是数据源点。这其中必须有一个用于产生报表的处理。事务的后果是改变零件库存量,然而任何改变数据的操作都是处理,因此对事务进行的加工是另一个处理。注意,在问题描述中并没有明显地提到需要对事务进行处理,但是通过分析可以看出这种需要。系统把订货报表送给采购部,因此订货报表是一个数据流;事务需要从仓库送到系统中,显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配一每当有一个事务发生时立即处理它,然而每天只产生一次订货报表。因此,用来产生订货报表的数据必须存放一段时间,也就是应该有一个数据存储。

在弄清楚数据流图的成分之后,就开始画数据流图了,首先画出一个顶级数据流图: 在这里插入图片描述

从基本系统模型这样非常高的层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点和终点是一目了然的,因此它是很有价值的通信工具。

下一步应该把基本系统模型细化,描绘系统的主要功能。“产生报表"和"处理事务"是系统必须完成的两个主要功能,它们将代替图的"定货系统”,如下面的一级数据流图: 在这里插入图片描述 接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。

考虑通过系统的逻辑数据流:当发生一个事务时必须首先接收它;随后按照事务的内容修改库存清单;最后如果更新后的库存量少于库存量临界值时,则应该再次定货,也就是需要处理定货信息。

因此,把"处理事务"这个功能分解为"接收事务"、"更新库存清单"和"处理定货"三个步骤,这在逻辑上是合理的,如下面的二级数据流图所示。 在这里插入图片描述 至此,一个详细的数据流图才算画完了。

当用数据流图辅助系统的设计时,以图中不同处理的定时要求为指南,能够在数据流图上画出许多组自动化边界,每组自动化边界可能意味着一个不同的物理系统,因此可以根据系统的逻辑模型考虑系统的物理实现。

例如,事务随时可能发生,因此处理1.1(“接收事务”)必须是联机的;采购员每天需要一次定货报表,因此处理2(“产生报表”)应该以批量方式进行。问题描述并没有对其他处理施加限制。对 L 2 L2 L2划分自动化边界的结果如下图所示: 在这里插入图片描述

3.4. 数据流图的分层

以上绘制数据流图的步骤可以用下面这张分层数据流图来表示,首先绘制最上面一层的顶级数据流图 L 0 L0 L0,然后是第二层的一级数据流图 L 1 L1 L1,再是最下面的二级数据流图 L 2 L2 L2,理论上还可以画出 L 3 L3 L3、 L 4 L4 L4等等。 在这里插入图片描述 如果要产生详细的数据流图就要把所有加工处理都分解成基本加工,所谓基本加工,就是数据流图中所有不能进一步分解的加工,一般有父项、无子项的加工就是基本加工。

3.5. 基本加工说明 PSPEC

PSPEC用来说明DFD中的每个基本加工

可以用的描述工具有:结构化语言、决策树、决策表、盒图、数学公式等等

其中结构化语言也叫作伪代码或者过程设计语言,其介于自然语言和计算机语言之间,通过顺序语句、条件语句和循环语句对基本加工进行描述,例如:

IF 发货单金额超过$500 THEN IF 欠款超过60天 THEN 在偿还欠款前不予批准 ELSE 欠款未超期 发批准书及发货单 ENDIF ELSE 发货单金额未超过$500 IF 欠款超过60天 THEN 发批准书、发货单及催款通知 ELSE 欠款未超期 发批准书及发货单 ENDIF ENDIF

决策树是一种图形工具,适合于描述加工中具有多个策略,而且每个策略和若干条件有关的逻辑功能,例如: 在这里插入图片描述 决策表的内涵与决策树一致,但是适用于如果判断的条件较多,各条件又相互组合的情况,如下表所示:

1234条件发货单金额>$500>$500


【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3