Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:dydaktyka:ztb:2012:projekty:rss:start [2012/07/03 22:11] ztb2012 |
pl:dydaktyka:ztb:2012:projekty:rss:start [2019/06/27 15:50] (aktualna) |
- [[pl:dydaktyka:ztb:2012:projekty:past_explorer:konceptualny|Projekt konceptualny]] | ====== RSS Hunter ====== |
- [[pl:dydaktyka:ztb:2012:projekty:past_explorer:logiczny|Projekt logiczny]] | Program RssHunter służy do „polowania” na konkretne informacje w kanałach RSS. Użytkownik nie musi dzięki temu tracić czasu na przeszukiwanie wszystkich nowych informacji, jakie się pojawiają. Nie musi też martwić się o odświeżanie kanału w poszukiwaniu nowych wpisów. Jedyne, co robi to tworzy bazę poszukiwań, do której dodaje kanały RSS oraz słowa kluczowe, które powinny znajdować się w interesujących go artykułach. Jeśli tylko na którymś kanale pojawi się wpis, który użytkownika interesuje, program o tym powiadamia. |
- [[pl:dydaktyka:ztb:2012:projekty:past_explorer:koncowy|Raport końcowy]] | |
| |
====== Projekt konceptualny ====== | Do realizacji projektu postanowiliśmy posłużyć się zaproponowaną na [[pl:dydaktyka:ztb:2012:etapy_projektowania|stronie]] metodyką. Składa się ona z następujących etapów: |
| |
===== 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: | |
- Dzienny, zawierający podsumowanie, ile RSSów zawierających słowo kluczowe pojawiło się na stronie | |
- Godzinny | |
- 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: | |
- Pobieranie nowych RSSów dla podanych przez użytkownika stron | |
- Przeszukiwanie nowych RSSów pod kątem zawartości, kiedy zawierają dane słowo kluczowe. | |
- Zapisywanie zaakceptowanych RSSów w bazie danych | |
- Powiadomienie użytkownika o nowych wiadomościach w bazie | |
- Tworzenie raportu dotyczącego nowej zawartości bazy | |
| |
Should: | |
- Wybieranie rodzaju i częstotliwości raportowania | |
- Wybór rodzaju powiadomień (poprzez mail/sms) | |
- Powiadamianie o zmianie zawartości danej strony | |
| |
Could: | |
- Znalezienie darmowego sposobu na powiadomienia sms | |
- Wysłanie powiadomień sms wykorzystując kalendarz google (posiada możliwość darmowego powiadamiania) | |
- Sprzątanie bazy ze starych wpisów | |
| |
Won't: | |
- Własna bramka wysyłająca smsy z powiadomieniami (mogłaby być korzystna w przypadku dużego zainteresowania aplikacją) | |
- 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: | |
- Zaprojektowanie bazy danych (Jakub Kozik) | |
- Konfiguracja serwera bazy danych (Jakub Kozik) | |
- Moduł pobierania RSSów (Jakub Kozik) | |
- Moduł obsługi bazy danych (Jakub Kozik) | |
- Moduł powiadamiania użytkownika (Dariusz Gruca) | |
- Moduł tworzenia raportów (Dariusz Gruca) | |
- Zaprojektowanie i wykonanie GUI (Dariusz Gruca) | |
- 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 === | |
| |
- Użytkownik uruchamia program. | |
- Użytkownik tworzy nową bazę przeszukiwań. | |
* Wpisuje nazwę bazy | |
* Dodaje 1 kanał RSS | |
* Dodaje 1 słowo kluczowe | |
- Użytkownik ustawia powiadamianie cykliczne na mail co 1 godzinę. | |
- Użytkownik minimalizuje program do traya. | |
| |
=== Scenariusz II === | |
| |
- Użytkownik uruchamia program. | |
- Użytkownik tworzy nową bazę przeszukiwań. | |
* Wpisuje nazwę | |
* Dodaje 1 kanał RSS | |
* Dodaje 1 słowo kluczowe | |
- Użytkownik ustawia powiadamianie smsem, gdy tylko pojawi się jakiś wyszukiwany RSS. | |
- Użytkownik minimalizuje program do traya. | |
- | |
=== Scenariusz III === | |
| |
- Użytkownik uruchamia program. | |
- Użytkownik modyfikuje istniejącą bazę przeszukiwań. | |
* Dodaje 2 nowe kanały RSS | |
* Dodaje 1 słowo kluczowe | |
- 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**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:fhd.png|}} | |
| |
| |
===== 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**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:kontekstowy.png|}} | |
| |
**Diagram główny**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:glowny.png|}} | |
| |
**1. Obsługa baz przeszukiwań**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:1.png|}} | |
| |
**1.5 Konfiguracja bazy**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:15.png|}} | |
| |
**2. Obsługa systemu powiadomień**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:2.png|}} | |
| |
**2.1 Odświeżanie baz danych**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:21.png|}} | |
| |
**2.2 Raportowanie**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:22.png|}} | |
| |
| |
===== 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**\\ | |
{{:pl:dydaktyka:ztb:2012:projekty:rss:baza.png|}} | |
| |
**Kod SQL (SQLite) bazy danych**\\ | |
<code sql> | |
BEGIN; | |
| |
CREATE TABLE IF NOT EXISTS bases ( | |
base_name VARCHAR(30) PRIMARY KEY, | |
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; | |
</code> | |
| |
| |
===== 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:std.png|}} | |
| |
| - [[pl:dydaktyka:ztb:2012:projekty:rss:konceptualny|Projekt konceptualny]] |
| - [[pl:dydaktyka:ztb:2012:projekty:rss:logiczny|Projekt logiczny]] |
| - [[pl:dydaktyka:ztb:2012:projekty:rss:koncowy|Raport końcowy]] |