Advanced Application- System Development Skript WS 04-05.pdf · Abbildung 33: Namespace-Hierarchie...

Fachhochschule Kiel Fachbereich Informatik und Elektrotechnik

Institut für Angewandte Informatik

Studiengang Master Internet Science and Technology

Stichworte zur Vorlesung

Advanced Application- System Development

Prof. Dr.-Ing. Ulrich Samberg

Ausgearbeitet von Daniel Barth WS 2004/2005



Inhaltsverzeichnis Inhaltsverzeichnis....................................................................................................................... 2 Abbildungsverzeichnis ............................................................................................................... 4 1 Übersicht .............................................................................................................................. 5 2 Entwicklungsrahmen............................................................................................................ 6

2.1 Qualitätssicherung....................................................................................................... 6 2.2 Team Building............................................................................................................. 6 2.3 Application Management Lifecycle - Vorgehensmodell nach ITIL ........................... 7

2.3.1 Requirement Phase............................................................................................. 8 2.3.2 Design Phase .................................................................................................... 12 2.3.3 Build Phase....................................................................................................... 15 2.3.4 Deploy, Operate und Optimise Phase .............................................................. 20

3 Organisation ....................................................................................................................... 21 3.1 Projektmanagement (allgemein) ............................................................................... 21

3.1.1 Einführung........................................................................................................ 21 3.1.2 Die 9 Wissensfelder des PM ............................................................................ 22 3.1.3 Zielbereiche...................................................................................................... 23 3.1.4 Erfolgsfaktoren................................................................................................. 24 3.1.5 Formale Projektmanagementsysteme............................................................... 24

3.2 Umsetzung ITIL ........................................................................................................ 24 4 Entwurf............................................................................................................................... 25

4.1 Architektur ................................................................................................................ 25 4.1.1 Architektur Grundtypen ................................................................................... 26 4.1.2 Beispiel: Microsoft Windows (MFC, alt) ........................................................ 27 4.1.3 Wie entsteht eine Anwendungsarchitektur....................................................... 29

4.2 Exkurs: UML-Modellierung ..................................................................................... 31 4.3 Systementwurf........................................................................................................... 32

4.3.1 Schritt 1: Use Case Diagramm erstellen .......................................................... 32 4.3.2 Schritt 2: Klassenmodell (fachlich).................................................................. 33 4.3.3 Schritt 3: Klassenmodell (technisch)................................................................ 33 4.3.4 Schritt 4: Komponentenmodell ........................................................................ 33 4.3.5 Schritt 5: Deployment Diagramm .................................................................... 34

4.4 Oberfläche ................................................................................................................. 34 4.4.1 Architektur eines Oberflächenmodells............................................................. 34 4.4.2 Dialoggestaltung............................................................................................... 36

Advanced Application System Development Seite 2



4.5 Wiederverwendung ................................................................................................... 37 4.6 Entwurfsmuster ......................................................................................................... 37

4.6.1 Grundlegende Muster nach GoF ...................................................................... 38 4.6.2 Beispiel für den Entwurf eines Musters ........................................................... 39

5 Anwendungstechnologie .................................................................................................... 41 5.1 Frameworks............................................................................................................... 41 5.2 Microsoft .NET ......................................................................................................... 42

5.2.1 Ausblick ........................................................................................................... 43 5.2.2 Konzept ............................................................................................................ 43 5.2.3 CLR, CIL, Garbage-Collection und Reflection ............................................... 44 5.2.4 Managed und Unmanaged, Interoperabilität .................................................... 44 5.2.5 Verteilte Programmierung und Web Services.................................................. 45 5.2.6 Laufzeitumgebung (CLR) ................................................................................ 45 5.2.7 .NET Framework - Klassenbibliothek (FCL) .................................................. 45 5.2.8 Typhierarchien ................................................................................................. 46 5.2.9 Programmausführung (CIL)............................................................................. 47 5.2.10 Assemblies ..................................................................................................... 48

5.3 WebServices.............................................................................................................. 48 5.3.1 Grundlagen ....................................................................................................... 49 5.3.2 Vorteile............................................................................................................. 49 5.3.3 Anwendungsgebiete ......................................................................................... 49 5.3.4 Erweiterungen .................................................................................................. 49 5.3.5 Architektur am Beispiel von ASP.NET ........................................................... 50 5.3.6 Aufbau eines WebService ................................................................................ 51 5.3.7 Aufruf eines WebService ................................................................................. 52

5.4 Exkurs: XML, Datenzugriffsschicht der Anwendung............................................... 54 5.5 Exkurs: Organisation von Zugriffen auf Anwendungs-programme aus eigenem Programmcode ................................................................................................................... 56

Quellenverzeichnis ................................................................................................................... 57




Abbildungsverzeichnis Abbildung 1: Übersicht AASD .................................................................................................. 5 Abbildung 2: Mind Map Team Building.................................................................................... 6 Abbildung 3: Application Lifecycle........................................................................................... 8 Abbildung 4: Wissenfelder des PM ......................................................................................... 22 Abbildung 5: ITIL Prozessorganisation .................................................................................. 24 Abbildung 6: 1-tier-Architektur ............................................................................................... 26 Abbildung 7: 2-tier-Architektur ............................................................................................... 26 Abbildung 8: 3-tier-Architektur ............................................................................................... 27 Abbildung 9: Windows Anwendung........................................................................................ 27 Abbildung 10: Windows Klassenhierarchie (MFC)................................................................. 28 Abbildung 11: Windows-Anwendung (MFC) ......................................................................... 28 Abbildung 12: Ebenenmodell ASP.Net ................................................................................... 29 Abbildung 13: SAP Anwendungsarchitektur........................................................................... 30 Abbildung 14: Ausgangssituation UML-Modelleierung ......................................................... 31 Abbildung 15: Objektmodell.................................................................................................... 31 Abbildung 16: Klassenmodell (Variante 1) ............................................................................. 31 Abbildung 17: Klassenmodell (Variante 2) ............................................................................. 31 Abbildung 18: Use Case Diagramm......................................................................................... 32 Abbildung 19: Fachliches Klassenmodell................................................................................ 33 Abbildung 20: Technisches Klassenmodell ............................................................................. 33 Abbildung 21: Komponentenmodell ........................................................................................ 33 Abbildung 22: Komponenten Abhängigkeiten ........................................................................ 34 Abbildung 23: Deployment Diagramm.................................................................................... 34 Abbildung 24: Model-View-Controler Architektur ................................................................. 35 Abbildung 25: Model-View-Controler Klassenmodell............................................................ 35 Abbildung 26: Klassenfabrik ................................................................................................... 40 Abbildung 27: Framework (allgemein).................................................................................... 41 Abbildung 28: Microsoft .NET ................................................................................................ 42 Abbildung 29: .NET Dienste.................................................................................................... 42 Abbildung 30: Laufzeitumgebung und Klassenbibliotheken vor .NET................................... 43 Abbildung 31:Laufzeitumgebung und Klassenbibliotheken in .NET...................................... 44 Abbildung 32: CLR-Aufbau..................................................................................................... 45 Abbildung 33: Namespace-Hierarchie ..................................................................................... 46 Abbildung 34: Vererbungshierarchie ....................................................................................... 46 Abbildung 35: Objektmodell.................................................................................................... 47 Abbildung 36: Architektur ASP.NET ...................................................................................... 50 Abbildung 37: Deploymentdiagramm ASP.NET..................................................................... 50 Abbildung 38: WebService Struktur ........................................................................................ 52 Abbildung 39: Aufrufstruktur WebServices in ASP.NET ....................................................... 53




1 Übersicht

Abbildung 1: Übersicht AASD

Die Inhalte der Vorlesung befassen sich sowohl mit den organisatorischen Aspekten größerer Softwareprojekte wie der Wahl und Umsetzung geeigneter Vorgehensmodelle, als auch mit den technischen Grundlagen moderner Anwendungssystemarchitekturen und deren Imple-mentierung. Die Entwicklung eines „Softwareproduktes“ teilt sich in drei Hauptbereiche auf:

1. Organisation 2. Fachliche Lösung 3. Technologie




2 Entwicklungsrahmen Der Entwicklungsrahmen legt das Umfeld fest, in dem das Projekt durchgeführt werden soll. Er definiert beispielsweise die Einbindung in einen qualitätssichernden Kontext (Qualitätsma-nagement) und legt fest nach welchem Vorgehensmodell die Entwicklung organisiert werden soll. Ferner können im Entwicklungsrahmen unterstützende Funktionen wie z.B. Reporting, Benchmarking, Controlling etc. enthalten sein.

2.1 Qualitätssicherung Qualitätssicherung ist Teil des Qualitätsmanagements. Nach DIN EN ISO 9000:2000, Punkt 3.2.11 ist Qualitätssicherung definiert als "Teil des Qualitätsmanagements, der durch das Erzeugen von Vertrauen darauf gerichtet ist, dass Qualitätsanforderungen erfüllt werden". Qualitätssicherung ist der unternehmensinterne Prozess, der sicherstellen soll, dass ein herge-stelltes Produkt ein festgelegtes Qualitätsniveau erreicht. Dabei geht es nach ISO 9000 nicht etwa darum, die Qualität eines Produktes zu optimieren, sondern ein vorgegebenes – unter Umständen auch extrem niedriges - Niveau zu halten. Das Produkt kann dabei sowohl materi-ell sein, als auch eine erbrachte Leistung oder eine verwendete Verfahrensweise. Teil der Qualitätssicherung ist die Gleichheit des Produktes mit einem zweiten und jedem weiteren Exemplar des Produktes (Reproduzierbarkeit). Um diese Gleichheit zu erreichen, setzt man Qualitätssicherungsnormen wie beispielsweise internationale Normen nach EN oder ISO, nationale Normen nach DIN oder Önorm, firmeninterne Normen oder andere technische Dokumentationen wie RFCs ein. So fordert z.B. ein Qualitätsmanagement-System nach DIN EN ISO 9001:2000 für Entwick-lungsprozesse ein Modell zur Entwicklungsplanung das folgende Forderungen erfüllt:

• Planung und Lenkung der Entwicklung durch die Organisation • Festlegung von Entwicklungsphasen, einer angemessenen Bewertung, Verifizierung

und Validierung für jede Phase sowie der Verantwortung und Befugnisse dafür • Lenkung der Schnittstellen der an der Entwicklung beteiligten Gruppen, um eine

wirksame Kommunikation und eine klare Verantwortungszuordnung zu sichern • Aktualisierung der Planung bei Fortschreiten der Entwicklung, soweit angemessen

Angewendet auf den Softwareentwicklungsprozess ergibt sich aus dem Qualitätsmanagement als qualitätssichernde Maßnahme die Notwendigkeit des Vorhandenseins und Befolgens eines Vorgehensmodells zur Anwendungsentwicklung.

2.2 Team Building

Abbildung 2: Mind Map Team Building




2.3 Application Management Lifecycle - Vorgehensmodell nach ITIL (nach [5])

Die IT Infrastructure Library, kurz ITIL, ist ein in Großbritannien entwickelter Leitfaden zur Unterteilung der Funktionen und Organisation der Prozesse, die im Rahmen des Betriebs einer IT-Infrastruktur eines Unternehmens entstehen (IT Service Management). Vor allem in England und den Niederlanden ist die Organisation dieser Prozesse nach ITIL ein weit ver-breiteter Standard, in Deutschland wächst die Bedeutung ebenfalls stetig. ITIL ist in einer Reihe von Büchern definiert, die vom Office of Government Commerce (OGC), einer Stab-stelle der Regierung von Großbritannien herausgegeben werden. Bei ITIL handelt es sich um keine Projektmanagementmethode: ITIL soll nicht die Einfüh-rung einer IT-Infrastruktur organisieren, sondern vielmehr deren dauerhaften Betrieb. Sie definiert klare Aufgabenstellungen, die beim Betrieb dieser Infrastruktur anfallen. ITIL beschreibt Umsetzungsmöglichkeiten für die wesentlichen Prozesse, die im Rahmen des IT Service Managements und ICT Infrastructure Managements organisiert werden sollten, einschließlich der nicht oder nicht nur spezifisch IT-originären Prozesse wie Strategiebildung, Planung, Controlling, Personalmanagement etc. ITIL in der Revision 2 besteht aus acht Kernpublikationen:

• Service Support • Service Delivery • ICT Infrastructure Management • Security Management • Application Management Lifecycle • Planning to Implement Service Management • Software Asset Management • The Business Perspective

Im Rahmen dieser Vorlesung soll aus ITIL lediglich das Vorgehensmodell, der Application Management Lifecycle betrachtet werden. Im Gegensatz zu klassischen Vorgehensmodellen verfolgt dieses einen integrierten Ansatz über die gesamte Lebensdauer einer Anwendung und endet nicht mit deren Auslieferung, sondern schließt nachgelagerte Problemstellungen der Softwareentwicklung wie Betrieb, Wartung und Pflege bereits in den eigentlichen Entwick-lungsprozess mit ein. Der Lebenszyklus einer Anwendung erstreckt sich bis zu dem Punkt, an dem alle Programmdateien von sämtlichen involvierten Systemen der IT-Infrastruktur entfernt wurden und keinen Einfluss mehr auf die IT-Umgebung ausüben können. Es gibt eine Reihe von Perspektiven aus denen der Application Lifecycle betrachtet werden kann, aber die meisten fallen in zwei Kategorien – entweder betrachten sie die Anwendungs-entwicklung oder das Service Management. Die Entwicklungssicht unterscheidet zwischen globalem und detailliertem Design, Modul- und Systemtests und endet mit einer sehr vagen Phase namens Wartung. Das Service Management beginnt meist erst bei bereits fertig entwickelten Anwendungen, die für den Produktivbetrieb freigegeben wurden.


http://de.wikipedia.org/w/index.php?title=IT_Service_Management&action=edit


Institut für Angewandte Informatik Was in beiden Perspektiven übersehen wird ist, dass die Verbindung zwischen Anwendungs-entwicklung und Service Management in der Realität sehr viel enger ist als in den entspre-chenden Vorgehensmodellen berücksichtigt wird. Der Application Lifecycle nach ITIL definiert sechs Phasen, die jeweils aus beiden Perspekti-ven betrachtet werden, was eine Abstimmung beider Sichten in jeder einzelnen Phase erfor-derlich macht.

Abbildung 3: Application Lifecycle [5]

2.3.1 Requirement Phase Jedes Anwendungssystem beginnt seinen Lebenszyklus in der Requirement Phase. In dieser Phase arbeitet das Entwicklungsteam eng mit den involvierten Fachabteilungen zusammen und sammelt die Anforderungen, die an das System gestellt werden. Die Requirement Phase identifiziert Funktionalitäten und andere Charakteristiken wie Performance, Skalierbarkeit, Sicherheit etc., die die Anwendung erfüllen muss. Die Anforderungen, die in dieser Phase entwickelt werden, dienen als Ausgangspunkt für die weiteren Phasen des Entwicklungspro-zesses. ITIL unterscheidet drei verschiedene Anforderungsbereiche:

• Functional Requirements • Non-Functional Requirements • Usability Requirements

2.3.1.1 Functional Requirements Funktionale Anforderungen beschreiben die Dinge, die eine Anwendung unterstützen soll und lassen sich als Dienste, Aufgaben oder Funktionen formulieren. Eine Möglichkeit funktionale Anforderungen zu spezifizieren ist z.B. der Einsatz von Use Case Modellen aus der UML, die sich später z.B. auch zu Testfällen erweitern lassen. Da Use Cases die Funktionalität einer Anwendung auf einem Level beschreiben das sowohl für die Business-als auch die IT-Seite verständlich ist, können sie als Vehikel genutzt werden die funktionalen Elemente von Service Level Agreements (SLA’s) zu spezifizieren.



Institut für Angewandte Informatik Eine Ebene unterhalb der Use Cases werden je nach Typ der Anwendung weitere Modellie-rungsschritte durchgeführt, die die statischen / dynamischen Charakteristiken des Anwen-dungssystems darstellen und ein konzeptionelles Datenmodell definieren (z.B. Sequenz-, Zustandsdiagramme und Komponentenmodell etc. ebenfalls aus der UML). Sie dienen als Basis für die weitere technische Modellierung in der Design Phase.

2.3.1.2 Non-Functional Requirements Nicht funktionale Anforderungen werden dazu verwendet Anforderungen und Restriktionen an das Anwendungssystem selbst zu definieren. Diese Anforderungen dienen beispielsweise als Basis zur frühen Bestimmung der benötigten Systembemessung und der damit verbundenen Kosten. Am wichtigsten ist jedoch der Einfluss den sie auf das Design der technischen und operativen Modelle haben. Nicht funktionale Anforderungen bestimmen zu großen Teilen die Entschei-dung für eine konkrete Anwendungsarchitektur. Zwei Anwendungssysteme mit identischen Use Cases aber sehr unterschiedlichen nicht funktionalen Anforderungen brauchen sehr unter-schiedliche Architekturen. Nicht funktionale Anforderungen sollten den einzelnen Entwickler ebenso dazu ermutigen einen Blick über den Tellerrand zu riskieren und das Projekt und seine Ziele als Ganzes wahr-zunehmen. Typische nicht funktionale Anforderungen sind:

• Verlässlichkeit: o Ausfallsicherheit o Ausfallwirkung

• Effizienz (z.B. Ressourcenverbrauch) • Effektivität (System lernt) • Anwendungsintegration (kann es mit anderen Programmen laufen?) • Verfügbarkeit (z.B. 24/7/356) • Kapazitätsanforderungen (Minimalausstattung) • Sicherheitsanforderungen (Checklisten abhaken) • Korrigierbarkeit • Standartkonfiguration • Wartbarkeit • Sicherung gegen Störung von außen




2.3.1.3 Usability Requirements Der primäre Zweck von Usability Requirements ist es sicherzustellen, dass das Anwendungs-system die Erwartungen der Benutzer an seine unkomplizierte Verwendbarkeit erfüllt. Sie liefern Vorgaben für die Bereiche:

• User Interface und GUI-Design • Performance Standards (z.B. Antwortzeiten) • Test Szenarien

2.3.1.4 Change Cases Change Cases sind nicht direkter Teil der Modellierung des zu entwickelnden Anwendungs-systems, sondern spezifizieren wahrscheinliche, in zukünftigen Programmversionen zu implementierende Funktionen. Sie dienen dazu die Planung um eine vorausschauende Kom-ponente zu erweitern, um den Aufwand für zukünftige Änderungen zu minimieren.

2.3.1.5 Testing Requirements Das Testen der Anforderungen ist eine oft übersehene Möglichkeit die Qualität der zu entwickelnden Anwendung zu verbessern. Die hier zur Verfügung stehenden Möglichkeiten sind beispielsweise:

• Prototyping, • User Interface und GUI Dummies, • Screenshot Reviews, • Dokumentations Reviews, • Präsentationen, • etc.

Die Herausforderung bei Anforderungstests sind zum einen die anfänglich vielleicht unüber-sichtliche Anzahl von Anforderungen und zum anderen die unterschiedlichen Erwartungen und Meinungen der Beteiligten was das System wie zu leisten hat. Ziel dieses Schrittes soll sein, vor Beginn der nächsten Phase eventuell vorhandene Missverständnisse in den doku-mentierten Anforderungen aufzudecken und zu beseitigen.

2.3.1.6 Requirements Management Checklist Bei der Identifizierung der Anforderungen ist es wichtig, dass in der Requirements Phase alle Service Management Funktionen vollständig berücksichtigt und behandelt werden. Dazu gehören:

• Configuration – Unter welcher Systemumgebung soll das System laufen ? • Change – Sind bereits Erweiterungen absehbar (s. Change Cases) ?

• Release – Wie soll das System herausgegeben werden; hat es Einfluss auf andere

Applikationen die eventuell Updates benötigen ?




• Security – Welche Sicherheitsanforderungen müssen eingehalten werden (z.B. Ver-schlüsselung, Zugriff auf die Hardware etc.) ?

• Incidents – Wie soll auf Fehler in der Anwendung reagiert werden, wie auf Fehler in

der Organisation; Einführung von Unternehmensstandards zur Fehlerbehandlung ?

• Problems – Wie sieht die Problembehandlung in der Systemungebung aus (stehen Backup Lösungen bereit etc.) ?

• Capacity – Welche Kapazitäten sind verfügbar / werden benötigt ?

• Availability – 24/7/365 ?

• Service Continuity – Wie lange kann der Betrieb ohne das System arbeiten, wie

arbeitet er ohne das System ?

• Service Level – Welches Service Level wird benötigt (24h Hotline / Vor Ort Service etc.) ?

• Financials – Wie beeinflusst das System die Kostenstruktur, wer bezahlt dafür ?

2.3.1.7 Organisation des Requirements Teams Das Requirements Team erfordert die Anwesenheit einiger Schlüssel Service Management Bereiche um sicherzustellen, dass die Arbeit umfassend erledigt wird. Dazu werden Rollen definiert, die von ein oder mehreren Personen übernommen werden:

• Change and Configuration Management Verantwortlich für Change, Release und Configuration Management, welche die Hauptprozesse darstellen, die die Anwendung vom Entwicklungs- in den Produktiv-einsatz überführen.

• Support Verantwortlich für Support, Incident und Problem Management.

• Operations

Verantwortlich für die alltäglichen Wartungsaktivitäten nachdem das System in den Produktiveinsatz überführt wurde. Ziel ist es sicherzustellen, dass Wartung und Pflege des Systems definiert und deren Durchführung kompatibel mit anderen Anwendungen der Organisation ist (z.B. gemeinsame Wartungsfenster, um Downtimes zu reduzie-ren).




• Security Verantwortlich für das Betreiben eines Risiko Managements. Hauptziele sind die Sicherstellung von:

o Daten-Konfidenz: Niemand darf unauthorisierten Zugriff auf Daten haben. o Daten-Integrität: Die Daten müssen korrekt sein. o Daten-Verfügbarkeit: Daten müssen verfügbar sein wann und wo sie gebraucht

werden (speziell bei mobilen Applikationen z.B. Aussendienst).

Weitere Bereiche sind :

o Umfassende Planung zur Erhebung, Aufbewahrung, Klassifizierung und siche-ren Vernichtung von Datenbeständen.

o Rechtsverbindliche, finanzielle und historische Daten müssen für eine

angemessene Zeit, gemäß gesetzlichen, branchen- oder unternehmensverbind-lichen Fristen, sicher aufbewahrt werden.

o Unnötige Daten sollten gelöscht werden um Kosten und Aufwand zu sparen.

o Physische Sicherheit – Zugang zu Systemen; sicherer Zugang und Betrieb von

Datenverbindungen mit Geschäftspartnern und Unternehmensteilen. • ICT Infrastructure Management

Verantwortlich für Capacity und Availability Management.

2.3.2 Design Phase Die Design Phase ist eine der wichtigsten Phasen innerhalb des Application Lifecycles. Sie verarbeitet die Ergebnisse der Requirement Phase und erstellt aus ihnen Spezifikationen und Modelle auf deren Grundlage die Anwendung entwickelt wird. Im Allgemeinen werden in der Design Phase die gleichen Modelle wie in der Requirement Phase erstellt, jedoch werden diese sehr viel detaillierter ausgearbeitet. Neu hinzu kommen Modelle wie Deployment-Diagramme um die physische Aufteilung der Anwendungskompo-nenten (Komponenten-Diagramm) auf Systeme, Netzwerke und Datenbanken zu planen. Ein weiterer wichtiger Aspekt des Deployment Modells ist das Einfügen der Anwendung in die bestehende Infrastruktur. Welche Systeme können weiterverwendet werden mit was für Auswirkungen ? Welche sind zur Unterstützung der neuen Funktionalitäten erforderlich ? Sind eventuell bereits notwendige Funktionalitäten vorhanden, die eingebunden werden kön-nen ? Existieren bereits Lösungen, die verwendet werden können oder müssen sie von Grund auf neu entwickelt werden ? All diese Systemcharakteristiken sollten Dokumentiert werden. Die Design Phase bezieht alle Anforderungen in ihre Überlegungen mit ein und erstellt aus ihnen einen ersten Lösungsansatz. Dieser dient den Entwicklern als Basis, um mit der Arbeit zu beginnen. Ebenso können sich aus diesem ersten Ansatz noch Fragen ergeben, die mit dem



Institut für Angewandte Informatik Kunden geklärt werden müssen. Nach Möglichkeit sollte der Einsatz von Frameworks als Ausgangspunkt der Entwicklung dienen. Es ist nicht immer möglichen jeden Aspekt des Lösungsdesigns vorherzusehen. Während der Entwicklung werden sich sehr wahrscheinlich neue Vorgehensweisen und Methoden zur Umsetzung der Anforderungen erlernt oder entwickelt. Das Auftauchen ungeplanter Hinder-nisse erfordert oft eine Neubewertung des Verständnisses der Kundenanforderungen.

2.3.2.1 Design von Non-Functional Requirements / Manageability Das Design nicht funktionaler Anforderungen bedeutet ihnen die selbe Wichtigkeit zuzuord-nen wie den funktionalen und sie als erforderlichen – nicht zusätzlichen - Teil in die Design Phase einzubinden.

2.3.2.2 Risiko gesteuerte Terminierung Risiko gesteuerte Terminierung ordnet risikoreicheren Aufgaben eine höhere Priorität zu und berücksichtigt Risikoprioritäten für die Kundenanforderungen. Das bedeutet, dass die risiko-reichsten Aufgaben als erstes abgearbeitet werden, so dass im Falle eines Fehlers oder Fehl-planung mehr Zeit zur Lösung zur Verfügung steht und eine Beeinträchtigung des kritischen Projektablaufs vermieden wird.

2.3.2.3 Kompromissentscheidungen Kompromissentscheidungen konzentrieren sich darauf, die Beziehung zwischen Ressourcen, dem Projektplan und den zu implementierenden Funktionalitäten auszubalancieren. Oftmals geschieht dies auf Kosten der nicht funktionalen Anforderungen. Ein Weg dies zu verhindern ist die nicht funktionalen Anforderungen in den anwendungsunabhängigen Design- Richtlinien zu berücksichtigen, beispielsweise durch den Einsatz von Frameworks, die einen Teil der Anforderungen bereits implementieren.

2.3.2.4 Anwendungsunabhängige Design-Richtlinien und Frameworks Die Nutzung anwendungsunabhängiger Design-Richtlinien fördert die Manageability inner-halb einer Entwicklung, indem nicht funktionale Anforderungen bereits standardmäßig in den Design-Prozess integriert werden. Der Einsatz von Frameworks ist ein effizienter Weg diese in allen Design-Prozessen zu Standardkomponenten zu machen.

2.3.2.5 Organisation des Design Teams Neben den regulären Anwendungsentwicklungsrollen (Datenbank Design, GUI, Architektur etc.) die man im Design Team erwartet, werden auch hier wieder Rollen des Service Mana-gements benötigt, um sicherzustellen, dass die Application Management und Operation Perspektiven in die wichtigen Designentscheidungen eingebunden werden:




• Change and Configuration Management Berät das Entwicklungsteam beim Übergang der Anwendung vom Entwicklungs-/Testbetrieb zum Produktiveinsatz. Änderungsüberwachung, Status- und Versions-kontrollen, Softwareverteilung, Lizenzmanagement, Einsatzüberwachung und Außer-dienststellung sind weitere Bereiche in denen das Change and Configuration Manage-ment konsultiert wird. Eine weitere beratende Funktion besteht in der Integration automatischer Instrumenta-lisierungsfunktionen (z.B. für CMDB oder DMI) in das Anwendungssystem.

• Support Berät das Design Team im Hinblick auf die Vereinfachung des Zugriffs auf Support Informationen und die Integrierung von Support Funktionen direkt in die Anwendung. Dazu gehört zum Beispiel das Logging wichtiger Systemparameter oder die Bereit-stellung von „Speed Recovery“ oder Selbsthile-Funktionen (z.B. das Anlegen von Wiederherstellungspunkten um das System auf einen früheren, fehlerfreien Stand zurückzusetzen).

• Operations

Stellt sicher, dass die alltäglichen Anforderungen nicht aus den Augen verloren werden. Diese beinhalten die Einbindung der Anwendung in bestehende System Management Systeme, die Einplanung von regelmäßigen Prozessen wie Backups, Archivierung, Überwachung, Output- und Event Kontrolle und die generelle Überein-stimmung mit unternehmensweiten Standards.

• Security

Überwacht die Einhaltung der festgelegten Sicherheitsstandards hinsichtlich ihrer Berücksichtigung im Design der Anwendung, als auch im Entwicklungsteam selbst. Hierzu gehören unter anderem:

o Intrusion Detection und Virenschutz, o Denial of Service Prävention, o Festlegung von Standards zum sicheren Umgang und Speicherung von Daten, o Netzwerksicherheit, o Ergreifung von Gegenmaßnahmen im Ernstfall, o Durchsetzen von Benutzer Regeln wie Password Policies, o Physische Sicherheit, Zugriffs-/Zutrittskontrolle, o Sicherung von Kommunikation.

• ICT Infrastructure Management

Achtet darauf, dass die Anwendung im Hinblick auf ihren Ressourcenverbrauch berechenbar bleibt und den Kostenrahmen der dafür bereitgestellten Infrastruktur nicht verlässt, stellt Server Installationen, Images und Installationspakete zusammen und verrechnet den entstandenen Installationsaufwand.




2.3.3 Build Phase Nachdem die Design Phase abgeschlossen ist beginnt das Entwicklungsteam mit der Umset-zung der Entwürfe und dem Test der Anwendung. Auch in der Build Phase muss die Berück-sichtigung der nicht funktionalen Anforderungen sichergestellt sein.

2.3.3.1 Konsistente Programmierkonventionen Der Hauptgrund Programmierkonventionen zu verwenden ist die Struktur und Quellcodefor-matierung einer Anwendung zu standardisieren, so dass jeder den Entwicklungsprozess ohne Schwierigkeiten lesen, verstehen und managen kann. Gutes Design und Programmierricht-linien sorgen für einen präzisen, lesbaren und unzweideutigen Quellcode, der mit den Unter-nehmensstandards übereinstimmt und intuitiv nachvollzogen werden kann. Aus der operati-ven Perspektiven stellen diese Konventionen sicher, dass die Anwendung über ihren gesamten Lebenszyklus wartbar bleibt. Programmierrichtlinien können eine große Hilfe bei der Verwaltung und Kontrolle von Anwendungen sein, weil sie den Management Tools den Zugriff auf die Anwendung in gewohnter Weise erlauben. Im Allgemeinen ist es vorzuziehen, ein minimales Set an Konventionen zu verwenden an das sich alle halten, als ein übermäßig komplexes aufzustellen das von niemandem mehr vollständig umgesetzt werden kann.

2.3.3.2 Anwendungsunabhängige Erstellungsrichtlinien Templates, Code Generierung und Application Frameworks Eine Reihe von Tools bieten eine Vielzahl von Templates zur Erstellung gängiger Anwen-dungskomponenten. Anstatt alle Teile einer Anwendung von Grund auf neu zu entwickeln können die Entwickler existierende Templates anpassen. Ebenso ist eine Wiederverwendung eigener Komponenten in mehreren Anwendungen möglich. Andere Tools generieren große Abschnitte Quellcode (Skeletons) basierend auf den Design Modellen (z.B. Klassenmodell) und Programmierkonventionen. Der Code enthält Markierun-gen an denen eigener Code eingefügt werden muss. Application Frameworks können viele der nicht funktionalen Anforderungen abdecken, die dem Standard in ähnlichen Anwendungen entspricht. Templates und Frameworks stellen Werte dar. Diese Werte lenken nicht nur die Entwicklung, sondern enthalten auch das Wissen aus vorangegangenen Entwicklungsanstrengungen. Je mehr dieser Komponenten zur Verfügung stehen, desto schneller und langfristig kostengün-stiger läuft die Entwicklung. Eingebettete Anwendungsinstrumentarisierung In der Design Phase wurde das Konzept der Anwendungsinstrumentarisierung eingeführt, in der Build Phase geht es darum diese Komponenten in das Anwendungsgerüst einzufügen.



Institut für Angewandte Informatik Entwickler brauchen ein konsistentes Vorgehen bei der Einbindung von Instrumentarisie-rungsschnittstellen-Anwendungs-Treibern (z.B. Datenbanktreiber) und Anwendungen, das effizient und einfach zu implementieren ist. Um das Rad nicht mit jeder Anwendung neu erfinden zu müssen, stehen eine Reihe von Methoden und Technologien zur Vereinfachung dieses Prozesses bereit:

• IBM Application Management Specification (AMS), • Distributed Management Task Force (DMTF), • Desktop Management Instrumentation (DMI), • Microsoft Windows Management Instrumentation (WMI).

Jede dieser Technologien bietet ein konsistentes und umfangreiches beschreibendes Modell von Konfiguration, Status und operativen Aspekten von Anwendungen und Systemen. Es wird durch API’s zugänglich gemacht, die von den Entwicklern in die Anwendung eingefügt werden (z.B. durch Verwendung von Templates). Es ist wichtig, dass alle Anwendungen so entwickelt werden das sie konform zu einem Instrumentarisierungslevel sind. Wege dies zu erreichen sind:

• Zugriff auf Management Daten über API Wenn die Anwendung vom System bereitgestellte Managementfunktionen und –daten benutzt und diese Daten innerhalb des Instrumentarisierungs-Namespaces verfügbar sind, sollte der Zugriff auf sie über das Instrumentarisierungs-API erfolgen anstatt über native API’s. Dies beinhaltet normalerweise unterschiedliche Management Objekte, Performance Monitors und Event-Log-Daten. Das Instrumentarisierungs-API erlaubt eine größere Interoperabilität der Anwendungen und Management Informatio-nen. Ein Beispiel ist Microsofts WMI. WMI ist eine Technologie, die ein Framework bereitstellt um eine Anwendung zu Instrumentarisieren, so dass es möglich ist Funk-tionen wie beispielsweise Live Performance Monitoring zu nutzen.

• Bereitstellen von Management Daten für andere Systeme über API Verfügt die Anwendung über Managementfunktionen und –daten, die eine Kontrolle oder Überwachung der Anwendung aus anderen Anwendungen heraus erlauben, sollten diese über das Instrumentarisierungs-API zugänglich gemacht werden. Erzeugt die Anwendung Events, sollten auch diese über das Instrumentarisierungs-API an die verarbeitende Management-Anwendung weitergereicht werden.

• Einhalten der Regeln zur Erweiterung des gemeinsamen Namespace Dies bedeutet, dass die eingebettete Anwendungsinstrumentarisierung in einer Weise beschrieben wird, die nicht nur der Anwendungsentwickler versteht, sondern auch von anderen Entwicklern / Herstellern verwendet wird, damit alle Anwendungen koexistie-ren können und interoperabel bleiben. Es wäre schwierig für zwei Systeme zusam-menzuarbeiten, wenn die selben Objekte unterschiedliche Namen und Methoden hätten, die inkonsistent und untereinander unbekannt sind.




• Bereitstellung von Anwendungs-Event-Handling Ein Anwendungs-Event ist ein Ereignis das normalerweise Folgeaktionen auslöst. Dies kann vom simplen aufzeichnen des Events bis zum alarmieren des Sicherheits-teams reichen, wenn jemand versucht in das System einzubrechen. Die Erzeugung, Behandlung und Meldung von Events sowohl innerhalb als auch außerhalb des Anwendungsrahmens liefern die Schlüsselinformationen um zu verste-hen was die Anwendung gerade tut und wie sie arbeitet.

• Bereitstellung von Diagnosehooks Ein Diagnosehook erlaubt Überwachungs- und Debugging-Tools die Ausführung innerhalb verteilter Systeme zu überwachen und Diagnoseinformationen zu sammeln. Normalerweise stellt er Informationen zu Performance-Daten, Fehlerzuständen und Konfigurationseinstellungen bereit. Sie werden hauptsächlich eingesetzt um die Systemverfügbarkeit und –verlässlichkeit zu erhöhen. Fehler können immer auftreten und Diagnosehooks helfen die Downtime zu minimieren. Gute Diagnosehooks helfen bei der Identifizierung der Fehlerursache und stellen Informationen zur Fehlerbehebung bereit. Des weiteren helfen sie die Gesamtqualität der Systeme zu steigern, indem Fehlerursachen aufgezeichnet und analysiert werden. Ein gutes Vorgehen ist, Diagnosehooks zu nutzen, die sich an- und abschalten lassen. So kann im Falle eines Fehlers im Test- oder Produktiveinsatz relativ simpel an die benötigten Informationen gelangt werden, ohne die Performance zu beeinträchtigen. Diagnosehooks können in drei Kategorien aufgeteilt werden:

o System Level Information von Betriebssystem und Hardware, o Software Level Information der Systeminfrastrukturen wie Webserver,

Datenbanken etc., o Individuelle Informationen der einzelnen Anwendung.

Diagnosehooks sind von größtem Wert während der Testphase und wenn Fehler im Betrieb auftreten. Sie stellen die Informationen bereit, die nötig sind um Probleme und Anwendungsfehler zu lösen. Fehler treten selbst in gründlich getesteten Anwendungen auf. Während der Entwick-lung ist es für den Entwickler unmöglich an jede einzelne Fehlermöglichkeit zu denken und den Quellcode entsprechend zu gestalten. Jede Anwendung, egal wie auftragskritisch oder gut entwickelt, kann Fehler erleiden. Fehler können durch so einfache Dinge wie geändertes Trafficvolumen oder Benut-zungsmuster entstehen. Auch Hardwarefehler eines Server oder der Ausfall von Netz-werkkomponenten können zu Fehlern führen. Nicht zuletzt sind Änderungen innerhalb der Systemumgebung ein häufiger Grund für Fehler. Anscheinend kleine Änderungen können weitreichende Auswirkungen auf laufende Anwendungen haben. Die Änderung von Datenbankschemas zur Unterstüt-




zung neuer Anwendungen, die Inbetriebnahme neuer Systeme oder Änderung von Sicherheitsrichtlinien sind weitere Fehlermöglichkeiten.

2.3.3.3 Produktivtests Während die Anwendung entwickelt wird, muss sie gründlich getestet werden um sicherzu-stellen, dass sie alle funktionalen und nicht funktionalen Anforderungen erfüllt. Die Herangehensweise an Tests kann zu einem Großteil die Softwarequalität bei Auslieferung bestimmen. Viel zu oft wird das Testen an das Ende der Build Phase - kurz vor die Deployment Phase – verschoben und wird dann, vor allem wenn das Projekt schon außerhalb des Zeitplans liegt, beschleunigt oder gekürzt, was der Qualität abträglich ist. Qualität sollte in einem Softwareentwicklungsprojekt von Beginn an berücksichtigt werden und die Arbeitsabläufe des Entwicklungsteams sollten Tests als integrale und obligatorische Tätigkeit in jeder Stufe des Projekts enthalten. Der Test von nicht funktionalen Anforderungen wird oftmals vernachlässigt. Der Testplan sollte eine Sektion enthalten, die jede der nicht funktionalen Anforderungen beschreibt, welches Gebiet sie abdeckt und wie sie getestet werden soll. Ein Beispiel einer solchen Anforderung kann sein, das bei einem Systemausfall ein Ersatzsystem innerhalb von acht Stunden installiert und restauriert werden können muss. Viele Test-Typen sind angemessen, inklusive Tests die vom Entwicklungsteam durchgeführt werden, wie Unit-, System- und Integrationstests und Tests die hauptsächlich von separaten Test-Teams oder den Auftraggebern vorgenommen werden, wie Tests zur funktionalen Akzeptanz, User- und Produktions-Akzeptanz. Um einen qualitativ hochwertigen Übergang in die Deploy Phase zu gewährleisten, sollten Tests eine alles durchdringende Aktivität während der gesamten Build Phase sein. Genau wie die Anforderungen aus der Requirements Phase als Testbasis für die Arbeitsergebnisse der Design Phase genutzt werden können, können auch die Anforderungen der Design Phase als Testbasis für die Build Phase verwendet werden. Basierend auf dem Design der Anwendung kann das Test Team die Testpläne erstellen. Interne Design-Spezifikationen können zu Unit- und System-Tests, externe für Akzeptanz-Tests verwendet werden. Wenn eine Anwendung in mehreren Iterationen in Versionsschritten entwickelt wird, sollte jede dieser Versionen wieder gegen das gesamte Testpaket getestet werden. Diese „Regres-sionstests“ sind der einzige Weg sicherzustellen, dass sich keine Fehler in bereits entwickelte und getestete Komponenten einschleichen, was immer einmal vorkommen kann. Ein weiterer Weg sicherzugehen das die Testumgebung eine realistische Abbildung der Produktivumgebung darstellt, ist sie unter das gleiche Change und Configuration Manage-ment zu stellen als wäre es das Live-System.




2GG

A

Code-Review bezeichnet ein Peer-Review von Programmcode mit dem Ziel Fehler zu finden undzu beheben, die in der Entwicklungsphase übersehen wurden. Dadurch soll die Gesamtqualitätdes Programmcodes verbessert werden. Bei Code-Reviews können oft gängigeSicherheitslücken, wie Format String Attacks, Race Conditions oder Buffer-Overflows gefundenund entfernt werden. Online Software Repositories wie CVS erlauben es Gruppen von Individuengemeinschaftlich Code-Reviews durchzuführen, und damit Sicherheit und Qualtität desProgrammcodes zu verbessern. Unit-Tests (auch Komponententests) sind Teil eines Softwareprozess-Vorgehensmodells (z.B.Extreme Programming). Es handelt sich um ausführbare Codefragmente, die das sichtbareVerhalten einer Komponente (z.B. einer Klasse) verifizieren und dem Programmierer eineunmittelbare Rückmeldung darüber gibt, ob die Komponente das geforderte Verhalten aufweistoder nicht. Als Voraussetzung für Refactoring kommt ihnen besondere Bedeutung zu. Nach jederÄnderung sollte durch Ablaufenlassen aller Testfälle die Fehlerfreiheit überprüft werden. Beimtestgetriebenen Programmieren, auch TestFirst-Programmieren genannt, werden die Unit-Testsparallel zum eigentlichen Sourcecode erstellt und gepflegt. Dies ermöglicht bei automatisierten,reproduzierbaren Unit-Tests, die Auswirkungen von Änderungen sofort nachzuvollziehen. DerProgrammierer entdeckt dadurch sicher ungewollte Seiteneffekte oder Fehler durch seineÄnderung.

.3.3.4 Organisation des Build Teams enau wie in den Phasen zuvor soll auch bei der Organisation in der Build Phase der esamtkontext der Anwendung berücksichtigt werden.

• Change and Configuration Management Berät die Entwickler bei der Einbindung von Diagnosehooks und der Anwendungs-instrumentarisierung, so dass die Anwendung mit den Unternehmensstandards konform ist. Dies beinhaltet Komponenten Identifizierung, Change Control, Status-Reports, Versions-Kontrolle, Softwareverteilung, Lizenzkontrolle, Einsatzüber-wachung und Ausserdienststellung, sowie Beratung wie die Übereinstimmung mit obigen Punkten getestet werden kann.

• Support Hauptaufgabe des Support-Teams ist es, mit den Testern zusammenzuarbeiten, um sicherzustellen das es die Anwendung später supporten kann. Eine Ideale Aufgabe für das Support-Team wäre es, die Anwendung während der Testphase zu betreuen. So kann es den Entwicklern direktes Feedback über die dabei gemachten Erfahrungen liefern, so dass die „Supportbarkeit“ noch vor Inbetriebnahme berücksichtigt werden kann. Der Helpdesk könnte in die User-Akzeptanz-Tests involviert werden. Das hat den Vorteil, dass Endanwender Vorfälle über die gewohnten Kanäle berichten können und der Helpdesk schon vor Inbetriebnahme erste Erfahrungen mit der neuen Anwendung sammeln kann. Zudem kann das hinzufügen einer „diagnostischen“ Sichtweise hilfreich sein.

dvanced Application System Development Seite 19



• Operations Ähnlich wie beim Support sollte das Operations-Team an den Test beteiligt werden und idealerweise die Prozesse und Funktionen durchspielen, die bei der späteren Benutzung auftreten.

• Security Überwacht die Einhaltung der Sicherheitsstandards, führt Risikoanalysen durch, prüft Quellcode und Dokumentation, ist zuständig für die Sicherheitsaspekte des Testplans und prüft Kompromissentscheidungen auf Sicherheitsprobleme.

• ICT Infrastructure Management Berät die Entwickler bei der Einbindung von Kapazitäts- und Verfügbarkeitsmanage-ment Funktionen. Diese Rolle sollte dem Entwicklungsteam auch dabei helfen die Anwendung im Hinblick auf das in der Requirement Phase getroffene Service Level Agreement (SLA) zu entwickeln. Diese Punkte sollten auch in den Testplan aufge-nommen werden, um die SLA’s auf Realismus zu prüfen und Schwierigkeiten gege-benenfalls mit der Business-Seite besprechen zu können.

2.3.4 Deploy, Operate und Optimise Phase Die Deploy, Operate und Optimise Phase sollen in diesem Skript nicht weiter beschrieben werden, da sie nicht mehr direkt zum Softwareentwicklungsprozess gehören, sondern diesem nachgelagert sind. Entsprechende Informationen zu diesen Phasen lassen sich den angegebe-nen Quellen entnehmen.




3 Organisation Die Organisation oder auch Projektplanung soll das zukünftige Handeln so früh und so präzise wie möglich gedanklich vorwegnehmen. Die Planung orientiert sich an den fünf W-Fragen (wer, was wie, wann und wo).

W-Frage Aufgabe Methoden / Ergebnis Was ist wie zu tun ? Projekt aufgliedern Projektstrukturplan (PSP)

PSP Methoden Grafik PSP Prinzipien

Wer erledigt was ? Ressourcen zuteilen Arbeitspakete Beispiel AP-Definition

Was sind wichtige Ergebnisse ? Meilensteine setzen Meilensteinplan (MSP) Beispiel MS-Definition

Wann müssen die Arbeiten ausgeführt werden ? Welche Voraussetzungen müssen erfüllt sein ?

Ablauf festlegen

Terminplanung Balkenplan Netzplan Abhängigkeiten Kritischer Pfad und Puffer Vorwärtsrechnung Rückwärtsrechnung

Wie hoch sind Aufwand und Kosten ? Aufwandsschätzung Ressourcenplanung Aufwandsschätzung (z.B. Function Point Analyse)

Wie wird das Ziel effizient erreicht ? Plan straffen Planoptimierung Wo liegen die Projektrisiken ? Risiken abschätzen Risikoanalyse

3.1 Projektmanagement (allgemein) Unter Projektmanagement versteht man alle organisatorischen Verfahren und Techniken, die mit der erfolgreichen Abwicklung eines Projektes verbunden sind. Die Norm DIN 69901 definiert entsprechend Projektmanagement als die "Gesamtheit von Führungsaufgaben, -orga-nisation, -techniken und -mitteln für die Abwicklung eines Projektes". Gelegentlich wird, insbesondere wegen der Doppeldeutigkeit des engl. Wortes management, unter dem Projekt-management auch die organisatorische Ebene der Projektleitung verstanden.

3.1.1 Einführung Es gibt äußerst verschiedene Strukturen und Methoden des Projektmanagements. Ihre Wahl hängen von der Branche, der Art, der Größe und der Komplexität des Projekts ab. Mit der Durchführung eines Projektes kann eine einzige, aber auch mehrere tausend Personen befasst sein. Entsprechend reichen die Werkzeuge des Projektmanagements von einfachen To-Do-Listen bis hin zu komplexen Organisationen mit ausschließlich zu diesem Zweck gegründeten Unternehmen und massiver Unterstützung durch Projektmanagementsoftware. Werden mehrere Projekte gleichzeitig gesteuert und koordiniert, dann spricht man von Multi-projektmanagement. Multiprojektmanagement, das häufig etwa bei großen Baufirmen oder im Anlagenbau gefragt ist, stellt besondere Herausforderungen an die Beteiligten, weil hier kriti-sche Ressourcen über mehrere Projekte hinweg koordiniert werden müssen. Im Englischen



Institut für Angewandte Informatik existiert zudem der Ausdruck Program Management für das Management extrem großer, auf mehrere Jahre bis Jahrzehnte hin angelegter Projekte. Viele Begriffe und Verfahrensweisen im Projektmanagement sind mittlerweile etabliert und standardisiert. Im Rahmen der meisten universitären Studiengänge im Ingenieur-, Wirtschafts- und Informatikbereich werden Grundkenntnisse des Projektmanagements vermittelt. Diverse Institute bieten Zertifizierungen zum Projektmanager an, hier sind insbesondere die Deutsche Gesellschaft für Projektmanagement (http://www.gpm-ipma.de) sowie das amerikanische Project Management Institute (http://www.PMI.org) als maßgebliche Institutionen zu nennen. In wieweit eine Zertifizierung den guten Projektmanager ausweist, sei jedoch dahingestellt. Projektmanagement ist immer auch Krisenmanagement: In jedem Projekt treten ungeplante Situationen auf. Ein guter Projektmanager zeichnet sich dadurch aus, dass er solche Situatio-nen mit möglichst wenig Reibungsverlusten wieder in den Griff bekommt. Hier sind neben der Beherrschung des Handwerkszeugs insbesondere "weiche" Qualitäten gefragt, die sich einer Zertifizierung in der Regel entziehen.

3.1.2 Die 9 Wissensfelder des PM (siehe [1])

Abbildung 4: Wissenfelder des PM

Erfolgreiches Projektmanagement hat im Wesentlichen die folgenden Tätigkeits- oder Wissensbereiche abzudecken (nach Project Management Institute (http://www.pmi.org)):

• Integrationsmanagement: Hier werden die verschiedenen Elemente eines Projektes koordiniert. Die Einhaltung von Projektmanagement-Standards erleichtert dies.

• Umfangsmanagement (auch Scope Management): Das Management des Projekt-

rahmens (auch: Inhalts- und Umfangsmanagement) sorgt dafür, dass die gesetzten Projektziele erreicht werden. Es sorgt allerdings nicht nur für die Ergebnisorientierung




in Bezug auf die ursprünglichen Ziele, sondern hat insbesondere zur Aufgabe, notwendige Abweichungen von diesen Zielen, die im Projektverlauf deutlich werden, in das Projekt einzusteuern sowie entsprechende Neuplanungen zu veranlassen.

• Zeitmanagement: Zielt auf die Einhaltung des Zeitrahmens ab und sollte alle beteilig-

ten Zielgruppen einbinden. Der Projektplan dient dabei v.a. als Kommunikations-medium.

• Kostenmanagement: Zielt auf die Budgeteinhaltung ab. Hierfür ist der Kostenverlauf

zu erfassen. Gegebenenfalls sind Gegenmaßnahmen einzuleiten.

• Qualitätsmanagement: Projektspezifisches Qualitätsmanagement umfasst Standardisierung von Projektmanagement-Prozessen, Dokumentation der Arbeiten und Ergebnisse, sowie ein geeignetes Maßnahmenmanagement

• Ressourcenmanagement: Beinhaltet die effiziente Zuordnung der Ressourcen nach Fähigkeiten und verfügbaren Kapazitäten auf die Projektaufgaben, aber auch die Teamentwicklung.

• Kommunikationsmanagement: Nimmt häufig bis zu 50% der Projektarbeit ein und

schließt alle Beteiligten und Betroffenen ein; auch im Change Management zu berück-sichtigen.

• Risikomanagement: Projektspezifisches Risikomanagement. Beinhaltet Risikoanaly-

sen, präventive Maßnahmen und Notfallkonzepte. Insbesondere bei komplexen Projekten ist dies von Bedeutung.

• Beschaffungsmanagement: Integration und Zusammenarbeit mit Partnern und Liefe-

ranten.

3.1.3 Zielbereiche Um die benötigten Funktionen abzudecken, muss das Projektmanagement eine Reihe von Zielbereichen anvisieren, die es zu organisieren gilt. Dies sind im einzelnen:

• Die Projektorganisation, die die organisatorischen, insbesondere auch die personellen Rahmenbedingungen festlegt und Verantwortlichkeiten sowie Weisungsbefugnisse regelt.

• Die Projektplanung, die im Vorfeld versucht, das Projektrisiko durch zeitliche und

kapazitive Schätzungen und entsprechende Planungen zu verringern und Soll-Vorga-ben für den folgenden Bereich zu liefern:

o Die Projektsteuerung bzw. das Projektcontrolling, die das Projekt während

seines Verlaufs begleitet, Abweichungen vom geplanten Ablauf zu bemerken und das Projekt entsprechend umzusteuern hat.




3.1.4 Erfolgsfaktoren Projektmanagement ist weitaus mehr als lediglich die Anwendung von Planungstechniken. Unumstritten ist die große Bedeutung weicher Faktoren. Kommunikation, Change Manage-ment und ein für die Aufgaben geeignetes Projektteam sind häufig ausschlaggebend für den Erfolg von Projekten.

3.1.5 Formale Projektmanagementsysteme

• actiF: Agiler Entwicklungsprozess • Goal Directed Project Management (GDPM) • Hermes (EDV): Das (IT-)Projektführungsmodell der Schweizer Bundesbehörden

(http://www.isb.admin.ch) • PMBoK: PM-Standard des weltgrößten Projektmanagementverbandes PMI - Project

Management Institute • PRINCE2: weit verbreitete Projektmanagementmethode im Vereinigten Königreich

und den Niederlanden. (http://www.ogc.gov.uk/prince/) • Rational Unified Process • V-Modell: IT-Entwicklungsstandard der öffentlichen Hand in Deutschland

3.2 Umsetzung ITIL Ziel ist es anhand der Fragestellungen zur Projektplanung die aus dem Vorgehensmodell abgeleiteten Rollen und Verantwortlichkeiten mit Ressourcen zu besetzen und die einzelnen Aufgaben unter Berücksichtigung ihrer Abhängigkeiten zu terminieren. Ausgehend von der ITIL Prozessorganisation wird die Projektplanung mit Blick auf die unterschiedlichen Perspektiven erstellt.

Total Application Management

BusinessPerspective

ServiceManagement

InfrastructureManagement

Application Management Lifecycle

„Business“ „Technology“

Abbildung 5: ITIL Prozeßorganisation

Das bedeutet beispielsweise, dass im Projektplan nicht nur die eigenen Ressourcen – wie die zur Verfügung stehenden Entwickler - berücksichtigt werden müssen, sondern auch Aufgaben aus der Business Perspective (z.B. Reviews, Zwischenpräsentation etc.) und Service / Infra-structure Management (z.B. Einplanung von Wartungsfenstern um Downtimes niedrig zu halten).




4 Entwurf Der Entwurf beschäftigt sich mit der Modellierung des zu entwickelnden Anwendungs-systems. Siehe auch: „Neue Softwaretechnologien“ (Download Script unter http://www.dipl-inf.de) UML 2.0 Version siehe OMG (http://www.omg.org/uml) Literatur: z.B. Oestereich Objektorientierte Softwareentwicklung – Analyse und

Design mit der UML 2.0 Speziell: UML für EAI (Enterprise Application Integration) UML Profile and Interchange Models for EAI

4.1 Architektur Die Software-Architektur repräsentiert die früheste Softwaredesign-Entscheidung. Mit ihr werden alle Parameter wie Modifizierbarkeit, Wartbarkeit, Sicherheit, Performance etc. in gewissen Grenzen festgelegt und sind der in der Literatur vorherrschenden Meinung nach in späteren Entwicklungsphasen nur noch mit erheblichen Kosten- und Zeitaufwendungen abän-derbar. Die Entscheidung über das Design einer Software-Architektur ist somit eine der kritischsten und wichtigsten Punkte während des Software-Entwicklungsprozesses. Eine einheitliche Definition von Software-Architektur ist noch nicht gefunden, es existiert eine Vielzahl von parallelen Definitionen, von denen hier zwei wiedergegeben sind: "Eine Software-Architektur ist eine strukturierte oder hierarchische Anordnung der System-komponenten sowie Beschreibung ihrer Komponenten." (Balzert, S. 716) "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationship among them." (Bass, Clements, Kazman)




4.1.1 Architektur Grundtypen 1-tier: Die einfachste und älteste Form von Softwarearchitekturen ist die monolithische, heute auch in Anlehnung an die Nachfolger als 1-tier-Architektur bezeichnet.

Abbildung 6: 1-tier-Architektur

Sie zeichnet sich dadurch aus, dass sie von der Oberfläche bis zur Datenhaltung alle Funktio-nen in sich kapselt. Dem immensen Aufwand, den die Entwicklung einer solchen Anwendung kostet, steht aus heutiger Sicht lediglich der Vorteil der absoluten Kontrolle über das komplette Anwendungssystem gegenüber, der sich jedoch auch nur bis zur Betriebssystem-grenze erstreckt. Die Nachteile dieser Architektur ergeben sich aus dem monolithischen Aufbau selbst, der eine schlechte Wartbarkeit zur Folge hat und die Wiederverwendung von / als Komponenten verhindert. 2-tier: Architekturen diesen Typs werden zusammen mit den 3- und mehrschichtigen schon zu den Client-Server-Architekturen gezählt, da die hier vorgenommene logische Aufteilung in Programmkomponenten meist auch mit einer physischen Trennung der Implementierungen einhergeht.


Die Anwendung wird bei diesem Modell in Ein-/Ausgabeverarbeitung und Datenverarbei-tung/-haltung getrennt. Der erhöhte Aufwand der nötig ist um die nun getrennten Programm-teile - teilweise über Rechnergrenzen hinweg - zu verbinden, wird durch das Konzept der



Institut für Angewandte Informatik Wiederverwendung von Programmkomponenten kompensiert. Auf Seite der Oberfläche werden dazu standardisierte Komponenten der Betriebssysteme verwendet, die die Ausgabe- und Eingabeverarbeitung übernehmen und an die Datenverarbeitung – die eigentliche Anwendung - weiterleiten. 3-tier / Multi-tier: Wird aus der 2-tier-Architektur zusätzlich noch die Datenhaltung ausgegliedert, ergibt sich eine 3-tier-Architektur.


Der Aufwand, eine Anwendung innerhalb dieser Architektur zu realisieren, beschränkt sich hier fast nur noch auf das Erstellen einer geeigneten Verarbeitungslogik. Die restlichen Teile des Systems stehen in Form von standardisierten Komponenten zur Verfügung und bedürfen lediglich noch der Anpassung an die eigenen Bedürfnisse, das aufwendige Programmieren eigener Verfahren und Schnittstellen ist nicht mehr nötig. Der Komfort dieser Lösung wird durch einen erhöhten Verwaltungs- und Kommunikationsoverhead erkauft, der in den heuti-gen Systemumgebungen jedoch vernachlässigbar ist. Für die Kommunikation zwischen den einzelnen Komponenten ist wiederum eine Komponenten zuständig, die so genannte Middle-ware. Beispiel hierfür sind Microsoft: DCOM / OLE und OMG: CORBA.

4.1.2 Beispiel: Microsoft Windows (MFC, alt) Der Weg eine Anwendung für Microsoft Windows zu schreiben führt über die bereitgestellten Klassen (Komponenten) des Betriebssystems. Betrachtet man sich den Aufbau der nachfol-genden Diagramme wird deutlich wie groß der Teil der zur Wiederverwendung bereitstehen-den Komponenten ist.

Abbildung 9: Windows Anwendung



Institut für Angewandte Informatik Das Windowssystem und die darauf aufbauenden Anwendungen bauen auf einer bestehenden Klassenhierarchie (MFC, Microsoft Foundation Classes) auf, die zur Erstellung eigener Anwendungen an die eigenen Bedürfnisse angepasst (erweitert) werden kann.

Abbildung 10: Windows Klassenhierarchie (MFC)

Die erstellte Anwendung setzt sich also aus vorhandenen Klassen des Windowssystems und selbst erstellten Komponenten zusammen.

Abbildung 11: Windows-Anwendung (MFC)




4.1.3 Wie entsteht eine Anwendungsarchitektur Ziel einer Anwendungsarchitektur ist es, den systematischen Aufbau einer Anwendung zu dokumentieren. Kernaufgabe: Zerlege das System in eine geeignete Anzahl / Form zusammenarbeitender Subsysteme und entwerfe die Kommunikation dieser Subsysteme.

Kunde

Webanwendung Buchhandel

Buch kaufen

Ausschnitt Use Case

+addtocart()

Einkaufswagen

Ausschnitt Klassenmodell(fachlich)

Oberflächenschicht Verarbeitungsschicht Datenhaltungsschicht

Fachliche Ebene

Technische Ebene(Designebene)

Webgrafik Oberflächenfunktionalität der AnwendungBannerseite

ShoppingcartShoppingcart.aspx Shoppingcart.aspx.vb

(Code Behind)

Ebenen zur Aufbereitungder Grafik .aspx

Verarbeitung Datenhaltung

Beschreibung der SeitenBeschreibung der Grafik

Abbildung 12: Ebenenmodell ASP.Net



Institut für Angewandte Informatik Anwendung dieses Architekturprinzips auf Unternehmensanwendungen – Beispiel SAP Präsentation 1 (Client)

Präsentation 2 (Server) Anwendungsschicht

(Verarbeitung) Datenzugriff Operative Daten Auswertungsdaten

Abbildung 13: SAP Anwendungsarchitektur

[Quelle: Technische Integration von SAP-Systemen (SAP-Press 2003)]



Institut für Angewandte Informatik 4.2 Exkurs: UML-Modellierung Aufgabe: Erstellen Sie ein Objekt- und ein Klassenmodell

Abbildung 14: Ausgangssituation UML-Modelleierung

Abbildung 15: Objektmodell

Abbildung 16: Klassenmodell (Variante 1)

Abbildung 17: Klassenmodell (Variante 2)




4.3 Systementwurf Die Basis für den Systementwurf bildet die durchgeführte Anforderungsanalyse. Die z.B. aus Kundengesprächen gewonnenen Informationen werden mit den Werkzeugen der UML struk-turiert und modelliert. Da der Systementwurf die Schnittstelle zwischen Kunde und Entwicklungsteam darstellt, findet die Ausarbeitung auf zwei Ebenen statt:

• Fachliche Ebene (Kundenebene) – Was soll das System für wen leisten, welche Objekte sind betroffen, Zusammenfassen von Anforderungen / Funktionalitä-ten zu Komponenten / Modulen

• Design Ebene (technische Ebene) – Wie und mit welchen Mitteln soll das

System die Funktionalitäten bereitstellen, wie sieht der Ablauf aus. Die techni-sche Ebene stellt oftmals eine detailliertere Version der fachlichen Strukturen dar.

Anhand eines einfachen Beispiels - Einzahlung auf ein Konto - sollen die einzelnen Schritte und Methoden zur Erstellung eines Systementwurfs verdeutlicht werden.

4.3.1 Schritt 1: Use Case Diagramm erstellen Use Case Diagramme dienen dazu festzulegen welche Geschäftsprozesse das Anwendungs-system unterstützen soll und wer sie nutzt. Ein Use Case Diagramm besteht aus zwei Kompo-nenten: Anwendungsfälle welche die Funktionalitäten (Services) des Systems darstellen und Akteure die diese nutzen. Ein Anwendungsfall stellt einen in sich geschlossenen Ablauf dar, der von Außen angestoßen wird und mit einem definierten Ergebnis endet. Akteure können die Benutzer des Systems sein, aber auch andere Systeme. Unser Beispielsystem soll einem Kunden ermöglichen etwas auf sein Konto einzuzahlen.

Abbildung 18: Use Case Diagramm




4.3.2 Schritt 2: Klassenmodell (fachlich) Aus dem Use Case Diagramm wird das fachliche Klassenmodell entwickelt. Es identifiziert die am Geschäftsvorfall beteiligten Objekte und ihre Beziehungen untereinander. In unserem Fall gibt es nur ein Objekt das bearbeitet wird – das Konto auf das etwas eingezahlt werden soll.

Konto

Abbildung 19: Fachliches Klassenmodell

4.3.3 Schritt 3: Klassenmodell (technisch) Aufbauend auf dem fachlichen Klassenmodell findet der Übergang in die Designebene statt. Die identifizierten Objekte (Klassen) werden weiter detailliert und auf technischer Ebene klassifiziert. Sie erhalten Attribute (Eigenschaften) und Methoden.

+Methode()-AttributDialog Konto

+Methode()-AttributVerarbeitung Konto

+Methode()-AttributDatenhaltung Konto

Abbildung 20: Technisches Klassenmodell

4.3.4 Schritt 4: Komponentenmodell Das Komponentenmodell beschreibt die Organisation der Teilkomponenten des Systems und ihre Abhängigkeiten untereinander. Es stellt den Übergang zum physischen Entwurf dar.

GUI Verarbeitung Datenhaltung

CKonto CKontoDBCWinMain CFrameWnd CDialogK

Abbildung 21: Komponentenmodell

Verarbeitungsklassen der GUI eigene Datenzugriffsklasse Verarbeitungsklasse für Kunde




GUI COM

GUI Verarbeitung

COM CKonto

„Middleware“Stellt die Schnittstellen bereit

und die Verbindung her Abbildung 22: Komponenten Abhängigkeiten

4.3.5 Schritt 5: Deployment Diagramm Das Deployment Diagramm stellt die Konfiguration des Laufzeitsystems auf physischer Ebene dar. Die Komponenten des Systems werden dabei auf Hardwarekomponenten verteilt.

Production ServerKontoverwaltung

GUI Verarbeitung Datenhaltung

<<supports>><<supports>>

<<supports>>

Implementierung aufeinem PC zu Testzwecken

Abbildung 23: Deployment Diagramm

4.4 Oberfläche Das Grundkonzept von Oberflächen besteht in der Trennung von GUI und Fachkonzept. Sie stellen dem Anwender eine Schnittstelle zur Verfügung, über die er die Funktionalitäten der Anwendung nutzen kann.

4.4.1 Architektur eines Oberflächenmodells Model-View-Controler-Architektur (MVC): Diese Architektur basiert auf einem weit verbreiteten, objektorientierten Entwurfsmuster (Design Pattern) und strukturiert die Verant-wortlichkeiten in der Präsentationsschicht einer Applikation. Dabei werden die drei Kompo-nenten Model (Fachobjekte mit Status, Persistenz), View (Darstellung, Sicht auf die Fach-objekte) und Controller (Workflow, Benutzersteuerung) unterschieden.



Institut für Angewandte Informatik Anhand des Model-View-Controler Konzeptes soll beispielhaft die Architektur eines Oberflä-chenmodels skizziert werden:

Abbildung 24: Model-View-Controler Architektur [6, S. 692ff]

View- und Controller-Komponente bilden zusammen das User-Interface. Wenn auf Basis derselben Model-Komponente mehrere voneinander unabhängige Darstellungen existieren, muss die eine immer „erfahren“, ob die andere geändert wurde. Dazu übernehmen die User-Interfaces die „Observer“-Rolle (Beobachter), das Model die „Observeable“-Rolle (Subjekt). Ändert einer der Controller den Dateninhalt (Model), benachrichtigt dieses alle angemeldeten Beobachter, die daraufhin ihre Darstellung aktualisieren. Die Umsetzung in ein Klassenmodell anhand des Architekturentwurfs:

Abbildung 25: Model-View-Controler Klassenmodell




4.4.2 Dialoggestaltung Aufgaben angemessen:

• Keine Vor-/Nacharbeiten • Ablaufangepasst • Abbildung wiederholter Arbeitsabläufe möglich • Eingaben geeignet vorbelegt

Selbstbeschreibend:

• „Mentales“ Modell • bekannte Oberflächenlayouts berücksichtigen

(z.B. The Windows I/F Guidelines for SW-Design, MS-Press) • Erläuterungen (Hilfefunktion [Menü „?“], kontextbezogene Hilfe)

Steuerbar: • Arbeitsgeschwindigkeit Bedienung • Frei wählbare Arbeitswege • Information über sinnvolle Wege • Aufsatzpunkte (z.B. für Unterbrechen des Dialogs) • Undo / redo • Sicherheitsabfragen bei kritischen Eingriffen • Steuerung der Informationsmenge • Anzeigen zum Schritt, der (als nächstes) durchgeführt wird

Erwartungskonform:

• Einheitliches Layout • Ähnliches Layout (gleiche Aufgaben = gleiches Layout) • Anzeige über Arbeitsstatus (Durchführung des Systems) • Erwartungsgemäße Systemantwortzeiten

Fehlertolerant:

• Fehlertestverfahren Rückinfo an Anwender • Automatische Korrektur (abschaltbar!) • Korrekturhinweise • Fehlermeldung zu Fehlerort

Lernförderlich:

• Darstellung von Regeln • Lernhinweise (Strategie) • Zusatzinfo für wenig genutzte Befehle • Nach Regeln aufgebaute Oberfläche




4.5 Wiederverwendung „…object-orientation is not a magic formula to ensure reusability however. Reuse does not just happen; it must be planned by thinking beyond the immediate application and investing extra effort in a more general design.” (Rumbaugh, 1991) Erfahrungswissen ist die Voraussetzung für wiederverwendbare Entwürfe. Erfahrungen benö-tigen aber Zeit und setzen ein Erproben und Verwerfen von Entwürfen voraus. Das Projekt-geschäft lässt aber nur selten Zeit, das Versuch-und-Irrtum-Prinzip auszuleben. Hieraus erge-ben sich zwei Fragestellungen:

• Wie kann der Unerfahrene aus der Erfahrung des Experten lernen ? • Wie kann der Experte seine Erfahrungen umfassend und in kürzester Zeit Vermitteln ?

Wiederverwendung ist eines der wichtigsten Ziele der heutigen Softwareentwicklung. Wiederverwendung kann auf Programmier-, Entwurfs- und Analyseebene erfolgen. Als Basis für ihre Realisierung werden fast ausschließlich objektorientierte Techniken wie Frameworks, Komponenten und Entwurfsmuster eingesetzt.

4.6 Entwurfsmuster Ein Entwurfsmuster (englisch: design pattern) beschreibt eine in der Praxis erfolgreiche Lösung für ein mehr oder weniger häufig auftretendes Entwurfsproblem und stellt damit eine wiederverwendbare Vorlage zur Problemlösung dar. Entstanden ist der Ausdruck in der Architektur, von wo er für die Softwareentwicklung übernommen wurde. In den letzten Jahren hat der Ansatz der Entwurfsmuster auch zunehmendes Interesse im Bereich der Mensch-Computer-Interaktion gefunden. Erich Gamma promovierte Mitte der neunziger Jahre an der Universität Zürich über die Übertragung dieser Methode auf die Softwareentwicklung. Im Anschluss ging er in die Verei-nigten Staaten von Amerika, wo er zusammen mit Richard Helm, Ralph Johnson und John Vlissides das Buch Design Patterns - Elements of Reusable Object-Oriented Software heraus-brachte. Diese vier Autoren sind unter Entwicklern auch unter ihrem Spitznamen "Gang of Four" (Viererbande, kurz "GoF") bekannt. Gelegentlich wird GoF auch als Verweis für besagtes Buch verwendet. Die Beschreibung eines Entwurfsmusters folgt dem folgenden Schema:

• Zweck des Musters. • Synonyme: Andere bekannte Namen des Musters. • Motivation: (Hinter-)Gründe für den Einsatz des Musters. • Anwendbarkeit: Einsatzbereiche für das Muster. • Struktur: Beschreibung der allgemeinen Struktur des Musters. • Beteiligte: Klassen, die an dem Muster beteiligt sind. • Zusammenspiel der beteiligten Klassen. • Konsequenzen: Welche Vor- und Nachteile gibt es?




• Implementierung: Code-Beispiele. • Praxiseinsatz: Wo wird das Muster bereits eingesetzt? • Querverweise: Wie spielt das Muster mit anderen Mustern zusammen?

Der primäre Nutzen eines Entwurfsmusters liegt in der Beschreibung einer Lösung für eine bestimmte Klasse von Problemen. Weiterer Nutzen ergibt sich aus der Tatsache, dass jedes Muster einen Namen hat. Dies vereinfacht die Diskussion unter Softwareentwicklern, da man abstrahiert über eine Softwarestruktur sprechen kann. So sind Entwurfsmuster zunächst einmal unabhängig von der konkreten Programmiersprache. Wenn der Einsatz von Entwurfsmustern dokumentiert wird, ergibt sich ein weiterer Nutzen dadurch, dass durch die Beschreibung des Musters ein Bezug zur dort vorhandenen Diskus-sion des Problemkontextes und der Vor- und Nachteile der Lösung hergestellt wird.

4.6.1 Grundlegende Muster nach GoF Nach GoF werden Muster in drei Kategorien eingeteilt, die nach der Wirkung des jeweiligen Musters unterscheiden: Die erste Gruppe von Mustern bezieht sich auf die Erzeugung von Objekten. So kann man etwa die Anzahl von erzeugten Objekten einer Klasse kontrollieren wollen, oder man will den konkreten Typ der erzeugten Objekte - abhängig von den jeweili-gen Bedingungen - anpassen. Die zweite Gruppe liefert Muster, welche eine Vereinfachung der Struktur zwischen Klassen ermöglichen sollen. Komplexe Beziehungsgeflechte können beispielsweise über vermittelnde Klassen oder Schnittstellen logisch vereinfacht werden. Die dritte Gruppe von Mustern betrifft das Verhalten der Klassen. Hierbei handelt es sich um die größte Gruppe von Mustern. Sie beziehen sich auf die Zusammenarbeit und den Nachrichten-austausch von Klassen.

4.6.1.1 Erzeugungsmuster (Creational Patterns) Erzeugungsmuster beschreiben Vorgehensmodelle zur Erzeugung von Objekten.

• Abstrakte Fabrik (Abstract Factory, Kit) • Erbauer (Builder) • Fabrikmethode (Factory Method, Virtual Constructor) • Prototyp (Prototype) • Einzelstück (Singleton)

4.6.1.2 Strukturmuster (Structural Patterns)

• Adapter (Adapter, Wrapper) • Brücke (Bridge, Handle/Body) • Kompositum (Composite) • Dekorierer (Decorator, Wrapper) • Fassade (Facade) • Fliegengewicht (Flyweight) • Stellvertreter (Proxy, Surrogate)




4.6.1.3 Verhaltensmuster (Behavioral Patterns)

• Zuständigkeitskette (Chain of Responsibility) • Kommando (Command, Action, Transaction) • Interpreter (Interpreter) • Iterator (Iterator, Cursor) • Vermittler (Mediator) • Memento (Memento, Token) • Beobachter (Observer, Dependents, Publish-Subscribe) • Zustand (State, Objects for States) • Strategie (Strategy, Policy) • Schablonenmethode (Template Method) • Besucher (Visitor)

4.6.2 Beispiel für den Entwurf eines Musters Problem: Gesucht ist ein Lösungsansatz der es ermöglicht in allgemeiner Form die Realisierung unter-schiedlicher User-Interfaces (GUI’s) einheitlich zu beschreiben. Anwendungsbeispiel: Erzeuge eine Scrollbar unter „Motif“ und als „MacMenue“. Erster Ansatz:

scrollbar * scrollbar = new motifscrollbar;

Lösung in der Anwendung, die abhängig ist von der Umgebung. Besser:

scrollbar * scrollbar = Guifabrik->erzeugeScrollbar();

Der Aufruf „erzeugeScrollbar()“ ist unabhängig von der Umgebung, die Klasse „Guifabrik“ ist zuständig für die Erzeugung des richtigen Formats.



Institut für Angewandte Informatik Erzeugen von Klassen entsprechend dem Umfeld:

Guifabrik

+erzeugeScrollbar()

Motiffabrik

+erzeugeScrollbar()

Macfabrik

return new motifscrollbar; return new macscrollbar;

Abbildung 26: Klassenfabrik

Wie arbeitet die GUI Fabrik ?

//Code zum erzeugen der Fabrik Guifabrik * Guifabrik; const char * stilname = getenv(„Look and Feel“); if(strcmp(stilname, “Motif”) == 0) { Guifabrik = new Motiffabrik; }




5 Anwendungstechnologie

5.1 Frameworks Wörtlich übersetzt bedeutet Framework (Programm-) Gerüst, -Rahmen oder -Skelett. Dies drückt aus, dass die Grobarchitektur bereits vorgegeben ist, und dass nur noch an ganz bestimmten Stellen applikationsspezifischer Code "eingehängt" wird. So gesehen definiert ein Framework eine Standard-Softwarearchitektur. Die eigentliche Applikation umfaßt also kein Hauptprogramm mehr sondern wird von Framework-Komponenten aus aufgerufen, im Gegensatz zur Programmbibliothek (Toolkit), wo die Komponenten vom individuellen Programm aus aufgerufen werden. Ein Framework ist immer auf eine spezielle Klasse von Applikationen und damit speziellen Anwendungsbereich ausgerichtet; Beispiele sind Frameworks für graphische Editoren, Buch-haltungssysteme oder elektronische Warenhäuser im WWW. Das im Framework enthaltene Hauptprogramm realisiert das gemeinsame Verhalten aller Applikationen dieses Anwen-dungsbereichs. Technisch gesehen besteht ein Framework aus einer Reihe von Klassen bzw. Bibliotheken. Analog zu Bibliotheken sind diese für die Entwurfstätigkeit irrelevant und werden daher in einer Architektur nicht oder nur rudimentär dargestellt. Aus der Sicht der objektorientierten Computer-Programmierung ist ein Framework ein Nicht-Lauffähiges Klassenmodell, welches durch Vererbung der Methoden oder durch Delegation an Framework-Klassen und durch einen definierten Einstiegspunkt eine spezielle Anwendung realisiert.

Abbildung 27: Framework (allgemein)




5.2 Microsoft .NET .NET ist ein Satz von Softwaretechnologien des Softwareherstellers Microsoft, der als Gegenpol zu Sun Microsystems Java eingeführt wurde, und neben einer virtuellen Laufzeit-umgebung aus einem Rahmenwerk (Framework) von Klassenbibliotheken (API) und Dien-sten besteht, die als Basis für Eigenentwicklungen dienen. Einfach gesprochen handelt es sich also um eine umfangreiche Programmierumgebung, die eine neue Generation von Program-men und damit auch der Programmierung einläuten soll. Keine der verwendeten Technolo-gien ist völlig neu, aber in der Gesamtheit ist .NET eine Innovation.

Abbildung 28: Microsoft .NET (siehe [7])

Abbildung 29: .NET Dienste (siehe [7])




5.2.1 Ausblick • Für 2005 ist die nächste Version von .NET V2.0 und Visual Studio 2005 angekündigt,

die neben starken Erweiterungen der Klassenbibliothek einige Vereinfachungen des Programmiermodells mit sich bringen soll.

• 2006–2007 Nachfolgetechnologien als Bestandteil des Windows-XP-Nachfolgers mit

Codenamen "Longhorn" sollen die Redundanzen in aktuellen .NET-Teiltechnologien beseitigen, insbesondere die APIs zur Web- und Windows-Oberflächenprogrammie-rung vereinheitlichen und ein fortschrittliches Konzept für verteilte und insbesondere serviceorientierte Architekturen bereitstellen und damit das weitgehend unstrukturierte Nebeneinanderher von Web Services, .NET Enterprise Services und .NET Remoting Services beseitigen.

5.2.2 Konzept Die .NET-Plattform stellt mit der Common Language Infrastructure (CLI) eine Basis zur Ausführung von Programmen, die mit unterschiedlichen Programmiersprachen erstellt wurden, her. Dies wird durch die Verwendung einer (objektorientierten) virtuellen Maschine (CLR) und die Framework Class Library (FCL) – einer gemeinsamen Klassenbibliothek – erreicht.

Abbildung 30: Laufzeitumgebung und Klassenbibliotheken vor .NET (siehe [8])




Abbildung 31:Laufzeitumgebung und Klassenbibliotheken in .NET (siehe [8])

5.2.3 CLR, CIL, Garbage-Collection und Reflection Die Common Language Runtime (CLR) ist die virtuelle Maschine (VM) von .NET und stellt somit die Laufzeitumgebung für verschiedene an .NET angepasste Hochsprachen zur Verfü-gung. Die VM führt den standardisierten Zwischencode der Common Intermediate Language (CIL) aus. Die CIL hieß früher Microsoft Intermediate Language (MSIL), wurde aber im Rahmen der Standardisierung durch die ECMA umbenannt. Für die CIL wurde ein sprach-übergreifendes System von objektbasierten Datentypen definiert, so dass auch in unterschied-lichen Sprachen geschriebene Programmteile auf gemeinsame Ressourcen zugreifen können. Das von Vorneherein im Gesamtkonzept berücksichtigte Nebeneinander mehrerer Program-miersprachen unterscheidet .NET von anderen auf Zwischencode basierenden Laufzeitumge-bungen (z.B. Java Virtual Machine, siehe Java).

5.2.4 Managed und Unmanaged, Interoperabilität In der .NET-Sprache gelten alle Programme, die innerhalb der CLR laufen, also für .NET geschrieben wurden, als managed -- alle anderen, insbesondere ältere Programme, damit quasi abwertend, als unmanaged. Mit Hilfe der so genannten Interop-Technik lassen sich insbeson-dere traditionelle (Microsoft-)COM-Programme mit .NET-Hüllen versehen und danach deren Klassen wie .NET-Klassen aufrufen. Umgekehrt lassen sich auch .NET-Klassen wie COM-Klassen aufrufen. Damit soll eine fließende Umstellung von Projekten auf .NET ermöglicht werden. Die bisher einzige Sprache, mit der man sowohl managed als auch unmanaged Code in einer einzigen Programmdatei mischen kann, ist C++/CLI (Managed C++).




5.2.5 Verteilte Programmierung und Web Services Microsoft bietet hier nicht einen übergreifenden Ansatz, sondern gleich (mindestens) drei unterschiedliche, mit jeweils eigenen Vor- und Nachteilen: eine moderne Implementierung des ersten neuen Industriestandards des 21. Jahrhunderts, Web Services (manchmal auch "XML Web Services" genannt), eine Architektur für verteilte Programme (im Wesentlichen im LAN), die .NET Remoting Services, und die .NET Enterprise Services. Letztere sollen eine Konkurrenztechnologie zu der erfolgreichen J2EE werden, aber obwohl diesmal Microsoft Ende der 1990er Jahre mit dem MTS (Microsoft Transaction Server) eine weithin unbeachtete Innovation lieferte, reagierte Sun und bildete eine vergleichbare Technologie nach, und zwar kommerziell erfolgreich, so dass die Microsoft-Technologie in diesem umsatzstarken Unter-nehmensmarkt bislang noch keine Rolle spielt.

5.2.6 Laufzeitumgebung (CLR) "Managed code" wird wie oben erwähnt von der Laufzeitumgebung Common Language Run-time (CLR) verwaltet. Diese virtuelle Maschine übernimmt die Anforderung und Freigabe von Speicher und anderen Ressourcen (Garbage-Collection) und stellt sicher, dass geschützte Speicherbereiche nicht direkt angesprochen oder überschrieben werden können. Auch Zugriffe auf Dienste, Dateisystem-Funktionen oder Geräte können überwacht werden und werden, sofern sie gegen Sicherheitsrichtlinien verstoßen, von der CLR abgelehnt.

Abbildung 32: CLR-Aufbau (siehe [7])

5.2.7 .NET Framework - Klassenbibliothek (FCL) Die Framework Class Library (FCL) ist die Realisierung einer Klassenbibliothek mit einem durchgängigen Konzept, die von allen Sprachen vollständig und einheitlich genutzt werden kann. Sie umfasst einige Tausend Klassen, die in so genannte Namensräume (Namespaces) unterteilt sind. Die Klassen erfüllen Aufgaben wie z.B. das Formatieren von Text, das Verschicken von E-Mails, aber auch das Generieren von Code. Die Unterteilung in Namens-räume dient dazu, die große Menge an Informationen übersichtlicher zu gestalten. Beispiels-weise befinden sich Klassen zum Generieren von Code in dem Namensraum System.Reflection.Emit. Die Dokumentation der Klassen liefert der Hersteller in seinem Software Development Kit (SDK) mit (siehe unten).




5.2.8 Typhierarchien Das .NET Framework unterstützt bezüglich Typen drei Hierarchiekonzepte:

• Namespace-Hierarchie Typen haben hierarchische Namen, was durch die Organisation von Typen in Namespaces erreicht wird. Die Namespacehierarchie ist ein Baum ohne Zyklen.

Abbildung 33: Namespace-Hierarchie (siehe [8])

• Vererbungshierarchie

Klassen und Schnittstellen (nicht aber die anderen beiden Arten von Typen) können voneinander erben, allerdings ist immer höchstens eine explizite Vererbungsbeziehung möglich. Die Vererbungshierarchie ist daher ein Baum ohne Zyklen. Die Klasse System.Object ist dabei immer die oberste Klasse.

Abbildung 34: Vererbungshierarchie (siehe [8])




• Objektmodell Instanzen von Typen können (müssen aber nicht !) zur Laufzeit in Beziehung stehen. Daraus ergibt sich eine Objekthierarchie, die Objektmodell genannt wird. Da die Objektbeziehungen beliebig sind, ergibt sich ein Graph, der möglicherweise auch Zyklen enthält.

Abbildung 35: Objektmodell (siehe [8])

5.2.9 Programmausführung (CIL) Der Compiler für .NET-Sprachen erzeugt keinen Maschinencode der direkt vom Prozessor ausgeführt werden kann. Stattdessen wird ein Zwischencode, die sogenannte Common Inter-mediate Language (CIL) erzeugt. Dieser besteht aus Befehlen, die auf der Stack-basierten virtuellen Maschine (VM) ausgeführt werden. Die resultierenden Programme haben wie andere Programme unter Windows, eine ".exe"-Erweiterung. Dies wird durch eine kleine Routine am Anfang des Programmes ermöglich, die die virtuelle Maschine startet, welche wiederum den Zwischencode ausführt. Wenn das Programm ausgeführt wird, übersetzt ein JIT-Compiler, der in der Laufzeitumge-bung Common Language Runtime (CLR) enthalten ist, den Zwischencode in Maschinencode, der dann vom Prozessor direkt ausgeführt werden kann. Da Code aus allen .NET-Sprachen in die selbe Zwischensprache übersetzt wird, können Funktionen und Klassenbibliotheken, die in verschiedenen .NET-Sprachen geschrieben sind, problemlos gemeinsam in einem Programm verwendet werden.




5.2.10 Assemblies Übersetzte Programmklassen werden als ausführbare Programme in so genannten Assemblies zusammengefasst und bereitgestellt (vgl. mit Packages/Paketen in Java). Diese haben typischerweise die altbekannten Endungen .exe oder .dll, sind intern jedoch völlig anders strukturiert. Insbesondere sind im so genannten Manifest alle notwendigen Metadaten aufge-führt, so dass für reine .NET-Programme in der Regel die gewohnte, aber aufwändige und fehlerträchtige Registrierung, wegfällt (Ausnahme z.B. COM+/Enterprise Services). Assemblies können entweder privat, gemeinsam (shared) oder global sein. Private Assem-blies befinden sich in dem selben Programmverzeichnis, wie die auszuführende Anwendung. Daher wird angenommen, dass die Version des Assemblies kompatibel zur Anwendung ist und daher nicht von der CLR geprüft wird. Ein gemeinsames (shared) Assemblie kann sich in einem Verzeichnis befinden, auf das von mehreren Anwendungen zugegriffen wird. Daher wird für ein gemeinsames Assemblie ein so genannter Strong Name benötigt. Ein Strong Name besteht aus dem Dateinamen des Assem-blies, seiner Version, der Kultur und einem kryptografischen Schlüssel. Durch eine Konfigu-rationsdatei, die sich in dem Verzeichnis der Anwendung befindet, kann der Anwendung die Lage des Assemblies angegeben werden. Ein Strong Name kann mit Hilfe des Werkzeugs sn erzeugt werden. Ein globales' Assemblie wird im globalen Assemblie-Zwischenspeicher (Global Assembly Cache (GAC)) gespeichert. Mit Hilfe des Werkzeugs gacutil können Assemblies dem GAC hinzugefügt werden. Innerhalb des GAC können Assemblies mit unterschiedlichen Versionen und Kulturen gespeichert werden. Mit Hilfe von Konfigurationsdateien kann festgelegt werden, welche Versionen eines Assemblies von der Anwendung benutzt werden sollen. Erfolgt keine Angabe, so wird nur die Version benutzt, die bei der Erstellung der Anwendung benutzt wurde. Wenn diese Version nicht vorhanden ist, dann wird beim Start der Anwendung eine Fehlermeldung ausgegeben. Aktuelle Windows-Versionen besitzen eine Explorer-Erweiterung, die eine aussagekräftige Anzeige des Inhalts des GAC im Windows Explorer ermöglicht.

5.3 WebServices Ein Webservice ist ein Dienst, der mit Hilfe von XML auf der Basis von Internet-Netzwerk-protokollen erbracht wird. Web Services sind eigentlich nicht für menschliche Benutzer gedacht, sondern für Software-systeme, die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern aufrufen. Client-Programme senden im Allgemeinen Anfragen an einen Web Service und dieser antwortet mit der gewünschten Information. Von vielen Seiten wird daher behauptet, dass Webservices für Rechner das sind, was Webseiten für den Menschen sind. Auch wenn das nur ein Teil der Möglichkeiten der Webservices beschreibt, ist diese Aussage durchaus treffend.



Institut für Angewandte Informatik So gibt es zum Beispiel seit kurzem vom Betreiber der Suchmaschine Google einen Web-service, der die gleichen Möglichkeiten der Webseite anbietet wie die Benutzerschnittstelle. So können nun Programme mit wenigen Aufrufen nach Informationen im Internet suchen und diese für ihre eigenen Aufgaben verwenden. Das Parsen der Webseite von Google, ist dazu keine auch nur annähernd gleichwertige Alternative. Erreichbar sind Webservices über eine eindeutige URI. Webservices bilden die drei wichtig-sten Teile der Zusammenarbeit zwischen Client und Server ab: Das Zusammenfinden, Binden und den Datenaustausch.

5.3.1 Grundlagen Die Grundlage bilden vier Standards, die alle auf XML basieren:

• SOAP oder XML-RPC zur Kommunikation / Datenaustausch, • WSDL zur Beschreibung und • UDDI als Verzeichnisdienst zur Registrierung von Web Services.

Dank der Verwendung des HTTP-Protokolls zur Datenübertragung treten nur selten Probleme mit Firewalls auf, im Gegensatz zu vergleichbaren Technologien wie CORBA, DCOM oder auch Java RMI. Ein Webservice wird dadurch eingerichtet, dass man eine bestehenden Anwendung mit einem XML-Interface versieht. Danach kann sie mit anderen Anwendungen, die auch über XML-Interfaces verfügen, über das Internet kommunizieren.

5.3.2 Vorteile Durch die Verwendung von bereits bestehenden und weit verbreiteten Internet-Standards (HTTP, XML etc.) entsteht eine offene und sehr flexible Architektur, die unabhängig von den verwendeten Plattformen, Programmiersprachen und Protokollen ist. Windows-C#-Clients hinter einer Firewall können mit Java-Servern, die auf Linux implementiert sind, kommuni-zieren. Die weit verbreiteten Standard-Protokolle ermöglichen eine Interoperabilität über jegliche Heterogenitäten im Internet hinweg.

5.3.3 Anwendungsgebiete Web Services stellen neue Ansätze im Rahmen von EAI (Enterprise Application Integration) und Grid-Computing dar. Das geplante Haupteinsatzgebiet liegt im Business-to-Business-Bereich (B2B). Geschäftsprozesse sollen problemlos über Unternehmensgrenzen hinweg abgewickelt werden.

5.3.4 Erweiterungen Mit dem Web Services Composite Application Framework (WS-CAF) wurde eine weiterfüh-rende Spezifikation beim W3C und bei OASIS zur Standardisierung eingereicht, die Web Services um für die Koordination von Applikationen nützliche Standards, wie z. B. Transak-tionsmanagment, erweitern sollen. Weitere, proprietäre Erweiterungen sind bei verschiedenen



Institut für Angewandte Informatik Herstellern angedacht. Um Problemen der Sicherheit zu begegnen, werden Konzepte auf der Grundlage der Security Assertion Markup Language (SAML) entwickelt.

5.3.5 Architektur am Beispiel von ASP.NET Eine konkrete Implementierung eines WebServices kann unter .NET unter anderem im Rahmen einer ASP.NET-Anwendung erfolgen.

Abbildung 36: Architektur ASP.NET

Client PC WebServer

Browser

z.B. IIS (Webserver-Dienst)

ASP (GUI)

<<Schnittstelle>>

HTTPXML

SOAP...

Anwendungsrechner

Business Facade

Anwendung

Datenzugriff

Datenbank

1 2

3

Abbildung 37: Deploymentdiagramm ASP.NET




5.3.6 Aufbau eines WebService Der Quellcode einer WebService-Komponente wird in .asmx (Active Server Method) Dateien und den korrespondierenden Code Behind Dateien (z.B. .asmx.vb) gespeichert. Diese haben folgenden Aufbau:

<%@webservice class=“Test“ language=“C#“ Debug=“True“%> //Namensräume using System; using System.Web.Services; public class Test : WebService {

[WebMethod] public String sayHello() { return(“Hallo Welt !”); }

}

Um auf die WebService Komponenten von .NET zuzugreifen, müssen die entsprechenden Namensräume bekannt gemacht werden. Dies geschieht über die „using“ Anweisung. Der eigentliche WebService wird als eigene Klasse implementiert, die von der Klasse „Web-Service“ abgeleitet wird public class Test : WebService. ACHTUNG: Das es sich um einen WebService handelt wird durch die Attributierung in der ersten Zeile (<%@webservice ...) festgelegt, die Klasse implementiert lediglich die Methoden und muss nicht zwingend von WebService abgeleitet werden. Zu guter letzt kann ein WebService noch öffentliche und interne Funktionen (Methoden) enthalten. Dies ist nicht zu verwechseln mit den „public“ / „private“ Klassifizierungen, sondern bezieht sich auf das Attribut „[WebMethod]“. Eine so gekennzeichnete Methode ist von außen (z.B. in einem Browser) über die XML/SOAP Schnittstelle aufrufbar.




XML XMLUDDI WSDL XML SOAP

XML SOAP

XML SOAP

HTTP

DB WebService

Verwaltung der Anfrage WebService Container

Application Browser

Abbildung 38: WebService Struktur

5.3.7 Aufruf eines WebService WebServices können auf verschiedene Art und Weise aufgerufen werden. Die einfachste Art ist das direkte Aufrufen einer .asmx Datei mittels eines Browsers. Diese Variante bietet aller-dings kaum den gewünschten Komfort, da sie nur über eine rudimentäre Oberfläche verfügt und die Ausgaben keinerlei Formatierung aufweisen. Wesentlich sinnvoller ist daher der Aufruf von WebServices aus anderen Anwendungen – in unserem Fall eine ASP.NET-Anwendung - heraus, die eine entsprechende Oberfläche und Verarbeitung der Ausgabedaten bereitstellen. Das Protokoll das dabei zum Einsatz kommt ist das XML-basierte SOAP. Die Aufrufe werden dabei innerhalb eines HTTP-Post Requests in einem „SOAP-Envelope“ an den Webserver (IIS) übermittelt.

POST /FService.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://www.fh-kiel.de/WissenSuchen" <?xml version="1.0"? encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"> <soap:Body> <WissenSuchen xmlns="http://www.fh-kiel.de/"> <strSuche>string</strSuche> </ WissenSuchen > </soap:Body> </soap:Envelope>



Institut für Angewandte Informatik Der Prozess, der beim Aufruf eines WebService über ASP.NET abläuft gliedert sich wie folgt:

WebServices

Abbildung 39: Aufrufstruktur WebServices in ASP.NET

1. Die Anfrage des Browsers nach der .aspx Seite wird vom IIS entgegengenommen.

2. Innerhalb des IIS wird der Aufruf zur Verarbeitung an die ISAPI.dll weitergegeben,

welche die Anfrage prüft und an die CLR weiterleitet.

3. Die CLR lädt die angeforderte .aspx Seite mit der dazugehörigen Code Behind Datei und erzeugt die entsprechenden Code-Objekte (Assemblies). Erstellung der Webseite für die Oberfläche (liest Seitenbeschreibungsskript aus .aspx, um Seiten zu erzeugen).

4. Enthält diese den Aufruf eines WebService, wird dieser Aufruf zunächst über den IIS

geleitet, der wiederum nach der Prüfung durch die ISAPI.dll diesen WebService Aufruf an die CLR weiterleitet. Dieser „Umweg“ ist nötig, da der Aufruf über HTTP und SOAP erfolgt, der WebService könnte auch auf einem weiteren IIS – ausserhalb der aktuellen CLR – angeboten werden.

5. Die Ergebnisse der Aufrufe werden von der CLR an den IIS zurückgeliefert, nach den

Vorgaben der .aspx in HTML transformiert und an als Ergebnis an den Browser gesendet.




5.4 Exkurs: XML, Datenzugriffsschicht der Anwendung XML (siehe http://XML.apache.org) „eBNF“ Version XML 1.0 Beispiel: Zu übertragender Inhalt: Personalakte für die Personalnummer 1234 <Personalakte …> = `<` Name `>` XML gibt die formale Beschreibung an, wie die Sprachimplementierung aufgebaut sein muss. Wenn die Kriterien dieser formalen Beschreibung eingehalten sind „well-formedness“ Beispiel einer XML-Nachricht: XML-Nachricht:

• Prolog • Data Type Definition (DTD) • Inhalt

Prolog: <?XML version = „1.0“> -Angabe der Version zur Regelung der Kommunikation DTD: <[DOCTYPE Personalakte [ <!ELEMENT Personalakte (Personalien)> <!ATTLIST Personalakte Personalnummer CDATA #REQUIRED)> <!ELEMENT Personalien (Nachname)> <!ELEMENT Nachname (#PCDATA)> ] > <!ATTLIST… ist ein Beispiel für eine optionale Attributliste Inhalt: <Personalakte Personalnummer = „1234“> <Personalien> <Nachname> Müller </Nachname> </Personalien> </Personalakte>



Institut für Angewandte Informatik Wozu wird XML verwendet?

• Hauptnutzen: o Plattformunabhängige (weil Textformat) anwendbare Formulierung zur

Strukturierung von Daten • Ausprägung:

o Standardisierung der mit einem Web-Service auszutauschenden Daten (Anwendung der XML-Syntaxregeln auf den Fall Web-Service)

SOAP (Simple Object Access Protocol)

Quellen: Schoning, XML und Datenbanken ISBN 3-446-22008-9, Hanser 2003 Erweiterung DTD:

XSL = extensible stylesheet language XSLT = XSL-Transformer

Anwendung von XML in Programmen:

• SAX – Simple API for XML (framework für XML-Parser)




5.5 Exkurs: Organisation von Zugriffen auf Anwendungs-programme aus eigenem Programmcode

* Common Language Runtime

• (verwaltet die Zugriffe) • wenn die Verwaltung funktionieren soll, muss die Anwendung Teil der CLR sein

„managed code“, d.h. unterliegt der Speicherverwaltung (Präfix dieser Klassen: „__gc“ (= garbage collector als Schlüsselwort)

• Suchstruktur gespeichert in Namespace

o Jeweils Klassen mit gleichen Eigenschaften o (SYSTEM.DATA Datenzugriffsklassen)





Quellenverzeichnis [1] Wikipedia http://www.wikipedia.de

[2] Brauer, Jörg Peter DIN EN ISO 9000:2000 ff. umsetzen

München: Hanser, 2002 ISBN 3-446-21865-3

[3] Samberg et al Vorlesungsskripte:

Organisation und Qualitätssicherung - Stichworte zur Vorlesung - Mitschrift SS 2004

Neue Softwaretechnologien - Stichworte zur Vorlesung 2004

Basiswissen Projektmanagement

Softwareengineering - SE2 Vorlesungsskript mit Ergänzungen WS 04/05

[4] Oestereich, Bernd Objektorientierte Softwareentwicklung Analyse und Design mit der UML 2.0 München: Oldenbourg, 2004 ISBN 3-486-27266-7

[5] OGC – Office of Government Commerce

Best Practice for Application Management London: Crown Copyright, 2002 ISBN 0-11-330866-3

[6] Balzert, Helmut Lehrbuch Grundlagen der Informatik Heidelberg, Berlin: Spektrum, 1999 ISBN 3-8274-0358-8

[7] Microsoft Helpfiles Microsoft Development Environment 2002, Version 7Microsoft .NET Framework 1.0, Version 1

[8] Schwichtenberg, Holger Eller, Frank

Programmierung mit der .NET-Klassenbibliothek München, u.a.: Addison-Wesley, 2004 ISBN 3-8273-2128-X

Advanced Application- System Development Skript WS 04-05.pdf · Abbildung 33: Namespace-Hierarchie...

Documents

Transcript of Advanced Application- System Development Skript WS 04-05.pdf · Abbildung 33: Namespace-Hierarchie...