I.) Gruppenbildung: Es werden Gruppen zwischen 2 und 4 Studenten akzeptiert. Die Einteilung der Gruppen entspricht der Gruppeneinteilung der Übung.
Zudem wird die Aufgabenstellung in den Varianten ET_A, ET_B, MST_A, MST_B heraus gegeben! Die Zugehörigkeit zu dem Varianten ergibt sich aus dem
Zeitplan (siehe ET1-Server). Andere Zuordnungen der einzelnen Gruppen zu den Varianten müssen mit mir im Voraus abgesprochen werden.
II.) Abgabe: Die Abgabe hat UNDBEDINGT auf ZWEI Arten zu erfolgen:
Die Gruppen geben bis ENDE des Sommersemesters (Stichtag 30. Sept. 2011) die Arbeit auf ZWEI Arten gleichzeitig ab:
1.) Per Email (reinhard.ludes@hs-magdeburg.de); WICHTIG: >>> Lauffähiger und dokumentierter Code <<<
UND
2.) Schriftlich mit Angabe: Mitglieder der Gruppe, Name, Vorname, Matr.-Nr. und wichtig: PERSÖNLICHE UNTERSCHRIFT
> VERSPÄTET eintreffende schriftliche Arbeiten werden NICHT akzeptiert (Stichtag ist der 30. Sept. 2011).
III.) Zusammenarbeit zwischen den Gruppen, Übernahme von Fremdfunktionen
Es dürfen Teilfunktionen aus Literatur, Internet und auch aus anderen Gruppen übernommen werden. Die Übernahme muss jedoch dokumentiert sein im Source-Code (=vollständige Quellenangabe).
Nicht dokumentierte Übernahmen werden als nicht anerkannt gewertet!
Es wird erwartet, dass jeder Teilnehmer die GESAMTE Lösung auf Nachfrage persönlich gegenüber dem Prüfer vertreten und erklären kann. Ansonsten die Leistung der gesamten Gruppe oder seine
seine Teilnahme in der Gruppe nicht anerkannt.
Markierung des spezifischen Eigenanteils jeder einzelnen Gruppe im Sourcecode: Es muss MINDESTENS EINE FUNKTION PRO GRUPPE genannt werden, die auf Eigenleistung oder Eigenrecherche der Gruppe beruht und nicht direkt von einer anderen Gruppe übernommen wurde, die zudem für besonders ideenreich und originell gehalten wird! Sie wird einer gesonderten Bewertung unterzogen!
Es müssen vier Punkte gesammelt werden, die auf Eigenleistungen beruhen und NICHT von einer anderen Gruppe stammen
Vollständige Dokumentation der Funktionsabläufe im Sourcecode, ansonsten sofortige Rückgabe seitens des Prüfers.
Testfunktionen: für alle wesentlichen Abläufe müssen Menüpunkte in der Benutzeroberfläche zur Verfügung gestellt werden, die nachweisen, dass die realisierten Funktionen stabil und ohne Absturz funktionieren.
Nicht stabile Versionen und Testabläufe, die schon die Fehlfunktionen dokumentieren, werden OHNE Prüfung SOFORT zurückgewiesen!
Die endgültige Aufgabenstellung liegt bis spätestens Ende KW27 auf dem Fachbereichsserver ("Vorlesungen/Ludes/IFD_SS11/Hausarbeit.. "). Eine Beta-Version ist derzeit schon vorhanden.
2011-06-29, R. Ludes
Aufgabenstellung: Realisieren Sie ein listenbasiertes Verwaltungssystem!
Version: 2011-06-29; Betaversion, Änderungen bis 10. Juli noch möglich!!
I.) Generelle Anwendung:
Variante ET_A: "für Mitarbeiter" mit den Informationen Personalnummer, Name, Gehalt pro Monat
Variante ET_B: "für Bücher" mit den Informationen BuchNr, Titel, Anzahl Variante MST_A: "für Ersatzteile" mit den Informationen Teile-Nr, Bezeichnung, Anzahl
Variante MST_B: "für Lebensmittel" mit den Informationen Artikel-Nr, Bezeichnung, Anzahl
II.) Generelle Realisierung: Setzen Sie in allen Fällen ein einfach verkettetes Listensystem sein, dessen Einzelelement auf einer geeigneten Strukturen beruht. Fügen Sie neue Elemente am Anfang der Liste ein.
III.) Mindestfunktionen, die von der Konsole den Benutzer angeboten werden sollen: 1. Neueingabe eines Eintrages 2. Löschen eines Eintrages, der dem Kriterium Pers-, Buch-, Teile- bzw. Artikelnummer entspricht bzw. Hinweis/Fehlermeldung, wenn nicht vorhanden in Liste 3. Darstellung des aktuellen Listeninhaltes
IV.) Individuelle Zusatzfunktionen, die in der Summe auf 4 Punkte kommen müssen:
Achtung: Diese Funktionen sollte von jeder Gruppe individuell realisiert werden! Auch hier können Literatur- und Internet-Inhalte herangezogen und zitiert werden.
Allerdings werden nur Realisierungen anerkannt, die sich von anderen Gruppen definitiv unterscheiden.
Im Folgenden werden Anregungen und Beispiele gegeben, was jede Gruppe individuell realisieren kann. Dies ist keine Beschränkung, sondern nur eine Orientierung!
IV.1) Beispiele, jeweils max1P:
ET_A:
- Verhindern der Eingabe einer doppelten bzw. schon vorhandenen Personalnummer;
- Berechnung der Summe der Mitarbeiter
ET_B, MST_A, MST_B: - Erlauben der Eingabe einer doppelten Buch-/Teile-/Artikel-Nr., wenn die Titel bzw. Bezeichner identisch sind, dabei jedoch Erhöhung des Eintrages "Anzahl" - Berechnung der Summe der Artikel
Alle Varianten: - Suche nach Personal-, Buch-, Teile- bzw. Artikel-Nr.: Anzeige beim Finden, sonst Fehlermeldung - Sonstige Funktionen zur Erhöhung der Ergonomie und Benutzerfreundlichkeit, sorgfältiges Abfangen von Fehlern, besonders bei Benutzereingaben - Ansprechende optische Gestaltung der Benutzeroberfläche (natürlich nur im Rahmen der nicht-grafischen Konsolenoberfläche !!!) - Weitere Nutzdateneinträge realisieren in der Datenstruktur - Löschen des ersten Elementes - Löschen des letzten Elementes
IV.2.) Beispiele, jeweils max.2P: - Auf Userwunsch: Einfügen bei Neueingaben am Ende der Liste (Sortierschlüssel dabei ist: Personal-, Teile-, Artikel- bzw. Buch-Nummer) - neue Funktionalitäten realisieren aufgrund zusätzlicher Nutzdateneinträge in der Datenstruktur
IV.3) Beispiele, jeweils max.3P: - Abspeicherung und Zurückholen der erstellten Liste auf Datei zwecks Weiterbearbeitung - Sortiertes Einfügen bei Neueingaben in die Liste statt Einfügung am Anfang der Liste (Sortierschlüssel: Personal-, Teile-, Artikel- bzw. Buch-Nummer)
IV.4.) Beispiele, jeweils max. 4P: Realisierung einer automatisierten Testfunktion, die die realisierten Basis-Funktionen separat testet und die Ergebnisse am Bildschirm und/oder auf Datei ausgeben. In anderen Worten: Start der Testfunktion über Benutzeroberfläche, ggf. Abfrage von Parametern oder Wertebereichen vom User, in Abhängigkeit davon automatisches "Füllen" einer exemplarischen Liste mit Werten, dann automatisches Starten aller Benutzerfunktionen und Ausgabe der Ergebnisse um zu zeigen, dass die realisierten Listenfunktionen alle ordnungsgemäß arbeiten.
V.) Hilfen und Hinweise, wie in der Vorbereitung schon besprochen: Listenelement und Listenkopf kann als identische structure vom Typ "list_elem" realisiert werden, jedes Element wird mit new dynamisch erzeugt und beinhaltet die in der Aufgabenstellung geforderten Elemente. Listenelement und Listenkopf Der verwendete Datentyp kann wie oben erläutert gleich sein, sich aber ggf. um einen "Marker Eintrag" unterscheiden, z.B. Artikel- oder Pers-Nr. auf Null setzen, das Teile- ArtNr-, BuchNr-Feld dann für den Namen der Liste verwenden. Ggf. bei jedem Eintrag die Anzahl der eingetragenen Elemente nachziehen. Aber auch das muss nicht unbedingt sein. Beginn der Liste: Pointer auf das erste erzeugte Element der Liste alle Listen-Funktionen: als function realisieren, nicht im Hauptprogramm "herunterprogrammieren". Grundsätzliche Struktur bzw. Deklaration "int funktionsname (list_elem *, ...) Zum Sortieren muss ein Eintrag existieren, der als Sortierschluessel geeignet ist (z.B. ein integer-Element mit/ohne Vorzeichen, auch Zeichenketten lassen sind Sortierkrierien unterwerfen, ist hier aber primär nicht gefordert). Die Aufgaben sind absichtlich frei formuliert und lassen einen großen Freiheitsgrad zu in Hinblick auf den detaillierten Entwurf so wie die konkrete Realisierung. Die Leistung besteht darin, in Gruppenarbeit, und auch in übergreifender Gruppenarbeit, eigene Lösungen zu entwickeln und auf die im Semester erlernten Techniken zurückzugreifen, ggf. auch noch weitere Techniken und Möglichkeiten, die die Sprache C bietet, zu finden bzw. zu erlernen! Die Übernahme großer Teile aus recherchierten Quellen und/oder von anerkannten "Leistungsträgern" des Kurses mit davon ausgehenden individuellen Anpassungen, um mit den erworbenen Code vertraut zu werden ist ausdrücklich NICHT untersagt!