العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolCOMPONENT-BASED SOFTWARE ENGINEERING
(Redirected from Software component)
'Component-based software engineering (CBSE)' (also known as 'Component-Based Development (CBD)' or 'Software Componentry') is a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components. Components are considered to be a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages carrying data.
A 'software component' is a system element offering a predefined service and able to communicate with other components. Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:
★ Multiple-use
★ Non-context-specific
★ Composable with other components
★ Encapsulated i.e., non-investigable through its interfaces
★ A unit of independent deployment and versioning
A simpler definition can be: ''A component is an object written to a specification''.
It does not matter what the specification is: COM, Java Beans, etc., as long as the object adheres to the specification. It is only by adhering to the specification that the object becomes a component and gains features like reusability and so forth.
Software components often take the form of objects or collections of objects (from object-oriented programming), in some binary or textual form, adhering to some interface description language (IDL) so that the component may exist autonomously from other components in a computer.
When a component is to be accessed or shared across execution contexts or network links, some form of serialization (also known as ''marshalling'') is employed to turn the component or one of its interfaces into a bitstream.
Reusability is an important characteristics of a high quality software component. A software component should be designed and implemented so that it can be reused in many different programs.
In 1960s, we built scientific subroutine libraries, that were reusable in a broad array of engineering and scientific applications. Though these subroutine libraries reused well defined algorithm in an effective manner, but it had a limited domain of application.
Today, modern reusable components encapsulate both data and processing that is applied to the data. This enable software engineer to create new applications from reusable parts. For example - todays interactive interfaces are built using reusable components, that enable the creation of graphic windows, pull down menus and a wide variety of interaction construction.
Software components are built using a programming language that has a limited vocablury, an explicit defined grammer and well defined rules of syntax and semantics.
At the lowest level , the language mirrors the instruction set of the hardware. At the mid level, programming language such as c, smalltalk are used to create a procedural description of the program. And at the highest level, the language uses graphical icons or other symbology to represent the requirement for a solution. here executable instructions are automatically generated.
When a good software developer produces a maintainable, well documented program, machine level language can make extremely efficient use of memory and "optimize" program execution speed.But mid level language allow software developer and the program to be machine independent. These are procedural languages. In non procedural language, a program by specifying the desired result is required to achieve the result. Support software translates the specification results into a machine executable code.
It builds on prior theories of software objects, software architectures, software frameworks and software design patterns, and the extensive theory of object-oriented programming and the object-oriented design of all these. It claims that software components, like the idea of hardware components, used for example in telecommunications, can ultimately be made interchangeable and reliable.
The idea that software should be componentized, built from prefabricated ''components'', was first published in Douglas McIlroy's address at the NATO conference on software engineering in Garmisch, Germany, 1968 titled ''Mass Produced Software Components''. This conference set out to counter the so-called software crisis. His subsequent inclusion of pipes and filters into the Unix operating system was the first implementation of an infrastructure for this idea.
The modern concept of a software component was largely defined by Brad Cox of Stepstone, who called them ''Software ICs'' and set out to create an infrastructure and market for these components by inventing the Objective-C programming language. (He summarizes this view in his book ''Object-Oriented Programming - An Evolutionary Approach'' 1986.) Cox's attempt did not succeed because of the most obvious, yet fundamental, difference between silicon and software ICs. The former are made of atoms, so it is possible to buy and sell them through scarcity-based economics. The latter are made of bits which don't live under the same constraints, which undercuts the incentive to provide them.
IBM led the path with their System Object Model (SOM) in the early 1990s. Some claim that Microsoft paved the way for actual deployment of component software with OLE and COM. Today, several successful software component models exist.
The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.
Software componentry, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics. It accepts that the definitions of useful components, unlike objects, can be counter-intuitive. In general it discourages anthropomorphism and naming, and is far more pessimistic about the potential for end user programming. Some peers will even talk of software components in terms of a new programming paradigm: ''component-oriented programming''.
Some argue that this distinction was made by earlier computer scientists, with Donald Knuth's theory of "literate programming" optimistically assuming there was convergence between intuitive and formal models, and Edsger Dijkstra's theory in the article ''The Cruelty of Really Teaching Computer Science'', which stated that programming was simply, and only, a branch of mathematics.
In both forms, this notion has led to many academic debates about the pros and cons of the two approaches and possible strategies for uniting the two. Some consider them not really competitors, but only descriptions of the same problem from two different points of view.
It takes significant effort and awareness to write a software component that is effectively reusable. The component needs:
★ to be fully documented;
★ more thorough testing;
★ robust input validity checking;
★ to pass back useful error messages as appropriate;
★ to be built with an awareness that it ''will'' be put to unforeseen uses;
★ a mechanism for compensating developers who invest the (substantial) effort implied above.
A computer running several software components is often called an application server. Using this combination of application servers and software components is usually called distributed computing. The usual real-world application of this is in financial applications or business software.
★ Pipes and Filters
★
★ Unix operating system
★ Component-oriented programming
★
★ Fractal component model[1] from ObjectWeb
★
★ Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
★
★ XPCOM from Mozilla Foundation
★
★ VCL and CLX from Borland and similar free LCL library.
★
★ Enterprise Java Beans from Sun Microsystems
★
★ UNO from the OpenOffice.org office suite
★
★ Eiffel programming language
★
★ Oberon programming language and BlackBox
★
★ Bundles as defined by the OSGi Service Platform
★
★ NexWave Software Infrastructure (NSI) from NexWave Solutions
★
★ The
★
★ Flow-based programming
★
★ MidCOM[2] component framework for Midgard and PHP
★ Compound document technologies
★
★ Bonobo (a part of GNOME)
★
★ Object linking and embedding (OLE)
★
★ OpenDoc
★
★ Fresco
★ Business object technologies
★
★ Newi
★ Distributed computing software components
★
★ 9P distributed protocol developed for Plan 9, and used by Inferno and other systems.
★
★ CORBA and the CORBA Component Model from the Object Management Group
★
★ D-BUS from the freedesktop.org organization
★
★ DCOM and later versions of COM (and COM+) from Microsoft
★
★ DCOP from KDE
★
★ DSOM and SOM from IBM (now scrapped)
★
★ ICE from ZeroC
★
★ Java EE from Sun
★
★ .NET Remoting from Microsoft
★
★ Web Services
★
★
★ REST
★
★ Universal Network Objects (UNO) from OpenOffice.org
★ Interface description languages
★
★ XML-RPC, the predecessor of SOAP
★
★ SOAP IDL from W3C
★
★ WDDX
★
★ Part of both COM and CORBA
★
★ Open Service Interface Definitions
★
★ Platform-Independent Component Modeling Language
★ Generic programming emphasizes separation of algorithms from data representation
★ Brad J. Cox, Andrew J. Novobilski: ''Object-Oriented Programming: An Evolutionary Approach''. 2nd ed. Addison-Wesley, Reading 1991 ISBN 0-201-54834-8
★ Bertrand Meyer: ''Object-Oriented Software Construction''. 2nd ed. Prentice Hall, 1997.
★ Clemens Szyperski: ''Component Software: Beyond Object-Oriented Programming''. 2nd ed. Addison-Wesley Professional, Boston 2002 ISBN 0-201-74572-0
★ George T. Heineman, William T. Councill, ''Component-Based Software Engineering: Putting the Pieces Together''. Addison-Wesley Professional, Reading 2001 ISBN 0-201-70485-4
★ Business logic
★ Web Service
★ Third party software component
★ ''Mass Produced Software Components'' by M. Douglas McIlroy
★ NATO Science Committee Software Engineering Conference in Garmisch - reports (PDF)
★ ''Planning the Software Industrial Revolution'' The history of manufacturing vs software compared.
★ ''The independence of notion of component-orientation''.
★ ''Cox's feasibility demonstration'' of a usage-based mechanism for incentivizing component producers.
★ comprehensive list of Component Systems
★ Article "Why Software Reuse has Failed and How to Make It Work for You" by Douglas C. Schmidt
★ Article "Piecing together the component puzzle for greater gains"
★ New proposals to explore the Component properties: (i) Reuse and (ii) Loose coupling
★ http://www.smb.uklinux.net/reusability/
'Component-based software engineering (CBSE)' (also known as 'Component-Based Development (CBD)' or 'Software Componentry') is a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components. Components are considered to be a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages carrying data.
| Contents |
| Software component |
| History |
| Differences from object-oriented programming |
| Architecture |
| Technologies |
| References |
| See also |
| External links |
Software component
A 'software component' is a system element offering a predefined service and able to communicate with other components. Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:
★ Multiple-use
★ Non-context-specific
★ Composable with other components
★ Encapsulated i.e., non-investigable through its interfaces
★ A unit of independent deployment and versioning
A simpler definition can be: ''A component is an object written to a specification''.
It does not matter what the specification is: COM, Java Beans, etc., as long as the object adheres to the specification. It is only by adhering to the specification that the object becomes a component and gains features like reusability and so forth.
Software components often take the form of objects or collections of objects (from object-oriented programming), in some binary or textual form, adhering to some interface description language (IDL) so that the component may exist autonomously from other components in a computer.
When a component is to be accessed or shared across execution contexts or network links, some form of serialization (also known as ''marshalling'') is employed to turn the component or one of its interfaces into a bitstream.
Reusability is an important characteristics of a high quality software component. A software component should be designed and implemented so that it can be reused in many different programs.
In 1960s, we built scientific subroutine libraries, that were reusable in a broad array of engineering and scientific applications. Though these subroutine libraries reused well defined algorithm in an effective manner, but it had a limited domain of application.
Today, modern reusable components encapsulate both data and processing that is applied to the data. This enable software engineer to create new applications from reusable parts. For example - todays interactive interfaces are built using reusable components, that enable the creation of graphic windows, pull down menus and a wide variety of interaction construction.
Software components are built using a programming language that has a limited vocablury, an explicit defined grammer and well defined rules of syntax and semantics.
At the lowest level , the language mirrors the instruction set of the hardware. At the mid level, programming language such as c, smalltalk are used to create a procedural description of the program. And at the highest level, the language uses graphical icons or other symbology to represent the requirement for a solution. here executable instructions are automatically generated.
When a good software developer produces a maintainable, well documented program, machine level language can make extremely efficient use of memory and "optimize" program execution speed.But mid level language allow software developer and the program to be machine independent. These are procedural languages. In non procedural language, a program by specifying the desired result is required to achieve the result. Support software translates the specification results into a machine executable code.
It builds on prior theories of software objects, software architectures, software frameworks and software design patterns, and the extensive theory of object-oriented programming and the object-oriented design of all these. It claims that software components, like the idea of hardware components, used for example in telecommunications, can ultimately be made interchangeable and reliable.
History
The idea that software should be componentized, built from prefabricated ''components'', was first published in Douglas McIlroy's address at the NATO conference on software engineering in Garmisch, Germany, 1968 titled ''Mass Produced Software Components''. This conference set out to counter the so-called software crisis. His subsequent inclusion of pipes and filters into the Unix operating system was the first implementation of an infrastructure for this idea.
The modern concept of a software component was largely defined by Brad Cox of Stepstone, who called them ''Software ICs'' and set out to create an infrastructure and market for these components by inventing the Objective-C programming language. (He summarizes this view in his book ''Object-Oriented Programming - An Evolutionary Approach'' 1986.) Cox's attempt did not succeed because of the most obvious, yet fundamental, difference between silicon and software ICs. The former are made of atoms, so it is possible to buy and sell them through scarcity-based economics. The latter are made of bits which don't live under the same constraints, which undercuts the incentive to provide them.
IBM led the path with their System Object Model (SOM) in the early 1990s. Some claim that Microsoft paved the way for actual deployment of component software with OLE and COM. Today, several successful software component models exist.
Differences from object-oriented programming
The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.
Software componentry, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics. It accepts that the definitions of useful components, unlike objects, can be counter-intuitive. In general it discourages anthropomorphism and naming, and is far more pessimistic about the potential for end user programming. Some peers will even talk of software components in terms of a new programming paradigm: ''component-oriented programming''.
Some argue that this distinction was made by earlier computer scientists, with Donald Knuth's theory of "literate programming" optimistically assuming there was convergence between intuitive and formal models, and Edsger Dijkstra's theory in the article ''The Cruelty of Really Teaching Computer Science'', which stated that programming was simply, and only, a branch of mathematics.
In both forms, this notion has led to many academic debates about the pros and cons of the two approaches and possible strategies for uniting the two. Some consider them not really competitors, but only descriptions of the same problem from two different points of view.
It takes significant effort and awareness to write a software component that is effectively reusable. The component needs:
★ to be fully documented;
★ more thorough testing;
★ robust input validity checking;
★ to pass back useful error messages as appropriate;
★ to be built with an awareness that it ''will'' be put to unforeseen uses;
★ a mechanism for compensating developers who invest the (substantial) effort implied above.
Architecture
A computer running several software components is often called an application server. Using this combination of application servers and software components is usually called distributed computing. The usual real-world application of this is in financial applications or business software.
Technologies
★ Pipes and Filters
★
★ Unix operating system
★ Component-oriented programming
★
★ Fractal component model[1] from ObjectWeb
★
★ Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
★
★ XPCOM from Mozilla Foundation
★
★ VCL and CLX from Borland and similar free LCL library.
★
★ Enterprise Java Beans from Sun Microsystems
★
★ UNO from the OpenOffice.org office suite
★
★ Eiffel programming language
★
★ Oberon programming language and BlackBox
★
★ Bundles as defined by the OSGi Service Platform
★
★ NexWave Software Infrastructure (NSI) from NexWave Solutions
★
★ The
System.ComponentModel namespace in Microsoft .NET★
★ Flow-based programming
★
★ MidCOM[2] component framework for Midgard and PHP
★ Compound document technologies
★
★ Bonobo (a part of GNOME)
★
★ Object linking and embedding (OLE)
★
★ OpenDoc
★
★ Fresco
★ Business object technologies
★
★ Newi
★ Distributed computing software components
★
★ 9P distributed protocol developed for Plan 9, and used by Inferno and other systems.
★
★ CORBA and the CORBA Component Model from the Object Management Group
★
★ D-BUS from the freedesktop.org organization
★
★ DCOM and later versions of COM (and COM+) from Microsoft
★
★ DCOP from KDE
★
★ DSOM and SOM from IBM (now scrapped)
★
★ ICE from ZeroC
★
★ Java EE from Sun
★
★ .NET Remoting from Microsoft
★
★ Web Services
★
★
★ REST
★
★ Universal Network Objects (UNO) from OpenOffice.org
★ Interface description languages
★
★ XML-RPC, the predecessor of SOAP
★
★ SOAP IDL from W3C
★
★ WDDX
★
★ Part of both COM and CORBA
★
★ Open Service Interface Definitions
★
★ Platform-Independent Component Modeling Language
★ Generic programming emphasizes separation of algorithms from data representation
References
★ Brad J. Cox, Andrew J. Novobilski: ''Object-Oriented Programming: An Evolutionary Approach''. 2nd ed. Addison-Wesley, Reading 1991 ISBN 0-201-54834-8
★ Bertrand Meyer: ''Object-Oriented Software Construction''. 2nd ed. Prentice Hall, 1997.
★ Clemens Szyperski: ''Component Software: Beyond Object-Oriented Programming''. 2nd ed. Addison-Wesley Professional, Boston 2002 ISBN 0-201-74572-0
★ George T. Heineman, William T. Councill, ''Component-Based Software Engineering: Putting the Pieces Together''. Addison-Wesley Professional, Reading 2001 ISBN 0-201-70485-4
See also
★ Business logic
★ Web Service
★ Third party software component
External links
★ ''Mass Produced Software Components'' by M. Douglas McIlroy
★ NATO Science Committee Software Engineering Conference in Garmisch - reports (PDF)
★ ''Planning the Software Industrial Revolution'' The history of manufacturing vs software compared.
★ ''The independence of notion of component-orientation''.
★ ''Cox's feasibility demonstration'' of a usage-based mechanism for incentivizing component producers.
★ comprehensive list of Component Systems
★ Article "Why Software Reuse has Failed and How to Make It Work for You" by Douglas C. Schmidt
★ Article "Piecing together the component puzzle for greater gains"
★ New proposals to explore the Component properties: (i) Reuse and (ii) Loose coupling
★ http://www.smb.uklinux.net/reusability/
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
