case-tools
Sven Bauhan
Hi Programmierer,
ich habe bisher meine Programme immer sehr stark "zusammengehackt". Da man
aber mit größer werdenden Software-Projekten immer leichter den Überblick
verlieren kann, hatte ich mich schon mal auf die Suche nach Tools begeben.
Mein erster Ansatz war UML. Dies ist aber auf spezielle Anwendungen
zugeschnitten und eignet sich meist nur für Java. Ausserdem ist die
Verbindung zwischen den Diagrammen untereinander und dem Code nicht sehr
gut.
Vor kurzem habe ich von case-tools gehört wie zB Innovator von mid
(http://www.mid.de/de/innovator/).
Hat jemand von Euch schon einmal mit solchen Tools gearbeitet? Wisst ihr,
welche Tools dieser Art existieren bzw. ob es eine Übersicht davon gibt?
Mfg,
Sven
Felix von Leitner
> <veröffentlicht & per Mail versendet>
Usenet-Direktion? Einmal Merkbefreiung bitte!
Mit besonderer Würdigung der Zeilenlänge. In dreifacher Ausfertigung.
Danke.
> Hat jemand von Euch schon einmal mit solchen Tools gearbeitet? Wisst ihr,
> welche Tools dieser Art existieren bzw. ob es eine Übersicht davon gibt?
Niemand hat je mit case-Tools "gearbeitet". Denn mit case-Tools
arbeitet man nicht. Mit case-Tools fummelt man schlecht laufende
Monster-Bloat-Demos zusammen, die man danach wegschmeißt und neu macht.
Felix
--
A commune is where people join together to share their lack of wealth.
--R. Stallman
Klaus von der Heyde
>
> Niemand hat je mit case-Tools "gearbeitet". Denn mit case-Tools
> arbeitet man nicht. Mit case-Tools fummelt man schlecht laufende
> Monster-Bloat-Demos zusammen, die man danach wegschmeißt und neu macht.
Es kann, richtig eingesetzt, das management bei laune halten ;)
Klaus
--
Klaus von der Heyde -- he...@informatik.uni-bonn.de
Peter Simons
> Hat jemand von Euch schon einmal mit solchen Tools gearbeitet?
Ich habe einmal in einem relativ großen kommerziellen Projekt
"Rational Rose" mit viel Begeisterung verwendet, welches allgemein als
eines der besten solcher Tools erachtet wird. Mein Fazit dazu, welches
ich auf CASE-Tools allgemein ausweiten zu können glaube, ist, daß ich
nie wieder derartig geile Diagramme für technische Dokumentation,
Prospekte, Meetings und Präsentationen hatte. Für das Design der
Software hat es mir effektiv jedoch keinen Vorteil gebracht, es hat
mir (und dem Team) nicht beim Implementieren der Software geholfen,
und es hat definitiv mir keine Zeit gespart.
Insofern denke ich, daß CASE-Tools durchaus ihre Berechtigung haben,
jedoch nicht unbedingt beim Designen von Software, sondern vielmehr
beim Visualisieren eines Softwaredesigns. Ich würde an Deiner Stelle
also nicht allzuviel Zeit auf sowas verwenden. Ein gutes
"Zeichenprogramm" wie "dia" <http://www.lysator.liu.se/~alla/dia/>
leistet IMHO dasselbe und kostet -- im Gegensatz zu "Rational Rose" --
keinen Pfennig. Das beste Werkzeug zum Designen von Software ist dann
letztendlich noch der Kopf, kombiniert und Stift und Papier.
-peter
Felix von Leitner
> > Hat jemand von Euch schon einmal mit solchen Tools gearbeitet?
> Ich habe einmal in einem relativ großen kommerziellen Projekt
> "Rational Rose" mit viel Begeisterung verwendet, welches allgemein als
> eines der besten solcher Tools erachtet wird.
ROTFL, Rational Rose stinkt ja so derartig eklig, das ist echt schon
wieder lustig. Mich hat mal jemand überzeugen wollen. Er meinte: "hey,
ich lad hier mal eben dein Suchmaschinen-Projekt rein, und dann kenne ich
deinen Code im Nu besser als du selber!". Er lud den Code rein,
Rational layoutete das ganze dann auf 20000 x 30000 Pixel, und wenn man
das so zoomte, daß das auf 1600x1200 paßte, konnte man genau gar nichts
mehr erkennen.
Kurz gesagt: das _kann_ gar nichts taugen. Diese ganze _Klasse_ von
Software kann nichts taugen. Kaum überschreitet ein Projekt die
Trivialitätsgrenze von der Größe her, ist einem diese Art Tool sofort
mehr im Weg als es nützt.
Ab in die Tonne damit.
> Mein Fazit dazu, welches ich auf CASE-Tools allgemein ausweiten zu
> können glaube, ist, daß ich nie wieder derartig geile Diagramme für
> technische Dokumentation, Prospekte, Meetings und Präsentationen
> hatte.
Ja, ganz toll, als Selbstzweck ist das ganz prima. Man kann damit
hervorragend unnütze Diagrammer erzeugen, mit denen kein Mensch später
wieder was anfangen kann, aber immerhin hat man prima Papier produziert.
Felix
--
Every great man has his disciples,
and it is always Judas who writes the biography.
--Oscar Wilde (1854-1900)
Peter Simons
> Ja, ganz toll, als Selbstzweck ist das ganz prima.
Eine gute Visualisierung einer Software-Architektur zu haben, ist
solange Selbstzweck, wie man nicht darauf angewiesen ist, daß
Nicht-Techniker eine Vorstellung davon zu haben meinen, sie
verstünden, was man da treibt. Es ist nunmal eine Tatsache, daß
der Entwickler, der seinem Management solches Material vorlegen
kann, auf die Dauer glücklicher sein wird, als der, der es nicht
kann.
Daß die Existenz bunter Bildchen die Qualität der entwickelten
Software positiv beeinflußt, habe ich nicht behauptet und darum
geht es in meinem Argument auch gar nicht. Solange man zum Spaß
programmiert, kann man sich das ganze auch gut sparen. Wenn man
gegen Bezahlung programmiert, ist es weise, diese Hilfsmittel im
vernünftigen Ramen zu nutzen.
-peter
Felix von Leitner
> Eine gute Visualisierung einer Software-Architektur zu haben, ist
> solange Selbstzweck, wie man nicht darauf angewiesen ist, daß
> Nicht-Techniker eine Vorstellung davon zu haben meinen, sie
> verstünden, was man da treibt. Es ist nunmal eine Tatsache, daß
> der Entwickler, der seinem Management solches Material vorlegen
> kann, auf die Dauer glücklicher sein wird, als der, der es nicht
> kann.
Was hat eine gute Visualisierung einer Software-Architektur mit Rational
Rose zu tun? Ich habe noch keine Software gesehen, die unter UML
Einfluß entstanden ist und eine elegante Architektur gehabt hätte.
Gut, das trifft auch auf die meiste Nicht-UML-verseuchte Software zu,
aber ich glaube ehrlich, daß UML und UML-Tools der natürlich Feind guter
Software sind.
Leute, die sich $FOO mit UML auskennen, kennen sich halt $FOO weniger
mit Software-Entwicklung aus. Und man kann das nicht trennen, denn wenn
der Software-Ingenieur das dem UML-Fritzen vermitteln kann, kann er es
auch dem Management vermitteln. So einfach ist das.
Felix
Peter Simons
> Was hat eine gute Visualisierung einer Software-Architektur mit
> Rational Rose zu tun?
Rational Rose ist _ein_ Hilfsmittel, mit dem man eine Architektur
verbildlichen kann. Genauso gut kann man das auch mit Visio, Dia, TCM,
xfig oder einer Tafel tun, aber mit Rational Rose geht es noch ein
bißchen einfacher. Ob man deswegen 'zig Kilodollar ausgeben will, ist
eine andere Frage. Ich tue es nicht.
> Leute, die sich $FOO mit UML auskennen, kennen sich halt $FOO
> weniger mit Software-Entwicklung aus.
Nunja ... Eine ähnlich klar strukturierte Meinung habe ich über den
Zusammenhang zwischen der fehlenden Differenzierungsfreudigkeit eines
Gemüts und der Schlichtheit der Wahrheiten, denen der dazugehörige
Mensch anhängt. Nur ist das Verhältnis hier IMHO nicht linear.
Gute Nacht.
Walter Mühlheim
> Kurz gesagt: das _kann_ gar nichts taugen. Diese ganze _Klasse_ von
> Software kann nichts taugen. Kaum überschreitet ein Projekt die
> Trivialitätsgrenze von der Größe her, ist einem diese Art Tool sofort
> mehr im Weg als es nützt.
Es gibt eine Software für die Telekommunikationsbranche SDT (Kostenpunkt
angeblich rund 100.000 DM pro Lizenz). Diese Software ist brauchbar, wird
benutzt, auch (oder gerade) für sehr große Projekte.
Allerdings ist das ganze eher eine visuelle Entwicklungsumgebung als ein
Case-Tool. Auch wenn es manche Dinge (z.B. grafische Darstellung von
Informationsflüssen etwa) hat, die ich eher einem Case-Tool zuschreibe.
Mfg
Rainer Weikusat
> Felix von Leitner wrote:
> > Kurz gesagt: das _kann_ gar nichts taugen. Diese ganze _Klasse_ von
> > Software kann nichts taugen. Kaum überschreitet ein Projekt die
> > Trivialitätsgrenze von der Größe her, ist einem diese Art Tool sofort
> > mehr im Weg als es nützt.
>
> Es gibt eine Software für die Telekommunikationsbranche SDT (Kostenpunkt
> angeblich rund 100.000 DM pro Lizenz). Diese Software ist brauchbar, wird
> benutzt, auch (oder gerade) für sehr große Projekte.
Sobald der Überblick über ein Programm verlorengegangen ist, ist der
weg. Finito. Falls die Struktur so abartig komplex ist, das ich einen
Computer brauche, um sie wenigstens ansatzweise zu verstehen, wird es
Zeit für einen Neuentwurf.
Oliver Bandel
Naja, dem Argument folgend, dürfte man garnichts mit
dem Computer erledigen wollen, denn *alles* was derart
komplex wird, daß man den Computer braucht, um es zu
verstehen müsste dann neu designt werden.
Also quasi alles, was einem tagtäglich begegnet.
Oder anders ausgedrückt: Wenn man wirklich derart komplexe
Dinge zusammenbaut, daß man einen Computer braucht, um's
zu verstehen, dann sollte man auch den Computer dazu nutzen,
um's zu verstehen.
Das heisst natürlich nicht, daß man deswegen Kack-Design
einestzt und alles komplizierter macht, als es sein müsste.
Aber wenn man einen bestimmten Level von Komplexität nun mal
im Gesamt-System einer Software "erschlagen" muß, dann muß
man das halt tun, wen man die Aufgabe bewältigen will.
Gutes Design und dem jeweiligen Problem gut angepasste
Sprachen (am besten halt welche, die mehrere Programmierparadigmen
unterstützen, also imperativ, funktional, OO, etc.)
helfen natürlich, Komplexitäts-Bloat zu verringern
und die Komplexität auf's wesentliche -das zu lösende problem -
zu reduzieren.
Was gute Dokumentation von Software angeht - nun, da könnte
man auch Literate programming Tools statt Case-Tools nutzen.
BTW: Speziell zum Visualisieren komplexer Programme, zum maintainen
von legacy code gibt es ein Tool, dessen name mir jetzt gerade
nicht einfällt (ich glaube Rigi oder so ähnlich bin mir aber eben nicht
sicher)... hatte 4 Buchstaben oder so... war von irgend einer Uni in USA.
Das, was da so auf der Homepage zu sehen war, war doch recht
überzeugend; hatte es aber selbst noch nicht angetestet.
Falls das jemand mal macht und damit Erfahrung sammelt,
bitte in den News hier (oder mir per Mail) mal ne Info
schicken; würde mich schon sehr interessieren.
Ciao,
Oliver
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > Walter =?ISO-8859-15?Q?M=FChlheim?= <Walter.M...@gmx.de> writes:
> >> Es gibt eine Software für die Telekommunikationsbranche SDT (Kostenpunkt
> >> angeblich rund 100.000 DM pro Lizenz). Diese Software ist brauchbar, wird
> >> benutzt, auch (oder gerade) für sehr große Projekte.
>
> > Sobald der Überblick über ein Programm verlorengegangen ist, ist der
> > weg. Finito. Falls die Struktur so abartig komplex ist, das ich einen
> > Computer brauche, um sie wenigstens ansatzweise zu verstehen, wird es
> > Zeit für einen Neuentwurf.
>
> Naja, dem Argument folgend, dürfte man garnichts mit
> dem Computer erledigen wollen, denn *alles* was derart
> komplex wird, daß man den Computer braucht, um es zu
> verstehen müsste dann neu designt werden.
Ähh ... 'Ja'. Es besteht allerdings ein Unterschied zu
'umfangreich'. Aus praktischen Gründen habe ich immer nur einen
winzigen Bruchteil des auf diesem Rechner archivierten Wissens im
Kopf, nämlich den, den ich gerade brauche, denn bei 'dem Rest' weiß
ich ja, wo ich ihn finde, wenn ich ihn brauche. Falls ich etwas
finde, das ich nicht verstehe, bleibt mir wenig übrig, als es
verstehen zu lernen und das geht m.E. immmer noch am besten mit
'durchlesen' und 'darüber nachdenken'.
'Visualisierungen' sind nützlich für Zahlen, weil die wenig
individuelle Erkennungsmerkmale haben. Ein 'Datenfluß' der ausreichend
wirr ist, daß einen graphische Darstellung ihm unbekannte
Informationen zu entnehmen hilft, deutet darauf hin, das ich keine
'saubere' Kontrollstruktur habe, denn es müssen ja offensichtlich
Rückwärts- und Seitwärtsbewegungen darin vorkommen. Ich halte die für
vermeidbar.
> Oder anders ausgedrückt: Wenn man wirklich derart komplexe
> Dinge zusammenbaut, daß man einen Computer braucht, um's
> zu verstehen, dann sollte man auch den Computer dazu nutzen,
> um's zu verstehen.
Das hilft mir erst in dem Moment, wo der Computer das vollständig von
alleine tut, denn der versteht es nicht und funktional irrelevanten
Code kann es in einem Programm nicht geben (bestenfalls nach
irgendeiner Definition von 'Bestimmungszweck' überflüssigen).
> Aber wenn man einen bestimmten Level von Komplexität nun mal
> im Gesamt-System einer Software "erschlagen" muß, dann muß
> man das halt tun, wen man die Aufgabe bewältigen will.
Das ist ein unteres Ende:
sub parse_href($)
{
my $item = shift;
my $key;
$key = (keys(%$item))[0];
for (ref($item->{$key})) {
/ARRAY/ && return map {
die("Cannot handle $_ in hash") if ref($_);
[$key, $_];
} @{$item->{$key}};
/.+/ && die("Cannot handle $_-references in hash");
}
return [$key, $item->{$key}];
}
Und das ein oberes:
#** burn
#
@names = sort(keys(%fields));
{
my $sth;
if (defined($hid)) {
$sth = $dbh->updater('hosts', [@names, { mtime => 'now()'}],
sql_where(eql('hid', $hid)));
} else {
$sth = $dbh->inserter('hosts', \@names);
}
$sth->execute(map { $fields{$_}; } @names);
$dbh->commit();
}
#** and die
#
1;
[... und ich weiß, das es da je nach DBI-Version 'unterschiedliche
Shortcuts' gibt, aber deswegen ist das nicht so besonders nützlich].
> Gutes Design und dem jeweiligen Problem gut angepasste
> Sprachen
Ich würde eine vorschlagen, in der sich alle beteiligten Menschen
untereinander verständigen können :->. Falls ich tatsächlich die Wahl
habe (dh ausschließlich, ich komme mal dazu, irgendwas für den
privaten Hausgebrauch zu schreiben) nehme ich eine, 'die mir gerade so
einfällt' und die ein erträgliches Interface zum System bietet, dh
shell, C oder Perl, die letzteren in beliebiger Reihenfolge. C++ ist
wg 'moving target' und der Unmöglichkeit, jemals sicher ergründen zu
können, was C++ eigentlich überhaupt ist, sein möchte oder werden
soll(te?), weitgehend uninteressant geworden ('stdio' ist schon
größtenteils brechreizfördernd, aber bei 'iostreams' hakt es wirklich
aus ...).
> (am besten halt welche, die mehrere Programmierparadigmen
> unterstützen, also imperativ, funktional, OO, etc.)
'Funktionales Programm' ist ein Oxymoron. Wenn es keine Seiteneffekte
hat, tut es auch nichts (außer 'einen Wert liefern'). Rekursionen sind
cool, aber meistens Unsinn, weil zu kompliziert (interessanterweise
wird der Terminus von allen möglichen Leuten synonym zu 'irgendetwas
geheimnisvolles, kompliziertes' verwendet). Sie werfen auch dieselben
dynamischen Probleme auf, weil ein rekursiver Algorithmus keine
Akkumulatormaschine mehr beschreibt, sondern eine (kastrierte)
Stackmaschine.
> BTW: Speziell zum Visualisieren komplexer Programme,
Gibt in Quellcode überflüssige Details außer Kommentaren und
whitespace? Falls ja, wie sieht sowas aus? ( a += a - a?)
Lars P. Wolschner
> <veröffentlicht & per Mail versendet>
Was soll das?
> ich habe bisher meine Programme immer sehr stark "zusammengehackt".
> Da man aber mit größer werdenden Software-Projekten immer leichter
> den Überblick verlieren kann, hatte ich mich schon mal auf die
> Suche nach Tools begeben.
Was meinst Du mit "den Überblick verlieren"? Gibt es die Probleme
schon beim Entwurf, bei der Codierung oder machen sie sich erst bei
Modifikationen bemerkbar? (Ich befürchte allerdings in allen
Situationen.)
Wenn Du bisher "nur" mit Editor, Compiler/Linker und Debugger
gearbeitet hast, käme der Einsatz eines Tools der von Dir offenbar
gesuchten Art dem Ersatz einer Feile durch eine CNC-Maschine gleich -
mit dem Unterschied, daß CNC-Maschinen wirklich Arbeit sparen und die
Fertigung beschleunigen.
Du müßtest jedenfalls viel Geld ausgeben (lassen) oder zumindestens
viel Arbeitszeit zur Einarbeitung in die zugrundeliegenden Denk-
modelle und die Bedienung des "Tools" aufwenden. In der Zeit kommst
Du mit laufenden Projekten nicht weiter. Und weil Du ja allenfalls
verschwommene Vorstellungen davon hast, was das Tool überhaupt
leisten soll/muß, ist der erfolgreiche Einsatz nicht garantiert.
Wie wäre es stattdessen mit der jederzeit beherrschbaren Methode
stetiger Weiterentwicklung? Wenn Du von fehlendem Überblick sprichst,
scheint mir doch zu allererst einmal die Einführung gewisser
Codierkonventionen angeraten, angefangen mit einer systematischen
Vergabe von Bezeichnern aller Art und einer gewissen Kommentierung
des Codes. Gleich danach solltest Du von der alten algorithmisch
geprägten zur datenstrukturorientierten Modularisierung übergehen.
Beim Entwurf des modularen Funktionsumfanges empfiehlt sich ebenfalls
die Beachtung grundlegender Regeln.
Diese Regeln solltest Du in der Literatur finden, die die Kenntnis
einer (bestimmten) Programmiersprache bereits voraussetzt. Literatur
zur Vermittlung einer Programmiersprache hilft da i.d.R. nicht
weiter.
> Mein erster Ansatz war UML. Dies ist aber auf spezielle Anwendungen
> zugeschnitten und eignet sich meist nur für Java.
AFAIR sollte UML eigentlich nicht sprachspezifisch sein. Die Lektüre
solcher Denkmodelle hilft erst ab einer gewissen Dosis und wenn sie
möglichst verschiedenen Problemkreisen entstammen. Dann erkennt man
mit der Zeit das Prinzip und kann für ein gegebenes Problem eigene,
d.h. vollständig selbst verstandene entwickeln.
> Ausserdem ist die Verbindung zwischen den Diagrammen untereinander
> und dem Code nicht sehr gut.
Die Diagramme helfen manchmal bei der Dokumentation. Aber dafür
allein sind die Produkte viel zu teuer und zu zeitaufwendig.
CU
--
Lars P. Wolschner lars.wo...@nexgo.de
Bernardstraße 11b lars.wo...@nikocity.de
D-63067 Offenbach am Main lwols...@business-sector.de
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)
Oliver Bandel
[...]
> Und das ein oberes:
[...]
äääh, worauf willst du hinaus?
> [... und ich weiß, das es da je nach DBI-Version 'unterschiedliche
> Shortcuts' gibt, aber deswegen ist das nicht so besonders nützlich].
Weiss nicht, was du sagen willst.
>> Gutes Design und dem jeweiligen Problem gut angepasste
>> Sprachen
> Ich würde eine vorschlagen, in der sich alle beteiligten Menschen
> untereinander verständigen können :->.
BNF? ;-)
> Falls ich tatsächlich die Wahl
> habe (dh ausschließlich, ich komme mal dazu, irgendwas für den
> privaten Hausgebrauch zu schreiben) nehme ich eine, 'die mir gerade so
> einfällt' und die ein erträgliches Interface zum System bietet, dh
> shell, C oder Perl, die letzteren in beliebiger Reihenfolge. C++ ist
> wg 'moving target' und der Unmöglichkeit, jemals sicher ergründen zu
> können, was C++ eigentlich überhaupt ist, sein möchte oder werden
> soll(te?), weitgehend uninteressant geworden ('stdio' ist schon
> größtenteils brechreizfördernd, aber bei 'iostreams' hakt es wirklich
> aus ...).
Ich würde C, Perl, Ocaml nehmen, mit Priorität auf Ocaml
für komplexe Aufgaben, Perl für viel Textbearbeitung in
kleinst-Scripten, C für systemnahe Sachen, auf die andere
Tools/Programme zurückgreifen muessen.
>> (am besten halt welche, die mehrere Programmierparadigmen
>> unterstützen, also imperativ, funktional, OO, etc.)
> 'Funktionales Programm' ist ein Oxymoron. Wenn es keine Seiteneffekte
> hat, tut es auch nichts (außer 'einen Wert liefern').
Wenn es die Seiteneffekte schön weit von einem fern hält
bzw. man diese nur in ganz besonderer Weise benutzen
kann, also eine klare Feststellung hat, wo man denn
mit Seiteneffekten arbeitet (spezielle Code-Abschnitte
bzw. eigener Typ), dann findet man auch die
durch Seiteneffekte aufgeworfenen Problemstellen zügig
wieder. Wenn das ganze Programm Seiteneffekte erzeugen
kann und einem die Sprache nicht eingrenzt, wo Seiteneffekte
zu finden sind (durch spezielle behandlung der selbigen),
dann sucht man sich bei haarigen problemen nen Wolf
und muß quasi das gesamte Programm unter die Lupe nehmen
(Coding-Rules sind im zweifelsfalle keine Hilfe, weil's
immer wieder Leute gibt, die sich daran nicht halten.)
> Rekursionen sind
> cool, aber meistens Unsinn, weil zu kompliziert
Sind cool, wenn sie dem problem angemessen sind, bzw. sich das
Problem gut rekursiv beschreiben lässt.
Und dann sind sie auch nicht zu kompliziert; dann sind eher
iterative herangehensweisen zu kompliziert.
Wenn man in einer sprache auswählen kann, wie man das Problem
in Code umsetzt, und einen die sprache dabei auch unterstützt
- man also keine Verrenkungen machen muß ("geht ja auch mit Sprache
xyz..." 0> aber wie?!) -, dann wird man mit seiner Arbeit
auch fertig und muss nicht erst das Problem (die problemlösung),
das sich gut in einer bestimmten Weise beschreiben lässt
(iterativ, rekursiv, als Objekt, ...) um-formulieren
(um-wurschteln), damit es in einer bestimmten, eingeschränkten
ProgrammierSprache beschrieben werden kann.
> (interessanterweise
> wird der Terminus von allen möglichen Leuten synonym zu 'irgendetwas
> geheimnisvolles, kompliziertes' verwendet).
Das liegt wohl daran, daß typische Vertreter der Lehranstalten
es versuchen, *alle* probleme auf diese Weise zu beschreiben.
Sicherlich einn löbliches Vorhaben, wenn's um das verständnis
geht, aber nicht, wenn es um die Lösung von Programmierproblemen
im Alltag geht. Dann fährt man nämlich besser, wenn man rekursiv
beschreibt, was sich auf diese Weise gut beschreiben lässt
(z.B. Fakultät), und für andere Problembereiche nimmt man eben
andere Beschreibungsmöglichkeiten.
[...]
>> BTW: Speziell zum Visualisieren komplexer Programme,
> Gibt in Quellcode überflüssige Details außer Kommentaren und
> whitespace? Falls ja, wie sieht sowas aus? ( a += a - a?)
Oftmals sind (gut gewählte) Kommentare das einzig sinnvolle
in einem Stücke Code... :->
Explizite Typdeklarationen für eine definierte Variable
sind überflüssiger Ballast. Sprachen wie Ocaml erkennen
den Typ eines Ausdrucks selbst (Auf Wunsch kann man das
auch explizieren). Dadurch spart man schon mal die unnötigen
Deklarationen, die in der C-Familie so nervig sind und
oftmals den Code unleserlich machen (da sie nichts
zum Algorithmus beitragen und nur Ballast sind, der den
Code unnötig aufbläht => und deswegen braucht man dann
ggf. Visualisierungstools, die die eigentliche algorithmische
Struktur aus dem Sprachwust raus filtern.).
Ciao,
Oliver
Andreas Krey
>Oliver Bandel <oli...@first.in-berlin.de> writes:
>
>hat, tut es auch nichts (außer 'einen Wert liefern').
sort liefert nur ein Resultat und tut sonst nichts.
>> BTW: Speziell zum Visualisieren komplexer Programme,
>
>Gibt in Quellcode überflüssige Details außer Kommentaren und
>whitespace? Falls ja, wie sieht sowas aus? ( a += a - a?)
Auskommentierten Code, case-Zweige, die nicht mehr benötigt werden,
ganze Funktionen, die nirgends mehr benutzt werden, etc. pp. Die
ganzen Codeleichen, die entstehen, wenn dem inkompetenten Programmierer
eine zeitliche Deadline, aber keine qualitative Deadline gesetzt wird.
Andreas
--
@(g){g(g)}(@(g){@(v){v>0 ? g(g)(v-1)*v : 1}})(99);
Oliver Bandel
Oliver Bandel <oli...@first.in-berlin.de> wrote:
[...]
> BTW: Speziell zum Visualisieren komplexer Programme, zum maintainen
> von legacy code gibt es ein Tool, dessen name mir jetzt gerade
> nicht einfällt (ich glaube Rigi oder so ähnlich bin mir aber eben nicht
> sicher)... hatte 4 Buchstaben oder so... war von irgend einer Uni in USA.
[...]
OK, habe wohl doch ein gutes Gedächtnis:
http://www.rigi.csc.uvic.ca/Pages/description.html
http://www.rigi.csc.uvic.ca/rigi/manual/user.html
Ciao,
Oliver
Felix von Leitner
> Naja, dem Argument folgend, dürfte man garnichts mit
> dem Computer erledigen wollen, denn *alles* was derart
> komplex wird, daß man den Computer braucht, um es zu
> verstehen müsste dann neu designt werden.
Der Computer eignet sich prima, um Aufgaben auf große Datenbestände
anzuwenden. Man kann sich da auf Verfahren beschränken, deren
Komplexität man überschauen zu können glaubt.
Henrik Motakef
>> 'Funktionales Programm' ist ein Oxymoron. Wenn es keine Seiteneffekte
>> hat, tut es auch nichts (außer 'einen Wert liefern').
> sort liefert nur ein Resultat und tut sonst nichts.
Mein sort hat einen Seiteneffekt: Es schreibt auf stdout. So gesehen
fallen mir nur true und false als seiteneffektfreie Programme ein.
Klaus von der Heyde
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> >
> >Gibt in Quellcode überflüssige Details außer Kommentaren und
> >whitespace? Falls ja, wie sieht sowas aus? ( a += a - a?)
> Auskommentierten Code,
Das verlaengert ja nur die compilier-zeit, aber nicht die
programmlaufzeit. Manchmal kommt man (imho) nicht darum herum,
um etwas auszuprobieren - auch wenn darunter die uebersichtlichkeit
leidet.
> case-Zweige, die nicht mehr benötigt werden,
Manchmal mit enums oder nur 1x vorkommenden konstanten (compilerwarnung)
in den griff zu bekommen.
> ganze Funktionen, die nirgends mehr benutzt werden, etc. pp. Die
Die koennte/sollte der compiler dann rauswerfen, oder zumindest eine
warnung generieren.
> ganzen Codeleichen, die entstehen, wenn dem inkompetenten Programmierer
> eine zeitliche Deadline, aber keine qualitative Deadline gesetzt wird.
Imho muss man unterscheiden, ob man gerade in der entwicklung ist
und verschiedenes ausprobiert, ohne gleich alles im moment ueberfluessige
zu loeschen, oder ob es ein fertig gestelltes programm ist.
Rainer Weikusat
> > Gibt in Quellcode überflüssige Details außer Kommentaren und
> > whitespace? Falls ja, wie sieht sowas aus? ( a += a - a?)
>
> Oftmals sind (gut gewählte) Kommentare das einzig sinnvolle
> in einem Stücke Code...
"Das wird wohl so sein"
Karsten Wemheuer
Walter Mühlheim wrote:
> Es gibt eine Software für die Telekommunikationsbranche SDT (Kostenpunkt
> angeblich rund 100.000 DM pro Lizenz). Diese Software ist brauchbar, wird
> benutzt, auch (oder gerade) für sehr große Projekte.
>
> Allerdings ist das ganze eher eine visuelle Entwicklungsumgebung als ein
> Case-Tool. Auch wenn es manche Dinge (z.B. grafische Darstellung von
> Informationsflüssen etwa) hat, die ich eher einem Case-Tool zuschreibe.
AFAIK ist SDT eine Entwicklungsumgebung für SDL (Specification and
Description Language), welche im Telekommunikationsumfeld verwendet wird,
um Protokolle zu beschreiben. Mit SDL können sehr gut Abläufe von
Protokollen (Automaten: "Wenn im Zustand x Ereignis y eintrifft, werden
folgende Aktionen ausgeführt und der Zustand z eingenommen") beschrieben
werden. SDT kann nicht nur Diagramme zeichnen (SDL ist eine grafische
Sprache) sondern daraus auch Code (seinerzeit war das C) generieren.
Aufgrund der unterschiedlichen Parameterübergabe-Modelle war das damals
allerdings mit viel kopieren verbunden und daher wie häufig bei automatisch
generierten Code weniger performant.
Gruss
Karsten
Walter Mühlheim
> Sprache) sondern daraus auch Code (seinerzeit war das C) generieren.
> Aufgrund der unterschiedlichen Parameterübergabe-Modelle war das damals
> allerdings mit viel kopieren verbunden und daher wie häufig bei
> automatisch generierten Code weniger performant.
Heute bedarf es eines handgeschriebenen Treibers. Der Rest (C Code erzeugen,
Makefile erzeugen, compilieren) mach SDT. Ist schon cool. Über Performance
kann man streiten. Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
Performance. Notfalls nimmt man halt eine bessere CPU. :)
Mfg
Rainer Weikusat
> AFAIK ist SDT eine Entwicklungsumgebung für SDL (Specification and
> Description Language), welche im Telekommunikationsumfeld verwendet wird,
> um Protokolle zu beschreiben. Mit SDL können sehr gut Abläufe von
> Protokollen (Automaten: "Wenn im Zustand x Ereignis y eintrifft, werden
> folgende Aktionen ausgeführt und der Zustand z eingenommen") beschrieben
> werden. SDT kann nicht nur Diagramme zeichnen (SDL ist eine grafische
> Sprache) sondern daraus auch Code (seinerzeit war das C) generieren.
Ähh ... verstehe ich Dich richtig? Wenn man wirklich Geld ausgibt,
erwirbt man ein Frontend für einen Compiler, das aus einer
graphischen Darstellung 'automatisch' schlechten Code erzeugt? Dh
man kann sich soviel Mühe geben, wie man möchte, aber die Software
stellt sicher, das dieser Arbeitsaufwand umsonst war und bleiben wird?
Sind cell phones in der Herstellung wirklich so teuer?
Rainer Weikusat
> Karsten Wemheuer wrote:
> > Sprache) sondern daraus auch Code (seinerzeit war das C) generieren.
> > Aufgrund der unterschiedlichen Parameterübergabe-Modelle war das damals
> > allerdings mit viel kopieren verbunden und daher wie häufig bei
> > automatisch generierten Code weniger performant.
>
> Heute bedarf es eines handgeschriebenen Treibers. Der Rest (C Code erzeugen,
Mit einem Aufwand, der seine breitere Benutzung offensichtlich
verhindert.
> Ist schon cool. Über Performance kann man streiten.
Nein, die braucht man entweder oder man braucht sie nicht. Vor allem
ist 'Performance' erheblich irrelevanter als Platzverschwendung (oder
'Zeitvergeudung') und durch die Einschränkung auf (graphische)
Primitivsprachen bekommt man die eben.
Mach bitte ein Bild, das diesen Satz repräsentiert :->.
> Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
> wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
> Performance.
Und Deine Erkenntnis, das ein wirklich komplexes Programm
diesbezüglich in jedem Fall fehlerfrei ist, beziehst Du
woher?
'Gottvertrauen', wie gewöhnlich?
Walter Mühlheim
>> Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
>> wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
>> Performance.
> Und Deine Erkenntnis, das ein wirklich komplexes Programm
> diesbezüglich in jedem Fall fehlerfrei ist, beziehst Du
> woher?
> 'Gottvertrauen', wie gewöhnlich?
:)
Fehler lassen sich natürlich auch mit SDT programmieren. Aber typische
Sachen wie vergessene free()s gibt es nicht mehr, es gibt keine Möglichkeit
Signale zu vergessen oder Hänger einzubauen, weil die Software Signal x
erwartet, aber y kommt. Nur als Beispiel.
Was die Performance betrifft: Die meisten Automaten haben nicht wirklich ein
Performance-Problem. Wie schon gesagt: Notfalls einen schnelleren Prozessor
oder mehr Speicher nehmen.
Wichtig bei Automaten ist die Echtzeitfähigkeit bzw. die Reaktion auf
Signale innerhalb der dem Kunden versprochenen Zeit (oder umgekehrt Anzahl
von bearbeiteten Signalen innerhalb einer bestimmten Zeit).
Keine Ahnung von wann Deine Erfahrungen mit SDT stammen. Ich persönlich fand
die Software cool.
Ein Genuss ist zum Bespiel auch die automatische Generierung von Signalen im
Testbetrieb, einschließlich Generierung von Fehlern und eine graphische
Auflistung der Automatenreaktion auf solche Fehler.
SDT ist außerdem Einsteigerfreundlich, da die Software den "Code" sehr
übersichtlich darbietet.
Mfg
Rainer Weikusat
> Keine Ahnung von wann Deine Erfahrungen mit SDT stammen.
Ich besitze keine. Ich finde lediglich das Konzept eigenartig.
Karsten Wemheuer
Dann hat sich an der Arbeitsweise seit damals (1992) nicht viel verändert.
Meine Bemerkung zum "Kopieren" bezog sich darauf, dass in C häufig mit
Zeigern gearbeitet wird, während bei SDL wegen der Übergabe "per Value"
(damals) eine vollständige Kopie auf den Stack gelegt wurde. Wenn man
Automaten z.B. im OSI-Layer 4 (TP4, das damals interessante Pendant zu TCP)
baut ist Deine Aussage zwar richtig, was die Speicherlecks und die
Stabilität betrifft, aber so ganz würde ich die Performance nicht ausser
acht lassen ... Damals hatte wir nur eine Sparc (das damals aktuelle
Modell) und die wurde ganz gut ausgelastet.
Aber es ist sowohl eine interessante Sprache als auch ein interessantes
Tool!
Gruss
Karsten
Karsten Wemheuer
Wie in meinem anderen Posting
(<6593943.y...@04022715243-0001.dialin.t-online.de>) geschrieben,
liegt meine Erfahrung sowohl mit der Sprache als auch mit dem Tool ca. 10
Jahre zurück. Die Sprache (sofern diese Bezeichnung für eine graphische
"Sprache" passen mag) ist von Normungsgremien standardisiert (ITU) und für
ihren Einsatzzweck (Beschreibung von Protokollen) gut geeignet. Da SDL eine
eigene, in ihrer Anwendung spezielle Sprache ist, würde ich das SDT nicht
in einen Topf rühren mit Dingen wie Innovator o.ä.
Das Tool SDT eignet sich m.E. gut zum Entwurf von Protokollen, da es
gewisse Prüfungen vornimmt (IIRC unbekannte Zustände von Automaten, Signale
die nicht verarbeitet werden usw.). Ausserdem kann man mit dem Tool auch
Simulationen durchführen. Der automatisch generierte Code ist IMHO
allerdings nicht für Echtzeitanforderungen geeignet. Ja, die
Reaktionszeiten mögen vorhersagbar sein, aber Die Aktionen brauchen auch
ihre Zeit ;-). Nicht in jeder Umgebung kann man einfach eine performantere
Hardare einsetzen...
Gruss
Karsten
Oliver Bandel
>>> Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
>>> wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
>>> Performance.
>> Und Deine Erkenntnis, das ein wirklich komplexes Programm
>> diesbezüglich in jedem Fall fehlerfrei ist, beziehst Du
>> woher?
>> 'Gottvertrauen', wie gewöhnlich?
> :)
> Fehler lassen sich natürlich auch mit SDT programmieren. Aber typische
> Sachen wie vergessene free()s gibt es nicht mehr, es gibt keine Möglichkeit
> Signale zu vergessen oder Hänger einzubauen, weil die Software Signal x
> erwartet, aber y kommt. Nur als Beispiel.
Ocaml,
Haskell,
Scheme,
Lisp,
Clean,
Erlang,
...
Ciao,
Oliver
Oliver Bandel
Walter M?hlheim <Walter.M...@gmx.de> wrote:
[...]
> Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
> wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
> Performance.
Dann nimmt man gleich eine richtige Programmiersprache,
die das sicherstellt, anstatt irgendwelche krüppligen
schweineteuer-Tools (im übrigen können die auch
fehlerhaft arbeiten) zu nutzen, um Code in einer
Programmiersprache zu erzeugen, die keineswegs Sicherheit
in den genannten Punkten liefert.
Also: statt dummer Tools lieber gut durchdachte Programmiersprachen
nutzen.
Ciao,
Oliver
Heinrich Schramm
>Rainer Weikusat wrote:
>
[SDT:]
>> Ähh ... verstehe ich Dich richtig? Wenn man wirklich Geld ausgibt,
>> erwirbt man ein Frontend für einen Compiler, das aus einer
>> graphischen Darstellung 'automatisch' schlechten Code erzeugt?
Nein. SDL steht fuer "Specification and Description Language" und wird
benutzt, um Zustandsmaschinen zu beschreiben. SDL ist von der ITU
standardisiert und wird z.B. bei der Spezifikation von
Kommunikationsprotokollen eingesetzt. Siehe
<http://www.sdl-forum.org/SDL/index.htm>
SDT ist eine SDL-Entwicklungsumgebung von Telelogic, die mehrere Tools
umfasst, z.B. einen "Message Sequence Charts Editor", mit dem man die
Spezifikation erstellen kann, einen "Analyzer", der gewisse formale
Fehler im Entwurf findet, einen "Simulator", mit dem man den Automaten
z.B. auf einer Unix-Maschine testen kann, bevor die Zielhardware
verfuegbar ist. Der Code-Generator, der aus dem SDL-Entwurf C-Code
erzeugt, kuemmert sich allerdings nur um das organisatorische Drumherum
des Programmablaufs: Verwaltung der Zustaende und Zustandsuebergaenge,
Austausch von Signalen (Verwaltung von Message-Queues), Timer-Handling.
Wenn man den Programmablauf mit weiterem Leben fuellen und speziell mit
seiner Umwelt in Interaktion treten will (z.B. Zugriffe auf
Hardware-Treiber), kann man es gar nicht vermeiden, auch eigenen C-Code
einzubinden.
<http://www.fokus.gmd.de/step/simulations/sdt.html>
>Der automatisch generierte Code ist IMHO
>allerdings nicht für Echtzeitanforderungen geeignet.
Es haengt davon ab, welches Betriebssystem auf der Zielhardware
eingesetzt wird. Wenn man ein Realtime-OS nimmt (z.B. VxWorks) ist auch
der mit SDT erzeugte Code echtzeitfaehig. Unter Standard-Linux waere das
nicht der Fall. (Allerdings gibt es inzwischen auch einige Ansaetze,
Linux echtzeitfaehig zu machen, z.B. von Red Hat.)
>Ja, die Reaktionszeiten mögen vorhersagbar sein,
Genau das bedeutet Echtzeit.
>aber Die Aktionen brauchen auch ihre Zeit ;-).
Das ist egal. Wenn ich den Lichtschalter umlege und eine Stunde spaeter
geht das Licht an, dann ist das immer noch Echtzeit, solange ich
garantieren kann, dass es unter _keinen_ _Umstaenden_ laenger dauert,
als eben eine Stunde. ;-)
>Nicht in jeder Umgebung kann man einfach eine performantere
>Hardare einsetzen...
Stimmt, das faellt dann unter das Stichwort "Optimierung" und ist ein
ganz anderes Thema. Schlimmstenfalls muss ich dann in Assembler
programmieren. Oder ganz auf Software verzichten und eine
Hardware-Schaltung entwerfen.
Gruss Heiner
Felix Deutsch
>Walter =?ISO-8859-15?Q?M=FChlheim?= <Walter.M...@gmx.de> writes:
>> Karsten Wemheuer wrote:
>> > Sprache) sondern daraus auch Code (seinerzeit war das C) generieren.
>> > Aufgrund der unterschiedlichen Parameterübergabe-Modelle war das damals
>> > allerdings mit viel kopieren verbunden und daher wie häufig bei
>> > automatisch generierten Code weniger performant.
>>
>> Heute bedarf es eines handgeschriebenen Treibers. Der Rest (C Code erzeugen,
>> Makefile erzeugen, compilieren) macht SDT.
>
>Mit einem Aufwand, der seine breitere Benutzung offensichtlich
>verhindert.
Nunja, die Hersteller von embedded telecom software *sind* überschaubar.
>> Für Automaten die 24h/7d laufen sollen, sind IMHO Sachen
>> wie Speicherlecks und Absturzsicherheit sehr viel wichtiger als
>> Performance.
>
>Und Deine Erkenntnis, das ein wirklich komplexes Programm
>diesbezüglich in jedem Fall fehlerfrei ist, beziehst Du
>woher?
Solche tools können zumindest einige eklige Fehlerklassen ausschliéssen.
--
"Source port zero is illegal. USwest has a sysadmin who loves source port zero.
So about 90% of the source port zero things I see here are from either Quest or
USwest. DNS is so robust, that they don't notice that many of their nameservers
are totally ineffective." -- Evi Nemeth, CAIDA at NANOG24
Juergen Beisert
<hein...@schramm.com> wrote:
>Das ist egal. Wenn ich den Lichtschalter umlege und eine Stunde spaeter
>geht das Licht an, dann ist das immer noch Echtzeit, solange ich
>garantieren kann, dass es unter _keinen_ _Umstaenden_ laenger dauert,
>als eben eine Stunde. ;-)
bearbeitet werden muß, bevor das nächste eintrifft?
Wenn ich nach fünf Minuten den Lichtschalter nochmal umlege, weil ich
mittlerweile überzeugt bin, daß die Lampe kaputt ist und wieder nichts
passiert, ist das nicht mehr Echtzeit...
JB
Heinrich Schramm
>On Tue, 21 May 2002 19:24:25 +0000, Heinrich Schramm
><hein...@schramm.com> wrote:
>>Das ist egal. Wenn ich den Lichtschalter umlege und eine Stunde spaeter
>>geht das Licht an, dann ist das immer noch Echtzeit, solange ich
>>garantieren kann, dass es unter _keinen_ _Umstaenden_ laenger dauert,
>>als eben eine Stunde. ;-)
>
>Ist die Definition von Echtzeit nicht, daß ein Ereignis vollständig
>bearbeitet werden muß, bevor das nächste eintrifft?
Das kann eine Randbedingung fuer die Loesung einer bestimmten Aufgabe
sein. Eine (zumindest mir) gelaeufige Definition von Echtzeit waere:
"Echtzeit-Anwendungen muessen auf aeussere Ereignisse innerhalb eines
vorhersagbaren Zeitraums reagieren." Wenn man jetzt weiss, in welchen
Zeitraeumen eine bestimmte Aufgabe jeweils erledigt sein muss, kann man
eine Aussage darueber treffen, ob ein bestimmtes Echtzeitsystem zur
Loesung dieser Aufgabe geeignet oder ungeeignet (weil zu langsam) ist.
>Wenn ich nach fünf Minuten den Lichtschalter nochmal umlege, weil ich
>mittlerweile überzeugt bin, daß die Lampe kaputt ist und wieder nichts
>passiert, ist das nicht mehr Echtzeit...
Nach meinem Verstaendnis ist es schon Echtzeit, allerdings fuer die
spezielle Aufgabenstellung eventuell zu langsam. "Eventuell", weil ich
mir durchaus Situationen vorstellen kann, in denen eine Verzoegerung von
einer Stunde akzeptabel ist. (Z.B. wenn sich der Schalter auf der Erde
befindet, die Lampe aber an einer Raumsonde angebracht ist, die sich
gerade einem Kometen in der Gegend des Saturn naehert.)
Gruss Heiner