Protokoll zum Projektgruppentreffen vom 13.12.2000 0. Protokollant: Sebastian Freund 1. Anmerkungen zum letzten Protokoll ------------------------------------ - bezgl. Portierung gab es den Vorschlag von jeder Gruppe 6 Testfaelle für Herrn Müller zu erstellen -> bisher von keiner Gruppe ein Feedback erhalten 2. Subsystembildung durch Restrukturierung (Schuetzler) ------------------------------------------------------- - Anmerkungen welche Vorstellungen Prof. Bothe hat: + Code aufteilen in verschiedene Teilsysteme durch schrittweises Aufstueckeln + Ziel: System in Komponenten - Vortrag von Herrn Schuetzler mit Handout + Teilsysteme beschreiben durch geordnete Filestruktur gemaess Use-Cases (siehe Handout Punkt 3 -> "Vorgehen konkret") + Idealzustand wie von Prof. Bothe beschrieben nicht erreichbar Grund: Vermischung der Use-Cases und Oberflaechenprogrammierung - Anmerkungen zu "Subssystembestimmung verwendete Methoden" + zu 1.: Zusammenhang zwischen Uses-Cases und Code + zu 2.: Schuetzler: Software ist anzusehen, ob vom Team bearbeitet oder nur ein Entwickler am Werk war (Erkennbar an bestimmten Eigenschaften der Software) + zu 4.: Beispiel comhead.h -> Aufsplittung in 4 Module moeglich insgesamt die 3 wichtigsten Headerdateien aufgesplittet (comhead.h, comclass.h & m_devcom.h) + zu 7.: Wortmeldung Prof. Bothe: Warum nicht UML statt Entity Relationship Modell? Fuer diesen Fall doch besser ge- eignet?! - Ergebnis nach Neusortierung der Filestruktur in der Entwicklungsumgebung (siehe Handout Punkt 3) erfolgreich -> Beweis: Screenshot vom erfolgreichen Kompilieren (0 Warnings!) *Protokollant schaut unglaeubig* ;-) - Wortmeldung Prof Bothe: Welche Konsequenzen gibt es fuer die anderen Projekt- mitarbeiter durch die veraenderte Filestruktur? Antwort Schuetzler: neue CVS Struktur -> Verzeichnisname in CVS: .../NEUE_STRUKTUR/ + alten Quellen noch in ihrer bisherigen Struktur vorhanden + wer Files aendert, bitte Mail an ihn schreiben + uebertraegt die Aenderungen in die neue Struktur - Vorschlag Sacklowski: alle am alten System weiterarbeiten, spaeter wird dann ein Schnitt kommen -> Uebergang zu neuer Struktur - Vorschlag Sacklowski: Detecuse eingefuehrt -> counters.cpp dort raus, weil dort Zaehlerfenster enthalten ist -> muss immer da sein - CCD-Scan (Punkt 3: ccdscans) zur Zeit noch nicht moeglich, obwohl schon als Use-Case definiert - Wortmeldung Prof. Bothe: Welche Tools koennen Subsystembildung vereinfachen oder gar automatisieren? Antwort Schuetzler: + Bauhausprojekt einige Ansaetze zur Subsystembildung + Dominanzbaeume finden + Bojic-Tool? -> Ansaetze da, aber alles in allem nicht dafuer geeignet (Grund: Debug-Code nicht brauchbar) - Wortmeldung Buss: Objektorientierte Struktur beachtet ? Antwort Schuetzler: Hauptaugenmerk auf die Uses-Cases gerichtet 3. Dokumentation des Reverse Engineerings (Prof. Bothe) ------------------------------------------------------- - Handout ausgegeben - Unterschied: forward engineering -> Anforderungsspezifikation reverse engineering -> Verhaltensspezifikation -> beide sollen aber das externe Verhalten beschreiben, allerdings gehoeren zum Beispiel keine Fehler ins Pflichtenheft - zentraler Punkt: Was soll anders werden in der Verhaltensspezifikation ? Loesung: soll Bestandsaufnahme zum aktuellen System werden - Problemfaelle: wie die Grenzbereiche (ungeklaertes Verhalten, Fehler enthalten?...siehe Handout) behandeln ? - Vorschlag fuer die Nummerierungsart der Dokumente -> Wechsel der Vorkommastelle nur bei grundlegenden Aenderungen im Dokument - Vorschlag: + Aenderungen zur vorherigen Version in einem Abschnitt des Doku- mentes angeben? + Frage: ans Ende oder nach Punkt 7 ? (siehe Handout "Verhaltensspezifikation") + Vorschlag Sacklowski: am Anfang kurze verbale Beschreibung, am Ende dann ausfuehrlich - Gliederung am Anfang des Dokumentes angeben -> dann beginnen mit: zu 1. (Punkte der Reihenfolge nach abarbeiten) - Vorschlag Schuetzler: da HTML verwendet wird, bieten sich fuer solche Sachen Links an, um von der Gliederung schnell zum Punkt der Ausfuehrung zu kommen - zu 5. Aenderungswuensche: erst knapp (bei den ersten Versionen), aber spaeter dann konkret (letzten Versionen) -> am Ende wird es das Pflichtenheft fuer die- jenigen, die Erweiterungen durchfuehren werden - zu 8. Glossar: Vorschlag Freund: ein grosses Glossar zentral und im Dokument nur die dort verwendeten Begriffe - zu 9. Verwandte Dokumente: HTML-Links zu anderen Dokumenten - Kritikpunkt: + Aenderungswuensche bzw. Fehler sind auch in der funktionalen Beschreibung aufgetaucht -> Vorschlag: deshalb die Maengel & Fehler in 4. + aber Fehler sind gleich zu erkennen wenn sie in 2. auch auf- tauchen - Vorschlag von Prof. Bothe: #Kennung Fehler nennen in 2. und konkret in 4. beschreiben - Vorschlag von Schuetzler: ueber Links in Hin- und Rueckrichtung verweisen - Vorschlag von Sacklowski: Hochziehen von erledigten Aenderungswuenschen in funktionale Beschreibung nach Bearbeitung - Prof. Bothe preferiert eine klare Abgrenzung, d.h. Kennzeichnung bei 5. als "erledigt", wenn die Aenderungswuensche bearbeitet wurden - dies sind jedoch alles Vorschlaege - Zeit abwarten... 4. Dokumentation der Implementation (Prof. Bothe) ------------------------------------------------- - Bezugspunkt soll die Studienarbeit von Picard, Harder, Paschold bilden (siehe letztes Blatt vom Handout) - zur Orientierung reicht eine Kommentierung der Quelltexte allein nicht aus, deshalb soll es auch eine Einfuehrung geben, bzw. es soll auch eine Ab- grenzung der Quellen geben (wie in der Studienarbeit geschehen) - Beschreibung der Klassenattribute nicht unbedingt noetig, weil die Dokumente dadurch unnoetig aufgeblaeht werden (Meinung von Schuetzler, Luetzkendorf, Freund) Begruendung: Grep aus der Entwicklungsumgebung oder Sniff liefern schnell adaequate Ergebnisse - Vorschlag von Luetzkendorf: nicht nur statischen Ablauf festhalten, sondern auch die dynamischen, die das Verstaendis der internen Ablaeufe erleichtern Zusammenfassend: - Studienarbeit soll als Orientierung dienen, vieleicht bei 2. weniger Infor- mationen -> eventuell Erweiterung mit dynamischen Ablaeufen 5. Portierung (Mueller) ----------------------------- - noch in der Phase der Analyse: Einteilung in Problemklassen - derzeit noch nicht alle Problemklassen (Assembler-Code, dll's,....) - Verfahren mit Problemklassen: Anlegen einer Tabelle in der jedes Problem mittels entsprechenden Code beschrieben wird und wie die Loesung zu erfolgen hat - anhand der Problemklassen und der Anzahl der Elemente soll ein Zeitmass be- rechnet werden (Aufwandsmass) - Testfaelle noetig, ob alles erfasst wurde - bis jetzt 98% erfasst - Problem: Verfahren geht nur in einem Rutsch und deshalb sehr fehleranfaellig (arbeitsweise erfolgt schon schrittweise, aber trotzdem in einem Durchlauf) - Wortmeldung Sacklowski: mit dem Kithara-Tool geht alles klar - Softwarepaket trifft demnaechst ein - eventuell wird noch dieses Jahr mit dem ersten Versuch der Portierung begonnen 6. Meldungen der anderen Arbeitsgruppen --------------------------------------- - Hepp/Freund: + Diplomarbeit in Bearbeitung + geplanter Test von unterschiedlichen Probenklassen - Buss: + Pflichtenheft fertig + noch Probleme loesen die durch fehlerhafte Darstellungen und Um- rechnungen auftreten - Berndt/Ullrich: Fehlerlisten erweitert und Pflichtenheft verbessert - Luetzkendorf: + Pflichtenheft fehlerbereinigt und erweitert + angefangen mit der Dokumentation fuer die Implementation der Motoren - Vorschlag von Prof. Bothe: naechstes Treffen Anfang Februar