Zasady prowadzenia zajęć projektowych z przedmiotu „Formalne
Transkrypt
Zasady prowadzenia zajęć projektowych z przedmiotu „Formalne
Zasady prowadzenia zajęć projektowych z przedmiotu „Formalne projektowanie systemów informacyjnych”, studia dzienne data opracowania/modyfikacji : 20.02.2009 1. Cel projektu Celem projektu jest wykonanie kompletnej i funkcjonalnej aplikacji bazodanowej z interfejsem działającym w przeglądarce WWW. Obowiązującym serwerem bazy danych jest Oracle (wersje 8i lub 9i lub 10g). Aplikacja ma być wykonana w technologii PL/SQL. 2. Elementy do wykonania oraz ich „waga” W ramach projektu należy wykonać 5 podstawowych elementów: 1. 2. 3. 4. 5. Opracowanie szczegółowych założeń tworzonego systemu (10%) Projekt struktury relacyjnej (15%) Implementacja w systemie Oracle (skrypt) (5%) Utworzenie skryptu zapełniającego tabele przykładowymi danymi (10%) Przygotowanie zestawu 10 zapytań SQL ilustrujących podstawową funkcjonalność projektu (10%) 6. Projekt oraz wykonanie interfejsu użytkownika (50%) Ad 1 Założenia powinny być przygotowane w formie pisemnej. Powinny zawierać, podane w bardzo syntetycznej formie, wszystkie najważniejsze cechy funkcjonalne systemu. Przykładowy fragment z opisu systemu do wspomagania układania planu zajęć na UZ zamieszczono na końcu opracowania. Opis nie powinien przekraczać 1 strony tekstu (czcionka 12pt, odstęp między wierszami pojedynczy) Ad 2 Projekt struktury relacyjnej musi zostać przygotowany w podanym przez prowadzącego systemie komputerowym. Projekty przygotowane w inny sposób (nawet poprawne merytorycznie) nie będą przyjmowane. Szczegóły zostaną podane na wykładzie. Należy zwrócić szczególną uwagę na prawidłowe i zgodne z „zasadami sztuki” zaprojektowanie powiązań między poszczególnymi tabelami (klucze główne i obce) oraz tzw. ograniczeń bazodanowych (NULL/NOT NULL, UNIQUE, DEFAULT, CHECK). Tam, gdzie jest to wymagane powinny zostać również utworzone indeksy oraz wyzwalacze bazodanowe. Ad 3 Na bazie opracowanej struktury relacyjnej musi zostać przygotowany skrypt (plik tekstowy) zawierający wszystkie niezbędne polecenia SQL konieczne do utworzenia zaprojektowanej struktury w bazie Oracle. Należy zwrócić szczególną uwagę na prawidłową i zgodną z „zasadami sztuki” implementację powiązań między poszczególnymi tabelami (klucze opracowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki główne i obce) oraz tzw. ograniczeń bazodanowych (NULL/NOT NULL, UNIQUE, DEFAULT, CHECK, ENUM, SET). Tam, gdzie jest to wymagane powinny zostać również utworzone indeksy. Ad 4 Przygotowany skrypt musi zawierać polecenia (INSERT) tworzące w zaprojektowanej strukturze relacyjnej przykładowe dane. Każda z głównych tabel powinna zawierać przynajmniej po ok. 20-30 sensownych rekordów. Tam, gdzie to będzie naprawdę uzasadnione danych tych może być mniej. Ad 5 Przygotowany skrypt musi zawierać polecenia SQL (10 sztuk) pozwalające zapoznać się z charakterem przechowywanych w strukturze relacyjnej danych. Przykładowo, gdy rejestrujemy dane na temat wielkości składanych zamówień na towary spożywcze, celowym było by zapytanie SQL pokazujące 10 największych zamówień w ostatnim kwartale. Ad 6 Interfejs użytkownika musi być wykonany w technologii PL/SQL z wykorzystanie tzw. bramki sieciowej (będzie o tym mowa na wykładzie). Student musi dostarczyć skrypt (plik tekstowy), z wszystkimi kodami źródłowymi. W czasie sprawdzania projekty będą one za każdym razem instalowane na „czystym” koncie utworzonego w tym celu użytkownika Oracle. Zakładamy ponadto, że serwer WWW będą już poprawnie skonfigurowany. Aplikacja musi dać się bezbłędnie zainstalować (skompilować) z dostarczonych przez studenta skryptów (patrz opis niżej). Dopiero potem będzie ona sprawdzana pod względem merytorycznym. 3. Terminy i zasady oceny Elementy systemu wymienione w punkcie 2. muszą być oddawane w określonych terminach. Za całość można zdobyć 10 pkt. Warunkiem dopuszczenia do obrony projektów jest dostarczenie wszystkich elementów oraz uzyskanie przynajmniej 60% punktów. Terminy są następujące: Element Termin oddania założenia na trzecich zajęciach projekt struktury relacyjnej na piątych zajęciach implementacja w bazie Oracle na siódmych zajęciach przykładowe dane oraz zapytania SQL na ósmych zajęciach opracowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki interfejs użytkownika na przedostatnich zajęciach Za każdy tydzień spóźnienia odejmowane jest 5%. Po osiągnięciu 0% wchodzimy w liczby ujemne! Prowadzący zastrzega sobie prawo do nie przyjęcia danego elementu ze względu na jego złą jakość. W przypadku nie uzyskania 60% student nie otrzymuje wpisu zaliczeniowego oraz nie ma możliwości zdawania „w późniejszym terminie”. Jedyne uwzględniane usprawiedliwienia mogą dotyczyć tylko przypadków losowych (za taki nie będą uznawane np. „niespodziewane awarie dysku”, „rozsypanie się systemu operacyjnego”, „zgubienie dyskietki” oraz tym podobne często stosowane tłumaczenia). 4. Obecność na zajęciach Obecność nie jest obowiązkowa poza terminami, o których mowa w poprzednim punkcie. Poszczególne elementy muszą być oddawane osobiście. opracowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki Fragment założeń dla systemu „Plan zajęć na Uniwersytecie Zielonogórskim” ... System ma umożliwiać przechowywanie danych o: • pracownikach naukowych (z podziałem na wydziały oraz instytuty, zakłady, katedry) • studentach (z podziałem na grupy dziekańskie, laboratoryjne, ćwiczeniowe itp.) • salach dydaktycznych wraz z informacją o ilości miejsc siedzących oraz wyposażeniu w ew. sprzęt audiowizualny, • przedmiotach przewidzianych aktualną siatką zajęć. System musi umożliwiać bardzo elastyczne planowanie zajęć, w tym sensie, że musi istnieć możliwość zaplanowania dowolnych zajęć, w dowolnym terminie, w dowolnych godzinach (z gradacją co 5 minut), dla dowolnej grupy studentów, dla dowolnego nauczyciela oraz w dowolnej sali. System musi również kontrolować, czy nie powstają tzw. „nakładki (np. dwie osoby mają zaplanowane zajęcia w tym samym czasie w jednej sali) ... opracowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki