Home

Best Practices in der Softwareentwicklung

1. Vgl Balzert Bal01 S 697ff Abbildung 5 2 Strikte lineare und baumartige Schichtenstruktur Abbildung a zeigt eine strikte Schichtenstruktur mit Zugriffskante x und eine lineare Schichten struktur ohne Zugriffskante x Abbildung b ist ein Beispiel f r eine baumartige Schichtenstruktur Innerhalb der Schichten befinden sich die mit K bezeichneten Komponenten Ein Schichtenmodell mit linearer Ordnung schr nkt die Zugriffsm glichkeiten gegen ber einer strikten Ordnung zus tzlich dadurch ein dass nur Zugriffe auf die eigene oder die n chstniedrige Schicht erlaubt werden Ein bekanntes lineares Schich tenmodell ist das ISO OSI Modell f r die Kommunikation in Rechnernetzen Hierbei werden die unterschiedlichen Aufgaben der elektronischen Kommunikation je nach ihrem Abstraktionsgrad auf insgesamt sieben Schichten verteilt CDKM02 S 103 Bei einer baumartigen Schichtenarchitektur ist es im Gegensatz zur strikten oder linearen Architektur m glich mehrere Schichten auf der gleichen Abstraktionsebene anzuordnen Da diese Architektur Zugriffe zwischen Schichten derselben Abstrakti onsebene verbietet ergibt sich durch die Kommunikationsbeziehungen zwischen den Schichten eine baumartige Struktur wie sie in Abbildung 5 2b dargestellt ist In einer sinnvoll gestalteten Schichtenarchitektur besitzen alle Dienstleistungen einer Schicht dasselbe
2. Vgl Balzert Bal01 S 698 Tabelle 5 1 Vor und Nachteile von Schichtenarchitekturen 5 1 3 Vergleich von Schichten Architekturen Klassische Schichten Architekturen Ein Anwendungssystem hat in der Regel drei wichtige Funktionen zu bernehmen Pr sentation Verarbeitung und Datenhaltung Die Pr sentationsfunktion ist die Schnittstelle zum Anwender in Form einer Benutzeroberfl che die Verarbeitungs funktion umfasst die gesamte Gesch ftslogik der Anwendung und f r das Lesen und Speichern der Anwendungsdaten ist die Datenhaltung zust ndig Abbildung 5 3 zeigt wie diese Funktionen auf eine zwei oder drei Schichten ver teilt werden k nnen Bei einem monolithischen System werden alle Funktionen durch eine Schicht bernommen w hrend in einer 3 Schichten Architektur jede Funktion durch eine eigene Schicht bernommen wird Die 2 Schichten Architektur stellt ei ne Zwischenform dar bei der Pr sentation und Verarbeitung durch eine einzelne Schicht realisiert werden Die Anzahl der Schichten in die ein Anwendungssystem unterteilt werden soll te ist abh ngig vom Funktionsumfang Je umfangreicher ein System ist desto mehr Schichten sollte die Architektur besitzen Wie bereits erw hnt bedingt die Einf hrung einer weitern Schicht zun chst einen h heren Implementierungsaufwand und meist auch einen erh hten Kommunikationsaufwand zwischen den Schichten Im Gegenzug wird jedoch die Strukturierung des Gesamtsystems erh ht was
3. Anwendungsobjekte Plattform 2 Server Objekte Spezielle Objektdienste Allgemeine Dienste Namensgebung Kopieren L schen Hilfedienste Drucken Sicherheitsdienste Abbildung 5 6 Architektur eines CORBA Systems den umgekehrten Weg wieder an das Client Objekt bermittelt F r den Transport m ssen der Methodenaufruf mit seinen Argumenten und das Ergebnis des Aufrufs in einen zu sendenden Datenstrom verwandelt und aus dem empfangenen Datenstrom extrahiert werden Diese Aufgaben werden als Marshalling bzw Demarshalling be zeichnet und werden von den Stumpf und Skelettobjekten bernommen Zusammen mit dem ORB der f r die Netzwerkkommunikation verantwortlich ist sind so bei ei nem Methodenaufruf der Aufenthaltsort der Anwendungsobjekte sowie die eventuell durchgef hrte Netzwerkkommunikation transparent Client Objekt Server Objekt o Ergebnis 2 as Stumpf s Demarshalling u Marshalling Abbildung 5 7 Entfernter Methodenaufruf mit CORBA Ergebnis Um ein Objekt in CORBA nutzbar zu machen m ssen dessen Schnittstellen zur Au enwelt zun chst in der Interface Definition Language IDL programmier sprachenneutral beschrieben werden Mithilfe der Metainformationen einer IDL Objektbeschreibung k nnen sowohl Stumpf als auch Skelett eines Anwendungsob jekts erzeugt werden Dar ber hinaus ben tigt der ORB die Metainformationen 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 49 um den ent
4. Forderkreis der Angewandten Informatik an der Westf lischen Wilhelms Universit t M nster e V Working Paper No 1 Best Practices in der Softwareentwicklung Christian Arndt Christian Hermanns Herbert Kuchen Michael Poldner 16 Februar 2009 WILHELMS UNIVERSITAT MUNSTER Best Practices in der Softwareentwicklung Christian Arndt Christian Hermanns Herbert Kuchen Michael Poldner 16 Februar 2009 Christian Arndt Christian Hermanns Prof Dr Herbert Kuchen Michael Poldner Institut fiir Wirtschaftsinformatik Westf lische Wilhelms Universit t M nster Leonardo Campus 3 48149 M nster kuchen uni muenster de Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbi bliografie detaillierte bibliografische Daten sind im Internet ber http dnb ddb de abrufbar ISSN 1868 0801 Dieses Werk ist urheberrechtlich gesch tzt Die dadurch begr ndeten Rechte ins besondere die der bersetzung des Nachdrucks des Vortrags der Entnahme von Abbildungen und Tabellen der Funksendung der Mikroverfilmung oder der Ver vielf ltigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen bleiben auch bei nur auszugsweiser Verwertung vorbehalten Eine Vervielf ltigung dies Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Gren zen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundes
5. ig an Auch f r die berprufung von Refactorings sind die vor der Implementierung erstellten Testf lle wichtig Fortw hrende Integration Bei der Verwendung traditioneller Vorgehensmodelle zur Softwareentwicklungen wer den Integrationsma nahmen zumeist relativ weit ans Ende der Entwicklungsar beiten gestellt Werden in dieser sp ten Phase Integrationsprobleme festgestellt die nicht selten auf grunds tzliche Schwachpunkte in der Systemarchitektur bzw bei der Gestaltung der Komponenten und Schnittstellen hinweisen so ist deren Korrektur mit einem berproportional h heren Aufwand verbunden als zu einem fr heren Zeitpunkt des Projektes Zudem stehen f r die Behebung der Proble me nur noch sehr beschr nkte Ressourcen zur Verf gung so das eine Termin oder Budget berschreitung oder gar ein Abbruch des Projektes h ufig unausweich lich ist Durch eine m glichst fr hzeitige und fortw hrende Integration sollen Feh ler im Zusammenwirken der einzelnen Komponenten fr hzeitig aufgedeckt werden Dies erm glicht es strukturelle Defizite zu einem Zeitpunkt zu erkennen zu dem deren Korrektur noch mit einem verh ltnism ig geringen Aufwand m glich ist Idealerweise sollten Integrationen t glich durchgef hrt werden wobei jede Integra 14 KAPITEL 2 VORGEHENSMODELLE tion eine lauffahige Version des Softwaresystems zum Ergebnis hat Um die In tegrationsf higkeit einer Anderung und die Funktionalit t des Gesamtsystems zu berp
6. MLK04 NUn08 OAS07a LITERATURVERZEICHNIS LIBERTY Jesse HURWITZ Dan Programming ASP NET 3 O Reilly Media Inc 2005 LINTHICUM David S Enterprise Application Integration 1 Boston et al Addison Wesley 2000 LINK Johannes Softwaretests mit JUnit dpunkt verlag 2005 LEMBECK Christoph MULLER Roger A KUCHEN Herbert Test fallerzeugung mit einer symbolischen virtuellen Maschine und Constraint Solvern In GI Jahrestagung 2 Bd 51 GI 2004 S 418 427 LOHRER Matthias Einstieg in ASP NET 1 Galileo Computing 2003 LINNHOFF POPIEN Claudia CORBA Kommunikation und Manage ment 1 Berlin et al Springer 1998 LAHRES Bernhard RAYMAN Gregor Praxisbuch Objektorientierung Von den Grundlagen zur Umsetzung 1 Bonn Galileo Press 2006 MELTON Jim EISENBERG Andrew Understanding SQL and Java To gether A Guide to SQLJ JDBC and Related Technologies 1 San Francisco Morgan Kaufmann 2000 MICROSOFT ASP NET http www asp net Abrufdatum 17 07 2007 MICROSOFT Microsoft NET Homepage http www microsoft com net default aspx Abrufdatum 17 07 2007 RED HAT MIDDLEWARE NHibernate for NET http www hibernate org 343 html Abrufdatum 17 07 2007 MULLER Roger A LEMBECK Christoph KUCHEN Herbert A sym bolic Java virtual machine for test case generation In JASTED Conf on Software Engineering 2004 S 365 371 NUNIT orG NUnit http www nunit org Abruf
7. Selenium http selenium openga org Abrufdatum 28 03 2008 POENSGEN Benjamin Bock Bertram Function Point Analyse 1 Heidelberg dpunkt verlag 2005 PORTLAND PATTERN REPOSITORY Anti Patterns definition and ca talog http c2 com cgi wiki AntiPattern Abrufdatum 19 09 2007 PROJECT The J Jakarta Cactus http jakarta apache org cactus Abrufdatum 28 03 2008 RAIBLE Matt Comparing Web Frameworks https equinox dev java net framework comparison WebFrameworks pdf Abrufdatum 17 07 2007 RATIONAL SOFTWARE CORPORATION Rational Unified Pro cess Best Practices for Software Development Teams http 118 Rat08a Rat08b RB98 SBS06 Sch07 SGMo2 Sou08 Sta07 Sti05 Sun07a Sun07b Sun07c Sun07d LITERATURVERZEICHNIS www augustana ab ca mohrj courses 2000 winter csc220 papers rup_best_practices rup_bestpractices pdf Abrufdatum 19 09 2007 RATIONAL IBM Rational Performance Tester http www 306 ibm com software de rational Abrufdatum 28 03 2008 RATIONAL IBM Rational TestManager http www 306 ibm com software de rational Abrufdatum 28 03 2008 RUBIN William BRAIN Marshall Understanding DCOM 1 New Jersey Prentice Hall 1998 SRIGANESH Rima P BROSE Gerald SILVERMAN Micah Mastering Enterprise JavaBeans 3 0 1 Indianapolis Wiley Publishing Inc 2006 SCHWABER Carey The Forrester Wave Software Change And Con fig
8. Tabelle 3 2 Eine Feldgruppe besteht aus inhaltlisch zusam mengeh rigen Datenelementen z B Nachname und Vorname Diese Bewertung erfolgt pro Elementarprozess genau einmal unabh ngig davon wie h ufig dieser in der Anwendung auftritt und genutzt wird Die klassifizierten Elementarprozesse wer den dann in ein Rechenblatt Abb 3 3 eingetragen und mit Punktzahlen bewertet Durch Addition der so ermittelten Punktewerte erh lt man zun chst die so genann ten unbewerteten Function Points Ei Diese werden dann unter Ber cksichtigung 3 2 RISIKO MANAGEMENT 19 von insgesamt 14 Einflussgr en wie z B der Frage ob das zu erstellende System auf mehreren Rechnern verteilt arbeiten soll oder ob schwer zu erf llende Anfor derungen an die Effizienz bestehen um maximal 35 verringert oder erh ht Als Ergebnis erh lt man dann die bewerteten Function Points E3 die mithilfe einer Tabelle dann in Mitarbeiter Monate umgerechnet werden k nnen Kategorie Anzahl Klassifizierung Gewichtung K Eingabedaten einfach 9 mitte komplex Abfragen einfach mitte komplex Ausgaben einfach 3 mitte komplex Datenbest nde 3 einfach mitte komplex Referenzdaten einfach mitte komplex 36 15 21 xixixixi x x x x x x x Gil A1 A1 od A a el co a wo x x x S I on Summe E Einflussfaktoren 1 Datenkommunikation Frontend Backend 0 5 andern den FP Wert 2 Verteilte V
9. dass diese oft andere Bausteine erfordern die beim Testen zun chst noch nicht ber cksichtigt werden sollen Durch eine geschickt gew hlte Testreihenfolge l sst es sich oft erreichen dass von dem zu testenden Baustein nur solche Bausteine ben tigt werden die bereits sorgf ltig getestet wurden In diesem Fall kann man direkt auf die getesteten Bausteine zur ckgreifen und ben tigt kei ne weiteren Vorkehrungen Manchmal ben tigen sich Bausteine aber wechselseitig Dann l sst es sich oft nicht umgehen einen der Bausteine zun chst durch einen vereinfachten Baustein auch Stumpf Stub oder Mock genannt zu ersetzten der die Funktionalit t des eigentlichen Bausteins auf m glichst einfache Weise simuliert vgl Abb 7 1 Ein Problem bei der Verwendung von Testst mpfen ist dass der zu testende Baustein oft ge ndert werden muss um mit den Testst mpfen verkn pft zu werden Dies ist nicht nur umst ndlich sondern birgt auch das Risiko dass diese nderungen TT 78 KAPITEL 7 TESTEN aufrufende Testtreiber Komponente zu testende zu testende Komponente T7 Komponente aufgerufene aufgerufene Stumpf Stumpf Komponente Komponente Abbildung 7 1 Ersetzen von benachbarten Bausteinen durch vereinfachte Testst mpfe nach dem Testen nicht alle wieder revidiert werden so dass ein vereinfachter Test stumpf irrt mlich statt des eigentlichen Sof
10. der die entspre 6 3 VERHALTENSMUSTER 73 chende FuehreAus Operation umsetzt Beispielsweise kann jede Auswahlm glichkeit eines Men s durch ein Exemplar der Klasse MenueEintrag realisiert werden Ein Ob jekt der Klasse Anwendung erzeugt diese Men s mit allen ihren Men Fintr gen und verwaltet Objekte der Klasse Dokument die ein Benutzer ge ffnet hat Abb 6 5 Je der MenueEintrag wird mit einer konkreten Unterklasse von Befehl konfiguriert Bei Auswahl eines MenueEintrags ruft das MenueEintrag Objekt die Operation Fuehre Aus auf seinem Befehlsobjekt auf das die entsprechende Operation umsetzt Welche konkrete Unterklasse sich hinter ihrem Befehlsobjekt verbirgt ist einem Exemplar der Klasse MenueEintrag nicht bekannt Anwendung K gt Menue MenueEintrag Befehl AddDokument AddMenueEintrag Geklickt FuehreAus IN befehl FuehreAus Abbildung 6 6 Entwurfsmuster Befehl Abbildung 6 6 stellt die Struktur des Befehlsmusters dar Der Klient Anwen dung erzeugt ein KonkreterBefehl Objekt und bergibt es dem Empf nger welcher wei wie die an die Ausf hrung einer Anfrage gebundenen Operationen auszuf hren sind Ein Aufrufer MenueEintrag speichert das Befehlsobjekt und ruft bei einem bestimmten registrierten Ereignis Geklickt die FuehreAus Operation des Befehls objekts auf Das Befehlsmuster hat mehrere Vorteile Zum einem entkoppelt das Befehlsmus ter das Objekt
11. nstigt eine einseitige und technologiespezifische Diskussion von Integrationsproblemen Die Frage inwie weit die favorisierte Integrationsl sung dabei wirklich den gestellten Anforderungen gen gt und ob ihr Einsatz m glicherweise mit Nachteilen oder Risiken verbunden ist ger t dabei allzu leicht ins Hintertreffen Als Beispiel hierf r kann die derzeitige Euphorie um Web Service basierte Integrationsl sungen angesehen werden Statt um eine konkrete Technologie handelt es sich bei EAI vielmehr um ein Konzept welches mit einer Vielzahl m glicher Technologien realisiert werden kann Das Ziel der Anwendungsintegration besteht in der umfassenden Verkn pfung von Anwendungen auf innerbetrieblicher oder zwischenbetrieblicher Ebene Dabei sollen die bestehenden Anwendungen in ihrer urspr nglichen Form erhalten bleiben um einerseits die in ihre Erstellung investierten Ressourcen und andererseits das darin gebundene Wissen f r die Zukunft zu erhalten Zur Umsetzung dieses Ziels stellt das EAI Konzept eine Reihe von Methoden Architekturkonzepten sowie Standards und Technologien zur Verf gung 89 90 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION 9 1 Heterogene Systemlandschaften Der Ausgangspunkt von Integrationsvorhaben ist stets eine Menge von bereits exis tierenden Systemen die aufgrund von Heterogenit ten nicht oder nur mit Ein schr nkungen in der Lage sind miteinander zu interagieren Diese Heterogenit ten k nnen sich auf ver
12. und Nachteile des JSF Frameworks Vor und Nachteile des Spring MVC Frameworks Vor und Nachteile des Tapestry Frameworks xi xii TABELLENVERZEICHNIS Kapitel 1 Einleitung Was das Vorgehen und die eingesetzten Methoden und Werkzeuge bei der Softwa reentwicklung angeht gibt es zwischen verschiedenen Firmen deutliche Unterschie de W hrend manche Firmen die Vorschl ge aus Lehrb chern zur Softwaretechnik weitgehend umsetzen gibt es andere die hinter dem aktuellen Stand der Technik zur ckbleiben Bei gr eren Firmen kann man feststellen dass solche Unterschiede sogar zwischen verschiedenen Abteilungen bestehen Die vorliegende Brosch re hat zum Ziel Methoden aufzuzeigen ber deren Einsatz zumindest nachgedacht wer den kann und die die Softwareentwicklung effizienter und qualitativ hochwertiger gestalten k nnen Im Folgenden wird davon ausgegangen dass Sie als Leser zumindest ber Grund kenntnisse der Softwareentwicklung verf gen Einige oder vielleicht sogar die meis ten der angesprochenen Themen werden Ihnen bekannt sein Es wird aber zumindest ein paar Themen und Aspekte geben bei denen sie auf Ans tze sto en die Ihnen weniger vertraut sind und die in Ihrer Firma vielleicht sinnvoll eingesetzt werden k nnen Wenn dem so sein sollte hat diese Brosch re ihr Ziel erreicht Wenn Sie ei nige Themen bereits kennen sollten ist es nicht unbedingt zwingend die Brosch re vo
13. Abstraktionsniveau Dar ber hinaus sind die Schichten so zueinander angeordnet dass eine Schicht ausschlie lich die Dienstleistungen der untergeordneten Schichten in Anspruch nimmt w hrend sie den bergeordneten Schichten Dienstleistungen zur Verf gung stellt Die Anzahl der Schichten z hlt zu den zentralen Eigenschaften einer Architektur und ist daher entscheidend f r einen guten Softwareentwurf W hrend zu wenige Schichten die Wiederverwendbarkeit Anpassbarkeit und Portabilit t einer Anwen dung einschr nken f hren zu viele Schichten dazu dass die Komplexit t des Ge samtsystems durch den erh hten Aufwand der durch die Schichtenaufteilung ent steht steigt Die Vor und Nachteile die sich durch die Umsetzung einer Schichtenarchitek tur ergeben k nnen sind in der Tabelle 5 1 aufgef hrt Im nachfolgenden Abschnitt 42 KAPITEL 5 SOFTWAREARCHITEKTUREN werden m gliche Schichtenarchitekturen f r Desktop und Web Anwendungen vor gestellt und verglichen VORTEILE NACHTEILE Strukturierung in Abstraktionseb Geringer Effizienzverlust da Daten enen f rdert bersichtlichkeit oft ber mehrere Schichten trans portiert werden m ssen Innerhalb einer Schicht freie Ge Definition von eindeutig abgegrenz staltungsm glichkeiten da keine ten Schichten nicht immer m glich Zugriffsbeschr nkung Unterst tzt Wiederverwendbar keit nderbarkeit Wartbarkeit Portabilit t und Testbarkeit
14. Aggregation und Komposition 32 KAPITEL 4 OBJEKTORIENTIERUNG UND UML Eine spezielle Assoziation welche eine Ganzes Teil Beziehung ausdriickt nennt man Aggregation Sofern es einem Modellierer wichtig ist diese spezielle Art der Beziehung herauszustellen kann er die beteiligten Klassen statt durch eine durch gehende Linie auch durch eine Linie verbinden die mit einer wei en Raute beginnt In Abbildung 4 4 oben wird modelliert dass ein Fahrrad zwei Reifen enth lt Ist eine Ganzes Teil Beziehung so geartet dass beim L schen des Objektes f r das Ganze auch die Teil Objekte ihre Existenzberechtigung verlieren so kann man dies bei der Modellierung durch eine spezielle Form von Aggregation eine Kompo sition zum Ausdruck bringen Im Klassendiagramm wird statt einer wei en dann eine schwarze Raute verwendet In Abbildung 4 4 unten wird beispielsweise dargestellt dass eine Person belie bige viele Wohnsitze hat Stirbt die Person so hat sie auch keine Wohnsitze mehr sondern es gibt h chstens noch Wohnungen Aus Implementierungssicht zeigt eine Komposition an dass hier ein so genanntes kaskadierendes L schen realisiert werden muss Man beachte dass in obigem Fahrrad Beispiel ein Rad auch bei einem anderen Fahrrad montiert werden kann wenn das urspr ngliche Fahrrad verschrottet wird Daher wurde hier keine Komposition modelliert Beipiel 1 Krankenhausanwendung Nachdem die Bestandteile eines Klassendiagramms nun erl utert
15. Be schreibung der Schnittstellen der entfernten Objekte erfolgt mithilfe von Java EJB oder programmiersprachenunabh ngig mittels einer Interface Definition Language CORBA DCOM Abbildung 9 7 verdeutlicht den Kommunikationsmechanismus welcher komponentenorientierter Middleware zugrunde liegt Lokale Proxies Stub 100 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION und Skeleton fungieren als schnittstellen quivalente lokale Stellvertreterobjekte des jeweiligen entfernten Server Objektes Der Client ruft eine Methode des Stubs wel cher diese in ein plattformunabh ngiges Zwischenformat umwandelt Marshalling und ber den Kommunikationskanal an das Skeleton auf der Serverseite bermittelt Dieser konvertiert die Parameter in ein lokales Format und ruft die gewiinschte Me thode des Server Objektes auf Zur Ubertragung der Riickgabewerte des Aufrufs verl uft die Kommunikation in umgekehrter Richtung ber das Skeleton und den Kommunikationskanal bis hin zum Stub welcher die Ergebnisse lokal an die aufru fende Anwendung tibergibt Demarshalling Auf eine vertiefende Darstellung der Architektur und Funktionsweise der skiz zierten Ans tze soll an dieser Stelle zugunsten einer differenzierten Bewertung der Alternativen im Hinblick auf ihre Einsatzpotentiale im Kontext der Anwendungs integration verzichtet werden F r weiterf hrende Informationen zu CORBA Java EE und COM DCOM sei daher auf die angegebene Literatur sowie auf Abschnitt 5
16. Benutzerschnittstellenintegration wie auch der Datenintegration Die integrierte Informationssysteminfrastruktur kann als System von mehr oder weni ger lose miteinander gekoppelten Komponenten betrachtet werden F r die Rea 9 4 INTEGRATIONSEBENEN 97 lisierung dieses Integrationskonzeptes bietet sich ein ganzes B ndel von Techno logien an Diese unterscheiden sich zum Teil erheblich in Aspekten wie Einrich tungsaufwand Performanz Skalierbarkeit Austauschbarkeit und der Flexibilit t der durch sie bewirkten Kopplung zwischen den Systemen Dar ber hinaus stellen die verschiedenen Integrationstechnologien sehr unterschiedliche Anforderungen an die zu integrierenden Systeme oder sind mit Restriktionen verbunden die ihre Ein satzm glichkeiten auf bestimmte Integrationsszenarien einschr nken Historisch ist eine Entwicklung ausgehend von RPC Remote Procedure Call basierten Integrati onstechnologien ber komponentenorientierte Middleware Plattformen wie CORBA oder DCOM bis hin zu Web Service basierten Integrationsl sungen zu beobachten Eine der wichtigsten Triebfedern f r die zu beobachtende technologische Entwick lung im Bereich der Anwendungsintegration ist der Trend hin zu flexiblen unter nehmens bergreifenden und kurzfristig an neue Anforderungen und Rahmenbedin gungen anpassbaren Gesch ftsprozessen Dies erfordert eine flexible und skalierbare Integration der zugrunde liegenden Informationssysteme Aufgrund der gro en Bedeut
17. Beobachter voneinan der unabh ngig zu variieren Subjekte k nnen wiederverwendet werden ohne ihre Beobachter wiederverwenden zu m ssen und umgekehrt Zudem k nnen neue Beob 6 3 VERHALTENSMUSTER 75 Subjekt beobachter MeldeBeobachterAn MeldeBeobachterAb Benachrichtige Beobachter Aktualisiere f r alle b in beobachter b Aktualisiere KonkreterBeobachter beobachteterZustand Aktualisiere KonkretesSubjekt subjektZustand bach GibZustand 7 SetzeZustand N 5 7 7 7 S J beobchteterZustand return subjektZustand subjekt GibZustand Abbildung 6 8 Entwurfsmuster Beobachter achter ohne Modifikation des Subjekts oder anderer Beobachter hinzugef gt werden Nachteil des Musters ist dass eine scheinbar harmlose Operation auf dem Subjekt zu aufw ndigen Aktualisierungen bei den Beobachtern f hren kann Schlecht de finierte und gewartete Abh ngigkeiten f hren des Weiteren schnell zu unsinnigen Aktualisierungen die schwer aufzufinden sind 6 3 3 Weitere Verhaltensmuster Details zu den im Folgenden kurz skizzierten weiteren Verhaltensmustern findet man in GHJV96 Besucher erlaubt bei Klassen mit sehr umfangreichen Schnittstellen und Operatio nen die sich in Themenbereiche untergliedern lassen die Operationen jeweils eines Themenbereichs in eine eigene Besucherklasse herauszuziehen Hi
18. Geschwindigkeitsverlust zur Folge Plattformunabh ngigkeit Da f r nahezu jedes Betriebssystem eine JVM existiert ist auch Java EE quasi vollst ndig Plattformunabh ngig Bei NEI w re eine Plattformunabh ngigkeit aufgrund der vorhandenen virtuellen Ma schine theoretisch auch realisierbar bisher gibt es jedoch abgesehen von eini gen wenige Ausnahmen z B Mono f r Linux ausschlie lich eine Implemen tierung der CLR f r Windows Betriebssysteme Sprachunterst tzung Java EE unterst tzt ausschlie lich die Sprache Java In anderen Sprachen geschriebene Programme k nnen lediglich ber das Java Native Interface JNI eingebunden werden Diese Form der Einbindung ist jedoch mit zus tzlichem Aufwand verbunden Die CLR kann theoretisch jede 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 63 CLS konforme Sprachen ausfiihren Compiler fiir sehr viele Sprachen existieren bereits e Entwicklungstools Wahrend es fiir Java EE eine Menge verschiedener Werk zeuge und Entwicklungsplattformen gibt wird f r die Entwicklung von NET Anwendungen im Wesentlichen die Visual Studio NET Entwicklungsumge bung eingesetzt Fazit Die wichtigsten Unterschiede zwischen beiden Frameworks liegen in der Plattform strategie W hrend Java EE eine plattformunabh ngige an die Sprache Java ge bundene L sung darstellt ist NET sprachunabh ngig jedoch an die Windows Plattform gebunden Im Bezug auf die Pr sentationsschicht scheint NET mit dem Code Beh
19. Komplexere Client Server Architekturen ergeben sich wenn ein Prozess sowohl die Rolle eines Clients als auch die Rolle eines Servers bernimmt Ein solcher Prozess stellt als Server Dienste zur Verf gung w hrend er zur Erbringung dieser Dienste auf die Dienste anderer Server zur ckgreift 5 1 2 Aufbau von Schichtenarchitekturen Komplexe Softwaresysteme die aus vielen Komponenten bestehen werden h ufig als Schichtenarchitekturen konzipiert um eine st rkere Strukturierung zu erreichen Die Schichten eines Softwaresystems erlauben beliebigen Zugriff zwischen den Kom ponenten derselben Schicht schr nken jedoch die Zugriffe zwischen den Schichten ein Die Anordnung der Schichten in einer Architektur ist hierarchisch in Abh ngig keit von den Abstraktionsniveaus der Schichten Dabei nehmen die h her liegenden Schichten von untergeordneten Schichten Dienste in Anspruch Diese Rollenvertei lung entspricht dem Client Server Modell Die Schichtenhierarchie kann eine strikte lineare oder baumartige Struktur annehmen wie in Abbildung 5 2 dargestellt In einem Schichtenmodell mit strikter Ordnung befinden sich alle Schichten auf einem unterschiedlichen Abstraktionsniveau und es gilt die Einschr nkung dass eine Schicht auf alle Schichten mit einem niedrigeren Abstraktionsniveau jedoch nicht auf Schichten mit einem h heren Abstraktionsniveau zugreifen darf 5 1 SCHICHTENARCHITEKTUREN 41 a b
20. Objekte erf llen m ssen werden Zusicherungen genannt und in geschweiften Klammern hinter das zu spezifizierende Element geschrieben ber die Sichtbarkeit wird festgelegt ob und in welcher Weise ein Zugriff auf die Attribute und Methoden erfolgen darf M gliche Sichtbarkeiten sind private protected und public Als private deklarierte Attribute und Methoden sind nur innerhalb der Klasse selbst und nicht von au en sichtbar Typischerweise sch tzt man so die Attribute einer Klasse vor unkontrolliertem Zugriff Man spricht in diesem Zusammenhang auch von Datenkapselung Auf die gleiche Weise k nnen Hilfsmethoden verborgen werden die nur innerhalb der Klasse genutzt werden sollen Deklariert man Attribute oder Methoden mit protected so sind diese nicht nur in nerhalb der Klasse selbst sondern auch f r alle eventuell vorhandenen Unterklassen sichtbar vgl Unterkapitel 4 1 3 Mit public werden die Methoden ausgezeichnet die die Schnittstelle einer Klasse nach au en bilden F r die Attribute einer Klasse werden typischerweise so genannte Set und Get Operationen bereit gestellt mit denen die Attributwerte gesetzt bzw ausgelesen werden k nnen Durch die kontrollierte nderung der Attributwerte ber die Set Operationen kann ein konsistenter Zustand eines Objekts im Bezug auf die angege benen Zusicherungen gew hrleistet werden So kann beispielsweise die setBreite Operation der Klasse Rechteck beim Versuch die Breite des R
21. Testen so weit wie m glich zu au tomatisieren Einige Prozessmodelle f r die Softwareentwicklung wie z B Extreme Programming verlangen eine solche Automatisierung sogar vgl Abschnitt 2 3 F r die Automatisierung von Tests haben in den letzten Jahren einfache frei verf gbare Frameworks wie JUnit JUn08 Lin05 f r Java und Varianten wie NU nit NUn08 f r alle NET Sprachen inklusive C C Visual Basic eine gro e Beliebtheit erreicht nicht zuletzt weil Hersteller von Entwicklungsumgebun gen diese in ihre Werkzeuge integriert haben Bei diesem Ansatz wird zu einer zu testenden Klasse eine Testklasse als Testtrei ber erstelllt Hierin wird f r jeden Testfall eine Methode angelegt In diesen Testme thoden werden im Framework vordefinierte Methoden wie z B assertEquals ver wendet mit denen das erhalte Ergebnis mit dem erwarteten verglichen werden kann Au erdem bietet die Testklasse die M glichkeit durch geeignetes berschreiben der Methode setUp das zu testende Objekt vor den Tests in einen definierten Anfangs zustand zu bringen Hierbei k nnen z B auch Datenbank oder Netzwerkverbindun gen aufgebaut Entsprechend erlaubt die Methode tearDown nach den Tests solche Ressourcen wieder frei zu geben Im folgenden Beipiel wird eine JUnit Testklasse ListTest gezeigt mit der eine hier nicht gezeigte Klasse MyList getestet wird MyList implementiert eine lineare Liste und bietet neben einer Iteratorschnittstelle ein
22. Universit t M nster lie en sich Webanwendun gen bei denen ausschlie lich so genannte CRUD Operationen create read upda te delete ben tigt wurden inklusive der hierf r n tigen Navigationsstrukturen zu 111 lt EXTENSION templates Library gt lt DEFINE Root FOR Metamodel Entity gt lt FILE getClassPath this gt package lt getPackageName this package gt Entity public class lt this name gt implements java io Serializablet lt EXPAND Property FOREACH this ownedAttribute gt lt EXPAND Accessor FOREACH this ownedAttribute gt lt ENDFILE gt lt ENDDEFINE gt lt DEFINE Property FOR uml Property gt lt getVisibility this gt lt getStatic this gt lt getTypeName this gt lt getAttributeName this gt lt IF isMultiple this gt lt ELSE gt new java util ArrayList lt lt getQualifiedTypeName this type gt gt Q lt ENDIF gt lt ENDDEFINE gt lt DEFINE Accessor FOR uml Property gt lt IF this association null gt lt getMultiplicityAnnotation this gt JoinColumn name lt this name gt lt ENDIF gt public lt getStatic this gt lt getTypeName this gt lt getGetterName this gt return lt getAttributeName gt public lt getStatic this gt void lt getSetterName this gt lt getTypeName this gt p_ lt getParameterName this gt lt getAttributeName gt p_ lt getParameterName gt lt ENDDEFINE gt lt DEFINE Root FOR uml Model gt lt E
23. Unternehmen Frau Cornelia Gaebert INDAL M nster Herrn Hans Hermann G cke mdi nora Ibbenb ren und Herrn Johannes Schlatt mann LVM M nster Ihre Mitarbeit hat zu weiteren wertvollen praxisbezogenen Hinweisen gef hrt Martin Kittner Dr Christoph Asmacher Vorsitzender des F rderkreises f r Angewandte Informatik IHK Nord Westfalen ill iv Inhaltsverzeichnis Einleitung Vorgehensmodelle 2 1 Das Wassertall Modell x a Sax 28 Due ews ee en aeg 2 2 Der Rational Unified Process 22 22 2 222m nn 2 3 Extreme Programming want ehe Pr ee ir E eg Management Aspekte 3 1 Aufwandssch tzung 2 2 an ow aa aaa ah ara 3 2 Risiko Management sur wa ee nn Go ery E Ae 3 2 1 Ris ko Identifikation dg Er ara en a En Saag a 3 2 2 Risiko Ahalyser a 0 2 4 0006 Sod ele ae ae 3 2 3 Risiko Priorit tenbildung za sam Kerner 3 2 4 Risikomanagement Planung 3 2 5 Risiko berwind ng u au a sad de AC A 3 2 6 E EEN Objektorientierung und UML 4 1 Grundkonzepte der Objektorientierung 4 1 1 Objekte und Klassen 228 22 8 2a 8 u a El a 4 1 2 Attribute und Operationen o 2 22 2 nme ALG VererDime un aa ae ale Bl dee p Sed te 4 2 Unified Modeling Language 2 CE nn nen 4 2 1 Klassendiagramme a Ae water ea e ee ks 4 2 2 Darstellung einer Klasse im Klassendiagramm 4 2 3 Anwendungsfalldiagramme 4 2 4 Bequenzdiasgr mme water ehe ae Pal De par eg 4 2 5
24. als Objekt erlaubt eine Vielzahl von Verwendungsm glichkeiten ggf in Kombination mit anderen Mustern wie z B einen Klienten mit einem austausch baren Befehl zu parametrisieren Operationen in eine Queue zu stellen ein Logbuch zu f hren und Operationen r ckg ngig zu machen In manchen Situationen ist es notwendig Anfragen an Objekte zu stellen ohne irgendetwas ber die auszuf hrende Operation zu wissen oder das Objekt zu kennen an das die Anfrage gerichtet wird Ein Beispiel hierf r sind Klassenbibliotheken f r Benutzungsschnittstellen welche Men s oder Schaltfl chen bereitstellen die als Reaktion auf eine Benutzereingabe eine bestimmte Operation ausl sen Der Entwickler eines solchen Frameworks kennt das Zielobjekt einer Anfrage und die auszuf hrenden Operationen nicht Anwendung K gt Menue MenueEintrag AddDokument 1 AddMenueeintrag Geklickt befehl FuehreAus FuegeHinzu Abbildung 6 5 Entwurfsmuster Befehl am Beispiel Mit dem Befehlsmuster k nnen Anfragen an unbekannte Anwendungsobjekte gerichtet werden indem die Anfrage selbst zu einem Objekt gemacht wird Der Kern dieses Musters ist eine abstrakte Klasse Befehl die eine Schnittstelle zum Ausf hren von Operationen deklariert Im einfachsten Fall ist dies eine abstrakte FuehreAus Operation welche von konkreten Unterklassen implementiert wird Ex emplare dieser Unterklassen werden einem Empf nger bergeben
25. bei OO zumindest Klassendiagramme und oft auch Aktivit tsdiagramme und Use Case Diagramme sowie manchmal weitere Diagramme wie State Charts sollten erstellt und gepflegt werden Werkzeuge CASE Tool zumindest bei Verwendung von OO und UML IDE zur Steigerung der Produktivit t immer zu empfehlen CVS insbesondere bei Teamarbeit immer zu empfehlen Testautomatisierung sollte zur Steigerung der Produktivit t soweit wie m glich genutzt werden Software Entwurf Schichtenarchitektur zur Steigerung der Ubersichtlichkeit Wartbarkeit und Anpassbarkeit fast immer zu empfehlen Middleware zur Senkung des Entwicklungsaufwands bei Informati onssystemen zu empfehlen sofern keine extremen Effi zienzanforderungen bestehen Entwurfsmuster sollte jeder OO Entwickler kennen da sie u a die Wart barkeit und Flexibilit t erh hen Sonstiges EAI bei gro en Unternehmen mit bisher nicht oder schlecht verbundenen Einzelsystemen MDA MDSD bei vielen Versionen Varianten eines Softwaresystems zur Steigerung der Produktivit t nach allerdings erheb lichem Einarbeitungsaufwand Tabelle 1 1 Eignung von Technologien Ma nahmen und Ans tzen Kapitel 2 Vorgehensmodelle in der Software Entwicklung Jedes Softwareprojekt einer nennenswerten Komplexit t sollte in einem mehr oder weniger festgelegten organisatorischen Rahmen verlaufen Obwohl diese Erkennt nis nicht neu ist verlaufen zahlreiche Projekte noch imm
26. das die Anfrage ausl st von dem das wei wie sie umzusetzen ist Zum anderen ist es einfach neue Befehlsobjekte hinzuzuf gen weil keine bereits existierenden Klassen ge ndert werden m ssen Weiterhin kann ein Befehlsobjekt wie jedes andere Objekt auch manipuliert und erweitert werden So lassen sich meh rere Befehlsobjekte zu einem komplexeren Makro Befehl zusammensetzen Die Klassen BinOp und Addition in Abb 4 6 sind ein weiteres Beispiel f r eine Verwendung des Befehlsmusters 6 3 2 Beobachter Oftmals muss man die Konsistenz zwischen den miteinander in Beziehung stehen den Objekten eines Anwendungssystems aufrechterhalten Eine enge Kopplung der Klassen sollte hierbei aus Gr nden der Wiederverwendbarkeit und bersichtlichkeit vermieden werden Beobachter ist ein objektbasiertes Verhaltensmuster bei dem eine 1 n Abh ngigkeit zwischen Objekten definiert wird so dass die nderung des 74 KAPITEL 6 ENTWURFSMUSTER Zustands eines Objekts dazu f hrt dass alle abh ngigen Objekte benachrichtigt und automatisch aktualisiert werden a b c x 60 30 10 y 50 30 20 z 80 10 10 7 Benachrichtigung ber Anderung Anfragen Ver nderungen Abbildung 6 7 Objekt mit unterschiedlichen Visualisierungen Abbildung 6 7 zeigt verschiedene gleichzeitig genutzte Objekte zur Darstellung Beobachter desselben Anwendungsdatenobjekts Subjekt hier einer Tabelle We
27. die Funktion Que ryInterface ben tigt die zu einer bergebenen Schnittstellen ID falls vorhanden eine Referenz auf den zugeh rigen Interface Knoten zur ck gibt Die QueryInterface Funktion wird ben tigt um die von einer Komponente implementierten Schnittstel len zu ermitteln und um die Funktionen der verschiedenen Schnittstellen aufrufen zu k nnen Wie bereits erw hnt dienen die Schnittstellenknoten dazu die Instanzen einer COM Komponente zu unterscheiden Weil eine COM Komponente auch mehrere Interface Knoten besitzen kann werden COM Objekte ber Schnittstellenknoten der Unknown Schnittstelle identifiziert Alle Schnittstellen eines COM Objekts ge ben beim Aufruf der QueryInterface Funktion mit der ID der Unknown Schnitt stelle als Parameter die Referenz auf den selben Interface Knoten zur ck Dies gew hrleistet die eindeutige Identifizierbarkeit von COM Objekten ASP NET ASP NET Mic07a ist das Web Framework der NET Plattform welches die Er stellung von Web Anwendungen und Web Services unterst tzt Im Gegensatz zur Java EE Plattform f r die es viele Web Frameworks mit unterschiedlichen Schwer punkten und Zielsetzungen gibt ist ASP NET das einzige Web Framework f r die NET Plattform ASP NET ist der Nachfolger der Active Server Pages ASP Tech nologie und bietet generische L sungen f r die blichen Probleme die bei der Pro grammierung von Webanwendungen auftreten Es gibt zum Beispiel L sungen f r Sitzung
28. durch eine so genannte Klasse Ein einzelnes Objekt geh rt immer nur zu einer Klasse und kann diese Zugeh rigkeit nicht ndern Ein Objekt wird auch als Instanz seiner Klasse bezeichnet 4 1 2 Attribute und Operationen Die Struktur eines Objekts ergibt sich aus seinen Bestandteilen bzw den in ihm ent haltenen Daten Letztere werden auch Attribute genannt Die Objekte einer Klasse besitzen alle die gleichen Attribute unterscheiden sich aber in den Werten die die se annehmen Zwei Objekte mit identischen Attributauspr gungen k nnen ber die Objektidentit ten eindeutig unterschieden werden Die Werte der Attribute k nnen sich im Programmverlauf ndern Dazu werden Operationen auch Methoden ge nannt definiert die die Attributwerte manipulieren und das m gliche Verhalten der Objekte festlegen Operationen werden in der jeweiligen Klasse definiert und sind f r alle Objekte einer Klasse gleich Eine direkte Manipulation der Attribute durch Operationen anderer Klassen sollte unterbleiben Als spezielle Operationen einer Klasse sind die Konstruktoren sowie die Destruktoren zu nennen Ein Konstruktor erzeugt ein neues Objekt einer Klasse ein Destruktor l scht ein Objekt 4 1 3 Vererbung Mit dem Konzept der Vererbung lassen sich Spezialisierungsbeziehungen zwischen Klassen herstellen Oftmals k nnen gewisse Objekte einer Klasse mit weiteren spe ziellen Attributen ausgestattet werden so dass diese Objekte eine spezialisierte Va riant
29. ergibt Risikofaktor Schadenswahrscheinlichkeit x Schadensausma Ein unbefriedigendes Ergebnis liegt vor wenn die Hauptbeteiligten an einem Software Projekt durch das Ergebnis einen Schaden erleiden 1 f r Kunden und Entwickler Kosten und Termin berschreitungen 2 f r Benutzer falsche Funktionalit t mit Defiziten der Benutzeroberfl che Leistung oder Zuverl ssigkeit 3 f r Wartungsingenieure schlechte Qualit t 3 2 3 Risiko Priorit tenbildung Um zu verhindern dass die wirklich relevanten Risiken angemessen beachtet wer den empfiehlt es sich die Risiken nach ihrem Risikofaktor zu sortieren Oftmals ist es sehr schwierig die Eintrittswahrscheinlichkeiten hinreichend genau zu sch tzen Eine vollst ndige Risiko Analyse w rde jedoch teure und in der Entwicklung zeit aufw ndige Prototypen Leistungsmessungen und Simulationen erfordern so dass man sich im Allgemeinen mit groben Sch tzungen zufrieden gibt 3 2 4 Risikomanagement Planung Nachdem die Hauptrisikoelemente ermittelt wurden muss f r jedes Risikoelement ein Risiko Plan entwickelt werden welcher die zur Kontrolle des Risikoelements notwendigen Aktivit ten spezifiziert Eine Hilfe hierzu gibt Tabelle 3 4 in wel cher erfolgreiche Risikomanagement Techniken f r die wichtigsten Risikoelemente aufgelistet sind Der letzte Planungsschritt besteht darin die Risikopl ne in den bergeordneten Projektplan zu integrieren 3 2 5 Risiko berwindung
30. fiir deren Eigenschaften und zukiinftige Entwicklungspotentiale Aufgrund ihres grundlegenden Charakters und der mit ihrer Einf hrung verbundenen hohen Kapitalbindung ist sie von l ngerfristiger Wirkung und kann nachtr glich nur mit hohem Aufwand korrigiert oder zur ckgenommen werden Der auf kurzfristige Sicht attraktivste Ansatz kann sich l ngerfristig als Sackgasse f r die Fortentwicklung der betrieblichen Informationsverarbeitung er weisen Eine Entscheidung f r einen bestimmten Architekturansatz sollte demnach wohl berlegt sein und gen gend Flexibilit t bieten um nicht nur gegenw rtigen sondern auch zuk nftigen Anforderungen begegnen zu k nnen Im den folgenden Abschnitten werden drei grundlegende Ans tze f r die Gestaltung einer Integrati onsinfrastruktur vorgestellt Um Handlungsempfehlungen f r die Praxis ableiten zu k nnen sollen dabei vor allem deren spezifische Vor und Nachteile sowie m gliche Restriktionen herausgestellt werden 9 3 1 Punkt zu Punkt Integration Die Punkt zu Punkt Integration vgl Abbildung 9 1 stellt weniger eine Integrati onstopologie dar als vielmehr einen Hinweis auf das Fehlen einer solchen System System 2 3 System System 1 4 System System 6 5 Abbildung 9 1 Vollst ndige Punkt zu Punkt Integration von sechs Systemen Bei der Punkt zu Punkt Integration werden jeweils zwei Systeme bedarfsgetrie ben b
31. inhaltlich klar abgegrenz te und f r den praktischen Einsatz geeignete Funktionalit t ab Sie k nnen durch den Dienstanbieter ber ein ffentlich zug ngliches Verzeichnis Dienst Registry zur Verf gung gestellt und von einem Dienstkonsumenten anhand ihrer Beschrei bung zur Laufzeit eingebunden werden Elementare Dienste lassen sich durch eine so genannte Orchestrierung zu komplexen Diensten kombinieren welche wiederum ver ffentlicht werden k nnen Technologisch beruhen Web Services auf den XML basierten Standards SOAP WSDL Web Services Description Language und UDDI Universal Description Dis covery and Integration Wor07a Ein SOAP Aufruf l sst sich als XML Dokument verstehen welches einen Methodenaufruf beschreibt Die grundlegende Semantik einer SOAP Nachricht entspricht somit im Wesentlichen der eines RPC Aufrufes SOAP Nachrichten k nnen mithilfe verschiedener Protokolle wie HTTP UDP oder SMTP Simple Mail Transfer Protocol bertragen werden Firewallprobleme wie sie im Zusammenhang mit JMS beschrieben wurden k nnen h ufig umgangen wer den wenn HTTP als bertragungsprotokoll gew hlt wird WSDL erlaubt es die 104 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION durch einen Klienten zugreifbaren Funktionen eines Web Service zu definieren sowie deren Schnittstellen zu beschreiben Im Einzelnen beinhaltet ein WSDL Dokument Angaben iiber Parameter und Riickgabewerte der Funktionen eines Web Service sowie allgemeine Zugr
32. modularen Sprachen wie z B Visual Basic Ada und Modula Die Kapselung allein kann also nicht der Grund f r den Siegeszug der Objektorientierung sein Ein mindestens ebenso wichtiger Aspekt ist die Vererbung die kennzeichnen des Merkmal objektorientierter Sprachen ist Sie erlaubt Spezialisierungen einer Klasse in Form von so genannten Unterklassen zu bilden welche die Struktur und das Verhalten ihrer Oberklasse erben Dies erm glicht zun chst eine Wiederver 25 26 KAPITEL 4 OBJEKTORIENTIERUNG UND UML wendung von Code Methoden der Oberklasse brauchen in den Unterklassen nicht erneut implementiert zu werden Bei Bedarf d rfen ausgew hlte Methoden in ei ner Unterklasse aber wie man sagt berschrieben d h neu implementiert werden Dies erm glicht eine Reihe von m chtigen Programmiertechniken Alle der in Unter kapitel 6 vorgestellten Entwurfsmuster verwenden Vererbung oft in Kombination mit berschreiben von Methoden um die zur L sung der betrachteten Proble me ben tigte Flexibilit t zu gewinnen Vererbung sorgt beispielsweise daf r dass das objektorientierte Gegenst ck zu klassischen Software Bibliotheken die so ge nannten Frameworks flexibler als konventionelle Bibliotheken sind Letztere k nnen ganz oder gar nicht genutzt werden Bei der Verwendung von Frameworks dagegen k nnen die fehlenden oder nicht passenden Methoden durch berschreiben in selbst erstellten Unterklassen erg nzt bzw ersetzt werden so das
33. sie in der eigenen Firma sinnvoll umsetzen In Kapitel 3 wird dann zun chst ein Ansatz zur Sch tzung des Aufwands eines Projekts vorgestellt die Function Point Analyse Sie liefert typischerweise mit ge ringem Aufwand genauere Ergebnisse als ein simpler Vergleich mit abgeschlossenen Projekten oder eine rein erfahrungsbasierte Sch tzung wie man sie h ufig vorfindet Weiterhin wird in diesem Kapitel ein systematisches Vorgehen zur Identifikation von Risiken bei einer Softwareentwicklung sowie zu deren Bewertung und Beherrschung vorgeschlagen Vor dem Hintergrund dass auch heute noch ein erheblicher Prozent satz der Softwareprojekte scheitert ist eine systematische Behandlung der Risiken empfehlenswert In Kapitel 4 werden die Vorteile der objektorientierten Softwareentwicklung her ausgearbeitet Letztere wird zwar in der Praxis vielfach eingesetzt Aber es ist vermutlich nicht jedem klar worin die Vorteile im Einzelnen liegen W hrend bei eingebetteten System wie Waschmaschinen Supermarktkassen und Aufz gen auch klassiche imperative Sprachen wie C nach wie vor ihre Vorz ge haben so k nnen objektorientierte Sprachen wie Java C und C gerade bei gr eren Software systemen und Informationssystemen ihre besseren Strukturierungsm glichkeiten aus Sicht der so genannten Programmierung im Gro en ausspielen Hinzu kommt dass die objektorientierte Softwareentwicklung durch das Vorhandensein einer standardi sierten Modellierungssprache d
34. t ASP NET und bietet eben falls L sungsans tze f r die oben genannten zentralen Aufgaben der Web Programmierung Zudem besitzt ASP NET ein Code Behind Modell das die klare Trennung von Layout und Gesch ftslogik erm glicht e Komponentenbasierung Die Einf hrung von Komponenten erm glicht auch f r Webseiten ein intuitives ereignisbasiertes Programmiermodell mit Steue relementen die einen persistenten Zustand besitzen Komponenten werden bei Java EE nur durch einige wenige Web Frameworks wie JavaServer Fa ces oder Tapestry unterst tzt ASP NET erm glicht ein komponentenbasiertes Programmiermodell durch den Einsatz von serverseitigen Web Controls Gesch ftslogik e Transaktionen Beide Frameworks unterst tzen sowohl automatisches als auch manuelles Transaktionsmanagement e Entfernte Methodenaufrufe Java EE bietet bei entfernten Methodenauf rufen vollst ndige Ortstransparenz weil alle Komponenten ber JNDI ermit telt werden Durch die strikte Verwendung von Schnittstellen wird so auch eine automatische Lastverteilung erm glicht Bei NEI liegt Ortstransparenz 62 KAPITEL 5 SOFTWAREARCHITEKTUREN nur bei expliziter Verwendung von NET Remoting vor Ohne Remoting sind nur lokale Aufrufe m glich Dieser Ansatz bietet nur bedingt Ortstransparenz daf r sind die expliziten lokalen Aufrufe jedoch schneller als bei Methodenauf rufen mit vollst ndiger Ortstransparenz Web Services Beide Frameworks bieten eine gute Integ
35. ufig in speziell f r diese Aufgabe ent wickelten Templatesprachen entwickelt F r jede Zielplattform gibt es jeweils eigene Transformationsregeln Damit in den Modellen plattform spezifische Einstellungen vorgenommen werden k nnen m ssen sie semantisch angereichert werden Dies ge schieht durch so genannte Stereotype mit denen sich Modellelemente wie z B Klas sen und Methoden genauer charakterisieren lassen Wenn beispielsweise eine Klasse Exemplar vom Modellierer mit dem Stereotyp Entity versehen wird vgl Abb 10 1 so bedeutet dies f r eine Transformation des Modells im Hinblick auf die Zielplatt form Enterprise JavaBeans vgl Abschitt 5 2 3 dass diese Klasse als Entit tsklasse realisiert und deren Objekte vom EJB Container verwaltet und mit den zugeh ri gen Tupeln der entsprechenden Datenbanktabelle synchronisiert werden sollen Der in diesem Beispiel generierte Java Code kann wie in Abbildung 10 2 aussehen Ne ben EJB spezifischen Annotationen Entity ManyToOne usw wurden get und set Methoden f r das Attribut inventarnr und die Assoziation zur Klasse Buch an gelegt Die Transformation wird bei oAW durch ein Template in der Sprache xPand 109 110 KAPITEL 10 MODELL GETRIEBENE SOFTWARE ENTWICKLUNG beschrieben Das hier verwendete Template ist in Abbildung 10 3 zu sehen In diesem Template werden einige Hilfsfunktionen wie z B getPackageName getVisibility getStatic getTypeName getAttributeName und isMultiple verwen
36. zur Zusammenf hrung einige Jahre parallel zu diesem entwickelt VORTEILE NACHTEILE Das Standard Framework Umst ndliche ActionForms Gute Dokumentation Keine Unit Tests m glich Gute Tag Bibliothek Quelle Raible Rai07 Tabelle 5 3 Vor und Nachteile des Struts Frameworks 54 KAPITEL 5 SOFTWAREARCHITEKTUREN JavaServer Faces hnlich wie viele andere Web Frameworks basiert JavaServer Faces JSF Sun07b HS06 auf dem Model View Controller Paradigma Der Unterschied zu andern Fra meworks liegt in der Erzeugung der Webseiten welche aus einzelnen Ul Komponenten zusammengesetzt werden Dieser komponentenbasierte Ansatz weist ein h heres Abstraktionsniveau auf und macht die HTML Programmierung zu weiten Teilen berfl ssig VORTEILE NACHTEILE Java EE Standard komplexe Tag Bibliothek Leicht und schnell erlernbar Mehrere konkurrierende Implemen tierungen Viele Komponentenbibliotheken Quelle Raible Rai07 Tabelle 5 4 Vor und Nachteile des JSF Frameworks UI Komponenten besitzen einen Zustand der w hrend eines Request Response Zykluses erhalten bleibt und erzeugen ihre eigene HTML Repr sentation wodurch die Programmierung einer Web Oberfl che deutlich leichter und intuitiver gestaltet wird Dar ber hinaus verf gt JSF ber ein serverseitiges Ereignismodell Hierbei werden die Eingaben des Benutzers auf der Clientseite in Ereignisse auf der Server se
37. 2 in dieser Brosch re verwiesen Da Objekte ihre innere Struktur hinter einer Schnittstelle verbergen kann sich die Implementierung einer Methode ndern ohne dass sich zwangsl ufig die Im plementierung der zugreifenden Klienten ndern muss Dar ber hinaus k nnen Ob jekte aufgrund der objektorientierten Mechanismen der Vererbung und der Poly morphie entsprechend ihrer Klassenzugeh rigkeit beim Aufruf der gleichen Metho de ein v llig unterschiedliches Verhalten zeigen Die zentrale Aufgabe einer kom ponentenorientierten Middleware Plattform besteht demnach darin eine Verbin dung zwischen einem Klienten und einem entfernten Objekt zu etablieren und die Interaktion zwischen diesen zu vermitteln Erg nzend werden von den einzelnen Middleware Systemen zus tzliche zumeist plattform und herstellerspezifische Funk tionen bereitgestellt welche Aspekte wie die Suche und Verwaltung von Objekten die Durchf hrung von Transaktionen oder die Authentifizierung und Autorisierung von Benutzern betreffen Diese sollen an dieser Stelle jedoch nicht weiter vertieft werden Das Hauptproblem nicht nur in RPC basierten Integrationsans tzen sondern auch bei der Verwendung komponentenorientierter Middleware ist die enge Kopp lung zwischen den integrierten Systemen Bei einer Funktionsintegration auf Code oder Komponentenebene kann neue Funktionalit t nur durch Anpassung und an schlie ende Neu bersetzung eines Systems integriert werden Sind die An
38. Aktivitatsdiapramme 3 4 2 4 Sa ae 4 2 6 Weitere UML Diagramme 11 17 17 19 20 Ab 21 21 21 22 vi INHALTSVERZEICHNIS Softwarearchitekturen 39 5 1 Schichtenarchitekturen e 39 5 1 1 Das Client Server Modell e 39 5 1 2 Aufbau von Schichtenarchitekturen 0 40 5 1 3 Vergleich von Schichten Architekturen 42 5 2 Komponentenbasierte Architekturen 2 2 222222 nen 45 31 Komponenten san a o a Na een Beet 46 DD SGORBA A re a a Da nee na 47 Eh laueren le Baal dr Rn weeds Ars aha 49 sicht ANETTE ae a ER de NR en rn Bene 56 5 2 9 Vergleich Java EE und NET 2 222 E er Go ebe A Ae 60 Entwurfsmuster 65 6 1 Erzeugungsmuster EE EENHEETEN 66 6 1 1 Abstrakte Fabrik tags aad et ae Sot een eat ees A 66 6 1 2 Weitere Erzeugungsmuster 2 2 22 nennen 68 6 2 Strukturmuster 2 Hmm 68 6 2 1 Adapter rest ee ns ee ae ee ee E 69 6 2 2 Weitere Strukturmuster e 71 6 3 Verhaltensmuster e 72 6 3 1 Befehl 2 22 Comm nen 72 6 3 2 Beobachter 73 6 3 3 Weitere Verhaltensmuster ooo a a a 75 6 4 Weitere Entwurfsmuster e 76 Testen 77 7 1 Isolation zu testender Einheiten e CE 7 2 Automatisierung des Testens 0 00002 0a ee 79 3 Black Box Lesten 24 2234 2 2 3 22 Ae Ge At ee AE 80 7 4 Glass Box Testen 81 Tools 83 8 1 Versionsverwaltung lt 2 eal 3 8 au a Side Boe es 83 ala Aufgaben a 2 chat a os 2er area 83 8 1 2 Funktionsweise e 84 825 MGB OGIS we zu he cue ee Soi ee ee A e
39. Benutzeroberfl chen Die Aufgaben der Benutzeroberfl che werden dabei folgender ma en auf die drei Komponenten Model View und Controller aufgeteilt das Model speichert die Daten der Anwendung die View ist f r die visuelle Repr sentation der Daten verantwortlich der Controller enth lt die Anwendungslogik der Anwendung und steuert das Zusammenspiel zwischen View und Model Das Struts Framework stellt einen zentralen Controller das ActionServlet be reit Alle Seiten Request werden an den zentralen Controller in Form von Actions die in einer zentralen Konfigurationsdatei definiert werden geschickt Der Control ler ruft die mit einer Action verkn pfte Action Klasse auf die daraufhin das an wendungsspezifische Model manipuliert Anhand eines zur ckgegebenen ActionFor ward Codes kann der Controller die an den Client zu schickende Antwortseite iden tifizieren Von zentraler Bedeutung f r die Funktionsweise des Struts Frameworks ist die oben bereits erw hnte Konfigurationsdatei in der der gesamte Kontrollfluss der Web Anwendung definiert wird Obwohl Struts ein sehr ausgereiftes und popul res Framework ist werden heute immer h ufiger auch neuere leichtgewichtige Frameworks wie JSF Spring MVC oder Tapestry eingesetzt Weitere Verbesserungen sollen mit dem Struts 2 0 Framework das eine Integration von Struts mit dem WebWork Framewok darstellt eingef hrt werden WebWork ist aus dem Struts Framework entstanden und wurde bis
40. Benutzeroberfl chen Man kann Ereignis folgen bestehend aus Klicks Mausbewegungen Textfeldeintr gen usw wie sie bei der Bedienung einer graphischen Benutzeroberfl che anfallen aufzeichnen und zur Durchf hrung eines Tests automatisiert wieder abspielen Hierbei l sst sich dann pr fen ob das System erwartungsgem reagiert Problematisch bei diesem Testen der graphischen Benutzeroberfl che kann die mangelnde Robustheit der Testf lle gegen ber nderungen an der Benutzeroberfl che sein Nur die ausgereifteren Tools erlauben eine Weiterverwendung von Testf llen nach nicht trivialen nderungen an den entsprechenden Fenstern Die oben genannten Tools zum Testen von Webappli kationen sind hier deutlich robuster da HTML einen gezielteren Zugriff auf Be dienelemente zul sst als das die Pixeldarstellung eines Fensters einer konventionel len graphischen Benutzeroberfl che bietet Dies ist nicht nur ein weiteres Argument f r Webapplikationen sondern er ffnet auch die M glichkeit in der Testphase mit einer Weboberfl che zu arbeiten die dann sp ter ggf durch eine konventionelle gra phische Benutzeroberfl che ersetzt bzw hierum erg nzt wird Insbesondere bei NET und den dort vorliegenden hnlichkeiten zwischen Webforms und konventionellen Fenstern sollte dies mit berschaubarem Aufwand realisierbar sein 7 3 Black Box Testen F r das Erstellen von Testf llen gibt es im Wesentlichen zwei Ans tze Black Box Testen und Gla
41. E und NET ge geniibergestellt und wichtige Gemeinsamkeiten und Unterschiede zwischen beiden 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 61 Frameworks beschrieben CORBA wird aufgrund der relativ geringen Verbreitung und abnehmenden praktischen Relevanz nicht in diesen Vergleich mit einbezogen Abbildung 5 13 stellt die Architekturen einer Java EE und einer NET Anwendung vergleichend gegen ber Gegenstand des Vergleichs sind die Pr sentationsschicht die Gesch ftslogikschicht und die Plattformen die den beiden Frameworks zugrun de liegen Die Unterschiede innerhalb der einzelnen Schichten werden im Folgenden genauer beschrieben Pr sentationsschicht e HTML Erzeugung Die dynamische Generierung von HTML Seiten geschieht bei Java EE mithilfe von Servlets oder JSP Seiten Das NET Framework ver wendet f r diese Aufgabe ASPX Seiten die von ihrem Aufbau in etwa mit JSP Seiten vergleichbar sind Hinsichtlich der automatischen Integration von JavaScript Code zur Client seitigen Pr fung von Benutzereingaben zeigt sich dass die ASPX Technologie etwas komfortabler ist e Web Frameworks F r Java EE gibt es eine Vielzahl von Frameworks die JSPs bzw Servlets um weitere generische L sungen wie Sitzungsverwaltung Sicherheit Validierung Internationalisierung und Seitennavigation erweitern Dar ber hinaus besitzen die Frameworks unterschiedliche Ans tze zur Tren nung von Layout und Gesch ftslogik Das Web Framework der NET Plattform hei
42. Kan ale Dee at 86 8 2 1 Funktionsweise e 86 82 2 Auswahl von CASE Plattformen 86 8 2 3 Test Werkzeuge 4 2 fo ok sa ee ana a Dre Er 88 8 2 4 Werkzeuge zur Architekturtiberwachung 88 INHALTSVERZEICHNIS 9 Enterprise Application Integration 9 1 Heterogene Systemlandschaften 9 2 Motivationen f r IntegrationsmaBnahmen 9 3 EAl Architekturkonzepte 02 0002 eee 9 3 1 Punkt zu Punkt ntegration 2 see ete eS 9 3 2 Hub and Spokes Integration 0 9 33 Eer A Ar Goad Geek hed er de Se Ske u 9 4 Integrationsebenen 9 4 1 Integration auf Datenebene 0 4 9 4 2 Integration auf Funktionsebene 9 4 3 Integration ber die Benutzerschnittstelle 2 9 5 Zusammenfassende Bewertung 10 Modell getriebene Software Entwicklung vi 89 90 90 92 92 93 93 94 94 96 105 107 109 viii INHALTSVERZEICHNIS Abbildungsverzeichnis 2 Wasserf llm dell e 5 8 2 5 4 4 a Eech o PS SER OY PERS 7 2 2 Rational Unified Process 3 aa aa aa Arie ale Able a 10 2 3 Extreme Programming au arte rear 11 3 1 Die sechs Schritte des Risikomanagements 20 4 1 Beispiel Klasse Rechteck im Klassendiagramm 28 4 2 Beispiel Klassenhierarchie und zugeh riger Java Code 30 4 3 Klassendiagramm mit Assoziation e 31 4 4 Klassendiagramm mit Aggregation und Komposition 31 4 5 Klassendiagramm f r ein
43. Krankenhaus Softwaresystem 32 4 6 Klassendiagramm f r arithmetische Ausdr cke 33 4 7 Beispiel Anwendungsfall Diagramm ooa oa a a 34 4 8 Sequenzdiagramm f r die Auswertung eines arithmetischen Ausdrucks 35 4 9 Aktivit tsdiagramm f r die Fr hst ckszubereitung 37 5 1 Das Client Server Modell 4 5 IER 40 5 2 Strikte lineare und baumartige Schichtenstruktur 2 41 5 3 Schichtenarchitektur f r Desktop Anwendungen 43 5 4 Schichtenarchitekturen f r Web Anwendungen 44 5 5 Multi Channel Architektur ooa nn 46 5 6 Architektur eines CORBA Systems 48 5 7 Entfernter Methodenaufruf mit CORBA 48 5 8 Architektur einer Java EE Anwendung 50 5 9 Aufbau einer EJB Komponente 51 5 10 Common Language Infrastructure 2 2 2 2m a 57 5 11 Architektur des NET Frameworks 00 97 5 12 Aufbau einer COM Komponente 2 22 nn nn 58 5 13 Vergleich Java EE und NET Architektur 0 60 6 1 Entwurfsmuster Abstrakte Fabrik am Beispiel 2 2 2 2 67 6 2 Entwurfsmuster Adapter am Beispiel 69 6 3 a Adapter va as hae Ed a Ri En a Ra ved Os 70 ix ABBILDUNGSVERZEICHNIS 6 4 Ob jekt Ada pt t yx act yk ac oar heed meh ee gree hn Seats A ate eh 6 5 Entwurfsmuster Befehl am Beispiel 6 6 Entwurfsmuster Befehl ere dE besen a Zeile Ge eg te 6 7 Objekt mit unterschiedlichen Visua
44. Nachdem die Risikopl ne aufgestellt wurden werden die dort festgelegten Akti vit ten zur Risiko Minimierung ausgef hrt Beispielsweise wird ein Prototyp erstellt oder es werden die Anforderungen gelockert 22 KAPITEL 3 MANAGEMENT ASPEKTE Risikoelement Risikomanagement Techniken 1 Personelle Defizite qualifizierte Mitarbeiter einstellen Teams zusammenstellen 2 Unrealistische Termin und Kostenvorgaben detaillierte Kosten und Zeitsch tzung mit mehreren Methoden Produkt an Kostenvorgaben orientieren Inkrementelle Entwicklung Wiederverwendung von Software Anforderungen streichen Features 3 Entwicklung von falschen Benutzerbeteiligung Funktionen und Eigenschaften Prototypen Fr hzeitiges Benutzerhandbuch 4 Entwicklung der falschen Prototypen Benutzungsschnittstelle Aufgabenanalyse Benutzerbeteiligung 5 Vergolden Anforderungen streichen Realisierung nicht geforderter Prototypen Kosten Nutzen Analyse Entwicklung an den Kosten orientieren 6 Kontinuierliche Anforderungs nderungen hohe Anderungsschwelle Inkrementelle Entwicklung nderungen auf sp tere Erweiterungen verschieben erledigten Auftr gen 7 Defizite bei extern Leistungstest gelieferten Komponenten Inspektionen Kompatibilit tsanalyse 8 Defizite bei extern Prototypen Fr hzeitige berpr fung Vertr ge auf Erfolgsbasis 9 Defizite in der E
45. Rechteck mit der Ausnahme weiter so wird der Fehler durch den entsprechenden Ablauf behandelt Aktivit ten mit einem Gabel hnlichen Symbol werden durch eigene Aktivit ts diagramme verfeinert Aktivit tsdiagramme k nnen horizontal in Bereiche unterteilt werden die jeweils einem ber dem Bereich angegebenen Bearbeiter zugeordnet werden Dieser Bear beiter ist f r die Ausf hrung der Aktivit tsfolge in seinem Bereich verantwortlich 4 2 UNIFIED MODELING LANGUAGE 37 Fr hst cksgetr nkezubereiter Koch Anfangsknoten Partition Fallunterscheidungsknoten e kein Kaffee verfeinerte Aktivit t Verzweigungskonten Kaffee vorhanden d Ausnahme behandlung Ausnahmekante nicht behandelte Ausnahme a Objektflussknoten Aktivit ts en Tase Licht geht aus Vereinigungskonten Fallunterscheidungsende ER Kaffee Endknoten Abbildung 4 9 Aktivit tsdiagramm f r die Fr hst ckszubereitung Abb 4 9 zeigt ein Aktivit tsdiagramm f r die Zubereitung eines Fr hst cks Das Diagramm besteht aus zwei Bereichen der linke Bereich modelliert die Bereitstel lung eines Getr nks durch einen Fr hst cksgetr nkezubereiter w hrend im rechten Bereich die Zubereitung von Muesli durch einen Koch dargestellt wird Der Ablauf wird gleich am Anfang in die beiden genannten Teilabl ufe aufgespalten und am Ende wieder zusammengef hrt Im linken B
46. UER Andreas GNZEL Holger Data Warehouse Systeme Architek tur Entwicklung Anwendung 2 Heidelberg dpunkt Verlag 2001 Bij 5NKE Jana JOHANNES Hermann ODBC Optimaler Einsatz im Client Server Umfeld 1 Mnchen Addison Wesley 1997 BURKE Bill MONSON HAEFEL Richard Enterprise JavaBeans 3 0 5 O Reilly Media 2006 BOEHM Barry W Software Risk Management 1 IEEE Computer Society Press 1989 113 114 Boe91 Bor07 CHK06 Co107 EFH 07 ELO7 Fai94 Fej08 Fow05 GHJV96 Hen06 H0106 LITERATURVERZEICHNIS BOEHM Barry W Software Risk Management Principles and Practices In IEEE Software 8 1991 Nr 1 S 32 41 BORLAND Borland Together http www borland com us products together index html Abrufdatum 17 07 2007 CDKM02 CoULOURIS George DOLLIMORE Jean KINDBERG Tim MUHR Judith Verteilte Systeme Konzepte und Design 1 Mnchen Pearson Studium 2002 CONRAD Stefan HASSELBRING Wilhelm KOSCHEL Arne Enter prise Application Integration Grundlagen Konzepte Entwurfsmuster Praxisbeispiele 1 Mnchen Spektrum Akademischer Verlag 2006 COLLABNET Subversion http subversion tigris org Abrufda tum 17 07 2007 EFFTINGE Sven FRIESE Peter HAASE Arno KADURA Cle mens KOLB Bernd Mororr Dieter THOMS Karsten V LTER Markus open Architecture Ware User Guide Version 4 2 http www eclipse org gmt oaw doc 4 2
47. UG zertifizierten Be rater zur ckgreifen Die FPA eignet sich nicht nur zur Sch tzung des Aufwands von Software Projek ten sondern u a auch zur Bewertung von Altsystemen sowie von Angeboten von Auftragnehmern und bei Make or Buy Entscheidungen Im Gegensatz zu lteren Verfahren die mit unbefriedigendem Erfolg versucht haben den Aufwand eines Projekts auf der Basis von ebenfalls unbekannten und gesch tzten Codezeilen vorherzusagen basiert die FPA auf den fachlichen Anforde rungen wie sie in einem Lasten oder Pflichtenheft formuliert sind Zur quantitativen Bestimmung des fachlichen Funktionsumfangs einer IT Anwendung zerlegt die FPA diese aus Sicht der Anwender in ihre Elementarprozesse Ein Elementarprozess ist die aus Anwendersicht kleinste sinnvolle und in sich abgeschlossene Aktivit t die mit dem System durchf hrbar ist Unterschieden werden die Elementarprozesse Einga 17 18 KAPITEL 3 MANAGEMENT ASPEKTE Eingaben Ausgaben und Abfragen b e 1 4 5 15 gt 16 b e 1 4 6 19 gt 20 0 1 e e m 0 1 e e m 2 e m k 2 3 e m k gt 3 m k k gt 4 m k k Tabelle 3 1 Zuordnung von Komplexit tsstufen einfach e mittel m komplex k f r Eingaben Ausgaben und Abfragen abh ngig von der Anzahl e der betrof fenen Datenelemente und der Anzahl b der betroffenen Datenbest nde f e 1 19 20 50 gt 51 1 e e m 2 5 e m k gt 6 m k k Tabelle 3 2 Z
48. UREN 45 SCHICHTENARCHITEKTUREN MERKMAL KLASSISCH WEB Plattform Eingeschr nkt da Desk Gegeben Es m ssen u U unabh ngigkeit top Clients oft plattfor jedoch unterschiedliche Web mabh ngig sind Browser unterst tzt werden Verteilung Aufw ndig da Client Leicht keine anwendungsspe Software auf dem Client zifische Software auf dem Web installiert werden muss Client zu installieren Skalierbarkeit Gut Gut Wartbarkeit Eingeschr nkt da Client Gut Software evtl neu installiert werden muss Sitzungs Leicht da eine permanente u a durch Cookies verwaltung Verbindung besteht angelehnt an Balzert Bal01 S 703ff Tabelle 5 2 Vergleich von Schichtenarchitekturen Abbildung 5 5 zeigt eine Multi Channel Architektur die ber die verschiedenen Module der Pr sentationsschicht unterschiedliche Zugriffsm glichkeiten auf das Sys tem bietet Die Dienste des Systems k nnen ber einen Desktop einen Web oder einen Web Service Client in Anspruch genommen werden Aufgrund der Schichten architektur greifen alle Module der Pr sentationsschicht auf die gleiche Gesch ftslogik zu Gesch ftslogik und Datenhaltung m ssen daher nur einmalig implementiert wer den wodurch der Aufwand f r die Erweiterung des Systems um neue Zugangsm g lichkeiten minimiert wird 5 2 Komponentenbasierte Architekturen In der komponentenbasierten Softwareentwicklung wird ein Softwaresystem a
49. Vielzahl von Werkzeugen zur ckgegriffen werden um u a Aspekte wie Ver sionsverwaltung Modellierung Implementierung und Testen zeitgem handhaben zu k nnen Hierauf wird in Kapitel 8 eingegangen Ein Thema mit dem sich z Z viele Firmen besch ftigen ist die so genannte Enterprise Application Integration d h die Integration der verschiedenen in ei nem Unternehmen vorhandenen Softwaresysteme Ziel ist die Unterst tzung neuer Gesch ftsprozesse oder die Beschleunigung vorhandener Prozesse Welche Ans tze hierf r in Frage kommen und welche Vor und Nachteile diese haben wird in Kapitel 9 ausgef hrt Kapitel 10 besch ftigt sich mit der Modell getriebenen Softwareentwicklung Hierbei wird Code zum gro en Teil oder manchmal sogar vollst ndig aus Modellen meist UML Modellen generiert Dies hat nicht nur den Vorteil dass Modelle und Code konsistent bleiben sondern erm glicht auch eine erhebliche Steigerung der Pro duktivit t in Situationen in denen h ufig neuen Versionen oder kundenspezisfische oder plattformspezifische Varianten eines Softwaresystems erstellt werden m ssen Auch wenn bereits einige Firmen auch im M nsterland die Modell getriebene Soft wareentwicklung produktiv einsetzen so handelt es sich hier um eine Technologie die ihren Zenit noch vor sich hat Es ist davon auszugehen dass sie in den n chsten Jahren an Bedeutung gewinnen wird Ihr Nachteil liegt darin dass sie mit einem erheblichen Einarbeitungsaufwan
50. XPAND Root FOREACH this allOwnedElements gt lt ENDDEFINE gt DEFINE Root FOR uml Element gt lt ENDDEFINE gt Abbildung 10 3 xPand Transformationsregeln im Buch Beispiel 100 aus den UML Modellen erzeugen Wol08 Im Wesentlichen wurden hierbei Klassendiagramme zur Datenmodellierung und Aktivit tsdiagramme zur Modellie rung der Navigationsstruktur in der webbasierten Benutzeroberfl che benutzt Ex emplarisch wurde so ein Bibliotheksverwaltungssystem vollkommen automatisch aus UML Modellen erzeugt Bei algorithmisch anspruchsvolleren Anwendungen wird ei ne Codegenerierung zu 100 nicht m glich sein jedoch kann auch hier vielfach ein gro er Teil erzeugt werden Nur der verbleibende algorithmisch komplexere Rest muss dann von Entwicklern in so genannten gesch tzten Regionen per Hand erstellt werden Die Modell getriebene Softwareentwicklung ist ein noch junger und in Entwick lung befindlicher Zweig der Softwareentwicklung Gleichwohl wird dieser Ansatz auch von einigen Firmen im M nsterland bereits produktiv eingesetzt und bietet auch f r andere erhebliches Potenzial zur Steigerung der Produktivit t Zu beachten 112 KAPITEL 10 MODELL GETRIEBENE SOFTWARE ENTWICKLUNG ist hierbei allerdings dass der Ansatz einen nicht unerheblichen Einarbeitungsauf wand erfordert und nur geeignet ist wenn die oben erw hnten Rahmenbedingungen viele Versionen bzw Varianten eines Systems f r die jeweils gleichen Plattformen gegeben si
51. agramme Anwendungsfalldiagramm Sequenzdiagramm und Aktivit tsdiagramm 4 2 1 Klassendiagramme Klassen und ihre Beziehungen werden in der UML durch so genannte Klassendia gramme dargestellt Klassenname Attributtyp Zusicherung Rechteck Attribute breite int breite gt 0 Sichtbarkeit hoehe int 4 Initialwert private public getBreite int protected getHoehe int setBreite b int setHoehe h Parameter Operationen Name Typ Initialwert Methoden ae flaeche Abbildung 4 1 Beispiel Klasse Rechteck im Klassendiagramm 4 2 UNIFIED MODELING LANGUAGE 29 4 2 2 Darstellung einer Klasse im Klassendiagramm Die grafischen Darstellung einer Klasse in einem so genannten UML Klassen diagramm besteht aus einem dreigeteilten Rechteck s Abb 4 1 Im oberen Teil steht der Name der Klasse im mittleren die Attribute und im unteren die Metho den Der mittlere und untere Teil k nnen weggelassen werden wenn diese Details nicht betrachtet werden sollen Die Attribute und Methoden sowie deren Parameter k nnen durch eine Typangabe z B int n her charakterisiert werden In der gra fischen Darstellung wird der Typ vom zugeh rigen Bezeichner durch einen Doppel punkt getrennt z B breite int nitialwerte k nnen hinter einem angef gten einem Attribut zugeordnet werden z B hoehe int 4 Zus tzliche Be dingungen Voraussetzungen oder Regeln die die
52. angen ist es daher sinnvoll sich die Aufgaben innerhalb der einzelnen Phasen ge nauer anzuschauen Ein Verzeichnis von CASE Werkzeugen findet sich bei Lam07 F r einen modellgetriebenen Softwareentwicklungsprozess gibt es u a kommerziell erh ltliche Plattformen wie die Rational Suite IBMOTb von IBM oder Borland Together Bor07 von Borland Es existieren aber auch kostenfreie L sungen wie StarUML Sta07 oder EclipseUML Omo07 88 KAPITEL 8 TOOLS 8 2 3 Test Werkzeuge Insbesondere was den Werkzeugeinsatz beim Testen angeht gibt es bei vielen Fir men noch Nachholbedarf Hier l sst sich sowohl die Durchf hrung von Tests als auch die Erstellung von Testf llen zumindest teilweise automatisieren Das Spektrum er streckt sich bez glich der automatisierten Testdurchf hrung von frei verf gbaren Tools f r das Unit Testing wie JUnit Lin05 JUn08 f r Java und Varianten hier von f r andere Sprachen z B NUnit f r C bis hin zu kommerziellen Werkzeugen wie dem IBM Rational TestManager Rat08b und HP Functional Testing HPO8a die neben funktionalen Tests auch das Testen von Benutzerschnittstellen durch Auf zeichnen und Abspielen von Ereignisfolgen unterst tzen Varianten von JUnit wie HttpUnit Fej08 und Cactus Pro08 unterst tzen ebenso wie z B Selenium ope08 und Watij Wat08 das Testen von Webapplikationen Schlie lich gibt es Werkzeuge f r das Performance Testing die festzustellen ge statten ob Leistungsanford
53. ass die beiden Klassen assoziert sind Im Klassendiagramm wird dies dadurch visualisiert dass die beiden Klassen durch eine Linie verbunden werden An dieser Linie kann annotiert werden mit wie vielen Objekten der Nachbarklasse ein Objekt der betrachteten Klasse verbunden ist steht hierbei f r beliebig viele Objekte n m f r mindestens n und h chstens m Nachbarobjekte Weiterhin kann eine As soziation mit einem Namen und mit Namen f r die Rollen jeder Klasse auch Sicht der Nachbarklasse annotiert werden Eine Assoziation wird h ufig dadurch implementiert dass jede beteiligte Klasse Attribute vom Typ der Nachbarklasse bekommt Gibt es nur h chstens ein Nachba robjekt so reicht ein einzelnes Attribut vom Typ der Nachbarklasse Bei mehreren oder beliebig vielen Nachbarobjekten bekommt die Klasse blicherweise als Attribut eine Kollektion Array Liste Menge von Objekten vom Typ der Nachbarklasse Kardinalit t Assoziationsname public class Rechteck protected Bild bild d enthalt public Rechteck int b 7 0 1 int h Bild abb breite b hoehe h bild abb breite hoehe flaeche Komponente Bild Rollennamen Abbildung 4 3 Klassendiagramm mit Assoziation In Abbildung 4 3 wird dargestellt dass ein Bild beliebig viele Rechtecke enth lt w hrend ein Rechteck in h chstens einem Bild vorkommt 4 hat gt 2 Fahrrad E Pai 4 hat gt E Abbildung 4 4 Klassendiagramm mit
54. ationslogik z B zur elementa ren Pr fung der Eingabe und sendet Benutzereingaben an den Web Server zur ck Mit Ausnahme der Aufteilung der Pr sentationsfunktion zwischen Web Browser und Web Server sind die Web Architekturen analog zu den klassischen Schichten architekturen Wie in Abbildung 5 4 dargestellt besitzen Web Architekturen daher blicherweise zwei drei oder vier Schichten F r die Wahl der geeigneten Schichten anzahl gelten die gleichen Argumente die auch bei der Betrachtung der klassischen Schichten Architekturen genannt wurden Vor allem f r komplexere Systeme ist da her eine Architektur mit vier oder mehr Schichten zu bevorzugen Der Abschnitt Multi Channel Architekturen zeigt welche Vorteile die Verteilung der einzelnen Sys temfunktionen auf unterschiedliche Schichten mit sich bringt 44 KAPITEL 5 SOFTWAREARCHITEKTUREN Web Client Web Client Web Client Prasentation Integrierte EE Webzugangs ee E EE LC schicht und Mono Gesch fts G haft Verarbeitung lithisches logik esc a S Server System logik Datenhaltung Datenbank Datenbank 2 Schichten 3 Schichten 4 Schichten Abbildung 5 4 Schichtenarchitekturen f r Web Anwendungen Vergleich Wie bereits erw hnt liegt der Unterschied zwischen klassischen Architekturen und den Web Architekturen in der Umsetzung der Pr sentationsfunktion W hrend die klassischen Architekturen eine Desktop Anwendung benutzen w
55. b Position Punkt position aendere dx dy getPosition Punkt verschiebe dx double dy double abst rakte Methoden flaeche double public abstract double flaeche zeichne public abstract void zeichne public class Rechteck extends Figur double breite hoehe public Rechteck double breite double hoehe Punkt pos this breite breite breite double mitte double this hoehe hoehe hoehe double radius double super pos public double flaeche return breite hoehe public void zeichne Public class Kreis extends Figur analog zu Rechteck Abbildung 4 2 Beispiel Klassenhierarchie und zugeh riger Java Code Abbildung 4 2 zeigt eine sehr einfache Vererbungshierarchie am Beispiel von geometrischen Figuren sowie deren Implementierung in Java Die gemeinsamen At tribute und Methoden von konkreten Figuren wie Rechtecken und Kreisen werden in einer abstrakten Oberklasse Figur zusammengefasst von der keine Instanzen gebildet werden k nnen Jede Figur ist also entweder ein Rechteck oder ein Kreis Alle Figuren k nnen gezeichnet werden und besitzen eine Fl che jedoch unterschei den sich die Implementierungen dieser Methoden da sie in den Unterklassen jeweils 4 2 UNIFIED MODELING LANGUAGE 31 geeignet berschrieben werden Assoziationen Verweisen Objekte einer Klasse dauerhaft auf Objekte einer anderen Klasse so sagt man d
56. beste L sung war Zu den h ufig beanstandeten M ngeln fr herer EJB Spezifikationen z hlen e Geringe Flexibilit t Die Dienste des Frameworks standen nur den EJB Komponenten zur Verf gung Es war nicht m glich einzelne Dienste au erhalb des Frameworks d h ohne vollst ndige Implementierung einer EJB L sung zu nutzen e Aufw ndiges Testen Das Testen von EJB Komponenten konnte mitunter recht teuer und zeitaufw ndig sein da sich einzelne Komponenten nicht au er halb des Frameworks testen lie en Auch f r das Testen kleiner nderungen musste deshalb jedes Mal ein vollst ndiges Deployment durchgef hrt werden e Komplexit t Zu einer EJB Komponente geh rten neben der EJB Klasse mehrere Schnittstellen f r entfernte lokale und administrative Zugriffe auf die Komponente sowie ein Deployment Descriptor Zudem mussten Methoden zum Management des Lebenszyklusses implementiert werden auch wenn diese nicht ben tigt wurden 52 KAPITEL 5 SOFTWAREARCHITEKTUREN Mit den in der EJB Spezifikation 3 0 eingef hrten Neuerungen wird versucht diese Kritikpunkte zu beheben um die Produktivit t bei der Anwendungsentwicklung im Vergleich zu fr heren Versionen zu steigern Zu den wichtigsten Neuerungen geh ren e POJOs Die EJB Klassen m ssen nun keine bestimmten Klassen oder Schnitt stellen des Frameworks mehr erweitern bzw implementieren Das hei t alle durch den Anwender implementierten Objekte sind POJOs Plain Old Java Obje
57. ces for Remote Portlets OASO07b beschreibt wie WSRP kompa tible Portale Anwendungen und Inhalte mithilfe standardisierter Web Services dy namisch integrieren konnen Im Unterschied zu Web Services erlaubt WSRP nicht nur Inhalte und Anwendungslogik sondern auch Darstellungselemente Markup Fragmente zu ver ffentlichen und zu konsumieren Auf diese Weise k nnen Portal betreiber flexibel Angebote nebst ihrer Pr sentation aus verschiedenen organisa tionsinternen und externen Quellen integrieren und dem Benutzer bereitstellen 9 5 Zusammenfassende Bewertung Verglichen mit einer Integration auf Funktionsebene l sst sich eine Datenintegration relativ einfach bewerkstelligen Dies liegt nicht zuletzt daran dass hierf r ein breit gef chertes Angebot an ausgereiften Integrationstechnologien zur Verf gung steht Eine Datenintegration ist daher vor allem dann zu empfehlen wenn ein lesender Zugriff auf die Daten einer Anwendung ben tigt wird Soll ber eine Integration der zugrunde liegenden Datenbasis auch schreibend auf die Daten einer Anwendung zu gegriffen werden so muss mit Problemen durch semantische Heterogenit ten gerech net werden So ist es zum Beispiel denkbar dass eine Anwendung Datens tze in die Datenbank einer Zielanwendung eintr gt die durch diese nicht korrekt interpretiert werden k nnen Eine Integration auf Datenebene verleitet dazu in Ermangelung ei nes Zugriffs auf die Verarbeitungslogik einer Anwendung diese
58. chdem ob sie einen Desktop Client oder einen Web Client als Frontend besitzt Es k nnen jedoch auch beide Varianten in einer Anwendung kombiniert werden Ein Java EE Server umfasst einen Web Server und einen so genannten Applica tion Server Der Web Server stellt die Laufzeitumgebung f r Servlets und JavaServer Pages JSPs die dazu dienen die Webzugangsschicht zu realisieren sie nehmen HTTP Anfragen entgegen und generieren dynamisch HTML Seiten Falls die Be nutzerschnittstelle der Anwendung ausschlie lich ein Desktop Client ist entf llt der Einsatz eines Web Servers Der Application Server stellt die Laufzeitumgebung f r die Gesch ftslogikkomponenten die Enterprise JavaBeans EJBs zur Verf gung Die Gesch ftsprozesse werden dabei durch spezielle EJBs n mlich Session Beans und Message Driven Beans implementiert wobei die Session Beans der Umsetzung von synchronen und die Message Driven Beans der Umsetzung von asynchronen Prozessen dienen Als Datencontainer f r die Gesch ftsdaten dienen die so geann ten Entities fr her Entity Beans dies sind leichtgewichtige POJOs Plain Old Java Objects die durch einen Entity Manager auf die Eintr ge einer relationalen Datenbank abgebildet werden d h es wird daf r gesorgt dass jedes Entity Objekt 50 KAPITEL 5 SOFTWAREARCHITEKTUREN JEE Client Web Client Prasentation EE JSP Servlets Application Server Application Server Session Beans Session Beans Verarbeitung und Message und M
59. che sind die syntaktischen und semantischen Heterogenit ten welche sich aus den spezifischen Anforderungen der einzelnen Anwendungen ergeben Unterschiede auf Daten und Schemaebene ergeben sich durch die Nutzung verschiedener Attribute eines Daten objektes unterschiedliche Datentypen Bezeichnungen Ma einheiten oder Werte bereiche sowie die verschiedenartige Anwendung von Abstraktionsmechanismen wie der Vererbung Um die Datenbest nde verschiedener Anwendungen im Zuge einer Integration zusammenzuf hren m ssen die Heterogenit ten durch Transformation der Daten berwunden werden Eine Transformation kann dabei ausgehend vom Datenmodell einer Datenquelle auf das Datenmodell eines Zielsystems oder auf ein verallgemeinertes f deriertes Datenmodell stattfinden F r die Umsetzung einer Datenintegration bieten sich verschiedene Technologien wie JDBC Java Database Connectivity ME00 ODBC Open Database Connec tivity BJ97 Datentransformationsdienste OLAP Online Analytical Processing Oeh00 und Data Warehousing BGO1 an Eine direkte Vergleichbarkeit der Tech nologien ist nicht gegeben da der Funktionsumfang sehr stark variiert W hrend sich die Funktionalit t von JDBC und ODBC darauf beschr nkt eine definierte und uni versell verwendbare Schnittstelle f r den Zugriff auf verschiedene Datenbanksysteme 96 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION bereitzustellen bieten Datentransformationsdienste und Data Warehouse Sys
60. chtzeitleistung Simulation Leistungstests Modellierung Prototypen Instrumentierung Tuning 10 Uberfordern der Software Technik Technische Analyse Kosten Nutzen Analyse Prototypen Tabelle 3 4 Typische Risiken einer Software Entwicklung 3 2 6 Risiko berwachung Die Fortschritte der Risiko Minimierung m ssen st ndig berwacht werden da mit bei Abweichungen unmittelbar korrigierende Ma nahmen durchgef hrt werden k nnen Eine bew hrte Technik zur Risiko berwachung stellt die Verfolgung der Top 10 Risiken dar welche es dem Manager erm glicht sich jeweils auf die kriti schen Risikoelemente zu konzentrieren Die Verfolgung der Top 10 Risiken beinhal tet folgende Schritte 1 Sortieren der Risikoelemente nach ihrer Priorit t 2 Definieren von regelm igen berpr fungsterminen 3 Erstellen eines Fortschrittsbericht im Vergleich zum vorhergehenden Termin gt gezieltes Beseitigen der aktuellen Risikoelemente 3 2 RISIKO MANAGEMENT 23 Die Risikoelemente werden regelm ig neu bewertet was zur Folge hat dass ei nige der Risikoelemente eine niedrigere Priorit t erhalten oder ganz verschwinden w hrend andere h here priorisiert werden oder neu in die Liste aufgenommen wer den 24 KAPITEL 3 MANAGEMENT ASPEKTE Kapitel 4 Objektorientierung und Unified Modeling Language Die Objektorientierung OO hat sich heute in der Softwareentwicklung weitgehend d
61. cts und besitzen somit keine direkten Laufzeitabh ngigkeiten vom EJB Container Dies f hrt zu einer Komplexit tsreduktion bei den EJB Klassen und erm glicht zudem auch das Testen von Klassen au erhalb des EJB Contai ners Spezielle Data Transfer Objekte zur Weitergabe von Ergebnissen an die Pr sentations oder Webzugangsschicht sind nicht mehr erforderlich e Leichtgewichtiges O R Mapping EJB 3 0 umfasst ein neues Persistenz Framework die Java Persistence API JPA f r das so genannte objektrela tionale Mapping O R Mapping JPA bildet leichtgewichtige Entity Objekte POJOs auf die Eintr ge einer relationalen Datenbanktabelle ab Ein Entity Objekt entspricht dabei einem Tupel in einer relationalen Datenbanktabelle Das Framework sorgt f r Konsistenz zwischen Objektmodell und Datenbank indem es nderungen an den Entity Objekten in die Datenbank bernimmt JPA ist auch ohne einen EJB Container nutzbar und ersetzt die schwergewich tigen Container abh ngigen EntityBeans e Dependency Injection Besitzt eine Komponente Abh ngigkeiten zu ande ren Komponenten so werden diese Abh ngigkeiten nicht durch die Implemen tierung der Komponente festgelegt sondern ber einen Methodenaufruf zur Laufzeit in die Komponente injiziert Dieser Ansatz reduziert die Abh ngig keiten zwischen den Komponenten und erh ht gleichzeitig die Wartbarkeit und Wiederverwendbarkeit der Komponenten e Komplexit tsreduktion Neben den bereits erw hnt
62. d Enterprise JavaBe ans in Verbindung mit RMI sind an die Verwendung der Programmiersprache Java gebunden Die Integration von Fremdsystemen die nicht in Java geschrieben sind ist m glich l sst sich jedoch nur mit zus tzlichem Aufwand realisieren CORBA bietet lediglich eine Spezifikation ohne konkrete Implementierung Die verf gbaren Imple mentierungen weisen dabei herstellerspezifische Erweiterungen und Besonderheiten auf weshalb die Interoperabilit t zweier Implementierungen oftmals nur sicher gestellt werden kann indem auf die Nutzung derartiger Erweiterungen verzichtet wird Dar ber hinaus setzt der objektorientierte Ansatz von CORBA implizit vor aus dass die zu integrierenden Systeme in einer Sprache implementiert wurden die dieses Paradigma unterst tzt Sollen Funktionen und Daten integriert werden die mit einer Skriptsprache wie Perl oder PHP erstellt wurden so sind diese zun chst durch einen so genannten Wrapper vgl Adapter Muster in GHJV96 in ein Ob jekt zu kapseln hnlich wie der RPC Mechanismus basiert komponentenorientierte Middleware auf einem synchronen Kommunikationsmodell Nachrichtenbasierte Middleware Plattformen Im Unterschied zu RPC und RMI unterst tzen nachrichtenbasierte Middleware Plattformen engl Message Oriented Middleware MOM sowohl synchrone als auch asynchrone Kommunikation Dadurch eignen sie sich gleicherma en f r den Aufruf von Funktionen wie auch f r die unidirektionale bertragun
63. d verbunden ist Tabelle 1 1 fasst die behandelten Technologien Ma nahmen und Ans tze zusam men und gibt an wo diese besonders geeignet sind Die Darstellung in der Tabelle ist aus Platzgr nden etwas pauschal Eine genauere Erl uterung finden Sie in den jeweiligen Kapiteln Die Autoren dieser Brosch re sind an Ihren Anregungen und Anmerkungen sehr interessiert Falls Sie solche haben schicken Sie sie bitte per Email an kuchen uni muenster de KAPITEL 1 EINLEITUNG Technologie Ansatz Wo wann geeignet Prozessmodelle ftir die Software Entwicklung Wasserfallmodell bei kleineren und ggf mittleren Projekten mit wenig innovativem Charakter Extreme Programming bei kleinen und mittleren Projekten mit innovativem Anteil und sich w hrend der Entwicklung wandelnden Kundenw nschen Unified Process bei mittleren und gr eren Projekten mit innovativem Anteil inbesondere das iterative Vorgehen ist zur Risi koreduktion empfehlenswert Aufwandsabsch tzung und Risiko Management Function Point Methode falls Umrechnung von Function Points in Mitarbeiter monate aus abgeschlossenen Projekten bekannt Risiko Management bei Projekten mit innovativem Charakter und oder neuen Technologien oder Plattformen Software Entwicklungsparadigmen und Modellierung Objekt Orientierung bei Informationssystemen weniger geeignet bei man chen eingebetteten Systemen UML immer
64. datum 11 04 2008 OASIS ORGANIZATION FOR THE ADVANCEMENT OF STRUCTURED INFORMATION STANDARDS Web Services Business Process Executi on Language Version 2 0 http docs oasis open org wsbpel 2 0 wsbpel v2 0 pdf Abrufdatum 19 09 2007 LITERATURVERZEICHNIS 117 OAS07b OASIS ORGANIZATION FOR THE ADVANCEMENT OF STRUCTURED INFORMATION STANDARDS Web Services for Remote Portlets Version 1 0 Standard Specification OASO7c Obj07 Oeh00 Oes05 Om007 00808 ope08 PBO5 Por07 Pro08 Rai07 Rat07 http www oasis open org committees download php 3343 oasis 200304 wsrp specification 1 0 pdf Abrufdatum 19 09 2007 OASIS ORGANIZATION FOR THE ADVANCEMENT OF STRUC TURED INFORMATION STANDARDS Web Services Security SOAP Message Security 1 1 Standard Specification http www oasis open org committees download php 16790 wss vi 1 spec os SOAPMessageSecurity pdf Abrufdatum 19 09 2007 OBJECT MANAGEMENT GROUP CORBA http www corba org Abrufdatum 17 07 2007 OFHLER Karsten OLAP Grundlagen Modellierung und betriebswirt schaftliche Ligsungen 1 Mnchen Wien Verlag Hanser 2000 OESTEREICH Bernd Analyse und Design mit UML 2 Objektorientierte Softwareentwicklung 7 Mnchen Oldenbourg 2005 OMONDO EclipseUML http www eclipsedownload com Abrufda tum 17 07 2007 OOSE INNOVATIVE INFORMATIK UML Tools http www oose de umltools htm Abrufdatum 05 03 2008 OPENQA
65. den allgemeinen Diensten Die Anwendungsobjekte die in Form von Client und Server Objekten die Anwendungsfunktionalit t implementieren greifen ber Schnittstellen auf die Dienste des ORB zu Der ORB erm glicht die trans parente Kommunikation zwischen Client und Server Objekten ber ein Netzwerk Daf r nutzt der ORB die speziellen Objektdienste zur Verwaltung der Objekte im Netzwerk Zus tzlich stellt der ORB den Anwendungsobjekten weitere allgemeine Dienste zur Verf gung Zu diesen geh ren Hilfsdienste die zum Beispiel Drucken Datenbankzugriffe und das Verschicken von Emails unterst tzen Die Kommunikation zwischen Anwendungsobjekten realisiert der ORB in Form von entfernten Methodenaufrufen Wie in Abbildung 5 7 dargestellt wird dem Client Objekt daf r ber eine entsprechende Schnittstelle ein Objektstumpf zur Verf gung gestellt der als Stellvertreter das entfernte aufzurufende Objekt repr sentiert Der Stumpf besitzt dieselbe Schnittstelle wie das durch ihn repr sentierte Objekt Wird eine Methode des Stumpfes aufgerufen so leitet diese den Aufruf an den ORB wei ter Der ORB ruft ber ein Skelett die entsprechende Methode des Server Objektes auf Das Skelett bernimmt serverseitig die gleiche Funktion wie der Stumpf auf der Client Seite Es dient dazu dem Server Objekt einen lokalen Aufruf vorzut uschen und macht so den entfernten Aufruf transparent Das Ergebnis des Aufrufs wird ber 48 KAPITEL 5 SOFTWAREARCHITEKTUREN
66. det Diese werden bei oAW in einer weiteren Dom nen spezifischen Sprache n mlich Xtend definiert Fiir die Funktion getMultiplicityAnnotation sieht eine solche Xtend Definition beispielsweise wie folgt aus String getMultiplicityAnnotation uml Property p isMultiple getOpposite p Many One To isMultiple p Many One Buch lt lt Entity gt gt Exemplar lt lt Entity gt gt autor String inventarnr int titel String isbn String Abbildung 10 1 Klassendiagramm mit Stereotypen package Data Entity public class Exemplar implements java io Serializable protected int inventarnr protected Data Buch buch public int getInventarnr return inventarnr public void setInventarnr int p_inventarnr inventarnr p_inventarnr ManyToOne JoinColumn name buch public Data Buch getBuch return buch public void setbuch Data Buch p_buch buch p_buch Abbildung 10 2 Generierter EJB Code f r die Klasse Exemplar im Buch Beispiel Durch die Modell getriebene Softwareentwicklung SV 06 l sst sich die Produkti vit t bei der Softwareentwicklung besonders dann steigern wenn viele sehr hnliche Versionen oder Varianten eines Softwaresystems f r jeweils die gleichen Plattformen erstellt werden m ssen Dann lassen sich die Transformationen wiederholt nutzen Bei Einzelentwicklungen bringt dieser Ansatz wenig Vorteile In einem Pilotprojekt an der
67. diskutierten Prinzipien und Vorgehensweisen auch innerhalb traditio neller Vorgehensmodelle sinnvoll einsetzen Extreme Programming ist nur f r kleinere und mittlere Projekte mit maximal 15 Entwicklern geeignet Gr ere Projekte erfordern mehr organisatorischen Aufwand 16 KAPITEL 2 VORGEHENSMODELLE Kapitel 3 Management Aspekte 3 1 Aufwandssch tzung Die Sch tzung des Aufwands eines Projekts ist aufgrund der bei Projektanfang unzureichenden Informationen einerseits schwierig andererseits aber f r Planunng von Laufzeit Kosten und Personaleinsatz unabdingbar Vollst ndig berzeugende L sungen f r dieses Problem gibt es nicht In vielen F llen hilft ein simpler Ver gleich des neuen Projekts mit einem oder mehreren hnlich gelagerten abgeschlosse nen Projekten Diesen Ansatz bezeichnet man auch als Analogiemethode Besonders pr zise Sch tzungen kann sie aber in der Regel nicht liefern In empirischen Vergleichen verschiedener Sch tzmethoden hat die so genannte Function Point Analyse FPA PB05 oder Function Point Methode am besten ab geschnitten Bal01 Sie hat daher in Deutschland und auch weltweit eine beachtliche Benutzergemeinde die IFPUG IFP08 Sie ist recht leicht und mit berschaubarem Aufwand durchf hrbar und f hrt zu relativ pr zisen Ergebnissen Selbst wenn man in der eigenen Firma kein eigenes Know How bez glich der Function Point Analyse aufbauen will so kann man ggf auf einen hierf r von der IFP
68. dung 4 8 zeigt ein Sequenzdiagramm das den Ablauf der Auswertung ei nes arithmetischen Ausdrucks genauer einer Summe von zwei Teilausdr cken spe zifiziert Hierbei wird angenommen dass ein arithmetischer Ausdruck durch das in Abbildung 4 6 dargestellte System von Klassen repr sentiert wird Zur Auswer tung des geschachtelten Ausdrucks der Summe werden zun chst die beiden Teilaus dr cke ausgewertet Die Zwischenergebnisse werden als Parameter an die Methode 36 KAPITEL 4 OBJEKTORIENTIERUNG UND UML ausfuehren des Additionsobjekts tibergeben auf das das Objekt verweist das den geschachtelten Ausdruck reprasentiert Das hierbei berechnete Ergebnis ist der ge suchte Summenwert Ab UML 2 0 ist auch m glich Kontrollstrukturen wie Verzweigungen und Schlei fen in Sequenzdiagrammen darzustellen Hierzu wird ein Sequenzdiagramm vertikal in Bereiche unterteilt die alternativ optional wiederholt oder parallel ausgef hrt werden Details hierzu findet man in Oes05 Sti05 Sequenzdiagramme sind eine Variante von Interaktionsdiagrammen weitere Va rianten sind Kommunikationsdiagramme und Zeitverlaufsdiagramme auf die hier nicht im Detail eingegangen wird Kommunikationsdiagramme sind semantisch qui valent zu Sequenzdiagrammen sie unterscheiden sich lediglich in der Art der Visua lisierung Von blichen UML Modellierungswerkzeugen k nnen Sequenzdiagramme auf Knopfdruck in quivalente Komunikationsdiagramme transformiert werden und u
69. dung f r eine Integrationsebene muss demnach ein Kompromiss zwischen den Anforderungen an die Integration und den technischen M glichkeiten f r deren Realisierung gefunden werden 9 4 1 Integration auf Datenebene Bei der Datenintegration erfolgt die Integration durch unmittelbaren Zugriff auf die Daten die von den jeweiligen Anwendungen erzeugt verwaltet und gespeichert werden vgl Abbildung 9 4 Ein wesentlicher Vorteil dieser Methode liegt darin dass keine Modifikationen der Datenstrukturen oder der Anwendungslogik der zu integrierenden Anwendun 9 4 INTEGRATIONSEBENEN 95 Integrierte Prasentation Integrationslogik Integrations plattform Anwendung A Anwendung B Datenspeicher A Datenspeicher B Abbildung 9 4 Integration auf Datenebene gen erforderlich ist Dies erm glicht vielmals eine schnelle L sung von Integrati onsproblemen und erlaubt eine Integration auch dann wenn eine Anpassung der Systeme nicht m glich ist da der Quellcode nicht verf gbar gemacht werden kann F r die berwindung der technischen Heterogenit t zwischen verschiedenen Daten bankmanagementsystemen und syntaktischer Heterogenit ten als Folge von unter schiedlichen Konzepten der Datenmodellierung z B Entity Relationship Modellie rung Objektorientierte Modellierung bietet sich eine Vielzahl von Werkzeugen an Dennoch ist eine Datenintegration keine triviale Angelegenheit Ursa
70. e vergleicht werden die kostenlos erh ltliche Open Source L sung Subversion C0107 und das von IBM kommerziell vertriebene ClearCase BM07a am besten bewertet werden 86 KAPITEL 8 TOOLS 8 2 CASE Tools 8 2 1 Funktionsweise Computer Aided Software Engineering CASE bezeichnet den Einsatz von Softwa retools zur Unterst tzung der Entwicklung und Wartung von Software Die Werk zeuge die hierf r zum Einsatz kommen werden als CASE Tools bezeichnet Die Un terst tzung durch ein CASE Tool kann sich auf verschiedenste Aspekte des Softwa reentwicklungsprozesses beziehen Ziel des Einsatzes von CASE Werkzeugen ist die qualitative und quantitative Verbesserung der Softwareentwicklung Zu den CASE Werkzeugen z hlen daher nicht nur die unabdingbaren Hilfsmittel wie Compiler Editor Linker und Debugger Der Einsatzbereich f r CASE Tools umfasst s mtliche Phasen des Entwicklungs prozesses wie Planung Definition Entwurf Implementierung sowie Einf hrung und Wartung Wie in Abbildung 8 2 dargestellt lassen sich CASE Werkzeuge in Abh ngigkeit von ihren Schwerpunkten zu Kategorien zusammenfassen Diejenigen Werkzeuge die die ersten Phasen der Softwareentwicklung Planung Definition und Entwurf unterst tzen werden auch als Front End oder Upper CASE Werkzeuge bezeichnet Zu den Back End oder Lower CASE Werkzeugen geh ren alle Werkzeu ge die sich den sp teren Phasen der Softwareentwicklung Implementierung Ent wurf Einf hr
71. e Methode insertFirst In der Testklasse ListTest wird beispielhaft eine Methode testList gezeigt in der eine Liste mit den Elementen 42 17 und 39 erzeugt wird f r die anschlie end mit assertEquals berpr ft wird ob diese Elemente auch ordnungsgem eingetragen wurden import junit framework public class ListTest extends TestCase public static Test suite return new TestSuite ListTest class public static void main String args junit textui TestRunner run suite protected void setUp protected void tearDown SU KAPITEL 7 TESTEN public void testList MyList lt Integer gt list new MyList lt Integer gt int testvalues 42 17 39 for int i testvalues list insertFirst i int i testvalues length 1 for Integer val list assertEquals val 0 testvaluesli Varianten von JUnit gibt es auch f r das Testen von Webapplikationen HttpUnit Fej08 erlaubt beispielsweise das Testen von Webapplikationen ber die aus HTML Seiten bestehende Benutzeroberfl che hnliche Tools hierf r sind Cactus Pro08 Selenium ope08 und Wat Wat08 Neben den erw hnten Frameworks gibt es zum automatisierten Abspielen von Testf llen auch kommerzielle Tools wie den IBM Rational TestManager und ande re Rational Tools Rat08b Rat08a und HP Functional Testing sowie weitere HP Tools HP08a HPO8b Solche Tools erlauben auch das Testen von konventionellen d h nicht HTML basierten graphischen
72. e Version erstellt hat gespeichert Dies erm glicht es die Entwicklung einzelner Teile des Pro jektes durch Versionsvergleiche vollst ndig nachzuvollziehen und nderungen unter Umst nden gezielt r ckg ngig zu machen Neben der historischen Versionsfortschreibung dient die Versionsverwaltung aber auch als zentrale und gemeinsame Datenbasis f r ein Softwareprojekt Der Einsatz einer Versionsverwaltung ist daher vor allem bei gr eren Projekten an denen meh rere Entwickler gleichzeitig arbeiten sinnvoll Zu den Hauptaufgaben eines Versionsverwaltungssystems z hlen e Protokollierung von nderungen Es kann jederzeit nachvollzogen wer den wer wann was ge ndert hat e Wiederherstellung Verschentliche oder f lschliche nderungen k nnen je derzeit r ckg ngig gemacht werden e Archivierung Die verschiedenen Releases eines Systems k nnen archiviert werden So kann auf diese Releases jederzeit zur ckgegriffen werden 83 84 KAPITEL 8 TOOLS e Koordinierung Es wird der gleichzeitige Zugriff von mehreren Anwendern auf die Dateien des Projektes erm glicht e Verwaltung mehrerer Entwicklungszweige Es ist m glich gleichzeitig mehrere Entwicklungszweige Branches eines Projektes zu verwalten Dabei kann bestimmt werden auf welche Zweige eine Anderung Auswirkungen hat 8 1 2 Funktionsweise Ein klassisches Versionsverwaltungssystem besteht in der Regel aus einem Server der die gemeinsame Datenbasis das Repositor
73. e daf r dass die unverzichtba re IT rund l uft F r diese Unternehmen ist es wichtig stets ber den aktuellen Stand der Softwareentwicklung informiert zu sein und fortschrittliche Methoden an zuwenden Nur dann sind Leistungs und Wettbewerbsf higkeit auf Dauer m glich Das gilt vor allem auch zunehmend in globalisierten M rkten Heimische Anbieter konkurrieren oft mehr und mehr mit g nstigen Software Produzenten etwa in Indien oder Osteuropa Die vorliegende Brosch re Best Practices in der Softwareentwicklung soll ins besondere kleinen und mittelgro en Betrieben eine Arbeitshilfe zur rationellen Soft wareentwicklung geben Sie soll in berschaubarer Form Methoden vorstellen die die Entwicklung effizienter gestalten k nnen Der vorliegende Leitfaden ist durch den F rderkreis f r Angewandte Informa tik an der Westf lischen Universit t M nster angeregt und finanziert worden Der F rderkreis wird von rund 30 Unternehmen aus der Region und der Industrie und Handelskammer Nord Westfalen getragen Hauptziel ist die F rderung der praxis orientierten Forschung und Lehre sowie der schnelle Wissenstransfer Besonderer Dank geb hrt dem Direktor des Instituts f r Angewandte Informatik Herrn Professor Dr Herbert Kuchen und seinen Mitarbeitern f r die au erordentlich engagierte und praxisnahe Umsetzung des Projektes Ein weiteres gro es Dankesch n geht an die Mitglieder einer projektbegleiten den Arbeitsgruppe aus
74. e der allgemeinen Klassendefinition repr sentieren Die in gleicher Weise spe zialisierten Objekte bilden dann eine Unterklasse der Ausgangsklasse Letztere wird dann auch als Oberklasse bezeichnet Diese Objekte einer Unterklasse erben alle nicht privaten Attribute und Operationen der Oberklasse Zus tzlich k nnen wei tere Attribute und Operationen erg nzt werden Eine Oberklasse kann hierbei so 28 KAPITEL 4 OBJEKTORIENTIERUNG UND UML allgemein gehalten sein dass es nicht immer sinnvoll ist hierfiir konkrete Objekte zu bilden Dies ist genau dann der Fall wenn eine Klasse nur gemeinsame Attri bute und Methoden fiir alle Unterklassen bereitstellen soll Solche Klassen werden als abstrakte Klassen bezeichnet Es k nnen keine Objekte von abstrakten Klassen erzeugt werden 4 2 Unified Modeling Language Bei der objektorientierten Softwareentwicklung wird das zu erstellende System vor der Implementierung typischerweise in der allgemein akzeptierten standardisierten Notation Unified Modeling Language UML modelliert Oes05 Sti05 Die UML stellt hierf r insgesamt sechs Strukturdiagramme zur Beschreibung statischer Struk turen wie z B der Beziehungen zwischen Objekten Klassen und Paketen und sie ben Verhaltensdiagramme zum Modellierung des dynamischen Verhaltens eines Sy tems zur Verf gung Die wichtigsten dieser Diagramme werden im Folgenden kurz vorgestellt n mlich das Strukturdiagramm Klassendiagramm sowie die Verhaltens di
75. e nachvollziehbar Aus diesem Grund und aufgrund der besonderen Betonung des Anforderungsmanagements sowie der Qualit tssicherung eignet sich der Ratio 2 3 EXTREME PROGRAMMING 11 nal Unified Process insbesondere f r Projekte die hohen Qualit tsanforderungen gerecht werden m ssen Das umfassende Projektmanagementinstrumentarium er laubt es auch gro e Projekte mit vielen Beteiligten und heterogener Interessenlage koordinieren zu k nnen In kleineren Teams oder kurzfristigeren Projekten f hrt der Einsatz des RUP schnell zu einem Verwaltungs Wasserkopf der das Projekt mit unn tiger B rokratie belastet Ein weiterer Kritikpunkt ist die fehlende Flexibilit t kurzfristig auf neue Anforderungen oder ver nderte technologische Rahmenbedin gungen reagieren zu k nnen Um unterschiedlichen Rahmenbedingungen einzelner Projekte gerecht werden zu k nnen ist der Rational Unified Process in hohem Ma e anpassbar Entsprechend der jeweiligen Anforderungen an das Projektmanagement k nnen einzelne Teile des RUP auf eigene Erfordernisse zugeschnitten oder anstatt des gesamten Prozesses nur eine sinnvolle Teilmenge der Handlungsempfehlungen eingesetzt werden 2 3 Extreme Programming Extreme Programming XP BA04 ist ein von Kent Beck Ward Cunningham und Ron Jeffries entwickelte Methodologie f r die Entwicklung von Software Extreme Programming ist der bedeutsamste Vertreter der so genannten agilen Vorgehensmo delle Diese entstanden aus de
76. e z B B ume Die Klassen Ausdruck Konstante und Geschachtelt in Abb 4 6 sind eine Auspr gung des Kompositum Musters zur Darstellung arithmetischer Aus dr cke z B im Rahmen eines Compilers Stellvertreter verschiebt die Kontrolle ber ein Objekt auf ein vorgelagertes Stell vertreter Objekt mit gleicher Schnittstelle Der Stellvertreter kann beispiels weise die Funktionalit t eines entfernten Objekts lokal zur Verf gung stellen oder ein Speicherplatz intensives Objekt solange im Hauptspeicher vertreten bis es wirklich gebraucht wird und es dann nachladen 72 KAPITEL 6 ENTWURFSMUSTER 6 3 Verhaltensmuster Verhaltensmuster befassen sich mit Algorithmen und der Zuweisung von Zust ndig keiten zu Objekten und beschreiben nicht nur Muster von Objekten oder Klassen sondern auch Muster der Interaktion zwischen ihnen d h komplexe Kontrollfl sse Einige dieser Muster beschreiben wie eine Gruppe von Objekten zusammenarbeitet um eine Aufgabe zu erf llen die keines der Objekte alleine ausf hren kann 6 3 1 Befehl Das Befehlsmuster ist ein objektbasiertes Verhaltensmuster Hierbei wird ein Befehl eine Operation als ein Objekt gekapselt Durch Anbindung eines Befehlsobjekts per Delegation wird einem Klienten Objekt die Operation als Dienstleistung zur Verf gung gestellt Durch Anbindung eins anderen Befehlsobjekts kann zur Laufzeit die Funktionalit t des Klientenobjekts indirekt ge ndert werden Die Kapselung ei ner Operation
77. echtecks auf einen negativen Wert zu setzen eine Exception ausl sen und auf diese Weise das Errei chen eines inkonsistenten Objektzustands unterbinden Dieses Verhalten kann nicht sichergestellt werden wenn das breite Attribut als public deklariert ist da so die ggf zur Verf gung gestellte Set Methode umgangen werden kann Oft muss nicht auf jedes der vorhandenen Attribute lesend oder schreibend zugegriffen werden Insofern liegt der Gedanke nahe nur diejenigen Get und Set Operationen zu implementie ren die auch tats chlich ben tigt werden Dennoch ist es sinnvoll f r jedes Attri but einer Klasse eine Set und Get Operation zu implementieren damit die Klasse besser getestet werden kann Da Get und Set Operationen sowie der Konstruktor einer Klasse blicherweise vorhanden sind werden sie in der Regel nicht explizit im Operationen Block einer Klasse im Klassendiagramm aufgelistet 30 KAPITEL 4 OBJEKTORIENTIERUNG UND UML Darstellung von Vererbung im Klassendiagramm Im Klassendiagramm werden Vererbungshierarchien durch eine Verbindungslinie zwischen der Ober und der Unterklasse dargestellt die auf der Seite der Ober klasse durch ein Dreieck gekennzeichnet wird Der Name einer abstrakten Klasse wird kursiv geschrieben public abstract class Figur protected Punkt position public Figur Punkt position this position position public Punkt getPosition return position public void verschiebe doub Figur dou
78. egel auf die Dienste der Komponentenplattform zur ckgegriffen Die f r die Kommunikation verwendeten Netzwerke und Protokolle sind dabei f r die Softwarekomponenten transparent was dazu f hrt dass die Entwicklung der Komponenten erheblich vereinfacht wird Durch den vorgeschriebenen Aufbau und die vereinheitlichte Interaktion wird ei ne Entkopplung der einzelnen Komponenten erreicht Ziel dieser Entkopplung ist es die bereits erw hnte Wiederverwendbarkeit und Austauschbarkeit der Komponen ten zu verbessern Im Folgenden werden drei weit verbreitete Komponentenmodelle CORBA Java EE und NET n her erl utert 5 2 2 CORBA Die Common Object Request Broker Architecture CORBA Obj07 ist ein von der Object Management Group entwickelter Standard der plattform und programmier sprachen bergreifende Protokolle und Dienste f r die Umsetzung objektorientierter und verteilter Anwendungen definiert Ziel dieser Architektur ist es die Interaktion von objektorientierten Systemen verschiedener Programmiersprachen und Plattfor men zu erm glichen Um die Interoperabilit t verschiedener CORBA Implementierungen zu gew hr leisten basiert die gesamte Architektur ausschlie lich auf offenen Standards und Schnittstellen Der Aufbau eines CORBA Systems wird in Abbildung 5 6 schema tisch dargestellt und setzt sich aus vier zentralen Bestandteilen zusammen Den Anwendungsobjekten dem Object Request Broker ORB den speziellen Objekt diensten und
79. eibung des Auf baus einer Softwarekomponente sowie der Laufzeitumgebung f r diese Komponente der Komponentenplattform Die Spezifikation der Komponentenplattform umfasst s mtliche Dienste und Funktionalit ten die einer Komponente zur Verf gung ge stellt werden und legt somit auch die Interaktions und Kompositionsm glichkeiten von Komponenten fest Eine Softwarekomponente ist ein Softwarebaustein der ber Schnittstellen Ope rationen Eigenschaften und Ereignisse zur Verf gung stellt Zudem ist sie eine un abh ngige Auslieferungseinheit die zur Ausf hrung eine bestimmte Laufzeitumge bung die Komponentenplattform ben tigt Dar ber hinaus besitzt sie Metadaten zur Selbstbeschreibung ber die sie ihre Schnittstellen und Kontextabh ngigkeiten d h ihre Abh ngigkeit von anderen Komponenten und Bibliotheken offen legt Ei ne Komponente sollte zudem in hinreichendem Ma e anpassungsf hig sein um ihre Wiederverwendbarkeit sowie ihre Kompositionsf higkeit zu gew hrleisten Eine Komponentenplattform bietet den Komponenten eine Infrastruktur f r h ufig ben tigte Mechanismen wie Verteilung Nachrichtenaustausch Persistenz Si cherheit und Versionierung Durch die Inanspruchnahme der Dienste der Komponen tenplattform m ssen diese Funktionen nicht f r jede Komponente einzeln implemen tiert werden Beispielsweise wird f r die Kommunikation zwischen den Softwarekom 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 47 ponenten in der R
80. eit mit dem Kunden nicht immer m glich oder auf wirtschaftliche Weise realisierbar Kritisch zu beur teilen sind auch die hier nicht n her behandelten Techniken der Programmierung in Paaren und der gemeinsamen Verantwortlichkeit f r die Quellcodebasis Pro grammieren in Paaren bedeutet dass bei der Erstellung des Quellcodes jeweils zwei Entwickler gemeinsam an einem Rechner arbeiten Einer der beiden Entwickler er stellt den Code w hrend der andere ber aktuelle Problemstellungen nachdenkt und den geschriebenen Code kontrolliert Um einen intensiven Erfahrungsaustausch zu gew hrleisten werden die Rollen regelm ig getauscht und die Programmier teams durch Rotation immer wieder neu zusammengestellt In einem Unterneh men dessen Betriebsklima durch Neid Misstrauen und Angst gepr gt ist oder in einem Team dessen Mitarbeiter sehr unterschiedliche Qualifikationen besitzen wer den diese Praktiken schwerlich auf fruchtbaren Boden fallen Arbeiten die Entwick ler r umlich verteilt so ist der Einsatz spezieller Werkzeuge f r das distributed pair programming erforderlich Diese erm glichen den Entwicklern eine einheitli che und konsistente Sicht auf den zu bearbeitenden Quellcode Die Synchronisation der verteilt stattfindenden Benutzerinteraktionen erfolgt dabei automatisiert ber 2 3 EXTREME PROGRAMMING 15 eine Datenverbindung Jede nderung wird somit unmittelbar f r jeden Teilnehmer der Pair Programming Sitzung sichtbar En
81. en Server Stub realisiert Letzterer reicht den Aufruf serverseitig als loka len Aufruf an die adressierte Methode weiter und veranlasst die bermittlung der R ckgabewerte an den entfernten Client Durch diesen Mechanismus ist die Benut zung eines Kommunikationskanals zum Aufruf einer entfernten Servermethode f r den Entwickler der Client Anwendung transparent Problematisch an RPC basierten Integrationsans tzen ist die enge Kopplung an implementierungsspezifische Details der zu integrierenden Anwendung Wird Letztere erweitert oder abge ndert so zieht dies im Regelfall Anpassungsentwicklungen am Quellcode der integrierenden An wendung nach sich Da die Kommunikation ber RPC und RMI Anfragen synchron abl uft ist die aufrufende Anwendung so lange blockiert blockierendes Warten bis vom Empf nger eine Antwort eintrifft Um eine reibungslose Kommunikation sicherzustellen muss daf r Sorge getragen werden dass zwischen den kommunizie renden Anwendungen stets eine stabile Netzwerkverbindung besteht und der Ser ver permanent verf gbar ist Alternativ besteht die M glichkeit einen asynchronen 9 4 INTEGRATIONSEBENEN 99 Kommunikationsmechanismus mittels synchroner Kommunikation und einem Puf fer nachzubilden Wenngleich die Problematik des blockierenden Wartens auf diese Weise vermieden werden kann so ist dies doch mit zus tzlichem Aufwand verbun den Komponentenorientierte Middleware Einen st rker objektorientierten Integration
82. en Vereinfachungen ver zichtet EJB 3 0 auf einen Gro teil der Komponentenschnittstellen und setzt auf das Paradigma der Configuration by exception welches besagt dass nur diejenigen Einstellungen konfiguriert werden m ssen die nicht den Standar deinstellungen entsprechen e Annotationen Durch den Einsatz von Annotationen k nnen die Komponen ten mit Querschnittsfunktionen wie z B dem Logging annotiert werden Sol che Funktionen m ssen dann nicht f r jede Komponente einzeln implementiert werden Mithilfe von Annotationen werden auch das POJO Programmiermodell und die Komplexit tsreduktion z B durch Einsparung des Deployment Des criptors realisiert 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 53 Web Frameworks Ein Web Framework dient dazu die Entwicklung von Web Anwendungen zu un terst tzen indem es generische L sungen f r h ufig auftretende Probleme bei der Web Entwicklung bereit stellt Ublich sind u a L sungen f r Datenbankzugriff Si cherheit Sitzungsverwaltung Seitennavigation Validierung von Benutzereingaben Internationalisierung und Templatesysteme zum einfachen Designen von Webseiten Im Folgenden werden einige bekannte Web Frameworks f r Java EE vorgestellt Struts Das Struts Framework Apa07a Hol06 erweitert die Java Servlet API und setzt f r die Gestaltung von Webseiten das Model View Controller Entwurfmuster MVC GHJV96 um MVC ist ein gebr uchliches Entwurfsmuster zur Programmierung von
83. en wollen Das Problem ist nun dass die Klasse TextAnzeige nicht f r GrafischesObjekt Klassen entworfen wurde und die Schnittstellen daher nicht bereinstimmen Eine m gliche L sung dieses Problems ist die TextAnzeige Klasse an die durch GrafischesObjekt definierte Schnittstelle anzupassen Dies ist jedoch nicht sinnvoll da dann auch alle Klienten der Klasse angepasst werden m ssten Besser ist es die neue Adapterklas se Text so dazwischen zu schalten dass sie die Schnittstelle von TextAnzeige an 70 KAPITEL 6 ENTWURFSMUSTER die Schnittstelle von GrafischesObjekt anpasst Hierbei gibt es zwei M glichkeiten 1 Text erbt sowohl von GrafischesObjekt als auch von TextAnzeige oder 2 Text erbt nur von GrafischesObjekt und ein TextAnzeige Objekt wird per Delegation an ein Text Objekt angebunden wobei die Klasse Text die Methode GibAusmasse der Klasse TextAnzeige nutzt um die geforderte Methode BegrenzungsRahmen zu implementieren Diese beiden Ans tze entsprechen der klassen bzw objektbasier ten Version des Adaptermusters In Abbildung 6 2 wird der Objektadapter Ansatz verwendet Man beachte dass die Adapterklasse Funktionalit t die von der zu ad aptierenden Klasse nicht geboten von der zu implementierenden Schnittstelle aber erwartet wird selbst implementiert im Beispiel ist dies die Methode ErzeugeMani pulator AdaptierteKlasse SpezifischeOperation Implementierung Operation SS SpezifischeOpe
84. enaufruf der EJB auszuf hren Durch den Container bereitgestellte Dienste wie z B das Transaktionsmanagement k nnen so automatisiert und f r den Programmierer transparent durchgef hrt werden Das 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 51 Business Interface ist die nach au en propagierte Schnittstelle einer EJB eine Kom ponente kann ber ein Local oder Remote Business Interface verf gen Diese k nnen entsprechend ber einen lokalen bzw entfernten Client angesprochen werden EJB Container JVM o Local Client EJB Komponente Middleware Dienste _ _ Lebenszyklus Management Remote Business Container erzeugte GE Slier X Interface Wrapper Klasse 5 Client pp Transaktionen EJB Klasse Abbildung 5 9 Aufbau einer EJB Komponente Eine ausf hrliche Beschreibung des EJB Komponentenmodells findet sich zum Beispiel bei SBS06 EL07 SGM02 Unterschiede zwischen EJB 2 1 und EJB 3 0 Das EJB Komponentenmodell wurde eingef hrt um die Entwicklung von verteil ten mehrschichtigen und objektorientierten Anwendungen zu vereinfachen Obwohl das EJB Modell diesen Anforderungen in weiten Teilen gerecht wurde haben sich im praktischen Einsatz auch einigen Schw chen gezeigt Vor allem das Aufkommen einfacherer Alternativen zeigte dass das EJB Modell im Hinblick auf die Produkti vit t bei der Anwendungsentwicklung oft nicht die
85. ens genauso viel Beachtung geschenkt werden wie der grunds tzlicheren Entscheidung f r eine Integrationsebene Da die Integrationsinfrastruktur grundlegende Funktionalit ten 108 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION bereitstellt welche die Interaktionsf higkeit zwischen den gegenw rtigen wie auch den zuk nftigen Informationssystemen eines Unternehmens erm glichen soll ist sie sowohl mit den Anforderungen Rahmenbedingungen und Restriktionen der exis tierenden Informationssysteme als auch mit den aus der Unternehmensstrategie abgeleiteten Zielvorgaben f r die zuk nftige Entwicklung der betrieblichen Informa tionsverarbeitung abzustimmen Aspekte wie Nachhaltigkeit Skalierbarkeit Flexibi lit t und Sicherheit spielen hier eine tragende Rolle Eine zu kurzsichtige und alleine an der gegenw rtigen Situation orientierte Planung einer Anwendungsintegration sollte vermieden werden da dies leicht zu einer Integrationsinfrastruktur f hrt die zuk nftigen Anforderungen nicht mehr gewachsen ist oder mit dem Wachstum des Unternehmens nicht schritt h lt und sich somit zum kostspieligen Engpass f r die Fortentwicklung der betrieblichen Informationsverarbeitung entwickelt Eine Integration auf Benutzerschnittstellenebene wird in der Literatur zur EAI CHK06 Lin00 gemeinhin als Notl sung angesehen die erst dann zur Anwendung kommt wenn eine Integration auf Daten oder Funktionsebene nicht m glich ist Die Hauptgr nde f r die Kri
86. entierte Architektur SOA KBS05 realisiert werden Analog zur Definition eines Web Service stellen Dienste im Sinne einer SOA ein durch eine wohldefinierte und ber ein ffentliches Verzeich nis zug ngliche Schnittstellenbeschreibung repr sentiertes sowie wiederverwendba res St ck Software dar das eine abgegrenzte Funktionalit t anbietet und durch einen Klienten integriert werden kann Eine Service Orientierte Architektur stellt ein Netzwerk von lose gekoppelten und miteinander interagierenden Diensten dar Diese Kommunizieren durch den Austausch von Nachrichten und k nnen unter einander auf Daten oder auf ihre Anwendungslogik zugreifen Wenngleich sich das SOA Konzept mithilfe von Web Services realisieren l sst so muss betont werden dass die Verwendung von Web Services nicht zwangsl ufig zu einer SOA f hrt und eine SOA andererseits nicht notwendigerweise mithilfe von Web Services implemen tiert werden muss Aus Sicht eines Gesch ftsprozessverantwortlichen macht weder die Integration eines zu komplexen noch die eines zu simplen Dienstes Sinn W hrend ein kom plexer Dienst sich aufgrund seiner ausgepr gten Semantik nur in wenigen F llen ohne aufw ndige Anpassungen einsetzen l sst kann ein elementarer Dienst zwar leicht wiederverwendet werden liefert dabei jedoch nur einen beschr nkten Nutzen Dienste sind demnach von mittlerer Komplexit t und bilden einen wiederverwend baren Ausschnitt aus einem Gesch ftsprozess oder eine
87. er Unified Modeling Language UML und hierauf aufbauender Werkzeuge erleichtert wird Die UML wird ebenfalls in diesem Kapitel kurz vorgestellt Jeder Softwareentwickler sollte sie heute kennen und beherrschen In Kapitel 5 werden dann einige Entwurfsaspekte von Softwaresystemen behan delt Inbesondere die Vorteile von Schichtenarchitekturen und komponentenbasierten Architekturen bei denen Middleware zur Reduktion des Aufwands und der Ferti gungstiefe eingesetzt wird sollte jeder Softwareentwickler kennen In Kapitel 6 werden so genannte Entwurfsmuster vorgestellt Hierbei handelt es sich um Systeme von Klassen die sich zur L sung gewisser immer wiederkehrender Entwurfsprobleme bew hrt haben und die in vielen F llen die angestrebte Flexibi lit t der L sung gew hrleisten k nnen Diese Muster geh ren zum Handwerkszeug jedes objektorientierten Entwicklers Wer sie nicht kennt kann kaum hochwertige objektorientierte Software entwickeln Kapitel 7 besch ftigt sich dann mit dem Thema Testen Die diesbez glichen Grundlagen werden erl utert Weiterhin wird hier auf Automatiserungsm glichkeiten eingegangen Es ist wegen der Kosten und des Zeitbedarfs heute nur noch in weni gen F llen sinnvoll Testeingaben per Hand bei jedem Test erneut in den Rechner einzutippen Viele Firmen haben was die Automatisierung von Tests angeht noch erhebliches Potenzial Bei der Softwareentwicklung sollte heute zur Steigerung der Produktivit t auf eine
88. er eine individuelle Schnittstelle miteinander gekoppelt Der Vorteil dieses Ansatzes liegt bei kleinen Systemen in seiner schnellen und kosteng nstigen Reali sierbarkeit Sobald jedoch mehrere Systeme miteinander verbunden werden m ssen zeigen sich die Grenzen dieses Integrationsansatzes Um in einer Infrastruktur mit n Systemen ein weiteres System mit allen bestehenden Anwendung zu integrieren m ssen n Schnittstellen geschaffen werden In einer Infrastruktur mit n Systemen m ssen demnach maximal n n 1 2 Schnittstellen gewartet werden Diese Schnitt stellenexplosion f hrt trotz der Vorteile dieses Ansatzes in berschaubaren Inte 9 3 EALARCHITEKTURKONZEPTE 93 grationsszenarien bei einer wachsenden Zahl der zu integrierenden Systeme zu einer unflexiblen und schwierig zu wartenden Schnittstellenlandschaft 9 3 2 Hub and Spokes Integration Bei der Hub and Spokes Integration vgl Abbildung 9 2 stellt eine zentrale Inte grationskomponente alle grundlegenden Infrastrukturdienste fiir die Anwendungsin tegration zur Verf gung Die einzelnen Systeme werden nicht direkt sondern ber den Hub miteinander integriert System System 2 3 System Integrations F System 1 infrastruktur Hub 4 System System 6 5 Abbildung 9 2 Hub and Spokes Integration Um ein neues System in eine Infrastruktur mit n Systemen einzubinden muss nur eine standardisie
89. er nach dem anarchischen Code and Fix Ansatz oder einer Variante des Wasserfall Modells In Literatur und Praxis hat sich eine verwirrende Vielfalt von Prozessmodellen und Entwicklungsme thodologien herausgebildet Dennoch oder gerade deswegen scheitern immer noch zahlreiche Projekte aufgrund von Fehlsteuerungen im Rahmen des Projektmana gements Laut einer Untersuchung der Standish Group wurden 2004 lediglich 29 aller IT Projekte erfolgreich abgeschlossen Als endg ltig gescheitert galten 18 aller Vorhaben Mehr als die H lfte aller Projekte 53 konnten nur nach zum Teil erheblichen Termin oder Budget berschreitungen bzw einer Reduzierung des Funktionsumfangs abgeschlossen werden Neben einer fehlenden Disziplin bei der Durchf hrung von Tests und einer unklaren oder l ckenhaften Erfassung der An forderungen werden nach wie vor Projektmanagementprobleme aufgrund eines feh lenden oder ungeeigneten Vorgehensmodells f r die Misere verantwortlich gemacht Der vollst ndige Verzicht auf ein Vorgehensmodell stellt f r Projekte die eine ge wisse Gr e berschreiten die denkbar schlechteste Alternative dar Trotzdem kann auch die Verwendung eines Vorgehensmodells dessen Eigenschaften das Projekt management in einem konkreten Fall nur unzureichend unterst tzen oder sich so gar kontraproduktiv auswirken zu erheblichen Problemen f hren Die verf gbaren Vorgehensmodelle unterscheiden sich zum Teil erheblich in ihren Voraussetzungen Zusic
90. erarbeitung 0 5 um 35 3 Leistungsanforderungen 0 5 4 Ressourcennutzung 0 5 5 Transaktionsrate 0 5 6 Online Benutzerschnittstelle 0 5 7 Anwenderfreundlichkeit 0 5 8 Onlineverarbeitung 0 5 9 Komplexe Verarbeitung 0 5 10 Wiederverwendbarkeit 0 5 11 Migrations u Installationshilfen 0 5 12 Betriebshilfen 0 5 13 Mehrfachinstallationen 0 5 14 Anderungsfreundlichkeit 0 5 I N 9 Of Of 9 o A Ga OF FY oj FY eA w N N Summe Ea der Einf sse Bewertete Function Points E3 E E2 100 0 65 Q w Tabelle 3 3 Beispiel Ermittlung von Function Points 3 2 Risiko Management Untersuchungen zeigen dass zur berarbeitung von fehlerhafter Software ungef hr 80 der berarbeitungskosten ben tigt werden um lediglich 20 der Fehler zu beseitigen Bei diesen 20 der Probleme handelt es sich um die risikoreichen Pro bleme die im Rahmen des Software Managements identifiziert und beseitigt wer den m ssen bevor sie den Projekterfolg gef hrden und solange die entsprechenden berarbeitungskosten noch relativ gering sind Nach Balzert Bal98 besteht das Risikomanagement aus sechs Schritten s Abb 20 KAPITEL 3 MANAGEMENT ASPEKTE Risiko Bewertung Risiko Identifikation d Risiko Analyse Risiko Prioritaten bildung Risiko Beherrschung Risiko management Planung __ Ri
91. erdurch kann der Themenbereich getrennt betrachtet und verstanden werden sowie die Klasse bersichtlich gehalten werden Iterator erlaubt das schrittweise Durchlaufen einer Kollektion wie z B einer Liste Memento erm glicht den Zustand eines Objektes extern zu sichern und bei Be darf wiederherzustellen Schablonenmethode hnlich wie bei der Fabrikmethode wird in einer Oberklas se eine abstrakte Schablonen Methode vorgesehen die in einer Unterklasse berschrieben wird 76 KAPITEL 6 ENTWURFSMUSTER Strategie erlaubt es Algorithmen in eigenen Klassen zu kapseln und so austausch bar zu halten Vermittler steuert die Kooperation von Objekten Zustand erlaubt das Verhalten eines Objekts von seinem Zustand abh ngig zu machen F r jeden Zustand wird eine eigene Unterklasse der Zustandsklasse mit hierf r spezifischem Verhalten bereitgestellt Durch Anbindung eines Ob jekts an ein Objekt der passenden Unterklasse wird daf r gesorgt dass es zum Zustand passende Dienstleistungen bereitgestellt bekommt und sich dadurch selbst zustandsabh ngig verh lt Zust ndigkeitskette schaltet mehrer Objekte hintereinander Eine eingehende Anfrage wird die entstandene Kette entlang geleitet bis ein Objekt die Anfrage beantworten kann 6 4 Weitere Entwurfsmuster Neben den klassischen Entwurfsmuster der Gang of Four haben inzwischen noch einige andere Muster eine gewisse Bedeutung erlangt Einige hiervon werden im Folgende
92. ereich wird zun chst Kaffee gesucht Ist kein Kaffe vorhanden wird Tee gekocht sofern das m glich ist Geht auch das nicht so wird eine Exception ausgel st die anzeigt dass der Ablauf gescheitert ist Ist Kaf fe vorhanden wird der Ablauf in drei parallele Teilabl ufe unterteilt Im ersten Ast werden Kaffee und Filter in die Kaffemaschine gef llt Parallel hierzu werden Was ser in die Maschine gef llt und Tassen geholt Sobald Kaffee Filter und Wasser in der Kaffeemaschine sind wird diese eingeschaltet Ist keine Tasse mehr vorhanden so wird die hierdurch ausgel ste Ausnahme dadurch behandelt dass eine Tasse ge sp lt wird Wenn die Machine fertig ist und die Tasse bereit ist wird der Kaffee eingesch ttet 38 KAPITEL 4 OBJEKTORIENTIERUNG UND UML 4 2 6 Weitere UML Diagramme Klassendiagramme Anwendungsfalldiagramme Sequenzdiagramme und Aktivitats diagramme sind die am h ufigsten verwendeten UML Diagramme Weitere hier nicht im Detail erlauterte UML Diagramme sind die folgenden Strukturdiagramme Montagediagramme modellieren die Grobstruktur eines Systems Komponentendiagramme zeigen aus welchen Komponenten ein System be steht und welche Scnittstellen diese bieten und nutzen Verteilungsdiagramme stellen die Verteilung von Komponenten auf Rechen knoten dar Objekdiagramme hneln Klassendiagrammen sie beschreiben aber die Ver kniipfungen einzelner Objekte statt ganzer Klassen Paketdiagramme beschreibe
93. erungen vom betrachteten System eingehalten werden Als Beispiel seien hier der HP LoadRunner HPO8b und IBM Rational Performance Tester Rat08a erw hnt Das automatische Generieren von Testf llen kann z B von QuickCheck Sou08 bernommen werden Hier werden per Zufallsgenerator zuf llige Testeingaben er zeugt f r die dann automatisch gepr ft wird ob sie das gew nschte Ergebnis be rechnen Dies funktioniert vielfach erstaunlich gut und ein Gro teil der Fehler wird durch die so erzeugten Testf lle aufgedeckt Vorausgesetzt wird hierbei dass eine spezielle Methode eine so genannte Property vom Tester bereitgestellt wird die pr ft ob ein berechnetes Ergebnis stimmt Das Erstellen solcher Properties kann manchmal aufw ndig werden Auch werden manchmal spezielle Generatoren f r sinnvolle Eingaben ben tigt Dies ist insbesondere dann der Fall wenn ein Gro teil der aufgrund der Datentypen der Eingabeparameter m glichen Eingaben unzul ssig ist und das Verhalten des Systems f r diese illegalen Eingaben nicht interessiert Schlie lich gibt es Werkzeuge die feststellen welcher Anteil des betrachteten Codes durch die bisher untersuchten Testf lle berdeckt wird So l sst sich Fest stellen ob Teile des Codes noch nicht getestet wurden und daher weitere Testf lle erforderlich sind 8 2 4 Werkzeuge zur Architektur berwachung Weiterhin gibt es kommerzielle Werkzeuge wie z B Sotograph Tom08 die ins besondere bei lange e
94. es Clients besteht eine COM Komponente somit aus einem Zeiger auf einen Zeiger der auf eine vTable zeigt Client Interface Variable Knoten vTable 0p gt gt gt Op 2 Op 3 COM Komponente Quelle Szyperski SGM02 S 331ff Abbildung 5 12 Aufbau einer COM Komponente Mithilfe dieser doppelten Indirektion ist es m glich fiir die Komponente ein objektorientiertes Verhalten zu simulieren Hierfiir wird den Methoden der Kompo nente bzw der vTable beim Aufruf die Referenz auf den Schnittstellenknoten als zus tzlicher Parameter bergeben Mithilfe dieser Referenz k nnen verschiedene In stanzen von Interface Knoten die auf dieselbe vTable zeigen unterschieden werden Die Methoden der vTable k nnen durch diese Referenz die Instanzen der Interface Knoten unterscheiden und objektorientiertes Verhalten simulieren indem sie intern den Interface Knoten Instanzvariablen zuordnen Das wichtigste Interface des COM ist das Unknown Interface dessen Funktionen QuerylInterface AddRef und Release von allen COM Schnittstellen implementiert werden m ssen Die Funktionen AddRef und Release in bzw dekrementieren einen Referenzz hler f r den Interface Knoten Mithilfe des Referenzz hlers k nnen nicht 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 59 mehr referenzierte COM Objekte ermittelt und gel scht werden Da eine COM Komponente auch mehrere Schnittstellen besitzen kann wird
95. essage Driven Beans Driven Beans Datenhaltung Datenbank Server Datenbank Server 3 Schichten 4 Schichten Abbildung 5 8 Architektur einer Java EE Anwendung einem Datenbank Tupel entspricht und dass beide synchron gehalten werden Die Bezeichnung POJO soll verdeutlichen dass es sich dabei um einfache Java Objekte handelt die keine externen Abh ngigkeiten durch Namenskonventionen oder zu im plementierenden Schnittstellen besitzen Fiir die Datenhaltung ist in der Regel ein separater Datenbank Server verantwortlich Die EJB Komponenten ben tigen zur Ausf hrung eine spezielle Laufzeitumge bung den EJB Container der durch den Application Server zur Verf gung gestellt wird Abbildung 5 9 zeigt den Aufbau einer EJB sowie deren Interaktionsm glich keiten mit Diensten des EJB Containers und den Clients die die Dienste der Kom ponente in Anspruch nehmen Nach der EJB Spezifikation 3 0 besteht eine EJB Komponente aus der eigent lichen EJB Klasse einem Business Interface und einer vom Container erzeugten Verpacker Klasse engl Wrapper Business Interface und EJB Klasse sind durch den Programmierer zu implementieren w hrend die Wrapper Klasse automatisch beim so genannten Deployment d h der Bereitstellung der Komponente auf ei nem Application Server durch den Application Server erzeugt wird Die Wrapper Klasse kapselt Zugriffe auf die EJB Klasse und erm glicht es so spezielle Dienste des Containers vor bzw nach einem Method
96. fe ohne komplexe Logiken oder Berechnungen ein 9 4 3 Integration ber die Benutzerschnittstelle Bei einer Integration auf Benutzerschnittstellenebene werden Daten Funktionen und Prozesse einer Anwendung durch Einbindung ihrer Benutzerschnittstelle zugreifbar gemacht vgl Abbildung 9 9 Die Programmlogik oder die Daten der Anwendung bleiben bei dieser Form der Integration unber hrt 106 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION A Portal System EN WSRP Portlets Prasentation Web Services Pr sentation A Pr sentation B Anwendung A Anwendung B Datenspei icher A Datenspeicher B Abbildung 9 9 Integration auf Benutzerschnittstellenebene Eine derartige Integration kann mithilfe so genannter Screen Scraping Systeme oder durch ein webbasiertes Portal gew hrleistet werden Welche Art der Integration in speziellen Situation sinnvoller ist h ngt vor allem davon ab ob die Daten eines Systems fiir eine automatisierte Weiterverarbeitung in einem Fremdsystem verfiigbar gemacht oder Benutzern in integrierter Form pr sentiert werden sollen Ein Screen Scraping System erm glicht es die Bildschirmmasken einer Anwendung zeilenweise auszuwerten und einen Benutzerdialog zu simulieren Die Ausgaben der Anwendung an den Benutzer k nnen auf diese Weise automatisch erfasst und einem Fremdsystem zugef hrt werden Screen Scraping gilt gemeinhin als Notl sung welche mit enormen Performanzeinbu en erka
97. fen oft den Speicherplatzverbrauch die Laufzeit und Sprach und Implementierungsaspekte Da in objektorientierten Syste men oft der Wiederverwendbarkeit eine zentrale Rolle zugeschrieben wird umfasst der Konsequenzenabschnitt eines Musters auch seinen Einfluss auf die Flexibilit t 65 66 KAPITEL 6 ENTWURFSMUSTER Erweiterbarkeit und Portabilit t des Systems In vielen Situationen k nnen mehrere Muster verwendet werden um ein Problem zu l sen Welches dann ausgew hlt wird h ngt davon ab welche mit jedem Muster verbundenen Vor und Nachteile in der jeweiligen Situation am wichtigsten sind Au erdem werden Muster oft kombiniert Entwurfmuster k nnen in drei Kategorien unterteilt werden Erzeugungsmuster Strukturmuster und Verhaltensmuster Erzeugungsmuster betreffen die Erzeugung von Objekten Die Unterscheidung der anderen beiden Kategorien ist nicht sehr trennscharf und ihre Beschreibungen sind recht generisch Strukturmuster befassen sich mit der Zusammensetzung von Klassen und Objekten w hrend ein Verhaltens muster ein interessantes Verhalten realisiert Entwurfsmuster basieren auf den bei den Mechanismen Vererbung und Delegation d h Weitergabe einer Anfrage an ein per Assoziation angebundenes Nachbarobjekt Abh ngig davon ob Vererbung oder Delegation bei dem jeweils betrachteten Muster von gr erer Bedeutung ist spricht man auch von einem Klassen bzw Objekt basierten Muster Bei Mustern die auf Flexibilit t abzielen
98. fernten Methodenaufruf durchf hren zu k nnen Eine ausf hrlichere Be schreibung von CORBA findet sich u a in LP98 SGMO2 Obwohl CORBA das in der Version 1 0 bereits 1991 ver ffentlicht wurde das lteste hier vorgestellte Komponenten Framework ist bleibt seine Verbreitung heu te deutlich hinter der von Java EE oder NET zur ck Gr nde hierf r sind u a die hohe Komplexit t sowie inkompatible oft unvollst ndige Hersteller spezifische Implementierungen 5 2 3 Java EE Grundlagen Die Java Platform Enterprise Edition Java EE Sun07a ist eine Menge von Spe zifikationen und Benutzerschnittstellen die auf der Java Platform Standard Edition Java SE aufbauen W hrend die Java SE f r die Entwicklung allein stehender Ein zelanwendungen geeignet ist stellt die Java EE Dienste und Schnittstellen f r die Entwicklung serverbasierter Applikationen bereit und ist besonders f r die Umset zung verteilter mehrschichtiger und komponentenbasierter Anwendungsarchitektu ren geeignet Der Java EE liegt das Komponentenmodell der Enterprise JavaBeans EJB zu grunde Das EJB Modell fokussiert Systeme bei denen die folgenden Eigenschaften von besonderer Bedeutung sind Skalierbarkeit Verf gbarkeit Sicherheit Transak tionen und Ortstranzparenz Der schematische Aufbau einer generischen Java EE Anwendung ist in Abbil dung 5 8 dargestellt Die Architektur einer klassischen Java EE Anwendung besteht aus drei oder vier Schichten je na
99. flexibel zusammenzusetzen Zur Erstel lung von Gesch ftsprozessen bietet WS BPEL die M glichkeit bereits existieren de Web Services zu adressieren und aufzurufen Dar ber hinaus k nnen Kontroll strukturen wie Verzweigungen und Schleifen implementiert werden Jeder mithilfe von WS BPEL erstellte Prozess stellt wiederum einen Web Service dar der durch ein WSDL Dokument beschrieben wird und ver ffentlicht werden kann Um einen WS BPEL Prozess ausf hren zu k nnen wird eine BPEL Engine als Laufzeitum gebung ben tigt welche auch einen transparenten Zugriff auf die eingebundenen Web Services erm glicht Zudem stellt sie Funktionen f r das Deployment und die Verwaltung der WS BPEL Prozesse sowie Persistenzdienste zur Verf gung Die Be schreibung der WS BPEL Prozesse erfolgt mittels XML wobei die einzelnen Spra chelemente wie Variablendeklarationen Zuweisungen oder Kontrollstrukturen durch entsprechende Tags dargestellt werden Verglichen mit anderen Programmierspra chen wie zum Beispiel Java wird der Quellcode eines WS BPEL Prozesses daher schnell un bersichtlich Durch die zunehmende Verf gbarkeit grafischer Entwick lungswerkzeuge relativiert sich dieser Nachteil jedoch zusehends Schwerer wiegt dass dem Entwickler nur wenige Konstrukte zur Verf gung stehen die eine ange messene Strukturierung von Prozessen erm glichen Dieser Umstand schr nkt die Einsatzm glichkeiten von WS BPEL auf die Beschreibung relativ berschaubarer Abl u
100. forderun gen an die Integrationsinfrastruktur und die Anbindung neuer Systeme im Zeitver lauf relativ unver ndert so kann dieser Nachteil hingenommen werden In einem dynamischen Umfeld mit rasch wechselnden Integrationsanforderungen erweist sich eine derartige L sung schnell als kostspielig und unflexibel In diesem Fall ist ei ne Integrationsinfrastruktur w nschenswert die es erm glicht Funktionalit ten zur Laufzeit dynamisch einzubinden Das hei t jegliche Referenzen oder Adressierungs informationen die zum Auffinden einer Funktionalit t erforderlich sind d rfen nicht 9 4 INTEGRATIONSEBENEN 101 zur Ubersetzungszeit sondern erst zur Laufzeit angelegt werden Ein weiterer gravierender Nachteil komponentenorientierter Middleware ist die unzureichende Kompatibilitat der Systeme untereinander Die Entscheidung fiir eine bestimmte Middleware Plattform bedingt dass alle in die Integrationsl sung einge bundenen Systeme den gleichen RPC Mechanismus das gleiche Objektmodell oder ein einheitliches Nachrichtenformat unterstiitzen miissen Da einige der am Markt verf gbaren Middleware Plattform dar ber hinaus keine vollst ndige Plattform und Programmiersprachenunabh ngigkeit bieten ist die Flexibilit t bei der Aus wahl von Betriebssystemen und Programmiersprachen stark eingeschr nkt So bie tet DCOM die gr ten Einsatzpotentiale in einer Windows Umgebung wenngleich Implementierungen f r weitere Betriebssysteme verf gbar sin
101. g und der Kosten f r die Fehlerbehebung Wenn sich eine Entwurfs oder Implementierungsent scheidung als ungeeignet herausstellt so ist hier im Gegensatz zum Wasserfallmodell nicht das Gesamtsystem sondern typischerweise die letzte Iteration betroffen die dann vergleichsweise kosteng nstig korrigiert werden kann Die drei zentralen Prin zipien des Unified Process sind auch losgel st hiervon interessant und k nnen auch in eigenen auf das jeweilige Projekt zugeschnittenen Vorgehensmodellen verwendet umgesetzt werden Die Unified Process basiert auch auf den folgenden Konzepten e Phasen erm glichen eine zeitliche und sachlogische Gliederung des Entwick lungsprozesses Jede Phase dient einem bestimmten Zweck umfasst bestimmte Aktivit ten und f hrt zu einem definierten Ergebnis Meilenstein Der RUP unterscheidet zwischen Konzeptionsphase Entwurfsphase Konstruktionspha se und bergabephase e Iterationen erm glichen es komplexe Teilaufgaben einzelner Phasen in ber schaubare Arbeitspakete zu zergliedern Den Ausgangspunkt einer Iteration bildet jeweils eine intersubjektiv nachpr fbare Zieldefinition welche am Ende der Iteration herangezogen wird um den Grad der Zielerreichung festzustellen e Meilensteine stellen die Verkn pfung von klar definierten Ergebnissen mit ei nem festgelegten Zeitpunkt dar und erm glichen es den Fortschritt des Pro jektes zu berwachen e Aktivit ten stellen die einzelnen Aufgaben Arbeitsschr
102. g von Informationen Bei der Anwendung asynchroner Kommunikation m ssen Sender und Empf nger f r eine funktionierende Kommunikation nicht zwingend aktiv sein Ist der Empf nger nicht verf gbar so werden die an ihn adressierten Nachrichten in einer Warteschlange persistent zwischengespeichert Die sendende Anwendung wird somit auch dann nicht blockiert wenn der Empf nger zum Zeitpunkt des Versendens einer Nach richt nicht erreichbar ist Aus diesem Grund zeichnet sich asynchrone nachrichten basierte Kommunikation vor allem in einem verteilten heterogenen Umfeld aus in welchem die zu integrierenden Anwendungen unterschiedlichen Verantwortlichkeiten unterstehen oder ber das Internet interagieren m ssen Nachrichtenbasierte Kom munikation erm glicht eine Entkopplung der zentralen Integrationsinfrastruktur von 102 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION der Implementierung der einzelnen Anwendungen Dies erlaubt gegen ber dem Ein satz von RPC oder RMI basierten Integrationsl sungen einen zus tzlichen Grad an Flexibilit t Ein Nachteil nachrichtenbasierter Kommunikation besteht darin dass sie die Suche nach Fehlern erschwert W hrend bei einer engen Kopplung zwei er Systeme aufgrund der Implementierungsabh ngigkeiten viele Fehler bereits zur bersetzungszeit gefunden werden k nnen zeigen sich bei einer nachrichtenbasier ten losen Kopplung viele Fehler erst zur Laufzeit Dabei ist in vielen F llen zun chst nicht direkt er
103. gar g nzlich verzichtet werden da Schnittstellen und Funktionalit ten der eingesetzten Web Services hinreichend bekannt sind Verglichen mit den anderen betrachteten Standards kommt UDDI im praktischen Einsatz daher eine eher geringe Bedeutung zu Der Hauptvorteil von Web Services liegt in der Verwendung offener Standards die sowohl Plattformunabh ngigkeit als auch Protokoll und Programmiersprachen unabh ngigkeit erm glichen und somit eine hohe Flexibilit t und Interoperabilit t Web Service basierter Integrationsl sungen sicherstellen 9 4 INTEGRATIONSEBENEN 105 Durch das blicherweise zur Nachrichten bertragung verwendete HTTP Pro tokoll ist eine Kommunikation auch ber Organisationsgrenzen hinweg problem los m glich Nachteile betreffen vor allem die Performanz die durch die XML Verarbeitung und die Gr e der zu bertragenen Nachrichten negativ beeinflusst wird Kritisch zu hinterfragen ist weiterhin ob die verf gbaren Standards wie XML Encryption Wor07b XML Signature Wor07c oder Web Services Security OASO7c ausreichen um auch in sensiblen Bereichen ein angemessenes Sicherheitsniveau zu gew hrleisten Orchestrierung von Web Services Mithilfe der Sprache WS BPEL Web Service Business Process Execution Lan guage OAS07a JMS06 lassen sich Web Services zu komplexeren Diensten or chestrieren Dies erm glicht es Gesch ftsprozesse aus elementaren Web Service Bausteinen mit definierten Schnittstellen
104. gen ber tritt der urspr ngliche Vorteil von Java n mlich die M glichkeit spezielle Java Klassen so genannte Applets ber das Internet zu laden ud gefahrlos auf dem eigenen Rechner in einem gesch tzten Bereich der so genannten Sandbox ausf hren zu k nnen deutlich in den Hintergrund In den nachfolgenden Abschnitten werden die grundlegenden Konzepte der Ob jektorientierung dargestellt Eine ausf hrlichere Einf hrung in die Objektorientie rung bieten Zep04 Bal98 LR06 Des Weiteren werden in Anlehnung an Oes05 Sti05 einige der wichtigsten Diagrammarten der UML sowie deren Semantik be schrieben Unter OOS08 findet sich eine Gegen berstellung von mehr als 100 UML Werkzeugen und deren Leistungsumfang Leser die mit der Objektorientierung ud 4 1 GRUNDKONZEPTE DER OBJEKTORIENTIERUNG 27 der UML vertraut sind k nnen den Rest des Kapitels berspringen 4 1 Grundkonzepte der Objektorientierung 4 1 1 Objekte und Klassen Bei jedem Programmmieransatz m ssen Objekte und Konzepte der Realwelt im Rechner repr sentiert werden In der Objektorientierung geschieht dies durch so genannte Objekte Jedes Objekt l sst sich durch zwei Merkmale charakterisieren 1 es besitzt einen eindeutigen Zustand und ein wohldefiniertes Verhalten und 2 unter allen Objekten ist es eindeutig identifizierbar Nicht jedes relevante Objekt wird individuell konzipiert Stattdessen beschreibt man Objekte mit gleicher Struktur und gleichem Verhalten
105. gt wurde als Prototyp an der Universit t M nster entwickelt MLK04 LMK04 Glass Box Testen findet auch Fehler die nur in Sonderf llen auftreten Allerdings ist der Rechenaufwand hier so gro dass es sich zwar f r das Testen von einzelnen algorithmisch komplexen Klas sen eignet i allg aber nicht f r die berpr fung ganzer Subsysteme oder Systeme Durch Verwenden beider Ans tze lassen sich die St rken von Black Box und Glass 82 KAPITEL 7 TESTEN Testfall 1 Testfall 2 a 17 42 a 17 42 ves INT wei up a length 1 Ergebnis 1 Ergebnis 1 S low lt up y j mid low up 2 up low mid 1 return mid Abbildung 7 3 Kontrollfluss berdeckung f r bin res Suchen Box Testen kombinieren Kapitel 8 Tools In diesem Kapitel sollen einige Werkzeuge vorgestellt werde deren Einsatz bei der Softwareentwicklung zu empfehlen ist oder zumindest berlegt werden sollte 8 1 Versionsverwaltung 8 1 1 Aufgaben Die Versionsverwaltung dient in der Softwareentwicklung der Verwaltung unter schiedlicher Versionen von digitalen Dokumenten wie Quellcode oder Dokumen tationsdateien Die wesentliche Aufgabe einer Versionsverwaltung besteht darin die unterschiedlichen Versionen der Dateien eines Projektes zu speichern Hierf r wer den zu jeder Version eine Versionsnummer sowie die Person welche die neu
106. herungen und Rahmenbedingungen Daher kann sich ein Vorgehensmodell wel ches sich in einem Projekt bew hrt hat in einem nur geringf gig anders gearteten Projekt als fataler Fehlgriff erweisen Dennoch neigen viele Projektleiter dazu aus Bequemlichkeit Routine oder mangelnden Kenntnissen f r unterschiedliche Pro jekte stets die gleichen Vorgehensmodelle einzusetzen Insbesondere Varianten des 5 6 KAPITEL 2 VORGEHENSMODELLE Wasserfall Modells werden aufgrund ihrer Einfachheit und ihrer hohen Verbreitung in der Praxis vielmals als eine Art Standardmethodologie eingesetzt Ein Vorgehensmodell oder Prozessmodell sollte Vorgaben fiir folgende Bereiche der Projektplanung berwachung und steuerung geben e sachlogische Strukturierung des Arbeitsablaufs Gliederung in Entwicklungs schritte Phasen oder Iterationen e Festlegung der jeweils durchzuf hrenden Aktivit ten e Fixierung der in den einzelnen Gliederungsabschnitten zu erstellenden Leis tungen e Definition von Kriterien zur berwachung des Projektfortschrittes Meilen steine Artefakte e Ermittlung der ben tigten sowie verf gbaren personellen und materiellen Res sourcen e Festlegung sowie Abgrenzung von Rollen Kompetenzen und Verantwortlich keiten e Ausarbeitung der anzuwendenden Standards Richtlinien Methoden und Werk zeuge Die zentralen Aspekte f r die ein Vorgehensmodell Handlungsempfehlungen bie ten sollte lassen sich kurz und pr gnant mit f
107. hode enth lt die in einer vom Framework Nutzer erstellten Unterklasse so berschrieben wird dass bei Aufruf der Fabrikmethode das gew nschte Objekt erzeugt wird Singleton stellt ein Einzelobjekt zur Verf gung und verhindert dass weitere Ob jekte der betreffenden Klasse erzeugt werden Es wird h ufig verwendet um in einem Softwaresystem globale Einstellungen zu speichern Prototyp erzeugt Objekte und insbesondere komplexe Objektstrukturen durch Klonen von Vorlagen statt durch direkte Verwendung von Konstruktoren Erbauer trennt den Konstruktionsprozess von komplexen Objektstrukturen von deren Repr sentation 6 2 Strukturmuster Strukturmuster befassen sich mit der Komposition von Klassen und Objekten um gr ere Strukturen zu bilden Als Beispiel wird im Folgenden der Adapter bzw 6 2 STRUKTURMUSTER 69 Wrapper vorgestellt der je nach Realisierung sowohl ein klassen oder objektba siertes Strukturmuster sein kann 6 2 1 Adapter Mitunter kann eine als wiederverwendbar entwickelte Klasse einer Klassenbibliothek nicht wiederverwendet werden weil ihre Schnittstelle nicht der von der Anwendung verlangten spezifischen Schnittstelle entspricht Das Adaptermuster l st dieses Pro blem und l sst Klassen zusammenarbeiten die wegen inkompatibler Schnittstellen ansonsten nicht dazu in der Lage w ren Im Allgemeinen passt ein Adapter die Schnittstelle des zu adaptierenden Objekts an eine andere Schnittstelle an und bie te
108. ie Integration mit COM wird durch die Verwendung des Adaptermusters er reicht Runtime callable Wrapper erm glichen den Zugriff auf COM Komponenten Microsoft unterst tzt eine Vielzahl von Programmiersprachen f r die CLR u a C J JScript Managed C und Visual Basic NET Da alle Sprachen vor der Ausf hrung in dieselbe Zwischensprache bersetzt werden erm glicht das NET Framework Programmiersprachenunabh ngigkeit Net Framework COM Dienste Betriebssystem Abbildung 5 11 Architektur des NET Frameworks 58 KAPITEL 5 SOFTWAREARCHITEKTUREN COM Das Component Object Model SGM02 S 329 ff stellt die Grundlage komponen tenbasierter Software fiir die Microsoft Windows Plattform dar Beim COM handelt es sich um einen bin ren sprachunabh ngigen Standard zur Definition von Schnitt stellen Das Verhalten einer Schnittstelle wird durch den COM Standard nicht weiter spezifiziert d h es werden keine Vorgaben gemacht wie das Verhalten der Schnitt stelle umzusetzen ist Eine COM Schnittstelle muss daher nicht zwangsl ufig durch ein Objekt implementiert werden sondern kann auch lediglich aus einer Menge von Funktionen bestehen die die Vorgaben der Schnittstelle umsetzen Abbildung 5 12 zeigt den Aufbau einer COM Schnittstelle Sie wird auf bin rer Ebene durch einen Interface Knoten repr sentiert Dieser Knoten enth lt einen Zei ger auf eine Tabelle von Funktionszeigern vTable Aus der Sicht ein
109. iebnahme unterschieden Der Entwicklungsablauf verl uft sequentiell d h eine Aktivit t muss vollst ndig beendet werden bevor die n chste gestartet werden kann vgl Abbildung 2 1 Um auf nderungen eingehen oder nachtr glich Korrekturen vornehmen zu k nnen sind in jeder Phase R ckspr nge auf vorangegangene und bereits abgearbeitete Phasen m glich Aufgrund seiner Einfachheit und des geringen Managementaufwands wird das Wasserfall Modell in der Praxis verbreitet eingesetzt Allerdings gibt es auch eine Reihe von Kritikpunkten e Das Wasserfall Modell verleitet aufgrund seines sequentiellen Charakters da zu die Anforderungsdefinition zu Beginn des Projektes vorzunehmen und anschlie end f r beendet zu erkl ren Ergeben sich im weiteren Verlauf des Projektes nderungen an den urspr nglich erhobenen Anforderungen oder Erg nzungen so k nnen diese in einer sp ten Projektphase nicht mehr oder nur mit enormen Aufwand ber cksichtigt werden e Test und Integrationsaktivit ten sieht das Wasserfall Modell erst nach dem Abschluss der Implementierungsphase vor Fehler werden oftmals erst dann er kannt wenn das Projekt weit fortgeschritten und ein Grossteil des verf gbaren 8 KAPITEL 2 VORGEHENSMODELLE Budgets aufgebraucht ist Zudem steigt der Aufwand fiir die Behebung von Fehlern mit zunehmendem Fortschritt des Projektes berproportional an Ins besondere die Beseitigung von Problemen die auf Fehlentscheidungen in der Definiti
110. ier Phasen des Projektes in unterschiedlich hohem Ma e an was durch die Darstellung in Form eines Gebirges verdeutlicht wird Auch in fr hen Phasen fallen hier bereits Implementierungs und Test Arbeiten an z B wenn es darum geht anhand eines kleinen Beispiels herauszufinden ob zwei Platt formen oder Frameworks vertr glich sind Die Phasenziele k nnen in Teilziele zerlegt werden welche jeweils durch eine Iteration abgearbeitet werden Der Projektfort schritt wird durch Meilensteine berpr ft und dokumentiert welche den Abschluss einer Phase oder Iteration markieren k nnen Charakteristisch f r den RUP sind sechs so genannte Best Practises welche bei der Umsetzung der Grundprinzipien helfen sollen Im Einzelnen sind dies Iterative Entwicklung Anforderungsmanage ment Architekturzentrierte Entwicklung Visuelle Modellierung in der Regel mit UML Qualit tssicherung und nderungsmanagement Im Rahmen eines RUP Projektes m ssen neben der eigentlichen Software zum Zweck des Projektmanagements eine ganze Reihe zus tzlicher Dokumente erstellt werden Der hohe Strukturierungsgrad des RUP und seine starke Ausrichtung auf formale Dokumente und Definitionen macht dieses eher schwergewichtige Vor gehensmodell in erster Linie f r Projekte mit mehr als 10 Beteiligten und einer Dauer von mehreren Monaten interessant Sowohl die Eigenschaften des zu entwi ckelnden Systems als auch der Verlauf des Entwicklungsprozesses sind in hohem Grad
111. iffs und Deploymentinformationen Um fiir eine bestimmte Anforderung einen ad quaten Web Service finden und adressieren zu k nnen kann der Standard UDDI verwendet werden UDDI stellt mithilfe einer SOAP Schnitt stelle einen Verzeichnisdienst bereit der Informationen ber Web Services und deren Anbieter enth lt Die Interaktionen zwischen einem Dienstanbieter und einem Kon sumenten sind in Abbildung 9 8 veranschaulicht Der Anbieter ver ffentlicht in einer UDDI Registry Informationen zu seinem Unternehmen bzw seiner Organisation so wie die WSDL Beschreibung der zu ver ffentlichen Web Services UDDI Registry WS description iind Anwendung A Anwendung B Service Ges Service Anbieter bind invoke Konsument Abbildung 9 8 Interaktionen zwischen Web Services Der Konsument durchsucht dieses Verzeichnis findet anhand der Anbieter und Dienstbeschreibungen einen passenden Dienst und erhalt die WSDL Beschreibung des ausgew hlten Web Services Mit dieser kann er den entsprechenden Dienst inte grieren und ber SOAP Nachrichten auf dessen Funktionen zugreifen Sollen Web Services lediglich innerhalb der eigenen Organisation oder eines beschr nkten Kreises von Anbietern und Nutzern ver ffentlicht werden so kann als Alternative zu UDDI auch ein eigener Web Service Verzeichnisdienst eingerichtet werden In vielen F llen kann auf die Verwendung eines Registry Dienstes so
112. in unterschiedlichen Systemen redundant zu implementieren Schwierig nachzuvollziehende Fehler sind dann m glich wenn nderungen an der Programmlogik nicht konsistent nachgef hrt werden oder transaktionsverarbeitende Logik dupliziert wurde Aus diesen Gr nden stellt die Datenintegration nur dann eine unproblematische Integrationsl sung dar wenn lediglich ein lesender Zugriff auf die Daten einer Anwendung ben tigt wird Die Integration auf Funktionsebene ist die semantisch reichhaltigste Art der In tegration da hier nicht nur die Semantik der Daten sondern zudem die Semantik der Programmlogik einer Anwendung zug nglich gemacht wird Dar ber hinaus lassen sich Redundanzen welche in den zu integrierenden Systemen sowohl auf Daten ebene als auch auf Funktionsebene bestehen k nnen weitestgehend beseitigen An dererseits l sst sich eine Funktionsintegration nicht in jedem Fall ohne Schwierig keiten durchf hren Probleme sind vor allem dann zu erwarten wenn Anwendungen zu integrieren sind die ber keine Schnittstellen zur Anbindung an Fremdsyste me verf gen und keinen Einblick in den Quellcode erlauben Dar ber hinaus ist die Funktionsintegration mit einem nicht zu untersch tzenden technischen Aufwand verbunden Hierzu tr gt nicht zuletzt die F lle der verf gbaren Integrationstechno logien bei Aufgrund der unterschiedlichen Eigenschaften der Technologiealternati ven sollte der Auswahl einer geeigneten Integrationstechnologie mindest
113. ind Modell den Web Controls und der guten Visual Studio Integration den L sungen f r Java EE berlegen zu sein Im Bereich der Gesch ftslogik insbesondere bei der Anbindung an relationale Datenbanken bietet Java EE die berzeugenderen Ans tze Ein Nachteil der NET Plattform ist hier vor allem darin zu sehen dass ADO NET noch kein automatisches O R Mapping unterst tzt F r Java EE gibt es neben der JPA viele weiter Frameworks die diese Funktion automatisieren So wohl Java EE als auch NET Komponenten k nnen relativ leicht als Web Services bereitgestellt und eingebunden werden Hierdurch werden auch heterogene Softwa rekomponenten in denen Java EE NET und andere Ans tze verkn pft werden erm glicht Web Services sind die lingua franca der Software Integration und ent sprechen damit der Sprache Englisch im internationalen Gesch ftsleben 64 KAPITEL 5 SOFTWAREARCHITEKTUREN Kapitel 6 Entwurfsmuster Entwurfsmuster GHJV96 sind bew hrte L sungen h ufig auftauchender Entwurfs probleme Durch ihre Verwendung ist eine Wiederverwendung auf Entwurfsebene m glich das Rad muss nicht mehr st ndig neu erfunden werden Im objektorien tierten Kontext besteht ein Muster aus einem System von wenigen Klassen Muster erlauben ein Softwaresystem auf einem h heren Abstraktionsniveau zu verstehen Statt als System von sehr vielen Klassen wird es von den Entwicklern als Kombina tion von deutlich weniger Mustern wahrgenom
114. ine klare Trennung von HTML und Anwendungscode erreicht die es erm glicht beide parallel und unabh ngig von einander zu entwickeln 56 KAPITEL 5 SOFTWAREARCHITEKTUREN VORTEILE NACHTEILE Hohe Produktivitat steile Lernkurve Echte HTML Templates Schlechte Dokumentation Viele Innovationen zwischen Lange Versionszyklen Versionszyklen Quelle Raible Rai07 Tabelle 5 6 Vor und Nachteile des Tapestry Frameworks 9 2 4 NEI Grundlagen Das NET Framework Mic07b ist eine von Microsoft entwickelte Implementierung der Common Language Infrastructure CLI Die CLI ist ein ISO IEC ECMA Standard der ahnlich wie CORBA eine programmiersprachen und plattformneutrale Softwarearchitektur spezifiziert Im Unterschied zu CORBA defi niert CLI zusatzlich eine Common Intermediate Language CIL und ein Dateifor mat fiir das Deployment von Komponenten den sogenannten Assemblies In diesen Punkten hnelt die CLI der Java Spazifikation die Java Bytecode als Zwischenspra che und Jar Dateien fiir das Deployment definiert Die CLI umfasst e die Common Language Specification CLS eine Menge von Regeln die eine Programmiersprache erfiillen muss um in die Zwischensprache die Com mon Intermediate Language bersetzt werden zu k nnen e das Common Type System CTS ein f r alle Sprachen der CLI einheitli ches und verbindliches Typsystem und e eine Laufzeitumgebung das Virtual Execution System VES welches
115. ingesetzten und h ufig gewarteten Softwaresystemen sicher stellen k nnen dass die urspr ngliche Architektur im Laufe der Zeit nicht immer mehr untergraben und die Verst ndlichkeit und Wartbarkeit somit verschlechtert wird sondern dass die ursp nglichen Architekturrichtlinien eingehalten werden z B bez glich der Schichten Solche Tools k nnen auch eine Vielzahl von Kennzahlen zu einem Softwareprodukt ermitteln die u a Aufschluss ber dessen Zustand geben Kapitel 9 Enterprise Application Integration Die Anwendungsintegration oder Enterprise Application Integration EAI CHK06 Lin00 geh rt zu den Themengebieten der Informatik die in Wissenschaft und Pra xis vielfach diskutiert werden Trotzdem wird das Konzept der EAI h ufig verk rzt oder sogar grunds tzlich falsch verstanden Neben einer uneinheitlichen Definition der relevanten Begriffe tr gt vor allem die F lle der im Kontext der EAI verf gbaren Produkte und Technologien zu der Verwirrung bei Nicht selten wird EAI mit dem Einsatz bestimmter Technologiekonzepte z B Middleware Plattformen oder In tegrationsarchitekturen z B Service Orientierte Architekturen gleichgesetzt Das Spektrum der verf gbaren Integrationstechnologien ist aufgrund der sich wandeln den Anforderungen an die Anwendungsintegration fortw hrenden Ver nderungen unterworfen Die Dominanz aktueller Technologietrends am Markt f r Integrati onsprodukte und in den wissenschaftlichen Publikationen beg
116. ird bei den Web Architekturen diese Funktion auf Web Server und Web Browser aufgeteilt Die Kommunikation zwischen Web Browser und Web Server basiert auf dem HTTP Protokoll was zur Folge hat dass die Verbindung zwischen Client und Ser ver nach jedem Request Response Zyklus wieder getrennt wird Im Unterschied zu einem Desktop Client besteht also keine dauerhafte Verbindung zum Server Um dennoch eine Zusammenfassung von Zugriffen zu Sitzungen zu erm glichen wird auf Techniken wie Cookies zur ckgegriffen Diese werden bei jeder Kommunikation zwischen Web Client und Web Serverim Header der betreffenden HTTP Nachricht mitgeschickt und erm glichen so die Zuordnung eines Zugriffs zu einer Sitzung Aufgrund dieser zentralen Unterschiede ergeben sich unterschiedliche Vor und Nachteile der beiden Architekturen welche in der nachfolgenden Tabelle gegen ber gestellt werden Multi Channel Architektur Der Vorteil einer Schichtenarchitektur zeigt sich vor allem dann wenn der Zugang zum System ber verschiedene Kan le erfolgen soll Durch die Verteilung der Pr sentations Verarbeitungs und Datenhaltungsfunkti on auf unterschiedliche Schichten muss f r eine neue Zugangsm glichkeit nicht das komplette System neu implementiert werden da es ausreichend ist die entsprechen den Sichten um weitere Module zu erg nzen Dabei kann auf die Funktionalit ten der bereits vorhandenen Schichten zur ckgegriffen werden 5 2 KOMPONENTENBASIERTE ARCHITEKT
117. ite umgewandelt Dieses Modell erm glicht eine Oberfl chenprogrammierung die sehr viel hnlichkeiten mit der Programmierung von Desktop Oberfl chen aufweist Spring MVC Das Spring MVC Framework Int07 JHA 05 zur Entwicklung von Web Anwen dungen ist ein Modul des Spring Frameworks Spring selber ist eine auf Java basie rende Plattform zur Serverprogrammierung die ebenso wie die Java EE Plattform dazu dient verteilte mehrschichtige und komponentenbasierte Architekturen zu im plementieren Ziel von Spring ist es die Entwicklung von Anwendungen f r Application Server durch ein leichtgewichtiges POJO basiertes Programmiermodell zu vereinfa chen Um dieses Ziel zu erreichen unterst tzt Spring und demzufolge auch Spring MVC die folgenden Programmierparadigmen e Dependency Injection Spring bietet ein auf der JavaBean Technologie ba sierendes Konfigurationsmanagement mit dem die Abh ngigkeiten zwischen den einzelnen Komponenten reduziert werden Hierf r werden die Abh ngigkeiten die eine Komponente besitzt nicht durch sie selbst bestimmt sondern von au Ben ber die Argumente eines Methodenaufrufes injiziert 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 59 VORTEILE NACHTEILE Gute Integration mit anderen Tech Aufw ndige Konfiguration durch nologien und Frameworks XML Leichtes Testen durch Dependency Erfordert viel Code in JSPs Injection Durch hohe Flexibilit t u U man gelnde Struktur kein Parent C
118. itte oder Arbeitspake te dar welche im Rahmen des Entwicklungsprozesses zu erledigen sind Die Granularit t der Aktivit ten sollte so gew hlt werden dass sich diesen jeweils ein sinnvolles und abgrenzbares Ergebnis sowie eindeutig formulierte Kompe tenzen und Verantwortlichkeiten zuordnen lassen e Disziplinen erm glichen eine inhaltliche Strukturierung der Entwicklungsakti vit ten Der RUP unterscheidet die sechs Kerndisziplinen Gesch ftsprozessmo dellierung Anforderungsanalyse Analyse und Design Implementierung sowie Test und Softwareverteilung Hinzu kommen die drei unterst tzenden Diszipli nen Konfigurations und nderungsmanagement Projektmanagement sowie Infrastrukturmanagement e Akteure erm glichen die Verkn pfung von Aufgaben und Artefakten mit den daf r verantwortlichen Personen und Rollen 10 KAPITEL 2 VORGEHENSMODELLE Phases Disciplines Inception Elaboration Construction Transition Business Modeling Requirements i Analysis amp Design Implementation Test Deployment Configuration amp Change Mgmt Project Management Environment oes oe a Iterations Abbildung 2 2 Der Rational Unified Process Abbildung 2 2 verdeutlicht das Zusammenspiel der vorgestellten Grundkonzepte innerhalb des Entwicklungsprozesses In den vier Projektphasen werden die nach Disziplinen geordneten Aktivit ten durch festgelegte Akteure ausgefiihrt Die ein zelnen Aktivit ten fallen in den v
119. itzen an den Assoziationen sagen aus dass der Zugriff auf die jeweiligen Nachbarobjekte nur in Pfeilrichtung m glich ist Von einem geschachtelten Ausdruck kann also beispiels weise auf die beiden Teilausdriicke zugegriffen werden nicht aber umgekehrt 4 2 3 Anwendungsfalldiagramme Ein Anwendungsfall use case beschreibt eine konkrete funktionalen Anforderung an ein Anwendungssystem bzw eine Interaktion zwischen einem Akteur und dem System Hierbei wird nur beschrieben was das System leisten muss aber nicht wie es das leisten soll Ein Anwendungsfall wird durch einen Akteur initiiert Ein Akteur kann sowohl ein Anwender als auch ein anderes Anwendungssystem sein Ublicherweise werden nicht die konkreten beteiligten Personen unterschieden son dern ihre Rollen die sie im Kontext eines bestimmten Anwendungsfalls einnehmen z B Handler und Kunde 34 KAPITEL 4 OBJEKTORIENTIERUNG UND UML Ein Anwendungsfalldiagramm zeigt die Zusammenh nge und Abh ngigkeiten zwischen Anwendungsf llen und Akteuren Ein als Strichm nnchen dargestellter Akteur ist im Diagramm durch eine Linie mit einem oder mehreren als Ellipse dar gestellten Anwendungsf llen verbunden an denen er beteiligt ist Ein Beispiel f r ein Bibliothekssystem ist in Abbildung 4 7 dargestellt Mahnungen O verschicken A Abrechnungssystem lt lt includes gt gt Kunde S Authentifizieren 2 2 7 lt lt includes gt gt Buch zuriickgeben lt l
120. kennbar ob ein Fehler mit der Erzeugung einer Nachricht im Quell system dem Nachrichtenformat selbst der bertragung der Nachricht oder ihrer Auswertung im Zielsystem zusammenh ngt Java Messaging Service In einem Java Umfeld bietet sich Java Message Service JMS vgl Sun07d als m gliche Implementierungsplattform f r eine nachrichtenbasierte Kommunikation an Die JMS API erlaubt es Java EE Anwendungen Nachrichten zu erzeugen zu versenden und zu empfangen Sie unterst tzt die Umsetzung einer lose gekoppelten verteilten und asynchronen Kommunikationsplattform Vorteilhaft ist die Verf gbar keit einer ausgereiften API die dem Anwender eine einfache Benutzung erm glicht und dar ber hinaus Dienste wie Transaktionssicherung oder die Unterst tzung ver schiedener Nachrichtenmodelle bereitstellt Neben der Punkt zu Punkt Kommunika tion Unicast welche mit einem E Mail Versand von einem Sender an einen Empf n ger verglichen werden kann lassen sich Nachrichten im Publish and Subscribe Modus versenden Beim Publish and Subscribe werden Nachrichten nicht an einen bestimm ten Empf nger sondern an ein so genanntes Topic gesendet Empf nger einer Nach richt sind dabei nur solche Systeme die das jeweilige Topic abonniert haben Auf diese Weise l sst sich auch eine Multicast oder Broadcast Kommunikation nachbil den welche mit einem E Mail Versand eines Senders an mehrere Mitglieder bzw eine ganze Gruppe von Empf ngern vergleichba
121. lient Prasentation Web Server Web Server PR Minion Pe eae Verarbeitung Session Beans NET Kissen Entities ADO NET Abbildung 5 13 Architekturvergleich von Java EE und NET Anwendungen re Request Response Zyklen zwischen Browser und Webserver hinweg erzeugt sei nen eigenen HTML und JavaScript Code zur Webclient seitigen Visualisierung im Browser kann mit anderen Controls zu einem komplexeren Control kombiniert wer den und wandelt Benutzereingaben in entsprechende Ereignisse um Diese Eigen schaften erm glichen es in einer zustandslosen Web Umgebung ein ereignisbasiertes zustandsbehaftetes Programmiermodell zu realisieren hnlich wie bei den Java EE Frameworks JSF und Tapestry Das ASP NET Framework bietet eine hohe Performanz und Skalierbarkeit Gr n de hierf r sind die Pr compilierung der ASPX Seiten die vielf ltigen Caching M glichkeiten und die automatisierte Sitzungsverwaltung die eine Sitzungsverfol gung auch auf einer Webfarm erm glicht Im Vergleich zu anderen Web Frameworks werden bei ASP NET gro e Teile des HTML und JavaScript Codes automatisch ge neriert Aussehen und Verhalten der Steuerelemente werden im Wesentlichen ber deren Eigenschaften gesteuert das Erzeugen des HTML Codes geschieht dann auto matisch Weiterf hrende Informationen ber die ASP NET Technologie finden sich u a in LH05 Loh03 5 2 5 Vergleich Java EE und NET In diesem Abschnitt werden die Komponenten Frameworks Java E
122. lisierungen 2 2 2 2 6 8 Entwurfsmuster Beobachter EK EE e EE EEN EEN 7 3 Kontrollfluss berdeckung a oaa E A e E rasen 8 1 Speichermodelle f r die Versionskontrolle 8 2 Kategorisierung von CASE Tools oaoa a aa a 9 1 Vollst ndige Punkt zu Punkt Integration von sechs Systemen D 9 2 Hub and Spokes Integration 93 aerer eler ee ie A oe i e det Wed 9 4 Integration auf Datenebene e 9 5 Integration auf Funktionsebene 00 0048 9 6 bersicht Integrationstechnologien 9 7 Entfernter Methodenaufruf ber einen Objekt Request Broker 9 8 Interaktionen zwischen Web Services 2 222 9 9 Integration auf Benutzerschnittstellenebene 10 1 Klassendiagramm Buch und Exemplar 10 2 Generierter EJB Code f r die Klasse Exemplar im Buch Beispiel 10 3 xPand Transformationsregeln im Buch Beispiel 2 Tabellenverzeichnis 1 1 3 1 3 2 3 3 3 4 5 1 5 2 5 3 5 4 5 9 5 6 Eignung von Technologien Ma nahmen und Ans tzen FP Bewertung von Eingaben Ausgaben und Abfragen FP Bewertung von internen Datenbest nden und Referenzdaten Beispiel Ermittlung von Function Points 2 2 2 2 Typische Risiken einer Software Entwicklung Vor und Nachteile von Schichtenarchitekturen Vergleich von Schichtenarchitekturen e Vor und Nachteile des Struts Frameworks Vor
123. llen an denen das jeweilige Objekt aktiv ist verdickt wird Horizontale Pfeile zeigen an wo eine Nach richt an ein Nachbarobjekt geschickt wird d h wo eine Methode des Nachbarobjekts mit welchen Parametern aufgerufen wird Eine gestrichelte Kante in Riickrichtung kann verwendet werden um anzuzeigen wann welches Ergebnis des Methodenauf rufs zur ckgeschickt wird Ein Pfeil von einem Objekt zu sich selber repr sentiert eine interne Operation des Objekts Ein Objekt kann nur dann eine Nachricht an ein anderes Objekt schicken wenn es dieses Objekt kennt d h wenn die zugeh rigen Klassen durch eine Assoziation verbunden sind das erste Objekt das zweite er zeugt hat oder eine Referenz auf das zweite Objekt als Teil Ergebnis einer vorhe rigen Rechnung des ersten Objekts ermittelt wurde UML Modellierungswerkzeuge k nnen insbesondere berpr fen ob die in einem Sequenzdiagramm unterstellte As soziation zwischen zwei Klassen in einem Klassendiagramm wirklich vorhanden ist und die Modelle insofern konsistent sind Geschachtelt Ausdruck Ausdruck Addition auswerten auswerten ergebnis1 GE ell auswerten ergebnis2 Wie a a dy Ia ere ek tae al ausfuehren ergebhis 1 ergebnis2 gt ergebnis ergebnis lt x y Abbildung 4 8 Sequenzdiagramm f r die Auswertung eines arithmetischen Aus drucks Abbil
124. llen Look and Feel Zudem sichert eine Widgetfabrik die Abh ngigkeiten zwischen den konkreten Widgetklassen ab Ein Swing Fenster sollte nur mit einem Swing Scrollbar ausgestattet werden Diese Konsistenzbedin gung wird automatisch als Konsequenz des Einsatzes einer SwingWidgetFabrik si chergestellt Das Abstrakte Fabrik Muster kann verwendet werden wenn 1 ein System un abh ngig von der Erzeugung Zusammensetzung und Repr sentation seiner erzeug ten Objekte sein soll 2 ein System mit einer von mehreren Produktfamilien kon figuriert werden soll 3 Konsistenzbedingungen bei der Zusammenarbeit von ver wandten Objekten sichergestellt werden m ssen und 4 nur eine Schnittstelle aber nicht die konkrete Implementierung einer Klassenbibliothek offen gelegt werden soll Das Abstrakte Fabrik Muster hat die folgenden Vorteile Zun chst erm glicht es Klassen von Objekten zu steuern welche durch die Anwendung erzeugt werden Da eine Fabrik f r den Prozess des Erzeugens von Objekten zust ndig ist und ihn kap selt isoliert es Klienten von den Implementierungs und Produktklassen Des Wei teren l sst sich ein einfacher Austausch von Produktfamilien realisieren Die Klasse einer konkreten Fabrik erscheint nur einmal in der Anwendung n mlich genau dort 68 KAPITEL 6 ENTWURFSMUSTER wo von ihr ein Exemplar erzeugt wird Dies erm glicht einen einfachen Austausch der von der Anwendung benutzten Fabriken und der damit zusammenh ngenden P
125. llst ndig im Detail zu lesen Sie k nnen dann gezielt die Kapitel durcharbeiten in denen Sie neue Aspekte vorfinden und die anderen eher diagonal lesen Zu jedem der hier behandelten Themen gibt es eigene umgangreiche B cher Eine umfassende detaillierte Darstellung h tte daher mehrere Tausend Seiten er fordert Ziel dieser Brosch re ist es daher nicht alle Aspekte der Softwaretechnik im Detail darzustellen sondern interessante Methoden und deren Vorz ge kurz vorzu stellen und Ihnen durch Literaturhinweise die M glichkeit zu geben die f r Sie rele vanten Aspekte in den entsprechenden umfassenderen Werk nochmal ausf hrlicher nachzuschlagen Die folgenden Themen werden in dieser Brosch re behandelt In Kapitel 2 wer den zun chst in der aktuellen Diskussion vielbeachtete Vorgehensmodelle f r die Softwareentwicklung vorgestellt und zwar der Unified Process und Extreme Pro gramming Viele Firmen setzen was das Vorgehensmodell angeht noch das klassi 1 2 KAPITEL 1 EINLEITUNG sche Wasserfallmodell ein In einigen Projekten mag das sinnvoll sein Zumindest aber in Projekten bei denen es bedeutsame Risiken zu bew ltigen gilt sollte zur Reduktion der Risisken und der Kosten der Behebung sp t erkannter Fehler eher ein iteratives Vorgehensmodell wie eines der beiden genannten Modelle eingesetzt werden Auch wenn man keinen der beiden Ans tze komplett bernimmt so kann man sich hieran zumindest einzelne Aspekte abschauen und
126. ls eine Zusammenstellung einzelner Softwarekomponenten beschrieben Eine Komponente ist ein Software Baustein mit einer spezifizierten Schnittstelle der konform zu einem Komponentenmodell ist das u a die Verkn pfungsm glichkeiten mit anderen Kom ponenten bestimmt Sie ben tigt zur Ausf hrung oft eine Komponentenplattform von der ihr Dienste wie z B Zugriffskontrolle Transaktionsverarbeitung und Syn chronisation mit einer Datenbank bereitgestellt werden Nicht zuletzt durch diese Dienste l sst sich eine Erh hung der Produktivit t und Qualit t erreichen Wei terhin wird angestrebt sorgf ltig getestete und zuverl ssige Komponenten auch in anderen Projekten wiederzuverwenden was wiederum eine Steigerung der Produk tivit t erm glicht Au erdem l sst sich durch eine Zerlegung eines Softwaresystems 46 KAPITEL 5 SOFTWAREARCHITEKTUREN Desktop Webservice Client ESSEN Client Pr sentation Webzugangs Web schicht Service Verarbeitung Gesch fts logik EE Datenhaltung Datenbank Abbildung 5 5 Multi Channel Architektur in mehrere unabh ngige Teilkomponenten das Abstraktionsniveau f r die Software entwickler erh hen 5 2 1 Komponenten Grundlage eines komponentenbasierten Softwaresystems ist ein Komponentenmo dell welches die Struktur der einzelnen Elemente der Architektur spezifiziert Ein Komponentenmodell umfasst im Wesentlichen eine genaue Beschr
127. men und dadurch leichter berblickt Jeder professionelle Softwareentwickler der diese Bezeichnung verdient sollte zu mindest die wichtigsten Muster kennen und bei den brigen Muster wissen wozu sie dienen und wo ihre Details bei Bedarf nachgeschlagen werden k nnen Muster sind in nahezu jeder gut strukturierten objektorientierten Architektur zu finden und besitzen vier grundlegende Elemente Jedes Muster wird durch einen Mustername benannt Entwurfsmuster stellen somit eine Terminologie f r den Softwareentwurf zur Verf gung welche die Kom munikation und die Dokumentation erleichtert und erweitert Der Problemabschnitt beschreibt wann ein Muster anzuwenden ist welches Problem adressiert wird und was sein Kontext ist Oft wird die Problembeschreibung eine Liste von Bedingun gen auff hren die erf llt sein m ssen wenn die Anwendung des Musters sinn voll sein soll Es beschreibt m gliche spezifische Entwurfsprobleme oder Klassen oder Objektstrukturen die symptomatisch f r einen unflexiblen Entwurf sind Der L sungsabschnitt beschreibt eine allgemeine Anordnung von Klassen und Objek ten aus denen der Entwurf besteht sowie ihre Beziehungen Zust ndigkeiten und Interaktionen Der Konsequenzenabschnitt beschreibt die Vor und Nachteile des aus der Anwendung eines Musters resultierenden Entwurfs und ist oft von zentra ler Bedeutung f r die Bewertung von Entwurfsalternativen Die Konsequenzen der Musteranwendung f r den Entwurf betref
128. mgekehrt Zeitverlaufsdiagramm sind etwas detaillierter da sie auch noch den ge nauen zeitlichen Ablauf auszudr cken gestatten wie dies bei der Modellierung von reaktiven Systemen h ufig erforderlich ist 4 2 5 Aktivit tsdiagramme Wie Sequenzdiagramme erlauben auch Aktivit tsdiagramme das dynamische Ver halten eines Systems zu modellieren allerdings auf einem etwas abstrakteren Ni veau Hier wird ein Ablauf nicht auf die Beitr ge beteiligter Objekte herunterge brochen sondern losgel st von Objekten und Nachrichten als Folge von Aktivit ten dargestellt Im Diagramm wird eine Aktivit t durch ein abgerundetes Rechteck re pr sentiert Pfeile zwischen den Aktivit ten geben an in welcher Reihenfolge die Aktivi ten durchlaufen werden Schwarze Balken zeigen an wo der Ablauf in parallel bearbeitete Teilabl ufe aufgespalten wird bzw wo diese Teilabl ufe wieder zusam mengef hrt werden Rauten stellen dar wo in Abh ngigkeit von gewissen Bedingun gen einer von zwei alternativen Abl ufen ausgew hlt wird bzw wo die Alternativen wieder zusammengef hrt werden Ein Pfeil zwischen zwei Aktivit ten kann optional mit einem Rechteck annotiert werden das anzeigt welche Daten in Pfeilrichtung flie en Geht von einer Aktivit t ein mit einem Blitz annotierter Pfeil aus so zeigt dies an dass im Falle eines Fehlers bei Ausf hrung der Aktivit t die Ausnahme Exception ausgel st wird auf die der Pfeil zeigt Geht der Ablauf hinter dem
129. n die Abhangigkeiten zwischen Paketen jeweils bestehend aus mehreren Klassen und die folgenden Verhaltensdiagramme Zustandsautomaten modellieren zustandsabhangiges Verhalten genauer eine Menge von m glichen Zust nden und die Ubergangsm glichkeiten zwischen diesen Interaktions bersichtdiagramme nutzen die Ausdrucksmittel von Aktivit ts diagrammen um Interaktionen die durch Interaktionsdiagramme beschrieben wurden zu kombinieren Details hierzu findet man zum Beispiel in Oes05 Sti05 Kapitel 5 Softwarearchitekturen Eine Softwarearchitektur beschreibt den grundlegenden Aufbau eines Softwaresys tems indem sie dessen wesentliche Elemente und deren Beziehungen zueinander darstellt Im Folgenden werden zwei weit verbreitete Ans tze zur Strukturierung von Softwaresystemen vorgestellt die sich auch kombinieren lassen n mlich Schich tenbildung und die Zerlegung in Komponenten 5 1 Schichtenarchitekturen Softwarearchitekturen deren Elemente Module Klassen in bereinander liegen den Schichten angeordnet sind werden als Schichtenarchitekturen bezeichnet Sie beschr nken die Zugriffe jedes Elements auf Elemente der gleichen oder tieferer Schichten Schichtenarchitekturen eigenen sich vor allem f r die Strukturierung von komplexen Systemen Sie reduzieren die Abh ngigkeiten zwischen den Elementen verschiedener Schichten und erh hen so u a die bersichtlichkeit Testbarkeit Wart barkeit und Wiederverwendbarkei
130. n kurz skizziert Datentransferobjekt data transfer object DTO stellt eine Zeile des Ergeb nisses einer Datenbankabfrage als Objekt zur Verf gung und erlaubt auf die Attribute ber get Methoden zuzugreifen Datenzugrifsobjekt data access object DAO kapselt den Zugriff auf eine Da tenquelle wie z B eine Datenbank und h lt diese daher austauschbar Business Delegate entkoppelt Pr sentations und Gesch ftslogik Kapitel 7 Testen Zum Thema Testen sollen im folgenden drei Aspekte genauer betrachtet werden Zun chst wird erl utert wie zu testende Softwarebausteine mit m glichst geringem nderungsaufwand isoliert getestet werden k nnen Dann wird die Automatisierung des Testens behandelt Im letzten Abschnitt dieses Kapitels wird dann gezeigt nach welchen Prinzipien Testf lle erzeugt werden k nnen 7 1 Isolation zu testender Einheiten Beim Testen ist es nicht sinnvoll sofort das zu komplette betrachtete Gesamtsystem im Rahmen eines Big Bang Ansatzes zu testen Das Ergebnis eines solche Versuchs w re absehbar es w rde ein Fehler auftreten der aber im Rahmen des Gesamt systems nur sehr schwer lokalisieren lie e Stattdessen beginnt man typischerweise mit einzenen Basiseinheiten Modulen Klassen und setzt diese dann sukzessiv zu immer gr eren Teilsystemen zusammen wobei auftretende Fehler jeweils vor einer weiteren Integration beseitigt werden Ein Problem beim Testen von Basiseinheiten und Teilsystemen ist
131. nd Ein weiteres Problem ist in der komplexeren Qualit tssicherung zu sehen W hrend es bei konventioneller Softwareentwicklung ausreicht den entwi ckelten Code zu testen k nnen sich Fehler nun nicht nur im handgeschriebenen Programmcode sondern auch in den Modellen Transformationsregeln und Metamo dellen verbergen Debugger die die Fehlersuche ber diese verschiedenen Ebenen hinweg unterst tzen fehlen noch Literaturverzeichnis AndO8 Apa07a Apa07b BAO4 Bal93 Bal98 Bal01 Bet07 le BJ97 BMHO6 Boe89 ANDROMDATEAM AndroMDA http www andromda org 2008 APACHE SOFTWARE FOUNDATION Struts http struts apache org Abrufdatum 17 07 2007 APACHE SOFTWARE FOUNDATION Tapestry http tapestry apache org Abrufdatum 17 07 2007 BECK Kent ANDRES Dirk Extreme Programming Explained Embrace Change 1 Boston Addison Wesley 2004 BALZERT Helmut CASE Systeme und Werkzeuge 1 Mannheim B I Wissenschaftsverlag 1993 BALZERT Helmut Lehrbuch der Software Technik Software Management Software Qualitig 5 ssicherung Unternehmensmodellie rung 1 Heidelberg u a Spektrum Akademischer Verlag 1998 BALZERT Helmut Lehrbuch der Software Technik Software Entwicklung 1 Heidelberg u a Spektrum Akademischer Verlag 2001 BETTER SCM INITIATIVE Version Control System Comparison http better scm berlios de comparison comparison html Abrufda tum 17 07 2007 BA
132. nkt f r die Durchf hrung eines Refactorings sind so ge nannte bad smells welche auf Schwachstellen im Code hinweisen Beispiele f r bad smells sind duplizierter Code berlange Klassen Methoden oder Parameterlisten switch Anweisungen oder tempor re Variablen Durch eine iterative Verbesserung der Codequalit t mithilfe von elementaren Refactorings k nnen Schwachstellen und potentielle Fehlerquellen im Code beseitigt werden Durch die erh hte Qualit t des Quelltextes verbessert sich dar ber hinaus die Verst ndlichkeit Wartbarkeit und Erweiterbarkeit des Softwaresystems Beispiele f r Refactoring Schritte sind das Verschieben von Klassen Methoden oder Feldern die Zusammenf hrung logisch zusammen geh riger Felder in einem Objekt oder die Nutzung von Subklassen und Polymorphie zur Vermeidung von switch Anweisungen Ausgangspunkt und Ziel je des Refactoring Schrittes ist stets eine lauff hige Version des Softwaresystems Um das Risiko unerw nschter Seiteneffekte m glichst gering zu halten sind komplexe Restrukturierungen in elementare Refactorings zu zerlegen Am Ende jedes Refac torings stehen Tests die die Funktionalit t des ge nderten Systems berpr fen Um diese vollst ndig und effizient durchf hren zu k nnen ist eine hohe Abdeckung mit automatisierten Tests erforderlich Andernfalls werden m glicherweise nicht alle Feh ler aufgedeckt oder der Zeitaufwand f r die Durchf hrung der Refactorings steigt unverh ltnism
133. nn sich die Tabelle ndert so wird zun chst das Datenobjekt aktualisiert welches dann alle Darstellungsobjekte ber seine Zustands nderung informiert Als Reaktion dar auf synchronisiert sich jedes Darstellungsobjekt mit dem Zustand des Datenobjekts mit Hilfe von Anfragen Abbildung 6 8 zeigt die Struktur des Beobachtermusters Die Basisklasse Subjekt definiert das Protokoll zur Benachrichtigung ber nderungen und die Schnittstelle zum An und Abmelden einer beliebigen Anzahl von Beobachtern Ein Beobach ter definiert eine Aktualisierungsschnittstelle ber welche die Synchronisation mit den ge nderten Daten des Subjekts erfolgt Der Zustand eines KonkretesSubjekt Objekts kann ber die Operation SetzeZustand ge ndert werden Eine Zustands nderung des konkreten Subjekts bewirkt die Benachrichtigung aller registrierten Beobachter welche sich daraufhin mit dem Subjekt ber die Operation GibZustand synchronisieren Das Beobachtermuster kann verwendet werden wenn 1 die nderung eines Ob jekts die nderung anderer Objekte verlangt wobei die Anzahl der zu ndernden Objekte nicht bekannt ist 2 ein Objekt andere Objekte benachrichtigen sollte ohne Annahmen dar ber treffen zu d rfen wer diese Objekte genau sind und 3 wenn eine Abstraktion zwei voneinander abh ngige Aspekte besitzt die aus Gr nden der Wiederverwendung in unterschiedlichen Objekten gekapselt werden sollen Somit erm glicht das Beobachtermuster Subjekte und
134. nn der Entwicklung werden alle Testf lle fehlschlagen da noch keine Programmfunktionalit t implementiert wurde Im weiteren Verlauf dokumentieren die erfolgreich durchlaufenen Testf lle den Projektfortschritt Weiterhin sind die Testf lle bei so genannten Regressionstests wichtig um nach einer nderung schnell und automatisch festzustellen ob die bisher realisierte Funktionalit t immer noch fehlerfrei verf gbar ist Nur durch diese Regressionstests l sst sich ein Projektfort schritt sicherstellen Refactoring Unter Refactoring FowO5 versteht man die schrittweise und systematische Verbesse rung der Struktur eines Softwaresystems unter Beibehaltung seiner Funktionalit t Der von Martin Fowler entwickelte Ansatz zur Coderestrukturierung gr ndet auf der Beobachtung dass Softwaresysteme im Laufe der Zeit bedingt durch zahlreiche nderungen Anpassungen und Erweiterungen eine zunehmend un berschaubare und chaotische Struktur annehmen Bezeichnend f r diesen Zustand ist das Anti Pattern des Spaghetti Codes Por07 welches auf plakative Weise ein Softwaresys 2 3 EXTREME PROGRAMMING 13 tem mit einer undurchdringlichen Struktur und Kontrollflusslogik beschreibt Auf grund der immer schwieriger zu durchschauenden Programmstruktur w chst die Gefahr dass nderungen in einem Programmteil unerw nschte Seiteneffekte in an deren Teilen der Software ausl sen die sich nur mit hohem Aufwand aufdecken und beheben lassen Ansatzpu
135. olgender Frage zusammenfassen Wer welche Akteure macht wann zeitliche und sachlogische Abfolge wie welche Standards Richtlinien Werkzeuge und Methoden was welche Artefakte Vorgehensmodelle f r die Softwareentwicklung lassen sich zwei grundlegenden Kategorien zuordnen den phasenorientierten und den agilen Vorgehensmodellen Als Orientierungshilfe werden im Folgenden mit dem Rational Unified Process RUP und Extreme Programming XP zwei Vertreter dieser unterschiedlichen Denkrich tungen vorgestellt Zuvor soll jedoch zum Vergleich das Wasserfallmodell skizziert werden welches eines der einfachsten phasenbasierten Vorgehensmodelle darstellt Aufgrund der gro en Verbreitung des Wasserfallmodells in der Praxis soll auf ei ne ausf hrliche Darstellung jedoch verzichtet und vielmehr auf die Schwachstellen dieses Ansatzes eingegangen werden 2 1 DAS WASSERFALL MODELL 7 System anforderungen Software anforderungen CA L Analyse L Entwurf zu E Implementierung EH Test E Betrieb Abbildung 2 1 Das Wasserfallmodell 2 1 Das Wasserfall Modell Das Wasserfall Modell Bal98 S 99 f gliedert den Entwicklungsprozess in mehrere Phasen die sukzessive abgearbeitet werden und an deren Ende das fertige Software produkt steht In der urspr nglichen Form werden die Phasen Anforderungsdefini tion Analyse Entwurf Implementierung Test und Inbetr
136. ollen Der Vorteil eines Klassenadapters ist dass er Teile des von der adaptierten Klasse geerbten Ver haltens tiberschreiben kann weil er Unterklasse von ihr ist Zudem wird lediglich ein einzelnes Objekt verwendet Es wird keine Zeigerindirektion ben tigt um zum adap tierten Objekt zu gelangen Im Gegensatz dazu erlaubt ein Objektadapter sowohl mit der anzupassenden Klasse selbst als auch mit allen ihren Unterklassen zusammen zuarbeiten Des Weiteren kann der Adapter neue Funktionalit t allen adaptierten Klassen auf einmal hinzuzuf gen Jedoch k nnen die Methoden der anzupassende Klasse nicht berschrieben werden 6 2 2 Weitere Strukturmuster Details zu den im Folgenden kurz skizzierten weiteren Strukturmustern findet man in GHJV 6 Br cke trennt eine Schnittstelle von ihrer Implementierung und erm glicht beide unabh ngig zu modifizieren Dekorierer erlaubt eine Klasse dynamisch um Funktionalit t zu erweitern bzw ihr Funktionalit t zu entziehen In solchen Anwendungen vermeidet dieses Muster die Erstellung einer sehr komplexen Klassenhierarchie Fassade vereinfacht die Nutzung eines Subsystems durch Bereitstellung einer kom pakten einfach zu verwendenden Schnittstelle Intern leitet die Fassadenklasse Aufrufe an die passenden Klassen des Subsystems weiter Fliegengewicht dient dem Sparen von Speicherplatz bei vielen hnlichen Kleinst objekten Kompositum repr sentiert rekursiv aufgebaute Objektstrukturen wi
137. on troller Quelle Raible Rai07 Tabelle 5 5 Vor und Nachteile des Spring MVC Frameworks e Integration Spring bietet gute Integrationsm glichkeiten mit anderen Fra meworks so dass sich bereits existierende und bew hrte L sungen leicht inte grieren lassen e Aspektorientierte Programmierung Durch dieses Paradigma k nnen ein zelne Aspekte das sind in der Regel anwendungs bergreifende Querschnitts funktionen wie z B Logging von der reinen Anwendungslogik isoliert werden Das Ziel ist es hierdurch die bersichtlichkeit Wartbarkeit und Wiederver wendbarkeit des Programmcodes zu erh hen Diese Eigenschaften geh ren im Vergleich zu anderen Web Frameworks zu den Besonderheiten von Spring MVC Wie der Name bereits andeutet setzt auch Spring MVC auf das MVC Paradigma Tapestry Tapestry Apa07b Ton06 basiert auf einer komponentenbasierten Architektur und weist daher hnliche Merkmale und Besonderheiten wie JSF auf Das Framework un terst tzt neben den blichen Merkmalen wie Seitennavigation Eingabevalidierung Internationalisierung und Sicherheit vor allem persistente d h Request Response Zyklus berdauernde Zust nde der Komponenten Durch die Verwendung von Komponenten erreicht Tapestry hnlich wie JSF einen relativ hohen Abstraktionsgrad bei der Oberfl chenprogrammierung verwen det jedoch f r die Erzeugung des HTML Codes eine eigene Template Engine Mithil fe der Template Engine wird e
138. on Look and Feel spezifischen Widgetklassen nicht ber die ganze Anwen dung verteilen 6 1 ERZEUGUNGSMUSTER 67 a AWTScrollbar SwingScrollbar 4 WidgetFabrik Klient ErzeugeScrollbar ErzeugeFenster Fenster Le gt AWTFenster SwingFenster je q A l SwingWidgetFabri AWTWidgetFabrikL e ve 1 a 1 Scrollbar ErzeugeScrollbar ErzeugeScrollbar I I ErzeugeFenster ErzeugeFenster i A I U U peace Abbildung 6 1 Entwurfsmuster Abstrakte Fabrik am Beispiel Dieses Designproblem kann mit einer abstrakten WidgetFabrik gel st werden die eine Schnittstelle zum Erzeugen jeder grundlegenden Art von Widget deklariert s Abbildung 6 1 Jede Widgetart wird durch eine abstrakte Klasse repr sentiert de ren konkrete Unterklassen den jeweiligen Look and Feel Standard implementieren F r jeden Look and Feel Standard gibt es eine konkrete Unterklasse der abstrakten Widgetfabrik welche f r jede abstrakte Widgetklasse eine Operation zum Erzeu gen eines neuen Widgets implementiert Eine abstrakte Fabrik verlagert folglich die Erzeugung von Objekten auf ihre konkreten Unterklassen Klienten erzeugen neue Widgets ausschlie lich ber die durch die abstrakte WidgetFabrik definierte Schnitt stelle ohne die konkreten Klassen zu kennen die sie benutzen Auf diese Weise blei ben sie unabh ngig vom aktue
139. onen sind Bei geringf gigen nderung werden daher zwei nahezu identische Versionen gespeichert Um ein Repository mit vielen unterschiedlichen Versionen effektiv und platzsparend verwalten zu k nnen ist es wichtig Redundanzen m glichst zu ver meiden Viele Versionsverwaltungssysteme speichern daher blicherweise lediglich die Unterschiede zwischen den einzelnen Versionen die nderungsmenge Um dies zu erreichen wird in vielen Systemen nur die neueste Version vollst ndig gespeichert w hrend alle lteren Versionen als R ckw rts Patch vorliegen ltere Versionen lassen sich dann durch Anwendung der R ckw rts Patches aus der aktuellsten Ver sion rekonstruieren Schnappsch sse Version 1 3 2 a N Delta1 1 N Delta 1 2 Anderungsmenge Ja Abbildung 8 1 Speichermodelle fiir die Versionskontrolle Verschiedene Versionen einer Datei k nnen entweder vollst ndig in Form von Schnappsch ssen oder als nderungsmenge die ausgehend von einer vollst ndigen Version nur die Versions unterschiede protokolliert gespeichert werden Es existiert eine Vielzahl von kommerziellen und nicht kommerziellen Versi onsverwaltungssystemen die aufgrund ihrer individuellen Eigenschaften f r unter schiedliche Anforderungen geeignet sind Eine Gegen berstellung der Eigenschaf ten bekannter Systeme findet sich z B bei Wik07 und Bet07 In einer von For rester durchgef hrten Studie Sch07 die 11 f hrende Versionsverwaltungssystem
140. ons oder Entwurfsphase zur ckgehen muss zu diesem sp ten Zeit punkt teuer erkauft werden e Ein Projekt welches dem Wasserfall Modell folgt liefert in der Regel erst sehr sp t eine lauff hige Version der zu entwickelnden Software an den Kun den aus Stellt dieser fest dass seine Anforderungen nicht vollst ndig oder nicht in der gew nschten Form umgesetzt wurden so ist eine Anpassung in den allermeisten F llen nicht mehr m glich Fine fr he Auslieferung von Teil funktionalit ten erm glicht es fr hzeitig ein Feedback durch den Kunden zu erhalten M gliche Fehlsteuerungen die sich aus einer unklaren oder unvoll st ndigen Erhebung der Anforderungen ergeben k nnen lassen sich auf diese Weise rechtzeitig korrigieren 2 2 Der Rational Unified Process Der Rational Unified Process RUP Rat07 ist ein iteratives Vorgehensmodell zur Softwareentwicklung welches von der Firma Rational Software heute IBM Ratio nal Software auf der Grundlage des Unified Process entwickelt wurde Rat07 Der Unified Process wurde parallel zur Unified Modelling Language UML Oes05 von Ivar Jacobson Grady Booch und James Rumbaugh entwickelt und kann als Me tamodell f r Vorgehensmodelle zur objektorientierten Softwareentwicklung aufge fasst werden Der RUP stellt eine konkrete Implementierung des Unified Process dar und basiert ebenfalls auf der UML als Modellierungssprache Als zentrale Prin zipien der Softwareentwicklung werden die Orientie
141. openArchitecture Ware 42 reference pdf 2007 EBERLING Werner LESSNER Jan Enterprise JavaBeans 8 1 Mnchen u a Carl Hanser Verlag 2007 FAIRLEY Richard Risk Management for Software Projects In IEEE Software 11 1994 Nr 3 S 57 67 FEJES Balasz Test Web Applications with HttpUnit http www javaworld com javaworld jw 04 2004 jw 0419 httpunit html page 1 Abrufdatum 28 03 2008 FOWLER Martin Refactoring Oder wie Sie das Design vorhandener Software verbessern 2 Mnchen Addison Wesley 2005 GAMMA Erich HELM Richard JOHNSON Ralph VLISSIDES John Entwurfsmuster Elemente wiederverwendbarer objektorientierter Softwa re 3 Bonn Addison Wesley 1996 HENNING Michi The Rise and Fall of CORBA In ACM Queue Com ponent Technologies 4 2006 Nr 5 HOLMES James Struts The Complete Reference 2 McGraw Hill Os borne Media 2006 LITERATURVERZEICHNIS 115 HP 08a HPOsb HS06 IBMO7a IBMO7b IFPO8 Int07 JHA 05 JMS06 Jun02 Jun04 JUn08 KBS05 Lam07 HP HP Functional Testing https h10078 www1 hp com cda hpms display main hpms_home jsp zn bto amp cp 1_4011_100__ Abrufdatum 28 03 2008 HP HP LoadRunner https h10078 www1 hp com cda hpms display main hpms_home jsp zn bto amp cp 1_4011_100__ Abrufdatum 28 03 2008 HOLMES James SCHALK Chris JavaServer Faces The Complete Re ference Complete Reference Series 1 McGraw Hill O
142. plication Testing in Java http watij com Abrufdatum 28 03 2008 WELLS Don Extreme Programming A gentle introduction http www extremeprogramming org index html Abrufdatum 19 09 2007 WIKIPEDIA Comparison of revision control software http en wikipedia org wiki Comparison_of_revision_control_software Abrufdatum 17 07 2007 WOLFFGANG Ulrich Modellgetriebene Entwicklung von Webapplikatio nen University of Miinster Department of Information Systems Diplom arbeit 2008 WORLD WIDE WEB CONSORTIUM W3C Web Service Glossa ry February 2004 http www w3 org TR ws gloss Abrufdatum 19 09 2007 WORLD WIDE WEB CONSORTIUM W3C XML Encryption Syntax and Processing December 2002 http www w3 org TR xmlenc core Abrufdatum 19 09 2007 WORLD WIDE WEB CONSORTIUM W3C XML Signature Syntax and Processing February 2002 http www w3 org TR xmldsig core Abrufdatum 19 09 2007 ZEPPENFELD Klaus Objektorientierte Programmiersprachen 1 Spek trum Akademischer Verlag 2004 Zij 5NER Stefan Portlets Portalkomponenten in Java 1 Frankfurt a M Entwickler Press 2006
143. r fen spielen automatisierte Tests eine tragende Rolle Einbeziehung des Kunden Viele Entwickler neigen zu einer phasenorientierten Sicht und Denkweise bei der die Aufnahme der Kundenanforderungen in einer fr hen Phase des Entwicklungs prozesses abgearbeitet und anschlie end endg ltig f r beendet erkl rt wird Kunden verf gen jedoch zu Beginn des Projektes h ufig nur ber ein sehr unscharfes Bild ihrer Anforderungen und Erwartungen welches sich im Verlauf des Projektes durch den Kontakt mit den Entwicklern und das Feedback aus der Betrachtung des entste henden Systems allm hlich konkretisiert und vervollst ndigt Die Anforderungsana lyse ist demnach vielmehr ein wechselseitiger Lernprozess bei dem die Entwickler im Projektverlauf immer mehr ber die Bed rfnisse des Kunden erfahren w hrend dieser seine Vorstellungen ber die M glichkeiten und Restriktionen der Technologie erweitert XP fordert daher eine intensive Einbeziehung des Kunden in den gesam ten Entwicklungsprozess Anforderungen werden dabei nicht vollst ndig zu Beginn des Projektes erhoben sondern iterativ und projektbegleitend mithilfe informeller Story Cards Die gr ten Vorteile verspricht der Einsatz von XP nur dann wenn alle 12 Prak tiken gemeinsam eingesetzt werden Dies stellt jedoch hohe Anforderungen an al le Beteiligten und l sst sich mit den Rahmenbedingungen eines Projektes oftmals nicht vereinen Zum Beispiel ist eine intensive Zusammenarb
144. r Kritik an traditionellen phasenorientierten Vorge hensmodellen Als Hauptkritikpunkte wurden starre und zu restriktive Regelwer ke ausufernde Projektdokumentation mangelnde Orientierung an den Kunden bed rfnissen zu lange Integrations und Releasezyklen sowie eine unzureichende Reaktionsf higkeit auf nderungen der Anforderungen oder technologischen Rah menbedingungen genannt In Anlehnung an die Schwierigkeiten in durch B rokratie gekennzeichneten Organisationen pr gten die Autoren hierf r den Begriff der Soft ware B rokratie Anwendungs Testf lle f lle Neue Anwendungsf lle Projekt Geschwindigkeit Fehler Anforderungen Architektur Prue Sak Prototyp etapher Release z ersion Akzeptanz i Lech Architectural Planung Iteration Bile Spike unklare zuverlassige Annahme Annahmen und Annahmen und l Ee Sch tzungen Sch tzungen N chste Iteration Prototyp Kleine Spike Releases Abbildung 2 3 Der Extreme Programming Prozess nach Wel07 12 KAPITEL 2 VORGEHENSMODELLE Extreme Programming basiert auf den vier grundlegenden Werten Kommunika tion Einfachheit Feedback und Mut Ihre Konkretisierung finden sie in 15 Prinzipi en welche aus diesen Werten abgeleitet sind Zur Umsetzung der Werte und Prinzi Dien stehen zw lf Praktiken zur Verf gung die jeweils fiir sich betrachtet sinnvolle und in der Praxis bew h
145. r die korrekte Verwendung eines Informationsobjek tes relevant Wenngleich im Kontext eines bestimmten Informationssystems implizit gelten kann dass es sich bei einem Attribut mit dem Namen Preis stets um einen Bruttopreis handelt so kann das Vorhandensein dieser impliziten Bedeutung Se mantik in einem anderen Informationssystem nicht vorausgesetzt werden Eine In teraktion zwischen zwei Informationssystemen wird demnach nur dann reibungslos funktionieren wenn beide f r die auszutauschenden Informationsobjekte die gleiche implizite Semantik verwenden Ist dies nicht gegeben so spricht man von einer se mantischen Heterogenit t Semantische Heterogenit ten lassen sich umgehen indem die auszutauschenden Informationsobjekte mit zus tzlicher Semantik beispielswei se einer Unterscheidung zwischen Bruttopreis und Nettopreis angereichert oder auf ein vereinheitlichtes semantisches Referenzmodell abgebildet werden 9 2 Motivationen f r Integrationsma nahmen Vorhandene Heterogenit ten sind nicht in jedem Fall kritisch wachsen sich aber sp testens dann zu einem Problem aus wenn die Systeme aufgrund betrieblicher Er fordernisse miteinander interagieren bzw Informationen austauschen m ssen Dies 9 2 MOTIVATIONEN FUR INTEGRATIONSMASSNAHMEN 91 ist zum Beispiel dann der Fall wenn zwei Systeme Aktivit ten in einem inner betrieblichen oder zwischenbetrieblichen Gesch ftsprozess unterst tzen welche in einer Kunde Lieferant Beziehung s
146. r ist Probleme sind zu erwarten wenn Anwendungen zu integrieren sind die in einer Programmiersprache vorliegen f r die keine JMS Implementierung verf gbar ist Eine Integration kann in diesem Fall nur mit erh htem Implementierungsaufwand oder unter Einschr nkungen vorgenommen werden Sollen Anwendungen ber Organisationsgrenzen hinweg angebunden oder die Systeme geografisch verteilter Einheiten einer einzelnen Organisation integriert werden so findet die Kommunikation der Anwendungen zumeist ber eine Firewall oder einen Proxy statt Hierbei ist zu beachten dass der JMS Dienst standardm ig den Port 7676 nutzt weshalb JMS Anfragen h ufig durch die Firewall blockiert wer den L sen l sst sich dieses Problem indem der betreffende Port explizit f r die JMS Kommunikation ge ffnet wird Wenn dies nicht erw nscht ist so k nnen JMS Nachrichten alternativ in spezielle HTTP Pakete verpackt HTTP Tunneling und auf diese Weise ber Firewallgrenzen hinweg versandt werden 9 4 INTEGRATIONSEBENEN 103 Service Orientierte Architekturen und Web Services Eine nicht nur plattformunabh ngige sondern auch programmiersprachen und pro tokollunabh ngige Alternative stellen Web Services dar Ein Web Service l sst sich als Komponente auffassen die ihre Funktionalit t ber eine ffentlich zug ngliche Schnittstelle anbietet und ber offene im Internet verwendete Protokolle zugreif bar ist Mithilfe von Web Services kann eine Service Ori
147. rachtung der Unternehmensorganisation geht der Blick f r Schnittstellenprobleme zwischen den Informationssystemen der einzelnen Organisationseinheiten schnell verloren Bei einer prozessorientierten Betrachtung werden die Anforderungen an die Integration der betrieblichen Informationssyste minfrastruktur unmittelbar sichtbar Abweichungen zwischen der Ist Situation und dem gew nschten Soll Zustand lassen sich somit leicht feststellen Auch die Ver schmelzung zweier Unternehmen mit jeweils eigener Informationssysteminfrastruk tur im Rahmen von Unternehmenszusammenschl ssen oder bernahmen kann In tegrationsma nahmen erforderlich machen In den folgenden Abschnitten sollen die wesentlichen Konzepte und Technologien der EAI vorgestellt werden Ausgehend von einer Betrachtung verschiedener Topo logien f r den Aufbau einer Integrationsinfrastruktur werden mit der Datenebene der Funktionsebene und der Ebene der Benutzerschnittstelle drei Ansatzpunkte f r die Durchf hrung einer Anwendungsintegration vorgestellt Nachdem kurz auf die Eigenschaften sowie die Vor und Nachteile der einzelnen Integrationsans tze einge gangen wurde werden konkrete Technologien zur Umsetzung einer entsprechenden Integration vorgestellt und gegeneinander abgew gt 92 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION 9 3 EAI Architekturkonzepte Die Auswahl einer geeigneten Architektur fiir die Gestaltung einer Integrations infrastruktur ist von tragender Bedeutung
148. ration Abbildung 6 3 Klassen Adapter AdaptierteKlasse SpezifischeOperation Adaptiertes Objekt Adapte Operation H adaptiertesObjekt SpezifischeOperation Abbildung 6 4 Objekt Adapter Das Adaptermuster kann verwendet werden wenn 1 eine existierende Klasse benutzt werden soll deren Schnittstelle nicht der ben tigten Schnittstelle entspricht 2 eine wiederverwendbare Klasse erstellt werden muss die mit unabh ngigen oder nicht vorhersehbaren Klassen zusammenarbeiten soll welche nicht notwendigerweise ber kompatible Schnittstellen verf gen und 3 nur f r Objektadapter verschie dene existierende Unterklassen benutzt werden m ssen und es unpraktisch ist die Schnittstellen jeder einzelnen Unterklassen durch Ableiten anzupassen Ein Klassenadapter verwendet Mehrfachvererbung um eine Schnittstelle an ei ne andere anzupassen vgl Abb 6 3 und ist daher in Sprachen wie Java die nur 6 2 STRUKTURMUSTER ral Einfachverbung bieten nicht verwendbar Ein Objektadapter verwendet Delegation vgl Abb 6 4 In beiden Fallen ruft der Klient die Operationen von Adapterobjek ten auf die sich auf Methoden der adaptierten Klasse abstiitzen Ein Klassenadapter passt die zu adaptierende Klasse an genau eine konkrete Zielklasse an Daraus ergibt sich der Nachteil dass ein Klassenadapter nicht funk tioniert wenn wir eine Klasse und all ihre Unterklassen anpassen w
149. ration von Web Services Bei Java EE geschieht dies ber zus tzliche Spezifikationen NEI verf gt ber native APIs zur Web Service Programmierung Datenhaltung Java EE beinhaltet die Java Persistence API JPA die ber leichtgewichtige Entities ein O R Mapping erm glicht JPA bietet zu dem Diente f r Sicherheit Fehlertoleranz Skalierbarkeit und den Zugriff auf verschiedenste Typen von Datenquellen Auch ADO NET erm glicht es ei ner NET Anwendung auf unterschiedliche Arten von Datenquellen zuzugrei fen allerdings unterst tzt es bisher kein automatisches O R Mapping F r zuk nftige Versionen von ADO NET ist auch ein automatisches Mapping ge plant Es gibt allerdings auch f r NET O R Mapper wie z B NHibernate Mid07 Hiermit l sst sich dann eine hnlich komfortable Anbindung der Da tenhaltung wie bei Java EE erreichen Plattform e Laufzeitumgebung Java EE basiert auf der Java Virtual Maschine JVM die den durch einen Compiler erzeugten Bytecode zur Laufzeit interpretiert bzw Just in Time zur Ausf hrungszeit in Maschinencode bersetzt Auch NET verf gt analog ber eine virtuelle Maschine CLR die pr compilierten Zwischencode MSIL Code interpretiert bzw Just in Time compiliert Die Ausf hrung ber einen Interpreter bzw Just in Time Compilierung erm g lichen es gewisse Aufgaben wie die Code Verifikation das Sicherheitsmana gement und die Speicherbereinigung zu automatisieren haben jedoch einen
150. republik Deutschland vom 9 September 1965 in der jeweils geltenden Fassung zul ssig Sie ist in der Regel verg tungspflichtig Zuwiderhandlungen unterliegen den Strafbe stimmungen des Urheberrechtsgesetzes Copyright F rderkreis der Angewandten Informatik an der Westf lischen Wilhelms Universit t M nster e V Einsteinstra e 62 D 48149 M nster 2009 Printed in Germany Die Wiedergabe von Gebrauchsnamen Handelsnamen Warenbezeichnungen usw in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme dass solche Namen im Sinne der Warenzeichen und Markenschutz Gesetzgebung als frei zu betrachten w ren und daher von jedermann benutzt werden d rften Text und Abbildungen wurden mit gr ter Sorgfalt erarbeitet Verlag und Autor k nnen jedoch f r eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung bernehmen Vorwort Die Entwicklung leistungsf higer Software ist ein wesentlicher Kern von Informa tionstechnologie Zahlreiche Unternehmen entwickeln Software entweder als Soft wareanbieter im Rahmen eines eigenst ndigen Gesch ftsmodells oder als Nutzer selbstentwickelter Anwendungen zur Unterst tzung der Gesch ftsprozesse Auch im IHK Bezirk Nord Westfalen gibt es sehr viele Firmen die Software pro duzieren allein rund 1500 Anbieter Sie st rken die wirtschaftliche Leistungskraft der Region Und sie sorgen nat rlich in hohem Ma
151. roduktkonfigurationen aus dem gleichen Grund implementiert man abstrakte Fa briken am besten als Singleton s u GHJV96 Um verschiedene Look and Feel Objekte zu erzeugen sollten Klienten unterschiedliche konkrete Fabriken haben Ein weiterer Vorteil ist die einfache Konsistenzsicherung unter den Produkten um zu gew hrleisten dass nur Objekte einer Familie zu einer Zeit verwendet werden Als Nachteil von abstrakten Fabriken ist deren Erweiterbarkeit bzw die Un terst tzung neuer Produkte zu nennen Dies liegt daran dass die Schnittstelle der Fabrik die Menge von generierbaren Produkten festlegt Die Unterst tzung neuer Arten von Produkten erfordert es diese Schnittstelle zu erweitern was dazu f hrt die abstrakte Fabrik Klasse und all ihre Unterklassen zu ver ndern 6 1 2 Weitere Erzeugungsmuster Details zu den im Folgenden kurz skizzierten weiteren Erzeugungsmustern findet man in GHJV9B6 Fabrikmethode wird h ufig in so genannten Frameworks d h in objektorientier ten Klassenbibliotheken eingesetzt Ein Framework stellt oft sehr allgemeine Klassen zur Verf gung die bei seiner Nutzung durch Anwendungs bezogene Klassen erg nzt werden m ssen Problem ist dass bei der Framework Erstellung diese Klassen nicht bekannt sind und das Framework dennoch manchmal Ob jekte dieser Klassen erzeugen muss Letzteres wird von dem Fabrikmethode Muster dadurch erm glicht dass die betreffende Klasse des Frameworks ei ne abstrakte Met
152. rte Schnittstelle zum Hub geschaffen werden Verglichen mit der Punkt zu Punkt Integration entsteht bei der Verwendung einer Hub and Spokes Topologie ein hoher initialer Aufwand f r die Einrichtung des Hubs w hrend die Anbindung von Systemen an den Hub mit vergleichsweise geringen Kosten verbun den ist Ein Nachteil dieser Topologie entsteht dadurch dass jegliche Kommunika tion zwischen den Systemen ber den Hub l uft Dessen Leistungsf higkeit k nnte sich zum Performanz Engpass f r die gesamte Integrationsinfrastruktur entwickeln Bei einem Ausfall des Hubs w re gar jegliche Kommunikation zwischen den be teiligten Systemen unterbrochen Die geschilderten Probleme lassen sich durch den Aufbau von Rechnerverb nden Load Balancing Cluster Hochverf gbarkeitscluster und redundante Bereitstellung der Hub Funktionalit ten umgehen 9 3 3 Bus Integration Ausgehend von der Kritik an der Hub and Spokes Topologie macht sich die Bus Integration vgl Abbildung 9 3 einen verteilten Ansatz zu nutzen der die geschil derten Performanz und Verf gbarkeitsprobleme vermeidet Bei der Bus Integration werden die Integrationsfunktionalit ten verteilt durch die angebundenen Einheiten bereitgestellt Aufgrund des Fehlens einer zentralen Integrationskomponente ist eine 94 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION flexible Anpassung an Performanz und Verfiigbarkeitsanforderungen m glich Wie auch bei der Hub and Spokes Topologie ist zur Integra
153. rte Vorgehensweisen der Softwareentwicklung darstellen Durch kombinierten Einsatz dieser Best Practises soll die Entwicklung qualitativ hochwertiger Software m glich werden ohne gleichzeitig die Flexibilit t aufzugeben auf neue Anforderungen M glichkeiten oder Restriktionen angemessen reagieren zu k nnen Das Zusammenspiel der verschiedenen XP Praktiken im Entwicklungspro zess wird durch Abbildung 2 3 veranschaulicht Vier der wichtigsten XP Praktiken sollen nun exemplarisch vorgestellt werden Testgetriebene Entwicklung Um eine hohe Qualit t der Software sicherzustellen soll in einem XP Projekt kein St ck Programmcode ungetestet an den Kunden ausgeliefert werden Gleicherma en wird angestrebt fortw hrend Integrationen durchzuf hren und in kurzen Zeitabst n den lauff hige Versionen an den Kunden auszuliefern Auf diese Weise sollen Inte grationsprobleme fr hzeitig erkannt und regelm ig ein Feedback von Seiten des Kunden eingeholt werden Um beide Ziele auf wirtschaftliche Weise zu erreichen ist einerseits eine m glichst vollst ndige Testabdeckung und andererseits ein hoher Au tomatisierungsgrad der Tests erforderlich Die Testf lle werden stets auf der Grund lage der Anforderungen vor der eigentlichen Implementierung der zu testenden Pro grammteile erstellt So l sst sich gew hrleisten dass Testf lle nicht im Hinblick auf eine problemlose Testbarkeit bereits implementierter Funktionalit ten gestaltet wer den Zu Begi
154. rung an Anwendungsf llen use cases als Ausgangspunkt f r die Entwicklung die Architekturzentrierung der Pla nung sowie ein inkrementelles und iteratives Vorgehen in den Mittelpunkt gestellt Die Orientierung an den Anwendungsf llen bzw Gesch ftsprozessen bewirkt dass sich die Anwendungsf lle wie ein roter Faden durch die Entwicklung ziehen und je der Entwicklungsschritt sich letztlich auf einen Anwendungsfall zur ckf hren l sst Features bei denen sich die Entwickler selbst verwirklicht haben die aber von den Benutzern nicht verlangt wurden werden dadurch verhindert Die Architekturzen trierung verlangt dass bereits in einem fr hen Stadium die Grobarchitektur z B 4 Schichten Webapplikation basierend auf Java EE und einer r elationalen Daten bank auf der Grundlage einer kleinen Auswahl der wichtigsten Gesch ftsprozesse festgelegt wird so dass die restlichen Anwendungsf lle auf der Grundlage dieser Gro barchitektur leichter formuliert werden k nnen und Anwendungsfalle die mit dieser Grobarchitektur nicht vertr glich sind von Anfang an anders formuliert werden Die iterative inkrementelle Entwicklung verlangt dass zun chst ein Kernsystem basie 2 2 DER RATIONAL UNIFIED PROCESS 9 rend auf wenigen ausgew hlten Gesch ftsprozessen erstellt wird dass dann in jeder Iteration um weitere Funktionalit t erg nzt wird Diese iterative Vorgehen ist ganz entscheidend f r die Verminderung der Risiken bei der Softwareentwicklun
155. s auch zun chst nicht vollst ndig passende Klassen genutzt werden k nnen Dieser Aspekt wird insbeson dere bei dem Adpater Muster in Unterkapitel 6 besonders deutlich Neben der Kapselung und der Vererbung kommen inzwischen aber noch einige weitere Aspekte hinzu die f r die objektorientierte Softwareentwicklung sprechen Zun chst ist hier die Unified Modeling Language UML zu nennen Erfreulicherweise ist es der objektorientierten Community gelungen sich auf eine allgemein akzeptier te standardisierte Modellierungssprache die UML zu einigen Als Folge hiervon haben sich auch die Hersteller von Software Engineering Tools an dieser einheitli chen Notation orientiert so dass inzwischen eine vorher nicht gekannte Vielfalt von weitgehend kompatiblen Werkzeugen bereit steht die die objektorientierte Softwa reentwicklung weiter vereinfachen Weiterhin sind objektorientierte Programmiersprachen wie Java und C mit einem umfassenden Satz an vordefinierten Klassen und Frameworks f r nahezu al le Aspekte der Softwareentwicklung ausgestattet die die Anwendungsentwicklung zus tzlich enorm erleichtern Im Falle von Java reicht dies von Ans tzen zur Gestal tung der Pr sentationsschicht von Webanwendungen wie Servlets JSP Struts und JavaServer Faces ber Konzepte zur Realisierung der Gesch ftslogik und Datenhal tung von Informationssystemen wie Enterprise JavaBeans Spring und Hibernate bis hin zu Frameworks f r mobile Endger te Demge
156. sansatz vertreten komponentenorien tierte Middleware Plattformen wie die Common Object Request Broker Architek ture CORBA LP98 Hen06 das von Microsoft entwickelte Distributed Compo nent Object Model DCOM RB98 oder die im Rahmen der Java EE ehemals J2EE spezifizierten Enterprise JavaBeans EJB BMH06 Sun07c Hier werden die in einer zu integrierenden Anwendung enthaltenen Funktionen als Methoden in verteilten Objekten zug nglich gemacht Objekte verbergen gem dem Paradigma der Objektorientierten Programmierung ihre internen Strukturen und Eigenschaften wie auch die meisten Details bez glich Plattform Programmiersprachen und Imple mentierung hinter einer ffentlich zug nglichen Schnittstelle Anwendung A Anwendung B IDL Stub IDL Skeleton j Request Object Broker Abbildung 9 7 Entfernter Methodenaufruf ber einen Objekt Request Broker Durch einen so genannten Object Broker CORBA DCOM bzw RMI EJB wird ein Kommunikationskanal etabliert der es erm glicht einen entfernten Methodenaufruf gegen ber einem Klienten wie einen lokalen Aufruf erscheinen zu lassen Er stellt somit eine protokollunabh ngige Implementierung eines Kommu nikationskanals zwischen verteilten Objekten zur Verf gung Ein Entwickler kann somit auf entfernte Objekte zugreifen ohne auf Einzelheiten der verwendeten Hard wareplattformen oder Netzwerkprotokolle R cksicht nehmen zu m ssen Die
157. sborne Media 2006 IBM Rational ClearCase Change Management Solution http www 306 ibm com software awdtools changemgmt Abrufdatum 17 07 2007 IBM Rational Suite http www 306 ibm com software awdtools suite Abrufdatum 17 07 2007 IFPUG International Function Point User Group http www ifpug org Abrufdatum 28 03 2008 INTERFACE21 Spring Framework http www springframework org Abrufdatum 17 07 2007 JOHNSON Rod HOELLER Juergen ARENDSEN Alef RISBERG Tho mas KOPYLENKO Dmitriy Professional Java Development with the Spring Framework 1 Birmingham Wrox Press Ltd 2005 JURIC Matjaz MATHEW Benny SARANG Poornachandra Business Process Execution Language for Web Services 2 Packt Publishing 2006 JUNGMAYR Stefan Design for Testability In Proceedings of CON QUEST 2002 2002 S 57 64 JUNGMAYR Stefan Improving testability of object oriented systems dis sertation de 2004 ISBN 3 89825 781 9 JUNIT ORG JUnit Testing Ressources for Extreme Programming http www junit org Abrufdatum 28 03 2008 KRAFZIG Dirk BANKE Karl SLAMA Dirk Enterprise SOA Service Oriented Architecture Best Practices 1 New Jersey Prentice Hall 2005 LAMB David A Software Engineering Archives http www cs queensu ca Software Engineering Abrufdatum 17 07 2007 116 LHO5 Lin00 Lin05 LMK04 Loh03 LP98 LRO6 MEO0 Mic07a Mic07b Mid07
158. schiedenen Ebenen der Interaktion zwischen zwei Informations systemen vollziehen Bestehen zwischen diesen wesentliche Unterschiede in der tech nischen Repr sentation Speicherung und Bereitstellung der verwalteten Informatio nen so spricht man von einer technischen Heterogenit t Diese kann zum Beispiel durch zueinander inkompatible Hardwareplattformen Datenbankmanagementsyste me Kommunikationsmechanismen oder Programmiersprachen entstehen F r eine einfache berwindung derartiger Integrationsprobleme ist am Markt f r Integra tionsprodukte eine Vielzahl von Werkzeugen verf gbar Wesentlich schwieriger zu handhaben sind syntaktische Heterogenit ten Diese betreffen die Datenmodelle wel che der Speicherung von Informationen in einer Anwendung zugrunde liegen Unter scheiden sich die Datenmodelle zweier Informationssysteme deutlich voneinander so ist ein Informationsaustausch nur dann m glich wenn die zu bertragenden Infor mationen vom Datenmodell des Quellsystems auf das Datenmodell des Zielsystems oder auf ein zentralisiertes Datenmodell abgebildet werden kann Au erdem geht die Bedeutung eines Informationsobjektes manchmal nicht eindeutig aus dem Da tenmodell hervor Als Beispiel l sst sich ein Attribut Preis nennen Ohne weitere Anreicherung dieses Attributes mit zus tzlicher Information ist zum Beispiel nicht ersichtlich ob es sich um einen Bruttopreis oder einen Nettopreis handelt Dieser Bedeutungsinhalt ist jedoch f
159. siko Uberwindung __ Risiko Uberwachung Risiko Techniken Checklisten Vergleich mit Erfahrung Zerlegung Leistungsmodelle Kostenmodelle Analyse der Qualitatsanforderungen Risikofaktoren bestimmen Risikowirkung bestimmen Reduktion zusammengesetzer Risiken Kaufen von Informationen Risikovermeidung verminderung Risikoelement Planung Prototypen Simulationen Leistungstests Analysen Mitarbeiter Top10 Risiken Meilensteine Risiko Neueinsch tzung korrigierende Aktionen Abbildung 3 1 Die sechs Schritte des Risikomanagements 3 1 denen jeweils mehrere Techniken zugeordnet werden k nnen Fallstudien zum Risiko Management finden sich in z B in Boe91 Boe89 Fai94 3 2 1 Risiko Identifikation Checklisten sind ein hilfreiches Instrument um im Rahmen der Risikoidentifikati on die projektspezifischen Risiken zu finden Tabelle 3 4 zeigt die zehn wichtigsten Quellen f r Risiken in Software Projekten und die entsprechenden Techniken mit denen man die Risiken vermeidet oder berwindet 3 2 RISIKO MANAGEMENT 21 3 2 2 Risiko Analyse Bei der Risiko Analyse werden die Schadenswahrscheinlichkeit und das Schadens ausma f r jedes identifizierte Risikoelement und f r zusammengesetzte Risiken ab gesch tzt Eine quantitative Bewertung eines Risikos erfolgt durch den so genannten Risiko Faktor der sich aus dem Produkt aus dem erwarteten Verlust bzw Schaden und der Schadenswahrscheinlichkeit
160. ss Box Testen Beim Black Box Testen geht man von der Spezifika tion aus wie sie z B in Form des Pflichtenhefts oder der Schnittstellenbeschreibung von Klassen vorliegt und versucht alle hieraus ableitbaren Nutzungsszenarien des betrachteten Softwarebausteins abzuleiten und durch je einen Testfall berpr fen 7 4 GLASS BOX TESTEN 81 Diesen Ansatz bezeichnet man als Black Box Testen da man die Implementierung des Bausteins hierbei nicht ber cksichtigt Er funktioniert h ufig gut wenn man sich auf das normale Verhalten eines Systems konzentiert Fehler in Sonderf llen insbson dere solchen die sich nicht aus der Spezifikation ablesen lassen sondern durch die bei der Implementierung verwendeten Datenstrukturen und Algorithmen entstehen lassen sich mit diesem Ansatz nicht besonders gut aufsp ren Ein Vorteil von Black Box Testen ist dass es sich nicht nur f r einzelne Klassen und Module sondern auch f r Teilsysteme und das Gesamtsystem einsetzen l sst F r eine Testfall getriebene Softwareentwicklung wie sie bei Extreme Programming vgl Abschnitt 2 3 ver wendet wird l sst sich ausschlie lich mit Black Box Testen realisieren Ein interessantes Tool zur automatischen Erzeugung von Black Box Testf llen f r u a Java ist QuickCheck Sou08 Dieses Werkzeug erzeugt mit Hilfe eines Zufallsgenerators z B 100 Testf lle mit steigender Komplexit t die anhand einer vom Tester vorgegebenen Methode einer so genannten property a
161. st Die Einsatzpotentiale dieses Ansatzes sind jedoch auf Integrationsszenarien beschr nkt in welchen die zu integrierenden Anwendungen nicht auf unterschiedliche Rechner verteilt sind In einem verteilten Umfeld sind Mechanismen erforderlich die es erm glichen Methoden einer entfernten Anwendung aufzurufen F r diese Aufgabe bieten sich Dienste wie Remote Procedure Call RPC oder der aus dem Java Umfeld bekann te Mechanismus der Remote Method Invocation RMI an Der RPC Mechanismus f hrt eine zus tzliche Ebene der Abstraktion zwischen dem Klienten und dem Server ein der die Implementierungen der beiden Systeme voneinander entkoppelt und die erforderliche Netzwerkkommunikation vermittelt ohne dass diese durch den Ent wickler explizit implementiert werden muss Die Schnittstelle einer Funktion oder Methode wird mithilfe einer Schnittstellenbeschreibungssprache Interface Definiti on Language IDL spezifiziert Auf der Grundlage dieser abstrakten Beschreibung generiert ein IDL Compiler einen Client Stub und einen Server Stub Der Client Stub fungiert als lokaler Stellvertreter der durch den Server bereitgestellten Metho de F r den Klienten gestaltet sich der Aufruf der entfernten Methode als lokaler Prozeduraufruf Die technischen Einzelheiten der Kommunikation wie der Aufbau einer Kommunikationsverbindung ber den TCP IP Protokollstack oder die Erzeu gung von Nachrichten werden durch den Client Stub bzw in umgekehrter Richtung durch d
162. sverwaltung Authentifizierung und Autorisierung Caching sowie h ufig ver wendete Steuerelemente f r Web Oberfl chen wie Schaltfl chen Textfelder und Ta bellen Dar ber hinaus basiert das Framework auf der Common Language Runtime daher k nnen ASP NET Seiten in jeder NET Sprache erstellt werden Das Framework unterst tzt f r die Erzeugung von dynamischen Webseiten das ASPX Dateiformat Typischer Weise enth lt eine ASPX Datei statischen HTML Code in den ber bestimmte Tags dynamische Inhalte eingebunden werden k nnen Der Programmcode f r die dynamischen Inhalte wird nach dem so genannten Code Behind Modell in einer separaten Datei gespeichert Durch diese Form der Trennung von Layout und Programmlogik ist es m glich ein ereignisbasiertes Programmier modell umzusetzen Der dynamische Inhalt einer Webseite muss damit nicht mehr wie z B bei der veralteten ASP Technologie sequenziell mit der Webseite selbst erzeugt werden sondern wird durch die Reaktion auf Benutzereingaben im Code Behind manipuliert Dieser Ansatz ist deutlich intuitiver und erm glicht es Web Oberfl chen hnlich wie Desktop Anwendungen zu programmieren Das ASP NET Framework unterst tzt zudem ein Komponentenmodell welches es erm glicht Web seiten aus mehreren Ul Komponenten den sogenannten Web Controls oder Steuer elementen zusammenzusetzen Ein Web Control beh lt seinen Zustand ber mehre DU KAPITEL 5 SOFTWAREARCHITEKTUREN Java EE NET Web C
163. t Im folgenden Abschnitt wird zun chst das Client Server Modell dargestellt wel ches eine wichtige Grundlage f r die Konzeption von Schichtenarchitekturen dar stellt Darauf aufbauend werden die grundlegenden Eigenschaften von Schichten architekturen beschrieben Abschlie end werden zwei h ufig vorkommende Typen von Schichtenarchitekturen vorgestellt die 3 Schichtenarchitektur und die 4 Schich tenarchitektur 5 1 1 Das Client Server Modell Das Client Server Modell beschreibt einen Ansatz der die Elemente eines Softwa resystem in Clients und Server unterteilt Wie in Abbildung 5 1 dargestellt nimmt ein Client zur Erf llung seiner Aufgaben Dienste eines Servers in Anspruch in dem er eine Anfrage schickt Der Server nimmt die Anfrage entgegen und schickt 39 40 KAPITEL 5 SOFTWAREARCHITEKTUREN das Ergebnis der Anfrage an den Client zur ck Von besonderer Bedeutung ist das Client Server Modell bei der Umsetzung von verteilten Systemen Bei einer Client Server Architektur k nnen Clients und Server auf unterschiedlichen Rechnern lau fen die ber ein geeignetes Netzwerk mit einander verbunden sind Eine Client Server Architektur erh ht also in der Regel die Flexibilit t und Skalierbarkeit eines Systems 1 Aufruf Server 2 Verarbeitung 3 Ergebnis Abbildung 5 1 Das Client Server Modell Abbildung 5 1 zeigt die einfachste Form des Client Server Modells bestehend aus einem Client und einem Server
164. t extends gt gt Buch verloren Abbildung 4 7 Beispiel Anwendungsfall Diagramm Ein Anwendungsfall beschreibt meist nur den Normalfall einer Interaktion zwi schen Akteur und System Die Behandlung von Fehlern und Sonderfallen wird zur Vereinfachung des Anwendungsfalls oft in eigene Anwendungsfalle ausgelagert die mit dem Normallfall durch eine mit extends beschriftete gestrichelte Linie verbun den sind vgl Abb 4 7 Enthalten mehrere Anwendungsf lle einen gleichen Anteil so kann man diesen in einen eigenen Anwendungsfall herausziehen der dann im Diagramm ber eine mit inncludes beschriftete gestrichelte Linie an die Ausgangsanwendungsf lle an gebunden wird vgl Abb 4 7 Anwendungsfalldiagramme beschreiben ein Softwaresystem offensichtlich auf ei nem sehr groben Niveau Mindestens so wichtig wie das Diagramm selber ist daher die textuelle Beschreibung jedes Anwendungsfalls die spezifiziert was bei dem An wendungsfall passieren soll und welche Bedingungen vor und nach seiner Ausf hrung gelten m ssen Der Ablauf eines Anwendungsfalls wird oft durch ein Verhaltensdiagramm wie z B ein Sequenzdiagramm s u genauer beschrieben 4 2 UNIFIED MODELING LANGUAGE 39 4 2 4 Sequenzdiagramme Ein Sequenzdiagramm dient dazu zu spezifizieren in welcher Weise Objekte intera gieren um eine vorgegebene Aufgabe zu erfiillen Jedes der beteiligten Objekte wird hierbei durch eine vertikale Linie repr sentiert die an den Ste
165. t so eine einheitliche Abstraktion von mehreren unterschiedlichen Schnittstellen Die Schnittstelle des Adapters wird auf Basis der Schnittstelle des adaptierten Ob jekts realisiert ZeichenWerkzeug TextAnzeige GibAusmasse GrafischesObjekt BegrenzungsRahmen ErzeugeManipulator IN return text GibAusmasse text we BegrenzungsRahmen return new TextManipulator ErzeugeManipulator BegrenzungsRahmen ErzeugeManipulator Abbildung 6 2 Entwurfsmuster Adapter am Beispiel Betrachten wir als Beispiel ein Zeichenwerkzeug mit dem Linien Polygone Krei se Texte usw gezeichnet und zu Bildern und Diagrammen arrangiert werden k nnen vgl Abbildung 6 2 Jedes dieser grafischen Objekte kann editiert werden und einen passenden rechteckigen Begrezungsrahmen ermitteln Der Editor definiert hierzu f r jedes grafische Objekt eine konkrete Unterklasse z B eine Linien Klasse f r Linien eine Polygon Klasse f r Polygone usw die von einer abstrakten Klasse Grafisches Objekt abgeleitet werden Diese Oberklasse stellt eine einheitliche Schnittstelle f r die konkreten grafischen Objekte bereit Elementare geometrische Objekte k nnen sehr einfach implementiert werden da ihre Zeichen und Editierm glichkeiten be schr nkt sind Nehmen wir an dass eine vorhandene Klasse TextAnzeige bereits die Begrenzung eines Texts ermitteln kann und dass wir diese nutz
166. tehen Um Informationen entsprechend der Ge sch ftsprozesslogik ber die Systemgrenze hinweg von einer in die andere Akti vit t zu bertragen wird eine technische Schnittstelle ben tigt die eine Interak tion zwischen den jeweiligen Systemen erm glicht Ist dies nicht oder nur unzurei chend gew hrleistet so kommt es innerhalb des Prozesses unweigerlich zu einem Medienbruch Die fehlende oder mangelhafte Integration der Systeme zwingt zu ei ner Konvertierung der Informationen auf ein alternatives Medium welches in beiden Aktivit ten verarbeitet werden kann Der Austausch von Informationen per Email oder auf gedrucktem Papier sind nur zwei Beispiele f r eine derartige Situation Die Konvertierung und anschlie ende R ckkonvertierung der Informationen z B durch Erzeugung einer Excel Tabelle im Quellsystem welche auf elektronischem Wege an das Zielsystem bertragen und dort in die Datenbank eingelesen wird kostet Zeit und Geld Im Rahmen der Konvertierung k nnen dar ber hinaus Informationen ver loren gehen oder Fehler auftreten Medienbr che schr nken demnach nicht nur die Effizienz sondern auch die Effektivit t von Gesch ftsprozessen ein Den Ansto f r konkrete Integrationsprojekte k nnen vielerlei Ursachen geben Ein Beispiel ist die Optimierung oder Reorganisationen von Gesch ftsprozessen Bei einer an aufbauor ganisatorischen Gesichtspunkten wie Abteilungen Stellen Kompetenzen und Ver antwortlichkeiten orientierten Bet
167. teme dar ber hinaus einfach nutzbare Funktionalit ten f r die Umwandlung und Zusam menf hrung von Daten Der Hauptvorteil einer Integration auf Datenebene besteht darin dass sie zur In tegration einer Anwendung auch dann herangezogen werden kann wenn diese ber keinerlei offen gelegte Schnittstellen verf gt und eine Modifikation des Quellcodes nicht m glich ist Dar ber hinaus bietet ein breit gef chertes Angebot an ausge reiften Werkzeugen dem Entwickler ein hohes Ma an Unterst tzung Nachteilig ist jedoch dass eine Datenintegration keinen Zugriff auf die Funktionalit t eines Sys tems erm glicht Daher ist dieser Integrationsansatz nur dann zu empfehlen wenn ausschlie lich ein Zugriff auf die Daten einer Anwendung erforderlich ist Soll hinge gen die Anwendungslogik eines Systems genutzt werden so ist eine Integration auf Funktionsebene der Datenintegration vorzuziehen 9 4 2 Integration auf Funktionsebene Bei der Funktionsintegration wird die Programmfunktionalit t system bergreifend genutzt d h die integrierten Systeme k nnen gegenseitig auf ihre Anwendungslogik zugreifen vgl Abbbilung 9 5 Integrierte Pr sentation Integrationslogik Integrations plattform A Anwendung A Anwendung B Datenspeicher A Datenspeicher B Abbildung 9 5 Integration auf Funktionsebene Sie stellt das weitestgehende Integrationskonzept dar und umfasst die M glich keiten der
168. tik sind deutliche Defizite dieses Integrationsansatzes hin sichtlich Performanz und Skalierbarkeit Hinzu kommt die Problematik dass sich die Benutzerschnittstelle einer Anwendung verglichen mit der Anwendungslogik oder ih ren Datenstrukturen relativ h ufig ndert Bei der Verwendung von Screen Scraping Werkzeugen bewirkt jedoch oftmals schon die Verschiebung eines Anzeigeelementes um wenige Millimeter dass es nicht mehr zuverl ssig erkannt wird Dar ber hinaus werden in den einzelnen Anwendungen bestehende Redundanzen auf Daten oder Funktionsebene nicht beseitigt Kapitel 10 Modell getriebene Software Entwicklung Mit dem Siegeszug der Objektorientierung hat sich auch die hierfiir entwickelte ver einheitlichte Modellierungsnotation die Unified Modeling Language UML durch gesetzt vgl Abschnitt 4 2 Mit dem Vorliegen der Modelle entstand dann die Idee Teile eines objektorientierten Softwaresystems nicht von Hand zu erstellen sondern automatisch aus den Modellen zu generieren Die wohl beliebtesten Tools fiir die Modell getriebene Software Entwicklung sind androMDA And08 und openArchitectureWare oAW EFH 07 Beide bieten be reits vordefinierte Transformationsregeln so genannte Cartridges f r typische Platt formen wie Enterprise JavaBeans Spring Hibernate usw oAW ist etwas flexibler und leichter an eigene Plattformen anpassbar auch solche die nicht auf Java basie ren Die ben tigten Transformationen werden h
169. tion eines Systems in eine Infrastruktur mit n bestehenden Systemen lediglich eine Schnittstelle erforderlich System System System 1 2 3 System System System 4 5 6 Abbildung 9 3 Bus Integration Problematisch an diesem Ansatz ist dass die Integrationsfunktionalit ten nicht einmalig an einer zentralen Stelle sondern mehrfach implementiert sind wodurch sich ein erh hter Wartungs und Anpassungsaufwand ergibt Dar ber hinaus be wirkt die Koordination und Verwaltung der dezentral agierenden Einheiten einen Overhead der zu Performanzeinbu en und erh htem Netzwerkverkehr f hren kann 9 4 Integrationsebenen Ma nahmen zur Anwendungsintegration sind auf drei Ebenen eines Informations systems m glich der Datenebene der Funktionsebene und der Ebene der Benutzer schnittstelle Eine Integration auf diesen Ebenen ist mit spezifischen Vor und Nach teilen verbunden Dar ber hinaus stellt jede Integrationsebene gewisse Anforderun gen an die zu integrierenden Systeme weshalb eine uneingeschr nkte Wahlfreiheit in vielen F llen nicht gegeben ist Verf gt eine Anwendung beispielsweise ber keine Schnittstelle die einen Zugriff auf die Programmlogik erlaubt und ist dar ber hinaus der Quellcode nicht verf gbar bzw eine Anpassung des Systems nicht m glich so scheidet eine Integration auf Funktionsebene von vornherein als praktikable L sung aus Bei der Entschei
170. tsprechende Erweiterungen sind f r zahl reiche Entwicklungsumgebungen und Editoren verf gbar In Projekten deren An forderungen bereits zu Beginn des Vorhabens feststehen und die nur geringf gigen Ver nderungen der technologischen Rahmenbedingungen unterworfen sind bringt die Flexibilit t und Agilit t von XP keinen nennenswerten Vorteil Bei der Entwick lung sicherheitskritischer Anwendungen kann eine konsequente Befolgung der Werte von Extreme Programming gar zu gef hrlichen ad hoc Endscheidungen verleiten die zu einem unberechenbaren und unzuverl ssigen Systemverhalten f hren k nnen Da Extreme Programming dem Projektmanager f r seine Arbeit nur wenige konkrete Handlungsempfehlungen mit auf den Weg gibt h ngt der Erfolg des Projektes in hohem Ma e von dessen F higkeiten ab Auch dann wenn f r ein konkretes Projekt der gemeinsame Einsatz aller XP Techniken nicht sinnvoll oder m glich ist stellen die einzelnen Extreme Programming Praktiken n tzliche und in der Praxis bew hrte Techniken zur Erh hung der Qua lit t und Produktivit t in der Softwareentwicklung dar Insbesondere die Einf hrung automatisierter Tests hilft die Effizienz des Entwicklungsprozesses sowie die Qua lit t des Softwareproduktes zu steigern da Fehler zuverl ssiger erkannt werden und sich der Zeitaufwand f r die Fehlersuche gleichzeitig vermindern l sst Auf grund ihres universellen Charakters lassen sich viele der im Rahmen von Extreme Programming
171. twarebausteins im System verbleibt Bei der objektorientierten Softwareentwicklung l sst sich dieses Problem zumin dest bei einem geeigneten Design umgehen Wie das erreicht werden kann wird in Jun04 Jun02 im Detail erl utert Die Grundidee besteht darin dass eine Mock Klasse Unterklasse der Klasse wird die sie im Test ersetzen soll vg Abb 7 2 zu testende Klasse T verwendete K Mock M Klasse E is Abbildung 7 2 Verwendung von Mock Klassen Eine Anderung der zu testenden Klasse T kann vermieden werden wenn in T die zu ersetzende Klasse F nicht fest verdrahtet wird sondern wenn ein 7T Objekt stattdessen auch mit Objekten der Mock Klasse M verkniipft werden kann Insbe sondere darf in T nicht der Konstruktor von E verwendet werden Stattdessen sollte beispielsweise eine abstrakte Fabrik vgl Abschnitt 6 1 1 genutzt werden um die ben tigten Nachbarobjekte eines T Objekts zu erzeugen Im Normalbetrieb wird dann eine abstrakte Fabrik verwendet die E Objekte erzeugt Beim Testen von T w rde im Testtreiber stattdessen eine abstrakte Fabrik bereitgestellt die statt 7 2 AUTOMATISIERUNG DES TESTENS 79 E Objekten M Objekte erzeugt Voraussetzung fiir diesen Ansatz ist nat rlich dass die Klasse E berhaupt Un terklassen zul sst Im Falle von Java bedeutet dies dass E nicht final sein darf 7 2 Automatisierung des Testens Um Zeit und Kosten zu sparen ist es sinnvoll das
172. u a einen Class Loader einen JIT Just In Time Compiler und einen Memory Ma nager f r die Garbage Collection definiert Der Aufbau und die Funktionsweise der CLI sind in Abbildung 5 10 dargestellt Eine CLS konforme Quellsprache wird in die Zwischensprache CIL bersetzt Mithil fe einer plattformspezifischen Implementierung der VES wird die CIL interpretiert bzw in ausf hrbaren Maschinencode bersetzt Das NET Framework welches die CLI f r Windows Systeme implementiert besteht wie in Abbildung 5 11 dargestellt im Wesentlichen aus einer Menge von Klassenbibliotheken und der Common Language Runtime Die Common Language Runtime CLR ist die von Microsoft umgesetzte Im plementierung der VES die nicht nur die Spezifikation der CLI erf llt sondern dar ber hinaus Zugriffe auf das COM sowie das zugrunde liegende Betriebssystem und DLL basierte APIs erm glicht Durch die direkte Integration von COM und 5 2 KOMPONENTENBASIERTE ARCHITEKTUREN 57 Quellsprache CLS konform li Compiler Common Intermediate Language CIL 0110101000101101010001 0101110101010010101010 1010101010111010101110 0110101010101101001100 1010101010111011011001 0101110110101001010101 Abbildung 5 10 Aufbau und Funktionsweise der Common Language Infrastructure CLI der Windowsplattform erreichen die durch einen JIT Compiler bersetzten Zugriffe nahezu die gleiche Geschwindigkeit wie herk mmlicher pr compilierter Code D
173. uf Korrektheit berpr ft werden QuickCheck arbeitet meist sehr schnell und findet Fehler mit er staunlich gro er Zuverl ssigkeit Lediglich Fehler in Codeteilen die nur mit einer sehr geringen Wahrscheinlichkeit durchlaufen werden werden sofern es solche gibt teilweise nicht gefunden Problematisch ist allerdings dass in dem nicht seltenen Fall dass gewisse aufgrund der Paramatertypen m gliche Eingabeparameter einer zu testenden Methode unzul ssig sind vom Tester zun chst passende Eingabege neratoren erstellt werden m ssen da QuickCheck sonst nicht gen gend zul ssige Testeingaben findet 7 4 Glass Box Testen Beim Glass Box Testen geht man nicht von der Spezifikation sondern von dem Code des betrachteten Bausteins aus und versucht alle Kontroll und oder Datenfl sse die in diesem Baustein m glich sind durch m glichst wenige Testf lle abzudecken Abbildung 7 3 veranschaulicht den Code f r die bin re Suche in einem Array graphisch und zeigt wie sich der Kontrollfluss mit zwei Testf llen berdecken l sst In dem ersten rot dargestellten Testfall wird der Wert 5 in einem 2 elementigen Array mit den Werten 17 und 42 gesucht im anderen blau dargestellten Testfall wird im gleichen Array der Wert 42 gesucht Die rote bzw blaue Linie zeigen den sich jeweils ergebenden Kontrollfluss Ein entsprechendes Tools was f r Java Klassen ein solches System von Testf llen f r die berdeckung der Kontroll und Datenfl sse erzeu
174. uft werden muss Dar ber hinaus m ssen nderungen an der Benutzerschnittstelle einer Anwendung im Screen Scraping System nachgef hrt werden um Probleme wie Abst rze oder fehlerhafte Ergebnisse zu vermeiden An dererseits stellt Screen Scraping vielmals die einzige Alternative f r eine Integration dar wenn alle anderen Ans tze mangels Verf gbarkeit geeigneter Schnittstellen oder einer geeigneten Dokumentation bzw des Quellcodes ausscheiden Ein Portal kann als eine webbasierte Anwendung verstanden werden die Daten und Funktionen verschiedener Anwendungen als Dienste auf einer Plattform inte griert und dem Benutzer ber eine einheitlich gestaltete Bedienoberfl che zug nglich macht F r den Benutzer ergeben sich Vorteile wie eine einheitliche Bedienung Single Sign On benutzerspezifische Anpassung von Funktionsumfang und Layout sowie eine einfach einzurichtende Verkn pfung von Diensten und Inhalten verschie dener Anwendungen Die Pr sentation einer Anwendung auf der Portalseite erfolgt in einem Fensterbereich der als Portlet vgl Zi 06 f r die Entwicklung von Port lets mit Java bezeichnet wird Ein Portlet bildet die Benutzerschnittstelle einer einzelnen Anwendung oder einer Gruppe von logisch und oder inhaltlich zusammen geh rigen Anwendungen ab Durch Kommunikationsmechanismen k nnen einge schr nkte Interaktionen zwischen Portlets realisiert werden Der OASIS Standard 9 5 ZUSAMMENFASSENDE BEWERTUNG 107 WSRP Web Servi
175. ung der Integration auf Funktionsebene im Kontext der EAI soll eine Auswahl relevanter Technologien vorgestellt werden Da zahlreiche technologische Entwicklungen auf vorangegangene Technologien aufbauen indem sie diese weiterentwickeln oder ausgehend von deren Problemen einen vollst ndig neu en L sungsansatz versuchen werden nicht nur aktuelle Technologietrends sondern auch bestehende Technologien ber cksichtigt Als Ordnungsrahmen dient dabei eine Unterscheidung nach komponentenorientierten objektorientierten und dienstorien tierten Integrationstechnologien vgl Abbildung 9 6 Synchron Asynchron nachrichtenbasiert Synchron RPC basiert Funktionsorientiert Objektorientiert Serviceorientiert Abbildung 9 6 bersicht Integrationstechnologien 98 KAPITEL 9 ENTERPRISE APPLICATION INTEGRATION Remote Procedure Call Verfiigt eine Anwendung tiber eine API Application Programming Interface so k nnen ihre Funktionalit ten durch andere Systeme auf dem gleichen Rechner ber diese Schnittstelle direkt angesprochen und genutzt werden Der Quellcode der An wendung selbst wird dabei in der Regel nicht angepasst Der Hauptvorteil einer derartigen Integration liegt in der M glichkeit einer Nutzung der Typ berpr fung des Compilers zur bersetzungszeit Fehler k nnen so erheblich leichter gefunden und korrigiert werden als in einem Umfeld wo die Interaktion der Systeme durch die Verwendung von Nachrichten voneinander entkoppelt i
176. ung und Wartung zuordnen lassen Werkzeuge die sowohl die fr heren als auch die sp teren Phasen der Entwicklung abdecken werden als I integrated CASE Werkzeuge bezeichnet Werden mehrere CASE Werkzeuge in einer Plattform integriert so spricht man von einer CASE Umgebung SR Implemen Abnahme amp Wartung Definition Planung Entwurf tierung Einf hrung amp Pflege Integrierte Werkzeuge I CASE Spezialisierte Upper CASE Lower CASE Werkzeuge Front End Back End Abbildung 8 2 Kategorisierung von CASE Werkzeugen Bal93 S 126 8 2 2 Auswahl von CASE Plattformen Nach Bal98 S 591ff spielen bei der Auswahl von CASE Umgebungen drei Fakto ren eine entscheidende Rolle e allgemeine Anforderungen e firmenspezifische Anforderungen und 8 2 CASE TOOLS 87 e derzeitiges Marktangebot Die allgemeinen Anforderungen leiten sich aus dem Stand der Technik ab und sind unabh ngig von den firmenspezifischen Anforderungen Zu ihnen z hlen im wesent lichen Anforderungen an die CASE Plattform die einzelnen CASE Werkzeuge und die Entwicklungsumgebung Wichtige Anforderungen sind vgl Bal98 e Integrationsf higkeit F r eine CASE Plattform ist die Integrationsf higkeit von CASE Werkzeugen von entscheidender Bedeutung Hierf r ist h ufig auch eine sinnvolle Integration der Datenbest nde der einzelnenen Werkzeuge in ein gemeinsames Repository notwendig um die Interaktionsf higkeit der Werk
177. uordnung von Komplexit tsstufen einfach e mittel m komplex k zu internen Datenbest nden und Referenzdaten abh ngig von der Anzahl e der betroffenen Datenelemente und der Anzahl f der betroffenen Feldgruppen be Ausgabe und Abfrage d h Ausgabe mit trivialer Verarbeitungslogik Weiterhin betrachtet werden die vom System zu pflegenden Datenbest nde und die genutzten von externen Systemen gepflegten so genannten Referenzdaten Ein Elementarpro zess kann z B die Erfassung einer Kundenadresse der Ausdruck einer Rechnung die Berechnung eines Tarifs oder die Anzeige eines Kontostands sein Ein wesentliches Kriterium f r die Identifikation eines Elementarprozesses ist seine Einmaligkeit Ein Elementarprozess gilt dann als einmalig wenn er durch die ein oder ausgegebenen Daten oder durch die Verarbeitungslogik unterscheidbar ist An der Oberfl che hn liche Elementarprozesse welche beispielsweise eine gemeinsame Bildschirmmaske f r das Anzeigen und Erfassen von Kundendaten verwenden lassen sich auf diese Weise differenzieren Jeder identifizierten Eingabe Ausgabe und Abfrage wird in Abh ngigkeit von der Anzahl der betroffenen Datenelemente z B Name Kundennummer und Da tenbest nde d h z B einer Tabelle der Datenbank eine Komplexit t zugeordnet vgl Tabellen 3 1 Bei Datenbest nden und Referenzdaten h ngt die Komplexit t von der Anzahl der betroffenen Datenelemente und der Anzahl der so genannten Feldgruppen ab vgl
178. uration Management http www collab net forrester_wave_ report index html Abrufdatum 17 07 2007 SZYPERSKI Clemens GRUNTZ Dominik MURER Stephan Component software beyond object oriented programming 2 London u a Addison Wesley 2002 SOURCEFORGE QuickCheck for Java http sourceforge net projects qc4j Abrufdatum 28 03 2008 STARUML StarUML http staruml sourceforge net en Abruf datum 17 07 2007 STI RLE Harald UML 2 fr Studenten 1 Mnchen Pearson Studium 2005 SUN MICROSYSTEMS Java EE at a Glance http java sun com javaee Abrufdatum 17 07 2007 SUN MICROSYSTEMS JavaServer Faces Technology http java sun com javaee javaserverfaces Abrufdatum 17 07 2007 SUN MICROSYSTEMS The Java EE 5 Tutorial http java sun com javaee 5 docs tutorial doc Abrufdatum 19 09 2007 SUN MICROSYSTEMS Java Message Service Version 1 1 Documen tation http java sun com products jms docs html Abrufdatum 19 09 2007 LITERATURVERZEICHNIS 119 Svo6 Tomos Ton06 Wat08 Wel07 Wik07 Wol08 Wor07a Wor07b Wor07c Zep04 Zi 06 STAHL Thomas VOLTER Markus Model driven Software Development Technology Engineering Management Wiley 2006 TOMOGRAPHY Software Sotograph http www software tomography de html sotograph html Abrufdatum 28 03 2008 TONG Kent Ka L Enjoying Web Development with Tapestry 1 Lulu com 2006 WATIJ Watij Web Ap
179. urch andere Benutzer wieder freigegeben Auf diese Weise werden nderungskonflikte vermieden Die optimistische Versionskontrolle benutzt ein Verfahren welches als Copy Modify Merge bezeichnet wird Dieses Verfahren l sst gleichzeitige nderungen von unterschiedlichen Benutzern an derselben Datei zu Wird beim Checkin einer Datei festgestellt dass sich sowohl das Original im Repository als auch die lokale Kopie ge ndert haben so m ssen die beiden Versionen automatisch oder manuell zusammengef hrt werden Eine manuelle Aufl sung der Konflikte ist in der Regel nur notwendig wenn die Konflikte sich nicht automatisch beheben lassen Die optimistische Versionskontrolle besitzt im Vergleich zur pessimistischen den Nachteil dass sie durch die manuelle Konfliktbeseitigung zus tzlichen Aufwand f r den Anwender bedeutet Daf r wird durch das optimistische Verfahren der 8 1 VERSIONSVERWALTUNG 85 Mehrbenutzerbetrieb deutlich weniger eingeschr nkt Dies ist insbesondere bei einer gr eren Anzahl r umlich getrennter Anwender von Vorteil Wie in Abbildung 8 1 dargestellt gibt es grunds tzlich zwei M glichkeiten die verschiedenen Versionen einer Datei in einem Repository zu speichern Die einfachs te M glichkeit besteht darin von jeder Version einen vollst ndigen Schnappschuss zu speichern Bei dieser Form der Speicherung treten jedoch Redundanzen auf die umso gr er werden je kleiner die nderungen Deltas zwischen den Versi
180. urchgesetzt Einige Firmen werden objektorientiert entwickeln weil dies im Trend liegt ohne sich ber die Vorteile vollst ndig im Klaren zu sein Im Folgenden sollen diese Vorteile herausgearbeitet werden Der wohl am h ufigsten genannte Grund f r den Einsatz von Objektorientierung ist die Kapselung von Struktur und Verhalten oder anders gesagt von Daten und den auf ihnen arbeitenden Operationen im OO Kontext als Methoden bezeichnet Diese Kapselung in so genannten Klassen erm glicht zun chst eine bessere Struk turierung von Softwaresystemen die mun als Systeme von Klassen organisiert wer den k nnen Da nicht triviale Softwaresysteme blicherweise in Teamarbeit erstellt werden ist es weiterhin wichtig dass der verwendete Programmieransatz hierf r geeignet ist Die erw hnte Kapselung gew hrleistet dies da sie eine Trennung von Nutzern und Entwicklern einer Klasse erm glicht Die Nutzer einer Klasse m ssen nur deren Schnittstelle gegeben durch die Namen der Methoden und die Typen ihrer Parameter und ihrer Ergebnisse kennen nicht aber deren Implementierung Letztere interessiert nur die Entwickler Diese haben auch die M glichkeit die Imple mentierung z B aus Effizienzgriinden zu ndern ohne dass dies auf die Nutzer einen Einfluss hat vorausgesetzt dass die Schnittstelle unver ndert bleibt Die erw hnte Kapselung findet sich aber nicht nur in objektorientierten Programmiersprachen sondern auch in nicht objektorientierten
181. vor allem bei komplexeren Systemen sinnvoll ist Zudem wird die Skalierbarkeit der Anwen dung verbessert da sich die Schichten leicht auf unterschiedliche Rechner verteilen lassen Besonders bei komplexeren Anwendungen empfiehlt es sich im Hinblick auf 5 1 SCHICHTENARCHITEKTUREN 43 Prasentation Integrierte Ps Pr sentations g M und S SEH Geschafts ARE Verarbeitung lithisches logik See Datenbank Datenbank 1 Schicht 2 Schichten 3 Schichten Datenhaltung e Abbildung 5 3 Schichtenarchitektur fiir Desktop Anwendungen die Flexibilit t des Gesamtsystems eine Architektur mit drei oder mehr Schichten zu verwenden Ist das System sp ter um weitere Benutzerschnittstellen wie z B eine Web Schnittstelle oder eine Web Service Schnittstelle zu erweitern so k nnen in der Regel Teile der Verarbeitungs und Datenhaltungsschicht wiederverwendet werden Ein solches Szenario wird im Abschnitt Multi Channel Architekturen beschrieben Web Architekturen Im Unterschied zu den klassischen Schichten Architekturen weisen die Web Architek turen eine verteilte Pr sentationsfunktion auf Diese wird sowohl von einem Web Browser als auch von einen Web Server bernommen Der Web Server ist daf r zust ndig die anzuzeigende Webseite zu erzeugen und an den Web Browser zu schi cken Der Web Browser bernimmt lediglich die Darstellung der empfangenen Seite ggf erg nzt um z B in JavaScript realisierte Pr sent
182. wird typischerweise Delegation eingesetzt da so der verwendete Dienstleister zur Laufzeit ausgetauscht werden kann w hrend Vererbungshierarchi en statisch sind In den nachfolgenden Abschnitten werden einige Entwurfsmuster aus den drei erw hnten Kategorien vorgestellt Es wird beschrieben wann sie ein setzbar sind und welche Konsequenzen deren Einsatz hat 6 1 Erzeugungsmuster Entwurfsmuster die der Erzeugung von Objekten dienen verstecken den Erzeu gungsprozess und helfen so ein System unabh ngig davon zu machen wie seine Objekte erzeugt zusammengesetzt und repr sentiert werden 6 1 1 Abstrakte Fabrik Das wichtigste Erzeugungsmuster ist wohl die abstrakte Fabrik Abstract Factory Dieses objektbasierte Erzeugungsmuster bietet eine Schnittstelle zum Erzeugen von Familien verwandter oder voneinander abh ngiger Objekte ohne ihre konkreten Klassen zu spezifizieren Betrachten wir als Beispiel eine Klassenbibliothek f r Benutzerschnittstellen die mehrere Look and Feel Standards wie Swing oder Java AWT unterst tzt Unter schiedliche Look and Feel Standards legen jeweils ein unterschiedliches Aussehen und Verhalten der Interaktionselemente einer Benutzungsschnittstelle Widgets fest Typische Widgets sind Scrollbars Fenster oder Schaltfl chen Damit eine An wendung zwischen verschiedenen Look and Feel Standards portierbar bleibt sollte sie sich nicht auf die Widgets eines spezifischen Standards festlegen und die Erzeu gung v
183. wurden sollen nun zwei Beipielanwendungen gezeigt werden in denen diese verwendet werden Ph nomenTyp Messung name String 1 wert double 1 Ph nomen i Untersuchung name String datum Datum 0 1 2 1 Patient name String letzterWert Ph nomenTyp double Abbildung 4 5 Klassendiagramm f r ein Krankenhaus Softwaresystem 4 2 UNIFIED MODELING LANGUAGE 33 Abb 4 5 zeigt ein Beispiel Klassendiagramm fiir eine Krankenhausanwendung Hier wird modelliert dass Patienten untersucht werden Eine Messung ist eine spe zielle Untersuchung daher wird hier Vererbung eingesetzt Jeder Untersuchung ist ein Ph nomentyp z B Blutgruppe und ggf ein Ph nomen z B A zugeordnet Bei Messungen gibt es manchmal kein zugeordnetes Ph nomen sondern nur einen gemessenen Wert so z B bei Messungen zum Ph nomentyp K rpertemperatur Beispiel 2 Arithmetischer Ausdruck Ausdruck BinOp 2 1 L gt auswerten ausfuehren x y Konstante Geschachtelt Addition wert Abbildung 4 6 Klassendiagramm fiir arithmetische Ausdriicke Ein arithmetischer Ausdruck ist entweder einfach eine Konstante oder ein ge schachtelter Ausdruck bei dem zwei Teilausdr cke durch eine bin re Operation wie z B die Addition verkniipft werden vgl Abb 4 6 Die Pfeilsp
184. y verwaltet und ein oder mehreren Clients die mithilfe des Servers auf das Repository zugreifen Die Clients stellen die Anwenderschnittstelle dar ber die die Benutzer auf die Dienste des Versionsver waltungssystems zugreifen k nnen Zu den wichtigsten Diensten einer Versionsverwaltung z hlen das Checkout und das Checkin Beim Checkout erstellt ein Client eine lokale Kopie von einzelnen oder mehreren Dateien aus dem Repository Die nderungen an einer lokalen Kopie haben zun chst keinen Einfluss auf das im Repository gespeicherte Original und sind somit auch f r die brigen Clients nicht sichtbar Sollen die nderungen einer lokalen Kopie in das Repository bernommen werden so ist daf r eine besondere Best tigung notwendig Diese Best tigung wird als Checkin oder Commit bezeichnet Dabei wird f r die betroffenen Dateien eine neue Version im Repository erzeugt Bei der Koordinierung des Mehrbenutzerbetriebes tritt das Problem auf gleich zeitige nderungen an derselben Datei zu behandeln Hierf r gibt es im Wesentlichen zwei Strategien die pessimistische und die optimistische Versionskontrolle Der Mechanismus der pessimistischen Versionskontrolle wird als Lock Modify Write bezeichnet Beim Checkout werden dabei alle betroffenen Dateien gesperrt was zur Folge hat dass dieselbe Datei nur von einem Benutzer ausgecheckt und bearbeitet werden kann Erst nach dem Checkin wird die Sperre aufgehoben und die Datei f r nderungen d
185. zeu ge zu garantieren e Offenheit Die Plattform sollte m glichst ber Export und Importschnitt stellen verf gen und auch Drittanbietern muss es m glich sein Werkzeuge in die Plattform zu integrieren e Multi und Interprojektf higkeit Die CASE Plattform sollte in der Lage sein mehrere Projekte mit verschiedenen Mitarbeitern parallel verwalten zu k nnen Zudem sind projekt bergreifende Informationen separat zu verwalten um Redundanzen und Inkonsistenzen zu vermeiden Die firmenspezifischen Anforderungen leiten sich aus der individuellen Situati on und den Bed rfnissen der betroffenen Firma ab Hier nennt Balzert Bal93 S 144 ff folgende Kategorien die sich gegenseitig beeinflussen die Eigenschaften der Zielprodukte die zu unterst tzende Zielumgebung die zu unterst tzenden Methoden und Vorgehensmodelle sowie das Entwicklungsumfeld Nach Abgleich der allgemeinen und firmenspezifischen Anforderungen ergibt sich ein Kriterienkatalog der die ideale auf die Anforderungen der Firma zugeschnittene CASE Umgebung beschreibt Die ideale Firmenumgebung sollte mit den tats chlich am Markt vorhandenen L sungen verglichen werden um schlie lich die bestm gliche L sung auszuw hlen Bei der Begutachtung der Marktangebote gilt es vor allem zwei Punkte zu ber cksichtigen die technischen und die kaufm nnischen Aspekte der angebotenen Umgebungen Um einen berblick ber die Unterst tzungsm glichkeiten durch CASE Tools zu erl

Best Practices in der Softwareentwicklung

Contents

Download Pdf Manuals

Related Search

Related Contents