Skip to content
Till Uhlig edited this page Jul 25, 2017 · 12 revisions

Das System wurde 2013 vordergründig durch die Martin-Luther-Universität Halle-Wittenberg als Folgesystem einer bis dahin bestehenden Plattform entwickelt, zur Verwaltung von Übungsaufgaben, Übungsgruppen und Einsendungsbewertungen. Dabei begreift sich das System nicht als umfangreiche Lernplattform, sondern eher als Übungsverwaltung.

Zudem profitiert das System von der langjährigen Erfahrung, auf diesem Gebiet, sodass von Anfang an eine modulare Entwicklung im Vordergrund stand. Die Betreuung und Weiterentwicklung erfolgt dabei durch wechselnde Mithelfende und langfristig eher sporadisch, sodass die verwendeten Technologien auf einen längeren wartungsfreien Betrieb abzielen.

C: das Schichtenmodell von OSTEPU

Das System unterteilt seine Bestandteile dabei zunächst logisch, wie in Abbildung C dargestellt, innerhalb einer Schichtenarchitektur, welche eigene Entwicklungsgruppen darstellen und damit durchaus unterschiedlich in ihrer konkreten Umsetzung sind.

Ein großer Teil der inneren Logik besteht dabei aus voneinander getrennten Mikroservices, welche eine feste, klar abgegrenzte Aufgabe erledigen, sodass größere Aufgaben, wie in Abbildung D dargestellt, durch die Verschaltung kleinerer Module erledigt werden.

D: die Bearbeitung einer Aufgabe in OSTEPU

interner Zugriff auf Komponenten

Die Kommunikation zwischen den Komponenten basiert auf einer REST-Schnittstelle. Dadurch ist die interne Schnittstelle identisch zur äußeren. Dabei kommunizieren die Komponenten auf dem Server von OSTEPU also gleichermaßen mit externen Komponenten, sodass wir diese prinzipiell auch für die Kommunikation zwischen OSTEPU und eines anderen Service verwenden können.

Wir wollen nun ein kleines Beispiel für eine lesende GET Anfrage betrachten. Dazu wollen wir die Daten des Nutzers mit der userId=1 ermittelt. Die zuständige Komponente wäre dabei die Datenbankkomponente DBUser, welche die Adresse http://localhost/ostepu/DB/DBUser besitzt. Wir können dort nun unsere eigentliche Anfrage user/user/1 stellen. Dabei hat dieser Abfrageteil den Aufbau Rückgabetyp/Bedingung/Wert.

Die konkrete Anfrage sieht dann wie nachfolgend aus. GET http://localhost/ostepu/DB/DBUser/user/user/1

Die Antwort der Komponente erfolgt dann mithilfe von HTTP-Statuscodes und durch JSON kodierte Inhalte.

{
    "id": "1",
    "userName": "till",
    "email": "till@email.de",
    "firstName": "Till",
    "lastName": "Uhlig",
    "flag": "2",
    "password": "9f86d081884c7d6...",
    "failedLogins": "17",
    "courses": [{
        "status": "3",
        "course": {
            "id": "1",
            "name": "Bengalisch II",
            "semester": "SS 11",
            "defaultGroupSize": "1"
        }
    }]
}

C: ein JSON kodiertes Nutzerobjekt

Die Abbildung C zeigt nun jene Antwort unserer zuvor gestellten Anfrage für die Daten des Nutzers mit der userId=1. Dabei wurde hier zur Vereinfachung nur der Antwortkörper angegeben.

Komponentenbeschreibungen

Übersicht
CAbstract CContent CControl CGate
CHelp CSystem CUIHelp DBApprovalCondition
DBAttachment DBAttachment2 DBBeispiel DBChoice
DBControl DBCourse DBCourseStatus DBExercise
DBExerciseFileType DBExerciseSheet DBExerciseType DBExternalId
DBFile DBForm DBGate DBGroup
DBInvitation DBMarking DBNotification DBOOP
DBProcess DBQuery2 DBRedirect DBSelectedSubmission
DBSession DBSetting DBSubmission DBTransaction
DBUser FSBinder FSControl FSCsv
FSFile FSPdf FSZip LAttachment
LController LCourse LExercise LExerciseSheet
LExtension LFile LForm LFormPredecessor
LFormProcessor LGetSite LGitLab LMarking
LOOP LProcessor LSubmission LTutor
MarkingTool2
Clone this wiki locally