Objektbasert modellering med UML (og Rational Rose ) - intro

Presentasjon om: "Objektbasert modellering med UML (og Rational Rose ) - intro"— Utskrift av presentasjonen:

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 Mathiassen: OO systemutvikling - modell, bruk og arkitektur
Analyse av problemområde Design av arkitektur Analyse av bruk og grensesnitt OO- modell Spek. av Bruker- krav system- komponenter

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

11

12 Rational og UML Rational UML
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: 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 ) 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

18

19

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)

25

26

27

28

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) Beregning prosess 1 new new Beregning prosess 2 Vanlig sekvensielt kall returOK returOK

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

35

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) Beregning prosess 1 new new Beregning prosess 2 Vanlig sekvensielt kall 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)

41

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

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