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



1、下列需求描述中，不属于飞机订票系统功能性需求的是（70  ）
A、 必须使用某排序算法根据离开时间对航班排序
B、 什么信息要出现在机票和报告中
C、 什么信息必须存储在旅行社和其他人访问的数据库中
D、 如何输入有关航班、乘客及订票信息

答案:A
答题解析:

选项A不属于功能性需求。

2、  In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.  But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describe steps and sequences of events.  Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requirements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do. In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement.  Use cases are particularly well suited to capturing these kind of requirements. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.  But, like anything, use cases come with their own problems, and as useful as they are, they can be （75） The result is something that is as bad, if not worse, than the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.
A、 plenty
B、 loose
C、 extra
D、 strict

答案:D
答题解析:

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

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

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

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

(71) A 大量的B 宽松的C 额外的D 严格的

(72) A 不可能的B 可能的C 合理的D 实际的

(73) A 现代的B 常规的 C 不同的D 正式的

(74) A 静态 B 自然 C动态 D 原始

(75) A误用 B 应用 C使用 D 有力量的

3、  In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.  But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describe steps and sequences of events.  Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requirements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do. In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement.  Use cases are particularly well suited to capturing these kind of requirements. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.  But, like anything, use cases come with their own problems, and as useful as they are, they can be （75） The result is something that is as bad, if not worse, than the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.
A、 impossible
B、 possible
C、 sensible
D、 practical

答案:A
答题解析:

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

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

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

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

(71) A 大量的B 宽松的C 额外的D 严格的

(72) A 不可能的B 可能的C 合理的D 实际的

(73) A 现代的B 常规的 C 不同的D 正式的

(74) A 静态 B 自然 C动态 D 原始

(75) A误用 B 应用 C使用 D 有力量的

查看完整试题>>>