Eventorientierte Applikation -> Diagrammtyp?
Hallo Community!
Ich habe ein Windows Form projekt mit C# erstellt. Ich habe sehr viel Wert auf die Trennung des Busines Logic - und GUI Layer gelegt.
Ein Klassendiagramm reicht leider nicht für die Dokumentation, weil nicht-Programmierer Klassendiagramme nicht verstehen (Ich muss es leider auch anderen Personen vorstellen können). Flussdiagramme versteht jeder, nur ist es überhaupt nicht geeignet, um sowas darzustellen. Wie macht ihr das?
Gruss,
.unreal
In UML gibt es für sowas Aktivitäts- und Sequenz-Diagramme. Zeigen beide den Programmfluss und die beteiligten Instanzen. Mit Sequenzdiagramme haben eher eine funktionsorientierte Sicht (wie funktioniert etwas genau), während Activitätsdiagramme eher objektbezogen sind (was geht rein, was geht raus).
Hallo .unreal,
Ein Klassendiagramm reicht leider nicht für die Dokumentation, weil nicht-Programmierer Klassendiagramme nicht verstehen
Das halte ich bezogen auf die Business-Klassen für ein Gerücht oder für ein Zeichen, dass die Klassen sich zuwenig an der Realität orientieren.
Ansonsten habe ich gute Erfahrung mit Folien von den Fenstern der Anwendung gemacht und anhand dieser Folien typische Abläufe bzw. Aufgaben erklärt.
herbivore
Für die Kommunikation mit dem Kunden werden in der Regel Use-Case-Diagramme verwendet. Die zeigen den Ablauf aus Benutzersicht. Dabei werden technische Details völlig verborgen und es geht nur noch um den Kunden verständliche Begriffe wie "Kundennummer eingeben", "Betrag buchen", etc.! Die Ablaufe werden durch Pfeile gekennzeichnet. Sowas wird auch gerne als Spezifikationstechnik verwendet.
Keine Kunde will ernsthaft ein Klassenmodell sehen. Was den interessiert, ob seine Vorstellungen richtig verstanden wurden und in die richtigen Schritte zerlegt wurden. Den Rest überlaßt er dann dir. 😉
Hallo svenson,
dass die Kunden kein Klassenmodell sehen wollen, kann schon sein. Ich habe mich nur dagegen ausgesprochen, dass sie es nicht verstehen würden.
Im Klassenmodell tauchen Begriffe wie z.B. Versicherter, Adresse, Vertrag u.ä. auf. Also alles Begriffe mit denen die FA umgeht. Sie können also durchaus am Klassenmodell sehen, ob der Versicherte alle Attribute hat, die sie brauchen und ob dem Versicherten nur eine oder mehrere Adressen zugeordnet werden können. Das wäre ein Klassenmodell auf Analyseebene.
Bei Firmenanwendung gehört m.E. das Klassenmodell deshalb sogar mit zur Spezifikation, die dem "Vertrag" zwischen Fachabteilung und DV-Abteilung zugrundeliegen sollte.
Wenig bis nichts anfangen kann die FA natürlich mit Klassen für Observer, Singelton, Abstact Factory & Co, die normalerweise aber erst im Klassenmodell auf Designebene auftauchen.
herbivore
Natürlich ist ein Klassenmodell spannend. Wenn ich Software in Unterauftrag fertigen lassen würde, wäre das für mich (!) natürlich ein wichtiges Dokument. Meine persönlicher Erfahrung ist aber, dass Unternehmen, die nicht selbst Software entwickeln, Klassenmodelle tatsächlich nicht wirklich verstehen können. Für uns wäre das Klassenmodell vor allem interessant um die Freiheitsgrade ablesen zu können. Damit ist der 0815-Kunde m.E. völlig überfordert. Dies kann allenfalls ein externer Berater leisten, der ja selten existiert.
Insofern ist eine Darstellung wie Use-Cases oft hilfreicher, weil die Menschen ihre Handlungen und auch Daten wiederfinden und sie gleichzeitig im Kontext stehen (Reihenfolge, Bedingungen, Verzweigungen, Ausnahmen). Diese Dimensionen zeigt ein Klassenmodell nicht auf, weil es ein statisches Modell ist.
Hallo svenson,
Insofern ist eine Darstellung wie Use-Cases oft hilfreicher
Es ging ja (mir) nicht darum eine einzige Diagrammart zu finden, die alles erschlägt. Die verschiedenen Diagrammtypen ergänzen sich.
herbivore