Hallo zusammen Ich würde gerne meine Programme und vorallem Kommunikationsprotokolle sinnvoll dokumentieren. Nun scheint ja UML das "non plus ultra" zu sein. Leider habe ich bisher noch überhaupt keine Erfahrungen mit UML gemacht. Deshalb würde ich dies gerne mit einem Buch nachholen. Da UML ja vorallem für Objektorientierte Sprachen wie Cpp etc gedacht ist, frage ich mich, welches Buch meine Bedürfnisse wohl am ehesten abdeckt. Ich habe dieses hier gefunden: http://www.thalia.de/shop/home/artikeldetails/uml_2_5/christoph_kecher/ISBN3-8362-2977-3/ID40480622.html Was meint ihr dazu? Gibts evtl. empfehlungen? Gerne würde ich ein Buch bevorzugen, welches den aktuellen UML 2.5 Standard beschreibt. Danke
:
Verschoben durch Admin
Scheint ein gänzlich unbekanntes Thema zu sein...
Ich würde nicht zu sehr auf UML zur Dokumentation setzen, das ist doch eher zur Planung gedacht. Um programme zu dokumentieren empfehle ich Oxygen für die API Doku, und LaTeX für die Userdoku, weil text statt Grafiken. Für Kommunikationsprotokolle würde ich auch LaTeX empfehlen, oder sogar gleich ein RFC Schreiben.
> Nun scheint ja UML das "non plus ultra" zu sein.
Nein. Die Entwickler der "Sprache" und die Entwickler entsprechender
Tools trommeln natürlich laut und fleißig Werbung dafür.
Tatsache sit, dass UML Diagramme zwar eine eindeutig definierte Sprache
haben. Aber in der Realität werden die Diagramme trotzdem meistens
falsch gezeichnet. Ich denke, entweder ist UML zu kompliziert oder
unzureichend, um realen Anforderungen zu entsprechen.
Hinzu kommt: Der Große Traum, aus UML Diagrammen heraus automatisch
Programmcode zu erzeugen, ist auch noch nicht wahr geworden. Es gibt
zwar vorzeigbare Ansätze, doch in realen Busienss Anwendungen hat das
zumindest bei drei Konzernen, wo ich geaarbeitet habe, kein einziges mal
zufriedenstellend funktioniert. Und vorhandene Programme reverese
engineeren, so dass man sie anschließend mit Hilfe von UML Tools
erweitern kann ist erst Recht ein unerfüllter Traum geblieben.
Aber: Manager lieben UML. Entwickler sollten zumindest mal die
Grundlagen der UML Diagramme lernen.
Schau Dir mal die Webseiten von "Enterprise Architect" an. Im
Benutzerhandbuch gibt es ein schönes Kapitel zu den Grundlagen von UML,
das war meine Bassis zu lernen. Ich schätze, dass kann man dort irgendwo
kostenlos runterladen.
Apropos Dokumentation: Dieses "Enterprise Architect" ist kinderleicht zu
bedienen und eignet sich sehr gut, um Projekte und Programme zu
dokumentieren. Ist fast so simpel wie Visio, falls du das kennst.
Nur einen Tipp dazu: Verbinde Enterprise Architect nicht mit einem
Source Repository (Subversion, CVS, Git oder so). Diese Funktion ist
schlecht umgesetzt, da bekommst du mehr Probleme als Vorteile. Mach
stattdessen lieber regelmäßig ein Backup von der Projektdatei (das ist
intern eine MS-Access Datenbank, nur mit anderer Dateiendung). Man kann
Änderungen zwischen mehreren Versionen auch ohne Repository herausfinden
und auflisten.
Auf dieser Seite findest Links zu einem kaufbaren Buch und einem kostenlosen Grundlagen-PDF: http://www.sparxsystems.de/ressourcen/enterprise-architect-uml-buch/ Es gibt bei der Firma noch mehr Doku zu UML, die habe ich aber auf die Schnelle nicht gefunden.
> Scheint ein gänzlich unbekanntes Thema zu sein...
Andere Leute schlafen nachts
Stefan U. schrieb: > Apropos Dokumentation: Dieses "Enterprise Architect" ist kinderleicht zu > bedienen und eignet sich sehr gut, um Projekte und Programme zu > dokumentieren. Ist fast so simpel wie Visio, falls du das kennst. Dieses Enterprise Architect is ein Jammer. Ich muss täglich beruflich damit kämpfen und würde sofort umsteigen auf was Vernünftigeres wenn mein Auftraggeber es erlauben würde und ich eine gute Alternative kennen würde. Versionierung kannste vergessen, sorgfältig bearbeitete Diagrammlayouts werden immer wieder versaut, die GUI ist unintuitiv und nicht konsistent; ich verstehe nicht dass der Sch... sich noch so gut verkauft. Aber genug gejammert. Für nicht al zu komplexe Projekte kann man mit EA arbeiten. Kostenlose Open-Source Alternative wäre Modelio. Das hat auch seine Macken, aber man kommt für kleinere Projekte m.M.n. schneller ans Ziel, größere Projekte kann aber auch Modelio nicht anständig. EDIT: Wenn's aber nur um das (Nach)dokumentieren van Source-Code geht, ist Doxygen, wie oben schon erwähnt, viel sinnvoller.
:
Bearbeitet durch User
Hallo, der UML-Hype ist IMHO voellig uebertrieben. Fuer uns war es effizienter, Features und Parameter zumindest in einem eigenen XML Dialekt zu beschreiben. Fuer Protokolle wuerde ich auch den RFC-Stil bevorzugen und von zuviel grafischem Ueberfluss absehen, ASCII-Schemas lesen sich da besser. Aus XML laesst sich sehr gut Code und Dokumentation (Tabellen) generieren. Das ist soweit recht robust und besser zu unterhalten als closed Source Loesungen.
> Dieses Enterprise Architect is ein Jammer. Interessant, wie extrem unterschiedlich wir das programm bewerten. Aber das ist Ok, über Geschmack soll man nicht streiten. > Versionierung kannste vergessen Ja, allerdings. 100% Zustimmung > Wenn's aber nur um das (Nach)dokumentieren van Source-Code geht, > ist Doxygen, wie oben schon erwähnt, viel sinnvoller. Jupp. Diagramme kann ja da notfalls als Grafikdatei einbetten..
Stefan U. schrieb: >> Dieses Enterprise Architect is ein Jammer. > > Interessant, wie extrem unterschiedlich wir das programm bewerten. Aber > das ist Ok, über Geschmack soll man nicht streiten. Das hat nix mit Geschmack zu tun, oder magst du Diagramme 20x wiederherstellen zu müssen? Ich verbringe mindestens 20% meiner Zeit damit alle (!) Diagramme in meinen Modellen zu durchforschen nach irgendwelche von EA automagisch initierte Zerstörungen. |-( Oh, und hast du schon mal versucht in einem Sequence-Diagramm mit Fragments eine neue Nachricht einzufügen? Und schon mal was probiert mit "Alternate Image"s? Und warum sind manche Änderungen keine Änderungen, und können manche Änderungen rückgängig gemacht werden, andere aber nicht?
Holger K. schrieb: > Hallo zusammen > > Ich würde gerne meine Programme und vorallem Kommunikationsprotokolle > sinnvoll dokumentieren. Für Kommunikationsprotokolle bietet sich aus der UML das Sequenzdiagramm an: https://en.wikipedia.org/wiki/Sequence_diagram Die Teilnehmer der Kommunikation kann man ganz gut mit einem Blockschaltbild aufzeigen.
:
Bearbeitet durch User
Zum Spielen kann ich dir Software Ideas Modeler empfehlen ist für privat kostenlos. Ich benutze davon hauptsächlich das package Diagramm zur Modularisierung und das Klassendiagramm zur groben Übersicht beim Entwurf. Aber ein C++ Programm komplett auf UML abzubilden macht mehr Ärger als es nützt.
> magst du Diagramme 20x wiederherstellen zu müssen Ja, ich habe das auch erlebt. Das Programm ist zickig und bringt manchmal Diagramme durcheinander, die man gerade gar nicht aktiv bearbeitet hat. Dafür ist es aber auch relativ preisgünstig. Eine bessere Alternative habe ich noch nicht gesehen. In den vergangenen 5 Jahren habe ich allerdings deutliche Fortschritte beobachtet. Mit jeder Version wurde das Programm deutlich zuverlässiger. Zumindest bei den Funktionen, die ich genutzt hatte. > Aber ein C++ Programm komplett auf UML abzubilden macht mehr > Ärger als es nützt. Sehe ich auch so.
Holger K. schrieb: > Hallo zusammen > > Ich würde gerne ... vorallem Kommunikationsprotokolle > sinnvoll dokumentieren. > > Nun scheint ja UML das "non plus ultra" zu sein. Nein, ist es nicht. Es ist halt modern. Kommunikationsprotokolle wurde schon lange vor UML dokumentiert. Zum Beispiel wurde die ITU 1865, ca. 130 Jahre vor UML, gegründet und gibt seither unter unterschiedlichen Namen (CCITT, ITU-T) Standards für Kommunikationsprotokolle heraus. Typischerweise werden Kommunikationsprotokolle dadurch dokumentiert, dass man sie zuerst in Schichten zerlegt, und die Schichten soweit es geht dem OSI Referenzmodell zuordnet. https://de.wikipedia.org/wiki/OSI-Modell Dann wird jede Schicht auf der das Kommunikationsprotokolle arbeitet möglichst unabhängig als Protokoll beschrieben. Die typischen Mittel zur Beschreibung sind Zustandsautomaten, Sequenzdiagramme (hat UML übernommen) und Beschreibungen der Datenformate. Letzteres entweder direkt auf Bit- und Byte-Ebene (als Listen oder Tabellen) oder mit Beschreibungssprachen für Datenstrukturen. Da gibt es ganz schlimmes Zeug :-( Die IP-Protokolle mit ihren RFCs sind nicht zuletzt deshalb so populär geworden, weil man die lesen und verstehen kann. Die verwenden allerdings auch kein UML, sondern normalerweise Zustandsautomaten und Beschreibungen der Datenformate auf Bit- und Byte-Ebene. Wenn du UML nehmen willst, dann sind - Sequenzdiagramme - Zustandsdiagramme noch am nützlichsten. Ebenso können - Kommunikationsdiagramme - Zeitverlaufsdiagramme - Aktivitätsdiagramme nützlich sein. Die letzten drei werden allerdings ziemlich selten in UML verwendet, zumindest in dem UML das mir so unterkommt. Zu Dekorationszwecken kannst du noch andere UML Diagramme verwenden, wie das Verteilungsdiagram. Aber das beschreibt mehr die Systemarchitektur denn das Kommunikationsprotokoll. All diese Diagramme haben übrigens schon vor UML in ähnlicher Form existiert. So ein kleiner Witz nebenbei, Ivar Jacobsen, einer der Väter von UML, hat in seinem früheren Leben an der SDL (Specification and Description Language, ITU-T Z.100) mitgearbeitet. Das ist eine standardisierte Sprache zur Definition von Protokollen.
Vielen Dank für eure Antworten. Diese haben mir sehr weitergeholfen.
Ich kann mich dem gesagten nur anschließen. Sequenzdiagramme sind super und in vielen Protokoll Spezifikationen zu finden. Das gleiche gilt für Zustandsdiagramme. Da man seine Zustandsautomaten meist eh mit einem Tool wie z.B. Stateflow erstellt, kann man hier einfach Screenshots von machen und fertig ist die halbe doku.
Ich habe mich vor Jahren mal mit UML beschäftigt, es aber sehr schnell als für meine Zwecke völlig ungeeignet abgetan. Das liegt vor allem daran, dass ich den eigentlichen Sinn jeglicher Formalisierung vor allem darin sehe, den Weg zu einer, wie auch immer gearteten, maschinellen Verarbeitung zu ebnen. Graphische Repräsentationen einfach und effizient maschinell zu verarbeiten scheint mir auf absehbare Zeit noch ziemlich utopisch zu sein. Es ist, eine entsprechend gewählte Syntax vorausgesetzt, ziemlich einfach, einen Text zu parsen. Einmal geparst kann er meist ohne Schwierigkeiten in jede beliebige andere Repräsentation umgewandelt werden, auch in eine graphische. Tools dazu sind verfügbar, auch kostenlos. Man stelle sich aber mal den umgekehrten Weg vor: Ich habe die Graphik zum Beispiel eines Zustandsgraphen, bestenfalls also eine Menge von geometrischen Figuren mir Koordinaten und Abmessungen. (Schlimmstenfalls eine Pixelgraphik!) Der dahinter liegende Zusammenhang ist zwar für einen Menschen einfach zu erfassen, nicht aber für eine Maschine. Welchen einfachen Weg gibt es, zum Beispiel die Zustandsübergangsfunktion zu extrahieren? Wie kann ich auf eine Menge von, für die Maschine zunächst zusammenhanglosen, Kreisen und Pfeilen auf einfache Weise eine Metrik anwenden oder Code daraus generieren? Das geht ohne teure Spezialsoftware nur manuell. Wenn mir aber nur die manuelle Auswertung bleibt, macht eine Formalisierung in meinen Augen eigentliche keinen nennenswerten Sinn mehr. Um es kurz zu sagen, es ist viel einfacher, aus einem Text ein Graphik zu machen als umgekehrt, UML geht in meinen Augen also genau den verkehrten Weg. Alles was kompliziert ist, ist aber erfahrungsgemäß für Dokumentationszwecke auf Dauer ohnehin nicht sehr erfolgreich.
Trotzdem wird wohl niemand behaupten wollen, dass eine Dokumentation nur aus Text ohne jegliche Abbildung bestehen soll. Und da bieten sich manche UML-Diagramme eben für an.
also wir arbeiten seit einiger Zeit sehr erfolgreich mit UML, zuerst hatten wir es mit dem EA probiert, der ist meiner Meinung nach tatsächlich schon zu komplex. Dann haben wir mit dem simpleren SiSy angefangen und seit dem machen wir nur noch in UML. Hauptsächlich für AVR und XMC Controller. Die Grafik ist da eben kein Bild. Die wird aus dem Modell nur als View generiert genau wie der Code auch nur ein "View" des Modells ist. Wer UML als eine Anhäufung von Bildchen ansieht hat UML nicht geschnallt. Wenn man sich erst mal daran gewöhnt hat Programmcode auf höherem Abstraktionsniveau zu konstruieren will man zur Quellcodeperspektive nicht mehr zurück. Die anfängliche Angst des scheinbaren Kontrollverlustes über den Code ist absolut unbegründet. Der Codegenerator arbeitet ganz stur und simpel das ab was du modelliert hast. Hast du Schrott modelliert kommt bei der Codegenerierung schrott raus. Hast du sauber modelliert kommt super Code aus der Engine. Durch die Architekturzentrierung und die Adlerperspektive entsteht Systemarchitektur bei der Vorgehensweise auf einem ganz anderem Level. Und das beste ist man wird viel schneller fertig ;-) Nachteil bei SiSy ist dass es nur C++ und keinen C Code generiert. Auf den ARMs ist das kein Problem aber AVRs unter 16K FLASH bekommt man recht schnell voll :-( RF
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.