免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2016年上半年 信息系统项目管理师 上午试卷 综合知识
  第12题      
  知识点:   信息系统开发方法   分包   基本组成   软件设计   设计过程   数据流   数据流图
  关键词:   分包   软件设计   数据流图   数据        章/节:   信息系统及其技术和开发方法       

 
绘制数据流图是软件设计过程的一部分,用以表明信息在系统中的流向。数据流图的基本组成分包括(12)。
 
 
  A.  数据流、加工、数据存储和外部实体
 
  B.  数据流的源点和终点、数据存储、数据文件和外部实体
 
  C.  数据的源点和终点、加工、数据和数据流文件
 
  D.  数据、加工和数据存储
 
 
 

 
  第10题    2013年下半年  
   39%
常用的软件需求分析方法有很多,其中面向数据流的分析方法是(10)。
  第2题    2014年上半年  
   28%
(2)不属于信息系统项目的生命周期模型。
  第1题    2014年上半年  
   52%
结构化法是信息系统开发的常用方法之一,它将信息系统软件生命大致分为系统规划、系统分析、系统设计、系统实施和系统维护5个阶段..
   知识点讲解    
   · 信息系统开发方法    · 分包    · 基本组成    · 软件设计    · 设计过程    · 数据流    · 数据流图
 
       信息系统开发方法
        信息系统常用的开发方法有结构化方法、原型法和面向对象方法。
        1.结构化方法
        结构化方法是应用最为广泛的一种开发方法。按照信息系统生命周期,应用结构化系统开发方法,把整个系统的开发过程分为若干阶段,然后一步一步依次进行。
        结构化方法具有如下特点:
        .遵循用户至上的原则。
        .严格区分工作阶段,每个阶段有明确的任务和取得的成果。
        .强调系统开发过程的整体性和全局性。
        .系统开发过程工程化,文档资料标准化。
        结构化方法的优点有:
        .理论基础严密,它的指导思想是用户需求在系统建立之前就能被充分了解和理解。
        .注重开发过程的整体性和全局性。
        结构化方法的缺点有:
        .开发周期长。
        .文档、设计说明烦琐,工作效率低。
        .要求在开发之初全面认识系统的信息需求。
        .如果用户参与系统开发的积极性没有充分调动,可能造成系统交接过程不平稳,系统运行与维护难度加大。
        结构化分析(Structured Analysis,SA)方法
        结构化分析方法由美国Yourdon公司在20世纪70年代提出,是一种简单实用、使用很广的方法。该方法通常与系统设计阶段的结构化设计(SD)方法衔接起来使用,适用于大型信息系统的开发。
        结构化分析方法是一种单纯的自顶向下、逐步求精的功能分解方法,是一种面向数据流的分析方法。其核心特征是“分解”和“抽象”,下层是上层的分解,上层是下层的抽象。
        结构化系统分析和设计方法的基本思想是用系统的思想、系统工程的方法,按用户至上的原则,结构化、模块化、自上而下对信息系统进行分析与设计。
        2.原型法
        原型法在很难全面准确提出用户需求的情况下,本着对用户需求的初步理解,先快速开发一个原型系统,然后通过反复修改来实现用户的最终系统需求。
        原型应当具备的特点如下:
        .实际可行。
        .具有最终系统的基本特征。
        .构造方便、快速,造价低。
        原型分类如下:
        .抛弃型原型:此类原型在系统真正实现以后就放弃不用了。
        .进化型原型:此类原型的构造从目标系统的一个或几个基本需求出发,通过修改和追加功能的过程逐渐丰富,演化成最终系统。
        原型法的特点如下:
        .对用户的需求是动态响应、逐步纳入的,相互之间并无明显界限,也没有明确分工。
        .系统开发计划是一个反复修改的过程。
        .适用于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发。
        .如果用户配合不好,盲目修改,就会拖延开发过程。
        3.面向对象方法
        面向对象方法的基本思想如下:
        .客观事物是由对象组成的,对象是在原事物基础上抽象的结果。
        .对象是由属性和操作组成的,其属性反映了对象的数据信息特征,而操作则用来定义改变对象属性状态的各种操作方式。
        .对象之间的联系通过消息传递机制来实现,而消息传递的方式是通过消息传递模式和方法所定义的操作过程来完成的。
        .对象可以按其属性来归类,借助类的层次结构,子类可以通过继承机制获得其父类的特征。
        .对象具有封装的特性,一个对象就构成一个严格模块化的实体,在系统开发中可被共享和重复引用,达到软件复用的目的。
        在系统开发实际工作中,往往根据需要将多种开发方法进行组合应用,具体组合形式可以分为如下几种:
        .结构化方法与原型法的结合使用。
        .结构化方法与面向对象方法的组合使用。
        .原型法与面向对象方法的组合使用。
 
       分包
        中标人应当按照合同约定履行义务,完成中标项目。中标人不得向他人转让中标项目,也不得将中标项目肢解后分别向他人转让。中标人按照合同约定或者经招标人同意,可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件,并不得再次分包。中标人应当就分包项目向招标人负责,接受分包的人就分包项目承担连带责任。
 
       基本组成
        防火墙主要包括以下5个部分:安全操作系统、过滤器、网关、域名服务、函件处理。
        (1)安全操作系统。防火墙本身必须建立在安全操作系统中,由安全操作系统来保护防火墙的源代码和文件免遭入侵者的攻击。
        (2)过滤器。外部过滤器保护网关不受攻击,内部过滤器在网关被攻破后提供对内部网络的保护。
        (3)网关。提供中继服务,辅助过滤器控制业务流。可以在其上执行一些特定的应用程序或服务器程序,这些程序统称为"代理程序"。
        (4)域名服务。将内部网络的域名和Internet相隔离,使内部网络中主机的IP地址不至于暴露给Internet中的用户。
        (5)函件处理。保证内部网络用户和Internet用户之间的任何函件交换都必须经过防火墙处理。
 
       软件设计
               软件设计的任务
               在给定系统的需求规格说明书后,需要对软件的结构进行设计,并对设计的过程进行管理。在嵌入式系统的软件设计过程中,需要完成以下一些任务。
                      准备工作计划
                      在软件设计之前,首先要制订详细的工作计划,其内容包括:
                      .过程管理方案:包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等;
                      .开发环境的准备方案:包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等;
                      .软硬件联机调试的方案:联调的起始时间、地点、人员和具体的准备工作;
                      .质量保证方案:包括质量目标计划、质量控制计划等;
                      .配置控制方案:包括配置控制文档的编写、配置控制规则的制订等。
                      确定软件的结构
                      设计软件的各个组成部分,包括:
                      .任务结构的设计:使用操作系统提供的函数,设计出一个最佳的任务结构;
                      .线程的设计;
                      .公共数据结构的设计:在确保系统一致性的基础上,设计出所需的公共数据;
                      .操作系统资源的定义;
                      .类的设计;
                      .模块结构设计:在设计时要充分考虑模块的划分、标准化、可重用和灵活性等;
                      .内存的分配与布局。
                      设计评审
                      对于软件设计的结果,进行一次设计评审,并在必要时对设计进行修正。具体内容包括:
                      .确认每件工作的执行方法是否恰当,其内容是否完善;
                      .确认该设计完成了系统需求规格说明书所要求的功能和服务;
                      .评估任务结构设计、评估类的设计、评估模块结构设计;
                      .对软件设计的结果进行总结,编写出相应的文档。
                      维护工作计划
                      执行软件设计工作控制,在每日、每周和每月的时间粒度上对进度进行控制,确保软件设计能够如期完成。
                      与硬件部门密切合作、相互协调
                      根据工作计划中的安排,定期与硬件部门召开会议,协调各自的进展。如果软件规格说明书发生了变化,立即进行调整,重新进行软件设计。
                      控制工作的结果,把工作记录存档
                      掌握当前的工作进展情况,尽早地发现和分析问题,并采取相应的措施。对各种事件进行跟踪记录,包括:
                      .执行过程控制,跟踪进展情况并定期记录、存档。
                      .执行质量控制,保留质量记录。
                      .记录产品的配置、版本变化、bug的发现和处理等信息。
               软件架构设计
               软件架构也称为软件体系结构,需要考虑如何对系统进行分解,对分解后的组件及其之间的关系进行设计,满足系统的功能和非功能需求。软件架构形成过程如下图所示。
               
               架构的形成过程概要
               软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变,随后的架构设计需要通过一系列的迭代开发完善,使得软件架构日趋成熟、稳定。
               软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构,包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐,确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求,也具有可扩展、可移植性,从而为一个软件带来长久的生命力。
               在大量开发实践中,有很多广泛使用并被普遍接受的软件架构设计原则,这些原则独立于具体的软件开发方法,主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
               (1)抽象:这是软件架构的核心原则,也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性,从具体的事务中通过封装来忽略细节,并且运用这些特征和属性,描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象,从而有多个不同层次架构。
               (2)信息隐藏:包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中,减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
               (3)强内聚和松耦合:强内聚是指软件组件内的特性,即组件内所有处理都高度相关,所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性,软件组件之间应尽量做到没有或极少的直接关系,使其保持相对独立,这样使得未来的修改、复用简单,修改之后带来的影响最小。
               (4)关注点分离:所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件,需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分,使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单,那么就更容易理解和实现。但“展示某些关注点得到满足时,可能会影响到其他方面的关注点,但架构师必须能够说明所有关注点都已得到满足”。
               以上的原则中,删除需求细节或对细节进行抽象是最重要的工作,为用户的需求创建抽象模型,通过抽象将特殊问题映射为更普遍的问题类别,并识别各种模式。
               软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层,横向分解就是将每一个层面分成相对独立的部分。经过分解之后,可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装,功能独立、功能高度内聚、之间低耦合的一个组件。
               类似于建筑架构,软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性,好的软件架构也给人完整、明确、清晰等赏心悦目的感觉,具有较长的生命力。
               架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则,在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素,而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒,架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础,在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计,开发人员需要关注各子问题或要素的进一步分解和实现,是根据架构设计所定义的每个要素的功能、接口,进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下,考虑实现组件内部的细节及其实现方法。对于其中的公共子问题,形成公共类和工具类,从而可以达到重用的目的。
               一般的软件构架是根据需求自上而下方式来设计,即首先掌握和研究利益相关方的关键需求,基本思路是首先进行系统级的软件架构设计,需要将软件组件与其外部环境属性绑定在一起,关注软件系统与外部环境的交联设计;其次将一个大的系统划分成各组成部分,这些部分可以按照架构设计的不同方法,分为层次或成为模块;之后再开始研究所涉及到的要素,再实现这些要素以及定义这些要素之间的关系。
               在实际工作中,软件构架也可采用自底向上的方法,前提是已经建立了一个成熟稳定的软件架构,也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路,是为了解决共有问题解的方案模板,但并不是一个问题的设计或设计算法。
               模式常常整合在一起使用,提供解决更大、更复杂问题的解决方案,而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具,而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架,这时其他重要元素可以在这个架构基础上针对新的需求进行扩展,有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计,采用成熟的先进的设计框架和工具提高开发的效率,保证设计正确性。
               下图所示是针对架构设计中非功能需求的多维度分析,从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分,但超越了系统内部的算法和数据结构的详细设计。
               
               架构的多维度分析
               在架构设计阶段,需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
               软件设计方法
               在将系统分解为各个组件的过程中,需要采取不同的策略,而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略,设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。
               (1)基于功能分解的设计方法。实时结构化分析与设计采用了功能分解,系统被分解为多个函数,并且以数据流或控制流的形式定义函数之间的接口;基于并发任务结构化的设计(Design Approach for Real-Time Systems,DARTS)提供了任务结构化标准,辅助人员确定系统中的并发任务,并指导定义任务接口。
               (2)基于信息隐藏的设计方法。面向对象(Object Oriented,OO)设计方法将数据和数据上操作封装在对象实体中,对象外界不能够直接对对象内部进行访问和操作,只能通过消息间接访问对象,符合人类思维方式,提高软件的扩展性、维护性和重用性。
               (3)基于模型驱动开发的设计方法。通过借助有效的(Model Driven Development,MDD)工具,构建和维护复杂系统的设计模型,直接产生高质量的代码,将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。
 
       设计过程
        结构化设计的过程如下。
        (1)精化DFD。
        (2)确定DFD的信息流类型(变换流或事务流)。
        (3)根据流类型分别将变换流或事务流转换成程序结构图。
        (4)根据软件设计的原则对程序结构图做优化。
        (5)描述模块功能、接口及全局数据结构。
        (6)复查。
 
       数据流
        数据流由一组固定成分的数据组成,表示数据的流向。在DFD中,数据流的流向可以有以下几种:从一个加工流向另一个加工;从加工流向数据存储(写);从数据存储流向加工(读);从外部实体流向加工(输入);从加工流向外部实体(输出)。
        DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外,每个数据流都必须有一个合适的名字,以反映该数据流的含义。
        数据流或者由具体的数据属性(也称为数据结构)构成,或者由其他数据流构成。组合数据流是由其他数据流构成的数据流,它们用于在高层的数据流图中组合相似的数据流,以使数据流图更便于阅读。
        控制流是对数据流图的补充,采用虚线表示,是对由触发系统功能的事件进行描述。
        另外,一个加工可以有多个输入数据流和多个输出数据流,此时可以加上一些扩充字符符号或图形元素来描述多个数据流之间的关系。如:
        (1)星号(*)。星号表示数据流之间存在“与”关系。如果是输入流则表示所有输入数据流全部到达后才能进行加工处理;如果是输出流则表示加工结束将同时产生所有的输出数据流。
        (2)加号(+)。加号表示数据流之间存在“或”关系。如果是输入流则表示其中任何一个输入数据流到达后就能进行加工处理;如果是输出流则表示加工处理的结果是至少产生其中一个输出数据流。
        (3)异或(⊕)。异或表示数据流之间存在“互斥”关系。如果是输入流则表示当且仅当其中一个输入流到达后才能进行加工处理;如果是输出流则表示加工处理的结果是仅产生这些输出数据流中的一个。
 
       数据流图
        数据流图(Data Flow Diagram,DFD)是一种最常用的结构化分析工具,它从数据传递和加工的角度,以图形的方式刻画系统内数据的运动情况。数据流图是一种能全面地描述信息系统逻辑模型的主要工具,它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储的情况。数据流图具有抽象性和概括性。抽象性表现在它完全舍去了具体的物质,只剩下数据的流动、加工处理和存储;概括性表现在它可以把信息中的各种不同业务处理过程联系起来,形成一个整体。无论是手工操作部分还是计算机处理部分,都可以用它表达出来。因此,我们可以采用DFD这一工具来描述管理信息系统的各项业务处理过程。
        (1)数据流图的基本成分。
        数据流图用到4个基本符号,即外部实体、数据流、数据存储和处理逻辑,如下图所示。
        
        数据流图的基本成分
        ①外部实体。外部实体指不受系统控制,在系统以外又与系统有联系的事物或人,它表达了目标系统数据的外部来源或去处。例如,顾客、职工、供货单位,等等。外部实体也可以是另外一个信息系统。
        外部实体用一个正方形,并在其左上角外边另加一个直角来表示,在正方形内写上该外部实体的名称。为了区分不同的外部实体,可以在正方形的左上角用一个字符表示。在数据流图中,为了减少线条的交叉,同一个外部实体在一张数据流图中可以出现多次,这是在该外部实体符号的右下角画斜线,表示重复。若重复的外部实体有多个,则相同的外部实体画数目相同的斜线,如下图所示。
        
        外部实体
        ②数据流。数据流表示数据的流动方向,用一个水平箭头或垂直箭头表示。数据流可以是订单、发票等。数据流一般不会是单纯的数据,而是由一些数据项组成。例如“发票”数据流由品名、规格、单位、单价、数量等数据项组成。
        一般来说,对每个数据流要加以简单地描述,使用户和系统设计员能够理解一个数据流的含义。对数据流的描述写在箭头的上方,一些含义十分明确的数据流,也可以不加以说明,如下图所示。
        
        数据流的图示
        ③数据存储。数据存储表示数据保存的地方。这里的“地方”并不是指保存数据的物理地点或物理介质,而是指数据存储的逻辑描述。所以这里的数据存储是逻辑意义上的数据存储环节,即系统信息处理功能需要的,不考虑存储的物理介质和技术手段的数据存储环节。
        在数据流图中,数据存储用一个右边开口的长方形条来表示,图形右部填写存储的数据和数据集的名字,名字要恰当,以便用户理解。左边填写该数据存储的标识,用字母D和数字组成。同一数据存储可在一张数据流图中出现多次,这时在数据存储符号上画竖线,表示重复。
        指向数据存储的箭头,表示送数据到数据存储(存放、改写等);从数据存储发出的箭头,表示从数据存储读取数据,如下图所示。
        
        数据存储
        ④处理逻辑(加工)处理逻辑指对数据的逻辑处理功能,也就是对数据的变换功能。它包括两方面的内容:一是改变数据结构;二是在原有数据内容基础上增加新的内容,形成新的数据。
        在数据流图中,处理逻辑可以用一个带圆角的长方形来表示,长方形分为三个部分,如下图所示。
        
        处理逻辑
        标识部分用来标明一个功能,一般用字符串表示,如P1,P1.1等。
        功能描述部分是必不可少的,它直接表达这个处理逻辑的逻辑功能。一般用一个动词加一个作动词宾语的名词表示。不过要恰如其分地表达一个处理的功能,有时候需要下一番功夫。
        功能执行部分表示这个功能由谁来完成,可以是一个人,也可以是一个部门,甚至可以是某个计算机程序。
        (2)数据流图的绘制。
        由于数据流图在系统建设中的重要作用,绘制数据流图必须坚持正确的原则和运用科学的方法。绘制数据流图应遵循的主要原则如下。
        ①确定外部项。一张数据流图表示某个子系统或某个系统的逻辑模型。系统分析人员要根据调查材料,首先识别出那些不受所描述的系统的控制,但又影响系统运行的外部环境,这就是系统的数据输入的来源和输出的去处。要把这些因素都作为外部项确定下来。确定了系统和外部环境的界面,就可集中力量分析,确定系统本身的功能。
        ②自顶向下逐层扩展。信息系统庞大而复杂,具体的数据加工可能成百上千,关系错综复杂,不可能用一两张数据流图明确、具体地描述整个系统的逻辑功能,自顶向下的原则为我们绘制数据流图提供了一条清晰的思路和标准化的步骤。
        ③合理布局。数据流图的各种符号要布局合理,分布均匀、整齐、清晰,使读者一目了然。这才便于交流,避免产生误解。一般要把系统数据主要来源的外部项尽量安排在左方,而要把数据主要去处的外部项尽量安排在右边,数据流的箭头线尽量避免交叉或过长,必要时可用重复的外部项和重复的数据存储符号。
        ④数据流图只反映数据流向、数据加工和逻辑意义上的数据存储,不反映任何数据处理的技术过程、处理方式和时间顺序,也不反映各部分相互联系的判断与控制条件等技术问题。这样,只从系统逻辑功能上讨论问题,便于和用户交流。
        ⑤数据流图绘制过程,就是系统的逻辑模型的形成过程,必须始终与用户密切接触、详细讨论、不断修改,也要和其他系统建设者共同商讨以求一致意见。
        (3)数据流图的改进。
        对每个系统都有一个逐步熟悉和深化的过程,因此在画数据流图时难免会有这样或那样的错误,这就需要对数据流图做进一步的改进。一般可从下面两个方面着手。
        ①检查数据流图的正确性。
        .数据是否守恒,即输入数据与输出数据是否匹配。数据不守恒的情况有两种。一种是某个处理过程产生输出数据,但没有输入数据给该处理过程,这肯定是某些数据流被遗漏了。另一种是有输入数据给处理过程,但没有输出数据,这种情况不一定是错误,但必须认真加以推敲:为什么将这些数据输入给这个处理过程,而处理过程却不利用它产生输出?如果确实是不必要的,就可将它去掉,以简化处理逻辑之间的联系。
        .数据存储的使用是否恰当。在一套数据流图中的任何一个数据存储,必定有流入的数据流和流出的数据流,即写文件和读文件,缺少任何一种都意味着遗漏了某些处理逻辑。
        .父图和子图是否平衡。父图中某一处理框的输入、输出数据流必须出现在相应的子图中,否则就会出现父图与子图的不平衡。父图和子图的数据流不平衡是一种常见的错误现象。尤其是在对子图进行修改时(如添加或删除某些数据流),必须仔细检查其父图是否要做相应的修改,以保持数据流的平衡。父图与子图的关系,类似于全国地图与各省地图的关系。在全国地图上标出主要的铁路、河流,在各省地图上标得则更详细,除了有全国地图上与该省相关的铁路、河流之外,还有一些次要的铁路、公路、河流等。
        .任何一个数据流至少有一端是处理框。换句话说,数据流不能从外部实体直接到数据存储,也不能从数据存储直接到外部实体,也不能在外部实体之间或数据存储之间流动。初学者往往容易违反这一规定,常常在数据存储与外部实体之间画数据流。其实,记住数据流是处理功能的输入或输出,就不会出现此类错误。
        ②提高数据流图的易理解性。
        数据流图是系统分析员进行业务调查,与用户沟通的重要工具。因此,数据流图应该简明易懂。这也有利于后面的设计,有利于对系统规格说明书进行维护。可以从以下几个方面提高易理解性。
        .简化处理间的联系。结构化分析的基本手段是“分解”,其目的是控制复杂性。合理的分解是将一个复杂的问题分成相对独立的几个部分,每个部分可被单独理解。在数据流图中,将一个处理逻辑分解成若干个子处理逻辑,并使各子处理逻辑尽可能地相对独立、处理逻辑间的数据流尽可能地少、每个处理逻辑的输入和输出数据流数目尽可能地少,这样每一个处理逻辑就比较容易被单独地理解,因而一个复杂的处理逻辑也就被几个较简单的子处理逻辑代替了。
        .保持分解的均匀性。理想的分解是将一个加工分成大小均匀的几个子加工。如果在一张数据流图上,某几个已经是不必再分解的基本加工,而另一些加工却还要进一步分解三四层,这样的分解就不均匀。不均匀的分解是不容易被理解的。因为其中一些已是细节,而另一些仍然是较高层次上的抽象。在这种情况下应考虑重新分解,应努力避免特别不均匀的分解。
        .适当命名。给数据流图中的各个成分取一个适当的名字无疑是提高其易理解性的重要手段之一。比如处理框的命名应能准确地表达其功能,理想的命名由一个具体的动词加一个具体的名词(宾语)组成,在下层尤其应该如此。例如“计算总工作量”、“开发票”。而最好将“存储和打印提货单”分成两个。“处理订货单”则不太好,“处理”是空洞的动词,没有说明究竟做什么。如果难以为某个成分取合适的名字,那么往往是分解不当的迹像,这时可以考虑重新分解。
        数据流图也常常需要重新分解。例如画到某一层时意识到上一层或上几层所犯的错误,这时就需要对它们重新分解。重新分解可按下述步骤进行:
        .把需要重新分解的数据流图的所有子图拼接成一张图。
        .把新拼接成的图分成几个部分,使各部分之间的联系最少。
        .重新建立父图,即把第②步所得的每一部分画成一个处理框。
        .重新建立各张子图,这只需要把第②步所得的图沿各个部分边界分开即可。
        .为所有处理重新命名和编号。
        (4)数据流图举例。
        下面我们以高等学校学籍管理系统为例,说明画数据流图的方法。学籍管理是一项十分严肃而复杂的工作。它要记录学生从入学到离校,整个在校期间的情况,学生毕业时把学生的情况提供给用人单位。学校还要向上级主管部门报告学籍的变动情况。
        下图一所示概括描述了系统的轮廓、范围,标出了最主要的外部实体和数据流。它是进一步分析的出发点。学籍管理包括学生学习成绩管理、学生奖惩管理、学生异动管理三个部分。由此,下图一可以展开为下图二。虚线框是下图一中处理逻辑的放大。下面以“成绩管理”为例,说明逐层分解的思路。
        
        学籍管理系统顶层图
        
        学籍管理系统的第一层数据流图
        某校现在实行校、系两级管理学习成绩。学校教学管理科、系教务员都登记学生成绩。任课教师把学生成绩单一式两份分别送系教务员和学校教学管理科。系教务员根据成绩单登录学籍表,学期结束时,给学生发成绩通知,根据学籍管理条例确定每个学生升级、补考、留级、退学的情况。教学管理科根据收到的成绩单登录教管科存的学籍表,统计各年级各科成绩分布,报主管领导。补考成绩也做类似处理,这样P2框扩展成下图。
        
        “成绩管理”框的展开
        在上图中的一些处理,有的框还需要进一步展开,如P2.1框,但在这里我们不再一一展开。
   题号导航      2016年上半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第12题    在手机中做本题