Lecture 21: Component-Based Software Engineering

Today’s Topics Issues and Challenges for CBSE The CBSE Process Guidelines for Reuse The Reuse Environment Economics of CBSE Metrics for CBSE

Characteristics of CBSE Analysis & Design includes checking for reusable solutions A “more organized approach” to software reuse Helps reduce development time & cost (with streamlined infrastructure & process) Less emphasis on implementation, more on integration

Challenges for CBSE Does the domain allow reusability? Systems have common requirements Can the extra cost be justified? High degree of reusability Can support for reuse be created? Indexing, common access, process Can incentives be created for engineers? Appropriate culture, metrics, etc.

Composition Follows architectural design & precedes detailed design Can requirements be implemented: By COTS components? By internally-developed components? Are component interfaces with the architecture compatible? Can the requirements be adjusted to accommodate reuse?

CBSE Activities Component Qualification Does the component fit the need? Component Adaptation Resolve design mismatches Component Composition Adopt framework for integration Component Update Manage third-party updates

Types of Components Run-Time Components Business Components Dynamic binding Interface discovered at run-time E.g.: distributed objects (CORBA) Business Components Encapsulate an autonomous business concept or process E.g.: enterprise Java beans (EJB)

CBSE Development Process Identify, qualify, adapt, assemble, and update reusable components Component engineering Domain engineering and component engineering are concurrent Requirements are adjusted to accommodate reuse

The CBSE Process [From SEPA 5/e]

Domain Analysis Define the domain Categorize the items in the domain Collect a sample of applications Analyze each application Develop and analysis model for the domain objects

Identification & Categorization Select specific functions or objects Abstract functions or objects Define a taxonomy Identify common features Abstract the relationships Derive a functional model Define a domain language

Example: Common Objects Text processing objects share common functions Process sentence & provide feedback Process sentence & provide an output (rewrite, translation) Process sentence & provide markup Text processing programs share common context (desktop)

Example [2] Shared Objects Client: a program that resides on the desktop, interfaces with a word-processing program, and provides some functionality on the desktop Server: a program that resides remotely and does the actual work The KANT system (CMU) provides reusable boundary objects which are used in several applications

Other Examples Document class in Java (also its subclasses) User Interface components (e.g., Java Swing classes) Database interface components (e.g. reusable JDBC classes)

Guidelines for Reuse Is there a future need? Is the functionality common? Is the functionality duplicated? Is there a hardware dependency? Is the design optimized? Can we parameterize components? Can we reuse via modification? Can we decompose a component to derive reusable components?

Domain Characteristics Impact Reusability [From SEPA 5/e]

Structure Points Capture a repeating pattern in the domain (function, data, behavior) e.g., aircraft avionics system Three characteristics: Limited number of instances Simple rules, interface Implements information hiding

Generic Structure Points Application Front End (GUI) Database Computational Engine Reporting Facility Application Editor Can be used for estimation

Component Qualification Does the component: Perform the function required? Fit into the architectural style? Have the right qualities? Things to consider: API, tool support, run-time requirements, maintenance requirements, security, design assumptions, exception handling, …

Component Adaptation Ultimate Goal: “easy integration” Consistent resource management Common data management Consistent interfaces Alternative: Component Wrapping White-box (modify code) Gray-box (extend code / data) Black-box (pre-/post-processing)

Component Composition Four architectural ingredients: Data exchange model e.g., drag/drop, cut/paste Automation tools, macros, scripts Structured storage single interface to heterogeneous data Underlying object model ensure component interoperability

Integrated Information Management Flow-based information processing architecture Shared object model (Node, Document, etc.) User-defined nodes & resources Rapid development of reusable components

Emerging Standards OMG/CORBA Common Object Request Broker Architecture Microsoft COM Component Object Model Sun Java Beans Enterprise Java Beans – well-suited for eCommerce

Classification & Retrieval 3C Model [Tracz 1990] Concept: What does it do? Content: How is it built? Context: What is the domain? Indexing Schemes Controlled vocabulary Uncontrolled vocabulary

Classification Hierarchy [From SEPA 5/e]

The Reuse Environment Component Database Library Management System Component Retrieval System CBSE Tools for Integration Example of a web-based component library: www.jars.com

Economics of CBSE Quality Lower defect rate for reusable code Productivity Faster delivery of complete systems Cost Savings = CS – (CR + CD) Develop from Scratch Cost of Reuse Develop w/Reuse

Reuse Metrics Reuse Benefit (cost-based) Rb(S) = [Cnoreuse – Creuse]/Cnoreuse Reuse Leverage (object-based) Rlev = OBJreused / OBJbuilt

Questions?