Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "1 Objektbasert modellering med UML (og Rational Rose ) - intro Arne Maus Inst. For Informatikk Univ. I Oslo."— Utskrift av presentasjonen:

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

2 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 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 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 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 6 Faser, aktiviteter, iterasjoner og produkter (Rational)

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

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

11

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

18

19

20 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 21 Klassediagram eksempel 1

22 22 class-diagram (I)

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

24 24 class-diagram (III)

25

26

27

28

29 29 arv

30 30 object diagram  Viser forholdet mellom noen objekter (ofte av angitt type) under eksekvering  Brukes til å eksemplifisere bruk av klassene i implementasjonen. DagSjøberg ArneMaus in219 foreleser

31 31 sequence diagram

32 32 sequence diagram, Studentregistrering - eksempel

33 33 Parallellitet i sekvensdiagrammer Asynkron melding (sender fortsetter) new returOK Objektet terminerer (’delete’ på seg selv) Pallellisering controller Beregning prosess 1 Beregning prosess 2 Vanlig sekvensielt kall

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

35

36 36 collaboration diagram

37 37 Samarbeids-diagram (generert fra sekvensdiagrammet)

38 38 object diagram  Viser forholdet mellom noen objekter (ofte av angitt type) under eksekvering  Brukes til å eksemplifisere bruk av klassene i implementasjonen. DagSjøberg ArneMaus in219 foreleser

39 39 Parallellitet i sekvensdiagrammer Asynkron melding (sender fortsetter) new returOK Objektet terminerer (’delete’ på seg selv) Pallellisering controller Beregning prosess 1 Beregning prosess 2 Vanlig sekvensielt kall

40 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 42 activity diagram Finn drikke Finn ColaFinn kopperTa i vann Putt kaffe i Sett i filter Skru på Trakt kaffe Hell kaffeDrikk Start Kaffe = NEI Kaffe = JA Cola ? Cola = JA Cola = NEI Inneholder brede linjer som sprer og samler parallelle aktiviteter. Slutt

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

44 44 deployment diagram

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


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

Liknende presentasjoner


Annonser fra Google