Component-Based Software Engineering (CBSE) Speaker: Jerry Gao Ph.D. San Jose State University email: [email protected] URL: .

Component-Based Software Engineering (CBSE)

Speaker: Jerry Gao Ph.D.

San Jose State Universityemail: [email protected]

URL: http://www.engr.sjsu.edu/gaojerry

Sept., 2001

Topic: Component-Based Software Engineering

- Introduction to Component-Based Software Engineering - The CBSE Process

- Design Principles for CBSE

- Classification and Retrieving Software Components

- Component Technologies- CORBA- COM+- Enterprise JavaBeans

- Management of CBSE

Jerry Gao Ph.D. 9/2001

Presentation Outline

All Rights Reserved


During system analysis, we ask the following questions relating to software components:

- Are commercial off-the-shelf (COTS) components available to implement the requirements?- Are internally developed reusable components available to implement the requirements?- Are the interfaces for available components compatible in the targeted system architecture?

Component adaptation:

Component composition:

Component update:


Engineering of Component-Based Systems

All Rights Reserved


What is Component-Based Software Engineering?

Component-Based Software Engineering is a process that emphasizes the design and construction of computer-based systems using reusable software “components”. CBSE is changing the way large software systems are developed. CSBE shifts the emphasis from programming software to composing software systems based on reusable components.

In CBSE, reusable component construction and component integration for software system are the major focus.

Why Component-Based Software Engineering ?

People believes that constructing software systems based on reusable high quality components is a cost-effective approach --> short development time, cost-reduction projects, high quality products.


Introduction To Component-Based Software Engineering

All Rights Reserved


Who are involved in Component-Based Software Engineering?- System analyst- Software engineers

- Component software developers - Application software integration engineers- Test engineers and QA

- Project and product managers

The major concerns of CBSE and software engineering:

- Developing software from pre-produced parts

- The ability to reuse those parts in other applications

- Easily maintaining and customizing those parts to produce new functions and features


Introduction To Component-Based Software Engineering

All Rights Reserved


- Lack of reusability due to:- Developed based the specific requirements- Use an ad hoc mechanisms to add reusability

- Lack of standardized component interfaces between components- Component interfaces are designed for a specific project- No consistent mechanism for supporting component interactions

- Lack of component interoperability- Lack consistent data exchange mechanism between components- Lack consistent interaction mechanism between components

- Lack of customization- Lack of support of customization of component features and interfaces.- Poor component user interface support

- Lack of development environment to support

-No language, and develop tools, and service facilities for component development


Engineering of Software Components- Issues of Traditional Software Modules

All Rights Reserved


- Component interface specification based on IDL (interface description language)

- Consistent component naming

- Meta data about component information, such as interfaces, relationships.

- Interoperability - communication and data exchange among various components

- Customization - interfaces for customizing components.

- Composition - interfaces and rules for building assembled components based on given components

- Evolution Support - rules and services for replacing components or upgrades

- Packaging and deployment - packaging resources and deployment support


Engineering of Software Components- Basic Elements of a Component Model

All Rights Reserved


Different descriptions of software components:

- Component: a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture.

- Run-time software component:a dynamic bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered in run time.

- System component a unit of composition with contractually specified and explicit context dependencies only.

- Business component:the software implementation of an “autonomous” business concept or business process.


Engineering of Software Components

All Rights Reserved


In addition to COTS components, the CBSE process yields:

- Qualified components:- assessed by software engineers to ensure that not only functionality, but performance, reliability, usability, and other quality factors conform to the requirements of the target system.

- Adapted components:- adapted to modify unwanted or undesirable features

- Assembled components:- integrated into an architectural style and interconnected with an appropriate infrastructure

- Updated components:- replacing existing software by new versions of software components



All Rights Reserved


Domain Engineering


DomainAnalysis

SoftwareArchitectureDevelopment

StructuralModel

DomainModel

ReusableComponent

DevelopmentRepositoryReusableArtifacts/

Components


Component-Based Development Process


AnalysisArchitectural

Design

Component Qualification

ComponentAdaptation

ComponentComposition

ComponentEngineering

Testing

ComponentUpdate

Application Software


Component qualification:

--> ensure that a candidate component will - perform the required functions- fit into the architectural style for the system- exhibit the quality characteristics (such as performance, …)

During component qualification, many factors should be considered:

- application programming interface (API)- the required development and integration tools or package- run-time requirements, such as storage, speed, network protocol- service requirements, such as OS, programming language,..- security features, including access control, ...- embedded design assumptions- exceptional handling



All Rights Reserved


Component adaptation:

--> ensure that a candidate component will - perform the required functions- fit into the architectural style for the system- exhibit the quality characteristics (such as performance, …)

During component qualification, many factors should be considered:

- application programming interface (API)- the required development and integration tools or package- run-time requirements, such as storage, speed, network protocol- service requirements, such as OS, programming language,..- security features, including access control, ...- embedded design assumptions- exceptional handling



All Rights Reserved


Component composition:

--> assembles qualified, adapted, and engineered components to forman application system based on a well-defined architecture.

Major task: --> establish an infrastructure to bind the components into an operational system.

The infrastructure provides a model for the coordination of components and their interaction protocols, and specific common services

There are four mechanisms for creating an effective infrastructure:- Data exchange model- Automation- Structured storage- Underlying object model



All Rights Reserved



Engineering of Component-Based Systems- Component Composition

Component i Component j

Data exchange model provides mechanisms to support:- human-to-software data transfer- component-to-component data transfer

Component -to-componentdata transfer

Human-to-software interactions e.g. drag and drop, cut and paste




Component i

Automation facilities and tools support:-interactions between components- installation, configuration for deployment- instantiation, run, and testing- management and service

Component execution and management environment

Automation facility

Automation facility




Component i

Structured storage model provides mechanisms to support heterogeneousdata and resources of software components in a single structure:

- various data resources, voice/video, text, data- various documents of components- creation, navigation, edition of component content

documents

data

text

Componentrepository




Underlying object model provides mechanisms to supportcomponent-to-component interactions over a network to achieve:

- platform and language independent supporting component communications- regulate component interaction protocols- standardized component interoperability

networkComponent Component


Myth #1: It’s important to know what COTS components can do for you.

Realty: It’s important to know what COTS components can do to you..Myth #2: COTS-based systems can be designed “top-down”.

Realty: COTS-based systems are built “bottom-up”.

Myth #3: An “Open System” architecture solves the COTS component interoperability problem.

Reality: There is no standard definition for “open system”, and “plug-in-and-play” doesn’t always work.


COTS Myths and Others- Myths on infrastructure issues:

All Rights Reserved


Myth #4: You don’t need to test COTS components.

Reality: You need to test COTS components more thoroughly because you don’t understand how they were built.

Myth #5: COTS product selections are often based on extensive evaluation and analysis..

Realty: COTS product selections are often based on slick demos, web search, or reading trade journals.

Myth #6: COTS components come with adequate documentation.

Realty: Features sell COTS components, not documentation.

Myth #7: You can configure a COTS-based system to meet your requirements.

Realty: You can configure your process to meet the COTS component’s capabilities.


COTS Myths and Others- Myths on infrastructure issues:

All Rights Reserved


Myth 8: The processes COTS products utilize reflect our industry’s best practice.

Reality: The processes COTS products utilize often only reflect the market schedule and domain experience of the producer.

Myth 9: You buy COTS component.

Realty: You buy the right to use a version of a COTS component.

Myth 10: Vendors will fix problems in the current release of the software component.

Realty: Vendors may fix problems in the next version of the product.

Myth 11: If you are a large enough customer you can influence COTS component supplier.

Realty: The market influences COTS component supplier.


COTS Myths and Others- Managerial Issues:

All Rights Reserved


A reusable software component can be described in many ways. An ideal description encompasses: (3C model)

(a) concept (b) content (c ) context

Three classification schemes: - enumerated classification- faceted classification- attribute-value classification

Jerry Gao Ph.D. 9/2001 All Rights Reserved

Classifying and Retrieving Components

Description of what the component does

Concept

Content

ContextDescription of howthe concept is realized

Description of its domain application



Classifying and Retrieving Components

All Rights Reserved

Indexingvocabularies

UncontrolledControlled

Classed Keyword Terms extractedfrom text

Terms not extracted from text

Enumerated

Faceted

Descriptors

Subject headings

With syntax

Without syntax

There are three types of component classification methods: -- library and information science methods

-- artificial intelligence methods-- hypertext systems

Component-Based Software Engineering (CBSE) Speaker: Jerry Gao Ph.D. San Jose State University email: [email protected] URL: .

Documents

engineering of component

component integration

component features

reusable software components

component update

component composition

component adaptation

programming software