Intermesso. Visjonen... samling av trådene. Veivalget. Et bedre bilde av visjonen?

Transkript

1 Visjonen... Intermesso samling av trådene jfr. Systemutvikling fra kjernen og ut, fra skallet og inn kapittel INF02-Intermesso- Theodor Kittelsen: Og i det fjerne, langt, langt borte så han noe lyse og glitre Nasjonalgalleriet INF02-Intermesso-2 Et bedre bilde av visjonen? Vi er allerede på byggetomten for slottet Veivalget Lover og regler Penger Tid Teknologi Utfordringen er å hele tiden bygge, endre og rive slik at slottet til enhver tid tilfredsstiller interessentenes behov og ønsker TAU_ UML Dataorientering Objektorientering Illustrasjoner: Ukjent terreng Endring av rammer Teknologiske problemer Manglende ressurser INF02-Intermesso-3 INF02-Intermesso-4

2 Figur -3. Et systems livssyklus Myte eller faktum? Kostnader for endringer Jo tidligere man gjør en feil, jo senere oppdages den, og jo dyrere blir den å rette Idé Krav og ønsker Utforming Realisering Ny idé t... Systemet settes i drift Idé Krav og ønsker Utforming Realisering Ny idé... Initiell utvikling og realisering Vedlikehold Systemet settes i drift Initiell utvikling og realisering Vedlikehold INF02-Intermesso-5 INF02-Intermesso-6 Myte eller faktum? Return on investment Kostnader for endringer Jo tidligere man gjør en feil, jo tidligere kan den oppdages, og jo billigere blir den å rette Inntekter/ kostnader Idé. iterasjon 2. iterasjon 3. iterasjon Ny idé... Systemet settes i drift Idé Krav og ønsker Utforming Realisering Ny idé Systemet settes i drift INF02-Intermesso-7 INF02-Intermesso-8

3 Return on investment Figur 3-7. Generell arkitektur for et utviklingsmiljø Inntekter/ kostnader Systemutvikler Upper-CASE verktøy Repository, Utviklingsdatabase Lower-CASE verktøy Idé. iterasjon 2. iterasjon 3. iterasjon Ny idé... Reverseengineeringverktøy Dokumentasjon Brukersystem Systemet settes i drift INF02-Intermesso-9 INF02-Intermesso-0 Et moderne utviklingsmiljø Modellenes to formål Bruksmønstereditor Interesseområdet Programteksteditor Klassediagrameditor Systemutvikler Sekvensdiagrameditor Repository, Utviklingsdatabase Beskrivelse Oppfatningen av interesseområdet Foreskrivelse Lower-CASE verktøy Brukersystem Brukere INF02-Intermesso- INF02-Intermesso-2

4 Beskrivelser og beskrivelsesspråk I begynnelsen av systemutviklingsprosessen er uformelle beskrivelser det beste! Formelle beskrivelser drar oppmerksomheten mot formalitetene, og vekk fra problemstillingene! UML dekker ikke alt, til tross for at UML er meget omfattende! Hvor høy skal detaljeringsgraden være? Styres av formålet med beskrivelsen o Beskrivelse av interesseområdet? Produksjon av informasjonssystemer Produksjon o Analyse, utforming og realisering To hovedmetoder: o Fra kjernen og ut (Ugruppert begrepsmodell -> gruppert modell -> relasjonsdatabase) o Fra skallet og inn (Bruksmønster -> sekvensdiagram->klassediagram) o Foreskrivelse av informasjonssystemet? INF02-Intermesso-3 INF02-Intermesso-4 Hva oraklet skal kunne vite uttrykkes i et dataorientert UMLklassediagram, i ORM eller som tabelldatabasestruktur Fra kjernen og ut Interesseområdet registrering påvirkning Fra skallet og inn Interesseområdet registrering påvirkning De funksjonelle krav uttrykkes i UML-bruksmønstre Jeg svarer på alle spørsmål (nesten, da) Oppfatningen av interesseområdet Jeg gjør det du forventer at jeg skal gjøre Oppfatningen av interesseområdet Orakel Organisasjonen Brukere INF02-Intermesso-5 Organisasjonen Brukere INF02-Intermesso-6

5 Statiske og dynamiske virkelighetsmodeller Dataorientert (statisk) virkelighetsmodell Interesseområdet t Virkelighetsmodellen omfatter o virkelighetens tilstander og deres representasjoner registrering påvirkning o regler for lovlige/ulovlige tilstander og tilstandsoverganger Virkelighetsmodellen omfatter ikke transformasjoner fra en tilstand til den neste Oppfatningen av interesseområdet t et får istedenfor en melding om at virkeligheten har endret seg, og virkelighetsmodellen oppdateres ved hjelp av funksjoner i applikasjonslaget. Virkelighetsmodellen deles av alle funksjoner t Brukere INF02-Intermesso-7 INF02-Intermesso-8 Objektorientert (dynamisk) virkelighetsmodell Virkelighetsmodellen gjenspeiler konkrete og/eller tenkte (mentale) objekter, med hver sin tilstand og hver sin oppførsel Virkelighetsmodellens objekter kan selv sørge for transformasjoner fra en tilstand til den neste et må i tillegg ha funksjoner (ofte implementert ved hjelp av objekter) for o (resten av) forretningslogikken o brukergrensesnittet Fra det dataorienterte til det objektorienterte perspektiv I det dataorienterte perspektivet interesserer vi oss for faktaopplysninger av statisk natur om interesseområdet, og skranker som forhindrer registrering av åpenbart uriktige fakta I det objektorienterte perspektivet interesserer vi oss for virkelige og tenkte objekter i interesseområdet, og hvordan disse objektene gjennom samarbeide kan gi en hensiktsmessig modell Javel, men har ikke da disse perspektivene svært lite til felles? INF02-Intermesso-9 INF02-Intermesso-20

6 Dataorientering vs. objektorientering Både dataorienterte og objektorienterte informasjonssystemer inneholder data. Forskjellen er at i dataorienterte systemer er alle data samlet i en sentral ressurs databasen, mens i objektorienterte systemer er dataene fordelt på objektene ut fra det generelle prinsipp at det objektet som har bruk for data selv tar vare på dem. I objektorienterte systemer får dataene evig liv ved å gjøre objektene persistente. Dette kan realiseres på flere måter for eksempel ved hjelp av en OO-database. Andre relevante forskjeller I OO har vi som collection ikke bare mengde, men også bag, list og array > krav om entydighetsskranke faller bort > forekomstene kan ordnes I OO kan strukturer som set, bag, list og array, samt generelle objekter, brukes som verdier > uendelige mange muligheter for hvordan data struktureres Ugrupperte modeller bygd med elementære utsagn er i utgangpunktet nøytrale overfor hvilket perspektiv som velges. Perspektivet kommer inn når de elementære utsagnene skal grupperes til relasjonsdatabase eller inn i objekter. Gruppering til relasjonsdatabase kan gjøres utelukkende ut fra skrankene i den ugrupperte dataorienterte modellen (i UML eller ORM). For gruppering til objekter må vi i tillegg se på ansvarsfordelingen. I OO er dataene innkapslet i objektene > dataenes struktur er ukjent for omverdenen - de kan bare fås tak i gjennom spørremeldinger (jf. neste lysark) i OO har objekter sin egen innebygde identifikator (OID) > begreper behøver ikke alltid ha en representasjon Ah, hvilken frihet - men vi betaler vel noe for dette? INF02-Intermesso-2 INF02-Intermesso-22 Objektorientert vs. dataorientert utforming new new klasse Objektorientert Realisering av klassediagrammet Fylke {id} fylkenavn relasjonsdatabase {id} {fk} komnr2s {id} kommunenavn objekter Program CREATE INSERT INSERT Dataorientert klasse (entitet) UI fylkenavn Østfold komnr2s kommunenavn 04 Halden Moss Østfold:Fylke Østfold evt. metoder realiseres ved hjelp av OIDs eller relationships : Halden evt. metoder : 04 Moss evt. metoder INF02-Intermesso-23 INF02-Intermesso-24

7 Er OO-klasser lik dataorienterte klasser med metoder? Ser vi de samme fenomener i virkeligheten, uavhengig av om perspektivet er dataorientert eller objektorientert? Merk at: o I OO står vi mye friere med hensyn til strukturering av data o Objekter har ansvar og oppførsel Med andre ord - får vi et objektorientert klassediagram bare ved å føye til metoder? jf. figur 5-0 kommunenr {id} Dataorientert klassediagram (ugruppert) navn kommunenavn {id} År årstall {id} Materialgjenvinning gjenvunnet_ materiale 0: gjenvunnet mengde Materiale materialnavn {id} Mengde # tonn {id} INF02-Intermesso-25 INF02-Intermesso-26 Dataorientert klassediagram (gruppert) Figur 0-0. Sekvensdiagram for avfallsstatistikk-system Kontrollobjekt Forretningsobjekter År kommunenr {id} kommunenavn navn årstall {id} Materialgjenvinning kommunenr {id} årstall {id} materialnavn {id} mengde gjenvunnet_ materiale 0: gjenvunnet mengde Materiale materialnavn {id} Mengde # tonn {id} :Brukergrensesnitt :Statistikkinteressert person Be om statistikk :Statistikkprodusent new( ) lagstatistikk(args) hentdata(args) :HeleLandet Halden: Moss: Halden998: Gjenvinning mengde:=gjenvunnetmengde (periode,materiale) mengde :=gjenvunnetmengde(materiale) mengde := gjenvunnetmengde(materiale) mengde :=gjenvunnetmengde (periode,materiale) gjenta for alle kommuner Halden20: Gjenvinning mengde := gjenvunnetmengde(materiale) gjenta for alle aktuelle år Moss998: Gjenvinning kommunenavn {id} Fjern objektet det trengs ikke lenger INF02-Intermesso-27 INF02-Intermesso-28

8 Figur 0-. Klassediagram for avfallsstatistikk-system Skranker HeleLandet struct hentdata(args) kommunenr {id} kommunenavn int gjenvunnetmengde (periode, materiale) Materialgjenvinning årstall {id} papirmengde glassmengde plastmengde Hvorfor er skranker så viktige i dataorientert utforming, og lite omtalt i objektorientert utforming? En relasjonsdatabase har ingen egen bevissthet, og trenger et regelverk og en vaktbikkje til å beskytte seg Objektorientert klassediagram int gjenvunnetmengde (materiale) Objekter har oppførsel, og vi antar at de følger Kardemommeloven: Du skal ikke plage andre, du skal være grei og snill og for øvrig kan du gjøre hva du vil Dataorientert klassediagram kommunenr {id} kommunenavn Materialgjenvinning kommunenr {id} årstall {id} materialnavn {id} mengde Antagelsen holder ikke nødvendigvis alltid stikk (programmeringsfeil!) derfor er skranker på vei inn også i objektorienterte systemer jfr OCL (Object Constraint Language) INF02-Intermesso-29 INF02-Intermesso-30 UI Hva de vanligste skrankene blir brukt til Fylke NOT NULL komnr2s primærnøkkel referanseintegritet (fra implisitt delmengdeskranke) plassering av fremmednøkkel fremmednøkkel null / not null primærnøkkel Fylke {id} omfatter : ligger-i komnr2s {id} UI Hva de vanligste skrankene blir brukt til Fylke NOT NULL komnr2s primærnøkkel referanseintegritet (fra implisitt delmengdeskranke) plassering av fremmednøkkel fremmednøkkel null / not null primærnøkkel Fylke () komnr2s INF02-Intermesso-3 INF02-Intermesso-32

9 Forholdet mellom det generelle og det spesielle (klasser og objekter) Det generelle, eksisterer det egentlig, eller er det noe vi har funnet på for å beskrive/snakke om verden på en enklere måte? o o o o Eks: kråker, mennesker Eksisterer slike fellesbegreper, eller er det bare vår egen begrepsdannelse? Hvis de eksisterer, er de av fysisk eller åndelig natur? Eksisterer det generelle evt. fritt fra de enkelte individene, eller bare som del av disse? Debatt fra 00- tallet, interessant for systemutviklere Nominalist Nominalist eller Realist o Det som eksisterer er bare enkeltindividene. Generelle fellesbegreper er skapt av menneskene, bl.a. for bedre å forstå/beskrive verden (eks. Wilhelm av Occam og Charles Darwin) Realist o Generelle fellesbegreper som kråke, menneske har en egen eksistens, og enkeltindividene er dannet etter disse (eks: Platon og Thomas av Aquinas) INF02-Intermesso-33 INF02-Intermesso-34 Klasser eller objekter først? Utviklingsretninger og utforminger Dataorientert utforming: Begreper og klasser, deretter forekomster Men: Homogenitetsregelen Objektorientert utforming: Objekter, deretter klasser Sentralisert relasjonsdatabase Objektorientert arkitektur Fra kjernen og ut? Fra skallet og inn? Hvorfor forskjellen i praktisk fremgangsmåte? Er rutene med? interessante? INF02-Intermesso-35 INF02-Intermesso-36

10 Bruksmønstre og systemgrensen Figur.3. Personen og lånet et enkelt samarbeidsdiagram Allment akseptert at det er hensiktsmessig å spesifisere funksjonelle krav ved hjelp av en bruksmønstermodell Dette impliserer imidlertid at systemgrensen er fastlagt Vi skal se på en alternativ metode :Person beomavdrag :Lån Jfr. læreboka avsnitt -8 Grense mellom informasjonssystemet og omverdenen INF02-Intermesso-37 INF02-Intermesso-38 Figur.4. Tilordning av ansvar Figur.5. Kommunikasjon mellom virkelig og datamaskinbasert objekt-del :Person beomavdrag :Lån protokoll Person behamomavdrag(beløp, dato) purrham(beløp, dato) mottahansavdrag(beløp, dato) Person klasser behamomavdrag(beløp, dato) purrham(beløp, dato) mottahansavdrag(beløp, dato) Lån beregnrente( ) beregnsaldo( ) beregnavdrag( ) beomavdrag(beløp) mottaavdrag(beløp) Eksempel: purrham(beløp, dato) Send ham et brev Send ham en Be en funksjonær ringe ham Send en SMS-melding til mobiltelefonen hans INF02-Intermesso-39 INF02-Intermesso-40