hallo,
ich denke das hier als Diskussion zum Thema:
Ich suche eine geeignete Diagramm(sprache) etc., mit der es sinnvoll ist
uC_Software zu modellieren (strukturieren). wünschenswert wär auch
codegenerierung aus den diagrammen oder zumindest codevorlagen.
UML ist da denk ich zu komplex und allgemein, bzw. hab ich gerade mit
gnu dia versucht aus UML Diagramm code zu generieren ... schlägt aber
fehl, nur so klassenzeugs wird da übersetzt.
wenn ich an struktogramme denke, dann ist mir das zu fein, es gehen die
zusammenhänge verloren.
was meint ihr ??
>wünschenswert wär auch>codegenerierung aus den diagrammen oder zumindest codevorlagen.
Also für Volldeppen. Ich bevorzuge den umgekehrten Weg.
Code selber schreiben und danach Diagramme malen.
holger schrieb:>>wünschenswert wär auch>>codegenerierung aus den diagrammen oder zumindest codevorlagen.>> Also für Volldeppen.
Eigentlich nicht.
Ich kenns bisher eigentlich nur so: Ein besonders Kreativer sitzt
wochenlang vor dem UML Tool um möglichst tolle Diagramme zu erhalten,
die dann von jemand anderem komplett ignoriert werden, der dann in 3
Tagen die Implementierung macht :-)
wie auch immer, zu dokumentationszwecken nach dem programmieren ist
natürlich auch ne idee (was ist da zu empfehlen ?)
ich mein auch modellierung in richtung sich gedanken machen wie man
komplexere SW aufbaut und optimiert, vor jeglicher programmierung...
holger schrieb:>>wünschenswert wär auch>>codegenerierung aus den diagrammen oder zumindest codevorlagen.>> Also für Volldeppen. Ich bevorzuge den umgekehrten Weg.> Code selber schreiben und danach Diagramme malen.
Je nachdem wie komplex die Statemachine ist bist du der Volldepp wenn du
versuchst die "von Hand" zu implementieren.
radiUS schrieb:> Ich suche eine geeignete Diagramm(sprache) etc., mit der es sinnvoll ist> uC_Software zu modellieren (strukturieren). wünschenswert wär auch> codegenerierung aus den diagrammen oder zumindest codevorlagen.
schau mal hier: http://www.yakindu.de
Erfordert ein wenig Einarbeitung, aber nicht so komplex wie UML
>Je nachdem wie komplex die Statemachine ist bist du der Volldepp wenn du>versuchst die "von Hand" zu implementieren.
Ich mach das lieber von Hand als das einem Codegenerator
zu überlassen.
radiUS schrieb:> Ich suche eine geeignete Diagramm(sprache) etc., mit der es sinnvoll ist> uC_Software zu modellieren (strukturieren)
UML ist genau das was du suchst.
holger schrieb:> Also für Volldeppen
Volldeppen sind die jenigen die die Vorteile dieser Modellierung nicht
sehen. Programme werden immer komplexer, Sourcecode wird immer
komplexer, Anforderungen werden immer komplexer!
Genau diese Punkte gab es beim Umstieg von Assembler auf Hochsprachen
auch! Es muss nur endlich mal ankommen, man muss es probieren und sehen,
dass es funktioniert. (Für den >Hobbybereich< meist overpowered und ich
kenne keine günstigen Tools mit vernünftiger Codegenerierung)
UML mit Codegenerierung ist die Zukunft bzw. wird schon erfolgreich
angewandt.
Vielleicht haben manche hier auch schon Erfahrung damit und können dies
untermauern.
Ich habe selbst schon jahrelang mit CASE-Werkzeugen wie z.B. Telelogic
Tau oder Rational Rose gearbeitet, bei denen SDL- bzw.
UML-Klassendiagramme in Programmcode übersetzt werden.
Es gibt dabei mehrere Probleme: zum einen kann die Anbindung an das sog.
Environment, d.h. die Ablaufumgebung außerhalb des modellierten
Programmteils, so kompliziert werden, dass dies eine Vollzeittätigkeit
für ein bis zwei Entwickler wird.
Bei einem Kundenprojekt, in dem Rational Rose eingesetzt wurde, neigten
im Laufe der Zeit doch fast alle Entwickler dazu, eine Vorstellung von
dem zu generierenden Code zu entwickeln und dann so lange an dem Modell
und den Unmengen von Parametern zur Codegenerierung herumzudrehen, bis
der tatsächlich generierte Code dem angedachten entsprach. Damit wurde
das sehr teure Werkzeug schon fast zum umständlichen Quellcode-Editor
umfunktioniert.
Wenigstens hatte man anschließend tolle Klassendiagramme usw. zum
Ausdrucken und Vorzeigen.
Derzeit stehen wir in einigen Projekten wieder vor der Entscheidung,
Werkzeuge zu Modellierung von Zustandsautomaten einzusetzen, und sind da
noch einigemaßen unschlüssig. Unser derzeitiger Favorit ist hierbei
Enterprise Architect von Sparx Systems. Für (Teil-)Projekte in
objektorientieren Sprachen wie z.B. C# oder Python ist unsere
Entscheidung schon fast gefällt, für "klassische"
Microcontroller-Teilprojekte in C werden wir ihn sicherlich einsetzen,
aber nur zur Spezifikation und Dokumentation und weniger für die
Codegenerierung.
>Volldeppen sind die jenigen die die Vorteile dieser Modellierung nicht
sehen. Programme werden immer komplexer, Sourcecode wird immer
komplexer, Anforderungen werden immer komplexer!
Ja. Das waere dann der Fehler Nummer eins. Komplexer Code ist nicht,
oder schwer wartbar. Der Code muss einfach sein.
Milli Oschi schrieb:>>Volldeppen sind die jenigen die die Vorteile dieser Modellierung nicht> sehen. Programme werden immer komplexer, Sourcecode wird immer> komplexer, Anforderungen werden immer komplexer!
Sehe ich auch so. Seit ich mir das vorher aufmale bin ich (als
Gelegenheitsprogrammierer) schneller am Ziel und die Programme sind auch
noch leichter zu warten.
Gute Erfahrungen habe ich mit dem Pap Designer und yEd Grafik Editor
gemacht.
Keine Vollprofi Case Tools aber sehr hilfreich.
umlftw schrieb:> radiUS schrieb:>> Ich suche eine geeignete Diagramm(sprache) etc., mit der es sinnvoll ist>> uC_Software zu modellieren (strukturieren)>> UML ist genau das was du suchst.>> holger schrieb:>> Also für Volldeppen>> Volldeppen sind die jenigen die die Vorteile dieser Modellierung nicht> sehen. Programme werden immer komplexer, Sourcecode wird immer> komplexer, Anforderungen werden immer komplexer!
Ohne Zweifel.
> Genau diese Punkte gab es beim Umstieg von Assembler auf Hochsprachen> auch!
Hmm, weiss nicht, so alt bin ich dann doch nicht.
> Es muss nur endlich mal ankommen, man muss es probieren und sehen,> dass es funktioniert. (Für den >Hobbybereich< meist overpowered und ich> kenne keine günstigen Tools mit vernünftiger Codegenerierung)
Allein das ist schon das Todesurteil. Sorry, eine Technik für die keine
erschwinglichen Tools zum zu Hause ausprobieren verfügbar sind, uhh,
eher unwahrscheinlich dass sich so ein Kram mal breit durchsetzt. No
F*cking Way(tm) (wieso glaubt eigentlich die Forensoftware das F-Wort
würde ein Anzeichen für Spam sein, seltsam...).
> UML mit Codegenerierung ist die Zukunft bzw. wird schon erfolgreich> angewandt.
Das bezweifele ich (das mit der Zukunft), aus Erfahrung, auf wesentlich
tieferem Abstraktionslevel. Man schaue sich mal Java Enterprise Beans
an, die alleinseligmachende Technologie von vorgestern. Tja, die Leute
die das so richtig benutzen: können ihr SQL nicht beeinflussen
(optimieren), haben meistens keine Ahnung wie ihre Transaktionen
wirklich ablaufen und benutzen all die Features ihres DBMS zur
Konsistenzsicherung der Daten nicht (aber bezahlen natürlich trotzdem
dafür ;-). Plus sie sind hirngewaschen, anzunehmen dass niemals jemand
per sqlplus und bucklige Freunde direkt auf die DB zugreifen wird. Na
toll, ganz toll. Gilt übrigens genauso für Zeugs wie Microsofts LINQ.
Wenn es denn so wäre dass das einzige Problem die steigende Komplexität
wäre - dann könnte Codegenerierung aus UML (oder so) ein plausible
Lösung sein.
So ist es aber nicht, auch Performance, Ressourcenverbrauch usw. sind
immer (vorläufig?) noch ein wichtiger Punkt. So etwas wie Apache oder
Samba oder gar einen OS-Kernel aus UML generieren zu wollen - hehehe,
auf den Versuch wäre ich gespannt. Übrigens dito auf den Versuch die
Korrektheit einer signifikant komplexen Software mathematisch zu
beweisen ;-).
Viel grundlegender: Frederick P. Brooks hat vor ziemlich langer Zeit
einen schlauen Artikel zum Unterschied zwischen essentieller und
zufälliger Komplexität in Software geschrieben, und gesagt dass nur eine
Lösung für die essentielle Komplexität uns wirklich vorwärtsbringen
wird. Codegenerierung aus UML (und auch Compiler vs. Assembler)
verringert nur die zufällige Komplexität, vielleicht.
Gibt es eigentlich schon einen Debugger für UML-Diagramme?
Jasch schrieb:> Gibt es eigentlich schon einen Debugger für UML-Diagramme?
Jein. Das hängt natürlich von dem jeweiligen Diagrammtyp ab. Bei
Klassendiagrammen genügen ja die üblichen Debugger, da sich dort auch
die entsprechenden Methodendefinitionen leicht auffinden lassen.
Wenn man SDL als einen der Vorgänger von UML ansieht, zumindest für
einige Diagrammtypen, so gab es schon früher(tm) zu dem Codegenerator
Telelogic Tau Cmicro auch den Debugger Cmicro Tester. Dort konnte man
dann direkt im grafischen SDL-Diagramm den Programmablauf
nachvollziehen.
Für einen der anderen SDL-Codegeneratoren, d.h. Cadvanced, hatte ich
selbst einmal Protokollierungsfunktionen implementiert, mit denen aus
dem Programmablauf im Zielsystem eine MSC-Datei (Message Sequence Chart)
generiert wurde. Diese konnte anschließend im wiederum im Telelogic Tau
MSC Editor eingelesen und mit den Simulationsergebnissen verglichen
werden.
Verwendet man bei solchen Methoden jedoch nicht den durch den
Codegenerator mitgebrachten bzw. automatisch generierten Scheduler,
sondern bildet die SDL-Prozesse auf die Ressourcen (Prozesse, Threads)
des im Zielsystem befindlichen Betriebssystems ab, sieht man sehr schön,
wie sich das Schedulingverhalten zwischen Simulation und Zielsystem
unterscheiden kann. Dadurch scheidet der automatische Vergleich der MSCs
zwar aus, aber beim manuellen Vergleich erkennt man sehr schön, wo man
als Entwickler bei der Definition der Zustandsautomaten versehentlich
implizite Annahmen zum Laufzeitverhalten getroffen hat.
Mit freundlichen Grüßen
Andreas Schweigstill
(Meine Kommentare beziehen sich alle auf Embedded Systems)
Vorab: Ich benutze Rhapsody in C mit entsprechender Codegenerierung und
Betriebssystem.
Projekte werden direkt und vollständig im Programm gepflegt. Es wird die
Codegenerierung nicht ausgenutzt um Rümpfe zu erzeugen, die dann
ausprogrammiert werden. Debuggt wird der erzeugte Code in einer IDE. Die
Compilerfehler liefern Rückschlüsse auf Fehler im Modell, die dann
manuell berichtigt werden oder durch Roundtripping ins Modell
eingepflegt werden. Außerdem lassen sich Statecharts animieren um
Modellierungsfehler innerhalb dieser zu erkennen.
Karl Heinz schrieb:> holger schrieb:>>>wünschenswert wär auch>>>codegenerierung aus den diagrammen oder zumindest codevorlagen.>>>> Also für Volldeppen.>> Eigentlich nicht.> Ich kenns bisher eigentlich nur so: Ein besonders Kreativer sitzt> wochenlang vor dem UML Tool um möglichst tolle Diagramme zu erhalten,> die dann von jemand anderem komplett ignoriert werden, der dann in 3> Tagen die Implementierung macht :-)
Hahaha, wer sichs leisten kann :D
holger schrieb:>>wünschenswert wär auch>>codegenerierung aus den diagrammen oder zumindest codevorlagen.>> Also für Volldeppen. Ich bevorzuge den umgekehrten Weg.> Code selber schreiben und danach Diagramme malen.
genau und nur Volldeppen erstellen zuerst einen Schaltplan und löten
dann... die coolen löten erst und klingeln dann die Schaltung durch um
den Schaltplan zu "generieren" LOL
nix für ungut... so macht sich jeder so gut er kann zum VOLLDEPPEN ;-)
ach so... war letztens zu ner rhapsody schulung ... haben die mit dem
MDK von keil kombiniert ... voll fett fullcycle embedded uml mit
codegenerierung statecharts und model level debugging ... der code sogar
recht kompakt... nich ganz billig aber wahrscheinlich die oberste liega
... etwas leichtgewichtiger gehts auch mit sisy
ach und der EA soll inzwischen auch recht fit für embedded systems sein
Gruß J.
Ab einem gewissen Komplexitätsgrad sind handcodierte Statemachines
einfach nur noch unhandlich und fehlerträchtig.
Ich bin mitlerweile dazu übergegangen meine Statemachines in
Matlab/Simulink/Stateflow zu modellieren.
Die Codegenerierung geschieht dann mit dem embedded coder (ert.tlc).
Der generierte Code ist natürlich schwerer zu debuggen, hier muss man
sich mit andern Mitteln helfen. Ich leg mir z.B. gerne ein enum mit
allen Statenamen an, dieses kann dann im Debugger (oder auch auf einem
beliebigen Bussystem) beobachtet werden.
