1926050: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(93 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 4: Zeile 4:
|studiengang=IAM 2006
|studiengang=IAM 2006
|lehrveranstaltung=Multimedia-Anwendungen/Programmierung
|lehrveranstaltung=Multimedia-Anwendungen/Programmierung
|kürzel=
|kuerzel=
|pruefung=
|pruefung=nicht mehr angeboten
|pruefungsart=Prüfungspraktikum, Studienarbeit
|pruefungsart=Präsentation, Studienarbeit
|details=Prüfungspraktikum: 3h
|details=
|hilfsmittel=
|hilfsmittel=
|zweitpruefer=Wolfgang Kowarschick
|zweitpruefer=
|inhalte===Studienarbeit==
|inhalte=<!--==Termine==
<dl>
  <dt>22. März 2020:</dt>
  <dd>Abgabe der Anwendungsfälle (Use-Cases) via [https://gitlab.multimedia.hs-augsburg.de/ACCOUNT/ Git-Repository] und Link in [https://moodle.hs-augsburg.de/course/view.php?id=2857 Moodle]</dd>
  <dt>29. März 2020:</dt>
  <dd>Abgabe des Datenmodells: UML-Klassendiagramm (einschließlich textueller Beschreibung) sowie zugehöriger JavaScript-Dateien, die dieser Struktur genügen (die Implementierungen der Klassen und Funktionen dürfen noch fehlen)<br />
      Datenmodell als PDF-Datei sowie JavaScript-Dateien im [https://gitlab.multimedia.hs-augsburg.de/ACCOUNT/ Git-Repository], Link auf den Ordner im Repository in [https://moodle.hs-augsburg.de/course/view.php?id=2857 Moodle]
  </dd>
  <dt>24. April 2020 (Uhrzeiten werden in Moodle bekanntgegeben):</dt>
<dd>Zwischenpräsentation eines '''lauffähigen Prototyps''' der Studienarbeiten (die Präsentation eines Datenmodells reicht nicht aus)
</dd>
<dt>5. Juni 2020 (Uhrzeiten werden in Moodle bekanntgegeben):</dt>
<dd>2. Zwischenpräsentation eines '''lauffähigen Prototyps''' der Studienarbeiten (es muss ein Fortschritt gegenüber der ersten Präsentation sichtbar sein)
</dd>
  <dt>Prüfungspraktikum entfällt</dt>
  <dd><strong>Die Teilnahme an der Prüfung ist ohne Prüfungspraktikum möglich.</strong>
  </dd>
  <dt>12. Juli 2020</strong></dt>
  <dd>Abgabe der vollständigen Studienarbeit
      einschließlich einer [https://moodle.hs-augsburg.de/course/view.php?id=3263 Erstellungserklärung]
      unter [https://moodle.hs-augsburg.de/course/view.php?id=3263 Moodle] und als Inhalt eines Git-Repositories.
  </dd>
<dt>15./16./17. Juli 2020, J2.10 (die genauen Termine werden nach der Endabgabe bekanntgegeben):</dt>
  <dd>Präsentation der Ergebnisse.
      Sie müssen Ihre Anwendung erklären und Ihre Anwendung demonstrieren können.
      Sie brauchen keine Präsentationsfolien vorzubereiten.
  </dd>
</dl>


Als Teilnehmer der Lehrveranstaltung „Multimedia-Anwendungen/Programmierung“ (MMProg) sollen Sie nachweisen, dass Sie in der Lage sind, eine einfache interaktive Web-Anwendung mit Hilfe von HTML 5 und JavaScript (ECMAScript 5.1) zu erstellen.
Beachten Sie, dass in dem Dokument [https://moodle.hs-augsburg.de/course/view.php?id=2857 Erstellungserklärung] auch eine Abgabeliste enthalten ist, in der genau aufgelistet wird, was Sie in welcher Form abgeben müssen.


Sie müssen daher im Rahmen einer Studienarbeit eine derartige Anwendung gemäß den in der Vorlesung vermittelten Prinzipien realisieren. Am Ende des Semesters müssen Sie Ihre Arbeit präsentieren. Sie können sich das Thema (in Absprache mit mir) selbst aussuchen.  
Darüber hinaus müssen Sie im Laufe des Semesters regelmäßig den aktuellen Stand Ihrer Arbeit im Git-Repository, das Ihnen am Anfang des Semesters zur Verfügung gestellt wurde, zwischenspeichern. Das heißt, vor jeder Zwischenabgabe müssen mindestens 5 Versionen der abzugebenden Dokumente ins Repository eingefügt werden. Von der eigentlichen Implementierung der Studienarbeit müssen vor der Endabgabe jeweils mindestens 30 substanziell verschiedene Versionen ins Repository eingefügt werden.
-->
==Studienarbeit==


Da sich die in die Vorlesung und im Praktikum verwendeten Beispiele und Aufgaben mit dem Themenbereich Spiele befassen ist es empfehlenswert als Studienarbeit ebenfalls ein einfaches Spiel zu programmieren. Anbei finden Sie eine exemplarische und unvollständige Liste mit Themenvorschlägen:
Als Teilnehmer der Lehrveranstaltung „Multimedia-Anwendungen/Programmierung“ (MMProg) sollen Sie nachweisen, dass Sie in der Lage sind, eine interaktive Web-Anwendung mit Hilfe von HTML 5 und JavaScript (ECMAScript 6) zu erstellen.


*    Mini-Billard
Sie müssen daher im Rahmen einer Studienarbeit eine derartige Anwendung gemäß den in der Vorlesung vermittelten Prinzipien realisieren.  
*    Mini-Mohrhun
Am Ende des Semesters müssen Sie diese Arbeit präsentieren. Während des Semesters gibt es Zwischenpräsentationen. Die Teilnahme ist jeweils Pflicht, da die Zwischenpräsentationen Bestandteil der Prüfung sind.
*    Geschicklichkeitsspiel: herabfallende Gegenstände sammeln, Ballerspiel, ...
*    Snake
*    Memory
*    Vier gewinnt, Fünf gewinnt, Reversi ... (zwei Spieler, evtl. auch ein Spieler + KI)
*    Point-and-Click (2D)
*    Jump-and-Run
*    Spielephysik
*    Tic Tac Toe
*    Pong
*    Doodle Jump
*    Flappy Bird


Sie können die Studienarbeit auch als Zweier- oder Dreier-Teams realisieren. In diesem Fall muss die Arbeit allerdings aus mehreren eigenständigen Teilen bestehen. Jedes Teammitglied ist für die Planung und Realisierung eines dieser Teile verantwortlich. Jedes Teammitglied muss einen angemessenen Teil der Anwendung implementieren sowie selbstständig (d.h. nicht in Teamarbeit) eine Studienaufgabe bearbeiten.
Sie können sich das Thema (in Absprache mit dem Dozenten) selbst aussuchen.


Beachten Sie, dass Sie im Falle einer Wiederholungsprüfung eine vollkommen neue Arbeit erstellen müssen.
<!--
Da sich die Vorlesung und das Praktikum an dem Thema Spiele orientieren, ist es sinnvoll ein Spiel als Studienarbeit zu programmieren.


==Dokumentation==
Anbei finden Sie eine exemplarische und unvollständige Liste mit Themenvorschlägen:
Die Dokumentation der Studienarbeit (ein PDF-Dokument) muss Folgendes enthalten (siehe auch die Abgabeliste im Anschluss an die [http://www.hs-augsburg.de/medium/download/lehrveranstaltung/kowarschick/mmprog/erstellungserklaerung-mmprog.pdf Erstellungserklärung]):


#    den Autor/die Autoren der Anwendung
#    Mini-Billard
#    den Namen der Anwedung
#    Mini-Mohrhuhn
#    eine aussagekräftige Kurzbeschreibung der Anwendung
#  Geschicklichkeitsspiel: herabfallende Gegenstände sammeln, Ballerspiel, ...
#    eine kurze Installationsanleitung (falls notwendig)
#    Snake
#    eine kurze Bedienungsanleitung
#    Memory
#    ein technisches Konzept der Anwendung
#    Vier gewinnt, Fünf gewinnt, Reversi ... (zwei Spieler, evtl. auch ein Spieler + KI)
##      wichtige Bestandteile: Modellierungsentscheidungen, Strukturierung/Aufbau des Codes, angewendete Programmierparadigmen, verwendete Technologien und jeweils Begründungen für diese Entscheidungen
#    Point-and-Click (2D)
##      das Konzept muss einen Teil in Textform enthalten und darf ergänzend Grafiken und Diagramme enthalten (frei in Form)
#    Jump-and-Run
##       UML-Diagramme dürfen gerne verwendet werden, sind aber kein Pflichtbestandteil
#   Spielephysik
#    Quellenangaben zu allen für die Arbeit verwendete Quellen: Software, fremde Bibliotheken, fremde Algorithmen, Literatur (Nachschlagewerke) etc.
#   Tic Tac Toe (2-dimensional oder 3-dimensional)
#    Bei mehreren Autoren: Eine Übersicht, welcher Autor für welche Teile der Arbeit verantwortlich ist.
#   Pong
#   Doodle Jump
#    Flappy Bird
#    Bubble Worlds
#  ...


==Implementierung==
Beachten Sie, dass Sie im Falle einer Wiederholungsprüfung eine vollkommen neue Arbeit erstellen müssen.


Sie müssen bei der Erstellung der Arbeit darauf achten, dass Sie verständlichen (insbesodere lesbaren), möglichst wiederverwendbaren sowie leicht wart- und erweiterbaren Code nach anerkannten objektorientierten Programmierprinzipien schreiben. Beachten Sie bitte insbesondere Folgendes:
==Wiederverwendung von Code==


Die Anwendung muss mit mit HTML5/JavaScript erstellt werden.
Sie sind dazu berechtigt fremden Code in Ihrer eigenen Arbeit zu verwenden, solange dies durch dessen Lizenz erlaubt ist.


Setzen Sie in Ihrer Anwendung mehrere der komplexeren Programmiertechniken und -prinzipien ein, die in der Vorlesung vorgestellt werden:
Dazu zählen auch sämtliche Code-Beispiel und Musterlösungen aus der Lehrveranstaltung.
Für jeglichen fremden Code müssen Sie die Quelle korrekt angeben.
Ihre Studienarbeit kann als '''mangelhaft''' bewertet werden, wenn der Eigenanteil an der Arbeit zu gering ist,
{{dh}}, wenn Sie überwiegend vorgefertigten Code zur Realisierung der Arbeit einsetzen.


*    Dynamischer Umgang mit Objekten (und Funktionen)
<!--
*    (Prototypische) Vererbung
==Bewertung==
*    Browser-API
*    DOM API
*    Canvas/SVG
*    JSON
*    Timer-Programmierung
*    Event-Verarbeitung/Callbacks
*    Model-View-Controller


==Bewertung==
Sie müssen bei der Erstellung der Arbeit darauf achten, dass Sie verständlichen, lesbaren, modularen und wiederverwendbaren Code
nach anerkannten objektorientierten Programmierprinzipien schreiben. Die Anwendung muss mit mit HTML5 und JavaScript erstellt werden.


In die Bewertung der Studienarbeit fließen ein:
In die Bewertung fließen ein:


*    Studienarbeit
*    Studienarbeit
**        Dokumentation
**        Angewendete Programmiertechniken
***           Verständlichkeit
***            Klassen, Objekte, Objektbuilder
***           Umfang (1=angemessen, ..., 5=viel zu wenig)
***            Event-Listener, Verarbeitung von Events
****             Je nach Komplexität ist ein '''technisches Konzept''' von 1 bis 2 Seiten ausreichend
***           Modularisierung (Datei- und Code-Ebene)
**       Implementierung
***           Timer (setTimeout, setInterval)
***           Lesbarkeit
**        Qualität
***           Struktur
***            Qualität der Modularisierung (Datei- und Code-Ebene)
****             Verwendung von Model-View-Controller oder ähnlich sinnvollem Paradigma
***           Sinnvolle Benennung, Aussagekraft
***           Komplexität
***            Wiederverwendbarkeit, Konfigurierbarkeit
***           Wiederverwendbarkeit
***           Korrektheit, keine Fehler
***          Umfang (1=angemessen, ..., 5=viel zu wenig)
***           Keine Redundanz (DRY)
****             Eine Implementierung mit mehreren 1000 Codezeilen geht deutlich über die Anforderungen hinaus.
***       Logic-Data-View-Controller(-Service)-Prinzip
****             Ein Umfang, der über die Anforderungen hinaus geht, kann zur Aufwertung der Arbeit führen.
****            Qualität der Model-Module
****              Bei Teamarbeit: Jeder Teilnehmer muss einen wesentlichen Teil des Codes implementieren und namentlich kennzeichnen.
****            Qualität der View-Module
****            Qualität der Controller-Module
****            Qualität der Logik-Module
**        Tiefe
***           Komplexität des selbst erstellten Codes
**       Dokumentation (Use-Cases, Klassendiagramm samt Beschreibungen)
***            Vollständigkeit
***           Verständlichkeit
***            Korrektheit
***           Inline-Kommentare (im Sourcecode)
***           Quellenangaben
*    Prüfungspraktikum
*    Prüfungspraktikum
**        Qualität der Lösungen des Prüfungspraktikums (1=sehr gut, ..., 5=mangelhaft)
**        Qualität und Korrektheit der Lösungen
 
Die Bewertung '''einer der Hauptkatgorien''' als '''mangelhaft''' führt dazu, dass die '''gesamte Arbeit''' als '''mangelhaft bewertet''' wird.


Die Bewertung '''einer der Hauptkategorien''' „Programmiertechniken“, „Qualität“, „Umfang“, „Dokumentation“, „Prüfungspraktikum“ als '''mangelhaft''' führt dazu, dass die '''gesamte Arbeit''' als '''mangelhaft bewertet''' wird. Eine Arbeit, die nicht gemäß einen Pattern wie MVC oder LDVC strukturiert ist, wird höchstens als
''ausreichend'' bewertet. 
-->
==Nichtteilnahme und Plagiate==
Die gesamte Arbeit wird als '''mangelhaft''' bewertet, sobald auch nur ein '''Plagiat''' enthalten ist.  
Die gesamte Arbeit wird als '''mangelhaft''' bewertet, sobald auch nur ein '''Plagiat''' enthalten ist.  


Zeile 99: Zeile 130:
Die Arbeit wird als unvollständig und damit als '''nicht abgegeben''' gewertet, wenn ein wesentlicher Bestandteil fehlt, d.h., wenn '''in der Abgabeliste''' im Anschluss an die Erstellungserklärung '''eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste fehlt'''.
Die Arbeit wird als unvollständig und damit als '''nicht abgegeben''' gewertet, wenn ein wesentlicher Bestandteil fehlt, d.h., wenn '''in der Abgabeliste''' im Anschluss an die Erstellungserklärung '''eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste fehlt'''.


Die Arbeit wird als unvollständig und damit als '''nicht abgegeben''' gewertet, wenn '''die grobe Enstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im SVN-Repository nachvollzogen werden kann''' (entweder '''regelmäßige''' Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).
Die Arbeit wird als unvollständig und damit als '''nicht abgegeben''' gewertet, wenn '''die grobe Entstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im GIT-Repository nachvollzogen werden kann''' (entweder '''regelmäßige''' Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor jeder Zwischenabgabe und anschließend mindestens 20 einschlägige Updates vor der Endabgabe).
}}
}}

Aktuelle Version vom 11. Februar 2023, 11:30 Uhr


Diese Prüfung wird nicht mehr angeboten.
 

Nummer 1926050
Studiengang Interaktive Medien (IAM 2006)
Modul Multimedia-Anwendungen
Lehrveranstaltung Multimedia-Anwendungen/Programmierung
Alternativname Multimedia-Programmierung, MMProg
Kürzel i4.MM
Prüfer
Zweitprüfer
Prüfung Diese Prüfung wird nicht mehr angeboten.
Prüfungsart Studienarbeit, Präsentation
Details
Hilfsmittel

Studienarbeit

Als Teilnehmer der Lehrveranstaltung „Multimedia-Anwendungen/Programmierung“ (MMProg) sollen Sie nachweisen, dass Sie in der Lage sind, eine interaktive Web-Anwendung mit Hilfe von HTML 5 und JavaScript (ECMAScript 6) zu erstellen.

Sie müssen daher im Rahmen einer Studienarbeit eine derartige Anwendung gemäß den in der Vorlesung vermittelten Prinzipien realisieren. Am Ende des Semesters müssen Sie diese Arbeit präsentieren. Während des Semesters gibt es Zwischenpräsentationen. Die Teilnahme ist jeweils Pflicht, da die Zwischenpräsentationen Bestandteil der Prüfung sind.

Sie können sich das Thema (in Absprache mit dem Dozenten) selbst aussuchen.

Nichtteilnahme und Plagiate

Die gesamte Arbeit wird als mangelhaft bewertet, sobald auch nur ein Plagiat enthalten ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn eine der Zwischenabgaben nicht erfolgt ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn ein wesentlicher Bestandteil fehlt, d.h., wenn in der Abgabeliste im Anschluss an die Erstellungserklärung eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste fehlt.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn die grobe Entstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im GIT-Repository nachvollzogen werden kann (entweder regelmäßige Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor jeder Zwischenabgabe und anschließend mindestens 20 einschlägige Updates vor der Endabgabe).

Abgerufen von „https://glossar.hs-augsburg.de/w/index.php?title=1926050&oldid=51047“