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...
>Karl Heinz Buchegger schrieb: >>> Also für Volldeppen. >wie gemein... Das war nicht Karl Heinz. Das geht auf meine Rechnung;) holger
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
SysML ist dafür in Grenzen geeignet
>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
UML ist gut. DIA wohl eher nicht. ArgoUML könnte z.B. eine Opensource Alternative sein.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.