Analysis and development are based configuration of a software computer family as linux livecd in the context digital video of the project

In the communication company a large number at households orders higher) plants over a well equipped complete PC with comprehensive medium equipment such as TV-maps, fast, efficient diagram maps and Dolby Surround 5,1 (or. It is appropriate near to be e.g. used the advantages of these devices also in the medium range as the digital television more strongly since the borders disappear to the entertainment electronics ever more. Such Multimediaanlagen periods their existence often no more in the home office, but is the center of the modern living room.
Standard software points some lack out, which became conscious by the media the population. More efficient software is wished; some user would like to improve software actively. The interest in open SOURCE software increases in such a way and is no longer only one sphere of interest of a small group. The advantages are obvious: Open SOURCE software costs often nothing, always is by the spreading and the advancement on the most current conditions and loads for trying out in: In the Internet find interested an abundance in information.
On the other side the customer is not satisfied with the service range of software often. Modern requirements require for personally cut software. A solution for this is the concept 3 of the computer families.
A software core, which contains the basic functions, is adapted modular to the requirements and extended in such a way by various functions.
An example for this is the multiplicity at tax declaration software for different groups of users. That saves not only time in the face of rising achievement pressure of more briefly becoming product life cycles, since the modules can be used continuously again and modular are developed further, but also on economic side saves the consistent re-use development costs and serves above all the customer satisfaction.
These trends are trend-setting due to their development for the software production.
Therefore they are to be located connected with one another in the center of this thesis (diploma).

This work concentrates on that brought together modern software requirements with the advantages of digital television. In addition to the appropriate domains by Live CDs, digital television and computer families one introduces.
Major task is it to analyze and evaluate concepts of the computer family development along the software development process. But different representative concepts are systematically examined and their pro and cons are described.
As example in addition the configuration customized liveCD with the open SOURCE software of a VDR is presented, analyzed and to unite to Plugins and suggested changes in the sense software of the Reengineerings. These demo CD in a study by Melanie Schöppe and Martin Rulsch4 prototypically one created; it offers a Web-based menu for the selection of specific Plugins and starts the VDRSoftware configured after customer requirements.
These liveCD Ilmenau boats leaves itself and to implement in the computer laboratory DOES.
For the practical example to DO Ilmenau by Dr. – engineer Detlef Streitferdt developed FORE – model for the structuring by customer requirements used.

After the introductory words over this work in the 1. Chapter takes place in 2. Chapter an introduction to the DVP project and the FORE-Modell 5.
LiveCD of projects and their application type are presented. It is dealt with the receipt of digital television and video recorder at the PC as well as their pertinent software under Linux and Windows.
In the 3. Chapter is examined the configuration by software. Different operating systems, programming paradigms and tools in the course of the described software development process are analyzed. Systematics consist of the description of the concept and the following evaluation.
From these results conclusions for the configuration files of the VDR software about that are drawn liveCD. In 4. Chapter is presented the liveCD already existing and a theoretical concept to the new configuration on the basis the results from chapter 3 is suggested. Takes place last in 5. Chapter the summary of the explanations and the results of this thesis (diploma). Finally the view shows, where the development of computer families will lead.
In the appendix a number of useful information are made available.

3: Definition of a concept after [Balz 2001] P. 38 and 44: A concept models defined circumstances under several criteria. For the description of a concept one uses a notation.
4: See [Schö 2005]
5: See [Stre 2005] P. 87 FF

2.1. the DVP project to DO Ilmenau

This chapter is to introduce the reader to the ranges of topics of this thesis (diploma).
Thus as the first important point is described, what contents, meaning and a goal of the DVP project to do Ilmenau are. In addition the FORE model is described for the collection of requirements at computer families. Subsequently, liveCD projects are introduced. On the basis of the development of the digital television and the appropriate solutions of the maintenance industry the meaning of the software-technical solutions at the PC becomes clear.
Here with software solutions by Microsoft Windows and Linux one deals. For this purpose practicable liveCD projects are introduced.

2.1.1. conception of the project

The DVP project was called 2002 by Dr. – engineer Detlef Streitferdt at the faculty for software systems/process computer science in the life, in order to test among other things the FORE model developed in the thesis writing ” Family Oriented requirement engineering ”6 and to evaluate7 the basic idea of the DVP exists in the desire, the possibilities of television of uniting PC and audio devices to a multimedia center.
In the thesis a concept and a notation were created, in order to describe computer families, which let themselves consist of a system core and be extended in addition optionally depending upon customer’s request. This aspect of the software development has enormous development potential, there it quality, price and time optimization aims at.
The approach opens the possibility of being able to arrange economically individual software out components already used. The customer is included thereby consciously into the development process and the customer satisfaction rises.
For the evaluation of methodology a PC-based system with current VDR software was created.
The structure of the system to do Ilmenau can to the appendix A be taken.
Detailed information developed the interested reader finds in the Thesis writing8 as well as in various study and theses (diploma), those in the course of the time in the context of the DVP project9.

6: See [Stre 2004] P. 87 FF
7: See [DVP 2005] Home
8: see [Stre 2004] P. 19 FF
9: A logically connected overview of the past work knows [DVP 2005] Results or [Stre 2004] P. 168 FF. are taken.

2.1.2. the FORE model

The concept of the Computer families10 was developed, in order to reduce the expenditure from single solutions to, as software is reused. The basic consideration is that software parts resemble each other strong in structure and use often.
Therefore it is to be used meaningfully and economically such potentials.
Central task is the reusability of suitable parts. Software is to consist according to this principle of a firm core and variable parts, in order to correspond to customer requirements in such a way better. In order to be able to convert it, the existing requirements must be raised to the software in the context of the requirement engineering phase. The recognized requirements are logically arranged in models.
Finally they are evaluated, converted and varied accordingly or changed.
Accompanying to it the expenditure must be evaluated estimated and risks. The entire process is documented thereby. To this topic different concepts, like e.g. NEARLY, are described feature modelling, FeatuRSEB and KobrA11 in the literature.
Changeableness, family orientation, configuration options, which is spectrum of the parameters as well as the examinableness the tasks, at which they differentiate themselves. The analysis of these concepts took place in detail in the thesis writing12. At such concepts the fact is problematic that they support only more or less the respective task.
In order to create however a consistent model, all tasks mentioned must be linked logically and solved completely.
The description of a computer family takes place for it in a characteristic model. Here however problems arise as a result of the structure of the computer family. Because for the derivative of a system variant must be deposited both characteristics and requirements and their relations in the model. The clarity of these relations is the crucial thereby.
, An extended characteristic model consistent in itself makes in such a way Variety possible.
However the increased requirements attention must find also in the apron of the model. So additionally documents and persons must be held in the course.
The solution of the problems mentioned takes place in the FORE model regarding the automizableness and examinableness of the variant derivative. In the model versions are introduced in the context of the computer family and represented relations between the raised requirements. The FORE model extends the characteristic model under use of the traditional concepts. The data are raised by the requirement model and the extended characteristic model. By use of the development process the data flow into the data model. This locks the process of the requirement engineering and it takes place the draft of the software.
The individual steps have specific tasks: 13 requirement model: The model contains the hierarchically arranged requirements to the system and the appropriate persons as person model, anyway the referenzierte document model, which contains the structure of the Spezifikationsdokumentes14.
The relations and conflicts between the requirements must be likewise illustrated.
They can be mutually exclusive perhaps. In order changes reconstruct or retrogressive to make to be able, require it to a recording of the changes, history.
In order to be able to raise requirements, a requirement map is used. It logs important information like among other things dependence, the author, the allocation to a component or its meaning for the customer.
Characteristic model: Core elements in the following characteristic model are the relations of the requirements with the characteristics. Here the core of the software family by means of mandatory and the variants are described by means of optional characteristics. Characteristics are to be understood as summary of the requirements to the system and thus as descriptions of characteristic.
They can have different intentions: They can be functional nature, express interfaces, represent parameters or serve the structuring of the model. Also for their collection a characteristic map used, which is just as developed as the requirement map, will become, here all information a characteristic compactly summarized. The representation of the characteristics takes place hierarchically, in order to clarify their relations among themselves and to the architecture. They can e.g. point refinements or restrictions out of other characteristics.
For the representation of the numerous relations possibilities a notation was created, they are shown in appendix B. So can be indicated, which variants are possible and are thus necessary which characteristics to exclude, as well as which characteristics to the core belong, and which for the variant from the customer to it to be selected to be able. Finally only a model assertible in itself can automatically be transferred. This examination takes place on the basis automatic rules.
Development process: The development process is represented to 15 in the literature by ” the Six luggage model ” and used for the generation of the data model.
In addition the results of the domain analysis, thus requirements the engineering of the software family and the results of the application analysis, are used and adjusted thus the demands of the customers on the software. The result flows into the requirement model. This alignment has enormous meaning, since starting from here changes in the requirement model at additional costs and expenditure are to be only mastered. The FORE model covers the three modules mentioned as a part of the Six luggage model, which is pre-aged to the system model. Requirement the engineering of the computer family and the customized application is an extensive process, here to the thesis writing is referred.
Data model: The data model is the written compression of the results of past steps. The model contains a collection of the complete information. Those are the requirement model, the characteristic model, the computer family model, the document model, the person model and their relations among themselves. A goal is it here to represent the various relations among themselves in a UML diagram. The elements are stored in a data base under the appropriate variant of the computer family.
The requirement model represents the requirements to the system systematically arranged, to them persons, documents and numerous information is assigned. The requirements are attributed to the core and/or one or several variants. Something similar happens with the characteristics in the characteristic model.
Here the focus lies particularly in the assignment of the kind of the characteristics and the question whether the characteristic is optional in each case or mandatory. In the document model all provided documents are contained finally and the person model represent all persons in connection with the collection. Finally all changes with the appropriate date and the implementing person are specified in history, the collection of the characteristics are thereby abgeschlossen.16

10: A representation in more detail of this concept takes place in chapter 3.2.1.
11: More information under [Stre 2004] P. 72 FF
12: See [Stre 2004] P. 68 FF
13: See [Stre 2004] P. 87 FF
14: The document contains a complete description, as well as the components and interfaces and in addition costing and views of risk of the computer family including the persons, the requirements, the variants and their characteristics from the characteristic model.
15: The Six luggage model is a global model of the computer family development, see [Stre 2004] P. 211. The model including the entire development process is to remain here only briefly mentioned. Explanations in more detail are to be inferred [Stre 2004] P. from 70 FF.
16: See [Stre 2004] P. 87 FF

2.2. liveCD of projects

LiveCD is often linux based, necessary for working neither the non removable disk still another partition boatable CD with an operating system. It runs completely and directly from CD, DVD or a USB stick; is not necessary an installation. The operating system is only written into the main memory and used so a virtual non removable disk. Configurations can be made and become however then on disk or USB stick stored. The program can besides data media such as non removable disks, USB sticks, disks or CDs access. Under Linux the matured hardware recognition makes Kudzu17 possible.
Besides their employment is completely independent from software on the PC, already installed. A aufw�ndige and every now and then time-intensive installation is not necessary. They normally offer a total package at application software, which can be tested so witthout obligation with the operating system, or also a certain task like e.g. virus scanning fulfill. They can come and become thus everywhere to the employment so ” the individual on the way office ” 18. In this thesis (diploma) liveCD is defined as follows:

Table 1: Definition liveCD

The CDs offers so a large number at employment scenarios, which are summarized here: 20

Table 2: Application type of liveCDs

Since the software is not changeable on that CD, liveCDs are reliably in the Anwendung.21 however often need the CDs more patience. Because a system, which boats, hardware recognition and configuration must accomplish again and again again, needs for the start and the execution of the programs longer and achieves a constant noise level. Besides all system attitudes and data purge with each meeting, if not even of the back safety device by USB stick, non removable disk or CD one thinks. Also is not possible with Linux liveCDs writing accesses to Windows partitions with NTFS. 22
A summary of the pro and cons of liveCDs is here dargestellt23:

LiveCDs gives it for many operating systems; also for Exoten such as BeOS, ReactOS or AFROS such CDs is developed. A short overview with resuming left gives it under [Wiki 2005] Live-CD.25 in the following Unterkapiteln is liveCD of projects both furthest in Germany spread and for this thesis (diploma) of relevant operating systems presented.

17: See [Hatt 2005] P. 15
18: See [Hatt 2005] P. 20
19: See [Wiki 2005] liveCD and [Hatt 2005] P. 13 FF
20: See for this table [live 2005] starting side. This list does not raise the requirement to be complete.
21: See [Wiki2005] liveCD
22: See [Kofl 2003] P. 1258
23: All points mentioned could be confirmed in the context of this thesis (diploma).
24: See [Hatt 2005] P. 13 FF
25: There is more information to the topic under [live 2005] starting side, the forums and the appropriate Wiki.

2.2.1. existing liveCD of projects under Linux

Linux liveCDs, also humorously ” Little live Linuxes ” 26 mentioned, enjoy of large popularity.
Therefore there are momentarily approximately 250 different distributions. There are extensive lists at descriptions and Downloads of the liveCDs on the basis of Linux under [live 2005] starting side or [Bodn 2005].
Such distributions are suitable to rem asters, modifying that CD according to own requirements. In the Internet there are for it various guidances. The expandability of Linux liveCDs is possible over 3 different ways:

Extension by software packages (” minimum beginning ”)
extensive Modifzieren CD by De and installation of software packages (” maximum beginning ”)
Independent production liveCD (e.g. by Toolkits)

In the study of Melanie Schöppe and Martin Rulsch these 3 ways in detail beschrieben.27 two well-known distributions, which are relevant for this work, are in the following presented.

2.2.1.1 Knoppix 3.928

Knoppix, designated after its developers Klaus Knopper, is a free Linuxdistribution on the basis of Debian GNU/Linux.29
The software starts directly from CD or DVD and recognizes owing to a well maintained driver data base almost any one of Linux supported hardware already when starting automatically. The hardware can be likewise configured. If exotic hardware is used, there are universal drivers, which can be adapted by the user.
The software package on that liveCD already bring along a large number of programs, which are perfectly sufficient for normal requirements. It contains among other things the graphic user surface KDE with many supplementary product lines for the daily use such as OpenOffice.org, Gimp, Mozilla, Xchat and Gaim. Experienced Linux user can install the Knoppix operating system beyond that also directly on the non removable disk. This characteristic makes Knoppix one at the fastest furnishable Distributionen.30
Since Knoppix for all is freely accessible and can owing to the freely copyable Debian system license-free be used, the software becomes or the automatic hardware recognition Kudzu gladly for other derivatives uses. According to the requirements for user target groups programs are then installed. With the fact it is particularly favourable that owing to transparent compression up to 2 GB on that CD can be installed. Some well-known derivatives of Knoppix are presented in the following:

2.2.1.2 Kanotix 2005-0331

This Knoppix derivative e.g. puts the focus on particularly good and current hardware recognition, an elegant and uncomplicated installation on a non removable disk and would like the inadequacies of Knoppix, like the insufficient support of WLAN maps, beseitigen32.
Kanotix bring along likewise a large package at application software. In order to secure the topicality, with Kanotix also gladly packages are used, which are still in the test mode or still as unstable are considered.

26: See [Lin g 2005] Node 9185
27: See [Schö 2005] P. 1 FF
28: See [Knop 2005] Knoppix, [Wiki 2005] Knoppix and [Kofl 2003] P. 1257 FF
29: See [Wiki 2005] Debian: Debian is a GNU/a Linux distribution out excluding free software. Debian contains the operating system and a large selection of application programs, Tools and utilities, together with a suitable Kernel.
30: See [Lin t 2005] Knoppix FAQ
31: See [Kano 2005] info., [Kan w 2005] and [Wiki 2005] Kanotix
32: See [Heis 2005] Newsticker 60178; In the context of this thesis (diploma) the opinion of many Kanotix and Knoppix user in various forums could be confirmed: Kanotix is actually in the hardware recognition unbeatable.

2.2.2 liveCD of projects under Windows

Also under Windows there is official liveCD, which is however not freely accessible. Therefore these CD for private users one modified.
In order to go around legal problems, for it a program was written, which original CD of a Windows of operating system makes the production for owners possible own liveCD.

2.2.2.1 Microsoft Windows PE

Windows PE is liveCD, with which it boat-ends itself around 130 MT a large Windows variant of XP or the Windows of 2003 servers acts. The CD can be referred however only by Microsoft wholesale dealers and used. There the CD for the first installation by Windows and application programs with new PCs for the trade one uses.

2.2.2.2 beard PE33

Beard PE, and/or beard’ s PE, is ” the for everyone version ” from Windows PE, which gives it since April 2003. In addition belongs to 150 MT large liveCD with a Windows reserve system and a flexible Plugins as well as the possibility of burning additional Tools on the CD.
For the production of these CD the program PE Builder of beard Lagerweij is necessary. The beard PE software comes thus not from Microsoft, must however, since legal, are approved of, because everyone, which a current Windows has 2000 and more highly and the pertinent installation CD, can provide with the software own liveCD with network support and remote access as well as to graphic surface.
The system is conceived thereby openly and can individually be adapted; other programs can be copied into the listing which can be burned also inside, an additional XML and an info file provide for the necessary linkages and system attitudes for the Registry.
Besides various Plugins can be referred in the Internet. Special value is put here on the fact that beard PE data of NTFS and Fat32 partitions can read and write. Repaired with that CD can become secured Windowsinstallationen, copied or worked on and data. The standard environment becomes transportable as mini Windows, straight for administrators a useful program. Beard PE offers thus all advantages of Linux liveCDs.

33: See [situation of 2004]

2.3. digital television

Since the first basic considerations at the beginning of the 1990 years and the beginning of the conversion of similar to digital by ” the society for the promotion of the broadcast supply, created in Germany 1993, ”, briefly GARV, 34 conquers digital television the German households. Also European-wide efforts are based in the year 1993, as the DVB project started in Switzerland became35.
Until 2010 is to be able to receive now all German households digital television over a uniform standard. The digital standard improves the television in various regard by increased the transmission capacities36 and a multiplicity at additional information and services37 the advantages is here in summary represented:

Table 5: Advantages of the digital television

The digital signal can be received over the following ways: By satellite (DVB-S), by cable (DVB-C) or by antenna (DVB-T). In most densely populated areas in the meantime the receipt is no more problem. Additionally extensive service offers or a multiplicity at transmitters can be referred.
Digital television is strongly supported by economic side. ” Digitally the video Broadcasting Project ” 41, in over 270 the enterprise such as broadcast operator, manufacturer, Kabelund software companies and authorities from 35 countries co-operate, create for many years uniform standards. Digital television is European-wide, exactly the same as for a long time in Asia and South America a current and profitable topic. Digital television knows become42 on different ways received:

Table 6: Receipt of the digital television

2.3.1. digital television in the living room

Who would like to use digital television at the similar terminal, those needs to process additional components the digital signal and decodes43. For the translation a set Top box becomes needed44. Modern Integrated digitally TVs, briefly IDTV45, already inserted so a box. Who would like to transact photographs, needs a DVD recorder, which stores then the similar pictures and tones on CD or DVD. Another possibility are non removable disk recorders and/or Festplattenreceiver, them are recording equipment and set Top box in one. They store the data on an internal Non removable disk 46. Recorders, which support DVDRAM, offer the Time-Shift-function 47. The photograph formats however often make a re-using of the transmissions e.g. at the PC not possibly48. Often one pushes thereby also fast to the borders of the internal non removable disks

2.3.2 digital television at the PC

For the digital television is also the PC, if with appropriate capability characteristics available, as Multimediaanlage at home suitably. Such HTPC is able most diverse Multimediadaten like e.g. MP3s, VCDs, DVDs, DivX and AVI files to play 49 the equipment summarizes thereby single devices like e.g. video recorder, DVD player, CDSpieler, Hifi plant in equipment and made possible thereby still further application possibilities. Everything which is for this needed is a DVB map or a set Top box with digital exit and a connection, attached by USB, by cables, satellite or antenna.
Unfortunately some maps are unausgereift in the range of the DVB-T some more; for many maps are protect ” Patchorgien ” necessarily, in order to make the devices executable. In addition the appropriate software, those belongs often to the maps attached, but sometimes still not very much comfortable50.
Therefore lately different open SOURCE projects developed, with which with the help of the engaged developer municipality free and comfortable software for all requirements is to be provided. Thus the PC becomes the alternative opposite the classical television set.
Selected ones well-known and thus strongly forced open SOURCE projects for Linux are here in the following presented.

34: The society was created at the 22.Dezember 1993, more in addition under [GARV 2005] Home.
35: Under the homepage of the project there is much, also world-wide information over the DVB standard. See [DVB-O 2005] Home
36: Compression possibilities like the MPEG2 standard let save up to 96% the data set. Thus digital can be sent instead of a similar program on a frequency in the meantime up to 10. Exactly the same frequencies are cut off with the tones, in order to reduce the data set.

37: See [Dig f 2005] introduction
38: See for this [Ue-TV 2005] the over all television and [CT-SO 2004] P. 118 FF
39: See [CT-SO 2004] P. 119
40: Offerers e.g. are [Kab D 2005] or [Kab b 2005]
41: See [DVB-O 2005] Home
42: See [CT-SO 2004] P. 28 FF
43: See [Dig f 2005] introduction
44: See [DVBT 2005] FAQ; Set Top boxes are called often also DVB or digital Receiver.
45: See [Ue-TV 2005] devices
46: An overview of presently offered non removable disk recorders can be reread under [celebration 2005]
47: Deferred television is a popular function with digital video recorders, with which a transmission is taken up, while only little minute can be already begun later with looking at and the admission continues to run in the background. 48 see.
48: [CT-SO 2004] P. 28 FF the subsequent treatment of the data is not so easily possible due to incompatible data types. The manufacturer Seagate calls this procedure “DriveTrust technology “. See for this [PCMA 2005] message 37280
49: See [Wiki 2005] HTPC
50: See [CT-SO 2004] P. 125 FF, unfortunately is also the 2005 still like that, as had to be determined in the context of this thesis (diploma).

2.4. software projects for digital television

2.4.1 Linux based of projects

2.4.1.1 the VDR project

The VDR software 2002 of Klaus Schmidinger in the life called51 and can free of charge in the version 1.2.6 of the homepage of the VDR-project 52 downloaded become53.
The software makes it possible to note television and radio in high picture and clay/tone quality under Linux.
The basic idea was it, a linux based, free, to develop digital video recorders is pluginbasiert developed, and differently than the conventional commercial products all requirements fairly will was, as flexibly each user merges his Plugins necessary for it in primary system of the recorder.
The SOURCE code of the software is approved, so that there is in the meantime a multiplicity Plugins, which were programmed by the interested developer municipality. So far 76 Plugins were introduced on the homepage of the VDR portal of the public.
This and further available Plugins from other collections is listed for information in the appendix C.
All these extensions can be merged and made into the VDR software thereby the power spectrum of VDR more extensively than into some ready-made devices54.
In October 2004 the free software became even the test winner in the PC magazine under five Media center programs gekürt55.
which the software of everything can, is here exemplary represented56:

Table 7: The power spectrum of the VDR software

Since the software is so popular, in the meantime also some distributions were arranged based on Linux and are here briefly aufgelistet57:

Table 8: VDR distributions

These distributions differ in three important criteria. They contain different compositions of Plugins and/or support certain hardware. This they possess also different sizes of 32 MT for e.g. USB-Sticks58, up to contents complete CD. Most distributions are intended for an installation; they contain “abgespeckte” Linux distribution with integrated VDR software for a fast installation on hardware configurations for living rooms or PC, even arranged.
Right the distributions specified in table 8 are to be made accessible for efforts VDR over genuine liveCD. Two acquaintance representative are more near described in the following.
A. LinVDR
LinVDR is such liveCD for an installation with integrated VDR software and approximately 40 Plugins and supplementary product lines for a comfortable operation. The operating system lying to reason is strongly reduced; LinVDR is only approximately 50 MT largely.
A goal was to be sketched it, a stable and nevertheless small VDR Linux for a simple and complete installation inclusive of automatic installation routines. The current version 0.7 can be downloaded under [cook 2004]. The distribution supports however only few DVB maps and older versions of Plugins.
b. C’ T VDR
Also C’T VDR, from which develops magazine of the same name of the Heise of publishing house, supplies with a strongly reduced debianbasiertes Linux including to the VDR software and various Plugins and installation routines for a problem-free and fast installation.
The arising problems are the same as with LinVDR: The last update of the software took place in the summer 2004; Kernel, Plugins and thus also the supported maps are not current any longer. The distribution is however ideal for all, which would like themselves to assemble their own VDR box. The current version 3 can be referred under [Hei f 2004].

2.4.2 Windows based of projects

From the multiplicity commercial like also free software for HTPCs here on behalf four representatives under Windows, well-known in Germany, are mentioned.
Information is to be left reread under on the right of mentioned and is no further explanation here to find, since the practical example this thesis (diploma) is based on Linux.

Table 9: Software for digital television under Windows

51: See [VDR-P 2005] VDR info.
52: See [Schm 2005] Download
53: The current test version for developers is the 1.3.24, see [VDR-P 2005] Download
54: In the meantime one is in the Internet complete guidances, its own VDR box for the living room with LCD, housing with power pack, non removable disk, remote maintenance, noise protection, amplifier, to build Motherboard etc. Such boxes are commercially driven out also under the names Reelbox (vapor commodity), Topfield or Dreambox. See [VDR-P 2005] VDR info. and [home 2005] Home
55: See [PC-MA 2005] software tests
56: See for this table [VDR-P 2005] VDR info.
57: This table was inferred [VDR-W 2005] VDR distributions.
58: Under [strive 2005] it gives How ton for LinVDR on a USB stick.

3.1. general introduction

In this chapter now configuration concepts are to be presented in detail by software system families and by software under the two most common operating systems.
A goal is it to examine the configurableness requirements given by software system families to and to provide so an optimal proceeding for the conversion of the VDR based software to chapter 4.
Therefore with different philosophies for software configuration one deals and one describes their pro and cons. The evaluation is to serve to uncover the serviceability and adaptability of these philosophies and to develop the configuration that liveCD further.
In the context of the work the following is understood by the term “configuration”:

Table 10: Definition of configuration

Table 11: Definition of configuration management

There are several concepts software, which are integrated into the software development process to arrange configurable.
For classification into the appropriate software development phase the connection time is important, in which the variable portions are specified.
Configuration can take place at the following times:

To the development time over the way of the structure of code
At the compiler time over pre-processor instructions
In a configuration file when the setting-up and starting of a program
At run-time over the adjustableness

In order to understand the classification of the different configuration concepts in the Zeitverlauf of the software development process, this is represented in the following after [Balz 2001] P. 51 FF:

To the software development belong the tasks of the product planning, – definition, – draft and the product realization. In addition the quality and customer requirements must be fulfilled. After production of the software this must be maintained and waited during application. This contain e.g. error eliminate, the software to new condition adapt and new requirement to the software to fulfill61.

59: This definition orients itself at various encyclopedias: [INPR 2005] technical terms, [hand 2005] special dictionary, [unit 2005] glossary, [Seib 2005] glossary, [zpe g 2004] and [Inte 2005] glossary
60: Quoted after [agony 2005] SQUARE METER encyclopedia and [DIN 10007]
61: See [Balz 2001] P. 39

3.1.1 expiration of the software development process

The software development process covers after [Balz 2001] 6 phases, which are represented in illustration 1. The software development begins with the planning phase, in which an investigation is made whether the program product can be realized on the basis of technical, economic and personnel criteria. Here various studies are accomplished, in order to select the suitable product and finally roughly requirements, functions, to raise quality criteria etc. Finally it must be examined in this phase whether the project can be converted. At the end stand the work statement, a project plan and a Expenditure estimation63.
Here the definition phase follows. In this phase at the beginning of still very vague product requirements are specified, by being analyzed with the help of different participants of participants determined, whose models data and functions, and specified after simulation and execution. A goal is it to develop a consistent and complete product model. The result of this phase is product requirement specifications, a concrete summary of all requirements, functions, data and structures which can be realized, and a product model or a superficial Prototyp63
In these two phases the term of the requirement is engineering embodied64.
In the design phase become on basis of the seized requirements the software architecture, which develops user surface, interfaces, data base tying up and other goal platforms. Here edge and surrounding field conditions are considered and the fundamental decisions e.g. over interfaces to peripheral programs are met. The software architecture which can be developed describes the structure of the software system by the system components and their relations. It is to fulfill functional and not-functional product requirements and quality requirements and to interfaces supply65.
The results of this section are the Vorraussetzungen of the implementation phase. Here the sketched software architecture is transferred in programming activities, in order to implement the demanded achievements the given specification. In addition belong the program-technical development of the software as well as the documentation and cases of test.
Into the following acceptance and introduction phase the finished software to the client or market will hand over after numerous tests and with delivery minutes.
Then the introduction follows at the customer by installation, training, delivery of the user documentation and start-up of the Software.66 in the case of order work.
Maintenance and care servicing begin after the software introduction. Challenges are the error corrections, aging the software and This necessary increase in efficiency and the adaptation of changes or extensions. Here also already information and requirements know67 to a newer product collected.
Tests and validating are integrated tasks, itself by all phases the pull68.

3.1.2 concepts of the computer family development

For managing the special requirements of computer families and the re-use on the level of the code, Design and the architecture of software in the following in addition concepts and Method 69 are introduced, which require and develop one on the other in the run the software development each other.
On the basis of object orientation and their fine-granular class structure code is reused. Specialized classes over defined public interfaces can be summarized and reused in class libraries. Over transmission new classes can be derived, against which inquiries can be placed dynamically. The concrete use at run-time of classes can be steered via the Polymorphismus or Instructions70.
The production of universal classes requires thereby careful analyses and characteristic models, which hurt however the principle of the data packaging, if peripheral functions are changed such as persistence, security, remote access etc. in different classes. But aspect-oriented programming can be begun, where such critical processes in own classes are summarized, the basis classes contained only pure logic.
The maintenance and the reusability increases. These specialized classes become into the remaining code “eingewoben”.
Classes are however small for a comfortable re-use often too, if they cover only one function. Therefore rougher structures worked satisfactorily such as component architectures or Plugins. Their Granularit�t determines itself according to data of the performance and scaling barness, their installation extent and the number of components in the system. Here becomes only in containers, This run time environments, which worry about the technical interests, and which components with the pure computation logic partitions.
Good configurableness in the components ensures the use for computer families.
The re-use takes place not only in the code, but also in architecture and the Design. This can on Design level with draft samples, which designer driving on conceptional level contain, and on architecture level with Frameworks happen. Allcomprehensively the Generative programming concerns itself with the providing of a stable “plug system” from variable components and the automatic derivative over generators, which are based e.g. on GenVoca. Persistente attitudes can be specified in the current system e.g. in XML.

62: See [Balz 2001] P. 58 FF
63: See [Balz 2001] P. 98 FF
64: See [Stre 2004] P. 12 FF; Requirements the engineering after [Balz 2001] P. 118 as a subsection of the software technology understood, in which determines requirements, is assigned be modelled and analyzed and in the context of this thesis (diploma) on the basis the tasks of the requirement engineering both phases will be described.
65: See [Balz 2001] P. 719 FF
66: See [Balz 2001] P. 1085 FF
67: See [Balz 2001] P. 1090 FF
68: Testing begins 14 f after [Balz 2001] P. 1065 in this phase as one of the tasks, in [Stre 2004] P. tests as integrated phase is understood, which pulls itself continuously by all different.
69: For the definition of a method see [Balz 2001] P. 36: A method is a according to plan used and justified proceeding for the reaching of principles fixed by defined goals in the context. A method is understood thereby as upper grasp for concepts, notation and methodical proceeding.
70: Ifdef instructions are conditioned translations of certain optional or alternative program parts for different systems in the programming language C, e.g. in the Embedded range. See [Arno 2005] foil 21 FF

3.1.3. integration of the concepts into the software development process

The interaction of these methods and concepts aims at the development from computer families. They can be integrated according to the following pattern into the individual phases software development process, since their tasks construct one on the other: 71

Illustration 2: Configuration options in the course of the Development process72

The development of computer families begins Use Cases, the applications in the Planning phase73 with initial considerations like the Commonality Variability analysis, which concerns itself with the investigation of common and variable parts, modelful represents and characteristic models, how e.g. FORE, which raise requirements. In the definition phase the decisions and requirements in product requirement specifications are specified. Rough architecture which can be converted is specified.
The results affect any further procedure fundamentally and determine from the outset capability characteristics, the allocation of optional and mandatory requirements and make first decisions over usable hardware.
Finally in the design phase the complete software architecture is specified. In addition also decisions belong concerning the using programming paradigms, whereby the Generative programming developed as a spreading generic term with the development of computer families, which uses all following paradigms like aspect-oriented programming, architectures, concepts and technologies.
Layer architectures such as GenVoca, Plugins and Frameworks orient themselves at the structuring by fading out certain layers, functional areas or variable program sections.
The connection time, This at the earliest at the compiler time, knows the establishment of the variable parts of family members latest to the program start, as e.g. with that demo CD in chapter 4 happen also still at run time or particularly with Plugins.
At the VDR software Plugins can be called and merged into the program e.g. by OSD during the program execution. To the draft and the following implementation to it program sequence decisions, which are made by concepts such as Polymorphisms, draft sample, simple ifdef instructions or the fundamental way of thinking of the Separation OF Concerns, belong variable program sections with these concepts to the compiler time are realized. Draft and implementation of the program can be simplified thereby by component architectures such as COM, CORBA and JavaBeans, since they offer already finished components, which can be merged into a program. The connection of variable parts takes place here with the program start or also dynamically at run time, if ActiveX of elements in a Browser are e.g. installed. At the implementation time the realization of the software architecture is supported by Tools such as HyperJ of IBM or AspectJ of the Eclipse-Project74. , Specific portions of a family member developed here are specified at the compiler time. After introduction of the software can over configuration data banks and – files individual specific attitudes to the installation such as path data, to the program start such as server attitudes like e.g. with the Apache servers and like color and dimension of picture area attitudes of the screen being e.g. made at run time. Deputy topics of the individual ranges are more near examined in the following. The evaluation takes place following the demanded characteristics of the DIN ISO 9126, in which software quality is evaluated after the Kriterien75 functionality, reliability, usability, efficiency, alteration capability and transferability.
The points mentioned in the respective evaluation were inferred from the referenzierten literature of the Unterkapitel, and cannot be regarded not as generally accepted, since the decision must to be project-specifically made to certain Werkzeugen76, paradigms or architectures and dependence and usually according to experience used combinations of complex and less complex mechanisms exist here, which are suitable for specific problems particularly well, 77 “during in former times was assumed that that procedural models are as far as possible neutral for software development regarding the kind of the software systems which can be realized with them, can with newer methods completely clearly the connection between the choice of the methods and the associated conception over the kind of the system which can be provided be seen. “78
For the support of the selection of implementation assistance there are suggestions on supply 79, suitable by means of a catalog from Kiviat-diagrams 80 and description maps, e.g. of the FH Mannheim efforts,

71: See [V�lt 2000] P. 1 to 8
72: See [Balz 2001] P. 1 FF and [Arno 2005] foil 54 FF
73: The phase classification of the individual topics took place on the basis [Balz 2001] P. 1 FF.
74: Eclipse is a free, but platform-dependent software development environment (IDE), primarily for Java, which can be extended by Plugins of all kinds, by IBM was originally developed and then released and now by free developer municipalities of many large companies is constantly advanced. See [Wiki 2005] Eclipse
75: Quoted after [Balz 2001] P. 1113
76: For the definition of a tool and/or a Tools see [Balz 2001] P. 38: A tool serves the automated support of methods.
77: See [Arno 2005] foil 67 FF
78: See [Stru 2005] process
79: A Kiviat diagram represents developments of several dependent characteristics in a kind spider net.
80: See [Arno 2005] foil 56 FF

3.2 software engineering concepts for the configuration of computer families

Fundamentally by the configuration of the software architecture also the condition and expandability of the software are determined according to the implementation.
Therefore follow after the introduction for the development of computer families the exact analysis of the paradigms, architectures and auxiliary tools already mentioned in the preceding chapter, which are used with the production by families in the first phases.

3.2.1 introduction into the development of computer families

Software development places requirements within the range of new areas of application, complex tasks and increasing requirements, within the range quality with serious consequences of software errors, acceptance criteria, differently defined software quality and rising need of new systems and variants, increasing demand and the insufficient function cover of standard software. In addition the load comes by the high life span of old systems and their connection of developer capacities, which must be considered with new systems. Here well-known systems of the re-use of software intervene by means of component-based software development. A goal is the economical, generation specific to a request of a large number of qualitatively high-quality system variants, those to be automated to a large extent kann.81
In the context of this thesis (diploma) components are defined as follows:

Table 12: Definition of a component

Ulrich W. Eisenecker et al. designate the advantages of the computer families such as follows83 : “The software development is predominantly aligned to the production of individual systems, although everywhere to the necessity for re-use one refers. But how the development of unique pieces is to bring something re-usable out? Bring Frameworks, draft samples and software components in this regard improvement, but no break-through. However the a coil of computer families promises a substantial progress. It makes the manufacturing specific to a request for a large number of system variants possible, and which can to a large extent is automated. This permits the drastic lowering of development times and – substantial improvements of the quality as well as cost. “In this thesis (diploma) a computer family is defined as follows:

Table 13: Definition of computer families

The technical side of a computer family and the derivative of the family members are to be inferred from the illustration 3. The configuration of an application is manufactured automatically thereby on the basis the existing components and the reference structure by means of a generator. The diagram can be inferred from the following illustration:

81: See [ice 2003-3] P. 1 FF
82: See [Stre 2004] S. 11ff, [Wiki 2005] component, [ice 2003-2] P. 4 and [Balz 2001] P. 856
83: See [ice 2002] P. 1
84: See [Stre 2004] P. III
85: See [Alex 2004] foil 4, [2000 rubbed]

3.2.2 programming paradigms

3.2.2.1 Generative programming

On the basis of the requirements of software development, already described, the holistic Generative models programming of software systems in such a way that “on the basis of a requirement specification by means of configuration knowledge from elementary, re-usable implementation components an high-adapted and optimized Zwischenoder final product can be produced for “86 as required automatically.
In addition the Generative programming uses methods and techniques co-ordinated one on the other for the development of software system families. Substantial components of the Generativen of programming are to a large extent automatic the characteristic-based modelling requirements determined by thing in common and differences of the family members and the development from language means to the description of individual systems as well as the development of generators, the this due to produce87.
The proceeding of the Generativen of programming is represented in the following illustration:

Illustration 4: Computer family development after Czarnecki88

The fundamental components of the Generativen of programming are the Domain engineering and the Application engineering. In the Domain engineering is analyzed first the surrounding field: Which persons with which interests are involved, which requirements become posed. In the most important part, the characteristic model becomes summarizes, which relations has the characteristics of the family. Such a model is e.g. the FORE model presented in chapter 2.1.2. For the consistency examination of the characteristic model it gives to at present DOES to Ilmenau a research project. For the pluginbasierte software Eclipse gives it already such Überprüfungsplugin named pure:: variants89.
In addition tables and libraries must develop, which the appropriate knowledge over dependence, reciprocal effects, descriptions, origin and use of characteristics, as well as the standard defaults, connection times etc. to log. From this can be derived, which functions in the basic system compellingly to belong to to have and which in family members to be realized be able optional. But must be examined, which relevant components in appropriate categories of different implementations to be summarized to be able and which dependence exist.
Foundation-stone of this procedure is the Generative Domain Model, which contains the problem area, This the specialist areas and the specific requirements, the solution area, which describes all components of the system, and which configuration knowledge, which supplies the structural drawing for the components for the solution of concrete problem descriptions.
These results flow into the draft of the flexible software architecture for the complete application family and become then from again usable components, a domain-specific specification language which Domain Specific LANGUAGE implements, developed for it, and from configuration generators.
The results of the Domain engineering are similar a kind catalog for possible automatic derivatives to an offer brochure of car manufacturers. This catalog is the basis for the development of genuine applications of customers in the Application engineering. Here the specific customer requirements are raised and built up by means of the existing components, languages and generators by Templates and the configuration knowledge. Requirements, which are again raised here, flow over the necessary configuration management again into the Domain engineering ein90.
The procedure of the Generativen of programming has following pro and cons:

Table 14: Evaluation of the Generativen programming

86: See [Czar 2001-2] foil 8
87: See [ice 2003-2] P. 1 FF
88: See [Czar 2001-2] foil 7
89: The completely model-based commercial Plugin of the company of pure system GmbH supports the development and derivative of computer families, by translating characteristic models for these examined and by means of its own transformer independently into family members with the help of existing components. See [pure 2005]
90: See [ice 2003] technology and [Czar 2001-02] foil 7 FF
91: See [Tamm 2004] P. 1 FF, [Benz 2003] P. 1 FF and [Brüg 2005]

3.2.2.2 aspect-oriented programming

Fast development cycles by frequently changing requirements require flexible software architectures. Here that sets 1997 published paradigm of aspect-oriented programming. In addition, this is to extend object-oriented programming, becomes as independent Paradigma92 of which COM, CORBA or draft sample uses, understood.
Main idea of aspect-oriented programming is complete those realization of the Separation of Concerns, which is technical separation of important aspects or parts in programming, because many functionalities in object-oriented programming distributed on various classes, CROSS Cutting Concerns so mentioned. In addition aspect-oriented programming offers methods and techniques, in order to differentiate functional components and aspects orthogonal for program semantics to lead back and these again into a total composition. The reusability of the parts is the center of attention thereby.
Aspects embody here the code fragments of functions, scattered over the classes, which affect the software system in various places. Examples for this are right examinations, persistence, synchronisation of data, object interactions and parameter transfers. They embody on the one hand the requirements and encase them at the same time as program constructor93.
They can contain attributes, Kostanten, member types and functions, or replace and call also algorithm parts later. The aspects are paged out in own classes or other language fragments. Interconnect points, so-called Join POINTs, connect them with the remainder of the program. A Weaver controls, which classes are to be addressed by which aspects and “”she weaves among themselves.
The advantage of aspect orientation is in the fact that aspects can be in-maintained to extend also after compiling in component architectures, since aspect-oriented programming helps the crucial program sections the Concerns, to recognize and again use. In addition (see illustration 5) 94 must

• Aspects in an object-oriented program (grey deposited) to be recognized
• Efficient mechanisms for arranging and expressing the aspects to be found
• And in the object-oriented program verwoben become

The pro and cons are here summarized:

Table 15: Evaluation of aspect-oriented programming

Have a similar focus subject-oriented programming, Compostion of filter or the adaptive Programmierung96

92: For the definition of a paradigm see [Balz 2001] P. 40: A paradigm is programming techniques at the basis lying principle and/or a way of thinking.
93: See [Czar 2000] P. 264 FF
94: See [Czar 1998] P. 182 FF
95: See [Czar 2000] P. 267 FF, [Czar 2001] and [Arno 2005] foil 40 FF
96: See [Czar 2000] P. 254 FF

3.2.3 layer architectures

3.2.3.1 GenVoca

The GenVoca method developed 1988 from the two projects genesis and Avoca of Don Batory and O’ Malley, which concerned themselves with the use of DATA container LIBRARies. Within the range of the Generativen programming GenVoca is used as formal description of layer architectures and grammar for the development of a generator for the change of components with same interface, and focused likewise re-use and computer families. A generator has the goal of providing software systems automatically. Don Batory in addition: “Given A GenVoca model, incoming goods CAN create A family OF applications by composing feature” 97.
It closes the gap between the system description and the implementation of the system, and must specific requirements at speed, storage allocation, resources administration etc. fulfill. GenVoca solves the problem of the production of a generator by means of a compositional beginning as layer-oriented model. Each abstract data type or a characteristic is represented in its own layer. Each layer contains thereby a number of classes, which continue to refine the subordinated layer with classes and methods. The classes clarify parameterizable components, which can be represented from component view in a tree structure. The configuration knowledge from the domain analysis becomes thereby layer for layer of far carried98.
A manufacturer generator must examine a requirement specification within the range of the computer family development, completes, optimizes and the implementation to generate. Finished program products and likewise half products99 can do this.
An exemplary cutout clarifies this: 100

The components of a layer are summarized in a category (realm). A category can be understood in such a way as a library about exchangeable components, which is outward represented over a uniform interface.
Over parameters to the upper layer will then hand over, which component of the subordinated layer is to be used with the realization. The structure of the layers and their categories is transferred into a context-free GenVoca grammar, which with the help of the component categories and designing principles from the configuration knowledge means, which combinations at mandatory or choice-requiring parts is possible. Each expression along the grammar is a realizable Familienmitglied101.

The structure deposited in the grammar is converted by means of a suitable language as Templates. Such a developed generator can go through now all layers step by step and develop members of the described computer family.

Table 16: Evaluation of the GenVoca model

97: See [Bato 2005] P. 1 FF
98: See [Czar 1998] P. 119 FF and 134 FF
99: See [Tamm 2004] P. 2
100: See [Brüg 2005] chapter 2 FF and [ice 2002-2] foil 54 FF
101: See [Brüg 2005] chapter 2 FF and [ice 2002-2] foil 1 FF
102: [Arno 2005] foil 51 FF

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:

Table 17: Evaluation of Plugin architectures

103: See [Wiki 2005] Plugin
104: See [Völt 2000] P. 1 to 8
105: See [Völt 2004] P. 1 to 10

3.2.4 programming concepts

3.2.4.1 Draft sample106

Draft samples “are descriptions of co-operating objects and classes, which are custom-made, in order to solve a general draft problem in a certain context. A draft sample designates, abstracted and identifies the relevant aspects of a general draft structure ” 107, helps during the component development and represents again even universal components, which can be flexibly reused. They offer simple and elegant solutions for specific problems of the object-oriented software design, by representing simple and concentrated problem solutions.
Draft samples are by the consideration developed that itself in each well structured, object-oriented architecture samples find to let must. From this less extensive and more easily understandable architectures, which already successfully converted requirements, result and concentrate the knowledge and the experiences of the programmers in such a way that always recurring problems do not have again to be solved. They consist object-oriented of objects, classes, interfaces and leaving hierarchies.
The catalog after gamma contains 23 samples in 3 different Categories 108: Production samples, structure samples and behavior patterns, which resemble each other however frequent. They contain fundamental elements how

Sample name: As a knappe designation of the problem and elucidation of the vocabulary. Problem section: As problem and description of context with conditions for the employment of a sample (motivation, purpose, basic principle, questions, application diagrams). Solution section: As abstract description of the elements, relations, competencies and interactions and arrangements of the elements of the draft as a template, here also an example code belongs to.

Consequence section: As description of the pro and cons with use, e.g. storage location consumption, run time, speaking and aspects of implementation, influence on flexibility, expandability and portability of a system, variant possibilities, traps, Tipps and techniques for the implementation, samples and well-known applications and which samples used to be together used can.
Exemplary is here the structure sample for an adapter and/or a Wrapper described109.
The sample serves the interface implementation between incompatible classes without the classes themselves be changed must. Like that a re-use of classes of a class library is possible, which otherwise not the case would be. The proceeding is to be inferred illustration 9:

The Client accesses the target category and would like to implement an operation, which does not offer the class, but one offers by the adapted class. On direct way this operation incompatibility reasons cannot out e.g. take place, therefore in this development sample a new class is inserted “adapter “, which gets both methods left by the upper classes, implements the computation and returns the result to the Client. Pro and cons of draft samples are here summarized:

Beside the draft sample there is among other things architecture sample, which in principle pursues the same goal of solving i.e. a specific problem by an existing template. Architecture samples are here substantially far, since they give a complete basic structure for the arrangement of elements in a software system.

106: See [Phil 2003] P. 42 FF
107: See [Gamm 1996] P. 3 FF
108: See [Gamm 1996] P. 8 FF
109: See [Gamm 1996] P. 171 FF
110: See [Gamm 1996] P. 4 FF and [Vran 2002] P. 1 FF

3.2.4.2 Polymorphismus

In the object-oriented languages there are possibilities of submitting parts a program of an arranging view and so components define.111
This can e.g. be the central concept of the Polymorphismus, the multiformity of methods in object orientation. It is ‘the possibility of using objects of suitable interfaces at run-time for each other. ‘ 112
This there are different kinds of the Polymophismus113:

• ad hoc Polymorphismus:
  • (= different code is used for same objects)
  • Overloaded of values
  • Forced Polymorphismus (Coercion) – changes of data types with operations with different data types
• universal Polymorphismus:
  • (= same code is used for different objects)
  • Parametric Polymorphismus – production of Templates
  • Inklusionspolymorphismus – containment of a component by another

Methods of the same name can be applied in such a way to objects of different classes. Methods of the superclasses are replaced on use of a method of the same name in Subklassen, one speak of overloading. Here only the suitable interface of the object, other information is important e.g. over the class, which belongs to the object, is not relevant. This one is not fixed when placing an inquiry before the execution on a certain implementation. Straight one with generic components such as Templates comes the Polymorphismus to carrying. Crucial is only the compatibility.
Objects can be exchanged also at run time, so that objects of different classes react with same inquiries differently. The definition, which method of the Sub or superclass is applied to the object, takes place only at the run time. This becomes the principle of the late connection114.
The draft samples already introduced use likewise the Polymorphismus. They help to identify interfaces and their elements and data and with it concomitantly flexibly re-usable manufacture software 115.

Table 19: Evaluation of the Polymorphismus

111: See [build 2000] P. 53 FF
112: See [Gamm 1996] P. 447 FF
113: See [build 2000] P. 53
114: See [Balz 2001] P. 851
115: See [Gamm 1996] P. 17
116: See [Balz 2001] P. 828 FF, [Gamm 1996] P. 19 FF, [build 2000] P. 53 FF and [Gruh 2004] foil 1 FF

3.2.5 component architectures

Component architectures are the heart of the computer family development, because they assemble the “raw materials” systematically. The connections are here graphically represented:

Component architectures are presented in the following. Differences becomes thereby between single place systems such as COM, and architectures for distributed, heterogeneous systems like e.g. CORBA.

3.2.5.1 COM/ActiveX of Microsoft

COM is the object-oriented component model of Microsoft. The origin of COM lies in the technology of the group documents OLE introduced to the 1990ern, with which partial documents are embedded into other documents. Philosophy is here that applications make functions available, which also different programs can be from use.
So Word must e.g. know, how it must represent an integrated Exceltabelle. This means a re-use from program code already existing and This re-use of components.
Data exchange takes place in the Client/server model: The COM server produces and uses objects and offers the classes which can be exported, the COM objects, over the interfaces.
In the interfaces is deposited the information, which functions are offered.
The use of the functions takes place by pointers on one or more interfaces a component. The interface possesses a pointer on its internal table, which administers the pointers on its functions. It can be never accessed directly objects.
Transmission is possible here however only with the characteristics of the interfaces.
Interfaces have thereby a world-wide clear GUID, which must be registered before the use of the component into the Windows Registry. By the clear identification over the GUID components know also the same name carry118.
Components are present here as binary standard and are programming language independent thereby, the specification of the interfaces contain no special syntax, but describe the structure and the offered services of components. Besides 1996 a further model, the DCOM for distributed applications in the network were created. Today Microsoft COM+119 develops as an extension and the .NET-Frameworks120, which will replace some problems of COM to improve to be supposed and according to Microsoft COM.
COM components become as modules in the form of applications (as EXE on the local server with slower execution), as DLLs and OCX (in-process and This fast constantly) or as Windows Script Components delivered121. Since 1996 there are also COM components, which were created particularly for Internet: ActiveX of control members. They have only one interface and the ability to register itself automatically into the Windows Registry. Such control members are installed firmly thereby on the Client, which brings substantial safety problems with itself, since so the which is the basis operating system lies openly.
The architecture of COM can be evaluated as follows:

Table 20: Evaluation of COM architecture

117: See [point 1999] P. 21
118: See [Balz 2001] P. 871 FF
119: COM+ is belonged a platform and a model for the Clientseite, available in binary form, in one, and proprit�r to Windows. See [Balz] P. 941
120: See [build 2000] P. 53
121: See [Schw 2005]
121: See [Schw 2005], [Balz 2001] P. 896, [Micr 2005], [point 1999] P. 19 FF and [Punz 1999]

3.2.5.2 JavaBeans of Sun

JavaBeans are based a component model on the programming language Java. Their goal is it to make the composition of components possible for a complete program at minimum expenditure over graphic surfaces. Also individual Beans can be inserted as applet e.g. on web pages. In Builder Tools can JavaBeans by mouse-click to be joined. Each Bean a Java class, which was modified on configuration and adaptability, is in principle. JavaBeans reveal their characteristics, methods and events in a Builder for the additional adaptability and are This introspektiv.
In them are indicated (characteristics can take several values), bound (divides other Beans changes with) and characteristics with secondary conditions (other Beans can insert a veto before a change) implements.
They are connected loosely by events by means of GET () and set () methods, a JavaBean can so their services other Javabeans offer and again different services stress, by announcing themselves as a receiver and/or snoopers with the appropriate Bean. This loose coupling makes applicable 123 very flexible for JavaBeans
JavaBeans need thereby a container, This a run time environment, in that them to be always can embedded124.
For the development of JavaBeans Sun specifications gave change, in order to place the adherence to the standard surely.

Table 21: Evaluation of the JavaBeans

3.2.5.3 CORBA of OMG

CORBA belonged to distributed object-oriented applications and supported as middleware exactly like COM+ or like the EnterpriseJavaBeans of business procedures in distributed and heterogeneous systems. Middleware platforms must possess This multi-user abilities, on which number of the users, the data and business process scalable its and a high availability possess.
CORBA is thereby only a standard and a specification for the infrastructure of such platforms and component models, which communicate exclusively over interfaces.
The basis for it is short reference architecture Object management Architecture, GRANNY:

Illustration 11: GRANNY architecture of CORBA126

Components of this architecture are short the Client and server objects and the Object Request broker, ORB. This continues to lead the inquiry between the Client and server interfaces in the distributed system, in order not to have to fall back to complicated network minutes. The whole happens by Stubs on the Clientseite and Skeletons on the server side. They simulate the offered object services such as naming, a copying and deletion of objects (Lifecycle services), emergency services, pressures, security agencies, as if they would be locally present. Communication is made exclusively by it. The objects directly can be never accessed. Interfaces, classes and objects are described thereby with the help of the definition language IDL. The interface description supplies that dynamic to Invocation with interface (DII) and replaces unknown interfaces.
The described structure is equivalent to the EnterpriseJavaBeans127
Summary of the pro and cons of the middleware standard:

Table 22: Evaluation of CORBA

123: See [Balz 2001] S 856 FF
124: See [Java 2005]
125: See [Balz 2001] P. 896 and [Java 2005] and [point 1999] P. 19 FF and [Lemp 2002] P. 9 FF and [Punz 1999]
126: See [Balz 2001] P. 925 and 927
127: See [Balz 2001] P. 924 FF and [Wiki 2005] CORBA
128: See [point 1999] P. 19 FF and [Balz 2001] P. 924 FF and [Punz 1999]

3.3.1.1 description of the concepts

Microsoft has different concepts for the software for private users in the course of the time ent and developed further.
Under MS-DOS all programs had own configuration files for application-oriented data. The operating system stored own attitudes in 2 files: Config.sys and auto+EXEC-asked. Windows 3,0 introduced a system-far attitude storage to 4 initialization files: Program.ini, control.ini, win.ini and system.ini, simple linear and unencrypted instructions in text files. The use of the INI files was and is relatively simple to manage and offers a small expenditure for the software a programmer. Interfaces are intended and limit the functionality of software, since only in the context of the system-far INI files of Windows other programs or resources can be accessed.
This system has however some disadvantages:

Table 23: Evaluation of the INI files/text-based configurations

Therefore with Windows 3,1 a first central data memory for operating system-far configurations, which reg.dat, was introduced. This was present in a undokumentierten binary format and could be changed only by Registry editor. The associated file was allowed to become however not larger than 64 KB131, did not support yet the automatic synchronisation of the data and personal attitudes was not portabel.132
Since Windows 95 the Registry133 was improved. Configurations of the system are stored and administered in logically connected form in a hierarchical central data base. The data are called over keys and are among themselves linked.
The information is stored thereby in two coded files in the Windowsverzeichnis: And the system.dat 134 user.dat.
Additionally to the Registry for compatibility reasons still the old INI files are maintained win.ini and system.ini the Win 3.x versions, since old 16-bit applications is dependent on them still. The Registry permits several configurations of different users or changing system configurations and contains all hardware and operating system parameters. Additionally safeguards make a re-establishment possible of the Registry after a system crash. Network functions including remote ACCESS are possible135.
The Registry stores the information in a hierarchically developed, among themselves linked and code-system uniformly updatable This redundancy-free and. The contained values can be assigned Subschlüsseln. This attitudes in groups are summarized. The tree consists depending upon operating system of 5 or 6 main keys, everyone contains a certain aspect of the system configuration; User and machine data are separated:

Table 24: Structure of the Registry under Windows XP

The Registry is coded, by manual changes of the high-sensitive data in each literature is advised against. Previous backup copies are a mandatory recommendation. Changes of the key coded136 and values can make the operating system useless. For the modification of the parameters there are different possibilities.
The most important way is the registration editor:

Illustration 12: The registration editor

Besides there is a multiplicity from Tools on the market of third offerers and of Microsoft themselves to the comfortable optimization and ” Tuning ” the Registry, for clearing up errors and inconsistencies as well as for easy scanning for entries137.
Microsoft supports the configurableness by the system control and different riders like e.g. the screen characteristics; Changes are made also by set UP and installation programs over furnished APIs in the Registry. Programs bring various configuration menus for mouse, to printer, keyboard etc. with itself.
Many modern programs still use INI files for the deposit of the configuration and do without interfaces to the Registrydaten. From safety-relevant reasons Serial numbers become however usually into the Registry, and This codes, registered.
The use of the two systems can lead however to conflicts, because with each program start INI files are compared with Registryeinträgen and perhaps overwritten.
138 further advantage of the Registry concept is in and export of matching data. So certain keys and This configurations can being e.g. exchanged like the data types in the network. This method is used also by software producers and system designers, so simply over rain files the information into the Registry importieren.139

3.3.1.2 evaluation of the concepts

The Registry developed from the efforts to eliminate the disadvantages of the individual system files. The concept consists of the separation of the PC-own data and the user data, since application is to take place also in the network. The configuration attitudes are deposited thereby coded in the data base format, the data are global on the PC for all programs callably, uniformly and current, inconsistencies by outdated libraries or data type definitions are not possible.
By permanent examinations and the safeguard concept independent repairs and restorations can be accomplished. This “data corpses are eliminated “with e.g. the Deinstallation of a program.
It is problematic that all data are from each other dependently stored. That makes the system error-prone. Besides the interfaces are not obligatorily kept by programmers. The result are own redundant configuration files. For compatibility reasons also the conventional INI files must be maintained. By the distribution in the network data in addition, safety-relevant more sensitive become.
The advantages for a large operating system are however obvious, since central the important attitudes of the operating system are administered here; the concept is however still in some points improvement worthy.
The pro and cons of the data base concept are here in the following again summarized:

129: See [Robi 1998] P. 1 FF
130: See [Robi 1998] P. 4
131: This border was waived however with Windows NT 3,1. see [Robi 1998] P. 6
132: See [Robi 1998] P. 5
133: Also registration or registration data base mentioned.
134: The user file user.dat contains specific data of the announced user, which must be available in the network everywhere, the system file system.dat contains the local system configuration for the start the operating system and the application execution, This hardware, libraries and files.
135: See [fount 1998] P. 4 FF
136: The keys in the Registry consist of various data like the MAC address and the time and serve to the identification from interfaces to DLLs and Windows components (COM components), therefore should it in no case be changed.
137: See [fount 1998] P. 51 FF
138: See [fount 1998] P. 12 FF
139: See [fount 1998] P. 26 FF
140: See [fount 1998] P. 12 FF and [Robi 1998] P. 8 FF

3.3.2 Linux

3.3.2.1 description of the concepts

Under Linux there is no generally accepted way as it with Microsoft Windows is usual, since each group of developers pursues own opinions and goals. Like that each distribution is differently developed. Basis of these developments is the fact that the Linux source code for the free operating system under the GNU general Public License is approved, everyone may it use, copies, to pass on and change141.
Here also the graphic surface becomes from the multiplicity of the possible Variants142 beside the Kernel and the Software packages
installed; the individual components of the operating system are not as with Microsoft into a complete system embedded separate modular available, and explain so the complexity of Linux143.
With the surface frequently GNOMES, KDE, flux box/black box, Xfce 4 or evenly only the console are used. All pursue another configuration pattern. Linux is more transparently developed thereby in addition, and in all ranges from the user configurable.
This it can be more easily served by experts and be adapted to the own requirements. Vorkompilierte of packets (RPMs) gives it therefore in the Internet on various sides to the free Download144.
The system has advantages opposite Microsoft Windows: It can be adapted better and become safety gaps faster discovered and eliminated. The crucial disadvantage is that Linux requires a more complex installation; it is one seizes to usual distributions as e.g. talks has or Debian, Suse Linux, or Mandrake145.
The different distributions use thereby own Tools those with the configuration help, in the meantime e.g. give it in addition, system-spreading tools like Webmin146.
On the one hand they are usable in each Linux, limp however evenly to the development afterwards, since them each requirement to become fair to want.
For this work the distribution Suse Linux 9,2 is used. In order to make configurations at this system, the system control similar surfaces of KDE 3,3 and YaST 2, which use control centers, become.

Illustration 13: YaST 2 – the system control for Suse Linux

To configure Linux leaves itself generally after the guiding principle: ” Linux is larva with one thought in mind: Everything is A file. ” 147.
There are e.g. serious differences to Microsoft Windows like the file system structure, the user rights and the structure of operating system.
Due to the multiplicity of possible configurations in the different Packages there are many ways to modify the attitudes on a Linuxsystem. Also different offerers follow the example of Suse and offer user friendly surfaces for the attitude management.
Suse in the file etc. in the listing stores and transmits all changes, which are made over these surfaces and are system relevant, sysconfig configuration data into the appropriate uniform system files. The data are exactly the same formatted thereby like the Windows INI files: Key names for the group of configurations become of unencrypted instructions supplemented148.
As example here the configuration file of the VDR software for the transmit channels is represented:

Illustration 14: Configuration of the VDR channels

Behind the configuration of the attitudes under Linux directly several possibilities for the configuration management are applications and the operating system due to different developing stories. With the time have themselves some conventions develops by many programs to be used. Originally pure text files are used, which differ however in the syntax substantially.
Some applications use simple assignments of the form in the associated configuration files as under Windows “key name = value “, other applications use for the storage of the attitudes a C-similar Syntax149.
Also there are mixtures between different styles, then Apache e.g. uses a kind Mark UP language, those in its kind of a mixture from HTML and conventional value assignments150.
Other programs like Openoffice.org 1.1.4 used here use the XMLFormat.
This has the advantage that it is supported by many efficient Parsern and a usual essential structure for advancements and changes offers and for developers more easily be read can. The Desktop surface of GNOMES hits likewise a trend-setting way: For the storage of the configuration of the system a kind is used by Registry data base.
As examples here 3 different strategies of the configuration management are erläutet.

A. The registration data base concept of GNOMES 2.8
For the graphic surface GNOMES starting from the 2,0 version a Registry similar data base was introduced, in order to administer program attitudes, application and user attitudes central. The data base GConf contains however opposite the Registry some improvements: “So the library with variable Backends can work for storing the data, which makes it possible apart from the use of the normal XML format to secure GConf data in a Berkley data base. Further an administrator can set system-far pre-set values – with need even obligatory. Together with a LDAP baking it would be even possible to administer several computers central over a network. A further advantage from Gconf is that several programs, which access the same attitudes come themselves not into the traverse, and that all changes of attitude are announced immediately to the programs concerned – they step without delay into effect. So that the attitudes become not as kryptisch as in the Registry, are they in addition in patterns documents. For editing the GConf attitudes Garnome151 contains the early version of a graphic GConf editor; otherwise there also a command interface are named gconftool 2. “152
That access to the data base effected by means of the configuration editor, in Standardund of pre-set values to be worked on to be able and for e.g. the keys, values and descriptions used last be can searched kann153.
b. ” The Everything is A file ” – concept of Suse Linux 9.2: YaST 2 and KDE 3.3
For the basis of this thesis (diploma) Suse Linux 9,2 was installed. Users becomes over YaST 2, Suses installation and Configuration program154, which facilitate a configuring.
The KDE 3.3 Surface 155 used here offers likewise a multiplicity at graphic menus, which facilitate and strongly of the system control of Windows remind the attitudes. For example the optics of the KDE Kontrollleiste can be changed over a configuration rider, the changes become by the program in the appropriate listings of the programs themselves or generally for listing /etc, frequently under the file contraction conf deposited. A beautiful aspect, which speaks for Linux and simple text files: Changes, which are made by diagram-based menus, can be found and reconstructed problem-free:

Illustration 15: Opinion of the KDE Kontrollzentrums under Suse Linux 9.2

Illustration 16: The pertinent configuration file for the control border

C. The XML concept of Openoffice.org 1.1
The free Office package Openoffice.org goes just like the data base format of GNOMES a modern way, because it does not only store its documents in the XML format, but uses XML exactly the same for the deposit of its attitudes156.
One decided thereby for the XML format, since ” XML is an industry standard, and This the best choice for user-specific document types represents ” 157.
Exemplarily here an excerpt of an Openoffice.org is – configuration file for a user profile represented:

Illustration 17: A XML Konfigurationsdatei for Openoffice.org

151: Garnome is the development tool for GNOMES the Desktop.
152: The improvements opposite the Windows Registry were inferred [Lin u 2003].
153: More information about the registration data base of gnomes is there under [GNO-D 2005] GNOMES 2,8, [Lin m 2005] from the raising of a dwarf, [Lin m 2005] request announce here! and [Wiki 2005] GNOMES
154: See [Lin w 2005] YaST
155: See [Lin w 2005] KDE
156: See [OOo 2005] FAQ
157: See [OOo 2005] Main FAQ

3.3.2.2 evaluation of the concepts

The evaluation of the configuration concepts, which are used within the range Linux, becomes difficult on the first view, since the question touches also the fundamental discussion around Windows or Linux. Linux is a prime example for the use of simple text files for depositing attitudes. This basic adjustment, ” Everything is A file ” is pursued since its developing history by groups of developers with different goal.
Since these differences become also not in the future less, it is not to be foreseen that it will give a uniform system with Linux. On the one hand this attitude forces a larger research field, on the other hand gives this development less area for a generally accepted total concept.
These basic adjustments have however a crucial advantage opposite Windows, which is exemplarily represented by the two example illustrations of the KDE: Each change of the system, all the same whether by console, graphic surface is or direct interference into the configuration file logically and fast comprehensibly. That is to the one much responding, since everything can be changed fast by hand, besides is it, if it does not concern system files, not as riskily as an interference into the Windows Registry.
On the other hand one must find and recognize these files only once in the file system, in which format, This XML, Registry are written or C-similarly, them. The developers of application software have it under Linux comparatively simply.
Interfaces to other programs or libraries are, like each source code also, well-known and can be used, in order to use system-far data.
A summary of the pro and cons of linux basedly configuration concepts:

Table 26: Evaluation of linux basedly configuration concepts

158: See [Kofl 2003] P. 456 FF and [PCFo 2005] 1642 and [LiFo 2005] 117571

3.4.1 summary of the results

Concepts were presented for the development of computer families, which can be used for the flexible employment by re-usable components for the derivative by computer families. In addition belonged paradigms, concepts, Tools and architectures, whose proceeding and applicability in the course of the software development process were described. Here pro and cons from the literature were summarized. In addition according to standard used concepts of the configuration management of Windows and Linux came.
For the FORE model it can not be able to be derived from the results of analysis to be derived that a consistent modelling of the requirements for fundamental architecture decisions is important in the first phases of the development process from the outset, computer families component-based there from traditional software projects.
The use of components saves thereby time and money and canalizes for knowledge of preceding program developments. Cleanly arranged systems can be waited, extended also later better and modified. Generators, which are based e.g. on GenVoca, focus thereby the complete derivative of family members and need for it consistent rule-based grammar.
Therefore different aspects and summaries should not only take place from the outset from conventional functional view, but also model other criteria such as aspects, function groups, layers or architecture basic structures, in order to facilitate themselves so the following decision for rough architecture and the technologies which can be used and to already create for the implementation a foundation-stone for the proceeding of the program design at the time of conclusion of the requirement collection. The decision for the development of computer families should already be certain in the planning phase.
The moreover one this chapter pointed out, which concepts for the deposit of software in the two usually spread operating systems are at run-time used. Generally one can assume each problem requires its specific solution here. A simple application program, which does not need any communication with other programs, is well advised with the simple and clear structure of a text file. On the other hand power requires an operating system of a high performance, like also complex structure of a data base. Also from the safety aspect it is more meaningful to deposit system-far attitudes hidden and coded. The coding cannot be used with linuxbasierenden software projects however, since various licenses forbid this also at further developed software.
Meaningfully in connection with the production of computer families the development of a catalog would be similar the efforts of the FH Mannheim, in which over certain criteria in a model the correct aids can be selected. For this the appropriate knowledge would have to be gained and prepared. This could e.g. by extended and evaluated characteristic models for listing the software requirements and system properties happened159.
The concepts presented here are summarized in the following:

The criteria were used following the DIN ISO 9126. This covered160:

Functionality as comprehensive term for the range of the available functions, the correctness of the results and the compatibility with other systems or components and the suitability for practice.
Reliability as characteristic of the correct function with normal and less favourable conditions, the expenditure with resumption of the executability and reaction with falsification or overrun.
Usability as criterion for the comprehensibility, management and ability to learn of the concept.
Efficiency as length of time and resources need such as storage location and processor achievement up to the result.
Alteration capability as measure for the maintenance, feasibility, understanding duration of the program, stability and examinableness of the concept.
Transferability as characteristics for the expenditure of the implementation, for the adaptability to other environment and for the interface compatibility.

From the results of this table it follows that all concepts and methods more or less contribute to the software quality. Often due to the complexity of the concept reductions are made. Nevertheless it cannot be said generally accepted that certain concepts are suitable more badly, but is simply for other projects suitable.
This the power and error intolerance of a Windows Registry reduces the usability, increased however functionality all the more. The Generative programming against it offers a high function range under losses of the usability and alteration capability and can simply be transferred.
Component and Pluginarchitekturen support above average many criteria, and also ever more frequently due to their flexible structure are used.

3.4.2 results for the configuration of the VDR software

For the configuration that liveCD is pursued on the basis the results of analysis and the already existing Plugins the continuation of the Pluginmodells.
Configuration data are made thereby in individual unencrypted text files, which are expressed with the XML format, since the project has a relatively small extent.
With larger projects the positive aspects of an data base-oriented configuration would outweigh. The XML format is selected also therefore, since the requirements and characteristics of the DVP project are already present in XML. Besides XML offers a support of dynamic contents, better legibility and large support on international level, there to XML the data exchange format of the future161.

159: See [Arno 2005] foil 56 FF
160: See [Balz 2001] P. 1113 and [Phil 2005] P. 46 FF
161: See [Micr 2005-2]

For the practical demonstration of the configuration options presented in chapter 3 existing liveCD is to be examined, which contains a customized arrangement of the Plugins of the VDR software.
But the demo CD developed by Melanie Schöppe and Martin Rulsch in the context of its common academic year work ” digital video project on boat CD ” 162 one uses and one analyzes. The prototypische liveCD exclusively for the test environment in the laboratory DO Ilmenau provided. The software quality by means of suitable presented methods and techniques in the sense software of a Reengineerings and a Refactorings are to be increased, in order to be able to realize future changes more easily.
Refactoring as a Teilbegriff of the Reengineerings has the goal, the software quality without change of the actual functions regarding the re-use, comprehensibleness, maintenance, adaptability, of improving and of finding legibility and optimization of the resources use and of eliminating for future systems weak points. In the course of the Reengineerings then new requirements can be in-maintained faster. Both terms are however equivalently used often. Historically seen the software reorganization with function equivalence is based into the 1980er years, when one began to structure and modulate software. That should increase the legibility and page operations out. Today the focus is on the reusability of software parts. Object orientation offers itself thereby, class structures is however too fine granular, so that re-use in rougher structures such as must components163 take place.
The Reengineering of software as over term covers suitable methods and techniques, as well as all steps, which support the qualitative improvement, dressing and evolution of programs. This is possible in the following ranges: 164

• Emergency Repairs: immediate recovery of errors
• Corrective system preservation: Recovery of errors in next release
• Extension/adaptation: Adjustment to changed or new requirements
• Migration: Transfer into a new environment
• Integration: Integration into more comprehensive systems
• Reorganization: Improvement of the software quality without change of functionality
• RH documentation: subsequent production or improvement of the documentation

So measures in the object-oriented code can be e.g. made:

• Rename from methods
• Rename from classes
• Shift from methods
• Divide from classes
• Summarize from classes

The goals and measures mentioned of the achievement of objective are to be applied to the existing liveCD. In addition in the following Unterkapitel the CD is introduced in the context of an actual analysis. The moreover one become on the basis the results of analysis of the 3. Chapter theoretical suggestions in the sense of the Refactorings and Reengineerings made, in order to improve the configuration management.
The structure of the Pluginarchitektur can be inferred from the following illustration:

162: See [Sch� 2005]
163: See [Snee 2001] P. 5
164: See [Kuhl 2004] Home

4.1 actual state analysis and domain knowledge

In the following the existing CD is described, in order to seize possible starting points for a Refactoring.

4.1.1 description that CD

In the laboratory following relevant hardware becomes used165:

CCU: Intel Pentium 4 1500 MHz
Non removable disk: 40 GB von Maxtor
Diagram map: ATI technology Inc. Radeon check valve 100
DVB maps: Technotrend DVB Card “budget S� and DVB Card “Premium�

The complete graphic structure can be inferred from the appendix A.
Version with 2,6 a Kernel consists the available CD of a remasterten Knoppix 3,7, in which various programs necessary for the demo CD were not deinstalliert. In addition came the current DVB drivers and the Xfce 4 Desktop166, which is substantially smaller and faster loadable than associated according to standard the KDE of Knoppix. Additionally the Apache server 2,0 with the Python module 3,1 as well as the Python program 2,3 was furnished. In addition VDR was installed including for the Patch167 Elchi.
The additional Patch Vanilla can be selected optionally.
For demo purposes the following Plugins168 was installed:

Table 28: Plugins that demo CD

The exemplary Plugins was selected for visual reasons for the demo CD. The respective control guidance of the Plugins is to be inferred from the academic year work [Sch� 2005] P. 8 FF.
The finished system can be implemented in the laboratory environment. Automatically a Web surface starts the boatable CD in the goods basket Design, in the Plugins, Patchs and the operation to be selected can and then the VDR software configured start leaves themselves. The image output can be steered via the attached television or via the installed Player kvdr. The operation takes place alternatively by keyboard or remote maintenance. In addition the module lirc170 was furnished.
The opinion of the goods basket surface:

Illustration 19: Opinion of the menu of the existing CD

Over configuration files by means of XML fragments the Web surface is provided dynamically. When pressing the Startbuttons the compound instruction to a terminal is then led, which starts the VDR with the desired Plugins.
The proceeding is here graphically represented:

Illustration 20: Proceeding that demo CD

The complete notation of the FORE requirements and – characteristics can be taken from the appendix B. The notation is against-reflected in the menu; realized requirements that CD were marked contained in the program with one “+ “and in each case a further knot. Possible selection in the first level:

Illustration 21: Conversion of the requirements as FORE notation

In order to keep the listing structure in the eye, the paths relevant for VDR are here summarized:

Table 29: Paths that liveCD

165: See [Sch� 2005] P. 6
166: More to it under [Xfce 2005]
167: A Patch intervenes directly in a program logic, since it affects directly the source text and changes the entire user interface of the software.
168: A Plugin extends a program only by additional functions.
169: See [Sch� 2005] P. 8 FF and [VDR-W 2005] Plugins
170: Lirc is a project, which can steer the program via an infrared interface. Lirc contains device drivers for the Infrarotempf�nger and puts the signals of application at the disposal.

4.1.2 zones of contact

Ranges, within which changes can be made, are described in the following.

4.1.2.1 boat procedure

Since the boat procedure and the hardware recognition are Knoppix own, changes are not here necessary and/or not always possible for the VDR program. However it must be mentioned here that due to restrictions of capacity a large number at software and drivers were removed from that CD and the Kernel.
Thus the extent that reduces demo CD further to the size CD, can however exclusively for the laboratory environment be used. Therefore it would be appropriate to let with further versions the full Kernelumfang of the Knoppix version exist and to burn afterwards a DVD, in order to use so the full hardware recognition and the driver activation.

4.1.2.2 the Web surface

The Web surface is steered by the current Apacheserver. The user sees only the local web page, which is handed over by the server, after the program built dvp.py by the user inputs the sides from the HTML and XML fragments and for the pictures up.
In addition belongs the appropriate CSS file, which steers the appearance of the web page. The HTML fragments contain in each case parts to the heading, for navigation and to the Warenkorb with substitute symbols for the diagrams and left, which are then filled in each case with the XML fragments and built up depending upon Pluginauswahl.
For the XML files there is 3 different DTDs: for the Plugins themselves, for the operating module and for the controlling of the Ganzen171.
The exact flow diagram is to be inferred from the following illustration:

4.1.2.3 the program code

The script dvp.py builds the HTML sides up for the Web surface from the individual parts, gives it back to the Web server and starts and stops the VDR. In the source text the appropriate paths at the beginning are defined.
A change is here easily and understandably possible. Python can be used both procedurally and object-oriented.
The program used here is however not object-oriented written. Therefore the source code consists of various functions, which act as follows with one another:

The individual functions summarized the following tasks briefly:

• start (): initialize the menu, on the other functions, session management distributes the HTML inquiries
• ifaces (): determines IO haven and IRQs for the serial interface (remote maintenance)
• selection (): the list of selected Plugins, control and category opinions regulates
• auswahlisten (): The Scrolldown selection menus of the remote maintenance regulate
• patch (): The Scrolldown selection menu for the Patchs regulates
• warenkorb (): Provides the HTML code for the Warenkorb from 3 fragments
• Start (): the starting command line for the VDR builds up using the aid programmes vdrremote_server.py and modul.py
• Stop (): terminates the VDR, releases the interface of lirc again

4.1.2.4 integration of new Plugins

Despite a detailed description in the Studienjahresarbeit174 result in the case of the installation of a Plugins 5 practical problems:

Since the file structure does not correspond to the standard defaults, the Makefiles must and the Inc. loading files to be rewritten and a new Debian package for the Plugin be provided and compiled.
Since the two Patchs require one installation each, thereby 2 Debian of packages for the gepatchten VDR are necessary for each Plugin.
For merging the Plugins into the program new diagrams for navigation, the Warenkorb and the Buttons for the entire menu must be provided, which is connected with higher expenditure despite Templates, since does not provide the pictures dynamically, but is statically loaded.
In addition a mindestes HTML fragment must changed or provided to each Plugin, and at least one XML fragment to be provided.
In addition a Plugin can to be e.g. required also auxiliary configurations, and thus additional HTML elements as a Scrollbox, or other Plugins. The problems with the integration can be improved by following theoretical changes in the program and the configuration of the Web surface.

171: See [Schö 2005] P. 42 FF
172: See [Schö 2005] P. 44
173: See [Schö 2005] P. 51
174: See [Schö 2005] P. 55 FF

4.2 target concept: Possible changes

Possible changes are possible on different levels. On the one hand changes in the code and/or in the structure of the entire program can increase the software quality criteria, on the other hand can to level of the Web surface the criterion of the usability on the basis the DIN ISO 9241-10 further be specified.
Integrativ can be facilitated thereby the procedure for inserting new Plugins.

4.2.1 changes on code level

The prototypische program for and the VDRSoftware used here pluginbasiert configured is not object-oriented written.
The procedural allocation of the program code and the use of Templates are however already fundamental steps for the re-use of parts, use however not yet the full extent, which object orientation offers.
The principal purposes are here the increase of the software quality, reusability and the reduction of the expenditure, necessary are around a further Plugin to be integrated, e.g. by certain automations. Thus primarily the following considerations result:

Table 30: Changes of the program code

The object-oriented programming concepts presented in chapter 3 help to convert the program and to improve so the re-use and maintenance to be able to derive and in a later version in the sense of the Generativen of programming with the help of a generator automatically variants.
In addition the existing characteristic model must be transferred into a form, one automatic deriving from family members made possible.
For the better structuring of the object-oriented program then the advantages of object orientation can to be e.g. used as transmission, in order to realize the goals of the computer family development. To weigh however the expenditure and the use of the restructuring remain with small programs. To use the so following concepts presented in chapter 3.2 leave themselves:
Polymorphismus: Polymorphismus is as in each object-oriented language a task of standard. Python places to it a multiplicity to reports polymorphen on to order and gives the possibility own reports to provide. Conceivablly would here e.g. be in practical application the allocation of an application of methods for start and stop to a Plugin to the running time175.
Draft sample: Samples can be used or be able also in Python to be again developed here. Conceivable it would be to be created e.g. in the again structured program a Klassenkonstrukt after the sample “prototypes “, which regulates the diagram representation, the structure of HTML or the XML generation of new Plugins, because the sample “prototype “has the task by the use of a prototypischen copy new objects by copying to produce 176.
Aspect-oriented programming: As orthogonale summary of technical details apart from semantics aspect-oriented programming regulates right examinations, persistence, synchronisation of data, object interactions, parameter transfers etc. and increases thereby the reusability “of the filtered “code parts enormously. Conceivable here e.g. a routine in the practical example, which examines before program start, would be whether for the firmware or for the VDR software and its Plugins update are available177.

175: See [Lani 2000] P. 231 FF
176: See [Gamm 1996] P. 144 FF
177: For modpython the Apacheservers gives it in the meantime an aspect-oriented Framework named Pylets. More to it under [OSTG 2004]

4.2.2 changes on sides of the Web menu

In order to evaluate a user surface of application programs due to their ergonomics, the ISO 9241-10 (1996) became “ergonomic requirements for office activities with television sets – part of 10: Principles of the design of dialogue. Brussels: CEN “in the life called. She judges the software ergonomics for user friendly design of dialogue by the following criteria independently of the interaction technique: 178

• Suitability of task: Complexity of the operation, function range for the accomplishment of the requirements
• Self description ability: Overview of the function offer offers
• Controllability: Which functions are contained in which form
• Expectation conformity: the program corresponds to cognitive expectations
• Error robustness: as the system is tolerant in relation to control errors
• Individualizing barness: as the system can be adapted to own desires
• Learning favorableness: in what respect the surface helps the cognitive understanding of the

Users on the basis of these criteria surrender for the Web surface of the program the following suggestions, which increase on the one hand the ergonomics and reduce the integration expenditure of a new Plugins at the same time also here:

Table 31: Changes of the Web surface for the increase of the ergonomics

4.3 summary of the results

In the course of the investigation that it resulted demo CD that these in the laboratory environment do to Ilmenau is executable and by the verschlankten Kernel on other systems cannot be migrated. On the other hand it would be conceivable, instead of migrating to the aufw�ndigen modification that CD over the adjustment of the Kernels, extensive Deinstallationen and setting-up of the Xfce surface, the program and the Web surface on a Knoppix already existing derivative named Xfld with XFCE-Surface182 and to transfer the system on a DVD, so that space reasons must play no more role. Like that the spectrum of use that is not too strongly reduced CD. On the other hand the program lying to reason must be object-oriented adapted, in order to be able to use the advantages of object orientation.
Like that the demo CD are a suboptimales demonstration object for the concepts for the generation of computer families.
In chapter 4.2 so only theoretical suggestions on the improvement of the software quality and on the increase of the application ergonomics could be presented.
When further steps in subsequent work the applicability that must be possible CD primarily on mehren hardware environments and the program should object-oriented is adapted, in order to be able to use the concepts presented in this work. Then it is to be able to derive variants possible on the basis the characteristic model and a generator in form of a Skriptes, examined for consistency.

178: Quoted after [Rich 1999] P. 1 FF
179: See [Schö 2005] P. 65 FF
180: The Xine Plugin takes over the decoding of the MPEG2-Stroms, which is normally taken over with full featured maps by the hardware. The use of this Plugins makes the use of favorable Low for budget possible maps, which thereby however more main memory needs.
181: A proposal for solution in addition under [weave 2005]
182: This slim Knoppix gives it under [Xfld 2005]

5.1. summary and locking remarks

The Forschungsgebiet of the software architecture wins increasingly in meaning. Systematic structuring must be already embodied in the planning phase deeply, in order to reduce late error to improve and software parts to reuse be able maintenance, because “by a software architecture only the structure of the software system not specified, also possibilities of the arbeitsteiligen development which can be developed and thus the structure of a development project are put on in architecture.
The interfaces of the most important components are substantial elements of the common language of the project members. Thus the software architecture has a large influence on the procedure in the development project. “183
Here component-based architectures and computer families became generally accepted, based on proceedings of ripe technologies of the motorring industry away from monolith structures itself from a building block principle flexibly and reusing those serve184.
This work gave a representative cross section by the topic of the computer families. Modern systems require not only a new fundamental architecture, but also a constant methodical support by adapted proceedings, concepts, to reduce methods and Design principles to lower in order to be able successfully to develop software, the time ton Market time costs and the software quality for the customer to increase185.
To this thesis (diploma) in addition into the domain necessary for an example implementation by digital television and appropriate open SOURCE software, as well as liveCDs and computer families one introduced. The main part of the work lay in the investigation of the configuration options along the software development process of computer families.
In addition determined here applied paradigms, presented concepts and architectures in the different phases, described their pro and cons and analyzed strategies of the configuration management in the current operating system. For this in the summary a table was developed, which evaluated the individual topics on the basis the software quality criteria due to its special arrangement. However it must be considered here that a fundamental valuation is not possible and not necessary, since concepts must to be project-specifically selected and mutually cause themselves. On the basis the results of analysis a procedure for the configuration management that was developed demo CD in following chapter 4.
In a unification of digital television, liveCD, open SOURCE software and computer family development became in 4. To chapter an existing, to DO to Ilmenau developed liveCD, which a Web-based customer configuration of the VDR software offers for digital television, presented, and suggestions on the basis the results of analysis given by chapter 3, in order to increase in the sense of the computer family development the software quality with the help of the described concepts.
Likewise the Web surface was analyzed here and given suggestions on the basis the software ergonomics for an optimized user interface.
The VDR software is thereby an innovative deputy of Pluginarchitekturen, which can be adapted simply and flexibly actually changing requirements.
In the multimedia world this is a crucial competition factor, because the keyword of the today’s software development is thereby the re-use. It decides considerably on the cost factor of projects and improves the task distribution in software project teams. With this work could be shown, on which conditions the development of the generativen software development is, what momentarily by the method support can carry it out and in what respect she can be realized.

5.2 view

The development of component architectures, computer families and of them generativen derivative are still in the child shoes, however by the industry are strongly forced. The proponents are the opinion: “that in more near future the conventional software development is replaced by the generative “186
The problem here is the immense expenditure that behind it puts. The development of software on the basis detailed model production of requirements and specifications on high abstraction level before the implementation belongs with large software producers already to the state of the art. So one can reach by the generation of computer families of fast quality goals.
For small projects or smaller enterprises it is however questionable whether the expenditure on the side is worthwhile itself, since on the other side the complexity of the topic permits still no complete automation. Thus there are some restraining thresholds to overcome against the generative software development still. Therefore a multiplicity of promotion and research projects became e.g. of the Fraunhofer IESE the topic of the automatic generation in the life called187.
Automatic deriving becomes, if also do not replace, which can supplement conventional software production however substantially, since the advantages are immense. The knowledge from architectures already existing is gained systematically and forced further-used, re-use and maintenance, servicing and elimination of errors of such future systems will be substantially reduced.
Besides customer requirements will immensely rise such as customer use. Component-based systems are already today much like, the large success of such platforms like e.g. Eclipse or the VDRSoftware show dies.188
So this thesis (diploma) with the words is to close of Krzysztof Czarnecki: “The advancing technology wants make it easier ton package expert knowledge visits that it wants possible tons of staggered array it in A against set OF contexts, overcoming technological and domain differences.
This wants lead ton more automation, more specialization, and wants enable of new child of applications. But there is quietly A long way tons go”. 189

183: See [Tamm 2004] P. 5
184: See [Tamm 2004] P. 5
185: See [woman 2005]
186: See [Tamm 2004] P. 5
187: See [woman 2005]
188: See [Tamm 2004] P. 4 to 5
189: See [gentleman 2004]