component-based software engineering — new challenges in software development

Software DevelopmentChallengesWe are witnessing an enormous expansionin the use of software in business,industry, administration and research.Software is no longer marginal intechnical systems but has now become acentral factor in many fields. Systemfeatures based on software functionality,rather than other characteristics, arebecoming the most important factor incompeting on the market, for example inthe car industry, the service sector and inschools. Increasing numbers of softwareusers are non-experts. These trends placenew demands on software. Usability,robustness, simple installation andintegration become the most importantfeatures of software. As a consequence ofthe wider area of software utilisation, thedemand for the integration of differentareas has increased. We distinguishbetween vertical integration in which dataand processes at different levels areintegrated, and horizontal integration inwhich similar types of data and processesfrom different domains are integrated.For example, in industrial processautomation, at the lowest levels ofmanagement (Field Management), datacollected from the process and controlleddirectly, is integrated on the plant level(Process Management), then is furtherprocessed for analysis and combinationwith data provided from the market andfinally published on the Web (BusinessManagement).

A consequence of all this is that software isbecoming increasingly large and complex.Traditionally, software developmentaddressed challenges of increasingcomplexity and dependence on externalsoftware by focussing on one system at atime and on delivery deadlines andbudgets, while ignoring the evolutionaryneeds of the system. This has led to anumber of problems: the failure of themajority of projects to meet their deadline,budget, and quality requirements and thecontinued increase in the costs associatedwith software maintenance. To meet thesechallenges, software development must beable to cope with complexity and to adapt

quickly to changes. If new softwareproducts are each time to be developedfrom scratch, these goals cannot beachieved. The key to the solution to thisproblem is reusability. From thisperspective Component-based Development(CBD) appears to be the right approach.In CBD software systems are built byassembling components already developedand prepared for integration. CBD hasmany advantages. These include moreeffective management of complexity,reduced time to market, increasedproductivity, improved quality, a greaterdegree of consistency, and a wider rangeof usability [1].

Component-basedSoftware Engineering —

New Challenges inSoftware Development

Ivica CrnkovicMälardalen UniversityDepartment of Computer EngineeringVästerås, [email protected] http://www.idt.mdh.se/~icc

The primary role of component-basedsoftware engineering is to address the

development of systems as anassembly of parts (components),

the development of parts as reusableentities, and the maintenance and

upgrading of systems by customisingand replacing such parts. This

requires established methodologiesand tool support covering the entire

component and system lifecycleincluding technological,

organisational, marketing, legal, and other aspects. The traditional

disciplines from software engineeringneed new methodologies to support

component-based development.IVICA CRNKOVIC assesses the

challenges of this emergingtechnology and discusses itsimplications for the software

development process.

127Volume 2, Issue 4Copyright © 2002 John Wiley & Sons, Ltd.focussoftware

Non-experts...place new demandson software.

Winter 2001focusreview

software2-4 260302 8:49 AM 27

However, there are several disadvantagesand risks in using CBD which canjeopardise its success.

• Time and effort required for developmentof components. Among the factors whichcan discourage the development ofreusable components is the increasedtime and effort required, the building ofa reusable unit requires three to fivetimes the effort required to develop aunit for one specific purpose. (B.Spencer, Microsoft, Presentation at 22nd

ICSE, 1999, also an interestingobservation about efficient reuse of real-time components, made by engineers atSiemens [2] that, as a rule of thumb, theoverhead cost of developing a reusablecomponent, including design plusdocumentation, is recovered after thefifth reuse. Similar experience at ABB[3] shows that reusable components areexposed to changes more often thannon-reusable parts of software at thebeginning of their lives, until they reacha stable state.)

• Unclear and ambiguous requirements. Ingeneral, requirements management is animportant part of the developmentprocess, its main objective being todefine consistent and completecomponent requirements. Reusablecomponents are, by definition, to beused in different applications, some ofwhich may yet be unknown and therequirements of which cannot bepredicted. This applies to both functionaland non-functional requirements.

• Conflict between usability and reusability.To be widely reusable, a componentmust be sufficiently general, scalable andadaptable and therefore more complex(and thus more complicated to use), andmore demanding of computing resources(and thus more expensive to use). Arequirement for reusability may lead toanother development approach, forexample building a new, more abstract,level which gives less flexibility and finetuning, but achieves better simplicity[3,4].

• Component maintenance costs. Whileapplication maintenance costs candecrease, component maintenance costscan be very high since the componentmust respond to the differentrequirements of different applicationsrunning in different environments, withdifferent reliability requirements andperhaps requiring a different level ofmaintenance support.

• Reliability and sensitivity to changes. Ascomponents and applications haveseparate lifecycles and different kinds ofrequirements, there is some risk that acomponent will not completely satisfythe application requirements or that itmay include concealed characteristicsnot known to application developers.When introducing changes on theapplication level (changes such asupdating of operating system, updatingof other components, changes in theapplication, etc.), there is a risk that thechange introduced will cause systemfailure. To enjoy the advantages andavoid the problems and risks, we need asystematic approach to component-based development at the process andtechnology levels.

Component-Based SoftwareEngineeringThe concept of building software fromcomponents is not new. A ‘classical’ designof complex software systems always beginswith the identification of system partsdesignated subsystems or blocks, and on alower level modules, classes, proceduresand so on. The reuse approach to softwaredevelopment has been used for manyyears. However, the recent emergence ofnew technologies has significantlyincreased the possibilities of buildingsystems and applications from reusablecomponents. Both customers andsuppliers have had great expectationsfrom CBD, but their expectations havenot always been satisfied. Experience hasshown that component-baseddevelopment requires a systematicapproach to and focus on the component

aspects of software development [3].Traditional software engineeringdisciplines must be adjusted to the newapproach, and new procedures must bedeveloped. Component-based SoftwareEngineering (CBSE) has becomerecognised as such a new sub-discipline ofSoftware Engineering.

The major goals of CBSE are theprovision of support for the developmentof systems as assemblies of components,the development of components asreusable entities, and the maintenanceand upgrading of systems by customisingand replacing their components [5]. Thebuilding of systems from components andthe building of components for differentsystems requires establishedmethodologies and processes not only inrelation to the development/maintenanceaspects, but also to the entire componentand system lifecycle includingorganisational, marketing, legal, andother aspects. In addition to specific CBSEobjectives such as component specificationor composition and technologies, thereare a number of software engineeringdisciplines and processes that requirespecific methodologies for application incomponent-based development. Many ofthese methodologies are not yetestablished in practice, some are not evendeveloped. The progress of softwaredevelopment in the near future willdepend very much on the successful

Winter 2001 focus review

128 Volume 2, Issue 4 Copyright © 2002 John Wiley & Sons, Ltd. focussoftware

Figure 1 The development cycle compared with the waterfall model

Software engineering disciplinesmust be adjusted to the new

approach, and new procedures must be developed.

software2-4 260302 8:49 AM Page 128

establishment of CBSE and this isrecognized by both industry andacademia. All major software engineeringconferences now include sessions relatedto CBSE, and CBSE workshops are heldfrequently [6–10]. According to theGartner Group [11] ‘By 2002, 70% of allnew applications will be deployed usingcomponent-based application buildingblocks.’

Overviews of certain CBSE disciplines andsome of the relevant trends andchallenges in the near future arepresented below.

Component SpecificationFor a common understanding ofcomponent-based development, thestarting point is an agreement of what acomponent is and what it is not. As ageneric term the concept is pretty clear —a component is a part of something — butthis is too vague to be useful. Thedefinition of a component has been widelydiscussed [13,14]. However, we shall adoptSzyperski’s definition [4], which is themost frequently used today:

A software component is a unit ofcomposition with contractually specifiedinterface and explicit contextdependencies only. A software componentcan be deployed independently and issubject to composition by third parts.

The most important feature of acomponent is the separation of itsinterface from its implementation. Thisseparation is different from those that wecan find in many programming languages(such as ADA or Modula-2), in which

declaration is separated fromimplementation, or those in object-oriented programming languages in whichclass definitions are separated from classimplementations. We require that theintegration of a component into anapplication should be independent of thecomponent development lifecycle and thatthere should be no need to recompile orre-link the application when updating witha new component. Another importantcharacteristic of the separation is that thecomponent implementation is only visiblethrough its interface. This is especiallysignificant for components delivered by athird party. An implication of this is therequirement for a complete specificationof a component including its functionalinterface, non-functional characteristics(performance, resources required, etc.),use cases, tests, etc. While currentcomponent-based technologies successfullymanage functional interfaces, there is nosatisfactory support for managing otherparts of a component specification.

The component definition adopted aboveis focused on the use of components. It sayslittle about how to design, implement andspecify a component. There are however,other definitions that point to other aspectsof component-based development. Forexample there is a strong relation betweenobject-oriented programming (OOP) andcomponents. Component models (alsocalled component standards) COM/DCOM[15,16], .NET [17], Enterprise Java Beans(EJB) [15,17], and CORBA ComponentModel (CCM) [20] relate ComponentInterface to Class Interface. Componentsadopt object principles of unification offunctions and data encapsulation.Cheesman and Daniels [21] consider that acomponent can exist in several forms

during its lifecycle: Component Specification(component characteristics, componentfunction), Component Interface (a part of itsspecification, a definition of a component’sbehaviour), Component Implementation (arealisation of a Component Specification),Installed Component (deployed instance of aComponent Implementation) andComponent Object (an instance of InstalledObject). Not all researchers agree thatcomponents are extensions of OOP. Onthe contrary, they consider that thedifference between components and objectslies in the fact that an object has state andis a unit of instantiation, while acomponent is stateless and is a unit ofdeployment [4].

There are also different understandings ofCBD in academia and industry [22]. Whileresearchers in academia definecomponents as well-defined entities (oftensmall, and with easily understoodfunctional and non-functional features),industry sees components as parts of asystem which can be reused, but are notnecessarily well defined with explicitinterfaces and with slight or noconformance with component models. Acomponent can be an amorphous part ofa system, the adaptation of which mayrequire much effort. Such components (orrather reusable entities) are of extremeimportance, as the larger the componentsare, the greater the productivity that canbe achieved by their reuse.

Component specification remains a topicof research. Component standards aremostly concentrated on the interfacedefinition, while non-functional propertiesare specified (if specified at all) informallyin separate documentation. Someimprovements in that direction, bygathering both functional characteristicsand design characteristics, have beenmade in the new Microsoft ComponentModel .NET.

Component-Based SystemDevelopment Lifecycle CBSE addresses the requirements,challenges and problems similar to othersencountered elsewhere in softwareengineering. Many of the methods, toolsand principles of software engineering canbe used in the same or in a similar way asin other types of applications or systemsbut there is one distinction, CBSE coversboth component development and systemdevelopment with components. There is aslight difference in the requirements and



Figure 2 UML component


business ideas in the two cases anddifferent approaches are necessary. Ofcourse, when developing components,other components can be (and often mustbe) incorporated but the main emphasis ison reusability: Components are built to beused and reused in many applications,some not yet existing. A component mustbe well specified, easy to understand,sufficiently general, easy to adapt, easy todeliver and deploy and easy to replace.The component interface must be assimple as possible and strictly separated(both physically and logically) from itsimplementation. Marketing factors play animportant role as development costs mustbe recovered from future earnings, thisbeing especially true for COTS. However,the main problem in developingcomponents is in the acquisition andelicitation of requirements in combinationwith COTS selection [23] because theprocess includes multi-criteria decisions. Ifthe process begins with requirementsselection, it is highly probable that a COTSmeeting all the requirements will not befound. If components are selected too earlyin the process, the system obtained maynot meet all the requirements.

Development with components is focusedon the identification of reusable entitiesand relations between them, starting fromthe system requirements. The early designprocess includes two essential steps: Firstly,specification of a system architecture interms of functional components and theirinteraction, this giving a logical view of thesystems and secondly, specification of asystem architecture consisting of physicalcomponents.

Different lifecycle models, established insoftware engineering, can be used in CBD.These models will be modified toemphasise component-centric activities.Let us consider, for example, the waterfallmodel using an extreme component-basedapproach. Figure 1 shows the waterfallmodel and the meaning of the phases.Identifying requirements and a design inthe waterfall process is combined withfinding and selecting components. The design includes the systemarchitecture design and componentidentification/selection.

The different steps in the component-based systems development process are:

• Find components that may be used inthe system. All possible components arelisted here for further investigation. Tosuccessfully perform this procedure, a

vast number of possible candidates mustbe available as well as tools for findingthem. This is an issue not only oftechnology, but also of business.

• Select the components that meet therequirements of the system. Often therequirements cannot be fulfilledcompletely, and a trade-off analysis isneeded to adjust the system architectureand to reformulate the requirements tomake it possible to use the existingcomponents.

• Alternatively, create a proprietarycomponent to be used in the system. Ina component-based development processthis procedure is less attractive as itrequires more efforts and lead-time.However, the components that includecore-functionality of the product arelikely to be developed internally as theyshould provide the competitiveadvantage of the product.

• Adapt the selected components so thatthey suit the existing component modelor requirement specification. Somecomponents would be possible to bedirectly integrated in to the system,some would be modified through aparameterisation process, some wouldneed wrapping code for adaptation, etc.

• Compose and deploy the componentsusing a framework for components.Typically component models wouldprovide that functionality.

• Replace earlier with later versions ofcomponents. This corresponds withsystem maintenance. Bugs may havebeen eliminated or new functionalityadded.

There are many other aspects of CBD thatrequire specific methods, technologiesand management. For example,development environment tools [24,25],component models and support for theiruse, software configuration management[26], testing, software metrics, legal issues,project management, developmentprocess, standardisation and certificationissues, etc. Discussion of these is beyondthe scope of this article and the relationbetween software architecture and CBD isdiscussed in the following.

Software Architecture andComponent-BasedDevelopmentSoftware architecture and components areclosely related. All software systems havean architecture that can be viewed in

terms of the decomposition of the systeminto components and their relations. Acommonly used definition of Softwarearchitecture is 0: ‘The software architecture ofa program or computing system is the structureor structures of the system, which comprisesoftware components, the externally visibleproperties of those components and therelationships among them.’ Traditionally,software architecture is at the focus in theearly design phase when the overallstructure of the system is designed tosatisfy functional and non-functionalrequirements. In monolith applications,the architecture specified in the designprocess is concealed at execution time inone block of executable code. Componenttechnologies focus on composition anddeployment, closer to or at executiontime. In a component-based system, thearchitecture remains recognisable duringthe application or system execution, thesystem still consisting of clearly separatedcomponents. The system architecture thusremains an important factor during theexecution phase. Component-basedSoftware Engineering embraces the totallifecycles of components and component-based systems and all the proceduresinvolved in such lifecycles.

In a ‘classical’ approach, the design ofsoftware begins with determining itsarchitecture, structuring the system insmaller parts, as independent as possible.The first phase of this structuring isfunctionality-based architectural design.The second phase is software architectureassessment during which the softwarearchitecture is evaluated with respect tothe driving quality requirements. Once thesoftware architecture has been defined, thecomponents that are to constitute thesystem must be developed or selected. Wecan distinguish different categories ofcomponents in relation to therequirements of the system: specialpurpose components, developedspecifically for the system, reusedcomponents, internally developed formultiple usage, and final commercialcomponents (COTS). Pre-existingcomponents typically need to beintegrated into the system using glue codeor a modification of the componentsthemselves. This top-down approachensures the fulfilment of the requirements,or at least a better control of requirementsfulfilment. However, this approach doesnot encourage the reuse of pre-existingcomponents, especially not commercialcomponents, since there is a high degree




of probability that the pre-existingcomponents do not exactly fit into thesystem. Another approach, a mix ofbottom-up and top-down approachesbegins with the system requirements andthe analysis of possible candidatecomponents. The component specificationand selection have an impact on the finalrequirements and the system architecture.In this case, software architecting isprimarily concerned with identifyingmeans of optimising the interactionsbetween the given components. Since basicartefacts for both software architecture andcomponent technologies are componentsand their composition is natural that theywill merge, i.e. use common techniques,methods and tools. Architectural definitionlanguages (ADLs), for example ACME [29],can be used for designing component-based-systems and implemented for theexisting component models.

Software architecture is often related to aprocess of tradeoff analysis. Experiencehas shown that the many attributes of

large software systems live principally inthe system’s software architecture. In suchsystems the achievement of qualitiesattributes depends more on the overallsoftware architecture than on code-levelpractices such as language choice, detaileddesign, algorithms, data structures,testing, and so on. There exist severalmethods for such analysis, for exampleSAAM (Software Architecture AnalysisMethod) [30] and ATAM (ArchitectureTradeoff Analysis Method) [31]. BothATAM and SAAM are a scenario-basedmethod. However, unlike the SAAM, theATAM focuses on multiple qualityattributes (modifiability, availability,security, and performance) and is aimedat locating and analysing trade-offs in asoftware architecture. For component-based systems a modified approach inthese analyses is required. The componentshave pre-determined attributes, some ofthem immanent only to the component,but some of them emerging incomposition with other components. Atrade-off analysis helps in selecting the

proper components and in predicting theattributes of component compositions. Atthe same time inclusion of the pre-existing components sets the boundariesin which the analysis can be performed.For example one characteristic of acandidate component can be a highreusability but a poor performance, whileof the other candidate a betterperformance but a lower reusability. Thearchitectural analysis will help in making adecision in component selection.

Software architecture and CBD aresuccessfully used in the development ofsoftware product lines [22,27] from whichmany variants of a product are delivered.Typical product variants contain a set ofcore-components and a number ofadditional components. The component-based approach and architectural designplay an important role in productconfiguration management.

UML and Component-BasedSystems ModellingUML (Unified Modelling Language) canbe used for both component and systemmodelling, as shown in [21]. Component-driven design concentrates on interfacedefinitions and collaboration between thecomponents through the interfaces. Thedesign process continues with themodelling of the system with physicalcomponents, which do not necessarilymatch the logical structure. These may bepre-existing components, with interfacealready specified and possibly in need ofwrappers. One logical component,identified in the first phase of design, mayconsist of several physical components.Finally, there is a deployment aspect, thecomponents being executed on differentcomputers in a distributed application. Ina non-component-base approach the first,the design phase is important, whilemapping between the conceptual andimplementation level is a direct mapping,and the deployment phase is the same forthe whole application. In principle, UML[32] can be utilised to provide support fordesigning component-based systemscovering all these aspects [1,5]. Interfacesare presented as multiple subsystems (alsomultiple interfaces may be realised by asubsystem), which indicate the possibilityof changing the implementation withoutreplacing the interface. An interface canbe presented in two ways (see Figure 2),the second alternative being the morecommon presentation.



Figure 3 Examples of different aspects of component-based architecture


Figure 3 shows the three aspects of systemarchitecture. The conceptual architectureis a result of a top-down system analysisand design and in at least the first step isnot different from a ‘non-component-based’ design. In the conceptual part thecomponents are expressed by UMLpackages with the <<subsystems>>stereotype. In the implementationarchitecture part, the physical componentsare represented by UML components andthe <<imp>> stereotype. Note that theimplementation part is not necessarily theonly refinement of the conceptual level,but also the structure can be changed. Forexample, different packages can includethe same physical components. It may alsohappen that the component selectionrequires modifications of the conceptualarchitecture.

UML is however not specialised for CBDand certain extensions to standard UML(such as naming convention, orstereotypes) are required. The componentinterfaces cannot be described by UML atsuch a detailed level that they can be useddirectly. For this reason there existextensions to UML, for example Catalysis[33]. Further work on UML related toCBSE is expected. The next major versionof UML (UML 2.0) [34] includesproposals for extensions for describingEnterprise Java Beans, data modellingentities, real-time components, XMLcomponents, etc. Many of these arerelated directly or indirectly to CBSE.

Future of Component-Based Software EngineeringIt is obvious that CBD and CBSE are in thevery first phase of their lives. CBD isrecognised as a new, powerful approachthat will, if not revolutionise, at leastsignificantly change the development ofsoftware and software use in general. Wecan expect that components andcomponent-based services will be widelyused by non-programmers for buildingtheir applications. Tools for building suchapplications by component assembly will bedeveloped. Automatic component updateover the Internet, already present today inmany applications, will be a standardmeans of application improvement.Another trend we can see is thestandardisation of domain-specificcomponents on the interface level. This willmake it possible to build applications andsystems from components purchased from

different vendors. The standardisation ofdomain-specific components requires thestandardisation of domain-specificprocesses. Widespread work onstandardisation in different domains isalready in progress, (a typical example isOPC Foundation [35], working on astandard interface to make possibleinteroperability between automation/control applications, field systems/devicesand business/office applications). Supportfor the exchange of information betweencomponents, applications, and systemsdistributed over the Internet will be furtherdeveloped. Works related to XML [36] willbe further expanded.

CBSE is facing many challenges today,some of these are summarised in thefollowing.

• Trusted components — Because thetrend is to deliver components in binaryform and the component developmentprocess is outside the control ofcomponent users, questions related tocomponent trustworthiness become ofgreat importance. The meaning of‘trustworthiness’ is, however, notprecisely defined. Although there areformal definitions of many attributesassociated with the concept‘trustworthiness’ (reliability androbustness, for example), there is noformal definition and understanding of‘trustworthy’, no standardisedmeasurement or trustworthiness. Whatare the effects of different degrees oftrustworthiness on system attributes isnot known.

• Component certification — One way ofclassifying components is to certificatethem. In spite of the common belief thatcertification means absolutetrustworthiness, it in fact only gives theresults of tests performed and adescription of the environment in whichthe tests were performed. Whilecertification is a standard procedure inmany domains, it is not yet establishedin software in general and especially notfor software components [37,38].

• Composition predictability — Even if weassume that we can specify all the

relevant attributes of components, it isnot known how these attributesdetermine the corresponding attributesof systems of which they are composed.The ideal approach to derive systemattributes from component attributes isstill a subject of research. A questionremains — ‘Is such derivation at allpossible? Or should we not concentrateon the measurement of the attributes ofcomponent composites?’ [39].

• Requirements management andcomponent selection — Requirementsmanagement is a complex process. Aproblem of requirements management isthat requirements in general areincomplete, imprecise and contradictory.In an in-house development, the mainobjective is to implement a system thatwill satisfy the requirements as far aspossible within a specified framework ofdifferent constraints. In component-baseddevelopment, the fundamental approachis the reuse of existing components. Theprocess of engineering requirements ismuch more complex as the possiblecandidate components usually lack oneor more features which meet the systemrequirements exactly. In addition, even ifsome components are individually wellsuited to the system, it is not necessarythat they do not function optimally incombination with others in the system —or perhaps not at all. These constraintsmay require another approach inrequirements engineering — an analysisof the feasibility of requirements inrelation to the components available andthe consequent modification ofrequirements. As there are manyuncertainties in the process ofcomponent selection there is a need for astrategy for managing risks in thecomponents selection and evolutionprocess [5,40].

• Long-term management of component-based systems — As component-basedsystems include sub-systems andcomponents with independent lifecycles,the problem of system evolutionbecomes significantly more complex.There are many questions of differenttypes: technical issues (can a system beupdated technically by replacingcomponents?), administrative andorganisational issues (which componentscan be updated, which componentsshould be or must be updated?), legalissues (who is responsible for a systemfailure, the producer of the system or ofthe component?), etc. CBSE is a new



Components and component-based services will be widely usedby non-programmers for building

their applications.


approach and there is little experience as yet of the maintainability of suchsystems. There is a risk that many such systems will be troublesome tomaintain.

• Development models — Althoughexisting development modelsdemonstrate powerful technologies, theyhave many ambiguous characteristics,they are incomplete, and they aredifficult to use.

• Component configurations — Complexsystems may include many componentswhich, in turn, include othercomponents. In many casescompositions of components will betreated as components. As soon as webegin to work with complex structures,the problems involved with structureconfiguration popup. For example, twocompositions may include the samecomponent. Will these components betreated as two different entities or will

they be assumed to be one identicalentity? What happens if thesecomponents are of different versions,which version will be selected? Whathappens if these versions are notcompatible? The problems of thedynamic updating of components arealready known, but their solutions arestill the subject of research [41].

• Dependable systems and CBSE — Theuse of CBD in safety-critical domains,real-time systems, and different process-control systems, in which the reliabilityrequirements are more rigorous, isparticularly challenging. A major problemwith CBD is the limited possibility ofensuring the quality and other non-functional attributes of the componentsand thus our inability to guaranteespecific system attributes.

• Tool support — The purpose of SoftwareEngineering is to provide practicalsolutions to practical problems, and the

existence of appropriate tools isessential for a successful CBSEperformance. Development tools, suchas Visual Basic, have proved to beextremely successful, but many othertools are yet to appear — componentselection and evaluation tools,component repositories and tools formanaging the repositories, componenttest tools, component-based designtools, run-time system analysis tools,component configuration tools, etc. Theobjective of CBSE is to build systemsfrom components simply and efficiently,and this can only be achieved withextensive tool support.

These are some of the many challengesfacing CBSE today. The goal of CBSE isto standardise and formalise all disciplinessupporting activities related to CBD. Thesuccess of the CBD approach dependsdirectly on further research and theimplementation of CBSE.



References

[1] Brown A. Large-Scale Component-BasedDevelopment. Prentice Hall, 2000.[2] Mrva M. Reuse Factors in Embedded SystemsDesign. High-Level Design Techniques Dept. atSiemens AG, Munich, Germany, 1997.[3] Crnkovic I, Larsson M. A Case Study: Demandson Component-based Development. Proceedings22nd International Conference on SoftwareEngineering, ACM Press, 2000.[4] Szyperski C. Component Software –BeyondObject-Oriented Programming. Addison-Wesley,1998.[5] Heineman G, Councill W. Component-basedSoftware Engineering, Putting the Pieces Together.Addison Wesley, 2001.[6] ICSE 2000, Workshop on Component-BasedSoftware Engineering (CBSE 3), http://www.sei.cmu.edu/cbs/cbse2000/CFP2000.html, Access date2001-07-14.[7] ICSE 2001, Workshop on Component-BasedSoftware Engineering (CBSE 4),http://www.sei.cmu.edu/pacc/CBSE4-Proceedings.html, Access date2001-07-14.[8] ECOOP 2000, Workshop on Component-Oriented Programming, http://www.ipd.hk-r.se/bosch/WCOP2000/, Accessdate 2001-07-14.[9] Euromicro 2001, Workshop on Component-Based Software Engineering, http://www.idt.mdh.se/ecbse/, Access date 2001-07-14.[10] Workshop on CBSE – ABB Corporate ResearchCentre, Switzerland, 2000, http://icawww2.epfl.ch/~opreiss/CBSE_Conference2000/, Access date2001-07-14.[11] Gartner Group, http://www.gartner.com,Access date 2001-07-14.[12] Brown A, Wallnau K. The current state ofCBSE, IEEE Software, 1998.[13] Szyiperski C, Pfister C. Workshop onComponent-Oriented Programming, Summary. InMühlhäuser M. (ed.) Special Issues in Object-

Oriented Programming — ECOOP96 WorkshopReader, Springer, 1997.[14] ICSE 1999, Workshop on Component-BasedSoftware Engineering (CBSE 2),http://www.sei.cmu.edu/cbs/icse99/cbsewkshp.html,Access date 2001-07-14.[15] Box D. Essential COM. Addison-Wesley, 1998.[16] Microsoft Component Object Model,http://www.microsoft.com/com/, Access date 2001-07-14.[17] Microsoft .NET Component Model,http://www.microsoft.com/net, Access date 2001-07-14.[18] Enterprise Javabeans technology,http://java.sun.com/products/ejb/, Access date2001-07-14.[19] Matena V, Stearns B. Applying EnterpriseJavaBeans(TM): Component-Based Developmentfor the J2EE(TM) Platform. Addison-Wesley, 2000.[20] OMG, CORBA,http://www.omg.org/technology/documents/spec_catalog.htm, Access date 2001-07-14.[21] Cheesman J, Daniels J. UML Components —a Simple Process for Specifying Component-BasedSoftware. Addison-Wesley, 2001.[22] Bosch J. Design & Use of SoftwareArchitecture. Addison Wesley, 2000.[23] Maiden N, Ncube C. Acquiring Requirementsfor Commercial Off-The Shelf Package Selection,IEEE Software 1998; 15(2).[24] Microsoft Visual Studio,http://msdn.microsoft.com/vstudio/, Access date2001-07-14.[25] Development tools — Forte ™ tools,http://www.sun.com/forte/, Access date 2001-07-14.[26] Larsson M, Crnkovic I. New challenges forconfiguration Management, Proceedings of 9th

Symposium on System Configuration Management,Lecture Notes in Computer Science, Springer,1999.[27] Bosch J. Software Product Lines:Organisational alternatives, ICSE 2000 Proceedings,ACM Press, 2001, 91-100.

[28] Bass L, Clements P, Kazman R, SoftwareArchitecture In Practice. Addison Wesley, 1998.[29] ACME architecture definition language,http://www.cs.cmu.edu/~acme/, Access dated2001-07-14.[30] Kazman R, Abowd G, Bass L, Clements P.Scenario-based analysis of software architecture.IEEE Software 1996: 47–55.[31] Kazman R, Barbacci M, Klein M, Carrière SJ.Experience with Performing Architecture TradeoffAnalysis, ICSE 1999 Proceedings, ACM Press,1999, 54–63.[32] Booch G, Jacobson I, Rumbaugh J. TheUnified Modeling Language User Guide. Addison-Wesley, 1998.[33] D’Souza D, Wills A. Objects, Components, andFrameworks With UML: The Catalysis Approach.Addison-Wesley, 1998.[34] OMG UML,http://www.omg.org/technology/uml, Access date2001-07-14.[35] OPC Foundation,http://www.opcfoundation.org/ , Access date 2001-07-14.[36] Extensible Markup Language (XML)http://www.w3.org/XML, Access date 2001-07-14.[37] Voas J, Payne J. Dependability certification ofsoftware components. Journal of Systems andSoftware 2000; 52: 165–172.[38] Morris J, Lee G, Parker K, Bundell G, PengLam C. Software component certification. IEEEComputer 2001.[39] Wallnau K, Stafford J. Ensembles: Abstractionsfor a New Class of Design Problem, 27th EuromicroConference 2001 Proceedings, IEEE ComputerSociety, 2001: 48–55[40] Kotonya G, Rashid A. A strategy for ManagingRisks in Component-based Software Development,27th Euromicro Conference 2001 Proceedings,IEEE Computer Society, 2001: 12–21.[41] Crnkovic I, Larsson M, Küster Filipe JK, Lau K.Databases and Information Systems, FourthInternational Baltic Workshop, Baltic DB&IS,Selected papers. Kluwer Academic Publishers,2001: 237–252.


component-based software engineering — new challenges in software development

Documents