搜索
一、简答题1、需求分析的任务答：需求分析的任务主要包括以下几项：确定目标系统的综合要求，其中包括（目标系统的功能、性能、运行的环境及扩展性要求）；分析目标系统的数据要求，其中包括（系统平台需要哪些数据？数据间有什么关系？数据及数据结构？对数据的处理逻辑关系等）；导出目标系统的逻辑模型；修正系统流程图；修正系统开发计划、开发原型系统2、软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题，具体表现在哪些方面？答：1、无法开发复杂程度高的软件2、成本和进度估计不准3、无统一科学的规范，软件不可维护4、无质量保证，可靠性差5、软件常不能满足用户的需求6、无适当的文档资料7、软件生产率太低二、选择题1、从下列关于结构化程序设计的叙述中选出5条正确的叙述。①程序设计比较方便，但比较难以维护。②便于由多个人分工编制大型程序。③软件的功能便于扩充。④程序易于理解，也便于排错。⑤在主存储器能够容纳得下的前提下，应使模块尽可能大，以便减少模块的个数。⑥模块之间的接口叫做数据文件。⑦只要模块之间的接口关系不变，各模块内部实现细节的修改将不会影响别的模块。⑧模块间的单向调用关系叫做模块的层次结构。⑨模块越小，模块化的优点越明显。一般来说，模块的大小都在10行以下。答：正确的叙述有②、③、④、⑦、⑧。如果程序结构的模块化满足评价的标准（高内聚、低耦合），这样的结构是容易维护的，程序的功能也容易测试，容易理解、容易修改、容易维护的，程序的功能也容易扩充。特别适合于大型程序编制时，多人分工全中作，协同完成任务的情形。因为是采用自顶向下、逐层分解来划分解模块结构的，所以模块之间的调用关系是分层次的模块结构，就叫做模块的层次结构。模块之间的信息传递叫做模块的接口，模块之间传递信息可以通过参数表、全局变量或全局数据结构、数据文件、专门模块太大，控制路径数目多、涉及的范围广、变量的数目多、总体复杂性高，可理解性、可修改性、可靠性就会变差。模块太小，模块个数增多，调用的系统开销就会增大。所以要有一个权衡2、供选择的答案中选出正确的答案填入下列叙述中的（）内。模块内聚性用于衡量模块内部各成分之间彼此结合的紧密程度。（1）一组语句在程序中多处出现，为了节省内存空间把这些语句放在一个模块中，该模块的内聚性是（A）的。（2）将几个逻辑上相似的成分放在同一个模块中，通过模块入口处的一个判断决定执行哪一个功能，该模块的内聚性是（B）的。（3）模块中所有成分引用共同的数据，该模块的内聚性是（C）。（4）模块内的某成分的输出是另一些成分的输入，该模块的内聚性是（D）的。（5）模块中所有成分结合起来完成一项任务，该模块的内聚性是（E）的。它具有简明的外部界面，由它构成的软件易于理解、测试和维护。供选择的答案：A～E：①功能内聚②信息内聚③通信内聚④过程内聚⑤偶然内聚⑥时间内聚⑦逻辑内聚答：A.⑤偶然内聚;B.⑦逻辑内聚;C.③通信内聚;D.④过程内聚;E.①功能内聚;3、从下列叙述中选出5条符合程序设计风格指导原则的叙述。①嵌套的重数应加以限制。②尽量多使用临时变量。③不滥用语言特色。④不用可以省略的括号。⑤使用有意义的变量名。⑥应尽可能把程序编得短些。⑦把常见的局部优化工作留给编译程序去做。⑧注解越少越好。⑨程序的格式应有助于读者理解程序。⑩应尽可能多用GOTO语句。答：①、③、⑤、⑦、⑨是正确的。①条件语句和循环语句嵌套得过多会增加程序的复杂性，从而增加程序的出错率。③虽然国际上以至国内已经发表了编程语言的标准，但各个计算机厂商在推出自己的计算机系统的同时，也推出了针对自己机器特色的程序设计语言的非标准版本，如果利用这些语言的非标准特性编写程序，就会给将来程序的移植带来困难。为了提高程序的可移植性，应当只使用语言的标准版本，不要滥用语言的非标准特色。⑤给在程序中使用的变量赋予与实际含义相符的名字，可以提高程序的可读性，从而提高程序的可维护性。⑦程序优化的工作最好交给编译程序来做，程序员应把主要注意力放在提高程序的可读性、清晰性、简洁性、正确性、一致性等方面，从而保证软件的可靠性和可维护性。⑨程序的可读性是至关重要的，所以程序的格式应有助于读者理解程序4、由Rumbaugh等人提出的一种面向对象方法叫做对象模型化技术（OMT），即三视点技术，它要求把分析时收集的信息建立在下述3个模型中：第一个模型是（A）----它的作用是描述系统的静态结构，包括构成系统的对象和类、它们的属性和操作，以及它们这间的联系。第二个模型是（B）----它描述系统的控制逻辑，主要涉及系统中各个对象和类的时序及变化状况。（B）包括两种图，即（C）和（D）。（C）描述每一类对象的行为，（D）描述发生于系统执行过程中的某一特定场景。第三个模型是（E）----它着重于描述系统内部的数据的传送与处理，它由多个数据流组成。供你选择的答案如下：A，B，E：①数据模型②功能模型③行为模型④信息模型⑤原型⑥动态模型⑦对象模型⑧逻辑模型⑨控制模型⑩仿真模型C，D：①对象图②概念模型图③状态迁移图④数据流程图⑤时序图⑥事件追踪图⑦控制流程图⑧逻辑模拟图⑨仿真图⑩行为图答：A．⑦，B.⑥，C.③，D.⑥，E.②。在OMT中，把分析时收集的信息建立在3个模型中。第一个模型是对象模型，它的作用是描述系统的静态结构，包括构成系统的对象和类、它们的属性和操作，以及它们之间的联系。第二个模型是动态模型，它描述系统的控制逻辑，主要涉及系统中各个对象和类的时序及变化状况。动态模型包括两种图，即状态迁移图和事件追踪图。状态迁移图描述每一类对象的行为，事件追踪图描述发生于系统执行过程中的某一特定场景。第三个模型是功能模型，它着重于描述系统内部数据的传送与处理，它由多个数据流图组成。5、从下列叙述中选出5条与提高软件的可移植性有关的叙述。①把程序中与计算机硬件特性有关的部分集成在一起。②选择时间效率和空间效率高的算法。③使用结构化的程序设计方法。④尽量用高级语言编写程序中对效率要求不高的部分。⑤尽可能减少注释。⑥采用表格控制方式。⑦文档资料详尽、正确。⑧在有虚拟存储器的计算机系统上开发软件。⑨减少程序中对文件的读写次数。⑩充分利用宿主计算机的硬件特性。答：正确的叙述有①、③、④、⑥、⑦。为了提高软件的可移植性，应当尽可能用高级语言编写源程序代码。对于与硬件或操作系统有关的部分，或对效率要求很高的部分，应当为它们建立专门的模块，将用汇编语言写的程序封装在这些模块中，与程序中其他部分以事先约定的标准方式接口。这样，一旦硬件环境或操作系统环境发生变化，只需修改这个别模块即可。采用表格控制方式，将所有的外部设备接口或与其他系统的接口，包括信息传补递、驱动程序入口等都用表格控制，即使将来硬件、相关软件发生的变化，只需修改表格中的登记项，原来的程序一律可以不改。为了将来修改方便，不致于引入新的错误，相关文档一定要齐全、正确，程序必须有必要的注释，并使用如结构化程序设计方法这样的良好程序设计方法来编写程序。至于算法选择，与效率有关，与可移植性无关。其他叙述，如⑧、⑨、⑩，都不利于可移植性。三、论述题1.论述瀑布模型软件开发方法的基本过程。答：瀑布模型软件开发方法将软件开发分成四个时期八个阶段：分析时期：1)问题定义---问题性质、工程目标及规模2)可行性研究---技术上、经济上、社会上是否有可行解？3)需求分析---确定目标系统必须具备的功能？设计时期：4)总体设计---1）.几种求解方案；2）.设计软件的结构5)祥细设计---设计出程序的祥细规格说明编码与测试时期：6)编码与单元测试---程序编码实现与模块测试7)综合测试---集成测试和验收测试运行与维护时期：8)维护---改正性维护、适应性维护、完善性维护、预防性维护特点：下导式开发、追溯式确认、适合能事先确切定义需求的软件开发2.为什么软件需要维护？维护有哪几种类型？简述它们的维护过程。答：在软件开发成这交付用户使用后，为了保证软件在一个相当长的是时期有够正常运行，不需要对软件进行维护。软件维护的为类型有4种：改正性维护、适应性维护、完善性维护和预防性维护。其中，改正性维护是要改正正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷；适应性维护是要在软件使用过程中数据环境发生变化或处理环境发生变化时修改软件以适应这种变化；完善性维护是用户和数据处理人员使用软件过程中提出改进现有功能、增加新的功能，以及改善总体性能的要求后，修改软件以把这些要求纳入到软件之中。由这些原因引起折维护活动可以归为以下几类：预防性维护是为了提高软件的可维护性、可靠性等，事先采用先进的软件工程方法对面要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，为以后进一步改进软件打下良好的基础。软件维护的过程如图7.19所示。第一步是先确认维护要求。这需要维护人员与用户反复协商，弄清错误概况及对业务的影响大小，以及用户希望做什么样的修改，并把这些情况存入故障数据库。然后，由维护组织管理员确认维护类型。对于改正维护申请，从评价错误的严重性开始工作。如果存在严重的错误，则必须安排人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，进行“救火”性的紧急维护；对于不严重的错误，可根据任务、机时情况，视轻重缓急，进行排队，统一安排时间。对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。若某项早请的优先级非常高，就可立即开始维工作，否则，维护申请和其他的开发工作一样，进行排队，统一安排时间。并不能所有的完善性维护申请都必须承担，因为进行完善性维护等于是做二次开发，工作量大，所以需要根据商业需要、可利用资源的情况、目前和将来软件的发展向以及其他考虑，决定是否承担。尽管维护申请的类型不同，但都要进行同样的技术工作。这此工作有修改软件的需求说明，修改软件设计、设计评审、对源程做必要的修改、单元测试、集成测试（回归测试）、确认测试、软件配置评审等。在每次软件维护任务完成后，最好进行一次情况评审，对以下问题做一总结：（1）在目前情况下，设计、编码、测试中的哪一方面可以改进？（2）哪些维护资源应该有但没有？（3）工作中主要的或次要的障碍是什么？（4）从维护申请的类型来看是否应当有预防性维护？情况评审对将来的维护工作如何进行会产生重要的影响，并可为软件机构的效管理提供重要的反馈信息。3.软件复杂性有哪几类？软件复杂性度量模型应遵循哪些则？答：K.Magel从6个方面描述软件的复杂性：（1）理解程序的难度。（2）改错及维护程序的难度。（3）向他人解释程序的难度。（4）按指定方法修改程序的难度。（5）根据设计文档编写程序的工作量。（6）执行程序时需要资源的程度。软件复杂性度量模型应遵循的基本原则：（1）软件复杂性与程序大小的关系不是线性的。（2）控制结构复杂的程序较复杂。（3）数据结构复杂的程序较复杂。（4）转向语句使用不当的程序较复杂。（5）循环结构比选择结构复杂，选择结构又比顺序结构复杂。（6）语句、数据、子程序和模块在程序中的次序对软件复杂性都有影响。（7）全程变量、非局部变量较多时程序较复杂。（8）参数按地址传递比按值传递更复杂。（9）函数副作用比显式参数传递更难以琢磨。（10）具有不同作用的变量共用一个名字时较难理解。（11）模块间或过程联系密切的程序较复杂。（12）嵌套深度越深程序越复杂。最典型的两种程序复杂性度量的方法中，McCabe环路复杂性度量就是针对基本原则（2）制定的度量模型。Halstead软件科学则是针对程序中操作符和操作数的出现频度而制定的度量模型。4.简述面向对象OMT方法的分析模型，描述面向对象分析的大体过程。答：OMT是一种软件工程方法学，支持整个软件生存周期。它覆盖了问题构成、分析、设计和实现等阶段。统分析阶段涉及对应用领域的理解及问题域建模。分析阶段的输入是问题陈述说明要解决的问题并提供了对假想系统的概念总览同用户不断对话以及对客观世界背景知识的了解作为分析的附加输入分析的结果是一个形式化模型该模型概括了系统的3个本质因素:对象及对象之间的关系、动态的控制流以及带有约束