Diagramm-Sprache-Diagramm: Wenn Bilder sprechen lernen: Teil 4

DSD und das Klassendiagramm

Die Transformation von Klassendiagrammen – Das Schaf im Wolfspelz

Ja, ein Klassendiagramm ist tatsächlich ein Schaf im Wolfspelz. Viele Stakeholder wirken mit dem ersten Blick auf ein Klassendiagramm wie versteinert und sind der Meinung, dass sie ein solches Diagramm nie verstehen werden. Mit der Transformationsmethode, die wir Ihnen im Folgenden vorstellen, werden wir diesen Stakeholdern die Angst nehmen – denn Klassendiagramme sind auf den zweiten Blick gar nicht so furchterregend, wie sie auf den ersten erscheinen.

Im Folgenden möchten wir Ihnen jedoch nur einen Teil des Regelwerks für Klassendiagramme vorstellen und damit einen Einblick auf das Ganze gewähren. Daher beziehen wir uns auf die Umsetzung von fachlichen Analysemodellen in Form eines UML-Klassendiagramms in sprachliche Systemanforderungen. Zusätzlich werden keine fachlichen Rollen oder Benutzerrollen, sowie Systemkomponenten in Form von Klassen beschrieben.

Transformation eines UML-Klassendiagramms

Auf der höchsten Ebene sollten Sie zunächst mit der Umsetzung der Klassen in natürlich-sprachliche Anforderungen beginnen. Dazu haben wir die Regel:

  • Im <Systemname> muss <Klassenname> <Erklärung> bedeuten.

aufgestellt. Neben dem Systemnamen, Klassennamen und der Erklärung sollten Sie in jedem Fall auch die rechtliche Verbindlichkeit „muss“ angeben. Wir beschränken uns in diesem Fall auf das „muss“, da wir uns in einem Fachglossar nur auf eindeutige und verbindliche Aussagen berufen können. Wünsche, Absichten oder Vorschläge sind unserer Meinung nach ungeeignet.

 

Durch diese erste Regel definieren Sie die Bedeutung jeder Klasse und geben dem Leser (Stakeholder) einen Einblick in die Thematik, die dieses Diagramm darstellt. Im nächsten Schritt beziehen wir uns auf die Transformation der Attribute einer Klasse. Wenden Sie die Regel:

  • Im <Systemname> muss <Klassenname> durch <Attributname> beschrieben werden.

an, um Attribute in gute sprachliche Systemanforderungen umzuwandeln. Falls die umzuwandelnde Klasse sehr viele Attribute besitzt, sollten Sie, um die Lesbarkeit zu verbessern, die Attributnamen in Form einer Aufzählung beschreiben.

Damit hätten wir die Verbindung zwischen der Klasse und ihren Attributen beschrieben. Zusätzlich müssen die einzelnen Attribute definiert werden. Dazu verwenden Sie einfach folgende Regel:

  • Im <Systemname> muss <Attributname> <Klassenname> <Erklärung> bedeuten.

Ein Beispiel für diese Regel könnte zum Beispiel

„Im AROMA-System muss der Preis einer Speise den Bruttopreis pro Stück bedeuten“

sein.

Mit den bisher vorgestellten Regeln können wir Klassen und deren Attribute beschreiben, jedoch fehlen noch die Verbindungen zwischen den einzelnen Klassen. Eine Art einer Verbindung ist zum Beispiel die Binäre Assoziation. Mit einem aussagekräftigen Verb und durch Multiplizitäten wird diese Verbindungsart definiert. Dafür haben wir die Regel,

  • <Assoziationsname> muss im <Systemname> den Prozess bedeuten, <Quellenklassenname> <Präposition> <Multiplizität> <Zielklassenname> <Erklärung>.

aufgestellt.

Ein Beispiel für diese Regel könnte zum Beispiel

„Verbuchung muss im AROMA-System den Prozess bedeuten, eine Speise zu keiner oder einer Rechnung zuzuweisen, damit daraus die Kontobelastung erfolgen kann.“

lauten.

Die <Erklärung> für diese Regel, kann leider nicht aus dem Analysemodell gelesen werden, sondern muss eigenständig ergänzt werden.

Eine weitere Verbindungsart ist die Generalisierung. Sie beschreibt die Beziehung zwischen einer speziellen und einer generellen Klasse. Eine Generalisierung wird für eine Oberklasse in einem verbindlichen Fachglossar mit folgender Formulierung beschrieben:

  • Im <Systemname> muss <Oberklassenname> die Verallgemeinerung von <Unterklassenname> bedeuten.

Dabei kann es für eine Oberklasse n Unterklassen geben. Um die Lesbarkeit und Übersichtlichkeit zu bewahren, sollte bei vielen Unterklassen die Form der Aufzählung für die einzelnen Unterklassen verwendet werden. Ebenso können Sie für jede Verbindung zwischen Ober- und Unterklasse einen einzelnen Satz schreib

Diagramm – Sprache – Diagramm: unser Fazit

Dies war der vierte und letzte Blogeintrag unserer Serie zu Diagramm – Sprache – Diagramm. Wir haben Ihnen die Transformation von:

  • Use-Case-Diagrammen
  • Aktivitätsdiagrammen
  • Zustandsautomaten und
  • Klassendiagrammen

der UML vorgestellt. Wir hoffen, wir konnten damit Ihnen und ihrem Projekt weiterhelfen. Falls Sie Fragen zu dem bisher Vorgestellten, oder Interesse an dem vollständigen DSD-Regelwerk haben, schreiben Sie uns eine Mail an Heureka@sophist.de.

Ihre Meinung können Sie uns auch gerne über die Kommentarfunktion mitteilen – über Ihr Feedback sind wir jederzeit dankbar.

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert