Modelierung Software Analyse

Hallo Programmierfreunde,

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 ?

Ich benutze Bleistift und Papier um Abläufe, Strukturen usw. zu "modellieren". Ich finde da kann ich am besten nachdenken, habe die besten Ideen. Ohne solche Tools je benutzt zu haben bin ich mir ziemlich sicher, dass sie meine Kreativität stören würden. Nachteilig ist, dass man "Zeichnungen" auf Papier schlecht zu Dokumentationszwecken verwenden kann. Da nehm ich dann Visio wenn die Struktur fix ist...

Das macht man im Kopf und mit Intuition und Feeling.

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

SW Requirements Engineering (Anforderungsanalyse, Requirements Development) := Modellierung Software Analyse = Software Konzeption
Innovator ist kein GNU Tool
Use Cases auch in UML beschreiben generell keine zwingenden OO-Zusammenhänge.
Wer nutzt schon GNU Tools für UML?

zu Punkt 1:

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

Jup und mit welchen Tools ist????

Innovator ist kein GNU Tool

hat auch niemand gesagt

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

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

Wer nutzt schon GNU Tools für UML?

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

Headhunter

fischly schrieb:

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

nep

Ich benutze auch Bleistift und Papier...und erst dann mach ich das am Computer (mit ArgoUML), falls ich es weitergeben muss.
Bzw. manchmal gehe ich sogar den umgekehrten Weg, dass ich erst ein paar Interfaces/Klassen als Programmcode schreibe und dann schaue wie die zusammenpassen, und dann modelliere ich das erst als UML

wer braucht denn bleistift und papier, wenn es whiteboards gibt?

whiteboards ? Geld...

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

fischly schrieb:

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.

fischly schrieb:

whiteboards ? Geld...

... ab 7 Euro.

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.

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 ...

nep

Klar, Bleistift und Papier macht man ja auch eher für sich selbst.
Wenn ich das dann "richtig" haben will, z.B. eben auch zu Dokuzwecken, dann modelliere ich das auch in so nem Tool

und welche modelierungsart für die SW Analyse setzt Ihr jetzt nun ein ????

fischly schrieb:

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.

Möchte gerne sehen, wie Du ab 100k LOCs und 100 Klassen nach 6+ Monaten immernoch den Überblick über jeden Teil des Codes hast. Deine Teamkollegen sind sicherlich auch ganz heiß drauf, in Meetings zu durchwühlen, um den Überblick zu bekommen.

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.

LOLZ³ schrieb:

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.

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

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)

LOLZ³ schrieb:

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.

DieGuten schrieb:

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.