WREN—An Environment for Component-BasedDevelopmentChris Lüer David S. RosenblumInstitute for Software Research andDepartment of Information and Computer ScienceUniversity of California, IrvineIrvine, CA 92697-3425, USA+1-949-824-{2703,6534}{chl,dsr}@ics.uci.eduABSTRACTPrior research in software environments focused on three impor-tant problems—tool integration, artifact management, and processguidance. The context for that research, and hence the orientationof the resulting environments, was a traditional model of devel-opment in which an application is developed completely fromscratch by a single organization. A notable characteristic of com-ponent-based development is its emphasis on integrating inde-pendently developed components produced by multiple organiza-tions. Thus, while component-based development can benefitfrom the capabilities of previous generations of environments, itsspecial nature induces requirements for new capabilities not foundin previous environments.This paper is concerned with the design of component-based de-velopment environments, or CBDEs. We identify seven importantrequirements for CBDEs and discuss their rationale, and we de-scribe a prototype environment called WREN that we are buildingto implement these requirements and to further evaluate and studythe role of environment technology in component-based develop-ment. Important capabilities of the environment include the abilityto locate potential components of interest from component distri-bution sites, to evaluate the identified components for suitabilityto an application, to incorporate selected components into appli-cation design models, and to physically integrate selected compo-nents into the application.Categories and Subject DescriptorsD.2.6 [Software Engineering]: Programming Environments –Graphical environments, Integrated environments, Interactiveenvironments; D.2.2 [Software Engineering]: Design Tools andTechniques – Modules and interfaces, Software libraries; D.2.11[Software Engineering]: Software Architectures – Informationhiding, Languages; D.2.9 [Software Engineering]: Management– Life cycle, Software configuration management; D.2.7 [Soft-ware Engineering]: Distribution, Maintenance and Enhancement;D.2.13 [Software Engineering]: Reusable Software – Reusablelibraries, Reuse models; D.1.5 [Programming Techniques]:Object-oriented Programming.General TermsDesign, Languages.KeywordsComponent-based software engineering, Java, Java Beans, soft-ware components, software environments.1. INTRODUCTIONIt has been stated that component technology, while successful inindustry, has not received the attention it deserves from the re-search community [16]. Industrial component models are stillrudimentary, and the approaches of different vendors varystrongly. Research is necessary in order to define a common foun-dation of component technology, and to identify areas in whichcurrent standards and tools have to be extended.Software environments are one area that can benefit especiallywell from further research. Software development environments(SDEs) were originally designed to integrate collections of toolsand to manage locally created development artifacts. Later, proc-ess centered software engineering environments (PSEEs) weredeveloped to facilitate the use of well-defined processes to guidedevelopment. In order to provide tool integration and process-based guidance for the special needs of component-based devel-opment, we envision a new generation of environments, compo-nent-based development environments, or CBDEs. Reusable com-ponents developed by and licensed from other organizations can-not be treated in the same way as artifacts that were developed in-house, since it is usually not possible to change or analyze theirimplementations. Therefore, new approaches are needed to sup-port identification, retrieval and integration of such componentswithin an environment in an Internet-scalable way.Szyperski defines a component as follows [32]:• A unit of independent deployment. This means that a keygoal of component technology is to facilitate code reuse [14].A component is a piece of code that has been prepared forreuse. This is opposed to code scavenging, where code thatPermission to make digital or hard copies of part or all of this work or personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. ESEC/FSE 2001, Vienna, Austria © ACM 2001 1-58113-390-1/01/09…$5.00 207was not explicitly intended to be reusable is being reused.Though initially more expensive, we view design-for-reuseas being the superior approach to enabling reuse.• A unit of third-party composition. Reuse will pay off onlywhen reusing a component that was developed by anotherorganization is significantly easier than redeveloping it. Inthe ideal case, an application would be composable fromcomponents by domain experts without actual programming.• Without persistent state. A component is a piece of code, or aset of abstract data types. In an object-oriented system, acomponent is a set of classes. A component is not an objector a set of objects.A CBDE must provide its users with information about compo-nents. The users have not designed the components themselves, sothey depend on the environment to learn about them. With the useof components, the focus of tools shifts from implementation todesign, since the goal of component reuse is to minimize imple-mentation effort. Users must decide which components fit bestinto their architecture, so the environment should be able to visu-alize the dependencies among the components. Because compo-nents are developed by third parties, the environment should pro-vide the means to access components located at remote sources.In this paper, we present requirements for CBDEs, and we de-scribe a prototypical environment, WREN, which we are buildingbased on these requirements. Our prototype is based on the Javalanguage and the Java Beans component model. Componentspackaged as described in this paper are backwards compatiblewith Java Beans, although they have been extended in variousways. As described in the paper, WREN serves as an early exem-plar of this new generation of environments.2.