Flere UML diagrammer UML Distilled kap. 7,8, 9 Kirsten Ribu 11.11.05 Mer om UML Flere UML diagrammer UML Distilled kap. 7,8, 9 Kirsten Ribu 11.11.05

I dag Litt repetisjon – GRASP mønstre og OO design Prosjektoppgaven siste innlevering: ’Evaluer ditt design’ Mer om UML: Pakker Kollaborasjonsdiagrammer Aktivitetsdiagrammer Tilstandsdiagrammer

Repetisjon: Hva er UML? Et konseptuelt modelleringsspråk Et språk definert for å beskrive virkeligheten UML er dagens industri-standard UML definerer elementer regler mekanismer for å beskrive og visualisere modeller av den virkelige verden

Hvorfor modellere - repetisjon. Forskjellige modeller gir ulikt detaljeringsnivå. Noen ganger har man behov for å vise et oversiktsbilde, andre ganger er det detaljene man vil konsentrere seg om. En bruker er interessert i å se hvordan systemet vil se ut utenfra, mens en utvikler kan vikle seg inn i detaljer rundt realiseringen av systemet. Det er ikke nok med en enkelt modell. Store systemer vises best gjennom flere uavhengige modeller.

Objektorientert systemutvikling dreier seg om klasser og objekter. Klasser og instanser av klasser (objekter) og deres samarbeidsmønstre utgjør den statiske strukturen i programvaresystemet. Et grensesnitt beskriver en ekstern tjeneste som en klasse eller en samling klasser skal tilby. Grensesnitt er spesielt relevant i moderne distribuerte systemer. Disse bygges opp av distribuerte komponenter som kan være på et hvilket som helst sted i et nettverk. Komponentene gjør seg tilgjengelig gjennom et definert grensesnitt.

Ulike typer objekter - notasjon Entitesobjekter: informasjon overlever utførelsen av et use case (need-to-know-prinsippet) Grensesnittobjekter All kommunikasjon som er avhengig av systemets omverden plasseres her Kontrollobjekter Komplekse use case: Kontrollobjekter styrer adferden slik at use caset kan utføres korrekt. Typisk kontrollobjekt: Administrator.

OO design Prosjektoppgaven: Vurder designet ut i fra prinsipper om god OO design Stikkord: Kobling Kohesjon Ekspert-, skaper- og kontrollprinsippet

Objektdesign: Ansvarstilordning UML definerer ansvar som en ’kontrakt’ i en klasse Ansvar er knyttet til objektet i form av dets oppførsel Handling: Opprette objekt, beregning Kunnskap: Vite om private data, vite om relaterte objekter Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret Ansvarstilordning: En utfordring under utforming av sekvens-diagrammer

Objektdesign - ansvar Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel ’Spørreskjema’) Kontrollobjektprinsippet: Use case controller: Ett kontrollobjekt per Use case (store systemer) Fasadekontroller: Ett kontrollobjekt som styrer interaksjon med systemet Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: ’SpørreskjemaGenerator’)

Eksempler på objekter Grensesnittobjekter – f.eks webside, printerdriver aktør Kontrollobjekt- ’Use case Handler’, ’Use case controller’ Entitesobjekter: Spørreskjema, ordre

Litt om kontrollobjekter Hver use case kan ha et kontrollobjekt som styrer flyten i use caset Kontrollobjektet er et grensesnitt-objekt Kontrollobjekter delegerer oppgaver til andre objekter

Kjennetegn på ’god’ design En god utforming gjør den jobben den er ment å gjøre En god utforming er enkel og elegant (Eleganse innebærer å finne akkurat riktig abstraksjonsnivå) En god utforming er gjenbrukbar, utvidbar og enkel å forstå Et godt objekt har et lite og veldefinert ansvarsområde Et godt objekt skjuler implementasjons- detaljer fra andre objekter - Grady Booch

Mer om UML - diagrammer

UMLs roller Under utvikling av programvare fremstilles en rekke produkter både dokumenter og eksekverbar kode: Krav Arkitektur Kildekode Prosjektplaner Tester Prototyper Kjørende program UML bidrar til å gjøre disse produkter mer forståelige.

UML = Er et sett med ’byggeklosser’ som gjør det mulig å modellere alle viktige sider ved et programvaresystem. Fire hovedfunksjoner: Visualisere Spesifisere konstruere dokumentere

Forts.. Visualisere: ideene, modellen og koden visualiseres grafisk for lette kommunikasjon med andre (kunder, oppdragsgivere, utviklere). Spesifisere: det lages presise, komplette modeller. UML brukes til å lage spesifikasjonen i fasene analyse, design og implementasjon. Konstruere: UML modeller kan oversettes direkte til et programmeringsspråk som Java, C++. Man kan også gå fra programkode til UML modell (re-engineering). Dokumentere: UML dokumententasjon av krav, arkitektur, design, kildekode, prosjektplaner, tester, prototyper og produksjonsetting (deployment).

UML har 3 hovedbyggeklosser Ting Forhold Diagrammer Ting og forhold uttrykkes med symboler – UML-diagrammer. Diagrammene er grafisk visualisering av de forskjellige konseptene Diagrammene uttrykker sammenhengene i modellene.

Ting Ting består av: Strukturelle ting Oppførselsting Grupperingsting Merknadsting

Strukturelle ting De strukturelle tingene er substantivene i språket: De utgjør de statiske delene i modellene og kan være både konseptuelle, dvs logiske, og fysiske ting. De strukturelle tingene er klasser, grensesnitt, samarbeidsforhold, use case, aktive klasser, komponenter og noder.

Grupperingsting I større systemer vil det alltid være behov for å kunne gruppere deler av systemet for å få bedre oversikt. Den primære grupperingstingen er pakke. En pakke samler flere strukturelle og oppførselsting som er tett koblet. En pakke kan igjen bestå av flere pakker.

Pakker Pakker (eller ’klynger’) for gruppering av modeller eller modelleringselementer. Pakker kan være nøstede. Klassene er inni pakkene.

UML diagramtypene og deres gruppering

Dynamiske og statiske diagrammer Diagrammene kan grupperes i Dynamiske diagrammer: viser de dynamiske (skiftende) aspektene i systemet. Interaksjonsdiagrammer viser en interaksjon bestående av et sett av objekter og deres relasjoner inklusive meldinger som eventuelt blir sendt mellom dem. To typer interaksjonsdiagram: sekvensdiagram og samarbeidsdiagram (collaboration). Statiske diagrammer: viser de statiske (faste) aspektene i systemet. Eks: Fysisk diagrammer: Komponentdiagram og produksjonssettingsdiagram er to diagramtyper som brukes for å modellere de fysiske aspektene ved objektorienterte systemer.

Diagrammer Ni typer diagrammer: Klassediagram Objektdiagram Use case diagram Sekvensdiagram ______________________________________ Tilstandsdiagram Aktivitetsdiagram Samarbeidsdiagram (Kollaborasjonsdiagram) Komponentdiagram Deploymentdiagram ( produksjonssettingsdiagram )

Oppførselsting Oppførsel uttrykker dynamikken i tid og rom i et programvaresystem. For at meldinger skal kunne sendes fra et objekt til et annet må det være en forbindelse mellom objektene (assosiasjoner). Interaksjon: flere objekter samarbeider gjennom utveksling av meldinger seg imellom for å oppnå et resultat. Objekter vil i løpet av sin levetid kunne være i forskjellige tilstander. Dette kan modelleres som tilstandsdiagrammer.

Tilstandsdiagram UML tilstandsdiagrammet vises tilstandene et objekt kan være i, og overgangen mellom tilstandene. Tilstandsdiagrammet viser tilstandene til ett enkelt objekt. Start og slutt på en sekvens av tilstander vises med runde symboler.

UML - diagrammer forts. Klassediagram - Forhold mellom klasser og pakker, statisk og dynamisk Objektdiagram - Typisk forhold mellom noen objekter ved ett bestemt tidspunkt Use case diagram - Hovedfunksjonalitet mellom omverden og system Sekvensdiagram - Rekkefølge på kall/meldinger mellom klasser Kollaborasjonsdiagram - Interaksjon i forhold mellom objektene Tilstandsdiagram - Tilstandsdiagram for ett eller flere samvirkende objekter Aktivitetsdiagram - Beskriver hva som skjer i et objekt Komponentdiagram - Organisering og forhold mellom moduler/pakker Deployment diagram - Hvordan systemets deler er fordelt på maskinvaren

Klassediagram

Merknadsting Tekstlige forklaringer og anmerkninger som kan være nødvendige for å øke forståelsen av en modell eller spesielle deler av en modell: Kommentarer brukes for utfyllende dokumentasjon eller beskrivelse av et modelleringselement eller en modell.

Tilstandsdiagrammer beskriver et systems oppførsel Alle tilstander et objekt kan være i Hvordan objektets tilstander endrer seg som et resultat av hendelser som virker på objektet Er nyttig for å beskrive et objekts oppførsel over flere use case Er ikke egnet til å beskrive hvordan objekter samarbeider (bruk interaksjonsdiagrammer)

Tilstandsdiagram

Eksempel - fly

hendelser

Parallelle tilstander (concurrent)

Aktivitetsdiagrammer viser flyten fra aktivitet til aktivitet. Aktivitetsdiagrammere modellerer hvordan ting virker. Diagrammene er en hjelp for å anskueliggjøre arbeidsprosessen. Ofte har hvert use case et eget tilhørende aktivitetsdiagram.

Aktivitetsdiagram

Aktivitetsdiagram forts. Hovedsymbolet er aktiviteten (Action state (ovalt symbol) En aktivitet er enten en virkelig prosess, (velg drikke), eller utførelsen av en metode En variant av et tilstandsdiagram

Når bruke hva Alle diagrammer har styrker og svakheter Aktivitetsdiagrammer anbefales brukt for modellering av arbeidsflyt Ulempe: Viser ikke forbindelser mellom hendelser og objekter særlig godt Tilstandsdiagram anbefales brukt der hvor det forekommer asynkrone hendelser Ulempe: Viser ikke hvordan objekter samarbeider

Samarbeidssdiagram (Collaboration) Et samarbeidsdiagram vektlegger og får frem organiseringen av objekter som deltar i en interaksjon. Det viser også flyten av meldinger og rekkefølgen de forekommer.

Sekvensdiagram

Samarbeidsdiagram

Sekvensdiagram Et sekvensdiagram vektlegger og får frem tidsrekkefølgen for meldinger. Dette gjøres ved å vise systemets objekter og deres tilhørende levetid, samt meldinger som flyter mellom objektene. Et sekvensdiagram har to dimensjoner: Vertikal dimensjon som representerer tiden. Horisontal dimensjon som representerer forskjellige objekter.

Komponent-diagram viser et sett av komponenter og deres relasjoner (forbindelser). Diagrammet kan inneholde avhengighetsrelasjoner, generaliseringer, arv og realiseringsrelasjoner.

Komponentdiagram

Komponent + prosduksjonssetting (deployment)

Produksjonsettingsdiagram (eng. deployment diagram) viser konfigurasjonen av eksekverbare prosesseringsnoder og komponentene som inngår . Et produksjonsettingsdiagram viser ofte hvor programvare skal settes i produksjon og hvilke noder programvaren skal distribueres til. Vanlige bruksområder er modellering av: Embedded systems, dvs. systemer hvor beregningstjenester ikke er primærfunksjon, f.eks. en mikrobølgeovn eller en videomaskin. Klient/tjener systemer. Distribuerte systemer.

Modellering av databaser UML kan også benyttes til databasemodellering, selv om standarden ikke er utviklet spesielt for dette formålet. UML’s klassediagrammer har samme dekningsområde som ER-diagrammer. Ved å bytte ut elementene i klassediagrammet med standard ER-elementer kan man modellere databaser ved bruk av UML notasjon: Entiteter i ER-diagrammer ses på som klasser. Entitetenes attributter ses på som klassens attributter. Relasjonene mellom entitetene tilsvarer relasjonene mellom klassene.

Neste uke Spør studentassistenten om hjelp med prosjektoppgaven Nils går over ukeoppgavene Siste ordinære forelesning: