Gibt es Programme die von alleine Programieren?

aMan schrieb:

ob das jetzt maschinensprache oder eine programmiersprache ist, ist doch fast das gleiche..

mfg aman..

Damit hast du deine Ausgangsfrage selbst beantwortet.

Es soll trotzdem nicht unerwaehnt bleiben, dass Makros in Lisp zur Laufzeit eingebunden werden koennen und hierzu nichts separat kompiliert werden muss.

PeterTheMaster

man kann ohne weiteres ein programm schreiben, welches ein "hello world" programm in eine textdatei schreibt, die compilierung veranlasst und auch das kompilat startet wenn gewuenscht. dazu muss keiner denken koennen.
es wird sich natuerlich schwerlich ein programm selbstaendig eine idee fuer ein neues programm einfallen lassen koennen und dieses dann implementieren.

Last-Boyscout

Find ich alles verdammt interessant.

Thx für die vielen Beiträge!

mfg
Last-Boyscout

Prof84

Dabei existieren zwei Ansätze:

a) Code Generierung, zum Bleistift:
http://www.d-s-t-g.com/neu/pages/pagesger/et/ettop.htm

b) Komponentenkonfiguration und Integration, zum Bleistift:
http://de.wikipedia.org/wiki/Enterprise_Application_Integration

Beide Systeme treffen Entscheidungen auf bereits bestehende Konzepte. D.h., ein Softwarepogramm wird niemals vollständig autonome Entscheidungen treffen. Auch der eigentliche Thrill in der Agententechnologie (/me Agent := 'ein Softwareprogramm, das zu autonomen, mobilen, zielorientieren und behaarlichen Handlungen mit der Real World fähig ist, intelligente Dialoge führt und die Übertragung von Informationen verhandelt und koordiniert. Konzepte, Umwelt, Wahrnehmung und Handlung eingrenzt und bei der Auswahl der Handlungen logisch denkt.') kommt nur auf, wenn man durch konnektive und evolutionäre Zusammenhänge die Konzeptentwicklung und Entscheidungsfindung der menschlichen Nachvollziehbarkeit entzieht und sich dann entweder angenehm überraschen oder bitter enttäuschen läßt.

<ot subject="philo">
Deshalb bin ich auch so fasziniert von dem philosopischen Ansatz von Matrix I und II (III war Scheiße): - Der Mensch trifft ebenfalls keine autonomen Entscheidungen. Alles begründet durch logische, physische, chemische und physikalische Zusammenhänge. Ein paar meiner Lieblingssprüche:
- "Entscheidung ist eine Illusion, es existiert nur Kausalität!" (Matrix II)
- "Ein Menschenschicksal ist ein Menschenschicksal und das Leben ist nur eine Illusion!" (Japanisches Sprichwort zum Kamma - aus Shogun)
- Innovation is an illusion of human! In fact, it's just an unknown combination of things those already exist! /me
- "Der Auserwählte ist eine Anomalie zur Entscheidungsfindung!" (Matrix II)

Tja! Habe bereits einen Level erreicht, bei dem man Softwareentwicklung nur noch philosophisch betrachten kann und nicht nummerisch ...
</ot>

Man bin ich heute wieder fuzzy!

cu
P84

Wenn du dir vorstellst, das der Computer selbständig ein Programme schreiben soll, und du nur die Eigenschaft der zu entwerfenden Programme angibst, so ist dies VOLKOMMEN UNMÖGLICH.

Es ist nicht einmal möglich zu gegebenen Programmen f berechnen zu lassen, ob diese eine nicht triviale Eigenschaft überhaupt besitzen. (Satz von Rice)
Wie soll der Computer dann ein Programm mit einer Eigenschaft erzeugen, wenn er nichtmal überprüfen kann, ob der erzeugte Code die Eigenschaft überhaupt hat?

Prof84

@Mister:
Sorry, vielleicht möchtest Du eine andere Intention ausdrücken, aber einige Aussagen halte ich für schlicht weg falsch!

MisterX schrieb:

Wenn du dir vorstellst, das der Computer selbständig ein Programme schreiben soll, und du nur die Eigenschaft der zu entwerfenden Programme angibst, so ist dies VOLKOMMEN UNMÖGLICH.

Den Gegenbeweis könntest Du Dir in meiner Firma ankucken.

Einige Quellen die public sind:
http://de.wikipedia.org/wiki/Intentionale_Programmierung
http://www.edge.org/digerati/simonyi/simonyi_p2.html
http://c2.com/cgi/wiki?IntentionalProgramming
http://intentsoft.com/

MisterX schrieb:

Es ist nicht einmal möglich zu gegebenen Programmen f berechnen zu lassen, ob diese eine nicht triviale Eigenschaft überhaupt besitzen. (Satz von Rice)

Wieder falsch oder ggf. unvollständig: Die entscheidenen Fragen stammen aus dem Anforderungsmanagement. Entstehen aus der Problem-Domain nicht-funktionale Anforderungen (NFR) gebe ich dir Recht. Entwickeln sich aus den Eigenschaften (dem Verhalten) nur funktionalen Anforderungen (FR) ist eine Messung der Zielbefriedigung sehr wohl möglich. Alles was man braucht ist eine vollständig abdeckende Repositry und ein Konzept das die Rückverfolgung zur Solution-Domain herstellt. Ist klassisches Domain Engineering.

http://www.modulo3.de/vortraege/lt2002_vortrag_anforderungsmanagement_in_it_projekten.pdf
http://www.software-kompetenz.de/?4478

MisterX schrieb:

Wie soll der Computer dann ein Programm mit einer Eigenschaft erzeugen, wenn er nichtmal überprüfen kann, ob der erzeugte Code die Eigenschaft überhaupt hat?

s.o.
Eine wichtige Grundvoraussetzung ist allerdings, das sich alle Eigenschaftselemente untereinander nicht beeinflussen.

Prof84 schrieb:

@Mister:
Sorry, vielleicht möchtest Du eine andere Intention ausdrücken, aber einige Aussagen halte ich für schlicht weg falsch!

MisterX schrieb:

Wenn du dir vorstellst, das der Computer selbständig ein Programme schreiben soll, und du nur die Eigenschaft der zu entwerfenden Programme angibst, so ist dies VOLKOMMEN UNMÖGLICH.

Den Gegenbeweis könntest Du Dir in meiner Firma ankucken.

Einige Quellen die public sind:
http://de.wikipedia.org/wiki/Intentionale_Programmierung
http://www.edge.org/digerati/simonyi/simonyi_p2.html
http://c2.com/cgi/wiki?IntentionalProgramming
http://intentsoft.com/

MisterX schrieb:

Es ist nicht einmal möglich zu gegebenen Programmen f berechnen zu lassen, ob diese eine nicht triviale Eigenschaft überhaupt besitzen. (Satz von Rice)

Wieder falsch oder ggf. unvollständig: Die entscheidenen Fragen stammen aus dem Anforderungsmanagement. Entstehen aus der Problem-Domain nicht-funktionale Anforderungen (NFR) gebe ich dir Recht. Entwickeln sich aus den Eigenschaften (dem Verhalten) nur funktionalen Anforderungen (FR) ist eine Messung der Zielbefriedigung sehr wohl möglich. Alles was man braucht ist eine vollständig abdeckende Repositry und ein Konzept das die Rückverfolgung zur Solution-Domain herstellt. Ist klassisches Domain Engineering.

http://www.modulo3.de/vortraege/lt2002_vortrag_anforderungsmanagement_in_it_projekten.pdf
http://www.software-kompetenz.de/?4478

MisterX schrieb:

Wie soll der Computer dann ein Programm mit einer Eigenschaft erzeugen, wenn er nichtmal überprüfen kann, ob der erzeugte Code die Eigenschaft überhaupt hat?

s.o.
Eine wichtige Grundvoraussetzung ist allerdings, das sich alle Eigenschaftselemente untereinander nicht beeinflussen.

Folie 13
http://ls2-www.cs.uni-dortmund.de/~droste/GTI06/Inhalt/060518.pdf

Andreas XXL

Mister X hat recht.

In der Form, dass man einfach eine Eigenschaft angibt und der Computer ein entsprechendes Programm berechnet ist UNMÖGLICH.

Natürlich kann man Programme schreiben, die für BESTIMMTE Eigenschaften ein entsprechendes Programm erzeugen.

Aber allgemein IST ES UNMÖGLICH.
Gib einfach eine nicht berechenbare Eigenschaft ein, wie z.B die Berchnung der Diagonalsprache. Der Computer kann aber nicht erkennen, das es sich bei der Eingabe um eine nicht berechenbare Funktion handelt. Er wird bei einem theoretisch perfekten Code Erzeugungsprogramm unendlich lange versuchen den Code für die Eingabe zu erzeugen. Allerdings kann er auch nicht erkennen, das er unendlich lange daran scheitern wird. Denn selbst wenn er es 100000000 Jahre Versucht hätte kann er nicht daraus schließen, dass es nicht geht. Denn es könnte ja sein, das nur die Rechenzeit nicht gereicht hat und er das Ergebnis eine Sekunde später gefunden hätte.

MisterX schrieb:
Es ist nicht einmal möglich zu gegebenen Programmen f berechnen zu lassen, ob diese eine nicht triviale Eigenschaft überhaupt besitzen. (Satz von Rice)

Wieder falsch oder ggf. unvollständig: Die entscheidenen Fragen stammen aus dem Anforderungsmanagement. Entstehen aus der Problem-Domain nicht-funktionale Anforderungen (NFR) gebe ich dir Recht. Entwickeln sich aus den Eigenschaften (dem Verhalten) nur funktionalen Anforderungen (FR) ist eine Messung der Zielbefriedigung sehr wohl möglich. Alles was man braucht ist eine vollständig abdeckende Repositry und ein Konzept das die Rückverfolgung zur Solution-Domain herstellt. Ist klassisches Domain Engineering.

@Prof84
Diese Aussage von dir ist (leider) absolut falsch.
Selbst das Problem, ob ein Programm auch nur anhält ist nicht berechenbar.
Da nützten dir auch funktionale Anforderungen absolut nichts.

Selbt wenn du ein Programm gegeben hast, welches als Anforderung nur f(2) = 7
bei Eingabe n Element N hat, kann kein Computer berechnen ob das stimmt.

Natürlich kann er das programm starten und auf die Ausgabe von der Eingabe 2 warten. was passiert aber wenn das programm nicht anhält. Wie oben beschrieben kann der Computer aber nicht feststellen, das das gegebene programm nicht anhält. Also bleibt nicht anderes überig als nach einer gewissen zeit abzubrechen und zu sagen das das Programm nict das gewünschte berechnet. Aber es könnte ja sein das das Programm aus der 2 die 7 gaaaaanz aufwendig berechnet und das Programm eine Sekunde nachdem man es abgebrochen hat das richtige ergebnis berechnet hätte.

Prof84

MisterX schrieb:

Prof84 schrieb:

MisterX schrieb:

Es ist nicht einmal möglich zu gegebenen Programmen f berechnen zu lassen, ob diese eine nicht triviale Eigenschaft überhaupt besitzen. (Satz von Rice)

Wieder falsch oder ggf. unvollständig: Die entscheidenen Fragen stammen aus dem Anforderungsmanagement. Entstehen aus der Problem-Domain nicht-funktionale Anforderungen (NFR) gebe ich dir Recht. Entwickeln sich aus den Eigenschaften (dem Verhalten) nur funktionalen Anforderungen (FR) ist eine Messung der Zielbefriedigung sehr wohl möglich. ...

Folie 13
http://ls2-www.cs.uni-dortmund.de/~droste/GTI06/Inhalt/060518.pdf

Na also! Da sind wir doch d' accord! Ich zittiere deine Folie:
"Sei S eine Eigenschaft, die von mindestens einer, aber nicht von allen berechnbaren Funktionen erfüllt wird."

Prof84 schrieb:

Eine wichtige Grundvoraussetzung ist allerdings, das sich alle Eigenschaftselemente untereinander nicht beeinflussen.

Beispiel zur Illustration:
"Das System soll schadstoffarm sein!"
Beziehung: Environment <-> System (NFR)
Ist nicht berechenbar nach Rice.

Nun definieren wir schadstoffarm:
"Schadstoffarm bedeutet unter 10 ppm!"
Beziehung: System (Messung) <-> System (Programmierung) (FR)
Wenn die Systemberechnung nur FR's befriedigt, ist das System berechenbar und vor allem testbar.

Wie oben angedeutet, war deine Aussage nur unvollständig!
Never mind!

Prof84

Andreas XXL schrieb:

@Prof84
Diese Aussage von dir ist (leider) absolut falsch.
Selbst das Problem, ob ein Programm auch nur anhält ist nicht berechenbar.
Da nützten dir auch funktionale Anforderungen absolut nichts.

Selbt wenn du ein Programm gegeben hast, welches als Anforderung nur f(2) = 7
bei Eingabe n Element N hat, kann kein Computer berechnen ob das stimmt.

Natürlich kann er das programm starten und auf die Ausgabe von der Eingabe 2 warten. was passiert aber wenn das programm nicht anhält. Wie oben beschrieben kann der Computer aber nicht feststellen, das das gegebene programm nicht anhält. Also bleibt nicht anderes überig als nach einer gewissen zeit abzubrechen und zu sagen das das Programm nict das gewünschte berechnet. Aber es könnte ja sein das das Programm aus der 2 die 7 gaaaaanz aufwendig berechnet und das Programm eine Sekunde nachdem man es abgebrochen hat das richtige ergebnis berechnet hätte.

Sorry, Du hast nur nicht verstanden wovon ich rede:

Du hast bereits eine feste Verbindung von Problem-Domain (Eigenschaft) <-> Konzept <-> Solution-Domain im Induktionsansatz. Dieses Mapping wird aus der Repositry zu generischen Programmierung unter Zuhilfenahme von bestimmten Konzepten wiederverwendet (FR's). Ist simple AOM(P).

http://de.wikipedia.org/wiki/AOP

Vielleicht hilft Dir dieser Link worauf ich hinaus will:
http://www.swen.uwaterloo.ca/~kczarnec/ECE750T9F04/Lecture3_FeatureModeling1up.pdf
http://selab.postech.ac.kr/publication/2002_Concepts and Guidelines of Feature Modeling for Product Line Software Engineering.pdf

Btw:
Bei Boing befindet sich ein Riesenposter einer Hummel.
Untertitel übersetzt: " Unsere Ingenieure haben errechnet, dass diese Hummel nicht fliegen kann!"

Hallo!

Ich meine, daß es schon MÖGLICH ist, sich Programme nach gegebenen
Spezifikationen selbst entwickeln zu lassen.

Schließlich sind C++ Programme nur Zeichenketten. Man läßt also einen
Computer alle Zeichenketten in aufsteigender Länge hintereinander aufzählen, schickt die Zeichenkette
durch einen C++ Compilter und startet das Compilat. In den meisten Fällen wird
gar kein Compilat entstehet, da die meisten Zeichenketten keine syntaktisch
einwandfreien C++ Programme sind. In den Fällen, wo ein Compilat entsteht,
startet man dies und läßt (ebenfalls von einem Computer) prüfen, ob die
endlich vielen Spezifikationen in Form von input/output-Paaren erfüllt sind.

Falls nein: nächste Zeichenkette prüfen.
Falls ja: Fertig. C++ Programm releasen.

Theoretisch ist das also möglich,
praktikabel ist es nicht. Denn:
1. Falls es zur Spezifikation gat kein Programm gibt, zählt man unendlich
lange weitere Zeichenketten auf, ohne zu wissen, wann Schluß ist
2. Selbst wenn man sich auf Zeichenketten der Länge 30 beschränkt
(das reicht gerade für #include<iostream> int main(){. ....}),
zählt man länger als das Universum existiert.

Theoretisch ist es also möglich. Der praktische Nutzen ist aber etwa so
hoch wie der des Versuchs, Fermats letzten Satz zu wiserlegen, indem man
alle möglichen Zahlentripel aufzählt und hofft, ein Gegenbeispiel zu finden.

Grüße

Mindphreaker

Das ist ein ziemlich interessanter Ansatz!
Denn im Moment ist das Einzige, was diese Methode zum scheitern verurteilt, die Rechenkraft der CPU. Allerdings schreitet auch die Quantentechnologie langsahm voran und wer weiß, was die Zukunft bringt.

Ich denke daher, dass diese Methode in Zukunft sogar sehr effektiv sein könnte.

P.s.

Prof84 schrieb:

- Innovation is an illusion of human! In fact, it's just an unknown combination of things those already exist! /me

-In Wirklichkeit ist es eine unbekannte Kombination von Dingen welche bereits existieren.

Unbekannt? Ich würde sagen: Teils, Teils.
Viele Kombinationen, oder Vorgänge sind zwar ungewollt in Gang gesetzt aber nicht alle.

Aber lassen wir das unbekannt einfach mal ausser Acht.

"-In Wirklichkeit ist es eine Kombination von Dingen welche bereits existieren."

Gut erkannt, aber deswegen ist es noch lange keine Illusion?

P.p.s. Entschuldigung, dass ich deine Weisheit so zerfetzt hab.

Jester

Prof84 schrieb:

MisterX schrieb:

Folie 13
http://ls2-www.cs.uni-dortmund.de/~droste/GTI06/Inhalt/060518.pdf

Na also! Da sind wir doch d' accord! Ich zittiere deine Folie:
"Sei S eine Eigenschaft, die von mindestens einer, aber nicht von allen berechnbaren Funktionen erfüllt wird."

Ich sehe nicht, was das ändern soll? Klar ist die Voraussetzung wichtig, sonst wäre die Entscheidungsfunktion ja die konstante 0 oder die konstante 1-Funktion, die ist in jedem Fall berechenbar. Im allgemeinen werden Deine Anforderungen aber wohl (hoffentlich) von mindestens einer berechenbaren Funktion erfüllt (sonst ist das Projekt nicht realisierbar) und auch nicht von allen erfüllt (sonst wäre die Anforderung trivial).

Hobbyprogrammierer schrieb:

Hallo!

Ich meine, daß es schon MÖGLICH ist, sich Programme nach gegebenen
Spezifikationen selbst entwickeln zu lassen.

Schließlich sind C++ Programme nur Zeichenketten. Man läßt also einen
Computer alle Zeichenketten in aufsteigender Länge hintereinander aufzählen, schickt die Zeichenkette
durch einen C++ Compilter und startet das Compilat. In den meisten Fällen wird
gar kein Compilat entstehet, da die meisten Zeichenketten keine syntaktisch
einwandfreien C++ Programme sind. In den Fällen, wo ein Compilat entsteht,
startet man dies und läßt (ebenfalls von einem Computer) prüfen, ob die
endlich vielen Spezifikationen in Form von input/output-Paaren erfüllt sind.

Falls nein: nächste Zeichenkette prüfen.
Falls ja: Fertig. C++ Programm releasen.

Theoretisch ist das also möglich,
praktikabel ist es nicht. Denn:
1. Falls es zur Spezifikation gat kein Programm gibt, zählt man unendlich
lange weitere Zeichenketten auf, ohne zu wissen, wann Schluß ist
2. Selbst wenn man sich auf Zeichenketten der Länge 30 beschränkt
(das reicht gerade für #include<iostream> int main(){. ....}),
zählt man länger als das Universum existiert.

Theoretisch ist es also möglich. Der praktische Nutzen ist aber etwa so
hoch wie der des Versuchs, Fermats letzten Satz zu wiserlegen, indem man
alle möglichen Zahlentripel aufzählt und hofft, ein Gegenbeispiel zu finden.

Grüße

Ein Problem (hier Programm selbst erzeugen) welches nur mit Algorithmen gelöst werden können, die bei bestimmten Eingaben zwangsläufig in einer Unendlichschleife landen nennt man laut Definition:
NICHT BERECHENBAR.

Und wenn der Fehler nur einseitig ist nennt man diese rekursiv aufzählbar.
(auch rekursiv aufzählbare Probleme sind NICHT BERECHENBAR)

(Berechnenbar ist ein Problem, wenn ein Programm existiert, dass für ALLE mögliches Eingaben nach ENDLICH vielen Schritten das eindeutige, richtige Ergebnis berechnet hat)

Demnach ist das Automatische erzeugen eines Programms für das man die Spezifikationen angibt NICHT BERECHENBAR, denn wie du schon bemerkt hast wird es bei Spezifikationen, die nicht erfüllbar sind zwangsläufig zu einer Unendlichschleife kommen.

Andreas XXL

Jester schrieb:

Prof84 schrieb:

MisterX schrieb:

Folie 13
http://ls2-www.cs.uni-dortmund.de/~droste/GTI06/Inhalt/060518.pdf

Na also! Da sind wir doch d' accord! Ich zittiere deine Folie:
"Sei S eine Eigenschaft, die von mindestens einer, aber nicht von allen berechnbaren Funktionen erfüllt wird."

Ich sehe nicht, was das ändern soll? Klar ist die Voraussetzung wichtig, sonst wäre die Entscheidungsfunktion ja die konstante 0 oder die konstante 1-Funktion, die ist in jedem Fall berechenbar. Im allgemeinen werden Deine Anforderungen aber wohl (hoffentlich) von mindestens einer berechenbaren Funktion erfüllt (sonst ist das Projekt nicht realisierbar) und auch nicht von allen erfüllt (sonst wäre die Anforderung trivial).

Genau richtig!

Also zum Beispiel ist schon die Spezifikation " Ein Programm berechnet bei Eingabe X als Ausgabe f(x)=x^2 " nicht berechenbar.

"Sei S eine Eigenschaft, die von mindestens einer, aber nicht von allen berechnbaren Funktionen erfüllt wird."
Also gut:

Es gibt ein Programm welches f(x)=x^2 berechnet. Beweis:

#include <Iostream>
using namespace std;
int main()
{
   int x;
   cin >> x;
   x=x*x;
   cout << x;

   return 1;
}

Und diese Anforderung wird nicht von allen Programmen erfüllt, denn es gibt Programme, die nicht f(x) = x^2 berechnen. Beweiß:

#include <Iostream>
using namespace std;
int main()
{
   cout << "Hallo World!";

   return 1;
}

Also kann laut dem bewiesenen Satz von Rice kein Computer berechnen, ob ein gegebenes Programm f(x) = x^2 berechnet.

Und diese Anforderung war ja nun wirklich nicht schwierig. Aber trivial war sie eben nicht. Wenn man das also schon für so einfache Probleme nicht berechnen kann, kannst du dir bestimmt vorstellen, das es für kompliziertere nicht triviale Anforderungen erst recht nicht geht.

Jester

Da ziehst Du imho nen falschen Schluß. Die Zugehörigkeit ist zwar allgemein unentscheidbar. Das bedeutet aber nicht, daß man nicht doch für einzelne Probleme das sehr wohl entscheiden kann.

Andreas XXL schrieb:

Der Computer kann aber nicht erkennen, das es sich bei der Eingabe um eine nicht berechenbare Funktion handelt.

Warum nicht? D.h., bessere frage: Warum kannst DU das, und ein Computer nicht?

Prof84

Jester schrieb:

Prof84 schrieb:

MisterX schrieb:

Folie 13
http://ls2-www.cs.uni-dortmund.de/~droste/GTI06/Inhalt/060518.pdf

Na also! Da sind wir doch d' accord! Ich zittiere deine Folie:
"Sei S eine Eigenschaft, die von mindestens einer, aber nicht von allen berechnbaren Funktionen erfüllt wird."

Ich sehe nicht, was das ändern soll? Klar ist die Voraussetzung wichtig, sonst wäre die Entscheidungsfunktion ja die konstante 0 oder die konstante 1-Funktion, die ist in jedem Fall berechenbar. Im allgemeinen werden Deine Anforderungen aber wohl (hoffentlich) von mindestens einer berechenbaren Funktion erfüllt (sonst ist das Projekt nicht realisierbar) und auch nicht von allen erfüllt (sonst wäre die Anforderung trivial).

Joh, kannste knicken!

Ich kann immer noch nicht glauben, dass ich mir den Scheiß überhaupt durchgelesen habe ...

@Zauberlehrlinge:
Hier wird nicht groß gerechnet! Ich habe eine endliche Anzahl von Eigenschaften S(i), ein Konzept k und endliche Anzahl von Funktionen f(x) in einen abgeschlossenen System Y.

Gemäß http://de.wikipedia.org/wiki/Turingmaschine ist das eine deterministische Turing-Maschine.
Satz von Rice mit dem Beweis
http://www-i1.informatik.rwth-aachen.de/Lehre/VBuK0506/Folien/berechenbarkeit6.pdf
bezieht sich auf eine nichtdeterministische Turingmaschine.

So, jetzt will ich aus dem Hörsaal nichts mehr hören und gehe zurück auf mein Schlachtfeld:

In meinen System sind alle Abhängigkeiten der Funktionen beim System Engineering durch das Konzept bereits aufgeschlüsselt worden. Verhalten sich Eigenschaften untereinander nicht-kommulativ ist eine Eigenschaftsaggretation sogar trival. Ist dann reine komponentenbasierte Betrachtung. Verhalten sich Eigenschaften untereinander kommulativ (heiser & kälter -> bleibt das System wohl lauwarm) muss die Abhängigkeit der Funktionen über das Konzept untersucht werden. Welche Eigenschaften untereinander kommulativ sind, wird durch das Konzept bestimmt. Ich kann auch "geizig" mit "warm" in Verbindung bringen, über die Features "Zahlung" <-> "Heizkosten" <-> "Heizung" <-> "Raumtemperatur". Dann muss ich in der Problem-Domain nur noch die Use Cases oder Samples definieren - "geizig" := < 15 €/mon Heizkosten und "warm" := > 20° C Raumtemperatur. Jetzt habe ich nur noch FR's und kann alle den m Features zugehörigen n Funktionen deterministisch durchrechnen lassen, in wieweit Sie der Zielbefriedigung genügen, eine Taxonomie erstellen und wenn Platz 1 die Schwellwerte erfüllt Code generieren lassen => IP. Und wie das funktioniert, kann Euch jeder der vielen Tausend Mathlab/Simulink Entwickler bestens erklären, zum Bleistift bei der sogenannten Kalibrierung.

http://www.mathworks.ch/products/product_listing/index.html

Hat bei mir einfach nur super funktioniert! ... Tipps!

Generative Programming | ISBN: 0201309777 Software Factories | ISBN: 0471202843 Modellgetriebene Softwareentwicklung | ISBN: 3898643107

Hallo!

@MisterX:

Was du über die Bedeutung von rek.aufz. und ber.bar schreibst, dem kann ich zustimmen. Nur Deiner Schlußfolgerung nicht:

Demnach ist das Automatische erzeugen eines Programms für das man die Spezifikationen angibt NICHT BERECHENBAR,<<

Nein. Ich schrieb, daß die Spezifikation in Form ENDLICH vieler Input/Output-Paare
gegeben sei, und das kann man bei gegebenem Algorithmus eben doch rekursiv
überprüfen (Univ.Turing-Masch.).
Das Halteproblem ist nicht mit endlich vielen I/O-Paaren spezifizierbar,
wird also von meiner Behauptung nicht betroffen.

denn wie du schon bemerkt hast wird es bei Spezifikationen, die nicht erfüllbar sind zwangsläufig zu einer Unendlichschleife kommen.<<

Spezifikationen in Form endlich vieler I/O-Paare sind immer erfüllbar.

Übrigens: Mein Argument enthält eine undeutliche Stelle, die liegt aber
woanders: Man kann die Algorithmen nicht *nacheinander* prüfen, da man
ja auf eine Endlosschleife while(1){;} stoßen könnte. Aber dafür gibt es
eine einfache Lösung: Man simuliert die Algorithmen nicht nacheinander,
sondern "interleaved" bei aufsteigender Größe der Programmlänge: Schritt 1 vom 1. Algo der Länge 1, dann Schritt 1 vom 2. Algo der
Länge 1,....,SChritt 1 vom letzten Algo der Länge 1, usw... wobei man dabei
eine Methode zur Aufzählung von Tupeln natürlicher Zahlen verwendet
(Codierung von NxN in N).

Grüße

Nachtrag:

Spezifikationen in Form endlich vieler I/O-Paare sind immer erfüllbar.<<

...sofern nicht demselben I-Wert verschiedene O-Werte zugeordnet sind
(Widerspruchsfreiheit).