Managing Complexity Clause Samples

Managing Complexity. In researching the material for this section, the author was amazed to discover how so many of the ideas of the likes of ▇▇▇▇▇▇▇ [46], ▇▇▇▇▇▇▇ [69], ▇▇▇▇▇▇▇ [141], ▇▇▇▇▇ [19], ▇▇▇▇▇▇▇▇ [70], ▇▇▇▇▇▇▇▇ [121], ▇▇▇▇▇▇ and ▇▇▇▇▇▇ [128, 129] to name but a few—famous methodologists and truly remarkable figures of their time—still resonate today. In reading their most significant works, what comes across loud and clear is that they were all motivated by one thing: the desire to manage the complexity of software systems more effectively. The story starts with the humble subroutine. As ▇▇▇▇▇▇▇ [69] writes, “the invention of the subroutine in 1949 allowed larger functions to be specified in terms of smaller functions”, and argued that it was only “a relatively short step to view a program or system as having a single function that could be successively decomposed into smaller and smaller functions, until the functions at the level of the machine were reached”. This is essentially the view on which functional decomposition is based, and the one underlying ▇▇▇▇▇▇▇’▇ Structured Analysis and System Specification [46]. ▇▇▇▇▇▇▇ notes in the foreword, “it is a pleasure to watch the emergence of a new discipline”. In ▇▇▇▇▇▇▇’▇ view, a system specification consists of three things. First, a set of data flow diagrams comprising data flows, processes (also known as “bubbles”), data stores and sinks, for “showing the major decomposition of function and the interfaces among the pieces”. Second, a data dictionary documenting the interface flows and the data stores on all data flow diagrams. Third, a transform description describing the internals of each process in a rigorous fashion. The key goal of structured analysis is to define a useful partitioning of the system, where the rule of thumb is that a data flow diagram should not be too large to fit on a page.1 Yourdon [141] reported that the uptake of structured programming in the mid-1970s led to an order of magnitude improvement in the productivity, reliability and maintainability of software systems, but warned that a perfectly structured goto-less program is of little value if its basic design is unsound. ▇▇▇▇▇▇▇’s approach was to design a system “whose pieces are small, easily related to the application, and relatively independent of each other”. He proposed two criteria for judging the “goodness” of a design. First, coupling : a measure of the degree to which components are dependent on each other. Second, cohesion: a measu...