Numerous strategies have been developed over the years to deal with the difficulties involved in the development of large-scale software architectures. Object-oriented programming and several architecture description languages (ADLs) are examples of such strategies. In recent years, component-based software engineering (CBSE) has been emerging as an approach to software construction in which pre-manufactured software "components" with well-defined interfaces are designed and implemented, and subsequently incorporated into larger software systems. Increasing popularity of CBSE is related to recent advances in two areas:
Although there are many (informal) definitions of software components, there seems to be agreement that software components are software "units" which "enable practical reuse of software and amortization of investments over multiple applications" [C. Szyperski, "Software Components", 2nd ed.]. Software components, as opposed to other units of reuse, such as source code libraries, designs, and architectures, are executable units of independent production, acquisition and deployment that interact to form a functioning system. Insistence on independence and executable form is essential to allow for multiple vendors and robust integration [C. Szyperski].
Systems composed of software components are called component-based systems. The requirement for independence and executable form rules out many software abstractions, such as type declarations, C macros, C++ templates, or Smalltalk blocks. Other abstractions, such as procedurs, classes or modules, or even entire applications, can form components as long as they are in executable form that remains composable.
Selection and evaluation of components are critical to CBSE [A.W. Brown, Foundations for Component-Based Software Engineering]. Component selection can be based on component compatibility; two components are compatible if any sequence of operations requested by one of the interacting components can be satisfied by the other components. Component compatibility can be analyzed at the level of component interfaces (i.e., the internal structure of the component can be abstracted), and Petri nets can be used to model sequences of (requested and provided) operations at the interface level. In this sense, Petri net models can be considered parts of component specifications.
Specific projects in this area include:
|Prev Page||Up to Main Page||Next Page|
Copyright by W.M. Zuberek, All rights reserved.
Revised: 2005.02.15 : :2546