mich würde mal interessieren, wie Ihr Strukturierte / Objektorientierte Systeme übersichtilich und einfach modelliert. Momentan benutze ich die Software Inovator von MID. Besonderst toll finde ich die darstellung im Kontexdiagramm. Der UML Ersatz Use Cases finde ich dagegen für eine Sprache wie C++, in der in der Realität nicht alles nach dem OOP Prinzip arbeitet wenig passend.

Wer kann mal von seinen Erfahrungen (GNU tools... ) berichten ?

Das macht man im Kopf und mit Intuition und Feeling.

so ein Geschwätz...

@TactX:
Du hast Recht, das für die Kreativität der griff vom Bleistift aufs Papier am besten sein mag, nur bei Projekten mit mehreren Entwicklern ist es schon sinnvoll sich auf einer Dokumentationsnorm (ISO 9000) zu einigen. Wo der Bleistift versagt.
Mag auch sein das das bei einem 200 Zeilen Projekt noch gut geht aber ab 2 Mann hat man da schon ein Probelm

1. SW Requirements Engineering (Anforderungsanalyse, Requirements Development) := Modellierung Software Analyse = Software Konzeption

Jup und mit welchen Tools ist????

2. Innovator ist kein GNU Tool

hat auch niemand gesagt

3. Use Cases auch in UML beschreiben generell keine zwingenden OO-Zusammenhänge.

macht nur wenig sinn "extends" Kreise in eine SA einzubeziehen...

4. Wer nutzt schon GNU Tools für UML?

Mozilla beispielsweise
http://www.visual-paradigm.com/

Hallo Programmierfreunde,

mich würde mal interessieren, wie Ihr Strukturierte / Objektorientierte Systeme übersichtilich und einfach modelliert. [..]

Dia!
Benutze ich für alles was man modellieren kann. Windowsversion gibts hier: http://dia-installer.sf.net

Klar für den Klassenaufbau scheint mir UML sinnvoll, bei den Systemanalysen allerdings find ich die modelierung seitens UML sehr schwach...

Das macht man im Kopf und mit Intuition und Feeling.

so ein Geschwätz...

Nö, was ich im Kopf mache, kannst du nie so schnell mit Papier und Bleistift und mit einem Tool schon garnicht machen, weil ich da viel flexiebler bin und nicht irgendwie sortieren muss um alles auf ein Blatt zu bekommen.

whiteboards ? Geld...

... ab 7 Euro.

Du wirst, so wie ich dich einschätze, dein Quelltext durchstepen und dir dort ein richtigen Balkon hinbetonieren, der die neue Anforderung "irgendwie" Tragen soll. Ich hab nichts dagegen wenn man das als Hobbycoder so macht und nicht merkt, das jeder Tag mächtig $ kostet. Nur Professionell ist das nicht.

Nehmen wir auch mal an das du "irgendwann" die Vorzüge des V Modells genießen möchtest, deine Programme Automatisch Testen willst, oder gar ein HIL Modell (Hardware in the Loop) aufbauen möchtest. Spätestens dann stehst du ohne voher festgelegte Methodenverträge ganz dumm da.

Bis dato habe ich schon das neue Projekt verwirklicht.

Der Bleistift und das Papier sind sicherlicht ganz am anfang hilfreich nicht aber für die eigendliche Dokus ...

mag sein das du anfangs noch schneller bist als ich aber wenn wir uns in einem halben Jahr über Änderungen unterhalten zie ich meine .mid Datei raus, such mein änderungspunkt und implementiere. Ich muss auch nicht meine Kollege 2 wochen lang Brefen wie es damals in meinem Kopf ausgesehen hat...

Du wirst, so wie ich dich einschätze, dein Quelltext durchstepen und dir dort ein richtigen Balkon hinbetonieren, der die neue Anforderung "irgendwie" Tragen soll. Ich hab nichts dagegen wenn man das als Hobbycoder so macht und nicht merkt, das jeder Tag mächtig $ kostet. Nur Professionell ist das nicht.

Also wenn ich in meim Programm was ändere, dann kann ich mich schon erinnern wo was ist, hab ein ganz gutes Gedächtnis. Wenn man eine Doku für andere braucht, dann kann man ja irgend ein Diagramm erstellen, obwohl ich nicht wirklich viel davon halte. Diese Diagramme sind auch nur dann gut, wenn die Klassen und Methodennamen gut sind oder wenn viel Text dabei steht der das ganze erklär, aber den kann man auf in den Code schreiben. Außerdem haben diese Dokus auch den nachteil, dass sie falsch sein können. Wenn nachträglich was geändert wird, dann wird das Diagramm oft nicht mit geändert, oder die Doku wurde von einem anderen geschrieben, der nicht dne Code geschrieben hat und dann kann es schon mal passieren, dass in der Doku was steht, was nicht im Code zu finden ist. Wenn ich dagegen den Code lesen, dann macht das Programm auch das was da steht. Und ob die Änderung aufwendig ist oder nicht, liegt nicht an der Doku, sondern daran ob das Programm dafür vorgesehen war.

Nehmen wir auch mal an das du "irgendwann" die Vorzüge des V Modells genießen möchtest, deine Programme Automatisch Testen willst, oder gar ein HIL Modell (Hardware in the Loop) aufbauen möchtest. Spätestens dann stehst du ohne voher festgelegte Methodenverträge ganz dumm da.

Ich hab nicht gesagt, dass ich keine Schnittstellen (das sollen wohl Methodenverträge sein, bei google nur 3 treffer) zwischen den einzelen Komponenten definiere, die braucht man wenn andere meine Komponenten verwenden, aber intern brauch ich kein UML Diagramm zum Entwickeln.

DieGuten schrieb:

Wenn nachträglich was geändert wird, dann wird das Diagramm oft nicht mit geändert, oder die Doku wurde von einem anderen geschrieben, der nicht dne Code geschrieben hat und dann kann es schon mal passieren, dass in der Doku was steht, was nicht im Code zu finden ist.

Offenbar hast Du nie mit etwaigen CASE-Tools gearbeitet. Die erzeugen dir UML Diagramme bei Bedarf automatisch aus dem Code...

DieGuten schrieb:

Schnittstellen (das sollen wohl Methodenverträge sein, bei google nur 3 treffer)

Durch den Satz erübrigt sich wohl alles weitere.

Möchte gerne sehen, wie Du ab 100k LOCs und 100 Klassen nach 6+ Monaten immernoch den Überblick über jeden Teil des Codes hast.

LOCs???? Ist LOC nicht schon die Mehrzahl? Und warum so wenig? Ob ich nun in nem UML diagram nach irgenwelchenKlassen suche oder im Code macht bei vernünftigen Namen nicht viel unterschied. Was soll den so schwer daran sein Code zu lesen?

DieGuten schrieb:

Wenn nachträglich was geändert wird, dann wird das Diagramm oft nicht mit geändert, oder die Doku wurde von einem anderen geschrieben, der nicht dne Code geschrieben hat und dann kann es schon mal passieren, dass in der Doku was steht, was nicht im Code zu finden ist.

Offenbar hast Du nie mit etwaigen CASE-Tools gearbeitet. Die erzeugen dir UML Diagramme bei Bedarf automatisch aus dem Code...

Na warum soll ich die dann vorher erstellen? Wenn einer den Kram braucht, dann kann er sichs ja erstellen lassen.

DieGuten schrieb:

Schnittstellen (das sollen wohl Methodenverträge sein, bei google nur 3 treffer)

Durch den Satz erübrigt sich wohl alles weitere.

Warum findet man denn so wenig darüber?

Mal sehen was in 10 oder 20 Jahren aus den UML Diagrammen geworden ist. Wahrscheinlich sind sie dann so gefragt wie Struktorgramme jetzt. Aber bis dahin habt ihr ja schon wieder alles vergessen, wenn ihr so ein schlechtes Gedächtnis habt.

Im Übrigen:

Google: "Ergebnisse 1 - 10 von ungefähr 19.400.000 für schnittstelle"

Und damit Du nicht dumm sterben musst:

http://de.wikipedia.org/wiki/Schnittstelle_(objektorientierte_Programmierung)

Da Dir die zentralen Aspekte der OOP offenbar unbekannt sind, brauchen wir an dieser Stelle auch nicht weiter zu diskutieren.

LOL, jetzt hast du schon vergessen, was ich vor 3 Postings geschrieben hab. Hätt ich mal besser Kästchen drum gemalt.

Im Übrigen:

Google: "Ergebnisse 1 - 10 von ungefähr 19.400.000 für schnittstelle"

http://www.google.de/search?hl=de&q=Methodenvertrag&btnG=Google-Suche&meta=
Du Idiot
Kauf dir Hirn.

Du Idiot
Kauf dir Hirn.

Wenn Dir wieder Argumente einfallen und/oder Du die Pubertät hinter Dir gelassen hast, können wir dann gerne weiterdiskutieren.

Wenn Dir wieder Argumente einfallen und/oder Du die Pubertät hinter Dir gelassen hast, können wir dann gerne weiterdiskutieren.

Sorry, aber du bis entweder zu dumm oder zu vergeßlich, wenn du nicht verstanden oder schon wieder vergessen hast, worum es bei dem 3 Google Treffern ging.

LOLZ³ schrieb:

Da Dir die zentralen Aspekte der OOP offenbar unbekannt sind, brauchen wir an dieser Stelle auch nicht weiter zu diskutieren.

Und der dem die Argumente ausgehen bis du, wenn du einfach etwas daher lügst. Schau dir dazu einfach mal die letzten Postings an, dann sieht man ab wann die Argumente Fehlen. Musst du halt nochmal lesen, da du anscheinend schon wieder alles vergessen hast.

wir können uns doch normal unterhalten...

Mag sein das Methodenverträge ein "sehr Deutsches" Wort ist und selten benutzt wird, jedoch kann mann dadurch deutlich machen das hierbei Methoden beteiligt sind, und nicht wie bei Schnittstellen offen ist ob IO`s zu den Terminatoren (Ausgangsseite, Anwender) gemeint oder gar Fünktionsübergabewerte. Andererseits wage ich es wie LOLZ³ sehr zu bezweifeln, das ein größeres Programm mit reinen Quelltextkommentaren auskommt. Bei der Firma IBM Böblingen ist es ein Grund zur Abmahnung Programme ohne Doku zu verfassen (ISO 9000) und das hat schon sein Grund. Falls du immernoch der Meinung bist, jedes Programm über den Quelltext analysieren zu können hier mal 25 Zeilen für dich.

#include <list>
#include <vector>
using namespace std;
list< vector<int> > perm(const vector<int> &v)
{
list< vector<int> > l;
if (v.size() == 1)
{
l.push_back(v);
}
else
for (int i=0; i<v.size(); i++)
{
vector<int> vi(v);
vi.erase(vi.begin()+i);
list< vector<int> > li = perm(vi);
list< vector<int> >::iterator j;
for (j = li.begin(); j != li.end(); j++)
(*j).push_back(v[i]);
l.merge(li);
}
return l;
}
void calc(const vector<int> &v)
{
...
}
void main()
{
vector<int> v(3);
v[0] = 1; v[1] = 2; v[2] = 3;
list< vector<int> > &l = perm(v);
list< vector<int> >::iterator i;
for (i = l.begin(); i != l.end(); i++)
calc(*i);
}

Da das das Programm nun auf ein Motorsteuergerät übergespielt werden soll, möchte dein Boss nun die Zeitkomplexität wissen, die der letzte Mitarbeiter leider nicht Dokumentiert hat.

@LOLZ³ Welche Tools würdest du empfehlen (Diplomarbeit) auser Together und Rose PREIS!!!

Da weist du jetzt warum ich Methodenverträge sage....

Im Ernst: Die richtigen Tools sind ja schon praktisch und helfen. Aber dieser Quelltext ist qualitativ auch ziemlich übel.