Dagsorden. Hovedtemaene i INF102. Fra kjernen og ut. Produksjon av informasjonssystemer. Produksjon av informasjonssystemer

Transkript

1 Dagsorden Hovedtemaene i INF02 Jus-forelesningen tas igjen onsdag 4. mai kl 05 hvis interesse Prosjektoppgaven o Kandidatnummerlisten o Anonymisering av prosjektoppgaven o Hvordan levere programkoden Åpen-bok-eksamen hva innebærer det? o Trykkfeil i læreboka følg link fra Produksjon av informasjonssystemer Styring av produksjon av informasjonssystemer Rammer for utvikling av informasjonssystemer Verktøy og plattformer Gjennomgang eksamensoppgave vår 2002 Gjenværende spørretime-spørsmål Våre eksamenstips Kurskritikk (åpnes senest i morgen?) Hva vi håper dere har fått med dere INF02-oppsum- INF02-oppsum-2 Produksjon av informasjonssystemer Produksjon (utforming og programmering) To hovedmetoder: o Fra kjernen og ut (dataorientert klassemodell/ormmodell -> relasjonsdatabase) o Fra skallet og inn (Bruksmønster -> sekvensdiagram->klassediagram) Hva oraklet skal kunne vite uttrykkes i ORM, dataorientert UML-klassediagram eller som tabelldatabasestruktur registrering Jeg svarer på alle spørsmål (nesten, da) Fra kjernen og ut Interesseområdet påvirkning Oppfatningen av interesseområdet Orakel Informasjonssystem Brukere INF02-oppsum-3 Organisasjonen INF02-oppsum-4

2 Fra skallet og inn Interesseområdet registrering påvirkning De funksjonelle krav uttrykkes i UML-bruksmønstre Objektorientert vs. tradisjonell utforming Informasjonssystem new new klasse Objektorientert Jeg gjør det du forventer at jeg skal gjøre Informasjonssystem Oppfatningen av interesseområdet Organisasjonen Brukere INF02-oppsum-5 Program Informasjonssystem CREATE INSERT INSERT Tradisjonell INF02-oppsum-6 klasse (entitet) Fra skallet og inn, Inf02-metoden, del Inf02-metoden, del 2 Hvordan skal systemet fungere? Hva skal systemet gjøre? o Identifisere systemets primære (og sekundære) aktører og deres mål o Uttrykke målene til aktørene som bruksmønstre (use cases) i en UML bruksmønstermodell o Tekstlig spesifikasjon av bruksmønstre med normal hendelsesflyt og variasjoner (+ trigger, betingelser og annet snacks) o Sekvensdiagram for hvert bruksmønster Lag alltid sekvensdiagram for normal hendelsesflyt Lag sekvensdiagram for variasjoner som introduserer nye objekter eller metoder Hvordan finne gode objekter? Hjelpeteknikk: CRC 3 typer objekter Kantobjekter, kontrollobjekter og forretningsobjekter Første iterasjon: Lite fokus på innmaten i kantobjekter, mye fokus på samarbeid mellom kontrollobjekt og forretningsobjekter INF02-oppsum-7 INF02-oppsum-8

3 Inf02-metoden, del 3 Klassediagrammer for hvert bruksmønster o Inkluder klasser, metoder, attributter og assosiasjoner som er nødvendige for å utføre sekvensen av handlinger som er spesifisert i sekvensdiagrammene til bruksmønsteret o Start med normal hendelsesflyt. Lag klasser for alle objektene. Hver melding til et objekt har en tilsvarende metode i klassen til objektet Legg til attributter som metodene bruker Lag nødvendige assosiasjoner for at klassene skal kunne utveksle meldinger mellom sine objekter o Inkluderer deretter sekvensdiagrammer for variasjoner i klassediagrammet: Legg til nye attributter, assosiasjoner og metoder i klassediagrammet basert på meldingene i sekvensdiagrammet for variasjonen. Systemnivå klassediagram for alle bruksmønstre o Inkluder klasser, metoder, attributter og assosiasjoner fra alle klassediagrammene NB! Ofte viser vi KUN forretningsobjektene i klassediagrammet Ofte nyttig å visualisere/illustrerer klassediagrammene med et objektdiagram (en bestemt instans av klassediagrammet) Noen eksamenstips Du får helt sikkert en oppgave som ber deg om å utvikle, videreutvikle eller finne feil i o bruksmønstre (inkl. tekstlige spesifikasjoner), o sekvensdiagrammer, og o klassediagrammer. Det er ingen fasitsvar på typiske spørsmål om OOAD-delen av kurset. o Ikke svar på mer enn det oppgaven ber om o Redegjør kort for dine antagelser! INF02-oppsum-9 INF02-oppsum-0 Sambandsoperatør Eksamen vår 2002 Oppg 2a) Lag tekstlige spesifikasjoner av bruksmønstrene Loggfør oppdrag og Avslutt oppdrag. Loggfør oppdrag Avslutt oppdrag PROSESS VED OPERASJONSSENTRAL: Den innrapporterte hendelsen resulterer i at sambandsoperatøren loggfører (oppretter) et såkalt oppdrag. I oppdraget beskriver sambandsoperatøren hvor oppdraget er lokalisert (hvor hendelsen fant sted), hva slags type oppdrag det dreier seg om (for eksempel bilstikk eller innbrudd ), samt en kort tekstlig beskrivelse av oppdraget. Deretter blir Ledige patruljer allokert til oppdraget. Disse patruljene blir da Aktive. Sambandsoperatøren sender så en melding om oppdraget over politiradioen til de patruljene som ble tilordnet operasjonen. Når patruljene har utført oppdraget gir de beskjed til sambandsoperatøren, som deretter avslutter oppdraget. ne som var tilordnet operasjonen får dermed status som Ledige. Mulig løsning, oppg. 2a Bruksmønster: Loggfør oppdrag Aktør: Sambandsoperatør Trigger: En hendelse rapporteres inn til sambandsoperatøren Normal hendelsesflyt. Sambandsoperatøren ber systemet om å lage en nytt oppdrag 2. Systemet lager et nytt oppdrag 3. Sambandsoperatøren angir oppdragstype 4. Sambandsoperatøren angir hvor hendelsen er lokalisert 5. Sambandsoperatøren gir tekstlig beskrivelse av hendelsen 6. Systemet viser en oversikt over ledige patruljer 7. Sambandsoperatøren velger ledige patruljer til oppdraget 8. Systemet gir patruljene status som aktive og tilordner dem til oppdraget INF02-oppsum- INF02-oppsum-2

4 Oppg. 2a (forts.) Variasjoner: 6a. en har ingen ledige patruljer: Sekvensdiagram for Loggfør (Oppg. 2b) follo: Sambandsoperatør "nytt oppdrag" : Loggfør nytt () create() sierra30: sierra3:. Systemet gir en oversikt over andre operasjonssentraler med ledige patruljer oppdrag53: 2. Sambandsoperatøren velger alternativ(e) operasjonssentral(er) med ledige patruljer oppdrag53 settstatus(aktiv) "angir oppdragstype" 3. Systemet viser oversikt over ledige patruljer for valgt(e) operasjonssentral(er). settstype(bilstikk) 4. Bruksmønsteret fortsetter på punkt 7 under normal hendelsesflyt. "angir lokalisering" settlokalisering("drammensveien 4") Andre krav:. Dette er en flerbruker sanntidsapplikasjon! Responstidene må være gode. 2. Det er viktig at punktene 7 til 8 i normal hendelsesflyt lages slik at det ikke er mulig å tilordne samme patrulje til to forskjellige oppdrag (omtrent) samtidig. Mulige utvidelser: "beskriver hendelsen" settbeskrivelse("bd4397 stakk fra rutinekontroll") finnlediger() liste over ledige patruljer "viser liste" [sierra30 er ledig] "velger sierra30" aktiver(sierra30) settstatus(aktiv). Variasjon 3a. Det kan tenkes at forskjellige operasjonstyper har forskjellig videre behandling. [sierra3 er ledig] "velger sierra3" aktiver(sierra3) settstatus(aktiv) 2. Variasjon 7a. Systemet kan foreslå ledige patruljer basert på distanse fra hendelsen. "oppdrag loggført" INF02-oppsum-3 INF02-oppsum-4 Klassediagram for Loggfør (Oppg. 2c+d) kallenavn status settstatus() navn nytt() finnlediger() Allokert til 0.. loggførtav type lokalisering beskrivelse status settstatus() settstype() settlokalisering() settbeskrivelse() aktiver() Eksamensoppgave vår 2002, oppgave 3. Jeg har ikke spesifisert typer på attributter eller signatur på metoder multiplisiteten mellom og skyldes oppgavebeskrivelsens antagelse om at assosiasjonen bare skal gjelde aktive oppdrag. Her kunne man selvsagt også tenkt seg en mange-til-mange assosiasjon, slik at man også har historikk om hvilke patruljer som var med på avsluttede oppdrag, men det er ikke det oppgaven ber om. 3. Klassen har attributtet "status" selv om det, som et resultat av oppgavebeskrivelsens antagelse om at assosiasjonen bare skal gjelde aktive oppdrag, vil kunne avledes dersom assosiasjonen mellom og gjøres navigerbar (dvs, blir implementert som en peker el.l.) fra til. Jeg antar at assosiasjonen kun er navigerbar fra til, noe som er i henhold til CRC-ansvarsfordelingen i oppgaveteksten. Da må jeg ha et status-attributt. 4. Metoden lediger i klassen vil kanskje bruke en metode ::getstatus() for å finne r som er ledige, men det er en implementasjonsdetalj som ikke er spesifisert i sekvensdiagrammet. Det er dessuten også mulig å gjøre dette annerledes (f.eks. lage en ekstra assosiasjon mellom og som heter "lediger"). INF02-oppsum-5 INF02-oppsum-6

5 Første skritt Andre skritt sentralnavn{id} «identifying» disponerer sentralnavn{id} administrerer «identifying» patrulje-kallenavn{id} oppdragsnr{id} tilhører patruljekallenavn{id} tilordnes oppdragsnr{id} administreres_av INF02-oppsum-7 INF02-oppsum-8 Tredje skritt ORM-variant disponerer sentralnavn{id} administrerer «identifying» tilhører (sentralnavn) administreres_av administrerer disponerer tilhører patruljekallenavn{id} tilordnes Tilordning oppdragsnr{id} administreres_av (patruljekallenavn) (oppdragsnr) tilordnet tilordnes Tilordning INF02-oppsum-9 INF02-oppsum-20

6 Relasjonsdatabasestrukturen sentralnavn UI patruljekallenavn disponerer UI sentralnavn oppdragsnr UI UI Litt om dataorienterte modeller og databaser Databaseutformerens første bud: Lag ikke modeller som gir dobbeltlagring av opplysninger! dvs. enhver tabell skal være på tredje normalform/boyce-codd normalform Korrekt gruppering av korrekte elementære utsagn gir automatisk tredje normalform/boyce-codd normalform Normaliseringsteori kan brukes for å dele opp ikke-elementære utsagn Poenget er å skille ut funksjonelle avhengigheter (=elementære utsagn med entydighetsskranke over én av rollene) der determinanten (attributtet som skal ha entydighetsskranken) ikke er gjenstand for entydighetsskranke Tilordning sentralnavn oppdragsnr tilordnet person postnr poststed Per 400 Ski Gro 400 Ski INF02-oppsum-2 INF02-oppsum-22 Litt om dataorienterte modeller og databaser (forts.) Databaseutformerens andre bud: Lag ikke modeller som fører til at det lagres opplysninger som kan avledes fra andre opplysninger! Sjekk datamodellen Er representasjonene i samsvar med begrepene? Er assosiasjonene velvalgte og fornuftige? o Gir de interessante opplysninger? o Er det sikkert at de ikke kan avledes? Firma Avdeling Ansatt? Ordre Ordrelinje Beløp avledbar totalbeløp =Σ linjebeløp o Hvis tvil: Lag forekomsttabeller! Er multiplisitetene korrekte? o Hvis tvil: Lag forekomsttabeller! Er roller angitt der hvor latmannsregelen ikke holder? Er homogenitetsregelen anvendt? Er viktige skranker dokumentert? INF02-oppsum-23 INF02-oppsum-24

7 Pass på konsistensen! Sjekk konsistensen Ugruppert form (elementære utsagn) Gruppert form Er fremmednøkkelen generert på riktig side? Er {null} angitt for fremmednøkler der minimumsmultiplisiteten er 0? UML dataorientert klassediagram med begreps-stereotype ORM-diagram UML dataorientert klassediagram klasser med attributter Relasjonsdatabasestruktur Har du fått med deg eventuelle sammensatte fremmednøkler? Er delmengdeskranker satt på mellom fremmednøkler og primærnøkler? Er undertrykking av tabeller begrunnet? Er NOT NULL angitt for alle ikke {null} attributter? Er valg av partisjonering, absorbsjon eller separasjon ved gruppering rundt underbegreper begrunnet? Er eventuelle avvik fra tredje normalform/bcnf begrunnet? Finnes det noe i relasjonsdatabasestrukturen som ikke finnes i datamodellen, eller omvendt? INF02-oppsum-25 INF02-oppsum-26 En kommentar til oppgave 3 c3 (SQL): Styring av produksjon av informasjonssystemer Databasen i 3b har i utgangspunktet faktisk ikke nok opplysninger for å kunne utføre spørringen: Det skilles ikke mellom pågående og avsluttede oppdrag. Problemet fikses enklest med et status-attributt, som da må testes i spørringen. Se også oppgave 3d: Dersom det ikke er lagt inn noe ledigmeldingstidspunkt, er oppdraget pågående. o Styringsmodeller (fossefall, iterativ, inkrementell, ) o Estimering o Kontrakter og avtaler o Håndtering av usikkerheter INF02-oppsum-27 INF02-oppsum-28

8 Evolusjonære strategier for å håndtere usikkerheter Iterativ utviklingsmodell (Forbedringer) o Gjentatte evalueringer, forbedringer og tilpasninger av kravspesifikasjon, arkitektur, programmer og informasjonssystemet o Evaluering av risiko før hver iterasjon Barry W. Boehm (988) A spiral model of software development and enhancement. IEEE Computer, May, 6-72 Inkrementell (Del-leveranser) o Gjentatte leveranser av mindre deler av systemet o Evaluering av nytte før hvert nytt delsystem utvikles Tom Gilb (988) Principles of software engineering management. Addison-Wesley, Wokingham, UK Lover og regler Rammer o Personopplysningsloven (eksamen vår 2002 oppgave 5!) Relevante opplysninger Samtykke i innsamling av persondata o Arbeidsmiljøloven Medvirkningsrett o Regler for saksbehandling Teknologi Etikk INF02-oppsum-29 INF02-oppsum-30 Verktøy og plattformer Utviklingsmiljøer o CASE-verktøy Plattformer o Databasehåndteringssystemer Programmeringsspråk Typiske eksamensoppgaver Gjennomføre en fra skallet og inn UML-modellering med o Bruksmønstre (use-case) o Sekvensdiagrammer og o Klassediagrammer Gjennomføre en fra kjernen og ut-modellering med o dataorienterte UML-klassediagrammer/ORM-diagrammer med elementære utsagn o gruppere til relasjonsdatabasestruktrur Sammenlikne og avsløre inkonsistenser i gitte o ORM-diagrammer o UML-klassediagrammer og o Tabelldatabasestrukturer SQL-spørringer Finne rammer og mulige risiki i et beskrevet prosjekt og gi begrunnet forslag til systemutviklingsmodell INF02-oppsum-3 INF02-oppsum-32

9 Eksamenstips Les gjennom hele oppgaveteksten Les oppgaven om igjen før du begynner å svare Skriv med blyant Hvis du ser flere alternative løsninger, velg den ene og nevn de andre Gjør rede for forutsetninger Bruk ikke tid på uvesentlige detaljer (skriv gjerne b istedenfor, men gjør oppmerksom på forenklingen) Svar på alle oppgavene og delspørsmålene o Blankt svar gir F, nesten blankt gir kanskje E Eksamen varer 4 timer Fordel tiden på alle oppgavene Les oppgaven om igjen for å sjekke at du har svart på alle delspørsmålene Vurder systemets kvalitet: at det er riktig system <problem-definisjon> at systemet er riktig <problem-løsning> Eksamenstips målgruppe / brukergruppe hva skal de bruke systemet til? hva trenger de av funksjonalitet? og hva trenger de ikke? hvordan skal logikken i systemet være? hvordan skal den konkretiseres i kode? og hvordan skal logikken presenteres for brukerne? INF02-oppsum-33 Institutt for informatikk Erik Arisholm/G. Tone Bratteteig Skagestein 7.mai 2003 INF02-oppsum-34 Oppsummering Hvem bestemmer hvilke systemer vi skal ha? Vi lager det systemet vi får til: det vi kan forstå av bruken (og brukerne) det vi kan få til teknisk (håndverket) Systemutviklingsprosessen Vi designer både systemet og prosessen med å lage systemet vi må velge strategi etter hvor de største problemene er Brukergrensesnittdesign Brukergrensesnittet presenterer systemet for brukeren og informasjonen i systemet (presentasjon på ulike nivåer) NB husk at brukerne tenker med sin logikk Evaluering av informasjonssystemer Systemet må virke i praksis for å vite det trengs testing heuristisk testing (etter retningslinjer) realistisk testing med brukere Lykke til! Institutt for informatikk Erik Arisholm/G. Tone Bratteteig Skagestein 7.mai 2003 INF02-oppsum-35 Institutt for informatikk Erik, Arisholm/G. Gerhard, Jens Skagestein 7.mai 2003 INF02-oppsum-36