Testen von serviceorientierten Architekturen: Teststrategie und Implementierung
|
|
- Alexandra Sauer
- vor 8 Jahren
- Abrufe
Transkript
1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Testen von serviceorientierten Architekturen: Teststrategie und Implementierung Masterarbeit im Studiengang Informatik von Dennis Hardt Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr.-Ing. Christian Grimm Betreuer: Dr. Jan-Mirko Maczewski Betreuer: Dipl.-Wirt.-Inform. Daniel Lübke Hannover, 29. Oktober 2007
2 Zusammenfassung Serviceorientierte Architekturen (SOA) haben sich zu einem bekannten Paradigma zur Strukturierung von Applikationen entwickelt. An ihre aktiven Einheiten, die Services, werden hohe qualitative Ansprüche gestellt, um sie in einem beliebigen Umfeld einsetzen zu können. Dabei wird in der Forschung und Entwicklung oftmals speziell das Testen von Webservices betrachtet; die Beschreibung einer Teststrategie bleibt jedoch aus. Diese Arbeit stellt nicht nur eine Auswahl von potentiellen Problemen vor, die in einer SOA auftreten können, sondern ermöglicht auch diese Probleme als Grundlage zur Formulierung einer Teststrategie zu nehmen. Dazu werden die Artefakte, die eine Teststrategie für eine SOA beschreiben, identifiziert und präsentiert. Die Definition einer allgemeinen Vorgehensweise zur Findung einer konkreten Teststrategie erlaubt Teststrategien für beliebige SOA-Projekte zu bestimmen. Ein im Rahmen dieser Arbeit entwickeltes Werkzeug erlaubt nicht nur die Umsetzung einer Teststrategie, sondern ermöglicht auch die Realisierung von Teststufen exemplarisch für in.net implementierte Webservices. Dazu stellt diese Arbeit eine neue Sichtweise auf Komponenten vor und trennt diese klar von Kompositionen ab. Erfahrungen mit dem Werkzeug und einer konkret entwickelten Teststrategie wurden im Rahmen einer Fallstudie bei einem Unternehmen gesammelt. ii
3 Inhaltsverzeichnis 1. Einführung Motivation Problemstellung Struktur dieser Arbeit Grundlagen Testen Grundbegriffe Ausgewählte Testmethoden Teststufe Teststrategie Serviceorientierte Architekturen Grundbegriffe Konsequenzen Plattformen für Unternehmensanwendungen Webservices Grundbegriffe Webservice Standards Zusammenfassung Ableitung einer Teststrategie für serviceorientierte Architekturen Einordnung der Teststrategie Einflüsse auf die Teststrategie Idee, Plattform und Technologie Projektumfeld Teststrategie Serviceumgebung Vorgehensweise Testszenario Komponententests für eine SOA Vorgehen Identifikation der Komponente bei Services Austauschen von Komponenten in Services Zusammenfassung Testaspekte für SOA, Webservices und.net Identifikation von Testaspekten SOA als Idee iii
4 Inhaltsverzeichnis Webservices als Technologie NET als Plattform Analogien zu Java EE Zusammenfassung Werkzeugunterstützung für die Teststrategie Überblick Anforderungen Konsequenzen Prozess Testmöglichkeiten in.net Architektur Grobarchitektur Testablauf Adapter zu einem Unit Test Framework Interaktion mit externen Systemen Implementierung Realisierung von harten Mocks Identifikation von auszutauschenden Teilen Verarbeitung und Austauschen von Code Realisierung von weichen Mocks Zusammenfassung Fallstudie Projektumfeld Betrachtete Webservices Bisheriges Vorgehen beim Testen der Webservices Eine konkrete Teststrategie Annahmen Testmatrix und Testszenarien Anwendung der Teststrategie Umsetzung Gefundene Fehler Lektionen und Bewertung Zusammenfassung Kritische Würdigung Kritischer Rückblick auf den Erarbeitungsprozess Stärken und Schwächen einer Teststrategie Stärken und Schwächen der entwickelten Erweiterungen Kritischer Rückblick auf die Fallstudie Verwandte Arbeiten Andere Ansätze und Werkzeuge Testaspekte Testen von Kompositionen iv
5 Inhaltsverzeichnis 9. Zusammenfassung und Ausblick Rückblick Ausblick Fazit Literaturverzeichnis 76 A. Testszenarien 79 v
6 1. Einführung 1.1. Motivation Serviceorientierte Architekturen (SOA) sind längst mehr als nur ein Schlagwort oder Werbeträger. Das zentrale Ziel einer SOA besteht in der Reduktion von Abhängigkeiten zwischen Softwarelösungen [Sta06a]. Aber Dienste in heterogenen, dynamischen und verteilten Umgebungen anzubieten, fordert neue Sichtweisen beim Testen eines Services. So sind viele bekannte Testverfahren und -werkzeuge nicht mehr anwendbar [CP06]. Webservices sind nur eine mögliche Implementierung von Services [Sta06a]. Dennoch hat sich diese Technologie als die dominierende und am weitesten verbreitete Realisierung für SOA etabliert. Nicht zuletzt unterstützen viele Applikationsserver und Entwicklungsumgebungen aus dem Java- oder Microsoft.NET-Umfeld die Bereitstellung von Webservices [MTSM03][GP06]. Selbst Unternehmen, unter anderem zu nennen seien Amazon 1 und Ebay 2, lagern Teile ihrer Dienste in Webservices aus. Folglich können Kunden von überall auf der Welt ohne Benutzeroberfläche mit einem Geschäft interagieren und es sogar in ihre eigenen Geschäftsprozesse einbinden. Ein Kernkonzept von SOA ist die Komposition oder Zusammenschaltung von Services, um eine Applikation zu bilden [HS05]. Infolgedessen führen Fehler in einem einzelnen Service zu fehlerhaftem Gesamtverhalten. Testen wird somit unabdingbar, um die qualitativ hochwertige Implementierung von jedem Service sicher zu stellen. Insbesondere in den letzten Jahren wurden viele neue Ansätze und Werkzeuge entwickelt, um das Testen von SOA zu verbessern. Dennoch beruhen alle Entwicklungen auf denselben Ansätzen und betrachten Services als eine abgeschlossene Einheit, so dass sich das Testen selbst mitunter als sehr schwierig erweist. Durch die Verfügbarkeit von einfach zu handhabenden Werkzeugen [BG98] haben Komponententests zunehmend an Bedeutung gewonnen. Für nahezu jede Plattform ist ein xunit Test Framework [Ham04] verfügbar und erlaubt die einheitliche Formulierung von Komponententests. Auch die Integration in Entwicklungsumgebungen hat sich stetig verbessert [GP06], so dass Komponententests zu einer entwicklernahen und praktikablen Lösung geworden sind. Auch wenn für eine SOA Werkzeuge wie z.b. BPELUnit [May06] oder WSUnit [WSU] existieren, so nehmen sie eine bestimmte Sichtweise bei Komponententests ein. Oft werden jedoch bekannte Bibliotheken und objektorientierte Programmiersprachen eingesetzt, um einen Service zu realisieren. Speziell in diesem Umfeld versagen beim Testen Konzepte, die für objektorientierte
7 1. Einführung Software zur täglichen Praxis geworden sind. Sowohl die Interaktion mit einem Service, als auch das Austauschen von Komponenten, erfordert neue Sichtweisen und Ideen. Das Testen von Webservices und Kompositionen hat in der Forschung viel Aufmerksamkeit erfahren. Insbesondere die Eigenschaften, die bei einem Webservice funktional zu testen sind, sind wohl bekannt. Dennoch bleibt beim Testen die genaue Vorgehensweise unklar. Es fehlt eine Strategie, die Aktivitäten den Teststufen zuordnet und z.b. festlegt welche Tests zu automatisieren sind. Mitunter benötigt auch diese Teststrategie weitere Unterstützung durch Werkzeuge, um erst praktikabel umsetzbar zu sein Problemstellung Diese Arbeit befasst sich im Allgemeinen mit dem Testen von serviceorientierten Architekturen. Im Einzelnen sind dazu die folgenden Punkte gezielt zu adressieren: Ziel dieser Arbeit ist eine Teststrategie für serviceorientierte Architekturen bereit zu stellen, so dass beim Einsatz einer SOA die Vorgehensweise beim Testen bekannt ist. Beginnen soll die Teststrategie bei Komponententests, aber auch höhere Teststufen sind zu berücksichtigen. Falls erforderlich ist ein Werkzeug zu erstellen, das die Umsetzung der Teststrategie praktisch ermöglicht. Speziell die Realisierung von Komponententests ist dabei zu berücksichtigen. Im Rahmen einer Fallstudie ist zu prüfen, ob die vorgeschlagene Teststrategie umsetzbar ist und erstellte Werkzeuge praktikabel sind. Als Testobjekte werden Webservices dienen, die von einem Unternehmen entwickelt wurden und von ihren Kunden genutzt werden. Hierbei sollen insbesondere die notwendigen Schritte zur Erzeugung von Testdaten nachvollziehbar sein. Zur Entwicklung wird vom Unternehmen das Microsoft.NET Framework und die Microsoft Visual Studio Team Edition [GP06] eingesetzt, so dass alle erstellten Werkzeuge und Tests dort anwendbar sein müssen Struktur dieser Arbeit Diese Arbeit untergliedert sich in die folgenden Kapitel: In Kapitel 2 werden einige Grundlagen über Testen und serviceorientierte Architekturen unabhängig voneinander eingeführt. Aufgrund unterschiedlicher Definitionen im SOA-Umfeld, werden die verwendete Terminologie und das Verständnis von einer SOA definiert. Aufgrund bestimmter Einflüsse ist es nicht möglich direkt eine Teststrategie für SOA anzugeben. Kapitel 3 wird alle Einflüsse analysieren und ein allgemeines 2
8 1. Einführung Vorgehen zur Findung einer Teststrategie präsentieren. Kapitel 4 wird konkret für Webservices und dem Microsoft.NET Framework potentielle Probleme nach dem Vorgehen aus Kapitel 3 vorstellen. Webservices und das Microsoft.NET Framework werden aufgrund der Relevanz in der Fallstudie in Kapitel 6 betrachtet. Kapitel 5 stellt ein Werkzeug vor, mit dem Teststufen für Webservices umgesetzt werden können und eine nach Kapitel 3 angegebene Teststrategie realisierbar wird. In Kapitel 6 werden die Ergebnisse aus den Kapiteln 3, 4 und 5 in einer Fallstudie zusammengeführt, um die Webservices eines Unternehmens zu testen. Die Stärken und Schwächen der Teststrategie und des Werkzeugs werden in einer kritischen Würdigung in Kapitel 7 beleuchtet. Kapitel 8 zeigt verwandte Arbeiten, um die Einordnung dieser Arbeit in den wissenschaftlichen Kontext zu erleichtern. Diese Arbeit schließt in Kapitel 9 mit einer Zusammenfassung und einem Ausblick ab. 3
9 2. Grundlagen Während der Entwicklung durchlebt Software einen Lebenszyklus, der sich in mehrere Aktivitäten unterteilt. Von der Analyse der Anforderungen, über die Programmierung, bis zum Testen, arbeiten in jeder Aktivität verschiedene Persönlichkeiten zusammen. Oftmals wird dieses Vorgehen definiert, sei es durch das V-Modell [Boe79] oder durch agile Entwicklungsmethoden, z.b. Extreme Programming (XP) [Bec00]. Testen ist eine Aktivität, deren Durchführung die Qualität eines Produktes bewertet [IEE04]. Hierbei ist ein Test die Ausführung und Beobachtung von Teilen des Produktes. Die sich anschließende Behebung von identifizierten Mängeln und Fehlern verbessert das Produkt. Sowohl das V-Modell, als auch XP, sehen Tests als durchzuführende Aktivität vor. Dabei hat jedes Projekt ein individuelles Vorgehen und unterschiedliche Kapazitäten zur Realisierung von Tests. Speziell in XP testen nur Entwickler ihren Code durch automatisierte Komponententests. Serviceorientierte Architekturen (SOA) sind ein Stil zur Strukturierung von Applikationen. Durch viel Aufmerksamkeit in der Industrie sind sehr unterschiedliche Definitionen einer SOA entstanden [OAS06]. Besonders die Trennung zu Webservices ist verschwommen, weil sich Webservices zur verbreitetsten und bekanntesten Umsetzung von Services etabliert haben. Dieses Kapitel wird alle für den Verlauf dieser Arbeit wichtigen Begriffe bezüglich des Testens und SOA definieren. In den Folgekapiteln werden beide Themengebiete dann langsam einander angenährt, um eine Teststrategie für SOA zu formen Testen Grundbegriffe Tester sind die Scheinwerfer in einem Projekt, die die Straße für Programmierer und Manager erleuchten [KBP02]. Sie zeigen, ob man sich nahe am Abgrund bewegt oder auf sicherer Spur fährt. Im Allgemeinen ist das Produkt der Programmierung ein ausführbares Kompilat. Beim Testen sind es Testfälle, die letztendlich genutzt werden, um Aspekte einer Software in einem bestimmten Umfeld zu testen. Ein Testfall besteht dabei aus Eingabedaten, Ausführungsbedingungen und erwarteten Ergebnissen [IEE90]. Die Ableitung oder Auswahl von Testfällen ist durch Testmethoden [SLS06] möglich. Im Allgemeinen lässt sich jeder Test über fünf Dimensionen beschreiben [KBP02]: 4
10 2. Grundlagen Tester: Wer führt einen Test durch? Neben Testern, können auch andere Benutzergruppen Tests durchführen: Entwickler testen ihren Code z.b. durch automatisierte Komponententests in XP. Endnutzer testen ein Produkt im Rahmen eines Betatests. Abdeckung: Was wird getestet? Zum Testen wird immer ein Testobjekt benötigt, das durch konkrete Testfälle geprüft wird. Hierbei kann es sich z.b. um die Methode einer Klasse handeln oder die Oberfläche einer Applikation. Potentielle Probleme: Warum wird getestet? Welche Fehler können im Produkt auftreten? Aktivitäten: Wie wird getestet? Auswertung: Wann ist ein Test erfolgreich und wann fehlgeschlagen? Tritt der gewünschte Effekt bei Ansteuerung des Testobjekts ein, d.h. sind resultierende Werte korrekt oder wird eine erwartete Fehlermeldung geliefert. Beispiel 2.1 Bei der Testmethode Testen von Funktionen ( function testing ) wird jede Funktion einzeln nacheinander getestet. Demzufolge wird nur eine Aussage über die Abdeckung getroffen, aber wer den Test durchführt (Tester) oder was für Fehler (Potentielle Probleme) gesucht werden, bleibt unbekannt. [KBP02] Testmethoden sind formal anwendbare Methoden, die noch nicht in allen Dimensionen eine Ausprägung besitzen. Definition 2.1 Ein Testaspekt ist eine Ausprägung über der Dimension: Potentielle Probleme. Zusätzlich beschreibt ein Testaspekt die Vorgehensweise zur Herleitung von Testfällen unter Einbezug von Testmethoden. Ein Testaspekt beschreibt somit eine Klasse von Fehlern, die in einem Testobjekt auftreten können. Insbesondere ist aber auch das Vorgehen zur Findung dieses Fehlers zu beschreiben. Wenn bekannte Testmethoden existieren, sind diese anzugeben, ansonsten ist eine allgemeine Beschreibung zur Ableitung von Testfällen zu definieren. Im Verlauf dieser Arbeit werden ausschließlich Testaspekte benutzt, um potentielle Probleme in einer SOA zu definieren und die Vorgehensweise zum Auffinden dieser Probleme festzuhalten Ausgewählte Testmethoden In dieser Arbeit werden potentielle Probleme über Testaspekte beschrieben. Dabei stützt sich die Beschreibung der Vorgehensweise zur Identifikation von repräsentierten Fehlern auf Testmethoden, von denen eine benutzte Auswahl im Folgenden kurz 5
11 2. Grundlagen vorgestellt sei. Jede Testmethode ist durch ihren englischen Namen benannt und für weitere Informationen sei auf die angegebene Literatur verwiesen: Equivalence partitioning ([IEE04], [KBP02]): Unterteilung von Testdaten in Äquivalenzklassen, d.h. alle Testdaten aus einer Äquivalenzklasse führen bei einem Test zu äquivalentem Verhalten. So genügt es für ausgewählte Elemente einer Äquivalenzklasse zu testen. Regression testing ([IEE04], [KBP02], [SLS06]): Erneutes Testen eines Systems nach einer Modifikation, um zu verifizieren, dass durch Änderungen keine unbeabsichtigten Effekte im System entstanden sind. Dazu werden vorhandene Testfälle erneut verwendet. Statement and branch coverage ([IEE04], [KBP02]): Man erreicht 100% statement and branch coverage, wenn ein Test jede Anweisung und jeden Zweig im Programm ausführt. Tests werden so gestaltet, dass sie eine möglichst hohe statement and branch coverage erzielen. Function testing ([KBP02]): Testen von jeder Funktion einzeln und nacheinander. White-Box Ansätze testen dabei jede Funktion wie man sie im Code sieht. Black- Box Ansätze testen jede Funktion wie sie ein Benutzer im System nutzt. Specification testing ([KBP02]): Verifizierung sachbezogener Anforderungen, die in Spezifikationen, Handbüchern oder anderen Dokumenten an das Produkt gestellt werden. Load testing ([KBP02]): An ein System werden viele Anfragen gestellt. Bei einer hohen Auslastung wird das System wahrscheinlich ausfallen, so dass Schwachstellen offensichtlich werden. Performance testing ([IEE04], [KBP02]): Verifiziert, ob ein System Anforderungen an die Leistung erfüllt, z.b. an den Durchsatz oder an Antwortzeiten. Erhebliche Leistungseinbrüche gegenüber einer vorherigen Version des Systems können auf Fehler in der Programmierung hinweisen. Long sequence testing ([KBP02]): Über Nacht, Tage oder Wochen werden Anfragen an ein System gestellt. Smoke testing ([KBP02]): Testet grundlegende Eigenschaften, von denen erwartet wird, dass sie im System funktionsfähig sind. Ziel ist es zu prüfen, ob eine neue Version des Systems würdig ist getestet zu werden. Diese Tests sind oftmals automatisiert. Path testing ([KBP02]): Ein Pfad beinhaltet alle Schritte, die ein Tester ausführt, oder alle Anweisungen, die ein Programm ausführt, um einen bestimmten Zustand zu erreichen. Dabei ist es nicht möglich alle Pfade eines nicht trivialen Programms zu testen. Configuration testing ([IEE04], [KBP02]): Analyse von Software unter Einsatz verschiedener spezifizierter Konfigurationen. Boundary-value analysis ([IEE04], [KBP02]): Lassen sich Äquivalenzklassen für 6
12 2. Grundlagen Zahlenwerte aufstellen, so sind die Grenzen der kleinste und größte Wert dieser Klasse. Testfälle nutzen diese Grenzen und Werte nahe den Grenzen Teststufe Die Ursache eines Mangels in einem großen und komplexen System zu finden, ist mitunter ein schwieriges Unterfangen. In der objektorientierten Programmierung interagieren am Ende eines Projekts Tausende von Objekten miteinander, um eine Applikation zu formen. Existiert in einem dieser vielen Objekte ein Fehler, so lässt er sich nur schwer identifizieren. Eine Abschwächung dieses Problems ist durch den Einsatz von drei Teststufen möglich: 1. Komponententests (unit test [IEE04]): Eine Komponente sei die kleinste kompilierbare Einheit in einer Applikation [Tam02], so sind es z.b. in der objektorientierten Programmierung die Klassen [SLS06]. Komponententests verifizieren jede einzelne Komponente isoliert von allen anderen Komponenten durch den Einsatz von künstlichen Umgebungen [Tam02]. Praktisch werden dazu Mocks 1 eingesetzt, die das Verhalten einer Komponente simulieren [TH02]. Dabei haben Mocks das Ziel so einfach wie möglich umgesetzt zu sein und nicht die Logik der ersetzten Komponente nachzubilden [MFC01]. Verfasst werden Komponententests z.b. mit Unit Test Frameworks, die für eine Vielzahl von Sprachen zur Verfügung stehen [Ham04]. Dennoch setzen Komponententests voraus, dass alle von einer Komponente benutzten Komponenten austauschbar sind. In der objektorientierten Programmierung kann dies durch einen Programmierstil erreicht werden, der z.b. auf geringe Komplexität setzt und von globalen Objekten unabhängig ist [Goo06]. Zusätzlich haben sich über die Jahre Werkzeuge entwickelt, die bei der Erstellung von Mocks unterstützen [FMP + ] oder auch die Anforderungen an die Testbarkeit reduzieren [Typ]. 2. Integrationstests (integration test [IEE04]): Als Folgestufe nach Komponententests werden bei Integrationstests Komponenten zu größeren Teilsystemen integriert [SLS06]. Ziel ist es durch schrittweise Integration sicherzustellen, dass alle Komponenten korrekt zusammenarbeiten. 3. Systemtests (system test [IEE04]): Systemtests verifizieren bzw. validieren das gesamte Produkt, nachdem alle Teile einer Software integriert wurden [Tam02]. Insbesondere sind andere Sichtweisen testbar als dies auf niedrigeren Stufen der Fall ist - z.b. Performance- und Lasttests. Der Einsatz von Teststufen erleichtert das Testen, indem nicht immer mit einem evtl. großem und unübersichtlichem Produkt gearbeitet wird. Das Testen von einzelnen Komponenten und deren Zusammenspiel erweist sich oftmals als einfacher. Für diese Arbeit sind Abnahmetests unerheblich und seien daher nicht angeführt. 1 Auch: Stub oder Dummy 7
13 2. Grundlagen Teststrategie Bisher wurde eine kleine Auswahl an Grundbegriffen aus dem Bereich des Testens vorgestellt. Dennoch beschreiben all diese Ansätze und Methoden noch nicht wie ein Produkt zu testen ist. Es fehlt eine Darlegung der Vorgehensweise, genauer die Teststrategie. Eine Teststrategie ist mehr als nur eine Sammlung von Testmethoden, aber auch noch kein Testkonzept [KBP02]. Ziel ist die Festlegung eines einheitlichen Ansatzes für die zukünftige Testplanung. Eine Teststrategie legt den Umfang durchzuführender Tests fest und adressiert nur Probleme mit kritischem Risiko [SLS06]. Definition 2.2 Eine Teststrategie ist die (1) Abstrakte Beschreibung der Teststufen und der zugehörigen Ein- und Ausgangskriterien... (2) Aufteilung von Testaufwand über die zu testenden Teile und/oder zu erfüllende Qualitätsmerkmale des Testobjekts. Auswahl und Bestimmung der Reihenfolge von einzelnen Testmethoden und der Reihenfolge ihrer Anwendung auf die verschiedenen Testobjekte... [imb] Eine Teststrategie ist in der Regel in mehreren Projekten anwendbar [imb]. Sie beschreibt den Einsatz von Teststufen und legt das Vorgehen beim Testen fest, wenn möglich unter Angabe von Testmethoden. Beispiel 2.2 Testgetriebene Entwicklung ist eine Teststrategie, die ein iteratives Vorgehen nahe legt. Bevor Code geschrieben wird, ist immer ein Test zu verfassen, der zunächst fehlschlagen muss. Als Idee wird jede Methode einzeln mit Komponententests getestet, mit der Besonderheit, dass ein Testfall vor der Implementierung formuliert wird. Höhere Teststufen werden nicht betrachtet. Insbesondere ist der Testaufwand festgelegt, weil kein Code ohne Test existiert. Testaspekte beschreiben ein konkretes Problem und bilden eine Sammlung von Testmethoden, um das Problem ausfindig zu machen. Folglich kann eine Teststrategie über Testaspekte beschrieben werden Serviceorientierte Architekturen Grundbegriffe Im Folgenden wird ein einheitlich in dieser Arbeit verwendeter Sprachschatz für SOA eingeführt. Dabei liegt der Fokus auf Einfachheit, so dass für weitere Informationen auf [OAS06], [Sta06a] und [W3C04] verwiesen sei. Definition 2.3 Eine Schnittstelle ist ein Dokument, das beschreibt wie mit einem Objekt zu interagieren ist und was von einer Einheit angeboten wird. Erfolgt die Interaktion mit dieser 8
14 2. Grundlagen Einheit über Nachrichten, so legt die Schnittstelle das Format der Nachrichten fest. Zur Auswertung und Interpretation einer Schnittstelle ist eine einheitliche und öffentliche Beschreibung notwendig. Die Beschreibung ist auch in der Lage mögliche Kommunikationsformen zu realisieren. Definition 2.4 Eine Dokumentation ist ein Dokument, das die semantischen Eigenschaften, Randbedingungen und den Effekt einer Einheit beschreibt. Die Schnittstelle und die Dokumentation einer Einheit sind Artefakte, durch die eine Interaktion mit der Einheit möglich wird. Definition 2.5 Ein Service ist eine aktive Einheit, die Anderen seine Dienste anbietet. Jeder Service hat eine Schnittstelle, die Serviceschnittstelle, eine Beschreibung, die Servicebeschreibung und optional eine Dokumentation, die Servicedokumentation. Die Kommunikation zwischen Services erfolgt durch den Austausch von Nachrichten. Das Resultat einer Interaktion mit einem Service ist ein Effekt. Ein Service wird in der Fachliteratur und im allgemeinen Gebrauch immer abstrakt als ein Anbieter von Diensten betrachtet. Die gegebene Definition stützt sich auf den Austausch von Nachrichten, um Kopplungen an die Kommunikationsform zu reduzieren. Eine SOA hat zum Ziel die Abhängigkeiten zwischen Softwareinseln zu reduzieren [Sta06a]. Dabei befasst sich SOA jedoch nicht nur mit Services, sondern stellt auch die Beziehungen zwischen zunächst drei Rollen her [Pap03]: Serviceanbieter (service provider): Stellt einen Service zur Verfügung und verwaltet die notwendige Infrastruktur. Servicekonsument (service consumer): Möchte Dienste in Anspruch nehmen und sucht einen entsprechenden Service. Serviceregister (service registry): Stellt ein Verzeichnis von Services bereit. Jeder Service verwendet das Bridge -Entwurfsmuster [GHJV95], um die Serviceschnittstelle von der Implementierung zu trennen [Sta06a]. Deshalb muss der Serviceanbieter nicht immer zwangsläufig auch der Ersteller des Services sein, so dass die Rolle des Serviceentwicklers ebenfalls von Bedeutung ist. Diese Arbeit betrachtet eine nach Abbildung 2.1 entsprechend erweiterte Darstellung des klassischen SOA- Dreiecks [Pap03]. Definition 2.6 Die von einem Serviceentwickler erstellte Implementierung eines Services heißt Serviceimplementierung. Durch die Kenntnis von Services ist es möglich eine serviceorientierte Architektur zu definieren. Diese stützt sich auf Abbildung 2.1 und das erweiterte SOA-Dreieck. Genauer ist das Zusammenspiel aller beteiligten Rollen die Kerneigenschaft einer SOA. 9
15 2. Grundlagen Serviceregister Veröffentlichen Finden Servicekonsument Binden und Aufrufen Bereitstellen Serviceanbieter Serviceentwickler Abbildung 2.1.: Erweitertes SOA-Dreieck Definition 2.7 Eine serviceorientierte Architektur (SOA) ist die Strukturierung einer Lösung nach dem erweiterten SOA-Dreieck Konsequenzen Zum Verständnis dieser Arbeit ist es notwendig, einige Besonderheiten und Konsequenzen aus dem Einsatz einer SOA zu kennen. Dabei ergibt sich eine Konsequenz nicht immer unmittelbar aus vorhergehenden Definitionen, sondern entsteht durch den praktischen Einsatz einer SOA. Das erweiterte SOA-Dreieck trifft keine Aussagen darüber wie die Serviceimplementierung umgesetzt wird. Insbesondere beim Serviceanbieter wird sie wie eine Black-Box behandelt. Wenn ein Service jedoch wieder selbst zu einem Servicekonsument wird, entsteht ein Verbund von Services. Konsequenz 2.1 Eine Serviceimplementierung kann Services nutzen. Ein Szenario, indem ein Service durch das Zusammenschalten von Services entsteht, wird als Komposition bezeichnet [Yan03]. SOA begünstigt dadurch Flexibilität, indem auf Änderungen durch den Einsatz von alternativen Services reagiert werden kann [GP06]. Kompositionen werden häufig bei der Realisierung von Geschäftsprozessen eingesetzt [ACD + 03]. Beispiel 2.3 zeigt ein Szenario aus [KBL06], um den Einsatz von Services und Kompositionen zu motivieren. Beispiel 2.3 Ein Reisebüro bucht einen Ausflug für einen Kunden. Als Erstes sucht das Reisebüro Flüge bei verschiedenen Fluggesellschaften für das gewünschte Datum. Danach bucht das Reisebüro den preisgünstigsten Flug. Ähnliche Aktivitäten führt das Reisebüro 10
16 2. Grundlagen für eine Hotelreservierung durch und mietet ein Auto. Eigentlich muss das Reisebüro diesen Vorgang für 25 Kunden zur selben Zeit durchführen. Die Aktivitäten des Reisebüros aus Beispiel 2.3 bilden den Geschäftsprozess des Unternehmens. Während der Geschäftsprozess abgearbeitet wird, ist das Reisebüro ein Servicekonsument und Fluggesellschaften, Hotels,... sind Serviceanbieter. Dabei will das Reisebüro die einzelnen Aktivitäten im Geschäftsprozess automatisiert ausführen. Zur Interaktion mit einem Service muss der Servicekonsument den Aufbau der Nachrichten kennen, die ein Service erwartet. Folglich muss der Servicekonsument auch die Servicebeschreibung des Services kennen. Konsequenz 2.2 Auf der Seite des Servicekonsumenten kommt häufig, wenn auch nicht zwingend notwendig, das Proxy -Entwurfsmuster [GHJV95] zum Einsatz [Sta06a]. Ein generierter Proxy findet, bindet und benutzt dabei einen Service [MTSM03]. Der Einsatz eines Proxy auf Seiten des Servicekonsumenten vereinfacht die Kommunikation mit dem Service, wenn dieser Proxy automatisch generiert wird. Dazu ist unter Anwendung der Servicebeschreibung gezielt die Serviceschnittstelle auszuwerten. Konsequenz 2.3 In der objektorientierten Programmierung müssen Objekte erst instanziiert werden bevor man mit ihnen interagieren kann. Hingegen interagiert der Servicekonsument mit einem bereits existierenden Service. [OAS06] Durch die Unkenntnis der Serviceinstanz hat der Servicekonsument keine direkte Kontrolle über einen Service, sondern kann nur mit ihm interagieren. Konsequenz 2.4 Erst durch die Bereitstellung in einem Container, kann mit einem Service interagiert werden. D.h. der Vorgang der Bereitstellung macht aus einer Serviceimplementierung einen Service. Insbesondere verwaltet ein Container die Serviceinstanz. Konsequenz 2.5 Die SOA Infrastruktur ist zunächst zustandslos [Sta06a]. Folglich ist zwischen mehreren Interaktionen mit einem Service nicht garantiert, dass es sich um die selbe Serviceinstanz handelt. Auf Seiten des Serviceanbieters sind z.b. Wechsel der Serviceinstanz durch den Einsatz von Service-Pools denkbar [Sta06a]. Servicekonsumenten können an einen Service nahezu beliebige Nachrichten mit beliebigem Inhalt senden. Entweder wird die Nachricht verworfen oder aber ausgewertet und erhaltene Daten an die Serviceimplementierung weitergereicht. 11
17 2. Grundlagen Konsequenz 2.6 SOA minimiert Annahmen an das Vertrauen [OAS06]. Daher benötigt ein Service eine qualitativ hochwertige Implementierung und Dokumentation, um Wiederverwendbarkeit und Unabhängigkeit zu garantieren Plattformen für Unternehmensanwendungen Eine SOA wird häufig unter Einsatz einer Plattform zur Realisierung von serverseitigen Anwendungen umgesetzt. Bei der Betrachtung mehrerer Plattform wird ein einheitlicher Sprachschatz notwendig. Zur Herleitung sei zunächst die Java Enterprise Edition (Java EE) herangezogen und die Begriffe nach [JBC + 07] mit neutraler Namensgebung kurz vorgestellt: Applikationen werden aus Enterprise Komponenten aufgebaut. Ein Container bildet die Schnittstelle zwischen einer Enterprise Komponente und einer plattformspezifischen Implementierung zur Unterstützung der Enterprise Komponente. D.h. erst durch einen Container wird eine Enterprise Komponente nutzbar. Ein Web Container verwaltet die Enterprise Komponenten, die öffentlich in einem Netz angeboten werden. Ein Applikationsserver ist die äußere Verwaltungseinheit von mindestens einem Container. Der Vorgang zur Übertragung einer Enterprise Komponente in einen Container heißt Bereitstellung. Serverseitige Anwendungen sind mit der Java EE oder dem Microsoft.NET Framework (.NET ) realisierbar. Java EE und.net heißen Enterprise Plattformen. Als Versionen seien in dieser Arbeit Java EE 5.0 und.net 2.0 angenommen. Im Folgenden sei eine Auswahl von verfügbaren Web Containern bzw. Applikationsservern angegeben: Java EE: Apache Tomcat (Web Container), JBOSS (Applikationsserver)..NET: ASP.NET Development Server (Web Container), Internet Information Services (Applikationsserver) 2.4. Webservices Grundbegriffe Webservices sind eine Möglichkeit eine SOA zu realisieren. Sie sind so entworfen, dass eine plattformunabhängige Kommunikation zwischen Maschinen möglich wird [W3C04]. Deshalb stützen sich Webservices auf die Extensible Markup Language (XML) [W3C], einem Standard zur textbasierten Repräsentation von Daten. Eine Serviceschnittstelle wird definiert mit der Web Service Description Language 12
18 2. Grundlagen (WSDL) [W3C07]. Die Kommunikation erfolgt über Nachrichten, die mit dem Simple Object Access Protocol kodiert sind (SOAP). Das verwendete Protokoll zur Übertragung dieser Nachrichten wird in der Serviceschnittstelle festgelegt. Sowohl die WSDL, als auch SOAP basieren auf XML und sind somit auf mehreren Plattformen einsetzbar. Das Protokoll zum Auffinden von Webservices ist für den Verlauf dieser Arbeit unerheblich und wird daher nicht angeführt. Dienste bietet ein Webservice über Operationen an, die ein Servicekonsument nutzt. In der Serviceschnittstelle sind dazu die Eingabeparameter und der Rückgabewert jeder Operation definiert. Heutzutage werden Webservices oftmals mit Enterprise Plattformen durch Erstellung einer Enterprise Komponente implementiert. Dabei verbirgt die eingesetzte Entwicklungsumgebung und Enterprise Plattform die Komplexität bei der Erstellung eines Webservices. In Java EE und analog in.net erstellt der Entwickler einen Webservice mit Klassen, die durch zusätzliche Metainformationen so annotiert werden [JBC + 07], dass ein Web Container automatisch die Serviceschnittstelle generiert. Zur Kommunikation und Interaktion wird ein Proxy eingesetzt, der den Austausch von SOAP- Nachrichten versteckt [MTSM03]. Abbildung 2.2 zeigt eine typische Architektur von Enterprise Komponenten, die einen Webservice implementieren. Konsument Dienstschnittstellenschicht Servicevertrag Kommunikation Betriebsmanagement Sicherheit Geschäftsschicht Geschäftslogik Serviceadapter Geschäftsworkflow Geschäftselemente Ressourcenzugriffsschicht Datenzugriffslogik Dienstagenten Service Datenquellen Services Abbildung 2.2.: Webservice Referenzarchitektur [Sko06] 13
19 2. Grundlagen Webservices stellen die Konkretisierung einer SOA dar, so dass neue Konsequenzen entstehen. Konsequenz 2.7 Viele Unternehmen setzen Webservices ohne Serviceregister ein [MTSM03], d.h. die Vollständigkeit bei der Implementierung einer SOA variiert. Ein Serviceregister erlaubt z.b. den Serviceanbieter zu wechseln, ohne dass ein Servicekonsument Änderungen in seiner Applikation vornehmen muss. Dennoch erhalten Kunden oft direkt die Endpunkte von Webservices. Konsequenz 2.8 Webservices werden in verteilten Anwendungen eingesetzt, d.h. die Interaktion mit einem Webservice ist entfernt. Jeder Webservice repräsentiert mehrere entfernte Prozeduren. Dabei erfolgt nach Definition 2.5 die Interaktion mit einem Webservice über Nachrichten Webservice Standards Neben Standards, die grundlegende Eigenschaften für Webservices festlegen, erfordern bestimmte Anforderungen an die Kommunikation Erweiterungen des SOAP und der WSDL. Webservice Standards zur interoperablen Realisierung von z.b. Sicherheit oder Transaktionen adressieren dieses Problem. Für den Verlauf dieser Arbeit ist nur die Kenntnis von Webservice Standards relevant, spezielle Eigenschaften sind zu vernachlässigen Zusammenfassung In diesem Kapitel wurden alle notwendige Grundlagen und Begriffe vorgestellt, die für den weiteren Verlauf dieser Arbeit von Bedeutung sind: Eine Teststrategie als Zuordnung von Testaspekten zu Teststufen. Serviceorientierte Architekturen als ein Stil Anwendungen zu strukturieren. Die häufige Umsetzung einer SOA mit Enterprise Plattformen. Webservices als dominierende Realisierung einer SOA. In den folgenden Kapiteln sind die vorgestellten Begriffe aus dem Bereich des Testens und SOA zu vereinen, um eine Teststrategie für eine SOA zu definieren. Im Allgemeinen präsentieren die folgenden Kapitel alle Konzepte, Ergebnisse und Werkzeuge, die im Rahmen dieser Arbeit entstanden sind. 14
20 3. Ableitung einer Teststrategie für serviceorientierte Architekturen Bevor man eine Teststrategie für eine SOA formulieren kann, sind alle Einflüsse gezielt zu identifizieren. Besonders die möglichen Variationen zur Realisierung einer SOA erfordern zunächst ein allgemeines Vorgehen zur Findung der Teststrategie. Abschnitt 3.1 beschreibt das genaue Umfeld, das durch eine gefundene Teststrategie abgedeckt wird und welche Besonderheiten zu ignorieren sind. Services bilden als aktive Einheiten den Kern einer SOA, indem sie Funktionalitäten zur Verfügung stellen. Die Betrachtung von Teststufen in einer Teststrategie erfordert neue Sichtweisen aufgrund der in Kapitel 2 vorgestellten Natur von Services. Alle Überlegungen berücksichtigen die folgenden vier Anforderungen an eine Teststrategie [KBP02]: Produktspezifisch: Eine produkt- und technologiespezifische Teststrategie ist besser als eine allgemeine Teststrategie. Risikospezifisch: Die Teststrategie adressiert die wichtigsten Probleme. Vielfältig: Eine vielfältige Teststrategie setzt auf mehrere Testmethoden, um Fehler zu finden, die eine andere Testmethode übersehen hat. Praktikabel: Die Teststrategie ist einsetzbar und schlägt nichts vor, dass jenseits der Ressourcen eines Projekts liegt oder technisch nicht umsetzbar ist Einordnung der Teststrategie Kapitel 2 hat das Testumfeld einer SOA aufgezeigt. Durch die vielfältigen Einheiten in einer SOA entstehen Fehlerquellen, die es gezielt zu identifizieren gilt. Die beiden Hauptmerkmale einer SOA sind das SOA-Dreieck und als Konsequenz der Verbund von Services zu Kompositionen. Das erweiterte SOA-Dreieck aus Abbildung 2.1 hat vier Rollen aufgezeigt, von denen jede Einfluss auf die Teststrategie nehmen kann. Die einzelnen Aktivitäten und Interessen beim Testen stellen sich für jede Rolle wie folgt dar: Servicekonsument: Ein Servicekonsument prüft, ob das Finden eines Services und die Interaktion mit ihm korrekt arbeiten. Serviceanbieter: Ein Serviceanbieter testet, ob die angebotene Infrastruktur den Anforderungen zur Bereitstellung des Services genügt. 15
Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen
9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.
MehrTestplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013
Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael
MehrDiplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
Mehr.. für Ihre Business-Lösung
.. für Ihre Business-Lösung Ist Ihre Informatik fit für die Zukunft? Flexibilität Das wirtschaftliche Umfeld ist stärker den je im Umbruch (z.b. Stichwort: Globalisierung). Daraus resultierenden Anforderungen,
MehrBeschreibung des MAP-Tools
1. Funktionen des MAP-Tool 2. Aufbau des MAP-Tools 3. Arbeiten mit dem MAP-Tool Beschreibung MAP-Tool.doc Erstellt von Thomas Paral 1 Funktionen des MAP-Tool Die Hauptfunktion des MAP-Tools besteht darin,
MehrSoftwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch
Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich
MehrSDD System Design Document
SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen
MehrFassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing
Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster
MehrAutorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente
Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung
MehrSEP 114. Design by Contract
Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit
MehrJava Enterprise Architekturen Willkommen in der Realität
Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen
MehrHandbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken
Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen
MehrAgile Vorgehensmodelle in der Softwareentwicklung: Scrum
C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was
MehrSuche schlecht beschriftete Bilder mit Eigenen Abfragen
Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere
Mehr1 Mathematische Grundlagen
Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.
MehrStep by Step Webserver unter Windows Server 2003. von Christian Bartl
Step by Step Webserver unter Windows Server 2003 von Webserver unter Windows Server 2003 Um den WWW-Server-Dienst IIS (Internet Information Service) zu nutzen muss dieser zunächst installiert werden (wird
MehrObjektorientierte Programmierung für Anfänger am Beispiel PHP
Objektorientierte Programmierung für Anfänger am Beispiel PHP Johannes Mittendorfer http://jmittendorfer.hostingsociety.com 19. August 2012 Abstract Dieses Dokument soll die Vorteile der objektorientierten
MehrInhalt. 1 Einleitung AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER
AUTOMATISCHE DATENSICHERUNG AUF EINEN CLOUDSPEICHER Inhalt 1 Einleitung... 1 2 Einrichtung der Aufgabe für die automatische Sicherung... 2 2.1 Die Aufgabenplanung... 2 2.2 Der erste Testlauf... 9 3 Problembehebung...
MehrStandard Inhaltsverzeichnis für Testvorschrift
Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2
MehrDas System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.
Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt
MehrPrimzahlen und RSA-Verschlüsselung
Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also
MehrEinführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
Mehr7HVWHQYRQ6$3$QZHQGXQJHQPLWGHP([WHQGHG &RPSXWHU$LGHG7HVW7RROH&$77
7HVWHQYRQ6$3$QZHQGXQJHQPLWGHP([WHQGHG &RPSXWHU$LGHG7HVW7RROH&$77 (LQOHLWXQJ Mit der SAP Testworkbench und dem Testtool ecatt können Anwender von SAP Software auf Basis des SAP Web Application Servers ab
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
MehrZeichen bei Zahlen entschlüsseln
Zeichen bei Zahlen entschlüsseln In diesem Kapitel... Verwendung des Zahlenstrahls Absolut richtige Bestimmung von absoluten Werten Operationen bei Zahlen mit Vorzeichen: Addieren, Subtrahieren, Multiplizieren
MehrOutsourcing und Offshoring. Comelio und Offshoring/Outsourcing
Outsourcing und Offshoring Comelio und Offshoring/Outsourcing INHALT Outsourcing und Offshoring... 3 Comelio und Offshoring/Outsourcing... 4 Beauftragungsmodelle... 4 Projektleitung vor Ort und Software-Entwicklung
MehrStuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.
StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige
Mehretutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche
etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:
MehrVermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.
1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich
MehrBSV Ludwigsburg Erstellung einer neuen Internetseite
BSV Ludwigsburg Erstellung einer neuen Internetseite Änderungshistorie Version Datum Bearbeiter Änderung 0.1 02.06.2012 A. Lorenz Neuanlage Seite 1/9 1 Inhaltsverzeichnis: 1 Inhaltsverzeichnis:... 2 2
MehrIT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit
IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrRequirements Engineering für IT Systeme
Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein
MehrÜbung: Verwendung von Java-Threads
Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum
MehrUse Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
MehrBeweisbar sichere Verschlüsselung
Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 6
MehrFolgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert:
Firewall für Lexware professional konfigurieren Inhaltsverzeichnis: 1. Allgemein... 1 2. Einstellungen... 1 3. Windows XP SP2 und Windows 2003 Server SP1 Firewall...1 4. Bitdefender 9... 5 5. Norton Personal
MehrErfolgreiche Webseiten: Zur Notwendigkeit die eigene(n) Zielgruppe(n) zu kennen und zu verstehen!
Erfolgreiche Webseiten: Zur Notwendigkeit die eigene(n) Zielgruppe(n) zu kennen und zu verstehen! www.wee24.de. info@wee24.de. 08382 / 6040561 1 Experten sprechen Ihre Sprache. 2 Unternehmenswebseiten
MehrKlausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Prof. Dr. Peter Becker Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
MehrInstallation und Inbetriebnahme von SolidWorks
Inhaltsverzeichnis FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN I Prof. Dr.-Ing. Frank Lobeck Installation und Inbetriebnahme von SolidWorks Inhaltsverzeichnis Inhaltsverzeichnis... I 1. Einleitung... 1 2. Installation...
MehrIst Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers
Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,
MehrIntegration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.
Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung
MehrBarrierefreie Webseiten erstellen mit TYPO3
Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute
MehrDatensicherung. Beschreibung der Datensicherung
Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten
MehrGrundbegriffe der Informatik
Grundbegriffe der Informatik Einheit 15: Reguläre Ausdrücke und rechtslineare Grammatiken Thomas Worsch Universität Karlsruhe, Fakultät für Informatik Wintersemester 2008/2009 1/25 Was kann man mit endlichen
MehrIGT-Richtlinie 01: Anforderungen an Smarthome-Systeme
Bewertungskriterien inklusive Vorlagen zur Unterscheidung der Funktionalität von Smarthome- Systemen aus Nutzersicht bzw. aus technischer Sicht. Version 03, August 2015 Prof. Dr. Michael Krödel IGT - Institut
MehrGEORG.NET Anbindung an Ihr ACTIVE-DIRECTORY
GEORG.NET Anbindung an Ihr ACTIVE-DIRECTORY Vorteile der Verwendung eines ACTIVE-DIRECTORY Automatische GEORG Anmeldung über bereits erfolgte Anmeldung am Betriebssystem o Sie können sich jederzeit als
MehrFehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems
Fehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems Name: Bruno Handler Funktion: Marketing/Vertrieb Organisation: AXAVIA Software GmbH Liebe Leserinnen und liebe Leser,
MehrKlassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java
Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte
MehrLineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
MehrAlbert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen
Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.
MehrObjektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt
Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse
MehrHP Service Virtualization. Bernd Schindelasch 19. Juni 2013
HP Service Virtualization Bernd Schindelasch 19. Juni 2013 Agenda EWE TEL GmbH Motivation Proof of Concept Ausblick und Zusammenfassung HP Software Performance Tour 2013: HP Service Virtualization 2 EWE
MehrSoftwaretechnische Anforderungen zu Opale bluepearl Version 1.0 vom 23.05.2013
Sehr geehrte Kundin, Sehr geehrter Kunden. Sie werden demnächst die neue Version Opale bluepearl einsetzen. Damit Sie bestmöglich von der 3ten Generation der Opale-Lösungen profitieren können, ist es an
MehrFirewalls für Lexware Info Service konfigurieren
Firewalls für Lexware Info Service konfigurieren Inhaltsverzeichnis: 1. MANUELLER DOWNLOAD 1 2. ALLGEMEIN 1 3. EINSTELLUNGEN 1 4. BITDEFENDER VERSION 10 2 5. GDATA INTERNET SECURITY 2007 4 6. ZONE ALARM
MehrProfessionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
MehrIn diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.
Tutorial: Wie erfasse ich einen Termin? In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Neben den allgemeinen Angaben zu einem
MehrAgile Software Verteilung
Agile Software Verteilung Vortrag: René Steg Steg IT-Engineering, Zürich (Schweiz) Gründe für Agile Software-Verteilung Wenn Sie Hunderte von Servern mit vielen Anwendungen betreiben Verteilte Anwendungen
MehrT1 - Fundamentaler Testprozess
AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In
Mehr2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Lernziele:
2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Configuring Terminal Services o Configure Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp) o Configure Terminal Services Gateway
MehrFachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer
Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,
MehrIst Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?
UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.
MehrBüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen
BüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen Stand: 13.12.2010 Die BüroWARE SoftENGINE ist ab Version 5.42.000-060 in der Lage mit einem Microsoft Exchange Server ab Version 2007 SP1
Mehr50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte
50. Mathematik-Olympiade. Stufe (Regionalrunde) Klasse 3 Lösungen c 00 Aufgabenausschuss des Mathematik-Olympiaden e.v. www.mathematik-olympiaden.de. Alle Rechte vorbehalten. 503 Lösung 0 Punkte Es seien
MehrZustandsgebundene Webservices
Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite
MehrDaniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers
Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des
MehrProjektmanagement in der Spieleentwicklung
Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren
MehrFachbericht zum Thema: Anforderungen an ein Datenbanksystem
Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank
MehrSERVICE SUCHE ZUR UNTERSTÜTZUNG
SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte
MehrERSTELLEN VON INCENTIVES IM ZANOX NETZWERK
ERSTELLEN VON INCENTIVES IM ZANOX NETZWERK USER GUIDE FÜR ADVERTISER INHALTSVERZEICHNIS 1. Einführung...3 2. Incentives veröffentlichen...4 3. Weitere Funktionen...9 ZANOX.de AG Erstellen von Incentives
MehrSoftware Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle
MehrMotivation. Formale Grundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen. Informales Beispiel. Informales Beispiel.
Kontextfreie Kontextfreie Motivation Formale rundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen Bisher hatten wir Automaten, die Wörter akzeptieren Frank Heitmann heitmann@informatik.uni-hamburg.de
MehrDatenbank-Verschlüsselung mit DbDefence und Webanwendungen.
Datenbank-Verschlüsselung mit DbDefence und Webanwendungen. In diesem Artikel werden wir Ihnen zeigen, wie Sie eine Datenbank verschlüsseln können, um den Zugriff einzuschränken, aber trotzdem noch eine
MehrAnalyse zum Thema: Laufzeit von Support-Leistungen für ausgewählte Server OS
Analyse zum Thema: Laufzeit von Support-Leistungen für Axel Oppermann Advisor phone: +49 561 506975-24 mobile: +49 151 223 223 00 axel.oppermann@experton-group.com Januar 2010 Inhalt Summary und Key Findings
MehrKonsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt
Konsolidierung und Neuimplementierung von VIT Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Inhaltsverzeichnis 1 Was ist der Kontext?... 1 2 VIT: Ein sehr erfolgreiches
MehrRobot Karol für Delphi
Robot Karol für Delphi Reinhard Nitzsche, OSZ Handel I Version 0.1 vom 24. Januar 2003 Zusammenfassung Nach der Einführung in die (variablenfreie) Programmierung mit Robot Karol von Freiberger und Krško
MehrCode wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015
Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum
MehrReporting Services und SharePoint 2010 Teil 1
Reporting Services und SharePoint 2010 Teil 1 Abstract Bei der Verwendung der Reporting Services in Zusammenhang mit SharePoint 2010 stellt sich immer wieder die Frage bei der Installation: Wo und Wie?
MehrOhne Fehler geht es nicht Doch wie viele Fehler sind erlaubt?
Ohne Fehler geht es nicht Doch wie viele Fehler sind erlaubt? Behandelte Fragestellungen Was besagt eine Fehlerquote? Welche Bezugsgröße ist geeignet? Welche Fehlerquote ist gerade noch zulässig? Wie stellt
MehrEinsatz von xalerator. bei den. Ergo Direkt Versicherungen. Bereich Versicherungstechnik/Leben
Einsatz von xalerator bei den Ergo Direkt Versicherungen Bereich Versicherungstechnik/Leben Einführung Die Ergo Direkt Versicherungen wurden 1984 als Finanzdienstleistungs-Segment des Quelle Versandhandels
MehrJava und XML 2. Java und XML
Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003
MehrÜbungsklausur vom 7. Dez. 2007
Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement
MehrMicrosoft SharePoint 2013 Designer
Microsoft SharePoint 2013 Designer Was ist SharePoint? SharePoint Designer 2013 Vorteile SharePoint Designer Funktionen.Net 4.0 Workflow Infrastruktur Integration von Stages Visuelle Designer Copy & Paste
Mehr«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen
18 «Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen teilnimmt und teilhat.» 3Das Konzept der Funktionalen
MehrSocial-CRM (SCRM) im Überblick
Social-CRM (SCRM) im Überblick In der heutigen Zeit ist es kaum vorstellbar ohne Kommunikationsplattformen wie Facebook, Google, Twitter und LinkedIn auszukommen. Dies betrifft nicht nur Privatpersonen
MehrWhitebox-Tests: Allgemeines
-Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv
MehrAnleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH
Amt für Informatik Anleitung mtan (SMS-Authentisierung) mit SSLVPN.TG.CH Anleitung vom 12. September 2009 Version: 1.0 Ersteller: Ressort Sicherheit Zielgruppe: Benutzer von SSLVPN.TG.CH Kurzbeschreib:
Mehr«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»
«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING
MehrC++11 C++14 Kapitel Doppelseite Übungen Musterlösungen Anhang
Einleitung Dieses Buch wendet sich an jeden Leser, der die Programmiersprache C++ neu lernen oder vertiefen möchte, egal ob Anfänger oder fortgeschrittener C++-Programmierer. C++ ist eine weitgehend plattformunabhängige
MehrAgiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin
Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen
MehrSoftware - Testung ETIS SS05
Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks
MehrLizenzierung von System Center 2012
Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im
MehrVortrag von: Ilias Agorakis & Robert Roginer
MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile
MehrTask: Nmap Skripte ausführen
Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses
MehrSoftwareentwicklungspraktikum Sommersemester 2007. Grobentwurf
Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig
Mehrteischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep
teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep 1. Erstellen Sie ein neues Rechnungsformular Mit book n keep können Sie nun Ihre eigenen
MehrZENITY - Die Software für Ihre Unternehmens-Releaseplanung
ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen
MehrNeue Funktionen in Innovator 11 R5
Neue Funktionen in Innovator 11 R5 Innovator for Enterprise Architects, Java Harvester und Prüfassistent 12.11.2013 Agenda 1 2 3 Einführung Was ist neu in Innovator 11 R5? Szenario Enterprise Architektur
MehrResearch Note zum Thema: Laufzeit von Support-Leistungen für Server OS
Research Note zum Thema: Laufzeit von Support-Leistungen für Axel Oppermann Advisor phone: +49 561 506975-24 mobile: +49 151 223 223 00 axel.oppermann@experton-group.com November 2009 Inhalt 1 EINFÜHRUNG
Mehr