Transcript Objektbasert modellering med UML (og Rational Rose )
Slide 1
Objektbasert modellering med
UML (og Rational Rose ) - intro
Arne Maus
Inst. For Informatikk
Univ. I Oslo
1
Slide 2
Hvorfor lager vi modeller
Som hus-arkitekter, må enhver ansvarlig (programvare-)
ingeniør lage en modell før man lager den virkelige
konstruksjonen.
Enkle konstruksjoner (< 1 dagsverk) trenger bare enkle modeller
Vi trenger derfor modeller for våre kompliserte systemer:
Synliggjøre konstruksjonen og alternativer (for oss selv)
Beherske kompleksitet - oversikt og oppdeling
Kommunikasjon mellom flere utviklere - og med
brukere/oppdragsgiver
Vi trenger flere typer og flere modeller - ulike perspektiver på:
ulike egenskaper ved (hele) systemet
modeller for deler av systemet
Sentralt i modellering av alle systemer står ulike diagramtyper.
2
Slide 3
”full pakke” for OO systemutvikling
Systemutviklings-modell (prosess) :
I.Jacobson, G. Booch, J. Rumbaugh:’The Unified Software
Development Process’, Addison Wesley, 1999
Notasjon/diagrammer/dokumentasjon for
analyse/kravspesifikasjon og design: UML (ver 1.3)
Verktøy for sømløs utvikling fra spesifikasjon/analyse til kode :
f.eks Rational Rose XDE
Verktøy for kode-bearbeiding (kompilering, debugging,
versjoner og varianter..): eks: Visual Studio /.NET
Database modellering og sammenknytning : eks: ERWin
Tilsvarende RationalRose mot databaser (forward- og reverseengineering av ER-diagrammer mot relasjonsdatabaser)
3
Slide 4
OO systemutviklings-prosesser:
Iterative - dvs. ikke som fossefallsmodellen, hvor en fase
fullføres / sluttføres før neste fase tar til :
(Fossefalls-fasene: Kravspesifikasjon, system spesifikasjon,
arkitekturdesign, grensesnittdesign, detaljert design, koding,
enhetstesting, modultesting, integrasjonstesting, system/beta-testing,
akseptansetest, leveranse, vedlikehold)
OO har ofte tidlige prototyper, som Boems spiralmodell
Fleksibel, tilpasses problemtype
ulike diagramtyper
ulik vekt på ulike faser
Ikke teoretisk, men pragmatisk
Analyse (kalles ofte kravspesifikasjon) og design tett
sammenvevet
Mange foreslag er nær sammenfallede (Rational, Mathiassen,..)
4
Slide 5
RUP fra Rational – ellers UP:
Prosjektet deles inn i 4 faser:
Forprosjekt
(Videre)utvikling
Konstruksjon
Transisjon, ferdiggjøring
Hele tiden holder vi på med flg. aktiviteter med produkter som
resultat
Kravspesifikasjon
- bruksbeskrivelser
Design
arkitektur
- designmodell for system, moduloppdeling
klasser
- designmodell for klasser
Implementasjon
- implementasjonsmodell (programmkoden)
Test
- testplan
Prosjektledelse
- prosjektplaner
Prosesskonfigurering - beskrivelser, retningslinjer
Bortsett fra i forprosjekt-fasen, itererer vi disse aktivitetene og forbedrer
produktene en rekke ganger: 1,2,..,m
5
Slide 6
Faser, aktiviteter, iterasjoner og
produkter (Rational)
6
Slide 7
Rationals systemutviklingsprosess
Meget godt beskrevet i Martin Fowler & Kendall Scott: ”UML
Distilled”
Ikke formell - behøver ikke å beskrive hele systemet med
diagrammer etc. før man skriver koden
Diagrammene er for:
selv å holder oversikt over oppdelingen av systemet og logikken i
systemet
kommunikasjon innad i prosjektet
hjelp i utformingen av vanskelige punkter
dokumentasjon av vanskelige punkter
skal være en hjelp - ikke tvangstrøye
UML er dekket av flere verktøy - bl.a Rational Rose, men man
7
trenger alltid ikke fancy verktøy
Slide 8
Mathiassen: OO systemutvikling modell, bruk og arkitektur
OO-
Bruker-
modell
krav
Analyse av
bruk og
grensesnitt
Analyse av
Design av
problemområde
komponenter
Spek. av
Spek. av
system-
arkitektur
komponenter
Design av
arkitektur
8
Slide 9
Mathiassen: OO systemutvikling (II)
Problemområde:
Bruk og grensesnitt ( anvendelsesområdet)
Analyse av den organisasjon (med brukere og andre systemer)
som skal nytte det nye edb-systemet
Arkitektur
Analyse av det systemet vi skal lage et edb-system for
Finne ut hvilke objekter, deler det består av for vårt formål
Hvordan gruppere programvaren i (større) komponenter
Hvordan fordele programkomponentene på maskinutstyret
Baserer seg på UML notasjon i analyse og design
9
Slide 10
UML og Rational Rose oversikt
UML og Rational Rose
Er begge laget av samme firma, som eies av de 3 store innen OO
analyse&design (’the three amigos’): I.Jacobsen, G. Booch, J.
Rumbaugh.
UML:
vedtatt ’industristandard’ for OO-analyse/design diagrammer
Rational Rose: CASE-verktøy for spesifikasjon, analyse, design og
kodegenereringsfasene av et prosjekt
Tegneverktøy for alle typer UML-diagrammer med utfyllende tekster
Generer kode (C++, Visual Basic, Java,..) fra diagrammene
(forward engineering)
Genererer UML diagrammer fra gammel kode - og:
Oppdaterer eksisterende UML-diagrammer fra korreksjoner/tillegg i koden
(reverse engineering)
Meget dyrt
10
Slide 11
Slide 12
Rational og UML
Rational
Firma som laget et OO-CASE-vektøy ROSE og har slått seg sammen
med/kjøpt opp :
Atria (som lager Quantify og Purify)
Objectory (som var firmaet til I. Jacobson)
Se: http://www.rational.com for nedlasting av UML - dokumenter og gratis demo
(9.5 Mb) av RationalRose for WinNT
Ser ut til å bli en vinner, brukes bla. av SDS og Norges Bank med positive
erfaringer
UML
Den viktigste av flere forslåtte standarder for OO diagrammer
Ett diagram kan aldri si alt om et system / en modell
9 ulike diagramtyper - hver viser ulike aspekter ved en del av systemet
(noen typer nyttes oftere enn andre)
UML brukes av mange metoder (er uavhengig av RationalRose)
Anbefalte bøker:
Martin Fowler &Kendal Scott : ” UML distilled” Addison Wesley 1999
L. Matiassen, A. Munck-Madsen, P.A. Nielsen, J. Stage:
” Objektorientert analyse og design”,
MARKO Aalborg 1997, (ISBN 87-7751-123-9)
Craig Larman : Applying UML and Patterns, sec.ed. Prentice Hall 2002
Slide 13
UML Unified Modeling Language
Definerer notasjon og semantikk for:
class-diagram * * *
- forhold mellom klassene og pakker, statisk og dynamisk
object diagram **
- typisk forhold mellom noen objekter ved et tidspunkt
use case diagram* * *
-
sequence diagram * *
- rekkefølge på kall/meldinger mellom klasser
collaboration diagram *
- interaksjon og forhold mellom objektene(sqd-,cd-)
state diagram *
-
tilstandsdiagram for ett eller flere samvirkende objekter
activity diagram *
-
spesialtilfelle av std
component diagram
- organisering og forhold mellom moduler / pakker
deployment diagram
- hvordan systemets deler er distribuert på maskinvaren.
hovedfunksjonalitet mellom bruker og system
13
Slide 14
Sentrale UML begreper (I)
klasser, subklasse, innkapsling, polymorfisme (virtuelle) og objekter
pakke
modul
utveksling av en melding (ved prosedyrekall) fra ett objekt til et annet
assosiasjon
programvare-enhet som kompileres separat
melding
ansamling av klasser og evt. andre pakker
forhold/avhengighet mellom to klasser - med antall-begrensninger
(f.eks: ansatte og lønn, hus og eier, vare og selger, vare og regning..)
aggregering
betegner at et objekt inneholder/består av et visst antall andre objekter (en
bil har fire hjul, en stor bedrift har mange ansatte,..)
14
Slide 15
Sentrale UML begreper (II)
synkron/asynkron meldingsutveksling
Sendende objekt venter/venter-ikke på svar før det fortsetter
samarbeid (collaboration)
flere objekter som løser en oppgave ved utveksling av meldinger
synspunkt (view)
spesielt syn på (del av) modellen - utelater ikke-interessante detaljer
Skillet mellom assosiasjon og aggregering er ikke alltid like klart i praksis,
UML opererer også med enda et begrep:
sammensetting (composition) (= alltid-del-av)
Sterkere enn aggregering - betegner livslangt, fast forhold som ikke kan
brytes (et menneske har en hjerne og et hjerte, et fly har vinger ,..)
I praksis er dette skillet ikke så viktig, men assosiasjon, aggregering, composition
betegner svak-middels, sterk, alltid forbindelse mellom objekter
15
Slide 16
Ulike systemer kan modelleres
Administrativ edb
Tekniske , naturvitenskapelig databehandling
Use cases, klassediagrammer, sekvensdiagrammer,
deployment
(use cases), klassediagrammer,
sekvensdiagrammer, tilstandsdiagrammer
Sanntidssystemer
use cases, klassediagrammer,
aktivitetsdiagrammer, sekvensdiagrammer,
tilstands-diagrammer
16
Slide 17
use case
Brukes først i analysen
Lettest: Finne først noen aktører
Deretter finne typisk brukssituasjoner for disse
Utfyller disse senere med sekvensdiagram for hvert interessante
’use case’
Arranger eksamen
Meld på kurs
student
Opprett nytt kurs
Foreleser
Registrer påmelding
Stud-adm
Skriv vitnemål
17
Slide 18
Slide 19
Slide 20
Klasse-diagrammer beskriver:
Ulike typene av objekter i systemet
De forhold objekter av disse klassene evt. har til
hverandre
assosiasjon (tilknytning):
a) inneholder / aggregering
(eks : en student har tatt 20 eksamner, en datamaskin har 2
CPUer)
b) annen tilknytning/ bruker/kaller prosedyre i
(eks: en student melder seg til et kurs hos en studie-adm objekt,
en kunde tar ut penger fra et konto-objekt via en
minibankobjekt,..)
Antall objekter på hver side av forholdet (f.eks: 1 - til -mange)
Evt. subklasse (eks: en student er en subklasse av klassen
person)
20
Slide 21
Klassediagram eksempel
1
21
Slide 22
class-diagram (I)
22
Slide 23
class-diagram (II)
forhold mellom klassene, statisk og dynamisk
23
Slide 24
class-diagram (III)
24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
arv
29
Slide 30
object diagram
Viser forholdet mellom noen objekter (ofte av
angitt type) under eksekvering
Brukes til å eksemplifisere bruk av klassene i
implementasjonen.
ArneMaus
DagSjøberg
foreleser
foreleser
in219
30
Slide 31
sequence diagram
31
Slide 32
sequence diagram,
Studentregistrering - eksempel
32
Slide 33
Parallellitet i sekvensdiagrammer
Asynkron melding
(sender fortsetter)
Pallellisering
controller
new
Beregning
prosess 1
new
Beregning
prosess 2
Objektet terminerer
(’delete’ på seg selv)
Vanlig
sekvensielt
kall
returOK
returOK
33
Slide 34
Automatisk generert prosedyre i
’kurs.cpp’ - tatt fra VisualC++
Slide 35
Slide 36
collaboration diagram
36
Slide 37
Samarbeids-diagram (generert fra
sekvensdiagrammet)
37
Slide 38
object diagram
Viser forholdet mellom noen objekter (ofte av
angitt type) under eksekvering
Brukes til å eksemplifisere bruk av klassene i
implementasjonen.
ArneMaus
DagSjøberg
foreleser
foreleser
in219
38
Slide 39
Parallellitet i sekvensdiagrammer
Asynkron melding
(sender fortsetter)
Pallellisering
controller
new
Beregning
prosess 1
new
Beregning
prosess 2
Objektet terminerer
(’delete’ på seg selv)
Vanlig
sekvensielt
kall
returOK
returOK
39
Slide 40
tilstands-diagram
(state diagram)
Brukes til å vise hvordan ett enkelt objekt oppfører seg over
flere ’use cases’
= mulige endringer i objektet og handlinger fra dette
ved ytre påvirkning
(ved kall/signaler/inndata fra brukere, andre objekter eller
systemer)
40
Slide 41
Slide 42
activity diagram
Finn drikke
Kaffe = NEI
Start
Cola = NEI
Cola ?
Kaffe = JA
Cola = JA
Sett i filter
Ta i vann
Finn kopper
Finn Cola
Putt kaffe i
Skru på
Inneholder brede
linjer som sprer
og samler
parallelle
aktiviteter.
Trakt kaffe
Hell kaffe
Drikk
Slutt
42
Slide 43
component (pakke) diagram
Pakke
navn 2
Pakke navn 1
klasse 1
klasse 3
klasse 2
43
Slide 44
deployment diagram
44
Slide 45
Hva kan vi oppnå med UML
Oversikt og oppdeling (for deg og prosjektet)
Kommunikasjon med andre
Gjenbruk av analyse/design
Bedre utgangspunkt for kode enn:
et gammelt ’lignende system’
en udokumentert (i-hodet) ide
Kan vedlikeholdes effektivt
Bedret dokumentasjon
UML har mangler - mangler f.eks. kobling mot mer
formelle metoder (som: Z) og databaser
Går vi mot ’visuell’ programmering ?
45
Slide 46
Erfaringer med RRose &
VisualC++
Generelt sett gode
Uhyggelig mange opsjoner (plassering,
kodegenerering.. etc)
Lett å få plassert kode i feil katalog
Standardopsjonene virket rimelig OK
Rational har ca 13 utviklingsverktøy på
hjemmesidene sine.
Meget dyre brukerlisenser
Genererer bare skjelettkode fra klassediagram
Det finnes tilleggsverktøy som genererer kode fra
sekvensdiagrammet
46
Objektbasert modellering med
UML (og Rational Rose ) - intro
Arne Maus
Inst. For Informatikk
Univ. I Oslo
1
Slide 2
Hvorfor lager vi modeller
Som hus-arkitekter, må enhver ansvarlig (programvare-)
ingeniør lage en modell før man lager den virkelige
konstruksjonen.
Enkle konstruksjoner (< 1 dagsverk) trenger bare enkle modeller
Vi trenger derfor modeller for våre kompliserte systemer:
Synliggjøre konstruksjonen og alternativer (for oss selv)
Beherske kompleksitet - oversikt og oppdeling
Kommunikasjon mellom flere utviklere - og med
brukere/oppdragsgiver
Vi trenger flere typer og flere modeller - ulike perspektiver på:
ulike egenskaper ved (hele) systemet
modeller for deler av systemet
Sentralt i modellering av alle systemer står ulike diagramtyper.
2
Slide 3
”full pakke” for OO systemutvikling
Systemutviklings-modell (prosess) :
I.Jacobson, G. Booch, J. Rumbaugh:’The Unified Software
Development Process’, Addison Wesley, 1999
Notasjon/diagrammer/dokumentasjon for
analyse/kravspesifikasjon og design: UML (ver 1.3)
Verktøy for sømløs utvikling fra spesifikasjon/analyse til kode :
f.eks Rational Rose XDE
Verktøy for kode-bearbeiding (kompilering, debugging,
versjoner og varianter..): eks: Visual Studio /.NET
Database modellering og sammenknytning : eks: ERWin
Tilsvarende RationalRose mot databaser (forward- og reverseengineering av ER-diagrammer mot relasjonsdatabaser)
3
Slide 4
OO systemutviklings-prosesser:
Iterative - dvs. ikke som fossefallsmodellen, hvor en fase
fullføres / sluttføres før neste fase tar til :
(Fossefalls-fasene: Kravspesifikasjon, system spesifikasjon,
arkitekturdesign, grensesnittdesign, detaljert design, koding,
enhetstesting, modultesting, integrasjonstesting, system/beta-testing,
akseptansetest, leveranse, vedlikehold)
OO har ofte tidlige prototyper, som Boems spiralmodell
Fleksibel, tilpasses problemtype
ulike diagramtyper
ulik vekt på ulike faser
Ikke teoretisk, men pragmatisk
Analyse (kalles ofte kravspesifikasjon) og design tett
sammenvevet
Mange foreslag er nær sammenfallede (Rational, Mathiassen,..)
4
Slide 5
RUP fra Rational – ellers UP:
Prosjektet deles inn i 4 faser:
Forprosjekt
(Videre)utvikling
Konstruksjon
Transisjon, ferdiggjøring
Hele tiden holder vi på med flg. aktiviteter med produkter som
resultat
Kravspesifikasjon
- bruksbeskrivelser
Design
arkitektur
- designmodell for system, moduloppdeling
klasser
- designmodell for klasser
Implementasjon
- implementasjonsmodell (programmkoden)
Test
- testplan
Prosjektledelse
- prosjektplaner
Prosesskonfigurering - beskrivelser, retningslinjer
Bortsett fra i forprosjekt-fasen, itererer vi disse aktivitetene og forbedrer
produktene en rekke ganger: 1,2,..,m
5
Slide 6
Faser, aktiviteter, iterasjoner og
produkter (Rational)
6
Slide 7
Rationals systemutviklingsprosess
Meget godt beskrevet i Martin Fowler & Kendall Scott: ”UML
Distilled”
Ikke formell - behøver ikke å beskrive hele systemet med
diagrammer etc. før man skriver koden
Diagrammene er for:
selv å holder oversikt over oppdelingen av systemet og logikken i
systemet
kommunikasjon innad i prosjektet
hjelp i utformingen av vanskelige punkter
dokumentasjon av vanskelige punkter
skal være en hjelp - ikke tvangstrøye
UML er dekket av flere verktøy - bl.a Rational Rose, men man
7
trenger alltid ikke fancy verktøy
Slide 8
Mathiassen: OO systemutvikling modell, bruk og arkitektur
OO-
Bruker-
modell
krav
Analyse av
bruk og
grensesnitt
Analyse av
Design av
problemområde
komponenter
Spek. av
Spek. av
system-
arkitektur
komponenter
Design av
arkitektur
8
Slide 9
Mathiassen: OO systemutvikling (II)
Problemområde:
Bruk og grensesnitt ( anvendelsesområdet)
Analyse av den organisasjon (med brukere og andre systemer)
som skal nytte det nye edb-systemet
Arkitektur
Analyse av det systemet vi skal lage et edb-system for
Finne ut hvilke objekter, deler det består av for vårt formål
Hvordan gruppere programvaren i (større) komponenter
Hvordan fordele programkomponentene på maskinutstyret
Baserer seg på UML notasjon i analyse og design
9
Slide 10
UML og Rational Rose oversikt
UML og Rational Rose
Er begge laget av samme firma, som eies av de 3 store innen OO
analyse&design (’the three amigos’): I.Jacobsen, G. Booch, J.
Rumbaugh.
UML:
vedtatt ’industristandard’ for OO-analyse/design diagrammer
Rational Rose: CASE-verktøy for spesifikasjon, analyse, design og
kodegenereringsfasene av et prosjekt
Tegneverktøy for alle typer UML-diagrammer med utfyllende tekster
Generer kode (C++, Visual Basic, Java,..) fra diagrammene
(forward engineering)
Genererer UML diagrammer fra gammel kode - og:
Oppdaterer eksisterende UML-diagrammer fra korreksjoner/tillegg i koden
(reverse engineering)
Meget dyrt
10
Slide 11
Slide 12
Rational og UML
Rational
Firma som laget et OO-CASE-vektøy ROSE og har slått seg sammen
med/kjøpt opp :
Atria (som lager Quantify og Purify)
Objectory (som var firmaet til I. Jacobson)
Se: http://www.rational.com for nedlasting av UML - dokumenter og gratis demo
(9.5 Mb) av RationalRose for WinNT
Ser ut til å bli en vinner, brukes bla. av SDS og Norges Bank med positive
erfaringer
UML
Den viktigste av flere forslåtte standarder for OO diagrammer
Ett diagram kan aldri si alt om et system / en modell
9 ulike diagramtyper - hver viser ulike aspekter ved en del av systemet
(noen typer nyttes oftere enn andre)
UML brukes av mange metoder (er uavhengig av RationalRose)
Anbefalte bøker:
Martin Fowler &Kendal Scott : ” UML distilled” Addison Wesley 1999
L. Matiassen, A. Munck-Madsen, P.A. Nielsen, J. Stage:
” Objektorientert analyse og design”,
MARKO Aalborg 1997, (ISBN 87-7751-123-9)
Craig Larman : Applying UML and Patterns, sec.ed. Prentice Hall 2002
Slide 13
UML Unified Modeling Language
Definerer notasjon og semantikk for:
class-diagram * * *
- forhold mellom klassene og pakker, statisk og dynamisk
object diagram **
- typisk forhold mellom noen objekter ved et tidspunkt
use case diagram* * *
-
sequence diagram * *
- rekkefølge på kall/meldinger mellom klasser
collaboration diagram *
- interaksjon og forhold mellom objektene(sqd-,cd-)
state diagram *
-
tilstandsdiagram for ett eller flere samvirkende objekter
activity diagram *
-
spesialtilfelle av std
component diagram
- organisering og forhold mellom moduler / pakker
deployment diagram
- hvordan systemets deler er distribuert på maskinvaren.
hovedfunksjonalitet mellom bruker og system
13
Slide 14
Sentrale UML begreper (I)
klasser, subklasse, innkapsling, polymorfisme (virtuelle) og objekter
pakke
modul
utveksling av en melding (ved prosedyrekall) fra ett objekt til et annet
assosiasjon
programvare-enhet som kompileres separat
melding
ansamling av klasser og evt. andre pakker
forhold/avhengighet mellom to klasser - med antall-begrensninger
(f.eks: ansatte og lønn, hus og eier, vare og selger, vare og regning..)
aggregering
betegner at et objekt inneholder/består av et visst antall andre objekter (en
bil har fire hjul, en stor bedrift har mange ansatte,..)
14
Slide 15
Sentrale UML begreper (II)
synkron/asynkron meldingsutveksling
Sendende objekt venter/venter-ikke på svar før det fortsetter
samarbeid (collaboration)
flere objekter som løser en oppgave ved utveksling av meldinger
synspunkt (view)
spesielt syn på (del av) modellen - utelater ikke-interessante detaljer
Skillet mellom assosiasjon og aggregering er ikke alltid like klart i praksis,
UML opererer også med enda et begrep:
sammensetting (composition) (= alltid-del-av)
Sterkere enn aggregering - betegner livslangt, fast forhold som ikke kan
brytes (et menneske har en hjerne og et hjerte, et fly har vinger ,..)
I praksis er dette skillet ikke så viktig, men assosiasjon, aggregering, composition
betegner svak-middels, sterk, alltid forbindelse mellom objekter
15
Slide 16
Ulike systemer kan modelleres
Administrativ edb
Tekniske , naturvitenskapelig databehandling
Use cases, klassediagrammer, sekvensdiagrammer,
deployment
(use cases), klassediagrammer,
sekvensdiagrammer, tilstandsdiagrammer
Sanntidssystemer
use cases, klassediagrammer,
aktivitetsdiagrammer, sekvensdiagrammer,
tilstands-diagrammer
16
Slide 17
use case
Brukes først i analysen
Lettest: Finne først noen aktører
Deretter finne typisk brukssituasjoner for disse
Utfyller disse senere med sekvensdiagram for hvert interessante
’use case’
Arranger eksamen
Meld på kurs
student
Opprett nytt kurs
Foreleser
Registrer påmelding
Stud-adm
Skriv vitnemål
17
Slide 18
Slide 19
Slide 20
Klasse-diagrammer beskriver:
Ulike typene av objekter i systemet
De forhold objekter av disse klassene evt. har til
hverandre
assosiasjon (tilknytning):
a) inneholder / aggregering
(eks : en student har tatt 20 eksamner, en datamaskin har 2
CPUer)
b) annen tilknytning/ bruker/kaller prosedyre i
(eks: en student melder seg til et kurs hos en studie-adm objekt,
en kunde tar ut penger fra et konto-objekt via en
minibankobjekt,..)
Antall objekter på hver side av forholdet (f.eks: 1 - til -mange)
Evt. subklasse (eks: en student er en subklasse av klassen
person)
20
Slide 21
Klassediagram eksempel
1
21
Slide 22
class-diagram (I)
22
Slide 23
class-diagram (II)
forhold mellom klassene, statisk og dynamisk
23
Slide 24
class-diagram (III)
24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
arv
29
Slide 30
object diagram
Viser forholdet mellom noen objekter (ofte av
angitt type) under eksekvering
Brukes til å eksemplifisere bruk av klassene i
implementasjonen.
ArneMaus
DagSjøberg
foreleser
foreleser
in219
30
Slide 31
sequence diagram
31
Slide 32
sequence diagram,
Studentregistrering - eksempel
32
Slide 33
Parallellitet i sekvensdiagrammer
Asynkron melding
(sender fortsetter)
Pallellisering
controller
new
Beregning
prosess 1
new
Beregning
prosess 2
Objektet terminerer
(’delete’ på seg selv)
Vanlig
sekvensielt
kall
returOK
returOK
33
Slide 34
Automatisk generert prosedyre i
’kurs.cpp’ - tatt fra VisualC++
Slide 35
Slide 36
collaboration diagram
36
Slide 37
Samarbeids-diagram (generert fra
sekvensdiagrammet)
37
Slide 38
object diagram
Viser forholdet mellom noen objekter (ofte av
angitt type) under eksekvering
Brukes til å eksemplifisere bruk av klassene i
implementasjonen.
ArneMaus
DagSjøberg
foreleser
foreleser
in219
38
Slide 39
Parallellitet i sekvensdiagrammer
Asynkron melding
(sender fortsetter)
Pallellisering
controller
new
Beregning
prosess 1
new
Beregning
prosess 2
Objektet terminerer
(’delete’ på seg selv)
Vanlig
sekvensielt
kall
returOK
returOK
39
Slide 40
tilstands-diagram
(state diagram)
Brukes til å vise hvordan ett enkelt objekt oppfører seg over
flere ’use cases’
= mulige endringer i objektet og handlinger fra dette
ved ytre påvirkning
(ved kall/signaler/inndata fra brukere, andre objekter eller
systemer)
40
Slide 41
Slide 42
activity diagram
Finn drikke
Kaffe = NEI
Start
Cola = NEI
Cola ?
Kaffe = JA
Cola = JA
Sett i filter
Ta i vann
Finn kopper
Finn Cola
Putt kaffe i
Skru på
Inneholder brede
linjer som sprer
og samler
parallelle
aktiviteter.
Trakt kaffe
Hell kaffe
Drikk
Slutt
42
Slide 43
component (pakke) diagram
Pakke
navn 2
Pakke navn 1
klasse 1
klasse 3
klasse 2
43
Slide 44
deployment diagram
44
Slide 45
Hva kan vi oppnå med UML
Oversikt og oppdeling (for deg og prosjektet)
Kommunikasjon med andre
Gjenbruk av analyse/design
Bedre utgangspunkt for kode enn:
et gammelt ’lignende system’
en udokumentert (i-hodet) ide
Kan vedlikeholdes effektivt
Bedret dokumentasjon
UML har mangler - mangler f.eks. kobling mot mer
formelle metoder (som: Z) og databaser
Går vi mot ’visuell’ programmering ?
45
Slide 46
Erfaringer med RRose &
VisualC++
Generelt sett gode
Uhyggelig mange opsjoner (plassering,
kodegenerering.. etc)
Lett å få plassert kode i feil katalog
Standardopsjonene virket rimelig OK
Rational har ca 13 utviklingsverktøy på
hjemmesidene sine.
Meget dyre brukerlisenser
Genererer bare skjelettkode fra klassediagram
Det finnes tilleggsverktøy som genererer kode fra
sekvensdiagrammet
46