Weiterentwicklung und Evaluierung des. Promotionsverwaltungssystems

Transkript

1 Diplomarbeit Weiterentwicklung und Evaluierung des Promotionsverwaltungssystems eingereicht von Nico Häßlich geboren am Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Rechnernetze Dresden Betreuerin: Dr.-Ing. Iris Braun Betreuender Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Eingereicht am 13. Januar 2015

2 II

3 III

4 IV

5 Inhaltsverzeichnis 1 EINLEITUNG MOTIVATION ZIELSETZUNG RÜCKBLICK AUF DAS ERGEBNIS AUS DEM GROßEN BELEG [HÄ14] KONZEPTVORBEREITUNG/-ERGÄNZUNG WIEDERHOLUNG DER ANFORDERUNGEN EINORDNUNG DER CHECKLISTENERWEITERUNG NEUER ANSATZ ALS IDEENSKIZZE VORBEREITUNG AUF DIE REGELSPRACHE Aufgabe und Fallbeispiel Ansatz 1: Skriptsprache Ansatz 2: Business Rules Die bisherige Regelsprache Basis des Regel-Controllings FUNDAMENT DES SYSTEMS Selbstentwickeltes Framework als Basisarchitektur Alternative Basisarchitekturen IMPLEMENTIERUNGSKONZEPT GESAMTÜBERBLICK KOMPONENTE: DATENBANKVERWALTUNG KOMPONENTE: ALLGEMEINE KONFIGURATION KOMPONENTE: CHECKLISTE KOMPONENTE: FENSTERKONFIGURATION Teilkomponente: Referenzkonfiguration (Fenster) Teilkomponente: Schaltflächen- und Parameterkonfiguration (Fenster) Teilkomponente: Sichtkonfiguration (Fenster) Zusammenfassung der Komponente: Fensterkonfiguration KOMPONENTE: ROLLEN-CONTROLLING KOMPONENTE: DATEN-CONTROLLING KOMPONENTE: VORLAGEN-CONTROLLING KOMPONENTE: BEFEHLSSYSTEM KOMPONENTE: REGEL-CONTROLLING Begriffserklärung Umsetzung und Entwurfstruktur Neuerungen und Einsatzmöglichkeiten Optionale Erweiterung des Regel-Controllings KOMPONENTE: ABSTIMMUNGSSYSTEM KOMPONENTE: CRONJOB-CONTROLLING MÖGLICHE SERVERARCHITEKTUR AUSWERTUNG V

6 Inhaltsverzeichnis 4 RESULTIERENDE UMSETZUNG ÜBERSICHT DES MENÜS Konfiguration Cronjob Vorlagenstruktur SEITENVERWALTUNG CHECKLISTENSVERWALTUNG Registerkarten einer Checkliste Checklisteneinträge Kopiermodus VERWALTUNG DER TEMPLATES (VORLAGEN) Voraussetzung Vorlagen-Definitionsmodus Spezialvorlagen Vorlagen-Deklarationsmodus Controlling Sichten Regelsprache Kopiermodus BESCHRÄNKUNGEN DER VORLAGEN IMPLEMENTIERUNG EINER WEITEREN VORLAGE Aufbau einer standardisierten Vorlage Neue Vorlage hinzufügen Nachteil der Kompositionsstruktur im Vorlagensystem SCHWIERIGKEITEN WÄHREND DER IMPLEMENTIERUNG Probleme mit dem Implementierungskonzept und Komplexitätsanstieg Refactoring des Konzeptes während der Implementierung AUSWERTUNG EVALUATION DER PRAXISTAUGLICHKEIT UMSETZUNGSMÖGLICHKEITEN BEI MEHREREN FAKULTÄTEN / PO'S KONFIGURATION VON PROMOTIONSORDNUNGEN Umsetzung der PO für die Fakultät Informatik Umsetzungsmöglichkeiten für den ING-Bereich FEEDBACK DURCH BENUTZER DES SYSTEMS Kriterien Feedback der Sachbearbeiter Feedback der Professoren Feedback zur Konfiguration OPTIMIERUNG Analyse und Durchführung Ergebnis AUSWERTUNG TESTS UND VERIFIZIERUNG PARSER ALS VERIFIZIERUNGSWERKZEUG VI

7 Inhaltsverzeichnis Bedeutung einer Verifizierung Anwendungsbeispiel VISUELLE KONTROLLE SEMANTISCHE UND LOGISCHE FEHLERANALYSE MODULTESTS (UNIT-TESTS) BEWERTUNG DER TECHNIKEN AUSSICHT ZUSAMMENFASSUNG ANLAGE A ANLAGE B ANLAGE C ANLAGE D ANLAGE E ANLAGE F ABBILDUNGSVERZEICHNIS DEFINITIONSVERZEICHNIS LISTINGS TABELLENVERZEICHNIS LITERATURVERZEICHNIS VII

8 Inhaltsverzeichnis VIII

9 1 Einleitung Diese Arbeit beschäftigt sich mit der Weiterentwicklung des erarbeiteten Konzeptes aus dem Großen Beleg [Hä14]. Darin wurde ein Ansatz gesucht, der die Anpassbarkeit und Erweiterbarkeit eines Promotionsverwaltungssystem garantiert und verschiedene Promotionsordnungen erfassen kann, vorerst auf den Ingenieurbereich (ING-Bereich) der TU Dresden beschränkt. Das Kapitel 1 vermittelt die nötige Motivation und gewährt einen Einblick in die Zielsetzung. Das abschließende Unterkapitel 1.3 fasst die Analyseergebnisse aus dem Großen Beleg noch einmal komprimiert zusammen, um einen Einstiegspunkt in diese Arbeit zu erhalten. 1.1 Motivation Durch das jetzige aktive Promotionsverwaltungssystem kann ausschließlich die Promotionsordnung der Fakultät Informatik der TU Dresden abgebildet werden. In über drei Jahren Entwicklungszeit wurden viele Anpassungen vorgenommen. Einige davon waren einfach, andere hingegen sehr aufwendig in der Umsetzung. Ein Fachanwender kann keine konkreten Abläufe ändern oder gar hinzufügen. Lediglich die Anpassung von - und PDF-Vorlagen ist möglich. Die Konfigurationsoptionen der vorhandenen Checkliste wurde nicht genutzt, da ein zu geringer Einfluss vorliegt. Beispielweise ist es möglich Abhängigkeiten zu definieren oder neue Einträge zu ergänzen, doch die eigentliche Funktionalität der Einträge muss durch einen Entwickler vorgenommen werden. Immer wieder kommen neue Anforderungen hinzu, die teilweise keine Änderung an der Promotionsordnung als Ursprung haben, sondern allgemeine Funktionalitäten fordern. So war eine der letzten Erweiterungen, die Abfrage verschiedener Statistiken zu ermöglichen. Diese Anforderung war im Ganzen betrachtet nur eine kleinere Bereicherung. Eine oftmals neue Abstimmung für einen neuen Antrag ist eine komplizierte und aufwendige Angelegenheit, wie es im Großen Beleg [Hä14] detailliert veranschaulicht wurde. Zahlreiche Schritte sind notwendig, um das dahinter stehende Klassensystem mit den unterschiedlichen Auswertungsmöglichkeiten zu komplettieren. Die hier angesprochenen Punkte sind nur eine grobe Übersicht über den Beweggrund eine Software zu entwerfen und umzusetzen, um eben diese Nachteile entgegenzuwirken. Mit diesem Vorgehen soll in Zukunft der Entwickleranspruch verringert, der Eingriff durch Fachanwender erhöht, eine noch feiner Informationsabbildung ermöglicht werden und Änderungen durch Tests- und Simulationsmöglichkeiten schnell und unmittelbar umsetzbar sein. Somit wäre die gewünschte Erweiterbarkeit und Variabilität erfüllt. 1.2 Zielsetzung Das erste Ziel dieser Arbeit ist die Weiterentwicklung des im Großen Beleg [Hä14] entstandenen Prototyps. Dieser Prototyp entstand auf der Basis eines herausgefilterten 1

10 1 Einleitung Konzeptes. Das Konzept wird zu Begin wiederholt aufgearbeitet und um fehlende Anforderungen ergänzt. Zu berücksichtigen ist die geltende Forderung für Anpassbarkeit und Erweiterbarkeit hinsichtlich auf die Einsatzmöglichkeit an weiteren Fakultäten der TU Dresden. Die Umsetzung soll also eine flexible Anpassung an den persistenten Datensätzen, als auch an den Datenflüssen, sicherstellen. Die Schwierigkeit liegt, wie bereits im Beleg beobachtet, in der Erfassung von feinen Unterschiedsmerkmalen zwischen den Promotionsordnungen. Wobei zu gewährleisten ist, dass ein Fachanwender des Systems ohne Entwicklungserfahrung diese Änderungen vornehmen soll. Sobald das Implementierungskonzept, die dazugehörigen Vorbereitungen und die resultierende Umsetzung vollständig beschrieben ist, kann die Evaluation beginnen. Die Evaluation soll sicherstellen, dass die erhobenen Ziele erfüllt wurden. In Bezug auf das eben Gesagte ist es notwendig eine vollständige Promotionsordnung zu konfigurieren und ansatzweise die Unterschiede zwischen den Ordnungen hervorzuheben. Um festzustellen, ob das neue System zumindest die Funktionalitäten des alten Systems und die Anforderungen darüber hinaus abbilden kann. Durch eine Befragung der beteiligten Mitarbeiter, die jetzt und später Zugriff auf das System haben, wird die Praxistauglichkeit zusätzlich nachgewiesen. In dem Fall spielt nicht nur die Anwendung eine Rolle, sondern ebenfalls die Einschätzung zur Konfigurationsmöglichkeit und zur entwickelten Regelsprache für das System. Zusätzlich soll mit den aufgestellten Anforderungen aus dem Großen Beleg [Hä14, S. 74] verglichen werden. Problematisch wird die Überprüfung der Eingaben zur Konfiguration des Systems. Die hierfür notwendige Verifizierung liegt bei logischen Fehlern im Bereich von komplexen Analyseverfahren. Das Ziel sollte aus diesem Grund hauptsächlich auf die Syntax gerichtet sein, um mindestens den Aufbau der Konfiguration auf Korrektheit zu prüfen. Außerdem ist es bedeutsam nicht nur die Konfiguration zu inspizieren, sondern vordem die internen Systemkomponenten durch Komponententests zu überprüfen. Nur wenn diese Prozesse fehlerfrei arbeiten, kann die resultierende Verifizierung verwertet werden. Schließlich soll das System darüber hinaus effizient laufen. Durch Metriken ist die Ladezeit zu untersuchen und durch dazugehörige Optimierungen bei Bedarf zu verbessern. Das System wäre nicht verwendbar, wenn das System von einem komplexen Aufruf blockiert würde. 1.3 Rückblick auf das Ergebnis aus dem Großen Beleg [Hä14] Im Großen Beleg [Hä14] sollte herausgefunden werden, welche Konzepte für eine Umstrukturierung geeignet sind, um verschiedene Promotionsordnungen mit deren Lebenszyklus zu erfassen, hinsichtlich auf Anpassbarkeit und Erweiterbarkeit. Als Grundlage dienten Promotionsordnungen und vorhandene Systeme. Bei den vorhandenen Systemen fiel auf, dass in erster Linie statische Daten verwaltet werden. Dieser Fakt ist das Hauptproblem. Das derzeitige Promotionsverwaltungssystem generiert Abstimmungen, Anfragen oder wertet diese auch bei Abschluss entsprechend aus. Es müssen keine Wiedervorlagen verwendetet werden, da das System über ein 2

11 1.3 Rückblick auf das Ergebnis aus dem Großen Beleg [Hä14] Erinnerungssystem verfügt, wie beispielweise der Hinweis auf eine abgeschlossene Abstimmung oder der Eingang eines neuen Antrags. Es können deutlich mehr Anträge verwaltet werden. Die dazugehörigen Protokolle sind mit einer Systemaktion erstellt. Ein Fluss der Abhandlung einer Promotionsordnung ist deutlich zu erkennen. Auch der Kandidat bzw. der Doktorand bekommt eine Übersicht des Ablaufes zur Verfügung gestellt. Das Resultat ist der korrekte Ablauf der Promotion. Diese Strenge führte teilweise zu Kritik, wodurch das Recht für einen manuellen Eingriff erweitert wurde. Diese Faktoren sprechen für ein dynamisches System. Ein Beispiel für ein statisches System wäre Docata 1. Diese Doktorandenverwaltung kann, ähnlich wie das HIS 2 -System, eine große Menge an Daten abfragen und verwalten. Obwohl das HIS bedeutend mehr beinhaltet, was die gesamte Hochschulverwaltung betrifft, wie Zulassung, Finanzen und Personal. Eine Ergänzung um neue Dokumente ist zwar möglich, jedoch fehlen die Automatisierungen, welche die Abwicklungsprozesse für einen Fachanwender zeitlich und im Aufwand reduzieren. Eine entsprechende Umfrage zum aktuellen System im Großen Beleg [Hä14] haben diesen Punkt bestätigt. Darüber hinaus können schnelle Änderungen oder Erweiterungen an diesen Systemen nicht einfach durchgeführt werden. Entweder sind diese so komplex, dass eine geschulte Person diese Anpassungen vornehmen muss oder die Anforderungen zum Entwicklungsteam geleitet werden, welches das System wartet und in gegebener Zeit aktualisiert. Auf dieser Basis wurden im Großen Beleg [Hä14] verschiedene Konzepte entworfen, die alle Vorteile abdecken und die Nachteile reduzieren oder ganz beseitigen. Das bisherige Konzept ist für die Fakultät bisher eine zufriedenstellende Lösung gewesen. Doch es muss auch möglich sein, andere Promotionsordnungen abzubilden. Eine wiederholte, aufwendige Re-Implementierung ist keine akzeptable Lösung. Deswegen war es notwendig Konzepte zu finden, die eine stärke Konfigurationsmöglichkeit zulassen. Die dazugehörigen Ideen und Ziele wurden im Großen Beleg vorgestellt [Hä14, S. 74]. Letztendlich ist das Konzept für eine Checklistenerweiterung die wirtschaftlichste Alternative, da bereits entsprechende Komponenten vorhanden sind. Die Checkliste ist im jetzigen System die Kernkomponente. Eine Funktionalität, um Einträge hinzuzufügen, ist ebenfalls vorhanden. Die einfache Regelsprache kann bereits kleinere Anliegen erfolgreich erfüllen, wie die Einhaltung von Zeitangaben. Eine größere Erweiterung in den angesprochenen Punkten wäre bereits eine zweckmäßige Lösung. Der erste Prototyp zeigte das umsetzbare Konzept. Die Ansätze der Durchführbarkeit der Ziele wurde im Großen Beleg [Hä14] dokumentiert. An dieser Stelle kann nun mit dieser vorangegangenen Arbeit angesetzt werden. 1 Docata ist eine Doktorandenverwaltung von Divinus Soft. 2 HIS steht für Hochschul-Informations-System. Siehe: Stand

12 1 Einleitung 4

13 2 Konzeptvorbereitung/-ergänzung Dieses Kapitel wiederholt zunächst die grundlegenden Anforderungen, ordnet die Checklistenerweiterung aus dem Großen Beleg [Hä14] neu ein und skizziert einen weiterentwickelten Ansatz. Danach wird auf die Analyse der Regelsprache näher eingegangen. Im letzten Kapitel folgt die Systemvoraussetzung, welche im Entwurf als Basis verwendet wird. 2.1 Wiederholung der Anforderungen Im Großen Beleg [Hä14] wurden verschiedene Alternativen gesucht, um das bestehende Informationssystem zur Verwaltung des Repositoriums von Promotionsdaten und die darauf basierenden Abläufe variabel und erweiterbar umzusetzen. Hierbei wurde unterschieden zwischen einem statischen und einem dynamischen System. Das statische System wird infolge einer mangelnden Abbildung des Ablaufes einer Promotionsordnung nicht weiter betrachtet. Demgegenüber erfasst ein dynamisches System den exakten Prozess inklusive einer vollständigen Automatisierung vieler Anforderungen. Die folgende Auflistung beinhaltet die wesentlichen Anforderungen: 1. Das System soll als eine Webanwendung im Browser auf jedem System, unabhängig der Plattform, zugänglich sein. 2. Eine Anpassung des kompletten Ablaufes aller Arbeitsschritte und eine Erweiterung um neue Anforderungen soll möglich sein. 3. Bestehende Abläufe sollen für einen Sachbearbeiter als Automatisierung übernommen oder zumindest erleichtert werden. 4. Prinzipiell soll durch den zweiten Punkt auch die Erfassung unterschiedlicher Promotionsordnungen umsetzbar sein und das System an weiteren Fakultäten zur Verfügung stehen. 5. Eine Änderung an der Konfiguration soll durch jeden Benutzer durchführbar sein. Insbesondere soll dabei von der Hilfe eines Entwicklers abgesehen und eine aufwendigere Anpassung in der Implementierung verhindert werden. 6. Ein konfiguriertes System soll zusätzlich auf Vollständigkeit eines Promotionsablaufes prüfen, um einen Abgleich mit der spezifischen Promotionsordnung herzustellen. Durch Punkt (1) wird von Beginn an eine komplizierte Installation vermieden. Außerdem ist somit eine leichte Zurverfügungstellung von mobilen Seiten realisierbar. Die nächsten drei Punkte erfordern einen Ansatz zur Umsetzung. Der Punkt (5) soll zunächst als Vorteil gelten, jedoch können auch verschiedene Nachteile daraus abgeleitet 5

14 2 Konzeptvorbereitung/-ergänzung werden. Ein unerfahrener Benutzer könnte unabsichtlich eine funktionierende Konfiguration zerstören oder löschen. Eine zusätzliche Verteilung von Befugnissen könnte das Problem lösen. Andererseits kann eine fehlende Abbildung einer Information relativ schnell ergänzt werden. Eine Entlastung des Sachbearbeiters kann durch Punkt (6) erreicht werden. Es werden hierfür keine detaillierten Kenntnisse über eine Promotionsordnung vorausgesetzt. Darüber hinaus sollen verschiedene Abstimmungen durch den Promotionsausschuss konfigurierbar und erweiterbar sein. Eine mobile Ansicht ermöglicht die Abstimmung der Mitglieder unabhängig vom Ort. Daraus entstanden verschiedene Ansätze zur Umsetzung einer Promotionsverwaltung. Das favorisierte Konzept entsprach nach der Auswertung entsprechender Ziele aus dem großen Beleg [Hä14, S. 74] einer Checklistenerweiterung. Diese sollte so erweitert werden, dass es möglich ist, die Einträge anzupassen und auch verschiedene Checklisten zu verwalten. Die restlichen Konzeptmöglichkeiten werden in dieser Arbeit nicht weiter diskutiert. Doch der ausgewählte Ansatz ist ungenügend, um das Maß der gewünschten Flexibilität zu erreichen. Im Laufe des nächsten Hauptabschnittes wird ein überarbeiteter, konkreter Entwurf entwickelt, der als Basis für den zuvor entstandenen Prototyp nach [Hä14] dient. Im anschließenden Kapitel wird das konkrete Implementierungskonzept beschrieben. Im Folgenden wird mit dem Ansatz Checklistenerweiterung aus dem Großen Beleg [Hä14] fortgesetzt. Die vollständige Analyse bzw. die Erläuterung der Anforderungen wurde darin ausgiebig diskutiert. Die nächsten beiden Kapitel 2.2 und 2.3 sollen einen Überblick über die wichtigsten Veränderungen vermitteln. Vor allem soll die Ideenskizze noch einmal das erwünschte, neue Ziel präzisieren. 2.2 Einordnung der Checklistenerweiterung Die Checklistenerweiterung ist im Grunde genommen nur eine Komponente eines gesuchten Gesamtsystems. Somit war der bestehende Entwurf unvollständig. Grund dafür war die fehlende Konzentration auf die umliegenden Anforderungen der Promotionsverwaltung. Der größte Teil der Aufmerksamkeit befasste sich mit der Checklistenerweiterung. Der erste Schritt zur Fortsetzung der Analyse war die Herauslösung des Vorlagensystems. Dieses war, wie im Großen Beleg [Hä14] beschrieben, eine Teilkomponente. Unter der Anlage A wird noch einmal das Ergebnis der vorherigen Arbeit dargestellt. Wie zu erkennen ist, hängen die Teilsegmente Checkliste und Konfiguration voneinander ab. Das bedeutet, dass eine korrekte Funktionalität nur gewährleistet ist, wenn beide vorhanden sind. Anders ist es mit dem dritten Segment Vorlagen, dieses könnte auch entfernt werden, dadurch wäre die Checkliste trotzdem aufrufbar, besitzt aber demzufolge keinen Inhalt. Dieses Vorgehen war notwendig, weil im Laufe der Entwicklung festgestellt wurde, dass es unpraktisch und einschränkend ist, die Vorlagen auf die Checklisten zu begrenzen. Außerdem stellte sich heraus, dass die konfigurierbaren Referenzen, die auf Vorlagen 6

15 2.3 Neuer Ansatz als Ideenskizze zeigen, zu grob analysiert und entworfen wurden. Es resultierte eine größere Erweiterung. Der Abschnitt 3 stellt diese Weiterentwicklung als Entwurfskonzept dar. 2.3 Neuer Ansatz als Ideenskizze Um das neue Ziel zu erreichen, wird das konfigurierbare System zuerst in grober Form beschrieben. Die daraus entstandenen Spezifikationen können genutzt werden, um einen neuen Entwurf zu erstellen. Parallel werden verschiedene Begriffe, die im System vorkommen, definiert. Das System sollte grundsätzlich eine Seitenverwaltung unterstützen, welche gleichzeitig die Navigation durch das System gewährleistet. Jeder Seite können mehrere Fenster zugeordnet werden. Insbesondere sind auch Bestätigungsfenster und Formularseiten gemeint. Die Definition 1 verdeutlicht die Komponente Fenster. Definition 1 Fenster Jeder konfigurierbaren Seite und jedem Checklisteneintrag können eine unbestimmte Anzahl an Fenstern zugeordnet werden, welche zuvor erstellt wurden. Jedes Fenster besteht dabei aus einer Liste von Referenzen. (Siehe Definition 2) Definition 1 Fenster Wie im Kapitel 1 beschrieben, sollte das System nur die promotionsrelevanten Daten abbilden und so einfach wie möglich verwalten können, um mit diesem Ziel eine komplexe Neugestaltung zu umgehen, wie beispielsweise bei dem Einpflegen einer neuen Promotionsordnung. Damit die Fenster flexibel zu gestalten sind und inhaltsunabhängig fungieren können, werden Referenzen benötigt. Der Begriff Referenz wird in Definition 2 vorgestellt. Das Vorlagenkonzept ist nicht neu, auch ein Content- Management-System 3 (kurz CMS) besitzt Vorlagen. Die hier besprochenen Vorlagen entsprechen einer vordefinierten Rolle, beispielweise eine Texterfassung. Sie können entweder einfach oder komplex sein, zusätzlich einem bestimmten Datentypen mit dazugehöriger Eingabe oder einer ganzen Struktur entsprechen. Es werden also Eingabefelder, Auswahlfelder, Tabellen, replizierende Vorlagen und viele weitere Vorlagen benötigt. Definition 2 Referenzen Referenzen beschreiben in diesem System einen Steckplatz für eine beliebige Vorlage. Eine Referenz kann aus mehreren Vorlagen bestehen, jedoch ist nur eine dazugehörige Namensbezeichnung vorhanden. Als Dokumentation in der Software kann jede Referenz um eine Hilfeangabe ergänzt werden. Definition 2 Referenzen 3 Siehe: Stand:

16 2 Konzeptvorbereitung/-ergänzung Insgesamt müssen diese Artefakte ohne Beschränkungen variabel zusammensetzbar sein. Die logische Richtigkeit ist vorerst nicht wichtig und wird im späteren Kapitel 6 behandelt. Die Steuerung und das Zusammenspiel unter den Fenstern und Referenzen mit den entsprechenden Vorlagen können nicht ohne Weiteres eingegeben bzw. trivial eingestellt werden. Um die damit verbundene Konfiguration gering zu halten, sollte eine Regelsprache weitere, fehlende Funktionalität ersetzen. Die Definition 3 charakterisiert diese Sprache. Definition 3 Regelsprache Die hier verwendete Regelsprache ist eine einfache, interne Skriptsprache, um verschiedene Anweisungen oder Kommandos bezüglich der Datenbearbeitung und - verarbeitung auszuführen. Darüber hinaus wird die Kommunikation unter den Fenstern ermöglicht, womit eine Kette von Anweisungen oder Datenerfassungen aufgebaut werden kann. Definition 3 Regelsprache Eine derartige Sprache sollte so einfach wie möglich gehalten werden, damit nicht nur ein Entwickler Anpassungen vornehmen kann. Ein beispielhafter, möglicher Befehl wäre das Versenden einer an eine bestimmte Person oder Rolle. Als größeres System neben der Seitenverwaltung existiert die Checklistenkonfiguration. Diese sollte gleichermaßen aus Seiten, Referenzen und Vorlagen bestehen. Wie oben bereits beschrieben, ist diese ab dem jetzigen Zeitpunkt nicht mehr mit dem Vorlagesystem verbunden und kann als eigenständige Komponente angesehen werden. Wie diese Komponenten zusammengesetzt werden, wird im Kapitel 3 beschrieben. Die Eigenschaften einer Checkliste sollten die Abbildung von Promotionsordnungen sein mit dem dazugehörigen Workflow. Der Workflow entspricht dem Ablauf einer vollständigen Datenerfassung einer Promotion ohne die eigentliche Dissertation. Diese kann höchstens als Dokument bzw. als Teilartefakt des Systems angesehen werden. Definition 4 Sichten Eine Sicht beschreibt in diesem System eine vordefinierte Charakterisierung von Vorlagen eines Fensters. Die Sicht untergliedert sich in verschiedenen Aspekten. Es existieren insgesamt drei Aspekte, die Sichtbarkeit, der Modus und die Rolle. Der Modus beschreibt den Typ, ob die Vorlage änderbar oder nur einsehbar ist. Die Rolle spiegelt die Abhängigkeit zu einem bestimmten Benutzer wieder. Im Konfigurationsbereich gibt es einen dritten Modus zur Verwaltung von Vorlagen, dieser ist in der Sichtkonfiguration nicht verfügbar. Definition 4 Sichten Eine weitere, benötigte Funktionalität ist die Unterstützung von verschiedenen Sichten pro Fenster. Jeder Sicht, dargelegt in Definition 4, sollte eine Benutzerrolle zugeordnet werden können oder gar Endgerät abhängig sein, wie zum Beispiel eine minimierte Sicht auf einem Smartphone. Mit den Sichten sollten zusätzlich eine ganze Ansicht für eine Benutzerrolle simuliert werden. Somit müsste ein Fenster nur einmal erstellt werden mit 8

17 2.4 Vorbereitung auf die Regelsprache den verschiedenen Sichten und Rechten, und jeder Benutzer hätte einen erlaubten, zugeschneiderten Zugriff. Manchmal kann es vorkommen, dass ein Eintrag zurückgesetzt werden muss, dabei soll der vorherige Wert, falls vorhanden, wieder hergestellt werden. Dieser Fall kann bei Abstimmungen eintreten. Einfache Funktionen, wie Hinzufügen, Bearbeiten und Löschen von Datensätzen werden vorausgesetzt und durchziehen das gesamte System. 2.4 Vorbereitung auf die Regelsprache Dieses Unterkapitel analysiert die Anforderungen der Regelsprache im Detail, vergleicht verschiedene, existierende Typen und schafft die Basis für das Regel-Controlling im Kapitel Aufgabe und Fallbeispiel Das Regel-Controlling hat die Aufgabe verschiedene Systemabläufe als Regeln abzubilden, um eine statische Softwareimplementierung zu vermeiden. Insbesondere kann aus diesem Grund eine flexible und transparente Systemanpassung erfolgen ohne das Durchlaufen von den konventionellen Stufen der Softwareentwicklung. Logische Fehler im Ablaufprozess können mit angemessenen Zeitaufwand, abgängig von der Komplexität, von jedem Fachanwender beseitigt werden. Die Probleme, welche hier gelöst werden sollen, sind die immer wiederkehrenden Veränderungen im Ablauf einer Promotion, beispielsweise durch Änderung der Ordnung. Im großen Beleg [Hä14] wurden diese in die Anforderung einbezogen, insbesondere auch die kleinen Unterschiede zwischen den Promotionsordnungen der Fakultäten. Die neusten Anforderungen beziehen sich auf die Rollenverwaltung und die Ergänzung um Erinnerungsnachrichten. Beide Forderungen sind im derzeitigen System nicht trivial umsetzbar, insbesondere ist die Rollenverwaltung statisch aufgebaut. Doch auf die Rollen wird an dieser Stelle nicht weiter eingegangen. Die Erinnerungsnachricht würde sich jedoch mit einer Regelverwaltung einfach ergänzen lassen. Diese angesprochenen Beispiele zeigen die Notwendigkeit von einer Regelsprache. Existierende Regeleinträge sind persistent und werden wiederholt ausgeführt, ein nachträglicher Auslöser zur Realisierung ist nicht erforderlich, wie es beispielweise bei Wiedervorlagen der Fall ist. Die Umsetzung einer Regelverwaltung kann in zwei Varianten erfolgen Ansatz 1: Skriptsprache Die erste Möglichkeit implementiert eine abgeschlossene Skriptsprache. Eine Skriptsprache verfügt nicht über alle Sprachelemente, wie es bei einer Programmiersprache der Fall ist. Variablen werden ohne Typdeklaration verwendet, die Speicherverwaltung im Hintergrund arbeitet automatisch und es bedarf keinem vollständigen Compiler. 9

18 2 Konzeptvorbereitung/-ergänzung Es können spezifische Konstrukte angeboten werden, die den Umfang der Skripte verkürzen. Ein so erstellter Interpreter würde den analysierten Code unmittelbar ausführen. Skriptsprachen können auch in komplexer Form umgesetzt werden. Einige Beispiele dafür wären Perl 4, PHP 5, Python 6 oder Ruby 7. Die Besonderheit dieser Sprachen ist die Konzipierung für Webanwendungen Ansatz 2: Business Rules Eine weitere Alternative ist der beschriebene Business Rules ( Geschäftsregeln ) Ansatz nach Schacher und Grässle [SG06]. Dieser widmet sich den Abläufen eines Geschäftes. Es können Prozesse definiert werden, die einen bestimmten Sachverhalt beschränken oder beschreiben. Das Listing 2.1 nennt eine Geschäftsregel. Eine Geschäftsregel unterliegt keinem Zwang und kann missachtet werden, jedoch hat das Konsequenzen für die Verantwortlichen eines Geschäftes. Deswegen ist eine Dokumentation notwendig, um letztendlich Widersprüche zu erkennen und die Vollständigkeit zu gewährleisten. Eine weitere Forderung ist die Automatisierung der Regeln durch Softwaresysteme. Somit unterliegt die Verwaltung den vorgegebenen Geschäftsregeln und können bei Bedarf unmittelbar verändert werden. Business Rules werden immer häufiger in den Produkten von größeren Firmen, wie Oracle, Microsoft oder IBM, verwendet. [SG06] Im Fall der Promotionsverwaltung ist die Realisierung per Implementierung gelöst, beispielweise befolgt die Checkliste der bisherigen Version einen vorgeschriebenen Ablauf. Falls ein Doktorand die Abgabefrist nicht einhält, muss eine neue Anmeldung durchgeführt werden. Listing 2.1 Beispiel: Geschäftsregel Schacher und Grässle [SG06, S. 123] beschreiben verschiedene Möglichkeiten um Geschäftsregeln umzusetzen. Im Folgenden soll ein Ansatz genannt werden: Eine Repräsentation der Regeln kann als formales Deutsch oder in einer anderen beliebigen Sprache erfolgen, wobei Bedingungen mit Anweisungen inklusive mathematischer Formeln formuliert werden können. Eine Erfassung für eine Regel kann in der Komplexität rasant zunehmen. Der Übergang zum Entwurf sieht die Anpassung der beschriebenen Darstellung vor. Für Bedingungen und Anweisungen werden englische Begriffe verwendet, welche oftmals prägnant den Sinn wiedergeben, wie if oder while. Außerdem werden die beschriebenen, spezifischen Konstrukte aus Unterkapitel als Regeln hinzugenommen. 4 Siehe: Stand: Siehe: Stand: Siehe: Stand: Siehe: Stand:

19 2.5 Fundament des Systems Es existiert eine große Anzahl von Business Rule Engines für unterschiedliche Plattformen und Umgebungen. Beispielsweise basiert die Engine USoft vom Hersteller NESS 8 auf ein relationales Datenbankschema. Regeln werden mit SQL-Statements erfasst und finden Verwendung für große Datenmengen. Andere Systeme verfügen darüber hinaus über eine grafische Modellierung zur Abbildung von Prozessen und sind aufwendiger in der Konfiguration Die bisherige Regelsprache Im großen Beleg [Hä14] wurde die einfache Regelsprache für die Checklistenverwaltung vorgestellt. Diese Sprache unterlag keinem Konzept, um eine schnelle und unkomplizierte Lösung zu erhalten. Es resultierte ein geringer Funktionalitätsumfang. Als Regeln werden nur einfache Bedingungen unterstützt, verschachtelte Klammern oder Anweisungen sind nicht möglich und es gibt keine Möglichkeit auf Verifizierung. Des Weiteren kann es bei komplexen Angaben zu Fehlinterpretationen kommen. Die Eingabe der Regeln ist umständlich und die Übersicht kann leicht verloren gehen. Durch das Arbeiten mit numerischen Bezeichner werden die übergreifenden Änderungen erschwert, da bereits mehr als 100 Einträge vorhanden sind. Ohne schriftliche Notiz ist die Konfiguration zeitintensiv Basis des Regel-Controllings Beide Varianten aus Kapitel und können als Basis der Regelsprache verwendet werden. Der erste Ansatz beschreibt eine allgemeingültige Sprache zur Erweiterung von Fähigkeiten einer Anwendung, verglichen mit der zweiten Variante wird eine formale Definition von Abläufen eines Geschäfts vorgenommen. Das Resultat der Implementierung unterscheidet sich kaum. Generell ist die Abgrenzung für die geplante Aufgabe schwierig, deswegen werden beide Ansätze als Basis verwendet, um eine gewünschte Regelsprache zu entwerfen. Der Entwurf dazu folgt im Unterkapitel Fundament des Systems Neben der beschriebenen Basis für das System, werden im Unterkapitel Alternativen vorgestellt, womit ebenfalls ein Fundament gebildet oder ein ganzes System umgesetzt werden kann Selbstentwickeltes Framework als Basisarchitektur Als Grundlage für das System wird ein eigenes Framework, basierend auf PHP, verwendet. Dieses unterstützt bereits ein Fenstersystem mit einer Rückkopplungsfunkti- 8 Siehe: Stand:

20 2 Konzeptvorbereitung/-ergänzung onalität. Jede Nachricht, die mit einem Fenster an das System gesendet wird, kann je nach einer bestimmten Interaktion des Benutzers, zielgerichtet ausgewertet werden. Des Weiteren wird die dynamische Seitenanpassung unterstützt, somit ist ein ständiges Neuladen der Seite unnötig und es werden nur die veränderten Inhalte aktualisiert. Dieses Framework wurde in den letzten drei Jahren auf die Bedürfnisse der jetzigen Promotionsverwaltung ausgerichtet. Durch die oben genannten, zur Verfügung stehenden Erweiterungen ist ein Grundgerüst für die Re-Implementierung des neuen Systems entstanden. Vorhandene Frameworks hätten diesen Funktionsumfang nicht vollkommen unterstützt und es wären weitere Frameworks oder Teilfunktionserweiterungen notwendig gewesen, womit wieder eine individuelle Anpassung erforderlich gewesen wäre. Das hier verwendete Framework entspricht den Ebenen Infrastruktur und Domäne, welche im Kapitel 3.1 ausführlicher als Entwurf betrachtet werden. Im Allgemeinen werden dabei Funktionalitäten gekapselt, welche bei einer Software immer gleich bleiben. Durch entsprechende Slots können Erweiterungen vorgenommen und benutzerdefiniert angepasst werden. Die Instantiierung wird durch die oberen Schichten vorgenommen. Der tatsächliche Aufbau erfolgt durch eine Ergänzung um anwendungsspezifische Pakete Alternative Basisarchitekturen Eine alternative Umsetzungsmöglichkeit ist die Verwendung eines CMS. Ein CMS ist jedoch für die gesuchte Form ungeeignet, sondern vielmehr für statische bis dynamische, personalisierte Webinhalte gedacht. Diese Verwaltung von Inhalten kann auf mehrere Benutzer verteilt sein. Dabei müssen entsprechende Zugriffsrechte für eine geordnete Durchführung sorgen. Eine gute Website lässt sich aus zahlreichen Plug-Ins einfach bis aufwendig zusammensetzen, je nach Umfang des angestrebten Zieles. Es werden Grundbausteine geliefert, wie Seiten- und Benutzerverwaltung. Das entspricht in erster Linie einen Teil des verwendeten Frameworks, jedoch hätte eine gezielte Implementierungsanpassung der Fenster erfolgen müssen. Das Adaptieren wäre zwar möglich, hätte aber mehrere, verschiedene Konfigurationsseiten zur Folge. Die vollständige Umsetzung aus einem Entwicklungsprozess ist immer eleganter, als das Zusammenführen von vielen verschiedenen Systemen. Dazu kommt ein meist veralteter Kern, der bei einer Überarbeitung und einem verbundenen Update in der Zukunft zur aufwendigen Anpassung des aufgesetzten Systems führt. Weiterhin hätte die Funktionalität für eine spezifische Anpassung an den Seiten und an den Fenstern gefehlt. Diese steht, wie hier verwendet, nicht ohne Weiteres zur Verfügung. Die Referenz- und Vorlagenverwaltung wären aufwendiger geworden, da die Implementierungsvorschriften der CMS befolgt werden müssen. Resultierend müsste also ein komplexes System auf diese Inhaltsverwaltung als Plug-in aufgesetzt werden. Auf der anderen Seite wird ein CMS ständig weiterentwickelt und verbessert, hingegen könnten entstandene Sicherheitslücken bis zur Behebung ausgenutzt werden. Letztlich bleibt ein CMS der Grundbaustein für eine Website mit einer fortgeschrittenen 12

21 2.5 Fundament des Systems Möglichkeit zur Konfigurierung von Seiteninhalten, um als Benutzer eine Eingabe von HTML-Konstrukten zu umgehen (Web 2.0 9, beispielsweise: Wiki oder Blog). Ein Beispiel für eine solche Verwaltung wäre TYPO3 CMS. Dieses System bietet alles, was ein standardisiertes CMS besitzen muss [BHS13]. Ergänzend existiert eine Skriptsprache namens TypoScript für die inhaltliche Anpassung. Dadurch wird es auch ermöglicht Seiten ohne Vorlagen auszugeben. CMS-Systeme arbeiten mit Vorlagedateien, die im wesentlichen nur die Struktur besitzen. Für eine Implementierung, der hier angestrebten Umsetzung eines Promotionsverwaltungssystem, ist TYPO3 CMS deswegen ungeeignet, da die vielen Automatisierungen als Plug-ins ergänzt werden müssten. TYPO3 CMS wäre ein geeigneter Grundbaustein für ein statisches System, wie Docata. In dem Fall müsste nur ein Wiedervorlagensystem hinzugefügt werden. Die Übertragung der einzelnen Seiten wäre problemlos möglich. Es scheitert aber an der Eintragung von Datensätze in Tabellen. Ein CMS ist dafür nicht vollständig ausgelegt, sondern für eine ständige Anpassung durch den Autor der Seite bzw. dem Administrator. Alternativ müsste auch hier eine Erweiterung entwickelt werden. Darauf aufsetzende Systeme wären Onlineshops. Beispielweise ist Magento 10 eine oft verwendete Software, die in einem CMS eingepflegt werden kann. Derartige Anwendungen sind auf ein Konzept so stark angepasst, dass abweichende Systeme damit nicht problemlos umgesetzt werden können. Eine weitere Alternative entsteht an dieser Stelle durch eine Ergänzung eines Workflow- Management-Systems 11, daraus ergibt sich ein Enterprise-Content-Management- System 12 bis hin zu einem Business-Process-Mangement. Diese beiden Systeme wären zumindest in der Lage das gesuchte Informationssystem abzubilden. Der Nachteil liegt in der Komplexität und der aufwendigen Konfiguration durch einen oder mehrere Entwickler für die benötigte Abbildung des Promotionsablaufprozesses. Domänenbezogene Inhalte, wie ein Abstimmungssystem mit automatisierter Auswertung würden die Komplexität weiter ansteigen lassen. Eine schnelle Änderung des Ablaufs ist somit für eine Anwenderperson nicht möglich. Etablierte Systeme sind meistens dazu nicht kostenfrei zu erwerben. Diese Systeme verwenden meistens eine komplexe Workflow- Sprache, welche ein normaler Nutzer ohne Vorkenntnisse nicht bedienen kann. Generell sind diese Varianten für die Abläufe von größeren Firmen gedacht. Ein Promotionsverwaltungssystem ist eine sehr spezifische Anwendung mit einer begrenzten Anzahl an Nutzern. Lediglich um die 100 Einrichtungen haben in Deutschland das Promotionsrecht, wobei einige Einrichtungen zu klein sind, um ein derartiges, komplexes System einzuführen. Weiterhin wurden solche System über viele Jahre hinweg entwickelt und erweitert, wodurch eine schnelle Einarbeitung zusätzlich erschwert bis unmöglich wird. Ein konkretes Beispiel für ein Enterprise-Content-Management-System ist das CMS G3 13. Dieses System ist modular aufgebaut und verfügt über zahlreiche Zusatzmodule. 9 Siehe: Stand: Siehe: Stand: Siehe: Funktion, Stand: Siehe: Definition, Stand: Siehe: Stand:

22 2 Konzeptvorbereitung/-ergänzung Aber auch hier zeigt sich eine fehlende Erweiterung, um eine Art Abstimmung, wie sie bereits im vorherigen System vorhanden ist, umzusetzen. CMS G3 besitzt bespielweise eine Dokumentenverwaltung, eine Benutzerverwaltung und die Basisverwaltung zur Inhaltspflege. Ein Modul zur Konfigurierung von Geschäftsregeln in der Komplexität, wie sie benötigt wird, steht nicht zur Verfügung. Hierbei sei additional erwähnt, dass CMS G3 auf ColdFusion 14 basiert. Es ist prinzipiell unerheblich, welche webbasierte Skriptsprache für ein Informationssystem eingesetzt wird. Viele Skriptsprachen unterscheiden sich in der Ausführung hauptsächlich im Syntax. Das hier aufgezeigte Beispiel verwendet eine Eigenentwicklung von dem Software-Hersteller Adobe Systems und ist nicht öffentlich zugänglich, verglichen mit den oben genannten Skriptsprachen. 14 Siehe: Stand:

23 3 Implementierungskonzept Aus den oben beschriebenen Teilprodukten erfolgt nun die Erarbeitung eines Gesamtsystems. An dieser Stelle wird ein wichtiger Schritt ausgeführt, nämlich das Zusammenführen der Bausteine zu einem Bauplan für die darauffolgende Implementierung. Dieser Abschnitt soll nicht nur den Systementwurf bzw. die Architektur beschreiben, sondern auch bereits zum Teil die Funktionalität hervorheben. Der Datenbankentwurf, auf den nicht näher eingegangen wird, ist von der Struktur vergleichbar zum System. Ein Teilausschnitt des Datenbankentwurfes kann aus der Anlage C entnommen werden. Die Einführung und die Erklärung der Datenbanktabellen mit der dazugehörigen Architekturstruktur würden den Rahmen dieser Arbeit sprengen. Die Architektur wird in den anschließenden Abschnitten bereits als Komponenten, Datenfluss oder an Hand von Beispielen detailliert dargestellt. Mit dem Ergebnis des Entwurfs soll der Prototyp zur funktionsfähigen Software weiterentwickeltet werden. Ein kurzer Blick auf ein mögliches Serverkonzept erlaubt die Einsicht in eine vorangeschrittene Systemverteilung. Mit einer Auswertung wird dieses Kapitel beendet. Die verwendeten Klassendiagramme, welche in den nachfolgenden Kapiteln Verwendung finden, wurden nach der Definition von Entwurfsklassendiagrammen nach [St05, S ] erarbeitet. Der Unterschied zu Analysediagrammen liegt in der Vollständigkeit. In der Analyse wird auf beispielsweise spezielle Sichtbarkeiten von Attributen verzichtet. Der Entwurf betrachtet die Art und Weise genauer, als sich nur auf Anforderungen zu stützen, wie die Analyse. Als Hinweis sei angegeben, dass die Entwürfe mit ihren Attributen und Methoden unvollständig sind. Eine Angabe von allen vorhandenen Attributen und Methoden hätte zur Folge, dass die Klassendiagramme für das Beschreiben unübersichtlich und für das Einfügen zu umfangreich werden. Die wichtigsten Informationen sind jedoch vorhanden. Hauptsächlich wurde auf Hilfsfunktionen und allgemeine Controller-Pakete verzichtet. 3.1 Gesamtüberblick Die vollständige Systemarchitektur hat sich im Gegensatz zum vorherigen System stark erweitert. In der Anlage B findet sich zum Vergleich die Vorgängerarchitektur und in der Abbildung 3.1 die neue Systemarchitektur. Das grundlegende Schema als Schichtenmodell blieb bestehen. Als weitere Möglichkeit wäre das Role Object Pattern in Frage gekommen. Dieses erlaubt es ebenso mehrere Schichten anzulegen, jedoch mit verschiedenen Rollen. Diese Art Rolle darf nicht mit einer Rolle als Benutzer an sich verwechselt werden, wie sie später in diesem Kapitel erläutert wird. Grundsätzlich kann eine Rolle jegliche Form annehmen, solange diese über einen endlichen Zeitraum gespielt wird. Hier kann auf den Rollentyp und den natürlichen Typ verwiesen werden, um die Unterschiede zu verdeutlichen. [Bä97] Letztendlich war die Entwicklung zu weit voran geschritten, um das Fundament durch Refactoring zu restrukturieren [Mc04, Seite 577]. Auf die Methode Refactoring wird im Umsetzungsabschnitt noch tiefer eingegangen. 15

24 3 Implementierungskonzept Abbildung 3.1 Vollständige Systemarchitektur 16

25 3.1 Gesamtüberblick Ingesamt wurde in jeder Entwicklungsstufe der agile Ansatz verfolgt, um eine schnelle und präzise Lösung zu erhalten. Das volle Potenzial dieser Softwareentwicklung kann sich jedoch erst im Team entfalten. [HRS09] Die verwendeten Schichten Infrastruktur, Domäne, Anwendung und Nutzerschnittstelle blieben unverändert. Nur der interne Aufbau jeder Schicht wurde weiterentwickelt und auf die neuen und komplexeren Anforderungen angepasst. Die folgenden Absätze stellen jede Schicht vor und erfassen den Inhalt. Die Infrastruktur wird ein neues Sprachpaket erhalten, welches auf XML-Dateien beruht. Hierbei gibt es die Möglichkeit verschiedene Dateien anzulegen, um die Übersicht zu bewahren und die Ladezeit zu mindern. Es wird also nur der Sprachteil geladen, der wirklich benötigt wird, und um eine einfache Verwaltung von mehreren Sprachen zu gewährleisten. Zu einer Sprache gehören also immer zwei Dateien bei Verwendung von Deutsch und Englisch. Als Datenbank wird weiterhin MySQL verwendet mit dem Unterschied, dass der Zugriff weiter vereinfacht wurde. Unter den Einzelkomponenten der Schichten wird dazu detaillierter eingegangen. In der nächsten Ebene, die Domäne, können nun weitere Pakete gefunden werden, unter anderem die Sprachverwaltung, die Kontrollverwaltung und die Benutzerverwaltung. Alle Verwaltungen stellen Funktionalitäten für die Anwendungsschicht zur Verfügung. Diese Schicht hat die Möglichkeit die Daten aus der Infrastruktur zu verarbeiten. Die Anwendung hat keinen direkten Zugriff auf beispielsweise die Datenbank. Das zuvor angesprochene Box- / Callback-System entspricht dem Kontrollverwaltungspaket, wie es in der Abbildung 3.1 eingezeichnet ist. Diese Schicht spiegelt das angesprochene Framework aus dem Kapitel wider. Die Infrastruktur gehört zwar dazu, diese beinhaltet aber letztendlich nur die Daten. Relevant bleibt die Schicht für die Anwendung. Diese bildet die eigentliche Logik des Systems ab. Diese Schicht wird in den nächsten Abschnitten besonders betrachtet. Letztendlich werden alle bisherigen Pakete restrukturiert oder entfernt. Eine Wiederverwendung ist nur von einigen Pakten unter Einschränkung möglich. Das Checklistensystem dient nur noch für den eigentlichen Zweck einer Checkliste, Einträge abhaken oder als unerledigt kennzeichnen, darüber hinaus für das Laden der Checkliste. In der früheren Version beinhaltete das Paket für die Checkliste auch die Regelsprache. Wie in der Abbildung 3.1 zu erkennen ist, sind viele neue Pakete hinzugekommen, darunter die allgemeine Konfiguration, die Fensterkonfiguration, das Daten-Controlling, das Rollen-Controlling, das Vorlagen-Controlling, das Regel-Controlling, das Cronjob- Controlling und weitere Pakete. Was die Aufgaben der einzelnen Komponenten sind, wird in den nächsten Abschnitten hervorgehoben. Zusätzlich soll die Abbildung 3.1 auch die wichtigsten Abhängigkeiten zeigen. Zum Beispiel verwendet das Regel-Controlling die Pakete für Abstimmung und Befehle. Wobei das Abstimmungspaket nicht mehr den gesamten Abstimmungsvorgang regelt, sondern nur noch spezielle Funktionalitäten liefern soll, um das System hinter der Regelsprache im Umfang zu minimieren. 17

26 3 Implementierungskonzept Die oberste Schicht ist die Nutzerschnittstelle. Diese wurde in zwei Teile getrennt, die Standard-Benutzerschnittstelle und die mobile Benutzerschnittstelle. Die verschiedenen Nutzerpakete, werden nicht mehr fest implementiert, sondern generieren sich aus den konfigurierten Sichten aus der Anwendungsebene. Das hat den Vorteil, dass zur Laufzeit neue Sichten erstellt werden können und somit zusätzlich Variabilität und Erweiterbarkeit hinzugefügt wird. Der Einblick in die Systemarchitektur lässt auf eine komplexe Anwendung schließen. Hierbei soll erwähnt werden, dass die konfigurierten Nutzersysteme bzw. Promotionsverwaltungen in der Bedienung einfach gehalten werden. Die Konfiguration an sich erfordert weitreichende und detaillierte Funktionen. Ein Enterprise-Content- Management-System ist nicht trivial erstellbar und erfordert einen gewissen Aufwand, um später, bei der Abbildung und Verwaltung verschiedener Workflows, Kosten einzusparen. Wie groß die Anstrengung im Fall einer Promotionsverwaltung ausfallen wird, betrachtet das Kapitel 5. Zuerst muss das endgültige System erarbeitet werden, womit eine Basis für die Eingabe eines Workflows geschaffen wird. 3.2 Komponente: Datenbankverwaltung Zunächst wird ein grundlegender Baustein des Entwurfs erläutert. Dieser gehört nicht zur Anwendung, sondern zur Domäne. Die Datenbankverwaltung spielt im System nur noch eine untergeordnete Rolle, da durch den hier gezeigten Entwurf in Abbildung 3.2, der Datenzugriff sehr vereinfacht wird. Abbildung 3.2 Datenbankverwaltung Als erstes wird ein allgemeines Schema durch ein Interface CSQLSchemaDefinition festgelegt. Dieses Interface dient für verschiedene Datenbankklassen als Beschreibung für den Aufbau. Somit hat jede Datenbankklasse, die eine spezifische Art von Datenbank 18

27 3.3 Komponente: Allgemeine Konfiguration verwaltet, die gleiche Struktur. In diesem Fall sind CMySQL5 und CMySQLi vorhanden. Durch eine Klasse CDB, die durch eine Fabrikklasse charakterisiert ist, kann nun eine Datenbankverbindung aufgebaut werden. Das verwendete Entwurfsmuster ist eine Factory Method [Ga94, S. 107]. Dieses Muster definiert eine Schnittstelle, um verschiedene Objekte zu erstellen. Jedoch entscheidet eine Unterklasse, welche Instanz schließlich verwendet werden soll. Der Vorteil hierbei ist, dass ohne Probleme neue Produkte, also Datenbankklassen, hinzugefügt werden können. In dem hier gezeigten Fall handelt es sich um einen Sonderfall, die Klasse CDB ruft das Objekt durch Parametrisierung auf. Listing 3.1 Datenbankfunktion Die nun zur Verfügung stehende, abstrakte Klasse CDBAccessControl benutzt die initialisierte Datenbankverbindung und definiert verschiedene Datenbankfunktionalitäten. Das heißt, dass es nicht mehr nötig ist, konkreten SQL-Code einzugeben, sondern nur den Datenbanknamen, die Spaltennamen und die auszuführende Option, wie als Beispiel im Listing 3.1, Zeile neun, gezeigt. Jede Klasse im System kann von dieser Klasse erben und besitzt sofort einfachen Zugriff auf die Datenbank. Des Weiteren sind zwei spezielle Methoden vorhanden, settransactionbegin() und settransactioncommit(). Zusammen ermöglichen beide eine geschlossene, zusammenhängende Datenbankanfrage. Falls ein Fehler generiert wurde, wird die komplette Anfrage zurückgesetzt. Zu beachten wäre, dass dieses Merkmal klassenübergreifend wirkt durch interne, statisch verwendete Attribute. Leider werden keine komplexen Datenbankanfragen von dieser Klasse unterstützt, dafür ist weiterhin die Methode query() vorhanden. Da diese Art Anfragen nur selten vorkommen, ist bisher eine Implementierung zur Vereinfachung nicht notwendig gewesen. 3.3 Komponente: Allgemeine Konfiguration Um dem System mehr Variabilität und Erweiterbarkeit zuzusichern, müssen sowohl mehrere Checklisten, als auch Seiten angelegt werden können. Der Entwurf in der Abbildung 3.3 erlaubt es sogar mehrere Systeme zu verwalten, indem eine neue Hauptkategorie für Seiten erstellt wird. 19

28 3 Implementierungskonzept Abbildung 3.3 Allgemeine Konfiguration Im Grunde genommen sind Checklisten und Seiten vergleichbar aufgebaut. Der praktische Gedanke dahinter war, die Sprachverwaltung und das Vorlagen-Controlling. Beide Pakete basieren auf den gleichen Datenfluss mit der Struktur, wie hier dargestellt. Die oberste Klasse IList definiert das Schema der Liste. Es werden entweder CCL_Config für Checklisten oder CPA_Config für Seitenlisten abgeleitet, wobei eine 20

29 3.4 Komponente: Checkliste Seitenliste ein System darstellt. Hierbei spielt, wie auch in den folgenden Einordnungen, der Bezeichner Identifier die Rolle für einen eindeutigen Zugriff auf die Datenbank und auf die Sprachdatei. Eine Liste spiegelt nämlich gleichzeitig eine Sprachdatei wieder. Diese wird jeweils simultan erstellt. Als nächste Einordnung folgt das Klasseninterface IGroup, welche eine Gruppierung von Einträgen bzw. Unterkategorien von Listen repräsentiert. Die Klassen CCL_Config_Group und CPA_Config_Group können als optional eingestuft werden. Dennoch ist für den Funktionsablauf das Erstellen und das Vorhandensein von Gruppen eine Voraussetzung. Diese Sektionen dienen vor allem als bessere Übersicht und Darstellung von Checklisten und Sprachdateien. Sprachdateien können größere Ausmaße annehmen, eine Unterkategorie erleichtert die Zuordnung von Wörtern. Eine Gruppe ist genau einer Liste zugeordnet. Die unterste Klasse IGroupEntries mit den Ableitungen CCL_Config_Group_Entries und CPA_Config_Group_Entries haben eine wichtigere Rolle. Diese spiegeln einen Checklisteneintrag bzw. eine Seite wieder. Ein Checklisteneintrag ist zusätzlich mit dem Checklistenpaket verbunden. Dabei kann der Status des Eintrages in der Checkliste in der Datenbank verwaltet werden. Jeder Eintrag kennt wiederum seine Gruppe. Bei dieser Variante ist die Erzeugung von Listen einfacher, jedoch ist es schwieriger von einem Eintrag auf andere Einträge zu schließen, da zunächst die ID der Gruppe benötigt wird. Ein Seiteneintrag benutzt gleichzeitig eine weitere Klasse CPA_Pages, diese ist für die Erstellung der tatsächlichen Datei verantwortlich. Dabei wird eine Standardseite erzeugt, welche die Basis für Fenster und Vorlagen beinhaltet. Nachdem eine Seite erstellt wurde, kann diese ohne weiteren Aufwand konfiguriert werden. Die Klasse CPA_Pages kann zudem Dateien erzeugen, die dem Entwickler vordefinierte Vorlagen bereitstellen, ergo wird die Entwicklungszeit reduziert. Ein spezielles Entwurfsmuster wurde an dieser Stelle nicht benutzt. Die Generalisierung der Klassen mit einem vorgeschriebenen Interface ist angemessen, um den Aufbau zu explizieren. In einem vorangegangenen Entwurf gab es keine Seitenlisten und die Checklisten waren fest mit den Fenstereinträgen verbunden. Diese Ausführung schränkte die Variabilität ein, wobei letztlich das aktuelle Modell resultierte. 3.4 Komponente: Checkliste Bevor auf die Konfiguration der Fenster eingegangen wird, ist noch einmal das Checklistensystem zu betrachten. Das Checklistensystem beinhaltet neben den oben beschriebenen Aufgaben auch ein spezifisches Protokoll, welches ausschließlich die Änderungen an der Checkliste verwaltet, und eine Organisation für Abhängigkeiten. Die Abbildung 3.4 zeigt alle drei Teilkomponenten. Auch hier kam das Entwurfsmuster Factory Method [Ga94, S. 107] zum Einsatz. Dabei spiegelt das Interface IEntry die Produktdefinition und die Klasse CCLEntry das konkrete Produkt wider. Eine abstrakte Fabrik namens IList gestaltet den Aufbau der 21