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

UML personligheter David Harel, tilstandsgrafer Grady Booch, Booch method Jim Rumbaugh, OMT Ivar Jacobson, Objectory Alan Turing (http://www.alicebot.org/)

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

Ogdens triangel

UML har fire formål Visualisering Spesifisering Konstruering Dokumentering

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

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

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

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

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

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

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

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

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

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

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

Generalisering En generalisering kan spesialiseres for flere ulike domener

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Command Command oversetter brukerimpulser til systemoperasjoner

Praktisk problem og LoD Snakk bare med de nærmeste

Praktisk design med LoD La en venn ordne problemet

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

Layers, 3-tier GRASP Forretningssystemer er lagdelte

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

Praktisk lagdeling Figuren viser en lagdeling av et kinosystem