Entwicklung einer Webapplikationzur Unterstützung der Lehr- und Stundenplanung

BachelorarbeitEntwicklung einer Webapplikation zur Untersttzung der Lehr- und StundenplanungZur Erlangung des akademischen Grades eines Bachelor of Science - Informatik-

Fakultt Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl. Math. Gerd Recknagel eingereicht von: Christoph Schmidt Matr.-Nr. 281094 Leitenstrae 8 97795 Schnderling Schmalkalden, den 09.08.2011

Inhaltsverzeichnis1 Einfhrung 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Das SPIRIT-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Grundlagenbetrachtung 2.1 Scala . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 OOP versus funktionale Programmierung 2.1.2 Besonderheiten . . . . . . . . . . . . . . 2.2 Lift . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Architektur . . . . . . . . . . . . . . . . 2.2.2 Lift Core und Lift Web . . . . . . . . . . 2.2.3 Persistenz . . . . . . . . . . . . . . . . . 2.2.4 Projektstruktur . . . . . . . . . . . . . . 2.2.5 Konguration . . . . . . . . . . . . . . . 3 Analyse 3.1 Zielsystem . . . . . . . . . . . . . . 3.2 Benutzeranalyse . . . . . . . . . . . 3.3 Anwendungsflle . . . . . . . . . . 3.3.1 Lehrplanungsprozess . . . . 3.3.2 Arbeitszeiterfassungsprozess 4 Design 4.1 Drei-Schichten-Architektur 4.2 Vier-Schichten-Architektur 4.3 Softwarekomponenten . . . 4.4 Konkretes Design . . . . . 4.4.1 Datenhaltung . . . 4.4.2 Anwendungskern . 1 1 2 2 4 4 4 5 9 9 11 13 14 15 17 17 17 18 19 20 21 21 21 21 22 22 25 29 29 29 30 31 31 32 33

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Implementierung 5.1 Entwicklungsumgebung und Buildtools 5.1.1 IntelliJ . . . . . . . . . . . . . . 5.1.2 Simple-Build-Tool . . . . . . . . 5.2 Men und Zugriskontrolle . . . . . . . 5.2.1 FhS-LDAP-Module . . . . . . . 5.2.2 SiteMap . . . . . . . . . . . . . 5.3 Persistenz und Transformation . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Christoph Schmidt

II

Inhaltsverzeichnis 5.4

Fachhochschule Schmalkalden SS 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 36 37 37 40 43 45 47 49

5.5 5.6

Lehrveranstaltungsverwaltung und Planung . . . 5.4.1 Template Method-Muster . . . . . . . . . 5.4.2 Umsetzung des Template Method-Musters 5.4.3 Planungsprozess . . . . . . . . . . . . . . . Arbeitszeitverwaltung . . . . . . . . . . . . . . . . Testflle . . . . . . . . . . . . . . . . . . . . . . .

6 Fazit und Ausblick Literaturverzeichnis Eidesstattliche Erklrung

Christoph Schmidt

III

1 EinfhrungDiese Arbeit beschftigt sich mit der Implementierung einer Web-Anwendung zur Untersttzung der Lehr- und Stundenplanung an der Fachhochschule Schmalkalden, welche auf Scala 1 und Lift 2 basieren soll. Fr das Verstndnis der Arbeit werden Kenntnisse in Scala vorausgesetzt.

1.1 MotivationIn den vergangenen Jahren hat sich das Internet stark weiterentwickelt. Vom ursprnglichen Gedanken wissenschaftliche Dokumente auszutauschen, spricht heute kaum noch jemand. Hrt man heute Menschen ber das Internet sprechen, dreht sich alles um soziale Netzwerke, Blogs, Wikis und Podcasts. Der Ernder des Internets, Tim Berners-Lee, uert sich folgendermaen ber seine Erndung: The web is more a social creation than a technical one. I designed it for a social eect - to help people work together - and not as a technical toy. [Gre08] Dabei lsst sich noch ein weiterer Trend beobachten. Anwendungen, die frher auf Desktop-Computern installiert waren, verlagern sich immer mehr in das Internet und bieten eine Mglichkeit interaktiv an Projekten zu arbeiten, wie es vorher nur schwer mglich war. Ein Beispiel hierfr ist der von Google Inc. angebotene Dienst Google Docs. Mit diesem ist es mglich Prsentationen oder Textdokumente zu erstellen, welche von mehren Benutzern gemeinsam bearbeitet werden knnen. Dabei erinnert das Arbeiten stark an herkmmliche Desktop-Anwendungen. Auch die dafr bentigten Technologien haben sich in den letzten Jahren stark weiterentwickelt. Gerade im Bereich der Programmierung sind weitere Trends erkennbar. Es sind neue Sprachen entstanden, die die Objektorientierung mit Konzepten der funktionalen Programmierung vereinen. Auch das European Research Council 3 erkannte diesen Trend und frderte die Weiterentwicklung der Sprache Scala mit einem Betrag in Hhe von 2,3 Millionen Euro [Ano11]. Im Scala-Umfeld ist das Web-Framework Lift entstanden, welches im Vergleich zu anderen Frameworks seiner Art die meisten der Top 10 Sicherheitslcken, welche von der OWASP 4 herausgegeben wurde, wie Injection 5 oder Cross-Site Scripting 6 von vornherein ausschliet [Pol11a].1 2

Scala ist eine objekt-funktionale Programmiersprache. Lift ist ein in Scala programmiertes Web-Framework. 3 http://erc.europa.eu/ 4 OWASP steht fr Open Web Application Security Project. 5 Injection bezeichnet das Ausnutzen einer Sicherheitslcke in Verbindung mit einer Datenbank. 6 Cross-Site Scripting ist eine Sicherheitslcke bei der es mglich ist schadhaften Quellcode durch Formulareingaben in Webseiten zu platzieren.

Christoph Schmidt

Seite 1 von 49

1. Einfhrung

Fachhochschule Schmalkalden SS 2011

1.2 ZielsetzungWie einfhrend erwhnt ist das Ziel dieser Arbeit die Entwicklung einer WebAnwendung mit dem Namen PlanningWeb zur Untersttzung der Lehr- und Stundenplanung. Eine der Hauptaufgaben besteht darin, eine gemeinsame Plattform fr die Planung des Curriculums und Stundenplanung zu schaen, um den Arbeitsaufwand zu minimieren. Die fr diese Aufgaben bisher eingesetzten Programme liegen als reine DesktopAnwendung vor, welche auf Basis der deklarativen Sprache Prolog implementiert wurden. Allerdings knnen diese die ber die Jahre gewachsenen Anforderungen nicht mehr im vollen Mae erfllen. Darber hinaus werden die bislang eingesetzten Programme von neueren Windows-Versionen wie Windows 7 nicht mehr untersttzt, was fr die Zukunft mit einer internetfhigen Version vermieden werden soll. Um dies zu erreichen, sollen die Mglichkeiten der Sprache Scala und im speziellen die des Lift-Frameworks untersucht werden. Dazu kommt Scala in der Version 2.8.1 und Lift in der Version 2.3 zum Einsatz. Im Bereich Datenspeicherung ist zu untersuchen, wie eine datenbankunabhnige Speicherung erzielt werden kann, um sich auch hier nicht zu stark an ein Datenbank-Produkt zu binden. Fr die Darstellung der einzelnen Dialoge sollen herkmmliche Elemente wie Textfelder, Check-Boxen und Buttons eingesetzt werden. Fr die grasche Darstellung wird weitestgehend das Standard-CSS des Frameworks verwendet, da dies nicht Bestandteil der Arbeit ist.

1.3 Das SPIRIT-ProjektDie hier durchgefhrte Arbeit ndet ihm Rahmen des SPIRIT-Projekts der Fachhochschule Schmalkalden an der Fakultt Informatik statt. Dieses Projekt beschftigt sich mit der Neuimplementierung der Stundenplanungstools sowie dazugehriger Applikationen. Abbildung 1.1: SPIRIT-Projekt

Christoph Schmidt

Seite 2 von 49

1. Einfhrung


Abbildung 1.1 zeigt eine grobe Strukturbersicht der einzelnen Projekte und ihr Zusammenspiel. Das EmployeeWeb wird, genau wie dieses Projekt, mit Scala und Lift realisiert. Es dient dazu Dozenten eine Mglichkeit zu geben, Informationen, die die Studierenden betreen, in Spirit einzustellen. Diese Informationen werden den Studierenden ber das StudWeb zugnglich gemacht, wobei der Datenaustausch der Anwendungen ber den zentralen Datenbank-Service realisiert wird. Da sich die Nutzer des EmployeeWeb mit denen des PlanningWebs berschneiden und beide die gleichen Basistechnologien nutzen, ist fr die Zukunft geplant beide Applikationen in einer zu vereinen. Weiterfhrende Informationen zu diesem Projekt sind auf der Projektseite 7 oder auf Github8 zu nden.

7 8

http://pads.fh-schmalkalden.de/spirit.html https://github.com/spirit-fhs

Christoph Schmidt

Seite 3 von 49

2 GrundlagenbetrachtungIn diesem Kapitel wird kurz die Sprache Scala und das Lift-Framework vorgestellt. Zu Beginn wird auf die Entstehungsgeschichte von Scala eingegangen. Im Anschluss wird kurz die objektorientierte Programmierung der funktionalen Programmierung gegenbergestellt um darauf aufbauend die Besonderheiten der Sprache darzustellen. Nachdem Scala ausreichend vorgestellt wurde, wird auf das Lift-Framework eingegangen. Im Zuge dessen wird auch die Architektur des Frameworks untersucht.

2.1 ScalaDer Startschuss fr Scala el 2001 an der cole polytechnique fdrale de Lausanne in der Schweiz unter der Leitung von Professor Martin Odersky. 2003 wurde das erste Release verentlicht. Anschlieend erschien im Jahr 2006 die Version 2.0 und im Jahr 2010 Version 2.8 [Bra10, S. 1]. Derzeit ist Scala in der aktuellen Version 2.9 verfgbar. Vor der Entwicklung von Scala arbeitete Martin Odersky bereits an einer Sprache, die die Objektorientierung mit Konzepten der funktionalen Programmierung vereinen sollte. Es entstand Funnel 1 . Diese Sprache war aus Sicht eines Sprachentwicklers sehr rein. Sie besa lediglich ein paar primitive Spracheigenschaften. Fast alles, einschlielich Klassen, wurde durch Bibliotheken realisiert. Es stellte sich allerdings heraus, das eine Sprache nur dann akzeptiert wird, wenn sie eine groe Anzahl an Standard Bibliotheken bereitstellt. Aus den Ideen von Funnel entstand schlielich die Sprache Scala, wobei der Fokus bei ihr auf die Zusammenarbeit mit Standard-Plattformen wie Java gelegt wurde [Ode08].

2.1.1 OOP versus funktionale ProgrammierungDer in der Mathematik verwendete Begri einer Funktion spielt in der funktionalen Programmierung eine zentrale Rolle, da diese auf dem dort verwendeten Begri basiert. Die Eingabewerte stellen dabei den Denitionsbereich einer Funktion dar. Die Funktion wiederum bildet diese auf Rckgabewerte, welche dem Wertebereich entsprechen, eindeutig ab [PH06, S. 11]. Daraus folgt, dass Funktionen die immer mit dem gleichen Wert aufgerufen werden auch immer das selbe Resultat als Wert zurckgeben. Ein weiterer elementarer Bestandteil von funktionalen Sprachen sind Funktionen hherer Ordnung. Darunter versteht man Funktionen, welche als Eingabeparameter

1

http://lampwww.ep.ch/funnel/

Christoph Schmidt

Seite 4 von 49

2. Grundlagenbetrachtung


selbst wiederum Funktionen erwarten, wodurch letztlich ein Groteil an Produktivitt dieses Programmierparadigmas erzielt wird [PH06, S. 23 f.]. In diesem Zusammenhang taucht hug der Begri der anonymen Funktionen auf. Diese werden oft als Argumente fr Funktionen hherer Ordnung eingesetzt. Sie knnen deshalb direkt aufgeschrieben werden, ohne ihnen eine Bezeichnung zu geben [PH06, S. 14]. Im Gegensatz zur funktionalen Programmierung steht in der objektorientierten Programmierung der Objektbegri im Vordergrund. Ein Objekt reprsentiert in diesem Zusammenhang ein eindeutiges Exemplar von Dingen, wie beispielsweise ein Auto. Objekte besitzen Eigenschaften bzw. Attribute sowie ein bestimmtes Verhalten, was durch eine Anzahl an Methoden ausgedrckt wird [Hom02, S. 4]. Eine Klasse wiederum bildet eine Vorlage fr ein Objekt und ist somit ein Objekttyp. Die Gemeinsamkeiten einer Menge von Objekten werden daher in Klassen zusammengefasst und speziziert. Daraus folgt, dass Objekte als Instanzen einer Klasse bezeichnet werden [Hom02, S. 6]. Durch das Konzept der Kapselung bleiben Implementierungsdetails hinter spezizierten Schnittstellen verborgen, was dazu fhrt, dass die Darstellung eines Objekts nur entsprechend seiner Spezikation genutzt werden kann [Hom02, S. 5].

2.1.2 BesonderheitenScala gilt als Hybrid-Sprache, da sie Merkmale der objektorientierten und funktionalen Welt vereint. Scala-Quellcode wird in Java-Bytecode umgewandelt, was es so problemlos ermglicht Java-Code zu integrieren. Auerdem ist Scala eine rein objektorientierte Programmiersprache, da jeder Wert ein Objekt reprsentiert. Darber hinaus ist diese Sprache im Vergleich mit anderen modernen Vertretern ihrer Art statisch typisiert, was dazu fhrt, dass der Typ aller Ausdrcke bereits zur Kompilierzeit berprft wird und so unerwnschte Typfehler ausschliet [Bra10, S.1 f.]. Knappheit der Sprache Scala-Programme haben die Eigenschaft im Vergleich zu Java eher kurz zu sein. Sie sind meist um den Faktor 10 krzer als ein vergleichbares Programm in Java. Weniger Zeilen an Quellcode bedeutet aber nicht nur weniger Schreibarbeit sondern frdert auch die Lesbarkeit und Verstndlichkeit des Quellcodes. Darber hinaus bedeuten weniger Zeilen auch potenziell weniger Fehler im Programm selbst. Es gibt einige Faktoren die dazu beitragen die Anzahl an Zeilen des Quellcodes zu verringern. Beispielsweise vermeidet die Syntax von Scala einiges an Standardformulierungen, welche Java-Programme belasten. Semikolons sind optional und knnen in den meisten Fllen einfach weggelassen werden. Es gibt viele weitere Bereiche, in denen die Scala-Syntax bersichtlicher ist. Bei Betrachtung von Klassendenitionen mit Konstruktoren fllt dies besonders auf, was die nachfolgenden Beispiele, Listing 2.1 und Listing 2.2 darstellen sollen. Das erste Listing stellt die Denition einer Java-Klasse dar.

Christoph Schmidt

Seite 5 von 49



Listing 2.1: Java-Klasse mit Konstruktor class A { private int x ; private String y ; public A ( int x , String y ) { this . x = x ; this . y = y ; } } Im zweiten Listing ist die Denition einer Scala-Klasse zu sehen und wie unschwer zu erkennen ist, ist diese sehr viel krzer und bersichtlicher. Allerdings besitzt diese Denition exakt die gleiche Funktionalitt wie die zuvor dargestellte Klassendenition. Listing 2.2: Scala-Klasse mit Konstruktor class A ( x: Int , y: String ) Ein weiterer Grund fr die Knappheit von Scala ist auf ihre Typinferenz 2 zurckzufhren. Typangaben knnen teilweise weggelassen werden, was zur Folge hat, dass Programme lesbarer werden. Letztendlich ist aber der wichtigste Punkt um Quellcode kompakt zu halten der Code, der gar nicht erst geschrieben werden muss, da er in Form von Bibliotheken vorliegt. Fr diese Zwecke stellt Scala viele Werkzeuge zur Verfgung, um leistungsstarke Bibliotheken zu erzeugen. Viele Aspekte von Bibliotheken knnen in Traits ausgelagert werden, welche dann exibel zusammengesetzt werden knnen. Darber hinaus knnen Bibliotheksfunktionen mit Operationen parametrisiert werden, welche es ermglichen Konstrukte zu denieren, die schlussendlich eigene Kontrollstrukturen darstellen. Diese Konstrukte ermglichen es Bibliotheken zu denieren, welche zugleich hochrangig als auch exibel zu nutzen sind [OSV10, S. 13 .]. Kompatibilitt Wie bereits angesprochen ist Scala kompatibel zu Java 3 . Scala erzeugt JVM-Bytecode, dessen Laufzeitleistung dem von Java Programmen entspricht. Aus Scala heraus knnen Java Methoden aufgerufen und auf Felder zugegrien werden, die sich in Java Klassen benden. Auerdem knnen Java Interfaces implementiert werden. All das erfordert keine spezielle Syntax. Ein weiterer Grund fr die Zusammenarbeitsfhigkeit besteht darin, dass Scala die Java Typen wiederverwendet. Es werden z. B. die von Scala verwendeten Ints als primitive Integer von Javas ints dargestellt. Auerdem verwendet Scala viele der Java Bibliothekstypen wie den Typen eines String-Literals. Scala verwendet diese Typen jedoch nicht eins zu eins. Sie sind erweitert und in vielen Situationen komfortabler zu nutzen.2

Durch Typinferenz kann an einigen Stellen auf Typangaben verzichtet werden, da der entsprechende Typ durch Typisierungsregeln hergeleitet werden kann. 3 Es gibt auch eine Scala Variante die auf der .NET Plattform luft, allerdings wird die JVM Variante derzeit besser untersttzt.

Christoph Schmidt

Seite 6 von 49



Scala Quellcode kann auch aus Java heraus aufgerufen werden, was allerdings nicht so einfach mglich ist, da Scala eine reichhaltigere Sprache ist als Java. Deshalb mssen einige modernere Eigenschaften umgewandelt werden bevor sie in Java genutzt werden knnen [OSV10, S. 12 f.]. Hochsprache Scala ermglicht es den Abstraktionsgrad zu erhhen, was dazu fhrt, dass der Fokus bei der Programmierung strker auf das Problem selbst gelegt werden kann, um so ein Ziel besser zu erreichen, da zu komplexer Quellcode oft zu einem Aus fr ein Software-Projekt fhren kann. Dies soll nachfolgendes Beispiel verdeutlichen, welches berprft ob eine Zeichenkette, die durch die Variable name reprsentiert wird, Grobuchstaben enthlt oder nicht. Listing 2.3: Beispiel Java /* Programming in Scala : Second Edition S. 15 */ boolean nameHasUpperCase = false ; for ( int i= 0; i < name . length () ; ++ i ) { if ( Character . isUpperCase ( name . charAt ( i ) ) ) { nameHasUpperCase = true ; break ; } } Listing 2.3 zeigt eine derartige Implementierung in Java wohingegen Listing 2.4 dasselbe in Scala Syntax darstellt. Listing 2.4: Beispiel Scala /* Programming in Scala : Second Edition S. 15 */ val nameHasUpperCase = name . exists (_. isUpper ) Bei diesem Beispiel wird deutlich, dass bei Scala-Code direkt das Problem angegangen werden kann. Es mssen nicht, wie bei Java, unbersichtliche Schleifen programmiert werden, was letztendlich auf die Eleganz der funktionalen Programmierung zurckzufhren ist [OSV10, S. 15 f.]. Eine wachsende Sprache Programme verschiedener Gre tendieren dazu, unterschiedliche Programmierkonstrukte zu bentigen. Hierfr besteht in Scala die Mglichkeit, bestehende Konstrukte individuell an eigene Belange anzupassen. Das wird mglich, da diese Gebilde nicht fest in der Sprachsyntax verankert sind. Sie sind Bibliotheksabstraktionen, die erweitert oder adaptiert werden knnen. Es ist beispielsweise denkbar von einer Standard Map ausgehend eine speziellere Map zu implementieren, wie etwa eine HashMap oder TreeMap. In jedem Fall ist es aber potenziell mglich die gleiche Eingangssyntax einer Map zu verwenden. Dies gilt auch fr die in der Sprache eingesetzten Typen, welche zwar wie fest einge-

Christoph Schmidt

Seite 7 von 49



baute Typen erscheinen, aber dennoch nur als Klassen der Scala standard Bibliothek 4 vorliegen. All diese Eigenschaften ermglichen es vollkommen neue Abstraktionen zu schaen, mit deren Hilfe neue anwendungsspezische Sprachen entwickelt werden knnen, welche sich sehr weit einer natrlichen Sprache annhern [OSV10, S. 4 .]. Dies soll Listing 2.5 veranschaulichen. Listing 2.5: DSL zur Bestimmung eines Wochentages import java . util . Calendar class Date ( val data : Calendar ) { data . clear ( Calendar . HOUR ) import Date . Conjunction private var last = 0; def plus ( num : Int ) = { last = num ; this } def minus ( num : Int ) = { last = - num ; this } def years = { data . add ( Calendar . YEAR , last ) ; this } def years ( and : Conjunction ): Date = years def year = years def year ( and : Conjunction ): Date = years override def toString = data . get ( Calendar . DAY _ OF _ WEEK ) match { case 1 = > " Sunday " case 2 = > " Monday " /* ... */ } } object Date { class Conjunction val and = new Conjunction def Today = new Date ( Calendar . getInstance ) def Birthday = Today def Birthday ( day : Int , month : Int , year : Int ) = { var data = Calendar . getInstance data . set ( year , month - 1 , day ) new Date ( data ) } def today = Today def birthday = Birthday def birthday ( day : Int , month : Int , year : Int ) = Birthday ( day , month , year ) }4

Weiterfhrende Informationen zur Scala standard Bibliothek sind unter http://www.scalalang.org/api/current/index.html#package zu nden.

Christoph Schmidt

Seite 8 von 49



Die hier dargestellte domain specic language, kurz DSL, berechnet zu einem Geburtstag den entsprechenden Wochentag. Dabei ist es mglich zu diesem Tag beliebig viele Jahre hinzu zu addieren oder zu subtrahieren, um den Wochentag eines in der Zukunft oder Vergangenheit liegenden Geburtstags zu berechnen. Listing 2.6: Anwendungsbeispiel der DSL import java . util . Calendar import Date ._ object Example extends App { println ( birthday (16 ,8 ,1985) plus 26 years and minus 1 year and plus 1 year ) } Listing 2.6 zeigt wie zu einem Geburtstag mit Hilfe der plus Methode 26 Jahre hinzu addiert werden. Weiter wird dargestellt, dass sich Rechenoperationen wie minus einfach durch and anhngen lassen. Das hier dargestellte Beispiel wrde als Wochentag einen Dienstag berechnen. Um das erreichen zu knnen, liefert birthday(16,8,1985) ein Objekt der Klasse Date zurck. Auf diesem Objekt wird anschlieend die plus Methode aufgerufen. Der an diese Methode bergebene Zahlenwert wird in der Variablen last gespeichert. Die plus Methode gibt sich, also das Objekt, anschlieend selbst zurck, worauf die years Methode angewendet wird. Mit Hilfe des Wertes and, welcher eine Instanz der Klasse Conjunction ist, lassen sich dann beliebig viele Rechenoperationen anhngen. Das zuvor dargestellte Beispiel dient lediglich der Veranschaulichung der Erweiterbarkeit von Scala. Es lsst sich daraus ableiten, wie die dort genutzten und zuvor vorgestellten Konzepte hierzu beitragen.

2.2 LiftLift ist ein Framework mit dessen Hilfe Webapplikationen mit Scala realisiert werden knnen. Dabei handelt es sich um ein Full Stack Web Application Framework. Dies bedeutet, dass Lift alles, was fr die Entwicklung von Web-Applikationen bentigt wird, mitbringt [Bra10, S. 253]. Das Framework wurde entwickelt um sichere, performante und leicht wartbare Applikationen zu entwickeln [Per11, S. 5].

2.2.1 ArchitekturLift arbeitet nicht wie viele andere Web-Frameworks nach dem MVC -Muster. Lift verfolgt einen Denkansatz, der View First Design genannt wird. Dieser besteht aus den drei Bestandteilen View, Snippet und Model. Dadurch wird es, im Gegensatz zu MVC, mglich Seiten, die mehr als ein Element besitzen, innerhalb einer Anfrage zu erstellen, was in modernen Applikationen meist der Fall ist [Per11, S. 8]. Abbildung 2.1 zeigt das Zusammenspiel der einzelnen Komponenten, welche im Anschluss nher erlutert werden.

Christoph Schmidt

Seite 9 von 49



Abbildung 2.1: View First Design

View Innerhalb des View First Kontext bezieht sich View primr auf XML Inhalte, die bei einer Seitenanfrage bentigt werden. Innerhalb von Lift-Anwendungen gibt es grundstzlich zwei Arten von Views: Template Views, die dynamische Inhalte in vordenierte Markup Templates binden [Per11, S. 9]. Erzeugte Views, in welchen typischerweise dynamische Inhalte mittels Scala XML Ausdrcken erzeugt werden [Per11, S. 9]. Template Views werden blicherweise dafr eingesetzt um Inhalte einer View zu erzeugen. Dies setzt allerdings ein korrekt formatiertes XHTML oder HTML5 Template voraussetzt, da es in Lift nicht mglich ist Views einzusetzen, welche Formatierungsfehler aufweisen. Erzeugte Views sind weitaus weniger blich, sie werden aber manchmal fr eine schnelle Prototypenentwicklung verwendet. Als eine der Lift Hauptideen gilt, dass Views fr mehr als eine einzige Aufgabe eingesetzt werden knnen. Das trgt dazu bei, um redundanten Quellcode innerhalb einer Anwendung zu verringern und ermglicht es auch Komponenten zu entwickeln, welche voneinander entkapselt sind [Per11, S. 9 f.]. Snippet Snippets sind Darstellungsfunktionen, welche mittels Scala programmiert werden. Diese werden dann mit Hilfe von speziellen Tags in Templates eingebunden [Bra10, S. 262]. Sie bezwecken einzig das Erzeugen von dynamischen Inhalten und teilen nderungen der Model-Komponente dem View mit [Per11, S. 10]. Sie sind typischerweise in Klassen zusammengefasst [Per11, S. 35]. Listing 2.7: Hallo-Welt Snippet package code . snippet import scala . xml . NodeSeq import net . liftweb . util . Helpers ._ class HalloWelt { def hallo = " * " # > < strong > Hallo Welt ! }

Christoph Schmidt

Seite 10 von 49



Listing 2.7 stellt eine Scala Klasse dar, welche eine Snippet Methode hallo deniert, die als CSS Transformer bezeichnet wird. Das sind im wesentlichen Funktionen, die als Eingabeparameter ein Element vom Typ NodeSeq5 erwarten und auch ein Element von NodeSeq zurckliefern. Diese werden durch das Importieren des Helpers._ Objektes untersttzt, welches eine entsprechende implizite Typumwandlung beinhaltet [Per11, S. 36]. Listing 2.8: Hallo-Welt Template < body class =" lift : content _ id = main " > < div id =" main " class =" lift : surround ? with = default ; at = content " > Ersetze mich ! In Listing 2.8 ist ein Template dargestellt, welches die zuvor denierte hello Methode benutzt. Mittels des Schlsselworts lift wird die Methode hallo der Klasse HalloWelt aufgerufen und das entsprechende Tag ersetzt. Da Snippet Klassen Darstellungsfunktionen beinhalten muss es eine Mglichkeit geben um Textfelder, Check-Boxen oder Buttons zu erstellen. Fr diese Zwecke stellt Lift das Objekt net.liftweb.http.SHtml bereit, welches diese Aufgabe bernimmt [CBDW11, S. 25]. Model In diesem Zusammenhang ist Model eine allgemeine Bezeichnung, die mehrere Dinge darstellen kann. In den meisten Applikationen stellt dieser Teil ein Modell der Persistenz oder der Daten dar. Fr gewhnlich wird an dieser Komponente ein konkreter Wert nachgefragt, den diese dann zurckliefert [Per11, S. 10].

2.2.2 Lift Core und Lift WebLift besitzt zwei Module, die einen zentralen Teil des Frameworks ausmachen. Diese werden als Core und Web bezeichnet. Der Core setzt sich aus vier einzelnen Projekten zusammen. Diese beinhalten Bibliotheken, die sowohl mit als auch ohne das Web Modul in Projekten eingesetzt werden knnen. Das Web Modul selbst baut drauf auf und untersttzt die komplexen Komponenten von Lift um sichere und skalierbare Web-Anwendungen realisieren zu knnen. Das Web Modul setzt sich aus drei Teilprojekten zusammen: Das Basis Web System und zwei zustzliche Projekte, die spezielle Helfer zur Verfgung stellen [Per11, S. 12]. Abbildung 2.2 zeigt eine bersicht der einzelnen Bestandteile, welche im Anschluss nher erlutert werden.

5

NodeSeq ist in Scala eine Sequenz von XML Knoten.

Christoph Schmidt

Seite 11 von 49



Abbildung 2.2: Module Lift Core/Web

Lift Common Dieses Modul beinhaltet eine Menge an Basisklassen, die berall in Lift eingesetzt werden knnen. Darber hinaus knnen diese auch in Projekten genutzt werden, die keine Web-Anwendungen darstellen [Per11, S. 12]. Weiterfhrende Informationen zu diesem Paket sind in der API-Dokumentation 6 unter net.liftweb.common zu nden. Lift Actor Actor beschreibt ein Modell der nebenlugen Programmierung. Im Scala-Umfeld gibt es zahlreiche verschiedene Implementierungen hierzu. Lift besitzt seine Eigene, speziell fr den Bereich der Web-Programmierung [Per11, S. 13]. Diese ist im Paket net.liftweb.actor angesiedelt. Lift Utilities Utilities beschreibt eine Sammlung von Klassen, Traits und Objekten, welche entwickelt wurden um einen komfortablen Mechanismus zur Verfgung zu stellen, um mit hug genutzten Paradigmen zu arbeiten [Per11, S. 13]. Ein genauer berblick ist im Paket net.liftweb.util zu nden. Lift JSON Lift JSON stellt ein eigenstndiges Paket dar, dass es ermglicht mit JSON 7 auf eine sehr ressourcenschonende Art zu arbeiten. Im Vergleich mit dem JSON Parser, welchen Scala verwendet, ist dieser ungefhr 350 mal so schnell. Darber hinaus stellt Lift eine durchdachte DSL fr das Konstruieren von JSON Objekten bereit [Per11, S. 14]. Weitere Details sind im Paket net.liftweb.json bereitgestellt. Lift Webkit Dieses Modul beinhaltet den Einstiegspunkt des Frameworks. Es setzt sich aus der Anfrageverarbeitung, deren Lokalisierung sowie der Template-Darstellung zusammen. Es ist das wichtigste Modul von Lift [Per11, S. 14].

6 7

http://scala-tools.org/mvnsites/liftweb-2.3 JSON ist ein Kurzwort fr JavaScript Object Notation.

Christoph Schmidt

Seite 12 von 49



2.2.3 PersistenzEine der Hauptaufgaben von Web-Anwendungen befasst sich mit der dauerhaften Speicherung von Daten. Fr diese Zwecke stellt Lift ein Mapper und Record Framework zur Verfgung. Diese Frameworks stellen ein Gerst fr jegliche Datenmanipulation bereit. Mapper stellt das ursprngliche Persistenz-Framework dar, welches eng mit JDBC 8 verknpft ist [CBDW11, S. 89]. Auf diese Art und Weise stellt Lift verschiedene Optionen zur Verfgung um Daten zu speichern. Dabei ist es irrelevant ob es sich bei der zu Grunde liegenden Technologie um ein relationales Datenbankmanagementsystem (RDBMS) oder eine NoSQL9 Lsung handelt [Per11, S. 16]. Abbildung 2.3: Struktur der Lift-Persistenz

Abbildung 2.3 illustriert eine strukturelle bersicht der Persistenz. Im Anschluss werden die wichtigsten Bestandteile nher ausgefhrt. DB/Mapper Mapper bieten eine einheitliche Mglichkeit um mit persistenten Daten zu arbeiten. Das Framework stellt einen O/R-Mapper 10 bereit, welcher alle relationalen Beziehungen verarbeiten kann (z. B. 1:1, 1:N und M:N Beziehungen). Daher ist es nicht zwingend erforderlich SQL Join Anfragen 11 zu programmieren [Per11, S. 16]. Weiterfhrende Informationen sind im Paket net.liftweb.mapper zu nden. Lift JPA Die Java Persistence API ist im Java Umfeld weit verbreitet. Daher wurde diese zu Lift hinzugefgt und an Scala angepasst [Per11, S. 17]. Alle relevanten Daten sind im Paket net.liftweb.jpa bereitgestellt. Lift Record Die Records reprsentieren eine Sicht, die dem Benutzer Create, Read, Update und Delete Semantik fr die Datenmanipulation bereitstellt. Auerdem bietet diese eine Menge an Optionen um beispielsweise Form-Felder darzustellen [Per11, S. 17 f.]. Dabei spielt es keine Rolle, ob die Daten mit JDBC, JPA oder sogar in Form von XML gespeichert werden [CBDW11, S. 89].

JDBC ist eine Datenbankschnittstelle der Java-Plattform. NoSQL: Steht fr englisch Not only SQL. 10 O/R Mapper bezeichnet eine Programmiertechnik um Daten zwischen inkompatiblen TypSystemen zu transformieren. 11 SQL Join Anfrage kombiniert Datenstze zweier oder mehrerer Tabellen einer Datenbank.9

8

Christoph Schmidt

Seite 13 von 49



2.2.4 ProjektstrukturIn diesem Abschnitt wird die Projektstruktur einer Lift-Anwendung vorgestellt. Dabei beziehen sich alle Angaben auf das von Lift bereit gestellte lift_basic 12 -Projekt. Listing 2.9: Projektstruktur |-| | | | -project | - - build | -- LiftProject . scala -- build . properties src |-| | | | | | | | | | | | | | | | | | | | | | | | | | | --

main | - - resources | -- props | -- default . props | - - scala | | - - bootstrap | | -- liftweb | | -- Boot . scala | -- code | | - - comet | | - - lib | | -- DependencyFactory . scala | | - - model | | -- User . scala | | - - snippet | | -- HelloWorld . scala | -- view -- webapp | - - images | -- ajax - loader . gif | - - index . html | - - static | -- index . html | - - templates - hidden | | - - default . html | -- wizard - all . html -- WEB - INF -- web . xml test ...

Im Ordner project werden alle Informationen die zum Erstellen der Anwendung mit dem Build-Tool SBT notwendig sind aufbewahrt, welches in Abschnitt 5.1.2 vorgestellt wird. In diesem Ordner ist auch eine Datei LiftProject.scala zu nden.12

https://github.com/lift/lift_23_sbt/tarball/master

Christoph Schmidt

Seite 14 von 49



Sie beinhaltet beispielsweise Abhngigkeiten wie bentigte Repositories und wird mit Hilfe von Scala konguriert [Per11, S. 31]. In der Datei resources/props/default.props knnen Properties deniert werden, auf welche dann in der Anwendung zugegrien werden kann. Sie enthlt normalerweise keine Eintrge. Das Verzeichnis scala beherbergt die eigentlichen Scala-Dateien der Anwendung. Es ist mit verschiedenen Unterverzeichnissen ausgestattet um das Projekt zu strukturieren. Die Datei bootstrap/liftweb/Boot.scala wird beim booten der Anwendung genutzt und wird in Abschnitt 2.2.5 nher ausgefhrt. Alle anwendungsspezischen Klassen und Objekte benden sich im Verzeichnis code. Alle sonstigen fr die Anwendung wichtigen Dateien wie Bilder, statische HTMLSeiten und Templates werden im Verzeichnis src/main/webapp aufbewahrt [Bra10, S. 256].

2.2.5 KongurationBevor Lift eine Anwendung startet mssen einige Dinge konguriert werden, so dass berhaupt eine Anfrage ausgefhrt werden kann. Der Lift Servlet 13 sucht nach einer Klasse bootstrap.liftweb.Boot und fhrt dessen boot Methode aus. Diese Methode wird nur einmalig ausgefhrt und eignet sich daher um Initialisierungsaufrufe anderer Bibliotheken in ihr zu platzieren [CBDW11, S. 24]. Listing 2.10 zeigt einen Auszug einer boot Mehtode, welche im Anschluss nher ausgefhrt wird. Als Erstes wird mit dem StandardDBVendor Objekt eine Datenbankverbindung hergestellt, welches eine H2-Datenbank 14 verwaltet [Bra10, S. 257]. Anschlieend wird mit Hilfe des LiftRules Objektes der unloadHooks Collection eine Funktion angehngt, die fr das Schlieen aller Datenbankverbindungen verantwortlich ist. Diese wird ausgefhrt, wenn die Anwendung heruntergefahren wird [Bra10, S. 258]. Durch den Schemifier kommt ein Teil des O/R-Mappers zum Einsatz. Durch dessen schemify Methode wird gewhrleistet, dass die Datenbank das korrekte Schema eines User Objektes besitzt, um User zu speichern [Bra10, S. 258]. Ein User-Objekt knnte wie in der in Abschnitt 2.2.4 eingefhrten Beispiel-Anwendung aufgebaut sein, welches in der Datei code/model/User.scala zu nden ist. In der anschlieenden Zeile wird Lift mittels LiftRules.addToPackages("code") bekannt gegeben, in welchem Paket das Framework nach Quellcode, z. B. fr Snippets, suchen soll [Bra10, S. 258]. Dann wird die Mensteuerung implementiert, was durch die Methode sitemap erzielt wird. An dieser Stelle sei erwhnt, dass Lift bereits ber eine eingebaute Mensteuerung und Zugrisverwaltung verfgt, deren Funktionsweise im Kapitel 5.2 nher erlutert wird.

13

Mit Servlets werden Java-Klassen bezeichnet, deren Instanzen innerhalb eines Java-Webservers Anfragen von Clients entgegen nehmen und beantworten. 14 http://www.h2database.com

Christoph Schmidt

Seite 15 von 49



Listing 2.10: Die Methode boot def boot { val vendor = new StandardDBVendor ( " org . h2 . Driver " , " jdbc : h2 : lift _ proto . db ; AUTO _ SERVER = TRUE " , Empty , Empty ) LiftRules . unloadHooks . append ( vendor . closeAllConnections _! _) DB . defineConnectionManager ( DefaultConnectionIdentifier , vendor ) Schemifier . schemify ( true , Schemifier . infoF _ , User ) LiftRules . addToPackages ( " code " ) def sitemap = SiteMap ( Menu . i ( " Home " ) / " index " >> User . AddUserMenusAfter , Menu ( Loc ( " Static " , Link ( List ( " static " ) , true , " / static / index " ) , " Static Content " ) ) ) def sitemapMutators = User . sitemapMutator LiftRules . setSiteMapFunc (() = > sitemapMutators ( sitemap ) ) /* ... */ S . addAround ( DB . buildLoanWrapper ) } In Listing 2.10 wurden einige Objekte verwendet, die in Lift eine fundamentale Rolle spielen. Deshalb sollen diese im Anschluss kurz vorgestellt werden. S Objekt Das net.liftweb.http.S Objekt reprsentiert den Zustand der aktuellen Anfrage. Es wird beispielsweise benutzt, um Informationen abzufragen und um Informationen, die in der Antwort gesendet werden, zu modizieren. Es kann unter anderem auch fr das Cookie-Management oder fr eine Redirection verwendet werden [CBDW11, S. 25]. LiftRules Das Objekt net.liftweb.http.LiftRules wird eingesetzt um die globale Konguration eines Lift-Projekts zu realisieren. Alles was in Lift konguriert werden kann wird ber Variablen dieses Objekts umgesetzt [CBDW11, S. 25].

Christoph Schmidt

Seite 16 von 49

3 AnalyseIn Zusammenarbeit mit dem Studiendekan und Stundenplaner der Fakultt Informatik wurde die bisherige Planungssoftware zum Erfassen und Planen des Curriculums untersucht um daraus die grundstzlichen Anforderungen an eine webbasierte Neuimplementierung mit dem Namen PlanningWeb abzuleiten. Die daraus resultierenden Ergebnisse werden in den folgenden Abschnitten vorgestellt. Der Analyseprozess wurde in Anlehnung an [OB09, S. 89 .] durchgefhrt.

3.1 ZielsystemPlanningWeb ist eine Software, die den Studiendekan in allen wichtigen Anwendungsfllen der Lehrplanung untersttzt. Die daraus resultierenden Ergebnisse bilden die Grundlage fr die Stundenplanung des jeweiligen Semesters. Darber hinaus soll das System den Stundenplaner bei der Erfassung der Arbeitszeiten und Raumwnsche der Dozenten untersttzen. Es knnen Dozenten, Studiengnge, Lehrveranstaltungen und Rume mit allen planungsrelevanten Daten erfasst, gendert und gelscht werden. Nach Abschluss der Lehrplanung knnen die Ergebnisse des Planungsprozesses fr das externe Stundenplanungssystem bereitgestellt werden. Auerdem knnen sich Dozenten am System anmelden um Arbeitszeit- oder Raumwnsche zu uern, die der Stundenplaner anschlieend im Planungsprozess bercksichtigen kann. Die Software verfgt ber eine Zugriskontrolle, mit der es mglich ist Benutzer am System anzumelden. Die Authentizierung wird mit Hilfe einer gltigen FHS-ID 1 unter Zuhilfenahme des FH internen LDAP 2 -Servers durchgefhrt. Der Kern der Anwendung setzt einen Server mit Unix/Linux oder Windows als Betriebssystem voraus. Auf ihm muss ein Application-Server wie Jetty oder Tomcat installiert und konguriert sein. Der Anwendungsserver muss sich im Netz der Fachhochschule benden. Das System ist datenbankunabhgig und kann sowohl mit NoSQL3 - als auch relationalen Datenbanken betrieben werden. Die Anwendung wird von allen gngigen Internetbrowsern untersttzt und ermglicht plattformunabhniges Arbeiten.

3.2 BenutzeranalyseNachdem im vorangegangen Abschnitt das Zielsystem beschrieben wurde, sollen hier die spteren Benutzer analysiert und klassiziert werden. Aus den Gesprchen1 2

FHS-ID ist eine von der FH vergebene ID zur eindeutigen Identizierung. LDAP: Lightweight Directory Access Protocol [Sem06]. 3 NoSQL: Steht fr englisch Not only SQL.

Christoph Schmidt

Seite 17 von 49

3. Analyse


mit dem Studiendekan und Stundenplaner lassen sich grundstzlich drei Benutzergruppen ableiten: Lehrplaner, Stundenplaner und Dozenten. Dazu kommt noch ein Administrator, der die Anwendung betreut. Um zu verhindern, dass die Daten einer Abbildung 3.1: Systemkontextdiagramm

bestimmten Benutzergruppe von anderen Benutzergruppen gelesen oder manipuliert werden, ist es notwendig fr die einzelnen Benutzergruppen Rollen zu vergeben. Dies sind: Lehrplaner mit Zugri auf Dozenten, Studiengnge und Lehrveranstaltungen. Stundenplaner mit Zugri auf Arbeitszeiten der Dozenten, Rume und durch den Lehrplaner freigegebene Lehrveranstaltungen zur Stundenplanung. Dozent mit Zugri auf eigene Arbeitszeiten und Wunschrume. Administrator mit Zugri auf alle Daten.

3.3 AnwendungsflleDurch die Klassizierung der Benutzer im Abschnitt 3.2 ist es mglich entsprechend den Rollen Anwendungsflle abzuleiten. Diese ermglichen es die Hauptaufgabe des Systems darzustellen um im weiteren Verlauf ein exibles Design entwerfen zu knnen. [OB09, S. 114]. Es werden nur die Anwendungsflle des Planungsprozesses und der Arbeitszeiterfassung von Dozenten als Essenzbeschreibung 4 dargestellt, da diese fr das weitere Verstndnis von wesentlicher Bedeutung sind.

4

Essenzbeschreibung ist die komprimierteste und abstrakteste Form eines Anwendungsfalls [OB09, S. 114].

Christoph Schmidt

Seite 18 von 49

3. Analyse


3.3.1 LehrplanungsprozessDie Planung des Curriculums umfasst mehrere Schritte. Sie beginnt mit dem Zuweisen einer Veranstaltung zu einem Semester, wie in Tabelle 3.1 dargestellt. Tabelle 3.1: Anwendungsfall Lehrveranstaltung Semester zuweisenName Kurzbeschreibung Auslser Akteur Vorbedingung Nachbedingung Essenzielle Schritte Lehrveranstaltung Semester zuweisen Der Lehrplaner weist Lehrveranstaltung einem Semester zu. Es ist eine neue Lehrplanung fr Sommer- oder Wintersemester erforderlich Der Lehrplaner. Es ist mindestens eine Lehrveranstaltung im System vorhanden. Lehrveranstaltung wurde einem Semester zugewiesen. alle Lehrveranstaltungen anzeigen; gewnschte Lehrveranstaltung Semester zuweisen; nderungen speichern; Speicherung besttigen

Anschlieend besteht die Mglichkeit Vorlesungsgruppen zu erstellen, um die einzelnen Semester des gleichen oder eines anderen Studiengangs, die laut Studienordnung an dieser Veranstaltung teilnehmen, auf einen oder mehrere Dozenten zu verteilen, was in Tabelle 3.2 abgebildet ist. Desweiteren ist es mglich bungsgruppen fr eine Lehrveranstaltung anzulegen. Da dieser Anwendungsschritt aber analog zu dem Erstellen einer Vorlesungsgruppe zu sehen ist, wird dieser Anwendungsfall nicht explizit aufgefhrt. Tabelle 3.2: Anwendungsfall Vorlesungsgruppe erstellenName Kurzbeschreibung Auslser Akteur Vorbedingung Nachbedingung Essenzielle Schritte Vorlesungsgruppe erstellen Der Lehrplaner erstellt eine Vorlesungsgruppe fr eine Lehrveranstaltung. Die Anzahl der Teilnehmer einer Lehrveranstaltung ist zu gro und soll daher mehrfach angeboten werden. Der Lehrplaner. Es ist mindestens eine Lehrveranstaltung im System vorhanden. Vorlesungsgruppe wurde fr eine Lehrveranstaltung erstellt. eine Lehrveranstaltung auswhlen; Studiengnge einer Lehrveranstaltung mit zugehrigem Semester anzeigen; Studiengnge mit entsprechendem Semester auswhlen, alle Dozenten fr Lehrveranstaltung anzeigen, die diese Vorlesung halten; ein oder mehrere Dozenten auswhlen; Vorlesungsgruppe speichern; Speicherung besttigen

Nachdem die Planungsphase der Vorlesungs- und bungsgruppen abgeschlossen ist, mssen aus den erfassten Daten noch die konkreten Vorlesungen und bungen abgeleitet werden, die in einer Studienwoche eines Semesters angeboten werden sollen. Das Semester kann Sommer- oder Wintersemester sein. Diese Daten dienen dann

Christoph Schmidt

Seite 19 von 49

3. Analyse


dem Stundenplaner als Basis fr die entsprechende Stundenplanung. Der zugehrige Anwendungsfall ist in Tabelle 3.3 dargestellt. Tabelle 3.3: Anwendungsfall SemesterplanungName Kurzbeschreibung Semesterplanung Der Lehrplaner generiert die konkreten Vorlesungen und bungen fr alle Lehrveranstaltungen eines bestimmten Semesters. Die Planung des Curriculums ist abgeschlossen. Der Lehrplaner. Es ist mindestens eine Lehrveranstaltung im System vorhanden und Sommer- oder Wintersemester zugeordnet. Konkrete Vorlesungen und bungen sind im System erfasst. Sommer- oder Wintersemester zum Planen auswhlen; entsprechende Vorlesungen und bungen aus Lehrveranstaltungen generieren; erstellte Vorlesungen und bungen anzeigen; alle angezeigten Vorlesungen und bungen speichern; Speicherung besttigen

Auslser Akteur Vorbedingung Nachbedingung Essenzielle Schritte

3.3.2 ArbeitszeiterfassungsprozessDie Erfassung der Arbeitszeiten und Wunschrume einzelner Dozenten umfasst einen weiteren wichtigen Bestandteil der Anwendung, was in Tabelle 3.4 dargestellt ist. Die dabei erfassten Raum- und Zeitwnsche dienen spter dem Stundenplaner als Basis fr die Stundenplanung. Tabelle 3.4: Anwendungsfall Arbeitszeit und Raumwnsche erfassenName Kurzbeschreibung Arbeitszeit und Raumwnsche eines Dozenten erfassen Der Dozent whlt aus einer vorgegebenen Menge von Zeiteinheiten Arbeitszeiten aus. Anschlieend markiert er Wunschrume fr seine zu haltenden Lehrveranstaltungen. Die Zeiterfassung wurde durch den Stundenplaner freigeschaltet. Stundenplaner und Dozent. Es ist mindestens ein Dozent mit FHS-ID im System bekannt. Konkrete Arbeitszeiten und Wunschrume des Dozenten sind im System erfasst. Wunsch- u. Kann-Zeiten auswhlen; Wunschrume Lehrveranstaltungen zuweisen; prfen ob ausreichend Arbeitszeiten markiert wurden; wenn ja Speichern; wenn nein, Warnung ausgeben und Eingaben zurcksetzen

Auslser Akteur Vorbedingung Nachbedingung Essenzielle Schritte

Christoph Schmidt

Seite 20 von 49

4 DesignNachdem im vorangegangen Kapitel 3 das Zielsystem genau beschrieben und analysiert wurde, wird in diesem Abschnitt auf das Design der PlanningWeb-Anwendung eingegangen. Dabei ist festzuhalten, dass die gegebene Aufgabenstellung bereits eine Client/Server-Architektur voraussetzt. Prinzipiell kann die Architektur in verschiedene Schichten aufgeteilt werden, um eine Abgrenzung zwischen Funktionalitt und Aufgaben zu erzielen [M05, S. 62]. Im Folgenden wird daher kurz die Drei- und Vier-Schichten-Architektur vorgestellt um darauf aufbauend die Details des PlanningWeb-Designs zu erlutern. Im Bereich der Softwarearchitektur spielt aber nicht nur die Aufteilung eines Softwaresystems in Schichten eine Rolle. Moderne Softwaresysteme sind zudem meist in Komponenten aufgeteilt. Daher soll im Anschluss an die Schichtenarchitektur noch der Komponentenbegri konkretisiert werden.

4.1 Drei-Schichten-ArchitekturIn dieser Architektur wird die Anwendungs- von der Prsentationslogik getrennt, was zur Folge hat, dass der Client ausschlielich die Prsentationslogik enthlt. Die Anwendungslogik wird auf einem Applikationsserver bereitgestellt, die den Client mit dem Datenbank-Server verbindet [M05, S. 64 f.].

4.2 Vier-Schichten-ArchitekturIm Vergleich zur Drei-Schichten-Architektur ndert sich bei Hinzunahme einer weiteren Schicht, dass sich die Prsentationslogik vom Client auf einen Webserver verschiebt. Die Anwendungslogik ist weiterhin im Applikationserver angesiedelt. Dadurch stellt der Client nur noch eine Schnittstelle fr den Benutzer dar, welche die eingegebenen Daten an den Server weiterleitet. Auerdem dient der Client dazu die vom Server angeforderten Daten darzustellen. Durch diese Architektur knnen browserbasierte Internet-Anwendungen realisiert werden [M05, S. 65 f.].

4.3 SoftwarekomponentenTechnische Systeme bestehen zumeist aus Komponenten. Im Bereich der Softwareentwicklung hat sich jedoch bislang keine allgemein akzeptierte Denition etabliert. Es lassen sich aber allgemeingltige Merkmale darstellen, die eine Komponente kennzeichnen [Sie04, S. 42].

Christoph Schmidt

Seite 21 von 49

4. Design


Eine Komponente importiert andere Schnittstellen [Sie04, S. 43]. Eine Komponente verbirgt die Implementierung und kann daher durch andere Komponenten ersetzt werden [Sie04, S. 43]. Sie knnen wiederverwendet werden, da sie von der Umgebung in der sie eingesetzt werden unabhngig sind [Sie04, S. 43]. Sie lassen sich beliebig kombinieren um so neue Komponenten zu erzeugen [Sie04, S. 43]. Komponenten sind ein wichtiger Bestandteil des Entwurfs und der Implementierung [Sie04, S. 43].

4.4 Konkretes DesignDie in Abschnitt 4.2 vorgestellte Architektur lsst sich auch auf die PlanninWebApplikation bertragen. Das Anfordern einer Ressource eines Clients vom Server luft dann folgendermaen ab: Client fordert eine Ressource an. Webserver nimmt die Anfrage entgegen. Anschlieend wendet sich der Webserver an den Applikationserver um die angeforderten Daten in einer geeigneten Prsentationsform an den Client zurckzusenden. Applikationserver fordert die bentigten Daten von der Datenbank an und generiert auf Basis der Anwendungslogik das Ergebnis und bergibt dies an den Webserver, der dann die angeforderten Daten in geeigneter Prsentationsform an den Client sendet. Durch die Rahmenbedingungen des SPIRIT-Projekts in Kapitel 1.3 ist die Wahl des Webservers bereits auf Jetty festgesetzt, da dieser dort bereits im Einsatz ist. Jetty bietet den Vorteil, dass er die Funktion eines Webservers mit der eines Applikationservers vereint. Das nachfolgende Diagramm 4.1 stellt die einzelnen Komponenten des Systems genauer dar, die im Anschluss ausfhrlich erlutert werden.

4.4.1 DatenhaltungWie in Kapitel 2.2.3 dargestellt, verfgt Lift ber ein Mapper und Record Framework welches auch in der PlanningWeb-Anwendung zum Einsatz kommt. Allerdings soll das geplante System datenbankunabhnig implementiert werden. Auf Grund dieses Umstandes kann das Framework nur indirekt genutzt werden. Daher benden sich im Kern der Anwendung zwei Komponenten persistence und transform. Um die Hintergrnde dieser Komponenten zu verstehen sollen erst zwei Entwurfsmuster vorgestellt werden.

Christoph Schmidt

Seite 22 von 49

4. Design


Abbildung 4.1: Komponentendiagramm

Active Record Bei diesem Entwurfsmuster enthalten Objekte sowohl Daten als auch Verhaltensweisen. Die meisten dieser Daten sind persistent und mssen daher in einer Datenbank gespeichert werden. Active Record benutzt den klarsten Ansatz um Datenbankzugrislogik in einem Anwendungsobjekt unterzubringen. So wissen alle Nutzer wie Daten von der Datenbank gelesen und geschrieben werden knnen. Daraus folgt auch, dass die Struktur eines Records genau auf die darunterliegende Datenbankstruktur abgebildet werden kann. Dieses Muster ist fr Anwendungen geeignet, die einen geringen Komplexittsgrad aufweisen. Allerdings koppelt Active Record die Anwendungslogik direkt an die Datenbank, was zur Folge hat, dass Designnderungen nur schwer durchzufhren sind [FRF+ 03, S. 160 .]. Data Mapper Das Data Mapper Muster lsst sich am besten mit Hilfe eines Beispiels erklren. Angenommen es existiert eine Klasse Person und eine zugehrige Klasse PersonMapper. Um ein Personen-Objekt aus der Datenbank zu laden wrde ein Client die find Methode des Mappers aufrufen. Dieser wrde dann das entsprechende Objekt aus der Datenbank holen und als Ergebnis das entsprechende Personen-Objekt zurckgeben. Wrde ein Client ein Objekt speichern wollen, wrde das Objekt an den Mapper bergeben werden und dieser wrde das Objekt in der Datenbank speichern. Dieses Entwurfsmuster kann so implementiert werden, dass fr jede Klasse die in der Datenbank gespeichert werden soll, ein eigener Mapper erstellt werden muss. Es ist aber auch mglich das Muster so umzusetzen, dass in der gesamten Anwendung

Christoph Schmidt

Seite 23 von 49

4. Design


nur ein Mapper fr alle Objekt eingesetzt wird. Auerdem kann das Muster auch dafr verwendet werden, um die Anwendung von der darunterliegenden Datenbank abzutrennen [FRF+ 03, S. 166 .]. Architektur Wie eingangs erwhnt besitzt Lift bereits Records fr alle gngigen Datenbanken. Diese sind aber, wie beim Active Record Muster beschrieben, stark an die Datenbank gebunden. Deshalb wurden in der PlanningWeb-Anwendung die Komponenten persistence und transform eingefhrt. Diese sind in Anlehnung an das Data Mapper Muster implementiert. Dabei wurde ein Ansatz verfolgt, hnlich wie in [Sie04, S. 211 .] beschrieben. Die persistence Komponente bietet eine Schnittstelle an um Objekte in einer Datenbank zu lesen, zu schreiben, zu lschen und zu aktualisieren. Um das bewerkstelligen zu knnen benutzt die persistence Komponente eine Schnittstelle, die von der transform Komponente angeboten wird. Diese ist wiederum in der Lage Objekte der Anwendungslogik in Record-Objekte der entsprechenden Datenbank-Records zu transformieren um so das Lesen, Schreiben und ndern von Objekten in der Datenbank zu ermglichen. Durch diese Art der Architektur ist die Anwendungslogik komplett von der zugrundeliegenden Datenbank unabhngig und kann jederzeit gegen eine andere Datenbank ausgetauscht werden. Die nachfolgende Abbildung 4.2 stellt das Zusammenspiel der beiden Komponenten in einem Klassendiagramm dar.

Abbildung 4.2: Klassendiagramm Persistenz

Christoph Schmidt

Seite 24 von 49

4. Design


4.4.2 AnwendungskernDer Anwendungskern im Allgemeinen beschreibt die fachliche Intelligenz der Anwendung [Sie04, S. 165]. In der PlanningWeb-Anwendung ist dieser Teil in der snippet Komponente angesiedelt, welche bereits in Kapitel 2.2.1 eingefhrt wurde. Diese lsst sich gem der durchgefhrten Analyse wiederum in eigenstndige Teilkomponenten zerlegen, woraus fnf weitere Komponenten entstehen, die im Anschluss nher erlutert werden. Studiengangsverwaltung: Ein wichtiger Bestandteil der Lehr- und Stundenplanung sind die Studiengnge. Ein Studiengang besitzt einen Namen, eine Abkrzung und eine Semesteranzahl. Darber hinaus besitzt jedes Semester eine Anzahl an Studenten. Das System besitzt daher eine Studiengangsverwaltung mit folgenden Funktionen: Anlegen eines neuen Studiengangs, Bearbeiten eines Studiengans und Lschen eines Studiengangs. Dozentenverwaltung: Um berhaupt Lehrveranstaltungen anbieten zu knnen sind Dozenten erforderlich, die bestimmte Vorlesungen anbieten. Ein Dozent besitzt einen Typ der sich aus einem Namen, den zu haltenden Pichtstunden und einer Kennzeichnung, ob es sich bei diesem Typ um einen Lehrbeauftragen handelt, zusammensetzt. Auerdem gibt es auf Grund der FH internen LDAP-Struktur einen Dozenten fr die Lehrplanung und einen FHS-Dozenten fr die Authentizierung am System. Ein Dozent besitzt einen Namen, der diesen eindeutig identiziert, einen Typ und eine Zeitangabe zur Selbstverwaltung, die von den zu haltenden Pichtstunden des Typs abgezogen wird um die tatschliche Arbeitszeit zu ermitteln. Ein FHS-Dozent setzt sich wiederum aus einem Dozenten und einer FHS-ID zusammen. Die Studiengangsverwaltung besitzt deshalb diese Funktionen: Typen und FHS-Dozenten anzulegen und zu lschen. Dozenten knnen darber hinaus angelegt, gendert und gelscht werden. Lehrveranstaltungsverwaltung: Kern einer jeden Lehrplanung sind die Lehrveranstaltungen. Eine Lehrveranstaltung setzt sich aus einem Typ, einem Namen der diese eindeutig identiziert, Studiengngen mit entsprechenden Semestern, Dozenten sowie Vorlesungs- und bungswochenstunden zusammen. Die Lehrveranstaltungsverwaltung bietet daher folgende Funktionen an: Erstellen und Lschen eines Typs; Erstellen, ndern, Anzeigen und Lschen von Lehrveranstaltungen; Zuweisen von Lehrveranstaltungen zu Sommer- oder Wintersemester; Erstellen und Lschen von Lehrveranstaltungs- und bungsgruppen sowie der Semesterplanung, welche die entsprechenden Veranstaltungen pro Studienwoche generiert. Raumverwaltung: Ein wichtiger Bestandteil der Stundenplanung sind Rume. Ein Raum ist genau einem Gebude zugeordnet und besitzt eine Bezeichnung, eine Raumgre sowie zahlreiche Ausstattungsmerkmale (z. B. mit/ohne Tageslichtprojektor, Tafel, Beamer ...). Die Raumverwaltung bietet die Mglichkeit Rume zu Erstellen und zu Lschen.

Christoph Schmidt

Seite 25 von 49

4. Design


Arbeitszeitverwaltung: Die Arbeitszeiten der Dozenten bilden einen weiteren Bestandteil der Stundenplanung. Die Arbeitszeiten setzen sich daher aus verschieden Zeiteinheiten einer Studienwoche zusammen. Die Arbeitszeitverwaltung bietet daher die Mglichkeit an, Arbeitszeiten und Raumwnsche fr Veranstaltungen der einzelnen Dozenten zu erfassen und zu verwalten. Diese vorgestellten Funktionsgruppen besitzen gem ihrer Aufgaben Abhngigkeiten. Die Dozentenverwaltung ist wie die Studiengangs- und Raumverwaltung eigenstndig. Die Arbeitszeitverwaltung hingegen ist auf die Dozenten-, Raum- und Lehrveranstaltungsverwaltung angewiesen. Den Kern des PlanningWeb-Systems bildet die Lehrveranstaltungsverwaltung. Sie ist wiederum von der Dozenten- und Studiengangsverwaltung abhngig. Auf Grund dieser Beziehungen lsst sich ein vereinfachtes Datenmodell ableiten, das in Abbildung 4.3 dargestellt ist. Abbildung 4.3: Datenmodell der PlanningWeb-Anwendung

In dem in Abbildung 4.3 vorgestellten Datenmodell kommt der Lehrveranstaltung oder auch Lecture eine zentrale Rolle zu. Deshalb wird diese aus dem Datenmodell herausgegrien und deren Architektur ausfhrlich dargestellt. Abbildung 4.4 zeigt das Design einer Lehrveranstaltung wie es in der PlanningWeb-Anwendung umgesetzt ist. Eine Lehrveranstaltung besteht aus einem Name, der diese eindeutig beschreibt, einem Lehrveranstaltungstyp der sich aus der Studienordnung ergibt, einer Semesterwochenstudenanzahl fr bungen und Vorlesungen sowie zwei Flags, welche aussagen, ob die Lehrveranstaltung im Sommer- oder Wintersemester angeboten wird. Darber hinaus enthlt sie eine Liste mit Studiengangsinformationen, welche in der Klasse CourseInformation abgebildet sind. Eine CourseInformation setzt sich wiederum aus einem Course mit einer Liste entsprechender Semester zusammen, wie in Klasse Semester dargestellt. Eine Instanz der Klasse Semester besitzt einen Namen und eine Teilnehmerzahl. Die Klasse CourseInformation besitzt weiter eine Liste mit Dozenteninformationen, welche durch die Klasse DozentInformation reprsentiert werden. Diese Klasse bildet ab, ob ein Dozent eine Vorlesung und/oder eine bung der Lehrveranstaltung abhlt. Aus diesem Teilaufbau einer Lehrveranstaltung lassen sich bereits konkrete Vorlesungen und bungen einer Studienwoche ableiten, die allerdings noch nicht alle geforderten Anforderungen erfllt, wie beispielhaft in Listing 4.1 dargestellt.

Christoph Schmidt

Seite 26 von 49

4. Design


Abbildung 4.4: Klassendiagramm einer Lehrveranstaltung

Listing 4.1: Darstellung einer Lehrveranstaltung val lecture = Lecture ( " Prozedurale Programmierung " , LectureType ( " Pflichtfach " ) , List ( CourseInformation ( " Bachelor Informatik " ," BaI " , List ( Semester (1 ,1) ) , List ( SemesterInformation ( 1 , List ( DozentInformation ( Dozent ( " Braun " ," " ,0.0 , DozentType ( " Professor " ,18 , false ) ) , true , true ) ) ) ) ) ) , List () , List () ,1 ,1 , true , false )

Christoph Schmidt

Seite 27 von 49

4. Design


Aus Listing 4.1 lsst sich eine Vorlesungseinheit und eine bungseinheit fr das erste Semester des Studiengangs Bachelor Informatik mit der Lehrveranstaltungsbezeichnung Prozedurale Programmierung ableiten. Beide Termine werden vom Dozenten Braun im Sommersemester angeboten. Um weitere Anforderungen, wie das Erstellen von bungs- und Vorlesungsgruppen, die exibel einem oder mehren Dozenten zugewiesen werden knnen, enthlt das Design einer Lehrveranstaltung zwei weitere Attribute, hasLectureTogetherWith und hasTutorialTogetherWith. Beide aggregieren die Klasse LectureRelationship, welche eine Liste mit Studiengngen und zugehrigem Semester in eine direkte Beziehung zu einem Dozenten setzen. Durch diese Architekturentscheidung knnen die in Kapitel 3.3.1 geforderten Anforderungen erfllt werden.

Christoph Schmidt

Seite 28 von 49

5 ImplementierungNachdem in den vorangegangenen Kapiteln die Sprache Scala und das Lift-Framework vorgestellt und die Anforderungen sowie das Design der Beispielanwendung entworfen und analysiert wurden, geht dieses Kapitel auf die Implementierung der PlanningWeb-Applikation ein. Es werden wichtige Programmteile ausfhrlich untersucht. Dabei werden Mglichkeiten vorgestellt, die das Lift-Framework und Scala bieten um spezische Probleme zu lsen. Zu Beginn wird kurz ein berblick ber Programme gegeben, mit denen grundstzlich Lift-Anwendungen realisiert werden knnen. Anschlieend wird auf die Implementierung der wichtigsten Komponenten des Systems eingegangen. Die entstandenen Probleme werden dabei erlutert und die damit verbunden Lsungsanstze vorgestellt. Der gesamte Quellcode wurde auf Github1 verentlicht.

5.1 Entwicklungsumgebung und BuildtoolsFr die Entwicklung von Scala- und im speziellen fr Lift-Anwendungen besteht grundstzlich die Mglichkeit einen herkmmlichen Editor wie Vim oder Notepad in Verbindung mit einem Buildtool zu nutzen. Fr eine etwas komfortablere Entwicklung stehen fr die meist genutzten Entwicklungsumgebungen wie Eclipse, NetBeans oder IntelliJ entsprechende Scala-Plugins zu Verfgung [CBDW11, S. 6 f.]. Im Laufe der PlanningWeb-Entwicklung kam IntelliJ 2 und das Build-Tool SBT 3 zum Einsatz.

5.1.1 IntelliJIntelliJ IDEA wurde in der Community Edition 10.0.3 mit Scala-Plugin verwendet, das sich ber den Plugin Manager installieren lsst. Zu den wichtigsten Funktionen des Plugins zhlt Code Highlighting und Code Completion. Darber hinaus kann mit Projekten gearbeitet werden, die sowohl Scala als auch Java Dateien enthalten. Weiter wird das Compilieren, Testen und Refaktorisieren untersttzt. Die Entwicklungsumgebung bietet auerdem eine Untersttzung fr Versionsverwaltungen wie SVC, Git, Mercural und Subversion an. Grundstzlich lsst sich die Entwicklungsumgebung intuitiv und benutzerfreundlich bedienen. Allerdings fllt negativ auf, dass die Reaktionszeit von IntelliJ nach mehreren Stunden sehr stark ansteigt, so das ein Neustart erforderlich wird. Um die generelle Reaktionszeit von IntelliJ zu verbessern, kann die Datei idea.vmoptions im bin Verzeichnis wie in Listing 5.1 gezeigt angepasst werden.1 2

https://github.com/spirit-fhs/planningweb http://www.jetbrains.com/idea/ 3 http://code.google.com/p/simple-build-tool/

Christoph Schmidt

Seite 29 von 49

5. Implementierung


Listing 5.1: Modizierte Datei idea.vmoptions -Xms512m -Xmx2048m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=64m -ea Auch das Refaktorisieren bereitet Probleme. Das Umbenennen von Methoden oder Klassen erzielte oft nicht den erwnschten Eekt, so dass per Hand eingegrien werden musste. Ein weitere Schwachpunkt liegt im Verschieben von Dateien oder Paketen. Abschlieend kann die Arbeit mit IntelliJ aber als positiv bewertet werden.

5.1.2 Simple-Build-ToolZum bersetzten des Projekts kam SBT 0.7.4 zum Einsatz. Dahinter verbirgt sich ein Kommandozeilenprogramm das Scala Projekt bersetzt. Es setzt Java 1.5 oder eine aktuellere Version voraus. Projekte werden mit der Sprache Scala konguriert. Es ist auch mglich den Funktionsumfang von SBT mit Hilfe von entsprechenden Scala-Plugins zu erweitern. Auerdem untersttzt das Programm das Testen von Anwendungen, da es die Test-Frameworks Scala-Check, Specs und ScalaTest untersttzt. Fr das Arbeiten mit webbasierten Anwendungen stellt SBT einen integrierten Jetty-Server fr Testzwecke bereit, dessen Bedienung in Listing 5.2 dargestellt ist. Listing 5.2: Benutzung des Simple-Build-Tools ~/planningweb$ sbt [info] Building project sprit_planningweb_cs 0.1 against Scala 2.8.1 [info] using LiftProject with sbt 0.7.4 and Scala 2.7.7 >jetty-run [info] [info] == copy-resources == [info] == copy-resources == [info] [info] == compile == ... Im Projektverzeichnis der Applikation wird sbt mit dem Aufruf sbt gestartet. Anschlieend folgt die Eingabe von jetty-run, was die Anwendung bersetzt und startet. Sofern der Quellcode fehlerfrei bersetzt wurde, kann das Programm mit einem Browseraufruf von http://localhost:8081 gestartet werden. Beim erstmaligen Ausfhren sollte allerdings nach dem Start von SBT ein update Befehl ausgefhrt werden, um Paketabhnigkeiten aufzulsen. Alternativ kann dem jetty-run Befehl eine Tilde vorangestellt werden. Dadurch wird das Projekt automatisch bei nderungen am Quellcode neu bersetzt. Mit dem Aufruf der Befehlsfolge sbt clean update compile prepare-webapp package erzeugt SBT eine war-Datei, die dann auf einem Application-Server ausgefhrt werden kann.

Christoph Schmidt

Seite 30 von 49

5. Implementierung


5.2 Men und ZugriskontrolleWie in Kapitel 2.2.5 erlutert verfgt Lift bereits ber eine Benutzerverwaltung und Mensteuerung. Allerdings soll die Authentizierung an der PlanningWebAbbildung 5.1: PlanningWeb-Anmeldung

Anwendung mit Hilfe der FH-internen LDAP-Server durchgefhrt werden. Das Framework beinhaltet im Paket net.liftweb.ldap ein LDAP-Modul. Dieses kann aber auf Grund der FH-internen Struktur nicht zum Einsatz kommen. Fr die Abfrage aller relevanten Daten muss auf zwei unterschiedliche LDAP-Server zugegrien werden, welche die relevanten Daten vorhalten. Das enthaltene Modul kann lediglich Daten von einem LDAP-Server abfragen. Aus diesem Grund wurde in einer anderen Arbeit des Spirit-Projekts ein Fhs-LDAP-Modul entwickelt, das auch in dieser Anwendung Verwendung ndet. Der Quellcode wurde auf Github4 verentlicht.

5.2.1 FhS-LDAP-ModuleUm zu ermglichen, dass sich Dozenten am System mit ihrer FHS-ID anmelden knnen, wird im Objekt User des Moduls die Methode loginXhtml aus dem abgeleiteten Trait MetaMegaProtoUser berschrieben, welcher im Paket net.liftweb.mapper enthalten ist. Diese Methode reprsentiert das Standard-Anmeldeformular. Listing 5.3: Die Methode loginXhtml override def loginXhtml = { ( {"Login nur mit gltiger FHS-ID mglich!"} {S.??("log.in")} {S.??("FHS-ID")}4

https://github.com/mdenison/FhS-LDAP-Module

Christoph Schmidt

Seite 31 von 49

5. Implementierung


{S.??("password")}

document.forms[login].elements[username].focus(); ) } Der Trait MetaMegaProtoUser deniert darber hinaus einen User und bietet eine Methode currentUserId an. Diese Methode liefert nach erfolgreicher Anmeldung die FHS-ID eines Dozenten zurck. Dadurch wird es mglich eine Rollenunterscheidung der einzelnen Benutzergruppen zu implementieren. Hierzu ist in der Datei Boot.scala der Applikation eine Methode is implementiert, wie in Listing 5.4 dargestellt. Listing 5.4: Die Methode is def is(user: String): Boolean = { Props.get(user, "") .split(";") .contains(User.currentUserId.openOr("")) } Die Methode bekommt bei Aufruf einen Suchstring bergeben und prft in der Kongurationsdatei default.props ob der Benutzer der gesuchten Benutzergruppe entspricht. Die is Methode wird von den Methoden isSuperUser, isCourseSheduler und isTimetableSheduler aufgerufen, um eine bessere Lesbarkeit des Quellcodes zu erziehlen, wie in Listing 5.5 zu sehen ist. Listing 5.5: Die Methode isTimetableSheduler def isTimetableSheduler : Boolean = { is("spirit.timetable.user") }

5.2.2 SiteMapDas Men der Anwendung wird in der Methode sitemap erstellt. Um eine Unterscheidung zwischen den vier Benutzergruppen zu erzielen enthlt die Klasse Boot in der Methode boot die Attribute: ifSuperUser ifDozent ifCourseSheduler ifTimetableSheduler.

Christoph Schmidt

Seite 32 von 49

5. Implementierung


Listing 5.6: Attribut ifTimetableSheduler val ifTimetableSheduler = If (() => if (isTimetableSheduler || isSuperUser) {true} else {false}, () => RedirectResponse("/index")) Listing 5.6 stellt exemplarisch das Attribut ifTimetableSheduler dar. Bei diesem Attribut handelt es sich um einen sogenannten LocParam, auf den im weiteren Verlauf noch genauer eingegangen wird. Alle Elemente zum Erstellen einer SiteMap sind im Paket net.liftweb.sitemap enthalten. Die bereits angesprochene Methode sitemap liefert ein Objekt der Klasse SiteMap zurck. Diese bekommt die einzelnen Meneintrge im Konstruktor bergeben. Listing 5.7: Auszug der Methode sitemap def sitemap = SiteMap( /*...*/ Menu.i("Raumverwaltung") / "room" / "management" >> ifTimetableSheduler /*...*/ ) Listing 5.7 zeigt beispielhaft den Meneintrag der Raumverwaltung. Mit Hilfe der im Objekt Menu enthaltenen Methode i wird ein Eintrag fr die Raumverwaltung erzeugt. Zu diesem Eintrag wird mit der / Methode der Pfad zur Website hinzugefgt, die die Raumverwaltung reprsentiert. Die Methode fgt dem Meneintrag noch den LocParam ifTimetableSheduler hinzu. Dieser ist ein Objekt der Klasse If. Der erste Parameter dieser Klasse ist eine Funktion, die prft ob der Zugri auf die entsprechende Seite erlaubt ist oder nicht. Der zweite Parameter reprsentiert die Rckgabe an den Browser im Fehlerfall. Im Falle der Raumverwaltung wrde der Benutzer bei einem Fehler auf die Start-Seite umgeleitet werden. Sollte der Zugri auf die Seite nicht erlaubt sein, wird der Meneintrag nicht in der SiteMap angezeigt.

5.3 Persistenz und TransformationWie bereits in Kapitel 4.4.1 erlutert, wurde in der PlanningWeb-Anwendung eine Persistenz-Komponente implementiert. Dies wurde ntig, da das gesamte System datenbankunabhnig umgesetzt werden sollte. Die persistence Komponente setzt sich aus einem Trait IPersistence, welcher als Schnittstelle fungiert, der konkreten Implementierung Persistence und dem Objekt PersistenceFactory zusammen. Listing 5.8: Der Trait IPersistence trait IPersistence { def read : List[AnyRef]

Christoph Schmidt

Seite 33 von 49

5. Implementierung


def create(obj: AnyRef) def delete(obj: AnyRef) def update(before: AnyRef, after: AnyRef) } Bei Betrachtung von Listing 5.8 fllt der Typ AnyRef auf. Dieser Typ ist ein Subtyp der Wurzelklasse Any. AnyRef ist die Basisklasse aller Referenzklassen in Scala. Diese Klasse ist als Alias von java.lang.Object zu sehen [OSV10, S. 212 .]. Dadurch wird es mglich die im Trait IPersistence denierten Methoden fr unterschiedliche Objekte nutzbar zu machen. Das Objekt PersistenceFactory ist als Singelton-Objekt implementiert. Scala untersttzt im Gegensatz zu Java die Mglichkeit Singelton-Objekte zu erzeugen. Dazu wird lediglich bei der Denition eines solchen Objektes statt dem Schlsselwort class das Schlsselwort object verwendet [OSV10, S. 65], wie in Listing 5.9 zusehen. Listing 5.9: Das Objekt PersistenceFactory object PersistenceFactory { def createPersistence (transform: ITransform) : IPersistence = { new Persistence(transform) } } Das Objekt PersistenceFactory verfgt lediglich ber eine Fabrikmethode mit dem Namen createPersistence, bei deren Aufruf ein konkretes Objekt der Schnittstelle ITransform als Parameter mit bergeben wird. Als Ergebnis liefert diese Methode dann ein entsprechendes Persistenz-Objekt zurck. Die Schnittstelle ITransform ist fr die Konvertierung eines konkreten Datenbankobjektes in ein Anwendungsobjekt zustndig. Die Komponente transform verfgt wiederum ber ein Fabrikobjekt, welches fr jedes persistente Objekt ein entsprechendes Transformationsobjekt erzeugt. Listing 5.10: Das Objekt TransformFactory object TransformFactory { def createTransformDozentType(persType: String) : ITransform = { persType match { case "mongoDB" => new TransformDozentTypeMongo case _ => error("Could not support: " + persType) } } /*...*/ } Listing 5.10 zeigt beispielhaft die Methode createTransformDozentType des Objektes TransformFactory. Dieser Methode wird der zugrunde liegende Datenbanktyp bergeben, der in der Datei default.probs deniert ist. Auf diese Art und Weise wird es mglich unterschiedliche Datenbanken zu untersttzen. Diese Implementierung bietet den Vorteil, dass bereits bestehender Quellcode nur noch an zwei Stellen

Christoph Schmidt

Seite 34 von 49

5. Implementierung


des Programms verndert werden muss, nmlich das Objekt TransformFactory und die Datei Boot.scala, um weiter Datenbanken zu untersttzen. Alle neuen Transformationsklassen kommen lediglich ergnzend hinzu. Listing 5.11: Anlegen eines Persistenz-Objektes val persistence:IPersistence = PersistenceFactory.createPersistence(TransformFactory. createTransformDozentType(persLayer)) val dozentTypes = persistence.read.asInstanceOf[List[DozentType]] Listing 5.11 zeigt wie ein Persistenz-Objekt in der Anwendung angelegt werden kann. Dieses bietet dann die entsprechenden Methoden um Objekte aus der Datenbank zu lesen, zu schreiben, zu lschen und zu verndern. Das Beispiel zeigt auch, dass beim Lesen von Objekten aus der Datenbank das Ergebnis der read Methode explizit mit dem Aufruf von asInstanceOf in den erwarteten Rckgabetyp umgewandelt werden muss. Der Versuch den Aufruf von asInsatnceOf mittels Implicit conversions 5 berssig zu machen schlug fehl, da beispielsweise die Klassen Dozent und DozentType im Paket Dozentmanagement beide ein Attribut name besitzen, was dazu fhrt, dass es mehrere Mglichkeiten zur impliziten Umwandlung gibt. Abschlieend soll darauf hingewiesen werden, dass Lift mit dem Record-Framework den Ansatz verfolgt Datenbankzugrislogik in Anwendungsobjekten unterzubringen. Durch die hier dargestellte Trennung zwischen Anwendungs- und Datenbankobjekten kann der volle Umfang der Lift-Records nicht in der Anwendung genutzt werden.

5.4 Lehrveranstaltungsverwaltung und PlanungAlle relevanten Dateien der Lehrveranstaltungsverwaltung und Planung benden sich in der snippet Komponente unter lectures.snippet. Bei Betrachtung der einzelnen Mens fllt auf, dass sich beispielsweise das Erstellen einer Lehrveranstaltung ber mehrere Seiten erstreckt. Fr solche Formulare bietet Lift so genannte Screens und Wizards an, welche im Packet net.liftweb.wizard enthalten sind [Pol11b, S. 37 f.]. Beim Versuch, diese auch in der PlanningWeb-Anwendung einzusetzen, stellte sich allerdings heraus, dass diese fr die dortigen Zwecke ungeeignet sind. Abbildung 5.2: Lehrveranstaltung erfassen: Seite 1

5

Weiterfhrende Informationen zu Implicit conversions sind in [OSV10, S. 112 f.] zu nden.

Christoph Schmidt

Seite 35 von 49

5. Implementierung


Beim Erfassen der Lehrveranstaltungen ist es notwendig nach der Vergabe eines Namens und der Typauswahl eine Menge von Studiengngen zu selektieren. Abbildung 5.3: Lehrveranstaltung erfassen: Seite 2

Anschlieend soll aus den Studiengngen eine Formularseite generiert werden, auf der die einzelnen Semester zu den entsprechenden Studiengngen ausgewhlt werden knnen. Abbildung 5.4: Lehrveranstaltung erfassen: Seite 3

Dies lie sich jedoch nicht mit den Wizards umsetzen, da diese nicht fr dynamisch generierte Formulare geeignet sind. Der Vorgang des Erstellens einer Lehrveranstaltung ist dem nderungsvorgang sehr hnlich. Deshalb wurde versucht den Algorithmus fr beide Vorgnge nutzbar zu machen, um Quellcoderedundanzen zu verhindern. Fr diese Zwecke bietet sich das Template Method-Muster an, was im folgenden Abschnitt kurz vorgestellt wird.

5.4.1 Template Method-MusterDas Template Method-Muster deniert das Grundgerst eines Algorithmusses in einer Methode und berlsst einige Teile den Unterklassen. Dieses Muster lsst Unterklassen die Freiheit bestimmte Schritte zu redenieren, ohne dabei die Struktur des Algorithmuses zu verndern [GHV98, S. 274]. Diese Muster eignet sich in folgenden Situationen: Um unvernderliche Teile eines Algorithmusses einmal zu implementieren und es Unterklassen zu berlassen, das variierende Verhalten zu implementieren [GHV98, S. 275].

Christoph Schmidt

Seite 36 von 49

5. Implementierung


Wenn gemeinsames Verhalten zwischen Unterklassen erkannt wurde, das aus diesen herausgelst werden soll. Das Verhalten wird dann in eine gemeinsame Klasse verlagert um redundanten Quellcode zu vermeiden [GHV98, S. 274].

5.4.2 Umsetzung des Template Method-MustersWie bereits angesprochen ist das Erstellen einer Lehrveranstaltung dem ndern einer solchen sehr hnlich. Deshalb wurden diese Vorgnge mittels des Template Method-Musters umgesetzt. Der Trait LecturesCreateNavigator deniert die Template-Methode namens navigation. Die Klasse LecturesCreate reprsentiert das Men zum Erstellen einer Lehrveranstaltung und benutzt hierzu die Basisimplementierung der TemplateMethode. Die Klasse LecturesUpdate reprsentiert das Men zum ndern einer Lehrveranstaltung. Listing 5.12: Die Template-Methode des Traits LecturesCreateNavigator def navigation = { Status.is match { case LecturesCreateHelper.InitialStatus => addName case LecturesCreateHelper.AddedName => addCourses case LecturesCreateHelper.AddedCourse => addSemesters case LecturesCreateHelper.AddedSemester => addDozents case LecturesCreateHelper.AddedDozent => addHoures case LecturesCreateHelper.AddedHoure => saveLecture } } Listing 5.12 stellt die Template-Methode dar, welche den Erstellungs- bzw. nderungsprozess steuert. Das Objekt Status reprsentiert eine Sessionvariable, in der der aktuell bearbeitete Status des Vorgangs gespeichert wird. Die einzelnen Zustnde in denen sich das Status-Objekt benden kann, werden durch das LecturesCreateHelper-Objekt deniert. Durch das von Scala untersttzte Pattern-Matching kann so zwischen den einzelnen Menu-Seiten mittels Weiter- und Zurck-Button navigiert werden. Die Add-Methoden wie addName oder addCourse generieren dabei dynamisch die entsprechenden Formular-Seiten.

5.4.3 PlanungsprozessDer Planungsprozess ist der Kern des Systems. Er ist dafr verantwortlich aus den zuvor erfassten Lehrveranstaltungen konkrete Veranstaltungen einer Studienwoche des entsprechenden Semesters zu generieren. Diese Daten bilden die Grundlage fr

Christoph Schmidt

Seite 37 von 49

5. Implementierung


den Stundenplanungsprozess. Fr diese Zwecke wurde das Objekt PlanningLectureCreater implementiert. Es bietet eine Methode buildPlan an, die eine Liste von Lehrveranstaltungen, wie in Abbildung 4.4 eingefhrt, als Argument bergeben bekommt und daraus eine Liste von PlanningLectures erstellt, die alle stundenplanungsrelevanten Daten beinhaltet. Listing 5.13: Die Methode buildPlan def buildPlan(lectures: List[Lecture]): List[PlanningLecture] = { lectures.map(buildPlanningLecture(_)).flatten } Listing 5.13 zeigt die Implementierung der zuvor angesprochenen Generierungsmethode. Das Beispiel stellt dar, wie mit hilfe der map Methode auf jedes Element der Liste die Funktion buildPlanningLecture angewendet wird. Diese Methode verrichtet die eigentliche Arbeit und generiert eine Liste vom Typ PlanningLecture. Das wiederum hat zur Folge, dass eine verschachtelte Ergebnisliste entsteht. Deshalb wird auf das Ergebnis die flatten Methode angewendet um die Ergebnisliste zu gltten. Der Aufbau eines PlanningLecture Objektes ist in Listing 5.14 dargestellt. Listing 5.14: Die Klasse PlanningLecture case class PlanningLecture(name: String, typeOfLecture: String, groups: List[CourseSemester], dozents: List[Dozent], numberOfMembers: Int) Im weiteren Verlauf soll nun die Methode buildPlanningLecture genauer analysiert werden, wie in Listing 5.15 dargestellt. Listing 5.15: Die Methode buildPlanningLecture def buildPlanningLecture(lecture: Lecture): List[PlanningLecture] = { val minHouresOfLecture = 1 val maxHouresOfLecture = lecture.hoursOfLecture val minHouresOfTutorial = 1 val maxHouresOfTutorial = lecture.hoursOfTutorial val rangeHouresOfLecture = (minHouresOfLecture to maxHouresOfLecture).toList val rangeHouresOfTutorial = (minHouresOfTutorial to maxHouresOfTutorial).toList val lectureType = "Vorlesung" val tutorialType = "bung" /*...*/ if(lecture.hasLectureTogetherWith.isEmpty && lecture.hasTutorialTogetherWith.isEmpty) { buildPlanningLectureWithEmptyListsForHasLATTogetherWith

Christoph Schmidt

Seite 38 von 49

5. Implementierung


} else { buildPlanningLectureWithNoEmptyListsForHasLATTogetherWith } } Diese Methode unterscheidet, ob fr eine Lehrveranstaltung bungs- bzw. Vorlesungsgruppen erstellt wurden oder nicht und ruft dementsprechend eine der beiden Methoden buildPlanningLectureWithEmptyListsForHasLATTogetherWith6 buildPlanningLectureWithNoEmptyListsForHasLATTogetherWith7 auf. Diese beiden Methoden berechnen die Veranstaltungen, welche im Laufe einer Woche angeboten werden mssen und geben diese als Liste von PlanninLectures zurck. Listing 5.16 stellt eine der beiden Methoden dar. Listing 5.16: buildPlanningLectureWithNoEmptyListsForHasLATTogetherWith def buildPlanningLectureWithNoEmptyListsForHasLATTogetherWith = { def getCourseInfosFrom(lecture: Lecture, courseSemesters: List[ CourseSemester]) = { lecture.courseInfos .filter(ci => courseSemesters .exists(_.course == ci.course.name)) } val lecturesToPlan = lecture .hasLectureTogetherWith .map(lr => PlanningLecture(lecture.name, lectureType, lr.these, lr.withThose, calculateNumberOfMembers(getCourseInfosFrom(lecture, lr.these)))) val lectureList = rangeHouresOfLecture .map(nr => lecturesToPlan).flatten val tutorialsToPlan = lecture .hasTutorialTogetherWith .map(lr => PlanningLecture(lecture.name, tutorialType, lr.these, lr.withThose,6 7

Der Methodenname wurde abgekrzt. ...LAT... steht fr ...LectureAndTutorial.... Der Methodenname wurde abgekrzt. ...LAT... steht fr ...LectureAndTutorial....

Christoph Schmidt

Seite 39 von 49

5. Implementierung


calculateNumberOfMembers(getCourseInfosFrom(lecture,lr. these)))) val tutorialList = rangeHouresOfTutorial .map(nr => tutorialsToPlan).flatten lectureList union tutorialList } Diese Methode berechnet jeweils fr Vorlesungen und bungen getrennte Listen welche am Ende mittels union zu einer gemeinsamen Rckgabeliste vereint werden. Die so entstandenen Daten sollen dem Stundenplanungsprogramm als Grundlage dienen. Da das neue Stundenplanungsprogramm 8 bislang nur prototypisch implementiert wurde, knnen die mit der PlanningWeb-Anwendung generierten Daten bislang nicht fr die Stundenplanung eingesetzt werden. Auch der Versuch die auf Basis dieser Arbeit generierten Daten fr das alte Stundenplanungsmodul einzusetzen ist nicht mglich, da das den zeitlichen Rahmen der Arbeit weit berschreitet. Auderdem wrde dadurch die in den Daten enthaltene Semantik teilweise verloren gehen. Mit diesem Programm ist es beispielsweise nicht mglich abzubilden, dass mehr als ein Dozent an einer Lehrveranstaltung beteiligt ist. Deshalb wurde fr das Semesterplanungsmen nur eine Dummy-Implementierung umgesetzt.

5.5 ArbeitszeitverwaltungDie Verwaltung der Arbeitszeiten einzelner Dozenten umfasst eine weitere wichtige Aufgabe der PlanningWeb-Anwendung, da diese fr den Stundenplanungsprozess von essentieller Bedeutung sind. Die Arbeitszeitverwaltung setzt sich aus einem Men fr die Dozenten zusammen, in dem sie via Radio-Buttons in einem Stundenplan ihre Wunscharbeitszeiten eintragen knnen. Raumwnsche knnen derzeit lediglich ber ein Kommentarfeld eingetragen werden, wie in Abbildung 5.5 dargestellt. Weiter verfgt die Verwaltung ber einen Bereich fr den Stundenplaner, indem er die Arbeitszeitenerfassung fr Dozenten freischalten kann. Darber hinaus besteht fr ihn die Mglichkeit, sich die Arbeitszeiten grasch in einem Stundenplan anzeigen zu lassen, was Abbildung 5.6 zeigt. Das Men bietet dem Stundenplaner auch die Mglichkeit die Arbeitszeiten aller Dozenten zu bearbeiten. Die dafr notwendigen Dateien benden sich in der snippet Komponente unter worktimes.snippet. Das Men zur Erfassung der Arbeitszeiten durch die Dozenten und das Men des Stundenplaners zum Bearbeiten der Arbeitszeiten einzelner Dozenten basiert auf dem gleichen Prinzip. Deshalb wurde versucht eine Basisimplementierung fr beide Mens zu schaen um redundanten Quellcode zu vermeiden. Der Unterschied zwischen den beiden Mens besteht darin, dass Dozenten, welche sich am System authentiziert haben, beim Aufruf des Meneintrags Wunschzeiten8

https://github.com/spirit-fhs/core

Christoph Schmidt

Seite 40 von 49

5. Implementierung


Abbildung 5.5: Stundenplan der Wunschzeitenerfassung

Abbildung 5.6: Men Arbeitszeiten eines Dozenten anzeigen

Christoph Schmidt

Seite 41 von 49

5. Implementierung


direkt auf die Seite mit ihren Arbeitszeiten und Raumwnschen gelangen. Im Gegensatz dazu muss der Stundenplaner eine Mglichkeit besitzen, einen bestimmten Dozenten auszuwhlen, um dessen Arbeitszeiten bearbeiten zu knnen. Um dies realisieren zu knnen, wurde die Klasse Wishtimes implementiert, welche das Men fr einen Dozenten darstellt. Das Men fr den Stundenplaner ist von dieser Klasse abgeleitet und in der Klasse WishtimesAdmin umgesetzt. Der Stundenplaner muss die Mglichkeit besitzen Arbeitszeiten zu verndern, auch wenn die Arbeitszeiterfassung fr die Dozenten gesperrt ist. Das Men wird mit Hilfe der status Variable freigeschaltet. Deshalb muss dieser Wert in der Klasse WorktimesAdmin auf true gesetzt werden. Darber hinaus ist es auch ntig die Werte isFHSDozent worktimeOfDozent noteTextOfDozent neu zu setzen, deren Basisimplementierung im Trait WishtimesHelper zu nden ist. Stellt man die beiden Wertzuweisungen fr isFHSDozent gegenber, wie in Listing 5.17 dargestellt, wird der Unterschied oensichtlich. Listing 5.17: Gegenberstellung der Wertzuweisung fr isFHSDozent /* isFHSDozent in WorktimesHelper.scala */ var isFHSDozent = fhsdozents.filter(_.fhsId == currentUserId) /* isFHSDozent in WorktimesAdmin.scala */ isFHSDozent = fhsdozents.filter(_.fhsId == FHSDozentName.is) Ruft ein Dozent das Men Wunschzeiten auf, ist seine FHS-ID bereits beim Instanzieren der Klasse Wishtimes durch den Wert currentUserId bekannt. Das hat zur Folge, dass an dieser Stelle bereits die Arbeitszeiten und Raumnotizen berechnet werden knnen, um mit diesen die Darstellung des Stundenplans zur Auswahl der Arbeitszeiten zu berechen, welcher im Trait WishtimesTimetable durch den Wert timetable dargestellt ist. Im Gegensatz dazu ist die FHS-ID im Men des Stundenplaners erst nach Auswahl eines Dozenten aus einem Drop-Down Men bekannt, woraufhin in der Methode edit der Klasse WishtimesAdmin ein Redirect ausgefhrt wird. Das wiederum hat zur Folge, das eine neue Instanz der Klasse WishtimesAdmin erzeugt wird. Bei der Instanzierung wird allerdings zuerst der Wert fr isFHSDozent aus dem Trait WishtimesHelper berechnet, auf dessen Basis dann der Wert timetable fr die Darstellung des Stundenplans berechnet wird. Daraus ergibt sich, dass der Stundenplaner einen leeren Stundenplan fr den ausgewhlten Dozenten angezeigt bekommen wrde, da die Neuzuweisung in der Klasse WishtimesAdmin nicht bercksichtigt wird. Die Auswertung von timetable muss also solange unterdrckt werden, bis der Stundenplan tatschlich bentigt wird. So ist gewhrleistet, dass dieser auf Basis des Wertes von isFHSDozent aus der Klasse WishtimesAdmin berechnet wird, der dann die entsprechende FHS-ID enthlt.

Christoph Schmidt

Seite 42 von 49

5. Implementierung


Listing 5.18: Auszug der Methode timetable lazy val timetable = {"Montag"} {"Dienstag"} {"Mittwoch"} {"Donnerstag"} {"Freitag"} {"08:15-09:45"} {makeRadio("Mo",1)} {makeRadio("Tu",1)} {makeRadio("We",1)} {makeRadio("Th",1)} {makeRadio("Fr",1)} /*...*/ Scala bietet fr solche Flle die Mglichkeit der lazy evaluation. Standartmig werden die Felder in Scala beim Instanzieren einer Klasse ausgewertet, was dem Prinzip der eager evaluation entspricht. Werden Werte mit dem lazy Modier gekennzeichnet, hat dies zur Folge, das diese Felder erst bei Bedarf ausgewertet werden [Bra10, S. 102], was Listing 5.18 illustrieren soll. Abschlieend muss noch die vererbte render Methode in der Klasse WishtimesAdmin berschrieben werden, was in Listing 5.19 dargestellt ist. Listing 5.19: berschreiben der Render-Methode override def render = { "#edit *" #> edit }

5.6 TestflleFr das Erstellen von Software gehren Testflle zum guten Ton. Deshalb wurden auch fr die PlanningWeb-Anwendung Testflle erstellt. Im Scala-Umfeld haben sich zahlreiche Test-Frameworks etabliert. Im Rahmen des PlanningWebs wurde Specs 9 in der Version 1.6.6 eingesetzt. Specs wurde als Alternative zu JUnit 10 entwickelt, um Java- oder Scala-Projekte zu spezizieren und zu testen [Ano10]. Dieses Framework eignet sich zum Erstellen und berprfen einer Spezikation. Zuerst wird ein Objekt deniert, dass von der Klasse Specification abgeleitet ist [Bra10, S. 242], was das Listing 5.20 darstellt.9 10

http://code.google.com/p/specs/ http://www.junit.org/

Christoph Schmidt

Seite 43 von 49

5. Implementierung


Listing 5.20: Das Objekt DozentManagementSpecs object DozentManagementSpecs extends Specification( "Doz

Entwicklung einer Webapplikationzur Unterstützung der Lehr- und Stundenplanung

Documents

Transcript of Entwicklung einer Webapplikationzur Unterstützung der Lehr- und Stundenplanung