Eftersom det oprindelige udvikler-hold på MAOV ikke vil være til rådighed til ændringer af systemet efter det er færdigt, er her en guide der skal hjælpe et eventuelt senere udviklingshold med ændringer.
Systemet er fuldt ud udviklet i Java, og compilet med JDK 1.2.1 fra Sun. Der skulle dog ikke være noget i vejen for at bruge en anden compiler, som eksempelvis JDeveloper. Efter en ændring skal de ændrede klasser naturligvis recompiles.
Systemet er samlet i en package med navnet oracle.dk.maov, hvilket sætter krav til at klasserne skal ligge i nogle under-kataloger, der matcher stien på package'n.
Når systemet compiles skal compileren have adgang til de packages. som systemet bruger. Bruger man JDK, skal stien til dem sættes i environment-variablen CLASSPATH. De packages der er brug for er følgende:
Det samlede MAOV-system består af 20 klasser, der alle skal pakkes sammen i een JAR-fil eller ZIP-fil. Til det formål har vi brugt jar.exe som medfølger til JDK, med følgende parametre:
jar cvf0 MAOVAdapter.jar oracle/dk/maov/*.class
Den samlede pakke skal derefter uploades til Portal-to-Go, som ikke lå på den samme maskine som MAOV blev udviklet på. Til det blev brugt programmet "Portal-to-Go Service Designer", der er en grafisk applikation, og er en del af klient-siden af Portal-to-Go. I det finder man MAOVAdapteren og vælger "import" for at importere den nye version af MAOVAdapteren til systemet.
Portal-to-Go har en cache med de sider den skal vise. Det betyder at efter man har uploadet sin opdaterede MAOVAdapter, kan man få gamle sider, når man tester den. Man skal derfor tømme Portal-to-Go's cache når man har uploadet den ny version. Portal-to-Go har et web-baseret kontrol-interface hvor man kan gøre netop det, ved at trykke på "zap all".
http://stdemo.dk.oracle.com:8090/?req=objects
Vær opmærksom på at din browser også har en cache med gamle sider, og du risikerer at når du trykker "zap all", vises bare en side fra din lokale cache, hvilket betyder at Portal-to-Go's cache ikke bliver tømt alligevel. Du skal derfor trykke på refresh på din browser, for at sikre at du kalder selve "zap all"-siden og Portal-to-Go's cache bliver tømt.
Den nemmeste måde at teste om systemet virker er med det simple web-baserede interface på adressen:
http://stdemo.dk.oracle.com/ptg/rmhttp://stdemo.dk.oracle.com/papz/login.jsp
Her kommer en række generelle beskrivelse af hvordan det oprindelige MAOV-udviklerhold ville have foretaget nogle ændringer vi forestiller os kunne være nødvendige.
Tilføj en ny funktion. Hver funktion har to klasser. En der bygger XML-dokumentet op, og en det henter data fra databasen. Den nye funktion bør få sine egne klasser. Det er nemmest at kopiere et sæt hvis funktionalitet minder om den nye, og så tilretter dem. Der skal desuden ændres i MAOVAdapter-klassen, så den kan kalde den nye funktion. Desuden skal den sættes ind som menu-punkt et passende sted, eller oprettes som et nyt "alias" i service designeren til MAOVAdapteren med de ACTION- og SUBACTION-argumenter der kalder den nye funktion.
Ændre måden data præsenteres. Hvis det er de samme data som bare skal vises lidt anderledes, bør det være nok at ændre i den klasse der genererer siden. De forskellige data hentes fra data-objekterne med get-metoder, og de kan hentes i vilkårlig rækkefølge.
Tilføj yderligere information til en funktion. De nye data skal hentes fra databasen, så den tilhørende data-klasse skal ændres. SQL-forespørgslen ændres, der skal oprettes nye instansvariabler til de nye informationer. Den nye værdi skal trækkes med ud fra ResultSet'et over i Vector'en, og der hvor vectorens værdier flyttes ud i arrays, skal der tilrettes, så de rigtige værdier kommer i de rigtige variabler. Endelig skal der oprettes get-metoder til de nye data. For at få de nye data vist, skal der også ændres i den klasse der genererer siden med oplysningerne.
Vise om en kunde har licenser før brugeren trykker på licenser Når man har fundet en kunde og kan vælge Licenser, Aktiviteter, TAR og Kontakter ville det være rart at kunne se om de var tomme inden man trykker på dem, eksempelvis markeret med en lille stjerne (*). Det er ikke umuligt at lave denne ændring, men det kræver en omstrukturering af systemet. De informationer er nemlig ikke hentet før der er trykket på dem. De skulle så hentes frem allerede når man finder kunden, hvilket ville give længere ventetid, før kundeoplysningerne kan vises første gang. Det objekt der genererer menu-siden (FindCustomer) har heller ikke fat i de fire data-objekter. De skulle så oprettes deri, og kunne videre-gives til de objekter der skal generere de undeliggende sider. Det er ikke holdbart at hente oplysningerne op fra databasen to gange, men det kunne være en umiddelbart nemmere løsning.
Data flyttes til nye databaser. Hvis det er muligt at hente de samme oplysninger frem, vil det kun være de berørte data-klasser der skal ændres. Hele datahentningen som primært forgår i constructorerne, bør ses efter i sømmene. Det formodes at der stadig er adgang til dem fra MAOVs egen database.
Tilføj nye mulige action-points Dette kræver ikke at koden recompiles. Der skal blot tilføjes de nye actionpoints i "actionPoint" tabellen i MAOVs egen database, hvor de står.
Tilføj ny bruger Brugerne styres af Portal-to-Go, som har en brugervenlig brugerflade til opsætning af brugere. Det er yderligere beskrevet i bilag XXX side XXX.