摘要：对于【软件设计师】软考考试而言，试题无疑是最重要的学习资料之一。在软考备考过程中，吃透试题、掌握试题所考知识点、熟悉试题的出题思路，对我们提升分数的效果是最明显的，通过对试题的反复练习，还可以查漏补缺。今天，给大家带来【2015年11月 软件设计师 上午题】部分试题的详解，一起来看看吧~



1、以下关于层次化局域网模型中核心层的叙述，正确的是（）。
A、 为了保障安全性，对分组要进行有效性检查
B、 将分组从一个区域高速地转发到另一个区域
C、 由多台二、三层交换机组成
D、 提供多条路径来缓解通信瓶颈

答案:B
答题解析:

层次化网络设计中各个层次的主要功能包括：

接入层：用户接入、计费管理、MAC地址认证、收集用户信息。

汇聚层：网络访问策略控制、数据包处理、过滤、寻址。

核心层：高速数据交换，常用冗余机制。

2、In a world whereit seems we already have too much to do, and too many things to think about, itseems the last thing we need is something new that we have to learn.But use cases dosolve a problem with requirements:with （71） declarative requirements it's hard to describe steps and sequences ofevents.Use cases, statedsimply, allow description of sequences of events that, taken together, lead toa system doing something useful.As simple as this sounds,this is important.When confronted only with a pile of requiements, it's often（72）to make sense of what the authors of therequirements really wanted the system to do.In the preceding example, use casesreduce the ambiguity of the requirements by specifying exactly when and underwhat conditions certain behavior occurs;as such, the sequence of the behaviors canbe regarded as a requirement. Use cases are particularly well suited to captureapproaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with theiremphasis on declarative requirements and "shall"statements,completely fail to capture fail to capture the （74） of the system's behavior. Use cases are asimple yet powerful way to express the behavior of the system in way that allstakeholders can easily understand.But,likeanything, use cases come with their own problems, and as useful as theyare,they can be （75）. The result is something that is as bad, if not worse, that the originalproblem.Therein it's important to utilize use cases effectively withoutcreating a greater problem than the one you started with.作答71题
A、 plenty
B、 loose
C、 extra
D、 strict

答案:D
答题解析:

在这个世界上，我们似乎已经有太多的事情要做，太多的事情要思考，似乎我们最不需要的就是我们必须学习的新东西。

但是用例确实解决了需求的一个问题:对于严格的声明性需求，很难描述事件的步骤和序列。

简单地说，用例允许描述事件序列，这些事件组合在一起，导致系统做一些有用的事情。这听起来很简单，但很重要。当只面对一堆需求时，通常不可能弄清楚需求的作者真正想让系统做什么。在前面的例子中，用例通过精确地指定某些行为发生的时间和条件来减少需求的模糊性;因此，行为的顺序可以被看作是一个需求。用例特别适合于捕获方法。尽管这听起来很简单，但事实是传统的需求捕获方法，它们强调声明性的需求和“应该”语句，完全无法捕获系统行为的动态。用例是以所有涉众都能容易理解的方式表达系统行为的一种简单而强大的方式。

但是，像任何事情一样，用例也有自己的问题，尽管它们很有用，但也可能被误用。结果是某些东西和原来的问题一样糟糕，如果不是更糟的话。因此，有效地利用用例而不产生比开始时更大的问题是很重要的。

3、In a world whereit seems we already have too much to do, and too many things to think about, itseems the last thing we need is something new that we have to learn.But use cases dosolve a problem with requirements:with （71） declarative requirements it's hard to describe steps and sequences ofevents.Use cases, statedsimply, allow description of sequences of events that, taken together, lead toa system doing something useful.As simple as this sounds,this is important.When confronted only with a pile of requiements, it's often（72）to make sense of what the authors of therequirements really wanted the system to do.In the preceding example, use casesreduce the ambiguity of the requirements by specifying exactly when and underwhat conditions certain behavior occurs;as such, the sequence of the behaviors canbe regarded as a requirement. Use cases are particularly well suited to captureapproaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with theiremphasis on declarative requirements and "shall"statements,completely fail to capture fail to capture the （74） of the system's behavior. Use cases are asimple yet powerful way to express the behavior of the system in way that allstakeholders can easily understand.But,likeanything, use cases come with their own problems, and as useful as theyare,they can be （75）. The result is something that is as bad, if not worse, that the originalproblem.Therein it's important to utilize use cases effectively withoutcreating a greater problem than the one you started with.作答72题
A、 impossible
B、 possible
C、 sensible
D、 practical

答案:A
答题解析:

在这个世界上，似乎我们有太多的事情要去做，有太多的事情要去思考，那么需要做的最后一件事就是必须学习新事物。

而用例恰恰可以解决带有需求的问题：如果具有严格声明的需求，则很难描述事件的步骤和序列。

简单地说，用例可以将事件序列的说明放在一起，引导系统完成有用的任务。正如听起来一样简单---这很重要。在面对很多需求的时候，通常不太可能理解需求的作者真正想要系统做什么。在前面的例子中，通过指定特定行为发生的时间和条件，用例减少了需求的不确定性。这样的话，行为的顺序就可以当作是一种需求。用例特别适用于捕捉这类需求。尽管听起来可能很简单，但事实情况是由于常规的需求捕捉方法所侧重的是声明需求和“应该怎么样”的陈述，因此完全无法捕捉系统行为的动态方面。用例是一种简单而有效的表达系统行为的方式，使用这种方式所有参与者都很容易理解。

但是与任何事物一样，用例也存在自己的问题---在用例非常有用的同时，人们也可能误用它，结果就产生了比原来更为糟糕的问题。因此重点在于：如何有效地使用用例，而又不会产生比原来更严重的问题。

查看完整试题>>>