Systemutvikling med UML. Øyvind Stavdahl Institutt for teknisk kybernetikk, NTNU Oktober 2004

Transkript

1 Systemutvikling med UML Øyvind Stavdahl Institutt for teknisk kybernetikk, NTNU Oktober 2004

2 Denne kursbolken er basert på Martin Fowler, UML Distilled, Third Edition Addison-Wesley, ISBN Stoffet er primært hentet fra kapittel 1-4 og 9-12

3 To ord om terminologi Norske ord og begreper bør brukes der de kan brukes UML er et engelsk-basert modelleringsspråk. Norske ord brukes her sporadisk når det er åpenbart hvilket UML-begrep vi snakker om

4 Innhold 1. Intro til UML SA/SD vs. UML 2. Funksjonskrav: Use case-diagram Sekvensdiagram 3. Informasjons-rommet : Klassediagram 4. Tilstandsrommet : Tilstandsmaskin Aktivitetsdiagram 5. Funksjonsrommet : Kommunikasjonsdiagram Andre UML-diagrammer 6. Et lite eksempel Oppsummering

5 UML: Unified Modeling Language Standardisert grafisk modelleringsspråk Primært for programvaretunge systemer Mange uavhengige og overlappende språk eksisterte UML er en sammenstilling og formalisering av noen av disse

6 UML omfatter: 1. En meta-modell Rigorøs definisjon av UMLbegreper Viktig ved bruk av UML som programeringspråk 2. Grafisk notasjon for 13 ulike diagramtyper Activity Class Communication Component Composite structure Deployment Interaction overview Object Package Sequence State machine Timing Use Case

7 UML is Not Enough! UML - flere diagramer enn de fleste trenger UML standardisert, systemer forskjellige UML passer ikke alltid like godt Bruk bare det du har nytte av! Bryt reglene når det er nyttig!

8 Tre måter å bruke UML på 1. UML som skisse 2. UML som blåkopi 3. UML som programmeringsspråk

9 1. UML som skisse Nøkkel: Selektivitet Bare modellere det du trenger akkurat nå Rask konkretisering av ideer Sammenlikning av alternativer Kommunikasjon Kunder Medarbeidere

10 2. UML som blåkopi Nøkkel: Kompletthet Forward engineering: Alle detaljer som programmereren trenger å vite Backwards engineering: Komplett grafisk innholdsfortegnelse for systemet Typisk automatisert prosess!

11 3. UML som programmeringsspråk Nøkkel: Modellen er systemet! Systemmodellen utgjør kildekoden Utfordringer: Modellen må inneholder ALT Lavnivå-algoritmer ofte modellert i tekstbaserte prog.-språk Flere måter å modellere oppførsel på i UML Hvilke(n) skal brukes til programmering?

12 Denne kursbolken: Primært UML som skisse Myk start for nye UML-brukere Bare de viktigste diagrammene

14 Sammenliking av SA/SD og UML Utviklingsprosess uanvhengig av verktøy Sammenlikner verktøyene i lys av et typisk prosess-rammeverk: Analyse (spec., oppførselsmodell) Konstruksjon ( byggebeskrivelse ) Implementasjon (programmering) Dokumentasjon (for systemvedlikehold)

15 Egenskapsrommet Én - av uendelig mange - måter å dekomponere systemets egenskaper på Funksjonsrommet (hva systemet skal gjøre) Informasjonsrommet (hva systemet må huske) Tilstandsrommet (hvordan systemet skal reagere)

16 Analyse: Omgivelser, overordnet funksjon (1/2) SA/SD: Kontekstdiagram UML: Use case-diagram tastatur kortautomat Bensinstyring Bensinkunde Fyll bensin pistolbryter display

17 Analyse: Omgivelser, overordnet funksjon (2/2) SA/SD: Hendelsesliste UML: Sekvensdiagram Kunde Kortautomat Bensinpistol

18 Analyse/konstruksjon (1/3): Informasjonsrommet SA/SD: Logisk datamodell UML: Klassediagram farge Bil eies av regnr Bil farge: String regnr: String eier Person Person

19 Analyse/konstruksjon (2/3): Tilstandsrommet SA/SD: Tilstandstransisjonsdiagram UML: Tilstandsmaskin (aktivitetsd, interaksjonsd.) S1 S1 Hendelse 2 Aksjon 2a Aksjon 2b Hendelse Aksjon 1a Aksjon 1b Hendelse 2/Aksjon 2a, Aksjon 2b Hendelse/ Aksjon 1, Aksjon 1b S2 S2

20 Analyse/konstruksjon (3/3): Funksjonsrommet SA/SD: Dataflytdiagram UML: Kommunikasjonsdiagram Pros1 Data1 Data2 Pros2 2: data2 Obj1 Obj2 1: Data1

21 Modellering av funksjonelle systemkrav...eller: hvordan finne ut hva kunden egentlig bestiller, hvordan hun tenker og hvordan hun ønsker å bruke systemet.

23 Use case-diagrammet Actor Association Use case Fyll bensin Bensinkunde

24 Use case = bruksmodus Systemet tilbyr et antall funksjoner som er aktuelle for ulike formål, til ulike tider og for ulike aktører Hvert use case er én slik bruksmodus Summen av alle use cases = hele systemets funksjonalitet

25 Eksempel: veggmontert elektrisk bryter Systemets grense Lysbruker Betjen <<include>> Montér Montør

26 Actors En Actor representerer en rolle, ikke en entitet (person, system, fysisk enhet) Samme entitet kan utgjøre flere Actors Flere entiteter kan utgjøre samme Actor Alle slags entiteter kan være Actors Personer Systemer eller enheter

27 Use case-relevant informasjon (1/2) Pre-conditions: Vilkår som må være tilfredsstilt for at use case t kan starte Trigger: Hendelsen som starter use case t

28 Use case-relevant informasjon (2/2) Guarrantee: Det systemet vil garantere er oppfylt ved avslutningen av use case t Success guarrantee: Det som garantert er oppfylt etter et vellykket scenario Minimal guarrantee: Det som er oppfylt etter et hvilket som helst scenario.

29 Tekstlig use case-beskrivelse. Eksempel: Montering av bryter Montér Pre-condition: Sikringen er tatt ut. Trigger: Kunde bestiller montering av bryter Suksess-scenario: 1. Montør åpner bryterdekselet 2. Montør fester bryteren til veggen 3. Montør fester ledningene 4. Montør lukker bryterdekselet 5. Montør setter i sikringen 6. Montør betjener bryteren og konstaterer at den virker Utvidelse: 6a: Bryteren virker ikke.1: Montør fjerner sikringen... (kopler fra bryteren...).n: Montør setter i sikringen Suksessgaranti: Bryteren montert og operativ. Minimal garanti: Alle strømførende ledninger isolert eller frakoplet, sikringen satt i.

30 Hvordan ikke bruke use case-diagrammet Ikke bruk masse tid på å lage et avansert diagram! Ikke prøv å synliggjøre alle spesialtilfeller Ikke bruk avansert notasjon KISS: Keep It Simple and Stupid! - Alt annet er bortkastet tid!

31 Hvordan bruke use case-diagrammet Betrakt diagrammet som en oversiktlig innholdsfortegnelse for systemets funksjonalitet Detaljene beskrives med tekst eller andre typer diagrammer Dette er den verdifulle informasjonen!

33 Sekvensdiagrammet

34 Hva sekvensdiagrammet viser Hvordan en gruppe objekter samarbeider for å realisere en oppførsel Deltakerne i et scenario (sub-sett av et use case) Sekvensen og naturen i meldingsutvekslingen mellom deltakerne Deltakernes livsløp

35 Notasjonen er nesten selvforklarende

36 Synkrone vs. asynkrone meldinger Synkron: Senderen må vente til meldingen er utført (typisk: metodekall) Gammel notasjon Sender Ny notasjon Sender Mottaker Mottaker Asynkron: Senderen fortsetter så snart meldingen er sendt (typisk: meldingskø)

37 Hva sekvensdiagrammet ikke viser iallfall ikke så veldig godt: Løkker (loops, while ) Alternativer (conditionals; if, switch... ) og alt annet som ikke går i ren sekvens.

38 Loops and Conditionals

39 Hvordan (ikke) bruke sekvensdiagrammet Illustrere scenarier Ikke komplette/komplekse algoritmer Ikke for presis oppførselsemodellering Unntak finnes Sekvensielle algoritmer Bilateral kommunikasjon (protokoller)

40 Fra funksjonelle krav til detaljert oppførsel...eller: fra eksternt til internt perspektiv.

41 Funksjonrommets ortogonale dimensjoner Funksjonsrommet (hva systemet skal gjøre) Informasjonsrommet (hva systemet må huske) Tilstandsrommet (hvordan systemet skal reagere)

43 Informasjonsrommet : Klassediagram

44 Klasse Navn Attributter Operasjoner BankKunde - navn: String - konto: KontoNummer - pinkode: Kryptert + hentnavn(): String + hentkontonr(): KontoNummer + sjekkpinkode(pin: PinKode): Boolean

45 Klassers egenskaper (Properties) - to varianter: Attributter Member-variable Assosiasjoner Referanser (i praksis pekere etc.) til andre klasser Inneholder det direkte informasjonsinnholdet i klassen Informasjon relatert til klassen selv, men inneholdt i de assosierte klassene

46 Eksempel: attributt vs. assosiasjon Bil farge: String regnr: String * eier 0..1 Person navn: String personnr: Integer adresse: AdrType Attributt Assosiasjon Begge klassene utviser egenskaper som er relevante for Bil.

47 Hva er forskjellen...? farge regnr Bil eier 0..1 navn Person Bil farge regnr eiernavn An attribute is the ghost of a class without attributes

48 Forskjellen er... Attributter: små egenskaper (elementære datatyper) Assosiasjoner: mer signifikante ting (egenskaper) som har sine egne attributter

49 Notasjon Tenk variabeldeklarasjon. Generell notasjon: visbility name: type multiplicity = default {property-string} Kun name er obligatorisk Noen raske eksempler: + farge: String [1..*] = sjokkrosa - pinkode: Digit [4]

50 Notasjon - Visibility + Public, dvs synlig utenfor klassen - Private, dvs. usynlig utenfor klassen m.fl. Eksempel: - pinkode: Digit [4]

51 Notasjon - Type Igjen: tenk variabeldeklarasjon. Type angir hva slags data som kan inneholdes i attributten (type er irrelevant for assosiasjoner) Eksempel: alder: Integer finished: Boolean

52 Notasjon - Multiplisitet 1 Nøyaktig én , 1 eller 2 * 0 eller flere Ingen multiplisitet angitt => 1 Eksempler: Person barn * hender: Hånd [0..2] hår: Hårstrå [*] ektefelle 0..1

53 Angir tilleggsegenskaper: Notasjon Property-string readonly ordered osv. Kan ikke endres Ordnet mende (dvs. elementenes rekkefølge fast) Eksempel: navn: String = Nemo {readonly}

54 Bidireksjonelle assosiasjoner (1/2) Person eier 0..1 * Bil Merk to navigerbarhespiler To egenskaper som er forbundet som inverse : Person har egenskapen biler: Bil [*] Bil har egenskapen eier: Person [0..1]

55 Bidireksjonelle assosiasjoner (2/2) Person eier 0..1 * Bil Hvorfor? Begge klasser avhenger av tjenester fra den andre Spesiell praktisk utfordring: Synkronisering begge referansene må være gyldige til enhver tid

56 Operasjoner Tenk metodedeklarasjoner. Generell notasjon: visbility name (parameter list): return-type {property-string} Eksempel: + sjekkpinkode(pin: PinKode): Boolean {query}

57 Notasjon - Property-string Property-string angir tillegsegenskaper for operasjonene: query modifier osv. Endrer ikke klassens tilstand Endrer klassens tilstand Eksempel: + sjekkpinkode(pin: PinKode): Boolean {query} + settpinkode(pin: PinKode): Boolean {modifier}

58 Til ettertanke Omverdenen aksesserer ofte properties via aksessorer (query-operasjoner). Den som kaller aksessoren kan ikke avgjøre om den mottar eksplisitt lagrede data eller beregnede data. Det er mao. i utgangspunktet ingen direkte korrelasjon mellom UML-begrepene og programkoden.

59 Til etterlevelse...derfor bør du (utviklingsteamet, bedriften) etablere en praksis som definere en slik korrespondanse. Dette kan bety at du bevisst gjør en begrenset tolkning av UML, og at du kun benytter et subsett av notasjonen.

60 Notasjon - Generalisering Arv i UML Person Kvinne Mann Frimurer

61 Avhengighet (Dependency) Client Supplier Sirkeline <<use>> Trigonometrix dependency Scenario: Sirkeline lager sirkler. Til dette trenger hun funksjonalitet som Trigonometrix tilbyr. Hvis Trigonometrix forandrer oppførsel, kan dette få følger for Sirkeline slik at hun også må endre seg. Trigonometrix er derimot helt uavhengig av Sirkeline.

62 Vær uavhengig! UML 2.0 definerer 10 ulike Dependencies... Fare: Overlessede diagrammer Vis bare signifikante relasjoner Evt. egne diagrammer med fokus på avhengigheter Som skapt for automatisk reverse engineering!!!

63 Hva så med alt det andre...? Constraint Rules: I UML kan du skrive hva som helst i diagrammet, på et hvilket som helst språk, bare du setter det i krøllparentes: {korrekthetssjekk: alder>0 år} Dessuten har vi kommentarboksen : Se opp for runde former! Sirkeline