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 (

Historisk om UML

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

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

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

Praktisk lagdeling  Figuren viser en lagdeling av et kinosystem