1 / 46

Objektbasert modellering med UML (og Rational Rose ) - intro

Objektbasert modellering med UML (og Rational Rose ) - intro. Arne Maus Inst. For Informatikk Univ. I Oslo. Hvorfor lager vi modeller. Som hus-arkitekter, må enhver ansvarlig (programvare-) ingeniør lage en modell før man lager den virkelige konstruksjonen.

bly
Télécharger la présentation

Objektbasert modellering med UML (og Rational Rose ) - intro

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

  18. Klassediagram eksempel 1

  19. class-diagram (I)

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

  21. class-diagram (III)

  22. arv

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

  24. sequence diagram

  25. sequence diagram, Studentregistrering - eksempel

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

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

  28. collaboration diagram

  29. Samarbeids-diagram (generert fra sekvensdiagrammet)

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

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

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

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

  35. deployment diagram

  36. 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 ?

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

More Related