Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Transkript

1 Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker Kunnskap om gode designprinsipper bidrar til å oppnå høy kvalitet på det ferdige produktet Kirsten Ribu 1 2 Objektorientering hva er det? Objektets egenskaper 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 Innkapsling Polymorfisme Arv 3 4 Best practises ved programvareutvikling Iterativ utvikling Håndtering av krav Bruk av komponentbasert arkitektur Visuell modellering Kontinuerlig verifisering av programvarekvaliteten Kontrollerte endringer i programvaren Kravspesifikasjonen Tilhører analysefasen Definer funksjonelle og ikke-funksjonelle krav Funksjonelle krav: Konkrete krav til systemet som beskriver en ønsket tilstand. 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-funskjonelle krav: Kan ofte uttrykkes i tall (prosenter, antall, tid etc.) Eks: Ønskede (målbare) kvaliteter på systemet (svartid, feilprosent, antall samtidige brukere) 5 6 1

2 Noen kvalitetsattributter RUP Rational Unified Process Sikkert Portabelt Testbart En systemutviklingsprosess (industristandard) som beskriver: Pålitelig Brukervennlig Modulært Hvem som gjør hva, hvordan og når Retningslinjer Robust Forståelig Gjenbrukbart Utvidbart Effektivt Maler og mønstre Konsepter for overvåkning/måling av fremdrift 7 8 The Unified Process En prosessmodell Use-case dreven: Use case modellen driver utviklingsprosessen, ikke bare for kravspesifikasjon, 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 9 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 10 Oversikt over prosessen UP disipliner. Inception Elaboration Construction Transition Idefase Utdypning Konstruksjon Overgang Idefasen: Krav, omfang, lønnsomhet Utdypning: planlegging, krav, arkitektur, risiko, prototyping Konstruksjon: konstruksjon, implementering, testing Overgangsfasen: kvalitetskontroll, brukeropplæring

3 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 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 vokser inkrementelt - iterasjon for iterasjon - og leveres kunden i inkrementer (deler) RUP (Rational Unified Process) brukes i dag som prosessmodell i mange bedrifter ( Inception (idéfasen) noen aktiviteter Gjennomførbarhetsanalyse Prototyping for å klargjøre krav Planlegging av 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 15 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) 16 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 Transition (overgangsfasen) Programmering er ferdig Endringer gjøres for optimalisering Feilrettinger Ferdigstilling av produktet Forberedelse til pilotprosjekt Brukeropplæring Planlegging av videreutvikling (nye versjoner)

4 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 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 Use case modell for Ordrebehandlingssystem 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 Use case Lag ordre Sekvensdiagram for Lag ordre Aktør: Kunde Sekundær aktør: Regnskapssystem 1. Systemet viser et ordreskjema med varebeskrivelser 2. Kunden skriver inn de ønskede varene og betalingsinformasjon 3. Systemet sjekker at alle felt er fylt ut og viser totalsum 4. Kunden bekrefter bestillingen 5. Systemet lagrer ordren og sender betalingsinformasjon til regnskapssystemet 6. Regnskapssystemet bekrefter betalingsinformasjonen 7. Systemet sender en ordrebekreftelse til kunden

5 Domenemodell Overordnet 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 Designmodell - Design Eksempel En designmodell viser systemklasser, ikke konseptuelle klasser som i domenemodellen Typisk informasjon er: Klasser, assosiasjoner, attributter og navigasjon assosiasjonsnavn Ordre 1 har 1 * Pil for leseretning (kan utelates) Produkt Grensesnitt Metoder multiplisitet navigasjonspil Avhengigheter Designmodell for ordresystemet - overordnet Om prosjektoppgaven Obligatoriske innleveringer Frister for innleveringer kommer fortløpende på websiden Webside for prosjektet: Skal være ferdig i løpet av neste uke. For tips om utforming: Husk: Prosjektet må ha et navn 1. Leveranse: Overordnet use case modell med use case beskrivelser. Frist: Slutten av uke 5 (30.januar)

6 Neste gang onsdag Use case modellering Link til Rational Rose (studentversjon) på kurssiden Kap 8 i G&H Kap 3 i UML Distilled 31 6