Różnice między wybraną wersją a wersją aktualną.
Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
sk2:projekt [2021/11/02 20:32] jkonczak [Użyteczność!] |
sk2:projekt [2024/02/02 14:07] (aktualna) jkonczak aktualizacja linku do instytutowego serwera git |
||
---|---|---|---|
Linia 1: | Linia 1: | ||
- | //Uwaga: projekty będę przedstawiać na zajęciach dotyczących programowania. Do tego czasu treść tej strony (i tym samym wymagań) może się nieznacznie zmienić.// | + | ====== SK2 – projekt zaliczeniowy z programowania (2023/2024) ====== |
- | + | ||
- | ====== SK2 – projekt zaliczeniowy z programowania (wersja robocza 2021/2022) ====== | + | |
Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt __ustalony z prowadzącym__. | Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt __ustalony z prowadzącym__. | ||
Linia 7: | Linia 5: | ||
__Przykładowe__ tematy projektów: | __Przykładowe__ tematy projektów: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
- Ciągła synchronizacja katalogów – program który dba o to, by zawartość katalogu u wszystkich klientów była taka sama. Zmiany są wykrywane natychmiastowo. Współbieżne zmiany są wykrywane i właściwie obsłużone. | - Ciągła synchronizacja katalogów – program który dba o to, by zawartość katalogu u wszystkich klientów była taka sama. Zmiany są wykrywane natychmiastowo. Współbieżne zmiany są wykrywane i właściwie obsłużone. | ||
- | - Job scheduler – prosty system kolejkowy: w serwerze rejestrują się węzły obliczeniowe, do serwera klienci wysyłają zadania do wykonania na węzłach (https://en.wikipedia.org/wiki/Job_scheduler). | + | - Job scheduler – prosty system kolejkowy: w serwerze rejestrują się węzły obliczeniowe, do serwera klienci wysyłają zadania do wykonania na węzłach (por. [[https://en.wikipedia.org/wiki/Job_scheduler|job scheduler]], [[https://en.wikipedia.org/wiki/Slurm_Workload_Manager|slurm]]). |
- Reliable UDP multicast – biblioteka / protokół do realizacji niezawodnego przesyłania danych z użyciem UDP multicastu i użycie jej do budowy przykładowego programu (np. wysyłanie pliku). | - Reliable UDP multicast – biblioteka / protokół do realizacji niezawodnego przesyłania danych z użyciem UDP multicastu i użycie jej do budowy przykładowego programu (np. wysyłanie pliku). | ||
- Grupowy edytor grafiki wektorowej – serwer i klient programu, który pozwoli kilku osobom naraz pracować nad grafiką wektorową. Współbieżne operacje na tym samym obiekcie mają być obsłużone w praktyczny sposób. | - Grupowy edytor grafiki wektorowej – serwer i klient programu, który pozwoli kilku osobom naraz pracować nad grafiką wektorową. Współbieżne operacje na tym samym obiekcie mają być obsłużone w praktyczny sposób. | ||
Linia 15: | Linia 14: | ||
- "Zręcznościowa" gra karciana / planszowa w której wiele osób naraz może wykonać ruch – np. dobble, jungle speed. Wymagane GUI. | - "Zręcznościowa" gra karciana / planszowa w której wiele osób naraz może wykonać ruch – np. dobble, jungle speed. Wymagane GUI. | ||
- Quiz / gra państwa-miasta premiująca czas i unikalność odpowiedzi – gra po odpowiedzi od połowy graczy (lub upłynięciu czasu) generuje nowe pytanie. Przy nowym pytaniu serwer na podstawie poprawności, czasu odpowiedzi i odpowiedzi innych graczy przyznaje punkty i pokazuje odpowiedzi. Gracz może dołączyć w dowolnej chwili do gry. Wymagane GUI. | - Quiz / gra państwa-miasta premiująca czas i unikalność odpowiedzi – gra po odpowiedzi od połowy graczy (lub upłynięciu czasu) generuje nowe pytanie. Przy nowym pytaniu serwer na podstawie poprawności, czasu odpowiedzi i odpowiedzi innych graczy przyznaje punkty i pokazuje odpowiedzi. Gracz może dołączyć w dowolnej chwili do gry. Wymagane GUI. | ||
- | - Kahoot – serwer do którego można połączyć się w celu stworzenia quizu (na końcu tworzenia quizu otrzymuje się kod) lub z kodem, w celu wzięcia udziału w quizie. Twórca po przygotowaniu i wystartowaniu quizu widzi na bieżąco jakie odpowiedzi udzielają uczestnicy. Uczestnicy widzą przynajmniej wzajemną punktację. Czas na pytanie kończy się po udzieleniu odpowiedzi przez 2/3 graczy, chyba że wcześniej minie limit czasu na pytanie. Wymagane GUI. | + | - Kahoot – serwer do którego można połączyć się w celu stworzenia quizu (na końcu tworzenia quizu otrzymuje się kod) lub z kodem, w celu wzięcia udziału w quizie. Serwer obsługuje wiele quizów naraz. Twórca po przygotowaniu i wystartowaniu quizu widzi na bieżąco jakie odpowiedzi udzielają uczestnicy. Uczestnicy widzą przynajmniej wzajemną punktację. Czas na pytanie kończy się po udzieleniu odpowiedzi przez 2/3 graczy, chyba że wcześniej minie limit czasu na pytanie. Wymagane GUI. |
- | - Wisielec – gracze odgadują litery kolejnych słów tego samego hasła – kto pierwszy ten lepszy, ale każdy gracz ma własnego wisielca. Gracze widzą swoje wisielce nawzajem. Za odgadniętą literę gracz dostaje punkt. Gra kończy się gdy zostanie jeden aktywny gracz. Wymagane GUI. | + | - Wisielec – gracze wspólnie odgadują litery tego samego hasła – kto pierwszy ten lepszy, ale każdy gracz ma własnego wisielca. Gracze widzą swoje wisielce nawzajem. Za odgadniętą literę gracz dostaje punkt. Gra kończy się gdy zostanie jeden aktywny gracz. Wymagane GUI. |
- | - Układanie słów – serwer co rundę losuje określoną ilość liter i przesyła je graczom. Gracze wysyłają do serwera słowa z podanych liter. Gracz który podał jako pierwszy dające się ułożyć słowo dostaje punkty. Za słowo które nie daje sie ułożyć z liter gracz traci punkty. Po określonym czasie serwer rozpoczyna następną rundę. Gracze widzą na bieżąco ranking z ilością punktów i wszystkie ułożone słowa z poprzedniej rundy. Wymagane GUI. | + | - Układanie słów – serwer co rundę losuje określoną ilość liter i przesyła je graczom. Gracze wysyłają do serwera słowa z podanych liter. Gracz który podał jako pierwszy dające się ułożyć słowo dostaje punkty. Za słowo które nie daje się ułożyć z liter gracz traci punkty. Po określonym czasie serwer rozpoczyna następną rundę. Gracze widzą na bieżąco ranking z ilością punktów i wszystkie ułożone słowa z poprzedniej rundy. Wymagane GUI. |
- | - Publish–subscribe message queue – message broker (serwer), współdzielona biblioteka klienta i demonstracyjny program używający tej biblioteki. Klient może tworzyć kolejki, wysyłać do nich wiadomości i zapisywać się do odbioru wiadomości z kolejki. Kolejki wspierają wielu konsumentów, wiadomości mają określony czas ważności (https://en.wikipedia.org/wiki/Message_queue). | + | - Publish–subscribe message queue – message broker (serwer), współdzielona biblioteka klienta i demonstracyjny program używający tej biblioteki. Klient może tworzyć kolejki, wysyłać do nich wiadomości i zapisywać się do odbioru wiadomości z kolejki. Kolejki wspierają wielu konsumentów, wiadomości mają określony czas ważności (por. [[https://en.wikipedia.org/wiki/Message_queue|message queue]]). |
- | - HTTP caching proxy – proxy serwujące najczęściej pobierane strony z własnej pamięci (przykład programu – squid). Proxy ma redukować ruch (obsługa etag, if-modified-since, współbieżne żądania o tą samą stronę generują jedno zapytanie). | + | - HTTP caching proxy – proxy serwujące najczęściej pobierane strony z własnej pamięci (przykład programu – [[http://www.squid-cache.org/|squid]]). Proxy ma redukować ruch (obsługa etag, if-modified-since, współbieżne żądania o tą samą stronę generują jedno zapytanie). |
- Radio internetowe – serwer ma kolejkę plików dźwiękowych, które kolejno strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki. Wymagane GUI. | - Radio internetowe – serwer ma kolejkę plików dźwiękowych, które kolejno strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki. Wymagane GUI. | ||
- Inny projekt, uzgodniony z prowadzącym. | - Inny projekt, uzgodniony z prowadzącym. | ||
Linia 30: | Linia 29: | ||
* http://www.cs.put.poznan.pl/mboron/prez/zasady_projektow.pdf | * http://www.cs.put.poznan.pl/mboron/prez/zasady_projektow.pdf | ||
| | ||
- | Warunki które musi spełniać temat projektu: | ||
- | - interakcja klientów ze sobą: projektu nie da się zrealizować tworząc izolowany wątek / proces dla każdego klienta, | ||
- | - konieczność obsłużenia wielu klientów naraz: serwer przez większość czasu może otrzymać wiadomość od więcej niż jednego klienta i kolejność (lub czas) otrzymania wiadomości ma znaczenie, | ||
- | - konieczność rozwiązania konfliktów: w trakcie działania mogą pojawiać się sytuacje, gdzie poprawna wiadomość od klienta jest niepoprawna / niespójna / sprzeczna dla serwera. | ||
- | <html><small></html> | ||
- | Nieakceptowalne tematy projektów ze względu na temat nie ma wymaganej złożoności sieciowej: | + | **Warunki które musi spełniać temat projektu:** |
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
+ | - **interakcja klientów ze sobą: projektu nie da się zrealizować tworząc izolowany wątek / proces dla każdego klienta,** | ||
+ | - **konieczność obsłużenia wielu klientów naraz: serwer przez większość czasu może otrzymać wiadomość od więcej niż jednego klienta i kolejność (lub czas) otrzymania wiadomości ma znaczenie,** | ||
+ | - **konieczność rozwiązania konfliktów: w trakcie działania mogą pojawiać się sytuacje, gdzie poprawna wiadomość od klienta jest niepoprawna / niespójna / sprzeczna dla serwera.** | ||
+ | |||
+ | <small> | ||
+ | Nieakceptowalne tematy projektów ze względu na temat nie mający wymaganej złożoności sieciowej: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* Prosty komunikator internetowy. | * Prosty komunikator internetowy. | ||
* Prosty czat internetowy. | * Prosty czat internetowy. | ||
* Gra w której kolejność ruchów graczy jest z góry znana, a opuszczenie gry przez gracza jest równoznaczne z końcem rozgrywki. | * Gra w której kolejność ruchów graczy jest z góry znana, a opuszczenie gry przez gracza jest równoznaczne z końcem rozgrywki. | ||
- | * Kółko i krzyżyk | + | * Kółko i krzyżyk. |
- | * Zwykły pong | + | * Zwykły pong. |
+ | </small> | ||
- | <html></small></html> | ||
===== Użyteczność! ===== | ===== Użyteczność! ===== | ||
- | W związku z powtarzającymi się co roku pytaniami: proponowane programy mają posiadać cechę zwaną po polsku [[https://pl.wikipedia.org/wiki/U%C5%BCyteczno%C5%9B%C4%87_(informatyka)|użytecznością (ang: useability)]].\\ | + | W związku z powtarzającymi się co roku pytaniami: proponowane programy mają posiadać cechę zwaną po polsku [[https://pl.wikipedia.org/wiki/U%C5%BCyteczno%C5%9B%C4%87_(informatyka)|użytecznością]] (ang: [[https://en.wikipedia.org/wiki/Usability|useability]]).\\ |
Podsumowując: program ma wygodnie działać w normalnych (a nie tylko laboratoryjnych) warunkach. W szczególności: | Podsumowując: program ma wygodnie działać w normalnych (a nie tylko laboratoryjnych) warunkach. W szczególności: | ||
- | * **ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji connect (firewall), zerwanie połączenia, etc.,** | + | <html><div style="margin: -1.2em 0 0 0"/></html> |
+ | * **ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji ''connect'' (firewall), zerwanie połączenia, etc.,** | ||
* **ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. nie udzielać odpowiedzi w quizie / kahoocie),** | * **ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. nie udzielać odpowiedzi w quizie / kahoocie),** | ||
* jeśli program ma parametry konfiguracyjne, to powinny być konfigurowalne a nie ustawione na sztywno w kodzie; proszę się też zastanowić co użytkownik może chcieć ustawić (i pozwolić mu na to), | * jeśli program ma parametry konfiguracyjne, to powinny być konfigurowalne a nie ustawione na sztywno w kodzie; proszę się też zastanowić co użytkownik może chcieć ustawić (i pozwolić mu na to), | ||
Linia 58: | Linia 61: | ||
===== Ogólne zasady i uwagi ===== | ===== Ogólne zasady i uwagi ===== | ||
- | * Projekty są pisane w 2 osoby, chyba że uzgodniono inaczej z prowadzącym | + | * Projekty są pisane w 2 osoby, chyba że uzgodniono inaczej z prowadzącym. |
- | * **Uzgodnieniu projektu = mail do mnie z opisem projektu + moja odpowiedź OK** | + | * **Uzgodnieniu projektu = mail do mnie z opisem projektu + moja odpowiedź OK.** |
- | * Opis projektu najlepiej zrobić w postaci krótkiego przypadku użycia (use case [[https://pl.wikipedia.org/wiki/Przypadek_użycia|[1]]]) z zaznaczoną rolą serwera i klienta \\ Opis projektu można też wykonać w sposób podobny jak na stronie z propozycjami projektów Konrada Sieka [[http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html|[2]]] \\ [[projekt_przykladowy_opis|Przykład opisu projektu]] | + | * Opis projektu najlepiej zrobić w postaci krótkiego przypadku użycia (use case [[https://pl.wikipedia.org/wiki/Przypadek_użycia|[1]]]) z zaznaczoną rolą serwera i klienta. \\ Opis projektu można też wykonać w sposób podobny jak na stronie z propozycjami projektów Konrada Sieka [[http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html|[2]]]. \\ **[[projekt_przykladowy_opis|Przykład opisu projektu]].** |
- | * **W każdym projekcie serwer ma być pisany w C/C++ z użyciem BSD socket API do obsługi sieci** | + | * **W każdym projekcie serwer ma być pisany w C/C++ z użyciem BSD socket API do obsługi sieci.** |
- | * Programy mają się kompilować bez ostrzeżeń (dla kodu w C/C++ z flagami kompilatora ''-Wall -Wextra'') | + | * <small> Klient może być pisany w dowolnym języku, serwer (poza obsługą sieci) może korzystać z dowolnych bibliotek, ale: działający projekt musi być zaprezentowany w laboratorium, instalację egzotycznych bibliotek i kompilatorów na komputerach laboratoryjnych przeprowadzacie we własnym zakresie.</small> |
- | * Kod zadań ma się pojawiać na repozytorium GIT: https://gitlab.cs.put.poznan.pl/ [lub innym dostępnym dla prowadzącego] | + | * Programy mają się kompilować bez ostrzeżeń (dla kodu w C/C++ z flagami kompilatora ''-Wall -Wextra''). |
- | * Kod będzie testowany analizatorami statycznymi (np. splint, cppcheck, [[https://clang-analyzer.llvm.org/scan-build.html|clang]]), wykonanie – dynamicznymi (np. valgrind) | + | * Kod ma się pojawiać na repozytorium GIT: https://git.cs.put.poznan.pl/ [lub innym dostępnym dla prowadzącego]. |
- | * Projekt musi dać się łatwo zbudować – konieczne są pliki systemu budowania [[https://en.wikipedia.org/wiki/Build_automation|[1]]] [[https://en.wikipedia.org/wiki/List_of_build_automation_software|[2]]] | + | * Kod będzie testowany analizatorami statycznymi (np. cppcheck, [[https://clang-analyzer.llvm.org/scan-build.html|clang]]), wykonanie – dynamicznymi (np. valgrind). |
+ | * **Projekt musi dać się łatwo zbudować – konieczne są pliki systemu budowania** [[https://en.wikipedia.org/wiki/Build_automation|[1]]] [[https://en.wikipedia.org/wiki/List_of_build_automation_software|[2]]]. | ||
* Komunikacja klient-serwer ma odbywać się z wykorzystaniem protokołu TCP, chyba że temat projektu stanowi inaczej lub uzgodniono z prowadzącym użycie innych protokołów. | * Komunikacja klient-serwer ma odbywać się z wykorzystaniem protokołu TCP, chyba że temat projektu stanowi inaczej lub uzgodniono z prowadzącym użycie innych protokołów. | ||
* Liczba klientów nie może być sztucznie ograniczona. Jeśli np. liczba graczy jest ograniczona przez zasady gry, to należy umożliwić wiele gier na serwerze. (Po uzgodnieniu z prowadzącym można uchylić to wymaganie, np. dla gier czasu rzeczywistego). | * Liczba klientów nie może być sztucznie ograniczona. Jeśli np. liczba graczy jest ograniczona przez zasady gry, to należy umożliwić wiele gier na serwerze. (Po uzgodnieniu z prowadzącym można uchylić to wymaganie, np. dla gier czasu rzeczywistego). | ||
Linia 74: | Linia 78: | ||
Projekt jest wstępnie oceniany na: | Projekt jest wstępnie oceniany na: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* 5.0 jeśli stworzone programy działają poprawnie w każdych warunkach sieciowych i realizują wszystkie aspekty zawarte w opisie projektu | * 5.0 jeśli stworzone programy działają poprawnie w każdych warunkach sieciowych i realizują wszystkie aspekty zawarte w opisie projektu | ||
* 4.0 jeśli stworzone programy działają poprawnie przynajmniej w typowej sieci lokalnej i realizują wszystkie aspekty zawarte w opisie projektu | * 4.0 jeśli stworzone programy działają poprawnie przynajmniej w typowej sieci lokalnej i realizują wszystkie aspekty zawarte w opisie projektu | ||
* 3.0 jeśli pojawiają się błędy w działaniu programów lub nie zostały zrealizowane fragmenty opisu projektu | * 3.0 jeśli pojawiają się błędy w działaniu programów lub nie zostały zrealizowane fragmenty opisu projektu | ||
Następnie ocena jest zwiększana / zmniejszana w zależności od: | Następnie ocena jest zwiększana / zmniejszana w zależności od: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* przyjętych rozwiązań aspektów sieciowych | * przyjętych rozwiązań aspektów sieciowych | ||
* jakości kodu | * jakości kodu | ||
Linia 83: | Linia 89: | ||
* braku spełnienia zasad opisanych na tej stronie (np. terminy, brak plików systemu budowania, brak repozytorium etc.) | * braku spełnienia zasad opisanych na tej stronie (np. terminy, brak plików systemu budowania, brak repozytorium etc.) | ||
Często powtarzające się błędy które prawie zawsze skutkują obniżeniem oceny: | Często powtarzające się błędy które prawie zawsze skutkują obniżeniem oceny: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* aktywne czekanie (nieważne czy dla synchronizacji wątków, czy do obsługi sieci) | * aktywne czekanie (nieważne czy dla synchronizacji wątków, czy do obsługi sieci) | ||
* wysyłanie nadmiarowych danych przez sieć | * wysyłanie nadmiarowych danych przez sieć | ||
- | | ||
- | Brak zgłoszonego tematu projektu w terminie obniża ocenę o 0.5. | ||
| | ||
===== Terminy ===== | ===== Terminy ===== | ||
- | * **Tematy projektów należy uzgodnić nie później niż do 19.12.2021.** Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. | + | * **Tematy projektów należy uzgodnić nie później niż do 24.11.2023.** \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. |
- | * O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu projekt musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego. | + | * O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu opis projektu musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego. |
- | * Prowadzący musi zostać poinformowany o skończeniu projektu nie mniej niż 3 dni przed oddaniem projektu. | + | * **Mail z informacją o skończeniu projektu należy wysłać najpóźniej 12.01.2024**. \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. |
- | * Oddanie projektów możliwe jest na ostatnich (lub przedostatnich, jeśli jest czas) zajęciach lub po mailowym uzgodnieniu z prowadzącym. <html><!-- --></html> | + | * **Działający projekt należy zaprezentować w laboratorium przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 31.01.2024)**. |
- | * **Projekt należy oddać przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 28.01.2022)**. | + | * Wysłanie maila z informacją o skończeniu projektu a zaprezentowanie projektu w laboratorium muszą dzielić przynajmniej 2 dni (na przejrzenie kodu przez prowadzącego). |
+ | * Zaprezentowanie projektu w laboratorium projektów możliwe jest na/po zajęciach lub po mailowym uzgodnieniu z prowadzącym. | ||
* Do zaliczenia przedmiotu konieczna jest pozytywna ocena z projektu. | * Do zaliczenia przedmiotu konieczna jest pozytywna ocena z projektu. | ||