Model Driven Architecture and Offshoring

Inhaltsverzeichnis

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

1 EINLEITUNG
1.1 Themenmotivation
1.2 Zielsetzung der Arbeit
1.3 Gliederung und Vorgehensweise

2 MODEL DRIVEN ARCHITECTURE
2.1 Problemstellung
2.2 Definition und Thesen
2.3 Umsetzung
2.3.1 Modellgedanken
2.3.2 Unified Modeling Language
2.3.3 Meta Object Facility und XML Metadata Interchange
2.3.4 UML-Profile
2.3.5 Object Constraint Language
2.3.6 Query/Views/Transformations
2.3.7 Modelltypen der Model Driven Architecture
2.3.8 Transformation
2.4 Einordnung und Einsatz
2.5 Wirtschaftlichkeit
2.6 Kritische Bewertung

3 OFFSHORE-ENTWICKLUNG
3.1 Problemstellung
3.2 Definition und Thesen
3.3 Umsetzung
3.3.1 Ziele
3.3.2 Besonderheiten und Risiken
3.3.3 Kommunikation
3.3.4 Organisationsstruktur und Vertragstypen
3.3.5 Projektorganisation und Projektcontrolling
3.3.6 Capability Maturity Model Integration
3.4 Einordnung und Einsatz
3.5 Wirtschaftlichkeit
3.5.1 Business Case und Total Cost of Offshoring
3.5.2 Personalkosten
3.5.3 Langfristige ökonomische Auswirkungen
3.6 Kritische Bewertung

4 MODELLBASIERTE OFFSHORE-ENTWICKLUNG
4.1 Problemstellung
4.2 Definition und Thesen
4.3 Umsetzung
4.3.1 Kontrolle der Wertschöpfungskette
4.3.2 Qualitätssteigerung
4.3.3 Projektgestaltung
4.3.4 Projektorganisation
4.3.5 Projektvorgehen
4.4 Einordnung und Einsatz
4.5 Wirtschaftlichkeit
4.6 Kritische Bewertung

5 EVALUATION PRAXISPROJEKT
5.1 Software-Entwicklungsumgebung
5.2 Referenzmodell Enterprise Architect
5.3 Modellierung
5.3.1 Computation Independent Model
5.3.2 Platform Independent Model
5.3.3 Platform Specific Model
5.4 Code-Generierung
5.5 Kritische Bewertung

6 SCHLUSSBETRACHTUNG
6.1 Zusammenfassung
6.2 Ausblick

ANHANG

Anhang A: Übersicht MDD-Werkzeuge

Anhang B: Experten Interview T-Systems

LITERATURVERZEICHNIS

Abbildungsverzeichnis

Abbildung 1: Logo Model Driven Architecture

Abbildung 2: Beispiel OCL-Ausdruck

Abbildung 3: Modelle im MDA-Prozess

Abbildung 4: PIM - PSM - Code

Abbildung 5: Evolution der Softwareentwicklung

Abbildung 6: Verwendete Techniken und MDD-Software

Abbildung 7: Projektmodell Software Engineering

Abbildung 8: Aufwand bei modellgetriebener Softwareentwicklung

Abbildung 9: Aufteilung Client-Onsite-Offshore Aktivitäten

Abbildung 10: Hofstede Vergleich Deutschland - Indien

Abbildung 11: Media richness

Abbildung 12: Offshore Projektorganisation

Abbildung 13: CMMI-Modell

Abbildung 14: Direkte und versteckte Kosten beim Offshoring

Abbildung 15: Offshore Konfliktbeziehung

Abbildung 16: Wertschöpfungskette der MDA

Abbildung 17: Steuerung des Offshore-Spannungsfelds

Abbildung 18: MDO-Szenarien im Überblick

Abbildung 19: Verteilung Aktivitäten Fallstudie TSS

Abbildung 20: Exemplarisches MDO-Vorgehen

Abbildung 21: Kosten der Fehlerbehebung

Abbildung 22: Referenzmodell Enterprise Architect

Abbildung 23: Use Case Model

Abbildung 24: Business Model

Abbildung 25: Abstract Class Model (PIM)

Abbildung 26: Java Implementation Model (PSM)

Abbildung 27: WSDL Model (PSM)

Abbildung 28: Quellcode Beispiel

Abbildung 29: Anzeige der Modell Abhängigkeiten

Abbildung 30: Industrialisierung der Software-Branche

Tabellenverzeichnis

Tabelle 1: Thesen zur MDA

Tabelle 2: Verteilung des Aufwands bei der Softwareentwicklung

Tabelle 3: Kriterien für die Bewertung der MDA

Tabelle 4: Bewertung der Thesen zur MDA

Tabelle 5: Thesen zum Offshoring

Tabelle 6: Dimensionen nationaler Kulturen nach Hofstede

Tabelle 7: Vertragsarten einer Offshore-Beziehung

Tabelle 8: Kontrollmechanismen Projektcontrolling

Tabelle 9: Generationen des Outsourcing

Tabelle 10: Kostenkomponenten Offshore

Tabelle 11: IT-Jahresgehälter in Euro

Tabelle 12: Bewertung der Thesen zur Offshore-Entwicklung

Tabelle 13: Wiederholung von Schwächen und Risiken

Tabelle 14: Verbreitung der modellbasierten Offshore-Entwicklung

Tabelle 15: Thesen zur modellbasierten Offshore-Entwicklung

Tabelle 16: Bewertung der Thesen zur modellbasierten Offshore-Entwicklung

Tabelle 17: Software-Entwicklungsumgebung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In der Einleitung wird das Forschungsgebiet dieser Arbeit vorgestellt und die Motivation für das Thema erläutert. Es schließen sich Zielsetzung und Aufbau der Arbeit an. Zu Beginn eines jeden Hauptkapitels wird die oben rechts abgebildete Übersicht mit dem aktuell beschriebenen Abschnitt der Arbeit dargestellt. Die Abbildung soll als Leitfaden und Orientierungshilfe zu den behandelten Inhalten dienen.

1.1 Themenmotivation

Die Software-Industrie hat, trotz steigendem Bedarf an IT gestützten Geschäfts-prozessen, die versprochenen großen Sprünge aus der vor Jahrzehnten ausgerufenen Software-Krise bisher nicht bewältigen können. Kleine Schritte zur Steigerung der Effizienz, Effektivität und Produktivität sind durch den Einsatz von Standards, Frameworks sowie modernen Entwicklungsumgebungen erreicht worden. Software-lösungen werden jedoch immer komplexer, die Ansprüche an ihre Leistungsfähigkeit, Zuverlässigkeit, Sicherheit und Skalierbarkeit steigen kontinuierlich an. Die Prozesse laufen nicht mehr nur auf der eigenen Unternehmensplattform, sondern interagieren mit Systemen anderer Unternehmen in serviceorientierten Architekturen. Es sind daher maßgeschneiderte IT-Lösungen zur Befriedigung der individuellen Bedürfnisse nötig und dies zunehmend auch für kleine und mittelständische Unternehmen.¹

Die Globalisierung, teilweise durch die Software-Industrie selbst hervorgerufen, führt zu einem weltweit wachsenden Wettbewerb². Offshore-Dienstleister gewinnen an Bedeutung und sind inzwischen nicht mehr nur als Unterauftragnehmer für klar spezi-fizierte Aufgaben, sondern zunehmend auch als Konkurrenz bei der Herstellung spezialisierter Softwarelösungen zu sehen.

„Immer öfter gewinnen spezialisierte Offshorer auch in diesem Bereich gegen Dienst-leister aus der alten Welt ... Die westliche IT-Industrie ist auch hier überrumpelt worden. Über die Hälfte aller CMM5-zertifizierten Unternehmen kommt mittlerweile aus Indien“³.

Zu diesem Ergebnis kommt auch das Forschungsprojekt Export IT des Instituts für sozialwissenschaftliche Forschung e. V. München:

„Um das Vertrauen westlicher Unternehmen zu gewinnen und ihre Marktposition zu verbessern ... [sind] heute alle großen indischen IT-Dienstleister nach hochwertigen Qualitätsstandards wie CMM Level 5 zertifiziert“⁴.

Um auf dem Markt wettbewerbsfähig zu bleiben, spielen die Beschleunigung und Verbesserung des Entwicklungsprozesses eine ebenso wichtige Rolle, wie die Kosten-senkung der Entwicklung selbst. Eine Studie von A. T. Kearney der Top 500 Industrie-unternehmen in Deutschland besagt, dass bis 2011 im Bereich des IT-Offshoring voraussichtlich 20 bis 40 Prozent der Aufgaben in Niedriglohnländer verlagert werden⁵. Speziell beim Offshoring ergeben sich nach einer Studie der Gartner Gruppe fünf besonders schwerwiegende Probleme:⁶

- Verfehlen der Kosteneinsparungsziele
- Qualitätsprobleme
- Kulturelle Unterschiede und Kommunikationsprobleme
- Rechtliche Probleme
- Verlust der Kontrolle

Die zunehmende Komplexität erfordert die Hinterfragung, möglicherweise sogar die Abkehr vom klassischen Phasen- bzw. Wasserfallmodell hin zu einem stärker agilen und iterativen Vorgehen. In Verbindung mit Offshore führt dies zu weiteren Problemen und Risiken. Für diese Herausforderungen und bekannten Probleme im Offshoring sind innovative Konzepte zur Optimierung der Wertschöpfungskette in der Software-Industrie nötig. Im Endeffekt werden die IT-Unternehmen, wie in anderen Industrie-bereichen bereits durchgeführt, eine Standardisierung, Spezialisierung und Automatisierung anstreben.⁷ Als Vorbild ist hier die Automobilbranche zu sehen. In dieser ist der Anteil der Eigenerstellung mit nur circa 25 Prozent schon stark optimiert. Die Software-Branche steht erst noch am Anfang der Industrialisierung ihrer Fertigung⁸.

Die zukünftige Softwareentwicklung ist aus diesem Grund architekturzentriert, aspekt-orientiert, domänenspezifisch und modellgetrieben zu gestalten⁹. Eine Vorgehensweise ist der Einsatz der Model Driven Architecture (MDA), ein Standard der Object Management Group (OMG) zur automatischen Generierung von Softwaresystemen. Bei diesem Konzept bilden Modelle mit der Geschäftslogik den Schwerpunkt des Entwicklungsprozesses und nicht die Umsetzung auf eine konkrete Plattform. Das fertige Softwareprodukt soll durch geeignete Transformation möglichst automatisch aus den fachlichen Modellen erstellt werden können. Die OMG propagiert im Zusammen-hang mit MDA Schlagworte wie Portierbarkeit, Interoperabilität, Wiederverwendbarkeit sowie eine effiziente Softwareentwicklung und Domänen-Orientierung.¹⁰

Obwohl die MDA seit dem Jahr 2000 als Hoffnungsträger zur Erreichung der Ziele gilt, ist der praktische Einsatz für viele Unternehmen heute noch keine Realität. Gerade im Bereich der automatischen Codegenerierung und Kostensenkung sind noch Lücken zu schließen. Der Einsatz von Modellen und die Modellierung mithilfe der Unified Modeling Language (UML) sind inzwischen weit verbreitet. Eine aktuelle Forrester Studie zum Model Driven Development sagt aus, dass 57 Prozent der Befragten von sich behaupten, in gewisser Art und Weise zu modellieren¹¹.

In Verbindung mit dem durch das Management oder durch den Auftraggeber geforderte Offshoring zur Kostensenkung sehen viele Unternehmen einen Widerspruch und die modellgetriebene Entwicklung als unnötigen Overhead. Auch Diskussionen wie „Code-Generierung vs. Offshore“ sind in Artikeln sowie Foren zu finden.

In den zwei Themenkomplexen Model Driven Architecture und Offshore ergeben sich viele Forschungs- und Studienbereiche, welche in der Vergangenheit schon zahlreich behandelt worden sind. Beide Konzepte wurden dabei vorwiegend separat betrachtet oder in Konkurrenz zueinander gesehen. Ein für eine wissenschaftliche Betrachtung interessanter Ansatz zur Verringerung der Risiken und Optimierung der Wert-schöpfungskette, gerade im Bereich der Entwicklung von Individualsoftware, könnte aber in der Kombination von MDA und Offshoring, dem sogenannten Model Driven Offshoring (MDO), liegen.

Über die rein theoretische Betrachtung der beiden Bereiche hinaus ist zusätzlich eine Untersuchung der vorhandenen softwaretechnischen Unterstützungen in diesem Gebiet sinnvoll.

1.2 Zielsetzung der Arbeit

Ziel der Arbeit ist die Darstellung und Bewertung aktueller Methoden und Vorgehens-weisen im Bereich der Softwareentwicklung im Allgemeinen und der modellbasierten Offshore-Entwicklung im Speziellen. Der Schwerpunkt liegt dabei in der Darstellung einer flexiblen Kombination von Automatisierung und dem Einsatz von Offshore-Ressourcen.

Weiterhin wird das Potenzial und die Praxistauglichkeit der modellbasierten Offshore-Entwicklung analysiert sowie ein praktikabler Weg für ein kleineres Projekt aufgezeigt. Eine Software-Evaluierung wird im Rahmen dieser Arbeit nicht möglich sein. Alternativ wird im Praxisteil dargestellt, inwieweit das Konzept heute schon mit dem Modellierungswerkzeug Enterprise Architect (EA) von Sparx Systems umgesetzt werden kann. Als ein Ergebnis dieser Arbeit steht das Referenzmodell des EA als Ausgangsbasis für zukünftige Projekte bei T-Systems zur Verfügung. Zielgruppe, besonders für diesen Teil, sind IT-Architekten und Projektleiter sowie interessierte Entwickler, die noch am Anfang des Veränderungsprozesses stehen.

1.3 Gliederung und Vorgehensweise

Neben dem einleitenden Teil in diesem Kapitel und der Schlussbetrachtung in Kapitel 6 ist die Arbeit in zwei Teile, einen theoretisch-wissenschaftlichen und einen praktischen Teil untergliedert. Dabei stellen Kapitel 2 bis 4 die nötigen theoretischen Grundlagen für die Darstellung der praktischen Umsetzung in Kapitel 5 vor. In Kapitel 2 wird das Konzept der MDA dargestellt und im darauffolgenden das Thema der allgemeinen Offshore-Entwicklung. Anschließend werden in Kapitel 4 die Erkenntnisse in dem Ansatz zur modellbasierten Offshore-Entwicklung zusammengeführt.

Die Strukturierung der theoretischen Kapitel orientiert sich an folgendem Schema:

1. Problemstellung
2. Definition und Thesen
3. Umsetzung
4. Einordnung und Einsatz
5. Wirtschaftlichkeit
6. Kritische Bewertung

Die einheitliche Unterstruktur soll dem Leser einen systematischen Überblick über die drei Konzepte ermöglichen und der Lesbarkeit im Hauptteil dienen. Zur thematischen Eingrenzung der einzelnen Hauptkapitel werden jeweils im Abschnitt „Definition und Thesen“ die Kernaussagen und Versprechen der Konzepte aufgeführt.

Den praktischen Teil dieser Arbeit bildet Kapitel 5 „Evaluation Praxisprojekt“. In diesem wird das entwickelte Konzept der modellbasierten Offshore-Entwicklung mithilfe des EA als Referenzprojekt umgesetzt. Hierzu wird erst die softwaretechnische Umgebung sowie das zu lösende Praxisproblem vorgestellt. Anschließend erfolgt die Modellierung auf den einzelnen Abstraktionsebenen und soweit möglich, die automatische Generierung von dem Quelltext.

Abschließend werden in Kapitel 6 die behandelten Inhalte zusammengefasst und der Ausblick auf eine weiterführende Arbeit gegeben.

2 Model Driven Architecture

Abbildung in dieser Leseprobe nicht enthalten

Im folgenden Teil dieser Arbeit wird das Gebiet der modellgetriebenen Softwareentwicklung behandelt und in diesem Zusammenhang speziell die Standardisierungsinitiative zum MDA-Konzept hervorgehoben. Das Vorgehen orientiert sich an dem in Abschnitt 1.3 aufgeführtem Schema. Es wird zuerst die Problemstellung skizziert und danach die Definition der MDA sowie die zu behandelnden Thesen vorgestellt. Anschließend werden in Abschnitt 2.3 wichtige Standards, die technische Umsetzung sowie die Kernkomponenten behandelt. Die Einordnung in den historischen Verlauf der Softwareentwicklung und der heutige Einsatz sind Bestandteil von Abschnitt 2.4. Die im Rahmen dieser Arbeit mögliche wirtschaftliche Analyse wird im Abschnitt 2.5 behandelt. Abschließend erfolgt die kritische Bewertung der MDA.

2.1 Problemstellung

Bevor die Theorie der modellgetriebenen Softwareentwicklung behandelt wird, soll an dieser Stelle die damit verbundene Problemstellung charakterisiert werden. Die OMG beschreibt den Missstand der Softwareentwicklung mit dem Satz:

„...if we built buildings the way we built software, we would be unable to connect, change or even redecorate them and worse, they would constantly be failing down“¹².

Im Detail stehen dem steigenden Bedarf an Softwarelösungen die nachstehenden Herausforderungen gegenüber:¹³

- steigende Komplexität und gleichzeitige Kostensenkung
- hohe Anforderungen an Leistungsfähigkeit, Zuverlässigkeit und Qualität
- kurze Technologiezyklen der Hardware- und Software-Plattformen
- agile Vorgehensmodelle mit häufigen Anforderungsänderungen

Der modellgetriebene Ansatz wird von der Fachwelt als Lösung für diese Probleme diskutiert und auch evolutionär als der „nächste Schritt“ in der Softwareentwicklung gesehen (siehe Abschnitt 2.4).

2.2 Definition und Thesen

- Definition

Als Grundlage für die weiteren Ausführungen wird auf die Definition der MDA, wie sie die OMG publiziert, zurückgegriffen.

Abbildung in dieser Leseprobe nicht enthalten

„OMG’s Model-Driven Architecture .. provides an open, vendor-neutral approach to the challenge of business and technology change. Based on OMG’s established standards, the MDA separates business and application logic from underlying platform technology. Platform-independent models of an application .. can be realized through the MDA on virtually any platform .. These platform-independent models document the business functionality .. separate from the technology-specific code .. ”¹⁴.

Neben der OMG-Definition existieren in der Literatur weitere technische Abwand-lungen, welche aber in der Substanz die gleichen Inhalte behandeln.¹⁵

- Thesen

Die zu untersuchenden Thesen für den Bereich der MDA sind in Tabelle 1 aufgeführt. Neben dieser Auswahl existieren weitere Behauptungen über die Vorteilhaftigkeit der MDA, die aber für das angestrebte Offshoring von untergeordneter Bedeutung sind.

Durch Model Driven Architecture wird die Produktivität und Wiederverwendbarkeit des Entwicklungsprozesses gesteigert.

Model Driven Architecture leistet durch das Arbeiten auf unterschiedlichen Abstraktionsebenen einen wesentlichen Beitrag zur Optimierung und Kontrolle der Wertschöpfungskette von Individualsoftware.

Der MDA-Ansatz ist optimal für ein iterativ inkrementelles Vorgehensmodell geeignet und verhindert das Auseinanderlaufen von Modell und Code.

2.3 Umsetzung

Model Driven Architecture ist ein Framework, das die Ideen der modellbasierten Softwareentwicklung aufgreift, dabei aber auf die durch die OMG schon verbreiteten und etablierten Standards, wie zum Beispiel die Unified Modeling Language (UML), setzt. In der Literatur wird auch von der OMG-Implementierung des Model Driven Software Development gesprochen¹⁶. Nach Spezifikation der OMG ist der Kern-gedanke die ganzheitliche und aufeinander aufbauende Verwendung von Modellen während des Entwicklungsprozesses. Die Repräsentation von Software soll von der Programmcodeebene auf die Modellebene angehoben werden. In Verbindung mit dem Grundsatz zur Trennung von Fachlichkeit und technischer Umsetzung bietet die MDA einen Ansatz zur Komplexitätsreduktion bzw. Abstrahierung. Durch die Trennung von Verantwortlichkeiten soll schließlich die Portabilität, Interoperabilität und Wiederver-wertbarkeit gewährleistet werden.¹⁷

In der nachstehenden Abbildung ist das Logo der MDA mit den Kernelementen und Einsatzgebieten dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Logo Model Driven Architecture¹⁸

In der inneren Schicht sind die drei wichtigsten Modellierungsstandards, die UML, die Meta Object Facility (MOF) und das Common Warehouse Metamodell (CWM), angesiedelt. Darüber hinaus sind die Object Constraint Language (OCL) und die UML-Profile als weitere Konzepte innerhalb der MDA zu nennen. Die möglichen Zielplattformen sind in der zweiten Schicht dargestellt, wodurch die Trennung von Modellen und plattformabhängiger Implementierung verdeutlicht wird. Als Besonderheit in dieser Schicht ist der XML Interchange (XMI) Standard zu nennen, der als Plattform für den Austausch von Modellen sowie Metamodellen benutzt wird. Im äußeren Ring werden weitverbreitete bzw. durchdringende Dienste (engl. Pervasive Services), welche zusammen mit der MDA verwendet werden können, aufgeführt. Die Einsatz-gebiete werden über die äußeren Pfeile veranschaulicht.¹⁹

An dieser Stelle ist zu erwähnen, dass die OMG bis heute keine Spezifikation zur MDA veröffentlicht hat. Die Dokumente „Model Driven Architecture - A Technical Perspective“ (veröffentlicht 2001), „MDA Guide Version 1.0.1“ (veröffentlicht 2003) und ein Präsentationspapier „MDA Foundation Model“ (veröffentlicht 2005) bilden aktuell die textuelle Basis für eine erwartete Spezifikation.

2.3.1 Modellgedanken

Modelle spielen bei dem Paradigma der MDA die zentrale und treibende Rolle. Sie helfen bei dem Prinzip der Abstraktion und sind in der Lage komplexe Sachverhalte kompakt darzustellen. In den Phasen Definition, Analyse und Entwurf werden Modelle heute schon verwendet. Der methodische Bruch zwischen Design und Realisierung führt jedoch weiterhin zu Folgekosten im Bereich von Schulung und Wartung. Neue Anforderungen oder Änderungen im Quellcode müssen in den Modellen manuell nachgebessert werden. Dies führt oft zu Inkonsistenzen und einer fehlerhaften Dokumentation des Systems. Im Bereich des Requirements Engineering ist durch diesen Umstand die Nachvollziehbarkeit bzw. Rückverfolgbarkeit von Anforderungen nicht gegeben. Untersuchungen der aktuell angewandten Praxis von Guttman und Parodi lassen aber auf einen ganzheitlichen Einsatz von Modellen über den gesamten Software-Lebenszyklus von der initialen Definition bis hin zur Wartung hoffen²⁰.

2.3.2 Unified Modeling Language

Die formelle und eindeutige Beschreibung von Modellen ist eine wichtige Voraussetzung für die Automatisierung²¹. Modellierungs-sprachen müssen zu diesem Zweck eine definierte Syntax und Semantik besitzen, also deterministisch auswertbar sein. Zusätzlich muss die Möglichkeit existieren, die Sprache an unterschiedliche Einsatzgebiete sowie Domänen anpassen zu können. Dabei darf jedoch die Verständ-lichkeit der Darstellung nicht verloren gehen.²²

Von der OMG wird der Einsatz der UML als Modellierungssprache im Rahmen der MDA empfohlen. Dieser ebenfalls von der OMG spezifizierte Standard ermöglicht die visuelle Modellierung, Konstruktion und Dokumentation von Softwaresystemen. Die UML ermöglicht die Spezifikation von Systemen unabhängig von Fach- oder Spezial-gebieten auf Basis von Standardkonstrukten. Von Vorteil sind Verbreitung und Akzeptanz dieses Standards sowie die aktuellen Anpassungen in Version 2.0 zur weiteren Unterstützung des MDA Gedankens²³. Die Verzahnung der beiden Standards wird im Anhang B des OMG-Dokuments „OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2“ deutlich. Dort wird beschrieben, wie mithilfe der UML die Kerngedanken der MDA umgesetzt werden können und dass die unterschiedlichen Modelltypen der MDA (siehe Abschnitt 2.3.7) unterstützt werden.²⁴

Stahl, Völter, Efftinge und Haase bestätigen diese Entwicklung, indem sie viele Probleme vorheriger UML Versionen im Zusammenspiel mit der MDA durch Version 2.0 verbessert sehen.²⁵

2.3.3 Meta Object Facility und XML Metadata Interchange

Abbildung in dieser Leseprobe nicht enthalten

Die MOF ist die formale Basis für die Definition von Meta-modellen und dient vielen MDA-Werkzeugen als Grundlage für Konstruktion sowie Integration. Die Mechanismen der MOF dienen der Definition und Manipulation von eigenen Domain Specific Languages (DSL) oder von Metamodellen, wie zum Beispiel dem UML-Metamodell. Des Weiteren ist für die Transformation eine gemeinsame Meta-Metaebene nötig, um automatische Überführungen von Modellen zu ermöglichen²⁶. Die MOF wird mithilfe der UML-Syntax beschrieben und die UML ihrerseits durch die MOF definiert. Als Beispiel für diese Eigenschaft kann man die deutsche Sprache heranziehen, die sich auch durch sich selbst definiert. In der MOF werden vier Metalevel unterschieden. Die MOF ist das Urmodell und bildet die höchste Abstrak-tionsstufe, da alle anderen Modelle auf ihr basieren.²⁷ Die aktuelle Spezifikation „Meta Object Facility (MOF) Core Specification“ in Version 2.0 ist im Januar 2006 veröffent-licht worden²⁸.

Im Zusammenhang mit MOF und der Portierbarkeit von Modellen ist der XML Metadata Interchange Standard zu sehen. Seine Aufgabe ist es, die Austauschbarkeit von Modellen zwischen unterschiedlichen MDA-Werkzeugen zu gewährleisten und so die Integration der Werkzeuge verschiedener Hersteller im MDA-Entwicklungsprozess zu ermöglichen. Der Standard definiert das Mapping der MOF-Strukturen auf das Dateiformat der eXtensible Markup Language (XML). Realisiert wird das Mapping über die Serialisierung von einem MOF-basierten Meta-modell. Hierbei sind bestimmte Regeln zur Erstellung eines XML-Schemas zu berück-sichtigen.²⁹ Die aktuelle Spezifikation „MOF 2.0/XMI Mapping“ ist in Version 2.1.1 im Dezember 2007 veröffentlicht worden³⁰.

2.3.4 UML-Profile

Im Zusammenhang mit der UML dienen Profile dazu, eine bestimmte Menge an wohldefinierten Änderungen an einem bestehenden Metamodell durchzuführen. Das Konzept der UML-Profile erlaubt es, die Semantik bestimmter Sprachkonstrukte an spezifische Einsatzbedingungen anzupassen. UML-Profile dienen nicht nur der Einschränkung und Erweiterung des UML-Metamodells, sondern bilden auch die Grundlage für die automatische Modelltransformation. Zum Beispiel des plattform- unabhängigen in das plattformspezifische Modell. Hierzu werden drei Mechanismen der UML-Infrastructure verwendet:³¹

- Stereotypen (spezielle Klassen zur Detaillierung)
- Tagged Values (Eigenschaftswerte)
- Constraints (Einschränkungen)

2.3.5 Object Constraint Language

OCL, ein weiterer Standard der OMG, ist eine streng typisierte formale Sprache zur textuellen Ergänzung der grafischen UML-Modelle. Dies ist nötig, da UML-Modelle allein nicht die nötige Exaktheit besitzen, um ein System vollständig zu beschreiben. Zur Detaillierung können Bedingungen (engl. Constraints) oder vollwertige Ausdrücke (engl. Expressions) an die UML-Elemente angefügt werden. Die Ausdrücke spezi-fizieren typischerweise konstante Bedingungen, die zum Beispiel während einer Transformation erfüllt sein müssen. Die OCL hat rein deklarativen Charakter und ist keine übliche Programmiersprache. Es können keine Veränderungen am Modell während der Auswertung entstehen oder Abläufe mithilfe der OCL modelliert werden.³² Das abgebildete Klassendiagramm zeigt einen OCL-Ausdruck vom Typ Invariante.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Beispiel OCL-Ausdruck

Die OCL basiert auf den mathematischen Konzepten der Mengenlehre und Prädikatenlogik. In der textuellen Beschreibung der OCL-Ausdrücke wird die mathe-matische Symbolschrift verwendet (siehe Abbildung 2).³³ In der OCL-Spezifikation sind, neben der Verwendung als Invariante, weitere Einsatzmöglichkeiten aufgeführt, die aber im Rahmen dieser Arbeit nicht verwendet werden.

2.3.6 Query/Views/Transformations

Mithilfe der vorhandenen Standards im Bereich der Modellierung können Systeme grafisch durch Modelle repräsentiert und spezifiziert werden. Neben der visuellen Darstellung ist die weitere Verarbeitung bzw. Transformation entscheidend, um die Ziele der MDA verwirklichen zu können. Hier kommt der im April 2008 veröffentlichte QVT-Standard zum Einsatz. Der Standard spezifiziert drei (Programmier-)Sprachen für die Modell-zu-Modell (M2M) Transformation und gehört in den Kreis der MOF-Spezi-fikationen. Es gibt mit der Relations- und Core-Sprache zwei deklarative und mit der Operational-Mappings-Sprache eine imperative Möglichkeit zur Beschreibung von Transformationen. QVT-Transformationen setzen auf den MOF konformen Meta-modellen der jeweiligen Quell- und Zielmodelle auf. Die drei Sprachen erlauben Abbildungen auf die einzelnen Elementtypen der Metamodelle zu definieren, wie zum Beispiel eine Abbildung der Form, dass alle Elemente vom Typ EntityType aus einem ER-Modell auf je ein Element vom Typ Klasse im Klassenmodell transformiert werden.³⁴ Für die weiteren Details der einzelnen Sprachen wird an dieser Stelle auf die umfangreiche Spezifikation der QVT verwiesen³⁵.

Die M2M-Transformation ermöglicht keine Codegenerierung. Hierzu – also der Modell-zu-Text (M2T) Transformation – gibt es einen weiteren erst kürzlich veröffentlichten Standard mit dem Titel „MOF Model to Text Transformation Language“ (MOFM2T). Der Ansatz zur Erzeugung einer Textdarstellung basiert dabei auf der Verwendung von Templates. Innerhalb der Templates sind Platzhalter in Form von Ausdrücken definiert. Diese Ausdrücke werden dann bei der Transformation über Abfragen mit den Daten aus den Modellen gefüllt. Die Bezeichnung einer Klasse wird zum Beispiel über den Ausdruck „class [c.name/]“ aus dem Modell extrahiert.³⁶

Beide Standards sind entscheidend, um die Ziele der MDA im Bereich der Auto-matisierung und Effizienzsteigerung verwirklichen zu können. Die Softwarehersteller sind nun gefordert, die Standards entsprechend in ihre Software zu integrieren. In der zugrunde liegenden Literatur wird dieses Vorhaben jedoch kritisch gesehen und darauf verwiesen, dass die QVT-Spezifikation ein sehr komplexes und zahllosen Revisionen unterworfenes Dokument ist. Weiter führt das Fehlen einer einzigen und standar-disierten QVT-Sprache zu einer schlechten Akzeptanz und Verbreitung im Markt. Inzwischen existieren eine Reihe von Softwarelösungen, darunter auch der EA, mit denen sich Transformationen durchführen lassen. Die Beurteilung, ob und wie der QVT-Standard umgesetzt wurde, ist aber ohne Einblick in den Quellcode schwierig.³⁷

2.3.7 Modelltypen der Model Driven Architecture

Im Rahmen der MDA werden drei Arten von Modellen unterschieden,

- das Computation Independent Model (CIM),
- das Platform Independent Model (PIM) und
- das Platform Specific Model (PSM).

Die Trennung in mehrere Modelle soll nach Ansicht der OMG helfen die Hauptziele Portabilität, Interoperabilität und Wiederverwendbarkeit zu erreichen. Indem die Spezi-fikation eines Systems von der technischen Realisierung getrennt wird und dann „nach und nach“ mit den technischen Details angereichert wird.³⁸

Das CIM ist der Modelltyp mit der höchsten Abstraktionsstufe und dient der Erfassung geschäftlicher Aspekte wie Anforderungen, Geschäftsprozesse oder System-umgebung. Es wird in der Notation der Business Domäne erstellt und kann deshalb nicht in den technischen Rahmen der MDA (Transformation) miteinbezogen werden. In den technischen Betrachtungen der MDA spielt es deshalb eine untergeordnete Rolle. Da es jedoch für den gesamten Entwicklungsprozess wichtige Informationen für alle Beteiligte enthält, wird es in den nachfolgenden Ausführungen mitbehandelt.³⁹

Im MDA-Standard wird neben den konkreten Modellen zudem eine abstrakte Ebene, die sogenannten Viewpoints, unterschieden. Die unterschiedlichen Viewpoints be-schreiben das System aus einer festgelegten Sichtweise und dienen dem theoretischen Konzept der Abstraktion. Sie enthalten, zur Eingrenzung der Problem-domäne, die strukturellen und architektonischen Aspekte der einzelnen Modelle.⁴⁰

In Abbildung 3 wird dieser komplexe Sachverhalt und der Lebenszyklus der MDA-Modelle veranschaulicht. Diese ist eine Zusammenführung der Darstellungen von Gruhn, Piper und Röttgers sowie einer Veröffentlichung von Si Alhir in Methods&Tools. Zudem werden in der Abbildung die Schnittstellen mit den in Abschnitt 2.3.8 behandelten Transformationen gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Modelle im MDA-Prozess⁴¹

Neben den drei im Standard beschriebenen Modellen führen Gruhn, Pieper und Röttgers drei weitere Modelltypen auf:⁴²

- Architecture Metamodell (AMM)
- Transformation Description Model (TDM)
- Platform Description Model (PDM)

Dies ist sinnvoll, da der Standard viele Fragen offen lässt und nur sehr vage auf die eigentlichen Abbildungen von einem Modell in ein anderes eingeht.

Das AMM beschreibt in formaler Weise den domänenspezifischen und technologie-unabhängigen Architekturstil, der zur Modellierung eines Systems angewendet werden darf; also den Zusammenhang der architekturellen Elemente wie zum Beispiel Konzepte, Muster, Abstraktionen oder Schnittstellen. Als Hilfsmittel kommen hier die erwähnten UML-Profile zum Einsatz.⁴³ CIM und AMM bilden zusammen den Input für den Übergang in den plattformunabhängigen, aber anwendungsspezifischen Bereich des PIM. Diese erste Transformation kann nicht automatisiert erfolgen sondern erfordert das Wissen, wie der Architekturstil auf die Problemdomäne anzuwenden ist. In der klassischen Welt wäre diese Form der Transformation der Phasenwechsel zwischen Geschäftsprozessmodellierung und Analysephase.

Für den Übergang in die Designphase und damit dem Sprung auf die Ebene der technologiespezifischen Modelle sind neben dem PIM weitere Informationen über die konkrete Zielplattform und Transformationsvorschriften nötig. Das PDM bzw. Plattform Model bietet die technische Spezifikation der Zielplattform und beschreibt die angebotenen Dienste, Strukturen sowie die Möglichkeiten der Verbindung unterschied-licher Komponenten.⁴⁴ Auch hier werden UML-Profile zur Erweiterung des UML-Metamodells oder zur Schaffung eines eigenen Metamodells auf MOF-Basis eingesetzt. Für eine möglichst automatisierte Transformation werden im TDM die nötigen Transformationsvorschriften festgelegt.

2.3.7.1 Computation Independent Model

Das berechnungs-unabhängige Modell (engl. Computation Independent Model) repräsentiert die Geschäfts- oder Domänensicht der zu entwickelnden Software und stellt den Modelltyp höchster Abstraktionsstufe dar. Es beschreibt die Softwarelösung auf fachlicher Ebene und liegt in einer Sprache vor, die für die fachlichen Anwender des Systems verständlich ist. Das CIM legt fest, welche Anforderungen die Software-lösung erfüllen muss, definiert aber nicht, wie es diese erfüllt oder wie das System strukturiert ist. Bei der Erstellung des CIM sollte nach der Methodik der objekt-orientierten Geschäftsprozessmodellierung (OOGPM) vorgegangen werden. Ein Domain- bzw. Business-Modell und ein Requirements Modell sollten Ergebnis dieser Phase sein und vorzugsweise in der Sprache der UML beschrieben werden.⁴⁵

2.3.7.2 Platform Independent Model

In dem PIM wird die Funktionalität einer Komponente unabhängig von der gegebenen Plattform abgebildet. Das PIM beschreibt die Struktur und das Verhalten der zu entwickelnden Software ohne die endgültige Zielplattform zu kennen. Es bleibt damit

unabhängig von technischen Aspekten wie Software- oder Hardwareplattformen und abstrahiert so von den späteren Implementierungsdetails. Die Modellierung eines PIM sollte nach Meinung der OMG mit den Konstrukten der UML erfolgen. Eine Darstellungsform für das PIM ist zum Beispiel das Klassenmodell für strukturelle Aspekte des Systems.⁴⁶

2.3.7.3 Platform Specific Model

Durch die Anreicherung des PIM mit plattformabhängigen Informationen, durch das weiter oben erwähnte PDM, erhält man das Platform Specific Model. Es kennt die konkreten technischen Details, die für die Implementierung des Softwaresystems in der jeweiligen Zielplattform zum Beispiel J2EE, .Net oder Corba notwendig sind. Ein PSM enthält eine Vielzahl von Aspektbeschreibungen zum Beispiel durch UML-Modelle oder aus Konfigurations- und Deploymentwissen. Es verbindet Klassen- und Modell-elemente, die das „Wie“ der Klassen beinhalten. Diese Form der Modelle ist immer technologieabhängig und ändert sich, wenn die Plattform gewechselt wird. Aus diesem Grund sollte die Transformation von PIM zu PSM und schließlich zu Code möglichst vollständig automatisiert ablaufen.⁴⁷

2.3.8 Transformation

Neben den unterschiedlichen Modelltypen ist das Konzept der Transformation von Modellen als weiterer Baustein im MDA-Entwicklungsprozess zu sehen. Automatische Transformationen sind das Mittel zur Steigerung der Portabilität und Effizienz sowie der Qualität bei gleichzeitiger Verringerung von Entwicklungszeit und Kosten.⁴⁸

Es werden zwei Arten der Transformation (siehe Abbildung 3) unterschieden. Zum einen die aus der CASE-Zeit bekannte Modell-zu-Text Transformation (M2T) und zum anderen die für den MDA-Ansatz wichtigere Modell-zu-Modell Transformation (M2M).⁴⁹

Für beide Arten existieren inzwischen die von der Fachwelt geforderten Standards zur Harmonisierung der Softwareprodukte. Die M2M-Transformation wird durch den QVT-Standard abgedeckt, und die Erzeugung von Quellcode bzw. Text ist in der MOFM2T Sprache definiert. Beide Standards wurden bereits in Abschnitt 2.3.6 behandelt, dementsprechend kann direkt auf die Besonderheiten der beiden Trans-formationen eingegangen werden.

2.3.8.1 Modell-zu-Modell

Die Abbildung zwischen Modellen erfolgt über Transformations-Definitionen. Sie bestehen aus Regeln – in der Literatur häufig als Mapping bezeichnet – die auf Basis der Metamodelle beschreiben, wie Elemente des Quellmodells auf Elemente des Zielmodells abgebildet werden.

Die eigentliche Transformation ist in drei Schritte untergliedert und stützt sich auf den XMI-Standard sowie die Möglichkeit, Modelle als XML Dokumente zu formulieren. Im ersten Schritt wird das Modell deserialisiert, also in eine „In Memory Representation“ gebracht, danach die eigentliche Transformation ausgeführt und schließlich wieder serialisiert.⁵⁰

2.3.8.2 Modell-zu-Text

Die OMG schlägt für die Transformation in eine Textdarstellung den auf Templates basierenden Ansatz vor und hat diesen als Standard unter „MOF Model to Text Trans­formation Language“ veröffentlicht. In Abschnitt 2.3.6 wurde dieser Standard bereits im Zusammenhang mit der QVT-Sprache behandelt und dargestellt, dass mithilfe von Templates und Ausdrücken Modellinhalte in Test umgewandelt werden können. Nach der OMG ist das Ergebnis der Transformation nicht nur auf den Quellcode beschränkt, vielmehr soll jegliche Form der gradlinigen Textdarstellung wie zum Beispiel Berichte oder Spezifikationen ermöglicht werden.⁵¹

2.3.8.3 Ablauf

An dieser Stelle wird auf eine Vorstellung der unterschiedlichen⁵² Interpretationsweisen zur Umsetzung des MDA-Prozesses aus der Praxis verzichtet. Stattdessen wird der sogenannte elaboratorische⁵³ Ansatz, der schon implizit in Abbildung 3 dargestellt wurde, angewendet. Die fertige Anwendung entsteht dabei über die Transformationen des PIM in das PSM und schließlich in den Quellcode.⁵⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: PIM - PSM - Code⁵⁵

Bei dem Ansatz existiert das Problem der Synchronität bzw. Konsistenz zwischen den einzelnen Stufen, da die Anwendung allmählich beim Durchlaufen der einzelnen Modelle entsteht. Um dieser Problematik entgegenzuwirken, haben sich drei Konzepte in der Praxis etabliert:⁵⁶

- Forward Engineering Only
- Partial Round-Trip Engineering
- Full Round-Trip Engineering

Eine nähere Betrachtung der Konzepte ist nicht notwendig, da sie für das Verständnis der MDA von untergeordneter Bedeutung sind.

2.4 Einordnung und Einsatz

- Einordnung

Der modellgetriebene Ansatz wird in der Fachliteratur einheitlich als der nächste logische Schritt in der Historie der Softwareentwicklung gesehen und kann wie folgt veranschaulicht werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Evolution der Softwareentwicklung⁵⁷

Seit der Codierung mit Nullen und Einsen ist die Steigerung des Abstraktionsgrades das Hauptziel in der Softwareentwicklung. Der Grund für diese Evolution wird von den Experten in dem Problem der Komplexitätsbeherrschung gesehen, das auch schon in der Motivation dieser Arbeit thematisiert wurde. Zum gegenwärtigen Zeitpunkt wird von der IT-Industrie erfolgreich das objektorientierte Paradigma um- und eingesetzt. Aufgrund der steigenden Komplexität von Enterprise Architekturen, auch verursacht durch den Boom des Internets, rückt dieses Problem erneut in den Vordergrund.⁵⁸ Weitere Einflüsse wie Kosten, Qualität und Langlebigkeit einer Software verstärken diesen Trend zunehmend und erhöhen so den Druck auf die Industrie, ihr Vorgehen zu optimieren⁵⁹.

- Einsatz

Eine objektive Bewertung, ob der Einsatz vorteilhaft ist, kann nicht erbracht werden, da große empirische Untersuchungen in diesem Bereich noch ausstehen⁶⁰. Für die Bewertung wird daher auf die Fallstudienanalysen der OMG und der Softwareanbieter selbst zurückgegriffen. Ein Hauptgrund für diese Problematik ist, dass kein Unter-nehmen dasselbe Projekt zweimal durchführen würde und Projekte per Definition eine gewisse Einzigartigkeit besitzen⁶¹. Eine Aussage über den Trend kann aber bei Betrachtung der später zitierten Forrester Studien und Recherchen auf dem Software-markt durchaus erfolgen.

Derzeit werden auf der Internetseite der OMG 28 erfolgreich durchgeführte MDA Projekte vorgestellt. Darunter Projekte von Unternehmen wie DaimlerChrysler, Siemens, Credit Suisse oder Deutsche Bank Bauspar AG. Die veröffentlichten Fall-studien der OMG sind jedoch kritisch zu hinterfragen, da viele der Vorteile als Werbung für den jeweiligen Softwareanbieter gewertet werden können:⁶²

„MDA/ArcStyler Benefits: Up to 55% reduction of expenses compared to manual development; ROI achieved in less than 12 months”.

"We could not have done this without Aonix® ACDTM”.
“E-SoftSys improved productivity by 40 percent with Optimal”.

Blendet man die angesprochenen Hilfen der Softwareanbieter aus, oder betrachtet die auf Open Source basierenden Projekte, ist die MDA heute schon teilweise technisch einsetzbar. Durchaus kritische Aussagen zum praktischen Einsatz der MDA finden sich in einer Studie der Universität München aus dem Jahr 2007 zur Industrialisierung der Software-Branche, in der nur etwas mehr als die Hälfte der befragten Unternehmen den MDA-Ansatz zur Erreichung der Ziele positiv sahen⁶³.

Eine ausführlichere, auch die langzeitlichen sowie organisatorischen Aspekte betrachtende Darstellung, liefern Guttman und Parodi in ihrem aktuellen Werk „Real-Life MDA: Solving Business Problems with Model Driven Architecture“. In diesem werden sechs Projekte von drei großen Unternehmen, sowie von drei staatlichen Agenturen, die aus strategischen und kommerziellen Gesichtspunkten auf einen MDA-Ansatz gesetzt haben, betrachtet. Das Ergebnis der Fallstudien von Guttman und

Parodi ist, dass die MDA in vielen unterschiedlichen Problemfeldern profitabel eingesetzt werden kann. Die MDA bietet die Möglichkeit auf unterschiedliche Anforderungen zugeschnitten werden zu können und sollte nicht auf Generierung von Code oder reine UML-Modellierung beschränkt werden.⁶⁴ Die Auswahl an Produkten, die diese Art der Softwareentwicklung unterstützen, kann als weiterer Anhaltspunkt für die Verbreitung der MDA gesehen werden. Zurzeit existieren circa 35 Software-produkte zur Unterstützung eines modellbasierten Vorgehens. Eine Übersicht über die unterschiedlichen Werkzeuge ist dem Anhang A: Übersicht MDD-Werkzeuge zu entnehmen.

Die Art der Verwendung wurde im August 2008 in einer von Forrester durchgeführten Studie analysiert (siehe Abbildung 6). Bei dieser Untersuchung wurden 132 Unter-nehmen befragt, welche Software und Techniken zur Entwicklung eingesetzt werden bzw. mit welchen schon Erfahrungen existieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Verwendete Techniken und MDD-Software⁶⁵

Eine weitere Studie von Forrester aus dem Jahr 2007 zum Status des Model Driven Development belegt, dass viele Softwarehersteller in den Ausbau ihrer Software investieren, um das modellbasierte Konzept zu unterstützen.⁶⁶

[...]

---

¹ Vgl. Pietrek, G., Trompeter, J. (2007), S. 10.

² Vgl. Boes, A. et al. (2008), S. 8 ff.

³ Vgl. Gruhn, V. et al. (2006), Vorwort.

⁴ Vgl. Boes, A. et al. (2007), S. 26.

⁵ Vgl. Roeder, H. et al. (2007), S. 12.

⁶ Vgl. Gartner (2005), o.S.

⁷ Vgl. Hess, T. et al. (2007), S. 1 ff.

⁸ Vgl. Schwarze, L., Müller, P. (2005), S. 6.

⁹ Vgl. Frankel, D., Parodi, J. (2004), S. 13 f.

¹⁰ Vgl. OMG (2008c), o.S.

¹¹ Vgl. Forrester (2008), S. 3.

¹² Vgl. OMG (2003), S 6.

¹³ Vgl. Gruhn, V. et al. (2006), S. 10.

¹⁴ OMG (2008c), o.S.

¹⁵ Vgl. Gruhn, V. et al. (2006), S. 21.

¹⁶ Vgl. Stahl, T. et al. (2007), S. 377.

¹⁷ Vgl. OMG (2003), S. 12

¹⁸ Quelle: Entnommen aus: OMG (2008c), o.S.

¹⁹ Vgl. OMG (2008c), o.S.

²⁰ Vgl. Guttman, M., Parodi, J. (2007), S. 5.

²¹ Vgl. Roßbach, P. et al. (2003), S. 1.

²² Vgl. Gruhn, V. et al. (2006), S. 71 f.

²³ Vgl. Watson, A. (2008), S. 2.

²⁴ Vgl. OMG (2007a), S. 207 f.

²⁵ Vgl. Stahl, T. et al. (2007), S. 378 f.

²⁶ Vgl. Mellor, S. et al. (2004), S. 45.

²⁷ Vgl. Stahl, T. et al. (2007), S. 379.

²⁸ OMG (2006a), o.S.

²⁹ Vgl. Gruhn, V. et al. (2006), S. 91.

³⁰ OMG (2007b), o.S.

³¹ Vgl. Zengler, B. et al. (2007), S. 527 ff.

³² Vgl. OMG (2006b), S. 5 f.

³³ Vgl. Gruhn, V. et al. (2006), S. 107.

³⁴ Vgl. Stahl, T. et al. (2007), S. 393 ff.

³⁵ OMG (2008b), o.S.

³⁶ Vgl. OMG (2008a), S. 3 f.

³⁷ Vgl. Stahl, T. et al. (2007), S. 409 ff.

³⁸ Vgl. Gruhn, V. et al. (2006), S. 119.

³⁹ Vgl. Kleppe, A. et al. (2003), S. 19.

⁴⁰ Vgl. OMG (2003), S. 13 ff.

⁴¹ In Anlehnung an: Gruhn, V. et al. (2006), S. 120; Si Alhir, S. (2003), S. 20.

⁴² Vgl. Gruhn, V. et al. (2006), S. 121 ff.

⁴³ Vgl. Gruhn, V. et al. (2006), S. 130.

⁴⁴ Vgl. OMG (2003), S. 16.

⁴⁵ Vgl. Gruhn, V. et al. (2006), S. 122 f.

⁴⁶ Vgl. Gruhn, V. et al. (2006), S. 126 ff.

⁴⁷ Vgl. Gruhn, V. et al. (2006), S. 141 ff.

⁴⁸ Vgl. Mellor, S. et al. (2004), S. 47.

⁴⁹ Vgl. Kleppe, A. et al. (2003), S. 37.

⁵⁰ Vgl. Gruhn, V. et al. (2006), S. 156 f.

⁵¹ Vgl. OMG (2008a), S. 3.

⁵² Vgl. Kleppe, A. et al. (2003), S. 36; Mellor, S., Balcer, M. (2003), S. 303.

⁵³ « elaborieren » aus dem lat. elaborare (sorgfältig) Ausarbeiten

⁵⁴ Vgl. Gruhn, V. et al. (2006), S. 178.

⁵⁵ In Anlehnung an: Roßbach, P. et al. (2003), S. 2.

⁵⁶ Vgl. Frankel, D. (2003), S. 230 ff.

⁵⁷ In Anlehnung an: Gruhn, V. et al. (2006), S. 15.

⁵⁸ Vgl. Gruhn, V. et al. (2006), S. 14 f.

⁵⁹ Vgl. Frankel, D. (2003), S. 30.

⁶⁰ Vgl. Bucholdt, C. (2003), S. 23.

⁶¹ Vgl. Stahl, T. et al. (2007), S. 342.

⁶² Vgl. OMG (2008d), o.S.

⁶³ Vgl. Hess, T. et al. (2007), S. 7.

⁶⁴ Vgl. Guttman, M., Parodi, J. (2007), S. 155.

⁶⁵ In Anlehnung an: Forrester (2008), S. 13.

⁶⁶ Vgl. Giudice, D. (2007), S. 11 ff.