Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Objektorientert systemutvikling og UML

Liknende presentasjoner


Presentasjon om: "Objektorientert systemutvikling og UML"— Utskrift av presentasjonen:

1 Objektorientert systemutvikling og UML
OOSU er den mest anvendte metoden på både store og små prosjekter UML er det mest anvendte beskrivelsesspråk for OOSU UML er universelt anvendelig innenfor alle områder i OOSU OOSU og UML er en teknisk/vitenskapelig tilnærming til systemutvikling

2 UML personligheter David Harel, tilstandsgrafer
Grady Booch, Booch method Jim Rumbaugh, OMT Ivar Jacobson, Objectory Alan Turing (

3

4 Læring og tenkning Systemutvikling er læring
Gjensidig respekt og samarbeid Følge en konkret oppskrift Velge blant flere oppskrifter Nå målet uten oppskrift, realisere en abstraksjon

5 Ogdens triangel

6 UML har fire formål Visualisering Spesifisering Konstruering
Dokumentering

7 UML og ting Det er 1 type forklarende ting
Det er 1 type grupperende ting Det er 2 typer ting med oppførsel Det er 7 typer strukturerende ting

8 Klasse Grunnsymbolet for klasse er en firkant med klassenavnet på innsiden Symbolet kan utstyres med attributter og operasjoner Attributtene står for det klassen vet Operasjonene er hva klassen kan gjøre

9 Abstrakte klasser Vanlige klasser kan instansieres
Abstrakte klasser kan ikke instansieres Abstrakte klasser kan ha attributter En abstrakt klasse har minst en udefinert operasjon Abstrakte klasser utnyttes gjennom spesialisering Spesialiseringen er å definere udefinerte operasjoner

10 Interface Interface er mindre enn abstrakte klasser
Interface mangler nemlig attributter og konkrete operasjoner Interface bygger en felles meldingsstruktur mellom rammeverk og domeneklasser

11 Samarbeid Strukturen i et samarbeid vises med en stiplet ellipse
Navnet på samarbeidet vises inne i ellipsen Symbolet kan også vise mer detaljert hvilke elementer i systemet som inngår i samarbeidet Samarbeid kalles også kommunikasjon i UML Samarbeidsgrafen kan nemlig vise hvilke elementer som sender meldinger til hverandre Samarbeidsgrafen er et teknisk symbol

12 Brukstilfeller Brukstilfeller minner om samarbeid
Symbolet brukes ofte i ikke-teknisk sammenheng Grafen er en heltrukken linje Symbolet kan brukes både om systemaktiviteter og domeneaktiviteter Mange bruker det også om forretningsaktiviteter Grunngrafene kan brukes i møtet mellom systemutviklere og domeneeksperter Objektorienterte ornamenter (s. 60) brukes bare av systemutviklere

13 Aktive klasser Aktive klasser kontrollerer sine egne tråder eller prosesser Klassen har derfor ofte et statisk deklarert entry point Men klassen kan også ha et dynamisk deklarert entry point fra et interface

14 Komponenter En komponent er en utskiftbar enhet
UML-brukere har litt ulik praksis for hva begrepet komponent dekker En komponent er en instans av noe kjørbart Med UML 2.0 har mange tidligere komponenter blitt til artifakter

15 Noder En node er et fysisk punkt Et stykke maskinvare er en node
Et operativsystem er en node JRE og JVM er noder En node er nemlig et fysisk kjøremiljø for en applikasjon

16 Assosiasjon En assosiasjon kan være svak En assosiasjon kan være sterk
Disse to formene for assosiasjon kalles også aggregering og komposisjon

17 Generalisering Generalisering innebærer gjenbruk
Symbolet peker mot det mer generelle og gjenbrukbare Det spesielle er mer domenespesifikt enn det generelle Det spesielle er derfor mer brukbart og samtidig mindre gjenbrukbart

18 Generalisering En generalisering kan spesialiseres for flere ulike domener

19 Realisering Realisering innebærer konkretisering av det abstrakte
Symbolet peker fra det konkrete mot det abstrakte Det peker altså fra noe domenespesifikt til noe generelt

20 Realisering Interface og abstrakte klasser må realiseres før de kan brukes i et domene

21 Hvorfor diagrammer? Bruk diagrammer
for å lære om systemet eller deler av det for å konstruere systemet eller deler av det for å dokumentere systemet eller deler av det for å spesifisere entydig systemet eller deler av det

22 Aktivitetsdiagrammer
Viser en side ved systemets dynamikk Kan spesifisere et brukstilfelle Viser rekkefølgen i aktiviteter Konstruerer løsningen av en oppgave Dokumenterer vanligvis mer menneskelig enn teknisk dynamikk

23 Forgrening Kan vises som aktivitet med flere utgående transisjoner
Hver transisjon kan forsynes med en betingelse En av dem kan ha else

24 Parallelle aktiviteter
En transisjon går inn i det første symbolet Flere transisjoner går ut fra det første symbolet og inn i det parallelle området Flere transisjoner går inn i det andre symbolet En transisjon går ut fra det andre symbolet

25 Kombinasjon av signaler
Avanserte signaler kan kombineres Eksterne signaler kan også modelleres

26 Tilstandsmaskiner Tilstandsmaskiner kan beskrives med tilstandsdiagrammer Nivået er teknisk Tilstandsdiagrammet viser ett objekts tilstander og transisjoner Objektdiagrammet viser flere objekters tilstander på en gang Tilstandsdiagrammet viser hva som skal til for å endre tilstanden

27 Grunnleggende diagram
Hver tilstand vises som en avrundet firkant Hver tilstand må ha en merkelapp Hver transisjon har retning Transisjonen kan ha merkelapp Stopp viser hvilken tilstand objektet må være i rett før det destrueres

28 Transition label Transition label, eller ”merkelapp”, har tre avdelinger Alle avdelingene er valgfrie

29 Tilstandsoperasjoner
entry/ spesifiserer operasjoner ved inngangen til tilstanden exit/ spesifiserer operasjoner ved utgangen fra tilstanden do/ spesifiserer operasjoner i selve tilstanden I tillegg kan språket utvides ved å definere nye tilstandsord

30 Sammensatte tilstander
Sammensatte tilstander har topptilstand Under topptilstanden kan det finnes ulike sammensatte tilstander

31 Sekvensielle tilstander
Husholdningsmaskiner kan kreve høy grad av systemforståelse fra vanlige brukere Adax elektroniske varmelistsystem er et eksempel Adax veiledninger og oversikter for forbrukeren

32 Forenkling og fokusering
Kompliserte diagrammer er ikke så lærerike Diagrammer som ser for enkle ut er ofte bedre

33 Samtidige tilstander Samtidige tilstander modellers i samme tilstandsgraf Tilstandene deles med en stiplet linje

34 Patterns (mønstre) Patterns er erfaringer Patterns er best-practices
Patterns er how-to Patterns er velkjent design Larman: ” ’new Pattern’ is an Oxymoron”

35 High Cohesion Metoder med en oppgave
Objekter med få og enkle tilstander Klasser med høy konsentrasjon om ett ansvarsområde Applikasjonslag med konsentrasjon om ett område Bidrar til enkel API Høy grad av abstraksjon og enkel gjenbruk Bidrar til lav kobling

36 Low coupling Kobling vises som assosiasjoner mellom klasser
Lav kobling vises som få assosiasjoner

37 Struktur i Command Isolerer kilde og utfører
Mønsteret viser isoleringen mellom invoker - receiver, og Client - ConcreteCommand

38 Command Command oversetter brukerimpulser til systemoperasjoner

39 Praktisk problem og LoD
Snakk bare med de nærmeste

40 Praktisk design med LoD
La en venn ordne problemet

41 Generelt kart over LoD Klassen Ansvar har bare noen få nære Venn-er

42 Layers, 3-tier GRASP Forretningssystemer er lagdelte

43 Layers, n-tier Systemets størrelse krever av og til flere lag
Klikk for detaljer

44 Praktisk lagdeling Figuren viser en lagdeling av et kinosystem


Laste ned ppt "Objektorientert systemutvikling og UML"

Liknende presentasjoner


Annonser fra Google