计算机水平考试-电子商务设计师分类模拟题电子商务系统分析与设计
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
电子商务设计师分类模拟题电子商务系统分析与设计(一)
选择题
1、关于数据字典说法错误的是( )。
A.数据字典中描述数据的逻辑存储结构,也涉及它的物理组织
B.外部实体描述了数据流入、流出和处理的实际发生地点和有关的主体。
外部实体的定义包括实体编号、名称、简述、输入和输出数据流
C.数据流用来描述数据的流动过程,由一个或一组固定的数据项组成
D.数据结构描述了数据项之间的关系,由数据项或数据结构组成,是一个嵌套结构。
一个简单的数据结构由数据项组成,而复杂的数据结构则包含了其他数据结构,在数据字典中,需要详细列出每个数据结构包含的项
2、IBM WBI的核心是( )。
A.WBI Workbench B.WBI Workbench Server
C.WBI Monitor D.Process Modeler
3、下列说法错误的是( )。
A.U/C矩阵建立之后,还要进行完备性检验,指每个数据项必须有一个生产者和至少一个使用者
B.U/C矩阵的每个功能不一定要有数据的生产和使用活动
C.一致性检验则要求一个数据只能有一个生产者,避免数据有多个源头,产生不一致现象
D.U/C矩阵不仅适用于功能/数据分析,也适用于其他方面的管理分析,应该很好的掌握这种方法
4、业务流程改造说法不正确的是( )。
A.业务流程改造涉及到技术等因素,但与人文等因素没啥关系
B.信息技术应用是流程改造的核心
C.信息技术既是流程改造的出发点
D.也是流程改造的最终目标的体现者
5、以下哪一项说法错误( )。
A.系统结构设计的主要任务是在系统分析的基础上进行功能模块划分
B.一定要通过“自上而下”多次反复,把系统分解为若干个大小适当、功能明确、具有一定的独立性且容易实现的模块,从而把复杂系统的设计转变为多个简单模块的设计
C.合理地进行模块的分解和定义,是系统结构设计的主要内容
D.系统结构设计的基本特点:用分解的方法简化复杂系统;采用图表表达工具;有一套基本的设计准则:有一组基本的设计策略;有一组评价标准和质量优化技术
6、关于模块耦合说法不正确的是( )。
A.两模块间相互传递的信息是数据,联系是一种数据耦合。
数据耦合联系简单,耦合程度低,模块的独立性强,模块的可修改性和可维护性高,是一种较为理想的耦合形式
B.两个模块之间,除了传递数据信息外,还传递控制信息,是控制耦合。
这种耦合对系统的影响比较大,它直接影响到接收该控制信号模块的内部运行。
一般来说,控制耦合出现在模块的中下层
C.当两个或多个模块通过一个公共数据环境相互作用时,它们之间的耦合称为公共.耦合。
公共耦合可以是全程变量、内存的公共覆盖区、存储介质中的文件等
D.一个模块不经调用直接使用或修改另一个模块中的数据,则这种模块之间的连接关系为内容耦合。
内容耦合使得模块的独立性、系统的可修改性和可维护性最差,是一种病态联结,因此,在设计时必须避免这种模块耦合
7、关于数据库设计说法不正确的是( )。
A.数据存储的安全性要求从存储总体结构上保证数据的安全性、一致性和完整性
B.而数据的大量冗余往往为维护数据一致性带来困难,维护一致性就要尽可能地避免数据的冗余
C.要求对数据文件组织合理,数据元素归类和划分合理,以及对数据项进行合理描述
D.无论设计什么样的存储结构,首先应保证对数据进行管理和维护上的方便,它是提高系统运行效率的基础
8、下列哪个不是软件工程的层次( )。
A.过程层 B.方法层
C.应用层 D.工具层
9、下列哪项不是需求分析调查范围( )。
A.组织机构与功能业务 B.数据和数据流程
C.业务流程 D.实现细节
10、下列说法错误的是( )。
A.业务建模便于了解目标组织(将要在其中部署系统的组织)的结构及机制
B.业务建模便于了解目标组织中当前存在的问题并确定改进的可能性
C.一般只有ERP这种大系统才需要对业务流程进行重组
D.业务建模便于确保客户、最终用户和开发人员就目标组织达成共识
11、在软件项目中,需求决策问题说法正确的是( )。
A.分析员须听从呼声高的或来自最高层人物的最大的需求
B.谁将对需求做出决策的问题并没有统一的正确答案
C.分析员须听从用户代表的需求
D.应由系统地开发人员做出需求决策
12、需求间的关系说法错误的是( )。
A.因果关系,只要因需求解决了,果需求就自然解决了,对于这类问题,说明目标时,只要抓住原因就可以了,结果不必再提
B.主次关系,我们要根据实际情况,切实抓住使用者目前最急需解决的问题,作为主要目标
C.权衡关系,某两项需求在实际工作中是矛盾的,此长彼消,此消彼长。
这时使用者心目中往往有一个方面是关心的,而另一个方面则成为一种制约条件 D.平等关系,在实际工作中,还可能存在着平行的事情,需要根据经验合理安排
13、关于需求分析的活动说法不正确的是( )。
A.需求预测,系统分析员对系统的基本需求作一假设
B.需求导出,运用各种信息采集技术的本质要求
C.需求确认,将记录的需求反馈给用户进行检验
D.需求说明,利用NS图,PAD图等工具进行需求描述
14、关于用例说法正确的是( )。
A.用例不能描述业务的交互过程
B.用例不适用于描述用户的功能性需求
C.用例不关心系统设计,编写用例的最昂贵的错误包括太多细节和用户界面说明,使得用例变长,难以阅读
D.用例不适用于增量开发
15、下列关于用例说法错误的是( )。
A.因为用例来源于面向对象的开发环境,所以它不能应用在具有许多开发方法的项目中
B.最重要的,用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要
C.用例的重要功能是用画用例图的功能来鉴别和划分系统功能
D.它把系统分成角色(Actor)和用例
16、估算方法是基于分解的技术的方法,分类正确的是( )。
A.功能点估算法、LOC估算法、IBM模型
B.功能点估算法、IBM模型、MARK II
C.功能点估算法、COCOMO模型、MARK II
D.功能点估算法、LOC估算法、MARK II
17、数据的分析方式说法错误的是( )。
A.围绕系统目标进行分析 B.对信息环境分析
C.围绕现行业务流程进行分析 D.数据的功能分析
18、关于DFD说法错误的是( )。
A.数据流程分析的主要工具是数据流程图
B.数据流程图是现有数据流程的抽象,它包含了具体的组织结构、物流、场所等信息,并从信息流动的角度考察业务执行的过程
C.数据流程图具有抽象性特征
D.数据流程图具有概括性特征
19、哪项不是业务流程分析的内容?( )
A.业务功能分析 B.业务关系分析
C.业务流程优化 D.业务逻辑分析
20、关于流程图说法不正确的项是( )。
A.流程图是用描述程序执行具体步骤的统一规定的标准符号图形表示,是使用历史最久、流行最广的一种描述工具
B.流程图包括处理、判断条件、控制流三种基本成分
C.流程图只描述执行过程而不能描述有关数据
D.流程图表示控制的箭头很灵活,使流程图简单易懂,并易于维护
问答题
21、简述ACTOR、用例可以从不同的层次来描述信息的原因。
22、简述用例在需求中的作用。
23、确定用例的方法有哪些?
24、要进行需求分析的方面有哪些?
25、U/C系统的功能有哪些?
26、简述系统设计的原则。
27、某汽车配件公司最主要的业务,显然是采购和销售,外部项是顾客和供应商。
其第一层数据流程图如图9.3所示。
请分析该公司的第二层及第三层数据流图。
28、根据给定的U/C矩阵,如表9.2所示进行矩阵求解,并可将系统分为哪几个独立的小系统,同时要注明子系统间相互联系的数据有哪些?
29、系统设计中模块划分的原则是什么?
30、在按范围分解模块时应的要求是什么?
答案:
选择题
1、A
2、A
3、B
4、A
5、B
6、B
7、B
8、C
9、D 10、C 11、B 12、D 13、D 14、C 15、A 16、D 17、D 18、B 19、D 20、D
问答题
21、ACTOR、用例可以从不同的层次来描述信息。
采用该原则的原因有:
①需求并不是在项目一开始就很明确,往往是随着项目的推进,逐渐细化。
②人的认知往往具有层次的特性。
从粗到细,从一般到特殊。
采用不同的层次来描述,适于认知的过程。
使用用例开发系统的一般过程。
在开发过程的初始
阶段,可以根据具体的项目特点,制订开发各个视图之间的关联原则,指导规范。
在开发的过程中,视图的组织原则应不断进行维护、更新。
22、用例在需求中的作用:用例是从用户的角度看待系统,而不是基于程序员的角度。
这样,用例驱动的系统能够真正做到以用户为中心,用户的任何需求都能够
在系统开发链中完整的体现。
用户和程序员间通过用例沟通,避免了牛头马嘴的尴尬局面。
从前,系统开发者总是用于开发的流程。
当系统的开发过程都是基于用例
的,如用用例获取需求、设计、编码和测试,那么这个开发过程就是用例驱动的。
23、用例和用例文档一书中提到了以下几种方法来确定用例。
首先明确执行者和他们的角色,然后确定业务过程,在这一过程中每一个参与者都在为确定用例而努力。
确定系统所能反映的外部事件,然后把这些事件与
参与的执行者和特定的用例联系起来。
可以把它们描述成需求,这些功能需求可以使用户完成其任务,也可以把它们描述成非功能需求,这些非功能需求描述了系统
的限制和用户对质量的期望。
虽然最初的屏幕构思有助于描述你对需求的理解,但是你必须细化用户界面设计,建立用例文档。
在每一次的需求获取之后,都会生成
很多未整理的需求,你必须将它们组织成用例文档。
使用诸如模板的技术能够提高你的速度和需求的复用性。
一个用例文档可以使用表格来组织,主要的要素包括了
用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需
求、假设、注释和问题。
虽然列举㈩了这么多的属性,但是实际中使用的属性这要看你的团体而定,视项目的大小而定。
把大量的时间花在用例的描述上是没有意义
的。
用户需要的是一个软件系统,并不是一大堆的用例说明。
24、需求分析的方面如下:
①功能需求,列举出所开发系统要实现的功能,这是系统的硬性指标。
②性能需求,列出系统所要达到的技术性能指标,包括存储容量限制、运行时间限制、响应时间限制、传输速度要求和安全保密等。
③资源和环境需求,这是对系统运行时所处环境和资源的要求。
④可靠性需求,在需求分析时,应对所开发软件在投入运行后不发生故障的概率,按实际的运行环境提出要求。
对于那些重要的子系统,或是运行失效会造
成严重后果的模块,应当提出较高的可靠性要求,条件允许的最后能通过冗余设计,达到热备份,以期望系统能够高度可靠地稳定运行,避免因运行事故而带来不必
要的损失。
⑤安全保密需求,不同企业对应用系统的安全、保密的要求显然是不同的。
应当根据实际需求恰当地做出规定,以便使所开发的系统符合特殊的实际,使其
在运行中安全保密方面的性能得到必要的保证。
⑥用户界面需求,系统与用户界面的友好性是用户能够方便有效地使用该系统的关键之一,可以说用户就是系统的上帝,要使系统为用户服务,当然对用户
进行必要的培训也是必须的,后文将提到。
从市场角度来看,具有友好用户界面的系统才可能会有较强的竞争力。
因此,必须在需求分析时,细致地规定用户界面要
达到的要求。
⑦成本消耗与开发进度需求,对电子商务系统项目开发的进度和相应的费用提出要求,作为开发管理的依据。
⑧可扩展性需求,在开发过程中,对系统将来可能的扩充与修改做准备,留出必要的接口,为系统日后的升级扩展做准备。
25、U/C矩阵的功能:
①通过对U/C矩阵的正确性检验,及时发现前期调查和分析中的错误及疏漏。
②通过对U/C矩阵的正确性检验,分析数据的正确性和完整性。
③通过对U/C矩阵的求解,得到子系统的合理划分。
④通过子系统之间的数据使用关系,确定子系统之间的共享数据。
26、从逻辑模型到物理模型的设计是一个由抽象到具体的过程,有时没有明确的界限,甚至可能有反复。
经过系统设计,设计人员应该能为程序员提供经过评审的
完整、清楚、准确、规范的系统设计文档,且对设计规范中不清楚的地方做出解释。
系统设计总的原则是保证系统设计目标的实现,并在此基础上使技术资源的运用
达到最佳。
在进行系统设计过程中,应遵循以以下原则。
①系统性原则,系统是作为一个有机整体而存在的。
因此,在系统设计中,要从整个系统的角度进行考虑,使系统有统一的信息代码、统一的数据组织方法
、统一的设计规范和标准,以提高系统的设计质量。
②经济性原则,经济性原则是指在满足系统要求的前提下,尽可能减少系统的费用支出。
一方面,在系统硬件投资上不能盲目追求技术上的先进,而应以满
足系统应用需要为前提。
另一方面,系统设计应避免不必要的复杂化,各模块应尽可能简洁,以便缩短处理流程,减少处理时间。
③可靠性原则,可靠性既是评价系统设计质量的一个重要指标,又是系统设计的一个基本出发点。
只有设计出的系统是安全可靠的,才能在实际中发挥它应
有的作用。
一个成功的管理信息系统必须具有较高的可靠性,如安全保密性、检错及纠错能力、抗病毒能力、系统恢复能力等。
④简单性原则,在系统达到预定目标、完成规定功能的前提下,应该尽量简单。
具体来说,在设计过程中,要设法减少数据输入的次数和数量,提高系统中
数据的共享性:要使操作简单化,使用户容易理解操作的步骤和要求,确保用户的主动地位;系统结构清晰合理,易于理解和维护。
⑤灵活性原则,系统对外界环境的变化要有很强的适应能力,系统容易修改和维护。
因此系统设计人员要有一定的先见性,要从通用的角度考虑系统设计。
27、系统从顾客那里接受订货要求,把汽车配件卖给顾客。
当存货不足时,汽车配件公司向供应商发出订货要求,以满足销售的需要。
但该图没有反映账务,而且
销售和采购也没有分开表示,只是高度概括地反映了汽车配件公司的业务,因此要进一步扩展出第二层数据流程图。
该系统的主要逻辑功能有销售、采购和会计三个。
主要的外部项有顾客和供应商两个。
当然允许有许多顾客和许多供应商。
当顾客的订货要求被接受以后,就要按照顾客要购买的汽车配件以及需要的数量查找库存量,确定是否能够满足顾客的订货要求。
如果能够完全满足,就给顾客开发货单,并修改汽车配件的库存量,同时还要通知会计准备收款。
如果只能满足一部分或完全不能满足顾客的订货要求,就要把不能满足的订货记录下来,并通知采购部门,然后应向供应商发出订货要求。
当供应商接到汽车配件公司的订货要求,把货物发来后,采购部门要办入库手续,修改库存量,同时向销售部门发出到货通知,销售部门按到货配件检索订货单,向顾客补齐所要求的配件数量。
会计部门收到供应商的发货单后,应该准备办理付款业务。
第二层数据流程图比较具体地反映了汽车配件公司的数据流程,但是只考虑了正常情况,未考虑发生错误或特殊的情况。
例如,顾客订货单填写不正确,供应商发来的货物与采购部门的订货要求不符合等,都属于出错或例外处理。
原则上讲,第二层数据流程图不反映出错处理和例外处理,它只反映主要的、正常的逻辑处理功能,出错或例外处理应该在低层的更为详细的数据流程图里反映。
我们可以从“销售”、“采购”、“会计”三个处理逻辑分别扩展出第三层数据流程图。
28、U/C矩阵的行或列之间没有固定的顺序,通过行或列的调整,使得矩阵中的C尽量靠近对角线,然后以C为标准划分子系统,即构成了U/C矩阵的解。
小方框的划分是任意的,但必须把所有的C都包含在小方框内,每个小方框既没有重叠也不会遗漏任何一个数据和功能。
如表9.3中方框所示。
在实际划分中,可参考业务处理的要求和分析员个人的习惯进行。
在子系统划分以后,仍然存在着子系统以外的U元素,表明存在着跨子系统的数据使用,即子系统间的数据联系。
从表9.3的左上到右下,按小方块(阴影部分)的划分可以将系统分为经营计划子系统、产品工艺子系统、生产制造子系统、销售子系统、财务子系统和人事子系统。
这样就使系统数据间的凝聚性较强,耦合性较弱。
表中的U被分割成两类,一类在小方框内,表示数据只在一个子系统内产生和使用,可以考虑把数据放在子系统的计算机设备中处理:另一类数据使用关系U在小方框之外,表示不同子系统间存在着数据联系,需要考虑数据在网络中的分布和传递问题。
29、模块划分的原则如下。
(1)低耦合,高聚合原则
耦合是表示模块之间联系的程度。
紧密耦合表示模块之间联系非常强,松散耦合表示模块之间联系比较弱,非耦合则表示模块之间无任何联系,是完全独立的。
模块耦合度越低,说明模块之间的联系越少,相互间的影响也就越小,产生连锁反应的概率就越低,在对一个模块进行修改和维护时,对其他模块的影响程度就越小,系统可修改性就越高。
聚合则用来表示一个模块内部各组成成分之间的联系程度。
一般说来,在系统中各模块的聚合度越大,则模块间的耦合度越小。
但这种关系并不是绝对的。
耦合度小使得模块间尽可能相对独立,从而各模块可以单独开发和维护。
聚合度大使得模块的可理解性和维护性大大增强。
因此,在模块的分解中应尽量减少模块的耦合度,力求增加模块的聚合度。
(2)作用范围应在控制范围内
在进行模块划分设计时,可能会遇到在某个模块中存在着判定处理功能,某些模块的执行与否取决于判定语句的结果。
为了搞好判定处理模块的结构设计,我们需要了解对于一个给定的判定会影响哪些模块。
(3)合理的模块扇入和扇出数
模块的扇入表达了一个模块与它的直接上级模块的关系。
模块的扇入数是指模块的直接上层模块的个数。
模块的扇入数越大,表明它要被多个上级模块所调用,其公用性越强,说明模块分解得较好,在系统维护时能减少对同一功能的修改,因此要尽量提高模块的扇入数。
模块的扇出表达了一个模块对它的直接下属模块的控制范围。
模块的扇出数是指一个模块拥有的直接下层模块的个数。
模块的直接下属模块越多,表明它要控制许多模块,所要做的事情也就越多,它的聚合度可能越低。
所以要尽量把一个模块的直属下级模块控制在较小的范围之内,即模块的扇出系数不能太大。
一般来说,一个模块的扇出系数应该控制在6以内,如果超过7则出错的概率可能会加大。
(4)合适的模块大小
如果一个模块很大,那么它的内部组成部分必定比较复杂,或者它与其他模块之间的耦合度可能比较高,因此对于这样一个较大的模块应该采取分解的方法把它尽可能分解成若干个功能单一的较小的模块,而原有的大模块本身的内容被大大减少并成为这些小模块的上级模块。
一般来说,一个模块中所包含的语句条数以几十条较好,但这也不是绝对的。
在分解一个大模块时,不能单凭语句条数的多少,而主要是按功能进行分解,直到无法做出明确的功能定义。
在分解时既要考虑到模块的聚合度,又要考虑到模块之间的耦合度,在达两者之间选择一个最佳方案。
30、在分解模块时应该按以下要求进行分解。
(1)分解模块时作用范围与控制范围的要求
①判定的作用范围应该在判定所在模块的控制范围之内。
②判定所在模块在模块层次结构中的位置不能太高。
根据以上两点可知,最理想的模块划分的判定范围由判定所在模块及其直接下级模块组成。
(2)当出现作用范围不在控制范围之内时的纠正措施
①把判定所在的模块合并至上层模块中,或从低层模块移到高层模块使判定的位置提高。
②把受判定影响的模块移到模块控制范围之内。