1 / 11

COMPONENT BASED SYSTEMS: A CLASSIFICATION OF ISSUES

This paper discusses the benefits and challenges of component-based development, defining software components and presenting a framework of issues to address for maximizing the potential of component-based systems (CBS). It covers a wide range of topics, including component granularity, interoperability, maintenance, business considerations, and perspectives on software development processes. The framework derived in this article serves as a guide for software developers to navigate the complexities of building and integrating components effectively.

alew
Download Presentation

COMPONENT BASED SYSTEMS: A CLASSIFICATION OF ISSUES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMPONENT BASED SYSTEMS: A CLASSIFICATION OF ISSUES Sule Yildirim, 20 mars 2003

  2. What is this paper for? • Component-based development offers many potential benefits such as greater reuse and a commodity-oriented perspective of software. • But it raises several issues that developers need to consider.

  3. Component: definition • Software components are units of independent production, acquisiton and deployment that interact to form a functional system.

  4. Issues in a framework In this article, a set of issues organized within an overall frameworkthat software developers must address for component-based systems (CBS) to achieve their full potential are presented. • Components can take a wide range of forms and sizes. • They should be independent of specific software architectural style. • While objects maybe components, all components are not objects.

  5. Framework helps to achieve the following • Helps transfer the potential of component-based system development into reality. • Brings together disparate perspectives on components. • Begins to identify the key research questions.

  6. Derivation of the framework • Phase 1: The issues and the published material studied. • Phase 2: Identify relevant issues. • Phase 3: Use framework to elaborate ideas.

  7. Software Product Issues Viewed from the perspectives of: • Component providers • Granularity • Portability • Component Integrators • Component selection(evaluate against requirements) • Interoperability (architecture mismatch, functional deficiencies, quality maintenance) • Combining quality attributes • Maintenance over distributed components • Commmon needs • Predicting limits (i.e. 32 bits problem) • Component description to locate, understand and evaluate • Integrated systems customers (Should supply well specified requirements)

  8. Software Development Process Issues can affect one or all viewpoints. • Component providers • Internationalization • Testing practices (make dependencies explicit) • Component Integrators • Requirements and component capabilities trade-offs. • Tool support for component evaluation • Demands for change (from both customers and providers) • Commmon needs • Long term support • Responsibility chain

  9. Business Issues • Component providers • Internationalization (on global market- encryption, advertising reg. etc) • Responsibility for quality (limit level of responsibility) • Horizontal versus vertical market • Marketability • Component Integrators • New business opportunities (cheap, well supported products) • Managing a range of contractual styles (different national regulations) • Demonstrating products to potential buyers • Trade-offs (accept an existing component or build an ideal one) • Measuring productivity (new productivity models needed) • Commmon needs • Component redundancy • Payment • Distributed execution • Security and certification • Integrated systems customers (reliable and well maintained products)

  10. People in Software Development Viewed from the perspectives of: • Component providers • Component Integrators • Evaluators • Management • Commmon needs • Integrated systems customers

  11. Conclusion • Several themes require further research • Evaluation • Maintenance • Interaction and integration of commercial and technical factors • Aggregation rules

More Related