Wymagania

AAL - projekt: zalecenia ogólne
Proponowane problemy algorytmiczne są do opracowania indywidualnego. Może się zdarzyć, że to
samo lub b. podobne zadania projektowe są proponowane kilku studentom, praca projektowa
powinna mieć jednak charakter w 100% indywidualny i wykryte przypadki współdzielenia kodu,
itp. będą podlegały sankcjom.
Opracowywane algorytmy i realizujące je programy powinny spełniać następujące ogólne kryteria:
Język programowania. Projekt należy wykonać w języku C/C++. Program powinien być przenośny
i dać się skompilować/wykonać zarówno na platformie Linux jak i (opcjonalnie) Windows. Uwaga:
nie należy nadużywać mechanizmów obiektowych, projekt z AAL dotyczy algorytmów a nie
programowania obiektowego, tak więc mechanizmów obiektowych należy używać w taki sposób i
tam gdzie są one uzasadnione i upraszczają implementację, a nie jako "sztuki dla sztuki".
Samodokumentowanie. Każdy projekt powinien zawierać plik tekstowy readme.txt, w którym
należy umieścić zwięzłe informacje dotyczące organizacji kodu źródłowego oraz podstawowe dane
o problemie i algorytmie. W szczególności powinna tam znaleźć się:
 "wizytówka" studenta
 krótka specyfikacja problemu (albo przynajmniej tytuł problemu) – jednoznacznie identyfikujący
realizowane zadanie
 informacja o możliwych poleceniach aktywacji programu (opcje, parametry, ...)
 opis konwencji dotyczących danych wejściowych i prezentacji wyników
 krótki opis metody rozwiązania, zastosowanych algorytmów i struktur danych
 informacje o funkcjonalnej dekompozycji programu na moduły źródłowe - nagłówkowe i
implementacyjne ("przewodnik" po plikach źródłowych)
 inne informacje dodatkowe o szczególnych decyzjach projektowych (np. ograniczenia dotyczące
rozmiaru problemu, charakterystyki generatorów danych testowych, specjalne konwencje w
alokacji pamięci dynamicznej, wymagania dotyczące typów parametryzujących szablony,
konwencje związane z obsługą sytuacji wyjątkowych, itp.).
UWAGA: Plik readme.txt nie zastępuje dokumentacji końcowej.
Każdy plik źródłowy musi być opatrzony komentarzem nagłówkowym z nazwiskiem studenta i
tytułem problemu.
Dekompozycja. Program składa się z dwu logicznych części: części realizującej struktury danych i
algorytmy potrzebne w rozwiązaniu problemu (definicja i implementacja odpowiednich klas) oraz z
części realizującej interfejs użytkownika. Projektując warstwę algorytmiczną należy oczywiście
brać pod uwagę potrzeby interakcji z użytkownikiem i stosowane konwencje wejścia-wyjścia, ale
nie powinno to powodować sztywnego związania z tymi konwencjami (np. zmiana konwencji WEWY z tekstowej na graficzną nie powinna wymagać modyfikacji warstwy algorytmicznej, a jedynie
modyfikację/uzupełnienie warstwy odpowiedzialnej za interfejs użytkownika).
Samoprezentacja programu. Program powinien zachowywać się bez tajemnic użytkowych. W
szczególności jeden z typowych sposobów aktywacji programu (np. wg konwencji systemu UNIX)
powinien pokazywać wszystkie prawidłowe formy aktywacji lub podawać nazwę pliku z
informacjami dodatkowymi.
Wybór konwencji we-wy. Jeżeli program może ograniczyć się tylko do WE-WY znakowego, to
wystarczy zatroszczyć się o prostą i czytelną prezentację danych i wyników. W niektórych
przypadkach, przy spełnieniu pewnych ograniczeń, można wyniki prezentować w postaci
pseudograficznej (czyli znakowo z uproszczonym wrażeniem graficznym). Wiele z proponowanych
problemów wymaga jednak prezentacji graficznej danych i wyników. Interakcyjność nie jest
potrzebna – wystarczy dobrze opracowana bierna wizualizacja.
1
Dane wejściowe (instancje problemu). Wybór danych do testowania algorytmu powinien
uwzględniać szczególne sytuacje istotne z punktu widzenia (1) badania poprawności (2) oceny
złożoności. W większości przypadków generacja instancji problemów wg żądanych rozmiarów jest
zagadnieniem samym w sobie i wymaga opracowania pomocniczych algorytmów generacji.
Bezwzględnie należy unikać „zaszywania” w kodzie nazw plików z danymi wejściowymi czy z
wynikami i innych usztywniających chwytów (np. umieszczania w danych statycznych instancji
testowych problemu).
Tryby wykonania. Program powinien umożliwiać 3 rodzaje wykonań:
1. wg danych dostarczonych ze strumienia wejściowego (standardowego lub pliku) dla sekwencji
konkretnych problemów; ten tryb pozwala testować poprawności dla małych instancji
2. wg danych generowanych automatycznie (losowo) z ewentualną parametryzacją generacji
określaną przez użytkownik; ten tryb także służy do testowania poprawności
3. wykonanie z generacją danych, pomiarem czasu i prezentacją wyników pomiarów.
Dla niektórych problemów mogą być celowe inne tryby wykonania lub jeden z trybów wykonania
1, 2 podanych wyżej może okazać się zbędny (do ustalenia z prowadzącym).
Styl. W programie należy przestrzegać zasady dobrego stylu kodowania (przejrzysty układ tekstu
programu uwzględniający konstrukcje zagnieżdżone; odpowiednia zawartość i porządek konstrukcji
językowych w plikach źródłowych; stosowanie identyfikatorów ułatwiających zrozumienie kodu;
zwięzłe komentarze dla funkcji nietrywialnych; komentarze objaśniające algorytm wewnątrz
funkcji). Nazwy plików powinny sugerować ich zawartość i rolę w programie.
Przed przekazaniem projektu do oceny proszę przeczytać kod i usunąć pozostające zwykle po fazie
uruchamiania rozmaite nieużytki, dziwne komentarze itp. Proszę także zatroszczyć się o uzyskanie
kodu z czystą kompilacją (bez ostrzeżeń).
Dokumentacja. Wraz z programem źródłowym trzeba przekazać dokumentację końcową w formie
elektronicznej (dokument pdf jest wystarczający, postać edytowalna nie jest potrzebna) zawierającą
opis problemu i metody (lub metod) rozwiązania, opis wykorzystywanych struktur danych i
algorytmów pomocniczych oraz ocenę spodziewanej złożoności algorytmu (wykorzystaną w trybie
wykonania 3.). Prostą wskazówkę, którą należy kierować się przygotowując dokumentację
programu, zawiera pytanie: czy opis zadowoliłby mnie samego gdybym o problemie i jego
rozwiązaniu miał dowiedzieć się z tego dokumentu? Ewentualne dodatkowe ustalenia szczegółowe
dotyczące zawartości dokumentacji końcowej należy uzgodnić z prowadzącym projekt.
Pomiary czasu wykonania. W każdym projekcie oczekuje się: (1) przeprowadzenia analizy
złożoności zaproponowanego algorytmu oraz (2) wsparcia dla wykonywania eksperymentów z
pomiarami czasu dla różnych (wybranych przez użytkownika) rozmiarów problemu. Wynikiem
analizy jest oszacowanie asymptoty O(T(n)); wsparcie dla eksperymentów pomiarowych polega na
możliwości rejestracji ciągu wartości t(n1), ... t(nk) konkretnych czasów wykonania dla instancji
problemu o rozmiarach n1, ... , nk i generacji zestawienia wyników jak w poniższej tabeli. Jeśli
ocena teoretyczna T(n) jest zgodna z wynikami pomiarów, to potwierdzenie tego powinno być
natychmiast widoczne w tabeli.
2
Tabela wyświetlana na ekranie
Algorytm z asymptotą O(T(n))
n
t(n)[ms]
q(n)
n1
t(n1)
.
n2
t(n2)
.
....
....
.
nmediana
t(nmediana)
1.0
....
....
.
nk-1
t(nk-1)
.
nk
t(nk)
.
Przez q(n) oznaczono (znormalizowany dla nmediana ) współczynnik zgodności oceny teoretycznej z
pomiarem czasu:
q ( n) 
t (n) t (n) T (nmediana )

cT (n) T (n) t (nmediana )
Według takiej tabelki łatwo ocenić, czy ocena teoretyczna jest dobra (w kolumnie q(n) wszystkie
wartości bliskie 1), czy też w ocenie T(n) nastąpiło przeszacowanie (q(n) malejące) bądź
niedoszacowanie (q(n) rosnące). Użytkownik powinien móc wybrać rozmiary problemu, dla
których zostaną przeprowadzone pomiary.
Terminy. Do dnia 9 grudnia 2016 trzeba przygotować koncepcję rozwiązania problemu i przedstawić ją
prowadzącemu projekt do zaakceptowania. Niedotrzymanie terminu może spowodować zmniejszenie liczby
punktów za projekt (do 5p za tydzień opóźnienia). Zakończenie projektu (prezentacja ostatecznej wersji
algorytmu i przekazanie dokumentacji końcowej) powinno nastąpić do dnia 17 stycznia 2017; termin
ostateczny do 26 stycznia przeznaczony jest na ewentualne uzupełnienia / korekty projektu według
wcześniejszego ustalenia z prowadzącym.
Zasady oceniania

Łącznie można uzyskać 30 p., w tym:
 podejście do problemu, analiza złożoności, projekt wstepny (w sumie – ocena p.w.): 10 p.
 poprawność i kompletność implementacji (w tym "styl kodowania"): 10 p.; +3p za przenośność
– tj. wersję Windows
 analiza wyników: 5 p.
 Dokumentacja końcowa : 5 p.
Zasady kontaktowania się i prowadzenia konsultacji:

E-mail: [email protected]; tel. (PW): 222347184; przypominam też o istnieniu ogólnodostępnej listy e-mail: [email protected]

Konsultacje odbywają się zawsze we wtorki w godz 10:05-12:00; pok. 206; w wyjątkowych
przypadkach mogą zostać przełożone na inny dzień, o czym uprzedzę mailowo z wyprzedzeniem.
3

B. proszę w miarę możności stawiać się na konsultacjach w godz 10:05 – 11:00 (bez konieczności
uzgodnienia) lub zasygnalizować chęć przybycia na konsultacje w godz 11:00-12:00 co najmniej
dzień wcześniej mailem.

Na konsultacje zawsze można zgłaszać się z dowolnymi pytaniami dot. realizacji projektu, zarówno
organizacyjnymi jak i merytorycznymi; w przypadku kwestii merytorycznych preferowana jest
wizyta na konsultacjach (a nie e-mail – po prostu bardziej skomplikowane kwestie trudno omawia
się przez pocztę elektroccizną). Sprawy organizacyjne, dot. np. terminów, itp. można konsultować emailem.

Rozdanie zadań nastąpi zdalnie.

Projekt wstępny proszę przekazać w wymaganym terminie (lub wcześniej) w postaci
wydrukowanej na konsultacjach; w momencie przekazania nie jest konieczne (choć oczywiście
wskazane) osobiste stawienie się. Projekt wstępny prosze też wysłać e-mailem na podany wcześniej
adres podając w temacie: "AAL Projekt Wstępny Imię Nazwisko". Przekazanie wydruku jest jednak
obowiązkowe, za datę przekazania projektu uznaję datę przekazania wydruku, a nie wysłania maila!

Po zebraniu wszystkich (lub większości) projektów wstepnych opublikuję punktację oraz
indywidualne uwagi; po tym momencie zachęcam do odwiedzin w czasie konsultacji w celu
omówienia oceny projektu wstępnego.

"Zdanie" projektu końcowego wymaga osobistego pojawienia się na konsultacjach; konieczne jest:
(1) przeprowadzenie pokazu działania programu; (2) przekazanie wydrukowanej dokumentacji
końcowej. Dopiero po wstępnym pozytywnym zaopiniowaniu projektu poproszę indywidualnie o (3)
wysłanie mailem źródeł do weryfikacj (lub poprawki). Dokładne zalecenia dot. sposobu przekazania
źródeł podam osobno. Uwaga: przez "zdaniem" projektu nie należy przekazywać mailem ani w innej
postaci źródeł ani dokumentacji.

Nie jest możliwe zdalne zaliczenie projektu, jedyna dopuszczalna forma jest opisana punkt wyżej.
4