Despite its pervasiveness and popularity, the Unified Modeling Language (UML) is not uncontroversial in software engineering 20 years after the launch of its first version. A major reason is their unclear use in practice, which is influenced by the differentiation of software product types, agile development approaches and microservices as architectural style with reduced complexity. These trends move away from traditional top-down, sequential approaches that require extensive specifications of requirements and design. For teaching (especially at the Bachelor level), therefore, the question arises whether we still need UML at all and if so, for what and to what extent. The aim of this paper is to gather empirical evidence on the relevance of UML and to draw conclusions for possible competence goals in software engineering education. Our goal is to provide an up-to-date view of the practical relevance of UML to stimulate discussion about the role of UML in software engineering courses.
Die Beschreibung bestehender oder geplanter
Systeme ist eine wichtige Teilaufgabe im Software
Engineering. Dies wird vielfach mit grafischen
Modellen der Unified Modelling Language (UML)
durchgeführt. Die UML ist der De-facto-Standard
die grafische Modellierung von objektorientierten
Systemen, um deren Analyse, Entwurf und
Dokumentation zu unterstützten
Folgerichtig ist das Erlernen der UML ein wichtiger
Bestandteil in vielen Software Engineering
Modulen an Hochschulen, wie es auch in den
Rahmenempfehlungen der Gesellschaft für Informatik (GI)
verankert ist
Aus unserer Sicht sind mögliche Gründe dafür z.B.: - Die Relevanz der UML in der Praxis scheint zurückzugehen, da umfangreiche Spezifikationen in agilen Entwicklungsansätzen wie z.B.
Scrum nicht mehr erforderlich sind.
- Aufgrund ihrer Komplexität ist die UML
schwer zu erlernen
Vor diesem Hintergrund stellt sich die Frage, ob und wie die UML in der grundständigen Software Engineering Ausbildung zu integrieren ist. Dazu haben wir uns in diesem Beitrag an folgenden Leitfragen orientiert:
Wie und wofür wird die UML in der Praxis tatsächlich eingesetzt? Welche Kompetenzen sollten dafür durch die Hochschullehre entwickelt werden? Grundlage dieser Arbeit sind empirische Studien über den Einsatz der UML anhand ihrer tatsächlichen Nutzung. Die Relevanz in der industriellen Praxis wird anhand von bestehenden Studien bewertet. Daneben haben wir eine Analyse von studentischen Projekt- und Abschlussarbeiten hinsichtlich ihrer Nutzung von grafischer Modellierung durchgeführt.
Abb. 1: Google Trends für Begriffe des Software
Engineerings (2004-2018, nur Deutschland) Dieser Beitrag ist wie folgt aufgebaut: Zunächst ordnen wir die UML historisch ein, diskutieren die Einsatzfelder sowie den Nutzen der Modellierung. Anschließend erfolgt die Analyse von Studien zur Nutzung von UML in der Praxis sowie studentischen Arbeiten. Nach der Diskussion der Ergebnisse leiten wir Schlussfolgerungen für die Rolle der UML in der Lehre ab.
Im Methodenkrieg der 1990er Jahre gab eine Reihe
konkurrierender Ansätze für objektorientierte
Methoden und Modellierungssprachen. Die erste
Version der UML wurde 1997 als Vereinigung einer
aus der „Unified Method“ nach Rumbaugh/Booch
und dem „Object Oriented Software Engineering“
nach Jacobsen gebildet. Der Toolhersteller Rational
unterstützte die UML bereits damals und trug
damit zu ihrer Verbreitung bei
Die Verwendung von UML für die Modellierung
im Software Engineering soll sowohl
Produktqualität als auch Entwicklungsproduktivität verbessern.
Die Zwischenschritte zu diesen Wirkungen
entstehen in den Kategorien Entwickler, Team, Prozess
und Produkt, wie eine Studie von Chaudron u. a.
(2012) ergeben hat (siehe Abb. 2). Insgesamt lässt
sich sagen, dass das Ziel der Nutzung von UML im
Verstehen, Beschreiben und Kommunizieren von
existierenden oder geplanten Softwaresystemen in
verschiedenen Lebenszyklusphasen (Analyse,
Entwurf, Implementierung, Wartung) besteht. Ivar
Jacobson, einer der Gründerväter von UML
schreibt dazu: „Used appropriately it is a practical
tool for raising the level of abstraction on software
from the level of code to the level of the overall
system”
Die zentrale Rolle der Modellierung wird auch durch den Guide to the Software Engineering Body of Knowledge (SWEBOK) unterstrichen. Hier wird die UML als eine mögliche Modellierungssprache genannt und auf die Notwendigkeit verwiesen, eine für die jeweilige Aufgabenstellung geeignete grafische Notation auszuwählen (Bourque, Fairley, & IEEE Computer Society, 2014).
Phase
Analyse
Entwurf
Implementierung
Dokumentation Analysemodell
Ent- Implemenwurfsmo- tiertes dell System
Modelle können beschreibend (deskriptiv) oder
vorschreibend (präskriptiv) sein. Beschreibende
Modelle werden einerseits für die
Systemdokumentation und andererseits in der Analyse für die
Beschreibung des Problemraums (Domänenmodell,
Geschäftsprozesse usw.) eingesetzt. Präskriptive
Modelle hingegen werden für den Entwurf und die
Implementierung eingesetzt, da sie einen Bauplan
(„Vorschrift“) für ein zu realisierendes System
beschreiben. Für die automatische Codeerzeugung
auf Basis eines solchen Modells ist ein hoher
Detailgrad und ein für die Zielplattform geeigneter
Generator erforderlich. Wenn hingegen ein
Programmierer die Implementierung manuell
durchführt, kann dieser auf Basis seiner
Interpretationsfähigkeiten auch mit einem weniger formalen
Modell arbeiten. Tab. 1 fasst die verschiedenen
Aufgaben, Modellarten und Beteiligte zusammen.
Je nachdem, wofür die UML eingesetzt wird, gibt
unterschiedliche Anforderungen an die Modelle
und demnach auch die Fähigkeiten der
Modellersteller und -nutzer. Sommerville nennt für die
Modellierung von Systemen drei verschiedene
Absichten, die jeweils unterschiedliche Grade an
Detaillierung und Rigorosität in der Anwendung der
Modellierungssprache erfordern
Modelle zur Kommunikation Modelle als Vorlage für die Implementierung
Modelle als Basis für die Codegenerierung
unterscheiden
Analyse- Entwurfs- (Code) modelle, modelle, z.B. Do- z.B. Damänen- tenstrukmodell, turen, Geschäfts- Systemprozesse architektur Ersteller Mensch
Mensch
Mensch Nutzer
Mensch
Mensch Modellqualität
Informell, präzise, präzise, Vollstängeringer mittlerer hohe De- dig, korDetailgrad Detailgrad taillierung rekt, genau
Abb. 2: Nutzen der UML Modellierung (Chaudron u. a., 2012)
Für die Beurteilung der praktischen Relevanz von UML stützen wir uns auf Studien, die den Einsatz der UML in der Praxis untersucht haben. Dabei werden einerseits die empirisch ermittelte Nutzung von UML-Modellelementen und andererseits die Verwendungszwecke untersucht.
Die Frage nach der Nutzung der UML anhand der tatsächlichen Verwendung von Diagrammtypen und Modellelementen wurde in den letzten 15 Jahren mittels verschiedener Methoden untersucht. Die Ergebnisse und die zugrundeliegende Methode werden nachfolgend kurz vorgestellt.
Bei diesem Aspekt geht es um die Erhebung von Einsatzfällen für Modellierung, z.B. in Anhängigkeit von Unternehmensgrößen, Modellierungserfahrung, Projekttyp oder Entwicklungsphase. Die hier betrachtete konzeptionelle Modellierung umfasst auch andere Sprachen, nicht nur die UML. Wie auch schon bei den Studien zur Häufigkeit von Modellelementen werden hierfür unterschiedliche Forschungsmethoden eingesetzt. - Das Verhältnis von modellierten Klassen und implementierten Klassen lag zwischen 4% im größten Projekt (~900 Klassen) und 40% im kleinsten Projekt (<60 Klassen) - Nur wenige Projekte aktualisierten ihre initialen Modelle, meist wurden bei neuen
Features neue Modelle hinzugefügt.
3) Befragung zum Einsatz von Entwurfsmodellen,
N=3785
Toolsupport erstellt. - Die Notation ist tendenziell nicht UML. - Die Nutzung von Modellen nimmt mit
Grad an Erfahrung und Qualifikation ab
- Modelle werden eher zur Kommunikation
und Zusammenarbeit genutzt und auf
Whiteboard oder Papier gezeichnet und
werden nach Erstellung selten aktualisiert.
4) Befragung zum Einsatz von Skizzen und
Diagrammen im Software Engineering, N=39
Elemente, 9% ausschließlich UML. - Die Hälfte der Skizzen wurde von einer einzelnen Person angefertigt, 28% von zwei und 15% von drei Personen. - 58% aller Skizzen wurde analog (Papier,
Whiteboard) angefertigt, 40% digital. - Digitale Skizzen werden im Vergleich zu analogen Skizzen zu einem höheren Teil (77%) überarbeitet und archiviert (94%). - Wesentliche Einsatzzwecke sind Entwerfen (75%), Erklären (65%), Verstehen (56%) sowie Anforderungen analysieren (45%).
Da einige Studien z.T. schon über 10 Jahre alt sind,
können die Ergebnisse der Studien nur mit
Vorsicht auf die heutige Verwendung extrapoliert
werden. Dennoch lassen sich gewisse Tendenzen
bei der Nutzung von UML (bzw. konzeptionellen
Modellierungsansätzen insgesamt) in der Praxis
der Softwareentwicklung durchaus ausmachen.
Tendenzen in der UML-Nutzung
Die UML hat gemäß den ausgewerteten Studien in der
Praxis eine sehr hohe Bekanntheit und auch eine hohe
Nutzung. Allerdings werden in der Praxis die
einzelnen Diagrammtypen unterschiedlich häufig
verwendet. Insbesondere Klassen-, Aktivitäts-,
UseCase- und Sequenzdiagramme sind verbreitet.
Die Verwendungszwecke sind oft in frühen Phasen der
Systementwicklung, z.B. zur Unterstützung der
Analyse. Dabei spielt Modellierung besonders für die
Kommunikation und Zusammenarbeit zwischen
den Beteiligten eine wichtige Rolle.
Modelle sind häufig informell oder werden mit
informellen Notationen gemischt. Alternativen zur
Modellierung mit UML sind weniger formelle
Modellierungsansätze wie das C4-Architekturmodell
(Brown, 2018), textuelle Domain Specific
Languages (DSL) oder auch Ad-Hoc-Notationen.
Als Medien werden neben Papier und Whiteboard auch
verschiedene Tools eingesetzt, wobei diese nicht
notwendigerweise klassische UML-Modellierungstools
sind. Wenn ein konsistentes Gesamtmodell mit
vielen untereinander verbundenen Sichten weniger
wichtig ist, kann auf ein Model Repository
verzichtet werden. In diesen Fällen können auch
Zeichentools wie Visio oder eines der zahlreichen auf
Kollaboration ausgelegten webbasierten
Zeichenwerkzeuge für die UML-Modellierung genutzt werden.
Die Erzeugung von Code aus UML-Modellen spielt in
der Praxis eine sehr untergeordnete Rolle. Der
Ansatz der modellgetriebenen Architektur (MDA) mit
umfangreicher Codeerzeugung aus detaillierten
UML-Modellen hat sich im Wesentlichen nur in für
langlebige Systeme in gut verstandenen Domänen
etabliert
Gründe für die veränderte Nutzung von UML Trotz ihrer Verbreitung wird die UML in der Praxis in sehr unterschiedlichem Maße eingesetzt. Hierfür lassen sich eine Reihe von Gründen identifizieren. Die zunehmende Diversifizierung von Softwareproduktarten schränkt der Nutzen einer einheitlichen Modellierungssprache ein. Die Diversität der Softwarelandschaft insgesamt nimmt zu. Beispiele sind die weite Verbreitung von Webapplikationen und mobilen Apps oder das Nebeneinander von Endkundenorientierten E-Commerce-Applikationen neben klassischen betrieblichen Informationssystemen oder sicherheitskritischen Echtzeitsystemen. Diese verschiedenen Softwareprodukte unterscheiden sich sowohl in ihren technischen Plattformen wie auch in ihren typischen Projektkonstellationen stark voneinander. Dies betrifft u.a. die Stabilität der Anforderungen, die Größe des Projektteams sowie den formalem Projektrahmen, was wiederum den Nutzen der Modellierung beeinflusst. Agile Entwicklung braucht weniger UML. Agile Methoden basieren auf iterativer und inkrementeller Entwicklung, in denen die Phasen Analyse, Entwurf, Implementierung, Test und Dokumentation in kurzen Zyklen wiederholt werden. Dadurch sinkt die Notwendigkeit einer umfangreichen Spezifikation des gesamten Systems bzw. großer Systemteile, wofür in einem klassischen WasserfallVorgehen häufig UML eingesetzt wird.
In der agilen Welt wird die Rolle des
SoftwareArchitekten, die klassischerweise UML als
wesentliches Spezifikations- und
Kommunikationsinstrument verwendet, mit einer gewissen Skepsis
betrachtet. Ein Beleg ist etwa das Prinzip 11 des
Agilen Manifests: “The best architectures (…) and
designs emerge from self-organizing teams”,
Microservices haben keine zentralen Modelle mehr. Das Aufkommen des Microservice-Architekturstils als Alternative zur monolithischen oder serviceorientierten Architektur ist eng verbunden mit der agilen Vorgehensweise. Microservices sind so weit wie möglich lose gekoppelt, unter Inkaufnahme von Daten-Redundanzen. Eine klassische TopDown-Modellierung von Applikations-, Datenund Technologiearchitektur findet hier nicht mehr statt (oder in einer wesentlich abstrakteren, Prinzipien-orientierten Weise, die nicht unbedingt mehr eine formale Modellierung erfordert).
Die Services selbst sind eher klein und interagieren mit ihrer Umgebung häufig durch REST- und Eventschnittstellen, die sich ebenfalls gut ohne eine graphische Modellierung spezifizieren lassen. Diese maximal autarken Softwareeinheiten ermöglichen eine idealtypische Anwendung des agilen Ansatzes selbstorganisierter, autarker und im Wesentlichen auf mündliche (oder zumindest informelle) Kommunikation ausgerichtete Entwicklungsteams. Eine Modellierungssprache wie UML, die inhärent von einem zentralen Gesamtmodell mit vielen komplementären Sichten ausgeht, stiftet in diesem Kontext nur geringen Nutzen.
Domain Driven Design modelliert fachlich und weniger
komplex. Domain Driven Design
Wir haben anhand von 47 Abschlussarbeiten und Projektberichten in den Studiengängen Informatik, Medien- und Wirtschaftsinformatik (Bachelor und Master) der TH Köln untersucht, ob und welche Modellierungsansätze Studierende verwendet haben. Es wurden nur Arbeiten betrachtet, in denen die Konzeption und/oder Erstellung eines Softwaresystems mindestens einen Teilschwerpunkt darstellte. Die Arbeiten durften nicht älter als fünf Jahre sein, um ein aktuelles Bild zu gewinnen. Weiterhin durfte es keinerlei Vorgaben seitens der Betreuer geben, ob (und wenn ja welche) Modellierungsansätze zu verwenden waren1. Da die betrachteten Arbeiten also UML nicht explizit erfordern, lässt sich aus den Ergebnissen eine Tendenz ableiten, inwiefern Studierende UML (oder konkurrierende Ansätze) als Mehrwert bei der Spezifikation und Dokumentation empfinden.
Abb. 3: Modellierungsnutzung durch Studierende Wie Abb. 3 zeigt, verwenden weniger als die Hälfte der graphischen Modellierungen in den untersuchten Arbeiten UML. In knapp der Hälfte der Arbeiten werden zudem UI-Mockups genutzt, die im Folgenden jedoch nicht weiter betrachtet werden. In den analysierten Arbeiten spielen nur Klassen-, Komponenten-, Aktivitäts-, Use-Case- und Sequenzdiagramme eine nennenswerte Rolle (siehe Abb. 4). In jeweils einer Arbeit kommt auch ein Objekt- und Deployment-Diagramm zum Einsatz. Das mag daran liegen, dass diese Diagrammtypen gerade diejenigen sind, die in den Softwaretechnik1 Dadurch schieden z.B. Praktikumsberichte in Veranstaltungen aus, bei denen die Beschäftigung mit UMLModellierung ein explizites Lernziel war. Die untersuchten Arbeiten wurden von neun verschiedenen Professoren betreut. Damit dürfte sich auch der Einfluss von dem Bemühen der Studierenden, ihrem Betreuer in dessen persönlichen Modellierungsvorlieben zu gefallen, über die Gesamtheit der Ergebnisse verwischen. Vorlesungen in Informatik, Medien- und Wirtschaftsinformatik vermittelt werden (nur Zustandsdiagramme fallen aus der Reihe, die zwar gelehrt, aber in den Arbeiten nicht auftreten). Davon abgesehen bestätigen sich die Ergebnisse der oben zitierten Studien zum UML-Einsatz: Eine Teilmenge der UML-Diagramme wird in der Praxis in nennenswertem Umfang verwendet.
Eine weitere Erkenntnis lässt sich aus Abb. 4 ableiten: Komponentendiagramme treten in knapp 30% der Arbeiten auf, dort gibt es davon dann insgesamt 49 Instanzen. Klassen- und Use-CaseDiagramme werden in ähnlich vielen Arbeiten verwendet, aber mit weniger Instanzen. Wenn also eine Arbeit Komponentendiagramme enthält, dann in der Regel mehrere; Use-Case-Diagramme hingegen treten fast überall maximal einmal auf, bei Klassendiagrammen ist es ähnlich.
Ein wesentliches Ziel der Untersuchung war es, die Verwendung von UML-Diagrammen mit der von Nicht-UML-Notationen zu vergleichen. Hierfür wurden zwölf Einsatzkontexte für graphische Modellierung definiert, in denen neben UML auch andere formale Notationen sowie informelle Darstellungen in den untersuchten Arbeiten auftraten. Diese sind in Tab. 2 übersichtsweise dargestellt. Die Häufigkeit des Auftretens der verschiedenen Einsatzkontexte (unabhängig davon, ob UML oder eine alternative Darstellung gewählt wurde) ist in Abb. 5 dargestellt. Demnach wird eine Komponentenstruktur in über der Hälfte der Arbeiten graphisch modelliert, technisch-algorithmische Abläufe, eine Klassenstruktur der Implementierung sowie eine Übersicht der Anwendungsfälle sind ebenfalls oft anzutreffen. Einsatzkontext
UML
Diagramm Anwendungs- Use Case fälle Nutzungsszenario / Aktivitäts- BPMN, Geschäftspro- diagramm EPK zess Fachliche Zustände von ZustandsGeschäftsob- diagramm jekten
Fachliches Datenmodell Technischer Prozess / algorithmischer Ablauf Technisches Kommunikationsszenario Technische Zustandsfolge Zustands(State Machi- diagramm ne)
oder Kommunikationsdiagramm Logisches Datenmodell / KlassenDomänenmo- diagramm dell Physisches Datenmodell Klassenstruktur der Implementierung Komponentenstruktur Verteilungssicht
mentdiagramm Allerdings ist es etwas ernüchternd, dass im Median jede untersuchte Arbeit nur jeweils zwei der genannten Einsatzkontexte graphisch modelliert, mit jeweils vier Diagrammen. Abb. 6 zeigt die Häufigkeit der Wertepaare „(Anzahl Diagramme, Anzahl Einsatzkontexte)“ als Blasendiagramm (je häufiger ein Wertepaar auftritt, desto größer die Blase). Bei Diagrammen liegt der Mittelwert mit ca. acht Diagrammen je Arbeit deutlich über dem Median. Einzelne Arbeiten verwenden also graphische Modellierung deutlich größerem Ausmaß als der Rest.
UML-Klassendiagramme stellen in gleich vier von zwölf Einsatzkontexten eine der Alternativen dar (siehe Abb. 7). Am häufigsten wird die Klassenstruktur der Implementierung dargestellt, hier trifft man hauptsächlich auf UML-Klassendiagramme. Das physische Datenmodell wurde in den untersuchten Arbeiten hingegen ausschließlich als ERDiagramm modelliert. Logisches und fachliches Datenmodell werden nur selten modelliert. UML-Aktivitätsdiagramme sind in zwei der zwölf untersuchten Einsatzkontexte von Belang. In beiden tritt eine UML-Modellierung gleichberechtigt neben anderen Darstellungsformen auf (siehe Abb. 8). Bei technischen Prozessen und algorithmischen Abläufen trifft man häufig eine informelle Flussdiagramm-Notation an, während Geschäftsprozesse oder Nutzungsszenarien häufig als BPMN (und gelegentlich auch als EPK) modelliert waren.
Diagrammen in ihren jeweiligen Einsatzkontexten In Abb. 9 sind die Einsatzkontexte dargestellt, in denen UML-Use-Case-, Komponenten-, Sequenz-, Deployment- und Kommunikationsdiagramme eine Rolle spielen. Komponentendiagramme haben in einer informellen Darstellung mit gestapelten oder geschachtelten Blöcken eine große Konkurrenz. Anwendungsfälle werden hingegen in der Regel als Use-Case-Diagramme modelliert. Gleiches gilt für Kommunikationsszenarien, hier dominieren Sequenz- und Kommunikationsdiagramme.
Auch wenn geplant ist, die Untersuchung noch weiterzuführen und ihre Datenbasis zu verbreitern, lassen sich schon einige Erkenntnisse festhalten. Graphische Modellierung wird benötigt. Graphische Modellierung hat ihren festen Platz in der Dokumentation studentischer Softwarekonzeption und Implementation. Allerdings streuen die untersuchten Arbeiten stark in Umfang und Konsistenz der verwendeten Modellierungsansätze. Möglicherweise liegt dies einfach an der natürlichen Qualitätsverteilung der untersuchten Arbeiten.
Nur ein Subset der UML-Spezifikation ist für studentische Arbeiten relevant. Die Untersuchungen zeigen, dass in den Arbeiten im Wesentlichen diejenigen Diagramme verwendet werden, auf die sich auch die Lehre an der TH Köln beschränkt (und die auch in den Praxisstudien als die dominierenden Typen festgestellt werden). Ob die Studierenden einfach das einsetzen, was sie im Studium kennengelernt haben, oder aber diese Diagrammtypen anscheinend ihren Zweck gut erfüllen, lässt sich aus dieser Untersuchung nicht klären. Die Tatsache, dass so viele andere formale und informelle Notationen eingesetzt werden, spricht doch für eine „Freiwilligkeit“. Sprich: Es ist zu vermuten, dass die Studierenden nur Diagrammtypen verwenden, die sie für sinnvoll erachten und gut verstehen.
Informelle Notationen haben ihren Platz. Es fällt auf, dass informelle Notationen oft eingesetzt werden, in denen UML möglicherweise eine Überformalisierung darstellt (Komponentenstrukturen, technisch-algorithmische Abläufe). Dort, wo die UMLDiagramme jedoch entweder intuitiv klar (UseCase-Diagramme) und/oder kompakt und ausdrucksstark (Klassen-, Sequenz-Diagramme) sind, kommen informelle Alternativen selten vor. Andere formale Notationen haben ebenfalls ihren Platz. Bei Geschäftsprozessen und physischem Datenmodell dominieren andere Notationen als UML. Möglicherweise liegt dies an der Struktur der Informatik-Ausbildung an der TH Köln, die in den entsprechenden Fächern (Datenbanken, Informationsmanagement) die Standards „ER“ und „BPMN“ lehrt. Vielleicht sind diese Standards aber einfach tatsächlich verbreiteter als ihre UML-Gegenstücke. Das Potential graphischer Modellierung für fachliche Aspekte wird nicht ausgeschöpft. Betrachtet man die Ergebnisse in Abb. 5, so sind die drei am häufigsten abgedeckten Einsatzkontexte graphischer Modellierung allesamt technischer Natur. Die fachlich geprägten Kontexte „Anwendungsfälle“, „Nutzungsszenario / Geschäftsprozess“ und „fachliches Datenmodell“ stehen auf den Plätzen 4, 6 und 10 (von 12). Klassendiagramme werden überwiegend für Code-Dokumentation verwendet (Abb. 7). Zustandsfolgen von Geschäftsobjekten (die ein starkes Werkzeug fachlicher Modellierung sind) wurden in den untersuchten Arbeiten gar nicht gefunden. Dies alles zeigt ein deutlich technisches Übergewicht der graphischen Modellierung (ob in UML oder in anderer Form). Auf das Potential fachlicher Modellierung sollte also in der Lehre noch stärker hingewiesen werden.
Die Beschreibung von Software mithilfe von
Modellen ist eine essentielle Aufgabe und gehört
daher zum Kernbestandteil der
Softwaretechnikausbildung. Bereits von 10 Jahren stellte Glinz dazu ein
Thesenpapier über die Rolle der Modellierung in
der Lehre vor
Die dargestellten empirischen Untersuchungen zeigen, dass die UML in der Praxis eher selektiv eingesetzt wird. Eine eigene schlaglichtartige Analyse von studentischen Arbeiten bestätigt diesen Eindruck auch für diejenigen Informatikern, die gerade ins Berufsleben eintreten.
Welcher Schluss ist daraus für die zukünftige Ausgestaltung und Weiterentwicklung der Softwaretechnik-Lehre zu ziehen? Ist die UML-Ausbildung in ihrer jetzigen Form noch zeitgemäß? Sollte sie verändert werden? Oder wäre es sinnvoll, sie ganz aus den Curricula von Informatik-Studiengängen zu verbannen? Diese Fragen kann nur durch eine Diskussion in der Fachcommunity beantwortet werden. Dazu möchten wir nicht nur die möglichen Alternativen aufzeigen, sondern auch selbst Stellung beziehen.
Die Erkenntnisse und Schlussfolgerungen aus
Recherche und eigenen Erhebungen legen unserer
Meinung nach nahe, dass eine UML-Ausbildung in
der Form, wie sie vor 15 Jahren angemessen war,
heute nicht mehr in die Zeit passt. Die Gründe
hierfür haben wir unter „Zwischenfazit und
Diskussion“ bei UML-Nutzung durch Praktiker und durch
Studierende aufgezeigt. Ein reines „Belassen“ ist
unserer Ansicht nach also keine sinnvolle Option.
Ebenso wenig erscheint es angebracht, UML
komplett aus den Curricula zu entfernen. Unsere
Erkenntnisse legen nicht den Schluss nahe, dass UML
für die Softwaretechnik nicht mehr relevant ist.
Damit erscheint eine Anpassung des jetzigen
Lehrkonzepts der sinnvollste Ansatz zu sein. Aus den
obigen Analysen und Erkenntnissen lassen sich
durchaus Bereiche identifizieren, in denen eine
Neujustierung der Lehre sinnvoll ist. Um eine
Fachdiskussion zum Thema anzuregen, haben wir
unsere Vorschläge als Thesen strukturiert.
These 1. UML-Kompetenz sollte in der
Softwaretechnikausbildung weiterhin vermittelt werden.
Die hohe Verbreitung von UML und ihre Nutzung
als mittlere Abstraktionsebene zwischen fachlichem
Problem und Implementierung lassen ihre
Behandlung in der Lehre weiterhin sinnvoll erscheinen.
Die Aktivität der modellbildenden Abstraktion ist
eine grundlegende Querschnittskompetenz in der
Informatik
Darüber hinaus scheinen einige UML-Diagrammtypen intuitiv verständlich und gut anwendbar zu sein, oder zumindest als bewusste oder unbewusste Vorlagen für eine informelle Modellierung zu dienen. Sie können daher als eine Art von informatischer Allgemeinbildung angesehen werden. (siehe auch These 2.) These 2. Die Lehre sollte sich auf ausgewählte UML-Modellelemente fokussieren.
Die dargestellten Studienergebnisse legen nahe, dass ein Anspruch an Studierende, die UMLSprachelemente möglichst umfänglich zu beherrschen, nicht sinnvoll ist. Insbesondere die hohe Komplexität und der hohe Formalisierungsgrad der UML erscheint nicht mehr zeitgemäß, da insbesondere die Maschinenlesbarkeit von UML Modellen für Codegenerierung bzw. direkter Ausführung („Executable UML“) sich nicht in der Breite durchsetzen konnten.
Wie die empirischen Untersuchungen zeigen, werden UML-Modelle vielfach informell zur Kommunikation und Zusammenarbeit eingesetzt. In diesen Situationen werden nur wenige Sprachelemente benötigt. Einige Diagrammtypen scheinen intuitiv verständlich und gut merkbar zu sein. Sowohl in der Praxis wie auch in der Auswertung studentischer Arbeiten werden diese Elemente mehr oder weniger nahe am definierten Standard verwendet. Dies trifft insbesondere auf Klassen-, Use-Case und Sequenz-Diagramme zu.
Andere UML-Diagrammtypen findet man häufig auch in einer informellen, „verballhornten“ Form, die sich aber durchaus mehr oder weniger deutlich an den UML-Sprachelementen orientiert. Beispiele hierfür sind Komponenten-, Deployment-, Aktivitäts-, Zustands- und Kommunikationsdiagramme. Diese Tatsache allein ist unserer Ansicht nach Grund genug, Kompetenzen in den „originalen“ UML-Diagrammtypen in der Lehre zu vermitteln. Eine größere Bedeutung hat die UML nach wie vor für die Analyse, z.B. für Domänen- oder Geschäftsprozessmodelle. Da in diesen Fällen sowohl Modellersteller als auch -nutzer Menschen sind, ist ein geringeres Maß an Formalität ausreichend. Dafür wird der durch die hohe Ausdrucksstärke bedingte große Umfang an Modellelementen jedoch nicht benötigt. Dies sorgt zum einen für Konkurrenz durch informelle Modellierungsansätze, für eine hohe Hürde beim Erlernen der UML sowie auch mangelhafte Einsicht in die Notwendigkeit der Sprachbeherrschung bei den Studierenden. Konkrete Kandidaten für eine Verschlankung in der Lehre sind nach unserer Ansicht die Vielzahl von Beziehungstypen in Komponentendiagrammen, detaillierte Spezifikation von Extension Points in Use-Case-Diagrammen oder komplexe Entryund Exit- Aktionen in Zustandsdiagrammen. These 3. Die Lehre sollte sich auf die Beherrschung von Einsatzkontexten anstatt von UMLDiagrammtypen fokussieren.
Die GI gibt für die Informatikausbildung an
Hochschulen folgende inhaltliche Empfehlungen mit
Bezug zur UML
Zudem spielt Ausrichtung des Studiengangs auf eine Zieldomäne eine wichtige Rolle. Dabei sollten die verschiedenen Schwerpunkte in Softwareprodukten (Web vs. Backend, E-Commerce / Social Media vs. betriebliche Anwendungssysteme) sowie Projektmanagementansätze (agil vs. phasenorientiert) als Leitlinie dienen. In weiterführenden Modulen zum Thema Softwareproduktlinien oder Softwarewartung können besondere Einsatzbereiche der Modellierung erschlossen werden. These 6. Die UML-Ausbildung sollte die Modellierung von Fachlichkeit stärker fokussieren. Die Lehre sollte die frühen Phasen der Modellbearbeitung stärker in den Fokus nehmen. UML hat große Stärken in der Beschreibung einer fachlichen Domäne in Form eines fachlichen Datenmodells sowie von geschäftlichen Abläufen als Aktivitätsdiagrammen. Transaktionale Vorgänge lassen sich sehr gut als Zustandsdiagramme eines Geschäftsobjekts beschreiben.
Unsere Auswertung der studentischen Arbeiten hat im Gegensatz dazu gezeigt, dass UML eher für die technische Beschreibung aus Entwickler- statt aus Nutzersicht eingesetzt wird (siehe z.B. Abb. 7). These 7. Die Lehre sollte nicht Tools, sondern Kommunikation und Interaktivität in den Fokus stellen.
Softwareentwicklung wird immer stärker durch Kommunikation und Zusammenarbeit geprägt. Damit sollte die Ausbildung die interaktive Nutzung von UML stärker einüben, z.B. in der Analyse- und frühen Entwurfsphase, in der in der Praxis oft auf Papier oder am Whiteboard gearbeitet wird. Für die praktische Umsetzung ergeben sich daraus interessante Fragestellungen in Bezug auf die konkrete didaktische Umsetzung sowie die damit verbundene geeignete Toolunterstützung.
Die Bedeutung von UML für die Softwaretechnik ist in Veränderung begriffen. Die Ursachen dafür liegen in Trends, die umfangreiche Modellierungen nicht mehr erforderlich machen. Dazu gehören agile Entwicklungsansätze, Microservicearchitekturen sowie das weitgehende Scheitern des MDAAnsatzes, der detaillierte und formale Modelle erfordert. Die Aufmerksamkeit, die diesen Themen derzeit geschenkt wird, darf nicht darüber hinwegtäuschen, dass in vielen Großprojekten oder für sicherheitskritische Produkte die UML nach wie vor eine sehr wichtige Rolle spielt.
Aus unserer Sicht ist es notwendig, die Stellung der UML in der Lehre kritisch zu hinterfragen. Wir haben in diesem Beitrag dazu empirische Belege über die Nutzung der UML zusammengetragen. Diese Bestandsaufnahme diente als Grundlage für die Ableitung von Konsequenzen für die Ausgestaltung der Lehre. Naturgemäß kann dies keine abschließende Bewertung sein, sondern soll entsprechend unserer Zielsetzung Impulse zu diesem Thema liefern.
Für weiterführende Arbeiten erscheint neben einer Verbreiterung und Aktualisierung der empirischen Basis auch eine Ausdifferenzierung hinsichtlich verschiedener Studienrichtungen und -niveaus sinnvoll. Es muss beobachtet werden, wie sich die Nutzung der UML in der Praxis weiterentwickelt. Dabei sind Situationen zu betrachtet, in denen Modelle einen Mehrwert leisten. Wer ist Modellersteller, wer -nutzer? Wie umfangreich und präzise müssen die Modelle sein? Müssen aufkommende Programmierparadigmen wie funktionale und deklarative Programmierung berücksichtigt werden, da UML unmittelbar mit OOP zusammenhängt? Wie kann Fachlichkeit stärker in den Fokus genommen werden? Wie kann der identifizierte Kompetenzbedarf in praxisorientierten Lehrkonzepten umgesetzt werden? Wir hoffen, mit diesem Beitrag die Diskussion dazu ein Stück weit angeregt zu haben.
Boberić-Krstićev, D., Tešendić, D., Simos, T. E., Psihoyios, G., Tsitouras, C., & Anastassi, Z. (2011). Teaching Object-Oriented Modelling Using UML. In Numerical Analysis and Applied Mathematics ICNAAM 2011 (S. 810–812). AIP. https://doi.org/10.1063/1.3636856 Bourque, P., Fairley, R. E., & IEEE Computer Society. (2014). Guide to the Software Engineering Body of Knowledge (SWEBOK(R)): Version 3.0 (3.
Aufl.). IEEE Computer Society Press.
Brown, S. (2018). The C4 model for software architecture. Abgerufen 21. Oktober 2018, von https://c4model.com/ Burgueño, L., Vallecillo, A., & Gogolla, M. (2018).
Teaching UML and OCL models and their validation to software engineering students: an experience report. Computer Science Education, 28(1), 23–41. https://doi.org/10.1080/08993408.2018.1462000