eine klasse Messdaten möchte Daten an die Klasse Diagramm senden.

Wie würden die Klassen ausschauen, welche Methoden haben sie ?

class Diagramm
{

private:

Messdaten* ptr;

}

class Messdaten
{

private:

int messungen[10];
}

Im Ernst: Was willst du hören?

du wolltest bestimmt folgendes oder.

struct Diagramm 
{ 
    void doIt() { Messdaten d; d.gimmeDaData(ptr); } 

private: 
    Messdaten* ptr; 
}; 

struct Messdaten 
{ 
    void gimmeDaData(Messdaten*); 

private: 
    int messungen[10]; 
};

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

Nach dem Schema (ungetestet):

class MeasuringData;

class MeasuringDataListener{
public:
	virtual ~MeasuringDataListener(){}
	virtual void measuringDataChanged(const MeasuringData&, int pos, double value) = 0;

};

class MeasuringData{

public:
	void setData(int pos, double value){
		for(std::vector<MeasuringDataListener>::const_iterator = listeners.begin(); it!=listeners.end(); ++it){
			(*it)->measuringDataChanged(*this, poa, value);
		}
	}

	void addListener(MeasunringDataListener& listener){
		listeners.push_back(&listsner);
	}

private:
	std::vector<MeasuringDataListener*> listeners;
};

class Diagramm : public MeasuringDataListener{
public:
	Diagramm(MeasuringData& data){
		data.addListener(*this);
	}

	virtual void measuringDataChanged(const MeasuringData&, int pos, double value){
		// update diagramm
	}

}

EDIT: Naja... Man sollte den Listener spätestens im Destruktor wieder entfernen... (zusätzliches Feld auf MeasuringData notwendig)

noch eine Frage.

Was ist design by contract.

Zwischen wem wird hier ein Vertrag geschlossen ?
Den Entwicklern ? Den Klassen ?

Grob gesagt:
Pre/Postconditions und Invarianten genau definieren.

Was das mit einem Vertrag zu tun hat: Als Benutzer einer Schnittstelle ist man verpflichtet die Precondition einzuhalten und kriegt dafür die Postcondition garantiert.

Noch eine fRage zum unified process.
ER wird doch in Unternehmen heutzutage verwendet. Da der Wasserfall bei großen
Projekten zu statisch ist. Es muss ja jede Phase abgeschlossen sein.

Was bedeuten diese humps also Hügel im Diagramm. Was bedeutet die Y-Achse
also z.B. IMplementation , test, deploment. DAs hab ich doch in der Phase
inception gar nicht dort werden doch erst nur die Anforderungen erarbeitet.

Soll das heissen man prüft falsche Eingaben nicht und verlässt sich
auf den Benutzer ?

Ganz einfach:
Wenn du deine Bedingungen einhälst, garantiert dir dein Programm ein gewisses
Verhalten.

Dabei ist der Benutzer der Entwickler!!! Nicht der Endbenutzer!!!

Du hast eine Methode, die dir alle Primzahlen bis zu einer Zahl ausgibt.

Diese verlangt von dir, dass die übergebene Zahl größer als 0 ist.

Wenn der Entwickler jetzt eine Zahl dafür von der Tastatur einliest, muss
er vorher selber checken, damit die Bedingung erfüllt ist.

Falls die Logik des Programm es allerdings verbietet, dass diese Zahl
(sie kommt jetzt woanders her) <= 0 ist, dann braucht er sich um nichts zu kümmern.

my_function (in: INTEGER) : INTEGER
 local                              -- lokale Variablen definieren
   temp: INTEGER
 require                            -- hier fängt der Block mit Preconditions an
   in_greater_zero: in >= 0         -- in muss grösser 0 sein, ansonsten gibts einen Runtime Fehler, wo das Tag 'in_greater_zero' angezeigt wird
 do
   -- do some stuff
   Result := temp                   -- Result enthält den Rückgabewert
 ensure                             -- Block mit Postconditions
   greater_10: Result > 10          -- Rückgabewert muss Grösser 10 sein, ansonsten wieder Runtime Fehler.
 end

Der Vertrag (Contract) kommt hier zwischen dem Anwender der Funktion und dem Programmierer der Funktion zustande. Wenn der Anwender einen Integer Grösser/Gleich 0 übergibt, dann kann er sich darauf verlassen, dass die Funktion korrekt funktioniert und der Rückgabewert Grösser 0 ist.

Eiffel ermöglicht es 1:1 solche Contracts in Code abzubilden, was auch kein Wunder ist, denn der Entwickler von "Contract by Design" ist auch der Gründer dieser Sprache.

Was bedeuten diese humps also Hügel im Diagramm. Was bedeutet die Y-Achse
also z.B. IMplementation , test, deploment. DAs hab ich doch in der Phase
inception gar nicht dort werden doch erst nur die Anforderungen erarbeitet.

drakon schrieb:

ensure                             -- Block mit Postconditions
   greater_10: Result > 10          -- Rückgabewert muss Grösser 10 sein, ansonsten wieder Runtime Fehler.

Als zusätzliche Anmerkung an blurry333:
wobei in C++ Runtime-Fehler i.d.R. != Exception...
Wird in Eiffel ne Exception geworfen? (Ich hab 0 Plan von Eiffel)
Nicht Erfüllen der Preconditions kann z. B.

• falsches Ergebnis
• Endlosschleife
• undefiniertes Verhalten (z. B. Programmabsturz)

zur Folge haben.

Ein verletzen einer Condition hat einen Laufzeitfehler zur Folge (ausser mal stellt die naütrlich aus), wie bei C/C++ Programmen assertions (also mit assert ).

Wenn die Conditions aber ausgeschaltet sind (das kann man sehr selektiv machen mit EiffelStudio), dann tauchen natürlich die genannten Sachen auf.