Component (software)

from Wikipedia, the free encyclopedia

In the context of software architecture, a component is a piece of software that can interact with other software parts according to the rules of a component model .

definition

The word component is derived from the Latin componere (to put together ). In software engineering, however, the term component is used differently in terms of content. It is often wrongly used to designate a software module , which illustrates the similarity of both terms (see chapter Component Interfaces ).

In 1996 the software component was defined as follows at the European Conference on Object-Oriented Programming (ECOOP):

“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. "

“A software component is an element of assembly with contractually defined interfaces and only explicit context dependencies. A software component can be delivered independently and is a building block for third parties. "

More generally and in connection with the new concept of component-based development , a component is defined as follows, for example:

"A software component is a software element that conforms to a component model and can be linked and executed with other components without changes in accordance with a composition standard ."

A component is characterized by the fact that it represents an element of a component-based application and has defined interfaces for connection to other components. The exact shape of a component depends on the particular component model .

Component interfaces

The interface of the component is a binding interface ( interface ) to the rest of the software. The interface can therefore be compared to a contract between the component and the rest of the software . The explicit definition of context dependencies makes it clear how independent a component actually is from its environment.

The interfaces and the well-defined context conditions enable the component to be reused . The lower the context dependencies of a component, the fewer requirements must be met for the use of a component. It follows that the fewer dependencies, the easier it is to reuse. At the same time, the low dependencies enable the components to be maintained and developed independently. On the other hand, the independence of the components means that they contain redundancies. The developer of a component must therefore find a compromise.

The interface can be compared to a contract between the component and the rest of the software. An interface therefore defines how a component can be reused. At the same time, it defines how other components can interact with this component.

Components that extend software are sometimes referred to as add-ons , modules or plug- ins. It should be noted that the reverse does not necessarily have to be the case. For example, it is possible to refer to a collection of different mathematical functions as a module. The module may be independent in its functions. If it does not have a generally binding interface, however, the module does not meet the requirements of a component.

Interfaces can be divided into different types. Examples of different types of interfaces are:

  • Graphical user interface (GUI), also called human machine interface (HMI): Allows the component to interact with the user through a graphical user interface. It is operated using the mouse or the screen, for example.
  • Command line (CLI): Of particular interest when components are to be called by the system without the user having to do anything, for example, in order to process repetitive tasks at periodic intervals. Such an interface is addressed by entering commands in a command line.
  • Data interfaces : allow data from the component to be read in and out. This interface is accessed within the program.
  • Programming interface (API): This interface enables the programmer and other components to address the functionalities and services offered by the component using programming commands. Unless otherwise stated, the term interface always means an API in the following.

A component can have different interfaces of the same type. This can be necessary, for example, to integrate one and the same component into different systems. This increases the possibilities for reuse.

Advantage and benefit

Component development aims to reduce costs and increase flexibility in product development. The development costs for components are amortized through their reuse . Conversely, software development is accelerated through the use of components, since in the ideal case it only consists of assembling and parameterizing components (see also modularity ).

Components can be faulty. This leads to a further requirement: the independence of a component also means that the component handles its possible errors itself. This makes it a closed unit. In the event of an error, the error is easier to localize. An exception to this rule can only be made if this behavior is part of the interface contract. This means that an error in the component does not lead to incorrect behavior of the entire components, since these behave as contractually stipulated. This also reduces development costs.

Forms of reuse

Based on the reuse form of the component, it can be roughly divided as follows:

blackbox
The component is incorporated into the system to be developed as a self-contained unit. This component cannot be changed. Neither can any statements be made about their internal structure and functionality. The component is used exclusively on the basis of the defined interfaces and specifications of the component.
whitebox
The component is reused as an open unit. The word open describes that the unity is changeable. It can be adapted to the new requirements. In addition, their internal structure can be viewed and thus analyzed. The component is therefore viewed as a software fragment. The components are not only used on the basis of the defined interfaces, but also by analyzing the current implementation of these components.
greybox
The intermediate forms of black and whitebox.

Components at development time

Components can be integrated into the development environment, for example . Then they show their characteristics and behavior already at the development stage. This is a great advantage for the programmer: he can see how the component will look or work while programming.

Example of a component palette

Rapid application development is only possible through the use of prefabricated components .

Implementations

Standards

In software, component technology is, in the opinion of many, a cornerstone of software development over the next few years. Different standards coexist. Aside from CORBA , these standards are generally programming language, application, or platform specific. They form so-called component worlds or markets. Examples of such worlds are:

Development tools

There are special development environments and programming languages for component-based developments , such as:

literature

  • Olaf Zwintzscher: Overview of software components, W3L, 2004, ISBN 3937137602
  • Clemens Szyperski: Component Software - Beyond Object-Oriented Programming, Second Edition, 2002, ISBN 0-201-74572-0
  • MD McIlroy: Mass produced software components . In: Software Engineering, Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968 . 1969, p. 138-155 ( txt ).

Web links

swell

  1. ↑ Clemens Szyperski: Component Software - Beyond Object-Oriented Programming, Second Edition, 2002, ISBN 0-201-74572-0 , p. 41
  2. ^ William T. Council, George T. Heineman: Component-Based Software Engineering . Addison-Wesley, 2001, ISBN 0-201-70485-4
  3. ^ Dumke, Reiner: Software Engineering . Friedr. Vieweg & Sohn Verlagsgesellschaft / GWV Fachverlage GmbH, 4th edition, Wiesbaden 2003.
  4. ↑ a b Snoopy; Müller, Martin (German translation): Open Source - short & good.