0018-9162/00/$10.00 © 2000 IEEE54 ComputerComponent-BasedSystems: A Classification of IssuesDeveloping and using various componentforms as building blocks can significantlyenhance software-based system developmentand use,1which is why both the academic andcommercial sectors have shown interest incomponent-based software development. Indeed,much effort has been devoted to defining and describ-ing the terms and concepts involved. Briefly, wedescribe software components as units of independentproduction, acquisition, and deployment that interactto form a functional system.2See the “What Is aComponent?” sidebar for a detailed definition anddescription of a component.In this article, we identify a set of issues organizedwithin an overall framework that software developersmust address for component-based systems (CBS) toachieve their full potential. Participants in the 1999International Workshop on Component-Based Soft-ware Engineering (http://www.sei.cmu.edu/cbs/icse99/cbsewkshp.html, Aug. 1999) developed a frameworksimilar to ours, which helps validate our model.In component-based development, although signif-icant difficulties can arise from the inexact notion of acomponent, maintaining at least a semi-vague notionof a component can be valuable. Doing so helps avoida so-called “technology lock-in,” which narrows thescope of our thinking. Components can take a widerange of forms and sizes; they should be independentof specific software architectural style; while objectsmay be components, all components are not objects.3Therefore, our framework leads to a more effectiveunderstanding of components because it helps clarifythose aspects of the component concept that are largelyindependent of architectural and implementationissues.Classifying and grouping the relevant ideas into aframework achieves the following:• Helps transfer the potential of component-based sys-tem development into reality. Although still imma-ture, the concept of component-based developmentis timely. The necessary constructional technologiesare available to support and exploit it, and it offerspotential gains in productivity and reliability.• Brings together disparate perspectives on com-ponents. Thinking about components incorpo-rates a wide range of views, from those that reflectprimarily business objectives4to those that arealmost entirely concerned with technical issues.We believe that these views should all be com-plementary parts of a larger whole, and we havetherefore sought to bring them together within asingle framework.• Begins to identify the key research questions.Much as was the case when they began adoptingobject-oriented technology, developers currentlybelieve that component-based development offersgreat potential, but have yet to translate thatpotential into practice. However, one lesson OOtaught us is that we must identify where bottle-necks will likely occur so that we can addressthem at an early stage.5DERIVATION OF THE FRAMEWORKOur framework resulted from extensive discussionand debate within a research group composed of aca-Although component-based development offers many potential benefits,such as greater reuse and a commodity-oriented perspective of software, it also raises several issues that developers need to consider.PearlBreretonDavidBudgenKeele UniversityRESEARCH FEATUREdemics, postgraduate students, and undergraduatesummer interns who perform software engineeringresearch. One motivation for producing a compo-nents framework was to provide a vehicle for apply-ing our research to component-based development. We created the framework in three phases, as Table1 shows. In phase one, we studied the issues and thepublished material. In phase two, we brainstormedextensively to identify relevant issues and found thatwe needed to address these issues from several view-points. We initially established a 3 × 3 framework ofissues versus viewpoints. The framework consideredprocess, product, and people issues from the view-November 2000 55points of component providers, component integra-tors, and component-based system users. Using our framework to elaborate our ideas inphase three revealed that the initial classification ofprocess, product, and people was insufficient. We thensubdivided people issues into business issues and peo-ple in software development. Further review revealedthat many issues spanned either two or all three view-points. This breadth of relevance proved particularlynoticeable for business issues, which may suggest thatmany of these nontechnical issues likely concern awhole range of future component-based-system stake-holders.There are at least as many definitions ofa component as there are readers of this arti-cle. Perhaps you have chosen to read thisbecause you are working with componentsor because you have an interest in them. Inpresenting our framework, we have tried tobe as universal as possible, so whatever yourdefinition of a component is, you will findsome relevance here. As a baseline, however,we agree with Alan Brown and Keith Short1that a component is “an independentlydeliverable set of reusable services.” Independence does not necessarilymean that a component has no depen-dencies on other components, althoughsuch a characteristic is often desirable,merely that those dependencies aregeneric enough for several differentproviders to satisfy. For example, a wordprocessor can depend on a spell-checkingcomponent, but several perhaps rivalproducts could meet this need. The wordprocessor can be supplied independently,provided its dependencies are adequatelyspecified. This situation gives component-based system integrators and end usersmore flexibility and choice.Alan Brown and Kurt Wallnau analyzemore restrictive definitions from bothindustry and academia.2The concept ofthe explicit interface dominates these def-initions. Although the inner workings of acomponent can be treated as a black box,its interface must be explicitly defined. Thisincludes a complete listing of the servicesprovided and how to access them, genericdependencies, and error conditions thatmight occur. Many definitions includeeither build-time or runtime dynamism. Asindividual units of change, componentscan be swapped, replaced, or upgradedduring the build of a complete application.More complex component architecturesallow component services to be looked upand hooked up while an application runs.The scale and size of components varyenormously—there are no real limits—but readers
View Full Document
Unlocking...