In unserer Blogserie zur Wissensvermittlung eines Begriffsmodells auf Basis des UML-Klassendiagramms haben wir Ihnen bisher unser Konzept vorgestellt, wie wir das Wissen vermitteln das Sie benötigen, um selbst ein Begriffsmodell zu erstellen. Sie möchten noch einmal nachlesen? Hier finden Sie den vorigen Artikel.
In unserem heutigen Blogbeitrag stellen wir Ihnen vor wie wir vermitteln, wofür ein Begriffsmodell, speziell auf Basis des Klassendiagramms, geeignet ist.
Wir SOPHISTen haben ständig die spannende Aufgabe, unser Wissen aus dem Bereich des Requirements Engineering und unsere Erfahrungen aus der Praxis an unterschiedliche Personen weiterzugeben indem wir Personen oder Teams coachen, schulen und weiterbilden.
Wir wollen das Rad zwar nicht neu erfinden, aber wir haben uns das Ziel gesetzt, unsere Wissensvermittlung z. B. in Schulungsmaßnahmen noch effektiver und erfolgreicher zu gestalten. Aus diesem Grund lohnt es sich, das Themengebiet Wissensvermittlung – speziell im Requirements Engineering, jedoch auch allgemein – einmal genauer zu beleuchten.
Im Lehrplan des Certified Professional for Requirements Engineering Advanced Level – Requirements Modeling des IREB e.V. (Lehrplan) ist in Lehreinheit 3.3 Funktionsmodellierung die Datenflussmodellierung beinhaltet. Da die Literatur zu diesem Thema evtl. nicht bei jedermann vorhanden ist und falls doch sehr viel ausführlicher sein dürfte als dies der Lehrplan fordert, möchte ich die wichtigsten Aspekte der Datenflussmodellierung im Rahmen dieser kleinen Blogserie – bestehend aus drei Teilen – erklären. Weiterlesen
In unserem letzten Blogeintrag ging es darum, dass alle verwendeten Signale den gleichen Zustandsübergang auslösten. Wir haben einen Automaten modelliert, in dem ein Zustandsübergang durch den Empfang von FlugzeugFehler ausgelöst wird. Weiterlesen
Im ersten Teil unserer Blogserie „Modellierung von Signalfamilien“ haben wir uns mit dem Problem beschäftigt, wie unterschiedliche Signale denselben Zustandsübergang in einem Automaten auslösen können. Ausgehend von unserem sehr einfach gehaltenen Beispiel wurde aufgezeigt, welche Probleme bei der Modellierung von verschiedenen Signalen auftreten können. Unser UML-Zustandsdiagramm wirkte unleserlich, ineffizient und sehr komplex. Um diesem Sachverhalt entgegenzuwirken, wechseln wir zunächst von der Verhaltensperspektive in die Strukturperspektive unseres Systems. Weiterlesen