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