Założenia projektowe Spring. Lotnisko

Witam. Kiedyś chcąc się nauczyć Javy EE pisałem system informatyczny dla przychodni. Teraz chciałbym nauczyć się Springa i wpadłem na pomysł na napisanie systemu informatycznego lotniska. W poprzednim projekcie przychodni miałem 5 poziomów dostępu:
gość - przeglądał informacje i mógł się zarejestrować
lekarz - zarządzał swoimi wizytami oraz pacjentami(dodawał im wpisy w kartę chorobową)
pacjent - zapisywał się na wizytę, anulował wizytę, przeglądał swoją historię choroby
sekretarka - zapisywała pacjenta na wizytę, aktywowała konta pacjentów, zarządzała wizytami lekarzy
admin - dodawał wszystkie typy kont do systemu.

Teraz chciałbym w podobny sposób zaplanować konta dla lotniska, ale mam parę wątpliwości. Wstępne pomysł to:

gość - przegląda stronę, rejestruje się
admin - dodaje linię np: Londyn - Warszawa, zarządza lotami, dodaje wszystkie typy kont do systemu
pasażer - kupuje bilet, przegląda swoje loty
pracownik lotniska - zarządza lotami

I to taka minimalistyczna wersje. Myślałem, żeby rozszerzyć ten system, ale sam nie wiem jak takie systemy wyglądają od środka i czy takie rzeczy się dodaje:

admin - możliwość dodawania samolotów oraz pilotów wtedy przy dodawaniu lotu poza ceną oraz informacją skąd dokąd dodaje się informacje jaki samolot i kto nim leci.
dodanie konta pilota, który jedynie mógłby przegląda jakie loty odbył oraz swoje zaplanowane loty. Bo co więcej mógłby zrobić?
dodanie konta mechanika - dodawałby samoloty do naprawy co byłoby równoznaczne, że samolot znajdujący się w naprawie nie mógłby mieć w tym czasie zaplanowanego lotu.

Temat założyłem z prośbą o poradę jakie funkcjonalności powinien taki system posiadać może ktoś ma jakieś doświadczenie. Czy takie konta pilota oraz mechanika mają sens? Czy dodawanie samolotów oraz pilotów ma sens? Czy nie byłoby to dodawanie na siłę zbędnych informacji do lotu?

Pisałem kiedyś system rezerwacji biletów lotniczych na projekt zespołowy - coś w stylu WizzAir. Założenia były niemal identyczne, całość 95% systemu to panel administracyjny reszta - czyli wyszukiwarka połączeń i rezerwacji to pikuś. System miał możliwości:

Panel administracyjny

• Zarządzanie kontami i rolami systemu
• Dodawanie linii lotniczych
• Dodawanie lotnisk
• Dodawanie załóg zakładałem, że każda załoga potrafi latać na wszystkim, nikt nie choruje itp.
• Dodawanie floty samolotów wraz z ich parametrami technicznymi ważnymi z punktu widzenia zamawiających bilety czyli ilość miejsc w różnych klasach, wielkość załogi, itp.
• Ustalanie rozkładu lotów w skali tygodniowej lub miesięcznej czyli np. można było wybrać, że jeden lot jest w każdy wtorek i czwartek, lub tylko 6, 16, 26 dnia każdego miesiąca
• Podgląd ogólny konkretnych kursów tworzonych przez lazy loading, gdy pierwsza osoba zamówi bilet na dany lot, nie można było robić rezerwacji dalej niż 7 miesięcy (konfigurowalne) gdy zbliżała się data przydzielana zostawała załoga i samolot z posiadanej floty (domyślnie obie informacje były brane z rozkładu) - nie rozdrabniałem się na konkretnych pilotów itp. brakło mi czasu na takie pierdoły.
• Odwoływanie/zawieszanie lotów
• BOK Podgląd szczegółowy rezerwacji w wybranym kursie wraz z informacją czy rezerwacja jest potwierdzona, jak wygląda status płatności.
• BOK Rozwiązywanie konfliktów, gdy ktoś wpłacił już pieniądze a lot nie może odbyć się przez pył wulkaniczny
• System rabatowy, kupony itp.

Gość/Panel użytkownika

• Wyszukiwarka połączeń z uwzględnieniem przesiadek, wolnych miejsc w danej klasie lotniczej, dacie itd. to można "zgapić" z jakiejś strony, która takie rezerwacje prowadzi.
• Możliwość dokonania płatności elektronicznej, wysłanie na e-mail potwierdzenia rezerwacji

Jest masa części ruchomych w takim systemie, lepiej ogranicz sobie założenia do minimum a później dodaj pozostałe funkcjonalności jak np. tych mechaników czy pilotów. Akurat dla mnie taka informacja to nie było takie "must be"

szopenfx napisał(a):

wyszukiwarka połączeń i rezerwacji to pikuś.

Pracowalem kiedyś przy prawdziwym systemie rezerwacji lotów i zaręczam ci że nie jest to taki "pikuś" ;)

Jeśli chodzi o prawdziwe systemy rezerwacji to zwykle posiadają dodatkowo takie możliwości jak bookowanie hoteli czy samochodów oprócz samych lotów.

To był projekt na pół roku w 3 os. grupach, moje pierwsze podejście do ASP.NET MVC 3, wiele rzeczy trzeba było upraszczać do granic i wiadomo, że z takiego systemu nikt w rzeczywistości by nie skorzystał. Przedmiot miał na celu wygenerowanie masy dokumentacji, sam projekt jak powiedział prowadzący nie musiał być nawet ukończony. Inni robili jakieś biblioteki czy coś takiego. Wydawało mi się, że zrobienie wyszukiwarki będzie bardzo trudne ze względu na przesiadki i strefy czasowe, ale jakoś zgrabnie i szybko udało się to zakodować. Większym wyzwaniem było dla mnie robienie rezerwacji i integracja z systemem płatności a największym zaskoczeniem czego na początku nie przewidywałem ta cała otoczka z tworzeniem list lotnisk, floty dostępnych samolotów itp. Jak to jest naprawdę od strony administracyjnej można się tylko domyślać bo akurat ja nie miałem możliwości oglądać takiego systemu od kuchni, całość była raczej grubymi nićmi szyta :P.

@szopenfx dzięki za odpowiedź. Chyba faktycznie zminimalizować lepiej projekt chociaż nie lubię za bardzo potem przerabiać jak jest zbyt wiele zmian. Konto mechanika rzeczywiście wydaje się zbędne. Zwłaszcza, że też przecież nie ma nikt z tego raczej korzystać, tylko jest to robione w celach edukacyjnych, ale też wiadomo musimy mieć taka aplikacja sens. Mam jeszcze pytanie dotyczące załogi. Jak to wyglądało w bazie danych? Miałeś załoga1, załoga2, załoga3 itd? Czy było to bardziej rozbudowane, że do lotu dodawałeś wcześniej dodanego pilota, stewardesse itd? Co do floty to załóżmy miałeś flote składającą się z 5 samolotów typu samolot1. Czy było sprawdzane np, że jeśli było 5 lotów w pewnym przedziale czasowym tego typu samolotem to 6 już nie można było dodać? I ostatnie pytanie jeśli chodzi o integracje z systemem płatności. Zawsze zastanawiałem się jak coś takiego wykonać bo mamy np konto Jan Kowalski i rezerwuje on sobie lot do Londynu w cenie 500 zł. Jak w takim systemie informatycznym dodać taką integrację? Przecież nie przelejemy pieniędzy ani nic z takich rzeczy w takim domowym projekcie.

Jeśli chodzi o te załogi - to była to ostatnia rzecz za którą się wziąłem, zrobiona na odwal się i wyglądała mniej więcej tak jak opisujesz, nie wliczałem pozostałej obsługi samolotu poza pilotami, zazwyczaj taki samolot obsługiwany jest przez 2 do 3 pilotów, ale nie wiem na jakiej zasadzie są dobierani piloci - ja założyłem że zawsze latają takim samym składem i nie można tego składu zmienić, miał być do tego właśnie grafik personelu, w którym przydzielało by się w łatwiejszy sposób loty w rzeczywistym systemie można by było zrobić z tego osobną usługę. Trzeba np. brać pod uwagę to, że muszą mieć odpowiednią ilość czasu na odpoczynek i nie mogą się teleportować na 2 koniec ziemi, żeby lecieć innym samolotem zatem mój sposób ustalania grafiku był lekko mówiąc niewygodny.
Co do wyboru samolotu do danego lotu w rozkładzie był przypisany standardowy typ samolotu na danej trasie np. Boeing 747-400, a przy zbliżającym się terminie bodajże rola "kontroler lotów" przydzielał manualnie dostępne "fizyczne" samoloty z numerem bocznym do konkretnego lotu. Była możliwość wyłączania poszczególnych samolotów z dostępnej floty, ale np. w łatwy sposób nie można było ustalić gdzie dany samolot jest o danej porze (znów znacznie odbiegało to od realizmu), ale było zabezpieczenie, że na 2h przed i po locie jest ten samolot wykluczony z wyboru.
Co do systemu płatności skorzystałem bodajże z Przelewy24, dostałem środowisko do testów takiego sandbox'a, który zachowywał się jak prawdziwy system tylko płaciłeś "fałszywkami". Do całości dostajesz dokumentacje, możesz nawet użyć gotowców - ja miałem problem z PayU chyba był tam SOAP a ja wtedy nie ogarniałem w jaki sposób tego użyć, parsowanie XML'a wydawało mi się trudniejsze, ale możesz poprzeglądać różne API i wybrać to które by odpowiadało tobie.