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

2
I dag

• Rational Unified Process
• Kravspesifikasjon
• Use case modellering utbrodert
• Kap 3 i UML Distilled

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

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
5
Objektets egenskaper

• Innkapsling
• Polymorfisme
• Arv

Objekt
klasse
6
Hva er en klasse/et objekt?

• Ideen Strukturer, klassifiseringer.
• F.eks klasse fugl et konseptuelt begrep.
• Felles egenskaper Nebb, fjær, vinger etc,

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

8
(No Transcript)
9
Kravspesifikasjonen

• Tilhører analysefasen
• Definerer 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-funksjonelle krav Kan ofte uttrykkes i
  tall (prosenter, antall, tid etc.)
• Eks Ønskede (målbare) kvaliteter på systemet
  (svartid, feilprosent, antall samtidige brukere)

10
Noen kvalitetsattributter

Sikkert Portabelt Testbart
Pålitelig Brukervennlig Modulært
Robust Gjenbrukbart Effektivt
Forståelig Utvidbart
11
(No Transcript)
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

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.

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

15
UP disipliner
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

17
Oversikt over prosessen
.
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

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

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 vokser inkrementelt - 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)

20
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

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)

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

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)

24
(No Transcript)
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

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.

27
Use case modell for Ordrebehandlingssystem
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

29
Use case Lag ordre

• Aktør Kunde
• Sekundær aktø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

30
Sekvensdiagram for Lag ordre
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

32
Overordnet domenemodell
33
Designmodell - Design

• En designmodell viser systemklasser, ikke
  konseptuelle klasser som i domenemodellen
• Typisk informasjon er
• Klasser, assosiasjoner, attributter og navigasjon
• Grensesnitt
• Metoder
• Avhengigheter

34
Eksempel

assosiasjonsnavn
Pil for leseretning (kan utelates)
har
Ordre
Produkt
1
1
multiplisitet
navigasjonspil
35
Designmodell for ordre-systemet - overordnet
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 et navn
• 2. Leveranse Prosjektbeskrivelse med
  kravspesifikasjon og overordnet use case modell.
• Frist fredag 23.09

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).

38
Neste gang

• .NET ved Nils Einar Eide.
• Obligatorisk oppmøte.