Challenges of component-based development

2000

Building software systems with reusable components brings many advantages. The development becomes more efficient, the reliability of the products is enhanced, and the maintenance requirement is significantly reduced. Designing, developing and maintaining components for reuse is, however, a very complex process which places high requirements not only for the component functionality and flexibility, but also for the development organization. In this paper we discuss the different levels of component reuse, and certain aspects of component development, such as component generality and efficiency, compatibility problems, the demands on development environment, maintenance, etc. The evolution of requirements for products generates new requirements for components, if components are not enough general and mature. This dynamism determines the component life cycle where the component first reaches its stability and later degenerates in an asset that is difficult to use, difficult to adapt and maintain. When reaching this stage, the component becomes an obstacle for efficient reuse and should be replaced. Questions related to use of standard and de-facto standard components are addressed specifically. As an illustration of reuse issues, we present a successful implementation of a component-based system which is widely used for industrial process control.

step, 1997

The continuing increase of interest in Componentbased Software Engineering (CBSE) signifies the emergence of a new development trend within the software industry. Unlike preceding software engineering models, CBSE heavily relies on the utilization of commercial off-the-shelf (COTS) products as the underlying foundation for new product development. Its emphasis is on the identification, selection, evaluation, procurement, integration, and evolution of reusable software components to provide complex integrated solutions at shorter development time and minimum cost. Compared to traditional development-centric software engineering approaches, CBSE promises a more efficient and effective approach to the delivery of software solutions to the market. However, underestimating the technical risks associated with the selection, evaluation, and integration of these software components has often resulted in longer schedule delay, and higher development/ maintenance cost, often experienced in integrated system development projects, This paper describes an experience at the Mitsubishi Consumer Electronics Engineering Center (CEEC) in implementing embedded InternetfTelevision systems using CBSE. It also describes the procurement-centric model that we have utilized to support project planning and to guide the development process. The COTS-based Integrated System Development (CISD) model identifies key engineering phases and their sub-phases that are often ignored, or merely implicit, in existing developmentcentric models. From the initial results of this project, the paper presents the various lessons learned at the CEEC in CBSE. * Diamondweb" is a registered trademark of Mitsubishi Corporation.

IEEE Computer, 2000

Developing and using various component forms as building blocks can significantly enhance software-based system development and use, which is why both the academic and commercial sectors have shown interest in component-based software development. Indeed, much effort has been devoted to defining and describing the terms and concepts involved. Briefly, we describe software components as units of independent production, acquisition, and

Proceedings 2000 Australian Software Engineering Conference, 2000

Industrial software projects are not based on a top-down development process relying on refinement but use a more iterative and incremental approach with respect to changing requirements. We call this an evolutionary approach. In this paper, we present the basic concepts of a suitable overall componentware methodology with respect to software evolution. We clarify the difference between refinement steps and evolution steps in an document-based development process. Based on this, we introduce the concept of requirements/assurances contracts to explicitly model the dependencies between the development documents. This helps developers to track and manage the software evolution process. A short example shows the usefulness of the presented concepts and introduces a description technique for requirements/assurances contracts in componentware. ¢ This paper originates from the research in the project A1 "Methods for Component-Based Software Engineering" at the chair of Prof. Dr. Manfred Broy,

2012

One of the goals of Software design is to model a system in such a way that it is reused. Actively reusing designs or code allows taking advantage of the investment made on reusable components. However development of domain specific components and its impact on effort in terms of cost and time is still a challenging issue. The component based technology has transformed over a period of time from a simple component to the domain specific components. This paper presents a state of art of the drastic change in component technology from component engineering to domain engineering.

Science of Computer Programming, 2012

Software modernization is critical for organizations that need cost-effective solutions to deal with the rapid obsolescence of software and the increasing demand for new functionality. This paper presents the XIRUP modernization methodology, which proposes a highly iterative process, structured into four phases: preliminary evaluation, understanding, building and migration. This modernization process is feature-driven, component-based, focused on the early elicitation of key information, and relies on a model-driven approach with extensive use of experience from the previous projects. XIRUP has been defined in the European IST project MOMOCS, which has also built a suite of support tools. This paper introduces the process using a case study that illustrates its activities, related tools and results. The discussion highlights the specific characteristics of modernization projects and how a customized methodology can take advantage of them.

2007

Component-based software engineering has recently emerged as a promising solution to the development of system-level software. Unfortunately, current approaches are limited to specific platforms and domains. This lack of generality is particularly problematic as it prevents knowledge sharing and generally increases development costs.

2005

This paper deals with the issue of software adaptation. We focus on Component-Based Software Development including Architecture Description Languages, and clearly identify three levels of adaptation. We argue that capturing functional and non-functional changes in a system requires various types of adaptation tools working at different granularities and times in the system lifecycle, with various actors.

Khan,H.,&Hassina. S.,&Ilyas.Ahsen.(2020)-Component Based Software Development.Academia.edu, 2020

Software industries are affected most by quality of product, development cost and time-to-market. Many new models are introduced to deliver a quality product within given time. CBSD is one of them which has gain so much popularity because of its characteristics like least coding is involved, components written in different languages can be integrated with interfaces to acquire required product, testing and maintenance also becomes so easy. CBSD suggested assembling software frameworks utilizing existing reusable segments, rather than composing without any preparation. The primary target of component-based software development is to composes as soon as and recycle any quantity of period with not any or slight change. In this paper we have discussed CBSD, how it is useful, how components are integrated its life cycle, extended models and also the risks and challenges. Keywords-Component-based software development (CBSD), Component-based software Engineering (CBSE), COTS (commercial off-the-shelf), quality-of-service (QOS).

2007

A software product line to support urban transport systems is briefly described and the design of two of its features is discussed. Different solutions based on components are shown for these two features and their variabilities. In particular, an analysis is made of how their design is influenced by the development process adopted, by the decision to use black-box (off-the-shelf) components or white-box components that may be created or adapted depending on application requirements, and by the decision of automating or not the composition process. Additionally, alternatives for deciding how to define iterative cycles and increments of the product line are discussed.