ANALIZA PROJEKT ORAZ CZCIOWA IMPLEMENTACJA SYSTEMU BAZODANOWEGO WSPOMAGAJCEGO

ANALIZA, PROJEKT ORAZ CZĘŚCIOWA IMPLEMENTACJA SYSTEMU BAZODANOWEGO WSPOMAGAJĄCEGO PROWADZENIE ZAWODÓW SPEEDCUBINGOWYCH praca dyplomowa studia pierwszego stopnia Anna Prabucka promotor: mgr inż. Jerzy Stankiewicz

PLAN PREZENTACJI ü Cel i zakres pracy ü Projektowanie systemu ü Kostka Rubika ü Projekt aplikacji ü Analiza wymagań systemu ü Interfejs aplikacji ü Użytkownicy ü Testy ü Modelowanie systemu ü Podsumowanie ü Architektura systemu ü Wizja dalszego rozwoju systemu

CEL I ZAKRES PRACY Celem pracy było opracowanie dokumentacji projektowo – użytkowej systemu bazodanowego z wynikami zawodów speedcubingowych (układania kostki Rubika na czas) oraz częściowa implementacja wybranych funkcji. Zakres pracy dyplomowej : § przegląd obecnie stosowanego rozwiązania § analizę potrzeb przyszłych użytkowników § zaprojektowanie i zaimplementowanie bazy danych § zaprojektowanie i stworzenie aplikacji służącej do obsługi bazy danych § wprowadzenie danych słownikowych oraz testowych § testy aplikacji

KOSTKA RUBIKA Ernö Rubik, węgierski architekt, wynalazł „magiczną kostkę” w 1974 roku. Pierwotnym celem tej zabawki logicznej było zrozumienie przestrzeni trójwymiarowej. Wynalazca po raz pierwszy ułożył swoją łamigłówkę po ok. miesiącu. Kostka z czasem zyskiwała na popularności, co zaskutkowało organizacją w 1982 roku pierwszych mistrzostw świata w Budapeszcie. Kilka lat później zainteresowanie kostką spadło, aby w 2003 roku powrócić z kolejnymi mistrzostwami świata, na których zorganizowano 13 konkurencji. Od tamtego czasu liczba imprez speedcubingowych rokrocznie rośnie. W związku z tym rośnie również zapotrzebowanie na narzędzia wspomagające organizację i prowadzenie zawodów.

ANALIZA WYMAGAŃ SYSTEMU Słownik pojęć użytych w pracy: • best – jeden ze sposobów klasyfikowania wyników: liczy się najlepszy / najkrótszy czas ułożenia • delegat – osoba wyznaczona przez WCA będąca głównym rozstrzygającym jeśli chodzi o wyniki i poprawność zawodów w oczach WCA; po każdych zawodach weryfikuje wyniki i pisze raport dla WCA; jego rolą jest czuwanie nad prawidłowym przebiegiem zawodów zgodnym z regulaminem WCA, rozwiewaniem wątpliwości przy sędziowaniu i opieka nad poprawnością przesłanych do WCA wyników • DNF (Did Not Finish) – oznaczenie wykorzystywane w przypadku kiedy ułożenie zostało ukończone przez zawodnika • DNS (Did Not Start) – oznaczenie wykorzystywane w przypadku, kiedy zawodnik nie wystartował w danym ułożeniu • id WCA – identyfikator nadawany przez WCA po pierwszych oficjalnych zawodach danej osoby, jednoznacznie identyfikujący zawodnika; składa się z 10 znaków: 4 cyfr, które są rokiem pierwszych zawodów, 4 początkowych liter nazwiska - bez znaków narodowych oraz 2 cyfr służących do odróżnienia w przypadku, gdyby 8 pierwszych znaków miało być identycznych, np. 2010 PRAB 01

ANALIZA WYMAGAŃ SYSTEMU Słownik pojęć użytych w pracy cd. : • komitet organizacyjny – składa się z minimum 1 organizatora; w skład komitetu powinna wchodzić min. 1 osoba mająca doświadczenie w zawodach WCA jako uczestnik • konkurencja – na zawodach rozgrywanych jest wiele konkurencji, kilka powiązanych z tą samą układanką logiczną, ale będących wariacjami na temat możliwości jej układania (np. układanie kostki 3 x 3 x 3 jedną ręką czy stopami); poza konkurencjami oficjalnymi na zawodach mogą być rozgrywane konkurencje nieoficjalne, wyniki z tych konkurencji nie są brane pod uwagę w rankingu WCA • rejestrator – osoba wprowadzająca wyniki zawodników do aplikacji • runda – w jednej konkurencji może odbyć się kilka rund • sędzia – osoba czuwająca nad poprawnością wykonania ułożenia, świadcząca o wyniku swoim podpisem; może dodawać kary do ułożenia zgodnie z regulaminem WCA

ANALIZA WYMAGAŃ SYSTEMU Słownik pojęć użytych w pracy cd. : • średnia – jeden ze sposobów klasyfikowania wyników; rozróżniane są następujące rodzaje: o average – średnia z 5 ułożeń, z których odrzucany jest najlepszy i najgorszy wynik, a z pozostałych wylicza się średnią arytmetyczną o mean – średnia z 3 ułożeń; wyliczana za pomocą średniej arytmetycznej • ułożenie – jedno z podejść zawodnika w danej rundzie do zmagania się z kostką (synonimicznie solve) • WCA (World Cube Association) – organizacja, która stworzyła ranking wyników uznawanych za oficjalne; tylko wyniki osiągnięte na zawodach, które odbywają się za zgodą WCA są uznawane za rekordy świata, kontynentu czy kraju • wynik – czas potrzebny na ułożenie / ilość ruchów wykorzystanych do ułożenia kostki (w konkurencji FM – fewest moves – układanie jak najmniejszą ilością ruchów) / ilość punktów, na które przekłada się ilość ułożonych kostek - ilość kostek nieułożonych z zadeklarowanych (w konkurencji multiblindfolded – układanie wielu kostek bez patrzenia) • zawodnik – osoba biorąca udział w zawodach i uzyskująca w nich wyniki (zwany również speedcuberem) • zawody – impreza sportowa, podczas której można osiągnąć oficjalne wyniki

ANALIZA WYMAGAŃ SYSTEMU Wymagania funkcjonalne: § Osoba, która pragnie zorganizować zawody speedcubingowe loguje się/tworzy konto organizatora. Aby móc posiadać konto o uprawnieniach organizatora potrzebna jest akceptacja konta przez delegata. § Organizator zgłasza chęć organizacji zawodów poprzez odpowiednie opcje w aplikacji, do czasu akceptacji zawodów przez delegata (z ramienia WCA) możliwa jest jeszcze edycja danych o zawodach, po akceptacji zawody pojawiają się w kalendarzu i organizator może uzupełnić je o listę konkurencji i rund. Na tym etapie modyfikacja informacji o zawodach możliwa jest jedynie przez osobę posiadającą konto delegata. Możliwa jest również opcja usuwania zawodów, która realnie oznacza ustawienie flagi anulowania zawodów. Opcja ta jest dostępna tylko dla organizatora danych zawodów i delegata. § Aby wyniki zawodnika mogły być rejestrowane potrzebne jest uzupełnienie jego danych. Opcję tworzenia nowej encji zawodnika ma każdy rejestrator, organizator i delegat. Modyfikacji danych zawodnika może dokonywać tylko delegat.

ANALIZA WYMAGAŃ SYSTEMU Wymagania funkcjonalne cd. : § Delegat może dodawać organizatorów (tj. akceptować wnioski o utworzenie konta). Do jego uprawnień należy również modyfikowanie danych organizatorów oraz dodawanie i usuwanie organizatorów z zawodów. § Na początku zawodów rejestrator umieszcza (importuje do aplikacji) listę zawodników. Modyfikacji listy (dodawanie i usuwanie zawodników z zawodów) może dokonywać oprócz rejestratora również organizator zawodów. Podczas zawodów sędziowie zapisują czasy osiągnięte przez zawodników w poszczególnych rundach różnych konkurencji. Następnie kartki z wynikami trafiają do rejestratora, który wprowadza rezultaty zmagań zawodników do systemu. Rejestrator ma również możliwość dopisania zawodnika do konkurencji. Zarejestrowane wyniki są dostępne w czasie rzeczywistym dla zawodników do odczytu. § Po zakończeniu zawodów obowiązkiem delegata jest zweryfikowanie zarejestrowanych wyników, akceptacja ich oraz raport do WCA. Niniejszy projekt znacząco ułatwi to zadanie pozwalając na akceptację i ewentualnie poprawienie błędnie wprowadzonych danych oraz generację raportu z wynikami.

ANALIZA WYMAGAŃ SYSTEMU Wymagania pozafunkcjonalne: § system musi działać na systemach z rodziny Windows (Windows 7 i nowsze) § projektowany system powinien być kompatybilny ze wszystkimi wersjami Microsoft SQL Server § system podczas przeglądania wyników ma umożliwić sortowanie obiektów za pomocą dowolnie wybranych kryteriów § menu użytkownika musi być skonfigurowane zgodnie z przydzielonymi uprawnieniami

UŻYTKOWNICY Do użytkowników systemu należą dwa rodzaje osób: § § użytkownicy z uprawnieniami do edycji danych zgodnie z profilem uprawnień: o Rejestrator o Organizator o Delegat użytkownicy mogący tylko odczytywać część danych: o Zawodnik (tudzież Widz) użytkownik opis zawodnik osoba mogąca zobaczyć wprowadzone niekoniecznie biorąca w zawodach udział wyniki; organizator osoba będąca w komitecie organizacyjnym, odpowiedzialna za organizację zawodów rejestrator osoba wprowadzająca wyniki zawodników do systemu delegat osoba akceptująca wyniki, ma możliwość generacji raportu po akceptacji wszystkich wyników na delegowanych przez siebie zawodach; akceptuje organizatorów i zawody

UŻYTKOWNICY dostęp do modułów zawodnik organizator rejestrator delegat x x identyfikacja użytkownika x x x wprowadzanie zawodów x edycja zawodów x x usuwanie zawodów x x tworzenie zawodnika x odczyt wyników x x modyfikacja zawodnika x dodawanie organizatorów x modyfikowanie organizatorów x dodawanie organizatora do zawodów x usuwanie organizatora z zawodów x akceptacja zawodów x dodawanie zawodników do zawodów x x usuwanie zawodników z zawodów x x rejestracja wyników x x akceptacja wyników x raport wyników x

MODELOWANIE SYSTEMU Projektowany system został zamodelowany z użyciem diagramów UML (Unified Modeling Language). Na potrzeby pracy zostały stworzone następujące diagramy: § diagram przypadków użycia – 4 § diagram czynności – 17 § diagram sekwencji – 17 § diagram hierarchii funkcji – 1 § diagram klas – 1

MODELOWANIE SYSTEMU diagram przypadków użycia

MODELOWANIE SYSTEMU diagram czynności

MODELOWANIE SYSTEMU diagram sekwencji

MODELOWANIE SYSTEMU diagram hierarchii funkcji

MODELOWANIE SYSTEMU diagram klas

ARCHITEKTURA SYSTEMU Silnik bazy danych został oparty o SQL Server 2017 firmy Microsoft. Wybór tego narzędzia pozwala korzystać z wielu komponentów (m. in. : usługi raportowania). Dodatkowym atutem przemawiającym za wyborem tej aplikacji jest bezpieczeństwo. Do stworzenia aplikacji wykorzystane zostało środowisko programistyczne firmy Microsoft o nazwie Visual Studio 2017. Narzędzie to posiada wiele możliwości i pozwala tworzyć za pomocą szerokiej gamy języków programowania. Projektowany system został napisany z wykorzystaniem języka C#. Przyczyną wyboru powyższych narzędzi jest ich wspólna kompatybilność, bezpieczeństwo, ciągły rozwój i dodawanie w kolejnych wersjach nowych możliwości.

PROJEKTOWANIE SYSTEMU Baza danych składa się z 13 tabel (12 tabel nazwa tabeli opis PS_users tabela przechowująca informacje o kontach użytkowników systemu zawierających informacje zawodach, nazwa pola typ danych zawodnikach, organizatorach, delegatach u_id (PK) u_login u_haslo int varchar u_rejestrator boolean tak u_organizator boolean tak u_delegat boolean tak ograniczenia kolumna u_login musi być unikalna o i wynikach) oraz 1 tabela techniczna, w której zapisywane są loginy, hasła oraz poziomy uprawnień użytkowników systemu. opis tabeli technicznej PS_users rozmiar wymagane opis 10 15 tak tak identyfikator tabeli login użytkownika hasło użytkownika status poziomu uprawnień – rejestrator (0 – brak uprawnień, 1 – posiadanie uprawnień); wartość defaultowa to "0" status poziomu uprawnień – organizator (0 – brak uprawnień, 1 – posiadanie uprawnień); wartość defaultowa to "0" status poziomu uprawnień – delegat (0 – brak uprawnień, 1 – posiadanie uprawnień); wartość defaultowa to "0"

PROJEKTOWANIE SYSTEMU diagram ERD

PROJEKTOWANIE SYSTEMU diagram bazy danych – model fizyczny

create procedure dodaj_wyniki @id_zawod int, @id_zaw int, @id_konk int, @id_run int, @id_solve int, @wynik int, @info int output, @error varchar(50) output as begin try declare @id_wyn int begin transaction set @id_wyn=(select max(wyn_nr_porz) from wyniki) if exists (select * from wyniki where wyn_id_zawod=@id_zawod and wyn_id_zaw=@id_zaw and wyn_id_konk=@id_konk and wyn_id_run=@id_run) begin if exists (select * from wyn_solve join wyniki on wyn_nr_porz=ws_id_wyn where ws_id_solve=@id_solve and wyn_nr_porz=@id_wyn) begin set @info=1; set @error='UWAGA! Blad - istnieje juz taki wynik. ' end else begin insert into wyn_solve (ws_id_wyn, ws_id_solve, ws_wynik) values (@id_wyn, @id_solve, @wynik) set @info=0; set @error='Wynik dodany. ' end else begin insert into wyniki (wyn_id_zawod, wyn_id_zaw, wyn_id_konk, wyn_id_run) values (@id_zawod, @id_zaw, @id_konk, @id_run) set @id_wyn=(select max(wyn_nr_porz) from wyniki) insert into wyn_solve (ws_id_wyn, ws_id_solve, ws_wynik) values (@id_wyn, @id_solve, @wynik) set @info=0; set @error='Wynik dodany. ' end commit transaction end try begin catch if @@trancount>0 rollback transaction set @info=-1; set @error='Blad!' end catch go PROJEKTOWANIE SYSTEMU procedura dodaj_wyniki

PROJEKT APLIKACJI projekt ekranu logowania ogólny projekt interfejsu aplikacji

PROJEKT APLIKACJI projekt ekranu rejestracji wyników projekt ekranu odczytu wyników ↑ ↓

INTERFEJS APLIKACJI ekran główny aplikacji ekran powitalny aplikacji ↑ ↓

INTERFEJS APLIKACJI ekran odczytu wyników – wybieranie zawodów

INTERFEJS APLIKACJI ekran odczytu wyników po wybraniu parametrów

INTERFEJS APLIKACJI ekran logowania

INTERFEJS APLIKACJI ekran opcji dla rejestratora – zakładka „rejestruj wyniki”

INTERFEJS APLIKACJI ekran opcji dla organizatora – zakładka „dodaj zawody”

INTERFEJS APLIKACJI ekran opcji dla delegata – sekcja ORGANIZATORZY – zakładka „dodaj organizatorów”

INTERFEJS APLIKACJI ekran opcji dla delegata – sekcja ZAWODY – zakładka „edytuj dane o zawodach”

INTERFEJS APLIKACJI ekran opcji dla delegata – sekcja ZAWODNICY – zakładka „dodaj zawodnika”

INTERFEJS APLIKACJI ekran opcji dla delegata – sekcja WYNIKI – zakładka „rejestruj wyniki”

TESTY 1. Część opcji dostępna jest tylko dla zalogowanych użytkowników, więc przetestowano, czy system weryfikuje dane podawane w procesie logowania. 2. W związku z tym, że wyniki z każdej konkurencji rozlicza się zgodnie z rodzajem przypisanej jej średniej sprawdzone zostało wyświetlanie wyników i ich sortowanie zgodnie z analizą. Test polegał na weryfikacji wyników trzech różnych konkurencji dla różnych typów średniej. 3. Moduł rejestracji wyników obsługiwany głównie przez rejestratora zobowiązuje użytkownika do znajomości wymaganych formatów danych, tj. dla wyników oczekiwane wartości to „ 00: 00” lub „-1” dla DNF, lub „-2” dla DNS. ü Pierwszy przypadek testowy dotyczył wprowadzenia danych w błędnym formacie. System informuje użytkownika o tym, w którym polu wprowadzona została niepoprawna wartość. ü Drugi test zweryfikował, czy dane zostały wprowadzone w poprawnym formacie, zgodnie z założeniami oraz czy zostały zapisane w bazie danych.

TESTY test logowanie do systemu Opis działania: użytkownik podaje błędny login Scenariusz: 1. użytkownik uruchamia aplikację 2. wybiera przycisk „Zaloguj” 3. uzupełnia pola „Login” (201 PRAB 01) i „Hasło” (ania) 4. wciska przycisk „OK” Oczekiwane działanie systemu: 1. brak zalogowania 2. wyświetlenie komunikatu informującego o niepoprawnie wprowadzonym loginie 3. akceptacja komunikatu pozwala na ponowne wprowadzenie danych logowania Wynik testu pozytywny test logowania – wprowadzenie błędnego loginu

TESTY test logowanie do systemu Opis działania: użytkownik podaje błędne hasło Scenariusz: 1. użytkownik uruchamia aplikację 2. wybiera przycisk „Zaloguj” 3. uzupełnia pola „Login” i „Hasło” (odpowiednio: 2010 PRAB 01 i aniap) 4. wciska przycisk „OK” Oczekiwane działanie systemu: 1. brak zalogowania 2. wyświetlenie komunikatu informującego o błędnie wprowadzonym haśle do podanego loginu 3. akceptacja komunikatu pozwala na ponowne wprowadzenie danych logowania Wynik testu pozytywny test logowania – podanie błędnego hasła

TESTY test wyświetlanie wyników w zależności od średniej Opis działania: użytkownik wybiera wyniki konkurencji o średniej typu average of 5 Scenariusz: 1. użytkownik uruchamia aplikację 2. wybiera przycisk „wyświetl wyniki” 3. wybiera zawody (Warsaw Cube Masters 2018), konkurencję (3 x 3 x 3) i rundę (1), dla których chce zobaczyć wyniki Oczekiwane działanie systemu: 1. wyświetlenie wyników posortowanych wg średniej wyliczanej zgodnie z analizą 2. pojedynczy wynik DNF / DNS nie powoduje ustalenia średniej jako DNF; taki wynik traktowany jest jako najgorszy ze wszystkich 3. wyniki, dla których więcej niż jeden wynik to DNF lub DNS mają średnią DNF i ustawione są na końcu listy Wynik testu pozytywny test wyświetlania wyników – klasyfikacja wg average of 5

TESTY test wyświetlanie wyników w zależności od średniej Opis działania: użytkownik wybiera wyniki konkurencji o średniej typu mean of 3 Scenariusz: 1. użytkownik uruchamia aplikację 2. wybiera przycisk „wyświetl wyniki” 3. wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7) i rundę (1), dla których chce zobaczyć wyniki Oczekiwane działanie systemu: 1. wyświetlenie wyników posortowanych wg średniej wyliczanej zgodnie z analizą 2. pojedynczy wynik DNF / DNS powoduje ustalenie średniej jako DNF Wynik testu pozytywny test wyświetlania wyników – klasyfikacja wg mean of 3

TESTY test wyświetlanie wyników w zależności od średniej Opis działania: użytkownik wybiera wyniki konkurencji o średniej typu best Scenariusz: 1. użytkownik uruchamia aplikację 2. wybiera przycisk „wyświetl wyniki” 3. wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (3 x 3 x 3 blindfolded) i rundę (1), dla których chce zobaczyć wyniki Oczekiwane działanie systemu: 1. wyświetlenie wyników posortowanych wg najlepszego osiągniętego wyniku 2. uzyskanie wszystkich trzech wyników typu DNF / DNS powoduje ustawienie wyników na końcu listy Wynik testu pozytywny test wyświetlania wyników – klasyfikacja wg best

TESTY test rejestracja wyników Opis działania: użytkownik (rejestrator / delegat) wybiera zawody, konkurencję, rundę i zawodnika Scenariusz: 1. 2. 3. 4. 5. użytkownik uruchamia aplikację loguje się do systemu wybiera przycisk „dla rejestratora” wybiera opcję „rejestruj wyniki” wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7), rundę (1) oraz zawodnika (Brzezinska Karolina), dla którego chce zarejestrować wyniki 6. wybiera przycisk „Dodaj wyniki” Oczekiwane działanie systemu: 1. test rejestracji wyników – wybranie zawodów, konkurencji, rundy i zawodnika 2. odblokowanie tylu pól, ile zgodnie z typem średniej jest przypisane do konkurencji (w przypadku wybranej konkurencji oczekiwano odblokowania 3 pól wyników) odblokowanie przycisków „Anuluj dodawanie” oraz „ Zapisz” Wynik testu pozytywny

TESTY test rejestracja wyników Opis działania: użytkownik (rejestrator / delegat) wprowadza dane niezgodne z dokumentacją Scenariusz: 1. 2. 3. 4. 5. użytkownik uruchamia aplikację loguje się do systemu wybiera przycisk „dla rejestratora” wybiera opcję „rejestruj wyniki” wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7), rundę (1) oraz zawodnika (Brzezinska Karolina), dla którego chce zarejestrować wyniki 6. wybiera przycisk „Dodaj wyniki” 7. wprowadza błędną wartość (tekst) w polu 1 wyniku (kolejno: dnf, 02: 05. 20, 01: 55. 50) Oczekiwane działanie systemu: 1. 2. wyświetlenie komunikatu o polu, w którym zostały wprowadzone błędne dane (1 wpis) brak zapisu danych do bazy Wynik testu pozytywny test rejestracji wyników – wprowadzenie błędnej wartości w pole wyniku

TESTY test rejestracja wyników Opis działania: użytkownik (rejestrator / delegat) wprowadza dane niezgodne z dokumentacją Scenariusz: 1. 2. 3. 4. 5. użytkownik uruchamia aplikację loguje się do systemu wybiera przycisk „dla rejestratora” wybiera opcję „rejestruj wyniki” wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7), rundę (1) oraz zawodnika (Brzezinska Karolina), dla którego chce zarejestrować wyniki 6. wybiera przycisk „Dodaj wyniki” 7. wprowadza błędną wartość (niezgodnie z określonym formatowaniem) w polu 2 wyniku (kolejno wprowadzane wartości: -1, 02: 05. 20, 01: 55. 50) Oczekiwane działanie systemu: 1. test rejestracji wyników – wprowadzenie wartości w błędnym formacie 2. wyświetlenie komunikatu o polu, w którym zostały wprowadzone błędne dane (2 wpis) brak zapisu danych do bazy Wynik testu pozytywny

TESTY test rejestracja wyników Opis działania: użytkownik (rejestrator) wprowadza dane zgodne z dokumentacją Scenariusz: 1. 2. 3. 4. 5. użytkownik uruchamia aplikację loguje się do systemu wybiera przycisk „dla rejestratora” wybiera opcję „rejestruj wyniki” wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7), rundę (1) oraz zawodnika (Brzezinska Karolina), dla którego chce zarejestrować wyniki 6. wybiera przycisk „Dodaj wyniki” 7. wprowadza wartości zgodnie z określonym formatowaniem i ustalonymi miarami (dla DNF / DNS) w polu wyniku (kolejno: -1, 02: 05: 20, 01: 55: 50) Oczekiwane działanie systemu: 1. 2. wyświetlenie komunikatu o poprawnym zarejestrowaniu wyników zapisanie danych do bazy Wynik testu pozytywny test rejestracji wyników – poprawnie zapisane dane

TESTY test rejestracja wyników Opis działania: użytkownik (rejestrator) wyświetla wprowadzone przed chwilą dane Scenariusz: 1. 2. 3. 4. użytkownik uruchamia aplikację loguje się do systemu wybiera opcję „wyświetl wyniki” wybiera zawody (Poznan Fanatic Cube 2018), konkurencję (7 x 7 x 7) oraz rundę (1) dla której przed chwilą dodawał wynik Oczekiwane działanie systemu: 1. 2. test rejestracji wyników – wyświetlenie zapisanych wcześniej wyników wyświetlenie wyników dla wybranych zawodów, konkurencji i rundy wyświetlenie zapisanych wcześniej wyników na liście Wynik testu pozytywny

PODSUMOWANIE • zadanie dyplomowe zostało określone jako stworzenie analizy wymagań, a następnie zaprojektowanie i stworzenie bazy danych, która pozwalałaby wszystkie zebrane dane uporządkować • największym problemem było zebranie wielu funkcji w jednej aplikacji – ze względu na niszowość sportu oraz fakt, że aktualnie istnieje tylko jeden system wspierający częściowo pracę podczas organizacji takich zawodów • dodatkową trudnością jest to, że role pełnione przez zawodników nie są rozgraniczone, tzn. jedna osoba może być jednocześnie organizatorem, delegatem, sędzią, rejestratorem i zawodnikiem na jednych zawodach (!), co było przyczyną zamieszania podczas zbierania informacji do analizy • zrealizowane funkcje - stworzony system spełnia swoją podstawową rolę – pozwala odczytywać wprowadzone dane i wprowadzać wyniki dla przypisanych wcześniej do zawodów zawodników • nie została w pełni zrealizowana funkcja dodawania wyników ze względu na brak możliwości przypisania zawodników do rundy • zgodnie z założeniami pracy pozostałe funkcje systemu nie zostały zaimplementowane • istnieje możliwość rozbudowy aplikacji o informacje np. o sędziach, ale będzie to możliwe dopiero wtedy, kiedy sport ten stanie się bardziej popularny i wprowadzone zostaną zmiany do regulacji takich zawodów

PODSUMOWANIE • największą dumą napawa fakt przygotowania pełnej analizy i zaprojektowania bazy danych – był to etap najbardziej czaso– i pracochłonny • napisanie tej pracy nauczyło mnie, że bez rzetelnej analizy odzwierciadlającej rzeczywistość nie można zaczynać projektowania i programowania bazy danych i aplikacji – jest to nieodłączny etap tworzenia nowych systemów i wprowadzania zmian w już istniejących • pisząc tę pracę jeszcze raz zmieniłabym to, żeby praca była pracą zbiorową – osoby odpowiedzialnej za analizę, projekt i przygotowanie bazy danych oraz osoby odpowiedzialnej za zaprojektowanie i zaprogramowanie aplikacji. W realnym życiu, przy pracy nad prawdziwymi projektami te funkcje są rozdzielone, co pozwala na wykorzystanie indywidualnych umiejętności każdej z zaangażowanych osób

WIZJA DALSZEGO ROZWOJU SYSTEMU W związku z dynamicznym rozwojem speedcubingu jako sportu i jego rosnącą popularnością warto rozważyć możliwości, jakie niesie za sobą technologia i rozwijać systemy i aplikacje ułatwiające prace wykonywane przy okazji organizacji imprez masowych jakimi bez wątpienia są zawody sportowe w układaniu kostki Rubika i innych łamigłówek logicznych. Kilka przykładów na kierunek, w którym można rozwinąć zaprojektowany system: § umożliwienie odczytywania wyników poprzez stronę internetową, a nie tylko poprzez aplikację desktopową § aplikacja mobilna pozwalająca odczytywać wyniki § integracja z aktualnie wstrzymanym projektem opencubeware, dzięki czemu możliwa byłaby rezygnacja z roli rejestratora, ale sędziowie musieliby przejść dodatkowe odpowiednie szkolenie z obsługi systemu (rezygnacja z papierowych kart startowych) § integracja z systemem World Cube Association poprzez import danych historycznych z serwera organizacji poprzez przygotowane API § przygotowanie raportu dla delegata w formie możliwej do bezpośredniego zaimportowania do systemu WCA § umożliwienie eksportu danych wprost do bazy danych stowarzyszenia (WCA)

DZIĘKUJĘ ZA UWAGĘ!