Engineering of Component Based Systems

What’s components first?

  • Unit of independent deployment
  • Unit of third-party composition
  • No persistent state

Many people use the terms “components” and “object” interchangably. most of case there is no problem but, sometimes it is. obviously, a component is likely to come to life through objects and therefore would normally consist of one or more classes or immutable prototype objects. However, there is no need for a component to contain classes only, or even to contain classes at all.

First time when the people invented subroutines they just want to conserve memory. but, programmers soon observed that they could insert subroutines extracted from their previous programs, or even written by other programmers. now we understand that we can build a program by composition of those independent units of programs.

Component-based software development (CBSD) is changing the way large software systems are developed. CBSD shifts the emphasis from programming software to composing software systems. “Buy, don’t build”.

An architectural approach to building systems that are positioned to take advantage of the CBSD approach is the layered system. but we should keep in mind whatever approach is taken will have a profound effect on the integrability of a component-based system.

The benefit of CBSD is

  • Reduced development time
  • Increased reliability of systems
  • Increased flexibility

The pitfalls:

  • If the primary supplier goes out of business or stops making the component will other step in to fill the gap?
  • What happens if the vendor stops supporting the current version of the component, and the new versions are incompatible with the old?
  • If the system demands high reliability or high availability, how can the consumer be sure that the component will allow the satisfaction of those requirements?

Rather than the classic waterfall approach to software development, systems are designed by examining existing components to see how they meet the system requirements.

cbsd.gif

The key to the engineering of component-based systems is to understand what trade-offs are being made.

  • System requirements vs. available components
  • System architecture vs. component interfaces

A pre-condition for successful integration of components is that their interfaces are known.
Each of the following might be considered part of a component interface:

  • Application programming interface (API)
  • Required development and integration tools
  • Secondary storage requirements (run-time), processor requirements (performance) and network requirements (capacity)
  • Required software services (operating system, or from other components)
  • Embedded design assumption, such as the use of specific polling techniques
  • Exception detection and processing

From subroutines to subsystems: component-based software development
Engineering of component-based systems

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: