Velkommen til DV2-2000 http://home.eunet.no/~geirov

Hvem er vi? Asgeir Ryen 25 Er fra Heddal. Geir Øverby 27 Utannet Sivilingeniør innen næringsmiddelteknikk ved Landbrukshøyskolen i Ås. Geir Øverby 27 Er fra Fredrikstad. Utdannet høyskoleingeniør innen optometri ved høyskolen i Buskerud/Kongsberg. Ivana Kvam 24 Er fra Rokycany i Tsjekkia. Utannet Sivilingeniør innen organiskteknologi ved universiteteti Paha. Jørn Tharaldsen 25 Er fra Kongsberg. Utannet høyskoleingeniør innen elektronikk ved høyskolen i Buskerud/Kongsberg Torgeir Usland 24 Er fra Kongsberg. Utannet høyskoleingeniør innen flyteknikk ved høgskolen i Agder/Grimstad. http://home.eunet.no/~geirov

Ansvars områder Prosjektleder Web Økonomi Asgeir Ryen Implementasjon Geir Øverby Prosjektleder Web Økonomi Ivana Kvam Dokument Grensesnitt Presentasjon Jørn Tharaldsen Test Torgeir Usland Design http://home.eunet.no/~geirov

Agenda • Oppsummering • Salg • Teknisk • Introduksjon http://home.eunet.no/~geirov

eZ systems as Nystartet mai 1999 9 annsatte Kontorer i Produkter Skien Kongsberg Oslo Produkter eZ time eZ trade eZ publish eZ pattern http://home.eunet.no/~geirov

Prosjekt íde http://home.eunet.no/~geirov

Teknisk del Design Eksempel Databasemodell Implementasjon Prosjektplan http://home.eunet.no/~geirov

Design Hva er et modul? UML tilpassning http://home.eunet.no/~geirov <<Boundary Module>> UI_Opprett bruker Etternavn Fornavn Brukernavn Passord Bekreft passord Administrative rettigheter (ja/nei) OK knapp() Avbryt knapp() http://home.eunet.no/~geirov

Design Lagsmodell Lag 1 Lag 2 Lag 3 http://home.eunet.no/~geirov User Interface Pakke Lag 1 User Interface moduler Business Object Pakke Lag 2 Kontroll moduler Database Pakke Lag 3 Entitet moduler http://home.eunet.no/~geirov

Design Moduldiagram http://home.eunet.no/~geirov

Design Fysisk arkitektur http://home.eunet.no/~geirov Apache Server Terminal Intranett Internett Bruker Administrator http://home.eunet.no/~geirov

Design Komponent http://home.eunet.no/~geirov Sporbarhets figur     Komponent UI_opprett_bruker.php3 <<file>> Sporbarhets figur User Interface Pakke User Interface Pakke <<trace>> Implementasjons komponenter Design moduler Business Object Pakke Business Object Pakke <<trace>> Implementasjons komponenter Design moduler Database Pakke Database Pakke <<trace>> Design moduler Implementasjons komponenter http://home.eunet.no/~geirov

UML Hvert arbeidsområde er assosiert med en eller flere modeller Krav Use Case Model Krav Analysis Model Analyse Design Model Depl. Model Design Impl. Model Ja, Da har jeg tenkt å si litt om UML, og måten vi har brukt det på i prosjektet. I Unified Process er det fem kjerne arbeidsområder(arbeidsflyt). Arbeidet med disse fører frem til ulike modeller som beskriver systemet sett fra aktuellt arbeidsområde. Jeg har nå tenkt til å vise hvordan en use-case utvikles gjennom de forskjellige arbeidsområdene. (bytt skjerm) Implementasjon Test Model Test Hvert arbeidsområde er assosiert med en eller flere modeller http://home.eunet.no/~geirov

Use-case modellen http://home.eunet.no/~geirov 1.1 Opprett bruker Administrator Scenario: Administrator ønsker å legge til en ny bruker av systemet. Han/hun velger opsjonen ”Opprett bruker”. Administrator taster inn et nytt brukernavn og et passord. Systemet sjekker om brukernavnet er ledig, og at passordet er gyldig etter bestemte regler. Dersom nevnte kriterier er oppfyllt blir en ny bruker opprettet.   Krav nr. Overordnet krav Opphav/Kilde Prioritet Dato 1.1 Administrator skal kunne opprette nye brukere til systemet eZ Systems DV2-2000 A 07.02.2000 For å kartlegge systemets funksjonalitet benyttes use-case modellen. Da vil kravene til systemet enklere kunne fanges. En use-case er en oppgave en aktør ønsker å få utført ved hjelp av systemet, eller en oppgave systemet ønsker å få utført av en aktør. En aktør er en ekstern enhet som kommuniserer med systemet (HW/SW). I vårt system har vi to typer aktører: Brukere: De som benytter systemet til å registerere nye oppføringer Administrator: Administrasjon av brukerne (dvs opprette nye brukere, slette brukere) (scenario inn på skjerm) En use- case har gjerne et tekstlig scenario som beskriver situasjonen. (krav inn på skjerm) Utifra denne use-case’n kommer da følgende krav til systemet Ved å benytte seg av use-case’r har vi en modell som både brukere, kunder og utviklere lett kan forstå. http://home.eunet.no/~geirov

Analyse modellen Kollaborasjonsdiagrammer Sekvensdiagrammer Use-case modell Analyse modell 1.1 Opprett bruker   ”trace” Bruker DB Opprett bruker modul Opprett kunde Entitets klasse Kontroll klasse Grensesnittts klasse Brukerkontroll UI Så går vi over til analyse modellen. Som vi ser er denne sporbar fra use-case modellen. Det er dette som menes med at Unified Process er use-case drevet. Det vil si at alle modeller som opprettes kan spores tilbake til use-case modellen. Analyse modellen består av analyseklasser. Analyse klassene som blir opprettet her tar del i en use-case realisering av use-case’n Opprett bruker. Analyseklassene består av tre standard klasse stereotyper: Grensesnittsklassene – Blir brukt til å modellere interaksjoner mellom systemet og aktørene. Interaksjonen består ofte i å sende og motta informasjon. Kontroll klassene - representerer koordinering, transaksjoner og kontroll av andre objekter. De modellerer systemets dynamikk, og er ofte relatert til en enkelt use-case. Entitets klasser blir brukt for å modellere informasjon som ”lever lenge”, ofte er varig og tilhørende oppførsel. Vi får derved en grensesnittsklasse Brukerkontroll UI, En kontroll klasse Opprett bruker modul, og en entitetsklasse Bruker DB. Kollaborasjonsdiagrammer Sekvensdiagrammer http://home.eunet.no/~geirov

Kollaborasjonsdiagram Analyse modellen Kollaborasjonsdiagram 1:Ber om ny bruker 4:Opprett ny bruker 3:Send informasjon 2:Tast inn nødvendig informasjon   Administrator Bruker kontroll UI Opprett bruker modul Bruker DB Beskrivelse: Administrator ber i brukerkontroll UI om å opprette en ny bruker (1). Han/hun taster inn den nødvendige informasjonen (2), og spør Opprett bruker modulen (3) om ny bruker kan opprettes. Opprett bruker modulen oppretter så en bruker i bruker DB (4). Ved å sette analyseklassene sammen i et kollaborasjonsdiagram får vi en use-case realisering Diagrammet viser hvordan fokus flytter seg fra objekt til objekt etterhvert som use-case’n blir utført. Fokus flyttes vha beskjeder som sendes, og trigger dermed objektet som mottar beskjeden slik at dette utfører sin oppgave. Ofte vil kollaborasjonsdiagrammet bli fulgt av en ledsagende tekst. http://home.eunet.no/~geirov

Design modellen Use-case modell Analyse modell Design modell   1.1 Opprett bruker Use-case modell Analyse modell ”trace” Design modell Analyse modell Brukerkontroll UI Opprett bruker modul Bruker DB Design modell Design modellen uledes primært fra analysemodellen. Som dere ser av figuren øverst er sporbarhet til use-case modellen også tatt vare på her. Her opprettes det designmoduler utledet fra analysemodulene. Som vi ser er analyse modulen Brukerkontroll, delt opp i to forskjellige skjermbilder. <<Boundary Module>> <<Boundary Module>> UI_Opprett bruker <<Controll Module>> UI_Brukerkontroll <<Entity Module>> Etternavn 1.1.Opprett ny bruker Navn DB_Bruker Fornavn Brukernavn (from Logical View) Brukernavn Brukernavn Administrator_Ja/Nei Passord Etternavn Bekreft passord Fornavn Administrative rettigheter (ja/nei) Opprett bruker() Passord Slett bruker() Sjekkboks() OK knapp() Avbryt knapp() http://home.eunet.no/~geirov

Design modellen http://home.eunet.no/~geirov : Administrator : UI_Kundekontroll : UI_Brukerkontroll : DB_Bruker : 1.3.Vis brukere : 1.1.Opprett bruker : UI_Opprett 1: Velg brukerkontroll 6: Velg opprett bruker 8: Tast inn data 2: Utfør 7: Vis 4: Hent 5: Vis 3: Utfør 9: Send 10: Utfør Som i analyse modellen må interaksjonene mellom klassenene spesifiseres. Dette gjøres primært vha sekvensdiagrammer. Men dette kan også gjøres vha kollaborasjonsdiagrammer. http://home.eunet.no/~geirov

Design modellen http://home.eunet.no/~geirov UI_Kundekontr : UI_Brukerkontroll : UI_Opprett bruker : 1.3.Vis : 1.1.Opprett bruker : DB_Bruker : Administrator brukere Velg brukerkontroll Utfør Utfør Hent Vis Velg opprett bruker Som i analyse modellen må interaksjonene mellom klassenene spesifiseres. Dette gjøres primært vha sekvensdiagrammer. Men dette kan også gjøres vha kollaborasjonsdiagrammer. Vis Tast inn data Send Utfør http://home.eunet.no/~geirov

Implementasjon Design Modell Implementasjon Modell <<trace>> <<file>> UI_opprett_bruker. php3 <<Boundary Module>> <<trace>> UI_Opprett bruker <<file>> bruker_link.php3 <<trace>> <<file>> verifiser.php3 <<trace>> <<trace>> I implementasjonen var hovedoppgaven å identifisere hvilke filer som skulle utføre hvilke oppgaver. Eller sagt på en annen måte hvilke komponenter skulle utføre oppgavene til de uilike design modulene. Som vi ser av figuren kan en modul bestå av flere komponenter, og en komponent kan utføre oppgaver for flere moduler. <<Controll Module>> <<file>> 1.1.Opprett bruker opprett_ bruker.php3 http://home.eunet.no/~geirov

Testmodellen X Use-case modell Test-case modell     Testmodellen Use-case modell Test-case modell 1.1 Opprett bruker ”trace” X Opprett bruker Test Nr. Krav Opphav/Kilde Prioritet Dato 1.1 Administrator skal kunne opprette nye brukere til systemet eZ Systems DV2-2000 A 07.02.2000 Forutsetninger : Testbeskrivelse: 1) Logg på systemet som administrator 2) Velg å legge til en bruker 3) Legg inn en bruker   Oppfyllt : Dersom ny bruker ble opprettet. Sjekkes ved å prøve å logge på som aktuell bruker, evt ved å generere liste over brukere av systemet. Ved å utvikle test-case’r fra use-case modellen får man sjekket at alle krav til systemet er oppfyllt. Dette er jo tross alt det viktigste sett fra kundens synspunkt. Vi får da test med tilhørende testbeskrivelse, og hva som skal til for at kravet er oppfyllt. http://home.eunet.no/~geirov

Database Informasjon om kunder Informasjon om kontaktpersoner Informasjon om brukere I analyse fasen ble databasen påtenkt. Vi måtte ha lagrings mulighet for kunder, kontaktpersoner, og en oversikt over hvilke brukere som skulle få aksess til databasen. http://home.eunet.no/~geirov

Database Etter noen iterasjoner så kunde databasen slik ut:     Database   Etter noen iterasjoner så kunde databasen slik ut: Etter å ha arbeidet en stund med å finne eksakt hva som skulle lagres i systemet så datamodellen slik ut. Dette er et utsnitt som mangler entiter(eller tabeller) for e-post og telefonnr. Diise er implementert på samme måte som vi ser for adresser. Dette er et utsnitt av den komplette datamodellen for systemet. Det samme mønsteret gjentar seg for telefonnr og e-post adresser. http://home.eunet.no/~geirov

Test Inkrementell teststrategi A A A B T1 B B T2 T3 C C D Test 1 Så skal jeg si noen ord om testing. Vi har valgt en inkrementell teststrategi. Dette er en strategi som går ut på å teste modulene etterhvert som de blir utviklet, for så å sette de inn i systemet, og teste dette. På denne måten vil feil i modulene oppdages tidlig, og ved feil i systemtest er sannsynligheten stor for at det var en feil på den siste modulen som ble satt inn i systemet. Før man introduserer en modul for systemet, må den ha gjennomgått en modultest. Denne skal sørge for at alle moduler oppfyller ønsket funksjonalitet. Dette er en såkallt white box test der det vil bli gitt en del regler for hva som skal testes. Testen vil utføres av den som har utviklet modulen. Vi vil også benytte oss av Kodegjennomlesing. Dvs at Koden gjennomleses av en annen person en den som har utviklet den for å avdekke feil, og for å påse at kodestandard er fulgt. Her vil det bli utarbeidet endel regler for hva som skal sjekkes. D http://home.eunet.no/~geirov

MySQL Relasjons database SQL Utviklet i Sverige ”Liten” database http://home.eunet.no/~geirov

Hvorfor MySQL ? Hastighet Enkel å bruke Kostnad http://home.eunet.no/~geirov

PHP3 Php Hypertext Preprocessor Scriptspråk for utvikling av dynamiske websider Integrert i HTML Åpen standard Eksekvering på server siden http://home.eunet.no/~geirov

Hvorfor PHP ? Plattform uavhengig Åpen standard Server-side eksekvering Likhetstrekk med C http://home.eunet.no/~geirov

Virkemåte <HTML> <? $dato=date(d,m); $aar=date(Y); Echo ” I dag er det ”.$dato.” i år ”.$aar ; ?> </HTML> <HTML> I dag er det 29-05 i år 2000 </HTML> I dag er det 29-05 i år 2000 http://home.eunet.no/~geirov

Utviklingsverktøy Egen server: Tux Kode: Teksteditor på Tux Dokument: Word http://home.eunet.no/~geirov

Hva skjer ? PHP Web side script i Apache netleser PHP database server MySQL database server Bruker klikker på en link i nettleser sin, nettleser sender en forespørsel til en internetadresse med etternavnet php3. 2. Apache får forespørsel . Denne vet, at php3 filer blir behandlet av PHP processoren, og gir beskjed til PHP processoren som ta seg av dette. 3. PHP script inneholder forskjellige kommandoer. ( For exampel å etablere kommunikasjonkanal til database og hente data. 4.Dataene kommer tilbake fra databasen, og PHP script formaterer disse dataene. 5. HTML koden kommer tilbake til apache. 6. Apache sender HTML koden tilbake til brukerns nettleser . Bruker ser nå on web-side Informasjon fra database. http://home.eunet.no/~geirov

Prosjektplan Unified Process Definering av de største utfordingene Parallellitet = samarbeid mellom aktiviteter Revisjoner  oppdatering av f.eks krav Kritiske aktiviteter ble satt i gang på et tidlig tidspunkt. F,eks kodespråk som prosjekgruppen var ukjent med. Parallelitet. Samarbeid mellom aktiviter, f.eks design og implemenetasjon. Fikk en aktiv dialog melom de foskjellige aktivitene som medførte at prosjektmedlemmene viste hva som foregikk rundt dem. 3. Hvis man f,eks identifiserte en use case/et krav i designen som ikke var nevnt i kravspesifikasjonen, så kunne prosjektgruppen gå tilbake til kravspesifikasjonen pg legge til dette som et nytt krav. All dokumentasjon var derfor til en hver tid korrekt. http://home.eunet.no/~geirov

Spørsmål ? http://home.eunet.no/~geirov