Java EE - fra vugge til grav

Presentasjon om: "Java EE - fra vugge til grav"— Utskrift av presentasjonen:

1 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

2 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

3 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?

4 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…

5 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

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

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

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

9 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

10 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

11 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…

12 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

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

14 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

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

16 Standardisering

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

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

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

20 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

21 Teknikker Tidlig test Testdekning Patterns – jf MDA
Visualisering, prototyper

22 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

23 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

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

25 Verktøy + konfigstyring + multiplattform

26 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”

27 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

28 Ytelsesanalyse Profilering - ytelse - minneforbruk - trestruktur

29 Kodelesing

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

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

32 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

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

34 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

35 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, …

36 [OPPSUMMERING]