Testen von serviceorientierten Architekturen: Teststrategie und Implementierung

Größe: px
Ab Seite anzeigen:

Download "Testen von serviceorientierten Architekturen: Teststrategie und Implementierung"

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

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Software - Testung ETIS SS05

Software - 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

Mehr

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2) Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. 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

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

Java und XML 2. Java und XML

Java 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

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag 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

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Unit Testing mit JUnit. Dr. Andreas Schroeder

Unit Testing mit JUnit. Dr. Andreas Schroeder Unit Testing mit JUnit Dr. Andreas Schroeder Überblick Was dieses Video behandelt Warum Testen? Was sind Unit Tests? Der Teufelskreis des Nicht-Testens JUnit Unit Test Vorteile Test-Inspiration Wann aufhören?

Mehr

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung Methoden und Werkzeuge zur Softwareproduktion WS 2003/04 Karsten Beyer Dennis Dietrich Überblick Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung 2 Motivation Funktionstest

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE 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

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Modellgetriebene Service-Entwicklung

Modellgetriebene Service-Entwicklung Modellgetriebene Service-Entwicklung Service-orientierte Architekturen (SOA), Prof. Dr. M. Jäger Johannes Tietje 24. Juni 2010 1 / 13 Motivation konkrete Teile eines Dienstes Rahmenimplementierung der

Mehr

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Automatisiertes UI Testing. Mark Allibone, 18.04.2013, #2

Automatisiertes UI Testing. Mark Allibone, 18.04.2013, #2 Coded UI Testing Automatisiertes UI Testing Mark Allibone, 18.04.2013, #2 Eine klassische Applikations Architektur Grafische Oberfläche Business Logik Datenzugriff (Datenbank, Cloud, etc) Mark Allibone,

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

HP Service Virtualization. Bernd Schindelasch 19. Juni 2013

HP 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

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

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.

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Zustandsgebundene Webservices

Zustandsgebundene 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

Mehr

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

Mehr

Standard Inhaltsverzeichnis für Testvorschrift

Standard 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

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

.. für Ihre Business-Lösung

.. 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,

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Übersicht zu den Inhalten der Vorlesung) Somemrsemester 2013 1 Ziele und Abgrenzung 2 Allgemeine Lernziele Vermittlung von Basiskenntnissen

Mehr

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1. Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung

Mehr

T1 - Fundamentaler Testprozess

T1 - 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

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

CBIS - CARE BED INFORMATION SYSTEM

CBIS - CARE BED INFORMATION SYSTEM CBIS - CARE BED INFORMATION SYSTEM Test Plan Dokumentänderungen Version # Datum Ersteller Beschreibung V1.0 18.04.2010 Anna Bruseva Erste Version Inhaltsverzeichnis 1 INTRODUCTION...2 2 TESTKOMPONENTEN...2

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Bachelor Thesis an der Fachhochschule Kiel, Fachbereich Wirtschaft. Sommersemester 2011. : Prof. Dr. Doris Weßels

Bachelor Thesis an der Fachhochschule Kiel, Fachbereich Wirtschaft. Sommersemester 2011. : Prof. Dr. Doris Weßels Handlungsempfehlungen zur Nutzung von Social Media zur Gestaltung von Wissensmarktplätzen am Beispiel des europäischen Förderprojektes Win-Vin: Wissen nutzen im Norden Bachelor Thesis an der Fachhochschule

Mehr

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Herausforderungen bei agilem Testen Klassische Projektstruktur Projektleiter Entwickler QS-Abteilung

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving)

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving) Universität Paderborn Die Universität der Informationsgesellschaft Analyse, Entwurf und Implementierung zuverlässiger Software und (inkl., Model-Checking, Theorem Proving) Torsten Bresser torbre@uni-paderborn.de

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles 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

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

7HVWHQYRQ6$3$QZHQGXQJHQPLWGHP([WHQGHG &RPSXWHU$LGHG7HVW7RROH&$77

7HVWHQYRQ6$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

Mehr

IGT-Richtlinie 01: Anforderungen an Smarthome-Systeme

IGT-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

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. 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

Wissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider

Wissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider Wissenschaftliche Vertiefung Web Services Esslingen, 22. Januar 2016 Agenda 1. Einführung 2. Serviceorientierte Architektur 3. SOAP Web Service 4. Standards und Protokolle von SOAP Web Services 5. Bewertung

Mehr

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal Web Services - Brian Connel: The Seven Pillars of Web Services Management - IBM: IBM Strategy for management of the WebServices infrastrucutre Seminarvortrag von Lukasz Kidawski im Rahmen der Lehrveranstaltung

Mehr

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004 Ausarbeitung über SS 2004 Dennis Völker [dv04@hdm-stuttgart.de] Steffen Schurian [ss59@hdm-stuttgart.de] Überblick Sicherheit sollte eine Eigenschaft moderner, verteilter Anwendungen sein, jedoch ist ein

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Entwicklungswerkzeuge

Entwicklungswerkzeuge Entwicklungswerkzeuge Werner Struckmann & Tim Winkelmann 10. Oktober 2012 Gliederung Anforderungen Projekte Debugging Versionsverwaltung Frameworks Pattern Integrated development environment (IDE) Werner

Mehr

SDD System Design Document

SDD 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

Mehr

Sof o t f waretechn h o n l o og o i g en n f ü f r ü v e v rteilte S yst s eme Übung

Sof o t f waretechn h o n l o og o i g en n f ü f r ü v e v rteilte S yst s eme Übung Softwaretechnologien für verteilte Systeme Übung Organisatorisches Gruppen mit 3-4 Personen bearbeiten ein zugewiesenes Thema Abgabe besteht aus einer Arbeit mit 10-15 Seiten und ~30 Minuten Präsentation

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.

Mehr

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

ISTQB Certified Tester Foundation Level Exam Übungsprüfung

ISTQB Certified Tester Foundation Level Exam Übungsprüfung BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten

Mehr

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010 Architekturentscheidungen für große langlebige Softwaresysteme: Vendor-Lock-in- und Netz-Effekte Menschen beraten Menschen beraten BTC zeigt Wege auf - Sie entscheiden BTC zeigt Wege auf - Sie entscheiden

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit 1 DYNAMISCHER TEST Whitebox Testen mit JUnit Übersicht 2 1. Grundlagen des Unittests 1. Units 2. Unit Testing 2. Testverfahren 1. Blackbox 2. Whitebox 3. Unit Testing mit Eclipse 4. Besprechung der Übungsaufgabe

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

Neue Funktionen in Innovator 11 R5

Neue 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

Mehr

Programmiertechnik II

Programmiertechnik II Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen Enterprise Applikation Integration und Service-orientierte Architekturen 08 Einführung Service-Orientierte Architekturen Ist SOA immer noch aktuell? Prof. Dr. Holger Wache http://bhc3.files.wordpress.com/2009/07/gartner-emerging-technologies-hype-cycle-2009.png?w=552&h=451

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

Java Message Service im J2EE-Kontext

Java Message Service im J2EE-Kontext Java Message Service im J2EE-Kontext Im Folgenden soll kurz das Konzept der nachrichtenorientierten Kommunikation mit Hilfe von Messaging Services vorgestellt, und im Anschluss deren Einsatzmöglichkeiten

Mehr

Java Applet Alternativen

Java Applet Alternativen White Paper Java Applet Alternativen Version 1.0, 21.01.2014 Tobias Kellner tobias.kellner@egiz.gv.at Zusammenfassung: Aufgrund diverser Meldungen über Sicherheitslücken in Java haben in letzter Zeit Browser-Hersteller

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Modes And Effect Analysis)

Modes And Effect Analysis) Gefahrenanalyse mittels FMEA (Failure Modes And Effect Analysis) Vortragender: Holger Sinnerbrink Betreuer: Holger Giese Gefahrenanalyse mittels FMEA Holger Sinnerbrink Seite: 1 Gliederung Motivation Einordnung

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Software- Qualitätsmanagement

Software- Qualitätsmanagement Software- Qualitätsmanagement Thomas Kugel Brandenburg, den 10.12.2002 Agenda Einleitung Was heißt Softwarequalitätssicherung und Test Die Rolle von Test und QS in Softwareprojekten Wie wird getestet Statische

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr