"A commitment to simplicity of design means addressing the essence of design - the abstractions on which software is built - explicitly and up front. Abstractions are articulated, explained, reviewed and examined deeply, in isolation from the details of the implementation. This doesn’t imply a waterfall process, in which all design and specification precedes all coding. But developers who have experienced the benefits of this separation of concerns are reluctant to rush to code, because they know that an hour spent on designing abstractions can save days of refactoring." (Daniel Jackson, "Software Abstractions", 2006)
"A language for describing software abstractions is more than
just a logic. You need ways to organize a model, to build larger models from
smaller ones, and to factor out components that can be used more than once. There
are also small syntactic details - such as shorthands for declarations - that make
a language usable in practice. And finally, there’s the need to communicate
with an analysis tool, by indicating which analyses are to be performed."
"A model diagram declares some sets and binary relations, and imposes some basic constraints on them. A diagram is a good way to convey the outline of a model, but diagrams aren’t expressive enough to include detailed constraints." (Daniel Jackson, "Software Abstractions", 2006)
"Abstractions matter to users too. Novice users want programs whose abstractions are simple and easy to understand; experts want abstractions that are robust and general enough to be combined in new ways. When good abstractions are missing from the design, or erode as the system evolves, the resulting program grows barnacles of complexity. The user is then forced to master a mass of spurious details, to develop workarounds, and to accept frequent, inexplicable failures." (Daniel Jackson, "Software Abstractions", 2006)
"An assertion is a constraint that is intended to follow from the facts of the model. […] Typically, assertions play two different roles. Some express mundane properties that aren’t interesting in their own right; they’re written purely to detect flaws in the model. It’s surprising how effective even a few such assertions can be in uncovering subtle flaws. […] Other assertions express truly essential properties, and are sometimes more fundamental than the facts of the model." (Daniel Jackson, "Software Abstractions", 2006)
"Analysis brings software abstractions to life in three ways.
First, it encourages you as you explore, by giving you concrete examples that
reinforce intuition and suggest new scenarios. Second, it keeps you honest, by
helping you to check as you go along that what you write down means what you
think it means. And third, it can reveal subtle fl aws that you might not have
discovered until much later (or not at all)."
"An abstraction is not a module, or an interface, class, or
method; it is a structure, pure and simple - an idea reduced to its essential
form. Since the same idea can be reduced to different forms, abstractions are always,
in a sense, inventions, even if the ideas they reduce existed before in the
world outside the software. The best abstractions, however, capture their
underlying ideas so naturally and convincingly that they seem more like
discoveries."
"Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization […] Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make." (Daniel Jackson, "Software Abstractions", 2006)
No comments:
Post a Comment