God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu

Transkript

1 Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu

2 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven: Evaluer ditt design Mer om UML: Pakker Kollaborasjonsdiagrammer Aktivitetsdiagrammer Tilstandsdiagrammer 2

3 Repetisjon: Hva er UML? Et konseptuelt modelleringsspråk Et språk definert for å beskrive virkeligheten UML er dagens industri-standard UML definerer elementer regler mekanismer for å beskrive og visualisere modeller av den virkelige verden 3

4 Men først...hva er en modell? (nok en gang) 4

5 En modell er mange ting (Fra leksikon:) Representasjon av noe. Vanligvis mindre enn originalen. F.eks modelljernbane. Noe som lages for å brukes til kopiering i et annet materiale. F.eks voksmodell av noe som skal støpes. Bestemt type eller design av et produkt. F.eks bilmodell. Forenklet beskrivelse av et system brukt ved forklaring. F.eks en økonomisk modell. Noe som man kan arbeide etter. F.eks en oppskrift. Person eller ting som anses som eksepsjonelle og som det er verdt å etterligne. Person som poserer. F.eks mannekeng eller akt. Utgaver av klær fra motedesignere. 5

6 Hvorfor modellere Å få prøvet ut ting under kontrollerte betingelser i mindre skala før man setter i gang produksjon Eksempler: utprøving av fly og biler i vindtunneler. Prototyper. Man sparer penger fordi modellene er billigere å lage enn det endelige produktet. Å ha noe fast å kommunisere rundt for forskjellige deltakere i et prosjekt. I et systemutviklingsprosjekt er det brukere, analytikere, designere, testere, programmerere og eksperter innen forskjellige fagområder. 6

7 Hvorfor modellere forts. Forskjellige modeller gir ulikt detaljeringsnivå. Noen ganger har man behov for å vise et oversiktsbilde, andre ganger er det detaljene man vil konsentrere seg om. En bruker er interessert i å se hvordan systemet vil se ut utenfra, mens en utvikler kan vikle seg inn i detaljer rundt realiseringen av systemet. Det er ikke nok med en enkelt modell. Store systemer vises best gjennom flere uavhengige modeller. 7

8 Modeller i utviklingsprosessen Gjennom utviklingsprosessen lages forskjellige modeller. Modeller er sentrale artefakter i de forskjellige disipliner Modeller utvides og forfines i alle faser i livsløpet. Forskjellige modeller har ulik betydning i de forskjellige faser. F.eks arbeider man mer med use case modeller i de to første fasene av RUP. 8

9 Objektorientert systemutvikling dreier seg om klasser og objekter. Klasser og instanser av klasser (objekter) og deres samarbeidsmønstre utgjør den statiske strukturen i programvaresystemet. Et grensesnitt beskriver en ekstern tjeneste som en klasse eller en samling klasser skal tilby. Grensesnitt er spesielt relevant i moderne distribuerte systemer. Disse bygges opp av distribuerte komponenter som kan være på et hvilket som helst sted i et nettverk. Komponentene gjør seg tilgjengelig gjennom et definert grensesnitt. 9

10 OO design Prosjektoppgaven: Vurder designet utfra prinsipper om god OO design Stikkord: Kobling Kohesjon Ekspert-, skaper- og kontrollprinsippet 10

11 Objektdesign: Ansvarstilordning 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 11

12 Objektdesign - ansvar Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel Spørreskjema ) Kontrollobjektprinsippet: Use case controller: Ett kontrollobjekt per Use case (store systemer) Fasadekontroller: Ett kontrollobjekt som styrer interaksjon med systemet Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: SpørreskjemaGenerator ) 12

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

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

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

16 Ulike typer objekter Entitesobjekter: informasjon overlever utførelsen av et use case (need-to-know-prinsippet) Grensesnittobjekter All kommunikasjon som er avhengig av systemets omverden plasseres her Kontrollobjekter Komplekse use case: Kontrollobjekter styrer adferden slik at use caset kan utføres korrekt. Typisk kontrollobjekt: Administrator. 16

17 Eksempler på objekter (se G&H s.127) aktør Grensesnittobjekter f.eks webside, printerdriver Kontrollobjekt- Use case Handler, Use case controller Entitesobjekter: Spørreskjema, ordre 17

18 Litt om kontrollobjekter Hver use case kan ha et kontrollobjekt som styrer flyten i use caset Kontrollobjektet er et grensesnittobjekt Kontrollobjekter delegerer oppgaver til andre objekter 18

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

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

21 Mer om UML 21

22 UML Er et sett med byggeklosser som gjør det mulig å modellere alle viktige sider ved et programvaresystem. Fire hovedfunksjoner: Visualisere Spesifisere konstruere dokumentere 22

23 UMLs roller Under utvikling av programvare fremstilles en rekke produkter både dokumenter og eksekverbar kode: Krav Arkitektur Kildekode Prosjektplaner Tester Prototyper Kjørende program UML bidrar til å gjøre disse produkter mer forståelige. 23

24 De tre amigos Grady Booch Ivar Jacobsen James Rumbaugh 24

25 Tre amigos forts. UML er resultatet av at disse tre har samordnet (unified) sine metoder og notasjoner i et felles språk. Grady Booch var sterk på design og er kjent for å ha utviklet et rikt modelleringsspråk. James Rumbaugh står bak OMT (Object Modeling Technique) som var sterk på analyse. Ivar Jacobson er mest kjent for utviklingen av Use Case og en OO design som legger sterk vekt på å modellere oppførsel (funksjonalitet). 25

26 I følge Booch er UML et språk for å : Visualisere: ideene, modellen og koden visualiseres grafisk for lette kommunikasjon med andre (kunder, oppdragsgivere, utviklere). Spesifisere: det lages presise, komplette modeller. UML brukes til å lage spesifikasjonen i fasene analyse, design og implementasjon. Konstruere: UML modeller kan oversettes direkte til et programmeringsspråk som Java, C++. Man kan også gå fra programkode til UML modell (reengineering). Dokumentere: UML dokumententasjon av krav, arkitektur, design, kildekode, prosjektplaner, tester, prototyper og produksjonsetting (deployment). 26

27 UML har 3 hovedbyggeklosser Ting (Things) Forhold (Relationships) Diagrammer (Diagrams) Ting og forhold uttrykkes med symboler UML-diagrammer. Diagrammene er grafisk visualisering av de forskjellige konseptene Diagrammene uttrykker sammenhengene i modellene. 27

28 Ting Ting består av: Strukturelle ting Oppførselsting Grupperingsting Merknadsting 28

29 Strukturelle ting De strukturelle tingene er substantivene i språket: De utgjør de statiske delene i modellene og kan være både konseptuelle, dvs logiske, og fysiske ting. De strukturelle tingene er klasser, grensesnitt, samarbeidsforhold, use case, aktive klasser, komponenter og noder. 29

30 Grupperingsting I større systemer vil det alltid være behov for å kunne gruppere deler av systemet for å få bedre oversikt. Den primære grupperingstingen er pakke. En pakke samler flere strukturelle og oppførselsting som er tett koblet. En pakke kan igjen bestå av flere pakker. 30

31 Pakker Pakker for gruppering av modeller eller modelleringselementer. Pakker kan være nøstede. Klassene er inni pakkene. 31

32 Merknadsting Tekstlige forklaringer og anmerkninger som kan være nødvendige for å øke forståelsen av en modell eller spesielle deler av en modell: Kommentarer brukes for utfyllende dokumentasjon eller beskrivelse av et modelleringselement eller en modell. 32

33 Oppførselsting Oppførsel uttrykker dynamikken i tid og rom i et programvaresystem. For at meldinger skal kunne sendes fra et objekt til et annet må det være en forbindelse mellom objektene (assosiasjoner). Interaksjon: flere objekter samarbeider gjennom utveksling av meldinger seg imellom for å oppnå et resultat. Objekter vil i løpet av sin levetid kunne være i forskjellige tilstander. Dette kan modelleres som tilstandsdiagrammer. 33

34 Tilstandsdiagram UML tilstandsdiagrammet vises tilstnadene et objekt kan være i, og overgangen mellom tilstandene. Tilstandsdiagrammet viser tilstandene til ett enklet objekt. Start og slutt på en sekvens av tilstander vises med runde symboler. 34

35 Diagrammer Ni typer diagrammer: Klassediagram Objektdiagram Use case diagram Sekvensdiagram Tilstandsdiagram Aktivitetsdiagram Samarbeidsdiagram (Kollaborasjonsdiagram) Komponentdiagram Deploymentdiagram ( produksjonssettingsdiagram ) 35

36 Dynamiske og statiske diagrammer Diagrammene kan grupperes i Dynamiske diagrammer: viser de dynamiske (skiftende) aspektene i systemet. Interaksjonsdiagrammer viser en interaksjon bestående av et sett av objekter og deres relasjoner inklusive meldinger som eventuelt blir sendt mellom dem. To typer interaksjonsdiagram: sekvensdiagram og samarbeidsdiagram (collaboration). Statiske diagrammer: viser de statiske (faste) aspektene i systemet. Eks: Fysisk diagrammer: Komponentdiagram og produksjonssettingsdiagram er to diagramtyper som brukes for å modellere de fysiske aspektene ved objektorienterte systemer. 36

37 UML - diagrammer forts. Klassediagram - Forhold mellom klasser og pakker, statisk og dynamisk Objektdiagram - Typisk forhold mellom noen objekter ved ett bestemt tidspunkt Use case diagram - Hovedfunksjonalitet mellom omverden og system Sekvensdiagram - Rekkefølge på kall/meldinger mellom klasser Kollaborasjonsdiagram - Interaksjon i forhold mellom objektene Tilstandsdiagram - Tilstandsdiagram for ett eller flere samvirkende objekter Aktivitetsdiagram - Beskriver hva som skjer i et objekt Komponentdiagram - Organisering og forhold mellom moduler/pakker Deployment diagram - Hvordan systemets deler er fordelt på maskinvaren 37

38 UML diagramtypene og deres gruppering 38

39 Tilstandsdiagrammer beskriver et systems oppførsel Alle tilstander et objekt kan være i Hvordan objektets tilstander endrer seg som et resultat av hendelser som virker på objektet Er nyttig for å beskrive et objekts oppførsel over flere use case Er ikke egnet til å beskrive hvordan objekter samarbeider (bruk interaksjonsdiagrammer) 39

40 Eksempel - fly 40

41 hendelser 41

42 Tilstandsdiagram - fly 42

43 Parallelle tilstander (concurrent) 43

44 Aktivitetsdiagrammer viser flyten fra aktivitet til aktivitet. Aktivitetsdiagrammere modellerer hvordan ting virker. Diagrammene er en hjelp for å anskueliggjøre arbeidsprosessen. Ofte har hvert use case et eget tilhørende aktivitetsdiagram. 44

45 Symboler 45

46 Aktivitesdiagram 46

47 Aktivitetsdiagram forts. Hovedsymbolet er aktiviteten (Action state (ovalt symbol) En aktivitet er enten en virkelig prosess, (velg drikke), eller utførelsen av en metode En variant av et tilstandsdiagram 47

48 Når bruke hva Alle diagrammer har styrker og svakheter Aktivitetsdiagrammer anbefales brukt for modellering av arbeidsflyt Ulempe: Viser ikke forbindelser mellom hendelser og objekter særlig godt Tilstandsdiagram anbefales brukt der hvor det forekommer asynkrone hendelser Ulempe: Viser ikke hvordan objekter samarbeider 48

49 Samarbeidssdiagram Et samarbeidsdiagram vektlegger og får frem organiseringen av objekter som deltar i en interaksjon. Det viser også flyten av meldinger og rekkefølgen de forekommer. 49

50 Samarbeidsdiagram Stimulus / melding Link / (assosiasjonsinstans) Objekt / aktør 1: startsalg() : Ekspeditør : System Iterasjon med betingelse 2* [flere varer] : regvare(id,antall) 3: totalsum := sluttsalg() 4: betale(totalsum) 5: oppdaterlager() Respons Stimulus til seg selv 50

51 Samarbeidsdiagram 51

52 Sekvensdiagram 52

53 Sekvensdiagram Et sekvensdiagram vektlegger og får frem tidsrekkefølgen for meldinger. Dette gjøres ved å vise systemets objekter og deres tilhørende levetid, samt meldinger som flyter mellom objektene. Et sekvensdiagram har to dimensjoner: Vertikal dimensjon som representerer tiden. Horisontal dimensjon som representerer forskjellige objekter. 53

54 Komponent-diagram viser et sett av komponenter og deres relasjoner (forbindelser). Diagrammet kan inneholde avhengighetsrelasjoner, generaliseringer, arv og realiseringsrelasjoner. 54

55 Komponentdiagram 55

56 Komponentdiagram 56

57 Deployment diagram Produksjonsettingsdiagram: 57

58 Produksjonsettingsdiagram (eng. deployment diagram) viser konfigurasjonen av eksekverbare prosesseringsnoder og komponentene som inngår. Et produksjonsettingsdiagram viser ofte hvor programvare skal settes i produksjon og hvilke noder programvaren skal distrubueres til. Vanlige bruksområder er modellering av: Embedded systems, dvs. systemer hvor beregningstjenester ikke er primærfunksjon, f.eks. en mikrobølgeovn eller en videomaskin. Klient/tjener systemer. Distribuerte systemer. 58

59 Modellering av databaser UML kan også benyttes til databasemodellering, selv om standarden ikke er utviklet spesielt for dette formålet. For personell som er kjent med ER-diagrammer vil overgang til UML notasjon på databasedigrammene ikke by på store vanskeligheter UML s klassediagrammer har samme dekningsområde som ER-diagrammer. Ved å bytte ut elementene i klassediagrammet med standard ER-elementer kan man modellere databaser ved bruk av UML notasjon: Entiteter i ER-diagrammer ses på som klasser. Entitetenes attributter ses på som klassens attributter. Relasjonene mellom entitetene tilsvarer relasjonene mellom klassene. 59

60 Databasemodllering med UML Figuren under viser eksempel på bruk av UML notasjon ved modellering av databaser. Samtidig viser den problemet med bruk av UML for dette formålet, nemlig at UML ikke har noe standard symbol for vising av nøkler og fremmednøkler. Her er dette løst ved bruk av egendefinerte constraints. 60

61 Neste gang Gjesteforelesning - erfaringer fra industrien: Større og mindre prosjekter ulike utfordringer Kundemedvirkning i utviklingen 61