=Paper=
{{Paper
|id=Vol-2542/MOHOL1
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-2542/MOHOL1.pdf
|volume=Vol-2542
|dblpUrl=https://dblp.org/rec/conf/modellierung/Desel20
}}
==None==
https://ceur-ws.org/Vol-2542/MOHOL1.pdf
Joint Proceedings of Modellierung 2020 Short, Workshop and Tools & Demo Papers
58 Workshop zur Modellierung in der Hochschullehre
Modellieren lehren – Lehren modellieren
(Extended Abstract)
Jörg Desel1
1 Einleitung
Dieser Beitrag stellt die Lehre von Modellierung auf akademischer Ebene der Modellierungs-
lehre auf nichtakademischer Ebene, zum Beispiel in Ausbildungsberufen der Informatik,
gegenüber. Es wird zunächst erörtert, welche Aspekte der Modellierung an Hochschulen
gelehrt werden sollten, die über anwendungsbezogene Modellierungsfähigkeiten hinaus-
gehen. Modulbeschreibungen dienen nicht nur der Beschreibung der vermittelten Inhalte
bzw. der Kompetenzen, die der erfolgreiche Absolvent eines Moduls erworben haben soll.
Sie sind auch Grundlage von Entscheidungen zur Anerkennung von bereits erbrachten
Leistungen und Anrechnung von Kompetenzen, die außerhalb von Hochschulen erworben
wurden. Der zweite Teil des Titels bezieht sich einerseits auf Modulbeschreibungen als
Abstraktion (und damit Modell) von erworbenen Modellierungskompetenzen. Konkret geht
es darum, wie und warum Anrechnungen und Anerkennungen stattfinden (sollten). Erste
Ergebnisse aus einem aktuellen Projekt zur Durchlässigkeit zwischen Ausbildungsebenen
zeigen, dass Modulbeschreibungen im eigentlichen Sinn als Referenz oft nicht geeignet
sind, sondern dass relevante Kompetenzen auf verschiedenen Abstraktionsstufen betrachtet
werden müssen.
2 Akademische Modellierungslehre
Die Frage nach Unterschieden zwischen Hochschulausbildung und Berufsausbildung
in technischen Disziplinen geht über das Thema Modellierung hinaus, soll aber hier
für Modellierung betrachtet werden, wobei wir auf die Modellierung im Rahmen der
Softwareentwicklung fokussieren. Was also lernt man an der Universität über Modellierung,
was in der beruflichen Ausbildung nicht gelehrt wird, und warum? Ein kurzer Blick auf
Vorlesungsskripten und -folien von Kollegen (sofern diese im Internet verfügbar sind) zeigt,
dass diese Frage nicht einheitlich beantwortet werden kann. Zudem mag es Unterschiede
zwischen Fachhochschulen und Universitäten geben.
1 FernUniversität in Hagen, Lehrgebiet Softwaretechnik und Theorie der Programmierung, Universitätsstraße 11,
58097 Hagen, joerg.desel@fernuni-hagen.de
Copyright © 2020 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Modellieren lehren - Lehren modellieren 59
Nähert man sich der Frage nach Unterschieden in der Lehre über Ziele, die mit dem Studium
der Modellierung verbunden werden, so findet man für die Hochschullehre verbreitet
den Anspruch, dass Absolventen nicht nur (aber auch) gelernt haben sollen, wie und
warum man Modelle bei der Softwareentwicklung einsetzt. Entsprechendes gilt für andere
anwendungsnahe Fächer. Bei der Modellierung geht es meist um UML-Diagramme, ihren
Zusammenhang, ihren Entwurf, und ihre Verwendung bei der Erstellung von Code. Dies
lernt man aber außerhalb der Hochschulen auch.
Der häufig geäußerte Anspruch, dass Absolventen von Hochschulen nicht nur die heute
verwendeten Sprachen und Methoden beherrschen, sondern auch zukünftige Entwicklungen
der Modellierung verstehen, anwenden und eventuell sogar gestalten können, geht über
die oben genannte Anwendungskompetenz hinaus. Naturgemäß kann man die zukünftig
relevanten Modellierungssprachen und ihren Einsatz nicht vorhersehen und deshalb auch
nicht lehren. Was wir als Hochschullehrer aber vermitteln können und sollten ist die
historische Perspektive der Modellierung in der Forschung und in der Anwendung. Warum
ist UML entstanden, was waren die Vorläufer, was war der erste Entwurf (UML Version 1),
was unterscheidet ihn von dem aktuellen Stand, welche Moden bei der Softwareentwicklung
haben auf Modellierungsstandards Einfluss genommen usw.? Zudem ist es hilfreich, Bezüge
zwischen der UML und anderen, früher definierten Sprachen herzustellen: welche Anleihen
haben Klassendiagramme bei ER-Diagrammen genommen, was unterscheidet Aktivitäts-
diagramme von Petrinetzen, was haben Zustandsdiagramme mit endlichen Automaten zu
tun? Dies hilft nicht nur beim Verständnis der heutigen UML und ihrer Einsatzgebiete.
Auch zukünftige Entwicklungen bei Modellierungssprachen werden in irgendeiner Weise
Anleihen bei existierenden Sprachen nehmen. Begreift man die Zukunft als Fortsetzung der
Vergangenheit, muss der Prozess der Entwicklung von Modellierung im Softwareentwurf
erkannt und verfolgt werden können.
Die genannten Verbindungen aktueller Modellierungssprachen zu anderen Sprachen bzw. zu
anderen Bereichen der Informatiklehre dienen auch einem weiteren Ziel universitärer Lehre:
Es geht nicht um Inselwissen; ein Informatiker sollte nach Abschluss seines Studiums mehr
als die Summe der absolvierten Module beherrschen; er hat einen Überblick über die gesamte
Informatik und begreift Bezüge zwischen ihren Teilgebieten. Der Anspruch geht sogar über
das Fach Informatik hinaus, wenn man Informatik als interdisziplinäres Fach ansieht, das
von Beginn an starke Bezüge zu den älteren Disziplinen Elektrotechnik und Mathematik
hatte, und heute zu sehr vielen weiteren Fächern. Dies gilt auch und ganz besonders für die
Modellierung. So war Herbert Stachowiak, der auch in der Informatik meist als Begründer
der Modellierungstheorie genannt wird, Philosoph. Aus der Wirtschaftsinformatik kamen
im Verlauf der Modellierungsforschung der letzten Jahre wissenschaftstheoretische Aspekte,
aber auch Ökonomie, Psychologie und andere Fächer lieferten wichtige Beiträge zur
informatischen Modellierungsforschung.
Vergleiche zwischen Modellierungssprachen dienen nicht primär dem Zweck, bessere bzw.
schlechtere Sprachen zu identifizieren. Auch ist die relative Eignung für einen bestimmten
Anwendungszweck nur ein Merkmal unter vielen. Es geht auch und insbesondere darum,
60 Jörg Desel
dass manche (zu modellierende) Konzepte in manchen Sprachen besonders klar definiert
sind, zum Beispiel Nebenläufigkeit in Petrinetzen. Das heißt nicht, dass Petrinetze an sich
geeigneter sind für Anwendungen, in denen Nebenläufigkeit eine Rolle spielt. Aber der
Bezug einer anderen Sprache zu Petrinetzen hilft, das Phänomen Nebenläufigkeit durch
Betrachtung aus einer anderen sprachlichen Perspektive besser zu verstehen, gerade auch
im Anwendungskontext.
Ein besonderes Bezugsmodell war und ist stets die Mathematik, die eigene Sprachen zur
Beschreibung mathematischer Konzepte entwickelt hat. So ist A = {a, b, c} eine Menge mit
drei Elementen, die sich von {c, b, a} zwar syntaktisch, nicht aber inhaltlich unterscheidet.
Bei graphischen Modellen muss auch immer klar sein, was nur der Darstellung dient (oft
zum Beispiel die genaue Position eines Elements, aber nicht immer!) und was nicht. Wenn
man das Wechselspiel zwischen Syntax und Semantik in der Mathematik und insbesondere
in der Logik verstanden hat, ist man geschult, auch bei Modellierungssprachen zwischen
Darstellung und dem eigentlich Gemeinten differenzieren zu können und Diagrammspra-
chen tatsächlich als formale Sprachen anzusehen. Genau diese Sichtweise hilft, Sprachen
voneinander abzugrenzen und vermeidet Beliebigkeit in Darstellung und Anwendung.
3 Modulbeschreibungen
Was lehren wir, wenn wir Modellieren lehren? Welche Kenntnisse und Fertigkeiten erwarten
wir von Studenten nach einer erfolgreichen Teilnahme an einem Modul „Modellierung“?
Welche Kompetenzen folgen daraus, und welche Kompetenzen benötigt man, um überhaupt
Modellierung studieren zu können? All dies sollte in der Modulbeschreibung stehen. Diese
sollte zwar kompetenzorientiert geschrieben sein, besteht aber oftmals wie früher aus
einer Inhaltsübersicht, nun eingerahmt durch „nach erfolgreicher Teilnahme sollen die
Studierenden die folgenden Inhalte können“, wobei „können“ schon mal durch „beherrschen“
oder andere Verben ersetzt wird. Die Empfehlungen zur Gestaltungen von Informatik-
Bachelorstudiengängen der Gesellschaft für Informatik2 führen „Modellierung“ als einen
(von 13) Inhaltsbereichen auf. Wie jeder andere Inhaltsbereich muss Modellierung nicht
durch ein eigenes Modul repräsentiert werden, sondern kann auch durch mehrere Module
abgedeckt werden.
Modulbeschreibungen haben einen wichtigen weiteren Zweck: Aufgrund der Modulbeschrei-
bungen soll der Modulverantwortliche oder gar eine fachfremde Person aus dem jeweiligen
Prüfungsamt entscheiden, ob ein anderswo abgeschlossenes Modul anerkannt werden
kann oder ob die Kompetenzen eines Moduls (gemäß seiner Beschreibung) in mehreren
absolvierten Modulen vorkommen, so dass deswegen eine Anerkennung geboten ist. Dies ist
jedenfalls die formale juristische Sicht. Tatsächlich werden Anerkennungsentscheidungen
aber oft unabhängig von Modulbeschreibungen getroffen. Wenigstens ist auf der anerken-
nenden Seite das zu ersetzende Modul bekannt. Oft gibt es auch Indizien für die tatsächlich
2 Olaf Zukunft et. al.: Empfehlungen für Bachelor- und Masterprogramme im Studienfach Informatik an Hoch-
schulen, Gesellschaft für Informatik, Bonn 2016
Modellieren lehren - Lehren modellieren 61
erworbenen Kompetenzen aus anderen Hochschulen, über die Modulbeschreibung hinaus.
Diese nachvollziehbare Großzügigkeit bei der Anerkennung hat allerdings den Nachteil der
fehlenden Vorhersehbarkeit und Verlässlichkeit einer Anerkennung, der Antragsteller hängt
von dem guten Willen seiner Universität ab.
Die dargestellte formale Sicht soll nicht den Eindruck erwecken, dass Hochschulen exis-
tierende Kompetenzen ignorieren sollten, sofern diese bzw. ihre Beschreibung nicht eine
Modulbeschreibung abdecken. In dem von uns an der FernUniversität in Hagen durchge-
führten Projekt FIBIDAS3 geht es explizit um die Berücksichtigung von außerhalb der
Hochschule erworbenen Kompetenzen bei der Gestaltung von Modulen. Wenn man aber
die im vorigen Abschnitt genannten Unterschiede ernst nimmt, kann eine Anrechnung oder
Anerkennung meist schon aus formalen Gründen nicht stattfinden.
4 Modell der Lehre
Im vorigen Abschnitt wurde skizziert, wie die Anerkennung von Modulen durch extern
erbrachte Studienleistungen theoretisch erfolgen soll. Festzustellen ist dabei insbesondere,
dass sich die Frage nach Äquivalenz und Anerkennung „eigentlich“ ausschließlich auf
Modulbeschreibungen beider beteiligter Hochschulen beschränkt. Dies ist allerdings und
glücklicherweise nicht die tatsächliche Praxis, wie folgende Beispiele verdeutlichen:
• Statt der vorgesehenen imperativen Programmiersprache C++ wird die anderswo
gelernte Sprache Java akzeptiert, also Anerkennung der entsprechenden Module.
• Eine Erasmus-Partneruniversität bietet ein Modul an, das zu einem Studienschwer-
punkt des Heimatstudiengangs sehr gut passt, aus Ressourcengründen dort aber nicht
angeboten werden kann. Dieses Modul darf man – auf dem Wege der Anerkennung -
für ein inhaltlich verwandtes Modul ersetzen
• Für ein Nebenfach (genauer: für die vorgesehenen Nebenfachmodule) wird ein
anderswo absolviertes Fach anerkannt, das als Nebenfach garnicht angeboten wird.
Bei dem ersten Punkt wird das Java-Modul anerkannt, weil es um die Beherrschung der
Konzepte objektorientierter Programmierung geht. Der Fortschritt des Studiums sollte
weitgehend unbeeinflusst bleiben. Die Modulbeschreibungen dürften sich aber in dem einen
Punkt gravierend unterscheiden: Java statt C++. Angenommen, der betrachtete Studiengang
hätte ein weiteres Modul „Java“. Dann könnte das Fremdmodul nicht mehr für C++
angerechnet werden, wohl aber für dieses Java-Modul. Es kommt daher auf den Kontext im
Studiengang an, auf die Rolle, die ein Modul in diesem Studiengang spielt. Leider steht diese
Information aber nicht in einer Modulbeschreibung, die unabhängig vom Einsatz des Moduls
ist. Ähnlich sieht es beim zweiten genannten Punkt aus. Selbstverständlich gibt es keine
3 Vom Fachinformatiker zum Bachelor Informatik durch adaptierte Studiengestaltung
62 Jörg Desel
Modulbeschreibung zu dem externen Modul, aber auf einer höheren Abstraktionsebene
entspricht dieses Modul einem Heimatmodul, weil es ebenfalls eine vertiefende Rolle in
dem Schwerpunkt spielt. Es geht also wieder um die Rolle eines Moduls im Studiengang.
Im dritte Fall mag das Nebenfach für die Anforderung stehen, dass jeder Absolvent auch
einmal „über den Tellerrand“ geschaut hat und andere wissenschaftliche Disziplinen oder
Anwendungsbereiche kennengelernt hat, möglichst sogar in Verbindung zur Informatik (oft
heißen Nebenfächer deshalb Anwendungsfächer). Dies geht nun sicher erst recht nicht aus
den Modulbeschreibungen hervor.
Um also einerseits die existierende Anrechnungspraxis zu rekonstruieren und zu legitimieren
und um andererseits eine Grundlage für denkbare Studienverläufe unter Einbeziehung von
Mobilität, Interdisziplinarität und Durchlässigkeit zwischen Bildungssystemen zu schaffen,
haben wir im bereits genannten Projekt FIBIDAS ein konzeptuelles Modell der Lehre
entwickelt. Es stellt die verschiedenen Abstraktionsebenen der Studienganggestaltung und
ihre Beziehungen dar:
• Empfehlungen zur Studienganggestaltung (von GI, IEEE, Universität o.ä.),
• Profil eines Studiengangs (Orientierung, Schwerpunktsetzung),
• Rollen von Modulen (Grundlagenkompetenzen, Anwendungskompetenzen, For-
schungskompetenzen, überfachliche Kompetenzen, jeweils in Bezug zur Ausrichtung
des Studiengangs),
• Module selbst (Pflicht, Wahlpflicht, ...),
• abgrenzbare Teile von Modulen.
Die oben aufgeführten Beispielszenarien machen deutlich, dass für jede Anrechnungs-
oder Anerkennungsentscheidung, sei sie individuell oder pauschal auf andere Abschlüsse
bezogen, die passende Ebene dieses Modells betrachtet werden muss, und dort die so
genannte Äquivalenzprüfung stattfindet.
Abschließend soll die denkbare Frage beantwortet werden, ob sich ein derartiges Modell
lohnt, nur um hier und da ohnehin stattfindende Anrechnungen und Anerkennungen zu
legitimieren. Schon die Forderung nach ordentlichen Modulbeschreibungen wird vielfach als
Zumutung empfunden. In der aktuell stattfindende Anerkennungspraxis ist der Antragsteller
völlig abhängig von der Güte und Laune seiner Universität, die sich ja jederzeit auf den
Vergleich der Modulbeschreibungen zurückziehen kann, hier ist mehr Transparenz und eine
gemeinsame Verhandlungsebene angebracht.
Darüber hinaus sollte die Instanziierung des Modells bei der Gestaltung eines Studiengangs
ohnehin wenigstens implizit geschehen, und sie wird bei jedem (Re-)Akkreditierungsantrag
in irgendeiner Form wiederholt. Sie dient allen Beteiligten, insbesondere den Studienin-
teressierten und Studierenden, als Orientierung dafür, was sie eigentlich in den einzelnen
Modulen lernen sollen und warum sie dies im Rahmen des gewählten Studiengangs tun.