EKSAMEN I FAG SYSTEMERING 2 LØSNINGSFORSLAG Mandag 18. mai 1998 Tid: kl

Transkript

1 NORGES TEKNISK- NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP Side 1 av 2 Faglig kontakt under eksamen: Navn: Hallvard Trætteberg Tlf.: EKSAMEN I FAG SYSTEMERING 2 LØSNINGSFORSLAG Mandag 18. mai 1998 Tid: kl Hjelpemidler: Ingen tillatte hjelpemidler. Alle deloppgavene teller likt. (9 deloppgaver, 11 poeng per oppgave + et eventuelt bonuspoeng ved spesielt gode delbesvarelser (har forbeholdt denne 1C)) Oppgave 1. Modellering og modelleringsspråk A) I artikkelen No Silver Bullet Essence and Accidents of Software Engineering, nevner Brooks 4 ulike essensielle problemer ved systemutvikling. Hvilke er disse? I lys av dette, hvilke rolle kan formelle konseptuelle modelleringsspråk spille i systemutvikling? Svarskisse: Brooks fire essensielle problemer er: Kompleksitet. Merk her at han hevder at descriptions of a software entity that abstracts away its complexity often abstract away its essence i.e. vs. del to av dette spørsmålet. Han er uklar i forhold til hva det er han mener er det essentielle aspektene som abstraheres bort (ved e.g. modellering). Jmf. Kritikk av graphical programming, men her diskuteres kun flowcharts (i.e. design-beskrivelser), og ikke modellering generelt. Setter også fokus på at man må kunne se på (modellere) en virkelighet fra mange ulike perspektiver. Konformitet: (jmf. den konformitet/basisprinsipper som man (håper at man) har for eksempel i fysikk) Endrebarhet: Press for å endres fordi systemene skal holdes oppdatert i forhold til endrede funksjonelle krav og endret teknisk infrastruktur, samt at de oppfattes som enkle å endre. Usynlighet: Software er usynlig, og kan ikke visualiseres (på en komplett måte) Merk at Brooks i utgangspunktet ser på problemer ved design/programmering av ITsystemer Leser man Brooks kritisk i forhold til modellering, kan man fort få inntrykk av at han mener at alt som har med representasjon, språk, og abstraksjonsnivåer kun er accidental og ikke angriper essensen. Som Harel (Biting the bullet) nevner, er skillet essence/accidence i denne samenheng for strikt, og hans parallell til utvikling innen programmering er illustrerende. For å besvare del 2 av oppgaven mer i detalj, er et mulig utgangspunkt å se på de ulike bruksområder for konseptuelle modeller. Disse er: Representasjon av eksisterende systemer og krav til fremtidige systemer: Spesielt ved å bruke språk med formell syntaks/semantikk legger man inn økt støtte for mer komformitet, spesielt hvis det etterhvert blir enighet om hva som tradisjonelt er nyttig (vs. Harels diskusjon av en vanilla approach ). Ved at slike språk typisk også inneholder abstraksjonsmekanismer, vil dette være en måte å addressere kompleksitetsproblemet (sammen med at vokabularet er begrenset. Dette vil også begrense perspektivet, jmf. kritikken fra Brooks over, slik at det er viktig å kunne modellere fra mange ulike perspektiv).

2 Fungere som basis for kommunikasjon. Kan delvis bidra til å synliggjøre systemet (ved at man har visuelle modeller, men kanskje enda viktigere ved de teknikkene man har i forhold til å bedre den pragmatiske kvaliteten av en modell, e.g. forklaringsgenerering og prototyping/eksekvering som muliggjøres ved å bruke språk med en formell (operasjonell) semantikk. Disse aspektene er også positive i forhold til endrebarhet, ihvertfall hvis man er i stand til å vedlikeholde de (delvis visuelle) modellene, noe som baserer seg på: Basis for design og implementasjon. Se over (spesielt med tanke på kodegeneringsmulighetene basert på de formelle modellene). Merk at et språk kan være formelt på 3 måter: Formell syntaks, operasjonell semantikk og logisk semantikk. De to siste fordrer nødvendigvis den første, men et språk kan ha en operasjonell semantikk uten å ha en logisk semantikk og omvendt. Poenggiving: 5 for beskrivelsen av de fire problemene, 1 for diskusjon av Brooks kritikk av modellering i forhold til å angripe kompleksitetsproblemet, 5 for del 2 (hvordan bruk av formelle modelleringsspråk kan brukes i forhold til de essensielle problemene) A) I artikkelen Biting the Silver Bullet, formulerer Harel sitt syn på bruk av formelle modelleringsspråk i systemutvikling og krav til slike språk. Beskriv kort hans syn og de kravene han stiller og diskuter dette i forhold til elementene i kvalitetsrammeverket. Vis hvordan Statechart-språket (etter hans mening) tilfredsstiller disse språkkravene. Svarskisse: Harel er som indikert over svært positiv til bruken av denne type språk, spesifikt i forhold til reaktive systemer. I forhold til Domain Appropriateness nevner han at språkene må dekket det funksjonelle, strukturelle samt oppførselsperspektivet, med fokus på det siste. Han er svært opptatt av at språkene har en formell syntaks og semantikk (operasjonell og logisk) for å muliggjøre modelleringsaktiviteter som bidrar til øket semantisk og pragmatisk kvalite (vs. Technical actor Interpretation enhancement). I forhold til Participant interpretaion enhancement, nevner han viktighetene av at språkene er visuelle, og inneholder de nødvendige abstraksjonsmekanismene (fokus på generalisering og aggregering) Statecharts er en visual formalism som dekker aspektene i forhold til forståelse av modellen (sett fra både systemer og mennesker). Statecharts som sådann dekker strengt tatt bare oppførselsperspektivet (og knyttet mot andre modeller i Statemate, dekker den ikke den strukturelle perspektivet i særlig grad. Det funksjonelle perspektivet er delvis dekket av activitydiagrams) Merk at Harel nevner også i detalj modelleringsteknikker på empirisk, syntaktisk, semantisk, og pragamatisk nivå, men vi fokusere i denne oppgaven på språkkvalitet. Poenggiving: 3 per språkkvalitets-område, 2 i forhold til hvilke krav statecharts dekker B) PPP er et eksempel på et sett integrerte modelleringsspråk som er ment å dekke mange modelleringsperspektiv på en integrert måte. Hvilke delspråk innen PPP som beskrevet i pensum dekker hvilke perspektiver? Et perspektiv som bare er delvis dekket, er det perspektivet som Statecharts er en representant for. Kom med et forslag for å utvide PPP til også å inkorporere Statecharts på en integrert måte. Svarskisse: PPP består av følgende språk: ONER: Strukturelt og (delvis) objekt-perspektiv (men har ikke objekter, samt spesifikke mekanismer i forhold til kommunikasjon mellom objekter) PPM: Funksjonelt, delvis oppførsels (ved at man kan uttrykke samme grunnleggende temporale sammenhenger som i et tradisjonelt Petri-nett) samt talehandlingsperspektivet. DRL : Regelperspektiv AML: Aktør og rolle-perspektivet

3 Statecharts dekker oppførselsperspektivet. Nå brukes i og for en variant av Statecharts innen UID, men dette er ikke en del av den konseptuelle modelleringen innen PPP. Det er i utgangspunktet flere måter å utvide PPP på med tilstandsmodellering. En (som er mest konsistent i forhold til hvordan Statecharts brukes i UID) er å bruke tilstandsdiagrammer tilsvarende som for OMT og UML, i.e. utvide den statiske modellen, enten ved å modellere tilstandene til ulike entiteter (som må kunne snakkes om eksplisitt), eventuelt utvidet dette til også omfatte å se på tilstanden til scenarios (jmf. hvordan man bruker dette for hele skjermer i UID). Hendelser (eventuelt actions, actions kan også lenkes til metoder i ONER) kan lenkes til PPM-triggere (og man bruker (potensielt den fulle) syntaksen fra DRL-regler for å beskrive event/condition/action sammenhenger innen Statecharts). Forøvrig brukes statechartsmekanismene som de er definert, med unntak spesifikke mekanismer som Selection og Control. Et annet alternativ er å beskrive prosesser i PPM ved hjelp av tilstandsdiagrammer (ala hvordan activity-charts er utvidet med Statecharts i Statemate. Uansett type utvidelse, er det tilstrekkelig å beskrive den tekstlig. Å fremstille språkutvidelsene i form av en meta-modell (i ONER/Referent eller et annet passende språk) er å regne som en bonus (hvis språket er korrekt brukt da). En nærmere diskusjon av språkutvidelsen skal i utgangspunktet dekkes inn i 2B Poenggiving: 1 per språk/perspektiv komponent, maks 7 for språkutvidelsen, bonuspoeng for bruk av meta-modellering. Oppgave 2. Kvalitet av modeller A) I pensum er det definert et rammeverk for modellkvalitet. Beskriv de ulike kvalitetstypene som direkte involverer modellen som lages. Nevn også minst en (manuell eller verktøybasert) teknikk eller aktivitet som kan bidra til å bedre kvaliteten på dette nivået. Svarskisse: Kan baseres på figur 3.2 side 95 samt tabell 3.1 side 100. Siden vi bare skal ha de som direkte involverer modellen, er vi ute etter fysisk, empirisk, syntaktisk, semantisk, og pragmatisk kvalitet. Krever en kort beskrivelse av hver kvalitetstype som referer til de ulike settene som sammenlignes med utsagn i modellen. Hvis andre kvalitetstyper nevnes, gir ikke dette trekk (men heller ikke ekstrapoeng) Poenggiving: 1 per beskrevet kvalitetstype, 1 per teknikk innen en kvalitetstype, 1 bonuspoeng for en besvarelse som vitner om god forståelse. B) Diskuter Statechart-utvidelsen av PPP fra oppgave 1 C) i lys av de fem ulike relasjonene innen språkkvalitet. Svarskisse: Må minimum beskrive de fem områdene, i kapittel 3.10 samt indikere hvordan de er relevante sett i lys av den type utvidelse som er gjort i 1C. Domain appropriateness: Positivt i forhold til å kunne uttrykke ytterligere sammenhenger (spesielt i forhold til å modellere reaktive systemer, og ikke bare tradisjonelle informasjonssystemer), men kun hvis disse innføres på riktig nivå og i forhold til riktige typer domener. Participant Knowledge Appropriateness: Avhengig av de som skal bruke språket. Siden Statecharts allerede finnes i UID, vil det være få konseptuelle utvidelser ved at man inkluderer dette, ihvertfall for de som tidligere har brukt dette. Knowledge Externalizability Appropriateness: Dette bedres potensielt tilsvarende som domain appropriateness, men er igjen avhengig av aktørene som er involvert, hvilke måter de er vant til å eksternalisere sin kunnskap og hvilket domene det er snakk om.

4 Participant Interpretation Appropriateness. Ved en utvidelse som nevnt over, er den eneste egentlige konseptuelle utvidelsen konseptet tilstand. Selv med denne relativt minimale utvidelsen er det klart at den kan gjøre det vanskeligere å forstå og ta i bruk modelleringspalettet. Hva det er tilstand til (entitet) er allerede definert, mens events/conditions/actions kan representeres som DRL-regler, med dertil link til prosessmodeller. Her skal man være obs. på at bruken av disse i prosesser kan bli ulik den man har i tilstandsdigrammet (der en action typisk ville tilsvart en prosess). Statechartsutvidelse har abstraksjonsmekanismer innebygd, men brukt på en annen måte enn den som man har i PPP fra tidligere. Kan forøvrig ta tak i eventuelle positive og negative aspekter ved Statecharts som sådann, spesielt i samspill med eksisterende PPP-språk (e.g. ingen nye problemer i forhold til symbol discrimination, ulik størrelse på tilstandsnoder (der fordelene typisk er større enn ulempene). Technical actor interpretation enhancement: Formell syntaks og operasjonell semantikk også på utvidelsene, slik at man i prinsippet ihvertfall bør kunne utvide de teknikkene i PPP i forhold til syntaktisk, semantisk og pragmatisk kvalitet til også å utnytte den informasjonen som legges inn i Statecharts-delen for dette. Poenggiving: 1 per beskrevet område, 1 per diskusjon av språkutvidelsen, 1 bonuspoeng for en beskrivelse som tyder på god forståelse A) I øvingene er kvalitetsrammeverket benyttet til vurdering av modell- og språkkvalitet utifra en allerede definert modell eller språk. Beskriv hvordan rammeverket kan benyttes i selve modelleringsprosessen. Svarskisse: Dette kan ta utgangspunkt i beskrivelsen av prosessheuristikker i kapittel 8, samt den modellen som foreslås der (SPEC). Rammeverket som sådann kan brukes eksplisitt i forhold til at means-beskrivelsene gir pekere til mer spesifikke teknikker innen de ulike kvalitetsområdene utifra de behov man har. Viktige aspekter: Preparation: Definisjon av overordnet problemområde Valg av deltakere (basert på å identifisere stakeholders i forhold til problemområde t(stikkord: Knowledge quality) Valg av domener som skal modelleres (overordnet metodikk), samt strukturen på modelleringsmetodikken Valg av språk for de ulike modelleringsformål, i lys av domener og deltakere Valg av modelleringsverktøy (som støtter nødvendige språk og overganger mellom modeller innen ulike domener, samt har verktøystøtte for å oppnå ulike kvalitetstyper Under expansion/consolidation, kan rammeverket brukes i forhold til å foreslå hvilke kvalitetstyper man bør se på først, hvilke teknikker man skal benytte etc. Poenggiving: Avhengig av hvor mange poenger man får med, har gitt høy score hvis de fleste av de ovenstående punkter er nevnt (samt hvis man gir inntrykk av forståelse) Oppgave 3. Metode for systemutvikling A) Artikkelen Four Paradigms of Information Systems Development av Hirschheim og Klein beskriver 4 ulike paradigmer til systemutvikling basert på ulikt basissyn i forhold til hvordan man ser på verden. Gi en kort beskrivelse av de ulike paradigmene. Svarskisse: Denne inndeling tar utgangspunkt i 2 dimensjoner: Objectivistisk vs subjectivistisk og order vs. conflict, der man får fire historier

5 Funksjonalisme: Order-objektivisme. : The analyst as a system expert. Man må finne de sanne kravene til et system som alle vil være enige om, og implementere systemet i forhold til disse Sosialrelativisme: Subjektivisme-Order: The analyst as facilitator. Kravene er sosialt konstruert, og systemutvikleren skal bidra til at det dannes en felles forståelse blant de impliserte parter for denne Radical structualism: Objektivistisk-konflikt.The analyst as a labour partisan. Marxistisk. Neohumanism: Subjektivistisk,-konflikt. The analyst as emancipator or social therapist. Informasjonssystemer som frigjørende. Poenggiving: Maks 3 poeng per paradigmebeskrivelse, men totalt maks 11 A) En av de to dimensjonene som diskuteres av Hirschheim og Klein for å plassere disse fire paradigmene, er skillet mellom et objektivistisk og et konstruktivistisk (kalt subjectivism i artikkelen) verdenssyn. Hvilke betydning har et slikt basissyn for hvordan en metode vil fokusere på aktiv deltakelse (participation) av ulik interessenter (stakeholders)? Hvilken betydning har valget av verdenssyn for hvordan man vil benytte kvalitetsrammeverket i modelleringsprosessen? Svarskisse: Med et objektivistisk verdenssyn vil man inkludere eksperter på ulike felt nødvendig for å lage systemet kun i så liten omfang som mulig. Ved et konstruktivistisk verdenssyn vil man ideelt sett forsøke å involvere så mange interessenter som mulig, selv om de i utgangspunktet har overlappende kunnskap. Man vil også bruke mer tid på å opparbeide flere ulike modeller over samme område (jmf. metodebeskrivelse i kapittel 8). I forhold til rammeverket, vil man med et objektivistisk syn ikke fokusere på aspekter i forhold til perceived semantic quality og social quality, mens disse blir viktigere med et konstruktivistisk verdensbilde på bekostning av (triviell) semantisk kvalitet, siden domenet ikke her vil være gitt som sant. Poenggiving: 5 per delsvar + 1 bonus for å vise god forståelse av forskjellen Objektivistisk/konstruktivistisk B) Ved systemutvikling vil man i forskjellige faser modellere forskjellige aspekter ved et system, også kalt modeling domains i kompendiet del 2. Hvilke 4 slike domener er det man modellerer? I en artikkel i pensum diskuterer Davis overgangen mellom modellene man lager i to av disse domenene. Selv om domene er relatert illustrerer Davis hvordan overgangen mellom de ikke er liketil, selv om man i utgangspunktet bruker samme modelleringsspråk. Hvilke domener er det Davis diskuterer, og hvilke råd gir han for å gjøre overgangen lettere. Svarskisse: Følgende domener er beskrevet: Eksisterende IS-system Fremtidig IS-system Fremtidig CIS (inkluderer både kravspesifikasjon og design) Fremtidig CIS i seg selv. Davis diskuterer hovedsaklig overgangen fra analyse (fremtidig IS) til design (fremtidig CIS). En av hovedgrunnene til at overgangen ikke er enkel er nettopp at man i bunn og grunn modellerer ulike domener. Han gir følgende råd: Innse at man trenger en kravspesifikasjon (CIS-modell sett fra et eksternt synspunkt), og ikke bare en analysemodell. Ikke forvent at det er enkelt. En av hovedgrunnene til at overgangen ikke er enkel er nettopp at man modellerer ulike domener. Bruk en metodikk som passer til applikasjonsområdet som du har Bruk objektene fra OOA som et utgangspunkt (men ikke forvent at alle herfra vil overleve) Legg til andre objekter som kan identifiseres via kravspesifikasjonen

6 Gjennomfør en design (og legg til design-objekter) Poenggiving: 1 per domene, 2 for å kjenne til den overgangen som Davis diskuterer, maks 5 for rådene