Endlich, es ist so weit – es geht ans Eingemachte! Nachdem wir Ihnen im Rahmen dieser Blogserie das Wissen zur Hand gegeben haben, das Sie benötigen, um ein Begriffsmodell auf Basis des UML-Klassendiagramms zu erstellen, werden wir heute modellieren. Sie haben einen Teil der Blogserie verpasst oder möchten noch einmal etwas nachlesen? Hier finden Sie unseren Letzten Blogbeitrag zu diesem Thema.

Lösung Schüttelwörter

Bevor wir Ihnen jedoch erklären, wie wir modellieren lassen, greifen wir noch einmal das Thema des letzten Blogeintrags auf. Bei diesem haben wir Ihnen die Schüttelwörter vorgestellt und Ihnen eine Aufgabe dazu gestellt. Heute bekommen Sie von uns die Lösung dazu.

Wie modellieren wir? Hintergrundinformationen

Im Rahmen dieser Blogserie haben wir Ihnen vorgestellt, wie wir SOPHISTen im Rahmen von Schulungen die wichtigen Elemente, die zum Erstellen eines Begriffsmodells auf Basis des UML-Klassendiagramms nötig sind, vermitteln. Außerdem haben wir erste Schritte des Modellierens hinter uns gebracht, indem wir ein Begriffsmodell ergänzt haben.

Im Folgenden lassen wir die Teilnehmer unserer Schulungen selbstständig ein Begriffsmodell modellieren – wir zeigen Ihnen nicht das konkrete Beispiel, denn wir können Ihnen nicht alle unsere Geheimnisse offenlegen. Aber wir erklären Ihnen, wie unsere Modellierungsaufgabe aufgebaut ist. Dazu geben wir Ihnen noch bisschen Hintergrundwissen mit auf den Weg.

Als Requirements Engineer beschäftigen wir uns in erster Linie mit Requirements. So weit, so gut. Doch was sind Requirements? Requirements sind Anforderungen an ein zu entwickelndes System. Diese Anforderungen werden durch Ermittlungstechniken erhoben und müssen schriftlich festgehalten werden, damit nichts vergessen wird. Dafür gibt es z.B. die SOPHIST-Anforderungsschablone, nach der alle Anforderungen einheitlich beschrieben werden.

Aus den Anforderungen lassen sich Notationselemente des UML Klassendiagramms herleiten. Um diese graphisch dazustellen modellieren wir ein Begriffsmodell.

Wie modellieren wir? Der Ablauf

Wir geben den Teilnehmern unserer Trainings eine Reihe an Anforderungen, die nach oben genannter Schablone beschrieben sind – manche mit Fehlern, die Sie zuerst herausfinden müssen, manche aber auch korrekt. Korrigieren Sie zunächst die fehlerhaften Anforderungen. Die Lösung wird anschließend besprochen.

Der nächste Schritt ist, die Anforderungen der Reihe nach in ein Begriffsmodell umzusetzen. Nehmen Sie sich also der Reihe nach die einzelnen Anforderungen vor, finden Sie heraus, welche Klassen und Attribute darin vorkommen und welche Beziehung zwischen diesen Klassen vorliegt und modellieren Sie diese. Daraus wächst letzten Endes ein komplexes Begriffsmodell auf Basis des UML-Klassendiagramms heran.

Warum verwenden wir diesen Ablauf?

Im Rahmen unserer Schulungen lernen Sie die Schablone für Anforderungen kennen. Um effizient zu lernen, ist ein Verknüpfen von Wissen aus unterschiedlichen Lernbereichen sinnvoll. Daher greifen wir an dieser Stelle die Anforderungen und die Schablone erneut auf.

Durch das Herausfinden und Korrigieren der fehlerhaften Anforderungen machen Sie sich bereits Gedanken um die Anforderungen, und das Verständnis wird bei der Diskussion der Lösung nochmals vertieft.

Als Requirements Engineer hat man zuerst die Aufgabe, alle Anforderungen herauszufinden und zu beschreiben bevor man ein Begriffsmodell dazu erstellt. Daher haben wir uns dafür entschieden, das Begriffsmodell ebenfalls auf Basis von Anforderungen erstellen zu lassen.

Durch das schrittweise wachsen des Begriffsmodells wird des Weiteren eine Überforderung der Teilnehmer entgegengewirkt. Sie beschäftigen sich immer nur mit einem kleinen Ausschnitt des Begriffsmodells und fügen diesen dann in das wachsende Modell ein. Durch viele Teilerfolge steigt die Motivation, und sie findet ihren Höhepunkt, wenn man am Ende ein komplexes Begriffsmodell erstellt hat.

Wir haben nun ein Begriffsmodell modelliert. Das soll alles gewesen sein? Dem ist nicht so. Es gibt immer wieder auftretende Szenarien, die komplexe Sachverhalte widerspiegeln. Im Folgenden stellen wir Ihnen das erste dieser sogenannten Modellierungsszenarien vor.

Warum verwenden wir Modellierungsszenarien?

Modellierungsszenarien zu kennen erleichtert die Arbeit enorm, da in der Projektrealität immer wieder ähnliche Probleme auftreten können. Wir haben uns dafür entschieden, Modellierungsszenarien nicht einfach in Form eines Vortrags zu präsentieren, sondern unsere Schulungsteilnehmer sollen sich selbst den Stoff erarbeiten.

Wir haben dabei die Erfahrung gemacht, dass ein geringer Teil unserer Teilnehmer auf die richtige Lösung kommt – das ist aber auch nicht das Entscheidende daran. Vielmehr geht es uns darum, verschiedene Lösungsansätze zu sehen und diese gemeinsam zu diskutieren.  Bei dieser Diskussion entwickeln die Lernenden oftmals sehr schnell ein Gefühl für die Vor- und Nachteile, die unterschiedliche Modellierungsvarianten besitzen. Durch den Trainer angeleitet erarbeiten die Teilnehmer im Team dann eine optimale Modellierung für eine typische Problemstellung.

Modellierungsszenarien Teil 1 – Composite Pattern

Als erstes dieser Szenarien stellen wir Ihnen das Composite Pattern vor.

Stellen Sie sich eine Ordnerstruktur vor, mit der Dateien im Computer abgelegt werden. Um die Dateien wiederfinden zu können, erstellen wir Ordner, in denen die Dateien abgelegt werden. Wenn allerdings in einem Ordner zu viele Dateien liegen, dann verlieren wir auch dort schnell die Übersicht. Als Lösung erstellen wir Unterordner, die wiederum weitere Unterordner enthalten können.

Zusammengefasst bedeutet dies:

In einem Ordner liegen Dateien oder Unterordner. In den Unterordnern können wiederum Dateien oder Unterordner liegen. Dies kann beliebig tief gehen.

Wir lassen unsere Teilnehmer ein Begriffsmodell auf Basis des UML-Klassendiagramms erstellen, welches die beschriebene Ordnerstruktur darstellt. Nach einer kurzen Bearbeitungszeit diskutieren wir verschiedene vorgeschlagene Lösungen nach Vor- und Nachteilen und vermitteln somit ein Verständnis dafür, wie auch komplizierte Sachverhalte mit einem Begriffsmodell dargestellt werden können.

Sie sind gespannt, wie man Composite Pattern umsetzt? Die Lösung sowie ein weiteres Modellierungsszenario stellen wir Ihnen in unserem nächsten Blogbeitrag vor. Bei Anmerkungen oder Fragen nutzen Sie die Kommentarfunktion auf dieser Seite, oder melden Sie sich bei uns. Wir sind gerne für Sie da – telefonisch unter (0911 – 40 900-0) oder per Email unter heureka@sophist.de.