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.