Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Unified Process – Elaboration Iterasjon 3

Liknende presentasjoner


Presentasjon om: "Unified Process – Elaboration Iterasjon 3"— Utskrift av presentasjonen:

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 Unified Process Disciplines 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 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

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

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

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

18 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

19 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

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 UML – Avledet attributt / assosiasjon (2)
Notasjon Tilsvarende for avledet assosiasjon / betyr avledet

23 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

24 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

25 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

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 UML – Ordning i assosiasjon
Elementene i ene enden av assosiasjonen er ordnet Motsatt: Uordnet mengde Notasjon {ordered} 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 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

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 UML – Tilstandsdiagram (2)
Eksempel Starttilstand Overgang Tilstand Hendelse

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


Laste ned ppt "Unified Process – Elaboration Iterasjon 3"

Liknende presentasjoner


Annonser fra Google