在基于构件的软件开发中,(1)描述系统设计蓝图以保证系统提供适当的功能;(2)用来了解系统的性能、吞吐率等非功能性属性。

题目
单选题
在基于构件的软件开发中,(1)描述系统设计蓝图以保证系统提供适当的功能;(2)用来了解系统的性能、吞吐率等非功能性属性。 空白(1)处应选择()
A

逻辑构件模型

B

物理构件模型

C

组件接口模型

D

系统交互模型

参考答案和解析
正确答案: D
解析: 暂无解析
如果没有搜索结果或未解决您的问题,请直接 联系老师 获取答案。
相似问题和答案

第1题:

试题(36)、(37)

在基于构件的软件开发中, (36) 描述系统设计蓝图以保证系统提供适当的功能;(37)用来了解系统的性能、吞吐率等非功能性属性。

(36)

A. 逻辑构件模型

B. 物理构件模型

C. 组件接口模型

D. 系统交互模型

(37)

A. 逻辑构件模型

B. 物理构件模型

C. 组件接口模型

D. 系统交互模型


正确答案:A,B
试题(36)、(37)分析
在基于构件的软件开发中,逻辑构件模型用功能包描述系统的抽象设计,用接口描述每个服务集合,以及功能之间如何交互以满足用户需求,它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构、以及用于绑定的网络和通信协议描述系统的物理设计,这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
参考答案
(36)A  (37)B

第2题:

阅读以下关于软件架构的叙述,回答问题1至问题3。

软件架构是指大型、复杂软件的系统结构的设计、规格说明和实施。它以规范的形式装配若干结构元素,从而描述出系统的主要功能和性能需求,同时表述其他非功能性需求(如可靠性、可扩展性、可移植性和可用性等)。软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式,可以使用一个公式来表达:

软件架构={构成系统的元素,指导元素集成的形式,关系和约束}

“4+1”视图模型用五个视图组成的模型来描述软件架构。该模型包含五个主要的视图。

.逻辑视图(Logical View),描述了设计的对象模型,支持系统的功能需求。

.进程视图(Process View),描述了设计的并发和同步特征,支持系统的运行特性。

.物理视图(Physical View),描述了软件到硬件的映射,反映了分布式特性,支持系统的拓扑、安装和通信需求。

.开发视图(Development View),描述了在开发环境中软件的静态组织结构,支持软件开发的内部需求。

.场景(Scenario),用来说明重要的系统活动,是其他四个视图在用例(Use Case)驱动下的综合。

软件架构在软件需求与设计之间架起一座桥梁,也是风险承担者进行交流的手段,允许不同的风险承担者找出他们所关心的软件架构问题。假设采用面向对象的设计方法,各个视图涉及的组件(元素)包括:任务、类、模块、节点、步骤等,风险承担者包括最终用户、系统设计师、程序员、经理、项目管理师等。请在下表中的(1)到(7)处填入恰当的内容(空白处不用填)。


正确答案:[答案要点] 本题相当于选择题但要获得好的成绩仍需要仔细构思。 1)逻辑视图表述系统的功能需求。系统分解为一系列的关键抽象这些抽象(大多数)来自于需求分析中所提出功能要求以对象或类的形式来表示(采用抽象、封装和继承)。分解并不仅仅是为了功能分析而且用来识别遍布系统各个部分的通用机制和设计元素。系统的功能需求来自于最终用户最终用户是逻辑视图对应的风险承担者。 2)进程视图表述系统的运行特性。利用进程视图可解决系统的并发性、分布性、系统完整性、容错性等问题。另外它还可以表达逻辑视图的主要抽象在哪个控制线程上被实际执行。风险承担者主要是系统集成人员组件元素是任务。 3)物理视图表述系统的拓扑、安装和通信需求。用来表达软件系统中的各种元素 (元素可以理解为组件或过程)被映射或部署至不同的网络计算机节点上。风险承担者主要是系统实施工程师。 4)开发视图表述软件开发的内部需求。开发视图关注软件开发环境下实际模块的组织(程序库或子系统)它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构每个层为上一层提供良好定义的接口。风险承担者主要是编程人员和软件项目管理人员。 5)场景用来说明重要的系统活动是其他四个视图在用例(Use Case)驱动下的综合。在某种意义上场景是最重要的需求抽象。该视图是其他视图的冗余(因此“+1”)但它起到了两个作用:首先场景可用来发现架构设计过程中的架构元素其次场景可作为架构设计结束后的功能验证。它可作为架构原型测试的出发点。风险承担者是最终用户和开发人员组件元素是步骤。
[答案要点] 本题相当于选择题,但要获得好的成绩,仍需要仔细构思。 1)逻辑视图表述系统的功能需求。系统分解为一系列的关键抽象,这些抽象(大多数)来自于需求分析中所提出功能要求,以对象或类的形式来表示(采用抽象、封装和继承)。分解并不仅仅是为了功能分析,而且用来识别遍布系统各个部分的通用机制和设计元素。系统的功能需求来自于最终用户,最终用户是逻辑视图对应的风险承担者。 2)进程视图表述系统的运行特性。利用进程视图可解决系统的并发性、分布性、系统完整性、容错性等问题。另外,它还可以表达逻辑视图的主要抽象在哪个控制线程上被实际执行。风险承担者主要是系统集成人员,组件元素是任务。 3)物理视图表述系统的拓扑、安装和通信需求。用来表达软件系统中的各种元素 (元素可以理解为组件或过程)被映射或部署至不同的网络计算机节点上。风险承担者主要是系统实施工程师。 4)开发视图表述软件开发的内部需求。开发视图关注软件开发环境下实际模块的组织(程序库或子系统),它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构,每个层为上一层提供良好定义的接口。风险承担者主要是编程人员和软件项目管理人员。 5)场景用来说明重要的系统活动,是其他四个视图在用例(Use Case)驱动下的综合。在某种意义上场景是最重要的需求抽象。该视图是其他视图的冗余(因此“+1”),但它起到了两个作用:首先场景可用来发现架构设计过程中的架构元素,其次场景可作为架构设计结束后的功能验证。它可作为架构原型测试的出发点。风险承担者是最终用户和开发人员,组件元素是步骤。 解析:本题主要考查软件架构“4+1”视图的有关知识和实施方法,熟悉以下关于软件架构的知识是回答本题的前提。
首先要准确把握软件架构的定义。架构(Architecture)原意为建筑学设计和建筑物建造的艺术与科学。软件架构(Software Architecture,或称为软件架构)是软件系统的高层描述,它给出了关于软件系统组织结构的一系列高级的、重要的抽象,包括:系统组成的结构性构件;组成构件之间的接口:构件相对系统其他部分的可视行为:构件之间所采取的交互和协作关系。软件架构在RUP 中的定义是指系统核心构件的组织或结构,这些核心构件通过接口与不断减小的构件与接口所组成的构件进行交互。
人们在软件开发过程中积累了丰富的架构知识,形成了的特定的架构风格,这些架构风格为高层次的软件复用技术建立了坚实的基础:例如,C/S架构、管道/过滤器架构、分层架构、解释器架构、黑板架构等等,而各种分布式组件技术如DCOM,EJB, Web-Services 也都和软件架构密切相关。
长期以来,人们一直在努力软件架构更加精确的形式化描述,力图用一种类似于某种编程语言的形式来描述软件架构,如Rapide,Wright,Aesop,UniCon,ACME 等。XML描述与软件建模UML 技术的发展为软件架构描述语言注入了新的发展思路,新一代的架构描述语言(如xArch,xADL 等)充分应用了这些新的描述手段的特点。同时,伴随着架构描述技术的进步,架构评估等研究也在不断的深入。
其次,要正确理解软件架构的重要作用。
.软件架构能够指导整个系统的设计和演进,它是软件需求分析的结果,同时是下一步进行软件设计的规格和蓝图。对于复杂软件系统而言,在架构阶段,系统的结构和规格说明非常重要,而在软件设计阶段,算法和数据结构更重要。
.软件架构对系统的描述,借鉴了建筑工程设计的思想,通过各种视图从不同角度以规范、一致、易理解的“语言”来表达系统的各种规格和行为。以某一特定角度看到的系统架构之规格、行为,主要是结构、核心构件和主要控制流等。
.软件架构是风险承担者进行交流的手段。所谓风险承担者是指对软件系统某个方面(或层次)负责或(关注)的人员。也可以这样来理解风险承担者:软件系统的某个方面(或层次)如果存在缺陷或问题,对此负责任或受影响的人员。风险承担者包括最终用户、系统设计师、程序员、经理、项目管理师等。
.软件架构是可传递、可重用的模型。
.软件架构是软件工程早期设计决策的体现,而且在整个开发周期中不断演进,软件架构对于软件质量(功能属性、非功能属性)都有重要影响。
“4+1”视图模型是最重要软件架构模式,由Philippe Kruchten 在1995年提出。如下图所示。

需要指出的是,并不是所有的软件架构都需要“4+1”视图。无用的视图可以从架构描述中省略,例如,单机软件,可以省略物理视图;而如果仅有一个进程或程序,则可以省略过程视图。对于非常小型的系统,甚至可能逻辑视图与开发视图非常相似,而不需要分开的描述。
第一步:总结出问题的要点。
[问题1]
考查采用面向对象的架构设计方法,“4+1”视图各个视图涉及的组件要素与风险承担者。

第3题:

● 基于构件的软件开发,强调使用可复用的软件“构件”来设计和构建软件系统,对所需的构件进行合格性检验、 (15) ,并将它们集成到新系统中。

(15)

A. 规模度量

B. 数据验证

C. 适应性修改

D. 正确性测试


正确答案:C

第4题:

论非功能性需求对企业应用架构设计的影响

企业应用架构(Enterprise Application Architecture) 描述了企业IT系统的功能和技术实现内容,它在企业信息化建设中起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各IT系统的定位和功能。企业应用架构包括了企业的应用架构蓝图、架构标准、系统的边界和定义、系统间的关联关系等。其中非功能性需求是进行企业应用架构设计时需要重点考虑的因素,不同类型的非功能性需求从不同侧面影响应用系统的架构设计。

请以“非功能性需求对企业应用架构设计的影响”为题,依次从以下三个方面进行论述。 1.概要叙述你参与分析和开发的企业应用系统项目以及你所担任的主要工作。 2.分析在企业应用架构设计中应该考虑哪些非功能性需求,详细阐述这些非功能性需求是如何影响架构设计的。 3.详细说明你所参与的企业应用系统项目中,在进行系统架构设计时,考虑了哪些非功能性需求,如何通过架构设计满足了系统的这些非功能性需求。


正确答案:
本文第一部分应花400-600字的篇幅进行项目简介,涉及项目背景、规模、人员、作者的角色,开发的系统有什么样的一些功能,大体的设计。
接下来的内容是比较好组织的,因为非功能性需求的范围非常之广,只要作者在论述之前,表明这是非功能需求,然后写关于如何应对这种需求即可。这种需求可以是以下方面的内容:
1、性能
性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序(用以测量性能指标的特定事务集或工作量环境)。
2、可靠性
可靠性(reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间(Mean Time To Failure,简称MTTF)和平均失效间隔时间(Mean Time Between Failure,简称MTBF)来衡量。在失效率为常数和修复时间很短的情况下,MTTF和MTBF几乎相等。
3、可用性
可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4、安全性
安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
5、可修改性
可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。
6、功能性
功能性(functionality)是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性
可变性(changeability)是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性是很重要的。
8、互操作性
作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。为了支持互操作性(interoperation),软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件体系结构。

第5题:

(38) 是一个独立可交付的功能单元,外界通过接口访问其提供的服务

A.面向对象系统中的对象(Object)

B.模块化程序设计中的子程序(Subroutine)

C.基于构件开发中的构件(Component)

D.系统模型中的包(Package)


正确答案:C
在基于构件的开发中,构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想,它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付的功能单元

第6题:

在基于构件的软件开发中,( )描述系统设计蓝图以保证系统提供适当的功能;( )用来了解系统的性能、吞吐率等非功能性属性。

A.逻辑构件模型 B.物理构件模型 C.组件接口模型 D.系统交互模型 A.逻辑构件模型 B.物理构件模型 C.组件接口模型 D.系统交互模型


正确答案:A,B

第7题:

基于构件的软件开发,强调使用可复用的软件“构件”来设计和构建软件系统,对所需的构件进行合格性检验、______,并将它们集成到新系统中。

A.规模度量

B.数据验证

C.适应性修改

D.正确性测试


正确答案:C
解析:本题考查基于构件的软件开发基础知识。
基于构件的软件开发,主要强调在构建软件系统时复用已有软件“构件”,在检索到可以使用的构件后,需要针对新系统的需求对构件进行合格性检验、适应性修改,然后集成到新系统中。

第8题:

试题(35)

(35) 是一个独立可交付的功能单元,外界通过接口访问其提供的服务。

(35)

A. 面向对象系统中的对象(Object)

B. 模块化程序设计中的子程序(Subroutine)

C. 基于构件开发中的构件(Component)

D. 系统模型中的包(Package)


正确答案:C
试题(35)分析
在基于构件的开发中,构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想,它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付的功能单元。
参考答案
(35)C

第9题:

数据流图 (Data Flow Diagram ,DFD) 是进行系统分析和设计的重要工具,是表达系统内部数据的流动并通过数据流描述系统功能的一种方法。DFD从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的 情况,来说明系统所完成的功能。在系统分析中,逻辑DFD作为需求规格说明书的组成部分,用于建模系统的逻辑业务需求;在系统设计中,物理DFD作为系统构造和实现的技术性蓝图,用于建模系统实现的技术设计决策和人为设计决策。

请围绕“数据流图在系统分析与设计中的应用”论题,依次从以下三个方面进行论述。 1. 简要叙述你参与的软件开发项目以及你所承担的主要工作。 2. 列举出DFD中的几种要素及含义,简要说明在系统分析与设计阶段逻辑DFD和物理 DFD中这些要素之间有何区别。 3. 根据所参与的项目,具体阐述你是如何通过绘制数据流图来进行系统分析与设计的。


正确答案:本文的内容组织,其关键在于对题目要求的一些知识内容要能准确把握。
DFD是SA方法中的重要工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,如果采用结构化方法,则一般将DFD作为需求规格说明书的一个组成部分。
在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。
 DFD可以是一个物理系统模型,也可以是逻辑系统模型,也可以是两者的混合。
逻辑DFD与物理DFD最大的区别在于,逻辑DFD只描述了相关的组成要素,而物理DFD则会涉及到具体的实现技术。

第10题:

论数据流图在系统分析与设计中的应用

数据流图 (Data Flow Diagram ,DFD) 是进行系统分析和设计的重要工具,是表达系统内部数据的流动并通过数据流描述系统功能的一种方法。DFD 从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的 情况,来说明系统所完成的功能。在系统分析中,逻辑 DFD 作为需求规格说明书的组成部分,用于建模系统的逻辑业务需求;在系统设计中,物理DFD 作为系统构造和实现的技术性蓝图,用于建模系统实现的技术设计决策和人为设计决策。

请围绕“数据流图在系统分析与设计中的应用”论题,依次从以下三个方面进行论述。

1. 简要叙述你参与的软件开发项目以及你所承担的主要工作。

2. 列举出 DFD 中的几种要素及含义,简要说明在系统分析与设计阶段逻辑 DFD 和物理 DFD 中这些要素之间有何区别。

3. 根据所参与的项目,具体阐述你是如何通过绘制数据流图来进行系统分析与设计的。


答案:
解析:
DFD是SA方法中的重要工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,如果采用结构化方法,则一般将DFD作为需求规格说明书的一个组成部分。

在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。

DFD可以是一个物理系统模型,也可以是逻辑系统模型,也可以是两者的混合。

逻辑DFD与物理DFD最大的区别在于,逻辑DFD只描述了相关的组成要素,而物理DFD则会涉及到具体的实现技术。

更多相关问题