Spis treści

Projekt konceptualny

1. Sformułowanie zadania projektowego: podanie przedmiotu projektowania, jego celów, przeglądu zadań, specyfiki i uwarunkowań.

Rss Manager służyć będzie do zaawansowanego zarządzania kanałami RSS z jednej lub wielu stron WWW. Czasami zdarzają się sytuacje, w których użytkownik czeka na pojawienie się konkretnej zawartości na określonej stronie internetowej. Wymaga to ciągłego sprawdzania zawartości strony (lub w przypadku podstawowej obsługi RSSa, każdorazowego przeszukiwania jego najnowszej treści). Zadaniem aplikacji będzie zwolnienie użytkownika z takiej potrzeby poprzez powiadamianie go o pojawieniu się szukanej treści na danej stronie (np. w przypadku, w którym dany wpis zawiera określone wcześniej słowo kluczowe). Planowaną funkcjonalnością programu jest także sprawdzanie czy określona strona zmieniła swoją zawartość.

Przykład I
Marek – fan produktów firmy Apple, interesuje się wszelkimi nowinkami dotyczącymi iPhonów. Uruchamia więc aplikację Rss Manager i ustawia w niej słowo kluczowe „iPhone”. Następnie dodaje do bazy kanałów RSS kilka ze swoich ulubionych blogów. Gdy tylko na którymkolwiek z nich pojawi się wpis zawierający słowo „iPhone”, Marek zostanie o tym powiadomiony bezpośrednio na komputerze, przez mail lub przez sms. W bardziej zaawansowanej wersji programu Marek może w wolnym czasie przeglądać na swoim mailu dzienne raporty zawierające wszystkie wpisy dotyczące iPhonów z podanych blogów.

Przykład II
Maciej, student Informatyki Stosowanej na AGH z niecierpliwością czeka na wyniki egzaminu z Matematyki Dyskretnej. Zamiast co kilka minut odświeżać zawartość strony swojego profesowa, ustawia aplikaję Rss Manager na tą stronę i zaznacza powiadomienie sms. Teraz może spokojnie iść z kolegami napić się soku marchewkowego, a gdy na stronie profesora pojawi się nowa zawartość, Maciej zostanie powiadomiony smsem.

Istnieją różne możliwości zarobku na projekcie:

  • wprowadzenie reklam dołączanych do stopki wiadomości email i sms
  • wprowadzenie płatnej wersji programu (rozszerzone możliwości lub po prostu brak reklam)
  • pewne (bardzo niskie) opłaty za powiadomienia sms (najlepiej w przypadku wdrożenia własnej bramki)

2. Analiza stanu wyjściowego; analiza stanu zastanego, uwarunkowań prawnych, przyjętego obiegu istniejącej dokumentacji, analiza istniejącego systemu elektronicznego przetwarzania danych (aktualnej bazy), analiza występujących problemów, etc. pomocne mogą być scenariusze postępowania i ich analiza (elementy, obiekty, charakterystyki, atrybuty, struktura, przepływ danych, powiązania, relacje, ograniczenia funkcjonalności).

Na chwilę obecną konkurencja nie jest zbyt wielka. Istnieje kilka programów, jednak nie są tak rozpromowane że każdy o nich słyszał, pomimo tego że z RSS każdy ma jakiś pośrednią bądź bezpośrednią styczność. Jest kilka rozszerzeń które pomagają przeglądanie takich kanałów, jednak nie spotkałem się z takim który oferowałby podobne rozwiązania jak nasze. Dodatkowym atutem tego typu aplikacji jest fakt że każdy może z niego korzystać, dlatego też będziemy starać się aby aplikacja była jak najbardziej przyjazna użytkownikowi (user friendly). Na rynku znajduje się kilka czytników RSS, takich jak:

Google Reader – który umożliwia subskrypcje wybranych kanałów RSS, dostarcza także kilka możliwości sortować i udogodnień, jednak funkcje które nasz program będzie oferował nie są dostępne, bądź też trudne w odszukaniu. Jest to darmowe rozwiązanie.

Microsoft Outlook – jest to potężne narzędzie, i jak się okazuje można w nim skonfigurować RSS. Posiada takie funkcje jak: dodawanie źródeł, wyświetlanie najnowszych wiadomości, regularnie sprawdza kanały RSS i kilka dodatkowych. Wadą tego rozwiązania jest jego koszt, gdyż jest to program komercyjny.

FeedDemon – jeden z najbardziej zaawansowanych programów, posiada poza standardowymi funkcjami związanymi z RSS takie właściwości jak: wyszukiwarkę wiadomości, filtrowanie i sortowanie wiadomości. Oprogramowanie to jest na licencji Adare, czyli jest darmowe, jednak zarabia na reklamach.

3. Analiza wymagań użytkownika (wstępna); na tym etapie należy określić podstawowe cele, zadania i funkcjonalność jakie mają być realizowane przez projektowaną bazę danych oraz ew. wymagania dotyczące projektu i dokumentacji. Dobrze byłoby, aby użytkownik na bieżąco współuczestniczył w projektowaniu i implementacji oraz wnosił swoje uwagi. Należy zidentyfikować wymagania jawne i niejawne.

Funkcjonalność produktu:

Ponieważ podstawowym celem aplikacji jest oszczędzenie czasu użytkownika, głównym celem w funkcjonalności będą: prosty w obsłudze interfejs oraz przejrzyste raporty zawierające wyniki przeszukiwań danych kanałów RSS.

Główny interfejs powinien zawierać:

  • Bazę dodanych kanałów RSS, możliwość usuwania ich z listy, oraz dodawania nowych
  • Bazę poszukiwanych słów kluczowych, również w postaci listy

Cechy raportowania:

  • Możliwość ustawienia częstotliwości otrzymanych raportów. Użytkownik może otrzymywać następujące raporty:
    1. Dzienny, zawierający podsumowanie, ile RSSów zawierających słowo kluczowe pojawiło się na stronie
    2. Godzinny
    3. Natychmiastowy, gdy tylko pojawi się wpis dotyczący danego tematu, użytkownik jest powiadamiany.
  • Możliwość ustawienia rodzaju powiadomień. Użytkownik może chcieć otrzymywać szczegółowy raport mailowy, lub wiadomość sms o pojawieniu się nowej zawartości ze słowem kluczowym.

Analiza MoSCoW:

Must:

  1. Pobieranie nowych RSSów dla podanych przez użytkownika stron
  2. Przeszukiwanie nowych RSSów pod kątem zawartości, kiedy zawierają dane słowo kluczowe.
  3. Zapisywanie zaakceptowanych RSSów w bazie danych
  4. Powiadomienie użytkownika o nowych wiadomościach w bazie
  5. Tworzenie raportu dotyczącego nowej zawartości bazy

Should:

  1. Wybieranie rodzaju i częstotliwości raportowania
  2. Wybór rodzaju powiadomień (poprzez mail/sms)
  3. Powiadamianie o zmianie zawartości danej strony

Could:

  1. Znalezienie darmowego sposobu na powiadomienia sms
  2. Wysłanie powiadomień sms wykorzystując kalendarz google (posiada możliwość darmowego powiadamiania)
  3. Sprzątanie bazy ze starych wpisów

Won't:

  1. Własna bramka wysyłająca smsy z powiadomieniami (mogłaby być korzystna w przypadku dużego zainteresowania aplikacją)
  2. Zabezpieczenia przed celowym przeciążeniem programu nadmierną ilością przetwarzanych wpisów

Zadania, moduły do wykonania:

Do realizacji projektu należy wykonać następujące zadania:

  1. Zaprojektowanie bazy danych (Jakub Kozik)
  2. Konfiguracja serwera bazy danych (Jakub Kozik)
  3. Moduł pobierania RSSów (Jakub Kozik)
  4. Moduł obsługi bazy danych (Jakub Kozik)
  5. Moduł powiadamiania użytkownika (Dariusz Gruca)
  6. Moduł tworzenia raportów (Dariusz Gruca)
  7. Zaprojektowanie i wykonanie GUI (Dariusz Gruca)
  8. Dokumentacja projektu (Dariusz Gruca i Jakub Kozik)

4. Określenie scenariuszy użycia. Scenariusze użycia pozwolą na konstrukcję diagramów DFD i STD oraz hierarchii funkcji.

Scenariusze dla użytkownika:

Scenariusz I

  1. Użytkownik uruchamia program.
  2. Użytkownik tworzy nową bazę przeszukiwań.
    • Wpisuje nazwę bazy
    • Dodaje 1 kanał RSS
    • Dodaje 1 słowo kluczowe
  3. Użytkownik ustawia powiadamianie cykliczne na mail co 1 godzinę.
  4. Użytkownik minimalizuje program do traya.

Scenariusz II

  1. Użytkownik uruchamia program.
  2. Użytkownik tworzy nową bazę przeszukiwań.
    • Wpisuje nazwę
    • Dodaje 1 kanał RSS
    • Dodaje 1 słowo kluczowe
  3. Użytkownik ustawia powiadamianie smsem, gdy tylko pojawi się jakiś wyszukiwany RSS.
  4. Użytkownik minimalizuje program do traya.

Scenariusz III

  1. Użytkownik uruchamia program.
  2. Użytkownik modyfikuje istniejącą bazę przeszukiwań.
    • Dodaje 2 nowe kanały RSS
    • Dodaje 1 słowo kluczowe
  3. Użytkownik minimalizuje program do traya.

5. Identyfikacja funkcji. Określenie podstawowych funkcji realizowanych w bazie danych.

  • Dodanie/usunięcie nowej bazy przeszukiwań.
  • Odświeżanie bazy przeszukiwań.
  • Dodanie/usunięcie/modyfikowanie kanałów RSS w bazie przeszukiwań.
  • Dodanie/usunięcie/modyfikowanie słów kluczowych w bazie przeszukiwań.
  • Ustawienie sposobu raportowania o nowych wpisach (mail/sms).
  • Ustawienie częstotliwości raportowania o nowych wpisach (natychmiast/cyklicznie).

6. Analiza hierarchii funkcji projektowanej aplikacji (FHD – Function Hierarchy Diagram); określenie struktury zależności hierarchicznych pomiędzy jednostkami analizowanego systemu, zwłaszcza w zakresie specyfikacji wymagań funkcjonalnych. Specyfikacja funkcji (funkcjonalności) projektowanego systemu.

Diagram FHD

7. Budowa i analiza diagramu przepływu danych (DFD – Data Flow Diagram); ma na celu określenie przepływu danych (wejścia, wyjścia, operacje, przechowywanie) oraz elementów sterowania tym przepływem, co może być pomocne dla tworzenia aplikacji. Specyfikacja danych wejściowych i wyjściowych.

Diagram kontekstowy

Diagram główny

1. Obsługa baz przeszukiwań

1.5 Konfiguracja bazy

2. Obsługa systemu powiadomień

2.1 Odświeżanie baz danych

2.2 Raportowanie

8. Wybór encji (obiektów) i ich atrybutów.

BAZA_POWIADOMIEŃ

  • nazwa (VARCHAR)
  • data utworzenia (TIMESTAMP)
  • rodzaj powiadamiania (VARCHAR)
  • częstotliwość (INTEGER)


KANAŁ_RSS

  • url (VARCHAR)
  • baza_powiadomień (FK, BAZA_POWIADOMIEŃ)


SŁOWO_KLUCZOWE

  • słowo (VARCHAR)
  • baza_powiadomień (FK, BAZA_POWIADOMIEŃ)


WIADOMOŚĆ

  • tytuł (VARCHAR)
  • treść (TEXT)
  • data utworzenia (TIMESTAMP)
  • raportowana (BOOLEAN)
  • baza_powiadomień (FK, BAZA_POWIADOMIEŃ)

9. Projektowanie powiązań (relacji) pomiędzy encjami. Konstrukcja diagramu ERD (Entity-Relationship Diagram); jest to zasadniczy etap procesu projektowania struktury bazy danych. Identyfikacja klas encji, ich atrybutów, zdefiniowanie (określenie) kluczy. Tablica krzyżowa powiązań, eliminacja powiązań wiele-do-wielu. Konstrukcja diagramu ERD.

Projektowanie powiązań (relacji) pomiędzy encjami

Kod SQL (SQLite) bazy danych

BEGIN;
 
CREATE TABLE IF NOT EXISTS bases (   
    base_name VARCHAR(30) PRIMARY KEY,              
    base_type INTEGER NOT NULL, 
    created DATE NOT NULL,              
    notify_type VARCHAR(6) NOT NULL,   
    frequency INTEGER NOT NULL              
);
 
CREATE TABLE IF NOT EXISTS channels (          
    channelid SERIAL PRIMARY KEY,                      
    uri VARCHAR(200) NOT NULL,                  
    title VARCHAR(100),                         
    last_modified DATE,                         
    base_name VARCHAR(30) NOT NULL REFERENCES bases         
);
 
CREATE TABLE IF NOT EXISTS keywords (     
    keywordid SERIAL PRIMARY KEY,                      
    word VARCHAR(100) NOT NULL,                
    base_name VARCHAR(30) NOT NULL REFERENCES bases         
);
 
CREATE TABLE IF NOT EXISTS entries (          
    entryid SERIAL PRIMARY KEY,                  
    title VARCHAR(40) NOT NULL,             
    uri VARCHAR(200) NOT NULL,              
    description TEXT NOT NULL,                    
    created DATE,                   
    reported INTEGER NOT NULL,           
    channelid INTEGER NOT NULL REFERENCES channel            
);
 
COMMIT;

10. Projekt diagramów STD (State Transition Diagram – diagramy przejśćpomiędzy stanami). Wykonanie w oparciu o scenariusze użycia i strukturę bazy danych. Pomocny do budowy interfejsu aplikacji.

Diagram STD

pl/dydaktyka/ztb/2012/projekty/rss/konceptualny.txt · ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0