BESSER MODELLIEREN:

QUALITÄTSSICHERUNG VON

UML-MODELLEN

einen alle relevanten und notwendigenInformationen enthält und zum ande-ren entsprechend dem Model lierungs -zweck ausreichend detailliert ist.

■ Comprehensibility (Verständlichkeit):Ein Modell ist gut verständlich, wennes von den vorgesehenen Anwenderngelesen und schnell interpretiert werdenkann (Anwender sind hier entwedermenschliche Benutzer oder verarbeiten-de Werkzeuge).

■ Confinement (Angemessenheit): EinSachverhalt wurde angemessen model-liert, wenn das Modell mit dem Mo del -lierungszweck und der Model lierungs -domäne übereinstimmt. DieseDefi ni tion schließt auch die Auswahlder Modellierungssprache und der rele-vanten Konzepte (z. B. Diagramme undElemente) auf der richtigen Abstrak -tions ebene mit ein.

■ Consistency (Konsistenz): Ein Modellist konsistent, wenn es frei von Wi -dersprüchen ist. Dazu zählt zum einendie syntaktische Konsistenz bezüglich

Der Artikel präsentiert einen Qualitätssicherungsprozess für Softwaremodelle, der Metriken,Smells und Refactorings verwendet. Unterstützende Werkzeuge basieren auf dem „EclipseModeling Framework“ (EMF) und können in Modellierungsumgebungen, wie z. B. „Papyrus“ oder„IBM Rational Software Architect“, integriert werden. Neben einer groben Einführung in dasRefaktorisieren von Modellen liefert dieser Artikel zudem Hinweise auf weiterführendeLiteratur.

m e h r z u m t h e m a :eclipse.org/modeling/emft/refactor/

14 15

Quali tätssicherungstechniken für Software -modelle (vgl. [Are11]). Die Umgebung istflexibel bezüglich der Modellierungs -sprache, der Auswahl vorhandener Techni -ken sowie der konkret verwendetenSpezifikationssprachen für Erweiterungen.Die Werkzeuge sind in hohem Maße inte-griert: Einerseits benutzen sie sich gegensei-tig, andererseits kann der Qualitäts -sicherungsprozess komplett innerhalb einervorhandenen Modellierungsumgebung, wie„Papyrus“ (vgl. [Ecl-a]) und „IBMRational Software Architect“ (vgl. [IBM]),durchgeführt werden. Die Werkzeugebasieren auf dem Eclipse ModelingFramework (EMF) (vgl. [Stei08]) und wer-den im Eclipse-Incubation-Projekt „EMFRefactor“ (vgl. [Ecl-b]) angeboten.

ModellqualitätIm Gegensatz zur Softwarequalität gibt esfür die Qualität von Softwaremodellen kei-nen offiziellen Standard. Eine Übersichtüber die in der Literatur betrachtetenQualitätsaspekte findet man in einemArtikel von Mohagheghi et. al. (vgl.[Moh09]). Dort werden sechs primäreQualitätsaspekte identifiziert, die inForschungspapieren der Jahre 2000 bis2007 hinsichtlich der Qualität von Soft -waremodellen diskutiert wurden: die sogenannten 6C-Goals. Diese sind (in alpha-betischer Reihenfolge):

■ Changeability (Änderbarkeit): EinModell ist gut änderbar, wenn Modi -fikationen oder Verbesserungen ineinem Maße unterstützt werden, dassdas Modell schnell und kontinuierlichweiterentwickelt werden kann.

■ Completeness (Vollständigkeit): EinModell ist vollständig, wenn es zum

In der modernen Softwareentwicklungspielen Modelle eine wichtige Rolle. IhreEinsatzgebiete reichen von der System -analyse über die Spezifikation von Archi -tektur und Design bis hin zur Generierungvon Code. Für die Entwicklung qualitativhochwertiger Software ist es somit ratsam,bereits die Qualität der involviertenModelle zu prüfen und diese gegebenenfallszu verbessern. Ursachen für eine einge-schränkte Qualität von Modellen könnenzum Beispiel Unerfahrenheit mit demModellieren per se, mit der verwendetenModellierungssprache oder dem unterstüt-zenden Modellierungswerkzeug, aber auchunerfüllte projektspezifische Richt liniensein.

Eine standardisierte Modellierungs -sprache für Softwaresysteme ist die UnifiedModeling Language (UML) (vgl. [OMG]),deren Sichtenkonzept auf das Modell inverschiedenen Diagrammen weitereProbleme verursacht:

■ So können Sachverhalte redundantmodelliert werden, weil Modelliererjeweils nur ihre Sicht auf das Ge samt -modell haben.

■ Oder nicht benötigte Modellelementewerden nur aus einem Diagrammgelöscht und verbleiben somit als unge-nutzte Elemente im Modell.

In diesem Artikel1) stellen wir eine Werk -zeugumgebung vor, deren Komponenteneinen projektspezifischen Qualitäts siche -rungs prozess für Softwaremodelle unter-stützen. Dieser Prozess basiert auf Metri -ken, Smells und Refactorings als

schwerpunk t

Dr. Gabriele Taentzer

(taentzer@mathematik.uni-marburg.de)

ist Professorin für Softwaretechnik am

Fachbereich Mathematik und Informatik der

Philipps-Universität Marburg. In der Forschung

beschäftigt sie sich mit der modellgetriebenen

Softwareentwicklung, visuellen Sprachen und

Graftransformation.

Thorsten Arendt

(arendt@mathematik.uni-Marburg.de)

ist wissenschaftlicher Mitarbeiter und Doktorand

am Fachbereich Mathematik und Informatik der

Philipps-Universität Marburg. Ein Schwerpunkt sei-

ner Arbeit ist die modellbasierte Softwareent -

wicklung, insbesondere die Qualitätssicherung von

Softwaremodellen und die Entwicklung geeigneter

Werkzeuge.

d i e au toren

1) Diese Arbeit wurde teilweise von SiemensCorporate Technology, München, gefördert.

6/2012

der verwendeten Modellierungsspracheund gegebenenfalls einzuhaltendenMo dellierungskonventionen, zum an -deren aber auch die Konsistenz hin-sichtlich semantischer Widersprüche,beispielsweise zu Modellen einer ande-ren Abstraktionsebene.

■ Correctness (Korrektheit): Ein Modellist korrekt, wenn es die richtigen Ele -

mente und Beziehungen zwischen die-sen enthält und richtige Aussagen überdie zu modellierende Domäne trifft.

Wie bereits erwähnt, basieren diese De -finitionen (oder besser: Beschreibungen)nicht auf einem offiziell anerkanntenStandard. Sie stellen jedoch den aktuellenStand der Technik dar und sollten somit bei

der Betrachtung von Modellqualität immermit berücksichtigt werden. Anhand desDomänenmodells eines KFZ-Verleihs (sieheAbbildung 1) wollen wir die beschriebenenQualitätsaspekte im Folgenden andiskutie-ren. Der Verleih (Company) hat eine hierar-chisch organisierte Mitarbeiter struktur(Employee, Supervisor) sowie eine Mengevon Kunden (Customer) mit Adres sen undBankverbindungen. Weiterhin bietet dasUnternehmen einen Dienst für den Verleihseiner Kraftfahrzeuge an (VehicleRental,Vehicle).

Obwohl das Modell konsistent zurUML-Sprachspezifikation ist (Qualitäts -aspekt „Consistency“), weist es bezüglichanderer Aspekte die folgenden Mängel auf:

■ Die in den Klassen Car, Truck undMotorbike vorkommenden redundantenAttribute power und manufacturer beein-flussen die Änderbarkeit des Modells,da z. B. bei der Einführung einer neuenKlasse Manufacturer das Modell an meh-reren statt an einer Stelle angepasstwerden muss („Change ability“).

■ Die abstrakte Klasse Supervisor ist eineUnterklasse der konkreten KlasseEmployee. Hier wird das Prinzip derAbstraktion unzweckmäßig verwendet,da z. B. kein Objekt der Klasse

schwerpunk t

PapyrusInstallieren Sie die aktuelle Version „Juno“ der „Eclipse Modeling Tools“ von der Seiteeclipse.org/downloads. Starten Sie Eclipse und installieren Sie die UML-Modellierungs -umgebung Papyrus (Help > Install New Software… > Work with: Juno > Modeling > PapyrusSDK Binaries > next > …) sowie das Werkzeug BIRT für die Erstellung von Berichten(Help > Install New Software… > Work with: Juno > Bussiness… > BIRT Framework > next >…). Laden Sie sich anschließend aus dem Download-Bereich der EMF-Refactor-Web-Seite (eclipse.org/modeling/emft/refactor) das Archiv Juno.zip herunter, entpacken Sie diesesin das plugins-Verzeichnis Ihrer Eclipse-Installation und starten Sie Eclipse neu. Ein Bei -spielprojekt kann ebenfalls von der EMF-Refactor-Web-Seite heruntergeladen werden.

IBM RSA v7.5.5Wenn Sie eine bereits installierte Version des IBM Rational Software Architect haben,laden Sie sich aus dem Download-Bereich der EMF-Refactor-Web-Seite(eclipse.org/modeling/emft/refactor) das Archiv RSA755.zip herunter, entpacken Sie dieses indas plugins-Verzeichnis Ihrer RSA-Installation und starten Sie den RSA. Auch hier stelltdie Web-Seite von EMF Refactor ein Beispielprojekt zum Download bereit.

Kasten 1: Download und Installation der Werkzeuge, Techniken und Beispiele fürdie Qualitätssicherung von UML-Modellen.

Abb. 1: UML-Klassenmodell eines KFZ-Verleihs.

Beispiel für einen metrikbasierten Smell istder oben diskutierte Fall, in dem deutlichmehr Attribute als Operationen im Modellvorhanden sind (Too Many Knowers).Andere Smells in Softwaremodellen werdenals Muster auf der abstrakten Syntax derModellierungssprache definiert, die dannin konkreten Modellen gesucht werden.Ein Beispiel für einen solchen Smell ist EqualAttributes in Sibling Classes, der nach Klassenmit derselben Oberklasse sucht, die zusätz-lich alle ein Attribut mit gleichen Eigen -schaften (Name, Typ und Multiplizität)besitzen.

In unserer Werkzeugumgebung wird eineSmell-Analyse aus dem Kontextmenü einesModellelements gestartet (EMF Smell >Calculate Configured UML Smells). Ein Aufrufauf dem Wurzelelement vom Typ Modelsucht nach allen konfigurierten Smells imgesamten Modell. Die gefundenen Smellswerden in einer eigenen Sicht präsentiertund können anschließend exportiert wer-den.

In unserem Beispielmodell befinden sichinsgesamt zwölf Smells (siehe auch Abbi l -dung 3):

■ Der Smell Equal Attributes in SiblingClasses ist insgesamt sechsmal vorhan-den (die beiden Attribute power undmanufacturer jeweils in den Klassen Car,Truck und Motorbike).

■ Ebenso werden die anderen beschriebe-nen Situationen gefunden (SmellsSpeculative Generality, Unused Interfaceund Concrete Superclass).

■ Der Smell Long Parameter List, der nachOperationen mit einer hohen Anzahlvon Eingabeparametern sucht, tritt

16 17

Das unausgeglichene Verhältnis zwischenAttributen (40) und Operationen (4) kannunterschiedlich interpretiert werden:Einerseits könnte es ein Hinweis daraufsein, dass das objektorientierte Prinzip derOperationen nicht genügend genutzt wird(„Confinement“), andererseits könnte esauf eine unvollständige Modellierung hin-weisen („Completeness“).

Smells in SoftwaremodellenEine weitere Technik zur Qualitäts -sicherung von Softwaremodellen sindSmells in Softwaremodellen. Dies sindStellen im Modell, die hinsichtlich be -stimmter Qualitätskriterien verdächtigsind. Sie sollten genauer betrachtet undeventuell verbessert werden. Viele Smells inSoftwaremodellen für UML-Klassen -modelle wurden aus entsprechenden Smellsfür objektorientierte Programme abgeleitet(vgl. [Fow99]).

Smells in Softwaremodellen könnenmetrik- oder musterbasiert sein. Ein

Supervisor in einem Sequenzdiagrammmodelliert werden kann, obwohl einVorgesetzter auch ein Mitarbeiter ist(„Confinement“). Andererseits könntediese Klasse aber auch fälschlicherweiseals abstrakt gekennzeichnet sein („Cor -rec tness“).

■ Eine unzweckmäßige Verwendung desAbstraktionsprinzips kommt auch beider Klasse Service vor, die von lediglicheiner einzigen konkreten Klasse(VehicleRental) beerbt wird („Confi ne -ment“). Jedoch könnten die angebote-nen Dienste auch noch unvollständigmodelliert sein („Completeness“).

■ Das Modell enthält ein InterfaceIService (siehe Modellbaum in Abbil -dung 1), das in keinem Diagramm vor-kommt und möglicherweise das Er geb -nis eines fehlerhaften Löschens ist(siehe oben). Solche ungenutzten Ele -mente beeinflussen unter anderem dieVerständlichkeit des Modells („Com -pre hensibility“).

Im Folgenden beschreiben wir, wie dieQualität des Beispielmodells analysiert unddurch Umstrukturierung gezielt verbessertwerden kann.

ModellmetrikenSoftwaremetriken sind verbreitete Hilfsmit -tel, um bestimmte (Qualitäts-)Eigen -schaften zu messen. Somit kann es in einemModell-Review hilfreich sein, einen Berichtüber projektspezifische Modellmetriken zuerstellen und zu analysieren. In unsererUmgebung wird eine Metrikenberechnungaus dem Kontextmenü eines Modell -elements gestartet (EMF Metrics > CalculateConfigured UML Metrics). Ebenso können diekonfigurierten Metriken lediglich auf demselektierten Element oder auch transitiv aufallen enthaltenen Elementen (z. B. aufOpera tionen einer selektierten Klasse)berechnet werden. Die Metrikwerte wer-den in einer eigenen Sicht präsentiert undkönnen anschließend in Formaten wieHTML, PDF oder PPT exportiert werden.Die Werkzeugumgebung unterstützt rudi-mentäre Designs, wie Listen und verschie-dene Diagrammarten. Weitere Designskönnen leicht importiert werden.

Abbildung 2 zeigt den Export der berech-neten Metriken NATM (Gesamtanzahl derAttribute in Klassen des Modells) undNOM (Gesamtanzahl der Operationen inKlassen des Modells) auf unserem Beispiel -modell in Form eines Kuchendiagramms.

schwerpunk t

Abb. 2: Export einerMetrikenberechnung.

Abb. 3: Gefundene Smells.

6/2012

dreimal auf. Das Beispiel berücksichtigthier eine projektspezifische Grenze vonmindestens vier Eingabeparametern.

Wählt man ein konkretes Vorkommen einesSmells aus (z. B. {Motorbike, power} in Ab -bildung 3), werden die entsprechenden Mo -dellelemente im Modellbaum sowie in offe-nen grafischen Diagrammeditoren markiert.

Refactorings fürSoftwaremodelleEine bekannte Technik für die Quali täts -sicherung von Programmen durch Um -strukturierung, ohne die Semantik zuändern, ist Refactoring (vgl. [Fow99]).Diese Technik kann auch zur Qualitäts -sicherung von Softwaremodellen angewen-det werden und wird vom Eclipse-Plug-In„EMF Refactor“ (vgl. [Ecl-b]) unterstützt.Bei der Durchführung eines Refactoringsbenutzt EMF Refactor eine fest vorgegebe-ne Struktur: Nach einer ersten Überprü-fung von Vorbedingungen auf dem aktuel-len Kontext (Initial Check) folgen eine zweiteÜberprüfung unter Einbeziehung der einge-gebenen Parameterwerte (Final Check) undschließlich die Durchführung der konkre-ten Änderungen (Model Change).

Refactorings können sowohl direkt aufden Modellelementen als auch aus derErgebnissicht der Smell-Suche (z B.{Motorbike, power} > Refactoring Analysis)aufgerufen werden. Im zweiten Fall schlägtEMF Refactor alle Refactorings vor, die indem konkreten Kontext anwendbar sind.Beispielsweise werden für die Eliminierungdes Smells Equal Attributes in Sibling Classesauf den Elementen {Motorbike, power} neunRefactorings vorgeschlagen, die auf einemdieser beiden Elemente durchgeführt wer-den können (siehe Abbildung 4). Da jedochauch anwendbare Refactorings vorgeschla-gen werden, die nicht unmittelbar dazu bei-tragen, den Smell zu entfernen (wie z. B.Rename Class), bietet EMF Refactor einemanuelle Konfiguration der geeignetenModel Refactorings an.

In unserem Beispiel wenden wir dasRefactoring Pull Up Attribute auf dasAttribut power an. Da die UML Mehr -fachvererbung erlaubt, muss als Parameterdie Oberklasse angegeben werden, in diedas Attribut verschoben werden soll. DerEingabedialog bietet zudem die Mög -lichkeit, Voransichten der Änderungen amModell sowie der vorkommenden Smellsvor und nach dem Refactoring anzuzeigen.Sind bestimmte Vorbedingungen nicht

erfüllt, werden detaillierte Fehlermel dun -gen angezeigt. Weiterhin stehen dieüblichen Funktionalitäten undo und redozur Verfügung. Abbildung 5 zeigt einenAusschnitt unseres Beispielmodells nachDurchführung von Pull Up Attribute auf denAttributen power und manufacturer.

ProjektspezifischeAnpassungenDa Softwaremodelle für verschiedeneZwecke und in unterschiedlichen Domänen(z. B. Web-Anwendungen und eingebetteteSysteme) eingesetzt werden, variieren auchdie Bedeutung einzelner Qualitätsaspekteund somit die Auswahl spezifischer Si -cherungstechniken. Unsere Werkzeug -umge bung bietet die Möglichkeit, die vor-handenen Techniken projektspezifisch zukonfigurieren (z. B. Project > Properties >EMF Smell). In der Standardeinstellung sindalle vorhandenen Techniken aktiviert. Zweiweitere projektspezifische Einstellungenwurden bereits erwähnt: die Einstellung derGrenzen bei metrikbasierten Smells und dieKonfiguration der für die Eliminierung vonSmells in Softwaremodellen geeignetenRefactorings.

Neben der Anwendung von vorhandenenTechniken bietet die Werkzeugumgebungauch die Möglichkeit, neue Metriken,Smells und Refactorings zu integrieren(z. B. über File > New > Other… > EMF Smell> Model-Smell). Dazu besitzt jedes Werk -zeug einen Codegenerator, der nach derEingabe spezifischer Informationen (z. B.den Namen des Smells) Code generiert, derdann vom Anwendungsmodul verwendetwerden kann. Vorhandene Techniken kön-nen kombiniert werden: Neue Metrikenoder metrikbasierte Smells benutzen vor-handene Metriken, neue Refactorings kom-binieren vorhandene Refactorings. NeueTechniken können in Java, der ObjectConstraint Language (OCL) oder derModelltransformationssprache Henshin(vgl. [Are10]) spezifiziert und weitereSpezi fikationssprachen über entsprechendeAdapter integriert werden.

Implementierte Technikenfür UMLDie Werkzeuge unterstützen zurzeit über100 Metriken sowie jeweils 30 Smells undRefactorings für UML-Modelle. Sie ermög-lichen einen flexiblen Einsatz zur Quali -tätssicherung verschiedenartiger UML-Modelle. Viele Smells und Refactorings fürKlassendiagramme orientieren sich an denentsprechenden Pendants für Klassen struk -turen auf Programmier ebene, wie in[Fow99] beschrieben. Weitere Technikenkönnen mit Hilfe der erwähnten Spezifi -kationssprachen leicht ergänzt werden.

Neben den bereits erwähnten MetrikenNATM und NOM werden alle gängigenobjektorientierten Metriken für UML-Modelle unterstützt, etwa Metriken hin-sichtlich bestimmter Eigenschaften überVererbung (z. B. MaxDIT – Maximale Tiefealler Vererbungshierarchien im Klassen -

schwerpunk t

Abb. 4: Anwendbare Refactorings.

Abb. 5: Teil des verbesserten UML-Klassenmodells.

18 19

modell) oder Kopplung (z. B. Ce – EfferentCoupling/ausgehende Abhängigkeiten einesPakets und Ca – Afferent Coupling/einge-hende Abhängigkeiten eines Pakets).Weiterhin können die Metriken auf ver-schiedenen Modellelement-Typen berech-net werden (Modell, Paket, Klasse usw.).Weitere implementierte Smells und Refac -torings für UML-Modelle neben den inunserem Beispiel diskutierten sind:

■ Multiple Definition of Classes withEqual Names: Dieser musterbasierteSmell identifiziert Klassen in unter-schiedlichen Paketen, die den gleichenNamen besitzen.

■ Primitive Obsession: Dieser metrikba-sierte Smell wurde in zwei unterschied-lichen Varianten implementiert. Zumeinen tritt dieser Smell auf, wenn dieAnzahl der konstanten Attribute einerKlasse einen spezifischen Wert über-schreitet, und zum anderen, wenn dieAnzahl der Attribute einer Klasse mitprimitivem Datentyp (Integer, String)über dem konfigurierten Schwellenwertliegt.

■ Introduce Parameter Object: DiesesRefactoring erstellt – ausgehend voneiner Liste von Parametern einer Opera -tion – eine neue Klasse, legt für jedendieser Parameter ein entsprechendesAttribut in der Klasse an und ersetztschließlich die Parameterliste durcheinen neuen Parameter, getypt durch dieneue Klasse (sowohl in der ur sprüng -lichen Operation als auch in anderenOperationen der gleichen Klasse).

■ Remove Isolated State: Bei diesemRefactoring wird ein Zustand, derweder eigehende noch ausgehendeTransitionen besitzt, aus der entspre-chenden Region eines Zustandsdia -gramms gelöscht.

schwerpunk t

Literatur & Links

[Are10] T. Arendt, E. Biermann, S. Jurack, C. Krause, G. Taentzer, Henshin: Advanced Concepts

and Tools for In-Place EMF Model Transformations, MoDELS 2010, Springer 2010

[Are11] T. Arendt, S. Kranz, F. Mantz, N. Regnat, G. Taentzer, Towards Syntactical Model

Quality Assurance in Industrial Software Development: Process Definition and Tool Support,

Software Engineering 2011

[Ecl-a] Eclipse, Papyrus, siehe: eclipse.org/modeling/mdt/papyrus/

[Ecl-b] Eclipse, EMF Refactor, siehe: eclipse.org/modeling/emft/refactor/

[Fow99] M. Fowler, K. Beck, Refactoring – Improving the Design of Existing Code, Addison-

Wesley 1999

[IBM] IBM, Rational Software Architect, siehe:

http://www-01.ibm.com/software/rational/products/swarchitect/

[Moh09] P. Mohagheghi, V. Dehlen, T. Neple, Definitions and Approaches to Model Quality in

Model-Based Software Development – A Review of Literature, Information and Software

Technology, 12/2009

[OMG] Object Management Group, Unified Modeling Language, siehe: omg.org/spec/UML/

[Stei08] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF: Eclipse Modeling Frame -

work, Addison-Wesley 2008

[Yat] Yatta Solutions GmbH, UML Lab, siehe: uml-lab.com

Die Liste der unterstützten Metriken,Smells und Refactorings für UML-Modellewird sukzessive erweitert.

FazitIn diesem Artikel haben wir einenQualitätssicherungsprozess für Software -modelle sowie eine unterstützende Werk -zeug umgebung anhand eines Beispiel -modells der UML vorgestellt. Prozess undWerkzeuge bedienen dabei zwei verschiede-ne Benutzergruppen:

■ Qualitätsverantwortliche können pro-jektspezifische Qualitätseigenschaftenund somit bestimmte Sicherungs -techniken festlegen.

■ Modellierer und Reviewer werden auf-grund der Integration der Werkzeuge in

Modellierungsumgebungen direkt inihrer Modellierungsarbeit unterstützt.

Obwohl der Anwendungsfokus der vorge-stellten Werkzeuge auf der direkten Mo -dellierung von Softwareartefakten liegt,sind auch andere Anwendungsszenariendenkbar. Beispielsweise könnte in einemReverse-Engineering-Prozess aus dem vor-handenen Programmcode ein entsprechen-des UML-Modell erstellt werden (z. B. mitUML Lab, vgl. [Yat]) und anschließend dasDesign ähnlich einer statischen Code -analyse mit Hilfe der vorhandenen Metri -ken und Smells analysiert werden. EineBatch-Verarbeitung ist derzeit noch nichtmöglich. Entsprechende Schnittstellen wer-den jedoch in einer zukünftigen Versionvon EMF Refactor bereitgestellt. ■