For å unngå å benytte to adskilte begrepsapparat, et fra Åpen-edi referansemodellen og et fra OOram, har jeg tatt det beste fra begge og harmonisert begrepene slik at jeg kun benytte et begrepsapparat. Se avsnitt «Begrepsavklaringer» i kapittel en.
I forbindelse med arbeidet med Åpen-edi referansemodellen er det utarbeidet et dokument som tar for seg konsepter og notasjoner for Åpen-edi scenarier. Rapporten heter «Concepts and Notations for Open-edi Scenarios», [Walseth]. Rapporten diskutere forskjellige notasjoner og modeller. Den stiller noen krav til de formelle beskrivelsesteknikkene som skal kunne benyttes til å beskrive Åpen-edi scenarier. Rapporten er akseptert som et gjeldende dokument i det videre arbeidet med Åpen-edi referansemodellen.
Åpen-edi referansemodellen stiller en del krav til notasjoner og modeller som skal kunne modellere forretningstransaksjoner og interaksjon mellom roller involvert i forretningstransaksjoner. Beskrivelser laget i overensstemmelse med Åpen-edi formelle beskrivelsesteknikker skal kunne brukes som kilde til automatisk eller delvis automatisk å generere et internt interorganisatorisk system som baserer seg på Åpen-edi referansemodellen. [Walseth] diskuterer en rekke metoder for å modellere forskjellige aspekter ved forretningstransaksjoner. [Walseth] har valgt å ikke diskutere noen rene objektorienterte notasjoner, men kommer med følgende betraktning om objektorienterte metoder:
«With respect to modelling, the emerging object-oriented methods may improve the interplay between different notations and the use of uniform modelling constructs. Objectoriented analysis and design methods do in general include notations for both static, dynamic and functional aspect of an information system.» ([Walseth s. 37])
OOram er en analyse- og designmetodikk med et objektorientert perspektiv.
Som oppsummering om notasjon og modeller skisserer
[Walseth] fire områder som bør dekkes av formelle beskrivelsesteknikker.
|
Områder som må dekkes av formelle beskrivelsesteknikker [Walseth] |
Åpen-edi begreper som dekker områdene [Walseth] |
Hva i OOram som dekker områdene |
| Analyse av informasjonsbehov | Informasjonspakke | Informasjonspakke, Interface View |
| Identifisering av agenter, ansvar og forpliktelser m.m. | Rolle | Rolle, rollemodeller, Process View |
| Analyse av adferd og koordinering | Rolletilstander | Rolletilstander, tilstandsoversikter |
| Analyse av lover, regler og restriksjoner | Scenarioattributter | Scenarioattributter er spredd litt ut i de forskjellige view som OOram benytter, men mye er samlet i: Collaboration View og Method Specification View. |
Tabell 2 viser sammenhengen mellom kravene til formell beskrivelsesteknikk som ifølge [Walseth] må dekkes, og hvordan Åpen-edi referansemodellen og OOram støtter begrepene.
Område «Analyse av lover, regler og restriksjoner» i Tabell 2 er OOrams svakeste punkt fordi det er spredd over flere notasjoner, og ikke enhetlig presentert. Det er mulig dette området ville blitt bedre dekket ved bruk av metoder som stammer fra andre fagfelt som jus og/ eller kunnskapsbaserte systemer. Jeg kommer derfor ikke til å grundig inn på dette området.
For å få forståelse for hvorfor de fire områdene i Tabell 2 bør være i fokus, er det nyttig å gå tilbake å se hva som menes med et interorganisatorisk system og hvordan definisjonen av forretningstransaksjon og scenario er. Hovedhensikten med interorganisatoriske systemer er at forskjellige EDI-aktører skal kunne utføre forretningstransaksjoner elektronisk. For at interorganisatoriske systemer skal gi interoperabilitet både teknologisk og virksomhetsmessig, må grensesnittene mellom de interne interorganisatoriske systemene være veldefinert. Et internt interorganisatorisk system skal ha et eksternt grensesnitt definert av den eller de rollene EDI-aktøren utøver. Informasjonspakkene som utveksles må være veldefinerte og entydige, ellers vet ikke rollene hva slags informasjon andre roller forventer å få, og rollen selv vet ikke hva den vil motta. For å kunne plassere ansvar og funksjonalitet er det helt sentralt å vite hva slags ekstern adferd en rolle har. Hvilken informasjon som skal utveksles må være definert, og det må beskrives mellom hvilke roller informasjonspakker skal utveksles.
Jeg vil i hovedsak bruke rolle og rollemodeller for å behandle område «Identifisering av agenter, ansvar og forpliktelser m.m.». For å beskrive område «Analyse av adferd og koordinering» vil jeg bruke rolletilstander og tilstandsoversikter. «Analyse av informasjonsbehov» beskriver jeg ved en egen tilvalgsmodell i kapittel 7.2.3. Jeg vil gjøre oppmerksom på at de notasjoner og modeller jeg bruker i det videre ikke er omfattende nok til å kunne realisere en automatisk generering av et internt interorganisatorisk system som baserer seg på Åpen-edi referansemodellen. Dette skyldes at jeg har verken beskrivelser eller implementeringer av de teknologiske tjenestene, og det av beskrivelser som gjøres i operativt virksomhetsperspektiv er ikke komplett.
Ved bruk av mange andre objektorienterte systemutviklingsmetoder vil en søke etter objekter og klasser og definere en og en klasse etterhvert som de blir identifisert. OOram fokuserer på samspillet mellom roller i rollemodeller. Rollemodeller viser informasjonsutvekslingen mellom roller. Dette tilsvarer samspillet mellom roller slik det er definert i Åpen-edi referansemodellen sitt scenario begrep. En EDI-aktør kan utøve flere roller, dette kan implementeres ved støtte av OOram syntese, som blir forklart i avsnitt 6.3. En vil kunne sette sammen rollemodellene til sammensatt rollemodeller hvor en enkelt EDI-aktør har til hensikt å utøver flere roller.
OOram er mer konkret enn Åpen-edi referansemodellen når det gjelder hvordan ekstern adferd for roller er modulert. En rolle er innkapslet og kommuniserer med sine omgivelse via informasjonspakker som blir lagt i rollens «innkurv» eller «utkurv». Rollen har et sett av oppgaver og regler knyttet til hva som skal gjøres med de informasjonspakkene rollen sender og mottar. Dette stemmer godt overens med Åpen-edi referansemodellen sin intensjon med rollebegrepet.
En rollemodell i OOram viser hvordan informasjonspakker utveksles mellom roller, og hvordan sekvensen er i tid. Notasjonen OOram benytter til å beskrive en rollemodell er som følger:
Et eksempel illustrerer notasjonen i bruk:
Figur 15
Figur 15 viser en rollemodell for kjøp av varer
Rollemodellen i Figur 15 består av to roller, en kjøper av en vare og en selger av denne varen. Rollemodellen viser at kjøper sender en varebestilling til selger og at selger sender en faktura til kjøper. Varebestilling og faktura er eksempler på informasjonspakker. Modellen viser ikke frakt av varen fordi frakt er vareflyt og ikke informasjonsflyt. Denne type rollemodell vil jeg kalle basis rollemodell fordi den er minimal. Det vil si at den kan ikke dekomponeres til færre roller uten å miste sin hensikt.
Figur 16
Figur 16 viser en rollemodell for betalingsformidling
Basis rollemodellen i Figur 16 består av tre roller, betaler som skal betale en regning, mottaker som skal motta penger, og betalingsformidler/ bank. Betaler sender betalingsoppdrag til banken, banken sørger for at mottakeren får en betalingsanvisning, og banken sender deretter en betalingskvittering til betaler.
OOram støtter det å se på roller i flere perspektiver. Perspektivet er avhengig av hvor vi står når vi observerer, og innholdet vi ser er avhengig av hva vi ser etter. Følgende tre perspektiver blir benyttet i OOram: (i) samspill mellom omgivelser og rollemodellen, (ii) samspill mellom rollene i rollemodellen og (iii) innholdet i den enkelte rollen.
OOram bruker ti forskjellige notasjoner for å beskrive forskjellige forhold knyttet til roller. Disse notasjonene er blant annet «Process View», «State Diagram View», «Method Spesification View» og «Area of Consern View». Til OOram finnes det CASE verktøy som støtter et utviklingsløp helt fra analyse av problemområde til implementering, vedlikehold og gjenbruk av programkode.
Når vi har flere basis rollemodeller som vi ønsker å sette sammen kan vi gjøre dette på en trygg måte ved hjelp av OOram. Denne måten å sette sammen basis rollemodeller til en sammensatt rollemodell kalles OOram syntese.
Jeg vil nå slå sammen basis rollemodellene i Figur 15 og Figur 16 til en samlet rollemodell. Rollemodellen fra Figur 15 og Figur 16 er i Figur 17 merket med stiplede rektangler. I en sammensatt rollemodell kan noen roller være sammensatte roller, men de trenger ikke være det. I eksempelet under er rollen bank ikke sammensatt, men de to andre rollene er sammensatt.
Figur 17
Figur 17 viser hvordan den sammensatte rollemodellen
for kjøp av varer og betalingsformidling blir.
I Figur 17 er basis rollemodellene for bestilling av vare og betalingsformidling slått sammen til en sammensatt rollemodell. Rollene kjøper og betaler er slått sammen til kjøper, og selger og mottaker er slått sammen til selger. De stiplede rektanglene angir de opprinnelige basis rollemodellene som denne sammensatte rollemodellen består av. All interaksjon mellom rollene går via definerte informasjonspakker, og innkomne informasjonspakker aktiviserer rollen.
Alle roller har en initial tilstand, og de kommer i denne tilstanden når de mottar en impuls fra noe utenfor seg selv. Denne impulsen kalles stimuli, og det finnes to typer stimuli for roller. Det ene er stimuli som kommer inn i rollemodellen utenfra (omgivelses stimuli). Avsender av informasjonspakken er her ikke med i selve rollemodellen. Den andre er informasjonspakker mellom roller i den aktuelle rollemodellen. Eksempler på stimuli: (i) (omgivelses stimuli) Dagens dato er forfallsdato for fakturaer. Dette skal føre til at rollen som skal foreta betaling av fakturaer må aktiviseres. (ii) Den første informasjonspakken en rolle får i en rollemodell vil være rollens stimuli.
Tilstandsoversikt for rollen selger i rollemodellen, bestilling av vare.
|
Hendelse |
Tilstand ved start |
Utfør |
Tilstand ved slutt |
| Mottar varebestilling | Initial | Send varen | Varen sendt |
| Lag faktura | Varen sendt | Lag og send faktura | Ferdig |
En rolle blir aktivisert ved at rollen mottar sitt stimuli. Når en rolle er aktiv kan den aktivisere andre roller ved å sende deres stimuli. Problemet er imidlertid at når en slår sammen rollen kjøper og betaler slik det er gjort i Figur 17, vet ikke tilstandsoversikten til den opprinnelige rollen kjøper hvordan rollen betaler aktiviseres. Når kjøper har mottatt faktura går den opprinnelige rollen over i tilstand ferdig. Dette blir feil i den sammensatte rollemodellen, for når faktura er mottatt skal betalingsoppdrag utføres. Denne sammenhengen får en ikke automatisk ved bare å slå tilstandsoversiktene sammen. Hver gang en lager sammensatte roller må en derfor sørge for at det sammensatte tilstandsdiagrammet er komplett.
Ved syntese får en et kartesisk produkt av tilstandene fra de opprinnelige tilstandsdiagrammene. Et eksempel: Rolle A har tre tilstander og rolle B har to. Et kartesisk produkt vil da være at for hver av As tre tilstander så kan B være i en av sine to. Antall tilstander blir altså As antall tilstander multiplisert med Bs antall tilstander.
Eksempel på tilstandsdiagram og problemer knyttet til tilstandseksplosjon er vist i Figur 18.
Figur 18 er hentet fra [Reenskaug96]
Figur 18 viser syntese av tilstandsdiagrammer. A1, B1
og A1B1 er initialtilstander for henholdsvis tilstandsdiagrammene A, B
og AB.
Sett at rolle A, B og C skulle slås sammen til en sammensatt rolle og de hadde henholdsvis 4, 5 og 6 tilstander. Da ville det sammensatte tilstandsdiagrammet bestå av 4*5*6 =120 tilstander. Dette kalles tilstandseksplosjon, og er et sentralt problem med syntese. For å begrense tilstandseksplosjonen må en redigere tilstandsdiagrammet til den sammensatte rollen, og gjøre manuelle tilpasninger i selve tilstandsdiagrammet. Det er en fordel om en kan begrense tilstandsdiagrammene for den sammensatte rollen til alltid å måtte bli utført sekvensielt. Da ville tilstandseksplosjonen ha gitt oss 4+5+6=15 tilstander. Jeg tror det vil være vanlig at sammensatte roller gir færre tilstander enn det et kartesisk produkt skulle tilsi. Dette fordi tilstandene til roller ofte vil være knyttet til en sekvens. Følgende eksempel viser dette:
Når det gjelder sammensatte tilstandsdiagrammer ville det aller enkleste vært om tilstandsdiagrammet til en enkelte rolle i seg selv har en gitt sekvens, og at tilstandsdiagrammene til de opprinnelige rollene alltid kan utføres etter hverandre i en bestemt sekvens. Et eksempel: Rollen A har fire tilstander som alltid skal utføres i en bestemt rekkefølge. Rollen B har fem tilstander som alltid skal utføres i en bestemt rekkefølge. Den sammensatte rollen AB blir da at alle As tilstander gjennomløpes, og når de er ferdig starter Bs tilstander. Altså 4+5 tilstander.
I forbindelse med videreutviklingen av Åpen-edi referansemodellen er det kommet forespørsler om bidrag som beskriver hvordan scenarier skal kunne settes sammen, helst med utgangspunkt i scenarier med bare to roller. En EDI-aktør skal kunne utøve en eller flere roller, og da vil de være hensiktsmessig om den formelle beskrivelsesteknikken som velges støtter det å sette sammen roller til sammensatte roller. Ved å bruke OOram syntese har jeg vist at dette er mulig.