Workflow-Management zur Projektierung von Gebäude- Netzen im Rahmen des CANDY-Frameworks

Transkript

1 TECHNISCHE UNIVERSITÄT DRESDEN Workflow-Management zur Projektierung von Gebäude- Netzen im Rahmen des CANDY-Frameworks Diplomarbeit eingereicht an der Technischen Universität Dresden Fakultät für Informatik Lehrstuhl für Rechnernetze Natalia Trofimova Betreuender HSL: Betreuer: Prof. Dr. habil. A. Schill Dr.-Ing. A. Luntovskyy Dr. rer. nat. D. Gütter Dresden,

2 Selbstständigkeitserklärung Hiermit erkläre ich des Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Natalia Trofimova Dresden, den 08. November 2006

3 Danksagung Ich möchte mich an erster Stelle bei meinen Betreuern Herrn Dr. Luntovskyy und Herrn Dr. Gütter für die umfangreiche Betreuung und die sehr angenehme Atmosphäre bedanken. Mein Dank gilt außerdem dem CANDY-Team, hierbei vor allem meiner Schwester Taja für anregende Diskussionen und Korrekturlesen. Besonderer Dank geht an Stefan und an meine Eltern für ihre uneingeschränkte Unterstützung.

4 1 Einführung Motivation Ziele Aufbau der Arbeit Begriffe Problemstellung und Anforderungsanalyse Netzwerkprojektierung Netzwerkprojektierungstool CANDY NetPL - Austauschformat der CANDY-Tools Workflow-Management im Kontext der CANDY-Plattform Probleme Verwandte Arbeiten im Rahmen des CANDY-Projektes Vorgehensweise im Rahmen dieser Arbeit Zusammenfassung Analyse der Prozesse in der Netzwerkprojektierung Überblick Ablauf im Projekt vom Typ Neu-Entwurf Zusammenfassung Modellierung des Prozesses Neu-Entwurf Modellierungsaspekten Auswahl der Modellierungstechnik Kriterien der Analyse Analyse der verbreiteten Prozessmodellierungstechniken EPK UML 2.0-Aktivitätsdiagramme BPMN XPDL Zusammenfassung Modell für Prozess Neu-Entwurf Segmentierung (Funktionaler Aspekt) Rollen und Aufgaben (Organisationsaspekt) Prozessablauf (operationaler Aspekt) Datenfluss (Informationsaspekt) Analyse der Teilprozesse Teilprozess Sammlung der Information Teilprozess Festlegung der Anforderungen Teilprozess Festlegung der Strategie

5 Teilprozess Entwurf eines Netzwerkkonzeptes Eignung des Prozesses Neu-Entwurf zur Unterstützung vom WfMS Vorbetrachtungen Eigenschaften eines Prozesses Unterstützungsformen Eignungstest Zusammenfassung Konzeption des WfMS CANDY-Manager Anforderungen an WfMS für CANDY-Plattform Die funktionalen Anforderungen Die nichtfunktionalen Anforderungen Übersicht über die Open Source WfMS Enhydra Shark jbpm OpenWFE WfMOpen Zusammenfassung Architektur von WfMS CANDY-Manager Betrachtung von Architekturkomponenten Worklist-Handler Workflow-Engine Process-Model Workflow-Engine-Core Data-Handler Communication-Handler Datenspeicher Anbindung von CANDY-Anwendungen Zusammenspiel der Komponenten Szenario 1: Ausführung einer manuellen Aktivität Szenario 2: Ausführung einer vollautomatisierten Aktivität Szenario 3: Ausführung einer halbautomatisierten Aktivität Zusammenfassung Prototypische Realisierung Auswahl der Technologien Web-Client Worklist-Handler Workflow-Engine Datenbank

6 6.2 Realisierung der Komponenten Worklist-Handler Workflow-Engine Zusammenfassung Transformation des Prozessmodells in Workflow-Modell Mathematische Grundlagen Vorbetrachtungen Vergleich des UML-Aktivitätsdiagrammes und der XPDL-Beschreibung Funktionaler Aspekt Operationaler Aspekt Informationsaspekt Organisationsaspekt Beschreibung des Prozesses im Intermediatorformat Domäne der iuml-ad Prozessmodell im iuml-ad-format Transformation des Prozessmodells ins Workflow- Modell Zusammenfassung Zusammenfassung und Ausblick Anhang A Abkürzungen Abbildungsverzeichnis Tabellenverzeichnis Quellenverzeichnis Anhang B Anhang C: CD

7 1 Einführung In diesem Kapitel wird es auf die Motive eingegangen, die zur Erstellung dieser Diplomarbeit geführt haben und die Ziele beleuchtet, die erreicht werden sollen. Abschließend wird es einen kurzen Überblick über den Aufbau und den Inhalt der Arbeit gegeben. 1.1 Motivation Sowohl Anzahl als auch Nutzung von Rechnernetzen nimmt in unserer Welt stetig zu und ist aus vielen Bereichen des Lebens nicht mehr wegzudenken. Sie dienen heutzutage nicht nur der Kommunikation der Nutzer zwischen einander sondern sind auch ein Bestandteil jeder betrieblichen Infrastruktur. Es wächst nicht nur die Bedeutung von Rechnernetzen, sondern auch die Komplexität ihres Entwurfes. Die Vielfalt an möglichen Technologien, eine große Anzahl der beteiligten Geräten und die Integration des zu entwerfenden Netzwerkes in die bereits existierende Infrastruktur machen die Entwicklung des Netzwerkkonzeptes sehr anspruchsvoll. Das an der an der Fakultät Informatik der TU Dresden gestartete Pilot-Projekt Computer Aided Network Design UtilitY (CANDY) beschäftigt sich mit der Entwicklung von Werkzeugen, die den Ingenieuren beim Entwurf eines Netzes unterstützen sollen und ihnen die Routineaufgaben z.b. Simulation oder Kostenberechnung abnehmen. Jede Software kann aber nur dann bedient werden, wenn die notwendigen Eingabeparameter bereitgestellt sind. Es ist aber für den Ingenieur zeitaufwändig, wenn er sich in jedem Arbeitsschritt um die Beschaffung und den Einsatz der richtigen Tools und Daten selbst bemühen muss. Daher ergibt sich den Bedarf an einem System, welches die Steuerung des gesamten Ablaufes der Netzwerkprojektierung übernimmt und die Bereitstellung von Daten und Tools regelt. Diese Funktionalität kann z.b. vom Workflow Management System (WfMS) bereitgestellt werden. Durch WfMS kann auch sichergestellt werden, dass die Aufgaben zum richtigen Zeitpunkt ausgeführt werden, und die Überwachung der Projektdurchführung übernehmen Im Rahmen dieser Diplomarbeit wird es mit der Problematik des Einsatzes von WfMS für CANDY- Plattform auseinandergesetzt. 1.2 Ziele Das erste Ziel dieser Arbeit besteht in der Identifizierung und Modellierung der Prozesse im Rahmen der Netzwerkprojektierung. Anschließend sollen die Workflow-Definitionen von diesen Prozessen auf Basis der etablierten Standards entwickelt werden. Das weitere Ziel ist die Ausarbeitung des Konzeptes zur Unterstützung der modellierten Prozesse auf technischer Ebene, d.h. es soll ein erweiterbares, modular aufgebautes WfMS konzipiert und technisch in Form eines Prototyps umgesetzt. Dabei sind die Austauschbarkeit der Systemkomponenten und Erweiterbarkeit des Systems durch den modularen Aufbau zu gewährleisten. Als weiteres Designziel besteht in der Anforderung, dass die Arbeit der Ingeniere, die durch ein solches System unterstützt wird, möglichst orts-, zeit- und geräteunabhängig erfolgen kann. 4

8 1.3 Aufbau der Arbeit Im Einführungskapitel werden die Ziele und die Motivation dieser Arbeit beleuchtet und ein Überblick über Workflow-Management-Konzepte gegeben. Es werden Begriffe definiert, die zum Verständnis der vorliegenden Arbeit nötig sind. Als Ausgangspunkt wird in Kapitel 2 zuerst ein Einblick in das Kerngebiet des CANDY-Projektes gegeben und im Kapitel 3 erklärt, wie die Netzwerkprojektierung abläuft. Anschließend wird im Kapitel 4 die Erstellung eines Prozessmodells am Beispiel des Prozesses Neu-Entwurf vorgestellt. Im Zuge dessen wird auch analysiert, in wieweit der untersuchte Prozess zur Unterstützung durch ein WfMS geeignet ist. Das Kapitel 5 stellt das eigene Konzept des WfMS für die CANDY-Plattform vor. Dabei wird sowohl der Überblick über die gesamte Architektur als auch eine detaillierte Beschreibung jeder einzelnen Komponente des Systems gegeben. Die Details über die technische Realisierung des konzipierten Systems stehen im Mittelpunkt des Kapitels 5. Damit der modellierte Prozess auf Basis eines WfMS gesteuert werden kann, ist es notwendig, das Prozessmodell in eine maschinenlesbare Form zu übertragen. Das Kapitel 6 beschäftigt sich mit der Problematik der Transformation des erstellten Prozessmodells in das Workflow-Modell. Zum Abschluss der Diplomarbeit wird im letzten Kapitel das Erreichte nochmals rekapituliert und ein Ausblick auf mögliche Ansatzpunkte für eine Weiterentwicklung der vorgestellten Konzepte und Techniken gegeben. 1.4 Begriffe In der Literatur über Workflow-Management ist es schwierig, eindeutige Definitionen für relevante Begriffe zu finden. Im Folgenden werden Definitionen für die wichtigsten Termini in Anlehnung an [VB96], [wmcd], [JS96], [BM00] gegeben, die im Rahmen dieser Arbeit verwendet werden. Workflow (Vorgangssteuerung) ist der vordefinierte und durch das WfMS unterstützte Ablauf von Aktivitäten, bei denen Informationen und Aufgaben zwischen den Beteiligten ausgetauscht werden. Unter den Beteiligten werden eine Person (Sachbearbeiter) oder Anwendungsprogramm (z.b. ein Mail-Client, ein Tool, ein Datenbanksystem) verstanden. Zu den Informationen gehören Daten verschiedener Art: Dokumente, Parameter, Statusinformationen. Prozess ist eine Folge von Arbeitsschritten, die zum Erreichen eines gemeinsamen Geschäftsziels führen. Ein Prozess gibt nur eine abstrakte Sicht auf den Ablauf im Unternehmen. Im Gegensatz zu ihm beschreibt ein Workflow den Ablauf so exakt, dass die folgende Aktivität durch den Ausgang der jeweils vorangehenden determiniert ist. Prozessmodell ist die grafische Darstellung eines Prozesses. Es ist unabhängig vom später eingesetzten WfMS und enthält keine technischen Details. 5

9 Workflow-Modell ist die in einer formalen, maschinell verarbeitbaren Sprache formulierte Workflow-Beschreibung, die für die Ausführung und Steuerung von Prozessen mit Hilfe eines WfMS nötig ist. Das Workflow-Modell ist auf das konkrete WfMS zugeschnitten. Prozess-Instanz ist eine konkrete Ausprägung eines Prozessmodells. Die Prozessmodelle werden in der Regel selten instantiiert. Meist wird nur das daraus abgeleitete Workflow- Modell instantiiert. Es kann jedoch zu Simulationszwecken vorkommen, dass eine Prozess- Instanz erzeugt wird. Workflow-Instanz ist eine konkrete Ausprägung eines Workflow-Modells. Sie unterscheidet sich vom Modell dadurch, dass sie einen Zustand hat. Das Verhältnis zwischen Workflow- Modell und Workflow-Instanz ist der Beziehung zwischen Klasse und Objekt in der objektorientierten Programmiersprachen ähnlich. WfMS (Vorgangsbearbeitungssystem) ist ein System, welches die Modellierung und Durchführung von Workflows ermöglicht, zur Laufzeit die Verteilung der Funktionen unter Aufgabenträgern regelt und sich mit der Steuerung von Anwendungsprogramme zur Durchführung (teil-)automatisierter Funktionen beschäftigt. Workflow Engine (Vorgangssteuerungsmaschine) ist ein Software-Dienst, welcher die Ausführungsumgebung zur Laufzeit für einen Workflow-Prozess bereitstellt. Aktivität ist ein logischer Schritt innerhalb eines Prozesses. Einzelaufgabe ist eine Repräsentation der Arbeit (Aufgabe), die von einem Teilnehmer erledigt wird. Worklist (Arbeitsliste) ist eine Menge von Aufgaben, die einem gegebenen Teilnehmer oder Gruppen von den Teilnehmern zugeordnet sind. Aufgerufene Anwendung ist eine Anwendung, die vom WfMS aufgerufen wird, um eine Aktivität automatisch auszuführen oder um einen Teilnehmer bei der Bearbeitung einer Aufgabe zu unterstützen. Teilnehmer ist eine Ressource, die eine bestimmte Aufgabe ganz oder teilweise erledigt. Anwendungsdaten sind Daten, die ausschließlich von den eingesetzten Anwendungen verwaltet werden und auf die ein WfMS keinen Zugriff hat. Vorgangsdaten (Workflow Relevant Data) sind Daten, auf die das WfMS Zugriff hat. Sie können beispielsweise verwendet werden, um Zustandsübergänge innerhalb einer Workflow- Instanz zu entscheiden. 6

10 Workflow-Referenzmodell Das Workflow-Referenzmodells der Workflow Management Coalition (WfMC) definiert einen Architekturrahmen für WfMS (s. Abbildung 1-1). Den Kern des Referenzmodells bildet ein Vorgangsausführungsdienst (Workflow Enactment Service), der individuelle Vorgänge erzeugt, verwaltet und ausführt. An ihn sind über fünf Schnittstellen andere Komponente wie Modellierungswerkzeuge, Workflow-Klieneten, Anwendungsprogramme und weitere WfMS angeschlossen. Die Schnittstelle 1 (Workflow Definition Interchange) ist für die Kommunikation mit den Systemen konzipiert, die zur Beschreibung von Prozessen dienen. In diesen Systemen erstellte Beschreibungen können in ein WfMS übernommen werden. Als Beschreibungssprache wird XPDL verwendet. Die Schnittstelle 2 (Workflow Client Application Interface) beschreibt, wie der standardisierte Aufruf von Funktionen eines WfMS von einem Klienten aus erfolgt. Über die Schnittstelle 3 (Invoked Applications Interface) werden die anderen Anwendungsprogramme aufgerufen, die bei der Bearbeitung einer Aufgabe eingesetzt werden. Abbildung 1-1: Workflow-Referenzmodell [wmcd] Die Schnittstelle 4 (WAPI Interoperability Functions) unterstützt die Interoperabilität zwischen verschiedenen WfMS. Es sollen Workflows von einem WfMS zu einem anderen weitergegeben und dort weiterbearbeitet werden können. Die Schnittstelle 5 (Administration & Monitoring Interface) dient zur Anbindung verschiedener Verwaltungs- und Monitoring-Tools an ein WfMS. 2 Problemstellung und Anforderungsanalyse Dieses Kapitel gibt eine Einführung in das CANDY-Projekt. Dazu wird zuerst die CANDY- Plattform und ihr Betätigungsfeld vorgestellt. Danach wird auf das Austauschformat der 7

11 CANDY-Werkzeuge eingegangen. Zum Schluss werden die existierenden Probleme diskutiert. 2.1 Netzwerkprojektierung Die Netzwerkprojektierung stellt eine Modellierung und eine technische Realisierung der individuellen Anforderungen an das zukünftige System dar, deswegen läuft jeder Prozess der Planung und Einrichtung des Netzwerkes vollkommen individuell ab. Die Projektanten handeln in vielen Fällen intuitiv und treffen ihre Entscheidungen aufgrund von gesammelten Erfahrungen. Aus diesem Grund können die Schritte eines Projektes nicht komplett bei anderem wiederholt werden. Es ist trotzdem möglich, eine allgemeine Vorgehensweise bei der Projektierung der Gebaüde-Netze zu formulieren. Diese umfasst vier Phasen, deren Anzahl und Ablauf je nach Projektart variiert wird. Der Netzwerkprojektierungsprozess kann in folgenden Phasen aufgeteilt werden: 1. Informationserhebung 2. Entwurf des Netzwerkkonzeptes 3. Technische Realisierung des Netzwerkkonzeptes 4. Wartung Eine korrekte Netzwerkplanung setzt zunächst die Erhebung von Information voraus, wobei die Zielsetzung der Vernetzung, die wichtigsten Anforderungen und Parameter festzulegen. Danach werden die grundlegenden Entscheidungen über die Art der Vernetzung, über das Zugriffskonzept, über die Auswahl von Komponenten und die einzusetzenden Netzwerksysteme getroffen. Anschließend wird die Kostenanalyse durchgeführt und Netzauslastung überprüft. Erst dann wird das Netz aufgebaut und getestet. Die Arbeit zur Herstellung eines Verkabelungssystems inklusive der jeweiligen Installation und Einrichtung der Komponenten und Geräte wird mit einer ausführlichen Überprüfung durch den Auftraggeber, der so genannten Abnahme abgeschlossen. 2.2 Netzwerkprojektierungstool CANDY Im vorigen Abschnitt wurde beschrieben, was eine Netzwerkprojektierung ist und welche Aufgaben dazu gehören. Dabei ist es zu erwarten, dass die einzelnen Schritte in der Praxis wesentlich komplizierter als oben dargestellt ablaufen können. Durch den Einsatz der unterschiedlichen Software ist es möglich, die Projektanten mindestens bei der Erstellung des Konzeptes zu unterstützen. Genau dieses Ziel verfolgt das Projekt CANDY. Das CANDY- Framework besteht aus mehreren CAD-Tools (z.b. NDML-Editor, Bill- Reporter, RuleChecker), wobei jedes davon zur Erfüllung einer bestimmten Aufgabe beim Netzwerkentwurf eingesetzt wird (z.b. Bill-Reporter zur Kostenberechnung, RuleChecker zur Topologie-Verifizierung, NS-2 zur Simulation). Die Abbildung 2-1 stellt die Palette von Anwendungen im CANDY-Framework (Stand Mai 2006) dar. 8

12 Abbildung 2-1: CANDY-Framework Suite (Stand Mai 2006) Zur Erhebung von Basisinformationen wie Kundenkontaktdaten, sämtliche Projektdokumente (Gebäudeskizze, die Beschreibung des Projektes) wird im CANDY-Framework ein Projekt- Editor [ZF04] von F. Zhou zur Verfügung gestellt. Der Editor ist als einfacher Web-Browser ausgeführt. Der Designer füllt bestimmte Web- Formulare aus, aus denen danach XML- Dokumente mit zahlreichen Beschreibungsinformationen generiert werden. Bei der Erstellung der Topologie wird der Designer durch den von F. Zhou [ZF04] im Rahmen der Belegarbeit entwickelten Network-Editor unterstützt. Mit Hilfe vom Tool können die Komponenten ausgewählt, die im Verkabelungssystem eingesetzt werden sollen, und die Verbindungen spezifiziert werden. Der Projektingenieur kann zum Schluss die graphische Darstellung der Netztopologie anschauen. Die Beschreibungen von Standorten können als PDF- oder PytonCAD-Dokumente den Projektanten bereitgestellt werden. Aber in der letzten Zeit etablierte sich der Industry Foundation Classes (IFC)-Standard, der zur digitalen Beschreibung von Gebäude-Modellen dient. Die in diesem Format gespeicherten Standortbeschreibungen können nicht ohne weiteres im CANDY-Framework verwendet werden, da es von keinem Tool unterstützt wird. Aus diesem Grund entwickelte S. Holstein [HS06] in seinem Beleg einen IFC-to-NDML Konverter, der das Gebäude-Modell IFCXML-Format ins Gebäudemodell im für die CANDY-Plattform spezifischen Format transformiert. Bill Reporter dient der Berechnung der zu erwartenden Kosten für die Errichtung des Netzwerkes. Es existieren im CANDY-Framework einige Implementierungen dieses Moduls. Die erste Version von Bill-Reporter entstand im Rahmen des Beleges von H. Grünwald [GH04]. Seine Funktionalität besteht in der Berechnung von Komponenten-Kosten. Die zweite Version von Bill Reporter, welche von U. Winkler [WU06] vorgeschlagen wurde, ermöglicht zusätzlich die Erstellung der Graphiken zur Kostenanalyse. Die Verläufe von Kabelkanälen können im CANDY-Framework mithilfe vom Tool Trace Router auf die Gebäudeskizze eingetragen werden. Den Anfang zur Entwicklung dieser 9

13 Software wurde von A. Kaftanenko [KA04] gelegt. Sein Prototyp Network Tracing Planners erlaubt die in XML-Format gespeicherten Gebäude- und Kabeltrassenmodelle anzusehen. Das Tool CaNDeL, welches P. Bönisch [BP06] vorschlug, stellt ein Prototyp von Trace Router dar und erlaubt dem Designer die Kanäle am Computer einzuzeichnen und anschließend die optimalen Wege berechnen zu lassen. Zur Durchführung der Validierung vom Netzwerkvorschlag wird im CANDY-Framework einen Einsatz der Software NS-2 vorgesehen. NS-2 ist ein nicht CANDY-spezifisches Tool und wird durch eine passende Schnittstelle in das CANDY-Framework eingebunden. Dies geschieht durch Konvertierung des im XML-Format gespeicherten Simulationsmodells in ein OTcl- Script. Dieses Skript wird dann mit dem Network Simulator ausgeführt. An den Nutzer wird dann ein trace file zurückgegeben, in dem er die Simulationsergebnisse sehen und später analysieren kann. Der von G. Pfeifer [PG03] entwickelte Konverter erstellt eine OTcl-Datei aus der um Simulationsparameter erweiterte Topologie-Beschreibung. Anhand dieses OTcl-Scriptes kann die Simulation für ethernetbasierte Netze durchgeführt werden. Es existiert im CANDY-Framework auch die Möglichkeit die Lastbewertung einzelner Teilstrecke durchzuführen, was ermöglicht, die Überlastungen frühzeitig zu erkennen und zu beheben. Das Tool von W. Xuewei [XW06], welches auf den Netzwerk-Editor von F.Zhou basiert, dient zur Lastmodellierung der statischen Informationsströme. Das CANDY-Framework kann die Projektanten beim Entwurf nicht nur kabelgebundene, sondern auch kabellose Gebäude-Netze unterstützen. T. Fahnert [TF05] entwickelte im Rahmen seiner Belegarbeit das Tool StandortFinder, welches ermöglicht, optimale Standorte für Access Points zu ermitteln. Die Tabelle 2-1 gibt den Überblick über im CANDY-Framework vorhandene Tools mit ihrer Funktionalität. Tabelle 2-1: Überblick über im CANDY-Framework vorhandene Tools Anwendung Funktionalität CANDY 2.0 (F.Zhou) Erhebung der Basisinformationen über das Projekt (Projektbeschreibung, Benutzeranforderungen, Anwendungsanforderungen, Informationsflüsse), Festlegung der Verbindungsstruktur IFC-to-NDML Konverter (S. Holstein) Konvertierung der im IFCXML-Format gespeicherten Gebäude-Beschreibung in Gebäudemodell im NDML- Format Bill Reporter (H. Grünwald) Berechnung von Hardware-Kosten, Ausgabe der Komponentenliste Bill Reporter (U. Winkler) Berechnung von Hardware-Kosten, graphische Darstellung des Finanzberichtes 10

14 Network Tracing Planner (A. Kaftanenko) CaNDeL (P. Bönisch) NDML-to-OTcl-Konverter zur Simulation mit NS-2 (G. Pfeifer) Analysesoftware (W. Fäller) Last-Modul (W. Xuewei ) StandortFinder (T. Fahnert) Darstellung der in NDML-Format gespeicherten Gebäudeund Kabeltrassenmodelle Darstellung von Kabeltrassen an der Gebäudeskizze, Berechnung der optimalen Kabelwege Konvertierung des im NDML-Format gespeicherten Simulationsmodells in OTcl Script Analyse der Systemleistung anhand der Bedienungstheorie Lastbeschreibung für ethernetbasierte LAN S, Berechnung der zu erwartenden Auslastungen von Teilstrecken des Netzes Ermittlung der optimalen Standorte für Access Points 2.3 NetPL - Austauschformat der CANDY-Tools Für die Kommunikation zwischen den CANDY-Anwendungen ist ein gemeinsames Austauschformat notwendig, das mit jedem Tool der Umgebung kompatibel ist. NDML ist eine Netzwerkbeschreibungssprache, die im Rahmen des CANDY-Projektes an der TU Dresden entwickelt wurde. Bei dem Entwurf von NDML wurde das Ziel verfolgt, eine XMLbasierte Umgebung für die Rechnernetzprojektierung zu verwenden. Das NDML stellte aber ein unreifes Konzept dar und wies einige Probleme auf: Uneinheitlichkeit. Es existierten verschiedene Schemasprachen für verschiedene Aspekte (Viewpoints) Unübersichtlichkeit. Die Sprache charakterisierte sich durch die Koexistenz vieler Derivate einzelner Viewpoints. Unstrukturiertheit. Die thematisch ähnlichen Daten wurden in mehreren Viewpoints getrennt und die nicht zusammengehörenden Informationen wurden in einem Viewpoint zusammengefasst. Ungeregeltheit. Die Versionsvergabe war komplett willkürlich und entsprach nicht der üblichen Praxis. Unvollständigkeit. Die existierende Sprache umfasste nicht alle Aspekte des Netzwerkentwurfs. In der Arbeit von T. Trofimova [TT06] erfolgte der Versuch die oben beschriebenen Probleme zu eliminieren. Als Ergebnis entstand ein neuer Sprachstandard NetPL. In dieser Sprache werden die Ergebnisse der Netzwerkprojektierung abgebildet. Dabei werden Daten in thematische Gruppen (Viewpoints) innerhalb einer NetPL-Datei unterteilt. Jede Gruppe enthält zusammengehörende Daten. Die Daten unterschiedlicher Viewpoints können auch in Beziehung zu einander stehen. 11

15 Abbildung 2-2: Der Aufbau von NetPL [TT06] Der weitere Fortschritt in neuer Spezifikation ist die Nutzung eines einzigen XML-Schemas für die Sprachdefinition. Dies verlangt nur eine einzige NetPL Datei während des Projektierungsvorgangs zu benutzen, was die Verwaltung von Daten vereinfacht. Vorteilhaft ist in NetPL auch, dass hier alle benötigten Informationen zum Datenaustausch und Netzwerkbeschreibung zur Verfügung gestellt. Die genaue Beschreibung der Sprache ist in der Arbeit von T. Trofimova [TT06] nachzulesen. Da NetPL ein reifes Konzept darstellt, wird in Zukunft die gesamte CANDY-Plattform auf neue Sprache umsteigen. Aus diesem Grund wurde es entschieden, in dieser Diplomarbeit für das WfMS NetPL zu verwenden. Zum Zeitpunkt, wenn diese Arbeit geschrieben wird, verfügt das CANDY-Plattform über kein Tool, das NetPL als Austauschformat benutzt. 2.4 Workflow-Management im Kontext der CANDY- Plattform Probleme Im Abschnitt 2.2 wurde einen kurzen Überblick über die im CANDY existierenden Tools gegeben. Der Ingenieur kann aber viel Zeit verlieren, wenn er sich in jedem Arbeitsschritt um die Beschaffung und den Einsatz von richtigen Tools und Daten bemühen muss. Daher ergibt sich den Bedarf an einem System, welches die Steuerung des gesamten Ablaufes der Netzwerkprojektierung übernimmt und die Bereitstellung von Daten und Tools regelt. Diese Funktionalität kann z.b. vom WfMS bereitgestellt werden. Der Einsatz eines solchen Systems für CANDY-Plattform erschwert sich dadurch, dass jedes von diesen Werkzeugen eine individuelle Lösung zum bestimmten Problem darstellt und zum heutigen Zeitpunkt in eine einheitliche Plattform schlecht integrierbar ist. Der erste Grund hierfür ist die fehlende einheitliche Definition der Import- und Exportschnittstellen. Es lag bis jetzt teilweise auch daran, dass das Austauschformat ein ungereiftes Konzept darstellte. Als weiteres Hindernis zur Anbindung der Tools an ein einheitliches System ist die Heterogenität der eingesetzten Architekturen. Ein Teil der Anwendungen realisiert eine Client-Server-Architektur, der andere Teil ist als Stand-Alone-Anwendungen ausgeführt. Die Vielfalt der eingesetzten Technologien erschwert auch die Portierung der Tools in eine Umgebung, da dabei die Kompatibilität der Produkte unter einander berücksichtigt werden soll. 12

16 2.4.2 Verwandte Arbeiten im Rahmen des CANDY-Projektes Innerhalb des CANDY-Projektes gab es schon einige Beleg- und Diplomarbeiten, welche sich mit dem Themenumfeld Management der Netzwerkprojektierung und Werkzeuge beschäftigt haben. Im Folgenden wird einen kurzen Überblick darüber gegeben. Belegarbeit von R. Klinkewitz Entwicklung eines CANDY-Projekt-Managers [RK05] In dieser Belegarbeit untersucht der Autor die Konstrukte verschiedener Ablaufbeschreibugssprachen wie BPEL, PNML, SMILE und macht einen Vorschlag zum Entwurf einer eigenen Sprache (WorkflowNDML) für die Beschreibung von Workflows. Dazu wird in der Arbeit ein Editor zur Erstellung der Workflow-Definitionen konzipiert und prototypisch umgesetzt. Die vorgeschlagene Lösung stellt aber kein reifes Konzept dar, da es nicht möglich ist, mit Hilfe der vorhandenen Konstrukte einen Ablauf zu beschreiben. Diplomarbeit von F. Zhou Entwicklung und Optimierung eines graphischen Entwurfssystems für das Rechnernetzprojektierungstool CANDY [ZF05] Diese Diplomarbeit beschäftigt sich mit der Entwicklung von den CANDY-Tools und ihre Einbindung in den Entwicklungsprozess. Der Autor setzt sich also eher mit den technischen Aspekten von der Automatisierung einiger Schritte bei der Netzwerkprojektierung auseinander. Die von ihm entwickelten Konzepte können bei der Einführung von WfMS auf der technischen Ebene vom Nutzen sein. Diplomarbeit von P. Schmidt Entwicklung einer XML-basierten Arbeitsumgebung für die Rechnernetzprojektierung [SP04] Der Autor versucht im Rahmen seiner Diplomarbeit eine XML-basierte Umgebung für die Rechnernetzprojektierung zu konzipieren und technisch in der Form eines Prototyps umzusetzen. Dafür wurden zuerst die Arbeitsschritte identifiziert, die nötig sind um ein Netzwerk zu projektieren. Anschließend wurde vom Autor untersucht, welche Arbeitsschritte durch die vorgeschlagene Arbeitsumgebung unterstützt werden könnten. In der Arbeit wird jedoch nur eine grobe nicht formale Beschreibung des Netzwerkprojektierungsvorganges gegeben. Diplomarbeit von H. Grünwald Entwicklung eines integrierten Tools zur Projektierung von Rechnernetzen (Ethernet/WLAN) auf einer einheitlichen Programmierplattform [GH06] In seiner Diplomarbeit schlägt der Autor einen Ansatz vor, die zahlreichen CANDY- Werkzeuge, die bei der Netzwerkprojektierung eingesetzt werden, über eine einheitliche Benutzeroberfläche anzusteuern. Es wird hier der technische Aspekt der Toolanbindung betrachtet. Hierzu gehören Punkte wie Steuerung eines Tools, Datenversorgung, Aufruf eines Tools und seine Einbindung in die GUI. Die Arbeitet richtet sich aber auf die zukünftigen 13

17 CANDY-Werkzeuge und es fehlen dabei die Konzepte zur Intergration der momentan existierenden Anwendungen Vorgehensweise im Rahmen dieser Arbeit Das erste Ziel bei der Entwicklung einer Lösung, die die Netzwerkprojektierung mit Hilfe von den CANDY-Werkzeugen regelt, ist die Analyse der zu steuernde Prozessabläufe und ihre Darstellung in der maschinenlesbaren Form. Das weitere Ziel ist die Ausarbeitung des Konzeptes zur Unterstützung der modellierten Prozesse auf der technischen Ebene, d.h. es soll ein WfMS konzipiert und technisch in Form eines Prototyps umgesetzt werden. Daher wird im Folgenden eine Vorgehensweise beschrieben, die im Rahmen dieser Arbeit verfolgt wird. Bei der Entwicklung von Workflows wird in der Literatur [SK99] [swh] [JS95] zwischen der anwender-orientierten und eine system-orientierten Phase unterschieden. In der ersten Phase (s. Abbildung 2-3) befasst man sich mit der Modellierung von Prozessen und die zweite Phase dient zur Umsetzung des jeweiligen Prozesses in einem bestimmten WfMS. Prozess Prozess- Modell Workflow- Modell Workflow Anwender-orientiert System-orientiert Abbildung 2-3: Phasen der Workflow-Entwicklung Das Ergebnis der ersten Etappe ist ein Prozess Modell, das unabhängig vom später eingesetzten WfMS ist und einige technische Details wie z.b. einzusetzende Tools noch nicht berücksichtigt. Nach der system-orientierten Phase entsteht ein Workflow-Modell, in dem einige Einzelheiten in den Vordergrund treten, die bei der maschinellen Verarbeitung wichtig sind. Das Prozess Modell wird beim Übergang von der anwender- zur system-orientierten Phase in ein Workflow-Modell transformiert. Es gibt auch Ansätze, wo es auf die Erstellung des Prozessmodells verzichtet wird, d.h. der Prozess von Anfang an im Format modelliert, welches von diesem WfMS als Input verlangt wird. Die erste Methode ist es sinnvoll dann zu bevorzugen, wenn es erst zu einem späteren Zeitpunkt für ein bestimmtes WfMS entscheiden werden kann. Die Anforderungen an ein geeignetes WfMS können viel einfacher und genauer ermittelt werden, wenn der Prozess bereits erfasst und modelliert ist. Außerdem ist das Prozessmodell nicht mit implementierungsrelevanten Details belastet, dadurch es übersichtlich und für Anwender besser verständlich ist. Ein weiterer Vorteil besteht in der Entkopplung der Prozess-Analyse 14

18 von einem konkreten WfMS. Dabei bleibt die Möglichkeit nicht ausgeschlossen, das gewählte System später auszutauschen. Danach muss nur das Workflow-Modell auf Basis schon existierender systemunabhängiger Prozessbeschreibung neu erstellt werden. Der Vorteil der zweiten Möglichkeit zur Erstellung eines Workflow besteht darin, dass es vor der Umsetzung des Prozesses im WfMS keine Transformation in das Format des Systems notwendig ist. Andererseits wird es dabei verlangt, sich für ein System vor der Prozessmodellierung zu entscheiden. Außerdem können einige Anforderungen des speziellen Prozesses an ein WfMS noch nicht bestimmt werden. Aus diesem Grund ist es sinnvoll diesen Ansatz ist anzuwenden, falls es bereits bekannt ist, was für ein WfMS eingesetzt wird. Im Rahmen dieser Arbeit wird der erste Ansatz gewählt, da die Unterscheidung zwischen den Prozess- und Workflow-Modellen bei den komplexen Prozessen in der Netzwerkprojektierung besonders wichtig ist. Erstens besteht die Notwendigkeit, die Prozessbeschreibung ohne implementierungsrelevante Details zu erfassen, damit sie für die anderen CANDY-Gruppe Mitglieder überschaubar bleibt. Zudem gibt es noch nicht besonders viele Erfahrungen im Zusammenhang von Workflow-Unterstützung von Netzwerkprojektierung im CANDY-Projekt (s. Abschnitt 2.4.2). Daher ist nicht von Anfang an klar, welche Anforderungen man an ein WfMS stellt und welche Systeme überhaupt geeignet sind. Außerdem ist die Entkopplung vom System wegen Austauschbarkeit sinnvoll. Falls es später für ein anderes WfMS entschieden wird, muss nur das Workflow-Modell auf Basis schon existierender systemunabhängiger Prozessbeschreibung neu erstellt werden. Darüber hinaus wird folgende Vorgehensweise zur Erstellung des in dieser Arbeit verfolgt: Schritt 1: Erhebung von Informationen Die Beschreibung des Ablaufes der Netzwerkprojektierung ist sehr wichtig, um das Prozessmodell zu erstellen. Schritt 2: Erstellen von Prozessmodellen Das Ziel dieses Schrittes ist es nun, auf der Basis der gesammelten Informationen Beschreibungen von den Prozessen zu erstellen. Zuerst wäre sinnvoll die Beschreibung in der grafischen Form zu verfassen, weil Diagramme oft verständlicher sind als andere Repräsentationsalternativen. Das Ergebnis dieses Arbeitsschrittes soll ein Prozessmodell sein. Schritt 3: Feststellen der Eignung für das Workflow-Management. Wie im Abschnitt deutlich wird, ist nicht jeder Prozess gleichermaßen für die Unterstützung durch ein WfMS geeignet. In diesem Schritt muss entschieden werden, welche Teile des Prozesses dafür in Frage kommen, von einem WfMS unterstützt zu werden. Zudem ist zu untersuchen, welche Form der Unterstützung für die jeweiligen Teilprozesse empfehlenswert ist. 15

19 Schritt 4: Auswahl eines WfMS Aufgrund der bis jetzt erhobenen Anforderungen und unter Berücksichtigung von weiteren Kriterien, wie beispielsweise Kosten, Service und Benutzerfreundlichkeit, soll ein spezielles WfMS implementiert werden. Schritt 5: Erstellung von Workflows Das in den ersten Schritten erstellte Prozessmodell soll in eine Form gebracht werden, die das ausgewählte WfMS verarbeiten kann. Hierzu muss das Modell meist noch an die Bedürfnisse des jeweiligen WfMSs angepasst werden und eventuell müssen noch Zusatzinformationen hinzugefügt werden, die bisher nicht im Prozessmodell enthalten waren. Ergebnis ist ein Workflow-Modell, welches als Eingabe für das WfMS dienen kann. 2.5 Zusammenfassung Die Analyse der Ausgangssituation zeigte, dass das CANDY-Framework sich durch zahlreiche Tools zeichnet, die die Projektanten bei der Netzwerkprojektierung unterstützen können. Auf anderer Seite wird die Arbeit des Ingenieurs durch solche Vielfalt an Werkzeugen erschwert, da er wissen soll, welches Werkzeug in jedem Arbeitsschritt einzusetzen ist und welche Daten dafür zu benötigen sind. Daher ergibt sich der Bedarf an einem WfMS, welches die Steuerung des gesamten Ablaufes der Netzwerkprojektierung übernimmt und die Bereitstellung von Daten und Tools regelt. Der Einsatz eines solchen Systems für CANDY-Plattform erschwert sich dadurch, dass jedes von diesen Werkzeugen eine individuelle Lösung zum bestimmten Problem darstellt und zum heutigen Zeitpunkt in eine einheitliche Plattform schlecht integrierbar ist. Der erste Grund hierfür ist die fehlende einheitliche Definition der Import- und Exportschnittstellen. Es lag bis jetzt teilweise auch daran, dass das Austauschformat ein ungereiftes Konzept darstellte. Im Laufe dieser Diplomarbeit wurde eine Sprache NetPL entwickelt, die in Zukunft als eine gute Grundlage für die Tool-Kommunikation dienen könnte. Als weiteres Hindernis zur Anbindung der Tools an ein einheitliches System ist die Heterogenität der eingesetzten Architekturen. Ein Teil der Anwendungen realisiert eine Client-Server-Architektur, der andere Teil ist als Stand-Alone-Anwendungen ausgeführt. Die Vielfalt der eingesetzten Technologien erschwert auch die Portierung der Tools in eine Umgebung, da dabei die Kompatibilität der Produkte unter einander berücksichtigt werden soll. Bis jetzt wurde es im Rahmen des CANDY-Projektes mit der Einführung des WfMS nicht beschäftigt. Daher stellt diese Diplomarbeit einen Vorschlag zum Einsatz des WfMS für die CANDY-Plattform dar. Bei der Entwicklung der Lösung sollen die Besonderheiten der Netzwerkprojektierung und des CANDY-Frameworks berücksichtigt werden. Der weitere Schwerpunkt der Untersuchung liegt an der Festlegung, wann der Ingenieur bei der Erledigung der Aufgabe eine maschinelle Unterstützung erhält und welchen Daten hierfür bereitgestellt werden sollen. 16

20 3 Analyse der Prozesse in der Netzwerkprojektierung Die Analyse der Prozesse ermöglicht eine Erkenntnis über die Arbeitsabläufe zu gewinnen. Auf Basis der gesammelten Informationen werden später Prozessmodelle erstellt, welche das WfMS verarbeiten kann. Die Untersuchung der Prozesse in der Netzwerkprojektierung steht im Mittelpunkt des folgenden Kapitels. Dabei unterscheiden sich die Arbeitsvorgänge je nach dem Projektziel. Über mögliche Projektziele und damit verbundene Durchführungsstrategien wird es am Anfang des Kapitels diskutiert. Danach wird am Beispiel eines Projekttyps der Projektierungsvorgang ausführlich analysiert. Am Ende des Kapitels wird das Fazit gegeben. 3.1 Überblick Im Abschnitt 2.1 wurden vier Phasen der Netzwerkprojektierung vorgestellt. Es sei zu erwähnen, dass das CANDY-Projekt sich nur mit dem Design der Netzwerke beschäftigt, deswegen werden die technische Realisierung der vorgeschlagene Lösung und Wartung des Netzwerkes weiter nicht betrachtet. Der Ablauf des Projektierungsvorgangs hängt vom Projektziel ab. Je nach dem Projektziel werden im Rahmen dieser Arbeit verschiedene Projekttypen unterschieden: Neu-Entwurf Upgrade Netzumbau/-ausbau Seriennetzwerk Analyse der Netzwerkprobleme Der erste Projekttyp hat das Ziel, ein Netzwerkkonzept für ein Ort, wo keine Infrastruktur vorhanden ist, zu entwerfen. Im Rahmen solches Projektes wird eine Topologie ausgearbeitet, die die Kundenwünschen bezüglich der Platzierung der Komponenten und die Gegebenheit der Umgebung berücksichtigt. Die Verkehrsmenge im zukünftigen Netzt muss empirisch bestimmt werden, falls noch keine Aufzeichnungen oder statistischen Daten vorliegen. Auf Basis der spezifizierten Anforderungen bezüglich der Komponentenplatzierung, Kapazität, logischer Gruppierung, Gegebenheiten der Umgebung wird ein Topologiekonzept ausgearbeitet. Anschließend werden die Verkabelungs- und Komponentenverteilungspläne zusammengestellt und die Leistungsfähigkeit des zu entwerfende Netzwerkes bestimmt, die vor allem von den einzusetzenden Komponenten und Übertragungsmedien abhängen. Zum Schluss werden die Analyse des Kostenfaktors und der Resultate der Netzauslastungstestes durchgeführt. Bei den zufrieden stellenden Ergebnissen kann das Netzwerkkonzept als endgültig gelten und das Projekt abgeschlossen werden. 17

21 Beim Projekttyp Upgrade handelt sich über die Ersetzung der im Netzwerk vorhandenen Komponenten durch die neuen. Bei der Auswahl der neuen Komponenten sind die Anforderungen an die Kapazität, die Unterstützung der Topologie, Kompatibilität mit den anderen Komponenten und die Gegebenheiten der Umgebung zu berücksichtigen. Aus diesem Grund ist bei der Durchführung dieses Projekttyps die sorgfältige Analyse der vorhandenen Infrastruktur notwendig. Nachdem das Upgrade-Konzept ausgearbeitet wurde, soll die Leistungsfähigkeit des Netzwerkes unter neuen Umständen überprüft und der Kostenbericht erstellt werden. Anschließend werden die Ergebnisse analysiert und, falls sie zufrieden stellen können, wird die Lösung dokumentiert. Somit wird das Projekt abgeschlossen. Ziel des Projekttyps Netzumbau/-ausbau ist die Erweiterung des schon existierenden Netzwerkes um weitere Komponenten bzw. dessen Umstrukturierung. Ein Netzwerkumbau wird beispielsweise in dem Fall notwendig, wenn Probleme während des Betriebes auftreten, wie etwa Kommunikationsengpässe, bzw. Überlastungen, oder wenn die vorhandene Netzwerkinfrastruktur nicht mehr den Benutzeranforderungen entspricht. Im Rahmen des Netzwerkausbaus werden weitere Komponenten der bestehenden Netzwerkinfrastruktur hinzugefügt oder die vorhandenen durch die leistungsfähigen ersetzt. In diesem Fall ist es nicht ausgeschlossen, dass der Bedarf an die Umstrukturierung des Netzes wegen Inkompatibilität der neuen Geräte mit der alten Topologie entsteht. Ebenfalls kann es sich bei diesem Projekttyp um einen teilweisen (nur in Teilstrukturen) oder kompletten (im ganzen Netzwerk) Technologiewechsel, wie etwa die Bereitstellung eines drahtlosen Zuganges handeln. Auf jeden Fall soll die vorgeschlagene Lösung auch am Ende auf die Leistungsfähigkeit überprüft und bezüglich des Kostenfaktors analysiert. Falls alle Anforderungen erfüllt sind, kann das Konzept als endgültig erklärt werden und das Projekt gilt als abgeschlossen. Die Besonderheit des Projekttyps Seriennetzwerk besteht darin, dass die Rahmenbedingungen, unter denen das Netzwerk entworfen werden soll, stimmen mit den Vorgaben eines anderen Projektes überein. Dies bedeutet, dass das Konzept komplett übernommen oder nur etwas angepasst werden soll. Trotzdem ist es notwendig, dies zum Schluss zu überprüfen und die Kostenanalyse durchzuführen. Der letzte Projekttyp ist mit der Analyse der Netwerkprobleme verbunden. Der erste Schritt bei der Durchführung solches Projektes ist die Untersuchung der aufgetreten Probleme und der Aufzeichnungen über die Verkehrsmenge im Netzwerk. Dabei können die möglichen Ursachen der entstandenen Probleme sowohl an der Topologie als auch an den Komponenten liegen. Je nach der Situation wird entweder die Umstrukturierung des Netzes oder Austausch der Komponenten durchgeführt. Das Projekt kann auch ebenfalls erst dann abgeschlossen werden, wenn die Ergebnisse der Überprüfung auf die Leistungsfähigkeit und die Kosten der vorgeschlagenen Lösung zufrieden stellen. Die ausführliche Betrachtung der Abläufe bei jeder Projektart wird den Rahmen dieser Arbeit sprengen, deswegen wird zur Analyse nur der Projekttyp Neu-Entwurf ausgesucht. Diese 18

22 Auswahl kann dadurch begründet werden, dass es möglich ist, anhand solcher Projektart die Netzwerkprojektierung im vollen Umfang zu darzustellen. 3.2 Ablauf im Projekt vom Typ Neu-Entwurf Das Projekt startet mit dem Sammeln der für die Entwicklung des Netzwerkprojektes relevanten Informationen. Dabei werden sowohl Ziele des Projektes und Anforderungen an das Netz erfasst als auch Kundenkontaktdaten, Gebäudeplan, Beschreibung der vorhandenen Infrastruktur, Kosten- und Zeitrahmen spezifiziert. Eine zentrale Stelle dabei nimmt die Analyse der Bedingungen, unter denen das Konzept entworfen wird. Zu solchen Bedingungen gehören sowohl die Anforderungen des Auftraggebers an das zu entwickelnde Netzwerkinfrastruktur als auch der Ist-Zustand des schon existierenden Netzes. Im Allgemeinen werden drei Arten von Anforderungen unterschieden: 1. organisatorische Anforderungen 2. funktionale Anforderungen 3. technische Anforderungen Die Abbildung 3-1 veranschaulicht eine mögliche Klassifizierung der Anforderungen: Abbildung 3-1: Klassifizierung von Anforderungen Zur Gruppe der organisatorischen Anforderungen werden diejenigen Parameter zugeordnet, die mit der Organisation und Durchführung des Projektes wie z.b. Projektstarttermin, Projektendtermin, maximales Budget verbunden sind. Die funktionalen Anforderungen bilden diejenigen Parameter, die die Funktionalität des Netzwerkes bestimmen, wie z.b. Anforderungen an Infrastruktur, Sicherheit, Datenrate, Qualität. Die Anforderungen dieser Klasse können in drei Gruppen (s. Abbildung 3-1) aufgeteilt werden: 1. Anforderungen an Infrastruktur 2. Anforderungen an Sicherheit 3. Anforderungen an Kapazität Die möglichen Beispiele zu jeder Kategorie sind in der Tabelle 3-1 aufgeführt. 19

23 Tabelle 3-1: Klassifizierung der funktionalen Anforderungen Anforderungstyp Beispiel Infrastruktur Anzahl und Art der Netzwerkelemente Örtliche Verteilung der Netzwerkelemente Logische Gruppierung der Netzwerkkomponenten Sicherheit Datenübertragung (verschlüsselt/unverschlüsselt ) Datenspeicherform Authentifizierung am Client Authentifizierung am Server Integritätsüberprüfung Dauerhaftigkeit (Backup und Recovery) Kapazität Anforderungen je Anwendung Nutzung der Anwendung (Häufigkeit, Dauer) Kommunikationsflüsse Im Folgenden werden die funktionalen Anforderungen näher betrachtet. Anforderungen an Netzwerkinfrastruktur Die Spezifizierung der Anzahl und Typ der in der Zukunft einzusetzenden Geräten (Rechner, Server, Drucker etc.) und Software spielt beim Planungsprozess eine wichtige Rolle, da es je nach dem Endgerätetyp entsprechende Anschlussmöglichkeiten vorgesehen werden sollen. Von Anfang an ist es möglich, nur die Art von den zukünftigen Endgeräten (z.b. Server oder Arbeitsstationen) zu bestimmen, da es über den Einsatz von den Koppelkomponenten erst in späteren Schritten z.b. nach dem Topologieentwurf entschieden werden kann. Die geographische Verteilung der Netzwerkkomponenten ist auch für die Entwicklung einer Netzwerkstruktur von großer Bedeutung, da sie die Auswahl der Topologie, der Übertragungsmedien und weiteren Komponenten (Großserver passen nur in die Räume bestimmter Größe) beeinflussen kann. Wenn noch keine Netzinfrastruktur vorhanden ist und diese erst aufgebaut werden soll, muss mit dem Auftraggeber geklärt werden, wo die geplanten Komponenten platziert werden sollen. Die Zuordnung eines Netzwerkelementes zu einer logischen Gruppe z.b. zu einer Abteilung innerhalb der Firma erlaubt eine effektive Organisation der Kommunikation unter Berücksichtigung von Sicherheitskriterien zu entwickeln. Dies bedeutet, dass die Teilnehmer anderer Abteilungen Subnetze auf ihre Ressourcen z.b. Dateiserver oder Drucker in der Regel nicht zugreifen dürfen. Aus diesem Grund ist die Aufteilung eines Netzes in mehrere Subnetze sinnvoll. Ein weiteres Ziel der Netzwerkgliederung ist die Lastverteilung. In diesem Fall werden andere Subnetze nicht berührt bedeutet, wenn innerhalb eines Subnetzes eine hohe Transferlast anliegt. 20

24 Anforderungen an Netzwerkkapazität Die Analyse der Anforderungen an Netzwerkkapazität ermöglicht später die richtige Entscheidung über die Auswahl der Technologie und Netzwerkkomponenten zu treffen. Das ist ein komplizierter Prozess, wobei die Anforderungen können oftmals nur grob abgeschätzt werden. Wenn das Netzwerk bereits besteht, ist es möglich den Netzwerkverkehr auf der Basis der Aufzeichnungen zu analysieren und die Rückschlüsse über die Kapazitätsanforderungen zu ziehen. Schwieriger ist es, die Anforderungen an Netzwerkkapazität zu bestimmen, wenn das Netzwerk gar nicht existiert oder die Aufzeichnungen nicht vorliegen, was der Fall beim Projekttyp Neu-Entwurf ist. Eine Möglichkeit dabei die Anforderungen zu beschreiben, wäre zwei für Netzwerkkapazität wichtige Einflussgrößen: Anforderungen je installierter bzw. geplanter Anwendung und Benutzungsverhalten je Anwendung zu bestimmen. Die Festlegung und Quantifizierung der Anforderungen einer Anwendung erfolgt entweder auf Basis ihrer Spezifikation oder, falls solche nicht vorhanden ist, auf Basis ihres Typs. Die Beschreibung des Benutzerverhaltens kann auf Basis von direkten Benutzerberfragungen erfolgen. Auf solche Weise gewonnene Daten ermöglichen die Aussagen darüber zu formulieren, wie viele Benutzer eine bestimmte Anwendung nutzen, wie oft eine Anwendung genutzt wird, wie lange eine durchschnittliche Anwendungssitzung dauert und wie viele parallele Anwendungssitzungen auftreten. Die Aufstellung von Mustern für die Anwenundungsbenutzung gilt als Voraussetzung für die Analyse des Verhaltens von Verkehrsströmen zu analysieren, Auswahl und Konfiguration von Komponenten. Anforderungen an Sicherheit Ein weiterer wichtiger Aspekt bei der Planung des Netzes stellt die Festlegung der Sicherheits- und Datenintegritätsanforderungen dar. Das Ziel dieses Schrittes besteht in der Identifizierung der Risiken für die existierende bzw. zu entwickelnde Netzwerklösung. Die schlecht ausgearbeitete Sicherheitsarchitektur kann einige Netzwerkeigenschaften beeinflussen, z.b. Erhöhung der Auslastung des Netzes, da die fehlerhafte Datenübertragung eine automatisierte erneute Übertragung resultiert. Es muss auch durch das Netzwerkkonzept garantiert werden, dass bestimmte Daten und Ressourcen nur von berechtigten Personen benutzt und verändert werden dürfen. Für die besonders sensiblen oder wichtigen Daten sollen die Sicherheitsmechanismen beispielsweise wie Mirroring, Duplexing eingesetzt werden, die ermöglichen, den Datenverlust zu vermeiden. Um Aussagen zu Sicherheitsanforderungen treffen zu können ist es notwendig, die vorhandenen Gefährdungspotentiale zu identifizieren und hinsichtlich ihrer Relevanz für das Netzwerk zu bewerten. Die technische Anforderungen sind Konventionen und Standards, die bei der Planung und Aufbau des Netzwerkes berücksichtigt werden sollen. Dazu gehören Verkabelungsrichtlinien, Richtlinien für die Dokumenterstellung, Vorgabe der Messmethoden und der Messrichtwerte, 21

25 Bestimmung der zulässigen Werte für technische Parameter (z.b. Dämpfung, Nahnnebensprechen und etc.), für die einzelnen Testreihen und Richtlinien für die Ausführung der Installationsarbeiten. Dabei sollten auch gerade in Bezug auf Transparenz und Wiederverwendbarkeit von Ergebnissen schon etablierte Standards genutzt werden (z. B. DIN für die Dokumenterstellung). Die ermittelten Anforderungen sollen dann bezüglich der fachlich-logischen Zusammenhänge unter einander bewertet werden, d.h., es muss festgestellt werden, welche Rahmenbedingungen andere voraussetzen oder gemeinsam mit anderen realisiert werden. Es wird auch überprüft, ob sie widerspruchsfrei, realisierbar, notwendig sind. Außerdem soll auch festgestellt werden, welche Anforderungen am wichtigsten sind, so kann z.b. billigere Lösung der zeitsichere bevorzugt werden. Die Analyse der Anforderungen wird mit der Erstellung und Unterzeichnung des Leistungsheftes abgeschlossen. Danach können die Projektanten mit dem eigentlichen Entwurf des Netzwerkes anfangen. Dabei sollen vorgegebene Ziele, Randbedingungen und Kriterien berücksichtigt werden. Beim Entwurf werden solche Schritte wie Analyse des Datenverkehrs, Erstellung der Topologie, Auswahl der Komponenten etc. betrachtet. Im Folgenden wird auf sie eingegangen werden. Informationsflüsse Ein Fluss beinhaltet eine Menge von Anwendungs- und Protokollinformationen, die gemeinsame Attribute wie Absender- und Empfängeradresse, Informationstyp, Richtung der Information enthalten. Die Flüsse können direkt einer Anwendung, einem Netzelement, einem Netzwerk oder einem Benutzer zugeordnet werden. Die Analyse der Informationsflüsse ermöglicht die Ermittlung der Kommunikationsbeziehungen im Netzt und der Kapazitäts- und Quality of Service (QoS)-Charakteristiken pro Übertragungsstrecke und Kopplungskomponente, was sowohl bei dem Entwurf der Topologie als auch der Auswahl der Übertragungsmedien und Kopplungselementen wichtig ist. Man unterscheidet zwischen den individuellen und zusammengesetzten Flüssen. Der Fluss, der während einer einzelnen Anwendungssitzung entsteht, wird als individueller Fluss bezeichnet. Der zusammengesetzte Fluss stellt die Kombination der individuellen Ströme dar, die durch gleiche QoS- Anforderungen charakterisieren und denselben Pfad, dieselbe Verbindung oder dasselbe Netzwerk nutzen. Zur Identifizierung und Richtungsbestimmung des Informationsflusses soll die Rolle (Quelle oder Senke) beider Endpunkte analysiert werden. Eine Datenquelle ist ein Gerät oder eine Anwendung, die hauptsächlich den Netzwerkverkehr produziert. Eine Datensenke erhält hauptsächlich Daten vom Netzwerk und fungiert als Datenspeicher. Es kommt auch vor, dass der Endpunkt beide Rollen besitzt, d.h. kann sowohl als Quelle als auch Senke auftreten. In [MJ98] wird ausführlich auf diese Problematik eingegangen. 22