免费智能真题库 > 历年试卷 > 系统分析师 > 2022年上半年 系统分析师 下午试卷 论文
  第1题      
  知识点：   需求定义   原型法   ping   开发工具   信息系统开发方法

 
论原型法及其在信息系统开发中的应用
作为一种信息系统开发方法，原型法（Prototyping）被普遍使用，原型法是指在获取一组基本的需求定义后，利用可视化的开发工具，快速建立一个目标系统的最初版本，并交由用户试用，并根据用户反馈进行补充和修改，再形成新的版本。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。
 
问题：1.1   请围绕“原型法及其在信息系统开发中的应用”论题，依次从以下三个方面进行论述。
1.概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2.请简要描述原型法的开发过程。
3.具体阐述你参与管理和开发的项目是如何基于原型法进行信息系统开发的。
 
 
 

   知识点讲解    
   · 需求定义    · 原型法    · ping    · 开发工具    · 信息系统开发方法
 
       需求定义
        需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。
               严格定义方法
               严格定义（预先定义）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。
               在传统的结构化开发中，需求的严格定义建立在以下的基本假设上：
               （1）所有需求都能够被预先定义。假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统显然是困难的。即使事先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。
               （2）开发人员与用户之间能够准确而清晰地交流。假设认为，用户与开发人员之间，虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形／文档等通信工具进行交流，进行清晰、有效的沟通，这种沟通是必不可少的。可是，在实际开发中，往往对一些共同的约定，每个人可能都会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而自行其是，所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。
               （3）采用图形／文字可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的、被动的，不能实际演示，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形／文字描述来体现一个动态的系统是比较困难的。
               除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷：
               （1）文档量大。由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于开发人员之间、用户与开发人员之间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增大。
               （2）开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。
               需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。
               原型方法
               原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。
               采用原型方法时需要注意的几个问题。
               （1）并非所有的需求都能在系统开发前被准确地说明。事实上，要想严密、准确地定义任何事情都是有一定难度的，更不用说是定义一个庞大系统的全部需求。用户虽然可以叙述他们所需最终系统的目标及大致功能，但是对某些细节问题却往往不可能十分清楚。一个系统的开发过程，无论对于开发人员还是用户来说，都是一个学习和实践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世界的实例——原型，对原型进行研究、实践，并进行评价。
               （2）项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏幕、键盘进行对话和讨论、交流，从他们自身的理解出发来测试原型，一个具体的原型系统，由于直观性、动态性而使得项目参加者之间的交流上的困难得到了较好的克服。
               （3）需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具，但是，其最大缺陷是缺乏直观的、感性的特征，因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规格说明，用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统，显然比理解纸面上的系统要深刻得多。
               （4）有合适的系统开发环境。随着计算机硬件、软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便，对系统进行局部性修改甚至重新开发的代价大大降低。所以，对大系统的原型化已经成为可能。
               （5）反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。
               对系统改进的建议来自经验的发展，应该鼓励用户改进他们的系统，只有做必要的改变后，才能使用户和系统间获得更加良好的匹配，所以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最终系统的质量是有害的。另一方面，原型方法的使用并不排除严格定义方法的运用，当通过原型并在演示中得到明确的需求定义后，应采用行之有效的结构化方法来完成最终系统的开发。
               软件需求说明书
               软件需求说明书（Software Requirements Specification, SRS）是需求开发阶段的成果，代表用户和开发人员对软件系统的共同理解，是软件项目后期开发和维护的基础。不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。SRS需要把用户对软件的功能需求和非功能需求进行详细记录和准确描述，它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求说明不应该包括设计、构造、测试或工程管理的细节，也不应该包括对算法的详细过程描述。
               可以使用以下3种方法编写SRS。
               （1）用好的结构化和自然语言编写文本型文档。
               （2）建立图形化模型，这些模型可以描述转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。
               （3）编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。
               由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求的规格说明。
 
       原型法
        结构化方法和面向对象方法有一个共同点：在系统开发初期必须明确系统的功能要求，确定系统边界。从工程学角度来看，这是十分自然的，解决问题之前必须明确要解决的问题是什么，然而对于信息系统建设而言，明确问题本身不是一件轻松的事情。
        通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求，使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。
               原型的分类
               软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题，其目的是：明确并完善需求、探索设计选择方案、发展为最终的产品。
               原型有很多种分类方法。从原型是否实现功能来分，软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。
               从原型的最终结果来分，软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型，是指达到预期目的后，原型本身被抛弃。抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的系统，以适用于Web的项目。
               有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。演化型原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型演化成最终系统。
               还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。
               原型类型的选择
               如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。
               （1）系统结构：联机事务处理系统，相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。
               （2）逻辑结构：有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适于用原型化方法，而基于大量算法的系统不适宜用原型化方法。
               （3）用户特征：不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合使用原型的用户。
               （4）应用约束：对已经运行系统的补充，不能用原型化方法。
               （5）项目管理：只有项目负责人愿意使用原型化方法，才适于用原型化的方法。
               （6）项目环境：需求说明技术应当根据每个项目的实际环境来选择。
               当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求比较高时，在系统原型上先做一些试验也是很有必要的。
               原型生存期
               原型的开发和使用过程叫做原型生存期。下图（a）是原型生存期的模型，下图（b）是模型的细化。
               
               原型生存期
               （1）快速分析：在分析者和用户的紧密配合下，快速确定软件系统的基本要求。
               （2）构造原型：在快速分析基础上，根据基本需求，尽快实现一个可运行的系统。构造原型时要注意2个基本原则，即集成原则（尽可能用现有软件和模型来构成，这需要相应的原型工具）和最小系统原则（耗资一般不超过总投资的10%）。
               （3）运行和评价原型：用户在开发者指导下试用原型，在试用的过程中考核、评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明描述是否满足用户的愿望。
               （4）修正和改进：根据修改意见进行修改。如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。开发者和用户在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。
               （5）判定原型完成：如果经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一是继续迭代验证，另外则是进行详细说明。
               （6）判断原型细部是否说明：判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分或不能通过模型进行说明的成分进行严格的和详细的说明。
               （7）原型细部的说明：对于那些不能通过原型说明的所有项目，仍需通过文件加以说明。严格说明的成分要作为原型化方法的模型编入词典。
               （8）判定原型效果：考查用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响？是否会影响模块的有效性？如果模型效果受到影响，甚至导致模型失效，则要进行修正和改进。
               （9）整理原型和提供文档。
               总之，利用原型化技术，可为软件的开发提供一种完整的、灵活的、近似动态的规格说明方法。
               原型开发技术
               通常用于构造原型的一些技术包括可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件、简化假设和面向对象技术等。其中前三种还适用于用户界面的设计。
               （1）可执行规格说明：可执行规格说明是用于需求规格说明的一种自动化技术。可执行规格说明语言可描述系统要“做什么”，但它并不描述系统要“怎样做”。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。可执行规格说明包括形式化规格说明、有限状态模型和可执行的数据流图。
               （2）基于场景的设计：一个场景可模拟在系统运行期间用户经历的事件。由于它提供了输入—处理—输出的屏幕格式和有关对话的模型。因此，场景能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。
               （3）自动程序设计：自动程序设计是可执行规格说明的替身，主要是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程性问题的规格说明转换为某种高级语言程序。
               （4）专用语言：专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。
               （5）软件复用技术：软件复用技术可分为两大类：合成技术和生成技术。
               ①合成技术：可复用的软件构件可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成分的抽象，利用这些构件来构造软件系统。用构件合成较大的构件有三种方式：一是连接；二是消息传递和继承；三是管道机制。
               ②生成技术：利用可复用的模式，通过生成程序产生一个新的程序或程序段，产生的程序可以看做是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统（有时要经过一系列的变换），把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。
               （6）简化假设：简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。
               （7）面向对象技术：通常是指OO程序设计语言和面向对象的数据库等有关分析与设计技术的综合。使用OO技术，可以把现实世界中已存在的问题与实体，都采用对象去构成，能更好地体现出自然性、模块化、共享特性、并发特性、继承性、封装隐蔽性与可重用性等一系列功能化要求。如果能把OO数据库和OO程序设计语言等技术用于可重用的构件与原型语言，并且在其中体现出一致的“对象模型”本质，那么就有可能去统一“重用构件库”语言与原型化语言等。
               原型法适合于用户需求不明确的场合。它是先根据已知的和分析的需求，建立一个原始模型，这是一个可以修改的模型。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，缩短了开发周期，降低了开发风险，最终的结果是更适合用户的要求。原型法成败的关键及效率的高低，在于模型的建立及建模的速度。
 
       ping
        ping通过发送"Internet控制报文协议（ICMP）"回送请求／应答报文来验证与另一台TCP/IP计算机的IP级连接。回送请求/应答报文的接收情况将和往返过程的次数一起显示出来。ping是用于检测网络连接性、可到达性和名称解析的疑难问题的主要TCP/IP命令。如果不带参数，ping将显示帮助。
        1）语法格式
        
        2）参数说明
        参数如下表所示。
        
        ping的选项
        
 
       开发工具
        对应于开发过程的各种活动，开发工具通常有需求分析工具、设计工具、概要设计工具、编码与排错工具、测试工具等。
               需求分析工具
               用于辅助需求分析活动的软件称为需求分析工具，它辅助系统分析师从需求定义出发，生成完整的、清晰的、一致的功能规范（Functional Specification）。功能规范是系统所要完成的功能的准确而完整的陈述，它描述该系统要做什么及只做什么。按照需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具。
               设计工具
               用于辅助设计活动的软件称为设计工具，它辅助设计人员从系统功能规范出发，得到相应的设计规范（design specification）。对应于概要设计活动和详细设计活动，设计工具通常可分为概要设计工具和详细设计工具。
               概要设计工具
               用于辅助设计人员设计目标系统的体系结构、控制结构和数据结构。详细设计工具用于辅助设计人员设计模块的算法和内部实现细节。除此之外，还有基于形式化描述的设计工具和面向对象分析与设计工具。
               实现与排错工具
               辅助实现人员进行嵌入式硬件实现的电子设计自动工具、用于目标板调试的硬件仿真器，进行编码活动的工具有编码工具和排错工具。编码工具辅助编程人员用某种程序设计语言编制源程序，并对源程序进行翻译，最终转换成可执行的代码。因此，编码工具通常与编码所使用的程序语言密切相关。排错工具用来辅助程序员寻找源程序中错误的性质和原因，并确定出错的位置。
               测试工具
               用于支持进行软件测试的工具称为测试工具，分为数据获取工具、静态分析工具、动态分析工具、模拟工具以及测试管理工具。其中，静态分析工具通过对源程序的程序结构、数据流和控制流进行分析，得出程序中函数（过程）的调用与被调用关系、分支和路径、变量定义和引用等情况，发现语义错误。动态分析工具通过执行程序，检查语句、分支和路径覆盖，测试有关变量值的断点，即对程序的执行流进行探测。
 
       信息系统开发方法
        信息系统的开发是一个庞大的系统工程，它涉及到组织的内部结构、管理模式、生产加工、经营管理过程、数据的收集与处理过程、计算机硬件系统的管理与应用、软件系统的开发等各个方面。这就增加了开发一个信息系统的工程规模和难度，需要研究出科学的开发方法和过程化的开发步骤，以确保整个开发过程能够顺利进行。这正是信息系统开发方法的任务。
        信息系统开发方法学研究的主要对象是信息系统开发的规律、开发过程的认知体系、分析设计的一般理论以及具体的开发工具和技术等。
        下面从方法论的角度，介绍创建信息系统所需的规划方法，包括结构化开发和设计方法（SSA&D），面向对象的开发方法（OO）及原型方法（Phototyping）。
               结构化系统分析与设计方法（Structured System Analysis and Design, SSA&D）
               SSA&D是在由Dijkstra等人提出的结构化程序设计思想基础上发展起来的。它是一种系统化、结构化和自顶向下的系统开发方法。
               其基本思想是：用系统的思想，系统工程的方法，按用户至上的原则，结构化、模块化、自顶向下对信息系统进行分析与设计。具体来说，就是先将整个信息系统开发过程划分出若干个相对独立的阶段，如系统规划、系统分析、系统设计、系统实施等。在前三个阶段坚持自顶向下地对系统进行结构化划分。在系统调查或理顺管理业务时，应从最顶层的管理业务入手，逐步深入到最基层。在系统分析，提出新系统方案和系统设计时，先考虑系统整体的优化，然后再考虑局部的优化问题。在系统实施阶段，则应坚持自底向上的逐步实施。
               SSA&D有如下特点。
               （1）建立面向用户的观点。强调用户是整个信息系统开发的起源和最终归宿，即用户的参与程度和满意程度是系统成功的关键。
               （2）严格区分工作阶段。强调将整个系统的开发过程分为若干个阶段，每个阶段都有其明确的任务和目标以及预期要达到的阶段成果。一般不可打乱或颠倒。
               （3）结构化、模块化、自顶向下进行开发。在分析问题时，应首先站在整体的角度，将各项具体的业务和组织放到整体中加以考查。自顶向下分析设计：首先确保全局的正确，再一层层地深入考虑和处理局部的问题。
               自底向上进行开发：在具体系统实现过程中，一个模块一个模块地进行开发，调试，然后再由几个模块联调（子系统联调），最后是整个系统联调。
               （4）充分预料可能发生的变化。在系统的分析、设计和实现过程中，都要充分地考虑可能变化的因素。一般可能发生的变化来自于周围环境变化，来自外部的影响：如上级主管部门要的信息发生变化等。系统内部处理模式的变化，如系统内部的组织结构和鼓励体制发生的变化，工艺流程发生变化，系统内部管理形式发生变化等。用户要求发生变化：用户对系统的认识程度不断深化，又提出更高的要求。
               （5）工作文件的标准化和文献化。在系统研制的每一阶段、每一步骤都要有详细的文字资料记载，需要记载的信息是：
               .系统分析过程中的调研材料。
               .同用户交流的情况。
               .设计的每一步方案（甚至包括经分析后淘汰掉的信息和资料）资料要有专人保管，要建立一整套管理、查询制度。
               原型方法（Prototyping）
               原型方法是20世纪80年代随着计算机软件技术的发展，特别是在关系数据库系统（Relational Data Base System, RDBS）、第四代程序生成语言（4th Generation Language, 4GL）和各种系统开发生成环境产生的基础上，提出的一种从设计思想到工具、手段都是全新的系统开发方法。
               传统的结构化开发方法强调系统开发每一阶段的严谨性，要求在系统设计和实施阶段之前预先严格定义出完整准确的功能需求和规格说明。然而，对于规模较大或结构较复杂的系统，在系统开发前期，用户往往对未来的新系统仅有一个比较模糊的想法。由于专业知识所限，系统开发人员对某些涉及具体领域的功能需求也不太清楚。虽然可以通过详细的系统分析和定义得到一份较好的规格说明书，却很难做到将整个管理信息系统描述完整，且与实际环境完全相符，很难通过逻辑推断看出新系统的运行效果。因此当新系统建成以后，用户对系统的功能或运行效果往往会觉得不满意。同时随着开发工作的进行，用户会产生新的要求或因环境变化希望系统也能随之作相应更改，系统开发人员也可能因碰到某些意料之外的问题希望在用户需求中有所权衡。总之，规格说明的难以完善和用户需求的模糊性已成为传统的结构化开发方法的重大障碍。
               原型方法正是对上述问题进行变通的一种新的系统开发方法。在建筑学和机械设计学中，“原型”指的是其结构、大小和功能都与某个物体相类似的模拟该物体的原始模型。在信息系统开发中，用“原型”来形象地表示系统的一个早期可运行版本，它能反映新系统的部分重要功能和特征。“原型方法”则是利用原型辅助开发系统的一种新方法。原型方法要求在获得一组基本的用户需求后，快速地实现新系统的一个“原型”，用户、开发者及其他有关人员在试用原型的过程中，加强通信和反馈，通过反复评价和反复修改原型系统，逐步确定各种需求的细节，适应需求的变化，从而最终提高新系统的质量。因此可以认为原型方法确定用户需求的策略，它对用户需求的定义采用启发的方式，引导用户在对系统逐渐加深理解的过程中作出响应。
               原型法基本思想是凭借着系统分析人员对用户要求的理解，在强有力的软件环境支持下，快速地给出一个实实在在的模型（或称原型、雏形），然后与用户反复协商修改，最终形成实际系统。这个模型大致体现了系统分析人员对用户当前要求的理解和用户想要实现的形式。
               原型方法虽然是在研究用户需求的过程中产生的，但更主要的是针对传统结构化方法所面临的困难，因而也面向系统开发的其他阶段和整个过程。由于软件项目的特点，运用原型的目的和开发策略的不同，原型方法可表现为不同的运用方式，一般可分为以下三种类型。
               （1）探索型（Exploratory Prototying）主要是针对开发目标模糊、用户和开发人员对项目都缺乏经验的情况，其目的是弄清对目标系统的要求，确定所期望的特性并探讨多种方案的可行性。
               （2）实验型（Experimental Prototying）用于大规模开发和实现之前考核、验证方案是否合适，规格说明是否可靠。
               （3）演化型（Evolutionary Prototying）其目的不在于改进规格说明和用户需求，而是将系统改造得易于变化，在改进原型的过程中将原型演化成最终系统。它将原型方法的思想贯穿到系统开发全过程，对满足需求的改动较为适合。
               面向对象的开发方法（Object Oriented, OO）
               从事软件开发的工程师们常常有这样的体会：在软件开发过程中，使用者会不断地提出各种更改要求，即使在软件投入使用后，也常常需要对其做出修改，在用结构化开发的程序中，这种修改往往是很困难的，而且还会因为计划或考虑不周，不但旧错误没有得到彻底改正，又引入了新的错误；另一方面，在过去的程序开发中，代码的重用率很低，使得程序员的效率并不高，为提高软件系统的稳定性、可修改性和可重用性，人们在实践中逐渐创造出软件工程的一种新途径——面向对象方法学。
               面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程。由于客观世界的问题都是由客观世界中的实体及实体相互间的关系构成的，因此把客观世界中的实体抽象为对象（Object）。持面向对象观点的程序员认为计算机程序的结构应该与所要解决的问题一致，而不是与某种分析或开发方法保持一致，他们的经验表明，对任何软件系统而言，其中最稳定的成分往往是其相应问题论域（Problem Domain）中的成分。（例如在过去几百年中复式计账的原则未做任何实质性的改变，而其使用的工具早已从鹅毛笔变成了计算机）。
               所以，“面向对象”是一种认识客观世界的世界观，是从结构组织角度模拟客观世界的一种方法。一般人们在认识和了解客观现实世界时，通常运用的一些构造法则：
               .区分对象及其属性，例如区分台式计算机和笔记本计算机。
               .区分整体对象及其组成部分，例如区分台式计算机的组成（主机、显示器等）。
               .不同对象类的形成以及区分，例如所有类型的计算机（大、中、小型计算机、服务器、工作站和普通微型计算机等）。
               通俗地讲，对象指的是一个独立的、异步的、并发的实体，它能“知道一些事情”（即存储数据），“做一些工作”（即封装服务），并“与其他对象协同工作”（通过交换消息），从而完成系统的所有功能。
               因为所要解决的问题具有特殊性，所以对象是不固定的。一个雇员可以作为一个对象，一家公司也可以作为一个对象，到底应该把什么抽象为对象，由所要解决的问题决定。
               从以上的简单介绍中可以看出，面向对象所带来的好处是程序的稳定性与可修改性（由于把客观世界分解成一个一个的对象，并且把数据和操作都封装在对象的内部）、可复用性（通过面向对象技术，不仅可以复用代码，而且可以复用需求分析、设计、用户界面等）。
               面向对象方法具有下述四个要点：
               .认为客观世界是由各种对象组成的，任何事物都是对象，复杂的对象可以由比较简单的对象以某种方式组合而成。按照这种观点，可以认为整个世界就是一个最复杂的对象。因此，面向对象的软件系统是由对象组成的，软件中的任何元素都是对象，复杂的软件对象由比较简单的对象组合而成。
               .把所有对象都划分成各种对象类（简称为类（Class）），每个对象类都定义了一组数据和一组方法，数据用于表示对象的静态属性，是对象的状态信息。因此，每当建立该对象类的一个新实例时，就按照类中对数据的定义为这个新对象生成一组专用的数据，以便描述该对象独特的属性值。例如，荧光屏上不同位置显示的半径不同的几个圆，虽然都是Circle类的对象，但是，各自都有自己专用的数据，以便记录各自的圆心位置、半径等。
               类中定义的方法，是允许施加于该类对象上的操作，是该类所有对象共享的，并不需要为每个对象都复制操作的代码。
               .按照子类（或称为派生类）与父类（或称为基类）的关系，把若干个对象类组成一个层次结构的系统（也称为类等级）。
               .对象彼此之间仅能通过传递消息互相联系。
               各种开发方法的比较
               从国外最新的统计资料来看，信息系统开发工作的重心向系统调查、分析阶段偏移。系统调查、分析阶段的工作量占总开发量的60%以上。而系统设计和实现环节仅占总开发工作量比率不到40%。
               （1）结构化方法。能够辅助管理人员对原有的业务进行清理，理顺和优化原有业务，使其在技术手段上和管理水平上都有很大提高。发现和整理系统调查、分析中的问题及疏漏，便于开发人员准确地了解业务处理过程。有利于与用户一起分析新系统中适合企业业务特点的新方法和新模型。能够对组织的基础数据管理状态、原有信息系统、经营管理业务、整体管理水平进行全面系统的分析。
               （2）原型方法。它是一种基于4GL的快速模拟方法。它通过模拟以及对模拟后原型的不断讨论和修改，最终建立系统。要想将这样一种方法应用于大型信息系统的开发过程中的所有环节是根本不可能的，故它多被用于小型局部系统或处理过程比较简单的系统设计到实现的环节。
               （3）面向对象方法。它围绕对象来进行系统分析和系统设计，然后用面向对象的工具建立系统的方法。这种方法可以普遍适用于各类信息系统开发，但是它不能涉足系统分析以前的开发环节。
   题号导航      2022年上半年 系统分析师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
 
第1题    在手机中做本题