Unified Process – Elaboration Iterasjon 3

1. Unified Process – Elaboration Iterasjon 3 • Mål med denne seksjonen: • Arbeide videre med Elaboration fasen i UP • Se spesielt på Iterasjon 3 • Beskrive flere UML konstruksjoner • Mer notasjon for Brukstilfeller • Relatere Brukstilfeller • Mer notasjon for klasssediagram • Generalisering av klasser • Mer om assosiasjoner • Tilstandsdiagram

2. Disciplines Unified Process Disciplines Elaboration Iterasjoner

3. UML – Relatere Brukstilfeller (1) • Include • Brukes til å dekomponere et Brukstilfelle i mindre deler • Unngå duplisering i flere Brukstilfeller • Splitte opp et stort Brukstilfelle i mindre • ”Dekomponering” • Refererer til relaterte brukstilfeller i basis Brukstilfelle • Notasjon

4. UML – Relatere Brukstilfeller (2) • Include – Eksempel: Referanse i tekst UC1: Betale varer … • … • Systemet presenterer totalsum, inklusive moms • Kunden betaler totalsummen • … Alternativ flyt 6a. Betale kontant: Se UC11: Betale kontant 6b. Betale med bankkort: Se UC12: Betale med bankkort 6c. Betale med sjekk: Se UC13: Betale med sjekk Inkludert brukstilfelle

5. UML – Relatere Brukstilfeller (2) • Include – Eksempel grafisk

6. UML – Relatere Brukstilfeller (3) • Extend • Modifisere et Brukstilfelle på bestemte steder • Ønsker ikke å endre basis brukstilfelle • Kan oppnå mye det samme ved å bruke Include, men da må basis brukstilfelle referere et inkludert brukstilfelle • Notasjon

7. UML – Relatere Brukstilfeller (4) • Extend – Eksempel i tekst UC1: Betale varer … Extention point: Betaling, steg 6 • … • Kunden betaler totalsummen • … UC15: Betale med gavesjekk … Trigger: Kunden vil betale med gavesjekk Extension point: Steg 6: Betaling i UC1: Betale varer Hovedflyt • Kunden gir gavesjekk til ekspeditør • Ekspeditør registrerer gavesjekkens ID i systemet • …

8. UML – Generalisering (1) • Kan ordne begrep hierarkisk • Superklasse = Overordnet begrep • Subklasse = Underordnet begrep • Generalisering = Identifisere fellestrekk ved flere begrep, og definere dem som eget begrep • Definere felles superklasse for gitte (sub)klasser • Eksempel: Kontorsjef og lektor generaliseres til ansatt • Spesialisering = Identifisere spesialtilfeller av et begrep, og definere dem som eget begrep • Definere subklasser for en gitt (super)klasse • Eksempel: Ansatt spesialiseres til kontorsjef

9. UML – Generalisering (2) • Notasjon Superklasse Generalisering Subklasse

10. A B C UML – Generalisering (3) • Instanser for super- og subklasser • 100% regelen: Alt som gjelder for instanser i en superklasse gjelder også for alle instanser i enhver subklasse • IS-A regelen: Alle instanser av en subklasse er også instanser av dens superklasse Venn-diagram

11. UML – Generalisering (4) • Bruk generalisering / spesialisering i en domene-modell kun når det er relevant / nyttig • Spesialisering nyttig: • En klasse B er en subklasse for en klasse A når … • … A og B har de samme attributtene, men B har flere • … A og B har de samme assosiasjonene, men B har flere • … B håndteres alltid som A, men i tillegg finnes forskjeller • … B oppfører seg alltid som A, men i tillegg finnes forskjeller • … A og B følger 100% - og IS-A reglene • Generalisering nyttig: • Klasser A og B kan ha en felles superklasse når … • … A og B har felles attributter som kan faktoriseres ut • … A og B har felles assosiasjoner kan faktoriseres ut • … A og B følger 100% - og IS-A reglene

12. UML – Generalisering (5) • Abstrakt klasse = Klasse som ikke kan ha egne instanser • Hvert medlem i en abstrakt klasse må være med i en subklasse • Notasjon Kursiv = Abstrakt

13. UML – Generalisering (6) • Bruk av generalisering • Domenemodell: Spesialiseringshierarki mellom begreper • ”Faktorisere” ut felles egenskaper • Kan gi bedre forståelse av domenebegrepene • Basis for bruk av arv i designmodellen • Designmodell: Benytte arv i programmeringsspråket • Arve felles attributter og metode • Innfør kun relevant generalisering / spesialisering

14. UML - Mer om assosiasjoner • Flere mekanismer for assosiasjoner • Assosiasjonsklasse • Aggregering • Komposisjon • Roller • Kvalifisert assosiasjon • Refleksiv assosiasjon • Ordnet assosiasjon • Øker uttrykkskraften til assosiasjoner

15. UML – Assosiasjon som klasse • En assosiasjon kan modelleres som en klasse… er ekvivalent med…

16. Klassen kan også ha navn Anonym assosiasjons-klasse UML - Assosiasjonsklasse (1) • Assosiasjonsklasse = Klasse som ”holder på” begreper / data som er knyttet til en assosiasjon • Notasjon

17. UML – Assosiasjonsklasse (2) • Assosiasjonsklasse indikerer ofte et eget begrep • Assosiasjon blir til klasse…

18. Åpen diamant UML – Aggregering • Aggregering = Assosiasjon mellom klasser som er i et Hele – Deler forhold, der Delene kan inngå i flere Helheter • Delene kan eksisterer uavhengig av Helheten • Notasjon

19. Fylt diamant UML – Komposisjon • Komposisjon = Assosiasjon mellom klasser som er i et Helhet – Deler forhold, der Delene ikke kan inngå i flere Helheter • Delene kan ikke eksistere uten Helheten • Notasjon

20. UML – Aggregering / Komposisjon • Bruk av aggregering / komposisjon • Når det er et klart helhet - deler forhold • Fysisk • Logisk • Operasjoner på helheten gjelder også delene • Sletting • Flytting • Egenskaper ved helheten gjelder også delene • Plassering i rom eller tid • Delene har samme levetid som helheten Komposisjon • Kan utelates hvis i tvil – bruk heller en ordinær assosiasjon

21. UML – Avledet attributt / assosiasjon (1) • Avledet attributt = Attributt som kan beregnes på bakgrunn av verdien på andre attributter eller assosiasjoner • Avledet assosiasjon = Assosiasjon som kan beregnes på bakgrunn av verdien på andre assosiasjoner • Knytte til avledningsregel som beskriver hvordan avledningen gjøres • Bruk sparsommelig – kun hvis det er nyttig for forståelsen

22. / betyr avledet UML – Avledet attributt / assosiasjon (2) • Notasjon • Tilsvarende for avledet assosiasjon

23. id Qualifier UML – Kvalifisert assosiasjon (1) • Kvalifisert assosiasjon = Definerer Qualifier – en attributt som skiller entydig mellom objektene på mange-side i en assosiasjon • Nytte • Uttrykke entydig identifikasjon av elementer i mengder • Bruk sparsommelig i Domenemodell! • Notasjon

24. id UML – Kvalifisert assosiasjon (2) • Eksempel • ”For hver produktkatalog og id finnes en unik vare” • ”For hver produktkatalog finnes mange varer, som hver har en id” Uttrykker ingenting om entydighet

25. Rollenavn Rollenavn UML – Roller (1) • Rolle = Navn på den ene enden av en assosiasjon • Navn på rollen som klassen i ene enden av assosiasjonen spiller • Ofte unødvendig å sette på eksplisitt Rollenavn ofte lik Klassenavn • Notasjon

26. UML – Roller (2) • Roller i assosiasjon eller som begrep Rolle Eget begrep

27. UML – Refleksiv assosiasjon • Refleksiv assosiasjon = Assosiasjon fra en klasse til seg selv • Roller viktig for å identifisere hvilken ende av assosiasjonen som betyr hva • Notasjon / eksempel

28. {ordered} UML – Ordning i assosiasjon • Elementene i ene enden av assosiasjonen er ordnet • Motsatt: Uordnet mengde • Notasjon Begrensning (constraint): Ordnet mengde

29. UML – Pakker (1) • Pakke = Mekanisme for å organisere modell-elementer i UML • Kan organisere pakker i hierarki – pakke i pakke • En klasser kan tildeles til en pakke, og eies av denne pakken • Kan referere til en klasse i en annen pakke fra enhver pakke • Navnekonvensjon: • Pakkenavn::Elementnavn • Eksempel • Pakke: Produkter • Klasser: Produkter::Produktkatalog, Produkter::Vare

30. UML – Pakker (2) • Avhengighet mellom pakker • En pakke A er avhengig av en pakke B hvis A på en eller annen måte bruker elementer fra B • Notasjon Pakkenavn Indre pakke Avhengighet: B bruker C

31. UML – Pakker (3) • Eksempel 1 • Organisere klassemodell i flere pakker

32. UML – Pakker (4) • Eksempel 2 • Referere til en klasse i en annen pakke Prefix: Pakkenavn

33. UML – Pakker (5) • Eksempel 3 – POS • Fig 27.21: Oversikt • Fig 27.22: Ymse • Fig 27.23: Betaling • Fig 27.25: Salg • Fig 27.24: Produkter

34. UML – Pakker (6) • Hvorfor gruppere klasser i samme pakke • Logisk relaterte klasser • Klasser med mange assosiasjoner mellom seg • Subklasse- superklasse hierarki • Klasser som tilhører ulike delsystem • Klasser som lagres på ulike områder • Mål med å organisere i pakker • Bedre oversikt over modellen • Dele opp i naturlige delmodeller av ”passende” størrelse • Lav kobling mellom pakker • Høy kohesjon innen hver pakke

35. UML – Tilstandsdiagram (1) • Tilstandsdiagram – Modellerer endring (transition) i tilstand(state) som følge av hendelser (events) • Tilstand (state) = Beskrivelse av ”situasjonen” til et element • Eks.: Telefonen er ledig / Telefonen er opptatt • Hendelse (event) = Noe som medfører en endring i tilstand • Eks.: Tar av telefonrøret • Overgang (transition) = En endring fra en tilstand til en annen når en hendelse opptrer • Eks.: Tar av telefonrøret  Telefonen er opptatt

36. Tilstand Starttilstand Hendelse Overgang UML – Tilstandsdiagram (2) • Eksempel

37. Uml – Tilstandsdiagram (3) • Benyttes til å beskrive tilstandsendringer i et eksisterende UML – element • Klasser • Brukstilfeller • ”System” • Eksempel • Klasse: Telefon • Brukstilfelle: Tekstbehandler • Brukstilfelle: Brukerdialog • Beskriver programlogikk • Rekkefølge (eks.: åpne før lagre; cut før paste) • Tilgjengelighet (eks.: knapper, menyvalg) • Betingelser

38. UML – Tilstandsdiagram (3) • Eksempel - POS

39. UML – Tilstandsdiagram (4) • Mer detaljer for en overgang: kan spesifisere • Hendelse - hva som utløser overgangen • Betingelse - betingelse for overgangen • Aksjon - bieffekter hvis overgangen skjer • Notasjon • Hendelse : [Betingelse] / Effekt • Eksempel: Start telefonsamtale: tar av røret : [gyldig abonnement] / opprett forbindelse Overgang Hendelse Betingelse Aksjon

40. UML – Tilstandsdiagram (5) • Eksempel Betingelse Aksjon Hendelse

41. UML – Tilstandsdiagram (6) • Nøstet tilstand = Tilstand som består av del-tilstander med sine egne overganger • En nøstet tilstand arver alle overgangene til sin supertilstand • Eksempel • Telefon: ”Opptatt” inneholder mer logikk og handlinger enn kun en enkelt tilstand kan angi • Opptatt = Summetone + Slå siffer + Få forbindelse + Snakke

42. UML – Tilstandsdiagram (7) • Eksempel Nøstet tilstand Subtilstand

43. UML – Tilstandsdiagram (8) • Mål med å bruke tilstandsdiagram • Beskrive klasser / brukstilfeller / delsystem som har kompleks oppførsel • Beskrive klasser med tilstand: State dependant = Klasser med ”hukommelse” • Motsatt: State independant – ingen ”hukommelse” • Eksempler • Brukstilfeller – betale for varer • (Del)systemer - kredittvurdering • GUI vinduer - filbehandling • Sesjoner – ”handlevogn” i e-butikk