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

2017年上半年上午卷

The beauty of software is in its function, in its internal structure, and in the way in which it is created by a team. To a user, a program with just the right features presented through an intuitive and (71) $Simple$ interface is beautiful. To a software designer, an internal structure that is partitioned in a simple and intuitive manner, and that minimizes internal coupling is beautiful. To developers and mangers, a motivated team of developers making significant pprogress every week, and producing defect-free code, is beautiful. There is beauty on all these levels.
Our world needs software-lots of software. Fifty years ago software was somethin that ran in a few big and expensive machines. Thirty years ago it was something that ran in most companies and industrial settings. Now there is software running in our cell phones, watches, appliances, automobiles, toys, and tools. And need for new and better software never (72) $stops$. As our civilization grows and expands, as developing nations build their infrastructures, as developed nations strive to achieve eveer greater efficiencies, the need for more and more Software (73) $continues$ to increase. It would be a great shame if, in all that software, there was no beauty.
We know that software can be ugly. We know that it can be hard to use, unreliable, and carelessly structured. We know that there are software systems whose tangled and careless internal structures make them expensive and difficult to change. We know that there are software systems that present their features through an awkward and cumbersome interface. We know that there are software systems that crash and misbehave. These are (74) $ugly$ systems. Unfortunately, as a profession, software developers tend to create more ugly systems than beautiful ones.
There s a secret that the best software developers know. Beauty is cheaper than ugliness. Beauty is faster than ugliness. A beautyiful software system can be built and maintained in less time, and for less money, than an ugly one. Novice software developers don’t understand this. They think that they have to do everything fast and quick. They think that beauty is ( 75) $impractical$. No! By doing things fast and quick, they make messes that make the software stiff, and hard to understand, Beautiful systems flexible and sasy to understand. Building themand maintaining them is a joy. It is ugliness that is impractical. Ugliness will slow you down and make your software expensive and brittle. Beautiful systems cost the least build and maintain, and are delivered soonest.

软件之美在于它的功能，内部结构以及团队创建的方式。对于用户来说，通过直观的（71）简单界面呈现正确功能的程序非常漂亮。对于软件设计人员来说，内部结构以简单直观的方式进行分区，并且内部耦合最小化是美观的。对于开发人员和管理人员来说，一个积极的开发团队每周都会做出重大进展，并且生成无缺陷的代码，这很漂亮。所有这些层面都有美感。
我们的世界需要软件 - 许多软件。五十年前，软件是在一些大而昂贵的机器上运行的。三十年前，它在大多数公司和工业环境中运行。现在我们的手机，手表，电器，汽车，玩具和工具中都有软件运行。并且需要新的和更好的软件永远（72）停止。随着我们文明的发展和扩张，随着发展中国家建设其基础设施，随着发达国家努力提高效率，对越来越多的软件（73）的需求不断增加。如果在所有软件中没有美感，那将是一件非常遗憾的事。
我们知道软件可能很难看。我们知道它很难使用，不可靠和粗心结构。我们知道存在软件系统，其内部结构错综复杂，使得它们变得昂贵且难以改变。我们知道有些软件系统通过一个笨拙且繁琐的界面来展示它们的功能。我们知道有软件系统崩溃和行为不端。这些是（74）丑陋的系统。不幸的是，作为一种职业，软件开发人员倾向于创建比漂亮的系统更丑陋的系统。
最好的软件开发人员知道一个秘密。美丽比丑陋便宜。美丽比丑陋更快。与丑陋的软件系统相比，可以在更短的时间内构建和维护一个美丽的软件系统，并且花费更少。新手软件开发人员不明白这一点。他们认为他们必须快速而迅速地完成所有工作。他们认为美（75）是不切实际的。没有！通过快速，快速地做事，他们制造混乱，使软件变得僵硬，难以理解，美丽的系统灵活易懂。建立维护他们是一种快乐。丑陋是不切实际的。丑陋会降低你的速度，让你的软件变得昂贵和脆弱。美丽的系统成本和维护成本最低，并且交付最快。

(71)
A. $Simple$ 简单
B. Hard 硬
C. Complex 复杂
D. duplicated 复制
(72)
A. happens 发生
B. exists 存在
C. $stops$ 停止
D. starts 启动
(73)
A. starts 启动
B. $continues$ 继续
C. appears 出现
D. stops 停止
(74)
A. practical 实际的
B. useful 有用
C. beautiful 美丽
D. $ugly$ 丑陋
(75)
A. $impractical$ 不切实际的
B. perfect 完善
C. time-wasting 浪费时间
D. practical 实际的

---

2017年下半年上午卷

The development of the Semantic Web proceeds in steps, each step building a layer on top of another. The pragmatic justfication for this approach is that it is easier to achieve (71)$consensus$ on small steps, whereas it is much harder to get everyone on board if too much is attempted. Usually there are serveral research groups moving in diffenent directions : this (72) $competition$ of ideas is a major driving force for scientific progress. However, from an engineering perspective there is a need to standardize. So, if most researchers agree on certain issues and disagree on others, it makes sense to fix the point of agreement. This way, even if the more ambitious reaearch efforts should fail, there will be at least (73) $partial$ positive outcomes.
Once a (74) $standard$ has been established, many more groups and companies will adopt it, instead of waiting to see which of the alternative research lines will be successful in the end. The nature of the Semantic Web is such that companies and single users must build tools, add content, and use that content. We cannot wait until the full Semantic Web vision materializes-it may take another ten years for it to be realized to it’s full (75) $object$ (as envisioned today, of course).

语义Web的开发分步进行，每一步都在另一个上面构建一个层。对这种方法的务实选择是，在小步骤上更容易实现（71）共识，而如果尝试太多则让每个人都更难实现。通常，有几个研究小组在不同的方向上发展：这种（72）思想竞争是科学进步的主要推动力。但是，从工程角度来看，需要进行标准化。因此，如果大多数研究人员就某些问题达成一致并对其他问题持不同意见，那么确定协议点是有意义的。这样，即使更雄心勃勃的研究工作失败，也会有至少（73）部分积极成果。
一旦建立了（74）标准，更多的团体和公司将采用它，而不是等待看到哪个替代研究线最终会成功。语义Web的本质是公司和单个用户必须构建工具，添加内容和使用该内容。我们不能等到完整的语义Web愿景实现 - 它可能需要另外十年才能实现它的完整（75）对象（当然，如今所设想的）。

(71)
A. conflicts 冲突
B. $consensus$ 共识
C. success 成功
D. disagreement 异议
(72)
A. $competition$ 竞争
B. agreement 协议
C. cooperation 合作
D. collaboration 协作
(73)
A. total 总
B. complete 完成
C. $partial$ 局部
D. entire 整个
(74）
A. technology 技术
B. $standard$ 标准
C. pattern 图案
D. model 模型
(75)
A. area 区域
B. goal 目标
C. $object$ 对象
D. extent 程度