免费智能真题库 > 历年试卷 > 软件设计师 > 2017年上半年 软件设计师 上午试卷 综合知识
  第15题      
  知识点:   数据流图   结构化开发方法   设计阶段   需求分析   需求分析阶段
  关键词:   分析阶段   接口   开发方法   软件开发   设计阶段   需求分析   开发   需求        章/节:   软件工程基础知识       

 
在采用结构化开发方法进行软件开发时,设计阶段接口设计主要依据需求分析阶段的(15)。接口设计的任务主要是(16)。
 
 
  A.  数据流图
 
  B.  E-R图
 
  C.  状态-迁移图
 
  D.  加工规格说明
 
 
 

 
  第17题    2016年上半年  
   33%
在结构化分析中,用数据流图描述(17)。当采用数据流图对一个图书馆管理系统进行分析时,(18)是一个外部实体。
  第15题    2014年下半年  
   41%
以下关于结构化开发方法的叙述中,不正确的是()。
  第29题    2013年上半年  
   41%
在如下所示的数据流图中,共存在(29)个错误。
   知识点讲解    
   · 数据流图    · 结构化开发方法    · 设计阶段    · 需求分析    · 需求分析阶段
 
       数据流图
        数据流图也称数据流程图(Data Flow Diagram,DFD),它是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容,精确地在逻辑上描述系统的功能、输入、输出和数据存储等,是系统逻辑模型的重要组成部分。
        1)数据流图的基本图形元素
        数据流图中的基本图形元素包括数据流(Data Flow)、加工(Process)、数据存储(Data Store)和外部实体(Extemal Agent)。其中,数据流、加工和数据存储用于构建软件系统内部的数据处理模型;外部实体表示存在于系统之外的对象,用来帮助用户理解系统数据的来源和去向。
        (1)数据流。
        数据流由一组固定成分的数据组成,表示数据的流向。在DFD中,数据流的流向可以有以下几种:从一个加工流向另一个加工;从加工流向数据存储(写):从数据存储流向加工(读);从外部实体流向加工(输入);从加工流向外部实体(输出)。
        DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外,每个数据流都必须有一个合适的名字,以反映该数据流的含义。值得注意的是,DFD中描述的是数据流,而不是控制流。
        数据流或者由具体的数据属性(也称为数据结构)构成,或者由其他数据流构成。组合数据流是由其他数据流构成的数据流,它们用于在高层的数据流图中组合相似的数据流,以使数据流图更便于阅读。
        (2)加工。
        加工描述了输入数据流到输出数据流之间的变换,也就是输入数据流经过什么处理后变成了输出数据流。每个加工都有一个名字和编号。编号能反映出该加工位于分层DFD中的哪个层次和哪张图中,也能够看出它是哪个加工分解出来的子加工。
        一个加工可以有多个输入数据流和多个输出数据流,但至少有一个输入数据流和一个输出数据流。
        (3)数据存储。
        数据存储用来存储数据。通常,一个流入加工的数据流经过加工处理后就消失了,而它的某些数据(或全部数据)可能被加工成输出数据流,流向其他加工或外部实体。除此之外,在软件系统中还常常要把某些信息保存下来以供以后使用,这时可以使用数据存储。
        每个数据存储都有一个定义明确的名字标识。可以有数据流流入数据存储,表示数据的写入操作;也可以有数据流从数据向数据存储,表示对数据的修改。
        这里要说明的是,DFD中的数据存储在具体实现时可以用文件系统实现,也可以用数据库系统实现。数据存储的存储介质可以是磁盘、磁带或其他存储介质。
        (4)外部实体(外部主体)。
        外部实体是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。例如,对于一个考务处理系统而言,考生向系统提供报名单(输入数据流),所以考生是考务处理系统的一个源;而考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考试中心,所以考试中心是该系统的一个宿。
        在许多系统中,某个源和某个宿可以是同一个人员或组织,此时,在DFD中可以用同一个符号表示。考生向系统提供报名单,而系统向考生送出准考证,所以在考务处理系统中,考生既是源又是宿。
        源和宿采用相同的图形符号表示,当数据流从该符号流出时,表示它是源;当数据流流向该符号时,表示它是宿;当两者皆有时,表示它既是源又是宿。
        2)数据流图的扩充符号
        在DFD中,一个加工可以有多个输入数据流和多个输出数据流,此时可以加上一些扩充符号来描述多个数据流之间的关系。
        (1)星号(*)。
        星号表示数据流之间存在"与"关系。如果是输入流则表示所有输入数据流全部到达后才能进行加工处理;如果是输出流则表示加工结束将同时产生所有的输出数据流。
        (2)加号(+)。
        加号表示数据流之间存在"或"关系。如果是输入流则表示其中任何一个输入数据流到达后就能进行加工处理;如果是输入流则表示加工处理的结果是至少产生其中一个输出数据流。
        (3)异或(⊕)。
        异或表示数据流之间存在"互斥"关系。如果是输入流则表示当且仅当其中一个输入流到达后才能进行加工处理;如果是输出流则表示加工处理的结果是仅产生这些输出数据流中的一个。
        3)数据流图的层次结构
        从原理上讲,只要纸足够大,一个软件系统的分析模型就可以画在一张纸上。然而,一个复杂的软件系统可能涉及上百个加工和上百个数据流,甚至更多。如果将它们画在一张图上,则会十分复杂,不易阅读,也不易理解。
        根据自顶向下逐层分解的思想,可以将数据流图按照层次结构来绘制,每张图中的加工个数可大致控制在"7加减2"的范围内,从而构成一套分层数据流图。
        (1)层次结构。
        分层数据流图的顶层只有一张图,其中只有一个加工,代表整个软件系统,该加工描述了软件系统与外界之间的数据流,称为顶层图。
        顶层图中的加工(即系统)经分解后的图称为0层图,也只有一张。处于分层数据流图最底层的图称为底层图,在底层图中,所有的加工不再进行分解。分层数据流图中的其他图称为中间层,其中至少有一个加工(也可以是所有加工)被分解成一张子图。在整套分层数据流图中,凡是不再分解成子图的加工称为基本加工。
        (2)图和加工的编号。
        首先介绍父图和子图的概念。
        如果某图(记为A)中的某一个加工分解成一张子图(记为B),则称A是B的父图,B是A的子图。若父图中有n个加工,则它可以有0一刀张子图,但每张子图只对应一张父图。
        为了方便对图进行管理和查找,可以采用下列方式对DFD中的图和加工编号。
        ①顶层图中只有一个加工(代表整个软件系统),该加工不必编号。
        ②0层图中的加工编号分别为1、2、3--。
        ③子图号就是父图中被分解的加工号。
        ④对于子图中加工的编号,若父图中的加工号为X的加工分解成某一子图,则该子图中的加工编号分别为x.1、x.2、X.3…。
        4)分层数据流图的审查
        在分层数据流图画好后,应该认真检查图中是否存在错误或不合理(不理想)的部分。
        (1)分层数据流图的一致性和完整性。
        ①分层数据流图的一致性。
        a.父图与子图的平衡。
        b.数据守恒。
        c.局部数据存储。
        d.一个加工的输出数据流不能与该加工的输入数据流同名。
        ②分层数据流图的完整性。
        a.每个加工至少有一个输入数据流和一个输出数据流。
        b.在整套分层数据流图中,每个数据存储应至少有一个加工对其进行读操作,另一个加工对其进行写操作。
        c.分层数据流图中的每个数据流和文件都必须命名(除了流入或流出数据存储的数据流),并保持与数据字典一致。
        d.分层数据流图中的每个基本加工都应有一个加工规约。
        (2)构造分层DFD时需要注意的问题。
        ①适当命名。
        a.名字应反映整个对象(如数据流、加工),而不是只反映它的某一部分。
        b.避免使用空洞的、含义不清的名字,如"数据""信息""处理""统计"等。
        c.如果发现某个数据流或加工难以命名,往往是DFD分解不当的征兆,此时应考虑重新分解。
        ②画数据流而不是控制流。
        ③避免一个加工有过多的数据流。
        a.把需要重新分解的某张图的所有子图连接成一张图。
        b.把连接后的图重新划分成几个部分,使各部分之间的联系最小。
        c.重新定义父图,即第b步中的每个部分作为父图中的一个加工。
        d.重新建立各子图,即第b步中的每个部分都是一张子图。
        e.为所有的加工重新命名并编号。
        ④分解尽可能均匀。
        ⑤先考虑确定状态,忽略琐碎的细节。
        ⑥随时准备重画。
        (3)分解的程度。
        在自顶向下画数据流图时,为了便于对分解层数进行把握,可以参照以下几条与分解有关的原则。
        ①7加减2。
        ②分解应自然,概念上应合理、清晰。
        ③只要不影响DFD的易理解性,可适当增加子加工数量,以减少层数。
        ④一般来说,上层分解得快一些(即多分解几个加工),下层分解得慢一些(即少分解几个加工)。
        ⑤分解要均匀。
 
       结构化开发方法
        结构化方法由结构化分析、结构化设计、结构化程序设计构成,它是一种面向数据流的开发方法。结构化分析是根据分解与抽象的原则,按照系统中数据处理的流程,用数据流图来建立系统的功能模型,从而完成需求分析工作。结构化设计是根据模块独立性准则、软件结构优化准则将数据流图转换为软件的体系结构,用软件结构图来建立系统的物理模型,实现系统的概要设计。结构化程序设计是根据结构程序设计原理,将每个模块的功能用相应的标准控制结构表示出来,从而实现详细设计。
        结构化方法总的指导思想是自顶向下、逐层分解,它的基本原则是功能的分解与抽象。它是软件工程中最早出现的开发方法,特别适合于数据处理领域的问题,但是不适合解决大规模的、特别复杂的项目,且难以适应需求的变化。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        (1)了解建设单位的建设需求和对信息系统安全性的要求,协助建设单位制定项目质量目标规划和安全目标规划。
        (2)对各种设计文件提出设计质量标准。
        (3)进行设计过程跟踪,及时发现质量问题,并及时与承建单位协调解决。审查阶段性成果,并提出监理意见。审查承建单位提交的总体设计方案,审查承建单位对关键部位的测试方案。
        (4)协助承建单位建立质量保障体系。
        (5)协助承建单位完善现场质量管理制度。
        (6)组织设计文件及设计方案交底会,制定质量要求标准。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
       需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。
   题号导航      2017年上半年 软件设计师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第15题    在手机中做本题