Objektbasert modellering med UML (og Rational Rose ) - intro

1. Objektbasert modellering med UML (og Rational Rose ) - intro Arne Maus Inst. For Informatikk Univ. I Oslo

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.

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 reverse-engineering av ER-diagrammer mot relasjonsdatabaser)

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,..)

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

6. Faser, aktiviteter, iterasjoner og produkter (Rational)

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 trenger alltid ikke fancy verktøy

8. OO- modell Bruker- krav Analyse av bruk og grensesnitt Analyse av problemområde Design av komponenter Spek. av system- komponenter Spek. av arkitektur Design av arkitektur Mathiassen: OO systemutvikling - modell, bruk og arkitektur

9. Mathiassen: OO systemutvikling (II) • Problemområde: • 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 • Bruk og grensesnitt ( anvendelsesområdet) • Analyse av den organisasjon (med brukere og andre systemer) som skal nytte det nye edb-systemet • Arkitektur • Hvordan gruppere programvaren i (større) komponenter • Hvordan fordele programkomponentene på maskinutstyret • Baserer seg på UML notasjon i analyse og design

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

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

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* * * - hovedfunksjonalitet mellom bruker og system • 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.

14. Sentrale UML begreper (I) • klasser, subklasse, innkapsling, polymorfisme (virtuelle) og objekter • pakke • ansamling av klasser og evt. andre pakker • modul • programvare-enhet som kompileres separat • melding • utveksling av en melding (ved prosedyrekall) fra ett objekt til et annet • assosiasjon • 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,..)

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

16. Ulike systemer kan modelleres • Administrativ edb • Use cases, klassediagrammer, sekvensdiagrammer, deployment • Tekniske , naturvitenskapelig databehandling • (use cases), klassediagrammer, sekvensdiagrammer, tilstandsdiagrammer • Sanntidssystemer • use cases, klassediagrammer, aktivitetsdiagrammer, sekvensdiagrammer, tilstands-diagrammer

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’ Meld på kurs Arranger eksamen student Opprett nytt kurs Foreleser Registrer påmelding Stud-adm Skriv vitnemål

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)

21. Klassediagram eksempel 1

22. class-diagram (I)

23. class-diagram (II) • forhold mellom klassene, statisk og dynamisk

24. class-diagram (III)

29. arv

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

31. sequence diagram

32. sequence diagram, Studentregistrering - eksempel

33. Parallellitet i sekvensdiagrammer Asynkron melding(sender fortsetter) Pallellisering controller Objektet terminerer(’delete’ på seg selv) Beregningprosess 1 new Beregningprosess 2 new Vanlig sekvensieltkall returOK returOK

34. Automatisk generert prosedyre i ’kurs.cpp’ - tatt fra VisualC++

36. collaboration diagram

37. Samarbeids-diagram (generert fra sekvensdiagrammet)

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

39. Parallellitet i sekvensdiagrammer Asynkron melding(sender fortsetter) Pallellisering controller Objektet terminerer(’delete’ på seg selv) Beregningprosess 1 new Beregningprosess 2 new Vanlig sekvensieltkall returOK returOK

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)

42. Kaffe = NEI Cola = NEI Finn drikke Cola ? Start Kaffe = JA Cola = JA Ta i vann Finn kopper Finn Cola Sett i filter Putt kaffe i Skru på Inneholder brede linjer som sprer og samler parallelle aktiviteter. Trakt kaffe Slutt Hell kaffe Drikk activity diagram

43. component (pakke) diagram Pakke navn 2 klasse 1 Pakke navn 1 klasse 3 klasse 2

44. deployment diagram

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 ?

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