pptaszynski / codetodo

Home | Edit | New

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

 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.

1. Cel projektu.
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.
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.
2.2. Struktury danych i synchronizacja.
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.

Last edited by pptaszynski, Sat Jun 07 11:35:19 -0700 2008
Home | Edit | New
Versions: