Systembeskrivning Alhanko
Innehållsförteckning 1 Systemöversikt 1.1 Översikt 1.1.1 Klient/Server 1.1.2 Modulbeskrivning 1.1.3 Programvara 1.2 Databasen 1.3 Systemkrav 1.3.1 Servern 1.3.2 Klienten 2 Filstruktur 2.1 Webgränssnitt 2.1.1 Site-karta 2.2 JAVA Klassfiler 2.2.1 UML Klassdiagram 3 Säkerhet 3.1 Användarsäkerhet 3.2 Kommunikationssäkerhet
1 Systemöversikt 1.1 Översikt Denna systemöversikt gäller det informationssystem vi utvecklat på beställning av Kungliga Operan. Den hanterar deras lager och deras uppsättningar. Det finns möjligheter att lägga till bilder på både objekt och föreställningar, söka bland dessa och hyra ut objekt och boka om dem. Den stödjer även lagerhanteringen. Till systemet hör ett login med användarhantering och roller. Systemet är designad enligt en n-lager struktur och är gjort i JAVA/JSP. I vårt fall består systemet av 3 olika lager. Systemet bygger på principen om Klient/Server, alltså att systemet är installerat på en särskild server som sedan accessas genom en tunn klient, i vårt fall en webläsare. 1.1.1 Klient/Server Att bygga ett system enligt Klient/Serverprincip kommer säkerligen bli ännu vanligare om några år i och med införandet av bredband. Ett program kan köras på i huvudsak tre sätt. Det första är ett installerat program som installeras på datorn. Ingen kommunikation förekommer då vanligtvis med servern. Exempel på program är MS Word eller Photoshop. Det andra alternativet är Klient/Server med tjock klient, dvs användaren måste installera ett program på sin dator med som sedan kommunicerar med en Server. Beräkningsjobbet är då uppdelat på både användarens dator och servern. Det tredje alternativen är Klient/Server, tunn klient. Det är det vi använder oss av. Det innebär att inget program behöver förinstalleras på användardatorn. Det enda som krävs är att det finns en kommunikation till servern, antingen via ett lokalt nätverk, LAN eller t.ex. via Internet. Användaren, klienten, skickar en request till servern som skickar tillbaks en ofta grafisk sida med ett visst informationsinnehåll i HTML-format. När användaren sedan vill kommunicera med servern igen, t.ex. för att titta på nästa sida, få mer information, genomföra en sökning eller skicka information så måste en ny request göras. Kända Klient/Server-system är t.ex. MSN Hotmail.
Databas Relationsdatabas MYSQL Server Databaskoppling JDBC Applikationsserver TOMCAT 3.3 JSP JavaBeans Servlets Webserver APACHE INTERNET eller Lokalt nätverk HTMLdokument Användare Klientdator (Användare)
1.1.2 Modulbeskrivning Vårt system bygger i huvudsak på tre moduler: en databas, en applikationsserver och en webserver. Databasserver Databasservern innehåller databasen, som lagrar alla data i systemet i tabeller. Databasen bör ligga på en separat dator. Databasen kommer av säkerhetsskäl endast vara accessbar via applikationsservern. Det gör att en användare endast kan se det data som applikationen tillåter användaren att se. Vi har använt databasen MySQL 3.23.44 som är den världsledande gratisdatabasen. Applikationsserver Applikationsservern kör själva applikationen (programmet) och svarar på förfrågningar från webservern. Applikationsservern kan ligga på en separat dator eller på samma dator som webservern. I vårt fall är dessa nära integrerade och ligger på samma dator. Gränssnittet mellan webservern och applikationsservern är inte intressant ur vår synvinkel. Vi har använt oss av applikationsservern Tomcat ver 3.3.1 som hanterar program skrivna i programspråket JAVA. Webserver Webserver är den eller de datorer som har ett program som sköter kommunikationen mellan applikationen och användarnas klienter, vanligtvis via HTTP-protokollet, alltså det som används för vanliga hemsidor. Vi har använt Apache som webserver, vilket troligtvis är den mest använda gratiswebservern för Internetapplikationer. Klientprogramvara Klientprogramvara är det program användaren använder för att kommunicera med en applikation som ligger på ett annat ställe i ett lokalt eller globalt nätverk (Internet). I vårt fall kommer klientprogramvaran motsvaras av webbläsaren Internet Explorer som finns på alla PC-datorer som har en installation av Windows 95 eller senare version. 1.1.3 Programvara Den programvara som ska installeras på systemets serversida är: MySQL 3.23.44 (rekommenderad version) Tomcat 3.3.1 (rekommenderad version) Suns SERVLET-paket (endast för möjligheten till kompilering) MMMySql JDBC-drivrutin. JDK 1.2.2 (rekommenderad version) Vårt program MySQL bör installeras i c:\mysql\, annars måste vissa inställningar göras. Tomcat kräver ingen installation. Servletpaketets.JAR-fil ska inkluderas i CLASS_PATH som är en miljövariabel.
JDK rekommenderas ligga i C:\JDK1.2.2 och ska finnas i JAVA_HOME Vårt program bör installeras i \Tomcat\webapps\root\ JSP-filerna ska ligga i \root\jsp CLASS-filerna ska ligga i \root\web-inf\classes\. Denna sökväg måste också finnas i CLASS_PATH. HTML-filen index.html ligger direkt i \root\ JDBC-drivrutinen rekommenderas ligga i \root\web-inf\classes\ Servlet.jar rekommenderas ligga i \root\web-inf\classes\ 1.2 Databasen
boknings_tid PK,FK1 bokn_id bokn_start bokn_stopp bild_bokning PK,FK1 bokn_id bild_id bild_sökväg bokn_info PK,FK1 bokn_id spelplats regissör scenograf koreograf kostym anteckning premiärdatum Projekt Alhanko roll PK roll_id funktioner PK funk_id funk_benämning FK1 roll_id roll_benämning aktiv användare PK anv_id anv_namn password? FK1 roll_id aktiv [j/n] En användare måste kunna inaktiveras om personen slutar. Sök PK seek_id benämning sök_kolumn För att kunna styra vilka giltiga sökningar som kan göras på tabellen objekt och objekt_typer. sök_kolumn anger på vilken kolumn i objekt som sökning kan ske. En combo i GUI kan enkelt byggas upp med giltiga sökningar. objekt_typ PK typ_id benämning objekt_typer PK,FK2 obj_id PK,FK1 typ_id PK obj_id objekt benämning obundet_objekt [j/n] standardmaterial [j/n] handrekvisita [j/n] inventarienummer enhet/avd hanteras_av grupp antal form/typ motiv längd bredd höjd vikt material färg stil ålder [ååååmmdd] design tekniska_egensk kondition övriga kommentarer tillverkningsdatum [ååååmmdd] inköpsdatum [ååååmmdd] inköpspris värde förrådsplats förrådsansvar hyllsektion hyllnummer noteringar kasserad_år förbr_art_antal tumnagel aktiv [j/n] Förbrukningsartiklar hanteras som vanliga objekt. Om kolumnen förbr_art_antal är skiljt från 0 är det en förbrukningsartikel. Sätts default till 0. En artikel kan aldrig raderas, bara göras inaktiv bokade_objekt PK,FK2 obj_id PK,FK1 bokn_id akt rå position bokstav bild_objekt PK,FK1 obj_id bild_id bild_sökväg boknings_typ PK bokn_typ_id benämning aktiv bokning PK bokn_id FK1 bokn_typ benämning FK2 bokningsansvarig ex: föreställning, reparation, underhåll, uthyrning, utlåning etc En bokningstyp kan aldrig raderas, bara göras inaktiv
1.3 Systemkrav 1.3.1 Servern Databasen och Applikationsservern bör köras på separata datorer för optimal prestanda. Teoretiskt har både Tomcat och MySQL har relativt låga krav på hårdvaran, både till minne, processor och utrymme, och det går att köra på en Pentium II eller motsvarande, med en hårddisk med 4 GB reserverat utrymme för MySQL. Skulle servern vara av typ Pentium II kommer det i praktiken bli problem. Sökningar och annat kommer att ta lång tid och det kommer inte att vara skalbart för att hantera många användare. Därför rekommenderar vi att systemet ligger på en dator med en processor på minst 1000 MHz, 512 Mb och en hårddisk på minst 20 Gb. 1.3.2 Klienten Prestandan på klienten är inte av samma betydelse för systemet som servern, då alla beräkningar görs av servern. Däremot kan det upplevas långsamt då en sämre klientdator tar längre tid på sig att visa grafik, byta mellan olika htmlsidor m.m. Klienten ska ha installerat och använda webläsaren Internet Explorer ver 5.0 eller högre. Det medför att den bör ha Windows 98 eller högre, samt vara av minst typ Pentium.
2 Filstruktur Databaslager Databas Repository Tar informationsobjekt som parametrar och returnerar bara informationobjekt, såsom sökresultat. På så sätt kan databasen bytas ut eller skrivas om utan att det påverkar de andra lagerna. Endast repositoryt måste skrivas om för att matcha objekten mot den nya databasstrukturen Informationsobjekt Ett informationsobjekt kan vara t.ex. en person, en sak osv. Innehåller enbart get och setmetoder och privata typer. Programlogiklager Programlogiken (Sessionsobjekt) SERVLETS Då JSP-sidan laddas kan den genom sessionsobjektet hämta information, parametrar osv. Kan även sätta parametrar och anropa metoder. redirect Frontendlager JSP-SIDA Servlets anropas vid submit, t.ex. i formulärhantering, knapptryckningar osv. En servlet redirectar sedan till en annan eller samma jspsida som då laddas om på nytt. JSP pluginsidor inkluderar då sidan laddas
2.1 Webgränssnitt 2.1.1 Site-karta
2.2 JAVA Klassfiler Package Beans ApplicationBean DBService Enty Object Package Servlets AddObject AddPlay AddReservation AddPeriod LoginServlet ReservateObjects SearchBeforeReservateObject SearchObject SearchObjectBeforeChange SearchPlay SearchPlayBeforeChange SearchReservation SearchReservationBeforeChange 2.2.1 UML Klassdiagram
APPLICATIONBEAN int userid String username boolean loggedin Vector allowedfunctions String urlimage String urljsp String urlsearch String urlchange String: getdropdown(string) String: getdropdowninsertblank(string) String: getsearchresultandraashtml( ) String: getsearchresultandrareservationashtml( ) String: getsearchresultashtml( ) String: getsearchresultbokaashtml( ) String: getsearchresultreservationashtml( ) boolean: isfunctionallowed(int) 0..0 1..1 DBSERVICE String driver String database addobject(string, String, int, int, int, int, String, String, String, int, String, String, int, int, String, String, String, int, String, String, String, String, String, String, int, int, String, String, String, int, String, String) addobjecttypes(string, String) addtodb(string, Vector) Vector: getallowedfunctionsfromuserid(int) Vector: getdropdowncontent(string) Vector: getentry(int) Vector: getentrypictures(int) Vector: getentryrelatedobjects(int) Vector: getentrytimes(int) String: getnewidintable(string) Vector: getobject(int, Vector) Vector: getobjectpictures(int) Vector: getobjectrelatedinfo(int) Vector: getplayinfo(int) String: getsingletextfromdb(string) Vector: gettabletextfromdb(string, Vector) boolean: inserttodb(string) Vector: login(string, String) Vector: searchobject(vector) Vector: searchreservation(vector) int: stringtoint(string) String: stringtopic(string) 1..1 1..1
1..1 1..1 ENTRY OBJECT String site String entry String director int entryid String designer int id_object String choreographer String name_object String costumedesigner int unboundprops String note int standardprops String openingdate int handprops String bookedbyusername int inventorynumber String startdate String department String enddate String handledby int bookedby String groupid int entryid int numberof int entrytype String form int active String subject String name_entry int length String name_entry_type int height Vector pictureids int weight Vector links String material Vector typeids String color Vector objectids String style Vector name_objects int age Vector name_object_types String design Vector inventorynumbers String technical int: nrofpictures(int) String condition int: nrofrelatedobjects(int) String comment String: setid(int) String manufacturedate String buydate int buyprice int value String storage String storageresponsible String shelvesection int shelvenumber String note String trashdate int goodsnumber String thumbnail int active String barcode String act int row String stageplace String letter String link String name_type Vector object_types Vector pictures Vector entry_types int: nrofentrytypes( ) int: nrofobjecttypes( ) int: nrofpictures( ) String: setid_object(int)
3 Säkerhet Säkerheten i JAVA/JSP-baserade Klient/Server system kan anses vara god. I jämförelse med 2-lagerarkitekturer eller hur många ASP-baserade system brukar designas så är den mycket god. 3.1 Användarsäkerhet För att garantera att endast behöriga användare har tillgång till systemet så har vi skapat ett login med användarnamn och lösenord. Lösenorden är inte krypterade i databas. Det är ändå inte möjligt för användare att se andras lösenord. Systemet använder sig av roller där varje roll är knuten till ett visst antal funktioner. Varje användare är knuten till en roll som styr vad han kan göra i systemet. Om en användare inte är behörig till en funktion så ser han möjligheten i gränssnittet med kan inte genomföra funktionen. 3.2 Kommunikationssäkerhet Ett av de stora säkerhetsmålen är att se till att ingen obehörig kan få tillgång till information eller förstöra den genom att ta bort, ändra eller lägga till felaktig information. Databasen är aldrig mer skyddad än rummet där servern står i. Om någon stjäl datorn är informationen lätt att komma åt. Via nätverket är det betydligt svårare. Ingen användare kan själva prata med databasen utan att gå via gränssnittet som en mycket begränsad funktion. Begränsad menas nu med att jämfört med alla funktioner som är möjliga att göra så kan användaren endast göra de som gränssnittet tillåter honom till. Det enda i systemet som kan prata med databasen är en enda klass i applikationsservern. Men den går inte att påverka vad den ska hämta ut, den har redan förutbestämda metoder för vad som kan hämtas ut ur databasen. Därför anses innehållet i databasen vara relativt skyddad från obehöriga användare. Möjligheten till HTTPtunneling är också mycket mindre jämfört med en 2-lager arkitektur där det kan vara ett betydande problem. I många ASP-arkitekturer är det möjligt att via URL:en i webläsaren skriva in en söksträng för att nå information i databasen. Detta är inte möjligt i vårt system. Säkerheten förbättras också ytterligare genom att detta system ska köras på ett LAN-nätverk. Det gör att om LAN-nätverket är rätt konfigurerat så är det omöjligt att nå informationen över Internet.