Tematem zadania jest program telewizyjny (w sensie TeleTydzień, Gazeta Telewizyjna itp.; dobre przykłady elektroniczne to np. Telemagazyn i Gazeta Telewizyjna).
Głównym celem zadania jest napisanie programu w Javie, który będzie operował na tzw. „lokalnej bazie danych” i wykonywał podane polecenia: importu, eksportu i wizualizacji danych oraz „zapominania”.
Alternatywnie, zamiast programu command-line można stworzyć „webserwis” o takiej samej funkcjonalności (ale nie będzie za to dodatkowych punktów).
W skład rozwiązania wchodzą także schematy XML Schema, przykładowe dokumenty XML (z danymi do zaimportowania), arkusze XSLT (i pewnie CSS) oraz skrypt Anta służący do budowania aplikacji. I prosta dokumentacja.
W poniższym opisie za napis ab123456 należy wstawić własny login na students.
Program będzie czytał / pisał / modyfikował opisane poniżej rodzaje dokumentów XML. Dla każdego typu dokumentu należy opracować i zapisać w XML Schema jego schemat.
Schematy powinny być napisane w sposób modularny, wspólne i powtarzające się typy zawartości powinny być (w miarę możliwości) zdefiniowane w jednym miejscu i używane wielokrotnie. Dopuszczalne jest utożsamienie rozdzielonych tutaj typów dokumentów.
Zdefiniowane w schematach obiekty (elementy, typy, grupy itp.) powinny znajdować się
w przestrzeniach nazw np. (ale niekoniecznie) takich:
http://students.mimuw.edu.pl/%7Eab123456/xml_zad4/import.
Dokument lub dokumenty, w których system przechowuje lokalną kopię danych o programach telewizyjnych. Może to być jeden lub wiele dokumentów jednego lub wielu typów.
Przy projektowaniu „lokalnej bazy danych” należy wziąć pod uwagę wykonalność i efektywność operacji. Można przyjąć, że przechowywane dane nie będą przekraczały 50 kanałów i 3 miesięcy czasu. Ponadto należy przyjąć realistyczne założenia na temat średniej długości audycji, wielkości (i częstości występowania) opisów itp.
Dokument, w którym dostawcy treści przesyłają do systemu cząstkowe dane.
Dostawcą treści będzie zwykle stacja telewizyjna, która jednorazowo może przysłać informacje o programie jednego lub wielu kanałów w określonym przedziale czasu.
Typ dokumentu powinien umożliwiać przesłanie do systemu:
Z każdą audycją związane mogą być pewne informacje, co najmniej:
Należy rozważyć wzbogacenie opisu o bardziej specyficzne struktury, np. odcinek serialu, reżyseria, obsada i kraj(e) produkcji filmu itp. Dla audycji cyklicznych można też rozważyć sposoby na uniknięcie redundancji opisów itp.
Ponadto niezbędne może być przekazywanie informacji specyficznych dla przyjętej implementacji, np. identyfikatorów kanałów czy audycji.
Częścią rozwiązania mają być przykładowe dokumenty XML zawierające dane do zaimportowania. Wymagane są co najmniej:
Dokument, w którym system może wysłać dane do odbiorcy treści, np. wysłać do „drukarni” tygodniowy program polskich kanałów.
W jednym dokumencie mają znaleźć się dane o programie jednego lub wielu kanałów w określonym przedziale czasu, wraz z nazwami, opisami itp. (jak przy imporcie).
Klasą wykonywalną musi być pl.edu.mimuw.ab123456.xml_zad4.Main.
Katalogiem bieżącym, w którym program będzie uruchamiany, będzie workspace (patz Budowa).
Program będzie uruchamiany z co najmniej jednym parametrem. Pierwszy parametr będzie nazwą polecenia, które należy wykonać. Kolejne parametry programu, jeśli podane, będą parametrami podanego polecenia.
Dla większości poleceń program czyta ze standardowego wejścia i/lub pisze na standardowe wyjście. Komunikaty o błędach i ostrzeżenia należy wypisywać na standardowe wyjście błędów lub do pliku z logami. Wersja „produkcyjna” podczas normalnego działania (bez błędów) nie powinna wypisywać nic na standardowe wyjście błędów, a do ewentualnego pliku z logami co najwyżej stałą liczbę wierszy dla jednego uruchomienia.
Dla parametrów oznaczających czas dopuszczalne są następujące formaty:
2007-02-28 (oznacza godzinę 00:00),2007-02-28 12:40 (mimo spacji pojedynczy parametr),2007-02-28T12:40.Polecenie jest opcjonalne i ma służyć tylko do zbudowania pustej lokalnej bazy danych przez skrypt Ant.
initialize
Zależne od przyjętej implementacji.
Pozostawia zainicjowaną, pustą lokalną bazę danych.
import
Brak.
Dokument XML z danymi do zaimportowania.
Brak
Aktualizuje program, dodając, usuwając lub modyfikując audycje. W szczególności może dodać nowe kanały (a także inne dane współdzielone przez wiele audycji, jeśli rozwiązanie to przewiduje).
export
Brak.
Dokument XML z eksportowanymi danymi. Powinien zawierać audycje rozpoczynające się w podanym przedziale czasu, wraz z ich opisami.
Bez zmian.
show
Brak.
Poprawny dokument HTML lub XHTML wizualizujący wybrany fragment programu telewizyjnego (tzn. audycje wybranych kanałów rozpoczynające się w podanym przedziale czasu). Dla każdej audycji należy podać godzinę rozpoczęcia, nazwę i krótki opis. Warto też jakoś uwzględnić koniec ostatniego programu danego dnia (inaczej mówiąc przerwy w programie).
Można przyjąć ograniczenie na liczbę wyświetlanych kanałów (minimum trzy). Pozostałe parametry można zignorować.
Można przyjąć ograniczenie na długość dokumentu (nie krótsze niż trzy doby).
Bardzo zalecane jest formatowanie przy pomocy CSS. Ścieżki do zewnętrznych arkuszy CSS należy pisać tak, aby poprawnie wyświetlał się dokument zapisany w katalogu workspace.
W przypadku webserwisu audycje powinny zawierać odnośniki do zapytania zwracającego opis audycji.
Bez zmian.
Wynik tego polecenia ma zostać uzyskany w wyniku przekształcenia XSLT. Nie precyzuję, na jakim dokumencie / dokumentach to przekształcenie ma zostać wykonane.
details
Brak.
Poprawny dokument HTML lub XHTML z pełnym opisem wybranej audycji. Założenia co do CSS takie same jak dla show.
W skład opisu mają wchodzić:
Bez zmian.
Wynik tego polecenia ma zostać uzyskany w wyniku przekształcenia XSLT. Nie precyzuję, na jakim dokumencie / dokumentach to przekształcenie ma zostać wykonane.
forget
Data (format 2007-02-20).
Brak.
Brak.
Usuwa program telewizyjny sprzed podanej daty. Należy przyjąć, że polecenie to będzie wykonywane stosunkowo rzadko przez administratora systemu w celu zwolnienia miejsca na dysku i zwiększenia efektywności systemu.
Polecenie nie musi usuwać danych dokładnie co do minuty, dopuszczalna jest dokładność rzędu doby:
Po wykonaniu polecenia z datą 2007-02-20
w bazie mogą zostać lub nie dane dotyczące dowolnych programów kończących się po 2007-02-19 00:00
a rozpoczynających się przed 2007-02-21 00:00. Ważne jest, aby pozostały dane wszystkich programów
rozpoczynających się od 2007-02-21 00:00.
Program należy napisać w Javie w wersji 5.0 lub 6.0.
Jeśli program korzysta z bibliotek nie zawartych w dystrybucji Java SE, należy opisać to w dokumentacji.
Jeśli program korzysta z bibliotek innych niż składniki Java EE 5, JWSDP 2.0, Log4J, Ant, Xerces, Xalan i Saxon – należy także podać adres strony z tym oprogramowaniem.
W rozwiązaniu można korzystać ze sposobów przetwarzania XML zawartych w standardach JAXP (DOM, SAX, StAX, a także transformacje, walidacje i XPath) oraz JAXB.
Jeśli program używa StAX lub JAXB, lub piszesz webserwis zamiast programu, zalecam (ale nie wymagam) pisanie w Javie 6.0. Program będzie testowany z najnowszymi wersjami Xerces, Xalan i Saxon (dla XSLT 2.0)
Należy użyć co najmniej jednego sposobu parsowania (DOM, SAX, StAX, JAXB), a
przekształcenia XSLT wykonywać poprzez klasy i interfejsy z pakietu javax.xml.transform.
Należy dokonywać walidacji przetwarzanych dokumentów względem schematów.
Nie należy stosować innych metod dostępu do treści XML ani odwoływać się bezpośrednio do klas z konkretnych implementacji.
W skład rozwiązania wchodzą arkusze XSLT. Obowiązkowe jest wykorzystanie XSLT to wizualizacji danych (polecenia
show i details). Można także użyć XSLT do innych celów.
Można używać standardu XSLT 1.0 lub XSLT 2.0, najlepiej konsekwentnie tego samego we wszystkich arkuszach.
Wszystkie klasy należy umieścić w pakiecie pl.edu.mimuw.ab123456.xml_zad4 lub podpakietach.
Należy wysłać archiwum ZIP lub TGZ, o nazwie równej loginowi studenta, zawierające katalog o następującej strukturze:
podkatalog src zawierający:
java kod źródłowy klas Javy (w podkatalogach odzwierciedlających pakiety),xsd schematy XML Schema,xsl arkusze XSLT,css arkusze CSS,Nie należy wysyłać plików class ani jar, plików tymczasowych, przykładowych wyników testów (poza wymaganymi przykładowymi dokumentami XML).
W katalogu uzyskanym przez rozpakowanie paczki polecenie ant powinno:
Zbudować aplikację, tzn. jedno z poniższych:
workspace, workspace/class lub workspace/bin wygenerować pliki class
(w podkatalogach odpowiadających pakietom),
workspace (lub jego podkatalogów), tak,
aby katalog src nie był potrzebny do uruchomienia programu.
Pliki te (lub ich część) można także umieścić w jar. Jeśli program będzie działał,
nie trzeba już tych plików kopiować.
initialize.
Opis rozwiązania powinien zawierać:
W kodzie programu należy umieścić krótkie komentarze w kluczowych miejscach, a także komentarze zgodne z konwencjami javadoc dla własnych klas i metod.
W schematach należy (krótko) udokumentować znaczenie poszczególnych elementów i atrybutów, a także opisać typy nazwane, grupy i grupy atrybutów. Opisy mają być naprawdę krótkie.
W arkuszach XSLT należy opisać (w komentarzach) znaczenie całego arkusza, jego parametry, własne funkcje i szablony nazwane, a także umieścić krótkie komentarze w kluczowych miejscach.
Opcjonalnie, zamiast programu command-line, można stworzyć webserwis o takiej samej funkcjonalności. Zamiast interpretacji poleceń serwer powinien udostępniać odpowiednie zapytania, o takich samych parametrach.
Część wizualizacyjna ma być „klikalna” (np. linki do szczegółowych opisów, formularz do wybierania kanałów i przedziałów czasowych).
Gdyby ktoś się zdecydował, w czasie dyskusji uszczegółowimy wymagania.
Najważniejsze będzie poprawne działanie programu. Możliwe będzie zaliczenie jeśli np. jedno-dwa polecenia będą miały problem w pewnych szczególnych przypadkach, ale niedopuszczalne jest niedziałanie programu w najbardziej podstawowych zastosowaniach.
Aby uprościć program (obniżając ocenę, ale jeśli będzie poprawnie działać i będzie „ładnie”, ciągle będzie zaliczenie) można wprowadzić pewne ograniczenia (np. import danych tylko z jednej doby, brak nadpisywania audycji). Ważne, aby to opisać w dokumentacji.
Ważna dla oceny będzie też jakość opracowanych schematów (powinny jak najściślej kontrolować dokumenty, ale dawać im jak największą funkcjonalność), a także poprawna strukturalnie budowa schematów, arkuszy i oczywiście klas.
Dokumentacja (i komentarze) nie musi być obszerna, ale powinna wyjaśniać najważniejsze rzeczy. Za jej brak albo istotną niekompletność będą odejmowane punkty.
Jeśli chodzi o HTML i CSS, to większą wagę będzie miała struktura dokumentu (X)HTML i możliwość dopracowania jego wyglądu w CSS bez zmian w strukturze HTML, a mniejszą wagę sam wygląd. Poprawna struktura to m.in. stosowanie semantycznych znaczników tam, gdzie to właściwe, używanie tabel do robienia tabel, a nie wyrównywania, stosowanie klas dla podobnych elementów itp.
W razie wątpliwości co do treści zadania proszę wysyłać pytania pod adres czarnik@duch.mimuw.edu.pl.
Odpowiedzi na najczęściej pojawiające się pytania i inne uzupełnienia mogą pojawić się na tej stronie. Proszę sprawdzać ją co jakiś czas, na pewno przed wysłaniem pytania.