Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Unified Process – Elaboration Iterasjon 3  Mål med denne seksjonen: •Arbeide videre med Elaboration fasen i UP •Se spesielt på Iterasjon 3 •Beskrive.

Liknende presentasjoner


Presentasjon om: "Unified Process – Elaboration Iterasjon 3  Mål med denne seksjonen: •Arbeide videre med Elaboration fasen i UP •Se spesielt på Iterasjon 3 •Beskrive."— Utskrift av presentasjonen:

1

2 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

3 Unified Process Disciplines Elaboration Iterasjoner

4 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

5 UML – Relatere Brukstilfeller (2)  Include – Eksempel: Referanse i tekst UC1: Betale varer … 4.… 5.Systemet presenterer totalsum, inklusive moms 6.Kunden betaler totalsummen 7.… 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

6 UML – Relatere Brukstilfeller (2)  Include – Eksempel grafisk

7 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

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

9 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

10 UML – Generalisering (2)  Notasjon Superklasse Subklasse Generalisering

11 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 BC A Venn- diagram

12 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

13 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

14 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

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

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

17 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

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

19 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

20 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

21 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

22 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

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

24 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

25 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

26 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

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

28 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

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

30 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

31 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

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

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

34 UML – Pakker (5)  Eksempel 3 – POS •Fig 27.21: OversiktFig •Fig 27.22: YmseFig •Fig 27.23: BetalingFig •Fig 27.25: SalgFig •Fig 27.24: ProdukterFig 27.24

35 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

36 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

37 UML – Tilstandsdiagram (2)  Eksempel Starttilstand Overgang Tilstand Hendelse

38 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

39 UML – Tilstandsdiagram (3)  Eksempel - POS

40 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 Hendelse BetingelseAksjon Overgang

41 UML – Tilstandsdiagram (5)  Eksempel Hendelse Betingelse Aksjon

42 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

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

44 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


Laste ned ppt "Unified Process – Elaboration Iterasjon 3  Mål med denne seksjonen: •Arbeide videre med Elaboration fasen i UP •Se spesielt på Iterasjon 3 •Beskrive."

Liknende presentasjoner


Annonser fra Google