Objektorientert systemutvikling, litt UML og Rational Unified Process ( RUP)

1. Objektorientert systemutvikling, litt UML og Rational Unified Process (RUP) UML Distilled kap. 2 - 3 Kirsten Ribu Kirsten Ribu HiO 2005

2. I dag • Rational Unified Process • Kravspesifikasjon • Use case modellering – utbrodert • Kap 3 i UML Distilled Kirsten Ribu HiO 2005

3. Hensikten med denne delen av kurset • Å lære og øve på modelleringsteknikker • Å lære om gode designprinsipper • Sammen bidrar dette til å oppnå høy kvalitet på det ferdige produktet Kirsten Ribu HiO 2005

4. Objektorientering – hva er det? • Et objektorientert system er bygget opp av selvstyrte strukturer • Hvert objekt representerer en konkret ting (entitet) • Objektet reagerer med seg selv og med andre objekter Objekt 1 Objekt 2 Data data Kirsten Ribu HiO 2005

5. Objektets egenskaper • Innkapsling • Polymorfisme • Arv Objekt klasse Kirsten Ribu HiO 2005

6. Hva er en klasse/et objekt? • Ideen: Strukturer, klassifiseringer. • F.eks klasse ’fugl’ et konseptuelt begrep. • Felles egenskaper: Nebb, fjær, vinger etc, Kirsten Ribu HiO 2005

7. ’Best practises’ ved programvareutvikling • Iterativ utvikling • Håndtering av krav • Bruk av komponentbasert arkitektur • Visuell modellering • Kontinuerlig verifisering av programvarekvaliteten • Kontrollerte endringer i programvaren Kirsten Ribu HiO 2005

8. Kirsten Ribu HiO 2005

9. Kravspesifikasjonen • Tilhører analysefasen • Definerer funksjonelle og ikke-funksjonelle krav • Funksjonelle krav: Konkrete krav til systemet som beskriver en ønskettilstand. Enten er kravet oppfylt, eller ikke. • Eks: Vi ønsker å bestille en time i Zebra systemet, og få en tilbakemelding om at timen er bestilt. • Ikke-funksjonelle krav: Kan ofte uttrykkes i tall (prosenter, antall, tid etc.) • Eks: Ønskede (målbare) kvaliteter på systemet (svartid, feilprosent, antall samtidige brukere) Kirsten Ribu HiO 2005

10. Noen kvalitetsattributter Kirsten Ribu HiO 2005

11. Kirsten Ribu HiO 2005

12. RUP – Rational Unified Process • En systemutviklingsprosess (industristandard) som beskriver: • Hvem som gjør hva, hvordan og når • Retningslinjer • Maler og mønstre • Konsepter for overvåkning/måling av fremdrift • IBM/Rational: • http://www-306.ibm.com/software/awdtools/rup/index.html Kirsten Ribu HiO 2005

13. IBM kjøpte Rational Software • IBM Rational Unified Process®, or RUP®, is • a configurable software development process platform that delivers • proven best practices • and a configurable architecture. Kirsten Ribu HiO 2005

14. The Unified Process –En prosessmodell • Use-case dreven: Use case modellen driver utviklingsprosessen, ikke bare for krav-spesifikasjon, men også for prosjektplanlegging og definisjon av test cases • Arkitektursentrisk: Basisarkitekturen, dvs. klassestrukturen etableres før utviklingen starter. Arkitekturen forfines underveis • Iterativ og inkrementell: Kontrollert inkrementell utvikling med mange iterasjoner Kirsten Ribu HiO 2005

15. UP disipliner Kirsten Ribu HiO 2005

16. The Unified Process forts. • Prosessmodell som kombinerer best practises i software utvikling: • Iterativ livssyklus • Risikodrevet utvikling • UP består av 4 faser: • Inception – gjennoførbarhetsanalyser, tidlige estimater • Elaboration – iterativ implementering av basisarkitektur, løsning av høyrisiko faktorer, identifikasjon av mesteparten av kravene • Construction – iterativ implementering av lavrisiko-elementer og forberedelser til innføring av systemet • Transition – beta-test og innføring Kirsten Ribu HiO 2005

17. Oversikt over prosessen Idefasen: Krav, omfang, lønnsomhet Utdypning: planlegging, krav, arkitektur, risiko, prototyping Konstruksjon: konstruksjon, implementering, testing Overgangsfasen: kvalitetskontroll, brukeropplæring …………. Inception Elaboration Construction Transition Idefase Utdypning Konstruksjon Overgang Kirsten Ribu HiO 2005

18. Eksempel på faser Inception og Elaboration 1. iterasjon Analyse: • Kravanalyse: Utarbeide use case og identifisere ikke-funksjonelle krav • Utarbeide domenemodell Design: • Use case realisering: Utforme sekvensdiagrammer • Utforme designmodell Kirsten Ribu HiO 2005

19. En iterativ og inkrementell prosess • Iterativ utvikling med flere korte, tidsbestemte iterasjoner i hver fase (for eksempel 4 uker) • Hver iterasjon er et ’mini-prosjekt’ med egen kravanalyse, design-, implementering- og testaktiviteter • Resultatet av en iterasjon er et testet og kjørbart system • Systemet vokserinkrementelt - iterasjon for iterasjon - og leveres kunden i inkrementer (deler) • RUP (Rational Unified Process) brukes i dag som prosessmodell i mange bedrifter – i store prosjekter (www.rational.com) Kirsten Ribu HiO 2005

20. Inception (idéfasen) – noen aktiviteter • Gjennomførbarhetsanalyse • Prototyping for å klargjøre krav • Planleggingav 1. iterasjon • Overordnet use case utforming • Finn aktører og use cases • Beskriv funksjonelle og ikke-funksjonelle krav • Finn riktig detaljeringsnivå for beskrivelsene • Detaljer ut ca 10-20% av use casene: de mest interessante, komplekse eller risikofylte Kirsten Ribu HiO 2005

21. Elaboration (utdypningsfasen) • Analysefase på systemnivå, ikke detaljnivå • De viktigste eller mest kritiske deler av systemet utvikles inkrementelt • Alle modeller som innvirker på hele systemet lages nå: • Mesteparten av kravene blir identifisert • 80-90% av use casene blir skrevet i detalj • Sekvensdiagrammer • Klassediagram • Risikohåndtering • Mønstre (patterns) vurderes • Fasen består av flere iterasjoner • (f.eks 4) Kirsten Ribu HiO 2005

22. Construction (konstruksjonsfasen) • Består av mange iterasjoner • Hver iterasjon inneholder analyse, design, implementering og testing på detaljert nivå • Delprodukter blir ferdig dokumentert, testet og integrert • Et delprodukt realiserer ett eller flere use cases • Testing: • Enhetstesting: Gjøres av utvikleren på han/hennes delprodukt • Funksjonstest: En systemtest som involverer mange delprodukter, og gjøres av testere • Ved testing brukes use casene fra use case modellen Kirsten Ribu HiO 2005

23. Transition (overgangsfasen) • Programmering er ferdig • Endringer gjøres for optimalisering • Feilrettinger • Ferdigstilling av produktet • Forberedelse til pilotprosjekt • Brukeropplæring • Planlegging av videreutvikling (nye versjoner) Kirsten Ribu HiO 2005

24. Kirsten Ribu HiO 2005

25. Kort repetisjon av grunnleggende UML Use case modellen • Beskriver kravene til systemet • Beskriver systemet sett fra kundens perspektiv • Beskriver ’hva’ som skjer, ikke ’hvordan’ det skjer • Use case er ikke ’objekt-orienterte’, men beskrivelser av hendelsesforløp Kirsten Ribu HiO 2005

26. Ordrebehandlingssystem Kravspesifikasjon: En bedrift ønsker et online ordresystem for å kunne selge produkter fra flere forhandlere. Når kunder bestiller varer legger de inn en ordre sammen med betalingsinformasjon. Man kan legge til varer og lagre underveis for å kunne fortsette bestillingen senere. Ordre kan kanselleres etter at de er lagt inn, men før varene sendes. Kirsten Ribu HiO 2005

27. Use case modell for ’Ordrebehandlingssystem’ Kirsten Ribu HiO 2005

28. Sekvensdiagrammer: fra krav til design Et UML sekvensdiagram • viser hendelsesflyten i et use case • viser interaksjoner (samarbeid) mellom objekter i systemet • viser rekkefølgen på beskjedene som sendes mellom objektene • kan brukes til å identifisere metodene til objektene i systemet Kirsten Ribu HiO 2005

29. Use case ’Lag ordre’ Aktør: Kunde Sekundæraktør:Regnskapssystem • Systemet viser et ordreskjema med varebeskrivelser • Kunden skriver inn de ønskede varene og betalingsinformasjon • Systemet sjekker at alle felt er fylt ut og viser totalsum • Kunden bekrefter bestillingen • Systemet lagrer ordren og sender betalingsinformasjon til regnskapssystemet • Regnskapssystemet bekrefter betalingsinformasjonen • Systemet sender en ordrebekreftelse til kunden Kirsten Ribu HiO 2005

30. Sekvensdiagram for ’Lag ordre’ Kirsten Ribu HiO 2005

31. Domenemodell • Domenemodellen tilhører analysefasen og er en representasjon av objekter i domenet. • Domeneklassene gjenspeiler objekter i den virkelige verden, ikke systemkomponenter • Lages i parallell med use case modellen • Typisk informasjon om objektene: • Assosiasjoner • Attributter • Multiplisitet Kirsten Ribu HiO 2005

32. Overordnet domenemodell Kirsten Ribu HiO 2005

33. Designmodell - Design • En designmodell viser systemklasser, ikke konseptuelle klasser som i domenemodellen • Typisk informasjon er: • Klasser, assosiasjoner, attributter og navigasjon • Grensesnitt • Metoder • Avhengigheter Kirsten Ribu HiO 2005

34. Eksempel assosiasjonsnavn Pil for leseretning (kan utelates) har Ordre Produkt 1 1…* multiplisitet navigasjonspil Kirsten Ribu HiO 2005

35. Designmodell for ordre-systemet - overordnet Kirsten Ribu HiO 2005

36. Om prosjektoppgaven • Obligatoriske innleveringer • Frister for innleveringer kommer fortløpende på websiden • Alle frister MÅ overholdes. Hvis ikke er det å betrakte som avmelding av kurset. • Husk: Prosjektet må ha etnavn • 2. Leveranse: Prosjektbeskrivelse med kravspesifikasjon og overordnet use case modell. • Frist: fredag 23.09 Kirsten Ribu HiO 2005

37. Oppgaver • Gurholt og Hasle s. 337. Oppgave 1.1: Pantemaskin (Tomra). 1. Lag en kravspesifikasjon for pantemaskinen. 2. Lag en use case modell og use case beskrivelser for de viktigste use casene. 3. Lag sekvensdiagrammer for to av use casene. 4. Sette dere inn i og bruk modelleringsverktøyet ’Poseidon’ (eller annet hvis dere har). Kirsten Ribu HiO 2005

38. Neste gang • .NET ved Nils Einar Eide. • Obligatorisk oppmøte. Kirsten Ribu HiO 2005