Celem zadania jest utworzenie oprogramowania symulującego działanie szpitala, w którym rejestracja dokonywana jest zdalnie (niby) przez klientów w szpitalnym serwerze.
Każda studentka i każdy student utworzy program serwera i klienta. Serwer i klient porozumiewać się mają za pomocą samodzielnie opracowanego protokołu. Protokół powinien zostać dopracowany w ciągu 2 tygodni, oraz jego wersja, w postaci pliku .pdf lub .rst powinna zostać przesłana do prowadzącego zajęcia. Istnieje możliwość, że na podstawie opisu protokołu prowadzący napisze klient i serwera - w przypadku niejasności w opisie, prowadzący będzie interpretował je w sposób możliwie złośliwy.
Studenci i studentki podzielone będą na grupy kilkuosobowe, z których każda realizuje ten sam protokół. Dany klient (resp. serwer) musi być w stanie połączyć się z każdym serwerem z danej grupy, oraz - być może - z serwerem (resp. klientem) napisanym przez prowadzącego.
Do wyboru są dwie technologie komunikacji między klientami a serwerami: pamięć współdzielona+semafory (System V,POSIXowe) oraz kolejki komunikatów (System V, POSIXowe).
Kod napisany ma być w czystym C.
Kod musi być udokumentowany: dla każdej funkcji, jej parametry muszą być opisane w komentarzu. Dodatkowo komentarz ma zawierać opis działania funkcji. Zmienne i funkcje powinny posiadać nazwy coś mówiące (tzn. jeżeli funkcja służy do łączenia z serwerem, to powinna się nazywać connect lub podobnie, a nie wesola_funkcja_o_fajnej_nazwie.)
Protokół powinien być opisany w formie pliku napisanego w formacie RST (restructured text) lub .pdf. Jeżeli są potrzebne diagramy, należy użyć ditaa albo aafigure.
Każdy serwer udostępnia polecenia authenticate, register, details, delete, stats, update, list, role, whoami, help, passwd, adduser, deluser, appdate . Szczegóły tych poleceń mogą się różnić w zależności od studenta. Użytkownicy posiadają przypisane trzy role: pacjent, rejestracja, lekarz.
Pacjent ma jedynie dostęp read-only do informacji o sobie. Rejestracja może jedynie dodawać nowych pacjentów oraz dawać informacje o pacjencie, przy czym przed podaniem informacji rejestracja musi podać dodatkowe hasło pacjenta. Lekarz może wszystko oprócz rejestracji nowych pacjentów.
Każde polecenie po stronie serwera wprowadza opóźnienie, symulowane przez sleepa. Ile sekund ma trwać opóźnienie, ma być podawane jako argument przy uruchomieniu serwera.
Każdy serwer udostępnia polecenie help zwracające komendy zawierające dodatkową funkcjonalność serwera. Serwer w reakcji na nieobsługiwaną komendę powinien zwrócić komunikat o błędzie i listę wspieranych poleceń.
Następujące polecenia są dostępne do wyboru do implementacji:
Prezentacja została wykonana w ReStructured Text za pomocą narzędzia landslide. Źródło prezentacji znajduje się tutaj_
Zadanie zaliczeniowe 2015 | 1 |
---|---|
Technologia i wymagania wobec kodu | 2 |
Funkcjonalność serwera | 3 |
Funkcjonalność poleceń (1) | 4 |
Funkcjonalność poleceń (2) | 5 |
Dane o prezentacji | 6 |
Table of Contents | t |
---|---|
Exposé | ESC |
Full screen slides | e |
Presenter View | p |
Source Files | s |
Slide Numbers | n |
Toggle screen blanking | b |
Show/hide slide context | c |
Notes | 2 |
Help | h |