=Paper=
{{Paper
|id=Vol-2358/paper-01
|storemode=property
|title=UML in der Hochschullehre: Eine kritische Reflexion
(UML in Higher Education: A Critical Reflection)
|pdfUrl=https://ceur-ws.org/Vol-2358/paper-01.pdf
|volume=Vol-2358
|authors=Jürgen Anke,Stefan Bente
|dblpUrl=https://dblp.org/rec/conf/seuh/AnkeB19
}}
==UML in der Hochschullehre: Eine kritische Reflexion
(UML in Higher Education: A Critical Reflection)==
https://ceur-ws.org/Vol-2358/paper-01.pdf
UML in der Hochschullehre:
Eine kritische Reflexion
Jürgen Anke, Hochschule für Telekommunikation Leipzig
Stefan Bente, Technische Hochschule Köln
anke@hft-leipzig.de, stefan.bente@th-koeln.de
Zusammenfassung Abstract
Trotz ihrer hohen Bekanntheit und Verbreitung ist Despite its pervasiveness and popularity, the Uni-
die Unified Modelling Language (UML) 20 Jahre fied Modeling Language (UML) is not uncontro-
nach der Vorstellung ihrer ersten Version in der versial in software engineering 20 years after the
Softwaretechnik nicht unumstritten. Ein wesentli- launch of its first version. A major reason is their
cher Grund ist ihre unklare Nutzung in der Praxis unclear use in practice, which is influenced by the
die u.a. durch Ausdifferenzierung von Software- differentiation of software product types, agile
produktarten, agilen Entwicklungsansätzen sowie development approaches and microservices as
Microservices als Architekturstil mit reduzierter architectural style with reduced complexity. These
Komplexität beeinflusst wird. Diese Trends beför- trends move away from traditional top-down, se-
dern eine Abkehr von klassischen Top-Down- quential approaches that require extensive specifi-
Ansätzen mit sequenziellem Vorgehen, das um- cations of requirements and design. For teaching
fangreiche Spezifikationen der Anforderungen und (especially at the Bachelor level), therefore, the
des Entwurfs erfordert. Für die Lehre (insbesonde- question arises whether we still need UML at all
re auf Bachelorniveau) stellt sich daher die Frage, and if so, for what and to what extent. The aim of
ob wir UML überhaupt noch brauchen und wenn this paper is to gather empirical evidence on the
ja, wofür und in welchem Umfang. Ziel dieses Bei- relevance of UML and to draw conclusions for pos-
trags ist es, empirische Belege zur Relevanz der sible competence goals in software engineering
UML zusammenzutragen und daraus Schlussfolge- education. Our goal is to provide an up-to-date
rungen für mögliche Kompetenzziele in der Soft- view of the practical relevance of UML to stimulate
waretechnikausbildung zu ziehen. Unser Ziel ist es, discussion about the role of UML in software engi-
eine aktuelle Sicht auf die praktische Relevanz der neering courses.
UML zu liefern und damit die Diskussion über die
Ausgestaltung der Lehre im Fach Softwaretechnik
anzuregen.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 8
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Einleitung und Motivation Praxis wird anhand von bestehenden Studien be-
wertet. Daneben haben wir eine Analyse von stu-
Die Beschreibung bestehender oder geplanter Sys-
dentischen Projekt- und Abschlussarbeiten hin-
teme ist eine wichtige Teilaufgabe im Software
sichtlich ihrer Nutzung von grafischer Modellie-
Engineering. Dies wird vielfach mit grafischen
rung durchgeführt.
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 Doku-
mentation zu unterstützten (Rupp, Queins, & SO-
PHISTen, 2012; Sommerville, 2015).
Folgerichtig ist das Erlernen der UML ein wichtiger
Bestandteil in vielen Software Engineering Modu-
len an Hochschulen, wie es auch in den Rahmen-
empfehlungen der Gesellschaft für Informatik (GI)
verankert ist (Gesellschaft für Informatik, 2016).
Jedoch ist die UML auch in der Lehre aus unserer
Erfahrung nicht unumstritten.
Aus unserer Sicht sind mögliche Gründe dafür z.B.:
- Die Relevanz der UML in der Praxis scheint
zurückzugehen, da umfangreiche Spezifikatio-
Abb. 1: Google Trends für Begriffe des Software
nen in agilen Entwicklungsansätzen wie z.B.
Engineerings (2004-2018, nur Deutschland)
Scrum nicht mehr erforderlich sind.
- Aufgrund ihrer Komplexität ist die UML Dieser Beitrag ist wie folgt aufgebaut: Zunächst
schwer zu erlernen (Erickson & Siau, 2007; ordnen wir die UML historisch ein, diskutieren die
Seiko Akayama u. a., 2013). Einsatzfelder sowie den Nutzen der Modellierung.
- Besondere Schwierigkeiten verursacht die Ver- Anschließend erfolgt die Analyse von Studien zur
bindung verschiedener Sichten auf das Soft- Nutzung von UML in der Praxis sowie studenti-
waresystem (Boberić-Krstićev u. a., 2011). schen Arbeiten. Nach der Diskussion der Ergebnis-
- Klassische UML-Tools führen aufgrund ihrer se leiten wir Schlussfolgerungen für die Rolle der
Komplexität in der Lehre oft zu Herausforde- UML in der Lehre ab.
rungen (Liebel, Heldal, & Steghofer, 2016; Seiko
Akayama u. a., 2013). UML in der Softwaretechnik
- Der Nutzen der Modellierung erschließt sich
Studierenden nicht (Boberić-Krstićev u. a., Entstehung der UML
2011; Burgueño, Vallecillo, & Gogolla, 2018). Im Methodenkrieg der 1990er Jahre gab eine Reihe
Der Eindruck einer sinkenden Bedeutung von UML konkurrierender Ansätze für objektorientierte Me-
wird auch anhand der Google Trends deutlich, thoden und Modellierungssprachen. Die erste Ver-
welche die relative Häufigkeit von Suchanfragen sion der UML wurde 1997 als Vereinigung einer
betrachtet (Abb. 1). Hierbei wurde der Zeitraum aus der „Unified Method“ nach Rumbaugh/Booch
2004-2018 sowie die Region Deutschland gewählt. und dem „Object Oriented Software Engineering“
Zudem wurde mit „Themen“ statt Suchbegriffen nach Jacobsen gebildet. Der Toolhersteller Rational
gearbeitet, die verschiedene Formulierungen und unterstützte die UML bereits damals und trug da-
Schreibweisen berücksichtigen. mit zu ihrer Verbreitung bei (Rupp u. a., 2012). In
Vor diesem Hintergrund stellt sich die Frage, ob den folgenden Jahren fand eine Erweiterung der
und wie die UML in der grundständigen Software UML um weitere Diagrammtypen und Konstrukte
Engineering Ausbildung zu integrieren ist. Dazu wie der Object Constraint Language (OCL) statt.
haben wir uns in diesem Beitrag an folgenden Leit- Zur Standardisierung wurde die UML schließlich
fragen orientiert: an die Object Management Group (OMG) überge-
ben. In der aktuellen Version 2.5 enthält die UML
- Wie und wofür wird die UML in der Praxis insgesamt 14 Diagrammtypen, von denen jeweils
tatsächlich eingesetzt? sieben zur Beschreibung der Struktur (z.B. Klassen-
- Welche Kompetenzen sollten dafür durch die diagramm, Verteilungsdiagramm, Paketdiagramm)
Hochschullehre entwickelt werden? und sieben zur Beschreibung des Verhaltens (z.B.
Grundlage dieser Arbeit sind empirische Studien Use-Case Diagramm, Aktivitätsdiagramm, Se-
über den Einsatz der UML anhand ihrer tatsächli- quenzdiagramm) dienen.
chen Nutzung. Die Relevanz in der industriellen
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 9
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Einsatzfelder und Modellarten Nutzen der Modellierung
Modelle können beschreibend (deskriptiv) oder Die Verwendung von UML für die Modellierung
vorschreibend (präskriptiv) sein. Beschreibende im Software Engineering soll sowohl Produktquali-
Modelle werden einerseits für die Systemdokumen- tät als auch Entwicklungsproduktivität verbessern.
tation und andererseits in der Analyse für die Be- Die Zwischenschritte zu diesen Wirkungen entste-
schreibung des Problemraums (Domänenmodell, hen in den Kategorien Entwickler, Team, Prozess
Geschäftsprozesse usw.) eingesetzt. Präskriptive und Produkt, wie eine Studie von Chaudron u. a.
Modelle hingegen werden für den Entwurf und die (2012) ergeben hat (siehe Abb. 2). Insgesamt lässt
Implementierung eingesetzt, da sie einen Bauplan sich sagen, dass das Ziel der Nutzung von UML im
(„Vorschrift“) für ein zu realisierendes System be- Verstehen, Beschreiben und Kommunizieren von
schreiben. Für die automatische Codeerzeugung existierenden oder geplanten Softwaresystemen in
auf Basis eines solchen Modells ist ein hoher De- verschiedenen Lebenszyklusphasen (Analyse, Ent-
tailgrad und ein für die Zielplattform geeigneter wurf, Implementierung, Wartung) besteht. Ivar
Generator erforderlich. Wenn hingegen ein Pro- Jacobson, einer der Gründerväter von UML
grammierer die Implementierung manuell durch- schreibt dazu: „Used appropriately it is a practical
führt, kann dieser auf Basis seiner Interpretations- tool for raising the level of abstraction on software
fähigkeiten auch mit einem weniger formalen Mo- from the level of code to the level of the overall
dell arbeiten. Tab. 1 fasst die verschiedenen Aufga- system” (Jacobson, 2009).
ben, Modellarten und Beteiligte zusammen. Die zentrale Rolle der Modellierung wird auch
Je nachdem, wofür die UML eingesetzt wird, gibt durch den Guide to the Software Engineering Body of
unterschiedliche Anforderungen an die Modelle Knowledge (SWEBOK) unterstrichen. Hier wird die
und demnach auch die Fähigkeiten der Modeller- UML als eine mögliche Modellierungssprache ge-
steller und -nutzer. Sommerville nennt für die Mo- nannt und auf die Notwendigkeit verwiesen, eine
dellierung von Systemen drei verschiedene Absich- für die jeweilige Aufgabenstellung geeignete grafi-
ten, die jeweils unterschiedliche Grade an Detaillie- sche Notation auszuwählen (Bourque, Fairley, &
rung und Rigorosität in der Anwendung der Mo- IEEE Computer Society, 2014).
dellierungssprache erfordern (Sommerville, 2015):
- Diskussionen über ein bestehendes oder geplantes
System: Diese Modelle können unvollständig Phase Analyse Entwurf Imple- Doku-
sein und die Notationen der Modellierungs- men- mentation
sprache informell verwenden. tierung
- Dokumentation eines bestehenden Systems: Diese Original Problem- Analyse- Ent- Implemen-
Modelle müssen ebenfalls nicht vollständig / Grund- raum modell wurfsmo- tiertes
sein, wenn nur Teile des Systems dokumentiert lage dell System
werden. Jedoch ist Korrektheit und Genauig-
Modell- Analyse- Entwurfs- (Code) Entwurfs-
keit erforderlich.
inhalte modelle, modelle, modell,
- Codegenerierung: Präzise Systembeschreibung
z.B. Do- z.B. Da- z.B. Da-
als Basis für die Erzeugung der Implementati-
mänen- tenstruk- tenstruk-
on in einer modell-basierten Entwicklung.
modell, turen, turen,
Dies ist im Wesentlichen übereinstimmend mit der Geschäfts- System- System-
Systematisierung von Chaudon et.al., die prozesse architektur architektur
1. Modelle zur Analyse und Verstehen Ersteller Mensch Mensch Mensch Mensch /
2. Modelle zur Kommunikation Maschine
3. Modelle als Vorlage für die Implementierung
Nutzer Mensch Mensch Mensch / Mensch
4. Modelle als Basis für die Codegenerierung
Maschine
unterscheiden (Chaudron, Heijstek, & Nugroho,
2012). Die Reihenfolge dieser Nutzungsarten (von Modell- Informell, präzise, präzise, Vollstän-
den Autoren als modeling styles bezeichnet) gibt qualität geringer mittlerer hohe De- dig, kor-
ebenfalls die steigende Anforderung an Modellqua- Detailgrad Detailgrad taillierung rekt, ge-
lität bzw. Genauigkeit an. nau
Tab. 1: Modellarten und ihre Eigenschaften
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 10
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Abb. 2: Nutzen der UML Modellierung (Chaudron u. a., 2012)
- Nur für Validierung von Anforderungen mit
UML-Nutzung durch Praktiker dem Kunden wurde der Nutzen bei Aktivi-
täts- und Use Case-Diagrammen am höchs-
Für die Beurteilung der praktischen Relevanz von
ten eingeschätzt.
UML stützen wir uns auf Studien, die den Einsatz
- Der Einbezug von Kunden wurde anhand
der UML in der Praxis untersucht haben. Dabei
ihrer Mitwirkung beim Entwickeln, Prüfen
werden einerseits die empirisch ermittelte Nutzung
und Freigeben von Modellen bewertet. In al-
von UML-Modellelementen und andererseits die
len Fällen wird das Use Case Diagramm
Verwendungszwecke untersucht.
am häufigsten genannt, gefolgt vom Akti-
Häufigkeit von Modellelementen der UML vitätsdiagramm.
3) Analyse von Lehrbüchern, UML Tutorials,
Die Frage nach der Nutzung der UML anhand der Hochschulkursen (Gianna Reggio, Maurizio
tatsächlichen Verwendung von Diagrammtypen Leotta, Filippo Ricca, & Diego Clerissi, 2013)
und Modellelementen wurde in den letzten 15 Jah- - In Hochschulkursen sind Klassen-, Se-
ren mittels verschiedener Methoden untersucht. quenz-, Aktivitäts-, Use Case- und Zu-
Die Ergebnisse und die zugrundeliegende Methode standsdiagramme besonders häufig.
werden nachfolgend kurz vorgestellt. - In UML Tutorials zusätzlich dazu Kompo-
1) Delphistudie (Erickson & Siau, 2007) nenten- und Verteilungsdiagramme.
- Enterprise Systeme: 1. Klassen-, 2. Use - Die am seltensten genutzte Diagrammty-
Case-, 3. Sequenz-, 4. Aktivitätsdiagramme pen sind Timing-, Profil-, Interaktionsüber-
- Echtzeitsysteme: 1. Klassen-, 2. Zustands-, sichts- und Kompositionsstrukturdia-
3. Sequenz-, 4. Use Case-Diagramme gramme.
- Web Applikationen: 1. Klassen-, 2. Use 4) Quantitative Analyse von Open UML Model-
Case-, 3. Sequenz-, 4. Zustandsdiagramme len, N=121 (Langer, Mayerhofer, Wimmer, & Kap-
2) Befragung, N=284 (Dobing & Parsons, 2010) pel, 2014)
- 73% der Befragten nutzten in mind. 2/3 ih- - Häufigste Sprachelemente: Class (100%),
rer Projekte Klassendiagramme, gefolgt Use Case (47%), Interactions (39%)
von Use Case (51%) und Sequenzdia- - Häufigste Elemente in Interaktionsdia-
grammen (50%) grammen: Message, Lifeline
- Klassen- und Sequenzdiagrammen wurden - Profile werden häufig für Robustness-
für die Aufgaben Implementierung, Doku- Diagramme u. Datenbankschemata genutzt
mentation, Erklären/Verständnis im Team am - Klassen sind die am häufigsten mit Stereo-
häufigsten ein mindestens begrenzter Nut- typen versehenen Modellelemente.
zen zugeschrieben.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 11
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
5) Experteninterviews, N=50 (Petre, 2013) - Das Verhältnis von modellierten Klassen
- 35 von 50 Befragten nutzen UML gar nicht, und implementierten Klassen lag zwischen
v.a. wegen des Fokus auf die Softwarear- 4% im größten Projekt (~900 Klassen) und
chitektur und nicht auf das ganze System 40% im kleinsten Projekt (<60 Klassen)
(fehlender Kontext), dem hohen Aufwand - Nur wenige Projekte aktualisierten ihre ini-
zum Verstehen der UML (unnötige Kom- tialen Modelle, meist wurden bei neuen
plexität) sowie Problemen von Synchroni- Features neue Modelle hinzugefügt.
sierung bzw. Inkonsistenzen zwischen 3) Befragung zum Einsatz von Entwurfsmodellen,
Modell und Code bzw. Modellsichten N=3785 (Gorschek, Tempero, & Angelis, 2014)
- 11 von 50 Befragten nutzen UML nur selek- - Entwurfsmodelle werden in der Praxis
tiv, besonders in frühen Phasen zur Bewer- nicht häufig verwendet.
tung von Ideen, auch im Team. Sie weniger - Modelle werden eher informell und ohne
verwendeten UML meist in kleineren Mo- Toolsupport erstellt.
dellen, adaptierten die Notation an ihre - Die Notation ist tendenziell nicht UML.
Bedürfnisse und beendeten die Verwen- - Die Nutzung von Modellen nimmt mit
dung, wenn UML in der jeweiligen Pro- Grad an Erfahrung und Qualifikation ab
jektphase nicht mehr gebraucht wurde. - Modelle werden eher zur Kommunikation
- 3 der 50 Befragten nutzten UML für die au- und Zusammenarbeit genutzt und auf
tomatische Codeerzeugung. Die entspre- Whiteboard oder Papier gezeichnet und
chenden Einsatzfälle waren Software für werden nach Erstellung selten aktualisiert.
eingebettete System oder Produktlinien. 4) Befragung zum Einsatz von Skizzen und Dia-
grammen im Software Engineering, N=394
Einsatz von konzeptioneller Modellierung (Baltes & Diehl, 2014)
Bei diesem Aspekt geht es um die Erhebung von - 48% aller Skizzen enthalten einige UML-
Einsatzfällen für Modellierung, z.B. in Anhängig- Elemente, 9% ausschließlich UML.
keit von Unternehmensgrößen, Modellierungser- - Die Hälfte der Skizzen wurde von einer
fahrung, Projekttyp oder Entwicklungsphase. Die einzelnen Person angefertigt, 28% von zwei
hier betrachtete konzeptionelle Modellierung um- und 15% von drei Personen.
fasst auch andere Sprachen, nicht nur die UML. - 58% aller Skizzen wurde analog (Papier,
Wie auch schon bei den Studien zur Häufigkeit von Whiteboard) angefertigt, 40% digital.
Modellelementen werden hierfür unterschiedliche - Digitale Skizzen werden im Vergleich zu
Forschungsmethoden eingesetzt. analogen Skizzen zu einem höheren Teil
1) Befragung zur Modellierung, N=312 (Davies, (77%) überarbeitet und archiviert (94%).
Green, Rosemann, Indulska, & Gallo, 2006) - Wesentliche Einsatzzwecke sind Entwerfen
- Die häufigsten regelmäßig eingesetzten (75%), Erklären (65%), Verstehen (56%)
Modellierungstechniken sind ER- sowie Anforderungen analysieren (45%).
Diagramm (42%), Datenflussdiagramm Zwischenfazit und Diskussion
(34%) und Flowcharts (29%). UML ist mit
21% auf Platz 5. Da einige Studien z.T. schon über 10 Jahre alt sind,
- Die meistgenutzten Tools sind MS Visio können die Ergebnisse der Studien nur mit Vor-
(44%) und Rational Rose (11%). sicht auf die heutige Verwendung extrapoliert
- Unternehmensgröße: Die UML wird bei werden. Dennoch lassen sich gewisse Tendenzen
mittleren Unternehmen (100-1000 Mitarbei- bei der Nutzung von UML (bzw. konzeptionellen
ter) häufiger eingesetzt als bei kleineren Modellierungsansätzen insgesamt) in der Praxis
oder größeren Unternehmen. der Softwareentwicklung durchaus ausmachen.
- Modellierungserfahrung: Mitarbeiter mit 4- Tendenzen in der UML-Nutzung
10 Jahren Erfahrung nutzen häufiger kon- Die UML hat gemäß den ausgewerteten Studien in der
zeptionelle Modelle als Kollegen, die kür- Praxis eine sehr hohe Bekanntheit und auch eine hohe
zere oder längere Erfahrung haben. Nutzung. Allerdings werden in der Praxis die ein-
- Die häufigsten Einsatzzwecke für konzep- zelnen Diagrammtypen unterschiedlich häufig
tionelle Modellierung sind (1) Datenbank- verwendet. Insbesondere Klassen-, Aktivitäts-, Use-
design/–management, (2) Geschäftspro- Case- und Sequenzdiagramme sind verbreitet.
zessdokumentation, (3) Interne Prozess-
verbesserung, (4) Softwareentwicklung, (5) Die Verwendungszwecke sind oft in frühen Phasen der
Verbesserung kollaborativer Prozesse. Systementwicklung, z.B. zur Unterstützung der Ana-
2) Analyse der Repositories von Open Source lyse. Dabei spielt Modellierung besonders für die
Projekten, N=10 (Osman & Chaudron, 2013) Kommunikation und Zusammenarbeit zwischen
den Beteiligten eine wichtige Rolle.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 12
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Modelle sind häufig informell oder werden mit infor- trachtet. Ein Beleg ist etwa das Prinzip 11 des Agi-
mellen Notationen gemischt. Alternativen zur Mo- len Manifests: “The best architectures (…) and de-
dellierung mit UML sind weniger formelle Model- signs emerge from self-organizing teams”, (Beck
lierungsansätze wie das C4-Architekturmodell u. a., 2001), kritische Aussagen zu „klassischer“
(Brown, 2018), textuelle Domain Specific Langu- Softwarearchitektur finden sich darüber hinaus an
ages (DSL) oder auch Ad-Hoc-Notationen. vielen Stellen in der agilen Literatur (z.B. Coplien &
Als Medien werden neben Papier und Whiteboard auch Bjørnvig, 2010, S. 85). Diese Grundhaltung trägt
verschiedene Tools eingesetzt, wobei diese nicht not- dazu bei, dass formale Modellierung in agilen Pro-
wendigerweise klassische UML-Modellierungstools jekten weniger verbreitet ist, auch wenn seit mehre-
sind. Wenn ein konsistentes Gesamtmodell mit ren Jahren eine Reihe von Frameworks existieren,
vielen untereinander verbundenen Sichten weniger die agiles Vorgehen mit Architekturplanung ver-
wichtig ist, kann auf ein Model Repository verzich- binden (siehe z.B. Cockburn, 2006; Larman & Vod-
tet werden. In diesen Fällen können auch Zeichen- de, 2009; Leffingwell, 2007).
tools wie Visio oder eines der zahlreichen auf Kol- Microservices haben keine zentralen Modelle mehr. Das
laboration ausgelegten webbasierten Zeichenwerk- Aufkommen des Microservice-Architekturstils als
zeuge für die UML-Modellierung genutzt werden. Alternative zur monolithischen oder service-
Die Erzeugung von Code aus UML-Modellen spielt in orientierten Architektur ist eng verbunden mit der
der Praxis eine sehr untergeordnete Rolle. Der An- agilen Vorgehensweise. Microservices sind so weit
satz der modellgetriebenen Architektur (MDA) mit wie möglich lose gekoppelt, unter Inkaufnahme
umfangreicher Codeerzeugung aus detaillierten von Daten-Redundanzen. Eine klassische Top-
UML-Modellen hat sich im Wesentlichen nur in für Down-Modellierung von Applikations-, Daten-
langlebige Systeme in gut verstandenen Domänen und Technologiearchitektur findet hier nicht mehr
etabliert (Sommerville, 2015). statt (oder in einer wesentlich abstrakteren, Prinzi-
pien-orientierten Weise, die nicht unbedingt mehr
Gründe für die veränderte Nutzung von UML eine formale Modellierung erfordert).
Trotz ihrer Verbreitung wird die UML in der Praxis Die Services selbst sind eher klein und interagieren
in sehr unterschiedlichem Maße eingesetzt. Hierfür mit ihrer Umgebung häufig durch REST- und
lassen sich eine Reihe von Gründen identifizieren. Eventschnittstellen, die sich ebenfalls gut ohne eine
Die zunehmende Diversifizierung von Softwarepro- graphische Modellierung spezifizieren lassen. Die-
duktarten schränkt der Nutzen einer einheitlichen Mo- se maximal autarken Softwareeinheiten ermögli-
dellierungssprache ein. Die Diversität der Software- chen eine idealtypische Anwendung des agilen
landschaft insgesamt nimmt zu. Beispiele sind die Ansatzes selbstorganisierter, autarker und im We-
weite Verbreitung von Webapplikationen und mo- sentlichen auf mündliche (oder zumindest infor-
bilen Apps oder das Nebeneinander von Endkun- melle) Kommunikation ausgerichtete Entwick-
denorientierten E-Commerce-Applikationen neben lungsteams. Eine Modellierungssprache wie UML,
klassischen betrieblichen Informationssystemen die inhärent von einem zentralen Gesamtmodell
oder sicherheitskritischen Echtzeitsystemen. Diese mit vielen komplementären Sichten ausgeht, stiftet
verschiedenen Softwareprodukte unterscheiden in diesem Kontext nur geringen Nutzen.
sich sowohl in ihren technischen Plattformen wie Domain Driven Design modelliert fachlich und weniger
auch in ihren typischen Projektkonstellationen komplex. Domain Driven Design (Evans, 2003) ist
stark voneinander. Dies betrifft u.a. die Stabilität der dem Microservice-Stil zugrundeliegende ver-
der Anforderungen, die Größe des Projektteams bundene Entwurfsansatz. Der Designfokus liegt
sowie den formalem Projektrahmen, was wiede- hier auf dem Verständnis und der Modellierung
rum den Nutzen der Modellierung beeinflusst. der Domäne, also der Fachlichkeit einer Anwen-
Agile Entwicklung braucht weniger UML. Agile Me- dung. Die Gestaltung der Applikations- und Tech-
thoden basieren auf iterativer und inkrementeller nologiearchitektur rückt in Hintergrund, gemäß
Entwicklung, in denen die Phasen Analyse, Ent- der Überzeugung, dass diese nachgeordnet und
wurf, Implementierung, Test und Dokumentation dezentral gestaltet wird. Domain Driven Design
in kurzen Zyklen wiederholt werden. Dadurch nutzt zur Analyse nicht-graphische Begrifflichkei-
sinkt die Notwendigkeit einer umfangreichen Spe- ten wie die Ubiquitous Language oder informelle
zifikation des gesamten Systems bzw. großer Sys- Modellierungsformen wie Context Maps (Fowler,
temteile, wofür in einem klassischen Wasserfall- 2014), die nicht standardisiert sind und sich höchs-
Vorgehen häufig UML eingesetzt wird. tens (im Fall der Context Map) grob an UML-
In der agilen Welt wird die Rolle des Software- Klassendiagramme anlehnen.
Architekten, die klassischerweise UML als wesent-
liches Spezifikations- und Kommunikationsinstru-
ment verwendet, mit einer gewissen Skepsis be-
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 13
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
UML-Nutzung durch Studierende Vorlesungen in Informatik, Medien- und Wirt-
schaftsinformatik vermittelt werden (nur Zu-
Wir haben anhand von 47 Abschlussarbeiten und
standsdiagramme fallen aus der Reihe, die zwar
Projektberichten in den Studiengängen Informatik,
gelehrt, aber in den Arbeiten nicht auftreten). Da-
Medien- und Wirtschaftsinformatik (Bachelor und
von abgesehen bestätigen sich die Ergebnisse der
Master) der TH Köln untersucht, ob und welche
oben zitierten Studien zum UML-Einsatz: Eine
Modellierungsansätze Studierende verwendet ha-
Teilmenge der UML-Diagramme wird in der Praxis
ben. Es wurden nur Arbeiten betrachtet, in denen
in nennenswertem Umfang verwendet.
die Konzeption und/oder Erstellung eines Soft-
waresystems 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) Modellie-
rungsansätze zu verwenden waren1. Da die be-
trachteten Arbeiten also UML nicht explizit erfor-
dern, lässt sich aus den Ergebnissen eine Tendenz
ableiten, inwiefern Studierende UML (oder kon-
kurrierende Ansätze) als Mehrwert bei der Spezifi-
kation und Dokumentation empfinden.
Abb. 4: Häufigkeit von UML-Diagrammen
Eine weitere Erkenntnis lässt sich aus Abb. 4 ablei-
ten: Komponentendiagramme treten in knapp 30%
der Arbeiten auf, dort gibt es davon dann insge-
samt 49 Instanzen. Klassen- und Use-Case-
Diagramme 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 hinge-
gen treten fast überall maximal einmal auf, bei
Klassendiagrammen ist es ähnlich.
Abb. 3: Modellierungsnutzung durch Studierende
Wie Abb. 3 zeigt, verwenden weniger als die Hälfte Einsatzkontexte graphischer Modellierung
der graphischen Modellierungen in den untersuch- Ein wesentliches Ziel der Untersuchung war es, die
ten Arbeiten UML. In knapp der Hälfte der Arbei- Verwendung von UML-Diagrammen mit der von
ten werden zudem UI-Mockups genutzt, die im Nicht-UML-Notationen zu vergleichen. Hierfür
Folgenden jedoch nicht weiter betrachtet werden. wurden zwölf Einsatzkontexte für graphische Mo-
In den analysierten Arbeiten spielen nur Klassen-, dellierung definiert, in denen neben UML auch
Komponenten-, Aktivitäts-, Use-Case- und Se- andere formale Notationen sowie informelle Dar-
quenzdiagramme eine nennenswerte Rolle (siehe stellungen in den untersuchten Arbeiten auftraten.
Abb. 4). In jeweils einer Arbeit kommt auch ein Diese sind in Tab. 2 übersichtsweise dargestellt.
Objekt- und Deployment-Diagramm zum Einsatz. Die Häufigkeit des Auftretens der verschiedenen
Das mag daran liegen, dass diese Diagrammtypen Einsatzkontexte (unabhängig davon, ob UML oder
gerade diejenigen sind, die in den Softwaretechnik- eine alternative Darstellung gewählt wurde) ist in
Abb. 5 dargestellt. Demnach wird eine Komponen-
tenstruktur in über der Hälfte der Arbeiten gra-
1 Dadurch schieden z.B. Praktikumsberichte in Veranstal-
phisch modelliert, technisch-algorithmische Abläu-
tungen aus, bei denen die Beschäftigung mit UML- fe, eine Klassenstruktur der Implementierung so-
Modellierung ein explizites Lernziel war. Die untersuch- wie eine Übersicht der Anwendungsfälle sind
ten Arbeiten wurden von neun verschiedenen Professo- ebenfalls oft anzutreffen.
ren 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.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 14
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Andere Allerdings ist es etwas ernüchternd, dass im Medi-
Einsatzkon- UML- Informelle an jede untersuchte Arbeit nur jeweils zwei der
formale
text Diagramm Variante genannten Einsatzkontexte graphisch modelliert,
Notation
mit jeweils vier Diagrammen. Abb. 6 zeigt die Häu-
ArchiMa- Verknüpfung figkeit der Wertepaare „(Anzahl Diagramme, An-
Anwendungs- Use Case te Busi- von Aktoren zahl Einsatzkontexte)“ als Blasendiagramm (je häu-
fälle ness Ser- und Anwen- figer ein Wertepaar auftritt, desto größer die Blase).
vices dungsfällen Bei Diagrammen liegt der Mittelwert mit ca. acht
Nutzungs- Diagrammen je Arbeit deutlich über dem Median.
Informelles
szenario / Aktivitäts- BPMN, Einzelne Arbeiten verwenden also graphische Mo-
Flussdia-
Geschäftspro- diagramm EPK
gramm
dellierung deutlich größerem Ausmaß als der Rest.
zess
Fachliche
Zustände von Zustands- -
Informeller
Geschäftsob- diagramm Graph
jekten
Fachliches Klassen- Informeller
-
Datenmodell diagramm Graph
Technischer Informelles
Prozess / Aktivitäts- BPMN,
Flussdia-
algorithmi- diagramm EPK
gramm
scher Ablauf
Technische
Zustandsfolge Zustands- -
Informeller Abb. 5: Abdeckung der Einsatzkontexte
(State Machi- diagramm Graph
ne)
Sequenz- Mit Pfeilen
Technisches oder und Sequenz-
Kommunika- Kommuni- - Zahlen anno-
tionsszenario kations- tierte Struk-
diagramm turen
Logisches ER-
Datenmodell / Klassen- Dia-
Informeller
Domänenmo- diagramm gramm
Graph
dell
ER-
Physisches Klassen- Informeller
Dia-
Datenmodell diagramm Graph Abb. 6: Anzahl Diagramme vs. Einsatzkontexte
gramm
Klassenstruk- Informeller Verwendung von UML im Vergleich mit an-
tur der Im- Klassen- Graph, teilw. deren Notationen
-
plementie- diagramm aus Technik-
UML-Klassendiagramme stellen in gleich vier von
rung symbolen
zwölf Einsatzkontexten eine der Alternativen dar
Informelle (siehe Abb. 7). Am häufigsten wird die Klassen-
Kompo-
Komponen- Block- oder struktur der Implementierung dargestellt, hier trifft
nenten- -
tenstruktur Symbolgra- man hauptsächlich auf UML-Klassendiagramme.
diagramm
phik Das physische Datenmodell wurde in den unter-
Informelle suchten Arbeiten hingegen ausschließlich als ER-
Deploy- Diagramm modelliert. Logisches und fachliches
Verteilungs- Block- oder
mentdia- - Datenmodell werden nur selten modelliert.
sicht Symbolgra-
gramm
phik UML-Aktivitätsdiagramme sind in zwei der zwölf
untersuchten Einsatzkontexte von Belang. In bei-
Tab. 2: Untersuchte Einsatzkontexte graphischer den tritt eine UML-Modellierung gleichberechtigt
Modellierung neben anderen Darstellungsformen auf (siehe Abb.
8). Bei technischen Prozessen und algorithmischen
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 15
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Abläufen trifft man häufig eine informelle Flussdi- Zwischenfazit und Diskussion
agramm-Notation an, während Geschäftsprozesse Auch wenn geplant ist, die Untersuchung noch
oder Nutzungsszenarien häufig als BPMN (und weiterzuführen und ihre Datenbasis zu verbreitern,
gelegentlich auch als EPK) modelliert waren. lassen sich schon einige Erkenntnisse festhalten.
Graphische Modellierung wird benötigt. Graphische
Modellierung hat ihren festen Platz in der Doku-
mentation studentischer Softwarekonzeption und -
Implementation. Allerdings streuen die untersuch-
ten Arbeiten stark in Umfang und Konsistenz der
verwendeten Modellierungsansätze. Möglicher-
weise liegt dies einfach an der natürlichen Quali-
tätsverteilung der untersuchten Arbeiten.
Nur ein Subset der UML-Spezifikation ist für studenti-
sche Arbeiten relevant. Die Untersuchungen zeigen,
dass in den Arbeiten im Wesentlichen diejenigen
Diagramme verwendet werden, auf die sich auch
Abb. 7: Einsatzkontexte mit UML- die Lehre an der TH Köln beschränkt (und die auch
Klassendiagrammen 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 anschei-
nend 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 „Freiwil-
ligkeit“. Sprich: Es ist zu vermuten, dass die Studie-
renden nur Diagrammtypen verwenden, die sie für
sinnvoll erachten und gut verstehen.
Informelle Notationen haben ihren Platz. Es fällt auf,
Abb. 8: Einsatzkontexte mit UML- dass informelle Notationen oft eingesetzt werden,
Aktivitätsdiagrammen in denen UML möglicherweise eine Überformali-
sierung darstellt (Komponentenstrukturen, tech-
nisch-algorithmische Abläufe). Dort, wo die UML-
Diagramme jedoch entweder intuitiv klar (Use-
Case-Diagramme) und/oder kompakt und aus-
drucksstark (Klassen-, Sequenz-Diagramme) sind,
kommen informelle Alternativen selten vor.
Andere formale Notationen haben ebenfalls ihren Platz.
Bei Geschäftsprozessen und physischem Datenmo-
dell dominieren andere Notationen als UML. Mög-
licherweise liegt dies an der Struktur der Informa-
tik-Ausbildung an der TH Köln, die in den entspre-
chenden Fächern (Datenbanken, Informationsma-
nagement) die Standards „ER“ und „BPMN“ lehrt.
Abb. 9: Verwendung von weiteren UML- Vielleicht sind diese Standards aber einfach tatsäch-
Diagrammen in ihren jeweiligen Einsatzkontexten lich verbreiteter als ihre UML-Gegenstücke.
In Abb. 9 sind die Einsatzkontexte dargestellt, in Das Potential graphischer Modellierung für fachliche
denen UML-Use-Case-, Komponenten-, Sequenz-, Aspekte wird nicht ausgeschöpft. Betrachtet man die
Deployment- und Kommunikationsdiagramme Ergebnisse in Abb. 5, so sind die drei am häufigsten
eine Rolle spielen. Komponentendiagramme haben abgedeckten Einsatzkontexte graphischer Modellie-
in einer informellen Darstellung mit gestapelten rung allesamt technischer Natur. Die fachlich ge-
oder geschachtelten Blöcken eine große Konkur- prägten Kontexte „Anwendungsfälle“, „Nutzungs-
renz. Anwendungsfälle werden hingegen in der szenario / Geschäftsprozess“ und „fachliches Da-
Regel als Use-Case-Diagramme modelliert. Glei- tenmodell“ stehen auf den Plätzen 4, 6 und 10 (von
ches gilt für Kommunikationsszenarien, hier domi- 12). Klassendiagramme werden überwiegend für
nieren Sequenz- und Kommunikationsdiagramme. Code-Dokumentation verwendet (Abb. 7). Zu-
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 16
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
standsfolgen von Geschäftsobjekten (die ein starkes These 1. UML-Kompetenz sollte in der Software-
Werkzeug fachlicher Modellierung sind) wurden in technikausbildung weiterhin vermittelt werden.
den untersuchten Arbeiten gar nicht gefunden. Die hohe Verbreitung von UML und ihre Nutzung
Dies alles zeigt ein deutlich technisches Überge- als mittlere Abstraktionsebene zwischen fachlichem
wicht der graphischen Modellierung (ob in UML Problem und Implementierung lassen ihre Behand-
oder in anderer Form). Auf das Potential fachlicher lung in der Lehre weiterhin sinnvoll erscheinen.
Modellierung sollte also in der Lehre noch stärker
Die Aktivität der modellbildenden Abstraktion ist
hingewiesen werden.
eine grundlegende Querschnittskompetenz in der
Informatik (Engels, Hausmann, Lohmann, & Sauer,
UML in der Lehre – belassen, verän- 2006). Vor diesem Hintergrund dient die Beschäfti-
dern, abschaffen? gung mit UML grundsätzlich dem Erlernen dieser
Die Beschreibung von Software mithilfe von Mo- Kompetenz – ganz unabhängig davon, ob man die
dellen ist eine essentielle Aufgabe und gehört da- konkreten Modellelemente auch tatsächlich später
her zum Kernbestandteil der Softwaretechnikaus- in seiner beruflichen Praxis verwendet.
bildung. Bereits von 10 Jahren stellte Glinz dazu ein Darüber hinaus scheinen einige UML-Diagramm-
Thesenpapier über die Rolle der Modellierung in typen intuitiv verständlich und gut anwendbar zu
der Lehre vor (Glinz, 2008), das jedoch nicht spezi- sein, oder zumindest als bewusste oder unbewusste
fisch auf UML bezogen ist. Vorlagen für eine informelle Modellierung zu die-
Die dargestellten empirischen Untersuchungen nen. Sie können daher als eine Art von informati-
zeigen, dass die UML in der Praxis eher selektiv scher Allgemeinbildung angesehen werden. (siehe
eingesetzt wird. Eine eigene schlaglichtartige Ana- auch These 2.)
lyse von studentischen Arbeiten bestätigt diesen These 2. Die Lehre sollte sich auf ausgewählte
Eindruck auch für diejenigen Informatikern, die UML-Modellelemente fokussieren.
gerade ins Berufsleben eintreten. Die dargestellten Studienergebnisse legen nahe,
Welcher Schluss ist daraus für die zukünftige Aus- dass ein Anspruch an Studierende, die UML-
gestaltung und Weiterentwicklung der Software- Sprachelemente möglichst umfänglich zu beherr-
technik-Lehre zu ziehen? Ist die UML-Ausbildung schen, nicht sinnvoll ist. Insbesondere die hohe
in ihrer jetzigen Form noch zeitgemäß? Sollte sie Komplexität und der hohe Formalisierungsgrad
verändert werden? Oder wäre es sinnvoll, sie ganz der UML erscheint nicht mehr zeitgemäß, da insbe-
aus den Curricula von Informatik-Studiengängen sondere die Maschinenlesbarkeit von UML Model-
zu verbannen? Diese Fragen kann nur durch eine len für Codegenerierung bzw. direkter Ausführung
Diskussion in der Fachcommunity beantwortet („Executable UML“) sich nicht in der Breite durch-
werden. Dazu möchten wir nicht nur die mögli- setzen konnten.
chen Alternativen aufzeigen, sondern auch selbst Wie die empirischen Untersuchungen zeigen, wer-
Stellung beziehen. den UML-Modelle vielfach informell zur Kommu-
Die Erkenntnisse und Schlussfolgerungen aus Re- nikation und Zusammenarbeit eingesetzt. In diesen
cherche und eigenen Erhebungen legen unserer Situationen werden nur wenige Sprachelemente
Meinung nach nahe, dass eine UML-Ausbildung in benötigt. Einige Diagrammtypen scheinen intuitiv
der Form, wie sie vor 15 Jahren angemessen war, verständlich und gut merkbar zu sein. Sowohl in
heute nicht mehr in die Zeit passt. Die Gründe hier- der Praxis wie auch in der Auswertung studenti-
für haben wir unter „Zwischenfazit und Diskussi- scher Arbeiten werden diese Elemente mehr oder
on“ bei UML-Nutzung durch Praktiker und durch weniger nahe am definierten Standard verwendet.
Studierende aufgezeigt. Ein reines „Belassen“ ist Dies trifft insbesondere auf Klassen-, Use-Case und
unserer Ansicht nach also keine sinnvolle Option. Sequenz-Diagramme zu.
Ebenso wenig erscheint es angebracht, UML kom- Andere UML-Diagrammtypen findet man häufig
plett aus den Curricula zu entfernen. Unsere Er- auch in einer informellen, „verballhornten“ Form,
kenntnisse legen nicht den Schluss nahe, dass UML die sich aber durchaus mehr oder weniger deutlich
für die Softwaretechnik nicht mehr relevant ist. an den UML-Sprachelementen orientiert. Beispiele
Damit erscheint eine Anpassung des jetzigen Lehr- hierfür sind Komponenten-, Deployment-, Aktivi-
konzepts der sinnvollste Ansatz zu sein. Aus den täts-, Zustands- und Kommunikationsdiagramme.
obigen Analysen und Erkenntnissen lassen sich Diese Tatsache allein ist unserer Ansicht nach
durchaus Bereiche identifizieren, in denen eine Grund genug, Kompetenzen in den „originalen“
Neujustierung der Lehre sinnvoll ist. Um eine UML-Diagrammtypen in der Lehre zu vermitteln.
Fachdiskussion zum Thema anzuregen, haben wir Eine größere Bedeutung hat die UML nach wie vor
unsere Vorschläge als Thesen strukturiert. für die Analyse, z.B. für Domänen- oder Geschäfts-
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 17
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
prozessmodelle. Da in diesen Fällen sowohl Mo- These 5. Die Modellierungskompetenz sollte auf
dellersteller als auch -nutzer Menschen sind, ist ein das Absolventenprofil abgestimmt sein.
geringeres Maß an Formalität ausreichend. Sinnvoll wäre aus unserer Sicht eine Herleitung der
Dafür wird der durch die hohe Ausdrucksstärke angestrebten Modellierungskompetenz anhand des
bedingte große Umfang an Modellelementen je- gewünschten Kompetenzprofils pro Studienfach
doch nicht benötigt. Dies sorgt zum einen für Kon- und bestehenden Vorkenntnissen. Bei reinen In-
kurrenz durch informelle Modellierungsansätze, formatikstudiengängen ist in der Regel das Berufs-
für eine hohe Hürde beim Erlernen der UML sowie bild des Softwarearchitekten Teil des Absolventen-
auch mangelhafte Einsicht in die Notwendigkeit profils, was einen bewussten Umgang mit Me-
der Sprachbeherrschung bei den Studierenden. taebenen und Abstraktion voraussetzt. Im Gegen-
satz dazu steht bei angehenden Medien- oder Wirt-
Konkrete Kandidaten für eine Verschlankung in
schaftsinformatikern eher die Anwendung im Vor-
der Lehre sind nach unserer Ansicht die Vielzahl
dergrund. Verschiedene technische Studiengänge
von Beziehungstypen in Komponentendiagram-
sind z.B. mit der Entwicklung von Echtzeitsyste-
men, detaillierte Spezifikation von Extension Points
men befasst, in denen formale Verifikation und
in Use-Case-Diagrammen oder komplexe Entry-
Codegenerierung relevant sind.
und Exit- Aktionen in Zustandsdiagrammen.
These 3. Die Lehre sollte sich auf die Beherr- Zudem spielt Ausrichtung des Studiengangs auf
schung von Einsatzkontexten anstatt von UML- eine Zieldomäne eine wichtige Rolle. Dabei sollten
Diagrammtypen fokussieren. die verschiedenen Schwerpunkte in Softwarepro-
dukten (Web vs. Backend, E-Commerce / Social
Die GI gibt für die Informatikausbildung an Hoch- Media vs. betriebliche Anwendungssysteme) sowie
schulen folgende inhaltliche Empfehlungen mit Projektmanagementansätze (agil vs. phasenorien-
Bezug zur UML (Gesellschaft für Informatik, 2016): tiert) als Leitlinie dienen. In weiterführenden Mo-
- Stufe 1 (Verstehen): „Verschiedene Notationen dulen zum Thema Softwareproduktlinien oder
wie z.B. UML für die Modellierung von Soft- Softwarewartung können besondere Einsatzberei-
waresysteme erläutern.“ che der Modellierung erschlossen werden.
- Stufe 2 (Anwenden): „Standardsituationen im
Bereich der Modellierung (…) umsetzen. Die These 6. Die UML-Ausbildung sollte die Model-
Begriffswelt des Anwenders durch geeignete lierung von Fachlichkeit stärker fokussieren.
Vorgehensweisen erfassen und zu einer fachli- Die Lehre sollte die frühen Phasen der Modellbear-
chen Terminologie im Projekt verdichten.“ beitung stärker in den Fokus nehmen. UML hat
- Stufe 3 (Analysieren): „Die Eignung eines Vor- große Stärken in der Beschreibung einer fachlichen
gehensmodells, einer Notation oder einer Me- Domäne in Form eines fachlichen Datenmodells
thode für ein klassifiziertes Softwaresystem sowie von geschäftlichen Abläufen als Aktivitäts-
oder eine klassifizierte Aufgabe einschätzen.“ diagrammen. Transaktionale Vorgänge lassen sich
In dieser Systematik ist 2 (Anwenden) die praxisre- sehr gut als Zustandsdiagramme eines Geschäfts-
levanteste Lernstufe. Allerdings wird in realen objekts beschreiben.
Projekten nicht die Kompetenz „Entwerfe ein Unsere Auswertung der studentischen Arbeiten hat
UML-Klassendiagramm“ gefordert, sondern „Ent- im Gegensatz dazu gezeigt, dass UML eher für die
werfe ein fachliches oder logisches Datenmodell“. technische Beschreibung aus Entwickler- statt aus
Daher plädieren wir dafür, in der Formulierung Nutzersicht eingesetzt wird (siehe z.B. Abb. 7).
von Lernzielen den Fokus von UML-Diagramm- These 7. Die Lehre sollte nicht Tools, sondern
typen hin zu Einsatzkontexten graphischer Model- Kommunikation und Interaktivität in den Fokus
lierung zu lenken. In Tab. 2 haben wir dazu einen stellen.
Vorschlag von zwölf Einsatzkontexten gemacht.
Softwareentwicklung wird immer stärker durch
These 4. Die Fähigkeit zur Auswahl von Model- Kommunikation und Zusammenarbeit geprägt.
lierungsansätzen sollte gestärkt werden. Damit sollte die Ausbildung die interaktive Nut-
Neben der UML haben sich diverse andere mehr zung von UML stärker einüben, z.B. in der Analy-
oder weniger formale Modellierungsansätze etab- se- und frühen Entwurfsphase, in der in der Praxis
liert. Informelle Modellierungsansätze sowie for- oft auf Papier oder am Whiteboard gearbeitet wird.
male Nicht-UML-Modellierungssprachen sollten Für die praktische Umsetzung ergeben sich daraus
daher vergleichend in die Lehre einfließen. Studie- interessante Fragestellungen in Bezug auf die kon-
rende sollten die Kompetenz erwerben, geeignete krete didaktische Umsetzung sowie die damit ver-
Modellierungsansätze, Diagrammtypen und den bundene geeignete Toolunterstützung.
angemessenen Detailgrad im Modell in Abhängig-
keit von der Aufgabenstellung auszuwählen. Dies
ist konform mit Stufe 3 der o.g. GI-Empfehlung.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 18
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Zusammenfassung und Ausblick Boberić-Krstićev, D., Tešendić, D., Simos, T. E.,
Psihoyios, G., Tsitouras, C., & Anastassi, Z.
Die Bedeutung von UML für die Softwaretechnik
(2011). Teaching Object-Oriented Modelling Us-
ist in Veränderung begriffen. Die Ursachen dafür
ing UML. In Numerical Analysis and Applied
liegen in Trends, die umfangreiche Modellierungen
Mathematics ICNAAM 2011 (S. 810–812). AIP.
nicht mehr erforderlich machen. Dazu gehören
https://doi.org/10.1063/1.3636856
agile Entwicklungsansätze, Microservicearchitektu-
ren sowie das weitgehende Scheitern des MDA- Bourque, P., Fairley, R. E., & IEEE Computer Socie-
Ansatzes, der detaillierte und formale Modelle ty. (2014). Guide to the Software Engineering Body
erfordert. Die Aufmerksamkeit, die diesen Themen of Knowledge (SWEBOK(R)): Version 3.0 (3.
derzeit geschenkt wird, darf nicht darüber hinweg- Aufl.). IEEE Computer Society Press.
täuschen, dass in vielen Großprojekten oder für Brown, S. (2018). The C4 model for software archi-
sicherheitskritische Produkte die UML nach wie tecture. Abgerufen 21. Oktober 2018, von
vor eine sehr wichtige Rolle spielt. https://c4model.com/
Aus unserer Sicht ist es notwendig, die Stellung der Burgueño, L., Vallecillo, A., & Gogolla, M. (2018).
UML in der Lehre kritisch zu hinterfragen. Wir Teaching UML and OCL models and their vali-
haben in diesem Beitrag dazu empirische Belege dation to software engineering students: an ex-
über die Nutzung der UML zusammengetragen. perience report. Computer Science Education,
Diese Bestandsaufnahme diente als Grundlage für 28(1), 23–41.
die Ableitung von Konsequenzen für die Ausge- https://doi.org/10.1080/08993408.2018.1462000
staltung der Lehre. Naturgemäß kann dies keine Chaudron, M. R. V., Heijstek, W., & Nugroho, A.
abschließende Bewertung sein, sondern soll ent-
(2012). How effective is UML modeling ? Soft-
sprechend unserer Zielsetzung Impulse zu diesem
ware & Systems Modeling, 11(4), 571–580.
Thema liefern.
https://doi.org/10.1007/s10270-012-0278-4
Für weiterführende Arbeiten erscheint neben einer
Cockburn, A. (2006). Agile Software Development: The
Verbreiterung und Aktualisierung der empirischen
Cooperative Game (0002 Aufl.). Upper Saddle
Basis auch eine Ausdifferenzierung hinsichtlich
River, NJ: Addison Wesley Pub Co Inc.
verschiedener Studienrichtungen und -niveaus
sinnvoll. Es muss beobachtet werden, wie sich die Coplien, J. O., & Bjørnvig, G. (2010). Lean architec-
Nutzung der UML in der Praxis weiterentwickelt. ture for Agile software development. Hoboken,
Dabei sind Situationen zu betrachtet, in denen Mo- N.J.: Wiley.
delle einen Mehrwert leisten. Wer ist Modellerstel- Davies, I., Green, P., Rosemann, M., Indulska, M., &
ler, wer -nutzer? Wie umfangreich und präzise Gallo, S. (2006). How do practitioners use con-
müssen die Modelle sein? Müssen aufkommende ceptual modeling in practice? Data & Knowledge
Programmierparadigmen wie funktionale und de- Engineering, 58(3), 358–380.
klarative Programmierung berücksichtigt werden, https://doi.org/10.1016/j.datak.2005.07.007
da UML unmittelbar mit OOP zusammenhängt?
Dobing, B., & Parsons, J. (2010). Dimensions of
Wie kann Fachlichkeit stärker in den Fokus ge-
UML Diagram Use: Practitioner Survey and Re-
nommen werden? Wie kann der identifizierte
search Agenda. Principle Advancements in Data-
Kompetenzbedarf in praxisorientierten Lehrkon-
base Management Technologies: New Applications
zepten umgesetzt werden? Wir hoffen, mit diesem
and Frameworks, 271–290.
Beitrag die Diskussion dazu ein Stück weit ange-
https://doi.org/10.4018/978-1-60566-904-5.ch013
regt zu haben.
Engels, G., Hausmann, J. H., Lohmann, M., & Sau-
er, S. (2006). Teaching UML Is Teaching Soft-
Literaturangaben ware Engineering Is Teaching Abstraction. In J.-
Baltes, S., & Diehl, S. (2014). Sketches and diagrams M. Bruel (Hrsg.), Satellite events at the MoDELS
in practice. In S.-C. Cheung, A. Orso, & M.-A. 2005 conference (Bd. 3844, S. 306–319). Berlin:
D. Storey (Hrsg.), Proceedings of the 22nd ACM Springer. https://doi.org/10.1007/11663430‗
SIGSOFT International Symposium on Founda-
Erickson, J., & Siau, K. (2007). Can UML Be Simpli-
tions of Software Engineering, (FSE-22), Hong
fied? Practitioner Use of UML in Separate Do-
Kong, China, November 16 - 22, 2014 (S. 530–541).
mains.
ACM. https://doi.org/10.1145/2635868.2635891
Evans, E. (2003). Domain-Driven Design: Tackling
Beck, K., Beedle, M., Bennekum, A. van, Cockburn,
Complexity in the Heart of Software (1 edition).
A., Cunningham, W., Fowler, M., … Thomas,
Boston: Addison-Wesley Professional.
D. (2001). Manifesto for Agile Software Develo-
pment. Abgerufen 30. November 2018, von Gesellschaft für Informatik. (2016). Empfehlungen
http://agilemanifesto.org/ für Bachelor- und Masterprogramme im Studienfach
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 19
UML in der Hochschullehre: Eine kritische Reflexion
Jürgen Anke und Stefan Bente, HFT Leipzig & TH Köln
Informatik an Hochschulen (GI-Empfehlungen). Seiko Akayama, Birgit Demuth, Timothy Leth-
Abgerufen von bridge, Marion Scholz, Perdita Stevens, & Dave
https://gi.de/fileadmin/GI/Hauptseite/Aktuelles R. Stikkolorum. (2013). Tool Use in Software
/Meldungen/2016/GI-Empfehlungen_Bachelor- Modelling Education. In EduSymp@MoDELS.
Master-Informatik2016.pdf Sommerville, I. (2015). Software Engineering, Global
Gianna Reggio, Maurizio Leotta, Filippo Ricca, & Edition (10th edition). Boston: Pearson.
Diego Clerissi. (2013). What are the used UML
diagrams? A Preliminary Survey. In EESS-
MOD@MoDELS.
Glinz, M. (2008). Modellierung in der Lehre an
Hochschulen: Thesen und Erfahrungen. Infor-
matik-Spektrum, 31(5), 425–434.
https://doi.org/10.1007/s00287-008-0273-x
Gorschek, T., Tempero, E., & Angelis, L. (2014). On
the use of software design models in software
development practice: An empirical investiga-
tion. Journal of Systems and Software, 95, 176–193.
https://doi.org/10.1016/j.jss.2014.03.082
Jacobson, I. (2009). Taking the temperature of UML.
Abgerufen 1. November 2018, von
http://blog.ivarjacobson.com/taking-the-
temperature-of-uml/
Langer, P., Mayerhofer, T., Wimmer, M., & Kappel,
G. (2014). On the usage of UML: initial results
of analyzing open UML models. In H.-G. Fill
(Hrsg.), Modellierung 2014. Bonn: Köllen.
Larman, C., & Vodde, B. (2009). Scaling lean & agile
development: thinking and organizational tools for
large-scale Scrum. Upper Saddle River, NJ: Ad-
dison-Wesley.
Leffingwell, D. (2007). Scaling Software Agility: Best
Practices for Large Enterprises. Upper Saddle
River, NJ: Pearson Education.
Liebel, G., Heldal, R., & Steghofer, J.-P. (2016). Im-
pact of the Use of Industrial Modelling Tools on
Modelling Education. In 2016 IEEE 29th Interna-
tional Conference on Software Engineering Educa-
tion and Training (CSEET) (S. 18–27). IEEE.
https://doi.org/10.1109/CSEET.2016.18
Osman, H., & Chaudron, M. R. V. (2013). UML
Usage in Open Source Software Development:
A Field Study. Gehalten auf der EESS-
MOD@MoDELS 2013.
Petre, M. (2013). UML in Practice. In Proceedings of
the 2013 International Conference on Software En-
gineering (S. 722–731). Piscataway, NJ, USA: IE-
EE Press. Abgerufen von
http://dl.acm.org/citation.cfm?id=2486788.24868
83
Rupp, C., Queins, S., & SOPHISTen, die. (2012).
UML 2 glasklar: Praxiswissen für die UML-
Modellierung (4. Aufl.). München: Carl Hanser
Verlag.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 20