2 TIMER BATCH JONAS OG TERJE

Transkript

1 ACCENTURE FBU Jonas og Jonas og Jonas,, Dennis, 2 TIMER BATCH JONAS OG TERJE Møte om temaet Batch: Vi gikk raskt igjennom våre tanker om Batch og fikk tips om hva vi bør fortsette å lese om for å få en god forståelse av temaet. Vi gikk igjennom Batch teori: - Gjennomgang av presentasjonene vi fikk over mail - Teorier om hvilke parametre som er viktige ved Batch prosessering: * Monitorering * Overvåking * Scheduling * Feilovervåking Vi brukte også noe tid på å lufte våre( og Dennis ) tanker om Batch. Oppgaver for neste møte: Vi fikk i oppgave å finne gode kilder( eks fra internett, bibliotek, eller bestilling av bøker om Batch, hovedoppgaver ) som vi kan bruke for å få en forståelse av Batch temaet fra pålitelige kilder. Vi skal også fortsatt gjøre research på Batch, for å forberdre vår teoretiske forståelse av Batch og viktige parametre som inngår i temaet. Neste møte ble satt til den 20.01, kl Finne kilder og gjøre research på generell forståelse av Batch Dennis Finne kilder og gjøre research på generell forståelse av Batch

2 Batch ACCENTURE FBU, Dennis, 2 TIMER BATCH SYSTEM FORSTÅELSE OG ANALYSE TERJE Dennis har sendt ett forslag for en Batch standard( ANSI/ISA ), der ville at vi skulle tenke over hvordan/hvorfor vi eventuelt skal bruke denne eller andre standarder, og eventuelt redigere en egen standard. Vi diskuterte om hva som er relevant, generell kunnskap om Batch. Vi diskuterte litt om hovedmålet: Finne rammeverk som kan brukes igjen slik at apllikasjoner er kompatible( ikke for strekt knyttet mot bestemt type applikasjon ). var interessert i at vi snart begynta å lage en tidsplan for prosesser/faser i prosjektet.( Analyse-fase, Design-fase, Test-fase, osv ) Vi skal skrive en analyse av Batch-systemet helt enkelt og generell som en introduksjon, og deretter beskrive om forskjellige typer situasjoner som er rellevante ved forskjellige Batch-prosseser.( for eksempel feilhåndtering ). Vi skal lage ett utkast som vi sender til og Jonas, slik at de kan veilede og rette på vårt utkast. Vi skal begynne med det grunnleggende og utvide analysen over tid. Vi( Dennis og ) har også begynt å ta i bruk Office Live Workspace for å dele/redigere filer, referater og notater mellom oss og våre veiledere. Skrive generell analyse av Batch-systemet Dennis Før Skrive generell analyse av Batch-systemet Før o9

3 Forprosjekt DATAROM 4 ETG, HØGSKOLEN I OSLO Dennis og Gjennomgang av foreløpig status/arbeid med Forprosjekt Dennis og Dennis og 3 TIMER ARBEID MED FORPROSJEKT [FOREDRAGSHOLDER] Vi gikk igjennom hva som skulle leveres til forprosjektet. Vi jobbet med rapporten og kom til diskuterte hva som burde tas med i rapporten. Vi la også planer for hvordan vi skulle dokumentere Forprosjektet. Vi kikket også raskt over bøkene som har kommet fra biblioteket. Vi diskuterte litt rundt gangen i prosjektet og forståelsen. Dennis hadde laget en god mal for innleg av våre innlegg i Prosjektdagboken, og lagt inn flere poster. Prosjektdagboken har vært tidligere lagret som en vanlig tekst-fil. Vi var enige at boken Predictable Scheduling Algorithms and Applications så spesielt relevant ut for vårt videre arbeid med prosjektet. Vi trenger å lage/levere en Forprosjekt-rapport, en Fremdriftsplan( med milepæler ) og en Arbeidsplan( beskrivelse av postene i Fremdriftsplanen. Vi trenger også å ha med en kontrakt til vårt neste veiledermøte på Accenture Dennis laget Fremdrifstplanen ferdig som en Gant-Skjema. jobbet videre med Fremdriftsplanen( Word dokument ), og fikk hjelp av Dennis underveis. laget en rask mal for Arbeidsplanen( i Exel ). Legg inn flere poster i den nye Prosjektdagboken. Gjøre ferdig Forprosjektrapporten. Legge inn flere poster i den nye Prosjektdagboken. Gjøre ferdig Arbeidsplanen Dennis

4 Veiledning ACCENTURE FBU Heen Heen, Dennis, 3 TIMER VEILEDNING OG FORSTÅELSE AV OPPGAVE Vi diskuterte den veiledende mailen som vi fikk, og mye generelt om forståelsen av helheten i oppgaven. Mesteparten av tiden gikk med til å finne en felles og mer konkret forståelse av målet med oppgaven. Vi diskuterte særlig flertrådsapplikasjoner, og hvordan vi skal definere det i vår analyse av Batchsystemer. Definisjonen av oppgaven var vi enige om at var litt vag i begynnelsen. var enig i det. Men vi synes at den veiledende mailen vi fikk ga en mye mer konkret og enkel forståelse av helheten av våre mål med oppgaven. Vi skal benytte oss av helt enkle konseptuelle diagram når vi analyserer batchprosessser, de skal bare ta for seg en problemstilling/løsning av gangen. Vi gikk igjennom eksempler på prosessering av feilhåndteringer feil-prosessering, samt concurrency. Om prosjektet fram i tid: Vi kom fram til at de fleste utviklingsmiljøene vi skal teste når vi kommer til den fasen, er fastsatt( slik som Hibernate ), med mindre vi får tid til å teste andre løsninger. Vi skal spørre Jonas om hvor relevant det er at applikasjonen som skal testes er meldingsbasert, og mer om hva det innebærer. Lage overordnet struktur på sluttrapporten, Skrive videre på dokument om analyse av Batch-systemer Lage overordnet struktur på sluttrapporten, Skrive videre på dokument om analyse av Batch-systemer. Dennis

5 KL. 12 HØYSKOLEN I OSLO, P35 Siri Fagernes Siri Fagernes Dennis Siri Fagernes, veileder fra skolen (13: ) fra Accenture (14:00-15:00) Dennis 3 TIMER FØRSTE MØTE MED SKOLENS VEILEDER, SIRI FAGERNES 1. Koordinere arbeidet så langt ( og Dennis fra 12 til 13) 2. Møte med veileder fra skolen og fra Accenture Dokumentasjon Hvordan skal dokumentasjonen løses (1 eller 2 rapporter?) Hva slags standard skal vi følge for dokumenteringen. Vi (A, D) føler at vår oppgave ikke kan dokumenteres helt etter standarden skolen benytter Startvansker Oppgaveteksten er noe mangelful, misvisende Vi arbeider veldig abstrakt (frem til nå i alle fall), og har i hovedsak skullet utforske fagfeltet så langt Oppklaringsmail som belyser noen av oppgavens uklare aspekter kom fra Accenture rett før deadline for forprosjektlrapporten Vi fikk ikke veileder før forprosjektrapporten 2.3. Hvilken rolle har skolens veileder? KONKLUSJON 1. Arbeid med å koordinere arbeidsinnsatsen vår: 1.1. Opprettet et felles hoveddokument for rapporten. Vi skal benytte dette sammen og på egenhånd. Man må passe på at vi lager ny versjon når vi har gjort endringer på egenhånd eller når det gjøres store endringer. Når endringer gjøres på egenhånd skal nytt versjonsnummer ende på en A (), eller D(Dennis) Satte opp et rammeverkt for hoveddokumentet med inndeling i kapitler og innholdsfortegnelse 1.3. Lagde diagrammer til sin tekst. 2. Møte med veiledere 2.1. Dokumentasjon Dokumentasjonen kan vi ha i ett dokument i følge skolens veileder (Siri). Dette betyt at vi leverer det samme rapport-dokumentet til skolen som til Accenture Det er ikke kritisk at vi følger skolens dokumentasjonsstandard. Det kan faktisk skape problemer for oss hvis vi ikke benytter sunn fornuft og endrer standarden der det er hensiktsmessig. Dette er fordi standarden er rettet mot utviklingsprosjekter og de leveranser man hanskes med der. Den passer dårlig til en konseptuell analyse, slik som den vi utfører Hva kan skolens veileder hjelpe oss med Vi kan benytte Siri til å hjelpe oss med dokumentasjonens form, og til å vurdere arbeidsprosessen. Hun kan ta kontakt med oppdragsgiver hvis vi ønsker dette, men vil normalt sett ikke gjøre dette Hun vurderer ikke arbeidet vi utfører, og har ingenting med karakter å gjøre Hun forteller at vår oppgave minner mer om en Master i omfang, enn en Bachelor oppgave fortalte litt om hva de ønsker å oppnå Sette opp en test på gjennomførbarheten (utviklingen) av batchsystemer basert på POJO er og Springbatch sammen med Hibernate Finne problemområder De ønsker å finne ut om dette er en metodikk som kan passe til dem og deres kunder.

6 [DATO] [TIDSPUNKT] ACCENTURE FBU Jonas Jonas og Dennis 2 TIMER GJENNOMGANG AV BATCHBESKRIVELSEN, INNFØRING I BRUK AV UTVIKLINGSIMAGE Arbeid gjort sålangt med dokumenteringsdelen. Hva må endres/legges til i dokumentet Programmeringsmiljøet på image (Eclipse) JONAS Vi trenger del om mutual exclusions og dead-lock Endringer av delen om effektivisering og concurrency: Dette kan være en flaskehals siden alle trådene til slutt samles til en tråd (flaskehals) Delen om prioritering kan utelates inntil videre Delen om feilhåndtering og loggføring beskrives som tekstforklaring til enkel modell (scheduler, transaksjon, db) Vi kan begynne med utviklingen o o Benytte eksisterende database/hibernate oppsett Bruke quantum til å opprette tabeller bli kjent med tabeller og database implementasjonen t_student_karakter legger vi inn manuelt med random karakter t_student_diplom legges inn av batchjobb Sette oss inn i Hibernate, se også litt på Junit Benytte tekstfil for endringslogg til programmeringsprosessen (java, sql) Endre feil navn på transaksjon. Ordne sin egen tekst (partisjonering/scheduler/feilhåndtering/trans.) Ordne diagrammer Dennis Lage diagram om deadlock og skrive litt om det. (senere vil vi undersøke hvordan dette håndteres i springbatch) Skrive kort om flaskehalser i concurrency sammenheng med diagram

7 [TIDSPUNKT] HØGSKOLEN I OSLO, Dennis, 1 TIME [EMNE PÅ DAGSORDENEN] [FOREDRAGSHOLDER] Gjennomgang av implementering av transaksjoner ved bruk av Hibernate i Poc-et. Vi gikk igjennom vår hovedoppgave for tiden som er å lage transaksjoner i Hibernate(for å så bruke Spring Batch senere), som legger til og oppdaterer elementer i databasen. Fikk god starthjelp for forståelse av angående Exceptions( try, catch ), som er mye brukt av Hibernate. foreslo at vi skulle prøve å lage en ekstern pakke med en Java-klasse, som skal kunne kjøres flere runder med Quartz. Dennis

8 [TIDSPUNKT] HØGSKOLEN I OSLO, Dennis, 4 TIMER IMPLEMENTERING AV POC TERJE Sette en struktur med standardisert navngiving på prosjekter i Poc et.. Lage funksjon som henter data fra transaksjoner som holder styr på antall rader/og innholdt lagt til.( kan senere brukes til å lagre rollbackpunkter.

9 :00 HØGSKOLEN I OSLO, Dennis [AVSATT TID] HIBERNATESCENARIO, POC-OPSETT TERJE I forkant av møtet ble vi kjent med ett forslag til hovedoppsett for Hibernate som Dennis har jobbet med. hjalp oss med bedre forståelse av Subversion for å holde styr på filer i POC et. Vi satt opp hele POC et i Subversion slik at hele prosjektene i POC et kan kjøres av både oss og veiledere til en hver tid. Viktig at koden som oppdateres til Subversion er feilfri slik at prosjektene kan kjøres. Vi ryddet opp i POC et som nå er temmelig større, ved å fjerne overflødige prosjeker. Alle prosjektene som manglet, er blitt implementert med Maven slik at våre veiledere kan lett bygge en versjon av POC et, selv med de dependices(avhengigheter) som følger med. Vi satt opp ett interface for standarisert hoved-klasse i Hibernate. Fikk tips om å sende en nullpointerexception for å provosere feil for testing av rollback(). Linke Quartz med Hibernate s hoved-klasse,implementere opptelling av triggers kjørt i Quartz for bruk i Hibernatescenario Jobbe videre med standard opsett av HibernateScenario Dennis

10 HØGSKOLEN I OSLO, Jonas, Jonas, Dennis, 3 TIMER [EMNE PÅ DAGSORDENEN] [FOREDRAGSHOLDER] Vi kom med forklaring til våre veiledere om at det ikke er realistisk å få tid til implementere Spring Batch som tidligere tenkt, da det er kun kort tid igjen, og tid trengs til ut utarbeide rapporten. Oppgaven med å sett opp Hibernate har vært temmelig stor. Og våre veiledere har ingen erfaring med å sette opp Spring Batch slik at de kunne hjulpet oss med det. Våre veiledere foreslo at vi kun gjør ferdig vårt oppsett av Batch-styring med Hibernate, med de aktuelle funksjoner. Vi fikk en ny metode/sammensetning av logikk som vi skulle sette opp: En inndeling som består av Quartz, Batchsystem logikk og Persistens. Som en analyse skal vi da bevise/forklare hva som er gjennomførbart i standalone logikken som vi nå skal gjennomføre. Prosjektet dreier seg fortsatt om gjennomførbarheten i ett standalone rammeverk, men uten noe konkret system å sammeligne med.

11 HØGSKOLEN I OSLO Siri Siri Fagernes Siri, Dennis, 2 TIMER DISPONERING AV DEN SISTE SIRI MÅNEDEN/RAPPORTSKRIVING Vi diskuterte de siste dager av hovedprosjektet(4 uker igjen). Vi trenger nok minst 2 uker der all implementering er ferdig for å kunne jobbe videre med rapporten. Ett problem kan være å få tid til å implementere to løsninger som skal testes(vårt hibernate system) og ett system som innefatter Hibernate. Vi spør og Jonas fra Accenture(mail) om det kan være noe standard system eller sammenligninger som vi kan sammenligne vårt Hibernate-baserte system med for å kunne få tid til å gjennomføre en meningsfull analyse/testing, og avtaler møte i starten av neste uke der vi diskuterer hva det er tid for å få til før vi må konsentrere oss kun om rapporten. Vi sendte også vårt forslag til testkriterier, for å vite om de er gode nok til å brukes til testingen. Bestemmelser for resterende tid av prosjektet: * Vi begynner med fastsatt tidsplan for hva som skal gjøres for hver dag, i tilegg til ukentlige mål. Møtene fremover skal begynne med ca 15 minutter skriving, for å komme inn i en god rutine når det gjelder dokumentering og rapportering. * Viktig å få ferdig testrutinen vår med hensikt, resultat, analyse av resultat og implementering. Vi begynner med å skrive manuelt ett utkast for hvordan testrutinen skal se ut. (Blant testresultatene bør det vurderes om hastighet er hensiktsmessig å ha med?). Bør absolutt være ferdig om 2 uker. * Viktig for rapporten er å argumentere for hvorfor vi implementerer systemet slik som vi gjør det. * Send foreløpig skriv av vår Hoveddokument til Siri så ofte som mulig for konstruktiv tilbakemelding * Tips for Hovedrapporten: Skriv forklarende for testresultatene(ikke bare statistisk). Nytt møte med Siri: kl Let etter standariserte testmetoder/skala for rammeverk med samme hensikt som vårt som vi kan sammenligne med. Let etter standariserte testmetoder/skala for rammeverk med samme hensikt som vårt, som vi kan sammenligne med. Dennis

12 :00 HIO, Dennis, [AVSATT TID] [EMNE PÅ DAGSORDENEN] [FOREDRAGSHOLDER] Logging Hva skal vi sammenligne mot? Hoveddokumentets utforming Subversion(hvis tid) Separat logikk, slik at batchsystemet kan byttes ut med Spring. Modningsprosess: Forståelse opparbeidet, som har fått målet til prosjektet endrett(glatt overgang)