Software componentry |
Software componentry is a field of study within software engineering. It builds on prior theories of object (object-oriented programming)s, software architectures, software frameworks and software design patterns, and the extensive theory of object-oriented programming and object-oriented design of all these. It claims that software components, like the idea of a hardware component used e.g., in telecommunication, can be ultimately made interchangeable and reliable.
Software componentry is a common and convenient means for inter-process communication (IPC).
=Software component=
A software component is a loosely defined term for a software Technology for encapsulating software functionality. Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:
A simpler definition can be: A component is an object written to a specification. It does not matter what the specification is: Component_Object_Model, Enterprise 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 object (computing)s (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.
=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-Partenkirchen, 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 abide by the same laws, which undercuts the incentive to provide them.
While some claim that Microsoft paved the way for actual deployment of component software with Object linking and embedding and component object model, it was actually IBM who lead the path with their System Object Model, SOM in the early 1990s. Nowadays 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:
=Architecture=
A computer running several software components is 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 **VBX, Component object model and DCOM from Microsoft **XPCOM from Mozilla Foundation **Visual Component Library and CLX from Borland **Enterprise Java Beans from Sun Microsystems **Universal Network Objects from the OpenOffice.org office suite **Eiffel programming language **Oberon programming language and BlackBox *Compound document technologies **Bonobo (computing) (a part of GNOME) **Object linking and embedding (OLE) **OpenDoc **Fresco (computing) *Business object_(computer science) technologies **Newi *Distributed computing software components **9P distributed protocol developed for Plan 9 (operating system), and used by Inferno (operating system) 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 Component object model (and COM+) from Microsoft **DCOP from KDE **System Object Model from International Business Machines (now scrapped) **J2EE from Sun_Microsystems **Microsoft .NET from Microsoft **Web Services ***Representational State Transfer
=Literature=
=See also=
*Business logic *Web Service *Third party software component Business component Factory by Herzum and Sims
=External links=
*[http://www.cs.dartmouth.edu/~doug/components.txt Mass Produced Software Components by M. Douglas McIlroy] *[http://homepages.cs.ncl.ac.uk/brian.randell/NATO/ NATO Science Committee Software Engineering Conference in Garmisch] - reports (PDF) *[http://virtualschool.edu/cox/pub/PSIR Planning the Software Industrial Revolution ] The history of manufacturing vs software compared. *[http://virtualschool.edu/mybank Cox s feasibility demonstration ] of a usage-based mechanism for incentivizing component producers. *comprehensive list of [http://xplc.sourceforge.net/doc/others.php Component Systems] *Article [http://www.dre.vanderbilt.edu/~schmidt/reuse-lessons.html Why Software Reuse has Failed and How to Make It Work for You] by Douglas C. Schmidt|
|