Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Doris Schmedding, Anna Vasileva, Technische Universität Dortmund doris.schmedding | anna.vasileva@tu-dortmund.de Zusammenfassung Im Mittelpunkt dieses Beitrags steht allerdings die Qualitätskontrolle mittels gegenseitiger Reviews. In modellgetriebenen Software-Entwicklungspro- Wenn es möglich wäre, größere Mängel frühzei- jekten in der Ausbildung besteht das Problem, dass tig in den Modellen zu erkennen, so kann es sicher- die Qualität der Modelle oft schlecht ist. In diesem lich auch möglich sein, diese leichter und schneller Beitrag wird ein Konzept vorgestellt, wie durch ge- zu beheben, als dies während der Code-Erstellung genseitige Reviews der Entwicklerteams die Quali- der Fall ist (Boehm, Basili, 2001). Dies könnte dann tät der Modelle verbessert wird. Die Reviews basie- von vornherein zu einer besseren Code-Qualität ren auf einem Kriterienkatalog, der aus einem Qua- und zu einer besseren Wartbarkeit des Programm- litätsmodell entwickelt wurde. Das Software-Prakti- Codes führen, was insgesamt eine große Zeit- und kum bietet einen geeigneten Rahmen, dieses inter- Kostenersparnis bedeuten kann. Das setzt natürlich aktive Konzept einzusetzen. Wir stellen unsere Vor- voraus, dass sich das Entwicklungsteam eng an die gehensweise und unsere Erfahrungen vor. fertigen Modelle hält und nicht unzählige Verände- rungen und neue Elemente in der Implementie- Motivation rungsphase hinzufügt, ohne die Modelle dement- Die intensive Auseinandersetzung mit der Code- sprechend anzupassen und erneut zu prüfen. Qualität in den studentischen Projekten im Soft- Den Kontext unseres Erfahrungsberichts liefert ware-Praktikum (Vasileva, Schmedding, 2016; das Software-Praktikum der Fakultät für Informatik Schmedding, Vasileva, Remmers, 2015) führte uns der TU Dortmund. Das Ziel des SoPras ist es, im zu der Erkenntnis, dass manche Code-Mängel be- Rahmen von Software-Entwicklungsprojekten die reits im Modell zu finden sind. Im Software-Prakti- Methoden und Verfahren, die in der vorangehenden kum (kurz SoPra), das den Kontext unseres Beitrags Vorlesung Software-Technik kennen gelernt und ge- bildet, entwickeln die Studierenden Software nach übt wurden, im Zusammenhang eines Projekts an- dem Konzept der modellgetriebene Software-Ent- zuwenden. Außerdem dient das SoPra dazu, die in wicklung. Modellgetriebene Software-Entwicklung der Einführungsveranstaltung „Datenstrukturen, bedeutet, dass automatisiert aus formalen Modellen Algorithmen und Programmierung“ erworbenen vollständig oder wenigstens teilweise lauffähige Programmierkenntnisse zu vertiefen. Software erzeugt wird. (Bettin, Helsen, Kunz, 2007) Im SoPra führen acht Bachelorstudierende ge- Daneben bieten die Modelle in der modellgetrie- meinsam zwei Projekte durch. Etwa sechs bis zehn benen Software-Entwicklung eine gute Arbeits- und Gruppen bearbeiten gleichzeitig die gleichen Aufga- Kommunikationsgrundlage für das Entwicklerteam ben. In einem Blockpraktikum in der vorlesungs- in den frühen Phasen der Software-Entwicklung. freien Zeit dauert ein Projekt drei Wochen. Es wer- Außerdem können sie als Dokumentation der Soft- den nacheinander in sechs Wochen zwei Projekte ware dienen, so dass spätere Überprüfungen der nach einem einfachen Wasserfallmodell durchge- Anforderungen, Analysen des Codes, Verbesserun- führt. Dieses Software-Entwicklungsmodell hat sich gen und Erweiterungen oder Wiederverwendungen bei der Arbeit mit den Studierenden, die zum ersten der Software in anderen Bereichen leichter möglich Mal ein Projekt durchführen, gut bewährt. sind (Fieber, Huhn, Rumpe, 2008). Deshalb ist es Wir verwenden die Programmiersprache Java wichtig, die Modelle bereits frühzeitig einer Quali- aus der Einführungsveranstaltung. Zur Modellie- tätsprüfung zu unterziehen. Diese kann teilweise rung setzen wir die Sprache UML ein, die in der automatisiert erfolgen, wie z.B. bei Arendt (Arendt, Software-Technik-Vorlesung eingeführt wird. Die 2014), da die Modelle in digitaler Form vorliegen. Modellierung erfolgt mit dem Tool Astah (Astah, Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 8 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen 2016), das leichtgewichtig, sehr benutzerfreundlich und intuitiv bedienbar ist. Deshalb kommen die Studierenden nach unserer Erfahrung damit gut zu recht. Im Rahmen der modellgetriebenen Entwicklung werden aus dem mit Astah erstellten Strukturmo- dell Java-Code-Rahmen generiert. Als Entwick- lungsumgebung verwenden wir Eclipse mit dem SVN-Plugin Subclipse. Die Dokumentation mit JavaDoc und JUnit-Tests sind weitere wichtige Bestandteile unseres Entwicklungsprozesses. Der gesamte Entwicklungsprozess ist durchzo- gen von Maßnahmen zur Qualitätssicherung. Wäh- rend des Software-Praktikums gibt es interne und externe Reviews, Abgaben, Korrekturen und Ab- nahmen. Nach jedem Entwicklungsschritt werden die erzeugten Dokumente, bei denen es sich oft um UML-Diagramme, aber auch um Textdokumente handelt, im internen Bereich des SoPra-Wikis Abb. 1. UML-Modellierung im SoPra (SoPra-Wiki, 2016) des Projektteams hochgeladen. Um von der Modellqualität auf die Code-Qualität Die Dokumente werden innerhalb der Gruppe dis- schließen zu können, muss das Modell ein abstrak- kutiert und vom Betreuer korrigiert. Sowohl das An- tes Abbild dessen sein, was das Team entwickeln forderungsmodell als auch das Analysemodell wer- will. den von jeder Gruppe im öffentlichen Bereich des Im folgenden Kapitel wird vorgestellt, wie UML Gruppen-Wikis hochgeladen und sind damit für alle im SoPra zur Modellbildung eingesetzt wird. Da- SoPra-Teilnehmer lesbar. Die Diagramme werden nach folgen Überlegungen zur Qualität von UML- anschließend im Plenum vor anderen Gruppen vor- Diagrammen. Anschließend wird das Konzept von gestellt und Unterschiede und Mängel diskutiert. Reviews und ihre Bedeutung im Software-Entwick- Am Ende eines Projekts erfolgt die gegenseitige Ab- lungsprozess diskutiert. Es folgt die Rolle, die die nahme und Bewertung der Projekte durch die Grup- Reviews in der Lehrveranstaltung Software-Prakti- pen. Die Code-Qualität wird mit Hilfe von PMD kum spielen. Danach werden die Erfahrungen mit (PMD, 2016), einem Tool zur statischen Code-Ana- dem gewählten Vorgehen im Software-Praktikum lyse, sowohl von den Teammitgliedern selbst als diskutiert. Der Artikel schießt mit einer Zusammen- auch von den Lehrenden gemessen. fassung und einem Ausblick. Auch wenn man nach drei Wochen nicht erwar- ten kann, ein perfekt funktionierendes Programm zu erhalten, besitzt die funktionale Korrektheit den Modellierung mit UML im SoPra höchsten Stellenwert und wird als vorrangiges Ziel Die Modellierung mit UML findet im SoPra sowohl in der Software-Entwicklung von keinem der Betei- in der Phase Anforderungsdefinition als auch in der ligten in Frage gestellt. Für die Studierenden ist in Analysephase statt. Abb. 1 zeigt die Entwicklungs- ihrem eigenen Projekt und bei der Bewertung der hasen und die Zusammenhänge zwischen den Ergebnisse der anderen Gruppen auch das Ausse- Diagrammen des Modells, die im SoPra verwendet hen eines Programms sehr wichtig, insbesondere bei werden. Spielen. In der ersten Phase des Software-Entwicklungs- In den letzten Jahren ist es uns gelungen, auch prozesses werden die Anforderungen erhoben die Code-Qualität erfolgreich als Ziel in der Veran- und das Anforderungsmodell erstellt, das aus staltung zu verankern (Vasileva, Schmedding, 2016; Anwendungsfalldiagramm, Aktivitätsdiagrammen Schmedding, Vasileva, Remmers, 2015). Da manche und Problembereichsmodell besteht. Ein Anwen- Mängel, die bei der Bestimmung der Code-Qualität dungsfalldiagramm stellt die funktionalen Anforde- gemessen werden, wie z.B. schlecht gewählte rungen in Form von Anwendungsfällen dar, die die Bezeichner, bereits im Modell erkennbar sind, rich- Nutzer des Systems in unterschiedlichen Rollen aus- tet sich unser Augenmerk in unserer aktuellen führen können. Anschließend wird jeder Anwen- Arbeit auf die Modellqualität. Wir vermuten, dass dungsfall näher beschrieben, indem der genaue Ab- sich auch gravierendere Mängel, wie zu komplexe lauf durch ein Aktivitätsdiagramm dargestellt wird. Methoden und Klassen, bereits im Modell erkennen Zu jedem Aktivitätsdiagramm gehört ein erläutern- lassen. Voraussetzung dafür ist natürlich, dass das der Text, der u.a. die Vor- und Nachbedingungen Modell aussagekräftig genug ist, d.h. dass es genü- enthält. Ein Beispiel für ein typisches Aktivitätsdia- gend durchdacht ist und genügend Details enthält. gramm aus dem SoPra befindet sich in Anhang A. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 9 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Abb. 2: Qualitätsmodell des Software-Praktikums Die Aktivitätsdiagramme sind wichtige Be- Präsentation werden das Anwendungsfalldia- standteile des Entwicklungsprozesses. Beim Erstel- gramm, drei Aktivitätsdiagramme sowie das Prob- len dieser Diagramme stellen die Studierenden zum lembereichsmodell zwei anderen Gruppen im Ple- ersten Mal fest, dass einige Anwendungsfälle sehr num vorgestellt. In der zweiten Phase werden drei komplex sind. Andere Anwendungsfälle funktio- Sequenzdiagramme und das Strukturmodell prä- nieren nicht so, wie sie zunächst gedacht haben. sentiert. Der Entwicklungsprozess startet also mit einer ausführlichen Erhebung der funktionalen Anforde- Zur Qualität von UML-Diagrammen rungen, auf die im weiteren Verlauf des Prozesses In der Literatur finden sich verschiedene Ansätze immer wieder zurückgegriffen wird. Daneben wird zur Definition und Bewertung der Modellqualität, ein Datenmodell, das so genannte Problembereichs- von denen hier zwei genauer betrachtet werden. Der modell, erstellt, das die Klassen des Problembe- erste Ansatz stammt von Unhelkar (Unhelkar, 2005), reichs mit ihren Attributen und den Beziehungen der die Modelle unter den Gesichtspunkten ihrer untereinander darstellt. Anwendung im Entwicklungsprozess betrachtet, In der Analysephase wird das Problembereichs- d.h., für welchen Zweck sie erstellt werden und wie modell zum Strukturmodell ausgebaut, indem Steu- grob oder detailliert die Modelle dementsprechend erungsklassen ergänzt und Methoden hinzugefügt sein sollten. Dazu unterteilt er die Qualität in drei werden. Wir streben aus Gründen der Übersichtlich- Aspekte: Syntax, Semantik und Ästhetik. Syntax be- keit und Einfachheit eine Dreischichtenarchitektur schäftigt sich mit der Korrektheit der verwendeten an, die sich an dem Model-View-Controller-Muster Diagrammelemente und Semantik mit der korrek- der Software-Entwicklung orientiert. Um zu über- ten und vollständigen Abbildung der Aufgabenstel- prüfen, ob im Strukturmodell alle Methoden voll- lung. Unter Ästhetik subsummiert Unhelkar Be- ständig erfasst sind, werden Sequenzdiagramme griffe wie Übersichtlichkeit und Verständlichkeit, eingesetzt, die in der Regel die Anwendungsfälle aber auch Granularität. Für jeden Diagrammtyp und aus dem Anwendungsfalldiagramm repräsentieren. für jeden Qualitätsaspekt benennt Unhelkar begrün- Bei der Definition der Methoden im Strukturmodell dete Kriterien und Regeln für die Bewertung der werden die Signaturen der Methoden vollständig Qualität, die er in Form von Checklisten zusammen- angegeben. stellt. Das Strukturmodell und die Sequenzdia- Der zweite Ansatz stammt von Arendt (Arendt, gramme sind inhaltlich gekoppelt. Bei Astah liegt 2014), der stattdessen bei der Entwicklung eines diesen beiden Diagrammtypen ein gemeinsames Qualitätsmodells für UML-Modelle den Versuch Datenmodell zugrunde, so dass im Sequenzdia- unternimmt, die Metriken, die für die Untersuchung gramm die Klassen und Methoden aus dem Struk- der Codequalität entwickelt wurden, auf Modelle zu turmodell verwendet werden können. übertragen. Im Rahmen seiner Arbeit beschränkt er Am Ende der Anforderungs- und der Analyse- sich auf Klassendiagramme. Dabei betrachtet er die phase finden Präsentationen statt. Bei der ersten Qualität von Modellen unter den Gesichtspunkten Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 10 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen der Qualitätsziele von Mohegheghi (Mohagheghi, Dehlen, Neple, 2009), den sogenannten 6C-Zielen. Diese umfassen Korrektheit (correctness), Vollstän- digkeit (completeness), Konsistenz (consistency), Verständlichkeit (comprehensibility), Beschränkung auf das Wesentliche (confinement) und Änderbar- keit (Changeability) (Arendt, 2014). Hinzu zieht Arendt die Qualitätsziele von Fieber (Fieber, Huhn, Rumpe, 2008), die er im Weiteren als Qualitätseigen- schaften bezeichnet (zur besseren Unterscheidung von den 6C-Zielen) (Thorsten Arendt, 2014). Einige davon sind Präsentation, Einfachheit, Konformität, Kohäsion, Redundanz, semantische Angemessen- Abb. 3: Regelkonforme Diagramme im SoPra heit, Korrektheit, Präzision, Vollständigkeit bzgl. Anforderungs- und Lösungsphase, Rückverfolgbar- tation von UML zu komplex geworden ist. Einer- keit und Veränderbarkeit. seits macht die Komplexität die Einarbeitung in dem Wir orientieren uns bei der Zusammenstellung Bereich der Modellierung schwierig und zeitauf- der Qualitätskriterien an der Arbeit von Unhelkar, wendig. Andererseits können die Tools zur Model- da bei uns alle Diagramme, auch diejenigen, die lierung von UML-Diagrammen den ganzen Sprach- ganz früh im Entwicklungsprozess entstehen, be- umfang nicht umsetzen, was zum Entstehung eige- gutachtet werden. Es geht im SoPra nicht nur um die ner teilweise komplett unterschiedlichen Versionen Generierung von möglichst gutem Java-Code aus führt. Aus diesem Grund brauchen die Entwickler dem Klassendiagramm, sondern auch um die Qua- klare Richtlinien, welche Diagrammtypen und -ele- lität des gesamten Modells mit allen Diagrammen, mente sie bei der Modellierung verwenden sollen. die im SoPra erstellt werden, da diese Diagramme Im SoPra haben sich zur Qualitätssicherung be- die Arbeits- und Kommunikationsgrundlage des stimmte „Best-Practice-Regeln“ bewährt, die insbe- Entwicklerteams in allen Phasen des Entwicklungs- sondere dafür sorgen, dass der Informationsgehalt prozesses darstellen. Die Diagramme dokumentie- der Diagramme genügend groß ist. Die Diagramme ren den Grat, mit dem das Team die Aufgabenstel- sollen viele, aber nicht zu viele Details enthalten, da- lung durchdrungen hat. mit sie informativ, aber nicht unübersichtlich wer- Diese Überlegungen führen zu dem in Abb. 2 den. Diese Gratwanderung zwischen Unübersicht- dargestellten Qualitätsmodell für UML-Dia- lichkeit durch zu viele Details und Oberflächlich- gramme. Die einzelnen Qualitätseigenschaften wer- keit, also die Wahl des richtigen Abstraktionsgrads, den im Folgenden näher erläutert. stellt für Modellierungsanfänger eine sehr große Herausforderung dar. Wir versuchen durch Regeln, Syntax und Konsistenz z.B. wie viele Anwendungsfälle ein Anwendungs- Das im SoPra verwendete UML-Tool Astah ar- falldiagramm mindestens und maximal beinhalten beitet syntaxbasiert, aber nicht syntaxgesteuert. Da sollte, hier eine Hilfestellung zu geben. während des Modellierens zwangsweise immer Eine weitere Regel, die der inhaltliche Aussage wieder Diagrammzustände entstehen, die syntak- von Aktivitätsdiagrammen zugutekommt, ist die tisch nicht korrekt sind, lässt Astah dem Modellierer Verwendung von Partitionen in Aktivitätsdiagram- viele Freiheitsgrade. Deshalb besteht für wenig er- men. Normalerweise verfügen Aktivitätsdia- fahrene Modellierer die Gefahr, dass Diagramme gramme im SoPra über zwei Partitionen – “Benut- entstehen, die nicht dem UML-Meta-Modell ent- zer” und “System”. Auf diese Weise wird nicht nur sprechen und syntaktische Fehler beinhalten. Ein dargestellt, wie der Benutzer mit dem System inter- Beispiel für einen derartigen Mangel ist ein fehlen- agiert, sondern auch die Reaktion des Systems auf der Endknoten in einem Aktivitätsdiagramm. Ein die Aktivitäten des Benutzers. Ein Beispiel findet Diagramm mit diesem Fehler würde in die Klasse sich in Anhang A. „Astah-konform“ fallen, da es ohne Fehlermeldung Abb. 3 stellt dar, in welcher Beziehung die UML- von Astah erstellbar ist, aber es würde wegen der konformen Diagramme, die Astah-konformen Dia- Syntaxfehlers nicht in der Klasse „UML-konform“ gramme und die mit den SoPra-Regeln konformen liegen. Diagramme zueinanderstehen. Alle SoPra-kon- Insgesamt stellt die Komplexität der UML so- forme Diagramme liegen Schnittmenge zwischen wohl in der Ausbildung als auch in der Industrie ein den UML- und Astah-konformen Diagrammen. Die großes Problem dar. Eine Studie (Petre, 2013) hat ge- im Rahmen des SoPras erstellten Diagrammen müs- zeigt, dass 35 von 50 befragten Unternehmen UML sen eine echte Teilmenge dieser Menge sein, da sie nicht verwenden. Ein Grund dafür ist, dass die No- die SoPra-Regeln einhalten müssen. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 11 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Eine besondere Rolle für das Klassendiagramm Ästhetik spielt unsere Implementierungssprache Java. Astah Die Frage nach dem richtigen Abstraktionsgrad und auch UML lassen beispielsweise Mehrfacher- und der Menge von Details, die ein Modell enthalten bung zu, was Java ausschließt. Auch die Spezialisie- sollte, ist besonders wichtig für die Bewertung der rung von Interfaces ist im Klassendiagramm von ästhetischen Qualität eines Diagramms. Sie wird ge- Astah möglich, in Java nicht. prägt durch die Qualitätskriterien „Übersichtlich- Die nächste Gruppe von Mängeln in UML-Dia- keit“ und „Verständlichkeit“. Im Gegensatz zu Un- grammen bilden Inkonsistenzen. In einem Modell helkar betrachten wir Granularität nicht als eigen- können Inkonsistenzen zwischen Diagrammen des ständige Qualitätseigenschaft, vielmehr bestimmt gleichen Typs oder Inkonsistenzen zwischen Dia- die richtige Wahl der Granularität zusammen mit grammen unterschiedlichen Typs auftreten. anderen Merkmalen die Eigenschaften „Übersicht- Weiterhin besteht bei Astah das Problem der In- lichkeit“ und „Verständlichkeit“. Wenn ein Dia- konsistenz zwischen der graphischen Repräsenta- gramm zu viele Details enthält, kann es unübersicht- tion und den gespeicherten Daten. Teile der Grafik lich und dadurch unverständlich werden. Zu we- können gelöscht werden, ohne dass sie aus dem Mo- nige Details oder eine schlechte Bezeichnerwahl las- dell entfernt werden. Auf diese Weise lassen sich sen es unverständlich werden. Ein zu komplexes Di- übersichtliche Abbildungen gestalten. Die Code-Ge- agramm ist sowohl unübersichtlich als auch unver- nerierung basiert allerdings auf dem gespeicherten ständlich. Modell. Bei unachtsame Modellierern tauchen bei der Code-Generierung plötzlich Java-Klassen oder Die Aspekte der syntaktischen Qualität und die Methoden auf, die sie vermeintlich längst gelöscht Konsistenz der Diagramme lassen sich relativ ein- hatten. fach auch automatisch überprüfen, während sich Eine genaue Herleitung und Details sowie Bei- ihre semantische und ästhetische Qualität nur durch spiele wurden von Stefan Todorinski (Todorinski, Reviews feststellen lässt. 2016) in seiner Bachelorarbeit zusammengetragen. Allen bisher in diesem Kapitel dargestellten Män- Reviews in der Software-Entwick- geln ist gemeinsam, dass sie sich durch eine statische Analyse erkennen lassen. lung und in der Lehre Reviews sind in der Software-Entwicklung ein aner- Semantik kanntes Instrument zur Qualitätskontrolle. Nach Die nächste Kategorie von Mängeln stellen se- dem IEEE-Standard 1028 von 2008 (IEEE, 2008) ver- mantische Mängel dar. Hier geht es vor allem um steht man unter dem Begriff Review eine formell or- die Frage, ob die in der Aufgabenstellung festgeleg- ganisierte Zusammenkunft von Personen zur inhalt- ten Anforderungen vollständig und korrekt im Mo- lichen und formellen Überprüfung eines Produkt- dell umgesetzt werden. Striewe und Goedicke zei- teils (Dokument, Programmcode, usw.) nach vorge- gen in (Striewe, Goedicke, 2011), dass sich bei der gebenen Prüfkriterien und -listen. automatischen Korrektur von UML-Übungsaufga- Reviews werden meist in Form von Code-Re- ben auch semantische Mängel finden lassen. Aller- views zur Steigerung der Code-Qualität eingesetzt, dings funktioniert das nur gut für wenig umfangrei- aber auch zur Steigerung der Qualität der Doku- che Aufgabenstellungen wie z.B. Klausuraufgaben. mentation. Man unterscheidet zwischen informellen Die Lösung von Striewe und Goedicke basiert zwar Reviews, wie das Gegenlesen von Dokumenten nicht auf dem Vergleich mit einer Musterlösung, durch Kollegen, oder formellen Reviews, denen ein aber für die Korrektur müssen von den Lehrenden definierter Prozess mit festen Rollen und einer kon- für die Überprüfung der Lösung konkrete Abfragen kreten Checkliste zugrunde liegt. (Wiegers, 2001) in einer Abfragesprache definiert werden, die die Auch die Stellung der beteiligten Personen dient abgegebene Lösung erfüllen muss. als Kriterium für die Differenzierung von Review- Mängel im semantischen Bereich sind nach un- Typen. Man unterscheidet Peer-Reviews, bei denen serer Erfahrung in studentischen Projekten in erster nur der Autor und/oder Kollegen, die auf gleicher Linie darin begründet, dass die Modellierung nicht Ebene arbeiten, beteiligt sind, und Management-Re- vollständig genug ist. Das erstellte Diagramm mo- views, bei dem Personen aus dem Management als delliert den Sachverhalt nur oberflächlich, es geht Gutachter beteiligt sind und bei denen es in erster nicht genug in die Tiefe und enthält demnach nicht Linie darum geht, sich ein Bild vom Stand des Pro- genug Details. Daneben kommt es immer wieder jekts zu verschaffen. In der Lehre werden Reviews vor, dass die Aufgabenstellung missverstanden überwiegend im Form von Peer-Reviews, z. B. bei wird. der Erstellung von Seminararbeiten, eingesetzt. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 12 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Reviews haben im Software-Entwicklungspro- Reviews im SoPra zess zwei Funktionen. Im Vordergrund steht natür- lich das Entdecken von Fehlern und Mängel, entwe- Bereits im Motivationskapitel wurde darauf hinge- der durch die Person selbst, die die Fehler produ- wiesen, dass Reviews im SoPra in vielfältiger Form ziert hat, oder durch die Gutachter. Je frühzeitiger vorkommen. die Mängel entdeckt werden, desto geringere Kos- Zur Qualitätssicherung der UML-Diagramme ten verursacht ihre Beseitigung (Boehm, Basili, setzen wir im SoPra sowohl interne als auch externe 2001). Das sollte gerade bei der Begutachtung von Reviews der UML-Diagramme ein. Interne Begut- Dokumenten der frühen Entwicklungsphase wie achtungen innerhalb der Gruppe finden statt, wenn den UML-Diagrammen zur Anforderungsdefinition Diagramme, die von einzelnen Teilnehmern zu- eine große Rolle spielen. hause erstellt werden, in der Gruppe betrachtet und Die zweite wichtige Funktion besteht darin, dass kritisch diskutiert werden. Dabei wird eher infor- die Reviewer durch die intensive Auseinanderset- mell vorgegangen. zung mit dem zu begutachtenden Dokument oder Daneben gibt es auch externe, formelle Reviews. Programm-Code viel lernen. Sie lernen am Beispiel, Die gegenseitige Begutachtung der UML-Dia- indem sie Lösungsansätze sehen, deren Umsetzung gramme durch die SoPra-Gruppen erfolgt struktu- sie sich vielleicht nicht zugetraut hätten oder die riert und Checklisten-basiert. Ausgehend von dem ihnen selbst schlichtweg nicht eingefallen sind. in Abb. 2 dargestellten Qualitätsmodell wurde eine Die Gefahr bei sehr informellen Reviews, wie Checkliste (siehe Anhang B) erarbeitet, die den das Gegenlesen durch den Autor selbst oder einen Gruppen als Basis für die Suche nach Fehlern und Kollegen/eine Kollegin, besteht darin, dass der Fo- Mängeln dient. Die Fragen beziehen sich auf die drei kus schnell verloren geht und nicht kritisch genug im Kapitel „Zur Qualität von UML-Diagrammen“ begutachtet wird. Deshalb sollte der Review-Pro- genannten Kategorien. zess auch in einer Lehrveranstaltung zumindest ei- Wir haben folgende Vorgehensweise ausge- nen formalen Rahmen haben. wählt. Jede Gruppe begutachtet den Projektstatus Die Gefahr bei stark vom Management domi- einer anderen Gruppe. Es wird also für jede Gruppe nierten Reviews besteht darin, dass das Ziel sich eine Review-Gruppe festgelegt. Das Review leicht verschieben kann. Das gemeinsame Anliegen, der UML-Diagramme findet an zwei Zeitpunk- das konkret vorliegende Dokument oder Produkt zu ten im Entwicklungsprozess statt: Am Ende der verbessern und sich selbst zu verbessern, verschiebt Anforderungsdefinition, wenn das Anwendungs- sich hin zu einer Beurteilung und evtl. Abwertung falldiagramm, die Aktivitätsdiagramme und des Entwicklers. Wenn sich ein derartiges Klima ein- das Problembereichsmodell fertig sind, und stellt, stößt das Review auf Ablehnung und die Mit- am Ende der Analysephase, wenn das Struktur- arbeiter verschließen sich gegenüber diesem Mittel modell und die Sequenzdiagramme fertig sind. zur Qualitätsverbesserung. (Wiegers, 2001) Am Ende des Projekts findet noch die gegenseitige Für eine Lehrveranstaltung steckt viel Potential Begutachtung der fertigen Produkte durch die für die Weiterentwicklung der Fähigkeiten der Stu- Gruppen sowie eine statische Code-Analyse statt. dierenden in Reviews, die eine besondere Form des Diese Begutachtung soll hier allerdings nicht kollaborativen Lernens darstellen. Bauer et al. betrachtet werden, ebenso wenig wie die Bewertung (Bauer, Figl, Derntl et al., 2009) berichten in ihrem der Qualität des Quellcodes sowie die Begutachtung Artikel über Online-Reviews in der Informatik-Aus- und die Korrektur der Diagramme und Dokumente bildung u.a. darüber, dass die Reviews die Entwick- durch die Gruppenbetreuer. lung des Bewusstseins für Qualität bei der eigenen Der Begutachtungsprozess der UML-Dia- Arbeit erhöhen. Neben der Begutachtung anderer gramme läuft in zwei Schritten ab. Zur Vorbereitung Lösungsansätze lernen die Studierenden ebenso viel werden die für die Präsentation vorgesehenen Dia- von den Kommentaren und dem Feedback der Re- gramme im öffentlichen Bereich des Gruppen-Wikis viewer-Gruppe (Bauer, Figl, Derntl et al., 2009). Auf hochgeladen und können damit von allen SoPra-Be- diese Weise wird die Motivation einerseits erhöht teiligten eingesehen werden. In der letzten Grup- und andererseits vertiefen die Studierenden ihr pensitzung vor der Präsentation findet die Inspek- schon vorhandenes Wissen (S. Trahasch, 2004). tion der Diagramme anhand der Checklisten statt. Durch diese Vorgehensweise, gegenseitig die Arbei- Als Beispiel ist in Anhang B die Checkliste für das ten zu begutachten, erfahren die Studierenden au- Anwendungsfalldiagramm angegeben. ßerdem, dass Reviews eine wichtige Rolle im Be- Alle Gruppenmitglieder betrachten das Dia- reich der Softwareentwicklung spielen. gramm. Ein Gruppenmitglied liest die Fragen Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 13 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen nacheinander vor. Die Gruppe diskutiert und einigt Von den ausgeteilten Checklisten wurden die sich auf eine Antwort und trägt die gefundenen meisten ausgefüllt zurückgegeben. Allerdings blie- Mängel in das Formular ein. Abschließend wird das ben drei Bögen zu den Aktivitätsdiagrammen leer Diagramm allgemein bewertet. Für alle Diagramme und bei einem Bogen ist die Zuordnung zum zuge- (4 bzw. 5) sollten nicht mehr als 45 min. aufgewen- hörigen Aktivitätsdiagramm unklar. Von den Frage- det werden. Um zu vermeiden, dass Mängel überse- bögen zu den Sequenzdiagrammen blieben fünf leer hen werden oder Fehler gefunden werden, die keine und bei zweien ist die Zuordnung zum zugehörigen sind, achten die GruppenbetreuerInnen auf die Qua- Sequenzdiagramm wiederum etwas unsicher. Ins- lität der Diskussion und die Begründungen bei der gesamt konnten 82 von 90 Bögen ausgewertet wer- Begutachtung der UML-Diagramme. den. Der zweite Schritt ist die Präsentation der Dia- Trotz dieser Probleme und Unvollständigkeiten gramme im Plenum, das aus zwei bis drei anderen ergibt die Auswertung der 82 Checklisten ein unge- Gruppen besteht. Einer Gruppe stehen 15 min. zur fähres Bild über die Beurteilung der Qualität der Verfügung, die von ihr ausgewählten und im öffent- verschiedenen Diagramme durch die SoPra-Teil- lichen Bereich hochgeladenen 4 bzw. 5 Diagramme nehmer. Besonders auffallend ist, dass die häufigs- zu präsentieren und zur Diskussion zu stellen. Da- ten Mängel im Bereich der Semantik festgestellt nach stellt das Plenum Verständnisfragen und wurden. Bei 43 Diagrammen wurde dieser Bereich macht auf Mängel aufmerksam, die durch die Re- als derjenige mit angegeben, in dem viele Mängel zu views gefunden wurden. Auf diese Weise bekommt finden sind (wie die Abb. 4 zeigt), während viele äs- jede Gruppe Feedback zu der Qualität der vorge- thetische Mängel nur in 15 Diagrammen vorkom- stellten Diagramme und die Verständnisfragen las- men. In 14 Diagrammen spielen auch syntaktische sen sich unkompliziert in einer Face-to-Face-Situa- Fehler eine große Rolle. Dabei handelt es sich zur tion klären. Hälfte um Aktivitätsdiagramme. Das durch Checklisten unterstütze Review Dass nur bei einem Sequenzdiagramm viele wurde im Sommer 2016 erstmalig durchgeführt. An Mängel im ästhetischen Bereich und bei zweien diesem SoPra nahmen 10 Gruppen teil. Alle Grup- viele Syntaxmängel erkannt wurden, verwundert pen hatten jeweils die Aufgabe, in der Teamsitzung zunächst, da Sequenzdiagramme unter Studieren- vor der Präsentation des Projektfortschritts mit Hilfe den als besonders schwierig gelten. Aber für die Ge- von Checklisten die UML-Diagramme zu begutach- staltung der Sequenzdiagramme gibt es besonders ten. Zu bewerten waren von jeder Gruppe jeweils viele formale Regeln, für deren Einhaltung zum Teil ein Anwendungsfalldiagramm, drei Aktivitätsdia- auch der UML-Editor sorgt. Die beteiligten Objekte gramme, ein Problembereichsmodell, ein Struktur- sind ganz oben nebeneinander angeordnet. Das modell und drei Sequenzdiagramme. Also wurden Diagramm ist von oben nach unten zu lesen und insgesamt fast 90 Diagramme, allerdings nur jeweils zeigt einen zeitlichen Ablauf. Bei den Aktivitäts- einmal, begutachtet. diagrammen sind die Modellierer dagegen völlig Abb. 4: Gefundene Mängel in den beurteilten Diagrammen (UCD: An- wendungsfalldiagramm, AD: Aktivitätsdiagram, PBM: Problembe- reichsmodell, SD: Sequenzdiagramm, SM: Strukturmodell) Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 14 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen frei in der Anordnung und der Verwendung der Gruppen beobachtet, so dass die Checklisten-basier- Komponenten. ten Reviews auf jeden Fall ein fester Bestandteil des Dass beim Anwendungsfalldiagramm, Prob- SoPra bleiben werden. Die Zeit von etwa 45 min., die lembereichsmodell und Strukturmodell wenige syn- für die Inspektionssitzung aufgewendet wird, ist taktische Fehler gefunden wurden, wundert nicht so sehr nützlich investiert, da in der nächsten Iteration sehr. Für das Anwendungsfalldiagramm gelten nur die Qualität der abgegebenen Diagramme steigt. wenige Regeln und die beiden Klassendiaramme Dass das Bewusstsein für Qualität gestiegen ist, sind nahe an Programmierung, dem Java-Code, kann man den Diskussionen in den Gruppen ent- dem Teil der Entwicklung, mit dem die Studieren- nehmen. den die meiste Erfahrung haben. Wir haben uns gegen das Weiterleiten der aus- gefüllten Checklisten an die Entwickler entschieden, Erfahrungen da die Gutachter in den Präsentationen im Plenum die Gelegenheit haben, ihre Fragen zu stellen und Neben den tieferen Einsichten in die Qualität der ihre Kritik öffentlich zu äußern. Die Verantwortli- von den Studierenden erstellten Diagramme hat chen für die Lehrveranstaltung nehmen an diesen diese Vorgehensweise der gegenseitigen Begutach- Plenumssitzungen teil und können jederzeit bei un- tung der UML-Diagramme anhand von Checklisten, sachgemäßer Kritik eingreifen. die wir eigentlich nur eingeführt haben, um an Da- ten für eine Bachelorarbeit zu gelangen, sehr viele Vorteile für die Lehre mit sich gebracht. Zusammenfassung und Ausblick Schon lange ist die Präsentation der Diagramme In diesem Beitrag haben wir gezeigt, wie Checklis- ein wichtiger Bestandteil des Software-Praktikums, ten-basierte gegenseitige Reviews im SoPra einge- der auch in der Modulbeschreibung auftaucht. Das setzt werden, um die Qualität der UML-Diagramme Ziel der Präsentationen ist eine weitere Überprü- zu erhöhen. Die in UML-Diagrammen vorzufinden- fung, ob alle geforderten Funktionalitäten betrachtet den Mängel werden in drei Kategorien aufgeteilt. wurden. Darüber hinaus wird geprüft, ob alle Stu- Wir präsentieren, welche dieser Kategorien beim ge- dierenden die Aufgabestellung sowie das Entwick- genseitigen Review von den Studierenden am häu- lungsprozess gut verstanden haben. Deswegen figsten gefunden wurden. spielt die Qualität der Diagramme bei den Präsenta- Die Abgrenzung der Mängelklassen in Syntax, tionen eine wichtige Rolle, insbesondere ihre Les- Semantik und Ästhetik ist nicht einfach. Wenn bei- barkeit und Verständlichkeit. Allerdings verlief die spielsweise die Assoziationsrichtung in einem Klas- Diskussion bei den Präsentationen meist schlep- sendiagramm falsch eingezeichnet ist, könnte dieser pend. Die einzigen Anmerkungen und Fragen ka- im Ursprung syntaktische Fehler wie ein semanti- men von den Lehrenden. Ein erster Versuch, die Stu- scher Fehler wirken, da ein anderer Sachverhalt dar- dierenden der anderen Gruppen mehr in Diskussion gestellt ist. Ähnliches gilt für die Verwechselung einzubeziehen, indem die Diagramme vor der Prä- von include und extend im Anwendungsfalldia- sentation veröffentlicht wurden und immer eine gramm. Gruppe zum Reviewer bestimmt wurde, hat nur ein Wenn die Studierenden insgesamt nur wenige wenig Verbesserung gebracht. Manchmal kamen syntaktische Mängel gefunden haben, kann es daran dann tatsächlich ein paar Fragen und Anmerkungen liegen, dass sie selbst die UML-Syntax nicht so ganz von dieser zuvor bestimmten Review-Gruppe. genau beherrschen. Deshalb arbeiten wir an einem Den wirklichen Durchbruch brachten die Check- Eclipse-Plugin zur Syntax- und Konsistenzprüfung listen. Während sich bisher bei der Betrachtung von von UML-Diagrammen. Damit könnten die Studie- Diagrammen anderer Gruppen nur wenige interes- renden dann selbst ihre Diagramme vor der Abgabe siert gezeigt haben, entstand plötzlich in der Inspek- prüfen. tionssitzung eine lebhafte Diskussion über die dar- Die semantische und ästhetische Qualität der Di- gestellte Lösung. Sehr akribisch und ernsthaft, aber agramme lässt sich unserer Meinung nach am besten auch durchaus fair, wurden die Diagramme der an- durch eine gegenseitige Begutachtung mit Diskus- deren Gruppe inspiziert. Die differenzierte Betrach- sion bewerten. Da alle Gruppen an der gleichen Auf- tung der einzelnen Qualitätsaspekte ermöglichte gabe arbeiten, sind alle SoPra-Teilnehmer Experten eine tiefere Diskussion. auf dem Anwendungsgebiet. Der Einblick in die Auch der erhoffte Effekt, dass sich durch die Be- fremde Lösung ermöglicht zudem das Erkennen schäftigung mit der Qualität von fremden Diagram- von Unvollständigkeiten und Mängel im eigenen men der Blick für die Diagrammqualität schärft und Modell. dass auch bei der Erstellung der eigenen Dia- Der besondere Zugewinn durch die Reviews be- gramme in der nächsten Projektphase mehr Sorgfalt steht darin, dass sich insgesamt das Bewusstsein für verwendet wird, ist eingetreten. Das wurde in allen Diagramm-Qualität sehr erhöht hat, wie alle Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 15 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Gruppenbetreuer übereinstimmend berichten. Die Marian, P. (2013): UML in Practice. International Zeit für die Inspektion der fremden Diagramme Conference on Software Engineering. geht nur scheinbar dem eigenen Projekt verloren, Mohagheghi, P., Dehlen, V., Neple, T. (2009): Defi- vielmehr werden durch die verbesserte Qualität nitions and approaches to model quality in Korrekturzyklen eingespart. model-based software development – A re- view of literature. Quality of UML Models. Literatur PMD. (2016): Zugriff am 26.10.2016. Verfügbar un- Arendt T. (2014): Quality Assurance of Software ter https://pmd.github.io/ Models. A Structured Quality Assurance Pro- Schmedding, D., Vasileva, A., Remmers, J. (2015): cess supported by a flexible Tool Environment Clean Code - ein neues Ziel im Software-Prak- in the Eclipse Modeling Project. Dissertation. tikum. Tagungsband des 14. Workshops "Soft- Marburg. ware Engineering im Unterricht der Hoch- Astah. (2016) Zugriff am 31.10.2016. Verfügbar un- schulen". ter http://astah.net/ SoPra-Wiki. (2016): Software Praktikum. Zugriff am Bauer, B., Figl, K., Derntl, M., Beran, P., Kabicher S. 01.11.2016. Verfügbar unter https://sopra.cs.tu- (2009): The student view on online peer re- dortmund.de/wiki/ views. SIGCSE Bull. Striewe, M., Goedicke, M. (2011): Automated Bettin, J., Helsen, S., Kunz, M. (2007): Modellgetrie- checks on UML diagrams. ACM. bene Softwareentwicklung. dpunkt.verlag. Todorinski, S. (2016): Syntax- und Konsistenz- Boehm, B., Basili, V. R. (2001): Software Defect Re- checks von UML-Diagrammen. Interne Be- ductionTop 10 List. Software’s complexity an- richte / Universität Dortmund, Fakultät Infor- daccelerated developmentschedules make matik. avoiding defectsdifficult. These 10 techniques Trahasch, S. (2004): (Hrsg.). From peer assessment can help reduce the flaws in your code. IEEE towards collaborative learning (34th Annual Computer, 135-137. Frontiers in Education, 2004. FIE 2004). Briand, L., Labiche, Y., Leduc, J. (2006): Toward the Unhelkar, B. (2005): Verification and validation for Reverse Engineering of UML Sequence Dia- quality of UML 2.0 Models. New Jersey: Hobo- grams for Distributed Java Software. IEEE ken. Trans. Softw. Eng. Vasileva, A., Schmedding, D. (2016) How to Im- Fieber, F., Huhn, M. & Rumpe, B. (2008): Modell- prove Code Quality by Measurement and Re- qualität als Indikator für Softwarequalität: eine factoring. Quality of Information and Commu- Taxonomie. Informatik-Spektrum – Online. nications Technology (QUATIC). IEEE. (2008): IEEE Standard for Software Reviews Wiegers, K. (2001): Peer Reviews in Software: A and Audits. IEEE Std 1028-2008. Practical Guide. Addison-Wesley Professional. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 16 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Anhang A: Aktivitätsdiagramm Autoren: Alice, Bob Kurzbeschreibung: Löschen eines Projekts mit allen Unterprojekten und zugeordneten Tätigkeiten, sofern alle den Sta- tus erledigt tragen. Ein Unterprojekt ist erledigt, wenn alle seine Tätigkeiten und Unterprojekte erle- digt sind. Akteure: Benutzer des Programms Auslöser: Der Benutzer wählt die Aktion „Projekt löschen“ aus. Vorbedingung: Das zu löschende Projekt muss angezeigt werden. Nachbedingung: Waren alle Unterprojekte und Tätigkeiten erledigt, ist das Projekt gelöscht. Ansonsten keine Änderung des Zustands. Standardablauf: 1. Auswahl des zu löschenden Projekts aus der Projektliste. 2. Überprüfung, ob alle Tätigkeiten und Unterprojekte erledigt sind. 3. Falls alles erledigt ist, muss Benutzer eine Sicherheitsabfrage zum Löschen des Projekts be- stätigen. 4. Entfernen des Projekts mit allen seinen Unterprojekten und Tätigkeiten aus dem System. Mögliche Fehler: gewähltes Projekt wird nicht gefunden Alternativabläufe: 1. Wenn nicht alle Tätigkeiten und Unterprojekte erledigt sind, wird nicht gelöscht. 2. Bestätigt der Benutzer das Löschen nicht, wird die Aktion „Projekt löschen“ abgebrochen. Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 17 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Anhang B: Fragebogen zum Anwendungsfalldiagramm Fragebogen zum Anwendungsfalldiagramm 1 2 3 4 5 6 7 8 9 10 Das Diagramm ist von der Gruppe: ja eher ja eher nein nein schlecht zu sagen Ist das Diagramm informativ? (viele Informationen, vollständig) Ist das Diagramm leicht verständlich? (kein Erklärungsbedarf notwendig) Ist das Diagramm übersichtlich? (z.B. Elemente sinnvoll angeordnet) Welche der folgenden Mängel finden sich im Diagramm? (Es sind stets Mehrfachantworten möglich, aber bitte keine syntaktischen Fehler bewerten! Zur Syntax zählen alle Fehler, die die inkorrekte Verwendung der Diagrammelemente betreffen wie z.B. Kasten für Anwendungsfall statt Oval) Im Bereich Ästhetik ist das Diagramm … … zu detailliert / zu komplex … Akteure System-Akteure Anwendungsfälle Assoziationen … denn es gibt zu viele: Generalisierungen Extend-/Include-Bez. Notizzettel Andere Gründe: … zu wenig detailliert / unvollständig … Akteure System-Akteure Anwendungsfälle Assoziationen … denn es gibt zu wenige / es fehlen: Generalisierungen Extend-/Include-Bez. Notizzettel Andere Gründe: … unübersichtlich … … wegen: sich überschneidender Linien ungünstiger Anordnung der Elemente Andere Gründe: Im Bereich Semantik … … ist die Bedeutung der folgenden Akteure System-Akteure Anwendungsfälle Assoziationen Elemente unklar: (z.B. wegen schlecht gewählter Bezeichner) Generalisierungen Extend-/Include-Bez. Notizzettel Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 18 Doris Schmedding und Anna Vasileva - Reviews – ein Instrument zur Qualitätsverbesserung von UML-Diagrammen Grund/Gründe für die Unklarheit/en: kurz lang ungenau Gewählter Name / Erklärung ist zu … Element macht keinen erkennbaren Sinn Andere Gründe: Es existieren Duplikate/ Wiederholungen / Redundanzen Sonstige Mängel (außer Syntaxfehler!): Keine Mängel erkennbar Falls Mängel vorhanden sind: Im Bereich der … Welche Mängel überwiegen: Syntax Semantik (Bedeutung) Ästhetik (z.B. Layout, Abstraktheit, ...) (Mehrfachantworten möglich, falls gleich viele Mängel in verschiedenen Bereichen vorhanden sind) Insgesamte Bewertung des Diagramms: (sehr gut) 1 2 3 4 5 6 (schlecht) Das Diagramm ist … ... gut, denn es ist: informativ leicht verständlich übersichtlich nichts von allem (Mehrfachantworten möglich) ... nicht gut, denn es ist: nicht informativ schwer verständlich unübersichtlich nichts von allem (Mehrfachantworten möglich) Weitere Anmerkungen sind hier möglich! Bernd Bruegge, Stephan Krusche (Hrsg.): SEUH 2017 19