Dokumentacja wstępna
@toDo – Dokumentacja wstępna – Paweł Ptaszyński & Mateusz Paszkowski
@toDo – Dokumentacja wstępna
Autor: Paweł Ptaszyński
Mateusz Paszkowski
Spis treści:
1. Cel projektu
2. Planowana realizacjia
1. Funkcjonalności
1. Cel projektu.a) Zadanie.
b) Dodawanie zadania.
c) Zarządzanie zadaniem.
d) Wyświetlanie listy zadań.
e) Komentowanie zadań.
f) Użytkownicy systemu.
2. Struktury danych i synchronizacja.
a) Applet Web
b) MIDlet.
3. Proponowane klasy.Celem projektu jest stworzenie wstępnej wersji systemu do zarządzania zadaniami o roboczej nazwie @toDo. Na system składać będą się dwie aplikacje. Pierwszą z nich będzie applet do zarządzania zadaniami z poziomu www. Drugą będzie aplikacja na urządzenia mobilne stworzona w technologii J2ME o konfiguracji CLDC (Connected Limited Device Configuration) korzystając z profilu MIDP (Mobile Information Device Profile).Funkcjonalności systemu będą wzorowane na części funkcjonalności systemu MANTIS (http://www.mantisbt.org/).Celem projektu nie jest stworzenie kompletnego systemu tzw. bugtrackingu, bądź elastycznego systemu do zarządzania zadaniami w różnych dziedzinach działalności ludzkiej. Stworzone aplikacje mają być przykładem możliwego rozwiązania, oraz powinny stanowić rozsądną podstawę do dalszego ich rozwijania w celu stworzenia bardziej zaawansowanego i kompleksowego systemu.2. Planowana realizacja.2.1. Funkcjonalności:a) Zadanie.2.2. Struktury danych i synchronizacja.Zadanie istniejące w systemie będzie cechować się następującymi polami: - ID – W postaci numeru. Nadawane automatycznie przez system. - Temat (podsumowanie) – Jednozdaniowe podsumowanie zawierające merritum zdania. - Typ – Typ poruszanego problemu. Proponowana lista typów: Funkcjonalność, Optymalizacja, Bug, Dokumentacja, Kosmetyka. Do rozważenia: możliwość definiowania w systemie typów zadania. - Priorytet. - Data zgłoszenia. - Deadline. - Przypisane do. - Status. Proponowana lista statusów: Przypisane, Nieprzypisane, W toku, Zawieszone, Blokowane, Wykonane. - Blokowane przez – Jeśli wykonanie jakiegoś zadania powinno nastąpić po zakończeniu innego to tworzona jest relacja między nimi. Brak ukończenia zadania blokującego uniemożliwia np. zmianę statusu zadania blokowanego na „W toku”, bądź „Wykonane”. - Blokuje. Lista zadań blokowanych przez aktualne.b) Dodawanie zadania do systemu.- Temat zadania. - Specyfikacja jego rodzaju - Nadanie priorytetu - Opisnie zadania z podanie ew. scenariusza rozwiązania.c) Zarządzanie zadaniem.- Przypisanie zadania do konkretnej osoby. - Zmiana statusu zadania. - Zmiana priorytetu zadania. - Tworzenie realizacji typu blokuje/jest blokowany przez z innymi zadaniami. - Podanie propozycji rozwiązania zadania.d) Wyświetlanie listy zadań.Będzie możliwe wyświetlenie listy zadań znajdujących się w systemie z uwzględnieniem filtrów względem: - typu zadania, - priorytetu, - statusu, - aktualnego ownera, - relacji blkouje/jest blokowany. - data zgłoszenia przed/po, - deadline przed/po.e) Do rozważenia możliwość dodawania komentarzy do istniejących zadań. Funkcjonalność umożliwiająca dyskuję rozwiązania problemu i zespołowe jego znajdywanie. f) Do rozważenia możliwość rejestracji w systemie użytkowników zarządzających i realizujących zadania.a) Applet Web. Rozważane są dwie możliwości. Pierwszą z nich jest skorzystanie z relacyjnej bazy danych SQL (np. MySQL) przy pomocy bibliotek JDBC (pakiety java.sql i javax.sql dostępne w JDK). Drugą jest korzystanie z technologii XML. JDK udostępnia biblioteki JAXP i JAXB ułatwiające obsługę danych w formacie XML. W drugim przypadku rozważenie możliwości oddzielnych plików dla każdego zadania, bądź wielu zadania w jedym pliku. Aplikacja będzie umożliwiała eksport danych poprzez wygenerowanie pliku XML (opcja pierwsza składowania danych), bądź udostępnienie do pobrania plików istniejących w systemie (druga możliwość).b) Aplikacja J2ME. Moduł mobilny będzie korzystał z plików w formacie XML wygenerowanych przez Applet Web (zależnie od wybranej technologii przechowywania danych). Rozważane są dwie koncepcje obsługi danych. Pierwsza z nich – prostsza – polega na konwencji przechowywania plików zadań w określonej lokalizacji w systemie plików urządzenia mobilnego. Druga polega na obsłudze przez aplikację jednego z interfejsów transferu danych dostępnych na urządzeniu i import danych bezpośrednio do aplikacji, która następnie zapisuje je w dogodnym miejscu pamięci urządzenia.
3. Proponowane klasy.
Nie stworzono jeszcze wstępnego projektu klas.
