Software Design 2e - DIM

Some of the particular issues that the case study identifies from the viewpoint ofindividual component design are as follows:415nnnthe benefits of large components that are easy to reuse in preference to smaller onesthat could be developed in-house;the high cost of maintaining backward compatibility with early installations (thisarises largely because the system studied was a ‘product line’ rather than a singlesystem);the need to separate out those features of a component that depend upon platforminteractions in order to assist with ease of change (implementational differenceswhen using different C++ compilers created some particular problems).At the extremity – COTSOverall, this case study emphasizes the need for thorough planning (including designplanning) and control when developing and maintaining components. Such systemshave many sources of additional costs (the authors comment on the estimate inSzyperski (1998) that developing a reusable component requires 3–4 times theresources needed for a ‘non-component’ implementation, but provide no estimates ofadditional effort required for this particular case study). In particular, not all of theseadditional costs are easily predicted, since they may arise partly through external factorssuch as platform changes that are not under the developer’s control.One aspect of component development that has not received the attention it isprobably due is the domain aspect. A survey by Frakes and Fox (1995) observed thatthere were ‘significant differences in the reuse of lifecycle objects between differentindustries’ (domains), although the reasons for this were not identified. In Roschelleet al. (1999) a number of component developers identified the lessons learned fromdeveloping educational software components in collaboration with educators, andspecifically identified the influence of the domain as an important factor in determiningcomponent granularity.There is of course a potential tension here. The commercial supplier of componentswants the largest possible marketplace for their products (unless these areproduced to the end-user’s specification and for their use alone). Also, the relativeimmaturity of CBSE means that few domains are likely to have developed widely used‘standard components’. However, it may well be that the future success of CBSE willdepend upon the successful adoption of a more domain-centred approach to componentdevelopment.17.4 At the extremity – COTSThose components generally considered as being in the form of COTS can be regardedas representing an extreme, in the sense that the end user or integrator has no controlwhatever over their form and properties and no knowledge about their workings. So aCOTS component is one that is quite expressly black box in its nature.(Actually, this view is itself probably something of an extreme position! As Carneyand Long (2000) point out, COTS software spans something of a range of forms, and