A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in a problem specification will trigger a change of just one module, or a small number of modules.This criterion is directly connected to the general goal of extendibility.Change is an integral part of the software construction process. The requirements will almost inevitably change as the project progresses. Continuity means that small changes should affect individual modules in the structure of the system, rather than the structure itself.
The term “continuity” is drawn from an analogy with the notion of a continuous function in mathematical analysis. A mathematical function is continuous if a small change in the argument will yield a proportionally small change in the result. Here the function considered is the software construction method, which you can view as a mechanism for obtaining systems from specifications.
This mathematical term only provides an analogy, since we lack formal notions of size for software. More precisely, it would be possible to define a generally acceptable measure of what constitutes a “small” or “large” change to a program but doing the same for the specifications is more of a challenge. If we make no pretense of full rigor, however,the concepts should be intuitively clear and correspond to an essential requirement on any modular method.
Another rule states that a single notation should be available to obtain the features of an object whether they are represented as data fields or computed on demand.A method in which program designs are patterned after the physical implementation of data will yield designs that are very sensitive to slight changes in the environment.
No comments:
Post a Comment