Modellqualität als Indikatorfür Softwarequalität:eine Taxonomie
Florian Fieber · Michaela HuhnBernhard Rumpe
Auch neuere Beispielezur Entwicklung kom-
plexer softwarebasierterSysteme zeigen, dass
viele Projekte weiterhinmit erheblichen zeitli-chen und finanziellen
Risiken sowie demRisiko des Scheiterns
verbunden sind.
Deshalb ist es zwingendnotwendig, dass einestrukturierte, früh-zeitig einsetzendeQualitätssicherung(QS) in Kombinationmit adäquater Mei-lensteinplanung inSoftwareprojekteneinen höheren Stel-
lenwert einnimmt. Die Projektverantwortlichenerkennen zusehends den Wert von entwicklungs-begleitenden QS-Maßnahmen und stellen diesenentsprechend mehr Ressourcen zur Verfügung [39].Neben konstruktiven Maßnahmen (wie dem Einsatzvon Normen, Richtlinien und standardisierten Pro-zessen) stehen vor allem analytische Maßnahmen(z.B. statische Analyse, Review, dynamischer Test)zur Verfügung und werden immer erfolgreicherangewandt.
Die frühzeitige Planung und Durchführungvon QS-Maßnahmen ist in der Regel nur auf Basisadäquater, formaler Dokumentation möglich. Demmanuellen Review bzw. der Inspektion solcherDokumentationsartefakte zumeist weit überle-gene Technik sind die automatisierte Analysesowie Simulation, Testen und am besten die kon-struktive Generierung des lauffähigen Codes ausdiesen Dokumenten. Alle diese Techniken die-nen der Effizienzsteigerung in der Entwicklungund gehen einher mit einer gleichzeitigen Quali-tätssteigerung, da sie den Entwicklern manuelleTätigkeiten abnehmen. Eine solche Automatisierungbedeutet aber, dass die im Entwicklungsprozesszum Einsatz kommenden Dokumentationsarte-
fakte ,,maschinenlesbar“ sein müssen. Jenseitsvon informellen Beschreibungen kommen daherim modellbasierten Softwareentwicklungspro-zess verschiedenste Arten von Modellen zumEinsatz. Dabei ist sowohl nach Entwicklungs-tätigkeiten (früher: ,,Phasen“) als auch nachden Einsatzformen der verwendeten Modelle zuunterscheiden.
Am umfassendsten unterstützt die UML [44, 45,52, 53] mit ihren 13 Modellarten den Entwicklungs-prozess. Leider sind die zugehörigen Werkzeugeim Allgemeinen nicht so ausgereift wie etwaspezialisierte Werkzeugketten für die Modellbil-dung von regelungstechnischen Teilaspekten umMatlab/Simulink [8], zur Modellierung von Test-sammlungen mit TTCN [7] oder für bestimmteZielsetzungen extra gebildete domänenspezifischeSprachen [16, 25, 26, 34]. Derzeit für die Soft-wareentwicklung wichtige Modellarten erlaubeneine
– Struktur- und Schnittstellenbeschreibung,– konstruktive Verhaltensbeschreibung, typischer-
Florian Fieber · Michaela Huhn · Bernhard RumpeCarl-Friedrich-Gauß-Fakultät,Technische Universität Braunschweig,Mühlenpfordtstr. 23, 38106 BraunschweigE-Mail: {fieber, m.huhn, b.rumpe}@sse-tubs.de
408 Informatik_Spektrum_31_5_2008
[FHR08] F. Fieber, M. Huhn, B. Rumpe Modellqualität als Indikator für Softwarequalität: eine Taxonomie In: Informatik-Spektrum. Springer Verlag. Band 31, Heft 5, Oktober 2008. www.se-rwth.de/publications
ZusammenfassungKomplexität, Anforderungsmanagement undVariantenvielfalt sind zentrale Herausforderun-gen bei der Entwicklung und Evolution heutigersoftwaregesteuerter Systeme. Diesen wird zu-nehmend durch den Einsatz modellbasierterEntwicklungsmethoden begegnet. Dadurchwird das Modell zum zentralen Artefakt und dieErstellung und Nutzung von Modellen zu einerzentralen Tätigkeit in der Softwareentwick-lung. Mit der Bedeutung der Modelle steigenauch die Ansprüche an ihre Qualität. DieserBeitrag untersucht die Implikationen, die dar-aus entstehen, insbesondere werden sinnvolleQualitätsmerkmale für softwarebeschreibendeModelle identifiziert und diskutiert.
– (meist informelle) Organisation und Strukturie-rung der Anforderungsbeschreibung,
– Modellierung von Aufgaben- und Prozessabläufenund die
– Datenmodellierung.
Neben konstruktiven Modellen, die primärzur Gewinnung von Codes dienen, werden Simu-lationsmodelle zur Gewinnung von Erkenntnissenmittels Durchführung von Abläufen und analyti-sche Modelle für die Verifikation genutzt. MancheModelle bieten auch die gleichzeitige Darstellungkonstruktiver Anteile und zu prüfender Anteile.Konstruktiv sind etwa Klassen und Attribute imKlassendiagramm oder die Action an der Transi-tion, zu Prüfzwecken eingesetzt zu werden bzw.zu verifizieren sind jedoch Kardinalitäten oderNachbedingungen.
Zunächst scheint die Qualität der für all dieseZwecke im Einsatz befindlichen Modelle für dasErgebnis, einer qualitativ hochwertigen, korrekten,effizient und komfortabel nutzbaren, sicheren,robusten, rechtzeitig fertig gestellten und (meistauch) weiter entwickelbaren Software, nicht rele-vant zu sein! Dies ist zumindest die of geäußerteMeinung wenig erfahrener Softwareentwickler.Viele Erfahrungsberichte und Indikatoren zeigenjedoch, dass die Qualität der im Einsatz befindlichenModelle mit der Qualität der entwickelten Softwareauf vielfältige Weise verbunden ist. Wurden Modellebisher vor allem zu Zwecken der Visualisierung von
Entscheidungen, Kommunikation mit Experten undDokumentation des Systems eingesetzt, gewinnensie mit dem zunehmenden Einsatz modellbasierterSoftwareentwicklung stetig an Bedeutung [40] –die Modelle sind das wichtigste Artefakt der Ent-wicklung, ihre Qualität trägt somit entscheidendzum Erfolg des Projekts bei. Die QS-Maßnahmenallgemeiner Entwicklungsprozesse fordern daher,wie etwa in der Norm IEC61508 [19] beschrieben,zurecht eine adäquate Qualität der Artefakte bzw.Modelle im Softwareentwicklungsprozess ein. Mo-dellqualität ist kein Selbstzweck, sondern abhängigvon den Projektzielen zu identifizieren.
Erst durch die Identifikation geeigneter Qua-litätsmerkmale lässt sich Qualität messbar undquantifizierbar machen. Bereits während der Ent-wicklung können damit Aussagen zur Qualitätgetroffen werden und gegebenenfalls Maßnahmenrechtzeitig geplant und eingeleitet werden. FürSoftwaresysteme bzw. Codes wurden die unter-schiedlichen Qualitätsmerkmale bereits mithilfeverschiedener Qualitätsmodelle definiert (z.B. dasQualitätsmodell der ISO 9126:2001 [32]). Die Merk-male dieser Qualitätsmodelle lassen sich jedoch nurbedingt auch auf Softwaremodelle anwenden. Beider System- bzw. Softwaremodellierung gibt es nochkein anerkanntes und weithin eingesetztes Verfah-ren, um die Qualität der Modelle zu messen undzu verbessern. Die mangelnde Qualitätssicherungbetrifft dabei alle Modelle der unterschiedlichenPhasen gleichermaßen, z.B. Modelle zur Analyse derAnforderungen (Modellierung der Anforderungenin einem Analysemodell) oder Modelle zum Entwurfdes Systems (Transformation des Analysemodells inein Designmodell).
Dieser Beitrag entwickelt eine Taxonomieder Qualitätsmerkmale für Softwaremodelle. DerBeitrag soll damit eine Grundlage für weitereempirische Untersuchungen und Werkzeugent-wicklungen zur Modellqualität bilden. Zunächstwerden die zugrunde liegenden Modell- und Qua-litätsbegriffe eingeführt und eine Kategorisierungder Qualitätsarttribute für Modelle diskutiert. Dannwird ein Katalog konkreter Qualitätsattribute fürModelle vorgestellt und ihre Auswirkungen auf dieQualität der resultierenden Software diskutiert.Dieser Katalog ist strukturiert nach innerer Qualitätund horizontalen sowie vertikalen Qualitätsanforde-rungen zwischen Modellen. Qualitätsanforderungenan Modelle implizieren auch Anforderungen an
Informatik_Spektrum_31_5_2008 409
{ MODELLIERUNG
die im Einsatz befindliche Modellierungsnotation,die anschließend eigenständig diskutiert werden.Abschließend wird über Techniken zur Qualitäts-messung und Bewertung diskutiert, die letztlichdurch adäquate methodische Einbettung zu einerQualitätssicherung von Modellen der verschiedenenPhasen bis hin zum laufenden System führen.
Der ModellbegriffDer Begriff ,,Modell“ wurde in der italienischenRenaissance als Fachbegriff der Architektur geprägt.Er bezeichnet ein Anschauungsobjekt, anhanddessen Auftraggeber Form und Gestaltung einesgeplanten Gebäudes vorgeführt sowie konstruktive,architektonische Fragestellungen geklärt wurden.Bis zum Beginn des 20. Jahrhunderts etabliertesich der Modellbegriff als veranschaulichendeBeschreibung komplexer Theorien in den Natur-wissenschaften und als vereinfachendes Abbildoder Vorbild eines technischen Konstrukts in denIngenieurswissenschaften. Eine heute allgemeinanerkannte Definition des wissenschaftlichen Mo-dellbegriffs geht zurück auf H. Stachowiak [49], derfolgende Merkmale eines Modells als konstituierendherausstellt:
1. Abbildung: Modelle stehen immer in Bezug zueinem Original, das sie abbilden.
2. Verkürzung: Modelle erfassen i. Allg. nicht alleAttribute des durch sie repräsentierten Originals.
3. Pragmatismus: Modelle sind ihren Origi-nalen nicht per se eindeutig zugeordnet,sondern ihre Ersetzungsfunktion erfüllen siefür bestimmte Subjekte unter bestimmten Ein-schränkungen (Zweck und Randbedingungen derModellkonstruktion).
Zusätzlich wird zwischen deskriptiven undpräskriptiven Modellen unterschieden: Deskrip-tive Modelle (z.B. ein Stadtplan) beschreiben einOriginal zum leichteren Verständnis, währendpräskriptive Modelle (z.B. ein Bebauungsplan) zurErstellung eines Originals beitragen. Der primäreFokus dieses Artikels liegt auf präskriptiven Model-len (z.B. Entwurfsmodellen) eines zu entwickelndenSoftwaresystems. Diese dienen im Wesentlichen derschrittweisen Strukturierung und Formalisierungdes Systems durch Verfeinerung [41]. Aufgrund derimmateriellen Natur von Software ist allerdings auchder Code ein Modell des ausführbaren Systems, dasnatürlich Rückschlüsse auf die Qualität des Pro-
dukts, aber auch auf die Qualität anderer Artefaktezulässt (z.B. Konfiguration, Dokumentation).
Je nach Einsatzzweck eines Modells kann vonunterschiedlichen Aspekten des Systems abstrahiertwerden und damit Sichten bilden: Klassen- oderZustandsdiagramme im Entwurf [36] sind präskrip-tive Modelle des zu erstellenden Softwaresystems.Daneben kommen aber auch deskriptive Modellewie Umgebungsmodelle bei eingebetteten Systemenoder Ontologien im Zusammenhang mit Informa-tionssystemen im Entwurf zum Einsatz. Bei derAnforderungsspezifikation wird aus der Beschrei-bung der Istsituation die Zielsituation abgeleitet,die mithilfe des zu entwickelnden Softwaresystemserreicht werden soll. In diesem Sinne ist die An-forderungsspezifikation ein transientes Modell [36].Beim Nachweis der funktionalen Korrektheit werdendeskriptive Entwurfs- und Systemmodelle progno-stisch eingesetzt, wenn mit formaler Verifikationnachgewiesen wird, dass Anforderungen für jedesmögliche Verhalten im Modell erfüllt sind. Beider Evolution von Software werden Architektur-und Entwurfsmodelle explorativ verwendet, d.h.geplante Veränderungen werden erst am Modellvorgenommen und evaluiert, bevor sie in einer Im-plementierung umgesetzt werden. Die Taxonomieder Modelle ergibt sich aus dem primären Zweckeines Modells: Ein Zustandsdiagramm als Verhal-tensmodell im Entwurf ist präskriptiv, wenn es indie Dokumentation des implementierten Systemsübernommen wird; wird es deskriptiv verwendet,wenn der Zustandsraum dieses Diagramms mitModel-Checking exploriert wird, um funktionaleAnforderungen zu verifizieren, wird es prognostischeingesetzt.
Eine andere Betrachtung des Modellierungs-zwecks findet sich im Umfeld der Referenz-modellierung von Informationssystemen [13]:Hier steht der kreative Konstruktionsprozessmit seinen Randbedingungen und subjektivenEinflüssen im Vordergrund. Diese Interpre-tation trägt dem immateriellen Charaktervon Software und den kaum objektivierbarenEinflüssen im SoftwareentwicklungsprozessRechnung.
Der Fortschritt bei Modelltransformationen,Codegenerierung und formalen Methoden er-möglicht es, aus immer abstrakteren Modellenverfeinerte Modelle abzuleiten und somit auto-matisiert lauffähige Software zu erzeugen und zu
410 Informatik_Spektrum_31_5_2008
analysieren. Viele heute im Einsatz befindliche Mo-delltypen können automatisiert simuliert werden. Soverstärkt sich der transiente Charakter von Model-len im Software-Engineering, und die Beziehungenzwischen Modell und dem modellierten Systemwerden vielfältiger und komplexer.
Oft wird Modell auch als Synonym zu einer Sichtbetrachtet. Eine Sicht beschreibt einen Teilaspekteiner, bzw. eine bestimmte Perspektive auf dasGesamtsystem (abgebildet durch die Softwarear-chitektur) [11]. Aufgrund der Systemkomplexitätgibt es kein Modell, das ein Softwaresystem alsGanzes und in allen Details beschreibt (außer beisehr trivialen Systemen), sondern einzelne, ge-eignet komponierbare Modelle, die gemeinsamdie Softwarearchitektur oder den Entwurf bilden.Dadurch entstehen in einem Entwicklungsprozesssich horizontal ergänzende Modelle, die in ihrerKombination (d.h. Komposition) notwendige,konstruktionsrelevante Informationen über dasgesamte System darstellen, sowie vertikal sichin ihrem Informationsgehalt jeweils ablösendeModellketten. Abbildung 1 zeigt eine von vielenverschiedenen, meist methodenabhängigen Kom-binationsmöglichkeiten. Einzelne Elemente derArchitektur können somit in mehreren Modellenvorkommen (bzw. referenziert werden). Modelleeiner späteren Schicht der Modellkette beinhaltenInformationen der früheren Schicht, angereichertum technische Details und Entwurfsentscheidun-
Abb. 1 Beispiele für eineVerwendung horizontalerund vertikalerModellketten
gen. Sie bilden den Ausgangspunkt für weitereEntwicklungsschritte.
In der Research-Roadmap zur ,,Model-DrivenDevelopment of Complex Software“ [23] wurdeangemahnt, dass neben der noch ausstehendenKonsolidierung und Verbesserung der Werk-zeuglandschaft sowie der Standardisierung vonEntwicklungsnotationen, die Qualitätssicherungvon Modellen eine aktuelle Herausforderungan Wissenschaft und Industrie darstellt. DieseQualitätssicherung muss auf einem empirischenErfahrungsschatz zur Modellqualität beruhen, diegeeignete Qualitätsziele und -attribute, Qualitäts-maße, sowie deren Messung und Interpretationumfasst. Dabei müssen gerade wegen der Durch-gängigkeit vom Modell zum Original und denvielfältigen Zwecken der Modelle klar die verschie-denen Dimensionen der Qualität unterschiedenwerden: Soll anhand eines Modells die Qualitätdes Endprodukts Software beurteilt werden, oderist das Modell und seine Beziehung zum Originalauf seine Eignung für den angegebenen Zweckzu beurteilen und die Qualität der Software nurmittelbares Ziel. Außerdem sind die Einflüsse dereinzelnen Qualitätsattribute der Modelle auf dieQualitätsattribute des Codes zu klären. So bedeutetetwa gute Lesbarkeit des Modells keineswegs, dassdaraus generierter Code ebenfalls gut lesbar ist,während zwischen Modell- und Systemkorrektheitsehr wohl eine Korrelation bestehen dürfte.
Informatik_Spektrum_31_5_2008 411
{ MODELLIERUNG
Der Qualitätsbegriff,,Qualität“ leitet sich von dem lateinischen Wortqualitas (Beschaffenheit) ab und wird in der NormISO/IEC 9126:2001 zur Softwareproduktqualität als,,the totality of characteristics of an entity that bearon its ability to satisfy stated and implied needs“aus der ISO 8402 übernommen. Die Produktqualitätwird von der Prozessqualität, d.h. der Güte desEntwicklungsprozesses, abgegrenzt. Die Normunterscheidet zwischen interner, externer undGebrauchsqualität:
– Interne Qualität ist die Gesamtheit der Güte-merkmale aus einer herstellungsorientiertenSicht. Sie umfasst die Qualitätsattribute an alleZwischenprodukte der Entwicklung.
– Externe Qualität beinhaltet die technischen Güte-merkmale des Produkts aus einer externen Sicht.Die externe Qualität wird i. Allg. durch Messungenund Tests während der Ausführung der Software ineiner definierten Umgebung bestimmt.
– Gebrauchsqualität beschreibt die Gütemerkmaleaus Sicht des Benutzers, dabei ist nicht nur derKontext der Benutzung zu berücksichtigen, son-dern auch inwieweit der Benutzer die angestrebtenZiele mit der Software erreichen kann.
Wir beziehen dabei alle Qualitätsarten primärauf das Softwareprodukt. Darüber hinausgehendlässt sich die Modellqualität von präskriptiv ver-wendeten Entwurfsmodellen im Wesentlichen derinternen Qualität zuordnen. Außerdem hängentransiente Modelle im Bereich der Anforderungser-hebung und Modelle, aus denen automatisiert Codeerzeugt wird, unmittelbar mit der externen und derGebrauchsqualität zusammen.
QualitätsmodelleZur Differenzierung der Qualitätsanforderungenwerden sogenannte ,,Qualitätsmodelle“ verwen-det. Qualitätsmodelle setzen sich aus – häufighierarchisch strukturierten – Qualitätsattributenzusammen. Den Qualitätsattributen werden Tech-niken zur Qualitätsbewertung zugeordnet. EineQualitätsvorgabe gibt an, zu welchem Grad dieErfüllung des Qualitätsattributs für das zu bewer-tende Artefakt gefordert wird. Zur Erstellung einesQualitätsmodells werden entweder generische Qua-litätsmodelle den spezifischen Projekterfordernissenangepasst oder aber ein spezifisches Qualitätsmo-
Abb. 2 ISE/IEC 9126 Qualitätsmodell
dell gemäß eines definierten Vorgehensmodellsentwickelt:
Die ISO/IEC 9126:2001 bietet das in Abb. 2dargestellte hierarchische, generische Qualitäts-modell für die interne und externe Qualität sowieein einfaches für die Gebrauchsqualität. Die darinvorgeschlagenen Qualitätsattribute müssen danngemäß der Norm im Kontext der aktuellen Phaseim Lebenszyklus und im Sinne der jeweiligen Stake-holder verfeinert, ergänzt oder verworfen werden.In der Entwicklung sind die externen und die Ge-brauchsattribute in interne Qualitätsattribute zutransformieren, um im Prozess zielgerichtet auf dieQualitätsanforderungen an das Produkt zuzusteu-ern. Methodisch ähnliche Merkmale haben eineReihe von Ansätzen wie etwa [31].
Wie bereits angesprochen, gibt der Modellie-rungszweck die Ebene einer Qualitätsanforderungvor, z.B. setzt Wiederverwendbarkeit als Qua-litätsziel die langfristige Perspektive auf einenevolutionären Lebenszyklus voraus. Diese Dimen-sion ist naturgegebener Maßen bestimmend bei derAbleitung von Bewertungstechniken: Während fürQualitätsziele für klar abgegrenzte Zwecke Metrikenoder analytische Verfahren etabliert sind, wird beiQualitätsanforderungen an das Endprodukt undseine Evolution oft mit Heuristiken, Best Practicesund qualitativen Verfahren gearbeitet.
Alternativ wurden systematische Vorgehensmo-delle zur Entwicklung spezifischer Qualitätsmodelle
412 Informatik_Spektrum_31_5_2008
vorgeschlagen wie der Goal-Question-Metric-Ansatz (GQM) [3, 10]. Bei GQM werden zuerstQualitätsziele (goals) festgelegt, wobei sich einQualitätsziel aus dem zu bewertenden Objekt, denQualitätsattributen für dieses Objekt sowie derPerspektive eines Stakeholders zusammensetzt.Im zweiten Schritt werden dann Fragestellungen(questions) abgeleitet, die von den Qualitätszie-len zu Bewertungen für die Qualitätsattribute derzu bewertenden Objekte führen. Auf der dritten,quantitativen Ebene stehen Metriken (metrics).Zur Evaluation eines Qualitätsziels werden danndie den abgeleiteten Fragestellungen zugeordnetenMetriken ausgewertet und gewichtet kumuliert.
Als Weiterentwicklung und Spezialisierungdes GQM-Ansatzes zur Bewertung von Soft-warearchitekturen können szenarienbasierteArchitekturevaluationsmethoden [18, 20] ver-standen werden: Wie GQM unterstützen sie dieBildung eines spezifischen Qualitätsmodells durchdetaillierte Richtlinien und Vorlagen für ein stan-dardisiertes, systematisches Vorgehen. Um eingemeinsames Verständnis der Stakeholder vonden Qualitätsanforderungen schon in der frühenPhase des Architekturentwurfs zu gewährleisten,werden Szenarien spezifiziert, mit denen einerseitskomplexe Situationen – etwa zur geplanten Evolu-tion eines Systems – beschrieben werden können,andererseits der diffuse Raum der Möglichkeiteneingeschränkt wird.
Generische Qualitätsmodelle haben den Vorteil,dass sie eine strukturierte Ausgangsbasis mit eineroft umfangreichen Liste von zu berücksichtigendenQualitätsattributen anbieten. Allerdings müssen –wie schon Rombach in [5] ausführt – in praktischallen Fällen projekt- und phasenspezifische Anpas-sungen vorgenommen werden. Insbesondere dieAbleitung aussagekräftiger Bewertungstechnikenfür Zwischenprodukte der Entwicklung aus denQualitätsattributen wird selten gelöst. GQM undszenarienbasierte Ansätze tragen der Vielschich-tigkeit von Qualitätsanforderungen Rechnung,indem komplexere Qualitätsziele oder Szenarienspezifiziert werden. Zusätzlich erhält der Qualitäts-manager Techniken an die Hand, um Metriken fürdie Qualitätsziele abzuleiten. Daher sind GQM undszenarienbasierte Ansätze sicher im ersten Anlaufals aufwändiger zu betrachten, allerdings führen siezu passgenaueren Qualitätsmodellen, und sie stellendie Frage nach dem Zusammenhang zwischen Qua-
litätszielen und Maßen für die Zwischenprodukteder Entwicklung methodisch in den Mittelpunkt.
Qualitätsattribute in derSoftwareentwicklung
Als Zwischenprodukte der Entwicklung werdenModelle implizit fast immer zur Bewertung der Soft-warequalität herangezogen. Explizit werden Aspekteder Modellqualität allerdings nur in Teilbereichenbehandelt. Im Folgenden wird ein Überblick zubekannten Ansätzen in der Literatur gegeben.
Modellqualität in InformationsmodellenInformationsmodelle dienen der Strukturierungvon semantischen Räumen bei der Konzeptionkomplexer Informationssysteme, insbesondere fürAnwendungen in Betrieben und Behörden.
– In den Arbeiten zu Grundsätzen ordnungsgemä-ßer Modellierung [15] werden als übergeordneteQualitätsattribute im Rahmen der Informa-tionsmodellierung Richtigkeit, Relevanz,Wirtschaftlichkeit, Klarheit, Vergleichbarkeitund systematischer Aufbau gefordert. Diese Attri-bute werden dann verfeinert und müssen vor derAnwendung projektspezifisch angepasst werden.
– Schütte entwickelt diese Grundsätze in [48] weiterund fordert Konstruktionsadäquanz, Sprachad-äquanz sowie Klarheit, Vergleichbarkeit undsystematischen Aufbau.
Die Herausforderung bei diesen Modellen be-steht darin, dass das Original, die strukturierte Be-griffswelt der Anwendungsdomäne, rein gedanklichund nur in den seltensten Fällen standardisiert ist.Die Qualitätsattribute leiten sich daher aus Anforde-rungen an die Abbildung und dem Zweck des Modellsals Kommunikationsgrundlage der Projektbeteilig-ten ab. Sie sind unabhängig von dem gewähltenModellierungsparadigma und der -notation. Aber– wie Becker und Schütte herausstellen – sind sie inTeilen nicht objektiv bewertbar: So ergibt sich diesemantische Richtigkeit des Informationsmodells(aus softwaretechnischer Sicht: die ursprünglicheAnforderungs- und Umgebungsspezifikation) ,,ausdem Diskurs der Gutwilligen und Sachkundigen“.
Qualität der SoftwarearchitekturEine Softwarearchitektur beschreibt die wesentli-chen Strukturen eines Systems, die Softwarekom-
Informatik_Spektrum_31_5_2008 413
{ MODELLIERUNG
ponenten, ihre sichtbaren Eigenschaften und Be-ziehungen sowie die bestimmenden Prinzipien desEntwurfs und der Evolution des Systems [42, 54].Produktorientierte Qualitätsziele sind daher einerArchitektur inhärent und werden in einer Reihe vonAnsätzen diskutiert:
– [4] definiert als Qualitätsmerkmale für eine Archi-tektur: Verfügbarkeit, Änderbarkeit, Performance,Sicherheit, Testbarkeit und Benutzbarkeit.
– [35] definiert als Qualitätskriterien: Testbarkeit,Wartbarkeit, Erweiterbarkeit und Portierbarkeit.
– [11] definiert als nicht-funktionale Eigenschafteneiner Softwarearchitektur: Änderbarkeit (mit denAspekten Wartbarkeit, Erweiterbarkeit, Restruktu-rierbarkeit und Portierbarkeit), Interoperabilität,Effizienz, Zuverlässigkeit (mit den AspektenFehlertoleranz und Robustheit), Testbarkeit undWiederverwendbarkeit.
– [12] definiert als Qualitätsmerkmale: Performance,Maintainability, Flexibility, Reliability, Securityund Safety.
Weitere Merkmale aus der Literatur sindVollständigkeit, unterteilt in syntaktische und se-mantische Vollständigkeit [24] sowie Skalierbarkeit,Portabilität [4]. Naturgemäß werden an die Archi-tektur nachhaltige Qualitätsanforderungen gestellt,die in der frühen Phase des Architekturentwurfs nurungenau und aufwändig bewertet werden können.Daher dominieren in diesem Bereich qualitativeBewertungsmethoden wie etwa ATAM (ArchitectureTrade-Off Analysis Method) [4]. Quantitative Ver-fahren versuchen, die Bewertungen für verschiedeneQualitätsattribute über Qualitätsraten zusammen-zuführen [4, 20]. Für einzelne Qualitätsattributewie Sicherheit oder Performanz existieren quantita-tive Bewertungsverfahren, die aus der ArchitekturAnalysemodelle ableiten, die dann mathematischoder simulativ ausgewertet werden (s. [29] für einenÜberblick).
Qualität von EntwurfsmodellenInsbesondere zur Qualität objektorientierterEntwürfe gibt es eine Vielzahl von Arbeiten:
– [6] definiert ein hierarchisches Qualitätsmodellmit den übergeordneten Qualitätsattributen Wie-derverwendbarkeit, Flexibilität, Verständlichkeit,Funktionalität, Erweiterbarkeit und Effektivität.
Auf der zweiten Ebene haben Bansiya und Davisjedem Qualitätsattribut mehrere Entwurfsmerk-male zugeordnet, die dann mit Metriken bewertetwerden.
– Ein Ansatz zur Entwurfsqualität findet sichin [51]. Dort werden die QualitätsmerkmaleVollständigkeit (completeness), Inhärenz (in-herence), Übersichtlichkeit (clarity), Konsistenz(consistence), Orthogonalität (orthogonality)und Allgemeingültigkeit (generality) als Ei-genschaften innerhalb und zwischen Modellendefiniert.
– Ausführlich diskutiert Reißing in [43] Qualitäts-attribute für objektorientierte Entwürfe. Seindifferenziertes, generisches Qualitätsmodell kon-zentriert sich auf die herstellungsorientiertenAttribute Wartbarkeit, Wiederverwendung, Wie-derverwendbarkeit, Brauchbarkeit, Testbarkeitund Prüfbarkeit, für die er dann auf Basis sei-nes Entwurfsmetamodells Designkriterien undMetriken entwickelt.
Bei der Entwurfsqualität dominieren Arbeitenzu Bewertungsverfahren: Metriken für objekt-orientierte Entwürfe werden inzwischen bereitsvon einer Reihe von Werkzeugen unterstützt [21].Standardisierte oder projektspezifisch angepassteModellierungsrichtlinien oder Checklisten zurQualitätssicherung sind auch in der industriellenPraxis weit verbreitet [1, 30]. Neuere Arbeiten bezie-hen auch Domänenwissen und softwaretechnischeExpertise (Best Practices) in die Qualitätsbewertungein, indem etwa die Verwendung von Mustern,aber auch Anti-Mustern (,,Bad Smells“), analysiertwird. Briand et al. [9] weisen empirisch für einzelneQualitätsattribute nach, dass die mit Metrikenfestgestellten Qualitätsmaße auf Entwurfsebene si-gnifikant für korrespondierende Qualitätsmerkmaleder Implementierung sind.
SoftwarequalitätNeben der oben diskutierten ISO/IEC 9126 zurSoftwareproduktqualität wurden eine Reihe wei-terer generischer Qualitätsmodelle entwickelt,beispielsweise:
– Der IEEE Standard 1061 gibt die gleichen Quali-tätsattribute wie die ISO/IEC9126 auf der oberstenEbene vor, unterscheidet aber auf der zweitenEbene andere Qualitätskriterien. Der Schwerpunkt
414 Informatik_Spektrum_31_5_2008
der IEEE 1061 liegt auf der Bereitstellung vonMetriken.
– Hewlett-Packard entwickelte 1987 ein ähnlichesQualitätsmodell, es unterteilt sich in die MerkmaleFunctionality, Usability, Reliability, Performanceund Supportability, wobei diese ebenfalls weitereUntermerkmale besitzen [2].
– Bereits eines der ersten Qualitätsmodelle vonMcCall [37] betrachtet die Qualitätsattribute unterden Perspektiven Anwendung, Entwicklung undEvolution.
Bei der Softwarequalität werden Modelle nurindirekt adressiert, insoweit sie als Dokumentationdes Produkts Rückschlüsse auf dessen Qualitätzulassen.
Dieser Überblick über existierende Qualitätsat-tribute entlang des Softwareentwicklungsprozesseszeigt, dass der Zweck des Modells auch den Schwer-punkt der Qualitätsbetrachtungen bestimmt: BeiInformationsmodellen und Entwurfsmodellen stehtder Nutzen des Modells für die folgenden Entwick-lungsschritte im Vordergrund: Zum Teil werdensogar die konstituierenden Merkmale eines Modellszu Qualitätsattributen, wenn etwa Konstruktionsad-äquanz, Verständlichkeit oder Effektivität gefordertwird. Auch Qualitätsattribute wie systematischerAufbau, Einhaltung von Standards oder Überein-stimmung mit bewährten Entwurfsprinzipien zielenunmittelbar auf die Erfüllung der präskriptivenAufgaben der Modelle im Entwicklungsprozess,aus der sich dann die Qualität der entwickelndenSoftware mittelbar ergibt.
Bei Architekturmodellen und Softwareprodukt-qualität dagegen adressieren die Qualitätsattributein erster Linie die Qualitäten des EndproduktsSoftware, die prognostiziert oder exploriert wird.Ein Modell tritt ,,nur“ als adäquater Träger dieserInformationen in Erscheinung und wird selbstkeiner Qualitätsbetrachtung unterzogen.
Arten von Qualitätsanforderungenan Modelle
Nachdem Modellqualität als eigenständiges Zielerkannt ist, stellt sich nun die Frage, welche qualita-tiven Anforderungen an ein Modell zu stellen sind,um dem Gesamtziel, der qualitativ hochwertigenSoftware, zu genügen. Dabei können grund-sätzlich Kategorien von Qualitätsanforderungenunterschieden werden:
Wir bezeichnen Qualitätsattribute des Modellsals ,,innere Qualität“, wenn diese alleine für sichfestgestellt werden können (die ,,innere Qualität“ist somit kein Synonym zur ,,internen Qualität“ derISO/IEC 9126:2001, alle hier definierten Qualitätsat-tribute zählen zur internen Qualität). Dazu gehörenetwa ein übersichtliches Layout der Darstellung, zumBeispiel, dass Startzustände eines Statechart-Linksoben angeordnet sind und dergleichen mehr.
Demgegenüber stehen Qualitätsattribute, dieein Modell mit einem anderen Betrachtungsgegen-stand in Beziehung setzen. Zu diesen ,,relativen“oder ,,äußeren Qualitätsanforderungen“ gehörenBeziehungen zu den (informellen) Anforderungender Nutzer, wie etwa Korrektheit des Modells oderin Bezug auf den darzustellenden Systemausschnittauch die Vollständigkeit. Grundsätzlich sind dieseBeziehungen auch zu dem im Entwicklungsprozessnachfolgenden, zu realisierenden System relevant.Allerdings wird etwa die korrekte und vollständigeRealisierung des Systems primär als Qualitätsattri-but des Systems und nicht des Modells betrachtet.Während also relative Qualitätsanforderungenformal als Relation zwischen Entwicklungsartefak-ten zu sehen sind, ist ihre praktische Auswirkungzumeist als Anforderung an die Qualität des imEntwicklungsprozess nachfolgenden Artefakts zusehen. Diese zeitlich orientierte Sichtweise ist auchfür Werkzeugketten bzw. die Ketten an Modelleneinzusetzen, wenn in einem mehrstufigen ProzessModelle aus Anforderungen verfeinert, diese ineine Architektur umgesetzt, zum Design detailliert,technische Aspekte hinzugefügt und schließlich zurImplementierung gebracht werden.
Dieser vertikalen Modellkette mit ihren Be-ziehungen steht in großen Softwaresystemen einehorizontale Zerlegung von Modellen in kleine,handhabbare Einheiten gegenüber. Dazu gehörtetwa die Bildung mehrerer Datenmodelle der ein-zelnen Softwarekomponenten durch mehrere, nuran ,,Klebestellen“ zusammen zu setzende Klassen-diagramme, oder die hierarchische Zerlegung vonArchitekturen. Diese horizontale Zerlegung erfor-dert weitere qualitative Anforderungen zwischenModellen, wie etwa die Konsistenz der einzelnenModelle. Demgegenüber ist die Vollständigkeit sol-cher Einzelmodelle im Allgemeinen kein Kriterium.Diese Form der im Sinn der Entwicklungsebenehorizontalen Beziehungen zwischen Modellen kannverfeinert werden in homogene Beziehungen, etwa
Informatik_Spektrum_31_5_2008 415
{ MODELLIERUNG
zwischen Teilklassendiagrammen, und inhomo-gene Beziehungen, etwa zwischen Statecharts undSequenzdiagrammen, die das Verhalten derselbenKomponenten aus unterschiedlicher Sicht beschrei-ben. Darüber hinaus bestehen bei einer hierarchischangelegten Notation, wie etwa den in [14] ein-geführten Architekturmodellen, hierarchischeBeziehungen zwischen denen, die im Entwick-lungsprozess oft, wenn auch nicht zwingend, einezeitliche Reihenfolge intendieren. Architektur kannzum Beispiel Top-Down oder Bottom-Up erstelltwerden und wird zumeist evolutionär auf allenEbenen parallel weiter entwickelt.
Es lässt sich zusammenfassend feststellen,dass Qualitätsanforderungen für Modelle in fol-gende Kategorien eingeteilt werden können, die dienachfolgende Struktur des Artikels bestimmen:
– Innere Qualität: Qualitätsanforderungen an eineinzelnes Modell.
– Äußere Qualität: Qualität mit Bezug auf andereEntwicklungsartefakte.
– Horizontale Beziehungen: Qualität mit Bezug aufNachbarmodelle.
∗ Homogene Beziehung (zum selben Modelltyp).∗ Inhomogene Beziehung (zu anderem
Modelltyp).∗ Hierarchische Komposition aus demselben
Modelltypen.
– Vertikale Beziehungen: Qualität mit Be-zug auf den Vorgänger/Nachfolger imEntwicklungsprozess.
– Externe Beziehungen: Qualität mit Bezugauf weitere Artefakte, bspw. Anforderungen,Systemumgebung.
– Bezug zum Endprodukt, dem Softwaresystem.
Die eingeführte Kategorisierung von Qualitäts-anforderungen für Modelle erlaubt uns nun, diesedetaillierter zu diskutieren.
Innere Qualität
DarstellungDie Darstellung ist für jede Art von Modell, insbe-sondere aber für ein grafisches Modell, ein für dieWahrnehmung und Akzeptanz durch den Benutzer
entscheidendes Qualitätsmerkmal. Ein wichtigerEinsatzzweck von Modellen ist die Dokumentationund Kommunikation der getroffenen Entscheidun-gen – je besser die Darstellung, desto besser ist dieWahrnehmung und umso höher die Verständlich-keit des Systems. Zwar können mit einem Modellkomplexe Sachverhalte verständlicher dargestelltwerden, jedoch ist der Mensch in seinen Möglich-keiten der kognitiven Wahrnehmung begrenzt –ein überladenes, unübersichtliches Modell wirdnicht verstanden, nicht akzeptiert, gegebenenfallsignoriert und führt letztlich zu Fehlern in den aufdie Modellbildung folgenden Aktivitäten. So ist zumBeispiel die Anzahl der Elemente begrenzt, die einMensch gleichzeitig erfassen kann.
Die Ästhetik eines Modells beeinflusst dasEmpfinden des Nutzers. Ein Modell, das durch denBenutzer als ,,ansprechend“ oder ,,schön“ betrachtetwird, weist eine höhere (subjektive) Gebrauchstaug-lichkeit auf. Obwohl die Ästhetik nicht vollständigobjektivierbar ist, so lassen sich doch mithilfe all-gemeingültiger Gestaltungsrichtlinien ästhetischanspruchsvolle Modelle entwickeln.
Mithilfe des Modells sollen unterschiedlicheAspekte verdeutlicht werden. Durch eine hoheVerständlichkeit bzw. eine gute Übersichtlichkeitdes Modells lassen sich die Aspekte schneller undeinfacher begreifen. Enthält bspw. ein Klassenmo-dell zu viele unterschiedliche Klassen, so fällt es demBenutzer schwer, die wichtigen Aspekte des Modellsschnell zu begreifen. Ebenso führt ein ,,chaotisches“Modell zu Verwirrung beim Benutzer. Durch einübersichtliches und strukturiertes Modell (d.h. einModell mit einem guten Layout) können leicht diewichtigen Aspekte hervorgehoben werden.
PräzisionDie Präzision beschreibt, inwieweit das Modell diefür den aktuellen Zweck relevanten Merkmale derUmgebung, der Anforderungen oder des zu realisie-renden Systems widerspiegelt. Präzision adressiertdie Güte der Verkürzung, die bei der Modellbildungstattfindet: In einem präzisen Modell sind die aus-gelassenen Attribute des Originals für die aktuelleEntwicklungsphase unbedeutend. Präzision ist nichtzu verwechseln mit Detailreichtum oder Formalität:So lässt sich Interaktion auf der Anwendungsebeneeinfach und präzise als synchrone Kommunikationmodellieren, sofern die darunter liegende Kom-munikationsarchitektur entsprechende Dienste
416 Informatik_Spektrum_31_5_2008
anbietet. Von den möglicherweise komplexentechnischen Details kann im Entwurfsmodellder Anwendung abstrahiert werden. Andernfallswurden für den Entwurf wesentliche Verhaltens-eigenschaften durch die Modellierung unzulässigvereinfacht.
UniversalitätDie Universalität des Modells gibt an, inwieweit sichdas Modell auf die für die aktuelle Entwicklungs-phase notwendigen Festlegungen fokussiert, oderaber darüber hinaus Eigenschaften hinzugefügt wer-den, die eine unnötig komplexe oder eingeschränkteund damit letztlich teure Lösung induzieren, oderdie spätere Weiterentwicklung und Wiederver-wendung erschweren. Ein wichtiger Schritt zurVerbesserung der Universalität von Modellen istModel-Driven-Development, bei dem bewusst zwi-schen plattformunabhängigem, fachlichen Entwurfund technischen, plattformabhängigen Modellengetrennt wird.
EinfachheitEin wichtiges Qualitätsattribut ist die Einfachheit:Ein Modell sollte nicht komplexer sein, als diedargestellte Materie es verlangt. Einfachheit in derDarstellung kann oft durch Reformulierung undRestrukturierung semantikerhaltend (also ohne denInformationsgehalt zu verändern) erreicht werden.Deshalb betrachten wir die Einfachheit des Modellsals eine Anforderung an die innere Qualität einesModells, ohne den Bezug zu den darzustellendenInhalten zu fordern.
Da im Modell die für einen gewissen Darstel-lungskontext unwichtigen Details weggelassenwerden können, um von einem komplexen Zusam-menhang zu abstrahieren und diesen verständlichzu machen, ist eine zweite Interpretation des Quali-tätsattributs Einfachheit mit dem Zweck des Modellsund dem darzustellenden Original bzw. Systemgekoppelt. Zu beachten ist, dass ein einfaches Modell– wie oben beschrieben – gleichzeitig präzise seinkann, d.h. dass Einfachheit nicht bedeutet, dassPräzision aufgegeben werden muss.
Semantische AdäquatheitDurch geeignete Interpretation ist es möglich,denselben Sachverhalt in verschiedenen Model-lierungssprachen darzustellen. So kann etwa eineKombination aus Klassen- und Objektdiagramm
eingesetzt werden, um ein Zustandsmodell zubeschreiben. Das Entwurfsmuster ,,State“ schlägtzur Implementierung eines Zustandsautomatengenau das vor. Adäquat modelliert ist dies abernicht. Genau so ist es oft unsinnig, zustandsloseKomponenten mit Statecharts zu modellieren oderEntwurfsmuster unangemessen einzusetzen. Diesemantische Adäquatheit des Modells für denbeabsichtigten Zweck spielt dementsprechendfür die Qualität eines Modells eine wesentlicheRolle.
KonsistenzDie Konsistenz gibt an, in welchem Maß das Modellin sich konsistent ist. Eine Sammlung von meistsyntaktischen Konsistenzbedingungen legt zumBeispiel fest, dass Variablen vor ihrer Nutzungeinzuführen sind und ihre Typisierung passenmuss. Konsistenzbedingungen, die innerhalb ei-nes Modells geprüft werden können, heißen auchIntramodellkonsistenz. Für die Wiederverwendbar-keit und Modularität eines Modells ist es günstig,möglichst viele Konsistenzbedingungen innerhalbdes Modells zu klären. Konsistenzbedingungen,die über mehrere Modelle hinweg zu klären sind,werden Intermodellkonsistenz genannt. Sie tretenetwa dann auf, wenn die Strukturmodelle Attribute,Speicherplätze oder Schnittstellen beinhalten, aufdie in den Verhaltensmodellen Bezug genommenwird.
Konzeptionelle Integrität/UniformitätUm eine einheitliche, gleichförmige und systema-tisch realisierbare Software zu erreichen, sollteversucht werden, wiederholt die gleichen Regeln,Muster und Prinzipien in kohärenter Form anzu-wenden. In diesem Zusammenhang spricht manauch von konzeptioneller Integrität oder Unifor-mität (,,Gleiches wird gleich gelöst“). Ähnlich wiedie Konsistenz ist die konzeptionelle Integritätaber oft auch modellübergreifend zu verstehen, daEinheitlichkeit über alle Dokumente eines Projektserreicht werden sollte.
KonformitätDie Konformität ist ein Maß für die Verwendungvon Standards und Normen im Modell. Konformitätwird in Bezug auf genormte und standardisierteMethoden, Muster, Prinzipien oder Sprachenfestgelegt.
Informatik_Spektrum_31_5_2008 417
{ MODELLIERUNG
Die bereits diskutierte konzeptionelle Integritätkann eine Konsequenz der Konformität sein, wenndiese einen genügend engen Rahmen und Freiheitenvorgibt. Allerdings sind Normen und Standardsgerade so gewählt, dass eher viele Freiheiten ge-lassen werden und für eine konzeptuelle Integritätzusätzliche, meist projektspezifische Festlegungenzu treffen sind.
Weitere Qualitätsanforderungen können festgelegtwerden, wenn die Modellierungssprache spezifische,meist semantisch zu verifizierende Kriterien anbie-tet. Dazu gehört zum Beispiel die Vollständigkeiteines Statechart/Automaten, mit der gesichert wird,dass für die modellierte Komponente in jedemZustand zu jeder möglichen Eingabenachricht eineReaktion existiert. Petrinetze bieten mit ihrer ausge-feilten Theorie zu Lebendigkeit etc. eine Sammlungan semantischen Qualitätsanforderungen, die al-lein auf Basis des Modells entschieden werdenkönnen.
Äußere Qualität(Horizontale Beziehungen)
Viele Qualitätsanforderungen gelten als Relationenzwischen Modellen. Gemäß unserer Einteilung wer-den in diesem Abschnitt Qualitätsanforderungendefiniert, die zwischen Modellen innerhalb einerEntwicklungsphase relevant sind. Diese Modelleergänzen sich in ihren Inhalten zu einer Gesamtin-formation über das zu realisierende System, deckenjedoch nur einzelne Phasen im Entwicklungsprozessab.
Die bereits oben genannten, innerhalb eines Mo-dells relevanten Qualitätsattribute Konsistenz,konzeptionelle Integrität und viele sprachspezifi-sche Qualitätsanforderungen werden erst bei derBetrachtung der Beziehungen zwischen Modellenformulierbar. Als zusätzliche Komplexitätsstufeentsteht hier die Definition von Schnittstellen,die Sichtbarkeiten beschreibt, und es geschiehtdas Management (import, export, hiding) undDurchreichen von benannten Elementen dieserSchnittstellen.
Vollständigkeit nach untenIm nachfolgenden Abschnitt wird die ,,Vollständig-keit nach oben“ als die vollständige Umsetzungder in der vorhergehenden Phase der Modell-kette vorhandenen Information eingefordert. Die,,Vollständigkeit nach unten“ unterscheidet sichdemgegenüber, weil sie fordert, dass ein Modellalle notwendigen Informationen enthält, um dieArtefakte des nächsten Glieds der Modellketteabzuleiten oder zu generieren. Dies ist eine seman-tische Qualitätsanforderung, die nur die Modelleeiner Schicht der Modellkette betrifft und zu derenPrüfung kein Bezug zu den zum Prüfzeitpunktnoch nicht vorhandenen implementierungsnäherenModellen sein kann und darf. Dementsprechendwird diese Form der Vollständigkeit als horizontaleQualitätsanforderung betrachtet.
KohäsionKohäsion bedeutet, dass ein inhaltlich oder tech-nisch zusammenhängender Aspekt in einem engzusammenhängenden Teil des Modells behan-delt wird. Kohäsion ist ein Maß dessen, wie vieleModellteile zu verstehen sind, um einen Aspektdurchdrungen zu haben bzw. wie verteilt sich eineÄnderung auswirkt. Je kohäsiver eine Systemmo-dellierung einen Aspekt darstellt, umso einfacher istdieser im Systemkontext zu verstehen. Der Begriff,,Aspekt“ wird zwar in diesem Kontext nicht imSinne der Aspektorientierung verstanden, aberes zeigt sich, dass eine konsequente, auf Aspektehin orientierte Modellierung des Systems durchgeeignete Organisation der Architektur und durchKonzentration technischer Aspekte in entspre-chende Module die Kohäsion der Modellierung starkerhöhen kann, auch ohne aspektorientierte Model-lierung einzusetzen [50]. Die Kohäsion ist somiteng mit der Frage der Kopplung bzw. Kapselung derverschiedenen Aspekte verbunden.
ModularisierungDas Pendant zur Kohäsion ist die Modularisierunginhaltlich oder technisch unabhängiger Aspekte.Modularisierung ist die Grundlage dafür, dassunabhängige Teile auch unabhängig voneinan-der entwickelt, erweitert und wieder verwendetwerden können und ein wesentliches Mittel zurBeherrschung der Komplexität. Als Modellqualitätverstehen wir unter Modularisierung die Forderung,dass ein Modellelement oder Teilmodell auch nur
418 Informatik_Spektrum_31_5_2008
einen Aspekt behandelt. Unter Modularisierung fälltbeispielsweise die Anforderung, dass eine Klasseeine einzige Verantwortlichkeit haben sollte, oderdass bei einer zustandsbasierten Modellierung dieBetriebsmodi des Systems die Strukturierung aufden oberen Hierarchieebenen determinieren.
RedundanzfreiheitEine Qualitätsanforderung zwischen Modellenkann die möglichst redundanzfreie Darstellungvon Informationen sein. Redundanzfreiheit istfür die evolutionäre Weiterentwicklung wich-tig, weil in einer Anpassungsphase redundanteDarstellungen desselben Sachverhalts nicht not-wendigerweise konsistent modifiziert werden. Dieskann schnell zu Inkonsistenzen führen. VölligeRedundanzfreiheit wird aber in einer Welt hete-rogener Modellierungssprachen, die Sichten ineinzelne Artefakte zerlegen und per Namen zu ei-nem Gesamtmodell kombinieren, nicht zu erlangensein.
Kontrollierte RedundanzAndererseits ist die kontrollierte Modellierungredundanter Informationen ein wesentliches Mittelzur Qualitätssicherung. So können verschiedeneSichten auf einen Sachverhalt dazu genutzt werden,sowohl generativ/konstruktiv das lauffähige Systemzu entwickeln, als auch Testfälle dafür zu generie-ren [46, 47]. Beispielsweise können Statecharts fürdie Codegenerierung und Sequenzdiagramme fürTestfälle eingesetzt werden. In diesem Fall ist einekontrollierte Redundanz erwünscht. Sie lässt sichsogar messen in Form einer Testfallüberdeckungfür den generierten Code bzw. die Zustände undTransitionen des Statecharts.
Andere Formen kontrollierter Redundanz wer-den genutzt, um Informationen für verschiedeneEntwickler- und Testgruppen aufzubereiten und inderen spezifisch nutzbarer Sicht darzustellen oderAnforderungen aus verschiedenen Blickwinkelnzu betrachten und in Reviews und Inspektionendie Konsistenz als qualitätssichernde Maßnahmemanuell zu sichern.
Äußere Qualität (Vertikale Beziehungen)Die Qualitätsanforderungen eines Modells könnenauch im Bezug auf andere Entwicklungsartefaktedefiniert werden, die in der EntwicklungsgeschichteVorgänger bzw. Nachfolger des Modells sind. Frühe
Analysemodelle haben als Vorgänger typischerweisenur die informellen Anforderungen, die etwa ineinem Lastenheft dokumentiert sein können. Inder vertikalen Modellkette folgt nach dem Fein-design schließlich der Code. Jedes Modell einerModellkette ersetzt das vorhergehende, indem esdie dort vorhandenen Informationen in eine im-plementierungsnähere Form umsetzt und durchin Entwurfsentscheidungen getroffenen Detailsergänzt. Wesentliche in dieser Modellkette zuidentifizierende Qualitätsanforderungen sind:
KorrektheitKorrektheit bedeutet, dass das Modell die Anforde-rungen (gemäß in der Modellkette vorhergehendenArtefakte) präzise abbildet, d.h. dass alle Strukturen,Funktionen und Ausnahmen des Systems abgebildetsind. Diese Form der Korrektheit wird auch alssemantische Korrektheit verstanden, gelegentlichaber auch als ,,phasenübergreifende Konsistenz“bezeichnet. Ihr gegenüber steht die oben diskutierteKonsistenz als syntaktische Korrektheit des Modellsinnerhalb der Regeln einer Modellierungssprache.Sie verlangt, dass das Modell die Syntax der einge-setzten Sprache (z.B. UML) korrekt verwendet. Oftwird hierfür auch der Begriff ,,statische Semantik“verwendet. Demgegenüber beinhaltet die (seman-tische) Korrektheit sowohl funktionale Korrektheitals auch die korrekte Abbildung nichtfunktionalerAnforderungen. Zwischen syntaktisch überprüf-barer Konsistenz und semantischer Korrektheitkann nicht immer eindeutig unterschieden werden.Beispielsweise ist Terminierung zunächst eine An-forderung, also eine Korrektheitseigenschaft. Durchgeschickte Wahl der Modellierungssprache könnenevtl. aber hinreichende, syntaktisch prüfbare Kon-sistenzbedingungen gefunden werden, sodass sicheine Korrektheitseigenschaft des Modells durch einestatisch prüfbare Konsistenzeigenschaft ersetzenlässt.
Korrektheit nach unten heißt, alle Entschei-dungen einer Modellierungsebene werden in dernachfolgenden Schicht korrekt umgesetzt. Wäh-rend die Abbildung funktionaler Anforderungenrelativ gut verstanden ist, ist das Zerlegen undUmbauen nichtfunktionaler Anforderungen bis zurImplementierung und die Absicherung ihrer Kor-rektheit noch weitgehend Forschungsgegenstand.Insbesondere fehlen auch noch formalere Darstel-lungsmittel für nichtfunktionale Anforderungen in
Informatik_Spektrum_31_5_2008 419
{ MODELLIERUNG
implementierungsnäheren Artefakten. So könnenetwa zeitliche Vorgaben im Feindesign oder Codezumeist nicht wiedergegeben werden und entziehensich damit zumeist einer Prüfung auf Korrektheit.
Vollständigkeit nach obenVerwandt mit der korrekten Abbildung der An-forderungen im Modell ist die Frage nach derVollständigkeit der Abbildung aller Anforderungen.Da implementierungsnähere Modelle im Allge-meinen eine andere Sicht des Systems darstellenund einen wesentlich höheren Detaillierungsgradbeinhalten, werden zum Beispiel die Informationeneines Anforderungsmodells zumeist in mehrereEntwurfsmsodelle aufgeteilt. Umgekehrt stammendie in einem Entwurfsmodell zusammengefügtenInformationen ggf. aus mehreren Anforderungsmo-dellen. Daher ist die Vollständigkeit der Abbildungaller Modellinformationen zwischen zwei Ebenenkeine binäre Beziehung, sondern erfordert zumeistdie Betrachtung der Gesamtheit aller beteiligten Ar-tefakte der beiden Ebenen. Praktische Erfahrungenzeigen, dass von der Architektur über den Grob- undFeinentwurf zur Implementierung häufig eine rela-tiv schmale, wenn nicht eine 1:1-Beziehung zwischenden realisierenden Artefakten und den realisiertenArtefakten der Modellkette besteht. Demgegenüberist die Verwebung von der Anforderungsbeschrei-bung zur ersten Spezifikation/Architektur sehr breit.Das heißt, hier ist die Vollständigkeit nach oben nurdurch eine weitgehend globalisierte Betrachtung zuerkennen.
VerfolgbarkeitVerfolgbarkeit ist ein Maß für die Nachvollzieh-barkeit, welche Informationen von einem Modellan welchen Stellen zur Modellbildung in einernachfolgenden Entwicklungsaktivität eingesetztwurden. Verfolgbarkeit ist damit eine phasenüber-greifende Beziehung zwischen Modellen. Mittelsder Verfolgbarkeit lassen sich notwendige Ände-rungen zwischen den Artefakten verfolgen undsomit Aussagen bzgl. der Auswirkungen und desAufwands von Änderungen treffen. Beispielsweisekann bestimmt werden, welche Auswirkungen Än-derungen im Modell für die nachfolgenden Artefaktebedeuten. Verfolgbarkeit ist auch eine Grundlage fürdie Messung der als eigenständiges, aber verwandtesQualitätsattribut identifizierte ,,Vollständigkeit nachoben“.
ÄnderbarkeitÄnderbarkeit von Modellen ist in der heutigen,schnelllebigen Welt wichtig, um eine evolutionäreWeiterentwicklung des Systems zur Anpassung anneue Geschäftsziele und sich daraus ergebendeAnforderungen und neue Technologien zu ermög-lichen. Bei softwareintensiven Produkten spielt dieÄnderbarkeit der Software vor allem dann eineRolle, wenn eine weiterentwickelbare Produktlinielangfristig den Geschäftserfolg sichert. Änderbarkeitvon Software bedeutet immer auch Änderbar-keit der Modelle, die diese Software beschreiben.Änderbarkeit lässt sich in die Aspekte Wartbar-keit, Erweiterbarkeit und Wiederverwendbarkeitunterteilen.Die Wartbarkeit ist der Aufwand, der betrieben wer-den muss, um im Modell Fehler zu beheben, sowieSpezifikationsänderungen und -anpassungen zumodellieren. Die Erweiterbarkeit ist ein Maß für dieLeichtigkeit, mit dem das System erweitert werdenkann. Unsere Erfahrung zeigt, dass anders als beivielen Qualitätsattributen, die Erweiterbarkeit desSystems nicht notwendigerweise mit der Erweiter-barkeit der beschreibenden Modelle korreliert. DieseKorrelation ist nur dann gegeben, wenn das Systemaus den Modellen generiert wird. Wiederverwend-barkeit ist die Eigenschaft des Modells, für andereSysteme oder andere Varianten des Systems in einerProduktlinie wiederverwendet werden zu können.Durch Wiederverwendbarkeit sind im neuen Systemweniger Fehler zu erwarten, da das ursprünglicheModell bereits qualitätsgesichert wurde. Dadurchlassen sich deutliche Aufwände für die Modellierungund Qualitätssicherung einsparen.
Weitere QualitätsmerkmaleDer bisher diskutierte Katalog von Qualitäts-merkmalen erhebt nicht den Anspruch aufVollständigkeit, sondern soll und muss an projekt-und unternehmensspezifische Anforderungen an-gepasst werden. Weitere Kriterien können etwadie Transformierbarkeit oder die Prüfbarkeit sein.Transformierbarkeit des Modells einer Sprache inein implementierungsnäheres Modell einer anderenSprache ist zunächst eine Eigenschaft der Sprache,kann aber als Modelleigenschaft verstanden werden,wenn die Transformation auf einem bestimmtenSprachstil beruht. Oft können Transformatorennicht alle Sprachelemente bzw. alle Kombinationenvon Sprachelementen übersetzen.
420 Informatik_Spektrum_31_5_2008
Wie bei den Qualitätsmodellen schon ausge-führt, können nicht alle Qualitätsmerkmale gleichgut erfüllt werden, sondern es sind Priorisierungen,etwa über Gewichtungen, notwendig. Teilweise wi-dersprechen sich Qualitätsmerkmale auch. Ebensosind die einzelnen Merkmale nicht notwendiger-weise gegeneinander abgrenzbar, sondern könnensich bedingen oder ergänzen.
Qualitätsanforderungenan eine Modellierungsnotation
Eine Reihe von Anforderungen an einzelne Modellebzw. an miteinander in horizontaler oder vertikalerBeziehung stehenden Modellen steht in direktemZusammenhang mit den Sprachelementen, die eineModellierungssprache überhaupt anbietet und denwerkzeugbasierten oder manuellen Techniken, diefür die Sprache zur Verfügung stehen.
Dinge, die sich nicht ausdrücken lassen, kön-nen auch nicht analysiert oder entwickelt werden.Während für Programmiersprachen mittlerweileein gutes Verständnis darüber herrscht, welcheKonzepte eine Sprache im Kern und für eine Modu-larisierung braucht sowie welche Konzepte in eineBibliothek, ein Framework oder in vorgefertigteBausteine auszulagern sind, ist dies für Modellie-rungssprachen immer noch nicht gesichert. EineBetrachtung der UML zeigt, dass diese ein reichesSpektrum an Einzelnotationen für unterschiedlichePhasen und Sichten zur Verfügung stellt. Jedochwerden teilweise auch dieselben Notationen für un-terschiedliche Zwecke eingesetzt. Allen voran kanndas Klassendiagramm in der Analyse Gegenständeder realen Welt darstellen oder in der Implemen-tierung Klassen des realisierten Systems. Häufigerwerden Klassen auch zur statischen (!) Modellierungvon Vorgängen eingesetzt. Solche ,,Objektifizierung“findet bspw. statt, wenn Zustandsautomaten mit dembekannten State-Muster als Klassen repräsentiertwerden oder Vorgänge durch ,,Sachbearbeiter“ [17]oder Webservices als zustandslose Vorgangsobjekteumgesetzt werden.
Speziell für Modellierungssprachen ist aberdie Frage nach den richtigen, in der Sprache einge-setzten Konzepten und ihrer Semantik nicht gelöst.Gegenüber Programmiersprachen ist vor allem dasKonzept der gewollten, kontrollierten Unterspezi-fikation nur wenig beherrscht. Oft wird sogar dieMöglichkeit zur Unterspezifikation mit der Unge-nauigkeit der Bedeutung der Ausdrucksmittel einer
Sprache verwechselt und Formalität mit eindeutiger,ausführbarer und damit nicht zur Unterspezifikationfähiger Modellierungssprachen gleichgesetzt.
Viele der wesentlichsten Qualitätsanforderun-gen für eine Modellierungssprache lassen sich ausden Anforderungen für einzelne Modelle sowie denhorizontalen und vertikalen Beziehungen zwischenModellen ableiten. Dazu gehören etwa die Möglich-keit zur Vollständigkeit nach unten und oben, zurredundanzfreien bzw. kontrolliert redundanten Dar-stellung, zur Sicherung der Konsistenz, Kohärenz,Korrektheit, Verfolgbarkeit von Entscheidungen, etc.Zusätzlicher Beachtung bedürfen lediglich folgendeQualitätsattribute:
FormalisierungsgradEine Modellierungssprache kann vollständig forma-lisiert sein, halbformal oder völlig informell nutzbarsein. Typischerweise steigt der Grad der notwendi-gen Formalität einer Sprache in den späten Phaseneines Projekts an. Es ist also in Ordnung, Anforde-rungen in informellem Text, spezielle Algorithmenin Pseudo-Code oder Protokolle durch informelleAbläufe zu erklären und deren Strukturierungdurch Use-Cases- oder Pseudo-Architekturbildervorzunehmen. In der vertikalen Modellkette sollteaber der Grad der Formalisierung der Sprache nuransteigen – nie kleiner werden.
Nur bei adäquater Formalisierung könnenAnalyse, Simulation und Generierung genutzt sowieTracing von Modellbeziehungen und Anforderungenetabliert werden.
Adäquatheit für die AnwendungsdomäneSprachen wie die UML und ihre Teilsprachen sinddazu gedacht, allgemeingültig zu sein. Die aufkom-menden Domain Specific Languages (DSLs) [16]werden häufig ebenfalls zur Softwareentwicklungherangezogen. Sie bilden eine Anwendungsdomäne,die wesentlich spezifischer durch zur Verfügungstehende Sprachkonstrukte ist, ab. Dementspre-chend ist die Adäquatheit der Modellierungssprachefür die Anwendungsdomäne wichtig, da sonst um-ständliche Modellbildungen oder nicht darstellbareSachverhalte die Folge sind.
Teilaspekte sind hierbei die Verständlichkeitder Sprache für den Domänenexperten und denSE-Entwickler, die Kompaktheit der Modellie-rungssprache für eine Anwendungsdomäne, dieAngemessenheit der Modellierungselemente in
Informatik_Spektrum_31_5_2008 421
{ MODELLIERUNG
Bezug auf Komplexität, Parametrisierbarkeit, etc.sowie die Fähigkeit zur Repräsentation von Domä-nenwissen, Mustern oder Rahmenbedingungen fürden Einsatz. Abhängig von der Domäne müssenggf. sowohl funktionale als auch nichtfunktionaleEigenschaften dargestellt werden können.
Bewertung von Qualitätsanforderungenan Modelle
Während die Qualitätsanforderungen an eine Spra-che typischerweise nicht innerhalb eines Projekts,sondern a priori entschieden werden, ist es drin-gend geboten, die Qualitätsanforderungen aneinzelne Modelle effektiv bewerten zu können.Diese ,,Meta-“Qualitätsanforderung gilt gleichzeitigfür die gewählte Modellierungsnotation und diezur Verfügung stehende Werkzeuginfrastruktur.Ideal wären quantifizierte, automatisierte Verfah-ren zur Qualitätsbewertung, die aber bisher nurfür einzelne Qualitätsanforderungen in der Praxisumgesetzt werden: Für die QualitätsanforderungDarstellung bieten Ansätze wie [30] dem Entwicklerdie Möglichkeit, Modellierungsregeln individuellfestzulegen und automatisiert zu überprüfen. Fürdie Überprüfung der Korrektheit für funktionaleAnforderungen bieten sich formale Verifikationsme-thoden wie Model-Checking oder Theorembeweisenan, die aber ein hinreichend formales Entwurfsmo-dell und formalisierte Anforderungen voraussetzen.Auch für laufzeitrelevante, nichtfunktionale Anfor-derungen wie Performanz, Echtzeitverhalten oderEnergieverbrauch gibt es inzwischen Werkzeugun-terstützung für die Modellanalyse [28], die über eineModelltransformation an die Entwurfsmodellierungangebunden werden können [27]. Viele Qualitäts-kriterien für Modelle sind jedoch sehr schlechtdirekt messbar und benötigen eine Ersatzmessung,eine relative Messung über die Entwicklungszeitoder qualitative Befragungen, um Rückschlüsseauf das eigentliche Qualitätskriterium zu erhalten.Dazu gehören insbesondere herstellungsorientierteQualitätsanforderungen mit einer sehr langfristi-gen Perspektive wie Wartbarkeit, Flexibilität oderWiederverwendbarkeit.
Jedoch hängt der Automatisierungsgradvon Messkriterien sehr stark von der Form derSprachkonzepte ab. So sind etwa Erfüllbarkeit vonConstraints oder die Vollständigkeit von Automatenmit Vorbedingungen mit Formeln der Logik ersterStufe grundsätzlich nicht entscheidbar. Der Nach-
teil einer Restriktion der Sprache und damit desModellierungskomforts kann durch die automati-sierte Prüfbarkeit bzw. konstruktive Umsetzbarkeitauch nichtfunktionaler Anforderungen mehr alsaufgewogen sein, wie das Werkzeug Alloy [33] odersynchrone Sprachen [38] zeigen.
Über die genannten Qualitätskriterien hinausgibt es für Modellierungssprachen eine Anzahlweiterer, oft nur projektspezifisch einzusetzenderKriterien. Als allgemein gültiges Metakriteriumkann die für eine Notation zur Verfügung ste-hende Werkzeugunterstützung gesehen werden.Komfortable beziehungsweise effektive Werkzeug-unterstützung ist ggf. für verschiedenste Aufgabennotwendig. Dazu gehören Editor, geeignete Ver-sionskontrollmechanismen, die auch paralleleÄnderungen verschmelzen können, Analysatoreneinfacher und komplexer Kontextbedingungen,die Analyse in Bezug auf spezielle (meist nicht-funktionale) Anforderungen, ggf. Techniken zurValidierung und Verifikation bis hin zu Infrastruk-turen zu Simulation und Codegenerierung. DieseWerkzeuge müssen sowohl in einer Modellkette alsauch in einer heterogenen Sammlung horizontal inBeziehung stehender Modelle kompatibel sein. DieseMetaqualitätsanforderungen haben nicht direkt mitden Modellen zu tun und sind deshalb in diesemArtikel nicht weiter vertieft. Es ist jedoch evident,dass die Qualität von Modellen sich erst dann auf dieQualität der letztendlich zu entwickelnden Softwareüberträgt, wenn die qualitativ hochwertigen Mo-delle durch Werkzeuge adäquat umgesetzt werden.Dementsprechend ist eine adäquate Werkzeugin-frastruktur essenziell für die sinnvolle Nutzung vonModellen im Softwareentwicklungsprozess.
ZusammenfassungDieser Artikel gibt einen Überblick über den derzei-tigen Stand zur Frage, was Modellqualität ist und wieviel wir über die Beziehung zwischen Modellqualitätund Softwarequalität wissen. Allgemein anerkanntist, dass adäquate Modellbildung und Analyse derFähigkeiten des Modells sowie die Extrapolationdieser Eigenschaften auf das zu bildende Softwa-resystem einen deutlichen Qualitätsvorteil undPlanungssicherheit liefern können.
Weit unklarer ist die Antwort auf die Frage,wie viel Modellbildung unter Nutzung welcherModellierungssprachen für welche Arten von Pro-jekten adäquat ist. Diese Frage wird in der Praxis
422 Informatik_Spektrum_31_5_2008
gerade intensiv diskutiert, während sich die Wissen-schaft einer empirischen oder analytischen Klärungdieser Frage nur zaghaft nähert. Eine empirischeKlärung erscheint aufgrund der äußeren Rahmen-bedingungen (viele Einflusskriterien und dadurchunvergleichbare komplexe Softwareentwicklungs-projekte) schwer und aufgrund der immer nochhohen Veränderlichkeit der im Einsatz befindlichenSprachen auch von keinem dauerhaften Wert.
Dieser Artikel verzichtet aufgrund der vielenhöchst unterschiedlichen Modelltypen und ihrerEinsatzformen notwendigerweise auf eine detail-lierte und vollständige Auflistung von potenziellenQualitätskriterien. Viele davon wären auch nur sehrspezifisch für bestimmte Notationen zugänglich. Sosind in grafischen Modellen die zentralen Elementean den Lesebeginn zu legen, der sich jedoch z.B. beiAutomaten links oben und bei Klassendiagrammenleicht oberhalb der Mitte befindet (weil mehr Sub-klassen unterhalb als Oberklassen darüber liegen).Viele weitere solcher Kriterien sind für jede Spracheeinzeln zu identifizieren. Gegebenenfalls ändertsich mit der Expertise der Nutzer auch die Ästhetik.All diese Dinge sind empirisch nur wenig bis nichtuntersucht.
Dennoch werden weiter Untersuchungen zurModellqualität vorgenommen und insbesondereallgemeine, parametrisierbare Messwerkzeugegeschaffen, die individuell einstellbar verschiedeneMessungen vornehmen können. Wie schon DeMarcoausführte, verändert die Messung das Verhalten desProjektmitglieds. Deshalb sind Messungen vorsich-tig und zielgerichtet in ein Entwicklungsprojekt zuintegrieren.
Obwohl wir, wissenschaftlich gesehen, nurIndizien haben, welche ModellqualitätskriterienSW-Qualität implizieren und welche zu mehr Effek-tivität und/oder Prozessqualität beitragen, haltenwir derzeit die verstärkte und zielgerichtete Mes-sung zumindest für größere und geschäfts- odersicherheitskritische Softwaresysteme für gerechtfer-tigt. Einzelne Anwendungsdomänen, wie etwa dieFlugzeug- und die Automobilindustrie [21] habendamit bereits größere Erfolge erzielen können.
Wir wiederholen daher die von zahlreichenIndikatoren unterstützte Hypothese, dass zwischenModellqualität und Softwarequalität ein deutlicherZusammenhang existiert. Welche Qualitätseigen-schaften sich in welcher Form von Modell zumProdukt übertragen und welche dabei besonders re-
levant sind, muss allerdings eine größere empirischeWissensbasis noch präzisieren. Diese zu erstellen,wird in den nächsten Jahren eine wesentliche Auf-gabe der Wissenschaft in Zusammenarbeit mit dermodellbasiert entwickelnden Industrie sein.
Parallel dazu ist der Werkzeugbau, also dieautomatisierbare Messung und Bewertung vonQualitätsattributen sowie die Entwicklung geeig-neter Ersatzmessungen von nicht direkt messbarenQualitätskriterien voran zu bringen.
DanksagungWir danken Ruth Breu und Andy Schürr sehrherzlich für ihre konstruktiven Anmerkungen.
Literatur1. Ambler SW (2003) The elements of UML style. Cambridge University Press, Cam-
bridge2. Balzert H (1998) Lehrbuch der Software-Technik – Software-Management, Soft-
3. Basili VR, Rombach DH (1988) The tame project: Towards improvement-orientedsoftware environments. IEEE Trans Softw Eng 10(11):758–773
4. Bass L, Clements P, Kazman R (2003) Software architecture in practice, 2nd edn.Addison-Wesley, Boston
5. Basili V, Caldiera G, Rombach D (1994) Goal/Question/Metric Paradigm. In: Marci-niak JJ (ed) Encyclopedia of Software Engineering, Volume I. John Wiley & Sons,New York, S 528–532
6. Bansiya J, Davis CG (2002) A hierarchical model for object-oriented design qualityassessment. IEEE Trans Softw Eng 28(1):4–17
7. Baker P, Dai Z, Grabowski J, Haugen O, Schieferdecker I, Williams C (2007) Model-driven Testing. Using the UML testing profile. Springer, Berlin
8. Beucher O (2006) MATLAB und Simulink. Pearson Studium, München9. Briand LC, Morasca S, Basili VR (1999) Defining and validating measures for
object-based high-level design. IEEE Trans Softw Eng 25(5):722–74310. Briand LC, Morasca S, Basili VR (2002) An operational process for goal-driven de-
finition of measures. IEEE Trans Softw Eng 28(12):1106–112311. Buschmann F, Meunier R, Rohnert H, Sommerlad P, Stal M (1998) Patternorien-
tierte Softwarearchitektur. Addison-Wesley, München12. Bosch J (2000) Design & use of software architectures. Addison-Wesley, Oxford13. vom Brocke J (2003) Referenzmodellierung. Gestaltung und Verteilung von
Konstruktionsprozessen. Logos, Berlin14. Broy M, Rumpe B (2007) Modulare hierarchische Modellierung als Grundlage der
Software- und Systementwicklung. Informatik-Spektrum 30(1):3–1815. Becker J, Rosemann M, Schütte R (1995) Grundsätze ordnungsgemäßer Modellie-
München17. Denert E, Siedersleben J (1992) Software Engineering. Methodische Projektabwick-
lung. Springer, Berlin18. Dobrica L, Niemelä E (2002) A survey on software architecture analysis methods.
IEEE Trans Softw Eng 28(7):638–65319. EN 61508 (2000) Funktionale Sicherheit sicherheitsbezogener elektrischer/
elektronischer/programmierbarer elektronischer Systeme. Teil 1–7, IEC 6150820. Florentz B, Huhn M (2007) Architecture potential analysis. A closer look inside ar-
chitecture evaluation. J Softw 2(4):43–5621. Farkas T, Leicher A, Röbig H, Born M, Klein T, Zander-Nowicka J (2006) Werkzeug-
übergreifende Konsistenzsicherung von Artefakten bei der Entwicklung softwa-rebasierter Systeme im Automobil. In: Hochberger C, Liskowsky R (Hrsg) INFOR-MATIK 2006, 2.–6. Oktober 2006, Dresden. Lecture Notes in Informatics (LNI), GI-Edition
22. Frank U, Rumpe B (2006) Qualität konzeptueller Modelle. Workshop Modellierung2006, 21.–24. März 2006, Innsbruck
Informatik_Spektrum_31_5_2008 423
{ MODELLIERUNG
23. France R, Rumpe B (2007) Model-driven development of complex software: A re-search roadmap. In: Future of Software Engineering 2007 at ICSE, 26.–27. Mai2006, Minneapolis, S 37–54
24. Frankel D (2003) Model driven architecture. Wiley Publishing, Indianapolis25. Grönniger H, Krahn H, Rumpe B, Schindler M (2006) Integration von Modellen in
einen codebasierten Softwareentwicklungsprozess. In: Mayr HC, Breu R (Hrsg) Mo-dellierung 2006, 22.–24. März 2006, Innsbruck. Lecture Notes in Informatics (LNI),GI-Edition
26. Grönniger H, Krahn H, Rumpe B, Schindler M, Völkel S (2006) MontiCore 1.0 – EinFramework zur Erstellung und Verarbeitung domänenspezifischer Sprachen.Informatik-Bericht 2006-04, Technische Universität Braunschweig
27. Hagner M, Huhn M (2007) Modellierung und Analyse von Zeitanforderungen ba-sierend auf der UML. In: 5. GI-Workshop Automotive Software Engineering, GI-Jahrestagung 2007, 27. September 2007, Bremen
28. Henia R, Hamann A, Jersak M, Racu R, Richter K, Ernst R (2005) System level perfor-mance analysis the SymTA/S approach. IEE Proc Comp Digit Tech 152(2):148–166
29. Harel D, Rumpe B (2004) Meaningful modeling: What’s the semantics of ,,Seman-tics“? Computer 37(10):64–72
30. Huhn M, Braam J-C, Harms M, Horstmann M, Mutz M (2005) Structured hard-ware/software development for enhanced quality and safety in automotive sys-tems. Conference on Automation, Assistance and Embedded Real Time Platformsfor Transportation (AAET 2005) 16.–17. Februar 2005, Braunschweig, S 489–512
31. IEEE 1061-1998 (1998) IEEE standard for a software quality metrics methodology32. ISO/IEC 9126 (2001) Software engineering – product quality. International Stan-
darization Organization33. Jackson D (2002) Alloy: A lightweight object modelling notation. ACM Trans Softw
Eng Methodol (TOSEM’02) 11(2):256–29034. Krahn H, Rumpe B, Völkel S (2007) Roles in software development using domain
specific modeling languages. In: Proceedings of the 6th OOPSLA Workshop onDomain-Specific Modeling (DSM’ 06), 22. Oktober 2006, Portland, Oregon, USA
35. Ludewig J, Lichter H (2007) Software Engineering. dpunkt.verlag, Heidelberg36. Ludewig J (2002) Modelle im Software Engineering – eine Einführung und Kri-
tik. Modellierung 2002, 25.–27. März 2002, Tutzing. Lecture Notes in Informatics(LNI), GI-Edition, S 7–22
37. McCall J, Richards P, Walters G (1977) Factors in software quality, vol. 1–3. USRome Air Development Center Report, NTIS AD/A-049 014
38. Potop D, Edwards S, Berry G (2007) Compiling Esterel. Springer39. Pol M, Koomen T, Spillner A (2000) Management und Optimierung des Testpro-
zesses. dpunkt.verlag, Heidelberg40. Petrasch R, Meimberg O (2006) Modellgetriebene Software-Entwicklung – Eine
praxisorientierte Einführung. dpunkt.verlag, Heidelberg41. Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W (1991) Object-Oriented
Modelling and Design. Prentice Hall42. Reussner R, Hasselbrink W (2006) Handbuch der Softwarearchitektur.
d.punkt.verlag, Heidelberg43. Reißing R (2002) Bewertung der Qualität objektorientierter Entwürfe, Disserta-
tion, Universität Stuttgart44. Rumpe B (2004) Agile Modellierung mit UML – Codegenerierung, Testfälle, Re-
factoring. Springer, Heidelberg45. Rumpe B (2004) Modellierung mit UML – Sprache, Konzepte und Methodik.
Springer, Heidelberg46. Rumpe B (2004) Agile modeling with the UML. In: Wirsing M, Knapp A, Bal-
samo S (eds) Radical innovations of software and systems engineering in the fu-ture. 9th International Workshop, RISSEF 2002, 7.–11. Oktober 2002, Venice, Italy.LNCS 2941
47. Rumpe B (2006) Agile test-based modeling. In: Proceedings of the 2006 Interna-tional Conference on Software Engineering Research & Practice. SERP’2006, 26.–29. Juni 2006. CSREA Press, USA
48. Schütte R, Rotthowe T (1998) The guidelines of modelling as an approach to en-hance the quality of information models. In: Conceptual Modeling – ER ’98, 17thInternational ER-Conference, 3.–6. November 1997, S 240–254
49. Stachowiak H (1973) Allgemeine Modelltheorie. Springer, Wien50. Steinmann F (2005) Domain models are aspect free. In: MoDELS 2005, LNCS 3713.
Springer, Berlin, S 171–18551. Teeuw WB, v.d. Berg H (1997) On the quality of conceptual models. In: Procee-
dings of the ER’97 Workshop on Behavioral Models and Design Transformations:Issues and Opportunities in Conceptual Modeling, 6.–7. November 1997, Los An-geles, California
52. OMG Unified Modeling Language (OMG UML) (2007) Superstructure, V2.1.253. OMG Unified Modeling Language (OMG UML) (2007) Infrastructure, V2.1.254. Vogel O, Arnold I (2005) Software-Architektur. Spektrum Akademischer Verlag
Dr. Michaela Huhnentwickelt Methodenund Werkzeuge für denverbesserten Einsatzpragmatischer undformaler modell-basierter Technikenfür die effizienteEntwicklungeingebetteter Systeme.Angewendet werdendiese Technikendabei vor allem inden Bereichen Bahn,
Automobil und mobile Systeme.
Prof. Dr. BernhardRumpe leitet das In-stitut für SoftwareSystems Engineeringan der TechnischenUniversität Braun-schweig. Dort hat erein Forschungslaborzur modellbasiertenSoftwareentwicklungeingerichtet, das Mo-dellierungssprachen(DSLs) vor allem fürevolutionäre Softwa-
reentwicklung, Generierung und Konfiguration vonSoftwarearchitekturen und zur Qualitätssicherungeingebetteter Software einsetzbar macht. BernhardRumpe ist Autor mehrerer Bücher und Herausgeberdes Journal for Software and Systems Modelling(SoSyM).
![AnforderungsmAnAgement für geschäftsAnwendungen ein ... · Das klassische »Tire Swing Cartoon« in Abbildung 1 [Britt80] verdeutlicht die Notwendigkeit eines gemeinsamen Verständnisses](https://static.unterlagen.site/doc/80x56/5d4efe5288c993257d8b522a/anforderungsmanagement-fuer-geschaeftsanwendungen-ein-das-klassische-tire.jpg)
