This page has been automatically translate with Google from the German language.

3 configuration options of software

 3.2.3.2 Plugins

Plugin architectures are far common and since 1987 admits103, because each device driver is also a Plugin. Prominent examples are the Adobe of products, all possible Plugins for Browser like the Java, the Flash or the Realplayer Plugin and the developer platform Eclipse as well as the VDR software used here.
Plugins are thereby functionally independent additions of an application, which cover a technical function completely, without other components would have to be informed.
The application is responsible for the interfaces. Plugins are thereby more independent components than components. Besides they are written exclusively for an application and must into an existing system be integrated, work This also only with its application data.
Plugins are optional differently as components so actually than understanding and extend a software already functioning by certain functions or function groups. Plugins are latched thereby into the existing system and contain their own configuration.
They cannot be used however without integrative application. The main difference to components lies however in the emergence. Component architectures arranged an application into the computation logic and the infrastructure, This the technical interests, here apply: Logic and containers are separated. Plugins against it arranged entire application into same functional ingates and "put them again into one another ", therefore the name Plugins, here apply: Applications are separated by Plugins.
Their application can remain invisible as in the Browserbeispiel for the user, if this downloads and installs a Plugin independently; in the Adobebeispiel each Plugin reserves itself a range in the menu. By their structure innovative ideas are possible, for Eclipse so e.g. offer Plugins for code generators, Datenbankbrowser, Wikis etc.
Plugins can cause themselves and give also mutually at the installation time on. With the installation the Plugins must register itself with application, in order to be able to use their functions. The structure of a Pluginhierarchie can be represented as follows: 104


The domain knowledge contains thereby the information, which are necessary for the installation, integration and registration of a new Plugins, as well as information to the life cycle and to the services of a Plugins, without actually knowing the function logic of the Plugins. Pluginarchitekturen offer following pro and cons:

Evaluation of Plugin architectures105
Advantages Disadvantages
  • Very easy extension
  • Plugins are independent of total's application
  • Faster, parallel development in the project team possible
  • Exchangeability with changed requirements very flexibly
  • Makes possible a smooth integration of functions without complex infrastructure
  • Easy maintenance
  • Separation OF Concern in pure form
  • Uniform interfaces for all Plugins
  • Makes possible the development of innovative ideas
  • Optimal basis for the development of computer families
  • Plugins can be driven out individually
    		•
  • Installation becomes ever more aufwändiger, since each Plugin is integrated individually
  • Updates must be brought in for each functionality individually
  • Very large Pluginarchitekturen is more difficult to managen
  • Exclusively for an application conceives
  • The production of the domain knowledge is more difficult to manage
  • Development of a uniform interface for all interests is a more complex topic
  • Automatic installation of Browserplugins can a safety risk mean
    		•

    Table 17: Evaluation of Plugin architectures


     

    Top| Home| << back | next >>
    >> Home Page www.virtualenterprise.it <<