NORGES TEKNISK- NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP Side 1 av 3 Faglig kontakt under eksamen: Navn: Hallvard Trætteberg Tlf.: 7359 3443 EKSAMEN I FAG SIF 8060 Modellering av Informasjonssystemer Mandag 21. mai 2001 Tid: kl 0900-1300 Hjelpemidler: Ingen tillatte hjelpemidler. Sensuren faller mandag 11. juni 2001 LØSNINGSSKISSE Oppgave 1. Objekt-orientert modellering (40%) A) I pensum er det beskrevet 7 perspektiver til modellering. Et av disse er kalt objektperspektivet. Forklar hvordan dette perspektivet relaterer seg til de andre 6 perspektivene (for eksempel, i hvilken grad er det overlapp eller motsetninger mellom dette og de andre perspektivene) (Oppgaven teller 10%) LS: Hovedpunkter i et objektorientert perspektiv: Beskrivelse av verden som autonome, kommuniserende objekter med skjult tilstand og unik ID som gjennomgår et livsløp (prosess). Hovedkonsepter: Objekt. Entitet med unik identitet og lokal tilstand som bare kan aksesseres utenfra ved å sende meldinger til dets grensesnitt (hendelser som igangsetter operasjoner/metoder). Prosess: Objektets livssyklus, de tilstandene objektet gjennomgår basert på eksterne og interne hendelser under sin livstid Klasse: Et sett av objekter som deler samme definisjoner av attributter og metode/operasjoner I forhold til de andre perspektivene: Struktur: I objektorientert modellering pleier man å modellere klassestrukturen med et språk inspirert av det strukturelle perspektivet (utvidet ER-modellering) Funksjon: Dypest sett et radikalt anderledes perspektiv, ved at man her fokuserer på ende-til-ende prosessering på tvers av dataentiteter, mens slik prosessering er delt opp og knyttet til hvert objekt/klasse som metoder innen objekt-orientering. Også objektorientert modellering (e.g. OMT, UML) mener å dekke prosessorientering i noen grad e.g. med use-case, som ikke er en OO-teknikk, og aktivitetsdiagrammer etc der mange av disse teknikkene snarere understøtter oppførselsperspektivet Oppførsel: Dekket e.g. i UML ved tilstandsdiagrammer/statecharts, og sekvensdiagrammer. 1
Regel: Selv om man innen objekt-orienterte modelleringsspråk ofte har en begrenset evne til å modeller enkle regler, dekker man ikke målhierarkier som er et hovedpoeng ved dette perspektivet. Kommunikasjon (Talehandlingsperspektiv): Ikke dekket i objekt-orientering Aktør/rolle: Noe overlapp, ved at man kan se på aktører som en spesiell type objekter, og roller som en spesiell type klasser. Dette perspektivets styrke innen organisasjonsmodellering og modellering av sosiale sammenhenger er ikke eksplisitt dekket innen objekt-orientering. Nedenfor er en situasjonsbeskrivelse (case) som skal brukes i resten av oppgaven: Møteromreservasjons-systemet: Møteromreservasjons-systemet skal gjøre det mulig å reservere rom og utstyr nødvendig for å holde et møte. Systemet skal bidra til en effektiv allokering av møterom og andre resursser (videokanonener, bærbare PC-er etc), samt være så enkelt å bruke at alle ansatte ønsker å bruke det, og at man dermed kan bruke mindre tid på å arrangere møtet, samt at møtet i seg selv blir så effektivt som mulig. Funksjonalitet som skal støttes inkluderer: Systemet skal kunne presentere en prioritert liste over forslag til reservasjoner, basert på kravene som settes av møteorganisatoren. Krav kan inkludere: Tidsperiode, varighet for møtet, utstyr og tilkoplingsmuligheter, deltagere, sted, og romkapasitet. Personer som inviteres gis en automatisk beskjed, og skal bli bedt om å sende en respons. Hvis responsen er negativ (personen kan ikke delta), skal den som arrangerer møtet få beskjed. Man skal kunne reservere nødvendige ressursser innen de definerte tidsperiodene (rom, deltakere, utstyr, og eventuelt mat), og man skal kunne endre og fjerne reservasjoner. Ved endringer av tid, sted, eller deltagere, skal disse få beskjed. Man skal kunne få en påminning før et møte skal starte B) Modeller caset i UML ved bruk av use-case og klassediagrammer (Oppgaven teller 15%) LS: Se figurer for eksempler på modeller. Viktige aspekter er at de riktige språkene er brukt, at de modellene syntaktisk riktige, og at modellene er rimelig komplette og gyldige relativt til beskrivelsen, gitt mulighetene i språket. Merk at klassediagrammet under muliggjør at man reservere resursser til å være med i tidsperioder som ikke nødvendigvis er de samme som møtes tidsperiode. Dette er ikke sagt eksplisitt i caset, og bør derfor ikke forventes. Klassediagrammet har tatt med attributter og ikke metoder. Dette er et valg jeg har gjort, det er ikke feil å ta med metoder. 2
Use-case diagram Møteromssystem Bekreft deltagelse Møteorganisator Reserver møte Oppdater møte <<include>> Møtedeltage Fjern møtereservasjon <<include>> <<include>> Send påminning Påminner 3
Klassediagram: Møte starttid : datetime slutt.tid : datetime varighet : timer 0..1 1..1 Møtereservasjon Fra : datetime Til : Datetime 1..n 0..n Resurss Kapasitet : Integrer Navn : String 1..n 0..n Opptatte intervaller 1..1 1..1 Møteorganisator 0..1 1..1 Matbestilling Person email : string Møterom Romnummer : string 0..n Inneholder 1..1 Utstyr Utstyrstype : String C) Gi en egen-evaluering av modellen som du har laget i 1B sin fysiske, empiriske, syntaktiske kvalitet. Diskuter hvordan semantisk kvalitet eventuelt kan bedres ved å benytte andre deler av UML i tillegg. (oppgaven teller 15%) LS: Må gå klart frem enten ved definisjonen eller besvarelsen at man forstår ulikheten mellom nivåene: Fysisk kvalitet: Kunnskapen til modellererne er eksternalisert i form av en konkret modell, samt at modellen er tilgjengelig for internalisering. I forhold til eksternaliseringen bør man her vurdere om man har greid å modellere alt man har av kunnskap om caset, eventuelt hvorfor man ikke har fått med alt (ikke tid, bevisst fokusert på enkelte ting fremfor andre, svakheter ved språkene, manglende kjennskap til språkene). Man kan også si noe om mediet (papir) i forhold til overføring av kunnskap (men akkurat i denne sammenheng (en eksamen) er jo ikke dette så problematisk :-). Empirisk kvalitet: Omhandler feilfrekvens når modellen leses av ulike personer basert på empiriske undersøkelser av dette. Aspekter ved pen skrift, rette linjer, bokser like store, graflayout (kryssende linjer, balansering etc) som ikke nødvendigvis kan være optimal Syntaktisk kvalitet: Korrespondanse mellom modellen og språkekstensjonen til modelleringsspråket. Har man brukt språket korrekt i henhold til syntaksreglene for språket? Hvis man vet at man har brukt syntaks feil, og påpeker dette, er dette en pluss Semantisk kvalitet: Korrespondanse mellom modellen og domenet. Det finnes to semantiske mål: 1. Gyldighet: er det noe i modellen som ikke finnes i modelleringsdomenet? 4
2. Kompletthet: Er det noe i domenet som ikke finnes i modellen? Potensiell bedring av semantisk kvalitet spiller her på hvordan vi kan uttrykke mer om caset (completeness), samt riktigere beskrivelse (validity) av caset. Spesielt i forhold til kompletthet er det spesielt nyttig å kunne uttrykke mer av prosesseringsflyt i forhold til casebeskrivelse, e.g. ved sekvensdiagrammer eller aktivitetsdiagrammer. OCL kan brukes for å uttrykke visse regler formelt (selv om de ikke-funksjonelle reglene i caset ikke kan uttrykkes ved OCL). Oppgave 2. Web-utvikling, språkkvalitet og meta-modellering (30%) Alle underoppgavene teller likt Møteromreservasjons-systemet skal implementeres som en web-applikasjon. Denne applikasjonen skal aksessere interne systemer som har styring på selve ressursallokeringen, med all funksjonaliteten i systemet tilgjengelig via et webgrensesnitt. Web-grensesnittet skal lages av HyperDesign, et designbyrå som har spesialisert seg på hypermedia-presentasjoner på web utviklet ved bruk av HDM2000, en metode laget av Baresi, Garzotto, Paolini og Valenti. A) I forhold til design av web-applikasjoner, beskrives det i pensum flere mulige utvidelser av UML. To av disse er Modelling web-application architectures with UML av Conallen From web sites to web applications: New issues for conceptual modelling av Baresi, Garzotto, og Paolini Diskuter med basis i rammeverket for språkkvalitet i pensumboka hvilke av disse utvidelsene som sannsynligvis er best egnet for modelleringen av webapplikasjonen (gitt at basis-applikasjonene allerede er modellert slik som du har gjort det i oppgave 1). Gjør (og beskriv eksplisitt) nødvendige antagelser. LS: Språkkvalitet deles i pensum i 5 områder, og det gis et poeng per beskrevet område, samt 1 poeng for en rimelig begrunnet evaluering av de to utvidelsene (oppgaven vurderes som såpass vanskelig at det ikke forventes svært detaljerte utgreiinger). Domain appropriateness: Den siste artikkelen legger vekt på et overordnet design hvor kun bruker-operasjoner modelleres. Den påpeker at andre operasjoner skal komme inn på et senere tidspunkt i modelleringsfasen. Conallen går helt klart mer i dybden i designet og skiller mellom operasjoner på klient- og tjenersiden. Dette blir et design mer på implementeringsnivå. Begge aspektene er nyttige, men i forhold til å videreføre det som typisk er gjort i oppgave 1, er det trolig den siste artikkelen gir en mest nyttig basis for modellering av de tingene som er spesifikke for en web-applikasjon. Problemstillinger rundt hva man må legge på klient og hva man må legge på en server er egentlig (tildels) uavhengig av om systemet er web-basert eller ikke (men er naturligvis viktig i et operasjonsintensivt system) 5
Participant Knowledge Appropriateness: Avhengig av de som skal bruke språket. Her ser vi i beskrivelsen at de som skal jobbe med det alt kjenner det som er beskrevet i den andre artikkelen Knowledge Externalizability Appropriateness: Dette er igjen avhengig av aktørene som er involvert, hvilke måter de er vant til å eksternalisere sin kunnskap på og hvilket domene det er snakk om. Igjen, siden det er designere som er vant til å bruke den ene metoden, kan man trygt anta at denne er det mest anvendelige. Comprehensability Appropriateness: Her er det vanskelig å komme med en veldig sterk anbefaling den ene eller andre veien. Connalens utvidelse har færrest nye konsepter, og burde være enklest å ta i bruk. Igjen, på den annen side, det andre språket er kjent av de som skal bruke det (og det er ikke gitt at dette er modeller som nødvendigvis skal vises til så mange), så det er ikke sikkert dette er et problem. Technical actor interpretation appropriateness: Begge språkene har (tildels) en formell syntaks, men ikke noen formell semantikk (som for UML), og kan ses på å være under utvikling. Vanskelig å skille de her. Det er i og for seg ikke nødvendig å trekke noen endelig konklusjon (og gjør man det kan svaret godt være den ene eller den andre, bare det er konsistent med den øvrige beskrivelsen). Allikevel vil jeg si at ut ifra beskrivelsen er sannsynligvis den andre angrepsmåten bedre egnet både siden den er kjent for utviklerne, og fordi den utfyller UML i forhold til hypertekst-grensesnitt bedre enn Conallens forslag. B) I UML kan man utvide modelleringsspråkene på veldefinerte måter. Beskriv mekanismene for språkutvidelser i UML, og sammenlign disse med mulighetene man har for tilpasning av modelleringsspråk i et meta-modelleringsverktøy som MetaCase. Diskuter fordeler og ulemper ved de to angrepsmåtene. Bruk rammeverket for språkkvalitet for å strukturere diskusjonen. LS: Mekanismene for språkutvidelse i UML er Stereotypes: Nye sub-klasser i metamodellen Tagged Values: Nye properties på klasser i metamodellen Constraints: Spesifikke regler som definerer klarer begrensninger i hvordan språkprimitiver kan kombineres (skrives i OCL). I Metacase er man i utgangspunktet fritt til å gjøre alle type endringer av en eksisterende metamodell (eventuelt kan man lage noe fra scratch). Man gjør utvidelsene i et eget meta-modelleringsspråk (GOPPR) som er spesielt laget for dette formålet (vs. at man har gjort det i UML for UML) Domain appropriateness: Et hovedaspekt i forhold til å tilpasse modelleringsspråk. En ren metamodellering gir større mulighet her, men tilsynelatende på bekostning av den gjenbruk av konsepter man har ved UML-utvidelser. På den annen side, det er ingenting i veien for å ha UML definert i MetaEdit, og bruke dette som basis for 6
en utvidelse. Hvor lurt det er å basere seg på UML er veldig avhengig av domenet. Participant Knowledge Appropriateness: Hva som er best her vil ofte være avhengig av i hvilken grad de som skal ha språkutvidelsen er godt kjent med UML eller ikke. Generelt vil man i en ren meta-modellerings angrepsmåte være istand til å tilpasse språk i stor grad til de som skal bruke det, både for metamodellen og når det gjelder notasjonen. Knowledge Externalizability Appropriateness: Tilsvarende argumentasjon som på den forrige. Dette henger også i praksis ofte også sammen med domenet. Skal man modellere en produksjonsprosess, der en objektorientert måte å abstrahere verden på ofte vil virke kunstig, er det selvfølgelig lite nyttig å ha dette som ballast. Comprehensability Appropriateness: Som indikert i pensum, er det en rekke svakheter ved UML her, et sett svakheter og problemer som man automatisk arver (og kanskje forsterker) ved å legge til enda flere konsepter. På den annen side er meta-modellering vanskelig, det er ikke enkelt å lage gode språk. Når man har full frihet, er det ofte lett at språkene man lager inneholder mange problemer i forhold til dette området. Slik sett kan de begrensningene som ligger i utvidelsesmekanismene i UML være positive (gitt at den meta-modellen man tar utgangspunkt i er veldefinert). Technical actor interpretation appropriateness: En svakhet ved en ren metamodellering er at det skal mer til for å kunne understøtte semantikken i språket, i.e. for å understøtte mer avanserte modelleringsteknikker (for å bedre semantisk, pragmatisk, og sosial kvalitet). Dette kan være enklere å få til ved veldefinerte UML-utvidelser, da de fleste UML-verktøy allerede understøtter flere slike teknikker. C) Artikkelen 'Principles for Modelling Language Design' av Paige, Ostroff og Brooke, inneholder følgende prinsipper for språkkvalitet: Simplicity, Uniqueness, Consistency, Seamlessness, Reversibility, Scalability, Supportability, Reliability, og Space Economy. Hvordan relaterer disse prinsippene seg til rammeverket for språkkvalitet? LS: Simplicity: Ingen unødvendig kompleksitet er inkludert: Dekket av Comprehensability Appropriateness. Uniqueness: Ingen redundante eller overlappende konsepter: Dekket av Comprehensability Appropriateness. Kan også være nyttig for Technical actor interpretation appropriateness. Consistency: Language features cooperate to meet language design goals: Gjerne dekket av domain appropriateness (gitt at man kan si at domenet inkluderer dette målet). Kan også være relatert til de andre (kanksje spesielt Technical actor interpretation appropriateness) 7
Seamlessness: The same abstraction can be used throughout development. Er i utgangspunktet ikke dekket av kvalitetsrammeverket (siden man der i utgangspunktet ser på modellering i forhold til et domene av gangen). Vil erfaringsmessig gå på bekostning av domain appropriateness. Gitt at kodegenerering/modellgenerering er et krav, kan dette i stor grad ses på som en spesialisering av Comprehensability Appropriateness (gitt at det er behov også for å forstå både designmodeller og kode). Reversibility: Implementation changes can be propagated into the model: Som over. Scalability: Both large and smal systems can be modelled (abstraction mechanism): Domain Appropriateness Supportability: The language is usable by humans, and supportable by tools: Første aspekt dekket av Knowledge Externalizeability appropriateness og Comprehensability Appropriateness. Andre dekket av Technical actor interpretation appropriateness. Reliability: The language encourages the production of reliable software. Domain Appropriateness Space economy: Concise models are produced. Comprehensability Appropriateness 1 poeng per område + bonuspoeng Oppgave 3. Prosessmodellering og kravmodellering (30%) Alle underoppgavene teller likt A) Artiklene om arbeidsflytsystemer i pensum fokusere i stor grad på behovet for å understøtte fleksibel og fremspirende (emergent) arbeidsflyt (workflow). Hva skiller fleksibel og emergent arbeidsflyt fra mer tradisjonell arbeidsflyt? LS: basert på foil på forelesning, viktigste aspekter er krav av endring (av brukere, og ved kjøretid), modellene er ofte ufullstendige på forhånd, og krever interaksjon med bruker 8
Static production workflow Adaptive, Dynamic workflow Emergent workflow Process model changes during enactment Activation and interpretation of the process model Not supported. Automated enactment Exception handling. Some changes allowed. Mostly automated. Some interaction at the model level. Changes are normal, mostly handled at the instance level. Interactive. Interaction at model and enactment level. Coordination Automated sequencing of tasks. Automated sequencing of tasks Automated sequencing; shared worklists and awareness for mutual adjustment. Reuse approach Through instantiation, "Play it again, Sam". Through instantiation. Some copy and paste. Combinable process templates available as resources for situated planning. Harvesting of local innovation from instances into new templates. Research challenges Transaction management, scalability, security, systems integration etc. Dynamic change problem; making running instances follow a new, changed specification. Exception handling. Modelling by end users, model reuse, enactment of incomplete models, integration of model-based functionality (in addition to enactment). B) Hvordan påvirker (og spesialiserer) behovet for fleksibilitet de 6 ulike nivåene i rammeverket for modellkvalitet (fysisk, empirisk,.) (jmr. diskusjonen i artikkelen 'Evaluating Flexible Workflow Systems' av Carlsen et. al.). LS: Fysisk: Modellen er tilgjengelig (for forståelse og endring) av flere personer (i.e. de faktiske brukerne av modellen) Empirisk: Ingen stor endring Syntaktisk: Ikke samme grad av forutsetning at modellen er syntaktisk riktig før bruk (e.g. at all flyt inn og ut av prosesser er definert), ved at man kan bruke interaksjonsmekanismer for å fylle inn manglende informasjon på en ad-hoc måte. Endringer av modellen bør understøttes av standard mekanismer for syntax-sjekk. Semantisk: Blir et dynamisk, runtime aspekt, større muligheter for å opprettholde høy semantisk kvalitet ved endringer fra forutsetningene. En utfordring her er at man selvfølgelig veldig enkelt kan legge inn ting som er feil. Pragmatisk: Svært viktig, siden modellen nå skal kunne forstås (og endres)av alle brukere. Sosialt: Ikke nødvendigvis samme behov for enighet på tvers av hele organisasjonen (endringer gjøres på instans-nivå). Behov for enighet underveis i mindre grupperinger. 9
C) I artikkelen 'From Object-oriented to Goal-oriented requirements analysis', introduseres goal-oriented modelling som et supplement til objekt-orientert analyse. Hvilke aspekter i caset i oppgave 1 kan enklere modelleres i et mål/regelorientert språk enn i UML? LS: Hovedpunkter ved regelperspektivet: Regler som if-then uttrykk, regelhierarkier og nettverk som relatere ulike regler på ulike nivå. Artikkelen det refereres til fokuserer på hvordan man kan knytte til regelhierarkier for å bedre overordnet forståelse for hva som skal understøttes, med fokus på nedbrytning av ikke-funksjonelle krav I caset (første avsnitt) er det nevnt en hel rekke slike ikke-funksjonelle krav, som man ikke har klart å representere på en god måte i eksisterende UML-språk. 10