Diplomarbeit Thorsten Hagedorn
Werbung
Diplomarbeit Konzeption und prototypische Entwicklung eines Systems zur Unterstützung der Deployment-Prozesse in Lotus Notes basierten Arbeitsumgebungen Prof. Dr. Ludwig Nastansky Wintersemester 2006/2007 Vorgelegt von: Thorsten Hagedorn Student der Wirtschaftsinformatik Matrikelnummer 6176654 Zum Türkenplatz 30 59457 Werl Inhaltsverzeichnis II Inhaltsverzeichnis 1 2 Einleitung .................................................................................................................. 1 1.1 Szenario und Motivation ................................................................................ 1 1.2 Zielsetzung ..................................................................................................... 2 1.3 Aufbau der Arbeit........................................................................................... 2 Thematische Einführung ......................................................................................... 4 2.1 2.2 2.3 2.4 Computer Supported Cooperative Work und Groupware .............................. 4 2.1.1 Computer Supported Cooperative Work ............................................ 4 2.1.2 Groupware .......................................................................................... 5 Extensible Markup Language....................................................................... 10 2.2.1 Historische Entwicklung .................................................................. 11 2.2.2 XML-Dokumente und ihre Struktur ................................................. 12 2.2.3 Programmierschnittstellen zu XML ................................................. 14 Softwareentwicklung .................................................................................... 15 2.3.1 Geschichte der Softwareentwicklung ............................................... 16 2.3.2 Die fünf Ebenen der Softwareentwicklung ...................................... 17 2.3.3 Modelle der Softwareentwicklung.................................................... 20 Deployment .................................................................................................. 25 2.4.1 3 Deployment Prozess ......................................................................... 25 Plattform IBM Lotus Notes/Domino .................................................................... 29 3.1 Allgemeine Konzepte ................................................................................... 31 3.2 Unterschiede zwischen Templates und Datenbanken .................................. 34 3.3 Designelemente unter Lotus Notes/Domino ................................................ 35 3.4 Standard Deploy Mechanismus von Lotus Notes/Domino .......................... 38 3.5 Extensible Markup Language unter Lotus Domino ..................................... 39 Inhaltsverzeichnis 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse ......... 42 4.1 Problemanalyse............................................................................................. 42 4.1.1 4.2 4.3 Analyse der allgemeinen Deployment-Prozesse .............................. 42 Anforderungen an das neue System ............................................................. 47 4.2.1 5 III Kernfunktionalitäten......................................................................... 49 Entwurf für die Erstellung einer solchen Software ...................................... 50 Prototypische Umsetzung ...................................................................................... 57 5.1 Umsetzung der Architektur .......................................................................... 57 5.2 Template- und Datenbankenverwaltung....................................................... 58 5.3 Anlegen von Templatedokumenten.............................................................. 60 5.4 Erstellen von Konfigurationsdokumenten .................................................... 61 5.5 Anlegen von Datenbankdokumenten ........................................................... 64 5.5.1 Erstellen von Datenbankdokumenten für vorhandene Anwendungen64 5.5.2 Erstellen von Datenbankdokumenten für neue Anwendungen ........ 65 5.6 Designaktualisierung vorhandener Datenbanken ......................................... 66 5.7 Anpassungsmöglichkeiten ............................................................................ 67 6 Zusammenfassung und Ausblick .......................................................................... 69 7 Quellenverzeichnis.................................................................................................. 71 Abkürzungsverzeichnis Abkürzungsverzeichnis ACL Access Control List ANSI American National Standard Institute API Application Programming Interface CD-ROM Compact Disc read-only memory COM Component Object Model CSCW Computer Supported Cooperative Work CSS Cascading Stylesheet DIN Deutsche Industrie Norm DOM Document Object Model DTD Document Type Definition DXL Domino XML Language DVD Digital Versatile Disc GCC Groupware Competence Center GML Generalized Markup Language HTML Hypertext Markup Language IBM International Business Machines ID Identifikator ISO International Organisation for Standardization IT Informationstechnologie KOS Komponentenorientierte Softwareentwicklung LDOM Lotus Domino Object Modell NOS Notes Object Services NSF Notes Storage Facility PC Personal Computer SAX Simple API for XML IV Abkürzungsverzeichnis SGML Standard Generalized Markup Language UNID Universal ID W3C World Wide Web Consortium WYSIWYG What You See Is What You Get XML Extensible Markup Language XSD XML Schema Definition XSL Extensible Stylesheet Language XSL-FO Extensible Stylesheet Language-Formating Objects XSLT Extensible Stylesheet Language Transformation V Abbildungsverzeichnis VI Abbildungsverzeichnis Abbildung 1: Klassifikationsschema nach Unterstützungsfunktionen.......................................8 Abbildung 2: Zusammenhang von SGML, XML, HTML, CSS und DSSL ............................10 Abbildung 3: Die historische Entwicklung bis zur Extensible Markup Language ..................11 Abbildung 4: Baumstruktur eines XML Dokumentes..............................................................13 Abbildung 5: Wasserfallmodell................................................................................................21 Abbildung 6: Prototyping .........................................................................................................23 Abbildung 7: Spiralmodell .......................................................................................................24 Abbildung 8: Deployment Prozess...........................................................................................26 Abbildung 9: Drei Typen der Sicherheit ..................................................................................33 Abbildung 10: Ein Template kann Vorlage für mehrere Datenbanken sein ............................35 Abbildung 11: Beziehungen zwischen allgemeinen Design Elementen und Daten.................38 Abbildung 12: Vergleich XML und Domino Architektur........................................................40 Abbildung 13: Ändern von Domino Objekten per DXL..........................................................41 Abbildung 14: Architektur des zu erstellenden Systems mit Repository in der Zielumgebung .......................................................................................................................50 Abbildung 15: Architektur des zu erstellenden Systems mit Repository in einer Drittumgebung..................................................................................................51 Abbildung 16: Mechanismus zum Verteilen neuer Anwendungen..........................................53 Abbildung 17: Prozess zum Aktualisieren bestehender Anwendungen allgemein ..................54 Abbildung 18: Unterprozess zum Aktualisieren ohne Ausschluss von Designelementen.......55 Abbildung 19: Unterprozess zum Aktualisieren bestehender Anwendungen unter Ausschluss ausgewählter Designelemente ..........................................................................55 Abbildung 20: Architektur zur Implementierung von speziellen Funktionen..........................56 Abbildung 21: Einstiegspunkte zu den Kategorien ..................................................................58 Abbildung 22: Kategorisierung von Templates nach Server....................................................59 Abbildung 23: Verwaltung von Datenbanken ..........................................................................59 Abbildungsverzeichnis VII Abbildung 24: Gemischte Ansicht mit Template-, Datenbank- und Konfigurationsdokumenten ..............................................................................60 Abbildung 25: Form zum Erfassen von Templatedokumenten................................................61 Abbildung 26: Form zum Erfassen von Konfigurationsdokumenten.......................................62 Abbildung 27: Defektes Konfigurationsdokument ..................................................................63 Abbildung 28: Ansicht mit fehlerhaftem Konfigurationsdokument ........................................64 Abbildung 29: Erstellen eines Datenbankdokuments...............................................................65 Abbildung 30: Vorgang zum Erstellen neuer Anwendungen...................................................66 Abbildung 31: Vorgang zum Aktualisieren von Anwendungen ..............................................67 Abbildung 32: Architektur für Anpassungsmöglichkeiten.......................................................68 Tabellenverzeichnis VIII Tabellenverzeichnis Tabelle 1: Raum-Zeit-Matrix mit Groupware-Typen und Werkzeugen ....................................5 Tabelle 2: Standardarten des Domino Servers und ihre Funktionalitäten ................................30 Tabelle 3: Designelemente von Lotus Notes/Domino..............................................................37 Tabelle 4: Vergleich der Aktivitäten beim Deployment zwischen dem allgemeinen Deployment Prozess und dem Standard Lotus Notes/Domino Deployment Prozess ................................................................................................................................46 1 Einleitung 1 1 Einleitung 1.1 Szenario und Motivation „Die Technik verändert sich heute so rasant, daß es nur einen Weg gibt, den vollen Nutzen einer Software auszukosten, bevor sie bereits wieder überholt ist: Nehmen Sie ein Taxi vom Computerladen bis nach Hause!“ Robert "Bob" Orben (*1927) Das Zitat von Robert „Bob“ Orben besitzt heute mehr Gültigkeit denn je. Die Schnelllebigkeit im Bereich der Technik und Computerentwicklung nimmt immer mehr zu. Dinge, die heute angeschafft werden, können morgen schon veraltet sein. Das trifft auch auf Software zu, die auf immer hochleistungsfähigeren Computern eingesetzt wird und der sich durch die immer höhere Leistungsfähigkeit immer mehr Möglichkeiten bieten Anwendungen noch effizienter und besser zu gestalten. Außerdem bietet die ständige Weiterentwicklung Möglichkeiten neue Bereiche in der Softwareentwicklung zu erschließen, wie zum Beispiel die Vorhersage komplexer Wettervorhersagen. Diese immer leistungsfähigere Technik unterstützt Unternehmen bei ihrem Drang nach Globalisierung. Die Kommunikation zwischen den weltweit angesiedelten Niederlassungen wird durch immer effizientere Technik ständig weiter verbessert. Es begann alles mit der Papier basierten Kommunikation, danach wurden Techniken und Geräte, wie Telegraphie, Fernschreiber und Faxgeräte eingesetzt. Die wohl wichtigste Erfindung war das Internet in den 90er Jahren. Ab diesem Zeitpunkt gab es kein Halten mehr und jeder Brief war mit einem Knopfdruck, per E-Mail, an das andere Ende der Welt verschickt. Es blieb aber nicht bei der reinen Kommunikation, sondern es gab immer neue Anforderungen und Wünsche, wie der Ruf nach IT gestützter kooperativer Arbeit von Mitarbeitern aus der ganzen Welt. Dies war mit den vorhandenen Technologien nicht optimal zu bewerkstelligen. Aus diesen Anforderungen ergab sich die Notwendigkeit neue Konzepte zur vernetzten Zusammenarbeit zu entwickeln. Eines dieser Konzepte ist der Groupware-Lösungsansatz, der zum Ziel hat Mitarbeiter bei der Gruppenarbeit zu unterstützen. Neben den eben geschilderten Problemen traten auch andere, ganz neue Herausforderungen auf, denen es galt sich zu stellen. Durch global agierende Konzerne und deren weltweit ver- 1 Einleitung 2 netzte IT-Systeme ist es für Administratoren sehr schwer geworden den Überblick über die gesamte Softwarelandschaft zu behalten. Vor allem die Installation und Aktualisierung erforderten eine systemweit integrierte Deploymentstrategie. Häufig kommt es vor, dass Niederlassungen und teilweise sogar einzelne Abteilungen und Arbeitsgruppen eine eigene Installation einer Software bekommen. In solchen Fällen muss viel organisatorische Vorarbeit geleistet werden, um dies zu bewerkstelligen. Besonders bei Software Aktualisierungen muss ein Überblick über die bestehenden Installationen vorhanden sein. Große weltweit operierende Konzerne haben Lotus Notes als Kommunikations- und Groupware-Plattform im Einsatz und müssen sich mit diesen Aufgaben alltäglich befassen. Bezogen auf Lotus Notes basierte Anwendungen existieren in der Literatur bislang nur wenige Ansätze, wie diese Probleme zu lösen sind. Dabei ist gerade auch Lotus Notes/Domino mit seiner verteilten Client-Server Architektur eine Plattform, auf die oben beschriebene Problematik zutrifft. 1.2 Zielsetzung Die vorliegende Arbeit soll die geschilderte Problematik aufnehmen und einen Lösungsansatz im Bereich Deployment unter Lotus Notes geben. Es ist Ziel der Arbeit sich mit dem Thema Deployment auseinanderzusetzen und eine Architektur zu konzipieren, mit der es möglich ist Deployment-Prozesse für Lotus Notes Anwendungen zu unterstützten. Dabei ist besonderes Augenmerk auf die technischen Eigenschaften von Lotus Notes Datenbanken und deren Designelemente zu legen. Unter Berücksichtigung der technischen Möglichkeiten von Lotus Notes und der theoretischen Erkenntnisse über Deployment soll eine prototypische Entwicklung auf Basis der entwickelten Architektur den Abschluss der Arbeit bilden. 1.3 Aufbau der Arbeit Nachdem Fragestellung und Zielsetzung der vorliegenden Arbeit aufgezeigt wurden, werden im folgenden zweiten Kapitel grundlegende Begriffe wie Computer Supported Cooperative Work, Groupware oder Deployment definiert und erläutert. Diese Definitionen bilden im weiteren Verlauf die Basis der Ausführungen. Zusätzlich wird in diesem Kapitel der thematische Rahmen der Arbeit eingegrenzt. 1 Einleitung 3 Das dritte Kapitel widmet sich der Groupware Plattform Lotus Notes/Domino, die als Grundlage für die prototypische Entwicklung des Systems zur Unterstützung der DeploymentProzesse herangezogen wird. Das Konzept für den im Rahmen dieser Arbeit entwickelten Prototyp wird schließlich im vierten Kapitel vorgestellt. An dieser Stelle werden zuerst allgemeine Funktionalitäten untersucht, die ein Werkzeug mitbringen muss, das Deployment-Prozesse unterstützt. Anschließend werden diese Funktionalitäten analysiert und in Bezug auf das Einsatzgebiet im Bereich Lotus Notes/Domino eingegrenzt und übertragen. Daraus ergeben sich die Grundlagen für die Architektur des zu entwickelnden Prototyps mit seinen Kernfunktionalitäten. Im anschließenden fünften Kapitel wird die Umsetzung des in Kapitel vier vorgestellten Konzeptes betrachtet. Hier werden alle Eigenschaften und Funktionalitäten, die der entwickelte Prototyp besitzt, vorgestellt und im Hinblick auf ihre Umsetzung beschrieben. Den Abschluss bildet das sechste Kapitel, das die vorliegende Arbeit nochmals zusammenfasst und einen Ausblick für weitere Forschungs- und Entwicklungsarbeit gibt. 2 Thematische Einführung 4 2 Thematische Einführung Der Inhalt dieses Kapitels grenzt thematischen Rahmen der Arbeit ein. Dabei werden folgende Themen näher betrachtet. Als erstes wird auf die Thematik um Computer Supported Cooperative Work und Groupware eingegangen, bevor sich der Thematik der Extensible Markup Language gewidmet wird. Als Dritter Punkt wird der Softwareentwicklungsprozess näher betrachtet. Zum Schluss wird dann der Begriff Deployment thematisiert. 2.1 Computer Supported Cooperative Work und Groupware 2.1.1 Computer Supported Cooperative Work Den Begriff Computer Supported Cooperative Work prägten Cashmann und Greif im Jahre 1984. 1 „Computer Supported Cooperative Work (CSCW) stellt ein interdisziplinäres Forschungsgebiet dar.“ 2 Dieses bildet mit seinen Theorien die Grundlage für Groupware Applikationen und wird „in der Literatur nahezu durchgängig als wissenschaftlicher Rahmen beschrieben“ 3 . In der Forschung kann man CSCW nach Hasenkamp, Kirn und Syring in drei eng miteinander verbundene Bereiche aufteilen: 4 • Entwicklung eines Verständnisses der Zusammenarbeit und Koordination • Entwicklung von Konzepten und Werkzeugen zur Unterstützung der Zusammenarbeit und Koordination und deren Prozesse • Bewertung dieser Konzepte und Werkzeuge Das Ziel von CSCW ist es, mit Hilfe von Kommunikations- und Informationstechniken die Zusammenarbeit von Menschen, z.B. innerhalb von Arbeitsgruppen und Teams, flexibler und 1 Vgl. [Greif 1988] S. 5ff.; zitiert in [Nastansky et al. 2002] S. 238 und vgl. [Teufel et al. 1995] S. 17. 2 Siehe [Nastansky et al. 2002], S. 238. 3 Siehe [Nastansky et al. 2002], S. 239. 4 Vgl. [Hasenkamp / Kirn / Syring 1994], S.15-16. 2 Thematische Einführung 5 effizienter zu gestalten. 5 Unterschiedlichste Wissenschaftsbereiche, wie Wirtschaftsinformatik, Arbeitswissenschaft, Psychologie und Kommunikationswissenschaft, liefern dazu Themen für das Forschungsgebiet, wodurch dessen Interdisziplinarität charakterisiert wird. 6 2.1.2 Groupware Für den Begriff Groupware existiert in der Literatur keine eindeutige Definition. Nastansky et al. beschreiben Groupware als Lösungen, die computergestützte Konzepte für Teamarbeit bereitstellen. Besondere Beachtung sollte dabei der Unterstützung des Arbeitsflusses und des Vorgangsmanagements in den vielfältigen Kommunikations- und Arbeitsinteraktionen zwischen Mitarbeiterinnen und Mitarbeitern im Office Bereich bzw. in Projektteams geschenkt werden. 7 Die beiden Autoren Johnson und Lenz verwendeten 1982 als Erste den Begriff Groupware und beschrieben damit ein Softwaresystem und die damit zusammenhängenden Prozesse der Benutzergruppen. Zusammenarbeit Zur gleichen Zeit Zu verschiedenen Zeit Teammitglieder (synchron) (asynchron) Am gleichen Ort (lokal) An verschiedenen Orten (verteilt) • System zur computerunterstützten Sitzungsmoderation • Systeme zum Terminkalendermanagement für Gruppen • Präsentationssysteme • Projektmanagement-Systeme • Group Decision Support Systeme • Audio- und Videokonferenzsysteme • E-Mail-Systeme • • Voice-Mail-Systeme Screen-Sharing-Systeme • • Mehrautorensysteme System für Electronic Conferencing • Shared Information Systems • Workflow-Systeme Tabelle 1: Raum-Zeit-Matrix mit Groupware-Typen und Werkzeugen 8 5 Vgl. [Nastansky et al. 2002], S. 238. 6 Vgl. [Nastansky et al. 2002], S. 239. 7 Vgl. [Nastansky et al. 2002], S. 239. 8 Vgl. [Johansen 1988], S. 44 und vgl. [Nastansky et al. 2002], S. 240. 2 Thematische Einführung 6 Bekannt geworden ist der Ausdruck Groupware erst später durch Johanson, der darunter Applikationen, die kleine Arbeitsgruppen unterstützen sollen, versteht. 9 Er kategorisiert Groupware-Applikationen in Bezug auf ihre zeitliche und örtliche Verteilung der Gruppenarbeit in einer Raum-Zeit-Matrix (siehe Tabelle 1). Neben der Einteilung in die Raum-Zeit-Matrix „lassen sich Groupware-Applikationen nach ihren elementaren Unterstützungsfunktionen gliedern.“ 10 Bei den Funktionalitäten wird zwischen Kommunikations-, Kooperations- und Koordinationsfunktionalitäten unterschieden, wobei diese Funktionalitäten eng miteinander verknüpft sind. 11 Dabei bildet die Kommunikation die Grundlage für die anderen beiden Funktionen - Kooperation und Koordination. Kommunikation beinhaltet den Austausch von Informationen und Daten mit Hilfe verschiedenster Systeme, wie z.B. E-Mail oder Instant Messaging. Bei der Kooperation, die auf der Dimension der Kommunikation aufsetzt, werden die Benutzer von Arbeitsgruppen bei der Zusammenarbeit unterstützt. Dies geschieht mit Hilfe von Systemen, bei denen die Gruppenmitglieder auf einen gemeinsamen Datenbestand zurückgreifen und diesen beliebig verändern und erweitern können. Hierbei spielt die Reihenfolge, in der die Benutzer den Datenbestand verändern keine Rolle. Ein sequentieller Ablauf, wie er zum Beispiel bei E-Mail-Systemen vorliegt, ist nicht zwingend erforderlich. Die Koordination schließlich ist verantwortlich für eine effiziente Gruppenarbeit sowie für den optimalen Einsatz von Ressourcen. Um dies umzusetzen, bedient sich die Koordination geeigneter Kommunikationsprozesse und setzt so ebenfalls, wie die Kooperation, auf der Dimension der Kommunikation auf. 12 Auf der Grundlage der drei Dimensionen Kommunikation, Kooperation und Koordination lassen sich folgende Systemklassen unterscheiden 13 : 9 • Workflow Management • Workgroup Computing • Shared Information Space • Kommunikation Vgl. [Nastansky et al. 2002], S. 239 und vgl. [Johansen 1988]. 10 Siehe [Nastansky et al. 2002], S. 240. 11 Vgl. [Lotus 1995]. 12 Vgl. [Nastansky et al. 2002], S. 240ff. 13 Vgl. [Teufel et al. 1995], S. 28. 2 Thematische Einführung 7 Diese Einteilung ermöglicht nun die Zuordnung von verschiedensten GroupwareAnwendungen zu den Systemklassen (siehe Abbildung 1). Als Workflow wird eine zeitlich-strukturelle Aneinanderreihung von Teilaufgaben bezeichnet, die zur Bearbeitung eines gesamten Vorganges nötig sind. 14 Die Teilaufgaben setzen sich dabei aus verschiedenen Aktivitäten zusammen und werden durch unterschiedliche Ereignisse ausgelöst. Workflow Management hingegen umfasst nach Dierker und Sander verschiedene Aktivitäten, wie Analyse, Modellierung, Implementierung, Monitoring und Redesign. 15 Workflow Management Systeme sind letztendlich die computergestützten Anwendungen, die alle Aktivitäten vereinen und die arbeitsteiligen Prozesse und Vorgänge steuern. Bei Workflow Management Systemen lassen sich drei Arten von Systemen unterscheiden. Als erstes seien hier die Transaktions Workflow Management Systeme genannt. Diese zeichnen sich durch eine hohe Regelgebundenheit aus. Die Bearbeiter sind hierbei weitestgehend fremdgesteuert und haben auf Grund der im Voraus definierten Vorgänge und Abläufe wenige Eingriffsmöglichkeiten. Als zweites sind die Ad-hoc Workflow Management Systeme zu nennen. Diese Systeme sind im Gegensatz zu den transaktionsorientierten Systemen wesentlich flexibler einzusetzen, da sie weniger stark regelgebunden sind. Diese Systeme unterstützen weniger komplexe und unstrukturierte Aufgabenstellungen. Die einzelnen Workflows können vom Anwender selbst definiert werden. Als dritte Art existieren Synergetische Workflow Management Systeme. Diese Systeme bilden eine Zwischenform und können sowohl transaktionsgesteuerte als auch Ad-hoc basierte Workflows abbilden. 14 Vgl. [Nastansky et al. 2002], S. 243. 15 Vgl. [Dierker / Sander 1998], S. 110. 2 Thematische Einführung 8 Abbildung 1: Klassifikationsschema nach Unterstützungsfunktionen 16 Als Workgroup Computing Systeme werden Systeme bezeichnet, die Anwendern in Teams eine gemeinschaftlich nutzbare computerbasierte Umgebung bieten und sie bei der Erfüllung ihrer gemeinsamen Aufgaben unterstützen. Die Unterstützung von Kommunikation, Koordination, Treffen von Gruppenentscheidungen sowie die gemeinsame Bearbeitung von Objekten stehen dabei im Vordergrund. 17 Ein Beispiel für eine solche Umgebung ist z.B. ein mit Informationstechnologie ausgestatteter Konferenzraum. Die Informationstechnologie dient in diesem Falle der Mensch-Mensch-Kommunikation. Die Systemklasse Shared Information Space bzw. ge meinsame Informationsräume beinhaltet Groupware-Anwendungen, die nach Nastansky „der verteilten Nutzung von Informationen dienen, und bei denen gemeinsame Informationsbestände als eine wesentliche Komponente der Kommunikations-, Kooperations- und Koordinationsunterstützung zu betrachten sind.“ 18 Mit Hilfe von gemeinsamen Informationsräumen und deren Groupware-Anwendungen wer- 16 Siehe [Nastansky et al. 2002], S. 243. 17 Vgl. [Petrovic 1993], S.6. 18 Siehe [Nastansky et al. 2002], S. 247. 2 Thematische Einführung 9 den strukturierte und unstrukturierte Informationen zur verteilten Nutzung bereitgestellt und diese für längere Zeit und in geeigneter Form gespeichert. Kommunikationssysteme, wie E-Mail-Systeme oder verallgemeinert Messaging-Systeme, dienen der elektronischen Nachrichten- und Dokumentenübermittlung, wobei MessagingSysteme eine Weiterentwicklung traditioneller E-Mail-Systeme darstellen. Diese Systeme stellen einen grundlegenden Bestandteil von Groupware-Anwendungen dar und haben die Aufgabe, den Informationsaustausch zwischen Teammitgliedern und Kommunikationspartnern außerhalb des Teams zu unterstützen und dabei Raum und Zeitdifferenzen zu überbrücken. 19 „Groupware ist nicht als ein einzelnes, konkretes Produkt, sondern vielmehr als ein Zusammenwirken unterschiedlicher Funktionalitäten zu sehen, welche die Operationalisierung der computergestützten Teamarbeit in Office Umgebung ermöglichen.“20 Damit ist gemeint dass Groupware selbst nicht als Anwendungen existieren kann. Der Begriff Groupware setzt sich vielmehr aus verschiedenen Funktionalitäten zusammen. Nastansky et al. nennt in diesem Zusammenhang folgende Funktionalitäten weist aber auch darauf hin, dass diese Aufstellung nicht vollständig ist: 21 • Verteilte Datenbankarchitektur und Replikation • Integrierte Teamkommunikation • Compound Documents • Dokumenten und Transaktionsmanagement • Sicherheits- und Zugangskonzepte • Entwicklungsumgebung • Integrationskonzept für heterogene Umgebungen der Informationstechnologie 19 Vgl. [Nastansky et al. 2002], S. 248f und vgl. [Teufel et al. 1995] S.28. 20 Siehe [Nastansky et al. 2002], S. 249. 21 Vgl. [Nastansky et al. 2002], S. 249ff. 2 Thematische Einführung 10 2.2 Extensible Markup Language In diesem Kapitel wird eine kurze Einführung in die Extensible Markup Language, kurz XML, gegeben. Da XML in Verbindung mit Lotus Notes/Domino für das später folgende Konzept und die prototypischen Umsetzung relevant ist, sind Grundkenntnisse über XML unerlässlich. Über die für die Arbeit erforderlichen Kenntnisse hinausgehende Einzelheiten und Erläuterungen sind den in diesem Kapitel genannten Quellenangaben zu entnehmen. „Die Extensible Markup Language (XML) ist eine Teilmenge von SGML, […]. Das Ziel ist es, zu ermöglichen, generic SGML in der Weise über das Web auszuliefern, zu empfangen und zu verarbeiten, wie es jetzt mit HTML möglich ist. XML wurde entworfen, um eine einfache Implementierung und Zusammenarbeit sowohl mit SGML als auch mit HTML zu gewährleisten.“ 22 DSSSL formatiert & transformiert SGML HTML definiert XML formatiert CSS XHTML formatiert & transformiert XSL XSLT Auszeichnungssprachen Formatierungs- und Transformationssprachen Abbildung 2: Zusammenhang von SGML, XML, HTML, CSS und DSSL 23 22 Siehe [XML 2000-1]. 23 Vgl. [Behme / Mintert 2000], S. 23. 2 Thematische Einführung 11 2.2.1 Historische Entwicklung Das Konzept von SGML stammt aus dem Jahr 1967, als William Tunnicliffe den Vorschlag machte, Informationen von ihrer äußeren Form zu trennen. Das war die Geburtsstunde des generic coding. William Tunnicliffe (GCA) Stanley Rice 1967 Norman Scharpf (Direktor GCA) generic coding editorial structure tags GenCode-Komitee Goldfarb, Mosher, Lorie (IBM) 1969 ANSI Charles Goldfarb 1978 ISO 1986 SGML (ISO 8879) Tim Berners-Lee (CERN) 1989 HTML Marc Andreessen (NCSA) 1993 HTML-Formulare (XMosaic) Netscape Microsoft 1994 HTML-Abweichungen Dave Raggett (W3C) Håkon Lie (W3C) W3C (Jon Bosak (SUN) James Clark et.al.) GML HTML CSS 1997 XML Abbildung 3: Die historische Entwicklung bis zur Extensible Markup Language 24 24 Vgl. [Behme / Mintert 2000], S. 36. 2 Thematische Einführung 12 Eine ähnliche Idee, die auf der gleichen Methode basiert, hatte zu der Zeit Stanley Rice. Zunächst nannte man das Prinzip editorial structure tags, später wurde daraus generic markup. Als New Yorker Buch-Designer hatte er die Idee, Korrektur und inhaltliche Überprüfung von Manuskripten vom Layout und den Design-Entscheidungen zu trennen. Später entwickelte Norman Sharp das GenCode-Konzept mit einem eigens dafür gegründeten Komitee. 1969 entwickelten Charles Goldfarb, Edward Mosher und Raymond Lorie bei IBM die Generalized Markup Language (GML). Die formale Definition eines Dokumententyps war erstmals in dem Konzept von GML enthalten. 1978 wurde vom American National Standard Institute (ANSI) ein Komitee gegründet mit der Aufgabe, eine standardisierte Textbeschreibungssprache auf GML Basis zu entwickeln. 1986 wurde unter dem ISO-Standard 8879 die Standard Generalized Markup Language (SGML) veröffentlicht. 25 Auf Basis der Konstruktion von SGML wurde im Februar 1998 die Version 1.0 der Extensible Markup Language offiziell vom World Wide Web Consortium (W3C) freigegeben. Die aktuellste Version ist zurzeit die Version 1.1 (zweite Auflage) vom 16. August 2006. 26 2.2.2 XML-Dokumente und ihre Struktur Ein XML-Dokument ist ein Datenobjekt, in dem sich strukturierte und semi-strukturierte Daten ablegen lassen. Der Inhalt eines Dokuments kann sowohl aus reinem Text als auch aus Bildern, Videos etc. bestehen. XML-Dokumente weisen eine Baumstruktur auf, die sich im Wesentlichen aus Elementen zusammensetzt. In der Literatur werden diese Elemente auch häufiger als Entities bezeichnet. Solche Entities können sowohl Daten als auch andere Elemente enthalten. Darüber hinaus können einem Element zusätzliche Informationen, so genannte Attribute, mitgegeben werden. Das Element, das alle anderen Elemente enthält und somit das oberste in der Hierarchie der Baumstruktur darstellt, nennt man Wurzelelement. Die darunter liegenden Einheiten nennt man Unterelemente. Diese können Zweige oder Blätter sein wobei ein Zweig noch weitere Unterelemente besitzt, ein Blatt nicht (siehe Abbildung 4). 27 25 Vgl. [Behme / Mintert 2000], S.35ff und vgl. [Goldfarb / Prescod 2000]. 26 Vgl. [XML 2006-1]. 27 Vgl. [Goldfarb / Prescod 2000], S. 68-69. 2 Thematische Einführung 13 Abbildung 4: Baumstruktur eines XML Dokumentes XML besitzt, wie jede andere Sprache auch, eine Grammatik, die es einzuhalten gilt. Genügt ein XML-Dokument der Grammatik, nennt man es wohlgeformt. Ein textuelles Objekt ist ein wohlgeformtes XML-Dokument, wenn: 1. Es als Gesamtheit betrachtet mit der oben beschriebenen Struktur übereinstimmt. 2. Es alle Wohlgeformtheitsbeschränkungen, die vom W3C genannt werden, erfüllt. 3. Jedes seiner analysierten Elemente, das direkt oder indirekt referenziert wird, wohlgeformt ist. 28 Neben der Wohlgeformtheit bildet die Gültigkeit ein weiteres Kriterium für XMLDokumente. „Ein Dokument ist gültig, wenn in seiner Dokumententyp-Deklaration die Konformität mit einer DTD deklariert wird und es mit dieser DTD tatsächlich übereinstimmt.“ 29 Dokumententyp-Deklarationen, kurz DTD, beschreiben den strukturellen Aufbau und die logischen Elemente einer Klasse von Dokumenten, die man Dokumententyp nennt. 30 Eine DTD ordnet ein XML-Dokument einem Dokumententyp zu. Nicht alle XML-Dokumente haben eine DTD, woraus sich aber nicht schließen lässt, dass diese dann keinem Dokumenten- 28 Vgl. [XML 2000-1]. 29 Siehe [Goldfarb / Prescod 2000], S. 77. 30 Vgl. [Behme / Mintert 2000], S. 53. 2 Thematische Einführung 14 typ zugeordnet werden können. So kann es sein, dass sie lediglich keiner formal definierten DTD entsprechen. Bei einer DTD handelt es sich um eine Schemasprache. Neben der DTD existiert noch eine weitere Schemasprache, XML-Schema genannt. Das XML-Schema definiert ebenfalls eine Klasse von Dokumenten und ihre Struktur. 31 Erst im Jahr 2001 veröffentlicht, weist das XML-Schema gegenüber der DTD deutliche Vorteile auf. In einer DTD ist es dem Programmierer nicht möglich, zwischen mehreren Datentypen zu unterscheiden - es können ausschließlich Textdaten definiert werden. Des Weiteren entspricht eine DTD nicht der Struktur von XML. Mit dem XML-Schema sind diese beiden Nachteile behoben worden, so können in einem XML-Schema zulässige Datentypen definiert werden und die Struktur ist XML konform. Neben diesen beiden Sprachen existieren noch weitere, denen aber in der Praxis weniger Bedeutung zu kommt und die daher an dieser Stelle vernachlässigt werden können. Da in XML die Daten von der Darstellung getrennt werden, existieren neben den gewöhnlichen Datendokumenten noch Stylesheets. Im World Wide Web wird eine sehr einfache Stylesheetsprache verwendet. Diese trägt den Namen Cascading Style Sheets (CSS). Da diese nicht ausreicht, um XML-Dokumente komplett zu beschreiben, hat das W3C eine ergänzende Alternative zur CSS entworfen, die Extensible Stylesheet Language (XSL). Diese besteht aus zwei Teilbereichen: Der erste Teil ist für die Formatierung zuständig und wird Extensible Stylesheet Language – Formatting Objects (XSL-FO) genannt. Der zweite Teil ist die Extensible Stylesheet Language for Transformations (XSLT). Damit können XML-Daten in andere XML konforme und nicht XML konforme Datenformate konvertiert werden. 2.2.3 Programmierschnittstellen zu XML Programmierschnittstellen zu XML werden in der Regel durch Parser abgebildet. Ein Parser liest das Dokument vollständig oder teilweise ein und zerlegt die Textdarstellung in eine Reihe von begrifflichen Objekten. 32 Zusätzlich kann er anhand der DTD feststellen, ob ein Dokument gültig ist. Die beiden gängigsten XML-Parser sind das Document Object Model 31 Vgl. [XML 2001-1]. 32 Vgl. [Goldfarb / Prescod 2000], S. 81. 2 Thematische Einführung 15 (DOM) und die Simple API for XML (SAX). Beide Parser sind in allen gängigen Programmiersprachen implementiert und können so genutzt werden. Das DOM ist vom W3C als Standard Application Processing Interface (API) für die Verarbeitung von XML vorgegeben worden. Der DOM-Parser liest zur Verarbeitung eines Dokumentes das ganze Dokument ein, bildet daraus eine Baumstruktur und legt diese im Speicher ab. So sind alle Informationen schnell zugänglich. Die API des DOM bietet dem Anwender zusätzlich Methoden zum Bearbeiten der Baumstruktur an, so können Elemente geändert, hinzugefügt oder gelöscht werden. Der Nachteil des DOM liegt darin, dass es bei XMLDokumenten mit einer zu großen Dateigröße, es den Computer bei zu geringer Speicherkapazität zum Absturz bringen kann. Der SAX-Parser hingegen geht „ereignisorientiert“ vor: Er liest nicht das ganze Dokument ein und bildet daraus die Baumstruktur ab, sondern immer nur die Fragmente, die er gerade benötigt. Bei dieser Methode spielt die Größe der Dokumente eine untergeordnete Rolle, allerdings gibt es auch hier einen Nachteil: sind in einem Dokument die benötigten Informationen stark verteilt, so kommt es beim SAX-Parser zu Geschwindigkeitsproblemen, da hier immer erst die richtigen Stellen im Dokument gefunden werden müssen. 2.3 Softwareentwicklung Die Softwareentwicklung umfasst ein großes Gebiet an Aufgaben, Tätigkeiten und wissenschaftlichen Themen. Das Deployment von Software ist der Teilbereich der Softwareentwicklung auf den im Rahmen dieser Arbeit der Fokus gelegt wird (vgl. Kapitel 2.4). Darüber hinaus gehört zu dieser Arbeit die prototypische Entwicklung einer Software, weshalb an dieser Stelle eine kurze Einführung gegeben wird, was Softwareentwicklung bedeutet und darüber hinaus werden deren Grundzüge erläutert. 2 Thematische Einführung 16 2.3.1 Geschichte der Softwareentwicklung In der Vergangenheit waren Softwareprojekte mit hohen Erfolgsrisiken behaftet. Studien aus den 70er Jahren ergaben, dass ca. 33% der damaligen Softwareprojekte scheiterten, und von den erfolgreichen Projekten 85% ihre Kosten um 15% überschritten. 33 Gründe für das Scheitern bzw. die Kostenüberschreitungen dieser Projekte sind in den Tatsachen zu sehen, dass es zu jener Zeit keinerlei Prozessmodelle oder Schätzmethoden gab. Auch Qualitätsmanagement und Objektorientierung waren damals noch Fremdwörter. 34 Auch in späteren Jahren gab es noch immer Misserfolge. So belegt eine Studie von 1994 der Standish-Gruppe 35 , dass von den untersuchten Projekten 31% vor Fertigstellung abgebrochen wurden. Eine Verdoppelung des ursprünglich geplanten Budgets gab es bei jedem zweiten Projekt. Ein Drittel der Projekte konnte seine Projektziele nie erreichen und nur 16% wurden ohne Budget- und Zeitüberschreitung erfolgreich abgeschlossen. In der heutigen Zeit ist die Erfolgswahrscheinlichkeit der Projekte angestiegen. Der CHAOSForschungsbericht der Standish-Gruppe aus dem Jahr 2004 weist positive Tendenzen aus, allerdings ist er kein Aushängeschild für die IT-Branche. Auch wenn 29% aller untersuchten Projekte erfolgreich beendet worden sind und nur 19% abgebrochen wurden, so haben 53% die Budget und Zeitplanungen überschritten. Die positive Entwicklung ist auf zwei gegenläufige Trends zurückzuführen, die nach dem Jahr 2000 entstanden. Zum Einen wurden immer kürzere Entwicklungszeiten für neue Softwareprojekte gefordert, was zu Vorgehensweisen wie Extreme Programming 36 führte, zum Anderen erhielten einheitliche Realisierungs- und Modellierungstechniken Einzug in die Softwareentwicklung. 37 33 Vgl. [Winter 2005], S. 3. 34 Vgl. [Winter 2005], S. 3. 35 Vgl. [Standish 1995], zitiert in [Winter 2005] S. 3. 36 Für weitere Informationen siehe [Beck / Fowler 2001]. 37 Vgl. [Winter 2005], S. 5. 2 Thematische Einführung 17 2.3.2 Die fünf Ebenen der Softwareentwicklung Die Herausforderung bei der Softwareentwicklung ist, dass viele verschiedene Anwendungsgebiete für Software existieren. Daraus resultieren ebenso viele Vorgehensmodelle für den Softwareentwicklungsprozess. Frick hat diesen Prozess mit fünf Ebenen abstrakt dargestellt: 1. Analyse 2. Definition 3. Entwurf 4. Implementierung 5. Systemtest, Abnahme, Wartung . 38 Balzert wiederum teilt die letzte Ebene in zwei Ebenen auf, so dass hier eine eigene Phase für die Abnahme sowie für die Wartung existiert. 39 In dieser Arbeit wird aber der fünfstufige Prozess nach Frick betrachtet. Dieser und dessen Ebenen werden im Folgenden beschrieben. Analyse Die Analyse ist die erste Ebene und der Beginn eines jeden Softwareentwicklungsprozesses. In dieser Phase wird die Durchführbarkeit einer Softwareproduktentwicklung geprüft. Dies sollte zunächst mit möglichst wenig Aufwand geschehen, zum Beispiel in Form einer Vorstudie. 40 Fällt die Entscheidung auf der Basis der Vorstudie positiv für die Entwicklung aus, so ist eine vollständige Analyse für die Entwicklung durchzuführen. Hierzu ist zunächst ein Anforderungskatalog zu erstellen, der die Eckpunkte und Aufgaben enthält, die die Software in ihrer neuen Umgebung abzudecken hat. Zusätzlich muss auf der Analyseebene der Entwicklungsaufwand festgestellt werden. Dazu existieren verschiedenste Kalkulationsmethoden 41 , auf die in dieser Arbeit aber nicht weiter eingegangen wird, da sie den Rahmen der Arbeit sprengen würden. Mit diesen Fakten muss festgestellt werden, „ob die Anforderungen 38 Vgl. [Frick 1995], S. 34ff. 39 Vgl. [Balzert 2000]. 40 Vgl. [Frick 1995], S. 35. 41 Für weitere Informationen vgl. [Bundschuh / Fabry 2004]. 2 Thematische Einführung 18 umgesetzt werden können – sowohl von fachlicher (ist diese oder jene Forderung überhaupt durchführbar?), ökonomischer, (kann man es bezahlen?) und in personeller Hinsicht.“ 42 Definition Auf der Definitionsebene wird das Ergebnis der Anforderungsanalyse in eine „eindeutige, konsistente und vollständige Anforderungsdokumentensammlung“ 43 umgesetzt. Dabei entsteht die Produktdefinition, die bereits Sachverhalte, wie Daten und Kontrollflüsse, beinhaltet, die für die softwaretechnische Betrachtung relevant sind. Diese Form der Dokumentensammlung wird im Allgemeinen als Pflichtenheft bezeichnet. 44 Entwurf In der Entwurfsphase werden die Ergebnisse der beiden vorhergegangenen Phasen als Ausgangspunkt betrachtet. 45 Auf dieser Ebene befasst man sich nicht mehr mit dem „was ist zu tun“, sondern „wie ist es zu tun“. 46 Die Auswahl von Technologie und Architektur sind Grundsatzentscheidungen für den weiteren Verlauf des Softwareentwicklungsprozesses, die in dieser Phase getroffen werden. In dieser Phase sollten die Konstruktionsprinzipien der Implementierungsphase berücksichtigt werden, da diese auch im Entwurf modellierbar sein müssen. Implementierung Mit dem Entwurf aus der vorangegangenen Ebene wird in der Implementierungsphase ein lauffähiges Softwareprodukt erstellt und getestet. Dazu hat man zwei Implementierungsstrategien zur Auswahl. Entweder man verfährt nach der Top-Down Vorgehensweise oder nach der Bottom-Up Strategie. 47 Top-Down bedeutet, wie der Name schon sagt, dass das Software- 42 Siehe [Frick 1995], S. 35 und vgl. [Balzert 2000], S. 60ff. 43 Siehe [Frick 1995], S. 37. 44 Für weitere Informationen zum Pflichtenheft vgl. [Balzert 2000], S.111ff. 45 Vgl. [Balzert 2000], S. 686. 46 Vgl. [Frick 1995], S. 39. 47 Vgl. [Frick 1995], S.40. 2 Thematische Einführung 19 produkt immer von der obersten Ebene aus betrachtet und getestet wird. Der Vorteil bei dieser Vorgehensweise ist, dass Fehler, die beim Entwurf gemacht worden sind, sehr schnell erkannt werden. Dafür ist es allerdings sehr schwierig Testfälle für die Softwarearchitektur zu definieren, da die unteren Ebenen am Anfang der Implementierungsphase fehlen und bei Testfällen simuliert werden müssen. Die Bottom-Up Strategie ist genau das Gegenteil der Top-Down Vorgehensweise. Hier werden erst die unteren Architekturebenen implementiert. Daher lassen sich hier sehr leicht Tests durchführen, allerdings werden Fehler im Entwurf erst recht spät erkannt. Systemtest, Abnahme, Wartung Wie bereits erwähnt, sieht Frick 48 die Tätigkeiten des Systemtests, der Abnahme und der Wartung in einer Ebene, während Balzert 49 diese nochmals in Abnahme- und Einführungsphase sowie Wartungs- und Pflegephase unterteilt. Die Arbeitsschritte sind allerdings bei beiden vergleichbar beschrieben. In der Abnahmephase wird das Softwareprodukt inklusive einer vollständigen Dokumentation an den Kunden übergeben. Das Programm wird einer Reihe von Tests, wie Belastungstest, Stresstest etc. 50 , unterzogen und es wird ein Abnahmeprotokoll erstellt. Nach erfolgreicher Abnahme wird das Produkt anschließend beim Kunden eingeführt und installiert. Die Entwicklung eines Prototyps ist, wie im Laufe der Arbeit noch aufgezeigt wird, dieser Phase zuzuordnen und dient hier als Unterstützung. Nach der Inbetriebnahme der neuen Software geht das Produkt in „die längste Phase des Software-LebensZyklusses“ 51 , die Wartungs- und Pflegephase. Die Tätigkeiten und Aktivitäten in dieser letzten Phase lassen sich in vier Kategorien unterteilen: 52 • Stabilisierung/Korrektur • Optimierung/Leistungsverbesserung • Anpassung/Änderung • Erweiterung 48 Vgl. [Frick 1995], S. 42ff. 49 Vgl. [Balzert 2000], S. 1086ff. 50 Für weitere Informationen zu den Tests vgl. [Bazert 2000], S. 1087. 51 Siehe [Frick 1995], S. 43. 52 Vgl. [Balzert 2000], S. 1090. 2 Thematische Einführung 20 In den Kategorien Stabilisierung/Korrektur und Optimierung/Leistungsverbesserung werden korrektive Tätigkeiten an dem Softwareprodukt vorgenommen, während es sich in den Kategorien Anpassung/Änderung und Erweiterung um progressive Tätigkeiten handelt. Bei der Stabilisierung/Korrektur werden Fehler behoben, die entweder bei der Entwicklung oder bei vorherigen Korrekturen entstanden sind. 53 Unter Optimierung und Leistungsverbesserung sind die Tätigkeiten zusammengefasst, die dazu dienen das entwickelte Produkt in seiner Geschwindigkeit zu optimieren. 54 Funktionale Änderungen oder Änderungen, die durch neue Systemsoftware erzwungen werden, fallen in die Kategorie der Anpassung. Änderungen bzw. funktionale Ergänzungen, die geplant waren, aber bei der Entwicklung nicht berücksichtigt werden konnten, sind in der letzten Kategorie angesiedelt. 55 2.3.3 Modelle der Softwareentwicklung In der Theorie der Softwareentwicklung wurden im Laufe der Jahre verschiedene Modelle entwickelt, mit deren Hilfe der Ablauf eines Softwareentwicklungsprojektes strukturiert und beschrieben werden kann. In diesem Kapitel werden das Wasserfallmodell, Prototyping und das Spiralmodell vorgestellt. Wasserfallmodell Das Wasserfallmodell (siehe Abbildung 5) stammt bereits aus dem Jahre 1970 und wurde von W. W. Royce veröffentlicht. Ludewig und Lichter definieren das Wasserfallmodell wie folgt: „Die Software-Entwicklung wird als Folge von Aktivitäten betrachtet, die durch Teilergebnisse (Dokumente) gekoppelt sind. Diese Aktivitäten können auch gleichzeitig oder iterativ ausgeführt werden. Davon abgesehen ist die Reihenfolge der Aktivitäten fest definiert, nämlich (sinngemäß) Analysieren, Spezifizieren, Entwerfen, Codieren, Testen, Installieren, und Warten.“ 56 Die Aktivitäten sind in dem Schaubild als Rechtecke dargestellt, die Pfeile zeigen den 53 Vgl. [Balzert 2000], S. 1090. 54 Vgl. [Balzert 2000], S. 1091. 55 Vgl. [Balzert 2000], S. 1091. 56 Vgl. [Luewig / Lichter 2007], S. 147. 2 Thematische Einführung 21 Übergang zur Aktivität auf. In der Regel wird das Modell von oben nach unten durchlaufen, da aber kein Projekt perfekt verläuft, gibt es Rückpfeile zur vorherigen Aktivität, um dort gemachte Fehler zu korrigieren. Frick bezeichnet dies auch als „Top-Down gesteuertes JOJOVerfahren“. 57 Abbildung 5: Wasserfallmodell 58 Bei diesem Modell trat jedoch häufig das Problem auf, dass Zielsetzungen verfehlt wurden. Dies lag an der Beteiligung unterschiedlicher Projektmitglieder an den einzelnen Aktivitäten, die die Anforderungen der Anwender häufig unterschiedlich interpretierten. Zusätzlich konnte 57 Siehe. [Frick 1995], S. 46. 58 Siehe [Boehm 1988], Vgl. [Ludewig / Lichter 2007], S. 147 und vgl. [Frick 1995], S. 47. 2 Thematische Einführung 22 das Management diese Struktur nicht besonders gut überwachen, da es einen schlechten Einblick in die unteren Ebenen des Modells gestattet. Dies führte häufig zu Kostenexplosionen. 59 Prototyping Die Idee des Prototyping wurde Mitte der neunziger Jahre entwickelt, um Probleme bestehender Modelle zu beheben. 60 Ziel beim Prototyping ist, es möglichst früh eine lauffähige Version der zu entwickelnden Software zu erhalten, den so genannten Prototypen. 61 Ludewig und Lichter verstehen unter Prototyping eine „Vorgehensweise der Software-Entwicklung, bei der Attrappen, die wir Prototypen nennen, entworfen, konstruiert, bewertet, revidiert werden.“ 62 Die Probleme, die mit Prototyping gelöst werden, können sind sehr schnell deutlich zu machen. In der Regel existieren für neu zu entwickelnde Softwareanwendungen wenig bis keine ähnlichen Vergleichssysteme, weshalb die Aufgabe, sinnvolle Anforderungen an die Software zu formulieren, äußerst schwierig ist und häufig wichtige Anforderungen vergessen werden. Hieraus ergibt sich die Notwendigkeit, möglichst früh einen Prototypen zu erstellen, der zunächst einen Teil der Anforderungen realisiert. 63 Ein solcher Prototyp hat drei Eigenschaften: 64 • Ein Prototyp ist lauffähig • Ein Prototyp realisiert ausgewählte Aspekte des Zielsystems • Ein Prototyp wird vom Kunden geprüft und detailliert bewertet Alle Anforderungen, die der Kunde am Prototypen akzeptiert, werden zu Anforderungen für das zu entwickelnde System. Die Vorgehensweise bei der Prototypenentwicklung ist in Abbildung 6 dargestellt. Hat die Entwicklung des Prototyps einen bestimmten Reifegrad erreicht, so kann er als Pilot-Version die Grundlage für die weitere Entwicklung des neuen Softwareproduktes bilden. 65 59 Vgl. [Ludewig / Lichter 2007], S. 157. 60 Vgl. [Frick 1995], S. 46. 61 Vgl. [Ludewig / Lichter 2007], S. 153ff und [Frick], S.46. 62 Siehe [Ludewig /Lichter 2007], S. 155. 63 Vgl. [Ludewig /Lichter 2007], S. 156. 64 Vgl. [Ludewig /Lichter 2007], S. 156. 65 Vgl. [Suhl / Blumstengel 2002], S. 328. 2 Thematische Einführung 23 Abbildung 6: Prototyping 66 Spiralmodell Die Probleme der anderen Modelle sollten mit der Veröffentlichung des Spiralmodells nach Boehm gelöst werden. 67 Bei diesem Modell wird der Fortschritt des Softwareentwicklungsprozesses durch eine Spirale dargestellt (siehe Abbildung 7). Es finden sich auch hier die Ebenen wieder, die in Abschnitt 2.3.2 beschrieben wurden. Jeder Umlauf lässt sich mit einer Ebene vergleichen. 68 Bei jedem Umlauf durchquert die Spirale die folgenden vier Quadranten: 69 • Bestimmen der Ziele, Alternativen und Randbedingungen • Risiko-Analyse • Entwicklung und Validierung des Produktes • Planung der nächsten Phase 66 Vgl. [Ludewig / Lichter 2007], S. 169 und vgl. [Frick 1995], S. 49. 67 Vgl. [Boehm 1988]. 68 Vgl. [Frick 1995], S. 48f. 69 Vgl. [Suhl / Blumstengel 2002], S. 329, vgl. [Frick 1995], S. 49 und vgl. [Boehm 1988]. 2 Thematische Einführung 24 Bei der Entwicklung des Modells wurde auch das Prototyping berücksichtigt, das am zweiten Quadranten bei jedem Durchlauf zum Einsatz kommt. Am Anfang des dritten Quadranten wird der daraus entstandene Prototyp dann anhand von Simulationen und Benchmarktests geprüft. Die Kostenseite des Softwareprojektes wurde ebenfalls bei dem Entwurf von Boehm berücksichtigt. Die kumulativen Kosten werden auf der vertikalen Achse durch den Abstand zum Mittelpunkt im jeweiligen Zeitpunkt dargestellt. 70 Abbildung 7: Spiralmodell 71 70 Vgl. [Suhl / Blumstengel 2002], S. 329. 71 Vgl. [Frick 1995], S. 46 und siehe [Boehm 1988]. 2 Thematische Einführung 25 2.4 Deployment In diesem Kapitel wird der Begriff Deployment definiert, anschließend wird der DeploymentProzess erläutert. Deployment heißt übersetzt soviel wie ‚Bereitstellung’ oder ‚Verteilung’. Szyperskis allgemeine Definition von Deployment lautet: „Deployment ist the act of taking components and readying them for productive use.“ 72 Diese Definition trifft genau den Kern dieser Arbeit. Deployment bedeutet, dass fertige Komponenten oder auch Applikationen in eine informationstechnologische Umgebung eingefügt werden, so dass sie im produktiven Einsatz genutzt werden können. Ähnlich sehen es auch Emmerich und Wolf. Diese verstehen unter Deployment alle Arbeitsschritte, die nach der fertigen Entwicklung einer Software Komponente getan werden müssen, um diese einsatzfähig zu machen. Dies beinhaltet Aktivitäten, wie Anpassung, Konfiguration, Integration, Aktivierung, Deaktivierung sowie Außerbetriebnahme. 73 Diese Arbeitsschritte finden sich auch in dem zuvor beschriebenen Modell des Softwareentwicklungsprozesses wieder. Das Deployment ist auf der fünften und letzten Ebene (Systemtest, Abnahme, Wartung) angesiedelt. Nimmt man als Beispiel das WasserfallModell, so befinden wir uns da auf der vorletzten Stufe (siehe Abbildung 5). 74 Beim SpiralModell hingegen findet Deployment immer in der letzten Phase eines Zyklusses statt (siehe Abbildung 7). 75 2.4.1 Deployment Prozess Beim Deployment kann zwischen zwei grundsätzlichen Methoden unterschieden werden: dem Verteilen einer komplett neuen Software und dem Aktualisieren einer bereits bestehenden Software. Der Deployment Prozess selbst läuft allerdings in beiden Fällen gleich ab. 72 Siehe [Bishop 2002], Preface. 73 Vgl. [Emmerich / Wolf 2004] und vgl. [Deployment 2003], S. 3. 74 Vgl. [Lewis 1996], S. 207. 75 Vgl. [Lewis 1996], S. 207. 2 Thematische Einführung 26 Er besteht laut einer Veröffentlichung der Object Manage Group aus den folgenden fünf Phasen (siehe Abbildung 8): 76 • Installation • Konfiguration • Planung • Vorbereitung • Einführung Installation Konfiguration - Software dem - Standard Konfi- Verteiler zur guration der Verfügung stellen Software vor- Planung - Verteilung der Software planen Vorbereitung - Zielumgebung Einführung - Software in der der Software Zielumgebung vorbereiten implementieren nehmen und ablegen Abbildung 8: Deployment Prozess Voraussetzungen Um den Deployment-Prozess durchlaufen zu können, müssen die folgenden Voraussetzungen erfüllt sein: Die Software Komponente muss fertig kompiliert sein und demjenigen, der die Software-Komponente verteilen möchte, in adäquater Form vorliegen bzw. zur Verfügung gestellt werden. Möglichkeiten, dies zu gewährleisten, sind zum Beispiel ein Web- oder FTPServer, über den man sich die Software herunterladen kann, oder ein Datenträger, wie eine 76 Vgl. [Deployment 2003], S. 3ff. 2 Thematische Einführung 27 CD-ROM oder DVD, der die Softwarekomponente enthält. Die Person, die die SoftwareKomponente verteilen möchte, wird im Laufe der weiteren Arbeit als Verteiler bezeichnet. Eine weitere Voraussetzung ist, dass eine verteilte Umgebung existieren muss, im Folgenden Zielumgebung genannt, in der die Software später verteilt werden soll. So eine Umgebung könnte beispielsweise eine Client-Server-Architektur sein. Zusätzlich wird eine Sammelstelle, im folgenden Repository genannt, für die zu verteilende Software benötigt. Im Repository soll die Software abgelegt werden, bevor Entscheidungen zu treffen sind, wie die Software in der späteren Zielumgebung einzusetzen ist. 77 Installation 78 Der Begriff Installation darf in diesem Zusammenhang nicht falsch verstanden werden. Die Installationsphase ist nicht die Phase, in der die Software auf dem Computer veröffentlicht wird, auf dem diese später genutzt und ausgeführt werden soll. Vielmehr ist in diesem Zusammenhang der Vorgang gemeint, in dem die fertige Software-Komponente in einem Repository abgelegt wird, auf das der Verteiler Zugriff hat. Konfiguration 79 In dieser Phase liegt die Software noch im Repository. Es werden Standardeinstellungen an der Software vorgenommen und hinterlegt. Es besteht die Möglichkeit, mehrere Grundeinstellungspakete zu hinterlegen, so dass je nach Situation das passende Paket für die Verteilung und Bereitstellung der Software gewählt werden kann. Planung 80 In der Planungsphase des Deploymentprozesses wird entschieden wie und wo die Software in der Zielumgebung implementiert wird. Dabei spielen die Voraussetzungen der Software und die zur Verfügung stehenden Ressourcen eine wesentliche Rolle. 77 Vgl. [Deployment 2003], S. 3. 78 Für den ganzen Absatz vgl. [Deployment 2003], S. 3. 79 Für den ganzen Absatz vgl. [Deployment 2003], S. 4. 80 Für den ganzen Absatz vgl. [Deployment 2003], S. 4. 2 Thematische Einführung 28 Vorbereitung 81 Während sich bei der Planung zunächst entscheidet Wie und Wo man die Software in der Zielumgebung implementiert, versteht man unter der Vorbereitung alle Tätigkeiten an der Zielumgebung selbst um die letzte Phase, die Einführung, zu ermöglichen. Zu diesen Tätigkeiten gehört zum Beispiel das Kopieren der Dateien auf die einzelnen Computer, auf denen die Software später ausgeführt werden soll. Einführung 82 Mit der Einführung wird der Deploymentprozess abgeschlossen. Dabei wird die Software auf alle Computer in der Zielumgebung verteilt. Es werden alle Standardeinstellungen übernommen und weitere notwendige Anpassungen vorgenommen, um die Software auf allen Computern der Zielumgebung in einen ausführungsfähigen Zustand zu bringen. 81 Für den ganzen Absatz vgl. [Deployment 2003], S. 4. 82 Für den ganzen Absatz vgl. [Deployment 2003], S. 4. 3 Plattform IBM Lotus Notes/Domino 29 3 Plattform IBM Lotus Notes/Domino Als Referenz für diese Arbeit wird die Plattform IBM 83 Lotus Notes/Domino 84 verwendet. Diese Client/Server-Architektur ist ein klassischer Vertreter des Groupware-Konzeptes und gehört seit Jahren zu den Marktführern in diesem Bereich. Zunächst werden Charakteristika und spezifische Merkmale der Plattform herausgearbeitet. Lotus Notes/Domino ist von Raymond Ozzie entwickelt worden, um es Studenten und Professoren in der ganzen Welt zu ermöglichen, sich mit Hilfe eines computergestützten Kommunikationssystems in Verbindung zu setzen. 85 Es vereint die Verarbeitung und das Management wenig strukturierter Informationen in elektronischer Form in einem System. Dabei nutzt das System dokumentenbasierte nicht-relationale Datenbanken. Eine der wichtigsten Eigenschaften von Lotus Notes ist, dass alle Inhalte in so genannten ‚Notes’ gespeichert werden. Dies bezieht sich sowohl auf die Daten als solche, als auch auf das Design der jeweiligen Anwendungen. In Bezug auf eine Serverlösung bietet die Lotus Notes/Domino Plattform den Domino-Server an. Dieser besitzt die Möglichkeit, verschiedene Dienste bereitzustellen wie z. B. MailDienste, das Verwalten der Datenbanken und die Möglichkeit, den Domino-Server als WebServer fungieren zu lassen. Diese Dienste können entweder alle gemeinsam auf einem Server genutzt werden oder die Domino-Server können speziell für die jeweiligen Dienste konfiguriert werden. Daraus ergeben sich drei standardisierte Möglichkeiten den Domino-Server bei der Installation zu konfigurieren (siehe Tabelle 1). Die erste Möglichkeit bildet der DominoMessaging-Server, der die E-Mail Funktionalität bereitstellt. Zusätzlich unterstützt er kollaborative Anwendungen, wie Diskussionsdatenbanken und TeamRooms 86 , sowie persönliche Datenbanken und die Möglichkeit, partitionierte 87 Server einzusetzen. Als zweite Möglichkeit existiert der Domino-Utility-Server. Dieser ist als kollaborativer Server ausgelegt, so dass die E-Mail-Funktionalität hier nicht zur Verfügung steht. Die Workflow-Funktionalität sowie die 83 Weitere Informationen zu IBM sind unter [IBM 2007-1] zu finden 84 Für weitere Informationen siehe [Lotus 2007-1]. 85 Vgl. [Ebel 2006], S. 3. 86 TeamRooms sind virtuelle Arbeitsräume, die Anwender bei der kooperativen Arbeit unterstützen, vgl. [Lotus 2005-5]. 87 Für weitere Informationen siehe [Ebel 2006], S. 568ff. 3 Plattform IBM Lotus Notes/Domino 30 Möglichkeit der Partitionierung und des Clustering von Servern sind jedoch integriert. Als dritte Möglichkeit existiert ein Domino-Enterprise-Server, der die Funktionalitäten des Messaging Server und des Utility Servers vereint. Art Funktion Domino Messaging Server - E-Mail - kollaborative Anwendungen (Diskussionsdatenbanken, TeamRooms) Domino Utility Server Domino Enterprise Server - partitionierte Server - kollaborativer Server - Workflow - partitionierte Server, Clustering - E-Mail - Kollaborativer Server - selbst erstellte Anwendungen - partitionierte Server, Clustering Tabelle 2: Standardarten des Domino Servers und ihre Funktionalitäten 88 Auf der Client-Seite wiederum, existieren zwei Optionen, mit einem Domino-Server zu kommunizieren. Die erste Option erfolgt über den Webbrowser, wo ein so genannter ThinClient zum Einsatz kommt, die zweite über den nativen Lotus Notes Client, der auf jedem Client-PC installiert werden muss. Diese zweite Variante wird auch als Fat- beziehungsweise Rich-Client bezeichnet. Während die Möglichkeiten für den User mit dem Thin-Client beschränkt sind, bietet der Rich-Client alle Möglichkeiten, um die einzelnen Anwendungen zu bedienen. Für die Administration und die Entwicklung stehen zwei eigenständige Werkzeuge zur Verfügung. Der Lotus Domino Designer ist das Entwicklungswerkzeug, mit dem sich 88 Vgl. [Ebel 2006], S.29. 3 Plattform IBM Lotus Notes/Domino 31 nach dem WYSIWYG Prinzip Anwendungen entwickeln lassen. Die Administration kann mit Hilfe des Lotus Domino Administrator Clients durchgeführt werden. Auf Grund der Verwendung von Lotus Notes/Domino in dieser Arbeit werden an dieser Stelle allgemeine Konzepte von Lotus Notes/Domino erläutert. Des Weiteren werden verschiedene technische Hilfsmittel erklärt, die für das Werkzeug, das im Rahmen dieser Arbeit erstellt wird (vgl. Kapitel 5), von Bedeutung sind. 3.1 Allgemeine Konzepte Wie unter 2.1 schon erwähnt, sind Replikation, integrierte Teamkommunikation und Compound Documents sowie Sicherheits- und Zugangskonzepte typische Groupwarefunktionalitäten. Diese werden auch von der Groupware Plattform Lotus Notes/Domino unterstützt. Der Zusammenhang wird im Folgenden verdeutlicht. Zunächst wird auf die Eigenschaft eingegangen, dass Lotus Notes/Domino-Applikationen nicht, wie vorher schon angedeutet, auf relationalen Datenbanken basieren, sondern dokumentenbasiert sind. „Nach Schätzung von Experten liegen nur 10-20% der gesamten Informationen eines Unternehmens in strukturierter Form vor und lassen sich in relationalen Datenbanken ablegen“ 89 , der große Rest der Informationen ist unstrukturiert. Um diese besser handhaben zu können bietet sich Groupware an 90 . Die Datenbanken bilden das Grundkonzept von Lotus Notes. Alle Informationen werden dabei in Notes bzw. in Dokumenten gespeichert. Im Sinne von Groupware nennt man diese Dokumente Compound Documents. „Compound Documents enthalten als Container-Objekte strukturierte und unstrukturierte Informationen“ 91 . Laut Nastanstky et al. unterstützt Lotus Notes/Domino eine Architektur semi-strukturierter „Compound Documents“ 92 . Die Daten und Informationen werden in Feldern von Dokumenten gespeichert. Je nach Definition des Entwicklers können diese Felder Text-, Zahlen- oder berechnete Werte enthalten. Diese Werte können dem Benutzer in ver- 89 Siehe [Nastansky et al. 2002], S. 254. 90 Vgl. [Nastansky et al. 2002], S. 254. 91 Siehe [Nastansky et al. 2002], S. 252. 92 Vgl. [Nastansky et al. 2002], S. 253. 3 Plattform IBM Lotus Notes/Domino 32 schiedener Art und Weise zugänglich gemacht werden. Zum Anzeigen der Daten werden Forms verwendet, die als Schablone über die Dokumente gelegt werden. Eine Form enthält Platzhalter, die ebenfalls als Felder bezeichnet werden. Es werden dem Benutzer aspektorientiert immer nur die Informationen angezeigt, bei denen die Feldnamen der Form mit dem Feldnamen des Dokuments übereinstimmen. Der Benutzer kann die Dokumente über den Webbrowser, sofern die Anwendung für das Internet freigegeben wurde, oder über den Lotus Notes Client betrachten und bearbeiten. Wird der Lotus Notes Client verwendet, bietet sich dem Benutzer die Möglichkeit, Datenbanken als lokale Replik zu speichern. Die Anwendungen des Domino-Servers können so ohne Verbindung zu einem Domino Server genutzt werden. Beim Prozess der Replikation wird ein Abbild der Datenbank auf der lokalen Festplatte des Klienten abgelegt. Diese bekommt dann eine eindeutige Identifikationsnummer, die Replikations-ID. Damit zwei Datenbanken miteinander synchronisiert werden können, müssen die Replikations-IDs der beiden Datenbanken übereinstimmen. Um ein höchstmögliches Maß an Datenintegrität zu unterstützen, existieren Replikationsmechanismen 93 , die für den Abgleich der Datenbanken sowohl unter den Servern als auch zwischen Client und Server verantwortlich sind. Dies entspricht auch dem, was Nastansky schreibt: „Leistungsfähige GroupwareSysteme verfügen über eine Architektur, die Client-Server-Konfigurationen und verteilte Datenbanken unterstützt.“ 94 Die Replikation ist ein Mechanismus, bei dem Daten zwischen einem oder mehreren Speichermedien abgeglichen werden. Dieser Mechanismus wird auch bei verteilten Datenbanken angewendet und garantiert so identische Daten in allen zugehörigen Datenbankrepliken. Damit eine Datenkonsistenz gewährleistet ist, werden die Datenbanken regelmäßig abgeglichen. Es werden immer nur neue und geänderte Daten übertragen, wenn ein Rich-Client oder Domino-Server mit einem Domino-Server repliziert. Dabei ist der Replikationsmechanismus im Laufe der Zeit immer weiter verfeinert worden, so dass der Abgleich heute bis auf Feldebene hinunter geht. 95 Darüber hinaus bietet das Replikationskonzept unter Lotus Notes/Domino die Möglichkeit der selektiven Replikation. Eine Auswahl der zu replizierenden Daten kann getroffen werden, so dass nicht alle Daten abgeglichen werden müssen. Dies hat 93 Vgl. [Nastansky et al. 2002], S. 250. 94 Siehe [Nastansky et al. 2002], S. 250. 95 Vgl. [Ebel 2006], S.53. 3 Plattform IBM Lotus Notes/Domino 33 Vorteile bei der Nutzung von großen Applikationen, da nicht jedes Mal das gesamte Datenvolumen übertragen werden muss. Im Folgenden wird auf Sicherheitsaspekte von Lotus Notes/Domino eingegangen. Nastansky et al. äußern sich zur Sicherheit von Groupware-Systemen wie folgt: „Da in Büroinformations- und Kommunikationssystemen wichtige interne Daten übertragen und gespeichert werden, bedürfen Groupware-Systeme differenzierter Zugriffs- und Sicherheitsmechanismen, die allen an einem spezifischen Arbeitsprozess beteiligten Teammitgliedern den abgestuften Zugriff auf die für sie relevanten Teilmengen der Informationen im Rahmen einer skalierbaren Zugriffskontrolle ermöglichen.“ 96 Lotus Notes/Domino als Groupware-Plattform bietet in diesem Zusammenhang ein detailliertes Sicherheits- und Rollenkonzept. Grundsätzlich ist dieses aufgeteilt in physikalische Sicherheit, Netzwerksicherheit und Notes-Sicherheit 97 (vgl. Abbildung 9). Abbildung 9: Drei Typen der Sicherheit 98 Die physikalische und die Netzwerk-Sicherheit beziehen sich hier auf die Hardware und Umgebungskomponenten, die für diese Arbeit nicht relevant sind und daher an dieser Stelle nicht näher behandelt werden. Die Lotus Notes Sicherheit befasst sich mit Mechanismen, um Daten vor unbefugten Zugriffen von außen zu schützen, sowie insbesondere damit, Zugriffsrechte auf Daten so zu skalieren, dass verschiedene Anwendergruppen unterschiedliche Sich96 Siehe [Nastansky et al. 2002], S. 255. 97 Vgl. [Twomarek et al. 2004], S. 416. 98 Vgl. [Twomarek et al. 2004], S. 416. 3 Plattform IBM Lotus Notes/Domino 34 ten auf Daten bekommen können. Die Datenzugriffsrechte werden im Folgenden genauer betrachtet, da diese zum Einen, wie oben schon angedeutet, ein Groupwaremerkmal bilden und zum Anderen eine relevante Eigenschaft für das im weiteren Verlauf folgende Konzept darstellen. Lotus Notes/Domino erlaubt Entwicklern und Administratoren mit Hilfe von hierarchischen Strukturen, auf mehreren Ebenen Zugriffsrechte zu definieren. Dabei reicht das Spektrum der Rechtevergabe vom allgemeinen Zugriff auf den Server über den Zugriff auf Datenbanken bis hin zur Rechtevergabe für verschiedene Designelemente, Dokumente und sogar einzelne Felder in Dokumenten. Der Zugriff auf den Server basiert dabei auf leistungsfähigen LoginKonzepten, Namensverzeichnissen sowie Verschlüsselungskonzepten. 99 Der Benutzer authentifiziert sich beim Server mit seiner Benutzer-ID und dem darin enthaltenen Zertifikat. Beim Zugriff auf die Datenbanken kommt die Access Control List (kurz ACL) zum Einsatz. Über die ACL wird bestimmt, welche Personen, Personengruppen, Server, Server-Gruppen auf die jeweilige Datenbank zugreifen und welche Aktionen dort ausgeführt werden dürfen. 100 Zusätzlich können in der ACL Rollen definiert werden, mit deren Hilfe der Zugang zu Informations- und Designelementen konfiguriert werden kann. 101 3.2 Unterschiede zwischen Templates und Datenbanken Lotus Notes/Domino unterscheidet zwischen zwei Arten von Datenbanken: Lotus Notes Datenbanken und Domino Schablonen Datenbanken oder kurz Templates. Die Lotus Notes Datenbanken haben die Dateiendung „.nsf“ (Notes Storage Facility). Durch die Endung wird auf die Aufgabe der Datenbanken verwiesen: die Möglichkeit Notizen aufzunehmen. 102 Diese Notizen enthalten die Informationen und Applikationen, die dann in Lotus Notes/Domino verwendet werden können. Templates besitzen im Unterschied dazu die Endung „.ntf“. Strukturell gesehen sind die beiden Datenbanktypen identisch, inhaltlich betrachtet, enthalten Templates allerdings ausschließlich Design Elemente und Konfigurationsdokumente. Die 99 Vgl. [Nastansky et al. 2002], S. 255. 100 Vgl. [Kolm / Böck / Humpert 2002], S. 430. 101 Vgl. [Elliot 2007], S. 565. 102 Vgl. [Ebel 2006], S. 49-51. 3 Plattform IBM Lotus Notes/Domino 35 Anwendungsdatenbanken enthalten neben diesen zusätzlich die Dokumente, die von den Benutzern mit Informationen versehen worden sind, und bilden somit die Anwendung selbst. Die Kardinalität zwischen Templates und Datenbanken ist 1:n. Das bedeutet ein Template kann als Vorlage für n Datenbanken gelten. (siehe Abbildung 10) Master Database „Template 1.0" Discussion Forum A Discussion Forum B Discussion Forum C Discussion Forum D Inherit from: „Template 1.0" Inherit from: „Template 1.0" Inherit from: „Template 1.0" Inherit from: „Template 1.0" Abbildung 10: Ein Template kann Vorlage für mehrere Datenbanken sein 103 3.3 Designelemente unter Lotus Notes/Domino Die Designelemente unter Lotus Notes / Domino spielen in dieser Arbeit eine primäre Rolle. Daher werden diese im Folgenden genauer betrachtet. Designelemente sind unter Lotus Notes/Domino dafür verantwortlich, dass aus einem reinen Speichercontainer, der Datenbank, eine vollwertige Applikation wird. Sie existieren in jeder Lotus Notes Datenbank und liegen dort, wie vorher angedeutet, in Form von speziellen Dokumenten vor. Diese Dokumente sind in der Regel für den „normalen“ Benutzer nicht zugänglich, außer er hat die benötigten Zugriffsrechte und einen Domino Designer Client. Denn nur mit dem Domino Designer können Designelemente erstellt, bearbeitet oder gelöscht werden. Für den „normalen“ Benutzer liefern sie nur das Benutzer-Interface und die Logik der einzelnen Lotus Notes/Domino Anwen103 Vgl. [Elliot 2007], S. 600. 3 Plattform IBM Lotus Notes/Domino 36 dungen. In der Tabelle zwei sind die für diese Arbeit relevanten Designelemente, aufgeführt und kurz beschrieben. Design Element Beschreibung Frameset: In einem Frameset können mehrere voneinander unabhängige Seiten angezeigt werden. Jede Seite wird dabei in einem eigenen Frame dargestellt. Mit einer Page können Informationen angezeigt werden. Im Gegensatz zu einer Form, mit der Informationen gesammelt werden, werden mit einer Page Informationen dargestellt. Eine Form ist ein Gerüst, um Benutzer aufzufordern Informationen einzugeben. Dies kann entweder geschehen, indem sie die Informationen eintippen oder durch einfaches Benutzen verschiedenster Knöpfe. In einer View werden alle Dokumente, die in einer Domino Datenbank gespeichert sind, aufgelistet. Sie kann als ein „Inhaltsverzeichnis“ einer Datenbank angesehen werden. Die Informationen einer Zeile repräsentieren Informationen aus einem einzigen Dokument. Die Spalten beinhalten Informationen oder Kombinationen von Informationen aus Feldern des Dokumentes. Mit Foldern können sinngemäß zusammenhängende Dokumente verwaltet und gespeichert werden. Außerdem können die Dokumente per Drag and Drop in Foldern abgelegt werden. Das Aussehen von Foldern ist das gleiche wie bei Views. Der Hauptunterschied zwischen Foldern und Views ist, dass Views eine Selektions-Formel dafür benötigen, welche Dokumente dargestellt werden sollen, während Folder die in ihnen gespeicherten Dokumente automatisch anzeigen. Mit Agents kann man verschiedenste Aufgaben in Domino automatisieren. Sie sind eigenständige Programme, die spezielle Aufgaben für den Benutzer erledigen (zum Beispiel Senden von E-Mails, oder Ausfüllen und Speichern von Dokumenten). Agenten sind die flexibelste Lösung, Programme in Lotus Notes /Domino zu automatisieren, da sie von den Benutzern verwendet werden, aber auch im Hintergrund per Ereignis gestartet werden können. Eine Outline ermöglicht dem Benutzer, durch die Anwendung zu navigieren. Eine Subform bietet dem Entwickler die Möglichkeit, Teilbereiche einer Form auszugliedern und in einer Subform zu speichern. Diese können dann in anderen Forms wieder verwendet werden. Ein Shared Field gibt dem Entwickler die Option, Felder einmalig abzulegen und in mehreren Forms und Subforms wieder zu verwenden. Über eine Shared Action kann der Entwickler Actions zentral speichern und wieder verwenden. Actions geben dem Benutzer Page: Form: View: Folder: Agent: Outline: Subform: Shared Fields: Shared Actions: 3 Plattform IBM Lotus Notes/Domino Script Libraries: Images: Applets: Help Using Document: Help About Document: Data Connection: 37 die Möglichkeit, in Forms und Views mit der Anwendung zu interagieren. Script Libraries sind Program Code Bibliotheken, die für die Lotus Script Programmierung hinterlegt werden können. Es können eigene Klassen programmiert und gespeichert werden. Alle programmierbaren Design Elemente, die in Lotus Script programmiert sind, können auf die Script Libraries zugreifen. Images können direkt in der Datenbank gespeichert werden. Das ist ein hilfreiches Merkmal in Bezug auf das Kopieren und Replizieren von Datenbanken auf verschiedene Server. Es müssen keine Images einzeln von Server zu Server kopiert werden, so dass die Anwendung anschließend einwandfrei läuft. Java Applets können ebenso wie Images in der Datenbank gespeichert werden, so dass sie zentral verwaltet werden. Werden Veränderungen am Applet vorgenommen so muss dies nur zentral an einer Stelle geschehen und die Änderungen werden von allen Design Elementen verwendet, die dieses Applet benutzen. Das Help Using Document ist ein spezielles Dokument in der Datenbank, das Informationen darüber enthält, wie die Datenbank zu nutzen ist. Es gibt einen kleinen Überblick über die Datenbank und kann zusätzlich spezielle Informationen über Forms und Views der Datenbank enthalten. Das Help About Document ist ebenso wie das Help Using Document ein spezielles Dokument, das den Zweck der Datenbank beschreibt. Es kann beim Öffnen der Datenbank automatisch angezeigt werden. Die Data Connection Ressource (DCR) gibt dem Entwickler die Möglichkeit, mit Hilfe der Technologie des Domino Enterprise Connector Services (DECS) Informationen aus externen Datenquellen, wie relationalen Datenbanken, zu verwenden und anzuzeigen. Die Data Connection ist auch eine gemeinsame Komponente - sie muss nur einmal eingerichtet werden, so und kann dann wiederverwendet werden Tabelle 3: Designelemente von Lotus Notes/Domino 104 Die Abbildung 11 gibt einen Überblick über die Beziehungen zwischen den Daten einer Notes Datenbank und den allgemeinen Designelementen. Navigators können auf Daten zugreifen und diese darstellen. Views greifen ebenfalls auf den Datenbestand zu, zeigen diesen jedoch in Form von Documents an. Documents wiederum stellen Daten anhand von Fields dar. Agents 104 Vgl. [Tulisalo et al. 2002], S. 32-36 und [Lotus 2005-2] 3 Plattform IBM Lotus Notes/Domino 38 greifen auf Daten zu und können diese dann, je nach Wunsch des Programmierers, erstellen, ändern oder gar löschen. Abbildung 11: Beziehungen zwischen allgemeinen Design Elementen und Daten 105 3.4 Standard Deploy Mechanismus von Lotus Notes/Domino Da sich diese Arbeit mit der Entwicklung eines Prototypen zur Unterstützung der Deploymentprozesse unter Lotus Notes/Domino befasst, soll an dieser Stelle ein kurzer Überblick über die Standardmechanismen des Deployments unter Lotus Notes/Domino gegeben werden. Wir betrachten hier die zwei Standardfälle, Software auszuliefern. Der erste Fall ist ein Software Update für eine bestehende Software, der zweite Fall besteht darin, neu angeschaffte oder entwickelte Software auszuliefern. Es wird hier nur die Server-Seite betrachtet, denn die Benutzer erhalten die Aktualisierungen, die auf dem Domino Server getätigt wurden, automatisch bei der nächsten Replizierung. 105 Vgl. [Elliot 2007], S. 35. 3 Plattform IBM Lotus Notes/Domino 39 Betrachten wir den ersten Fall, das Software-Update, sind dort zwei Verfahren möglich: Zum Einen ein manuelles Verfahren, bei dem der Administrator oder Entwickler die Aktualisierung der Anwendung selbst auslöst, und zum Anderen ein auf dem Server automatisch angestoßener Aktualisierungsprozess. Der Administrator benutzt einen in Lotus Notes integrierten Mechanismus, der das Datenbank Design aktualisiert. Bei diesem Mechanismus wird das Design der Datenbank mit dem Design des Templates abgeglichen und alle Änderungen, die im Template vorgenommen wurden, werden übernommen. Dies funktioniert nur dann, wenn in den Datenbankeigenschaften das Design-Template eingetragen wurde. Den gleichen Mechanismus nutzt der Administrator beim manuellen Aktualisieren. Sollte das Design-Template nicht in den Datenbankeigenschaften eingetragen sein, so kann der Administrator einen weiteren Mechanismus wählen, mit dem das Design ersetzt wird. Bei dieser Vorgehensweise werden nicht die vorhandenen Design-Elemente aktualisiert, sondern es wird das komplette Design ersetzt. 106 Zum zweiten Fall, der Auslieferung der neuen Software, gibt es keinerlei Automatisierung, der Administrator bzw. Entwickler muss den Prozess der Installation manuell anstoßen. Dies bedeutet, dass der Administrator eine neue Datenbank anlegen und diese anschließend vollständig konfigurieren muss. 3.5 Extensible Markup Language unter Lotus Domino Lotus Domino bietet seit der Version 6 eine Unterstützung für XML. 107 Im Lotus Domino Umfeld wird im Allgemeinen von DXL (Domino XML) gesprochen. Die Daten werden strukturiert in Dokumenten gespeichert, XML ist eine Sprache, um Daten strukturiert abzulegen108 . Diese Eigenschaft macht es Lotus Domino möglich, seine Daten ebenfalls in einer XML konformen Struktur auszugeben. Ein weiteres gemeinsames Merkmal, das Lotus Domino mit XML gemeinsam hat, ist, dass die Daten getrennt vom Design abgelegt werden. Unter Lotus Domino werden die Daten in Dokumenten abgelegt und mit Hilfe von Forms dem User angezeigt. Bei XML ist es ähnlich, hier liegen die Daten im eigentlichen XML-Dokument und 106 Vgl. [Ebel 2006], S. 1081ff. 107 Vgl. [Lotus 2005-1], S.329ff. 108 Vgl. [Lotus 2005-3], S. 1 und [Morrison et al. 2000], S. 43. 3 Plattform IBM Lotus Notes/Domino 40 werden anschließend mit Hilfe eines XSL-Stylesheets angezeigt bzw. aufgewertet (vgl. Abbildung 12). Abbildung 12: Vergleich XML und Domino Architektur 109 Für Lotus Domino existiert eine detaillierte DTD, die die Struktur von DXL beschreibt 110 . Die Daten von DXL sind also Lotus Domino Daten in XML-Form und der Struktur der Domino DTD. Um Daten von Lotus Notes/Domino nach XML zu exportieren oder umgekehrt von XML nach Lotus Notes/Domino zu importieren, bietet Lotus Notes zwei Ansätze: Lotus Script, eine in Lotus Notes/Domino integrierte Scriptsprache, oder Java. Lotus Script weist insofern eine Einschränkung auf, als die Sprache nur innerhalb der Applikation lauffähig ist, während mit Java auch von außen über eine COM Schnittstelle von Lotus Notes/Domino auf die Daten zugegriffen werden kann. Zum Bearbeiten der XML-Strukturen besteht die Option, die in Lotus Notes/Domino integrierten DOM- und SAX Parser zu nutzen. Die Abbildung 13 zeigt 109 Vgl. [Morrison et al. 2000], S. 44. 110 Vgl. [Lotus 2005-4]. 3 Plattform IBM Lotus Notes/Domino 41 anhand eines Beispiels, wie Domino Daten durch DXL geändert werden können. Zuerst werden die Daten exportiert, dann bearbeitet und anschließend wieder importiert. Abbildung 13: Ändern von Domino Objekten per DXL 111 111 Vgl. [Morrison et al. 2000], S. 57. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 42 4 Konzeption eines Systems zur Unterstützung der DeploymentProzesse In diesem Kapitel wird das Konzept beschrieben, auf dem der zu entwickelnde Prototyp basiert. Zuerst wird das bestehende Problem untersucht. Dazu werden die Eigenschaften von Deployment im Allgemeinen und die bestehenden Möglichkeiten von Lotus Notes/Domino analysiert. Basierend auf den Ergebnissen werden die Anforderungen für ein System definiert, das die Deployment-Prozesse unter Lotus Notes/Domino unterstützt. Bei diesem Punkt wird darauf eingegangen, wie die allgemeinen Eigenschaften von Deployment unter Lotus Notes umgesetzt werden können. Zum Ende des Kapitels wird der Entwurf der Software erarbeitet, so dass in Kapitel 5 die Implementierung der Software beschrieben werden kann. 4.1 Problemanalyse Die Groupware Plattform Lotus Notes/Domino bietet standardmäßig nur einfachste Mittel an, um neue Anwendungen in größere Umgebungen zu verteilen. Dazu kommt, dass es gerade in verteilten Arbeitsumgebungen, die im Zusammenhang mit Groupware häufiger zu finden sind, sinnvoll ist einen Überblick über die vorhandenen Anwendungen zu haben. Dies bezieht sich vor allem darauf, in welchen Umgebungen die Anwendungen der verschiedenen Templates zu finden sind und wie viele produktive Instanzen, basierend auf einzelnen Templates, existieren. So ist es erheblich leichter diese zu verwalten und im Bedarfsfall die Zusammenhänge zu erkennen. 4.1.1 Analyse der allgemeinen Deployment-Prozesse Zunächst werden nochmals die Vorraussetzungen aufgegriffen, die in Kapitel 2.4 für den allgemeinen Deployment-Prozess gelten: • Fertig programmierte und kompilierte Software • Verteiler muss die Software erhalten 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse • Die Zielumgebung muss eine verteilte Umgebung sein • Es muss ein Repository existieren, in dem die Software abgelegt werden kann 43 Jetzt stellt sich die Frage, inwiefern die Standard-Möglichkeiten für Deployment von Lotus Notes/Domino diese Vorraussetzungen bereits erfüllen. Die erste Voraussetzung, dass die auszuliefernde Software ein fertiges Produkt ist, bedarf keiner größeren Analyse, denn ohne ein fertiges Software-Produkt ist kein Deployment erforderlich. Da unter Lotus Notes/Domino die Templates mit ihren integrierten Programmcodes nicht extra kompiliert werden müssen, ist auch diese Voraussetzung erfüllt. Der zweite Punkt ist auch mehr ein organisatorisches als ein technisches Problem. Daher ist dieser Punkt auch im Umfeld eines Software-Projektes zu klären und für dieses Konzept irrelevant. Punkt drei ist ebenfalls durch Systemeigenschaften von Lotus Notes/Domino geklärt. Da Lotus Notes/Domino auf einer Client-/Server-Architektur basiert, ist auch diese Voraussetzung erfüllt. Der vierte und letzte Punkt ist allerdings etwas schwieriger zu erläutern. Ein spezielles Repository, um das Softwareprodukt abzulegen, existiert nicht. Man könnte das Datenverzeichnis des Domino-Servers eventuell als solches ansehen. In Bezug auf die Voraussetzung für das Repository würde dies bei aktivierter automatischer Designaktualisierung auf dem DominoServer nicht zutreffen, da der Sinn des Repositories verfehlt würde. Das Softwareprodukt soll im Repository abgelegt werden, damit Konfigurationen an diesem vorgenommen und Entscheidungen in Bezug auf die Verteilung und den Einsatz der Software getroffen werden können. Grundsätzliche Voraussetzungen in Bezug auf den Deployment-Prozess sind also gegeben. Der Punkt „Repository“ ist allerdings verbesserungswürdig. Nachdem die Voraussetzungen von Lotus Notes/Domino für den Deployment-Prozess analysiert wurden, wird nun näher betrachtet, wie der Deployment-Prozess unter Lotus Notes/Domino umzusetzen ist. Dazu wird zunächst der Standard-Mechanismus für Deployment unter Lotus Notes/Domino nochmals betrachtet, um zu sehen, welche Mängel oder vielleicht auch Vorteile diese Vorgehensweise hat. Anschließend werden die Unterschiede zwischen beiden Prozessen untersucht. Die Vorgehensweise, um neue Datenbanken unter Lotus Notes/Domino auszurollen, ist nicht sehr ausgeprägt, wie im Kapitel 3.4 beschrieben. Sobald die Entwicklung des neuen Softwareproduktes in Form von einem oder mehreren Templates abgeschlossen ist, wird die neue Applikation in der Lotus Notes/Domino Zielumgebung auf einem Domino-Server abgelegt. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 44 Auf dieser Basis werden manuell neue Datenbanken erstellt und diese dann ebenfalls durch einen manuell angestoßenen Vorgang, der Replikation, auf die Clients verteilt. Die Verteilung der Anwendungen auf die Clients ist aufgrund der einfachen Verteilung durch die Replikation nicht der Gegenstand dieser Arbeit. Vielmehr ist die Auslieferung der Software aus einem Repository an den oder die Domino-Server in der Zielumgebung zu untersuchen. Versucht man mit Hilfe der standardmäßigen Möglichkeiten von Lotus Notes/Domino diese Vorgehensweise in die Phasen des allgemeinen Deployment-Prozesses Installation, Konfiguration, Planung, Vorbereitung und Einführung einzuteilen, kommt man zu folgendem Ergebnis (siehe Tabelle 4): Installation Da im eigentlichen Sinn kein echtes Repository existiert, würde diese Phase wegfallen. Man könnte aber das Einspielen des Templates in das Datenverzeichnis eines extra als Repository fungierenden Domino-Servers als Aktion in dieser Phase ansiedeln können. Konfiguration In dieser Phase können Konfigurationen an dem Template vorgenommen werden, die später in die produktive Anwendung übernommen werden. Allerdings besteht hier keine Möglichkeit mehrere Konfigurationspakete für verschiedene Umgebungen zu hinterlegen, es sei denn es würde für jede Umgebung eine Kopie des Templates angelegt. Planung In der Planungsphase soll nach dem Standard Prozess entschieden werden, wie und wo die Software installiert wird. Das Wie kann durch den Replikationsmechanismus übernommen werden. Das Wo, also die Zielumgebung, steht zu diesem Zeitpunkt auch schon fest. Hier stellt sich dann vielmehr die Frage, wer darf später auf die Anwendung zugreifen. Auf diesem Hintergrund können Rechte vergeben werden. Die Frage der zur Verfügung stehenden Ressourcen spielt an dieser Stelle ebenfalls eine eher untergeordnete Rolle. Wichtiger ist hier die Frage, welche Server- und Client-Versionen von Lotus Notes/Domino in der Zielumgebung als Mindestvoraussetzung benötigt werden und welche aktuell dort installiert sind. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 45 Vorbereitung Die Vorbereitung, wie zum Beispiel das Kopieren der Dateien von den Domino-Servern in der Zielumgebung auf die einzelnen Client-PCs, ist unter Lotus Notes/Domino nicht erforderlich und wird durch den Replikationsmechanismus übernommen. Sofern man einen DominoServer als Repository verwendet, kann der Mechanismus auch verwendet werden, um die Software aus dem Repository an die Domino-Server in der Zielumgebung zu verteilen. In dieser Phase ist als Aktion vielmehr das Aktualisieren der Domino-Server- und ClientVersionen von Lotus Notes/Domino anzusiedeln, falls erforderlich. Einführung In dieser Phase wird die Anwendung auf den Domino-Servern und Client-PCs in der Zielumgebung in einen lauffähigen Zustand versetzt. Zusätzlich werden letzte Konfigurationen und Einstellungen vorgenommen. Aktivitäten in den einzel- Standard Deployment- Deployment unter Lotus nen Phasen Prozess Notes/Domino Installation • Software wird in dem Verteiler • in einem Repository zur Verfügung gestellt Templates werden dem Verteiler übergeben • Es existiert kein echtes Repository Konfiguration • Anwendung wird konfiguriert • Anwendung wird konfiguriert • Möglichkeit zum Speichern • Keine Möglichkeit zum von Konfigurationspaketen Ablegen von Konfigurationspaketen Planung • Verteilung der Software in der • Zielumgebung planen • Ressourcen der Zielumgebung Die Zielumgebung ist vorgegeben • überprüfen Zugriff und Verteilung durch Rechtevergabe einschränken • Server- und Client-Versionen von Lotus Notes/Domino überprüfen 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse Vorbereitung • Vorbereitungen für das Aus- • rollen des Softwareproduktes treffen, wie Kopieren der In- 46 Aktualisierung der Server und Clients, wenn notwendig • stallationsdateien in die Ziel- Keine explizite Verteilung notwendig umgebung Einführung • Software einrichten • Software einrichten • Endkonfiguration herstellen • Endkonfiguration herstellen • Lauffähigen Zustand herstellen • Lauffähigen Zustand herstellen Tabelle 4: Vergleich der Aktivitäten beim Deployment zwischen dem allgemeinen Deployment Prozess und dem Standard Lotus Notes/Domino Deployment Prozess Vergleicht man nun die beiden Prozesse miteinander, so sind einige Gemeinsamkeiten zu entdecken, allerdings auch einige Unterschiede. Die Unterschiede werden im Folgenden hervorgehoben und bilden die Grundlage für die Anforderungen an das System. Als erstes ist an dieser Stelle zu nennen, dass unter Lotus Notes/Domino kein Repository existiert, um das Softwareprodukt dem Verteiler bereitzustellen. Des Weiteren fehlt unter Lotus Notes/Domino die Möglichkeit Konfigurationspakete zu speichern, um das Ausrollen und Verteilen der Software in mehreren unterschiedlichen Zielumgebungen mit unterschiedlichen Konfigurationen zu ermöglichen. Die Aktivitäten und Aktionen im Bereich der Planung unterscheiden sich gänzlich, weil sich die Aussagen für den allgemeinen Deployment-Prozess auf die Client-PCs und deren Ressourcen-Ausstattung beziehen. Da beim Einsatz der Plattform Lotus Notes/Domino auf jedem Client-PC der Lotus Notes Client installiert ist, sind in der Regel auch alle Anwendungen unter Lotus Notes auf diesen PCs lauffähig. Das gleiche gilt für die Serverseite. Voraussetzung ist, dass die Anwendung für die installierte Version des Lotus Notes/Domino freigegeben ist. Ist nicht der Fall, muss die Version der Lotus Notes/Domino Software aktualisiert werden. Die Verteilung des Softwareproduktes an die Clients ist nicht notwendig. Diese Funktionalität wird unter Lotus Notes/Domino vom Replikationsmechanismus abgedeckt. Allerdings muss, wie vorher schon angedeutet, die Software auf einen Server in der Zielumgebung gelangen. Diese Aktion ist an dieser Stelle vorzunehmen. In der letzten Phase existieren keine Unterschiede in den Aktionen, da in beiden Fällen der lauffähige Zustand in der Zielumgebung herzustellen ist. Nachdem die Unterschiede und Differenzen der Deployment-Prozesse herausgearbeitet wurden, werden an dieser Stelle spezielle Punkte der Plattform Lotus Notes/Domino in Bezug 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 47 auf Deployment untersucht, um weitere Schwachpunkte zu entdecken und diese später in die Liste der Anforderungen aufnehmen zu können. Dazu wird folgender Fall eines SoftwareUpdates betrachtet: Es existiert eine Anwendung unter Lotus Notes/Domino, die auf einer Standard-Software basiert. Dies bedeutet, dass alle Designelemente in allen Installationen identisch sind. Da allerdings in einigen Fällen das Standard-Produkt nicht immer ausreichend ist für den geplanten Einsatz, sind einige Designelemente in diesem Produkt verändert worden, und das Produkt ist mit diesen leichten Veränderungen in der produktiven Zielumgebung zum Einsatz gekommen. Das Problem, das auftritt, wenn ein Softwareupdate unter Lotus Notes/Domino für diese Software eingespielt werden soll, ist, dass bei einer Aktualisierung in der Regel alle Designelemente angepasst werden. Dies würde bedeuten, dass beim Einspielen eines vom Hersteller zur Verfügung gestellten Software-Updates, alle Änderungen überschrieben würden, die für den produktiven Einsatz vorgenommen wurden. Es gibt zwar die Möglichkeit, wie in Kapitel 3.4 beschrieben, diese Aktualisierung der Elemente auszuschließen, das ist jedoch umständlich, da dies in jeder Installation der Software berücksichtigt und manuell vorgenommen werden muss. Es wäre in diesem Zusammenhang hilfreich, wenn die Einstellungen für die Designelemente bei einem Software-Update automatisch berücksichtigt würden, besonders bei der Verwendung von mehreren Instanzen einer Software in verschiedenen Zielumgebungen. Eine weitere Anforderung, die ein solches System mitbringen sollte, ist eine integrierte Datenbank- und Template-Verwaltung. Mit ihrer Hilfe sollte es dem Benutzer des Systems erleichtert werden den Überblick über die vorhandenen Templates und die damit erzeugten Anwendungen in den unterschiedlichen Umgebungen zu behalten. 4.2 Anforderungen an das neue System Nachdem die Unterschiede zwischen dem Allgemeinen Deployment-Prozess und dem Standard-Deployment-Prozess unter Lotus Notes/Domino herausgearbeitet wurden, werden in diesem Kapitel die Anforderungen an das neue System bzw. den Prototypen definiert. Diese werden zunächst grob abgewogen und im Unterkapitel „Kernfunktionalitäten“ genauer beschrieben. Die erlangten Erkenntnisse bilden die Grundlage für die Anforderungen. Auf ihrer Basis wird abgewogen, ob es sinnvoll ist, diese im zu erstellenden Prototypen zu berücksichtigen, bzw. die Unterschiede auszugleichen. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 48 Angefangen bei den Unterschieden soll der Schwerpunkt zunächst auf der Installation und dem fehlenden Repository liegen. Es ist sicherlich sinnvoll diese Funktionalität im neu zu schaffenden Prototypen zu berücksichtigen in Bezug auf die besseren Möglichkeiten einer vorherigen Konfiguration und der Widerverwendbarkeit, speziell wenn Anwendungen in mehreren Zielumgebungen zum Einsatz kommen sollen. Des Weiteren können in einem Repository mehrere Versionen einer Software abgelegt werden, so dass jederzeit ein Überblick über ältere Versionen vorhanden ist. Die Möglichkeit, Konfigurationspakete abzulegen, fehlt unter Lotus Domino ebenfalls. Dies sollte im Prototypen berücksichtigt werden. Das Beispiel mit mehreren produktiven Zielumgebungen ist auch hier zutreffend. Soll eine Anwendung in mehreren Zielumgebungen zum Einsatz kommen, macht es Sinn für jede Umgebung Konfigurationen in Bezug auf umgebungsspezifische Eigenschaften abzulegen, wie zum Beispiel Serververbindung und Benutzerrechte. Als Ablage kann für die Konfigurationspakete das Repository dienen. Der nächste gravierende Unterschied ist, dass unter Lotus/Domino in der Planungsphase definiert werden muss, welche Clients bzw. Benutzer die Anwendung später nutzen sollen. Dazu müssen Benutzerrechte definiert werden. Sollte eine Softwareinstallation anstehen, ist es sehr hilfreich wenn in diesem Zusammenhang auf vordefinierte Pakete mit Benutzerrechten zurückgegriffen werden kann. Diese könnten ebenfalls im Repository gespeichert werden und auch als Basis für unterschiedliche Anwendungen dienen. Die Überprüfung sowie Aktualisierung, wenn notwendig, der Domino-Server- und ClientVersionen von Lotus Notes in der Zielumgebung sind eher ein organisatorisches als ein technisches Problem und können in diesem Zusammenhang nicht berücksichtigt werden. Daher sind für die Vorbereitungsphase keine zusätzlichen Anforderungen notwendig. Das Gleiche gilt auch für die Einführungsphase. Da hier der lauffähige Zustand der Anwendung hergestellt werden muss, sind die vorzunehmenden Einstellungen in der Regel sehr speziell und können nicht mit Standardkonfigurationen abgedeckt und damit auch schwer automatisiert werden. Nach der Abwägung der Unterschiede aus den Phasen zwischen dem allgemeinen Deployment und den Standard Möglichkeiten unter Lotus Notes/Domino werden im Folgenden die speziellen Anforderungen von Lotus Notes/Domino betrachtet. Die Problematik, die im vorangegangenen Kapitel beschrieben ist, zeigte Nachholbedarf im Bereich der Designaktualisierung auf, speziell im Zusammenhang mit einzelnen Designelementen. Dieses Problem sollte ebenfalls durch ein System gelöst werden, das Deployment unter Lotus Notes unterstützen soll. Eine weitere Schwierigkeit ist, dass spezielle Vorgänge nicht abgedeckt werden können. Dieses Problem haben in der Regel Anwendungen, die möglichst allgemein einsetzbar sein 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 49 sollen. Ein Beispiel ist, wenn zum Erstellen der Standardkonfiguration in den neuen Anwendungen zusätzlich Funktionen ausgeführt werden müssen, damit die Konfigurationen wirksam werden. Solche Spezialfälle kann ein Standardprodukt normalerweise nicht abdecken. Daher besteht Bedarf an einer Möglichkeit, diese Anwendung für spezielle Fälle anzupassen. Nachdem die Anforderungen formuliert wurden, werden im folgenden Kapitel die daraus resultierenden Funktionalitäten aufgezeigt und beschrieben. 4.2.1 Kernfunktionalitäten Die Kernfunktionalitäten eines Systems, das Deployment-Prozesse unter Lotus Notes/Domino unterstützt, sind auf der Basis der gerade getroffenen Anforderungen wie folgt zu beschreiben. Ein solches System muss ein Repository bereitstellen, in dem fertig entwickelte Anwendungen, in diesem Fall Templates, nach ihren Versionen abgelegt werden können. Außerdem muss eine Möglichkeit existieren, unterschiedliche Konfigurationspakete zu den einzelnen Versionen zu speichern. Diese Konfigurationspakete enthalten Standardkonfigurationen, die verschiedene Grundeinstellungen für das System enthalten und für verschiedene Einsatzzwecke vordefiniert sind. Ein weiterer Punkt ist die Unterstützung von Rechtepaketen. Diese sollen anwendungsübergreifend abgelegt und im Bedarfsfall den zu verteilenden Anwendungen zugeordnet werden können. Außerdem sollte ein Mechanismus existieren, der neue Anwendungen auf der Basis der Templates aus dem Repository in die Zielumgebung kopieren kann sowie existierende Anwendungen mit neueren Versionen der Templates aktualisiert. Bei der Aktualisierung von Anwendungen sollte das Problem mit den Designelementen, wie vorher beschrieben, berücksichtigt werden. Dies bedeutet, dass bei einer Aktualisierung vorher ausgewählte Designelemente nicht angepasst werden. Zudem sollte das System eine Verwaltung der Vorlagen und Anwendungen sowie die dazugehörigen Rechte und Konfigurationen ermöglichen. In diesem Zusammenhang sind besonders die Versionierung der einzelnen Elemente sowie der Speicherort der Datenbanken zu nennen, damit jederzeit auf die Originale zugegriffen werden kann. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 50 4.3 Entwurf für die Erstellung einer solchen Software Auf der Basis der Anforderungen mit ihren Funktionalitäten wird in diesem Kapitel ein Entwurf für den zu erstellenden Prototypen vorgestellt. Dies geschieht unter Berücksichtigung der technischen Möglichkeiten von Lotus Notes/Domino. Angefangen bei der Architektur für einen solchen Prototypen (siehe Abbildung 14 und Abbildung 15) bietet es sich an, diesen auf der Basis einer Datenbank abzubilden. Abbildung 14: Architektur des zu erstellenden Systems mit Repository in der Zielumgebung Diese Datenbank ist dann gleichbedeutend mit dem Repository für das Deployment und dient als Speicherort für Dokumente, die Referenzen auf Templates enthalten. Ebenso wird mit den Anwendungen verfahren. Auch diese werden als Referenz in der Datenbank abgelegt; als Referenz deshalb, weil es größenbedingt durch die einzelnen Dateigrößen der Templates und vor allem der späteren Anwendungen keinen Sinn machen würde, diese komplett in der Datenbank zu speichern. Außerdem ist es nicht sinnvoll die Anwendungen komplett zu spei- 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 51 chern, da sie sich in der produktiven Umgebung ständig verändern und nur mit viel Aufwand im Repository auf einem aktuellen Stand gehalten werden können. Die Referenzdokumente können die Verwaltung der einzelnen Vorlagen und Anwendungen sowie deren Versionierung ermöglichen. Die Konfigurations- und Rechtepakete werden ebenfalls in der Datenbank gespeichert und sind den Vorlagen und Anwendungen zuzuordnen. Der Speicherort des Repositories spielt eher eine untergeordnete Rolle. Dieser kann identisch mit der Zielumgebung (siehe Abbildung 14) sein oder sich in einer externen Lotus Notes/Domino-Drittumgebung befinden (siehe Abbildung 15). Wichtig ist nur, dass später genügend Zugriffsrechte für die Zielumgebung existieren, damit die neue Anwendung ordnungsgemäß bereitgestellt werden kann. Abbildung 15: Architektur des zu erstellenden Systems mit Repository in einer Drittumgebung Auf Grund der automatischen Design-Aktualisierung der Domino-Server ist es empfehlenswert die Template-Datenbanken in einer externen Drittumgebung zu speichern. Nachdem der Rahmen für eine Architektur aufgezeigt wurde, widmen sich die folgenden Ausführungen den einzelnen Mechanismen zum Erstellen und Aktualisieren von Anwendungen. Wenn eine neue Anwendung erstellt werden soll, läuft ein Prozess ab, der wie folgt beschrieben werden kann (siehe Abbildung 16). Am Anfang muss die Aktion zum Erstellen 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 52 der neuen Anwendung ausgelöst werden. Anschließend ist ein Template zu wählen, auf dessen Basis die Anwendung erstellt werden soll. Ist dies geschehen, stellt sich die Frage ob ein Konfigurationspaket gewählt wird oder nicht. Unabhängig von dieser Entscheidung muss im Anschluss entschieden werden, ob ein Rechtepaket verwendet werden soll. Sind beide Entscheidungen getroffen, wird die Anwendung in der neunen Zielumgebung bereitgestellt. Abhängig von den Entscheidungen über Konfigurations- und Rechtepakete werden jetzt die Konfigurationen und Rechte in die Anwendung übernommen. Zum Schluss wird das Dokument mit einem Link auf die Anwendung und Versionsnummer zur Verwaltung abgelegt. 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse Aktion neue Anwendung erstellen ausgelöst Template wählen Template gewählt 53 Konfigurationspaket auszuwählen XOR Keine Konfigurationspaket gewählt Konfigurationspaket gewählt Rechtepakete auswählen Rechtepakete auswählen XOR XOR Rechtepaket nicht gewählt Rechtepaket gewählt Rechtepaket nicht gewählt Rechtepaket gewählt Neue Anwendung in Zielumgebung erstellen Neue Anwendung in Zielumgebung erstellen Neue Anwendung in Zielumgebung erstellen Neue Anwendung in Zielumgebung erstellen Neue Anwendung erstellt Neue Anwendung erstellt Neue Anwendung erstellt Neue Anwendung erstellt Rechtedokumente in die Anwendung übernehmen Konfigurationsdokumente in die Anwendung übernehmen Konfigurations- und Rechtedokumente in die Anwendung übernehmen Rechtedokumente übernommen Konfigurationsdokumente übernommen Konfigurations- und Rechtedokumente übernommen XOR XOR XOR Anwendungsdokument im Repository erstellen Anwendungsdokument erstellt Abbildung 16: Mechanismus zum Verteilen neuer Anwendungen 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 54 Im Fall einer Aktualisierung des Designs einer Anwendung hat der Benutzer, wie oben beschrieben, die beiden Optionen, das Design entweder vollständig oder teilweise unter Ausschluss gewählter Designelemente zu aktualisieren. Die Prozesse dazu sind in Abbildung 17, Abbildung 18 und Abbildung 19 dargestellt. Abbildung 17 stellt den gesamten Prozess der Aktualisierung dar, während in Abbildung 18 und Abbildung 19 die Unterprozesse beschrieben werden, in denen die eigentliche Aktualisierung des Designs durchgeführt wird. Abbildung 17: Prozess zum Aktualisieren bestehender Anwendungen allgemein Der gesamte Prozess beginnt mit der Auslösung der Aktion zum Aktualisieren des Designs einer Anwendung. Als erstes muss eine Anwendung gewählt werden, die dann geladen wird. Anschließend wird ein Template gewählt, das als Basis für die Aktualisierung des Designs dient. Ist dies geschehen, wird das Template geladen und als Nächstes die Aktualisierungsmethode gewählt. Die Auswahlmöglichkeiten sind Designaktualisierung mit oder ohne Ausschluss von Designelementen. Ist die Entscheidung getroffen, wird die Aktualisierung, abhängig von der Auswahl, durchgeführt. An dieser Stelle spaltet sich der Prozess und es wird 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 55 einer der beiden möglichen Pfade gegangen. Wurde die Option zur kompletten Designaktualisierung gewählt, wird der dazugehörige Unterprozess ausgeführt (siehe. Abbildung 18). Abbildung 18: Unterprozess zum Aktualisieren ohne Ausschluss von Designelementen In diesem Fall kann zur Aktualisierung die unter Notes zur Verfügung gestellte Standardfunktionalität genutzt werden, die das Design komplett aktualisiert. Wurde die Option zur partiellen Aktualisierung des Designs gewählt, wird der andere Pfad im Prozess eingeschlagen und der Unterprozess zur partiellen Aktualisierung wird ausgeführt (siehe Abbildung 19). Bei diesem Unterprozess müssen zuerst die Informationen über die ausgeschlossenen Designelemente gelesen werden und diese anschließend von der Aktualisierung ausgeschlossen werden. Jetzt kann die Aktualisierung durchgeführt und damit der Unterprozess abgeschlossen werden. Die beiden Pfade werden wieder zusammengeführt, wenn das Design aktualisiert wurde. Zuletzt muss noch die Versionsnummer im Anwendungsdokument des Repositories auf den neuen Stand gebracht werden. Damit ist der Prozess der Designaktualisierung abgeschlossen. Abbildung 19: Unterprozess zum Aktualisieren bestehender Anwendungen unter Ausschluss ausgewählter Designelemente Nachdem die wichtigsten Prozesse, die sich dem Verteilen von Software widmen, beschrieben wurden, sollen im Folgenden die Anpassungsmöglichkeiten für eine Anwendung betrachte werden, um auf spezielle Fälle reagieren zu können. Hier bietet sich ein Mechanismus von Lotus Notes/Domino an, der in Abbildung 20 dargestellt und wie folgt zu beschreiben ist. Es existiert ein Template, in der Abbildung 20 als „Master-Template 1.0“ bezeichnet, das die Standardfunktionalitäten für ein Repository enthält. Von diesem Template wird die produkti- 4 Konzeption eines Systems zur Unterstützung der Deployment-Prozesse 56 ve Version des Repositories erstellt. Die produktive Version hat als Aktualisierungsgrundlage für spätere Designaktualisierungen das „Master-Template 1.0“ in den Eigenschaften eingetragen. Das „Master-Template 1.0“ wiederum hat als Aktualisierungsgrundlage ein weiteres Template eingetragen, in der Abbildung 20 als „MT Erweiterungen 1.0“ bezeichnet, in dem spezielle Funktionalitäten hinterlegt sind, die das Standard-Template erweitern. So kann das Standard-Template um Funktionalitäten ergänzt werden ohne das es selbst verändert wird. „Erweiterungsdatenbank“ Name: MT Erweiterungen 1.0 erweitert „Repository-Template“ Name: Master Template 1.0 Template: MT Erweiterungen 1.0 „produktives Repository“ aktualisiert Template: Master Template 1.0 Abbildung 20: Architektur zur Implementierung von speziellen Funktionen Damit sind die Architektur und die Prozesse der Funktionalitäten für ein System zur Unterstützung der Deployment Prozesse unter Lotus Notes/Domino beschrieben, so dass im folgenden Kapitel die prototypische Implementierung erläutert werden kann. 5 Prototypische Umsetzung 57 5 Prototypische Umsetzung Dieses Kapitel beinhaltet die prototypische Umsetzung des Entwurfs aus Kapitel 4.3. Zunächst wird kurz auf die Architektur und die Umgebung des Prototyps eingegangen. Anschließend wird die Implementierung der geforderten Funktionalitäten in den Prototyp genauer beschrieben. An dieser Stelle ist darauf hinzuweisen, dass nicht jede Anforderung implementiert wurde, die Gründe sind im Kapitel 6 Fazit und Ausblick zu finden und werden dort erläutert. Als Testgrundlage für die Umsetzung dient der am Groupware Competence Center der Universität Paderborn, kurz GCC, entwickelte Knowledge Pool, im weiteren Verlauf K-Pool genannt. Der K-Pool ist eine Lotus Notes Anwendung, die im Bereich Groupware anzusiedeln ist. 5.1 Umsetzung der Architektur Die Architektur ist aus dem Entwurf übernommen worden (siehe Abbildung 14 und Abbildung 15). Das Repository wird durch eine Datenbank abgebildet, die Template-, Datenbank- und Konfigurationsdokumente enthält. Die Template- und Datenbankdokumente enthalten Links zu den Template- und Anwendungsdatenbanken. Dadurch wird zum einen die Anwendung selbst nicht zu groß und zum anderen wird das im Entwurf beschriebene Problem, das bei der Aktualisierung der Daten entsteht, umgangen. Im Prototyp sind weitestgehend alle Anforderungen, die in Kapitel 4.2 erarbeitet wurden sowie die sich daraus ergebenen Funktionalitäten implementiert worden. Probleme traten jedoch bei der Umsetzung der Anforderung zur partiellen Designaktualisierung auf, darauf wird in Kapitel 6 näher eingegangen. Der Prototyp kann Templates und Anwendungen sowie die dazugehörigen Konfigurationsdokumente verwalten. Ebenso ist das Verteilen und Aktualisieren der Anwendungen auf Basis der im Prototyp verwalteten Datenbanken möglich. 5 Prototypische Umsetzung 58 5.2 Template- und Datenbankenverwaltung Die Applikation bietet dem Anwender eine übersichtliche Struktur über die zu verwaltenden Templates und Datenbanken. Dazu existieren Ansichten, die die Datenbanken und Templates nach verschiedensten Aspekten kategorisieren und so einen Überblick über die vorhandenen Daten verschaffen. Diese Ansichten sind in die drei Oberkategorien (siehe Abbildung 21), „Templates“, „Datenbanken“ und „Gemischt“ gegliedert. Zusätzlich gibt es zur Kontrolle eine Ansicht „Alle Dokumente“. Abbildung 21: Einstiegspunkte zu den Kategorien Unter der Kategorie „Templates“ sind nur die Templates zu finden, die in der Anwendung erfasst sind. Damit der Benutzer sich über diese einen Überblick verschaffen kann, sind die Templates in verschiedenen Ansichten nach unterschiedlichen Aspekten kategorisiert: • Kategorie der Anwendung • Server auf dem das Template abgelegt ist • Version Ein Beispiel ist in Abbildung 22 zu sehen. Dort werden die Templates nach Servernamen kategorisiert, auf denen sie abgelegt sind. Zusätzlich findet man relevante Informationen, wie den Namen, die Version und den Kategorienamen, zu dem das Template abgelegt wurde. Alle Templates sind über die gesamte Anwendung hinweg mit dem Piktogramm net. gekennzeich- 5 Prototypische Umsetzung 59 Abbildung 22: Kategorisierung von Templates nach Server Der Inhalt des Ordners Datenbanken stellt nur Ansichten dar, die ausschließlich Datenbankdokumente anzeigen. Diese sind genau wie bei den Templates in Kategorie, Server und Version gegliedert (siehe Abbildung 23). So kann der Anwender die Datenbanken gut überschauen sowie schnell und zielgerecht darauf zugreifen. Abbildung 23: Verwaltung von Datenbanken Das Symbol steht für die Einträge der Anwendungsdatenbanken und ist wie das Symbol der Templates über die gesamte Anwendung einheitlich. Abschließend ist eine Rubrik implementiert worden, in der sowohl Templates und Datenbanken, als auch Konfigurationsdokumente angezeigt werden. In dieser Datenbank werden Zusammenhänge zwischen den einzelnen Templates, den Datenbanken und den Konfigurationsdokumenten sichtbar. 5 Prototypische Umsetzung 60 Abbildung 24: Gemischte Ansicht mit Template-, Datenbank- und Konfigurationsdokumenten In Abbildung 26 ist eine gemischte Ansicht dargestellt. Es sind auch die zuvor beschriebenen Symbole für Datenbank- und Templatedokumente zu erkennen sowie das Symbol für Konfigurationsdokumente . Hier werden die jeweils zusammengehörigen Dokumente in Katego- rien dargestellt. 5.3 Anlegen von Templatedokumenten Um den Prototyp sinnvoll als Anwendung nutzen zu können, müssen zunächst Templatedokumente eingepflegt werde, die Informationen über die zu verwaltenden Templates enthalten. In Abbildung 25 ist ein solches Templatedokument dargestellt. Folgende Informationen werden benötigt, damit die gewünschte Funktionalität hergestellt werden kann: • Kategorie • Name • Version • Pfad • Server • Replikations-ID • Ob Konfigurationsdokumente zu dem Template abgelegt werden können • Template-Typ 5 Prototypische Umsetzung 61 Abbildung 25: Form zum Erfassen von Templatedokumenten Beim Feld Kategorie kann man das Template einer bereits bestehenden Kategorie zuordnen oder eine neue Kategorie eintragen und eröffnen. Das Feld Name wird automatisch durch den Templatenamen gefüllt. Im Feld Version ist vom Benutzer die Versionsnummer des anzulegenden Templates einzutragen. Um den Link zur Template-Datenbank in das Templatedokument zu bekommen muss der Benutzer den Pfad zur Template-Datenbank eintragen. Hierzu wird ihm ein Mechanismus zur Verfügung gestellt, der durch Auswahl der TemplateDatenbank automatisch den Namen, den Pfad, den Server und die Replikations-ID in das Dokument einträgt. Außerdem besteht die Möglichkeit an dieser stelle zu erlauben, dass diesem Template zu einem späteren Zeitpunkt Konfigurationsdokumente zugewiesen werden können. Die letzte Einstellung, die der Benutzer in diesem Dokument vornehmen kann ist die Auswahl des Template-Typs. Dies hat mit den in Kapitel 5.7 beschriebenen Anpassungsmöglichkeiten zu tun. Es wird an dieser Stelle ausgewählt, welche zusätzlichen Felder, die vorher hinterlegt wurden, im Konfigurationsdokument angezeigt werden. 5.4 Erstellen von Konfigurationsdokumenten Eine Anforderung an den Prototyp bzw. eine Software, die Deployment unterstützen soll, ist, dass die Ablage von Konfigurationsdokumenten, bzw. Paketen möglich ist. Als erstes wird auf die Dokumente eingegangen die angelegt werden müssen. Das Problem, das bei einer Software auftritt, die andere Software organisieren soll, ist die Allgemeingültigkeit für die Erfassung solcher Dokumente. Dies bedeutet, es kann nicht eine Maske zur Erfassung von 5 Prototypische Umsetzung 62 Konfigurationsdokumenten existieren, die für alle Anwendungen gültig ist. Als Beispiel benötigt die eine Anwendung das Feld „Anschrift“ eine andere benötigt aber die Felder „Strasse“ und „Hausnummer“. Es gibt die Möglichkeit an dieser Stelle eine dynamische Lösung zu finden, die eine Eingabemaske nach Regeln erstellt. Allerdings müssten dann jedes Mal, wenn in einer neuen Version der Anwendung ein Konfigurationsdokument geändert wird, diese Regeln auch im Dokument angepasst werden. Dies bedeutet zusätzlichen Aufwand und eine Redundanz der Daten. Dieser Prototyp bietet eine andere Lösung: er liest vorhandene Konfigurationsdokumente aus und speichert diese in dem Konfigurationsdokument. Deshalb muss mindestens eine konfigurierte Anwendung existieren. Der Mechanismus bedient sich dabei an dem in Lotus Notes/Domino integrierten Mechanismus der Doc-Links. Ein Doc-Link ist ein Link auf ein Dokument einer Datenbank. Mit Hilfe eines Doc-Links kann ein Dokument eindeutig in einer Lotus Notes/Domino Umgebung identifiziert werden. Abbildung 26: Form zum Erfassen von Konfigurationsdokumenten In Abbildung 26 ist eine Form zum Erfassen von Konfigurationsdokumenten dargestellt. Es ist zu erkennen, dass es zwei Abschnitte zum Erfassen gibt. Der obere Abschnitt „Konfiguration“ wird standardmäßig bei allen Konfigurationen eingeblendet. Der untere Abschnitt ist das Ergebnis einer Anpassung, die für eine spezielle Datenbank, in diesem Fall den „K-Pool“, vorgenommen wurde. An dieser Stelle wird abhängig von der Einstellung unter Template-Typ 5 Prototypische Umsetzung 63 im Templatedokument, der jeweilige Abschnitt mit Feldern dargestellt. Es werden folgende Informationen zum Anlegen eines Standardkonfigurationsdokumentes benötig: • Kategorie • Name • Version • Doc-Link zum Original Mit dem Feld Kategorie wird die Zuordnung in den Ansichten sichergestellt. Das Feld Name soll das Konfigurationsdokument treffend beschreiben und einen Wiedererkennungswert gewährleisten. Die Version der Anwendung sollte immer im Feld Version eingetragen werden und gleichzeitig im Feld Doc-Link der entsprechende Doc-Link zum Original des Konfigurationsdokuments gespeichert werden. Anschließend kann das Dokument über die „Anlegen“Schaltfläche generiert werden. Hierbei werden alle Funktionen aus dem Originaldokument in das neue Dokument übernommen. Abbildung 27: Defektes Konfigurationsdokument Sollte beim Erstellen ein Fehler auftreten wird dieser gemeldet. Das Konfigurationsdokument wird als defekt gekennzeichnet und kann nicht verwendet werden. Diese Kennzeichnung ist sowohl im Dokument (siehe Abbildung 27) durch einen großen roten Schriftzug zu erkennen, als auch in der Ansicht (siehe Abbildung 28). Dort werden fehlerhafte Konfigurationsdokumente mit diesem Symbol gekennzeichnet. 5 Prototypische Umsetzung 64 Abbildung 28: Ansicht mit fehlerhaftem Konfigurationsdokument 5.5 Anlegen von Datenbankdokumenten Nachdem beschrieben wurde, wie Template- und Konfigurationsdokumente in der Anwendung erstellt werden können, wird in diesem Kapitel erläutert, wie die Datenbankdokumente in der Anwendung zu handhaben sind. Es existieren zwei Möglichkeiten Datenbankdokumente zu erstellen. Die erste Möglichkeit ist für bereits existierende Datenbanken gedacht. Es können auch Anwendungen, die bereits im produktiven Einsatz sind, in die Datenbank zur Verwaltung und besseren Übersicht aufgenommen werden. Die zweite Möglichkeit ist das ein Dokument für eine neue, zu verteilende Anwendung erstellt wird. Diese beiden Möglichkeiten werden jetzt genauer beschrieben. 5.5.1 Erstellen von Datenbankdokumenten für vorhandene Anwendungen Anwendungen, die bereits im produktiven Einsatz sind, können ebenfalls in das Werkzeug aufgenommen werden. Dadurch hat der Benutzer einen besseren Überblick über seine Anwendungen und er hat zu einem späteren Zeitpunkt bessere Möglichkeiten Aktualisierungen der Anwendungen durchzuführen. Um eine Anwendung aufzunehmen muss ein Datenbankdokument erstellt werden. Beim Erstellen wird gefragt, welchem Template das neue Dokument zugeordnet werden soll. Ist diese Auswahl erfolgt kann die Datenbank ausgewählt werden, die in die Anwendung aufgenommen werden soll. Die sich anschließend öffnende 5 Prototypische Umsetzung 65 Form (siehe Abbildung 29) zeigt das Datenbank-Dokument mit den getroffenen Eingaben und den Eigenschaften der hinzugefügten Datenbank. An dieser Stelle kann nun noch die Auswahl getroffen werden, ob die zukünftigen Designaktualisierungen vollständig oder partiell erfolgen sollen. Wenn gewünscht kann auch noch eine kurze Beschreibung der Anwendung in das Dokument aufgenommen werden. Durch das Speichern des Dokumentes wird der Vorgang abgeschlossen. Abbildung 29: Erstellen eines Datenbankdokuments 5.5.2 Erstellen von Datenbankdokumenten für neue Anwendungen An dieser Stelle wird beschrieben, wie Anwendungen erstellt und verteilt werden können. Dieses Funktionsmerkmal ist schließlich im eigentlichen Sinn als Deployment zu bezeichnen und Schwerpunkt der Arbeit. Der Mechanismus zum Verteilen neuer Datenbanken ist durch folgende Lösung in die Software implementiert worden (siehe Abbildung 30). 5 Prototypische Umsetzung K K 66 Abbildung 30: Vorgang zum Erstellen neuer Anwendungen Das Repository enthält einen Link auf das Template, das die Basis für die neue Anwendung bildet. Wird die Aktion zum Bereitstellen einer Anwendung ausgelöst, so wird im ersten Schritt (1), mit Hilfe des Links aus dem Repository, das Template geladen. Als Zweites (2) werden auf der Basis des Templates die neue Anwendungsdatenbank in der Zielumgebung erstellt und die Konfigurationsdokumente in die Datenbank kopiert und dort gespeichert. Im dritten Schritt (3) wird der Link auf die neue Anwendung zurückgegeben, damit in Schritt vier (4) das Dokument für die Anwendung im Repository erstellt werden kann, inklusive dem Link auf die Anwendungsdatenbank. Der Benutzer hat im letzten Schritt nochmals die festzulegen, ob die Anwendung in Zukunft vollständig oder partiell aktualisiert werden soll. 5.6 Designaktualisierung vorhandener Datenbanken Zum Aktualisieren von Datenbanken existieren zwei Möglichkeiten: entweder es wird eine vollständige Designaktualisierung durchgeführt oder das Design wird nur teilweise aktualisiert. Die vollständige Designaktualisierung einer bestehenden Datenbank ist durch folgenden Mechanismus abzubilden (siehe Abbildung 31). Der Benutzer wählt in Schritt eins (1) die Anwendung, die aktualisiert werden soll und das Template mit dem neuen Design. Anschlie- 5 Prototypische Umsetzung 67 ßend wird in Schritt zwei (2) die Anwendung geladen. Danach wird dir Aktualisierung durchgeführt und die Datenbank wieder abgelegt (3). In Schritt vier (4) wird das Anwendungsdokument im Repository aktualisiert. Domino Directory Domino Directory Transformation Repository T DB T A 1 T 2 T A A K T T DB DB A DB 4 3 A Legende: A Anwendung K Konfiguration Link T Template Datenfluss Abbildung 31: Vorgang zum Aktualisieren von Anwendungen 5.7 Anpassungsmöglichkeiten Der Prototyp besitzt eine Möglichkeit zum Anpassen der Standardfunktionalitäten, wie es vorher schon in Kapitel 5.3 erwähnt wurde. Diese Funktionalität soll es dem Benutzer erlauben die Standard-Funktionalitäten des Prototyps zu erweitern. Vorgesehen ist dies vor allem für die Konfigurationsdokumente. Dies ist ebenfalls im vorhergehenden Text schon einmal kurz angesprochen worden. Die Problematik, die im Zusammenhang mit Konfigurationsdokumenten existiert ist, dass diese in verschiedenen Anwendungen nie gleich sind. Dazu kommt, dass bei der Konfiguration von Anwendungen teilweise Aktionen ausgeführt werden müssen, die man nicht mit einem Standardprodukt abdecken kann. Dafür benötigt man Anpassungsmöglichkeiten um diesen Problemen gewachsen zu sein. Die Lösung dieses Problems ist in dem Prototyp wie folgt implementiert worden (siehe Abbildung 32). Es existiert zum einen das Standard-Template, im folgenden Repository-Template genannt, welches die Standard Funktionalitäten des Prototyps enthält. Zusätzlich existiert ein Erweiterungstemplate, das das Design des Repository-Templates erweitert. So können grundsätzlich alle Anpas- 5 Prototypische Umsetzung 68 sungen im Erweiterungstemplate vorgenommen werden, so dass das Repository-Template unangetastet bleibt. Ein weiterer Vorteil ist das Erhalten der Anpassungen, wenn eine neue Version des Repository-Templates ausgeliefert werden sollte. Wären in diesem Falle die Anpassungen im Original-Template gemacht worden, so könnte es schwierig sein, diese nachzuvollziehen und in das neue Template zu übertragen. Mit Hilfe des Erweiterungstemplate ist dies kein Problem, da die Anpassungen getrennt vorliegen und nur erneut in die neue Version des Templates eingespielt werden müssen. „Erweiterungstemplate“ Name: MT Erweiterungen 1.0 erweitert „Repository-Template“ Name: Master Template 1.0 Template: MT Erweiterungen 1.0 „produktives Repository“ aktualisiert Template: Master Template 1.0 Abbildung 32: Architektur für Anpassungsmöglichkeiten Um Anpassungen im produktiv eingesetzten Repository anzusprechen und zu verwenden müssen drei Dinge beachtet werden. Als erstes existieren im Ordner Konfiguration Schlüsselwortlisten und Schlüsselworte. Es existiert eine spezielle Schlüsselwortliste mit dem Namen „Customized Datenbanken“ dort ist das Schlüsselwort für die Anwendung, für die Anpassungen vorgenommen wurden, einzutragen. Zweitens existiert im Erweiterungstemplate eine Script-Libary, bei der mit einer Abfrage die Anpassung abgefragt wird, an dieser Stelle ist der entsprechende Code zu ergänzen, der ausgeführt werden soll. Als dritter und letzter Punkt besteht die Möglichkeit über eine Subform die Konfigurationsdokumente zu erweitern. Diese muss das Schlüsselwort aus der Liste als Namen eingetragen haben, damit sie angezeigt wird. 6 Zusammenfassung und Ausblick 69 6 Zusammenfassung und Ausblick Die Zielsetzung der vorliegenden Arbeit war die Konzeption einer Architektur für ein System zur Unterstützung der Deployment Prozesse unter Lotus Notes/Domino. Unter Deployment ist in dieser Arbeit das Verteilen und Aktualisieren von Anwendungen in verteilten Umgebungen zu verstehen. Dieser Prozess wird in der Literatur nur selten separat betrachtet und ist in den häufigsten Fällen als Teil des Softwareentwicklungsprozesses beschrieben. Um die Zielsetzung zu erreichen, wurde Anfangs ein Einblick in das Umfeld und die theoretischen Grundlagen von Lotus Notes gegeben sowie verwendete Techniken und die Thematik der Softwareentwicklung und des Deployments beschrieben. Auf Basis der Grundlagen wurden die Unterschiede zwischen allgemeinem Deployment und dem Standard Deployment-Prozess unter Lotus Notes/Domino erarbeitet. Dabei ist der Versuch unternommen worden den Standard Deployment-Prozess von Lotus Notes/Domino auf den allgemeinen Deployment-Prozess, mit den Phasen Installation, Konfiguration, Planung, Vorbereitung und Einführung, abzubilden. Die sich aus diesem Vergleich ergebenen Unterschiede bilden die Grundlage für die Erstellung eines Anforderungskataloges. Auf Basis der Anforderungen ist ein Entwurf für eine Architektur und ein Lösungsansatz für die geschilderte Problematik, in Bezug auf Deployment, erarbeitet worden. Dieser berücksichtigt die technischen Gegebenheiten, wie zum Beispiel Dokumenten basierte Datenbanken und die Client-/Server-Struktur, die im Zusammenhang mit der Plattform Lotus Notes/Domino zu finden sind. Aus den Ergebnissen des Entwurfs ist als Abschluss der Arbeit eine prototypische Umsetzung erfolgt. Diese soll einen Lösungsweg aufzeigen, mit dem Deployment in Lotus Notes basierten Arbeitsumgebungen vereinfacht und strukturierter gestaltet werden kann. Der Prototyp sollte alle an ihn gestellten Anforderungen abdecken. Auf Grund von diversen Problemen im Umgang mit XML unter Lotus Notes ergaben sich bei der Implementierung jedoch folgende Schwierigkeiten, die dazu führten, dass die beiden Anforderungen „Ausschluss ausgewählter Designelemente bei einer Aktualisierung“ und „Rechteverwaltung für zu verteilende Anwendungen“ nicht umgesetzt werden konnten. Folgende Gründe sind für die Nichtberücksichtigung im Prototyp zu nennen: Bei allen Versuchen das Design nach XML zu konvertieren ist der Prozess mit einer Fehlermeldung, unterbrochen worden. Die Ursache konnte nicht genau geklärt werden, allerdings 6 Zusammenfassung und Ausblick 70 liegt die Vermutung nahe, dass ein Zusammenhang mit der Größe der Beispielanwendung „K-Pool“ besteht. Der Prozess generiert eine XML-Datei, die bei Abbruch jeweils größer als 30 Megabyte war. Die Größe war allerdings bei den Versuchen nicht immer identisch, so dass nicht von einem Fehler in der Beispiel-Anwendung ausgegangen werden kann. Auf Grund des fortgeschrittenen Zeitpunktes, zu dem dieses Element implementiert werden sollte, gab es keine Möglichkeit diese Funktionalität vollständig fertig zu stellen. Einzelne Teile sind allerdings vorhanden, so dass in kleineren Anwendungen die Auswahl der auszuschließenden Designelemente möglich ist. Bei größeren Anwendungen schlägt der Versuch beim Auslesen des Designs fehl. Dieser Fehler hat die gleiche Ursache, wie der Vorherige, da auch das Auslesen der Designelemente auf XML-Basis besteht. Für die Nichtberücksichtigung der „Rechteverwaltung“ ist der vorangegangene Fehler die Ursache. Auf Grund des Fehlers auf der XML-Ebene beim Auslesen der Designelemente, war für diese Anforderung ebenfalls die Zeitkomponente der kritische Faktor. Der Versuch eine Lösung für das Problem zur Designaktualisierung zu finden hat die zur Verfügung stehende Zeit voll ausgeschöpft. Daher ist auch dieses Element bei der Implementierung nicht berücksichtigt worden. Es existieren Ansätze im Prototyp, die weiter verfolgt werden können, falls die nicht vorhandenen Funktionalitäten nachträglich implementiert werden sollen. Diese Ansätze sind zum einen die mögliche Auswahl von Designelementen bei kleineren Anwendungen und zum anderen die Rechteverwaltung. Dafür ist ein sehr interessanter Ansatz in der Diplomarbeit „Konzeption und prototypische Implementierung einer Architektur zur Modularisierung von Groupware- Applikationen“ von Michael Klages zu finden. Dort wird die Access-ControlList von Lotus Notes Datenbanken in eine XML-Datei exportiert und kann als Rechtepaket wieder verwendet werden. Diese lassen sich zu einem späteren Zeitpunkt auf gleichem Wege in andere Datenbanken importieren. 7 Quellenverzeichnis 71 7 Quellenverzeichnis [Balzert 2000] Balzert, Helmut: Lehrbuch der Software-Technik – Software-Entwicklung, Spektrum Akademischer Verlag, Heidelberg 2000 [Beck / Fowler 2001] Beck, Kent; Fowler, Martin: Planning Extreme Programming, Addison-Wesley, Boston 2001 [Behme / Mintert 2000] Behme, Henning; Mintert, Stefan: XML in der Praxis, Addison-Wesley, München 2000 [Bennatan 1992] Bennatan, Edwin M.: Software Project Management: A Pactitioner´s Approach, MrGRAW-HILL Book Company Europe 1992 [Bishop 2002] Bishop, Judith (Ed.): Component Deployment, Springer-Verlag Berlin 2002 [Boehm 1988] Boehm, Barry W.: A Spiral Modell of Software Development and Enhancement, TRW Defense Systems Group 1988 http://www.sce.carleton.ca/faculty/ajila/4106-5006/Spiral%20Model%20Boehm.pdf (am 23.04.2007) [Bundschuh / Fabry 2004] Bundschuh, Manfred; Fabry, Axel: Aufwandsschätzung von IT-Projekten, 2. Auflage, mitp-Verlag, Bonn 2004 [Deployment 2003] (Ohne Verfasser): Specification for Deployment and Configuration of Componentbased Distributed Applications, Fraunhofer FOKUS, Mercury Computer Systems, Rockwell Collins 2003 http://www.omg.org/docs/mars/03-05-08.pdf (am 23.04.2007) 7 Quellenverzeichnis 72 [Dierker / Sander 1998] Dierker, Markus; Sander, Martin: Lotus Notes 4.6 und Domino – Integration von Groupware und Internet, Addison-Wesley, München 1998 [Ebel 2006] Ebel, Nadin: Lotus Notes Domino 7-Administration Band 1+2, Addison-Wesley, München 2006 [Elliot 2007] Elliot, Mark: Lotus Notes Developer´s Toolbox – Tips for Rapid and Successful Deployment, IBM, 2007 [Emmerich / Wolf 2004] Emmerich, Wolfgang; Wolf, Alexander L.: Component Deployment, Springer-Verlag Berlin 2004 [Frick 1995] Fick, Andreas: Der Software-Entwicklungsprozeß – Ganzheitliche Sicht – Grundlagen zu Entwicklungs-Prozeß-Modellen, Carl Hanser Verlag München Wien 1995 [Goldfarb / Prescod 2000] Goldfarb, Charles F.; Prescod, Paul: Das XML-Handbuch, Addison-Wesley, München 2000 [Greif 1988] Greif, Irene (Hrsg.): Computer Supported Cooperative Work: A Book of Readings; Morgan Kaufmann Publishers, San Mateo, California 1988 [Harold 1998] Harold, Elliotte Rusty: XML – Extensible Markup Language, IDG Books Worldwide Inc., Foster City, CA, 1998 [Hasenkamp / Kirn / Syring 1994] Hasenkamp, Ulrich; Kirn, Stefan; Syring, Michael (Hrsg.): CSCW – Computer Supported Co-operative Work. 1. Auflage, Addison Wesley GmbH, Bonn 1994 [IBM 2007-1] http://www.ibm.com/de (am 30.03.2007) 7 Quellenverzeichnis 73 [Johansen 1988] Johansen, Robert: Groupware: Computer Support for Business Teams. 2. Auflage, Free Press, New York 1988 [Lewis 1996] Lewis, Ted: Deploying Distributed Business Software, SIGS Books, New York 1996 [Ludewig / Lichter 2007] Ludewig, Jochen; Lichter, Horst: Software Engineering – Grundlagen, Menschen, Prozessse, Technien, dpunkt.verlag GmbH, Heidelberg 2007 [Kolm / Böck / Humpert 2002] Kolm, Klaus-Dieter; Böck, Monika; Humpert, Hubert: Lotus Notes 6 und Domino – Arbeiten im Team, arbeiten im Web, Addison-Wesley, München 2003 [Lotus 1995] (Ohne Verfasser).: Groupware - Communication, Collaboration, Coordination (1995). http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/0/5098c20fcf549d15412564ca00333bc2/$F ILE/Groupwar.pdf (am 16.04.2007) [Lotus 2005-1] (Ohne Verfasser): Application Development with Lotus Domino Designer, IBM 2005 http://doc.notes.net/uafiles.nsf/docs/DESIGNER70/$File/appdev.pdf (am 30.03.2007) [Lotus 2005-2] (Ohne Verfasser): Programming Guide, Volume 1: Overview and Formula Language, IBM 2005 http://doc.notes.net/uafiles.nsf/docs/DESIGNER70/$File/prog1.pdf (am 30.03.2007) [Lotus 2005-3] (Ohne Verfasser): Programming Guide, Volume 4: XML, Domino DTD, and JSP Tags, IBM 2005 http://doc.notes.net/uafiles.nsf/docs/DESIGNER70/$File/prog4.pdf (am 30.03.2007) 7 Quellenverzeichnis 74 [Lotus 2005-4] (Ohne Verfasser): Lotus Domino Designer 7 Help, IBM 2005 http://doc.notes.net/uafiles.nsf/docs/designer70/$File/help7_designer.exe (am 30.03.2007) [Lotus 2005-5] (Ohne Verfasser): Messaging und Collaboration auf Großunternehmensniveau für kleine und mittlere Unternehmen, IBM 2005 http://www.software-express.de/telig-c/info3/ibm/lotus/lotus-domino-notescollaboration-express-7-produktblatt.pdf (am 14.05.2007) [Lotus 2007-1] http://www.ibm.com/software/de/lotus (am 30.03.2007) [Morrison et al. 2000] Morrison, David; Benz, Brian; Calhoun, Paul; Murakami, Yusuke: XML Powered by Domino - How to use XML with Lotus Domino, IBM Redbook, 2000 [Nastansky et al. 2002] Nastansky, Ludwig; Bruse, Thomas; Haberstock, Philipp; Huth, Carsten; Smolnik, Stefan: Büroinformations- und Kommunikationssysteme: Groupware, Workflow Management, Organisationsmodellierung und Messaging-Systeme, in: Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl, Leena: Bausteine der Wirtschaftsinformatik, 3. Auflage, Erich Schmidt Verlag, Berlin, 2002 [Petrovic 1993] Petrovic, Otto: Workgroup Computing – Computergestützte Teamarbeit, Physica Verlag, Heidelberg 1993 [Standish 1995] Standish Group: Chaos – The Dollar Drain of IT Projects Failure; PC Week, No. 16, Jan.1995 [Suhl / Blumstengel 2002] Suhl, Lena, Blumstengel, Astrid: Systementwicklung, in: Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl, Leena: Bausteine der Wirtschaftsinformatik, 3. Auflage, Erich Schmidt Verlag, Berlin, 2002 7 Quellenverzeichnis 75 [Teufel et al. 1995] Teufel, S.; Sauter C.; Mühlherr T.; Bauknecht, K.: Computerunterstützung für die Gruppenarbeit. Addison-Wesley, Bonn 1995 [Tulisalo et al. 2002] Tulisalo, Tommi; Carlsen, Rune;Guirard, Andre; Hartikainen, Pekka; McCarthy, Grant; Pecly, Gustavo: Domino Designer 6 – A Developer´s Handbook, IBM Redbook, 2002 [Tworek et al. 2002] Tworek, William; Chiesa, George; Dahm, Frederic; Hinkle, David; Mason, Amanda; Milza, Matthew; Smith, Amy: Lotus Security Handbook, IBM Redbook, 2004 [Winter 2005] Winter, Mario: Methodische objektorientierte Softwareentwicklung – Eine Integration klassischer und moderner Entwicklungskonzepte, dpunkt.verlag GmbH, Heidelberg 2005 [XML 2000-1] http://edition-w3c.de/TR/2000/REC-xml-20001006/ (am 05.04.2007) [XML 2001-1] http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/ (am 09.04.2007) [XML 2006-1] http://www.w3.org/XML/Core/#Publications (am 05.04.2007) 7 Quellenverzeichnis 76 Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und nur unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Paderborn, den 15.05.2007. . . . . . . . . . . . . . . . . . . . . . . . . . .
