Ich bin kürzlich auf Software engineering mittels UML gestoßen. Also, man designt sein Projekt in UML, woraus ein plattformunabhängiges Codegerüst generiert wird, das man dann für verschiedene Plattformen fertig implementieren kann. Kann jemand dazu ein Buch zur Einführung empfehlen, das möglichst praxisnah, gerne anhand spezieller UML-Tools, zeigt, wie das ganze abläuft? Welche Teile generiert werden können - RPCs für verteilte Systene z.B? Zustandsautomaten? Wo die Handarbeit anfängt? Ich würde gerne tiefer in das Thema einsteigen, weil ich einige Vorteile für kommende Projekte sehe, doch ich bräuchte eine konkretere Vorstellung, wie das in der Praxis aussieht. Danke euch!
Das hat noch nie funktioniert und wird auch niemals funktionieren! Warum gibt es immer wieder den Irglauben, dass sich soetwas komplexes wie Software komplett in Diagrammen definieren läßt? Wenn das funktionieren würde, dann würde es das deutsche Steuerrecht doch auch in einer UML-Ähnlichen Notation geben. Gibt es aber nicht und die Kollegen hatten einige hundert Jahre Vorsprung. Bilder sind prima um den Überblick zu schaffen. UML ist prima, um Design-Details zu diskutieren. Denk mal weiträumiger über DSLs (domain specific languages) nach, dann findest Du wahrscheinlich sehr häufig eine Notation, die eine Problem (oder deren Lösung) sehr viel besser beschreibt, als eine "general purpose programming language". (Das kann dann natürlich auch eine grafische Sprache, wie UML sein). UML taugt nicht, als Programmiersprache! Mein Buchtipp: https://martinfowler.com/books/dsl.html mfg Torsten
Mir ist klar, dass UML keine Programmiersprache ist. Ich fragte nach der Generierung eines Code-GERÜSTs! Wer Tips zu knappen, praktischen Büchern zu Software engineering mithilfe von UML hat, dem bin ich für Antworten dankbar. Alternativen möchte ich hier nicht diskutieren.
Torsten R. schrieb: > Das hat noch nie funktioniert und wird auch niemals funktionieren! > Warum > gibt es immer wieder den Irglauben, dass sich soetwas komplexes wie > Software komplett in Diagrammen definieren läßt? > Ich kenne Beispiele wo das funktioniert -> Einfache Bedienprogramme (also nicht komplex ;). In meiner Hochschulausbildung, haben die Professoren immer einen ganz guten Blick dafür gehabt, wann man welche Visuellen Unterstützungen zur Hilfe nehmen sollte und wie weit man dabei gehen sollte. In der Embedded Programmierung haben wir nie ausgiebig UML gemacht, immer nur schöne Übersicht Blockdiagramme und einige Abläufe skizziert -> strukturiertes und planmäßiges Arbeiten halt. Leider tun das viele Kollegen in der Praxis nicht, es wird ohne Plan losgehackt. Aktuell laufen gefühlt wieder viele Unternehmen in eine UML Falle betreffend unpassender Problemstellungen, wo es einfach nur viel Geld verbrennt ohne nennenswerte Vorteile. > Wenn das funktionieren würde, dann würde es das deutsche Steuerrecht > doch auch in einer UML-Ähnlichen Notation geben. Gibt es aber nicht und > die Kollegen hatten einige hundert Jahre Vorsprung. > > Bilder sind prima um den Überblick zu schaffen. UML ist prima, um > Design-Details zu diskutieren. > > Denk mal weiträumiger über DSLs (domain specific languages) nach, dann > findest Du wahrscheinlich sehr häufig eine Notation, die eine Problem > (oder deren Lösung) sehr viel besser beschreibt, als eine "general > purpose programming language". (Das kann dann natürlich auch eine > grafische Sprache, wie UML sein). > > UML taugt nicht, als Programmiersprache! > > Mein Buchtipp: https://martinfowler.com/books/dsl.html > > mfg Torsten Dem Beitrag war kaum etwas hinzuzufügen. Bei DSLs habe ich immer etwas die Sorge die Übersicht zu verlieren. Habe ich aber auch wenig mit zu tun und kann da keine Qualitative Bewertung abgeben.
Karsten schrieb: > Mir ist klar, dass UML keine Programmiersprache ist. Ich fragte nach der > Generierung eines Code-GERÜSTs! Die Code-Generierung liest sich in der Theorie besser als sie in der Praxis sein wird: Probleme tauchen dann auf, wenn das Model geändert wird -> Code muss neu generiert werden. Deswegen muss man fürchterliche Konstrukte einsetzen, um bestehenden (von Hand geschriebenen) Code nicht einfach zu überschreiben - meistens gelöst durch generierte Basis-Klassen, die durch Ableitungen von Hand erweitert werden. In den Projekten, in denen ich tätig war, wurden die Anforderungen während der Projektlaufzeit mehrfach geändert, immer! Je häufiger man Änderungen am UML machen muss, desto problematischer kann das werden. Das taugt nur fürs Wasserfall-Modell und das ist weit an der Realität vorbei (einige Ausnahmen mag es da geben). Meine Erfahrungen: UML zu Dokumentationszwecken ok, dann aber auch nur für wesentliche Teile (Kernlogik). Just my 2 cents merciless
:
Bearbeitet durch User
Dirk K. schrieb: > Just my 2 cents Leute, ich brauche eure 2 cents nicht, auch nicht von zig anderen! Es nervt, wenn ich nach einem Buch zu einem bestimmten Thema frage, und alle, die das Thema nicht interessiert, sagen, dass es scheiße ist. Spart euch eure, meine und die Zeit von allen anderen, die diese sinnlosen Antworten angucken müssen. Kann jemand ein praktisches Buch zu Software engineering mithilfe von UML empfehlen? Wenn nein, bitte Fresse halten. Danke!
Karsten U. schrieb: > Wenn nein, bitte Fresse halten. Du willst Hilfe vom Forum, und poebelst rum wenn die Antworten nicht so sind wie du es gerne haettest. Die Leute hier sagen Dir, dass das was du da willst in der Praxis Mist ist. Es ist Schlussendlich ein Hinweis darauf, dass Du nicht zu viel erwarten solltest. Und da es offenbar kein entsprechendes Buch gibt, oder keiner ein solches Buch kennt, das deine Anforderungen erfuellt, werden dir Tipps aus der Praxis geben. Denk mal drueber nach. Du willst Hilfe von uns, nicht umgekehrt. Nichts desto trotz: Schau dir einfach mal das hier an: Software Engineering (Pearson Studium - IT) https://www.amazon.de/Software-Engineering-Pearson-Studium-Sommerville/dp/3868940995
Karsten U. schrieb: > Kann jemand ein praktisches Buch zu Software engineering mithilfe von > UML empfehlen? Wenn nein, bitte Fresse halten. Danke! http://bfy.tw/Jl6Z Und wir lieben dich auch alle! merciless
Für UML gibt es viele und gute Bücher. UML ist für viele Dinge gut, die keine Zeitkomponenten haben, in erster Näherung wo auch funktionale Sprachen gut sind. Ja, ein Codegerüst (Klassen) könnte man erstellen, das dient aber eher nur der Übersetzung zwischen Modellierern, die nicht programmieren und Programmierern, die nicht modellieren. Ein Buch dazu ist sinnlos. So als würde man beschreiben, wie man Google translate benutzt ohne eine der Sprachen zu kennen.
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.