Viderebearbeiding / Elaboration (del 2)

1. Viderebearbeiding / Elaboration (del 2) Arne Maus,Inst. for informatikk, UiO

2. Viderebearbeiding / Elaboration – kap 8 • Vi skal nå: • bygge kjerne-arkitekturen • løse alle høy-risk (vanskelige) deler • definere mesteparten av kravene • estimere en overordnet prosjektplan og kost (ressursbruk) Dvs: ikke minst, starte å programmere

3. En tidlig (første) implementasjon av systemet • Identifisere prosesser, pakker (av klasser), subsystemer, implementere noen av disse • Mye ’stub’-kode • Definere systemets grensesnitt (metoder og parametre) mot andre systemer • Integrere innkjøpte moduler • Implementere enklest mulig versjon av hoved Use Case’t (eks: Salg uten feilsituasjoner) • Lage brukergrensenitt for dette • Lage og utføre tester for implementert kode • Stress-testing av forbindelse til andre systemer

4. Oversikt over Viderebearbeiding / Elaboration • Ikke mer enn noen få måneder (for de fleste prosjekter) • Har flere iterasjoner • Oppdager/utpensler minst halvparten av kravene • Høyrisiko-deler behandles og løses • Lager én kjørende versjon av systemet per iterasjon • Design og kravspek. revideres kontinuerlig • Virkelig testing utføres • Flere ’hjerneblæst’-møter om design, arkitektur,..

5. System Sekvens-Diagrammer (SSD) – kap 9 • Viser Interaksjonen med systemet (som helhet) for noen sentrale Use Case’er • både de sentrale vellykkede og komplekse feilsituasjoner • Systemet behandles som en (svart) boks • Dette definerer også systemets grenser • Mellom mennesker/andre systemer og vårt system • Bemerkning: I boka er ikke kunden i interaksjon med systemet, mens i Norge drar jo Kunden både kredittkort og gir PIN-kode

6. SSD som viser et vellykket salg

7. System Sekvens Diagrammene Brukes til: • Gi navn til operasjoner (begynn med et verb) • Gi navn som forteller hensikten (resultatet) med operasjonen • Få oversikt over komplekse / sentrale Use Case situasjoner • Definere også grensesnittet til systemet • Lages bare for de litt mer komplekse Use Case’ne

9. Domene Modeller – kap 10 • En Domenemodell er en representasjon av begreper/ klasser (konseptuelle klasser ) i den virkelige verden ikke en modell av program-komponenter. Det beskriver ikke nødvendigvis hvordan programmet blir - bare inspirerer hvordan program-designen blir. • Her er det noe uenighet mellom Craigh Larman og Ifi-miljøet (Maus, Skagestein, Normann). • Vi mener at Domenemodellen er direkte utgangspunktet for å lage modellen av programsystemet (en-til-en + tillegg for GUI, annen i/o, maskinvare mm) • Meningsforskjellen er ikke stor i praksis – men i teorien !!?. • Domene-modellen er det viktigste produktet fra analysen (begge)

10. Domenemodell av sentrale deler av Kassa-apparatsystemet

11. En domenemodell består av konseptuelle klasser og forholdet mellom disse • En konseptuell klasse: • Har data (attributter) • Har ikke metoder • Utvikles og utvides hele tiden (man finner stadig nye begreper/klasser som skal være med)

13. Hva er en konseptuell klasse – og hva er bare et attributt • Hvis man tenker på det bare som en tekst eller et tall, så er det et attributt – ellers en klasse i domenemodellen • Hvis man er i tvil (attributt eller klasse) – lag en ny klasse • Vi noterer sammenhengen (assosiasjonene) mellom klassene • ’N.B Ikke alle, men der det er viktige sammenhenger

14. Hvorfor bør FlightDestination være en egen klasse i Domene-modellen

15. Vi trenger av og til spesifikasjonsklasser

16. Hva gjør en spesifikasjonsklasse • Beskriver en gjenstand eller tjeneste uavhengig av enkeltobjektene • Hvis vi f.eks fjerner alle gjenstandene mister vi ikke informasjon om objektene • Reduserer duplisering av informasjon • Hvorfor kan dette ikke implementeres som static variable i Java ? (klasse-variable)

18. UML og klasser • UML klasser (i diagrammene) kan brukes til å lage bilder av: • Klasser i Domene-modellen (virkelige ting / begreper) • Klasser i Designmodellen (spesifikasjon av programkomponenter) • Klasser i en bestemt (Java) implementasjon (beskrivelse av eksisterende programkomponenter) • En tabell i en database ’Alt’ (hele betydningen) kan ikke leses ut av et UML diagram At vi bruker samme begrep og klassenavn i de ulike modellene, gjør at vi enklere kan lage neste modell

19. A bruker eller styrer B A kommuniserer med B A er etterfølger til B A eies av B A er en hendelse relatert til B A er en transaksjon relatert til B B A Registrerer- Salg Registeret 1 1:* Legge på assosiasjoner – kap. 11 • A er del av B • A er logisk del av B • A er inneholdt i B • A er beskrivelse av B • A er en del av en rapport B • A er loggført av B • A er medlem i B • A er en underavdeling av B

20. Retningslinjer • Ta bare med slike assosiasjoner vi trenger en viss tid (”må vite dette”) • Assosiasjoner er ikke så viktig som klassene • Ikke for mange assosiasjoner • Vis ikke slike som kan avledes av andre assosiasjoner

21. Rollenavn og antall på assosiasjoner • Leses fra venstre mot høyre • Sier også noe om hvilke retninger vi kan ’gå’ • Ha med antall i hver ende 3,5,7 * null- eller flere tre, fem eller syv 1..* en- eller flere 1..44 1 * en til 44 salg vare består av 6 eksakt seks Rollenavn

22. Domene-modeller med attributter (variable) – kap 12 • Viser essensiell informasjon i systemet – må tas vare på • bare enkle datatyper (int, String, boolean, Tidspunkt) • Modellerer konseptuelle klasser som egne klasser med assosiasjoner, ikke som attributter • Sammensatte gjenstander/begreper er klasser (telefonnummer, personnummer, dato, produkltkode,..) • N.B legg ikke inn fremmednøkler , men bruk assosiasjoner til den andre klassen • Ett attributt har: ett navn, en type og en verdi

23. Kontrakter for systemet – kap 13 • Beskriver hva som skjer med klassene i domenemodellen når man utfører operasjoner på systemet • Bruker for- og etterbetingelser og gir tilstandsforandringen til objektene (endring av verdier på variable) • Lage eller fjerne objekter • Endre enkle verdier • Endre assosiasjoner (fjerne/flytte/opprette,...) • Eks: Ved hvert salg av en Vare, lages et SalgsLinje objekt (ny fakturalinje) • Kontrakter brukes til å fange krav til systemet, men Use Case er viktigere

24. Å lage kontrakter • Finn system-operasjoner fra SSDene • For komplekse systemoperasjoner som ikke kommer klart ut av et UseCase,men som likevel skal gjøres, lag en kontrakt • For å beskrive etterbetingelksene (hva gjelder etter et slikt kall) se på: • Lage eller fjerne objekter • Endre enkle verdier • Endre assosiasjoner (fjerne/flytte/opprette,...)

25. UML-notasjon – kap. 14 & 15 • OO Analyse mye viktigere enn UMLnotasjons-detaljer • Viktig OO Analyse • Design patterns (design-mønstre) • Hvordan plassere metoder (tilordne ansvar)

26. Interaksjonsdiagrammer • Er fellsenavn på Sammarbeids- og Sekvensdiakrammer

27. Sekvensdiagram – uttrykker det samme som samarbeidsdiagrammet, , tar større plass, men er mest egnet til å vise samspill mellom klasser og objekter i tidsrekkefølge

28. Sammarbeidsdiagram – uttrykker det samme som sekvensdiagrammet, og er mer kompakt (mindre oversiktlig)

29. KlasseNavn Attributter (data) Metoder Klasser i UML Unntak

30. Klasser og objekter, notasjon • Klasse • Objekt • Navngitt objekt Salg :Salg s1:Salg

31. Meldinger • Meldinger langs assosiasjoner (begge veier) • Melding til seg selv

32. Meldinger til mengder (collections)