[PDF] Konzeption und Realisierung einer Plattform zur Verwaltung von

View - Download Konzeption und Realisierung einer Plattform zur Verwaltung von

Previous PDF

Next PDF

Ingenieurwissenschaften,

Informatik und Psy-

chologie

Institut für Datenbanken

und Informationssyste- me

Konzeption und Realisierung einer Platt-

form zur Verwaltung von webbasierten Fra-

Vorgelegt von:

Fabian Egl

fabian.egl@uni-ulm.de

Gutachter:

Prof. Dr. Manfred Reichert

Betreuer:

Michael Stach

2018

Fassung 10. September 2018

c

2018 Fabian Egl

Satz: PDF-L

ATEX2"

Kurzfassung

oft papiergebunden, was eine Verarbeitung dieser erschwert. Für papiergebundene aus diesen gewonnenen Daten existiert, wird der Austausch der Forschungsdaten zwischen Forschern deutlich erschwert. Ziel dieser Arbeit ist es daher eine webbasierte Plattform zu konzipieren und zu entwickeln, damit Forscher und Ärzte jederzeit über das Internet mit dieser Plattform REST-Architektur basierende API, sowie einen Web-Client an. iii

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Verwandte Arbeiten 5

2.1 MobileTx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 TrackYourTinnitus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 QuestionSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Grundlagen 8

3.1 Begrifflichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Anforderungsanalyse13

4.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.2 Benutzerprofilanalyse . . . . . . . . . . . . . . . . . . . . . . 14

4.1.3 Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . 15

4.2.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 17

4.2.3 Nicht funktionale Anforderungen . . . . . . . . . . . . . . . . 24

5 Entwurf27

5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Web-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.2 Web-Service . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1.3 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Aufbau der Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . 29

iv

Inhaltsverzeichnis

5.2.1 Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.2 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.3 Fragebogenversion . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.4 Fragebogenresultat . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Nutzer und Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3.1 Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3.2 Rollen innerhalb eines Projektes . . . . . . . . . . . . . . . . 31

6 Aspekte der Implementierung 34

6.1 Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Zwei Aspekte der Implementierung . . . . . . . . . . . . . . . . . . 35

6.2.1 Implementation Web-Service . . . . . . . . . . . . . . . . . . 36

Routen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Erstellen einer Anfrage . . . . . . . . . . . . . . . . . . . . . 37 Verarbeiten einer Anfrage . . . . . . . . . . . . . . . . . . . 38 Antwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2.2 Implementation Web-Client . . . . . . . . . . . . . . . . . . . 42

7 Anforderungsabgleich46

7.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Nicht funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 50

8 Zusammenfassung und Ausblick52

8.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Literaturverzeichnis55

v

1 Einleitung

In diesem Kapitel wird eine kurze Einführung in die Thematik gegeben, auf der diese Arbeit beruht. Dabei wird der Fokus auf die Motivation und die Problemstellung, welche der Arbeit zu Grunde liegen, gelegt. Der Abschnitt 1.1 besteht aus einer kurzen Hinführung zum Thema mit Einbeziehung der aktuellen Situation, auf der diese Arbeit basiert. Danach folgt der Abschnitt 1.2, welcher die Problemstellung

1.3 eine kurze Zusammenfassung über den Aufbau der Arbeit gegeben. Dabei wird

kurz auf den Inhalt aller Kapitel eingegangen.

1.1 Motivation

zerbefragungen, durchführen um Nutzer- / Teilnehmerdaten zu erhalten. Dies wird unter anderem auch in der Psychologie genutzt, um wichtige Forschungsdaten von (vergleiche Abschnitt 2.1), TrackYourTinitus (vergleiche Abschnitt??) und Questi- onSys (vergleiche Abschnitt 2.3). Diese Anwendungen und Systeme sind jedoch oft

1.2 Problemstellung

Wie im Abschnitt 1.1 motiviert, gibt es momentan keine zentrale Plattform für die handen ist, erschwert dies den Austausch von Forschungsergebnissen und Infor- mationen, welche bei der Befragung von Patienten erhoben werden. Eine gemein- 1

1 Einleitung

an Forschungsdaten hervorrufen. Ziel dieser Arbeit ist es deshalb, eine zentrale Plattform für das Speichern und die haltet. Dies ist wichtig, damit die Nutzer bei Bedarf selbst ein System erstellen dings nur die Funktion eines Beispiels, wie man das System/die API nutzen kann. Ein einheitliches Frontend ist auch nicht sinnvoll, da verschiedene Nutzergruppen verschiedene Anforderungen an den Aufbau des Frontends besitzen. Somit ist es den Nutzergruppen selbst überlassen, ein Frontend für ihre spezifischen Zwecke zu erstellen und an die API des in dieser Arbeit erstellten Systems anzubinden.

1.3 Aufbau der Arbeit

Diese Arbeit ist in 4 Bereiche aufgeteilt. Den Anfang macht die Hinführung zum Thema, dies wird gefolgt von der Konzeption des Systems. Daraufhin folgt die Im- plementierung des Systems und zum Abschluss noch eine Zusammenfassung der

Arbeit.

Der erste Bereich besteht aus einer Einleitung und Hinführung zum Thema, sowie eine Übersicht über verwandte Arbeiten. Dieser Bereich besteht aus den Kapiteln

1 Einleitung, 2 verwandte Arbeiten und 3 Grundlagen. Das Kapitel 1 Einleitung be-

steht aus einer allgemeinen Hinführung zum Thema sowie der Problemstellung auf der diese Arbeit basiert. Im Kapitel 2 werden kurz verwandte Arbeiten vorgestellt. Der zweite Bereich besteht aus der Planung und Konzipierung des Systems. Er 2

1 Einleitung

derungsanalyse durchgeführt, um die Anforderungen für das System festzulegen. Das Kapitel 5 beinhaltet einen ersten Entwurf für das System. Danach folgt der dritte Bereich, welcher sich mit der Implementierung des Systems ausführlich behandelt. Den Abschluss bildet der vierte Bereich mit den Kapiteln 7 Anforderungsabgleich und 8 Zusammenfassung und Ausblick. In Kapitel 7 wird überprüft, ob die Anforde- rungen welche im Kapitel 4 aufgestellt wurden, erfüllt sind. Danach folgt mit Kapitel

8 das letzte Kapitel der Arbeit, welches eine Zusammenfassung der Arbeit liefert

und einen Ausblick auf die Zukunft, basierend auf dieser Arbeit, gibt. 3

2 Verwandte Arbeiten

In diesem Kapitel wird auf drei verwandte Arbeiten und Forschungsprojekte einge- gangen.

2.1 MobileTx

MobileTx [7] [22] [21] ist ein Projekt des Institutes für Datenbanken und Informati- Abbildung 2.1 bietet einen Überblick über die Funktionsweise des Projektes. Patien- gaben gestellt welcher zur Behandlung genutzt werden. Dabei unterstützen Smart- Patient ausfüllt. Diese werden daraufhin an den Server gesendet. Die dort gespei- und dadurch neue Aufgaben entwickeln.

2.2 TrackYourTinnitus

TrackYourTinnitus [15] ist ein Projekt des Institutes für Datenbanken und Informati- onssysteme der Uni Ulm. Tinnitus ist dabei ein Wahrnehmen von Ton, obwohl keine 5

2 Verwandte Arbeiten

Abbildung 2.1: MobileTx [7] [1]

bekommen nutzt das Projekt crowdsensing. Dabei wird eine Anwendung für Smart- aus der Nutzerbefragung und der Smartphone Sensoren an die TrackYourTinnitus schern abgerufen und analysiert werden [20].

2.3 QuestionSys

QuestionSys [13] ist ein Projekt des Institutes für Datenbanken und Informations- beiten und auswerten zu lassen. Dies hat den Vorteil, dass diese weniger Arbeit Abbildung 2.2 zeigt den prozessgetriebenen Ansatz der Architektur des Frame- works, das in diesem Projekt erstellt wurde, um das Sammeln von mobilen Daten zu unterstützen [23]. 6

Abbildung 2.2: QuestionSys [13] [2]

3 Grundlagen

Dabei wird in Abschnitt 3.1 eine Übersicht der wichtigsten Begriffe gegeben. Jeder hang mit dieser Arbeit zu verstehen sind gefolgt. Abschließend folgen eine kurze Zusammenfassung von OAuth in Abschnitt 3.2 und REST in Abschnitt 3.3

3.1 Begrifflichkeiten

die Art und Weise und der Zusammenhang, wie sie in der Arbeit verwendet werden Begriffe im Zusammenhang mit dieser Arbeit zu verstehen sind. Um eine Suche der APIAPI ist eine Abkürzung für Application Programming Interface. In dieser Ar- beit ist eine API eine Schnittstelle zwischen dem erstellten System und Nutzern

Funktionen für eine Interaktion nutzen.

Systems zugewiesen werden. Dies wird im System genutzt, um eine eindeutige und Verwaltung der API-Keys wird im System durch OAuth [9] umgesetzt. Dieser API-Key entspricht dem Bearer Token im OAuth2.0 Protokol (vergleiche Abschnitt 3.2). 8

3 Grundlagen

CRUDCRUD steht für Create, Read, Update und Delete [3]. Im Sinne dieser Ar- beit wird CRUD genutzt um die Standardaufgaben beim verwalten einer Ressource schen einer Ressource. FragebogenAls Fragebogen werden im Falle dieser Arbeit eine Sammlung von zum Beispiel Multiple Choice, freie Antwort, Bewertungen und viele weitere. Für work bestehen und als JSON innerhalb der Datenbank abgespeichert werden.

Synonym: Survey

FragebogenresultatEin Fragebogenresultat ist eine Sammlung von Antworten vorhanden sein oder auch getrennt von diesem gespeichert sein.

Synonym: Survey Result

nur mit Erlaubnis des Administrators einen Account erstellen kann. RessourceJede Information die benannt werden kann, kann eine Ressource sein [19]. RESTful APIEine RESTful API ist eine API welche die in Abschnitt 3.3 genannten

Bedingungen erfüllt.

TeilnehmerEin Teilnehmer ist eine Person, welche einen gegebenen Fragebo- gen beantwortet. Dabei muss der Teilnehmer nicht zwingend selbst die Person sein, nem Patienten Fragen stellt, sowie die Antworten von diesem dokumentiert und als Fragebogenresultat abspeichert. In diesem Fall ist der Patient der Teilnehmer. 9

3 Grundlagen

Web-ClientUnter dem Web-Client wird in Bezug auf dieses System das kom- plette Frontend verstanden, das heißt, alle HTML Seiten, die ein Gast, Nutzer oder Administrator abrufen kann (für fast alle Seiten muss der Nutzer bzw. Administra- tor eingeloggt sein). Diese HTML Seiten beinhalten oft Formulare, mit denen ein

3.2 OAuth

OAuth2.0 [9] ist ein Protokoll, welches eine sichere Autorisierung in einfachen und licht. Die OAuth2.0 Spezizierung und ihre Erweiterungen werden von der IETF OAuth Working Group entwickelt. Das OAuth Protokoll basiert dabei auf dem in

2006 erstellten OAuth Protokoll.

Server gespeichert welcher von OAuth geschützt werden. Darüber hinaus gibt es noch einen Client. Mit diesem Client kann der Besitzer der Ressource nach er- folgreicher Authentizierung die Ressourcen vom Server abrufen. Damit er diese Autorisierungsserver erstellt werden, nachdem dieser die Einwilligung des Nutzer, wurden diese kryptographische Signaturen durch Bearer Tokens ersetzt. Bearer To- kens sind einfache Access Tokens bei denen der Besitzt dieser Ausreicht, um auf

3.3 REST

Representational State Transfer (REST) [19] ist ein Architekturstil für distributed hypermedia systems. Damit ein System RESTful ist, müssen die nachfolgenden sechs Bedingungen erfüllt sein. Die erste Bedingung ist eine Client-Server Architektur. Die zweite Bedingung ist die Zustandslosigkeit der Kommunikation zwischen Client und Server. Das heißt auf 10

3 Grundlagen

dem Server werden keine Daten bezüglich der Session gespeichert, der Server verarbeitet jeweils nur die pro Anfrage eingegangenen Daten. Die dritte Bedingung im Cache abgespeichert werden dürfen. Die vierte Bedingung ist ein einheitliches Interface. Die fünfte Bedingung ist ein schichtbasiertes System. Dabei haben die einzelnen Schichten verschiedene Hierarchien. Dies kann genutzt werden um nur bestimmte Funktionen des Systems in bestimmten Ebenen sichtbar und somit ver- fügbar zu machen. Die letzte Bedingung ist Code-On-Demand. Dies erlaubt es dem Client Applets oder Skripte zu downloaden und auszuführen. 11

4 Anforderungsanalyse

Bevor das System Implementiert werden kann, muss zuerst klar sein welche An- forderungen das System erfüllen soll. Deshalb wird in diesem Kapitel eine Anforde- rungsanalyse des Systems ausgeführt. Dieses Kapitel ist in zwei Abschnitte der Anforderungsanalyse aufgeteilt. Zuerst erfolgt in Abschnitt 4.1 die Analyse des Systems. Daraufhin werden im Abschnitt

4.2 die Anforderungen des Systems erstellt.

4.1 Analyse

In diesem Abschnitt erfolgt die Analyse des Systems. Hierfür wird zuerst ein Szena- folgt die Benutzerprofilanalyse. In dieser werden alle Gruppen von Benutzern auf- in Bezug auf die Systemnutzung analysiert. Abschließend werden noch alle Rand-

4.1.1 Szenario

die wichtigsten Szenarien der Systemnutzung aufgestellt werden, damit eindeutig wichtigsten Szenarien der Systemnutzung aufgestellt. Dies wird am Anfang der An- forderungsanalyse erstellt, damit in Abschnitt 4.2 die Anforderungen des Systems basierend auf diesem Szenarien aufgestellt werden. Wie in Abschnitt 1.1 und Abschnitt 1.2 bereits genannt, ist ein wichtiges Benut- Forschung (vor allem in der Psychologie). Dabei soll die Plattform eine zentrale 13

4 Anforderungsanalyse

erreichbar sein sollte.

4.1.2 Benutzerprolanalyse

Damit das System an die Benutzer angepasst und nicht an den Benutzern vorbei entwickelt wird, wird in diesem Abschnitt eine Benutzerprofilanalyse ausgeführt. Bei dieser wird analysiert, welche Nutzergruppen das fertige System benutzen werden. Darüber hinaus wird aufgeführt, wie die einzelnen Nutzergruppen mit dem System interagieren. Somit bilden die Forscher und Ärzte eine wichtige Nutzergruppe. Die Forscher wer- chen Forschungsprojekten teilen. Darüber hinaus ist für Forscher die Analyse der ist. Eine weitere Nutzergruppe bilden die befragten Nutzer und Patienten. Die Nutzer chern der Antworten auf diese.

4.1.3 Randbedingungen

gen aufgestellt werden. Das zu erstellende System soll webbasiert sein und eine API besitzen. Die API ist dabei eine RESTful-API (vergleiche Abschnitt 3.3). Die Autorisierung der API erfolgt mit OAuth (vergleiche Abschnitt 3.2). Als Basis für das Fragebogenschema wird SurveyJS [14] (vergleiche Abschnitt??) genutzt.

4.2 Anforderungen

Nachdem nun die grundlegende Analyse des Systems fertig ist, werden nun die darauf aufbauenden Anforderungen des Systems erstellt. In diesem Abschnitt wird 14

4 Anforderungsanalyse

dafür zuerst ein Anwendungsfalldiagramm aufgestellt, welches eine Übersicht über Zusammenstellung der funktionalen Anforderungen und nicht funktionalen Anfor-

Anforderungen gefolgt.

4.2.1 Anwendungsfalldiagramm

diese grafisch darzustellen wurde ein UML-Anwendungsfalldiagramm genutzt. Die- welche diese jeweils am fertigen System ausführen. In Abbildung 4.1 ist das Anwendungsfalldiagramm für diese Arbeit zu sehen. Da

4.2.2, da diese fast identisch zu den funktionalen Anforderungen des Systems sind.

5.3. Das System besteht aus drei Rollen. Diese sind der Gast, der Administrator und der Nutzer. Der Gast kann sich im System registrieren und anmelden. Der Adminis- trator kann Nutzer des Systems verwalten. Die Rolle Nutzer bezeichnet den allge- meinen Nutzer des Systems, er kann sich dabei API-Keys erstellen und verwalten und verwalten. Die Berechtigungen hierfür sind für jeden Nutzer und jedes Projekt er ist Projektverwalter oder Projektteilnehmer in diesem Projekt. Im Diagramm 4.1 kann dabei abgelesen werden, welche Funktionen er in welcher Rolle je Projekt innerhalb eines Projektes befindet sich wie bereits vorher genannt in Abschnitt 5.3. 15

4 Anforderungsanalyse

Abbildung 4.1: Anwendungsfalldiagramm

16

4 Anforderungsanalyse

Nr.Funktionale AnforderungSeite

Gast:

FA1.01Gast kann sich registrieren17

FA1.02Gast kann sich anmelden18

Nutzer:

FA1.03Nutzer kann API-Key erstellen18

FA1.04Nutzer kann API-Key erneuern18

FA1.06Nutzer kann neues Projekt erstellen18

Administrator:

FA1.07Administrator kann neuem Nutzer Register-Token schicken18

FA1.08Administrator kann Nutzer sperren19

4.2.2 Funktionale Anforderungen

Die funktionalen Anforderungen des Projektes sind zur Übersichtlichkeit in drei Dies wird von der Tabelle 4.2 gefolgt welche die speziellen rollenspezifischen An- forderungen innerhalb eines Projektes beinhalten. Die Tabelle 4.3 beinhaltet alle die Tabellen. Alle Anforderungen die einen Nutzer des Systems betreffen, der kein Gast ist, setzen voraus, dass der Nutzer im System entweder durch Anmeldung im Web-Client oder durch Angabe des API-Keys beim Nutzen der API autorisiert ist. Bei Funktionen, welche ein Projekt betreffen, wird bei den Anforderungen vor- ausgesetzt, dass der Nutzer die entsprechenden Berechtigungen innerhalb dieses Projektes hat (entspricht Rolle Projektverwalter oder Projektteilnehmer innerhalb des Projekts).

FA1.01Gast kann sich registrieren

Ein Gast kann ein HTML-Formular abrufen mit dem er sich anschließend in der und dem neuen Nutzer per E-Mail zuschicken. 17

4 Anforderungsanalyse

FA1.02Gast kann sich anmelden

Ein Gast kann ein HTML-Formular zum anmelden im System abrufen und sich mit Hilfe von diesem im System anmelden. Der Web-Client des Systems kann nur nach erfolgreicher Anmeldung eines Nutzers genutzt werden.

FA1.03Nutzer kann API-Key erstellen

Ein Nutzer kann über die API einen neuen API-Key erstellen. Alternativ kann ein Nutzer auch ein HTML-Formular abrufen mit dem er sich einen API-Key erstellen kann. Mit diesem API-Key kann er auf die API zugreifen.

FA1.04Nutzer kann API-Key erneuern

Nutzer kann über die API seinen API-Key erneuern. Dabei wird die Gültigkeit des API-Keys auf die Standarddauer des Systems vom aktuellen Zeitpunkt aus gesetzt. Alternativ kann ein Nutzer auch ein HTML-Formular zum erneuern seines API-Keys abrufen und damit seinen API-Key erneuern. Alternativ kann ein Nutzer ein HTML-Formular abrufen mit dem er seinen API-Key

FA1.06Nutzer kann neues Projekt erstellen

Ein Nutzer kann ein neues Projekt über die API erstellen. Dabei muss er dem Sys- Alternativ kann ein Nutzer auch ein HTML-Formular abrufen mit dem er ein neues

Projekt erstellen kann.

FA1.07Administrator kann neuem Nutzer Register-Token schicken 18

4 Anforderungsanalyse

abrufen. Dieses Formular kann vom Administrator genutzt werden um einen neuen Register-Token zu erstellen und dem neuen Nutzer an dessen E-Mail zu senden. Dabei muss der Administrator die E-Mail des neuen Nutzers kennen.

FA1.08Administrator kann Nutzer sperren

Ein Administrator kann ein HTML-Formular abrufen um einen Nutzer bei gegebener E-Mail zu sperren. Der gesperrte Nutzer kann daraufhin das System nicht mehr der API des Systems ein. Ein Administrator kann ein HTML-Formular abrufen um einen Nutzer bei gegebener

FA2.01Projektverwalter kann Projekte bearbeiten

Ein Nutzer kann ein existierendes Projekt, bei dem er Projektverwalter ist, über die API editieren. Dabei übergibt er dem System das Projekt und die neuen Werte, welche das Projekt annehmen soll. Alternativ kann der Nutzer ein HTML-Formular zum editieren des Projektes abrufen. Mit diesem Formular kann der Nutzer die Daten des Projektes editieren und danach abspeichern. Ein Nutzer kann ein existierendes Projekt, bei dem er Projektverwalter ist, über die FA2.03Projektverwalter kann Nutzer als Projektteilnehmer zu Projekt hinzufügen Ein Nutzer kann zu einem existierenden Projekt, bei dem er Projektverwalter ist, andere Nutzer über die API als Projektteilnehmer hinzufügen. 19

4 Anforderungsanalyse

Nr.Funktionale AnforderungSeite

Projektverwalter:

FA2.01Projektverwalter kann Projekte bearbeiten19

FA2.03Projektverwalter kann Nutzer als Projektteilnehmer zu Projekt hinzufügen19 FA2.04Projektverwalter kann Projektteilnehmer zu Projektverwalterdes Projektes machen21 FA2.05Projektverwalter kann CRUD Fragebogen innerhalb des Projek-tes21 FA2.06Projektverwalter kann CRUD Fragebogenversion innerhalb ei-nem Fragebogen des Projektes21 FA2.07Projektverwalter kann Fragebogenresultat zu einem Fragebo-gen des Projektes hinzufügen21 FA2.08Projektverwalter kann Fragebogenresultat-Kollektion zu einemFragebogen des Projektes abrufen22 FA2.09Projektverwalter kann Fragebogen-Schema mit anderen Nut- zern teilen22

Projektteilnehmer:

FA2.10Projektteilnehmer kann Projekte abrufen22

FA2.12Projektteilnehmer kann Versionen eines Fragebogens des Pro- jektes abrufen23 FA2.13Projektteilnehmer kann Version eines Fragebogens des Projek-tes erstellen23 FA2.14Projektteilnehmer kann Resultat eines Fragebogens des Pro- jektes erstellen23 Tabelle 4.2: Projektspezifische funktionale Anforderungen 20

4 Anforderungsanalyse

Alternativ kann der Nutzer ein HTML-Formular abrufen mit dem er andere Nutzer als Projektteilnehmer zu diesem Projekt hinzufügen kann. FA2.04Projektverwalter kann Projektteilnehmer zu Projektverwalter des Projek- tes machen Ein Nutzer kann Projektteilnehmer eines Projektes, bei dem er Projektverwalter ist, zu Projektverwalter des Projektes über die API machen. Alternativ kann der Nutzer ein HTML-Formular abrufen um Projektteilnehmer des Projektes zu Projektverwaltern zu machen. Mit diesem HTML-Formular kann er Pro- jektteilnehmer des Projektes, zu Projektverwaltern machen. FA2.05Projektverwalter kann CRUD Fragebogen innerhalb des Projektes Ein Nutzer der Projektverwalter eines Projektes ist, kann alle CRUD Funktionen auf die Fragebogen-Ressource über die API anwenden, wenn die Ressource zu dem lich kann er über den Web-Client auch die Fragebogen-Ressource abrufen. FA2.06Projektverwalter kann CRUD Fragebogen-Version innerhalb einem Frage- bogen des Projektes Fragebogen-Ressourcen des Projektes, die CRUD Funktionen auf der Fragebogenversion-

Ressource ausführen.

Ressource abrufen und ausführen. Darüber hinaus kann er über den Web-Client die

Fragebogenversion-Ressource auch abrufen.

FA2.07Projektverwalter kann Fragebogenresultat zu einem Fragebogen des Pro- jektes hinzufügen 21

4 Anforderungsanalyse

Fragebogen-Ressourcen eine Fragebogenresultat-Ressource erstellen und über die API hinzufügen. Alternativ kann der Nutzer auch ein HTML-Formular zum erstellen einer Fragebogenresultat- Ressource erstellen und zu einer Fragebogen-Ressource des Projektes über das

HTML-Formular hinzufügen.

FA2.08Projektverwalter kann Fragebogenresultat-Kollektion zu einem Fragebo- gen eines Projektes abrufen. Ein Nutzer kann zu einem Projekt, bei dem er Projektverwalter ist, zu allen Fragebogen-quotesdbs_dbs25.pdfusesText_31

[PDF] Bachelorarbeiten 2016 - Lehrstuhl für Allgemeine

[PDF] bachelorette party - Anciens Et Réunions

[PDF] BACHELORS PROGRAMME ANNUEL 2016-2017 - Gestion De Données

[PDF] bachelorstudiengang politikwissenschaft - Fakultät Wirtschafts

[PDF] bachelor`s degree in economics and management - Science

[PDF] Bachelor`s Degree in Performance Sports Textile and - Gestion De Projet

[PDF] Bachelor`s degree of international management - Anciens Et Réunions

[PDF] Bachelor`s degrees - Anciens Et Réunions

[PDF] Bachelot Bernard, Louis XIV en Algérie. Gigeri, 1664

[PDF] Bâches d`alimentation pour petites chaudières vapeur - Anciens Et Réunions

[PDF] bâches et filets - Anciens Et Réunions

[PDF] Bachir KANOUTE Coordinateur Enda ECOPOP Conseiller - Gestion De Projet

[PDF] bachtage - Aachener Bachverein

[PDF] Bach®-Blüte Star of Bethlehem, 20 ml PZN 00161648

[PDF] bacii td