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

Unified Process Disciplines Disciplines Elaboration Iterasjoner

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

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

UML – Relatere Brukstilfeller (2) Include – Eksempel grafisk

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

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

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

UML – Generalisering (2) Notasjon Superklasse Generalisering Subklasse

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 B C A Venn-diagram

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

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

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

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

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

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

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

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 Åpen 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 Fylt diamant

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

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

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

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 id Qualifier

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” id Uttrykker ingenting om entydighet

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 Rollenavn

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

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

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

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

Avhengighet: B bruker C 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

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

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

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

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

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

UML – Tilstandsdiagram (2) Eksempel Starttilstand Overgang Tilstand Hendelse

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

UML – Tilstandsdiagram (3) Eksempel - POS

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

UML – Tilstandsdiagram (5) Eksempel Betingelse Aksjon Hendelse

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

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

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