Software Design 2e - DIM

74Design qualitiesHidden dependenciesThis concept describes a relationship between two components, such that while one isdependent upon the other the relationship is not fully visible. From a design standpoint,this touches upon one of the problems that we will be addressing later whenexamining design notations. Notations often capture one type of dependency (forexample, that component A invokes component B) but say nothing about other dependenciesthat exist between them (A and B share knowledge about certain data typesand structures). However, in thinking about their solution, the designer will need toconsider all of these relationships. Indeed, the problem becomes potentially muchmore significant when a design is being modified during maintenance: changing adesign is likely to be much more difficult if the designer has only a part of the necessaryknowledge about dependencies directly available to them, a point that is illustratedparticularly effectively in the study reported in Littman et al. (1987). (Thisdimension is also one that is particularly relevant for websites and their maintenance.)Secondary notationThis dimension describes additional information that is conveyed by means other thanthe ‘official syntax’. We will only touch on it briefly here, as we will return to this issuein the following chapters but, in brief, a good example of this problem is where designersmake use of local layout conventions when using particular design notations.While these may be familiar to the originators of the design, they may not be so evidentto others who join the team, or to those who later need to maintain the resultingsystem.ViscosityThis describes the concept of ‘resistance to change’. During design development, thismay well arise as a consequence of premature commitment, and during maintenance itmay be a significant reflection of the resulting design ‘quality’. Both conventional softwareand websites have many mechanisms that can easily result in high viscosity, especiallyat the more detailed levels of implementation. (As an example of this dimensionwithin the context of program code, we can consider the practice of using embeddednumerical constants rather than declaring symbolic forms. Using the specific value17.5 at various points in the code, rather than declaring a constant value such asVatRate = 17.5; at the start of the program, is only too typical an illustration of thispractice. When it becomes necessary later to adjust the value of the VAT rate, then eachinstance has to be located and modified, rather than simply changing the value definedfor the constant. Even worse, since 17.5 might occur within a program for other reasons(for example, within 217.53), some values may even get changed in error!)Viscosity is a readily recognizable property at many levels of abstraction, even ifit is not one that is easily quantified in design terms. For a design it may representthe extent to which modules are interdependent, and the differences that exist betweenthe ‘conceptual’ form of a solution and the one that actually emerges from the designprocess. (An interesting illustration of this is provided in Bowman et al. (1999), whichanalyses the ‘architectural structure’ of the software making up the Linux operating