Sequenzdiagramme

T

tanj

0
Moin,

wir nehmen im Informatikunterricht in der Schule Sequenzdiagramme durch, ich wollte hier einfach mal nachfragen in welchem Umfang das bei der Entwicklung von Software eine Rolle spielt. Mein bisheriger Eindruck von Sequenzdiagrammen ist, dass sie schon bei kleinen Beispielen wie wir sie in der Schule verwenden, extrem unübersichtlich und sehr groß werden. Wenn ich mir dann erst vorstelle wie groß so was werden würde wenn man so was z.B. bei einem Office-Programm anwenden würde, müsste das von der Seitenzahl in die Tausende gehen.

Bitte nur die Leute antworten, die Ahnung von der Sache haben, just for fun das erste Ergebnis von Google wiedergeben ist nicht wirklich eine Antwort...

Gruß
 
man wird mit so einem Sequenzdiagramm sicherlich keine ganze Software darstellen können, aber das kann man auf Grund der Komplexität und Modularität von großen Projekten sowieso mit keinem Diagramm - auch nicht mit Struktogrammen oder Programmablaufplänen.

Man kann mit solchen Diagrammen lediglich kleine Abschnitte modellieren.

Hab selbst noch keine Sequenzdiagramme benutzt und mir auch erstmal schnell welche bei Wikipedia angeschaut.
Es geht hier - wenn ich das so richtig überblicke - auch weniger um eine konkrete Implementierung, sondern ehr um allgemeine Formulierung von Problemen / zeitliche Abläufe von Interaktionen und Prozessen, etc.

In der Firma, wo ich z.Zt. jobbe, nutzen wir zum Darstellen von Prozessen + User-Interaktionen z.B. EPK-Diagramme (http://de.wikipedia.org/wiki/Ereignisgesteuerte_Prozesskette), um die Anforderungen, die wir vom Requirements-Team bekommen, visuell darzustellen und Lücken in den Anforderungen / unzureichend formulierte Spezifikationen aufzudecken.

Fazit: schaden kann's definitiv nicht, wenn man mal paar Diagramm-Typen kennt...
 
Seq.-Diagramme gehören eigentlich mehr in die Welt eines "IT-Architekten". Es kommt aber auf die Geflogenheiten der Firma an in der arbeitest.
Ob du selbst welche erstellen musst kann dir keiner vorhersagen, nur lesen solltest du UML auf jeden fall können.
 
Ich kenne eigentlich nur Fluss- und Nassi/Schneidermann-Diagramme aber der Unterschied scheint mir nicht allzu gross zu sein. Ich benutze Diagramme eigentlich eher selten aber sie haben durchaus ihre Nützlichkeit. Wenn du Mitglied eines Entwicklungsteams bist (z.B. im Rahmen eines Uni-Projekts) können sie hilfreich sein um deine Ideen zu verdeutlichen. Ausserdem können sie dir helfen komplexe Funktionen auseinanderzunehmen und übersichtlich zu gestalten damit du einen Leitfaden bei der Implementierung hast (z.B. ein Computergegner für ein Spiel indem du diverse Tests durchführen musst).
 
Oh, der Unterschied ist überwältigend.
Nassi-Shneiderman-Diagramme modellieren eher den Ablauf einer Funktion / Methode / evtl. Algorithmus (such dir was aus).
Sequenzdiagramme modellieren die Interaktion von Objekten.

Aus eigener Erfahrung kann ich nur sagen, dass Sequenzdiagramme durchaus wichtig sein können, mein letztes Nassi-Shneiderman-Diagramm dagegen hab ich in der 7. Klasse im "Informatik-Unterricht" gesehen.
 
Ich habe schon in mehreren Firmen als Softwareentwickler gearbeitet und Sequenzdiagramme sind mir dabei nie unter gekommen. Die Basis um eine Software zu entwickeln waren bei mir immer Konzepte die vom Kunden bzw. vom Kunden in Zusammenarbeit mit einem Konzeptionär enstanden sind.

Normalerweise stellt man nur (kompliziertere) Teilbereiche einer Software in Diagrammen dar, da alles andere viel zu viel Aufwand wäre. Man darf dabei ja nicht vergessen, daß solche Diagramme wenn sie zur Projektdokumentation benutzt werden ja bei jeder Änderung angepasst werden müssen. In meinem aktuellen Projekt werden zur Dokumentation Anwendungsfalldiagramme (Use Cases) verwendet, die an sich nicht zu tief im technischen Bereich liegen. Die wichtigsten Diagrammarten die mir bis jetzt untergekommen sind, sind ER-Diagramme (Entity Relationship Diagramme) um Datenbankbeziehungen darzustellen und Klassendiagramme (im OOP-Bereich) um mal schnell z.B. einem Kollegen Abhängikeiten/Beziehungen von Klassen zu erklären.

Gruß odigo
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben