UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram Implementasjonsdiagrammer Komponentdiagram Deployment diagram 1 2 Prosess-oversikt Spørreskjema Spørsmål UC Generer Spørreskjema 1.. Use case modell 2. 3. 4. Use case Black box Svar Metode: nyttspørreskjema() Kontrakter Domenemodell Use case modell Use case realisering En betegnelse fra Rational Unified Process (RUP) Beskriver forbindelsen mellom kravene uttrykt i use casene og objektdesignet som oppfyller disse kravene Beskriver hvordan scenariene i et use case realiseres gjennom objekter som samarbeider Illustreres med sekvensdiagrammer Designmodell 3 4 1
Prinsipper og teknikker Analyse Teknikker: Use case modellering Domenemodellering Use case drevet design Teknikker: Interaksjonsdiagrammer: Sekvensdiagram og kollaborasjonsdiagram Ansvarsdrevet design Teknikker: Use case realisering med sekvensdiagrammer Designmodellering med sekvensdiagrammer Design patterns (mønstre) Oppsummering av metoden Analyse 1 Identifiser aktører og deres mål 2 Lag et høynivå use case diagram 3 Spesifiser hvert use case tekstlig med normal hendelsesflyt og variasjoner 4. Lag domenemodell Design (ansvarsfordeling) 5 Identifiser objekter og fordel ansvar mellom dem 6 Lag sekvensdiagram for viktige use case 7 Lag klassediagram på systemnivå 5 6 Sekvensdiagrammer: fra krav til design Et UML sekvensdiagram viser hendelsesflyten i et use case viser interaksjoner (samarbeid) mellom objekter i systemet viser rekkefølgen på beskjedene (abstrakt) som sendes mellom objektene kan brukes til å identifisere metodene til objektene i systemet Interakjonsmodellering Sekvensdiagrammer Allokerer oppførsel til klasser og objekter Viser detaljert interaksjon som forekommer over tid blant objektene som er assosiert med hvert use case. Typisk ett interaksjonsdiagram pr. use case 7 8 2
Nok et eksempel: Betale for bestilt vare Sammenheng mellom use case og sekvensdiagram For hvert use case lages (i de aller fleste tilfeller) et sekvensdiagram for normal hendelsesflyt (main success scenario) For hver variasjon kan man velge å lage et nytt sekvensdiagram. Det er viktig å lage sekvensdiagram for variasjoner som ha stor innvirkning på designet 9 10 Klassediagram Arv (generalisering) Klasser og relasjoner 0..1 * assosiasjon spesialisering/ Generalisering (arv) Optiker er en spesialisering av Ansatt Aggregering (er en del av...) 12 3
Aggregering Designmodell Aggregering = en del av noe relasjon.. Vær forsiktig med bruk av aggregering som regel er det nok med en relasjon En designmodell viser systemklasser, ikke konseptuelle klasser som i domenemodellen Typisk informasjon er: Klasser, assosiasjoner og attributter Grensesnitt Metoder 13 14 Fra domenemodell til designmodell Utforming av designmodellen Designmodell - systemklasser Lag design-klassediagram parallelt med sekvensdiagrammer Lag noen sekvensdiagrammer, oppdater klassediagrammet, utvid sekvensdiagrammet etc. Designklassene er systemklasser, ikke konseptuelle klasser som i domenemodellen 15 16 4
Framgangsmåte for designmodellering Klassenavnene er inspirert av navn i domenemodellen Identifiser klasser ved å gå gjennom sekvensdiagrammene Finn metoder Legg til metodenavn ved å analysere sekvensdiagrammene Eks: Meldingen leggtil_info() sendes til Spørreskjemaobjektet. Objektet må derfor inneholde en leggtil_info() metode 17 18 Objektdesign: Ansvarstilordning Objektdesign - ansvar UML definerer ansvar som en kontrakt i en klasse Ansvar er knyttet til objektet i form av dets oppførsel Handling: Opprette objekt, beregning Kunnskap: Vite om private data, vite om relaterte objekter Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret Ansvarstilordning: En utfordring under utforming av sekvens-diagrammer Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel Spørreskjema ) Kontrollobjektprinsippet: Velg objekt som håndterer systemhendelser (Eksempel: SpørreskjemaHåndterer use case kontrollobjekt) Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: SpørreskjemaGenerator ) 19 20 5
Kjennetegn på god design En god utforming gjør den jobben den er ment å gjøre En god utforming er enkel og elegant Eleganse innebærer å finne akkurat riktig abstraksjonsnivå En god utforming er gjenbrukbar, utvidbar og enkel å forstå Et godt objekt har et lite og veldefinert ansvarsområde Et godt objekt skjuler implementasjonsdetaljer fra andre objekter - Grady Booch Modularisering Høy kohesjon Et objekt skal bare ha ansvar for relaterte ting Lav kobling Et objekt skal ha samarbeid med et begrenset antall andre objekter 21 22 Høy kohesjon Lav kobling Kohesjon er et mål på hva slags ansvar et objekt har og hvor fokusert ansvaret er Et objekt som har moderat ansvar og utfører et begrenset antall oppgaver innenfor ett funksjonelt område har høy kohesjon Objekter med lav kohesjon har ansvar for mange ting innen ulike funksjonelle områder Kobling er et mål på hvor sterkt et objekt er knyttet til andre objekter Et objekt med sterk kobling er avhengig av mange andre objekter noe som kan gjøre endring vanskelig 23 24 6
Finn systemklasser Hvordan: Begynn med å formulere ansvarsområdet: Hvilket objekt har ansvar for å opprette nye skjemaer? Se etter mulige systemklasser i domenemodellen Spørsmål: Hva er det generelle prinsipp for å opprette nye objekter? Forslag: Klasse B får ansvar for å opprette objekter av klasse A dersom: B bruker A objekter direkte B inneholder A objekter B aggregerer A objekter B har data som sendes til A objekter når de opprettes Finn systemklasse Vi trenger en klasse for å opprette skjemaer SpørreskjemaGenerator - klassen sender data til Spørreskjema ved opprettelse av nye skjemaer 25 26 Ansvar og sekvensdiagrammer Litt om kontrollobjekter Ansvaret utdypes under utforming av sekvensdiagrammene Et SpørreskjemaGeneratorobjekt har ansvaret for å opprette et nytt spørreskjema Hver use case kan ha et kontrollobjekt som styrer flyten i use caset Kontrollobjektet er et grensesnittobjekt Kontrollobjekter delegerer oppgaver til andre objekter 27 28 7
Kontrollobjektprinsippet Hvem er ansvarlig for å håndtere systemhendelser = en hendelse som genereres av en ekstern aktør? Løsning: F.eks tilordne ansvar for å håndtere en systemhendelse til En klasse som representerer et use case scenario der systemhendelsen forkommer ofte Navn: <UseCaseNavn> Håndterer Eksempel: SpørreskjemaHåndterer Eksempel: SpørreskjemaHåndterer Generer spørreskjema (2) visspørreskjema() 29 30 Retningslinjer for assosiasjoner Designmodell Klasse A og Klasse B er assosiert hvis Et objekt av klasse A sender en beskjed til et objekt av klasse B Et objekt av klasse A oppretter et objekt av klasse B Et objekt av klasse A har attributter hvis verdier er objekter av klasse B eller mengder av objekter av klasse B Et objekt av klasse A mottar en beskjed med et objekt av klasse B som parameter 31 32 8
Oppsummering I objektorientert analyse utarbeides use case modell og domenemodell i parallell. Scenariene i et use case realiseres gjennom objekter som samarbeider. Dette illustreres i sekvensdiagrammer. Klassediagrammer og sekvensdiagrammer utarbeides i parallell, designklasser og metoder finnes ofte fra sekvensdiagrammene og domenemodellen. Ordrebehandlingssystem en gang til: Kravspesifikasjon: En bedrift ønsker et online ordresystem for å kunne selge produkter fra flere forhandlere. Når kunder bestiller varer legger de inn en ordre sammen med betalingsinformasjon. Man kan legge til varer og lagre underveis for å kunne fortsette bestillingen senere. Ordre kan kanselleres etter at de er lagt inn, men før varene sendes. 33 34 Use case modell for Ordrebehandlingssystem Use case Lag ordre Aktør: Kunde Sekundær aktør: Regnskapssystem 1. Systemet viser et ordreskjema med varebeskrivelser 2. Kunden skriver inn de ønskede varene og betalingsinformasjon 3. Systemet sjekker at alle felt er fylt ut og viser totalsum 4. Kunden bekrefter bestillingen 5. Systemet lagrer ordren og sender betalingsinformasjon til regnskapssystemet 6. Regnskapssystemet bekrefter betalingsinformasjonen 7. Systemet sender en ordrebekresftelse til kunden 35 36 9
Overordnet domenemodell Sekvensdiagram for Lag ordre Aktør Kunde Ordrehåndterer Ordre Produkt Aktør Regnskapssyst bestillvarer() leggtilordre() velgprodukt() velgprodukt() leggtilbetalingsinfo() 37 38 Neste gang Prosjektstyring og prosjektgjennomføring Gurholt og Hasle kap. 7,16,17, 19 39 10