基于构件的开发模型包括软件的需求分析定义、(35)、 (36)、 (37)，以及测试和发布5个顺..

免费智能真题库 > 历年试卷 > 系统架构设计师 > 2009年下半年系统架构设计师上午试卷综合知识

第35题

知识点：其他经典模型需求分析构件开发模型

关键词：测试基于构件的开发模型需求分析构件基于构件开发需求章/节：软件开发方法

基于构件的开发模型包括软件的需求分析定义、(35)、 (36)、 (37)，以及测试和发布5个顺序执行的阶段。

A. 构件接口设计

B. 体系结构设计

C. 元数据设计

D. 集成环境设计

相关试题：软件开发模型

更多>

第26题 2010年下半年

58%

在RUP中采用“4+1”视图模型来描述软件系统的体系结构。在该模型中，最终用户侧重于（26)，系统工程师侧重于（27)。

第25题 2009年下半年

47%

(25) 方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化，比较适合需求变化较大或者开发前期对需求不是很清晰的项目..

第23题 2021年下半年

37%

RUP(Rational Unified Process)软件开发生命周期是一个二维的软件开发模型,其中，RUP的9个核心工作流中不包括（）。


知识点讲解
· 其他经典模型 · 需求分析 · 构件 · 开发模型

其他经典模型

本节简单介绍一些经典模型，包括演化模型、螺旋模型、喷泉模型、智能模型、增量模型、构件组装模型、迭代模型等。

（1）演化模型：也称为变换模型，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。

（2）螺旋模型：将瀑布模型和变换模型相结合，综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程及客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。

（3）喷泉模型：为软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界。

（4）智能模型：是基于知识的软件开发模型，它综合了上述若干模型，并与专家系统结合在一起。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。

（5）增量模型：融合了瀑布模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的增量。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。增量模型像原型实现模型和其他演化方法一样，本质上是迭代的。

但与原型实现不同的是，增量模型强调每一个增量均发布一个可操作产品。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求，而且还需要更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源，如果核心产品很受欢迎，则可以增加人力实现下一个增量；当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到“镇静剂”的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理，就必须做全盘的系统分析。增量模型采用的将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。

（6）迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。在迭代模型中，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发。在现代的开发方法中，例如XP、RUP等，无一例外地都推荐、主张采用能显著减少风险的迭代模型。迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发中。

（7）构件组装模型：基于构件的软件开发（Component Based Software Development，CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。CBSD模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。

CBSD方法由软件的需求分析和定义、架构设计、构件库的建立、应用软件构建、测试和发布5个阶段组成。CBSD方法使得软件开发不再一切从头开始，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是提高了软件开发的效率；构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用，CBSD允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。该方法的缺点是：由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入具有较大的风险；可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员，一般的开发人员插不上手，客户的满意度低；过分依赖于构件，构件库的质量影响着产品质量。

需求分析

需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：

（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）应用服务器（Application Server）。主要用于企业较大规模电子商务应用的开发、发布和管理，同时实现与企业原有系统的集成。

（2）工作流和群件服务器。主要用于使工作人员和商业伙伴能通过Internet共享资源、协同工作。

（3）内容管理子系统。简化企业网站的产品管理、提高效率，并将相应的、经过筛选的内容发送给最终用户。

（4）目录服务器。企业使用它来管理防火墙内外的用户、资源和控制安全权限，同时为用户的通信和电子商务提供一个通道。

（5）性能优化工具。改善网站服务质量，包括流量管理、动态数据缓存、网络动态负载（Load Balancing）、知识管理等。

（6）邮件和消息服务器。使企业和服务提供者能为所有员工、合作伙伴和客户社区提供商业级的通信架构。

（7）个性化信息服务。在实时分析用户数据的基础上提供一对一的交易平台。通过对用户行为的更好理解，企业更跟踪、分析和理解网站用户。

（8）搜索引擎。用户提供更广泛的资源。

（9）安全服务器。包括数据安全、应用安全和交易完全。其基本内容有用防火墙阻止对网络的非授权访问，在安全和个人的角色授权的基础上，只需一次登录就可以访问网站的所有应用，通过提供一种对在线交易的每一方的可信任的授权方式，帮助客户、合作伙伴和员工访问Internet应用。

（10）网站服务器（Web Server）。将各种网站的信息发布给用户。

以上是通常构建网站所需要的构件，企业可针对自己的特点以及网站规模大小，应用的类型等自行选择。

在网站结构的实现上，通常在逻辑上将网站分为三层：表示层、应用逻辑层、数据层。这种结构使得网站具有较好的可扩充性，将表示层与业务功能的实现分离开来，能够更灵活地适应业务的发展。网站不需要对业务逻辑组件进行任何变动，就能够适用新出现的表示形式和客户端。例如，为了使用户更方便地在网站上购物，网站调整了页面格局和页面风格。由于网站结构层次分明，只需要改动网站表示层，业务逻辑层和数据连接层则不需要改变。

（11）表示层和相关技术。表示层用于为最终用户提供一个友好的用户界面，接受用户提交的事件，并将处理的结果返还给用户。这一层作为应用的前端和“窗口”，决定了用户对网站优劣的评价和总体印象。

网站从总体上说是独立于客户端的，客户端包括基于浏览器的HTML客户端、给予Java的客户端、传统的C/C++应用、Power Builder客户端以及VB客户端。

在表示层除了使用最基本的HTML语言外，通常还利用JavaScript Internet脚本语言，以及Java Internet程序开发语言。JavaScript程序运行在客户端，能够完成用户事件获取、数据提交前的合法性校验、错误检查和实现动画效果等。而利用Java开发的JavaServlet程序运行于服务器端，负责实现与业务逻辑层的交互，从业务逻辑层获得数据，并将用户提交的信息传给业务逻辑层，而基于Java语言的JSP程序，则实现数据的动态显示，它将JavaServlet程序获得的数据形成相应的HTML页面传给客户端。

为了适应电子商务的各种需求，新的表示层技术不断发展。如XML（可扩展标记语言）和RDF（资源描述框架）等都是当前最新的、对表示层产生重大影响的技术。XML通过一种结构化的文本方式来表述数据；RDF提供一种统一的、可互操作的方法通过Internet在程序间交换元数据。

（12）商务逻辑与实现。商务逻辑层是电子商务系统的核心，也是系统建造过程中的重点和难点。商务逻辑层包括商务应用程序、支持平台（包括商务服务层、商务支持层和基础支持层）。

支持层向上层（商务应用层）提供的服务主要包括：表达、商务支持、运行支持、开发与集成服务。构成支持平台的技术产品至少应当包括：Web服务器、商务支持软件、集成与开发工具、计算机主机、网络及其他系统软件（如操作系统、管理工具软件等）。

通常，Web服务器、商务支持软件、部分集成开发环境被集成到一个被称为“应用服务器”的软件包里，所以商务逻辑层在物理上可以简化为以下三个部门：应用软件（实现商务逻辑）；应用服务器（为应用软件提供软件支持平台）和其他支持软件；计算机主机及网络（为应用软件提供硬件支持平台）。

构造商务逻辑层的任务是为选择合适的应用服务器和其他支持软件，开发实现商务逻辑的应用软件系统。

（13）数据层及实现。构造数据层的关键是开发电子商务与外部系统、内部资源系统的接口，完成系统集成。

数据层的数据源主要包括：相关信息系统（如ERP系统）的数据与企业的数据库，企业与协作企业（如供应商）间交换的数据，企业与银行间交换的数据，企业与认证中心之间的认证数据，企业与其他商务中介交换的电子数据。

由于企业商务逻辑的处理过程是一个从市场、销售、采购到客户服务的整体，所以必须将商务逻辑处理过程中所涉及到的数据集成到一起，因此构造数据层的任务是：实现电子商务系统与企业内部和外部信息系统之间的网络互联，并确保安全的网络环境，基于应用服务器平台的商务应用系统与企业内部数据的共享。

开发模型

电子商务应用系统开发模型是描述系统开发过程中各种活动如何执行的模型。系统生命周期模型确立了开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。常见的生命周期模型有如下5个模型。

瀑布模型（Waterfall Model）

瀑布模型是将软件生命周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。

但是，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。

快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。

第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

增量模型（Incremental Model）

增量模型又称演化模型。大量的软件开发实践表明，许多开发项目在开始时对软件需求的认识是模糊的，因此很难一次开发成功。为了减少因对软件需求的了解不够确切而给开发工作带来的风险，可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。增量模型特别适用于对软件需求缺乏准确认识的情况。

螺旋模型（Spiral Model）

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。在每个螺旋周期分为如下四个工作步骤。

①制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。

②风险分析。分析所选的方案，识别风险，消除风险。

③实施工程。实施软件开发，验证阶段性产品。

④用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。

喷泉模型（Water Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。

题号导航 2009年下半年系统架构设计师上午试卷综合知识

本试卷我的完整做题情况



	第35题在手机中做本题