Objektorientert systemutvikling og UML

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 (http://www.alicebot.org/)

3. Historisk om UML

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å implementeres eller 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 • Hva får vi?

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