2015软件设计师考试（英语部分）

2015年上半年上午卷

Why Have Formal Documents? Finally, writing the decisions down is essential. Only when one writes do the gaps appear and the (71) $inconsistencies$ protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones. Second, the documents will communicate the decisions to others. The manager will be continually amazed that policies he took for common knowledege are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the (72) $same$ directon, his chief daily task will be communication, not decision-making, and his documents will immensely (73) $lighten$ this load. Finally, a manager’s documents give him a data base and checklist. By reviewing them (74) $periodically$ he sees where he is, and he sees what changes of emphasis or shifts in direction are needed. The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable. Such a plan consists of documents on what, when, how much, where, and who. This small set of critical documents (75) $decides$ much of the manager’s work. If their comprehensive and critical nature is recognized in the beginning, the manager can approach them as friendly tools rather than annoying busywork. He will set his direction much more crisply and quickly by doing so.

为什么要有正式文件？最后，写下决定是至关重要的。只有当一次写入时才会出现间隙，并且（71）不一致性突出。写作行为最终需要数百个小决策，而这些决策的存在将明确，准确的政策与模糊政策区分开来。其次，文件会将决定传达给他人。经理将不断惊讶于他所采取的共同知识政策，他的团队成员完全不知道。由于他的基本工作是保持每个人都参与同样的工作，他的主要日常任务将是沟通，而不是决策，他的文件将极大地减轻这种负担。最后，经理的文件为他提供了数据库和清单。通过定期回顾他们（74）他会看到他在哪里，并且他看到需要改变重点或改变方向。经理的任务是制定计划然后实现计划。但只有书面计划才是准确和可传播的。这样的计划包括关于什么，何时，多少，何地和谁的文件。这一小组关键文件（75）决定了经理的大部分工作。如果一开始就认识到他们的综合性和批判性，那么经理可以将他们视为友好的工具，而不是讨厌繁忙的工作。通过这样做，他将更清晰，更快地设定方向。

(71)
A. $inconsistencies$ 不一致性
B. consistencies 一致性
C. steadiness 稳健
D. adaptability 适应性
(72)
A. other 其他
B. different 不同
C. another 另一个
D. $same$ 相同
(73)
A. extend 延伸
B. broaden 扩大
C. $lighten$ 减轻
D. release 发布
(74)
A. $periodically$ 定期
B. occasionally 偶尔
C. infrequently 不常
D. rarely 很少
(75)
A. $decides$ 决定
B. encapsulates 包囊
C. realizes 实现
D. recognizes 识别

---

2015年下半年上午卷

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) $strict$ declarative requirements it’s hard to describe steps and swquences 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 improtant. When confronted only with a pile of requiements, it’s often (72) $impossible$ 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 capture approaches. Although this may sound simple, the fact is that (73) $conventional$ requirement capture approaches, with their emphasis on declarative requirements and “shall” statements, completely fail to capture fail to capture the (74) $dynamics$ 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) $misapplied$. The result is something that is as bad, if not worse, that the original problem. Therein it’s important to utilize use cases effectively without creating a greater problem than the one you started with.

在一个看起来我们已经有太多事情需要做的事情以及太多需要思考的事情上，似乎我们需要的最后一件事是我们必须学习的新事物。但是用例确实解决了需求的问题：使用（71）严格的声明性要求，很难描述事件的步骤和时序。简单地说，用例允许描述事件序列，这些事件序列一起导致系统执行某些有用的操作。听起来很简单，这很重要。当只面对一堆要求时，通常（72）无法理解要求的作者真正希望系统做什么。在前面的示例中，用例通过精确指定何时以及在何种条件下发生某些行为来减少需求的模糊性;因此，行为的顺序可以被视为一种要求。用例特别适合捕获方法。虽然这听起来很简单，但事实是（73）传统的需求捕获方法，强调声明性要求和“应该”语句，完全无法捕获无法捕获系统行为的（74）动态。用例是一种简单而有效的方式，以所有利益相关者都能轻松理解的方式表达系统行为。但是，就像任何事情一样，用例会带来自己的问题，尽管它们很有用，但它们可能会被误用。结果是原始问题一样糟糕，甚至更糟。因此，有效利用用例非常重要，而不会产生比您开始时更大的问题。

(71)
A. plenty 丰富
B. loose 疏松
C. extra 额外
D. $strict$ 严格
(72)
A. $impossible$ 不可能
B. possible 可能
C. sensible 明智
D. practical 实际的
(73)
A. modern 现代
B. $conventional$ 常规
C. different 不同
D. formal 正式
(74)
A. statics 静力学
B. nature 性质
C. $dynamics$ 动力学
D. originals 原件
(75)
A. $misapplied$ 误用
B. applied 应用的
C. used 用过的
D. powerful 强大