Veröffentlichen auch Sie Ihre Arbeiten - es ist ganz einfach!
Mehr InfosBachelorarbeit, 2010, 64 Seiten
Bachelorarbeit
1
1. Einführung
1.1 Stahl Control
1.2 Business Control Software GmbH
1.3 Conzept 16
1.4 Serviceorientierung
1.5 Der C16 SOA Server
2. Aufgabenstellung
2.1 Erweiterung Stahl Control
2.2 Servicenutzung im WEB
2.3 Abgrenzung
3. Aufgabenanalyse
3.1 Anforderungsanalyse
3.2 Anwendungsfälle
3.3 Aktivitäten
3.4 Datenstrukturen
3.5 Benutzeroberfläche
3.6 Pflichtenheft
4. Implementierungsdetails
4.1 Datenbankstruktur
4.2 Prozedurstruktur
4.2.1 Bibliotheken
4.2.2 Controller
4.3 Fehlerbehandlung
4.4 Architektur
4.4.1 Technik
4.4.2 Servicelayer
4.4.3 Servicemanager
4.4.4 Serviceinventar
4.4.5 Serviceimplementierung
4.4.6 Protokollierung
4.5 Stahl Control Integration
4.5.1 Stammdaten
4.5.2 Serviceinventar
4.6 Beispielanwendung
4.6.1 Technik
4.6.2 Architektur
4.6.3 Abfragen von Services
4.6.4 Empfangen von Antworten
4.6.5 Verarbeitung
4.6.6 Darstellung
5. Fazit
6. Ausblick
Glossar
Abbildungsverzeichnis
Tabellenverzeichnis
Quellcodeverzeichnis
Literaturverzeichnis
Anlagen
Eidesstattliche Versicherung
Serviceorientierte Architekturen, kurz SOA, haben in den letzten Jahren immer mehr an Bedeutung gewonnen. Flexible Märkte benötigen eine flexible Anpassung der Unternehmen. Konzerne erweitern durch Übernahme von Unternehmen ihr Angebotsspektrum oder erlangen andere Marktvorteile. Die Anforderungen des Marktes leiten die Unternehmen als die Anforderungen an die IT Infrastruktur weiter. Um diesen Anforderungen gerecht zu werden, ist jedoch ein Umdenken innerhalb der IT und auch der Unternehmensstrategie zur Folge. In diesem Zuge wurden die service-orientierte Architekturen entwickelt. Die Kompositionen einzelner Services bilden Geschäftsprozesse ab. Dies hat den Vorteil, dass einzelne Services ausgetauscht werden können. Hiermit entsteht eine größere Flexibilität, als bestehende Softwareentwicklungen auf neue, vorher nicht bekannte, Anforderungen hin anzupassen.
Diese Arbeit beschreibt den Weg ingenieursmäßiger Planung und Umsetzung der Branchensoftware Stahl Control in serviceorientierte Architekturen zu integrieren. Den Kunden und Eignern soll somit ermöglicht werden, Stahl Control in bestehende Unternehmens- und Konzernstrukturen einzugliedern, sowie bestehende Software mit Stahl Control kommunizieren zu lassen.
Die Business Control Software GmbH erwartet durch diese Entwicklung, dass Konzerne, die Stahl Control Kunden übernommen haben, die bestehende Software weiternutzen und in das Gesamtkonzept ihrer IT Umgebung eingliedern. Ferner ist geplant, Stahl Control Module durch Services im Web zugänglich zu machen und diese für mobile Endgeräte anzupassen.
Fachbegriffe, die im Glossar erläutert werden, sind im folgenden Text fett und kursiv dargestellt.
Stahl Control ist eine Branchensoftware für die weiterverarbeitende Stahlindustrie. Die Software bietet Stahlhändlern und Lohnbearbeitern, sowie Stahl-Servicecentern Funktionen zur Stamm-datenpflege, Auftrags/- Bestellwesen, Materialverwaltung, Produktionsplanung, Finanz- und Qualitätsmanagement[1].
Stahl Control wird momentan in ca. 150 kleinen bis mittelständischen Betrieben im In- und angrenzenden Ausland eingesetzt.
Seit 15 Jahren basiert Stahl Control auf der proprietären Client/Server Datenbank- und Entwicklungsumgebung Conzept 16 aus dem Hause der Vectorsoft AG aus Heusenstamm.
Im Jahr 2000 wurde beschlossen eine neue Version von Stahl Control zu entwickeln. Das bestehende, auf DOS basierende Softwareprodukt ist seitdem unter "Stahl Control Classic"[2] bekannt. Die aktuelle Version trägt den Namen "Stahl Control Windows" und bietet neben MDI-Fenstertechnik weitere Features zur Integration in marktrelevante Office Lösungen.
Die Firma Business Control Software GmbH bietet Services für Stahl Control an und wurde im Jahr 2000 gegründet. Die Geschäftsfelder sind die Weiterentwicklung und Pflege der Software, Support sowie die Anpassung der Kundeninstallationen[3].
Bei Conzept 16 handelt es sich um ein proprietäres Datenbankmanagement System mit integrierter Entwicklungsumgebung . Als Basis dient eine relationale Datenbank. Der Conzept 16 Server ermöglicht die Verwaltung von Benutzern und stellt die Entwicklungsumgebung. Diese ermöglicht das Erstellen der Datenbankstrukturen und regelt die Benutzerverwaltung. Ferner bietet Conzept 16 eine prozedurale, pascalähnliche Programmiersprache. Konstruktionswerkzeuge um Dialoge, Menü-strukturen, Datenselektionen, Reports zu erstellen stehen dem Entwickler zur Verfügung[4].
Conzept 16 hat sich in der Evaluierungsphase im Jahre 2000 als geeignete Basis für die Weiterentwicklung von Stahl Control gegenüber Techniken wie Delphi, C# und PostgreSQL durchgesetzt. Gründe dafür waren das bestehende Lieferantenverhältnis zur Vectorsoft AG bezogen auf den Support und das finanziell attraktivere Lizenzmodell. Desweiteren verfügt Conzept 16 über einfache Auslieferungsmechanismen für entwickelte Applikationen. Ferner obliegt die Garantie der Lauffähigkeit des Datenbankservers und Clients nicht bei der Business Control Software GmbH. Abhängigkeiten von Funktionsbibliotheken in der Laufzeitumgebung liegen im Verantwortungs-bereich der Vectorsoft AG. Somit liegt das Hauptaugenmerk der Business Control Software GmbH auf der Entwicklung von Geschäftslösungen und nicht auf der zugrunde-liegenden Technik.
Conzept 16 bietet keine Objektorientierung. Infolge dessen sind einige Elemente des Software Engineering Prozesses nicht anwendbar. Bei der Objektorientierten Analyse muss in diesem Fall auf Klassen- und Sequenzdiagramme verzichtet werden. Im Kapitel "Aufgabenanalyse" wird dieses Thema noch weiter behandelt.
Durch die Verwendung der proprietären Datenbank ist die Verwendung von standardisierten Abfrage- und Definitionssprachen nicht möglich . Die Pflege von Datenstrukturen wird ausschließlich über den mitgelieferten Editor ermöglicht. In der optional vorhanden ODBC Schnittstelle von Conzept 16 ist die Datenabfrage zwar möglich, die Manipulation von Datenstrukturen wird jedoch nicht unterstützt.
Die Abfrage von Daten erfolgt durch Iteration der vorhandenen, indizierten Datensätze. Zusätzlich ermöglichen sogenannte Selektionen und Filter eine Vorauswahl über indizierte und nicht indizierte Spalten.
Serviceorientierung ist ein unternehmensweiter, strategischer Ansatz, um eine größtmögliche Flexibilität in der Abarbeitung von Geschäftsprozessen zu etablieren . Seit der Einführung der elektronischen Datenverarbeitung wird Software entwickelt, welche die Geschäftsprozesse von Unternehmen abdecken. Das Ergebnis dieser Entwicklung ist eine Vielzahl von Softwarelösungen, die ihre Aufgaben laut Intention erfolgreich lösen. Um den Wunsch der Interoperabilität mit Fremd-Systemen zu befriedigen, erfordert dies eine Vielzahl von Schnittstellen. Beispiele hierzu sind Schnittstellen zu Finanzbuchhaltungssystemen (zum Beispiel Datev, Coface und weiteren) zum Austausch von Fakturierungsdaten oder Schnittstellen zum Einlesen von Messdaten durch Spektralanalysen. Die Hersteller liefern eine Schnittstellenbeschreibung beziehungsweise setzen diese direkt im Zielsystem um. Der Transport der Daten erfolgt meist manuell per Daten-fernübertragung, FTP, E-Mail, USB-Speicher oder Disketten. Komplexere Vorgänge wie beispielsweise die Übermittlung von Produktionsaufträgen, Lieferanforderungen Et-cetera erfordern komplexere Schnittstellen wie zum Beispiel EDIFACT. Der Transport der Daten steht nicht im Vordergrund. Anpassungen der Geschäftsprozesse erfordert oft die Anpassung der eingesetzten Software.
Durch eine höhere Wettbewerbsintensität sind oben angesprochene Veränderungen der Software-landschaft meist nicht in adäquaten Zeitfenstern realisierbar. Um dieses Problem zu lösen, wurden serviceorientierte Architekturen geschaffen. Im Vergleich zu etablierten IT Strukturen ist festzustellen, dass Softwarelösungen für Geschäftsprozesse nicht starr implementiert werden, sondern aus sogenannten Services zusammengesetzt werden. Dies führt dazu, dass für Geschäftsbereiche eine andere Denke herrschen muss als bei den herkömmlichen Lösungen. Geschäftsprozesse werden serviceorientiert analysiert und danach in Teilservices aufgeteilt. Diese Services werden dann durch Servicekomposition zu einem Geschäftsprozess zusammengeführt.[5]
Die Grundlage von serviceorientierten Architekturen basiert auf mehreren Elementen. Als Basis dient der Enterprise Service Bus. Desweiteren existiert ein Serviceverzeichnis oder auch Serviceinventar, welches jeden verfügbaren Service mit seinen Aufrufparametern und Rückgabewerte kennt und auf Wunsch die Information zur Verfügung stellt. Das kleinste Element der Serviceorientierung stellen die Services dar. Services sind die konkrete Implementierung der Teilprozesse.
Bei dem Enterprise Service Bus (ESB) handelt es sich um eine unternehmensweite Informationsbasis inklusive Transport Protokoll. Jede eingesetzte Software, die unternehmensrelevante Daten verarbeitet oder zur Verfügung stellt, muss diese vom ESB lesen und wieder zurückgeben. Desweiteren etabliert der ESB einen gemeinsamen Standard um auf die Daten zuzugreifen. Um eine neue Software einzuführen, muss diese die Schnittstellen des ESB unterstützen und kann damit zugleich einen Mehrwert für das gesamte Unternehmen, respektive für alle angeschlossenen Prozesse, generieren.
Nicolai Josuttis fasst treffend zusammen, "Ein Enterprise Service Bus (ESB) ist die Infrastruktur einer SOA-Landschaft"[6]
Abbildung 1: Beispiel für einen heterogenen ESB Quelle: Vgl. (Josuttis, 2008) Seite 66
Abbildung in dieser Leseprobe nicht enthalten
Wie eingangs erwähnt, enthält das Serviceinventar alle implementierten Services. In der Regel wird dieses Verzeichnis veröffentlicht. Je nach Intention des Services ist die Verbreitungsweite unterschiedlich. Öffentlich verfügbare WEB Service Anbieter wie z.B. zur Abfrage von Aktienkursen nutzen große Verzeichnisdienste um ihren Service den Nutzern zu kommunizieren. Unternehmensintern benutzte und eigens implementierte Services werden meist nicht in dieser Tragweite publiziert. Das Serviceinventar ist in diesem Fall nur innerhalb der Organisation verfügbar. Desweiteren werden die angesprochenen Verzeichnisdienste und deren Anwendung als "Universal Description, Discovery and Integration protocol", kurz UDDI bezeichnet.[7]
Als Service wird das granularste Element der serviceorientierten Architektur bezeichnet. Ein Service verfügt über definierte Eingabeparameter und Ausgabestrukturen. Die Implementierung eines Services ist für das Gesamtsystem irrelevant. Dies bezieht sich sowohl auf die verwendeten Techniken als auch die Algorithmen. Dies ist notwendig um eine Austauschbarkeit zu garantieren. Ein Service wird in der Regel durch die sogenannte Web Service Description Language (WSDL) beschrieben[8]. Diese wird auf einem Server hinterlegt und kann von den Anwendern abgefragt werden. Diese Datei enthält Schnittstellen- und Laufzeitinformationen des Services.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Servicekomposition innerhalb eines Serviceinventars
Üblicherweise werden serviceorientierte Architekturen durch Webservices abgebildet. Dies be-inhaltet die Transportschicht über das HTTP Protokoll und die Nutzung des „Simple Object Access Protocol (SOAP) als Nachrichtenprotokoll. Ferner ist es auch gebräuchlich, Webservices im firmeninternen Intranet zu benutzen. In dieser Verwendung spricht man jedoch von Netservices[9].
Bei SOAP handelt es sich um einen Standard zur Formung von Nachrichten, dessen Intention die Verwendung in Webservices ist. Als Basis von SOAP dient XML. SOAP umfasst auch den Transport der Daten über HTTP[10].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Zwiebelschalenmodell einer üblichen Webservice Architektur (Quelle: Serviceorientierte Architekturen S. 11)
Seit der Conzept 16 Version 5.0 bietet Vectorsoft die Verwendung des SOA Service an. Der SOA Service ist ein Betriebssystemdienst, der Verbindungen annimmt und die eingehenden Daten in Conzept 16 verfügbar macht. Hierzu benötigt der SOA Service eine Verbindung zu einer Datenbank. Folgend wird die Kombination des laufenden SOA Services und einer konfigurierten Datenbankverbindung als "C16 SOA Server" bezeichnet.
Der SOA Service verfügt über die zwei Betriebsarten TIME und SOCKET[11]. Einerseits lassen sich zeitlich gesteuerte Services implementieren. Dies ermöglicht das Ausführen bestimmter Implementierungen für wiederkehrende Aufgaben, die keine Verbindung über Sockets verfügen. Hierdurch lassen sich z.B. nächtliche Berechnungen auf dem Datenbestand durchführen um den Geschäftsbetrieb nicht zu stören. Bei der zweiten Variante handelt es sich um den SOCKET Betriebsmodus. Dieser ermöglicht die Netzwerkkommunikation über IPv4 Adressen und einem definierten Port.
Für jede eingehende Verbindung wird im ausgeführten Systemprozess ein neuer Thread gestartet, in der für die gesamte Lebensdauer der Anfrage die Bearbeitung durchgeführt wird. Sollte die Abarbeitung einer Anfrage einen Ausnahmefehler erzeugen, gewährleistet Conzept 16 die Weiterausführung des Prozesses, da nur der entsprechende Thread terminiert wird.
Jede Anfrage benötigt eine Verbindung zum Conzept 16 Server und somit auch einen Datenbankbenutzer. Diesem Benutzer werden alle durchgeführten Aktionen im System zugeordnet und die Ergebnisse anhand seiner Benutzerkennung protokolliert. Durch diese Verknüpfung mit Datenbankbenutzern wird eine rudimentäre Zugriffssteuerung auf Tabellenbasis ermöglicht.
Der SOA Service verwendet das HTTP Protokoll[12] für den Datenverkehr. Es werden die Methoden GET und POST für die Befehls/Datenübermittlung benutzt. Die Verwendung von URL, im Sinne der Verwendung von Dateisystemen, entfällt, da keine Dateien angefordert werden. Wahlweise lassen sich die übergebenen Parameter aus dem Header extrahieren. Für das Auslesen der Daten aus dem Nachrichtenrumpf stellt Conzept 16 Funktionen zur Verfügung, bietet jedoch keine Möglichkeit der Unterscheidung, ob es sich um eine Parameterliste handelt oder anders gegliederte Werte in XML oder zum Beispiel JavaScript Object Notation (Json)[13].
Der C16 SOA Service wird über Konfigurationsdateien eingestellt und ist zusätzlich in dem Conzept 16 Control-Center integriert, um den Service separat zu verwalten.
Die Integration des Conzept 16 SOA Service als SOA Server stellt sich in einer typischen Conzept 16 Stahl Control Architektur wie folgt dar.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Erweiterte Systemarchitektur C16 mit Stahl Control und WEB Services
Ziel der hier beschriebenen Entwicklung ist die Möglichkeit Stahl Control in serviceorientierte Umgebungen einzugliedern. Dem Stahl Control Entwickler soll ein einfaches und jedoch je nach Anforderung komplexes Framework zur Verfügung gestellt werden. Anwendungen im WEB sollen die Verwendbarkeit demonstrieren. Aufgrund der bestehenden De-facto-Standards im Bereich SOA, müssen in der Verwendung von Conzept 16 und der Unternehmensstrukturen Abgrenzungen definiert werden.
Stahl Control soll im Kern erweitert werden, sodass einzelne Teile von Geschäftsprozessen von externen Applikationen zugänglich sind und so in ESBs integriert werden können. Hierzu muss der Conzept 16 SOA Server an Stahl Control angebunden und der Datentransport implementiert werden. Hierzu soll ein proprietäres Datenformat definiert werden.
Um die Anfragen zentral zu prüfen muss ein Servicemanagement vorbereitet werden, damit nur wohlgeformte Anfragen auf Stahl Control Zugriff erlangen. Zusätzlich zur Prüfung der gesendeten Parameter soll auch eine Zugriffskontrolle erfolgen.
Alle implementierten Stahl Control Services sollen zentral verwaltet und über gezielte Zugriffserlaubnisse für Vertreter, Kunden, Lieferanten und Verbänden zur Verfügung gestellt werden. Die Protokollierung der Anfragen soll für spätere Monetarisierungsmöglichkeiten implementiert werden.
Insbesondere Reports spielen zur Abfrage von aktuellen Datensätzen eine große Rolle. Somit können interessierte Drittparteien die für sie relevanten Daten aktiv abrufen und in ihre Geschäftsabläufe integrieren.
Desweiteren sollen Services zum Schreiben von Daten erstellt werden. Dies soll die externe Eingabe von Daten ermöglichen. Ein Anwendungsfall wäre das Erfassen von Lieferavisierungen direkt durch den Lieferanten.
Durch die Bereitstellung von Services und der entsprechenden Schnittstellenbeschreibung soll es Drittanbietern möglich sein, Eingabe und Abfragemasken für Stahl Control zu entwickeln, um Informationen abzufragen. Als mögliche Zielplattformen bieten sich Internetseiten oder auch mobile Endgeräte an.
Konkret sollen vier Beispielservices realisiert werden um die Funktionalität zu demonstrieren. Die Services "Kundenfertigmaterial" und "Freies Material" sollen die Verwendung von lesenden Services zeigen. Diese beiden Services korrelieren mit den Listen in Stahl Control, die als Reports bekannt sind. Als schreibender und somit direkt eingreifender Service soll die Erstellung von Lieferavisierungen in Stahl Control angeboten werden. Für die genannten Services ist die Angabe von Schlüsseldateien aus Stahl Control notwendig. Hierzu zählen beispielsweise vordefinierte Warengruppen, Länderkennzeichen, Lieferbedingungen Et-cetera. Demnach wird ein vierter Service angeboten, der die Schlüsseldateien ausliest, um in Fremdanwendungen Bezüge herzustellen.
Um die vorherig beschriebenen Service zu nutzen, ist die Entwicklung eines Frontends erforderlich. Dieses soll externen Entwicklern die Möglichkeit geben, die rudimentäre Funktionsweise von Stahl Control Webservices zu verstehen und zu verwenden.
Um dies zu ermöglichen, sollen die marktüblichen Produkte/Techniken[14] Apache Webserver, PHP, JavaScript, (X)HTML / CSS und Ajax verwendet werden.
Wie eingehend beschrieben, werden vorhandene Services in einem Serviceverzeichnis angeboten und veröffentlicht. Ein öffentliches Serviceverzeichnis ist nicht Teil der Stahl Control Webservices. Die Stahl Control Webservices werden einem definierten Anwenderkreis zur Verfügung gestellt. Diese werden durch die Business Control Software GmbH bei der Integration unterstützt. Die benötigten Schnittstellen werden je nach Kundenanforderungen entwickelt und dem Kunden zur Verfügung gestellt. Service-Level-Agreements (SLA) stellen die Grundlage der Zusammenarbeit zwischen dem Kunden, Business Control Software GmbH und dem Servicenutzer.
Auf die Verwendung von SOAP wird verzichtet. Zusätzliche Dateien zur Benutzung und Entwicklung von Stahl Control Webservices ist nicht erwünscht. Hierdurch ist es nicht notwendig WDSL Beschreibungen auszuliefern und zu warten. Da jeder Service eine Individualentwicklung darstellt, würde diese Technik die Implementierung verlangsamen.
Komplexe Sicherheitsmechanismen werden vorerst nicht implementiert. Als rudimentäres Autorisierungselement erfolgt die Verwendung von Benutzeridentifikation und Passwort. Übliche Angriffsszenarien per SQL Injection sind ausgeschlossen, da SQL in Conzept 16 keine Verwendung findet.
Der Focus der Implementierung richtet sich auf die interne Weiterentwicklung von Stahl Control. Die Realisierung des Webfrontends soll anhand eines rudimentären Beispiels die Verwendung von Services zeigen.
Im Zuge der ingenieursmäßigen Entwicklung von Software werden die möglichen Planungsschritte zur Struktur- und Verhaltensmodellierung durchgeführt. Diese Phase soll vor der eigentlichen Implementierung die Funktionsweise der Entwicklung festlegen und so Fehler durch Fehl-interpretation vermeiden.
Auf Basis von Besprechungen und Interviews mit den Ansprechpartnern der Business Control Software GmbH wurden die Anforderung an die zu implementierende Software eruiert. Nachfolgend entstand ein Dokument, welches alle Anforderungen aufzeigt und eindeutig identifiziert. Anhand dieser Liste ist es möglich Prioritäten, Muss- und Kannkriterien zu bewerten.
Die Anforderungen wurden iterativ erhoben und den aktuellen Kundenwünschen angepasst. Aufgrund dessen wurden die erweiterten Anforderungen nach jedem Treffen mit der Geschäfts-führung analysiert.
Auf der Primärebene sind die Anforderungen in Faktoren der Betriebsumgebung und Funktions-umfang unterteilt. Innerhalb der Betriebsumgebung wurde weiter in Benutzer-, Technik und umgebende Architektur separiert. Der Funktionsumfang gliedert sich in Transport-, Verteilung-, Verwaltungsaspekte. Ferner wurden die Anforderungen der zu implementierenden Services und deren Anbindung auf einer Webseite aufgenommen.
Die technische Nähe resultiert daraus, dass die Integration in eine bestehende Software geplant ist. Herr Ivanof stellt die Anforderungen im Kontext mit der bestehenden Stahl Control Implementierung in den Vordergrund. Herr Berbüsse konzentrierte sich auf die Anforderungen, die den Kundenwünschen und -vorteilen entsprechen.
Jede Anforderung wurde priorisiert. Dies erfolgt durch einen Zahlenwert zwischen 1 und 5, wobei 1 einer niedrigen Priorität entspricht, 5 hingegen der höchsten. Zusätzlich wurde vereinbart, dass Anforderungen mit einem Wert größer gleich 4 als Musskriterium angesehen werden. Analog dazu stellt eine Anforderung mit einer Priorität kleiner als 4 ein Kannkriterium dar.
Um für spätere Gespräche und Verwendung in etwaigen Dokumenten auf die erfassten Anforderungen zu referenzieren, stellt die erste Spalte der Tabelle eine eindeutige Identifizierung bereit.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Ausschnitt der Anforderungsanalyse innerhalb der verwendeten Exceltabelle (Quelle: Dokumente/anforderungen.xls)
Zu beobachten ist, dass, wie auch von Helmut Balzert erwähnt, die Anforderungen vage und unvollständig sind[15]. Dementsprechend müssen in der folgenden Aufgabenanalyse weitere, nicht bedachte Aspekte der zu erstellenden Software erarbeitet werden.
In Summe sind 52 Anforderungen erfasst worden (Siehe Anhang: Dokumente/anforderungen.xls).
Anwendungsfälle stellen in der Softwarenentwicklung die fachliche Sicht eines Akteures zu der von ihm benutzten Software dar. Ein Akteur ist entweder ein Benutzer aus einem existierenden Benutzerkreis, oder ein fremdes DV System. Akteure stehen in Beziehung mit den sogenannten Use Cases. Diese stellen eine Funktionsbenutzung innerhalb der zu modellierenden Software dar und werden auch Geschäftsprozess genannt. Use Cases sind in einem Systemkontext eingebettet, der einzeln betrachtet werden kann.
Für die Modellierung der hier zu erstellenden Software lassen sich vorerst folgende Untersysteme definieren:
- Verwaltung der Services in Stahl Control durch einen Administrator
- Benutzung der Stahl Control Webservices durch ein Fremdsystem
- Benutzung der Beispielservices im Webkontext
Je nach Kontext nutzen verschiedene Akteure die verschiedenen Aspekte der angebotenen Softwarelösung.
Bei der Stahl Control Serviceverwaltung handelt es sich um die zu entwickelnden Softwareelemente, die innerhalb von Stahl Control zugänglich sind. Die Serviceverwaltung stellt eine Ansicht auf das eingehend erwähnte Serviceinventar dar. Einträge in dieser Tabelle können von den Benutzern bearbeitet werden (Create, Read, Update, Delete). Zusätzlich stellt das Serviceinventar den Ausgangspunkt für servicebasierende Aktionen dar. Hierzu gehört ein Export der Schnittstellen-beschreibung sowie die Einsicht in die Verbindungsprotokolle. Außerhalb des Serviceinventars werden die Servicekeys den entsprechenden Stammdatensätzen der Kunden & Lieferanten (Adressen), Ansprechpartnern von Adressen, Vertretern und Verbänden hinterlegt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Use Case der Service Verwaltung innerhalb Stahl Control
Bei der Nutzung von Stahl Control Webservices durch Fremdsysteme beschränkt sich der Anwendungsrahmen auf das Senden von Anfragen und das Empfangen von Antworten. Um die Anfragen zu bearbeiten, wird die Serviceausführung benutzt. Selbiges gilt für das Erstellen von Antworten. Die genauere Verhaltensweise der Serviceausführung wird in den folgenden Kapiteln eingehend erläutert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: User Case der Servicenutzung
Im Falle der Benutzung der zu erstellenden Beispielwebseite bilden die Webseitenbenutzer die beteiligten Akteure. Je nach Nutzungskontext und Berechtigungen laut "Berechtigung einstellen" erfolgt der Zugriff auf einen Service über die Navigation zur entsprechenden Unterseite der Webapplikation. Jede Anfrage benötigt Benutzereingaben um die gewünschte Aktion durchzuführen. Analog dazu greift die Visualisierung der Daten auf Anfrage respektive Antwort zurück um diese dem Benutzer zur Verfügung zu stellen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Use Case zur Benutzung der Beispielwebseite
Anhand der erstellten Use Cases wurden klarere Nutzungsstrukturen und Abläufe erkennbar, die es in weiterführender Modellierung zu verfeinern gilt.
Um den genauen Ablauf der Kernkompetenz der zu erstellenden Software zu modellieren, wurde ein entsprechendes Aktivitätsdiagramm erstellt. Durch den Einzug der Objektorientierten Entwicklung von Software bietet UML das entsprechende Werkzeug. In der prozeduralen Programmierung benutzte man sogenannte Programmablaufpläne. Da diese sich jedoch nur im Detail unterscheiden wurde auf einen Programmablaufplan verzichtet.
Bei der oben erwähnten Kernkompetenz handelt es sich um die Serviceverarbeitung. Während der Lebensdauer einer Serviceabfrage werden folgende, hergeleitet aus der Anforderungsanalyse, interne, zu erstellende Applikationsschichten durchlaufen. Die verschiedenen Schichten werden im Diagramm durch Swimlanes dargestellt:
- Conzept 16 SOA Service
- Stahl Control Servicelayer
- Stahl Control Servicemanagement
- Stahl Control Serviceimplementierung
Der Conzept 16 SOA Service stellt die Socketverbindung zur externen Applikation her. Der Stahl Control Servicelayer übernimmt die Verbindung und liest die anliegenden Daten aus, welche er an das Servicemanagement weiterleitet. Das Servicemanagement überprüft die extrahierten Daten und bereitet diese zur Verwendung durch die Serviceimplementierung auf. Zusätzlich wird dort die Verfügbarkeit, Berechtigung etc. überprüft, sodass die Serviceimplementierung nur ausgeführt wird, wenn die Anfrage korrekt gestellt wurde.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9: Aktivitätsdiagramm für die Serviceverarbeitung
Die Verarbeitungsweise, die in Abbildung 9 dargestellt ist, konnte im Laufe der Implementierung nicht genau umgesetzt werden. So stellte sich erst während der Entwicklung heraus, dass es nicht reicht, die anliegenden Daten im HTTP Protokoll nur in GET oder POST zu unterscheiden. Warum innerhalb der POST Daten noch Unterschiede zu berücksichtigen sind, wird in den Kapiteln der Implementierungsdetails genauer erläutert.
Additional zur Aktivitätsmodellierung der Kernfunktion wurde auch ein Aktivitätsdiagramm zur Definition zur Abfrage und Darstellung der Servicedaten durch die Beispiel Webapplikation erstellt.
[...]
[1] Vgl. (Business Control Software GmbH, 2008).
[2] Vgl. (Business Control Software GmbH, 2007).
[3] Vgl. (Business Control Software GmbH, 2007).
[4] Vgl. (Vectorsoft AG).
[5] Vgl. (Erl, 2008).
[6] (Josuttis, 2008) Seite 78.
[7] Vgl. (Melzer, 2008) Seite 55.
[8] Vgl. (Melzer, 2008) Seite 107 ff.
[9] Vgl. (Melzer, 2008) S. 71.
[10] Vgl. (Josuttis, 2008) S. 262 ff.
[11] Vgl. (Vectorsoft AG, 2010).
[12] Vgl. (Tanenbaum & van Steen, 2003) Seite 734 ff.
[13] Vgl (Json.org).
[14] Vgl. (Netcraft Ltd., 2010).
[15] Vgl. (Balzert H. , 2000) Seite 98.
Kommentare