Das deutsche Python-Forum

Ich suche ein gutes Buch über UML2. Es sollte möglichst nicht speziell auf Java abziehlen, also nicht "folgendes Java-Programm/System könnte man so in UML zeichnen", sondern von der späteren Implementierungssprache möglichst unabhängig sein. Im Idealfall sollten auch die Probleme mit dynamisch typisierten Programmiersprachen behandelt werden, also wo UML da Probleme hat, und vielleicht auch Lösungsmöglichkeiten aufgezeigt werden.

Such ich auch. Sag bescheid, wenn du etwas gefunden hast.

Also ich fand "UML2 glasklar" relativ brauchbar zum Lernen in der Klausur, "UML @ Work" ging auch noch einigermaßen. Natürlich nichts zu dynamischen Programmiersprachen, aber da haben die Java-Leute (gerade die!) ja oft noch die Meinung dass es Spielzeug sei.

Werde UML aber hoffentlich nie wieder machen müssen.

@Leonidas: Zur Planung oder zum Visualisieren von grösseren Zusammenhängen und Systemen ist es IMHO ganz nett. Jetzt nicht um so Java-Roundtrip-Like riesige Klassen mit allen Datenattributen, Methoden, und deren Typen zu zeigen, sondern eher um Zusammenhänge aufzuzeigen, die im Code nur über drei Ecken bestehen und dementsprechend dort nicht so leicht zu lesen sind. Und für "externe" Leute, damit die sich ein Bild von den Daten und der Aufteilung und Verarbeitung im Programm machen können. Auf dem Level kann auch die Sachbearbeiterin hilfreiche Kommentare abgeben wo sie nur mit dem Kopf schütteln würde, wenn man ihr blanken Quelltext zeigt.

UML finde ich persönlich viel zu umständlich und unübersichtlich. Ich habe mal ein bisschen recherchiert und bin auf OPDs gestoßen:

http://www.er.byu.edu/er2003/slides/ER2003PT1Dori.pdf

Davon bin ich sehr angetan, leider ist die dort erwähnte Software mit rund 3000 EUR recht teuer. Und alternative Implementierungen gibt es anscheinend noch nicht.

@Pekh: Naja, UML ist halt Industriestandard und die ganzen Java-Drohnen verwenden es.

BlackJack hat geschrieben:@Pekh: Naja, UML ist halt Industriestandard und die ganzen Java-Drohnen verwenden es.

Naja, zum Einen wird es immer Standard bleiben, wenn die Leute nicht anfangen, Alternativen zu nutzen, zum Anderen ist es - für mich als Einzelkämpfer - schlicht Overkill. Meiner Meinung nach dient man der Übersicht nicht durch ständiges Umdenken zwischen den Diagrammen. Im Übrigen finde ich die Darstellung der OPDs auch für Laien anschaulicher als UML. Und die parallele Darstellung als Pseudo-Englisch (OPL) ist ebenfalls recht hilfreich.

@Pekh: Als Einzelkämpfer hat mans in der Hinsicht immer gut … aber wenn der Auftraggeber UML will, tja, dann bleibt nur der Biss in den sauren Apfel.

BlackJack hat geschrieben:@Leonidas: Zur Planung oder zum Visualisieren von grösseren Zusammenhängen und Systemen ist es IMHO ganz nett.

Dafür finde ich es zu formal und dadurch umständlich. Zum Darstellen von Zusammenhängen finde ich eine halbwegs brauchbare ad-hoc Syntax die ggf. UML-ähnlich ist ok, aber der Aufwand das dann gültiges UML2 werden zu lassen ist mir einfach viel zu groß.

Ich verstehe dass es so formal ist damit eben so Roundtrips möglich sind, aber davon halte ich nicht viel.

@Leonidas: Ich weiss nicht, so kompliziert fand ich das bisher nicht, aber vielleicht verwende ich es auch nur falsch. Ich bin bis jetzt jedenfalls immer davon ausgegangen, dass so ziemlich alles optional ist und man das nicht mit Details belasten muss, die nicht gebraucht werden, um dass zu zeigen, was man zeigen will. Und damit ist es eigentlich auch nicht zu überladen.

BlackJack hat geschrieben:@Leonidas: Ich weiss nicht, so kompliziert fand ich das bisher nicht, aber vielleicht verwende ich es auch nur falsch. Ich bin bis jetzt jedenfalls immer davon ausgegangen, dass so ziemlich alles optional ist und man das nicht mit Details belasten muss, die nicht gebraucht werden, um dass zu zeigen, was man zeigen will. Und damit ist es eigentlich auch nicht zu überladen.

Falsch verwendet ist wohl falsch gesagt, ich würde die UML auch nur so verwenden wie du's meintest. Aber wenn man sie vollkommen korrekt in der richtigen Reihenfolge mit allen Elementen verwendet, einschließlich solcher Konstrukte wie Metaklassen in bestimmten Diagrammen und die Diagramme verknüpft erzeugt die UML unfassbar viel Overhead.

Dann fühlt sich die UML fast an wie eine eigene Programmiersprache, die Vorteile des schnellen "ich modelliere, damit ich Probleme und Strukturen früh erkenne" gehen verloren. Dafür kann man UML automatisiert abbilden auf Programmiersprachen und umgekehrt leichter Code generieren, wenn man sich vollständig daran hält.

(Zumindest sind das meine persönlichen Erfahrungen. Wahrscheinlich irr ich mich.)

Ich halte es für einen Trugschluss sämtliche Aspekte der Softwareentwicklung in allen Bereichen mit einer einzigen Modellierungssprache (hier UML) erschlagen zu wollen. Das ist ungefähr so, als wollte man alles in C programmieren.

Ich habe allerdings gerade die starke Vermutung, dass ich mich >50% meines restlichen Studiums mit dem Entwurf von und der Codegenerierung aus (Modellierungs-)DSLs beschäftigen werde --
auf Basis von UML, die eben auch eigene Notationen zulässt.

Das Buch suche ich allerdings für eine Prüfung in Softwaretechnik.

@Pekh: Klingt interessant, danke!