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

Presentasjon om: "Velkommen til DV2-2000 http://home.eunet.no/~geirov."— Utskrift av presentasjonen:

1 Velkommen til DV2-2000

2 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.

3 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

4 Agenda • Oppsummering • Salg • Teknisk • Introduksjon

5 eZ systems as Nystartet mai 1999 9 annsatte Kontorer i Produkter
Skien Kongsberg Oslo Produkter eZ time eZ trade eZ publish eZ pattern

6 Prosjekt íde

7 Teknisk del Design Eksempel Databasemodell Implementasjon Prosjektplan

8 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()

9 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

10 Design Moduldiagram

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

12 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

13 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

14 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 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å.

15 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

16 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.

17 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()

18 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.

19 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

20 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

21 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 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.

22 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.

23 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.

24 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

25 MySQL Relasjons database SQL Utviklet i Sverige ”Liten” database

26 Hvorfor MySQL ? Hastighet Enkel å bruke Kostnad

27 PHP3 Php Hypertext Preprocessor
Scriptspråk for utvikling av dynamiske websider Integrert i HTML Åpen standard Eksekvering på server siden

28 Hvorfor PHP ? Plattform uavhengig Åpen standard
Server-side eksekvering Likhetstrekk med C

29 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 i år 2000 </HTML> I dag er det i år 2000

30 Utviklingsverktøy Egen server: Tux Kode: Teksteditor på Tux
Dokument: Word

31 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.

32 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.

33 Spørsmål ?