Systemutvikling med UML - Institutt for teknisk kybernetikk - NTNU

Systemutvikling med UML
Øyvind Stavdahl
Institutt for teknisk kybernetikk, NTNU
Oktober 2004

Denne kursbolken er basert på
Martin Fowler, UML Distilled, Third Edition
Addison-Wesley, 2004. ISBN 0-321-19368-7
Stoffet er primært hentet fra
kapittel 1-4 og 9-12

To ord om terminologi
Norske ord og begreper bør brukes der de
kan brukes
• UML er et engelsk-basert
modelleringsspråk.
• Norske ord brukes her sporadisk når det
er åpenbart hvilket UML-begrep vi snakker
om

Innhold
1. Intro til UML
SA/SD vs. UML
2. Funksjonskrav:
Use case-diagram
Sekvensdiagram
3. ”Informasjons-rommet”:
Klassediagram
4. ”Tilstandsrommet”:
Tilstandsmaskin
Aktivitetsdiagram
5. ”Funksjonsrommet”:
Kommunikasjonsdiagram
Andre UML-diagrammer
6. Et lite eksempel
Oppsummering

UML:
Unified Modeling Language
• Standardisert grafisk modelleringsspråk
– Primært for programvaretunge systemer
• Mange uavhengige og overlappende språk
eksisterte
• UML er en sammenstilling og formalisering av
noen av disse

UML omfatter:
1. En meta-modell
– Rigorøs definisjon av UMLbegreper
– Viktig ved bruk av UML som
programeringspråk
2. Grafisk notasjon for 13 ulike
diagramtyper
• Activity
• Class
• Communication
• Component
• Composite structure
• Deployment
• Interaction overview
• Object
• Package
• Sequence
• State machine
• Timing
• Use Case

”UML is Not Enough!”
• UML - flere diagramer enn de fleste
trenger
• UML standardisert, systemer forskjellige
– UML passer ikke alltid like godt
• Bruk bare det du har nytte av!
• Bryt reglene når det er nyttig!

Tre måter å bruke UML på
1. UML som skisse
2. UML som blåkopi
3. UML som programmeringsspråk

1. UML som skisse
Nøkkel: Selektivitet
• Bare modellere det du trenger akkurat nå
• Rask konkretisering av ideer
• Sammenlikning av alternativer
• Kommunikasjon
– Kunder
– Medarbeidere

2. UML som blåkopi
Nøkkel: Kompletthet
• Forward engineering:
– Alle detaljer som programmereren trenger å
vite
• Backwards engineering:
– Komplett grafisk ”innholdsfortegnelse” for
systemet
– Typisk automatisert prosess!

3. UML som programmeringsspråk
Nøkkel: Modellen er systemet!
• Systemmodellen utgjør kildekoden
Utfordringer:
• Modellen må inneholder ALT
• Lavnivå-algoritmer ofte modellert i tekstbaserte
prog.-språk
• Flere måter å modellere oppførsel på i UML
– Hvilke(n) skal brukes til programmering?

Denne kursbolken:
Primært ”UML som skisse”
• Myk start for nye UML-brukere
• Bare de ”viktigste” diagrammene

Innhold
1. Intro til UML
SA/SD vs. UML
2. Funksjonskrav:
Use case-diagram
Sekvensdiagram
3. ”Informasjons-rommet”:
Klassediagram
4. ”Tilstandsrommet”:
Tilstandsmaskin
Aktivitetsdiagram
5. ”Funksjonsrommet”:
Kommunikasjonsdiagram
Andre UML-diagrammer
6. Et lite eksempel
Oppsummering

Sammenliking av SA/SD og UML
• Utviklingsprosess uanvhengig av verktøy
• Sammenlikner verktøyene i lys av et typisk
prosess-rammeverk:
– Analyse (spec., oppførselsmodell)
– Konstruksjon (”byggebeskrivelse”)
– Implementasjon (programmering)
– Dokumentasjon (for systemvedlikehold)

Egenskapsrommet
Én - av uendelig mange - måter å dekomponere
systemets egenskaper på
Funksjonsrommet
(hva systemet skal gjøre)
Informasjonsrommet
(hva systemet må huske)
Tilstandsrommet
(hvordan systemet skal
reagere)

Analyse: Omgivelser,
overordnet funksjon (1/2)
SA/SD:
Kontekstdiagram
UML:
Use case-diagram
tastatur
kortautomat
Bensinstyring
Bensinkunde
Fyll bensin
pistolbryter
display

Analyse: Omgivelser,
overordnet funksjon (2/2)
SA/SD:
Hendelsesliste
UML:
Sekvensdiagram
Kunde
Kortautomat
Bensinpistol

Analyse/konstruksjon (1/3):
Informasjonsrommet
SA/SD:
Logisk datamodell
UML:
Klassediagram
farge
Bil
eies av
regNr
Bil
farge: String
regNr: String
eier
Person
Person

Analyse/konstruksjon (2/3):
Tilstandsrommet
SA/SD:
Tilstandstransisjonsdiagram
UML:
Tilstandsmaskin
(aktivitetsd, interaksjonsd.)
S1
S1
Hendelse 2
•Aksjon 2a
•Aksjon 2b
Hendelse
•Aksjon 1a
•Aksjon 1b
Hendelse 2/Aksjon
2a, Aksjon 2b
Hendelse/ Aksjon 1,
Aksjon 1b
S2
S2

Analyse/konstruksjon (3/3):
Funksjonsrommet
SA/SD:
Dataflytdiagram
UML:
Kommunikasjonsdiagram
Pros1
Data1
Data2
Pros2
2: data2
Obj1
Obj2
1: Data1

Modellering av
funksjonelle systemkrav
...eller: hvordan finne ut hva kunden
egentlig bestiller, hvordan hun tenker
og hvordan hun ønsker å bruke
systemet.

Innhold
1. Intro til UML
SA/SD vs. UML
2. Funksjonskrav:
Use case-diagram
Sekvensdiagram
3. ”Informasjons-rommet”:
Klassediagram
4. ”Tilstandsrommet”:
Tilstandsmaskin
Aktivitetsdiagram
5. ”Funksjonsrommet”:
Kommunikasjonsdiagram
Andre UML-diagrammer
6. Et lite eksempel
Oppsummering

Use case-diagrammet
Actor Association Use case
Fyll bensin
Bensinkunde

Use case = bruksmodus
• Systemet tilbyr et antall funksjoner som er
aktuelle for ulike formål, til ulike tider og
for ulike aktører
•Hvert use case er én slik ”bruksmodus”
Summen av alle use cases
=
hele systemets funksjonalitet

Eksempel:
veggmontert elektrisk bryter
Systemets grense
Lysbruker
Betjen
Montér
Montør

Actors
En Actor representerer en rolle, ikke en
entitet (person, system, fysisk enhet)
• Samme entitet kan utgjøre flere Actors
• Flere entiteter kan utgjøre samme Actor
Alle slags entiteter kan være Actors
•Personer
• Systemer eller enheter

Use case-relevant informasjon
(1/2)
Pre-conditions:
Vilkår som må være tilfredsstilt for at use
case’t kan starte
Trigger:
Hendelsen som starter use case’t

Use case-relevant informasjon
(2/2)
Guarrantee:
Det systemet vil garantere er oppfylt ved
avslutningen av use case’t
• Success guarrantee:
Det som garantert er oppfylt etter et vellykket
scenario
• Minimal guarrantee:
Det som er oppfylt etter et hvilket som helst
scenario.

Tekstlig use case-beskrivelse.
Eksempel: Montering av bryter
Montér
Pre-condition: Sikringen er tatt ut.
Trigger: Kunde bestiller
montering av bryter
Suksess-scenario:
1. Montør åpner bryterdekselet
2. Montør fester bryteren til
veggen
3. Montør fester ledningene
4. Montør lukker bryterdekselet
5. Montør setter i sikringen
6. Montør betjener bryteren og
konstaterer at den virker
Utvidelse:
6a: Bryteren virker ikke
.1: Montør fjerner sikringen
... (kopler fra bryteren...)
.n: Montør setter i sikringen
Suksessgaranti:
Bryteren montert og operativ.
Minimal garanti:
Alle strømførende ledninger
isolert eller frakoplet,
sikringen satt i.

Hvordan ikke bruke
use case-diagrammet
• Ikke bruk masse tid på å lage et
”avansert” diagram!
• Ikke prøv å synliggjøre alle spesialtilfeller
• Ikke bruk ”avansert notasjon”
KISS: Keep It Simple and Stupid!
- Alt annet er bortkastet tid!

Hvordan bruke
use case-diagrammet
Betrakt diagrammet som en oversiktlig
”innholdsfortegnelse” for systemets
funksjonalitet
• Detaljene beskrives med tekst eller andre
typer diagrammer
• Dette er den verdifulle informasjonen!

Innhold
1. Intro til UML
SA/SD vs. UML
2. Funksjonskrav:
Use case-diagram
Sekvensdiagram
3. ”Informasjons-rommet”:
Klassediagram
4. ”Tilstandsrommet”:
Tilstandsmaskin
Aktivitetsdiagram
5. ”Funksjonsrommet”:
Kommunikasjonsdiagram
Andre UML-diagrammer
6. Et lite eksempel
Oppsummering

Sekvensdiagrammet

Hva sekvensdiagrammet
viser
• Hvordan en gruppe objekter samarbeider
for å realisere en oppførsel
• Deltakerne i et scenario (sub-sett av et
use case)
• Sekvensen og naturen i
meldingsutvekslingen mellom deltakerne
• Deltakernes livsløp

Notasjonen er nesten
selvforklarende…

Synkrone vs. asynkrone meldinger
Synkron:
Senderen må vente til
meldingen er ”utført”
(typisk: metodekall)
Gammel
notasjon
Sender
Ny
notasjon
Sender
Mottaker
Mottaker
Asynkron:
Senderen fortsetter
så snart meldingen er
sendt
(typisk: meldingskø)

Hva sekvensdiagrammet
ikke viser
…iallfall ikke så veldig godt:
• Løkker (loops, ”while…”)
• Alternativer (conditionals; ”if…”, ”switch...”)
…og alt annet som ikke går i ren sekvens.

Loops and Conditionals

Hvordan (ikke) bruke
sekvensdiagrammet
Illustrere scenarier
• Ikke komplette/komplekse algoritmer
• Ikke for presis oppførselsemodellering
Unntak finnes
• Sekvensielle algoritmer
• Bilateral kommunikasjon (protokoller)

Fra funksjonelle krav til
detaljert oppførsel
...eller: fra eksternt til internt
perspektiv.

Funksjonrommets
”ortogonale dimensjoner”
Funksjonsrommet
(hva systemet skal gjøre)
Informasjonsrommet
(hva systemet må huske)
Tilstandsrommet
(hvordan systemet skal
reagere)

Innhold
1. Intro til UML
SA/SD vs. UML
2. Funksjonskrav:
Use case-diagram
Sekvensdiagram
3. ”Informasjons-rommet”:
Klassediagram
4. ”Tilstandsrommet”:
Tilstandsmaskin
Aktivitetsdiagram
5. ”Funksjonsrommet”:
Kommunikasjonsdiagram
Andre UML-diagrammer
6. Et lite eksempel
Oppsummering

”Informasjonsrommet”: Klassediagram

Klasse
Navn
Attributter
Operasjoner
BankKunde
- navn: String
- konto: KontoNummer
- pinKode: Kryptert
+ hentNavn(): String
+ hentKontoNr(): KontoNummer
+ sjekkPinKode(pin: PinKode): Boolean

Klassers egenskaper (Properties)
- to varianter:
Attributter
• ”Member-variable”
Assosiasjoner
• ”Referanser” (i
praksis pekere etc.) til
andre klasser
• Inneholder det direkte
informasjonsinnholdet
i klassen
• Informasjon relatert til
klassen selv, men
inneholdt i de
assosierte klassene

Eksempel:
attributt vs. assosiasjon
Bil
farge: String
regNr: String
*
eier
0..1
Person
navn: String
personNr: Integer
adresse: AdrType
Attributt
Assosiasjon
Begge klassene utviser egenskaper som er
relevante for Bil.

Hva er forskjellen...?
farge
regNr
Bil
eier
0..1
navn
Person
Bil
farge
regNr
eierNavn
”An attribute is the ghost of a class without attributes”

Forskjellen er...
Attributter:
”små” egenskaper (elementære datatyper)
Assosiasjoner:
mer signifikante ”ting” (egenskaper) som har
sine egne attributter

Notasjon
Tenk ”variabeldeklarasjon”.
Generell notasjon:
visbility name: type multiplicity = default {property-string}
– Kun name er obligatorisk
Noen raske eksempler:
+ farge: String [1..*] = ”sjokkrosa”
- pinKode: Digit [4]

Notasjon - Visibility
+ Public, dvs synlig utenfor klassen
- Private, dvs. usynlig utenfor klassen
m.fl.
Eksempel:
- pinKode: Digit [4]

Notasjon - Type
Igjen: tenk ”variabeldeklarasjon”.
Type angir hva slags data som kan
inneholdes i attributten
(type er irrelevant for assosiasjoner)
Eksempel:
alder: Integer
finished: Boolean

Notasjon - Multiplisitet
1 Nøyaktig én
0..2 0, 1 eller 2
* 0 eller flere
Ingen multiplisitet angitt => 1
Eksempler:
Person
barn
*
hender: Hånd [0..2]
hår: Hårstrå [*]
ektefelle
0..1

Angir tilleggsegenskaper:
Notasjon –
Property-string
readOnly
ordered
osv.
Kan ikke endres
Ordnet mende (dvs.
elementenes rekkefølge fast)
Eksempel:
navn: String = ”Nemo” {readOnly}

Bidireksjonelle assosiasjoner (1/2)
Person
eier
0..1
*
Bil
Merk to ”navigerbarhespiler”
To egenskaper som er forbundet som
”inverse”:
• Person har egenskapen
biler: Bil [*]
• Bil har egenskapen
eier: Person [0..1]

Bidireksjonelle assosiasjoner (2/2)
Person
eier
0..1 *
Bil
Hvorfor?
Begge klasser avhenger av tjenester fra
den andre
Spesiell praktisk utfordring:
Synkronisering – begge ”referansene” må
være gyldige til enhver tid

Operasjoner
Tenk ”metodedeklarasjoner”.
Generell notasjon:
visbility name (parameter list): return-type {property-string}
Eksempel:
+ sjekkPinKode(pin: PinKode): Boolean {query}

Notasjon - Property-string
Property-string angir tillegsegenskaper for
operasjonene:
query
modifier
osv.
Endrer ikke klassens tilstand
Endrer klassens tilstand
Eksempel:
+ sjekkPinKode(pin: PinKode): Boolean {query}
+ settPinKode(pin: PinKode): Boolean {modifier}

Til ettertanke
• Omverdenen aksesserer ofte properties
via aksessorer (query-operasjoner).
• Den som kaller aksessoren kan ikke
avgjøre om den mottar eksplisitt lagrede
data eller beregnede data.
• Det er mao. i utgangspunktet ingen direkte
korrelasjon mellom UML-begrepene og
programkoden.

Til etterlevelse
...derfor bør du (utviklingsteamet, bedriften)
etablere en praksis som definere en slik
korrespondanse.
Dette kan bety at du bevisst gjør en
begrenset tolkning av UML, og at du kun
benytter et subsett av notasjonen.

Notasjon - Generalisering
Arv i UML
Person
Kvinne
Mann
Frimurer

Avhengighet (Dependency)
Client Supplier
Sirkeline
Trigonometrix
dependency
Scenario: Sirkeline lager sirkler. Til dette trenger
hun funksjonalitet som Trigonometrix tilbyr.
• Hvis Trigonometrix forandrer oppførsel, kan
dette få følger for Sirkeline slik at hun også må
endre seg.
• Trigonometrix er derimot helt uavhengig av
Sirkeline.

Vær uAvhengig!
UML 2.0 definerer 10 ulike Dependencies...
• Fare: Overlessede diagrammer
• Vis bare signifikante relasjoner
• Evt. egne diagrammer med fokus på
avhengigheter
• Som skapt for automatisk reverse
engineering!!!

Hva så med alt det andre...?
Constraint Rules: I UML kan du skrive hva som
helst i diagrammet, på et hvilket som helst språk,
bare du setter det i krøllparentes:
{korrekthetssjekk: alder>0 år}
Dessuten har vi ”kommentarboksen”:
Se opp for
runde former!
Sirkeline