Sie sind auf Seite 1von 52
Bachelorarbeit Entwicklung einer Webapplikation zur Unterstützung der Lehr- und Stundenplanung Zur Erlangung des

Bachelorarbeit

Entwicklung einer Webapplikation

zur Unterstützung der Lehr- und Stundenplanung

Zur Erlangung des akademischen Grades eines Bachelor of Science - Informatik-

Fakultät Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl. Math. Gerd Recknagel

eingereicht von:

Christoph Schmidt Matr.-Nr. 281094 Leitenstraße 8 97795 Schönderling

Inhaltsverzeichnis

1 Einführung

1

1.1 Motivation

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1.2 Zielsetzung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

1.3 Das SPIRIT-Projekt

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

2

2 Grundlagenbetrachtung

 

4

2.1 Scala .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

4

2.1.1 OOP versus funktionale Programmierung

 

4

2.1.2 Besonderheiten

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

2.2 Lift .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.2.1 Architektur

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.2.2 Lift Core und Lift Web

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

2.2.3 Persistenz

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

2.2.4 Projektstruktur

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

2.2.5 Konfiguration

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

3 Analyse

17

3.1 Zielsystem

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

3.2 Benutzeranalyse

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

3.3 Anwendungsfälle

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

3.3.1 Lehrplanungsprozess

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

3.3.2 Arbeitszeiterfassungsprozess

 

20

4 Design

21

4.1 Drei-Schichten-Architektur .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.2 Vier-Schichten-Architektur .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.3 Softwarekomponenten .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.4 Konkretes Design

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

4.4.1 Datenhaltung

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

4.4.2 Anwendungskern

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

5 Implementierung

 

29

5.1 Entwicklungsumgebung und Buildtools

 

29

5.1.1 IntelliJ

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

5.1.2 Simple-Build-Tool .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

5.2 Menü und Zugriffskontrolle

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

5.2.1 FhS-LDAP-Module

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

5.2.2 SiteMap

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

32

5.3 Persistenz und Transformation .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

33

Inhaltsverzeichnis

Fachhochschule Schmalkalden SS 2011

 

5.4 Lehrveranstaltungsverwaltung und Planung

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

5.4.1 Template Method-Muster

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

36

5.4.2 Umsetzung des Template Method-Musters

 

37

5.4.3 Planungsprozess

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

5.5 Arbeitszeitverwaltung .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

40

5.6 Testfälle

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

43

6

Fazit und Ausblick

 

45

Literaturverzeichnis

 

47

Eidesstattliche Erklärung

 

49

1 Einführung

Diese Arbeit beschäftigt sich mit der Implementierung einer Web-Anwendung zur Unterstützung der Lehr- und Stundenplanung an der Fachhochschule Schmalkalden, welche auf Scala 1 und Lift 2 basieren soll. Für das Verständnis der Arbeit werden Kenntnisse in Scala vorausgesetzt.

1.1 Motivation

In den vergangenen Jahren hat sich das Internet stark weiterentwickelt. Vom ur- sprünglichen Gedanken wissenschaftliche Dokumente auszutauschen, spricht heute kaum noch jemand. Hört man heute Menschen über das Internet sprechen, dreht sich alles um soziale Netzwerke, Blogs, Wikis und Podcasts. Der Erfinder des Inter- nets, Tim Berners-Lee, äußert sich folgendermaßen über seine Erfindung:

“The web is more a social creation than a technical one. I designed it for a social effect - to help people work together - and not as a technical toy.” [Gre08] Dabei lässt sich noch ein weiterer Trend beobachten. Anwendungen, die früher auf Desktop-Computern installiert waren, verlagern sich immer mehr in das Internet und bieten eine Möglichkeit interaktiv an Projekten zu arbeiten, wie es vorher nur schwer möglich war. Ein Beispiel hierfür ist der von Google Inc. angebotene Dienst Google Docs. Mit diesem ist es möglich Präsentationen oder Textdokumente zu er- stellen, welche von mehren Benutzern gemeinsam bearbeitet werden können. Dabei erinnert das Arbeiten stark an herkömmliche Desktop-Anwendungen. Auch die dafür benötigten Technologien haben sich in den letzten Jahren stark wei- terentwickelt. Gerade im Bereich der Programmierung sind weitere Trends erkenn- bar. Es sind neue Sprachen entstanden, die die Objektorientierung mit Konzepten der funktionalen Programmierung vereinen. Auch das European Research Council 3 erkannte diesen Trend und förderte die Wei- terentwicklung der Sprache Scala mit einem Betrag in Höhe 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 Sicherheitslücken, welche von der OWASP 4 herausgegeben wurde, wie Injection 5 oder Cross-Site Scripting 6 von vornherein ausschließt [Pol11a].

1 Scala ist eine objekt-funktionale Programmiersprache. 2 Lift ist ein in Scala programmiertes Web-Framework. 3 http://erc.europa.eu/ 4 OWASP steht für Open Web Application Security Project. 5 Injection bezeichnet das Ausnutzen einer Sicherheitslücke in Verbindung mit einer Datenbank. 6 Cross-Site Scripting ist eine Sicherheitslücke bei der es möglich ist schadhaften Quellcode durch Formulareingaben in Webseiten zu platzieren.

1. Einführung

Fachhochschule Schmalkalden SS 2011

1.2 Zielsetzung

Wie einführend erwähnt ist das Ziel dieser Arbeit die Entwicklung einer Web- Anwendung mit dem Namen PlanningWeb zur Unterstützung der Lehr- und Stun- denplanung. Eine der Hauptaufgaben besteht darin, eine gemeinsame Plattform für die Planung des Curriculums und Stundenplanung zu schaffen, um den Arbeitsauf- wand zu minimieren. Die für diese Aufgaben bisher eingesetzten Programme liegen als reine Desktop- Anwendung vor, welche auf Basis der deklarativen Sprache Prolog implementiert wurden. Allerdings können diese die über die Jahre gewachsenen Anforderungen nicht mehr im vollen Maße erfüllen. Darüber hinaus werden die bislang eingesetzten Programme von neueren Windows-Versionen wie Windows 7 nicht mehr unterstützt, was für die Zukunft mit einer internetfähigen Version vermieden werden soll. Um dies zu erreichen, sollen die Möglichkeiten 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 un- tersuchen, wie eine datenbankunabhänige Speicherung erzielt werden kann, um sich auch hier nicht zu stark an ein Datenbank-Produkt zu binden. Für die Darstellung der einzelnen Dialoge sollen herkömmliche Elemente wie Text- felder, Check-Boxen und Buttons eingesetzt werden. Für die grafische Darstellung wird weitestgehend das Standard-CSS des Frameworks verwendet, da dies nicht Be- standteil der Arbeit ist.

1.3 Das SPIRIT-Projekt

Die hier durchgeführte Arbeit findet ihm Rahmen des SPIRIT-Projekts der Fach- hochschule Schmalkalden an der Fakultät Informatik statt. Dieses Projekt beschäf- tigt sich mit der Neuimplementierung der Stundenplanungstools sowie dazugehöriger Applikationen.

Abbildung 1.1: SPIRIT-Projekt

Stundenplanungstools sowie dazugehöriger Applikationen. Abbildung 1.1: SPIRIT-Projekt Christoph Schmidt Seite 2 von 49

1. Einführung

Fachhochschule Schmalkalden SS 2011

Abbildung 1.1 zeigt eine grobe Strukturübersicht der einzelnen Projekte und ihr Zusammenspiel. Das EmployeeWeb wird, genau wie dieses Projekt, mit Scala und Lift realisiert. Es dient dazu Dozenten eine Möglichkeit zu geben, Informationen, die die Studieren- den betreffen, in Spirit einzustellen. Diese Informationen werden den Studierenden über das StudWeb zugänglich gemacht, wobei der Datenaustausch der Anwendun- gen ü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 für die Zukunft geplant beide Applikationen in einer zu vereinen. Weiterführende Informationen zu diesem Projekt sind auf der Projektseite 7 oder auf Github 8 zu finden.

7 http://pads.fh-schmalkalden.de/spirit.html

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

2 Grundlagenbetrachtung

In 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 gegenübergestellt um darauf aufbauend die Besonderheiten der Sprache darzustel- len. Nachdem Scala ausreichend vorgestellt wurde, wird auf das Lift-Framework eingegangen. Im Zuge dessen wird auch die Architektur des Frameworks untersucht.

2.1 Scala

Der Startschuss für Scala fiel 2001 an der Ècole polytechnique fèdèrale de Lausanne in der Schweiz unter der Leitung von Professor Martin Odersky. 2003 wurde das erste Release veröffentlicht. Anschließend 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 verfügbar. Vor der Entwicklung von Scala arbeitete Martin Odersky bereits an einer Sprache, die die Objektorientierung mit Konzepten der funktionalen Programmierung verei- nen sollte. Es entstand Funnel 1 . Diese Sprache war aus Sicht eines Sprachentwicklers sehr “rein”. Sie besaß lediglich ein paar primitive Spracheigenschaften. Fast alles, einschließlich Klassen, wurde durch Bibliotheken realisiert. Es stellte sich allerdings heraus, das eine Sprache nur dann akzeptiert wird, wenn sie eine große Anzahl an Standard Bibliotheken bereitstellt. Aus den Ideen von Funnel entstand schließlich 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 Programmierung

Der in der Mathematik verwendete Begriff einer Funktion spielt in der funktiona- len Programmierung eine zentrale Rolle, da diese auf dem dort verwendeten Begriff basiert. Die Eingabewerte stellen dabei den Definitionsbereich einer Funktion dar. Die Funktion wiederum bildet diese auf Rückgabewerte, 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 zurückgeben. Ein weiterer elementarer Bestandteil von funktionalen Sprachen sind Funktionen höherer Ordnung. Darunter versteht man Funktionen, welche als Eingabeparameter

1 http://lampwww.epfl.ch/funnel/

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

selbst wiederum Funktionen erwarten, wodurch letztlich ein Großteil an Produkti- vität dieses Programmierparadigmas erzielt wird [PH06, S. 23 f.]. In diesem Zusammenhang taucht häufig der Begriff der anonymen Funktionen auf. Diese werden oft als Argumente für Funktionen höherer Ordnung eingesetzt. Sie kön- nen deshalb direkt aufgeschrieben werden, ohne ihnen eine Bezeichnung zu geben [PH06, S. 14]. Im Gegensatz zur funktionalen Programmierung steht in der objektorientierten Pro- grammierung der Objektbegriff im Vordergrund. Ein Objekt repräsentiert 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 ausgedrückt wird [Hom02, S. 4]. Eine Klasse wiederum bildet eine Vorlage für ein Objekt und ist somit ein Objekttyp. Die Gemeinsamkeiten einer Menge von Objekten werden daher in Klassen zusam- mengefasst und spezifiziert. Daraus folgt, dass Objekte als Instanzen einer Klasse bezeichnet werden [Hom02, S. 6]. Durch das Konzept der Kapselung bleiben Implementierungsdetails hinter spezifi- zierten Schnittstellen verborgen, was dazu führt, dass die Darstellung eines Objekts nur entsprechend seiner Spezifikation genutzt werden kann [Hom02, S. 5].

2.1.2 Besonderheiten

Scala gilt als Hybrid-Sprache, da sie Merkmale der objektorientierten und funktio- nalen Welt vereint. Scala-Quellcode wird in Java-Bytecode umgewandelt, was es so problemlos ermöglicht Java-Code zu integrieren. Außerdem ist Scala eine rein objek- torientierte Programmiersprache, da jeder Wert ein Objekt repräsentiert. Darüber hinaus ist diese Sprache im Vergleich mit anderen modernen Vertretern ihrer Art statisch typisiert, was dazu führt, dass der Typ aller Ausdrücke bereits zur Kompi- lierzeit überprüft wird und so unerwünschte Typfehler ausschließt [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 kürzer als ein vergleichbares Programm in Java. Weniger Zeilen an Quellcode bedeutet aber nicht nur weniger Schreibarbeit sondern fördert auch die Lesbarkeit und Verständlichkeit des Quellcodes. Darüber hinaus be- deuten weniger Zeilen auch potenziell weniger Fehler im Programm selbst. Es gibt einige Faktoren die dazu beitragen die Anzahl an Zeilen des Quellcodes zu verrin- gern. Beispielsweise vermeidet die Syntax von Scala einiges an Standardformulierungen, welche Java-Programme belasten. Semikolons sind optional und können in den meis- ten Fällen einfach weggelassen werden. Es gibt viele weitere Bereiche, in denen die Scala-Syntax übersichtlicher ist. Bei Betrachtung von Klassendefinitionen mit Kon- struktoren fällt dies besonders auf, was die nachfolgenden Beispiele, Listing 2.1 und Listing 2.2 darstellen sollen. Das erste Listing stellt die Definition einer Java-Klasse dar.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Listing 2.1: Java-Klasse mit Konstruktor

class

A

{

private

int

x;

private

String

y;

}

public A(int x, this.x = x; this.y = y;

}

String

y)

{

Im zweiten Listing ist die Definition einer Scala-Klasse zu sehen und wie unschwer zu erkennen ist, ist diese sehr viel kürzer und übersichtlicher. Allerdings besitzt diese Definition exakt die gleiche Funktionalität wie die zuvor dargestellte Klassendefini- tion.

Listing 2.2: Scala-Klasse mit Konstruktor

class

A(x:

Int ,

y:

String)

Ein weiterer Grund für die Knappheit von Scala ist auf ihre Typinferenz 2 zurückzu- führen. Typangaben können 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. Für diese Zwecke stellt Scala viele Werkzeuge zur Verfügung, um leistungs- starke Bibliotheken zu erzeugen. Viele Aspekte von Bibliotheken können in Traits ausgelagert werden, welche dann flexibel zusammengesetzt werden können. Dar- über hinaus können Bibliotheksfunktionen mit Operationen parametrisiert werden, welche es ermöglichen Konstrukte zu definieren, die schlussendlich eigene Kontroll- strukturen darstellen. Diese Konstrukte ermöglichen es Bibliotheken zu definieren, welche zugleich hochrangig als auch flexibel zu nutzen sind [OSV10, S. 13 ff.].

Kompatibilität Wie bereits angesprochen ist Scala kompatibel zu Java 3 . Scala erzeugt JVM-Bytecode, dessen Laufzeitleistung dem von Java Programmen entspricht. Aus Scala heraus kön- nen Java Methoden aufgerufen und auf Felder zugegriffen werden, die sich in Java Klassen befinden. Außerdem können Java Interfaces implementiert werden. All das erfordert keine spezielle Syntax. Ein weiterer Grund für die Zusammenarbeitsfähigkeit besteht darin, dass Scala die Java Typen wiederverwendet. Es werden z. B. die von Scala verwendeten Ints als primitive Integer von Java’s ints dargestellt. Außerdem 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 kom- fortabler zu nutzen.

2 Durch Typinferenz kann an einigen Stellen auf Typangaben verzichtet werden, da der entspre- chende Typ durch Typisierungsregeln hergeleitet werden kann. 3 Es gibt auch eine Scala Variante die auf der .NET Plattform läuft, allerdings wird die JVM Variante derzeit besser unterstützt.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Scala Quellcode kann auch aus Java heraus aufgerufen werden, was allerdings nicht so einfach möglich ist, da Scala eine reichhaltigere Sprache ist als Java. Deshalb müs- sen einige modernere Eigenschaften umgewandelt werden bevor sie in Java genutzt werden können [OSV10, S. 12 f.].

Hochsprache Scala ermöglicht es den Abstraktionsgrad zu erhöhen, was dazu führt, dass der Fokus bei der Programmierung stärker auf das Problem selbst gelegt werden kann, um so ein Ziel besser zu erreichen, da zu komplexer Quellcode oft zu einem Aus für ein Software-Projekt führen kann. Dies soll nachfolgendes Beispiel verdeutlichen, welches überprüft ob eine Zeichenkette, die durch die Variable name repräsentiert wird, Großbuchstaben enthält oder nicht.

Listing 2.3: Beispiel Java

/* Programming in Scala: Second Edition S. 15 */

boolean

for

(int

nameHasUpperCase

= false;

i=0;

i

< name.length(); ++i) {

if (Character.isUpperCase(name.charAt(i))) {

nameHasUpperCase

break;

}

}

= true;

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 angegan- gen werden kann. Es müssen nicht, wie bei Java, unübersichtliche Schleifen program- miert werden, was letztendlich auf die Eleganz der funktionalen Programmierung zurückzuführen ist [OSV10, S. 15 f.].

Eine wachsende Sprache Programme verschiedener Größe tendieren dazu, unterschiedliche Programmierkon- strukte zu benötigen. Hierfür besteht in Scala die Möglichkeit, bestehende Konstruk- te individuell an eigene Belange anzupassen. Das wird möglich, da diese Gebilde nicht fest in der Sprachsyntax verankert sind. Sie sind Bibliotheksabstraktionen, die erweitert oder adaptiert werden können. Es ist beispielsweise denkbar von ei- ner Standard Map ausgehend eine speziellere Map zu implementieren, wie etwa eine HashMap oder TreeMap. In jedem Fall ist es aber potenziell möglich die gleiche Ein- gangssyntax einer Map zu verwenden. Dies gilt auch für die in der Sprache eingesetzten Typen, welche zwar wie fest einge-

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

baute Typen erscheinen, aber dennoch nur als Klassen der Scala standard Bibliothek 4 vorliegen. All diese Eigenschaften ermöglichen es vollkommen neue Abstraktionen zu schaffen, mit deren Hilfe neue anwendungsspezifische Sprachen entwickelt werden können, welche sich sehr weit einer natürlichen Sprache annähern [OSV10, S. 4 ff.]. 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
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
case
/*
1 => "Sunday"
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 Weiterführende Informationen zur Scala standard Bibliothek sind unter http://www.scala- lang.org/api/current/index.html#package zu finden.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Die hier dargestellte domain specific language, kurz DSL, berechnet zu einem Ge- burtstag den entsprechenden Wochentag. Dabei ist es möglich 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
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 ein- fach durch and anhängen lassen. Das hier dargestellte Beispiel würde als Wochentag einen Dienstag berechnen. Um das erreichen zu können, liefert birthday(16,8,1985) ein Objekt der Klasse Date zurück. Auf diesem Objekt wird anschließend die plus Methode aufgerufen. Der an diese Methode übergebene Zahlenwert wird in der Va- riablen last gespeichert. Die plus Methode gibt sich, also das Objekt, anschließend selbst zurück, worauf die years Methode angewendet wird. Mit Hilfe des Wertes and, welcher eine Instanz der Klasse Conjunction ist, lassen sich dann beliebig vie- le Rechenoperationen anhängen. Das zuvor dargestellte Beispiel dient lediglich der Veranschaulichung der Erweiter- barkeit von Scala. Es lässt sich daraus ableiten, wie die dort genutzten und zuvor vorgestellten Konzepte hierzu beitragen.

2.2 Lift

Lift ist ein Framework mit dessen Hilfe Webapplikationen mit Scala realisiert wer- den können. Dabei handelt es sich um ein Full Stack Web Application Framework. Dies bedeutet, dass Lift alles, was für die Entwicklung von Web-Applikationen be- nötigt wird, mitbringt [Bra10, S. 253]. Das Framework wurde entwickelt um sichere, performante und leicht wartbare Applikationen zu entwickeln [Per11, S. 5].

2.2.1 Architektur

Lift 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, möglich 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 An- schluss näher erläutert werden.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Abbildung 2.1: View First Design

Schmalkalden SS 2011 Abbildung 2.1: View First Design View Innerhalb des View First Kontext bezieht sich

View Innerhalb des View First Kontext bezieht sich View primär auf XML Inhalte, die bei einer Seitenanfrage benötigt werden. Innerhalb von Lift-Anwendungen gibt es grundsätzlich zwei Arten von Views:

Template Views, die dynamische Inhalte in vordefinierte Markup Templates binden [Per11, S. 9].

Erzeugte Views, in welchen typischerweise dynamische Inhalte mittels Scala XML Ausdrücken erzeugt werden [Per11, S. 9].

Template Views werden üblicherweise dafür eingesetzt um Inhalte einer View zu erzeugen. Dies setzt allerdings ein korrekt formatiertes XHTML oder HTML5 Tem- plate voraussetzt, da es in Lift nicht möglich ist Views einzusetzen, welche Forma- tierungsfehler aufweisen. Erzeugte Views sind weitaus weniger üblich, sie werden aber manchmal für eine schnelle Prototypenentwicklung verwendet. Als eine der Lift Hauptideen gilt, dass Views für mehr als eine einzige Aufgabe ein- gesetzt werden können. Das trägt dazu bei, um redundanten Quellcode innerhalb einer Anwendung zu verringern und ermöglicht 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 typi- scherweise 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!</strong >

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Listing 2.7 stellt eine Scala Klasse dar, welche eine Snippet Methode hallo definiert, die als CSS Transformer bezeichnet wird. Das sind im wesentlichen Funktionen, die als Eingabeparameter ein Element vom Typ NodeSeq 5 erwarten und auch ein Ele- ment von NodeSeq zurückliefern. Diese werden durch das Importieren des Helpers Objektes unterstützt, welches eine entsprechende implizite Typumwandlung beinhal- tet [Per11, S. 36].

Listing 2.8: Hallo-Welt Template

<!--

-->

<body

class="lift:content_id=main">

<div

id="main"

content">

class="lift:surround?with=default;at=

<p

</div>

lift="HalloWelt.hallo">Ersetze

</body>

<!--

-->

mich!</p>

In Listing 2.8 ist ein Template dargestellt, welches die zuvor definierte hello Me- thode benutzt. Mittels des Schlüsselworts lift wird die Methode hallo der Klasse HalloWelt aufgerufen und das entsprechende Tag ersetzt. Da Snippet Klassen Darstellungsfunktionen beinhalten muss es eine Möglichkeit ge- ben um Textfelder, Check-Boxen oder Buttons zu erstellen. Für 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 Per- sistenz oder der Daten dar. Für gewöhnlich wird an dieser Komponente ein konkreter Wert nachgefragt, den diese dann zurückliefert [Per11, S. 10].

2.2.2 Lift Core und Lift Web

Lift besitzt zwei Module, die einen zentralen Teil des Frameworks ausmachen. Diese werden als Core und Web bezeichnet. Der Core setzt sich aus vier einzelnen Pro- jekten zusammen. Diese beinhalten Bibliotheken, die sowohl mit als auch ohne das Web Modul in Projekten eingesetzt werden können. Das Web Modul selbst baut drauf auf und unterstützt die komplexen Komponenten von Lift um sichere und skalierbare Web-Anwendungen realisieren zu können. Das Web Modul setzt sich aus drei Teilprojekten zusammen: Das Basis Web System und zwei zusätzliche Projekte, die spezielle Helfer zur Verfügung stellen [Per11, S. 12]. Abbildung 2.2 zeigt eine Übersicht der einzelnen Bestandteile, welche im Anschluss näher erläutert werden.

5 NodeSeq ist in Scala eine Sequenz von XML Knoten.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Abbildung 2.2: Module Lift Core/Web

Schmalkalden SS 2011 Abbildung 2.2: Module Lift Core/Web Lift Common Dieses Modul beinhaltet eine Menge an

Lift Common Dieses Modul beinhaltet eine Menge an Basisklassen, die überall in Lift eingesetzt werden können. Darüber hinaus können diese auch in Projekten genutzt werden, die keine Web-Anwendungen darstellen [Per11, S. 12]. Weiterführende Informationen zu diesem Paket sind in der API-Dokumentation 6 unter net.liftweb.common zu finden.

Lift Actor Actor beschreibt ein Modell der nebenläufigen Programmierung. Im Scala-Umfeld gibt es zahlreiche verschiedene Implementierungen hierzu. Lift besitzt seine Eigene, speziell für 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 ent- wickelt wurden um einen komfortablen Mechanismus zur Verfügung zu stellen, um mit häufig genutzten Paradigmen zu arbeiten [Per11, S. 13]. Ein genauer Überblick ist im Paket net.liftweb.util zu finden.

Lift JSON Lift JSON stellt ein eigenständiges Paket dar, dass es ermöglicht mit JSON 7 auf eine sehr ressourcenschonende Art zu arbeiten. Im Vergleich mit dem JSON Parser, welchen Scala verwendet, ist dieser ungefähr 350 mal so schnell. Darüber hinaus stellt Lift eine durchdachte DSL für 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 zusam- men. Es ist das wichtigste Modul von Lift [Per11, S. 14].

6 http://scala-tools.org/mvnsites/liftweb-2.3 7 JSON ist ein Kurzwort für JavaScript Object Notation.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

2.2.3 Persistenz

Eine der Hauptaufgaben von Web-Anwendungen befasst sich mit der dauerhaften Speicherung von Daten. Für diese Zwecke stellt Lift ein Mapper und Record Frame- work zur Verfügung. Diese Frameworks stellen ein Gerüst für jegliche Datenmani- pulation bereit. Mapper stellt das ursprüngliche Persistenz-Framework dar, welches eng mit JDBC 8 verknüpft ist [CBDW11, S. 89]. Auf diese Art und Weise stellt Lift verschiedene Optionen zur Verfügung um Daten zu speichern. Dabei ist es irrelevant ob es sich bei der zu Grunde liegenden Technologie um ein relationales Datenbank- managementsystem (RDBMS) oder eine NoSQL 9 Lösung handelt [Per11, S. 16].

Abbildung 2.3: Struktur der Lift-Persistenz

[Per11, S. 16]. Abbildung 2.3: Struktur der Lift-Persistenz Abbildung 2.3 illustriert eine strukturelle Übersicht der

Abbildung 2.3 illustriert eine strukturelle Übersicht der Persistenz. Im Anschluss werden die wichtigsten Bestandteile näher ausgeführt.

DB/Mapper Mapper bieten eine einheitliche Möglichkeit um mit persistenten Daten zu arbeiten. Das Framework stellt einen O/R-Mapper 10 bereit, welcher alle relationalen Bezie- hungen 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]. Wei- terführende Informationen sind im Paket net.liftweb.mapper zu finden.

Lift JPA Die Java Persistence API ist im Java Umfeld weit verbreitet. Daher wurde diese zu Lift hinzugefügt und an Scala angepasst [Per11, S. 17]. Alle relevanten Daten sind im Paket net.liftweb.jpa bereitgestellt.

Lift Record Die Records repräsentieren eine Sicht, die dem Benutzer Create, Read, Update und Delete Semantik für die Datenmanipulation bereitstellt. Außerdem 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].

8 JDBC ist eine Datenbankschnittstelle der Java-Plattform. 9 NoSQL: Steht für englisch Not only SQL. 10 O/R Mapper bezeichnet eine Programmiertechnik um Daten zwischen inkompatiblen Typ- Systemen zu transformieren. 11 SQL Join Anfrage kombiniert Datensätze zweier oder mehrerer Tabellen einer Datenbank.

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

2.2.4 Projektstruktur

In diesem Abschnitt wird die Projektstruktur einer Lift-Anwendung vorgestellt. Da- bei 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 vor- gestellt wird. In diesem Ordner ist auch eine Datei LiftProject.scala zu finden.

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

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

Sie beinhaltet beispielsweise Abhängigkeiten wie benötigte Repositories und wird mit Hilfe von Scala konfiguriert [Per11, S. 31]. In der Datei resources/props/default.props können Properties definiert werden, auf welche dann in der Anwendung zugegriffen werden kann. Sie enthält normaler- weise keine Einträge. Das Verzeichnis scala beherbergt die eigentlichen Scala-Dateien der Anwendung. Es ist mit verschiedenen Unterverzeichnissen ausgestattet um das Projekt zu strukturie- ren. Die Datei bootstrap/liftweb/Boot.scala wird beim booten der Anwendung genutzt und wird in Abschnitt 2.2.5 näher ausgeführt. Alle anwendungsspezifischen Klassen und Objekte befinden sich im Verzeichnis code. Alle sonstigen für die Anwendung wichtigen Dateien wie Bilder, statische HTML- Seiten und Templates werden im Verzeichnis src/main/webapp aufbewahrt [Bra10, S. 256].

2.2.5 Konfiguration

Bevor Lift eine Anwendung startet müssen einige Dinge konfiguriert werden, so dass überhaupt eine Anfrage ausgeführt werden kann. Der Lift Servlet 13 sucht nach einer Klasse bootstrap.liftweb.Boot und führt dessen boot Methode aus. Diese Me- thode wird nur einmalig ausgeführt 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 näher ausgeführt wird. Als Erstes wird mit dem StandardDBVendor Objekt eine Datenbankverbindung her- gestellt, welches eine H2-Datenbank 14 verwaltet [Bra10, S. 257]. Anschließend wird mit Hilfe des LiftRules Objektes der unloadHooks Collection eine Funktion angehängt, die für das Schließen aller Datenbankverbindungen ver- antwortlich ist. Diese wird ausgeführt, wenn die Anwendung heruntergefahren wird [Bra10, S. 258]. Durch den Schemifier kommt ein Teil des O/R-Mappers zum Einsatz. Durch des- sen schemify Methode wird gewährleistet, dass die Datenbank das korrekte Schema eines User Objektes besitzt, um User zu speichern [Bra10, S. 258]. Ein User-Objekt könnte wie in der in Abschnitt 2.2.4 eingeführten Beispiel-Anwendung aufgebaut sein, welches in der Datei code/model/User.scala zu finden ist. In der anschließenden Zeile wird Lift mittels LiftRules.addToPackages("code") bekannt gegeben, in welchem Paket das Framework nach Quellcode, z. B. für Snip- pets, suchen soll [Bra10, S. 258]. Dann wird die Menüsteuerung implementiert, was durch die Methode sitemap er- zielt wird. An dieser Stelle sei erwähnt, dass Lift bereits über eine eingebaute Menü- steuerung und Zugriffsverwaltung verfügt, deren Funktionsweise im Kapitel 5.2 nä- her erläutert 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

2. Grundlagenbetrachtung

Fachhochschule Schmalkalden SS 2011

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 repräsentiert den Zustand der aktuellen Anfrage. Es wird beispielsweise benutzt, um Informationen abzufragen und um Informatio- nen, die in der Antwort gesendet werden, zu modifizieren. Es kann unter ande- rem auch für das Cookie-Management oder für eine Redirection verwendet werden [CBDW11, S. 25].

LiftRules Das Objekt net.liftweb.http.LiftRules wird eingesetzt um die globale Konfigu- ration eines Lift-Projekts zu realisieren. Alles was in Lift konfiguriert werden kann wird über Variablen dieses Objekts umgesetzt [CBDW11, S. 25].

3 Analyse

In Zusammenarbeit mit dem Studiendekan und Stundenplaner der Fakultät Infor- matik wurde die bisherige Planungssoftware zum Erfassen und Planen des Curricu- lums untersucht um daraus die grundsätzlichen Anforderungen an eine webbasierte Neuimplementierung mit dem Namen PlanningWeb abzuleiten. Die daraus resultie- renden Ergebnisse werden in den folgenden Abschnitten vorgestellt. Der Analyse- prozess wurde in Anlehnung an [OB09, S. 89 ff.] durchgeführt.

3.1 Zielsystem

PlanningWeb ist eine Software, die den Studiendekan in allen wichtigen Anwen- dungsfällen der Lehrplanung unterstützt. Die daraus resultierenden Ergebnisse bil- den die Grundlage für die Stundenplanung des jeweiligen Semesters. Darüber hinaus soll das System den Stundenplaner bei der Erfassung der Arbeitszeiten und Raum- wünsche der Dozenten unterstützen. Es können Dozenten, Studiengänge, Lehrveranstaltungen und Räume mit allen pla- nungsrelevanten Daten erfasst, geändert und gelöscht werden. Nach Abschluss der Lehrplanung können die Ergebnisse des Planungsprozesses für das externe Stunden- planungssystem bereitgestellt werden. Außerdem können sich Dozenten am System anmelden um Arbeitszeit- oder Raumwünsche zu äußern, die der Stundenplaner an- schließend im Planungsprozess berücksichtigen kann. Die Software verfügt über eine Zugriffskontrolle, mit der es möglich ist Benutzer am System anzumelden. Die Authentifizierung wird mit Hilfe einer gültigen FHS-ID 1 unter Zuhilfenahme des FH internen LDAP 2 -Servers durchgeführt. Der Kern der Anwendung setzt einen Server mit Unix/Linux oder Windows als Betriebssystem voraus. Auf ihm muss ein Application-Server wie Jetty oder Tom- cat installiert und konfiguriert sein. Der Anwendungsserver muss sich im Netz der Fachhochschule befinden. Das System ist datenbankunabhägig und kann sowohl mit NoSQL 3 - als auch relationalen Datenbanken betrieben werden. Die Anwendung wird von allen gängigen Internetbrowsern unterstützt und ermög- licht plattformunabhäniges Arbeiten.

3.2 Benutzeranalyse

Nachdem im vorangegangen Abschnitt das Zielsystem beschrieben wurde, sollen hier die späteren Benutzer analysiert und klassifiziert werden. Aus den Gesprächen

1 FHS-ID ist eine von der FH vergebene ID zur eindeutigen Identifizierung. 2 LDAP: Lightweight Directory Access Protocol [Sem06]. 3 NoSQL: Steht für englisch Not only SQL.

3. Analyse

Fachhochschule Schmalkalden SS 2011

mit dem Studiendekan und Stundenplaner lassen sich grundsätzlich drei Benutzer- gruppen 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

dass die Daten einer Abbildung 3.1: Systemkontextdiagramm bestimmten Benutzergruppe von anderen Benutzergruppen

bestimmten Benutzergruppe von anderen Benutzergruppen gelesen oder manipuliert werden, ist es notwendig für die einzelnen Benutzergruppen Rollen zu vergeben. Dies sind:

Lehrplaner mit Zugriff auf Dozenten, Studiengänge und Lehrveranstaltun- gen.

Stundenplaner mit Zugriff auf Arbeitszeiten der Dozenten, Räume und durch den Lehrplaner freigegebene Lehrveranstaltungen zur Stundenplanung.

Dozent mit Zugriff auf eigene Arbeitszeiten und Wunschräume.

Administrator mit Zugriff auf alle Daten.

3.3 Anwendungsfälle

Durch die Klassifizierung der Benutzer im Abschnitt 3.2 ist es möglich entsprechend den Rollen Anwendungsfälle abzuleiten. Diese ermöglichen es die Hauptaufgabe des Systems darzustellen um im weiteren Verlauf ein flexibles Design entwerfen zu kön- nen. [OB09, S. 114]. Es werden nur die Anwendungsfälle des Planungsprozesses und der Arbeitszeiterfassung von Dozenten als Essenzbeschreibung 4 dargestellt, da diese für das weitere Verständnis von wesentlicher Bedeutung sind.

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

3. Analyse

Fachhochschule Schmalkalden SS 2011

3.3.1 Lehrplanungsprozess

Die Planung des Curriculums umfasst mehrere Schritte. Sie beginnt mit dem Zu- weisen einer Veranstaltung zu einem Semester, wie in Tabelle 3.1 dargestellt.

Tabelle 3.1: Anwendungsfall Lehrveranstaltung Semester zuweisen

Name

Lehrveranstaltung Semester zuweisen

Kurzbeschreibung

Der Lehrplaner weist Lehrveranstaltung einem Semester zu.

Auslöser

Es ist eine neue Lehrplanung für Sommer- oder Wintersemester erforderlich

Akteur

Der Lehrplaner.

Vorbedingung

Es ist mindestens eine Lehrveranstaltung im System vorhan- den.

Nachbedingung

Lehrveranstaltung wurde einem Semester zugewiesen.

Essenzielle Schritte

alle Lehrveranstaltungen anzeigen; gewünschte Lehrveranstal- tung Semester zuweisen; Änderungen speichern; Speicherung bestätigen

Anschließend besteht die Möglichkeit Vorlesungsgruppen zu erstellen, um die einzel- nen 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 möglich Übungsgruppen für ei- ne Lehrveranstaltung anzulegen. Da dieser Anwendungsschritt aber analog zu dem Erstellen einer Vorlesungsgruppe zu sehen ist, wird dieser Anwendungsfall nicht ex- plizit aufgeführt.

Tabelle 3.2: Anwendungsfall Vorlesungsgruppe erstellen

Name

Vorlesungsgruppe erstellen

Kurzbeschreibung

Der Lehrplaner erstellt eine Vorlesungsgruppe für eine Lehr- veranstaltung.

Auslöser

Die Anzahl der Teilnehmer einer Lehrveranstaltung ist zu groß und soll daher mehrfach angeboten werden.

Akteur

Der Lehrplaner.

Vorbedingung

Es ist mindestens eine Lehrveranstaltung im System vorhan- den.

Nachbedingung

Vorlesungsgruppe wurde für eine Lehrveranstaltung erstellt.

Essenzielle Schritte

eine Lehrveranstaltung auswählen; Studiengänge einer Lehr- veranstaltung mit zugehörigem Semester anzeigen; Studien- gänge mit entsprechendem Semester auswählen, alle Dozen- ten für Lehrveranstaltung anzeigen, die diese Vorlesung hal- ten; ein oder mehrere Dozenten auswählen; Vorlesungsgruppe speichern; Speicherung bestätigen

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

3. Analyse

Fachhochschule Schmalkalden SS 2011

dem Stundenplaner als Basis für die entsprechende Stundenplanung. Der zugehörige Anwendungsfall ist in Tabelle 3.3 dargestellt.

Tabelle 3.3: Anwendungsfall Semesterplanung

Name

Semesterplanung

Kurzbeschreibung

Der Lehrplaner generiert die konkreten Vorlesungen und Übungen für alle Lehrveranstaltungen eines bestimmten Se- mesters.

Auslöser

Die Planung des Curriculums ist abgeschlossen.

Akteur

Der Lehrplaner.

Vorbedingung

Es ist mindestens eine Lehrveranstaltung im System vorhan- den und Sommer- oder Wintersemester zugeordnet.

Nachbedingung

Konkrete Vorlesungen und Übungen sind im System erfasst.

Essenzielle Schritte

Sommer- oder Wintersemester zum Planen auswählen; ent- sprechende Vorlesungen und Übungen aus Lehrveranstaltun- gen generieren; erstellte Vorlesungen und Übungen anzeigen; alle angezeigten Vorlesungen und Übungen speichern; Speiche- rung bestätigen

3.3.2 Arbeitszeiterfassungsprozess

Die Erfassung der Arbeitszeiten und Wunschräume einzelner Dozenten umfasst einen weiteren wichtigen Bestandteil der Anwendung, was in Tabelle 3.4 dargestellt ist. Die dabei erfassten Raum- und Zeitwünsche dienen später dem Stundenplaner als Basis für die Stundenplanung.

Tabelle 3.4: Anwendungsfall Arbeitszeit und Raumwünsche erfassen

Name

Arbeitszeit und Raumwünsche eines Dozenten erfassen

Kurzbeschreibung

Der Dozent wählt aus einer vorgegebenen Menge von Zeiteinheiten Arbeitszeiten aus. Anschließend markiert er Wunschräume für seine zu haltenden Lehrveranstaltungen.

Auslöser

Die Zeiterfassung wurde durch den Stundenplaner freigeschal- tet.

Akteur

Stundenplaner und Dozent.

Vorbedingung

Es ist mindestens ein Dozent mit FHS-ID im System bekannt.

Nachbedingung

Konkrete Arbeitszeiten und Wunschräume des Dozenten sind im System erfasst.

Essenzielle Schritte

Wunsch- u. Kann-Zeiten auswählen; Wunschräume Lehrveran- staltungen zuweisen; prüfen ob ausreichend Arbeitszeiten mar- kiert wurden; wenn ja Speichern; wenn nein, Warnung ausge- ben und Eingaben zurücksetzen

4 Design

Nachdem im vorangegangen Kapitel 3 das Zielsystem genau beschrieben und analy- siert wurde, wird in diesem Abschnitt auf das Design der PlanningWeb-Anwendung eingegangen. Dabei ist festzuhalten, dass die gegebene Aufgabenstellung bereits ei- ne Client/Server-Architektur voraussetzt. Prinzipiell kann die Architektur in ver- schiedene Schichten aufgeteilt werden, um eine Abgrenzung zwischen Funktiona- lität und Aufgaben zu erzielen [Mü05, S. 62]. Im Folgenden wird daher kurz die Drei- und Vier-Schichten-Architektur vorgestellt um darauf aufbauend die Details des PlanningWeb-Designs zu erläutern. Im Bereich der Softwarearchitektur spielt aber nicht nur die Aufteilung eines Softwaresystems in Schichten eine Rolle. Mo- derne Softwaresysteme sind zudem meist in Komponenten aufgeteilt. Daher soll im Anschluss an die Schichtenarchitektur noch der Komponentenbegriff konkretisiert werden.

4.1 Drei-Schichten-Architektur

In dieser Architektur wird die Anwendungs- von der Präsentationslogik getrennt, was zur Folge hat, dass der Client ausschließlich die Präsentationslogik enthält. Die Anwendungslogik wird auf einem Applikationsserver bereitgestellt, die den Client mit dem Datenbank-Server verbindet [Mü05, S. 64 f.].

4.2 Vier-Schichten-Architektur

Im Vergleich zur Drei-Schichten-Architektur ändert sich bei Hinzunahme einer wei- teren Schicht, dass sich die Präsentationslogik vom Client auf einen Webserver ver- schiebt. Die Anwendungslogik ist weiterhin im Applikationserver angesiedelt. Da- durch stellt der Client nur noch eine Schnittstelle für den Benutzer dar, welche die eingegebenen Daten an den Server weiterleitet. Außerdem dient der Client dazu die vom Server angeforderten Daten darzustellen. Durch diese Architektur können browserbasierte Internet-Anwendungen realisiert werden [Mü05, S. 65 f.].

4.3 Softwarekomponenten

Technische Systeme bestehen zumeist aus Komponenten. Im Bereich der Software- entwicklung hat sich jedoch bislang keine allgemein akzeptierte Definition etabliert. Es lassen sich aber allgemeingültige Merkmale darstellen, die eine Komponente kenn- zeichnen [Sie04, S. 42].

4. Design

Fachhochschule Schmalkalden SS 2011

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 können wiederverwendet werden, da sie von der Umgebung in der sie ein- gesetzt werden unabhängig 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 Implemen- tierung [Sie04, S. 43].

4.4 Konkretes Design

Die in Abschnitt 4.2 vorgestellte Architektur lässt sich auch auf die PlanninWeb- Applikation übertragen. Das Anfordern einer Ressource eines Clients vom Server läuft dann folgendermaßen ab:

Client fordert eine Ressource an.

Webserver nimmt die Anfrage entgegen. Anschließend wendet sich der Webser- ver an den Applikationserver um die angeforderten Daten in einer geeigneten Präsentationsform an den Client zurückzusenden.

Applikationserver fordert die benötigten 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 Präsentationsform 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 Applikati- onservers vereint. Das nachfolgende Diagramm 4.1 stellt die einzelnen Komponenten des Systems genauer dar, die im Anschluss ausführlich erläutert werden.

4.4.1 Datenhaltung

Wie in Kapitel 2.2.3 dargestellt, verfügt Lift über ein Mapper und Record Frame- work welches auch in der PlanningWeb-Anwendung zum Einsatz kommt. Allerdings soll das geplante System datenbankunabhänig implementiert werden. Auf Grund dieses Umstandes kann das Framework nur indirekt genutzt werden. Daher befin- den sich im Kern der Anwendung zwei Komponenten persistence und transform. Um die Hintergründe dieser Komponenten zu verstehen sollen erst zwei Entwurfs- muster vorgestellt werden.

4. Design

Fachhochschule Schmalkalden SS 2011

Abbildung 4.1: Komponentendiagramm

Schmalkalden SS 2011 Abbildung 4.1: Komponentendiagramm Active Record Bei diesem Entwurfsmuster enthalten Objekte

Active Record Bei diesem Entwurfsmuster enthalten Objekte sowohl Daten als auch Verhaltenswei- sen. Die meisten dieser Daten sind persistent und müssen daher in einer Datenbank gespeichert werden. Active Record benutzt den klarsten Ansatz um Datenbankzu- griffslogik in einem Anwendungsobjekt unterzubringen. So wissen alle Nutzer wie Daten von der Datenbank gelesen und geschrieben werden können. Daraus folgt auch, dass die Struktur eines Records genau auf die darunterliegen- de Datenbankstruktur abgebildet werden kann. Dieses Muster ist für Anwendungen geeignet, die einen geringen Komplexitätsgrad aufweisen. Allerdings koppelt Acti- ve Record die Anwendungslogik direkt an die Datenbank, was zur Folge hat, dass Designänderungen nur schwer durchzuführen sind [FRF + 03, S. 160 ff.].

Data Mapper Das Data Mapper Muster lässt sich am besten mit Hilfe eines Beispiels erklären. An- genommen es existiert eine Klasse Person und eine zugehörige Klasse PersonMapper. Um ein Personen-Objekt aus der Datenbank zu laden würde ein Client die find Me- thode des Mappers aufrufen. Dieser würde dann das entsprechende Objekt aus der Datenbank holen und als Ergebnis das entsprechende Personen-Objekt zurückgeben. Würde ein Client ein Objekt speichern wollen, würde das Objekt an den Mapper übergeben werden und dieser würde das Objekt in der Datenbank speichern. Dieses Entwurfsmuster kann so implementiert werden, dass für jede Klasse die in der Datenbank gespeichert werden soll, ein eigener Mapper erstellt werden muss. Es ist aber auch möglich das Muster so umzusetzen, dass in der gesamten Anwendung

4. Design

Fachhochschule Schmalkalden SS 2011

nur ein Mapper für alle Objekt eingesetzt wird. Außerdem kann das Muster auch dafür verwendet werden, um die Anwendung von der darunterliegenden Datenbank abzutrennen [FRF + 03, S. 166 ff.].

Architektur Wie eingangs erwähnt besitzt Lift bereits Records für alle gängigen Datenbanken. Diese sind aber, wie beim Active Record Muster beschrieben, stark an die Daten- bank gebunden. Deshalb wurden in der PlanningWeb-Anwendung die Komponenten persistence und transform eingeführt. Diese sind in Anlehnung an das Data Map- per Muster implementiert. Dabei wurde ein Ansatz verfolgt, ähnlich wie in [Sie04, S. 211 ff.] beschrieben.

Die persistence Komponente bietet eine Schnittstelle an um Objekte in einer Da- tenbank zu lesen, zu schreiben, zu löschen und zu aktualisieren. Um das bewerkstel- ligen zu können benutzt die persistence Komponente eine Schnittstelle, die von der transform Komponente angeboten wird. Diese ist wiederum in der Lage Objek- te der Anwendungslogik in Record-Objekte der entsprechenden Datenbank-Records zu transformieren um so das Lesen, Schreiben und Ändern von Objekten in der Da- tenbank zu ermöglichen. Durch diese Art der Architektur ist die Anwendungslogik komplett von der zugrundeliegenden Datenbank unabhängig und kann jederzeit ge- gen 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

Komponenten in einem Klassendiagramm dar. Abbildung 4.2: Klassendiagramm Persistenz Christoph Schmidt Seite 24 von 49

4. Design

Fachhochschule Schmalkalden SS 2011

4.4.2 Anwendungskern

Der Anwendungskern im Allgemeinen beschreibt die fachliche Intelligenz der Anwen- dung [Sie04, S. 165]. In der PlanningWeb-Anwendung ist dieser Teil in der snippet Komponente angesiedelt, welche bereits in Kapitel 2.2.1 eingeführt wurde. Diese lässt sich gemäß der durchgeführten Analyse wiederum in eigenständige Teilkom- ponenten zerlegen, woraus fünf weitere Komponenten entstehen, die im Anschluss näher erläutert werden.

Studiengangsverwaltung: Ein wichtiger Bestandteil der Lehr- und Stun- denplanung sind die Studiengänge. Ein Studiengang besitzt einen Namen, eine Abkürzung und eine Semesteranzahl. Darüber hinaus besitzt jedes Semester eine Anzahl an Studenten. Das System besitzt daher eine Studiengangsverwal- tung mit folgenden Funktionen: Anlegen eines neuen Studiengangs, Bearbeiten eines Studiengans und Löschen eines Studiengangs.

Dozentenverwaltung: Um überhaupt Lehrveranstaltungen anbieten zu kön- nen sind Dozenten erforderlich, die bestimmte Vorlesungen anbieten. Ein Do- zent besitzt einen Typ der sich aus einem Namen, den zu haltenden Pflichtstun- den und einer Kennzeichnung, ob es sich bei diesem Typ um einen Lehrbeauf- tragen handelt, zusammensetzt. Außerdem gibt es auf Grund der FH internen LDAP-Struktur einen Dozenten für die Lehrplanung und einen FHS-Dozenten für die Authentifizierung am System. Ein Dozent besitzt einen Namen, der diesen eindeutig identifiziert, einen Typ und eine Zeitangabe zur Selbstverwal- tung, die von den zu haltenden Pflichtstunden des Typs abgezogen wird um die tatsächliche Arbeitszeit zu ermitteln. Ein FHS-Dozent setzt sich wiederum aus einem Dozenten und einer FHS-ID zusammen. Die Studiengangsverwal- tung besitzt deshalb diese Funktionen: Typen und FHS-Dozenten anzulegen und zu löschen. Dozenten können darüber hinaus angelegt, geändert und ge- löscht werden.

Lehrveranstaltungsverwaltung: Kern einer jeden Lehrplanung sind die Lehrveranstaltungen. Eine Lehrveranstaltung setzt sich aus einem Typ, einem Namen der diese eindeutig identifiziert, Studiengängen mit entsprechenden Se- mestern, Dozenten sowie Vorlesungs- und Übungswochenstunden zusammen. Die Lehrveranstaltungsverwaltung bietet daher folgende Funktionen an: Er- stellen und Löschen eines Typs; Erstellen, Ändern, Anzeigen und Löschen von Lehrveranstaltungen; Zuweisen von Lehrveranstaltungen zu Sommer- oder Wintersemester; Erstellen und Löschen von Lehrveranstaltungs- und Übungs- gruppen sowie der Semesterplanung, welche die entsprechenden Veranstaltun- gen pro Studienwoche generiert.

Raumverwaltung: Ein wichtiger Bestandteil der Stundenplanung sind Räu- me. Ein Raum ist genau einem Gebäude zugeordnet und besitzt eine Bezeich-

nung, eine Raumgröße sowie zahlreiche Ausstattungsmerkmale (z. B. mit/ohne

Tageslichtprojektor, Tafel, Beamer

lichkeit Räume zu Erstellen und zu Löschen.

).

Die Raumverwaltung bietet die Mög-

4. Design

Fachhochschule Schmalkalden SS 2011

Arbeitszeitverwaltung: Die Arbeitszeiten der Dozenten bilden einen weite- ren Bestandteil der Stundenplanung. Die Arbeitszeiten setzen sich daher aus verschieden Zeiteinheiten einer Studienwoche zusammen. Die Arbeitszeitver- waltung bietet daher die Möglichkeit an, Arbeitszeiten und Raumwünsche für Veranstaltungen der einzelnen Dozenten zu erfassen und zu verwalten.

Diese vorgestellten Funktionsgruppen besitzen gemäß ihrer Aufgaben Abhängigkei- ten. Die Dozentenverwaltung ist wie die Studiengangs- und Raumverwaltung ei- genständig. Die Arbeitszeitverwaltung hingegen ist auf die Dozenten-, Raum- und Lehrveranstaltungsverwaltung angewiesen. Den Kern des PlanningWeb-Systems bil- det die Lehrveranstaltungsverwaltung. Sie ist wiederum von der Dozenten- und Stu- diengangsverwaltung abhängig. Auf Grund dieser Beziehungen lässt sich ein verein- fachtes Datenmodell ableiten, das in Abbildung 4.3 dargestellt ist.

Abbildung 4.3: Datenmodell der PlanningWeb-Anwendung

ist. Abbildung 4.3: Datenmodell der PlanningWeb-Anwendung In dem in Abbildung 4.3 vorgestellten Datenmodell kommt der

In dem in Abbildung 4.3 vorgestellten Datenmodell kommt der Lehrveranstaltung oder auch Lecture eine zentrale Rolle zu. Deshalb wird diese aus dem Datenmodell herausgegriffen und deren Architektur ausführlich dargestellt. Abbildung 4.4 zeigt das Design einer Lehrveranstaltung wie es in der PlanningWeb-Anwendung umge- setzt ist. Eine Lehrveranstaltung besteht aus einem Name, der diese eindeutig beschreibt, einem Lehrveranstaltungstyp der sich aus der Studienordnung ergibt, einer Semes- terwochenstudenanzahl für Übungen und Vorlesungen sowie zwei Flags, welche aus- sagen, ob die Lehrveranstaltung im Sommer- oder Wintersemester angeboten wird. Darüber hinaus enthält 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 re- präsentiert werden. Diese Klasse bildet ab, ob ein Dozent eine Vorlesung und/oder eine Übung der Lehrveranstaltung abhält. Aus diesem Teilaufbau einer Lehrveran- staltung lassen sich bereits konkrete Vorlesungen und Übungen einer Studienwoche ableiten, die allerdings noch nicht alle geforderten Anforderungen erfüllt, wie bei- spielhaft in Listing 4.1 dargestellt.

4. Design

Fachhochschule Schmalkalden SS 2011

Abbildung 4.4: Klassendiagramm einer Lehrveranstaltung

2011 Abbildung 4.4: Klassendiagramm einer Lehrveranstaltung Listing 4.1: Darstellung einer Lehrveranstaltung val

Listing 4.1: Darstellung einer Lehrveranstaltung

val

lecture

=

Lecture(

"Prozedurale

,LectureType("Pflichtfach")

,List(CourseInformation(

Programmierung"

"Bachelor

,"BaI"

,List(Semester(1,1))

,List(SemesterInformation(

Informatik"

1

,List(DozentInformation(

Dozent("Braun","" ,0.0

,DozentType("Professor" ,18,false)) ,true ,true)))))) ,List() ,List()

,1

,1 ,true

,false)

4. Design

Fachhochschule Schmalkalden SS 2011

Aus Listing 4.1 lässt sich eine Vorlesungseinheit und eine Übungseinheit für das erste Semester des Studiengangs Bachelor Informatik mit der Lehrveranstaltungsbezeich- nung Prozedurale Programmierung ableiten. Beide Termine werden vom Dozenten Braun im Sommersemester angeboten. Um weitere Anforderungen, wie das Erstellen von Übungs- und Vorlesungsgruppen, die flexibel einem oder mehren Dozenten zugewiesen werden können, enthält das De- sign einer Lehrveranstaltung zwei weitere Attribute, hasLectureTogetherWith und hasTutorialTogetherWith. Beide aggregieren die Klasse LectureRelationship, welche eine Liste mit Studiengängen und zugehörigem Semester in eine direkte Be- ziehung zu einem Dozenten setzen. Durch diese Architekturentscheidung können die in Kapitel 3.3.1 geforderten Anforderungen erfüllt werden.

5 Implementierung

Nachdem in den vorangegangenen Kapiteln die Sprache Scala und das Lift-Framework vorgestellt und die Anforderungen sowie das Design der Beispielanwendung ent- worfen und analysiert wurden, geht dieses Kapitel auf die Implementierung der PlanningWeb-Applikation ein. Es werden wichtige Programmteile ausführlich un- tersucht. Dabei werden Möglichkeiten vorgestellt, die das Lift-Framework und Scala bieten um spezifische Probleme zu lösen. Zu Beginn wird kurz ein Überblick über Programme gegeben, mit denen grundsätz- lich Lift-Anwendungen realisiert werden können. Anschließend wird auf die Imple- mentierung der wichtigsten Komponenten des Systems eingegangen. Die entstan- denen Probleme werden dabei erläutert und die damit verbunden Lösungsansätze vorgestellt. Der gesamte Quellcode wurde auf Github 1 veröffentlicht.

5.1 Entwicklungsumgebung und Buildtools

Für die Entwicklung von Scala- und im speziellen für Lift-Anwendungen besteht grundsätzlich die Möglichkeit einen herkömmlichen Editor wie Vim oder Notepad in Verbindung mit einem Buildtool zu nutzen. Für eine etwas komfortablere Entwick- lung stehen für die meist genutzten Entwicklungsumgebungen wie Eclipse, NetBeans oder IntelliJ entsprechende Scala-Plugins zu Verfügung [CBDW11, S. 6 f.]. Im Laufe der PlanningWeb-Entwicklung kam IntelliJ 2 und das Build-Tool SBT 3 zum Einsatz.

5.1.1 IntelliJ

IntelliJ IDEA wurde in der Community Edition 10.0.3 mit Scala-Plugin verwendet, das sich über den Plugin Manager installieren lässt. Zu den wichtigsten Funktionen des Plugins zählt Code Highlighting und Code Completion. Darüber hinaus kann mit Projekten gearbeitet werden, die sowohl Scala als auch Java Dateien enthalten. Weiter wird das Compilieren, Testen und Refaktorisieren unterstützt. Die Entwick- lungsumgebung bietet außerdem eine Unterstützung für Versionsverwaltungen wie SVC, Git, Mercural und Subversion an. Grundsätzlich lässt sich die Entwicklungs- umgebung intuitiv und benutzerfreundlich bedienen. Allerdings fällt 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 https://github.com/spirit-fhs/planningweb

2 http://www.jetbrains.com/idea/

3 http://code.google.com/p/simple-build-tool/

5. Implementierung

Fachhochschule Schmalkalden SS 2011

Listing 5.1: Modifizierte 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 erwünschten Effekt, so dass per Hand eingegriffen werden musste. Ein weitere Schwachpunkt liegt im Verschieben von Dateien oder Paketen. Abschließend kann die Arbeit mit IntelliJ aber als positiv bewertet werden.

5.1.2 Simple-Build-Tool

Zum Ü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 konfiguriert. Es ist auch möglich den Funktionsumfang von SBT mit Hilfe von entsprechenden Scala-Plugins zu erweitern. Außerdem unterstützt das Programm das Testen von Anwendungen, da es die Test-Frameworks Scala-Check, Specs und ScalaTest unter- stützt. Für das Arbeiten mit webbasierten Anwendungen stellt SBT einen integrier- ten Jetty-Server für 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. An- schließend folgt die Eingabe von jetty-run, was die Anwendung übersetzt und star- tet. Sofern der Quellcode fehlerfrei übersetzt wurde, kann das Programm mit einem Browseraufruf von http://localhost:8081 gestartet werden. Beim erstmaligen Ausführen sollte allerdings nach dem Start von SBT ein update Befehl ausgeführt werden, um Paketabhänigkeiten aufzulösen. Alternativ kann dem jetty-run Befehl eine Tilde vorangestellt werden. Dadurch wird das Projekt automatisch bei Ände- rungen 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 ausgeführt werden kann.

5. Implementierung

Fachhochschule Schmalkalden SS 2011

5.2 Menü und Zugriffskontrolle

Wie in Kapitel 2.2.5 erläutert verfügt Lift bereits über eine Benutzerverwaltung und Menüsteuerung. Allerdings soll die Authentifizierung an der PlanningWeb-

Abbildung 5.1: PlanningWeb-Anmeldung

an der PlanningWeb- Abbildung 5.1: PlanningWeb-Anmeldung Anwendung mit Hilfe der FH-internen LDAP-Server

Anwendung mit Hilfe der FH-internen LDAP-Server durchgeführt werden. Das Fra- mework beinhaltet im Paket net.liftweb.ldap ein LDAP-Modul. Dieses kann aber auf Grund der FH-internen Struktur nicht zum Einsatz kommen. Für die Abfrage aller relevanten Daten muss auf zwei unterschiedliche LDAP-Server zugegriffen 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 findet. Der Quellcode wurde auf Github 4 veröffentlicht.

5.2.1 FhS-LDAP-Module

Um zu ermöglichen, dass sich Dozenten am System mit ihrer FHS-ID anmelden kön- nen, 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 repräsentiert das Standard-Anmeldeformular.

Listing 5.3: Die Methode loginXhtml

override def loginXhtml = { (<lift:surround with="default" at ="content"> <h3>{"Login nur mit gültiger FHS-ID möglich!"}</h3> <form method="post" action={S.uri} name="login"> <table> <tr><td colspan="2">{S.??("log.in")}</td></tr> <tr><td>{S.??("FHS-ID")}</td><td><user:user /></td></tr>

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

5. Implementierung

Fachhochschule Schmalkalden SS 2011

<tr><td>{S.??("password")}</td><td><user:password /></td></tr> <tr><td><user:submit /></td></tr> </table> </form> <script type="text/javascript" language="JavaScript"> document.forms[’login’].elements[’username’].focus(); </script> </lift:surround>)

}

Der Trait MetaMegaProtoUser definiert darüber hinaus einen User und bietet eine Methode currentUserId an. Diese Methode liefert nach erfolgreicher Anmeldung die FHS-ID eines Dozenten zurück. Dadurch wird es möglich eine Rollenunterschei- dung der einzelnen Benutzergruppen zu implementieren. Hierzu ist in der Datei Boot.scala der Applikation eine Methode is implementiert, wie in Listing 5.4 dar- gestellt.

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 prüft in der Kon- figurationsdatei default.props ob der Benutzer der gesuchten Benutzergruppe ent- spricht. 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 SiteMap

Das Menü der Anwendung wird in der Methode sitemap erstellt. Um eine Unter- scheidung zwischen den vier Benutzergruppen zu erzielen enthält die Klasse Boot in der Methode boot die Attribute:

ifSuperUser

ifDozent

ifCourseSheduler

ifTimetableSheduler.