About

This page contains a single entry from the blog posted on February 3, 2008 7:28 PM.

The previous post in this blog was Ideen für die Konfigurationsverwaltung.

The next post in this blog is Eine Sorge weniger! -- und die nächste folgt sogleich..

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31

« Ideen für die Konfigurationsverwaltung | Main | Eine Sorge weniger! -- und die nächste folgt sogleich. »

Ein Paar Dia-Gramm

OK, diese Diagramme wurden nicht mit Dia erstellt, sondern mit Umbrello. Aber nachdem Philipp schon solch schöne UML-Bildchen online gestellt hat, muss ich natürlich nachziehen ;-)

Das folgende Diagramm fasst noch einmal bildlich zusammen, was ich in einem anderen Post zum Ablauf einer Transaktion beschrieben hatte. Übrigens wäre ich noch immer SEHR dankbar, wenn mir jemand der Erfahrung mit dem Thema hat, ein paar Kommentarzeilen zu dem Eintrag da lassen würde!

Ablauf einer Transaktion

Das zweite Diagramm soll dem unbedarften Leser einen ungefähren Überblick über den Ablauf der Request-Verarbeitung verschaffen. In Wahrheit passieren noch ein paar unwesentliche Schritte mehr, aber ich denke nicht, dass das Weglassen dieser Schritte einen falschen Eindruck vermitteln könnte:

Ablauf eines Requests

Fragen? Ideen? => dafür gibt's das Kommentat-Formular unten ;-)

TrackBack

TrackBack URL for this entry:
http://www.innoq.com/movabletype/mt-tb.cgi/2999

Comments (3)

Zum ersten Diagramm: Ich würde meinen, dass die Synchronisationsbalken semantisch falsch sind. (Klar sehen sie toll aus, allerdings meinst Du an den Stellen höchstwahrscheinlich keine Synchronisation.

Die Diagramme finde ich beide gut. Allerdings ist mir nicht klar, in welchem Kontext Du sie verwenden möchtest. Möchtest Du den vollständigen Ablauf skizzieren, solltest Du vielleicht noch skizzieren, welche Kästen Rails-spezifisch sind und welche Deine Programmteile repräsentieren.

Für die Ausarbeitung solltest Du tendenziell Diagramme mit kleinerem Fokus verwenden, da deren Erläuterung sonst einigermaßen aufwendig würde.

Danke für den Hinweis mit den Balken -- ich hatte schon so eine Befürchtung ;-)

Zum Kontext: Ich möchte damit in der Tat den Gesamtablauf skizzieren -- für die Authentifizierung arbeite ich noch an einer detaillierteren Version, die dann fertig wird wenn ich das Thema PAM und NSS unter Linux auch abgearbeitet, sprich meinen Senf dazu in der Arbeit niedergeschrieben, habe.

Übrigens habe ich so meine lieben Schwierigkeiten damit, alle Zusammenhänge in meiner Arbeit ordentlich in UML abzubilden -- die ganze "Magie" von Rails kann und will ich nicht abbilden, aber ganz ohne machen viele eigene Sachen auch keinen Sinn... Das wäre sicher mal noch ein Thema für eine Diplomandenrunde.

Wenn Dein Fokus auf den von Dir erbrachten Leistungen beruht, würde ich die Rails-Magie so gut es geht ignorieren.

Letzten Endes ist das Programmiermodell sehr sprechend und nachvollziehbar, so dass es genügen sollte, als Elemente Deine Quellartefakte und deren Konstrukte zu verwenden. Selbst bei der Darstellung dynamischer Aspekte ist es nicht nötig, jede Zwischenstation eines Aufrufs zu zeigen.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)