Lecture 21: Component-Based Software Engineering
-
Upload
georgia-willis -
Category
Documents
-
view
231 -
download
0
description
Transcript of Lecture 21: Component-Based Software Engineering
Software Engineering
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
• 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 componentsComponent engineering
Domain engineering and component engineeringare concurrentRequirements are adjusted to accommodate reuse
TheCBSEProcess
[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 modele.g., drag/drop, cut/paste
• Automationtools, macros, scripts
• Structured storagesingle interface to heterogeneous data
• Underlying object modelensure 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
ClassificationHierarchy
[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?