Software Design 2e - DIM

well incorporate redundant functionality and may have particular expectations aboutcontext.One of the key factors to consider for COTS is the ‘shelf-life’. The effect ofcommercial and business pressures makes it likely that the supplier of any COTScomponent will cause it to be upgraded reasonably frequently. (Obvious exampleson a large scale include components such as operating systems and web browsers.)Since the development of such components is strongly market-driven, the individualend-user probably has little or no influence upon any changes that may occur betweenversions. If the customer’s business is operating in a rapidly-changing and ‘emergent’context then this may not form a particular disadvantage, and it may be more than offsetby the benefits of rapid development. In contrast, there needs to be more doubtabout employing COTS where an application may need to be used over a longer period.So far, there would appear to be relatively little published research into the use ofCOTS. This is perhaps not surprising, given its relative volatility, but it does mean thatthere are few guidelines available to the designer.417Further readingSummaryComponent-based software development is still at a relatively immature stage, and hence therehas so far been limited opportunity to consolidate experiences and develop recommended practices.For the designer, the problem of accumulating and codifying the experiences of CBSEdesign is further compounded by the multiplicity of architectural styles that can be employed.That this is a characteristic of CBSE rather than a passing state does not help!Many of the issues in this chapter have resonances with the issues that we discussed in Chapter12. This should not be surprising since one of the motivations for using CBSE practices is tospeed up system development. Indeed, the concept of the agile method may be one of the moreuseful ones for the longer-term goal of providing guidance on CBSE practices.Further readingGarlan D., Allen R. and Ockerbloom J. (1995). Architectural mismatch: why reuse is so hard.IEEE Software, 12(6), 17–26An interesting paper that was really written primarily as a discussion of the effects of architecturalstyle, but which en route identifies the importance of this for CBSE. It provides someexamples of particular problems encountered in a case study.Heineman G.T. and Councill W.T. (2001). Component-Based Software Engineering: Puttingthe Pieces Together. Addison-Wesley.This book is really a collection of papers on components, many of which have been writtento fit around the definitions provided by the principal authors and editors. Well-organized, itprovides a useful baseline for learning about CBSE, even if the quality of the individual papersis rather mixed. The main shortcoming is that it is somewhat light on case studies.