Java EE - fra vugge til grav Utvikling av komplekse Java EE-systemer med fokus på livssyklus Tema: Java Life Cycle fokus på vedlikeholdbarhet, driftbarhet når konsulentene har gått hjem… Lars Reed, 15. september 2005

Sikre kvalitet og effektivitet både ved utvikling og i vedlikehold Dagens tekst Typiske utfordringer etter et utviklingsprosjekt… … og hva kan vi gjøre med det Målsetning: Sikre kvalitet og effektivitet både ved utvikling og i vedlikehold

Mangler dokumentasjon Finner ikke frem i koden Ytelsesproblemer Tilbake til hverdagen Prosjektet er over, kaken er spist – hvor er vi nå? Rare feil… Mangler dokumentasjon Finner ikke frem i koden Ytelsesproblemer Skaleringsproblemer Vanskelig å legge til nye funksjoner Vanskelig å lære opp en ny… Tenk om noe viktig slutter å virke… Krav om nye kanaler Rakk ikke å teste alt… Rakk ikke å skrive den… Mange rare påfunn… Rakk ikke å tune… Etterpåklokskap… Arkitekten har sluttet… Har ikke oversikt… Rekker ikke å teste alt på nytt Må vel begynne på nytt?

YAGNI? Tilbake til hverdagen 2 Må porte til ny Javaversjon og databasesystem og Windowsversjon og integrere det nye lønnsystemet med Web Services og få på 200 nye brukere hvorav mange på mobil og dobling i datavolum og noens oldemor. Hjeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeelp!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Det er ikke alltid lurt å være korttenkt…

80% 20% Hva er det som koster? Endring Kostnad Utvikling Vedlikehold 80% Modellering Utvikling Debugging Testing Implementering Utrulling Dokumentasjon Endring Sammenslåinger og oppkjøp Endrede internasjonale og nasjonale lover og regler Kostnad Nye produkter og tjenester Stadig utvikling mht produksjon, distribusjon, support og administrative prosesser Store app: 5 – 10 – 25 år… Bygge for endring, ikke varighet (jf. smidige metoder…) 20% Applikasjonens livssyklus Tid

Og når betaler vi for det? Initiell kostnad vs TCO Innenfor / etter prosjektet 3 små griser…

Modellen i sentrum! DRY (1=1) Modellbasert = Utgangspunkt for vellykkethet  1 ting 1 gang (jf. ”koden i sentrum”)

Klassemodell Bitteliten applikasjon – hovedvindu + vedlikeholdsvindu med tilhørende liste

MDA Object Management Group: “Model Driven Architecture” Fokus: Invester i avanserte modeller som vil vare Ikke kode- eller plattform-APIer som endrer seg årlig Modeller kan være “broen” når teknologi skal skiftes ut OMG: Etablert i 1989, konsortium på over 800 medlemmer. Standardisert rammeverk for systemutvikling OMG har lykkes med standardisering Forretningsdrevet (ikke bare teknologisk) – konseptuelt riktig – riktig vei begrepet ”forretning” Generering – nødvendig for J2EE Varighet, uavhengighet av plattform

MDA-modellen PIM Platform Independent Model (PIM) representerer forretningsfunksjonalitet, egenskaper og relasjoner uten teknologidetaljer PSM Genererer en Platform Specific Model (PSM) fra PIM modellen (J2EE, .NET, Web Services etc) Code Model Genererer kode basert på PSM modeller Skriver tilleggslogikk i “free blocks” i kildekoden Platform Independent Model Code Specific QVT QVT MDA-definisjon 3-lags + transformasjoner osv Bevegelse ”oppover” – legg ting høyest mulig QVT = Query / View / Trransformation Alle MDA utviklingsprosjekter starter med å lage en Platformuavhengig modell (PIM - forretningsmodell), uttrykt gjennom UML.   PIM – forretningsmodell Forretningsmodellen definerer forretningsregler, egenskaper og relasjoner. En bedrifts ledelse og modelleringseksperter samarbeider for å lage modellen uten å se på teknologi. Dette gir bedriftsledelsen anledning til å bestemme når forretningsreglene er ferdig og korrekt definert – slipper å forholde seg til teknologi etc. PSM – arkitektur modell Når den første iterasjonen av PIM-modellen er komplett, blir den lagret i et MOF-basert repository (Meta-Object Facility) og skaper den plattformspesifikke modellen (PSM) basert på den eller de plattformer som er valgt av bedriften (slik som J2EE, .NET, etc). PSM-modellen definerer hva som skal genereres for å kunne implementere en applikasjon. Dette gjennom å gi et logisk overblikk av komponentene innenfor hvert lag som utgjør selve applikasjonen. Kodemodell Når først PSM-modellen er skapt, er det endelige steget å generere relevant kode. Resultatet er en første versjon av en fungerende applikasjon, som kan man da videre kan forbedre gjennom MDA prosessen eller håndkoding. Det unike ved MDA, er at man klart skiller forretningsmodellen fra arkitekturmodellen og skiller arkitekturmodellen fra implementasjonsspråket. Dette gjør det enkelt å bestemme hvor man skal gjøre endringer i applikasjonen: 1.Forretningsendringer gjøres i forretningsmodellen 2.Arkitekturendringer gjøres i arkitekturmodellen 3.Kodeendringer gjøres i kodemodellen

Utviklingsløp, MDA Tradisjonell modellbasert utvikling Utvikling med MDA Forstudie/ spesifikasjon Forretnings- modell Krav System- arkitektur Analyse design Domenemodell Samarbeid Tilstand Sekvens Realisering Test Klassediagram Objektdiagram Domene- Starter likt Jobber videre med samme modell, genererer Kjent kvalitet Vedlikehold…

Arkitektur Henger sammen med prosess, standarder Få tidlig på plass Teknisk arkitektur ikke i domenemodellen Arkitekt vs bruker Arkitekt vs utvikler For DRIFT: Skalerbarhet Konfigurering Logging / lytting For ENDRINGER: Redusere avhengigheter Tjenester, lagdeling Tabelllverk etc

Designet for drift (og vedlikehold) Skalerbarhet Konfigurering Logging / lytting / feilhåndtering Dokumentasjon / oversikt Brukermedvirkning: driftspersonell Dokumentasjon sammen med bygging av arkitektur

Designet for endringer Lines of handcrafted code J2EE Pet Store using OptimalJ – 610 J2EE Pet Store – 14,273 On average the developer wrote only one to four lines of Java code manually for each 200 lines generated automatically Upgrading to EJB 2.0 [from EJB 1.1] Took less than 30 minutes to upgrade -- Electronic Data Systems validating OptimalJ Redusere avhengigheter Tjenester, lagdeling Tabellverk etc Dynamisk konfigurasjon Fleksibelt Infrastruktur / dokumentasjon

Etabler gullstandarden 1. inkrement = “System GOLD” Gjør “alt riktig” Prøv ut standarder, maler og rutiner Holdes levende “Se her”:

Standardisering

Eksempel: Dialogstandard “Kokebok” for design av brukergrensenitt. Vil variere mellom plattformer. Høynivå: Hvordan implementere typiske modellkonstellasjoner. Lavnivå: Bruk av fonter og farger

Etablere mange-mange-forhold Eksempel Etablere mange-mange-forhold

Standarder må holdes i hevd Standarder & QA Standarder må holdes i hevd QA Levende standarder “No Broken Windows” QA er mer enn JUnit

Eksempel på QA-rutiner QA på design & testmanus Intern og med brukere Programmerers test & sjekklister Automatiske tester Kodelesing Kode & tester, manuelt & automatisk Enhets- og integrasjonstest System- og -integrasjonstest Akseptanse- og produksjonstest Feil- & endringsregister Verktøy… Leveransekontroll knyttet til feil & endringer Styring av tester

Teknikker Tidlig test Testdekning Patterns – jf MDA Visualisering, prototyper

Tradisjonell prosess Definere Implementere Revidere og korrigere Overordnet applikasjons- arkitektur Plattformekspertise Standarder for teknologi og utvikling Best Practices, metodikk Patterns, maler Modeller Utviklings- team Implementere Applikasjons-arkitektur Teknologi- standarder Utviklings- retningslinjer Best practices, metodikk Patterns, maler Modeller Revidere og korrigere Arkitektur ikke korrekt implementert Teknologistandarder ignorert Avvik fra utviklings- retningslinjer Feiltolkning av Best Practices Patterns/maler ikke benyttet Modeller duplisert Arkitekter Utviklings- team Entropi… Manuell kontroll, etterarbeid

Kunnskapsflyt i MDA Platform Independent Model Platform Specific Model Definere Overordnet applikasjons- arkitektur Plattformekspertise Standarder for teknologi og utvikling Best Practices, metodikk Patterns, maler Modeller + transformasjoner Utviklings- team Platform Independent Model Arkitekter Teknologi- transformasjon Platform Specific Model Utviklings- team Kode- transformasjon Muligheter Arkitekter implementerer sin arkitektur Tilpasning Åpenhet vs 4GL Kompetanseoverføring Code Model

Driftsløp Systemleverandør Driftsleverandør Kunden Test- opplegg Vedlikeholder System Monitorering Årsak/ Analyse Tilbakemelder Driftbart!  neste…

Verktøy + konfigstyring + multiplattform

OJ PIM  Domain model PSM Application model Code model Transformation patterns Functional Technology Implementation Domain Application Service Presentation Common Dbms Business logic facade Class Code SQL Java EJB Config JSP BPM OJ MDA-definisjon 3-lags OJs implementasjon PIM: klasser & tjenester Pattern-begrepet PSM: naturlig fordelt på lag Kode: lager ”alt”

Testverktøy Utfør tester Se på dekningsgrad Test a la JUnit, men på modellobjektnivå F.eks. kall en service, hva venter du til svar Frittstående, men integrert – kan gjøre en jobb selv om etterpåklok Hvor mye er dekket av tester

Ytelsesanalyse Profilering - ytelse - minneforbruk - trestruktur

Kodelesing

Mange verktøy, mange ambisjoner Kodelesing Mange verktøy, mange ambisjoner Ymse formater Konvertering Ukens trekløver…: FindBugs, DocCheck, PMD

Dokumentasjon Integrert dok lettere å vedlikehold Kan også linke til eksterne kilder UML-diagrammer Kommentert kode JavaDoc Lese kode

Prosess / kontrakt Mer enn daily scrum Prosesser & kontrakter tilpasset denne utviklingsmodellen holde kostnad nede tilpasset hverandre mye metode i kontraktene PS2000 – RUP: tilpasset vårt behov, f.eks. mot MDA, effektivisering, livssyklus Effektivitet, læring – kompetanse (noe man kan fra før) God metode = høyere måloppnåelse, levedyktig produkt

Inkrementell og iterativ utvikling Forskjell på iterativ, inkrementell Kostnad, risiko

F.eks. Dataforeningens vedlikeholds- kontrakt Prosess vs kontrakt Kontrakt kan hemme eller understøtte prosess Må være tilpasset Både utvikling og vedlikehold / forvaltning F.eks. PS2000 F.eks. Dataforeningens vedlikeholds- kontrakt Utvikling Forvaltning

Generert kode=færre feil Automatisk test En bedre hverdag Generert kode=færre feil Automatisk test Dokumentasjon i modell og kode Kodestandarder, gullstandard, navigasjon via modellen Avslørt underveis Standarder, verktøy, maler… Mer enhetlig, finnes dok., gullstd. Automatisk regresjonstesting Verktøy, modell Rare feil… Mangler dokumentasjon Finner ikke frem i koden Ytelsesproblemer Vanskelig å legge til nye funksjoner Vanskelig å lære opp en ny… Tenk om noe viktig slutter å virke… Kanaler, versjoner, …

[OPPSUMMERING]