免费智能真题库 > 历年试卷 > 系统架构设计师 > 2020年下半年 系统架构设计师 上午试卷 综合知识
  第29题      
  知识点:   测试工具   开发过程   软件开发工具   图形   需求定义   需求分析   编码   开发工具   需求分析工具
  章/节:   软件开发环境与工具       

 
对应软件开发过程的各种活动,软件开发工具需求分析工具、(29)、编码与排错工具、测试工具等。按描述需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于(30)的工具。
 
 
  A.  设计工具
 
  B.  分析工具
 
  C.  耦合工具
 
  D.  监控工具
 
 
 

 
  第29题    2019年下半年  
   43%
软件开发工具是指用于辅助软件开发过程活动的各种软件,其中,   (29)   是辅助建立软件系统的抽象模..
  第30题    2019年下半年  
   38%
软件开发工具是指用于辅助软件开发过程活动的各种软件,其中,   (29)   是辅助建立软件系统的抽象模..
  第30题    2020年下半年  
   52%
对应软件开发过程的各种活动,软件开发工具有需求分析工具、(29)、编码与排错工具、测试工具等。按描述需求定义的方法可将需求分..
   知识点讲解    
   · 测试工具    · 开发过程    · 软件开发工具    · 图形    · 需求定义    · 需求分析    · 编码    · 开发工具    · 需求分析工具
 
       测试工具
        测试工具是指辅助测试过程活动的各类软件,通常可分为白盒测试工具、黑盒测试工具和测试管理工具等。比较有代表性的白盒测试工具包括Compuware的Numega系列工具、ParaSoft的Java Solution和C/C++Solution系列工具以及开放源代码的以Junit、Dunit、HttpUnit为代表的Xunit系列工具;比较有代表性的黑盒测试工具包括Mercury Interactive的TestSuite系列工具、IBM Rational的TestStudio系列工具和Compuware的QACenter系列工具;比较有代表性的测试管理工具包括Mercury Interactive的TestDirector、Empirix的d-Tracker、Segue的Silkplanpro、Compuware的TrackRecord和IBM Rational的ClearQuest。
        下面重点介绍Mercury Interactive公司的功能测试工具WinRunner、性能负载测试工具LoadRunner和测试管理工具TestDirector。
        WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能以及是否能够正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
        LoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRuner能够对整个企业架构进行测试。通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助开发人员更快地查找和发现问题。此外,LoadRunner能支持广泛的协议和技术,为特殊环境提供特殊地解决方案。
        TestDirector是业界第一个基于Web的测试管理系统,它可以在公司内部或外部进行全球范围内测试的管理。TestDirector在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理、测试计划、测试执行以及错误跟踪等功能。TestDirector能消除组织机构间、地域间的障碍,让测试人员、开发人员或其他人员通过一个中央数据仓库,在不同地方交互测试信息。TestDirector将测试过程流水化,从测试需求管理,到测试计划、测试日程安排、测试执行,再到出错后的错误跟踪,仅在一个基于浏览器的应用中便可完成,而不需要每个客户端都安装一套客户端程序。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
 
       软件开发工具
        软件开发工具是指用于辅助软件开发过程活动的各种软件,包括建模工具、分析设计工具、编程工具、测试工具、项目管理工具等。
               建模工具
               简单地说,建模就是建立软件系统的抽象模型。系统模型贯穿于软件生命周期的整个过程,包括分析模型、设计模型、实现模型、测试模型等,但通常所说的“系统模型”主要指分析模型和设计模型。
               UML建模专家提出了建模工具应该具有的8条特性:
               (1)全面支持UML。
               (2)能自动保持源代码和模型的同步,无须人工干预。
               (3)具有强大的文档生成能力。
               (4)能与软件工程领域的其他工具进行集成。
               (5)能支持团队工作。
               (6)支持设计模式。
               (7)支持重构。
               (8)具有逆向工程能力。
               目前,典型的建模工具有Rose、Together、WinA&D、QuickUML、Metamill等。
               IBM Rational公司的Rose是UML建模的主要工具之一,为大型软件工程提供了可塑性和柔韧性极强的解决方案,能够完成正向建模和逆向建模工作。
               Borland公司的Together Designer Community Edition是一个与平台、语言和IDE(Integrated Development Environment,集成开发环境)无关的建模应用软件,支持所有的UML图形,可以将模型以XML规范的方式导出。
               Excel公司的WinA&D是一种用于需求管理、软件建模、代码生成、再工程以及报告生成的工程工具,可进行基于UML的面向对象的分析和设计、结构化分析和设计、多任务设计和数据库设计。
               Excel公司的QuickUML是一种提供UML主要模型之间的紧密结合及同步的面向对象的建模工具。QuickUML通过卡片窗口的形式提供对用例、类模型、对象模型、字典和代码的支持,支持跨平台和不同的编程语言。
               Metamill公司的Metamill的是一个基于UML的可视化建模工具,具有直觉而快捷的用户接口,支持对C、C++、C#和Java的双向代码工程,支持HTML文档生成。
               设计工具
               设计工具是指辅助软件设计过程活动的各种软件,它辅助设计人员从软件的需求分析模型出发,得到相应的设计模型。常用的设计工具包括面向对象的设计工具、结构化设计工具和数据库设计工具等。
               在面向对象的设计工具方面,全部建模工具均可作为面向对象的设计工具,目前软件设计人员最常用的设计工具就是IBM Rational Rose。除此之外,IBM Rational的Software Architect和Software Modeler也经常用于软件架构设计。
               在结构化设计工具方面,根据结构化方法学,软件系统的设计模型通常采用模块结构图、E-R图和流程图等图形元素描述,WinA&D可以辅助结构化设计活动。
               在数据库设计工具方面,主要有Rose Data Modeler、PowerDesigner、AllFusion ERwin Data Modeler等。
               IBM Rational公司的Rose Data Modeler是一个独特的基于UML的数据库设计工具,它使数据库设计人员、业务分析人员和开发人员——所有需要理解数据库构造,以及数据库与应用程序之间的交互和映射方式的人员可以用同一种工具和语言协同合作。
               Sybase公司的PowerDesigner是最具集成特性的设计工具集,用于创建高度优化和功能强大的数据库、数据仓库以及与数据密切相关的构件。PowerDesigner提供了一个完整的数据库设计解决方案,业务或系统分析人员、设计人员、数据库管理员和开发人员可以对其裁剪,以满足他们的特定需要,而其模块化的结构为用户购买和扩展提供了极大的灵活性,从而使开发单位可以根据其项目的规模和范围来使用他们所需要的工具。
               Computer Associates公司的AllFusion ERwin Data Modeler 4.0(简称ERwin)是关系数据库应用开发的优秀CASE工具,可用来建立E-R模型。ERwin可以方便地构造实体和联系,表达实体间的各种约束关系,并根据模板创建相应的存储过程、包、触发器、角色等,还可编写相应的PowerBuilder扩展属性,如编辑样式、显示风格、有效性验证规则等。
               编程工具
               编程工具是指辅助编程过程活动的各类软件。从方法学上分类,可分为结构化编程工具和面向对象的编程工具;从使用方式上分类,可分为批处理编程工具(目前已很少见到)和可视化编程工具;从功能上分类,可细分为编辑工具、编译(汇编)工具、组装(building)工具和排错工具等,目前的编程过程多采用集成化开发环境工具。
               目前,典型的集成式可视化编程工具有Visual Studio .NET、JBuilder、Delphi等。
               测试工具
               测试工具是指辅助测试过程活动的各类软件,通常可分为白盒测试工具、黑盒测试工具和测试管理工具等。比较有代表性的白盒测试工具包括Compuware的Numega系列工具、ParaSoft的Java Solution和C/C++Solution系列工具以及开放源代码的以Junit、Dunit、HttpUnit为代表的Xunit系列工具;比较有代表性的黑盒测试工具包括Mercury Interactive的TestSuite系列工具、IBM Rational的TestStudio系列工具和Compuware的QACenter系列工具;比较有代表性的测试管理工具包括Mercury Interactive的TestDirector、Empirix的d-Tracker、Segue的Silkplanpro、Compuware的TrackRecord和IBM Rational的ClearQuest。
               下面重点介绍Mercury Interactive公司的功能测试工具WinRunner、性能负载测试工具LoadRunner和测试管理工具TestDirector。
               WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能以及是否能够正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
               LoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRuner能够对整个企业架构进行测试。通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助开发人员更快地查找和发现问题。此外,LoadRunner能支持广泛的协议和技术,为特殊环境提供特殊地解决方案。
               TestDirector是业界第一个基于Web的测试管理系统,它可以在公司内部或外部进行全球范围内测试的管理。TestDirector在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理、测试计划、测试执行以及错误跟踪等功能。TestDirector能消除组织机构间、地域间的障碍,让测试人员、开发人员或其他人员通过一个中央数据仓库,在不同地方交互测试信息。TestDirector将测试过程流水化,从测试需求管理,到测试计划、测试日程安排、测试执行,再到出错后的错误跟踪,仅在一个基于浏览器的应用中便可完成,而不需要每个客户端都安装一套客户端程序。
               项目管理工具
               项目管理工具是指辅助项目管理活动的各类软件。项目管理工具分很多类别,有的管理工具只能用于项目管理的某个方面(如成本估算、质量控制等),有的管理工具则可用于项目管理的许多方面。综合性项目管理工具主要有Microsoft Project Server、PMOffice、P3E、Artemis Views 4等。
               Microsoft Project Server是Microsoft Project系列中的新的服务器产品,当与Microsoft Project配合使用时,Microsoft Project Server可为发布项目和资源信息提供一个集中的储存库,使企业能够统一保存数据,从而保证报告的时效性。Microsoft Project Server提供企业规模、安全性和性能能力,用于满足企业不断增长的项目和资源管理需求。
               PMOffice(简称PMO)是System公司和IBM公司合作开发的企业集成项目管理工具。PMO认为,项目活动可分为计划、执行和监控等3类活动,参与项目活动的角色可分为系统管理员/业务管理员、项目经理、项目成员、项目主管和功能部门经理等5类角色。不同的角色在PMO这个公共平台上,各司其职,协同完成各类项目活动。
               P3E(Primavera Project Planner for Enterpriser)是Primavera公司开发的企业集成项目管理工具。P3E包括4个模块,分别是计划模块、进度汇报模块、Primavision模块、Portfolio Analyst模块。
               Artemis Views 4是Artemis公司推出的企业级项目管理工具。
 
       图形
        UML2.0使用了14种图,列举如下:
        (1)类图(class diagram):描述一组类、接口、协作和它们之间的关系。在面向对象系统的建模中,最常见的图就是类图。类图给出了系统的静态设计视图,活动类的类图给出了系统的静态进程视图。
        (2)对象图(object diagram):描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样,这些图给出了系统的静态设计视图或静态进程视图,但它们是从真实案例或原型案例的角度建立的。
        (3)构件图(component diagram):描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说,构件图是很重要的。构件图是类图的变体。
        (4)组合结构图(composite structure diagram):描述结构化类(例如构件或类)的内部结构,包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。
        (5)用例图(use case diagram):描述一组用例、参与者(一种特殊的类)及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
        (6)顺序图(sequence diagram,序列图):是一种交互图(interaction diagram),交互图展现了一种交互,它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
        (7)通信图(communication diagram):也是一种交互图,它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念,但每种图所强调的概念不同,顺序图强调的是时序,通信图则强调消息流经的数据结构。
        (8)定时图(timing diagram,计时图):也是一种交互图,它强调消息跨越不同对象或角色的实际时间,而不仅仅只是关心消息的相对顺序。
        (9)状态图(state diagram):描述一个状态机,它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要,而且它强调事件导致的对象行为,这非常有助于对反应式系统建模。
        (10)活动图(activity diagram):将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要,并强调对象间的控制流程。
        (11)部署图(deployment diagram):描述对运行时的处理结点及在其中生存的构件的配置。部署图给出了架构的静态部署视图,通常一个结点包含一个或多个部署图。
        (12)制品图(artifact diagram):描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
        (13)包图(package diagram):描述由模型本身分解而成的组织单元,以及它们的依赖关系。
        (14)交互概览图(interaction overview diagram):是活动图和顺序图的混合物。
 
       需求定义
        需求定义的过程也就是形成需求规格说明书的过程,通常有两种需求定义的方法,分别是严格定义方法和原型方法。
               严格定义方法
               严格定义(预先定义)是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中,各个工作阶段排列成一个理想的线性开发序列,在每一工作阶段中,都用上一阶段所提供的完整、严格的文档作为指导文件,因此它本质上是一种顺序型的开发方法。
               在传统的结构化开发中,需求的严格定义建立在以下的基本假设上:
               (1)所有需求都能够被预先定义。假设意味着,在没有实际系统运行经验的情况下,全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的,但对那些功能庞大、复杂且较大的系统显然是困难的。即使事先做了深入细致的调查和分析,当用户见到新系统的实际效果时,也往往会改变原先的看法,会提出修改或更进一步增加系统功能的要求,所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深,这是与人类认识世界的客观规律相一致的。所以,能够预先定义出所有需求的假设在许多场合是不能成立的。
               (2)开发人员与用户之间能够准确而清晰地交流。假设认为,用户与开发人员之间,虽然每人都有自己的专业、观点、行话,但在系统开发过程中可以使用图形/文档等通信工具进行交流,进行清晰、有效的沟通,这种沟通是必不可少的。可是,在实际开发中,往往对一些共同的约定,每个人可能都会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具,仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而各行其事,所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。
               (3)采用图形/文字可以充分体现最终系统。在使用严格定义需求的开发过程中,开发人员与用户之间交流、通信的主要工具是定义报告,包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的、被动的,不能实际表演,很难在用户头脑中形成一个具体的形象。因此,要用静止的图形/文字描述来体现一个动态的系统是比较困难的。
               除了所论述的情况外,上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷:
               (1)文档量大。由于在结构化方法的每个阶段都必须写出规范、严密的各种文档,这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流,有助于开发过程的规范化,但由于编写文档花费大量人力和时间,导致系统开发周期增大。
               (2)开发过程可见性差,来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果,一直到系统实现阶段结束,用户才有机会通过对新系统的实际操作和体会来提出他们对新系统的看法和意见,但此时整个开发已近尾声,若想修改前几段的工作或修改需求定义,都将付出较大的代价,有时这种修改甚至会导致整个系统的失败。
               :需求的严格定义的基本假设在许多情况下并不成立,传统的结构化方法面临着一些难以跨越的障碍。为此,需要探求一种变通的方法。
               原型方法
               原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始,允许用户在开发过程中提出更好的要求,根据用户的要求不断地对系统进行完善,它实质上是一种迭代的循环型的开发方式。
               采用原型方法时需要注意的几个问题。
               (1)并非所有的需求都能在系统开发前被准确地说明。事实上,要想严密、准确地定义任何事情都是有一定难度的,更不用说是定义一个庞大系统的全部需求。用户虽然可以叙述他们所需最终系统的目标及大致功能,但是对某些细节问题却往往不可能十分清楚。一个系统的开发过程,无论对于开发人员还是用户来说,都是一个学习和实践的过程,为了帮助他们在这个过程中提出更完善的需求,最好的方法就是提供现实世界的实例——原型,对原型进行研究、实践,并进行评价。
               (2)项目参加者之间通常都存在交流上的困难,原型提供了克服该困难的一个手段。用户和开发人员通过屏幕、键盘进行对话和讨论、交流,从他们自身的理解出发来测试原型,一个具体的原型系统,由于直观性、动态性而使得项目参加者之间的交流上的困难得到较好的克服。
               (3)需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具,但是,其最大缺陷是缺乏直观的、感性的特征,因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规格说明,用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统,显然比理解纸面上的系统要深刻得多。
               (4)有合适的系统开发环境。随着计算机硬件、软件技术和软件工具的迅速发展,软件的设计与实现工作越来越方便,对系统进行局部性修改甚至重新开发的代价大大降低。所以,对大系统的原型化已经成为可能。
               (5)反复是完全需要和值得提倡的,需求一旦确定,就应遵从严格的方法。
               对系统改进的建议来自经验的发展,应该鼓励用户改进他们的系统,只有做必要的改变后,才能使用户和系统间获得更加良好的匹配,所以,从某种意义上说,严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求,这对提高最终系统的质量是有害的。另一方面,原型方法的使用并不排除严格定义方法的运用,当通过原型并在演示中得到明确的需求定义后,应采用行之有效的结构化方法来完成最终系统的开发。
               软件需求说明书
               软件需求说明书(Software Requirements Specification,SRS)是需求开发阶段的成果,代表用户和开发人员对软件系统的共同理解,是软件项目后期开发和维护的基础。不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。SRS需要把用户对软件的功能需求和非功能需求进行详细记录和准确描述,它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制,软件需求说明不应该包括设计、构造、测试或工程管理的细节,也不应该包括对算法的详细过程描述。
               可以使用以下3种方法编写SRS:
               (1)用好的结构化和自然语言编写文本型文档。
               (2)建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。
               (3)编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。
               由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了。虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在9.4节中进行详细介绍。
        (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包括三个子系统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种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用三类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
       编码
               编码过程
               在给定了软件设计规格说明书后,下一步的工作就是编写代码。一般来说,编码工作可以分为四个步骤:
               (1)确定源程序的标准格式,制订编程规范。
               (2)准备编程环境,包括软硬件平台的选择,包括操作系统、编程语言、集成开发环境等。
               (3)编写代码。
               (4)进行代码审查,以提高编码质量。为提高审查的效率,在代码审查前需要准备一份检查清单,并设定此次审查须找到的bug数量。在审查时,要检查软件规格说明书与编码内容是否一致;代码对硬件和操作系统资源的访问是否正确;中断控制模块是否正确等。
               编码准则
               在嵌入式系统中,由于资源有限,且实时性和可靠性要求较高,因此,在开发嵌入式软件时,要注意对执行时间、存储空间和开发/维护时间这三种资源的使用进行优化。也就是说,代码的执行速度要越快越好,系统占用的存储空间要越小越好,软件开发和维护的时间要越少越好。
               具体来说,在编写代码时,需要做到以下几点:
               .保持函数短小精悍。一个函数应该只实现一个功能,如果函数的代码过于复杂,将多个功能混杂在一起,就很难具备可靠性和可维护性。另外,要限制函数的长度,一般来说,一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中,其他代码不能直接访问这些数据。例如,全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性,提高了对象的内聚性,使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如,将一个变量赋给它自己,初始化或设置一个变量后却从不使用它,等等。研究表明,即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高,而且调试成本可能更高。如果可能,最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜,而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中,遵守编程规范,养成良好的编程习惯,这是非常重要的,将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容:
                      .命名规则。从编译器的角度,一个合法的变量名由字母、数字和下画线三种字符组成,且第一个字符必须为字母或下画线。但是从程序员的角度,一个好的名字不仅要合法,还要载有足够的信息,做到“见名知意”,并且在语意清晰、不含歧义的前提下,尽可能地简短。
                      .编码格式。在程序布局时,要使用缩进规则,例如变量的定义和可执行语句要缩进一级,当函数的参数过长时,也要缩进。另外,括弧的使用要整齐配对,要善于使用空格和空行来美化代码。例如,在二元运算符与其运算对象之间,要留有空格;在变量定义和代码之间要留有空行;在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括:函数的功能描述;设计过程中的决策,如数据结构和算法的选择;错误的处理方式;复杂代码的设计思想等。在书写注释时要注意,注释的内容应该与相应的代码保持一致,同时要避免不必要的注释,过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高,因此一般要求对代码的性能进行优化,使代码的执行速度越快越好。以算术运算为例,在编写代码时,需要仔细地选择和使用算术运算符。一般来说,整数的算术运算最快,其次是带有硬件支持的浮点运算,而用软件来实现的浮点运算是非常慢的。因此,在编码时要遵守以下准则:
                      .尽量使用整数(char、short、int和long)的加法和减法。
                      .如果没有硬件支持,尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持,尽量避免使用浮点数。
                      下图是一个例子,其中两段代码的功能完全一样,都是对一个结构体数组的各个元素进行初始化,但采用两种不同的方法来实现。下图(a)采用数组下标的方法,在定位第i个数组元素时,需要将i乘以结构体元素的大小,再加上数组的起始地址。下图(b)采用的是指针访问的方法,先把指针fp初始化为数组的起始地址,然后每访问完一个数组元素,就把fp加1,指向下一个元素。在一个奔腾4的PC上,将这两段代码分别重复10 700次,右边这段代码需要1ms,而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       开发工具
        对应于开发过程的各种活动,开发工具通常有需求分析工具、设计工具、概要设计工具、编码与排错工具、测试工具等。
               需求分析工具
               用于辅助需求分析活动的软件称为需求分析工具,它辅助系统分析师从需求定义出发,生成完整的、清晰的、一致的功能规范(Functional Specification)。功能规范是系统所要完成的功能的准确而完整的陈述,它描述该系统要做什么及只做什么。按照需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具。
               设计工具
               用于辅助设计活动的软件称为设计工具,它辅助设计人员从系统功能规范出发,得到相应的设计规范(design specification)。对应于概要设计活动和详细设计活动,设计工具通常可分为概要设计工具和详细设计工具。
               概要设计工具
               用于辅助设计人员设计目标系统的体系结构、控制结构和数据结构。详细设计工具用于辅助设计人员设计模块的算法和内部实现细节。除此之外,还有基于形式化描述的设计工具和面向对象分析与设计工具。
               实现与排错工具
               辅助实现人员进行嵌入式硬件实现的电子设计自动工具、用于目标板调试的硬件仿真器,进行编码活动的工具有编码工具和排错工具。编码工具辅助编程人员用某种程序设计语言编制源程序,并对源程序进行翻译,最终转换成可执行的代码。因此,编码工具通常与编码所使用的程序语言密切相关。排错工具用来辅助程序员寻找源程序中错误的性质和原因,并确定出错的位置。
               测试工具
               用于支持进行软件测试的工具称为测试工具,分为数据获取工具、静态分析工具、动态分析工具、模拟工具以及测试管理工具。其中,静态分析工具通过对源程序的程序结构、数据流和控制流进行分析,得出程序中函数(过程)的调用与被调用关系、分支和路径、变量定义和引用等情况,发现语义错误。动态分析工具通过执行程序,检查语句、分支和路径覆盖,测试有关变量值的断点,即对程序的执行流进行探测。
 
       需求分析工具
        用于辅助需求分析活动的软件称为需求分析工具,它辅助系统分析师从需求定义出发,生成完整的、清晰的、一致的功能规范(Functional Specification)。功能规范是系统所要完成的功能的准确而完整的陈述,它描述该系统要做什么及只做什么。按照需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具。
   题号导航      2020年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第29题    在手机中做本题