Søgemaskinedesign ved brug af Catalysis

Søgemaskinedesign ved brug af Catalysis Kasper Egdø <egdoe@diku.dk> og Morten Bjerre <mortman@diku.dk> 0. april 2005 Indhold Introduktion 2 2 Design 2 2. Domain Model............................ 3 2.2 Renement: Domain Model II.................... 5 2.3 Renement: Domain Model III................... 6 2.4 Connectors og Components..................... 9 3 Evaluering af Catalysis 2 3. Vores indtryk af Catalysis...................... 2 3.2 Uafklarede forhold ved brug af ved Catalysis........... 3 4 Konklusion 4

Introduktion Vores mål med denne rapport er at bruge Catalysis metoden [Catalysis, Components] på et mere abstrakt eksempel for at se om metoden fungerer i praksis. Vi vil derfor bruge Catalysis design metoden til at lave et komponentbaseret design af datahentningsdelen i en søgemaskine. Denne rapport består primært af et design kapitel der beskriver vores arbejde, erfaringer og resultater ved brug af Catalysis. Til sidst er der et evalueringskapitel hvor vi evaluerer Catalysis metoden. Ved at bruge Catalysis håber vi at opnå et solidt komponentbaseret design der gør det nemt at skifte komponenter ud og vedligeholde den endelige løsning. En af os arbejder til daglig med søgemaskiner og vores design er derfor baseret på dennes viden om søgemaskiner. 2 Design I dette kapitel vil vi gennemgå den process hvor ved vores design blev lavet. Hvert afsnit i dette kapitel svarer løst til en fase i designforløbet. For hver fase vil vi kort beskrive målet set udfra Catalysis, vores tanker i løbet af fasen og resultatet af fasen. Et Catalysis design er bygget op af ere dele, først skal hele begrebsverdenen for et projekt kortlægges således at alle der er involverede i designet, snakker det samme (rigtige!) sprog. Denne overordnede begrebsverden kaldes for en Domain Model. En Domain Model består af objekter forbundet via use-cases der beskriver hvordan objekterne bruges i modellen. Catalysis metoden starter ved at der først laves en overordnet Domain Model der består af de vigtigste use-cases og objekter. Den overordnede Domain Model skal dække hele begrebsverdenen og kun indeholde de overordnede objekter og use-cases. Derefter forbedres denne model ved brug af blandt andet abstraktion og renement. Abstraktion er det at se bort fra detaljer der ellers vil forstyrre den model der er ved at blive bygget. Vi betragter abstraktion, som en måde hvorpå man kan zoome længere væk eller tættere på, og derefter nøjes med at betragte dele af modellen. Renement bruges til iterativt at føje ere detaljer til modellen. I vores design laver vi først den simple Domain Model for hele søgemaskinen. Derefter bruger vi abstraktion til at zoome ind på datahentningsdelen. De andre dele skærer vi fra for at begrænse omfanget af designprocessen, samt for at undgå at de forstyrrer. Den interessante del modellerer vi så i ere detaljer ved brug af renement i ere omgange. Til sidst håber vi på at have en detaljeret Domain Model for datahentningsdelen. Den næste fase er at bruge den endelige Domain Model til at designe components og connectors. Connectors er en abstrakt repræsentation af data udveksling og kommunikation mellem komponenter. Det er derfor vigtigt at designe connectors før components således at generelle connectors kan identiceres. De generelle connectors er de connectors, som kan bruges i mere end et tilfælde. De kan altså genbruges mange forskellige steder i den endelige implementation. Når alle connectors er på plads kan components designes og kobles sammen udfra Domain Modellen. 2

2. Domain Model For at lave en Domain Model er det vigtigt nøje at undersøge domænet: Kigge implementationen af andre søgemaskiner igennem, læse manualer til tidligere udgaver af søgemaskinen, snakke med brugere/adminen osv. I vores tilfælde havde vi dog ikke mulighed (eller tid) til at være så grundige. I stedet interviewede vi hinanden (netop således at det svarerede til forholdet mellem en kunde og en analytiker) og på baggrund af det byggede vi vores Domain Model. Den første Domain Model se gur, er lavet på det højeste abstraktionsniveau dvs. den er helt zoomet ud og indeholder alle de objekter der bruger eller bruges af søgemaskinen. Domain Modellen består af 4 objekter nemlig brugere, en adminstrator, en datakilde og selve søgemaskinen. Brugere bruger søgemaskinen til at søge og det er vist ved den use-case der hedder søg. Administratoren administrerer søgemaskinen og det er vist ved den use-case der hedder administrer. Søgemaskinen bruger datakilden til at indsamle den information som brugeren kan søge i og det er vist ved den use-case der hedder Indeksering. Bruger Søg Søge Maskine Admin Administrer Indeksering Figur : Domain Model Udfra Domain Model lavede vi en data association i modellen se gur 2 på næste side. Data associations modellen beskriver de statiske associationer der er mellem de forskellige data i Domain Modellen. Det var nødvendigt at introducere nogle ekstra data i modellen sådan at vi korrekt kunne associere Domain Modellens objekter. De nye data er Søge Udtryk der repræsenterer hvad brugeren søger efter, Resultat der repræsenterer det output brugeren ser efter en søgning og Dokument der repræsenterer søgemaskinens interne repræsentation af det der søges i. Bemærk også at Admin er associeret med datakilde direkte, dette er fordi vi besluttede at på det nuværende abstraktions niveau administrerer Adminen kun hvilke datakilder data hentes fra. 3

Vi forestiller os datakilden, som en mængde af forskellige resourcer fx. html og pdf dokumenter. Dokumenter er en samling af ord og anden interessant information struktureret på en generel måde. Søge Udtryk udtrykker hvad brugeren søger efter. Resultat er en samling af dokumenter valgt og vægtet udfra Søge Udtryk. Søge udtryk Resultat Dokument Bruger Admin Figur 2: Data association model Til sidst studerede vi vores use-cases nærmere og opstillede Conditions for hver use-case, se tabel. Conditions kan være pre conditions, conditions eller invariants (gælder alle use-cases). De er logiske udtryk der beskriver betingelser der respektivt skal være opfyldt før, efter og både før og efter for en use-case. Conditions udtrykker ekstra information der sørger for at Domain Modellen ikke bliver uklar eller tvetydig, derudover tvinger de designerne til at re-evaluere om Domain Modellen er korrekt. Hvis der ikke kan udtrykkes klare conditions til at beskrive de brugte use-cases så er der noget galt med modellen. Vores conditions er rimelig simple: Søg og Indekser har hver en condition der udtrykker at deres respektive sæt får tilføjet et resultat eller dokument efter den use-case er udført; Administrer har den condition af Søgemaskinens datakildesæt er ændret efter use-casen er udført altså der er enten tilføjet eller fjernet nogle datakilder; Søg og Administrer har en invariant der udtrykker at de to use-cases ikke ændrer ved søgemaskinens dokumentsæt. inv (Bruger,Søgemaskine) :: Søg(Søge Udtryk) De sørger Bruger.Resultatsæt = Bruger.Resultatsæt@pre resultat (Søgemaskine,Data Kilde) :: Indekser(Data Kilde) Et dokument er tilføjet Søgemaskinens dokumentsæt (DS) Søgemaskine.DS = Søgemaskine.DS@pre dokument (Admin,Søgemaskine) :: Administrer() Søgemaskinens sæt af data kilder er ændret Søgemaskine.DataKildesæt!= Søgemaskine.DataKildesæt@pre En søgning ændrer ikke på søgemaskinens dokumentsæt (DS) Søg/Administrer::Søgemaskine.DS = Søgemaskine.DS@pre Tabel : Conditions for Domain Model 4

2.2 Renement: Domain Model II Efter at have lavet den første Domain Model valgte vi at kigge på Indekserings use-casen. Vi zoomede ind på den use-case og brugte renement til at udbygge hvordan et dokument bliver indekseret og tilføjet til de dokumenter der kan søges i. Her er det vigtigt at bemærke at resultatet af renement og abstraktion skal passe med de tidligere Domain Modeller der er blevet opstillet. Hvis de ikke passer sammen er det jo ikke muligt at zoome ind og ud, og i så fald falder hele Catalysis metoden fra hinanden. Vi havde en del problemer med at tilføje ere detaljer da vi ikke helt kunne få Indeksering til at passe med de nye use-cases vi ville tilføje. Indeksering var faktisk kun en lille del af søgemaskinen der sørgede for at bygge et indeks over de søgbare dokumenter i søgemaskinen. Vi valgte derfor helt at fjerne Indeksering og lave en Tilføj Dokument use-case istedet. Det endelige resultat var at vi zoomede et stykke ind, fandt et problem med den første Domain Model, zoomede ud igen og rettede problemet således at vi kunne zoome ind igen og fortsætte med at lave renement. Denne process med at bevæge sig op og ned igennem de forskellige abstraktions niveauer er en vigtig del af Catalysis, der ikke kun er en top down metode. Resultatet blev Domain Modellen i gur 3. Bemærk at søgemaskinen fra den første Domain Model ikke indgår, istedet har vi taget en del af søgemaskinen med i Domain Modellen nemlig objektet Søgbar Mængde der repræsenterer søgemaskinens samling af dokumenter. Domain Model II består af 4 objekter nemlig datakilde, Resource, Dokument og Søgbar mængde. n indeholder en samling af Resourcer der kan hentes og parses til Dokumenter der så kan tilføjes til den Søgbar Mængde. Bruger Søg Search System Søgbar Mængde Admin Administrer Tilføj Dokument Refinement Tilføj Dokument Hent Dokument Parse Resource Figur 3: Domain Model II Udfra Domain Model II lavede vi så en Data associations model, se gur 4 på den følgende side. Det var ikke nødvendigt at tilføje ere typer data i denne omgang da Domain Model II indeholdt alle de nødvendige data. Vi havde dog en diskussion om hvordan dokumenter og resourcer skulle associeres. Kunne det f.eks. tænkes at en resource ikke har noget tilhørende dokument i søgemaskinen eller at et dokument ikke længere havde nogen tilhørende resource hvis datakilden var ændret. Vi blev enige om at modellere det ved et 0, forhold begge veje, men vi var fristede til at lave et - forhold mellem resource og dokument. I afsnit 2. blev det kort nævnt at vi forestillede os at en datakilde indeholdt resourcer. Dette objekt har vi nu tilføjet til Domain Modellen og til Data as- 5

sociations modellen. Vi forestiller os at resourcer er en binær klump, der på en eller anden måde kan konverteres til et dokument. Søgbar mængde 0, 0, Dokument Resource Figur 4: Data association model Til sidst studerede vi vores use-cases også kaldet s nærmere og opstillede Conditions for hver use-case, se tabel 2. Vores conditions er lidt mere komplicerede end i det første afsnit og vi har her kun inkluderet de vigtigste conditions: Hent udtrykker at Resource indeholder en ny resource efter hver Hent Action; Det samme gælder en Parse Dokument indeholder derefter et nyt der er resultatet af at parse en resource; Tilføj Dokument fungerer ligesom før og føjer bare et dokument til den Søgbar Mængdes dokumentsæt. Det skal nævnes at vi er rimelig usikre på om vores conditions for Hent og Parse er korrekte. Det virker som om der mangler noget mere i Domain og Data associations modellerne sådan at conditions kunne udtrykkes tydeligere. For eksempel virker det forkert at sætte objektet Resource lig en Ny Resource; det ville give bedre mening at have et objekt der indeholdt en samling af resourcer som efter en Hent operation indeholdt yderligere en resource, men så ville vi jo bare beskrive n igen. Måske burde Dokument og Resource slet ikke være objekter i Domain Model II, men vi kunne ikke helt nde ud af hvordan vi så skulle bygge modellen op så vi valgte at beholde dem som objekter. (Resource,) :: Hent() Resource indeholder nu en ny resource fra datakilden Resource = Ny Resource (Dokument,Resource) :: Parse(Resource) Dokument indeholder nu resultatet af parsningen Dokument = Parse(Resource) (Dokument,Søgbar Mængde) :: Tilføj Dokument(Dokument) Den søgbar mængde (SM) får tilføjet et dokument SM.DokumentSæt = SM.DokumentSæt@pre Dokument Tabel 2: Conditions for Domain Model II' 2.3 Renement: Domain Model III Efter at have lavet den anden Domain Model færdig valgte vi at zoome ind igen og tilføje ere detaljer, se gur 5 på den følgende side. Vi har tilføjet to nye objekter, en fortolker og en efterbehandler. Bemærk at både Fortolk og Generaliser indeholder information om hvilken type resource der fortolkes eller generaliseres. Det der modelleres er, at der er mange meget forskellige typer af resourcer og det er derfor nødvendigt at have mange forskellige fortolkere. 6

Fortolkerobjektet i Domain Model III repræsenterer derfor en masse forskellige fortolkere der bliver valgt alt efter hvilken type resource der skal fortokes. Efterbehandlingsobjektet repræsenterer det der bliver gjort ved dokumenter før de bliver tilføjet den søgbar samling f. eks. stavekontrol, oversættelse osv. Hent Resource Fortolk(R.type) Fortolker Generaliser(R.type) Søgbar mængde Tilføj Efterbehandler Efterbehandling Dokument Figur 5: Domain Model III Udfra Domain Model III forsøgte vi at lave en passende Data associations model. Modellen lignede umiddelbart meget Data associations modellen i gur 4 på foregående side, men vi kunne ikke nde ud af hvordan vi skulle modellere det faktum at hver resource har en type og at der ndes mange forskellige fortolkere der hver kan fortolke en resource. Vi prøvede at modellere det på to forskellige måder, det første forslag ses i gur 6. I forslag modellen har resourcetyper og fortolkere et til forhold og fortolkere har et til mange forhold til dokumenter. Forslag virker syntaktisk korrekt, men udtrykker ikke krystalklart det faktum at der eksisterer mange forskellige fortolkere. Fortolker Resource Type 0, Resource Efterbehandler Dokument Søgbar mængde Figur 6: Data associations model forslag Det andet forslag ses i gur 7 på næste side. I forslag 2 bruger vi trekanten til at vise at Resource Type til N er en subtype af Resource og på samme måde er Fortolker Type til N en subtype af fortolker. Vi har brugt... til at vise at der kan være vilkårlig mange resource type med tilhørende fortolker. Forslag 2 udtrykker tydeligt at der er mange forskellige fortolkere, men vi er usikre på om forslaget bryder med hvordan data modeller skal laves i Catalysis. Bemærk at vi har klippet den sidste del af forslag 2 ud da det er identisk med forslag. 7

Resource Resource Type Resource Type 2.... Resource Type N Fortolker Type Fortolker Type 2.... Fortolker Type N Fortolker Dokument Se forslag Figur 7: Data associations model forslag 2 I tabel 3 på den følgende side ses vores conditions for de use-cases der indgår i Domain Model II. Hent og Tilføj er uændrede. Fortolk use-casen indeholder en pre condition der kræver at for at fortolke en given resource skal der eksistere og bruges en fortolker med samme type som resourcen. Post conditionen for Fortolk er at Fortolkeren får tilføjet endnu en fortolket resource til fortolkerens sæt. Generaliser use-casen har en condition der udtrykker at Dokument objektet skal indeholde det resulterende dokument efter generaliseringen er udført. Det er ikke helt klart hvordan der skal stille conditions op der dækker det faktum, at der er ere fortolkere og at en resource kun kan fortolkes af en passende fortolker. Det samme gælder for generaliserings use-casen, hver generalisering skal passe med fortolkeren og derfor direkte med resourcetypen. 8

pre (Resource,) :: Hent() Resource indeholder nu en ny resource fra datakilden Resource = Ny Resource (Fortolker[Fortolker Type],Resource) :: Fortolk(Resource) Der eksisterer en fortolker der kan fortolke Resource Type Resource.Type = Fortolker Type Fortolkeren får tilføjet en fortolket resource (FR) af en hvis type til sin mængde Fortolker.FRsæt = Fortolker.FRsæt@pre FR (Dokument,Fortolker) :: Generaliser(Fortolket Resource) Dokument indeholder nu resultatet af generaliseringen Dokument = Generaliser(Fortolket Resource) (Dokument,Efterbehandler) :: Efterbehandling(Dokument) Efterbehandleren (E) får tilføjet et dokument der er blevet efterbehandlet E.DokumentSæt = E.DokumentSæt@pre Efterbehandling(Dokument) (Efterbehandler,Søgbar Mængde) :: Tilføj Dokument(Dokument) Den søgbar mængde (SM) får tilføjet et dokument SM.DokumentSæt = SM.DokumentSæt@pre Dokument Tabel 3: Conditions for Domain Model III 2.4 Connectors og Components Udfra vores domainmodel kan vi se, at de typer af ting, som "bevæger" sig rundt i systemet, er dokumenter og resourcer. I særdeleshed kan vi se at ting som datakilder, brugere og den søgbare mængde ikke er noget der umiddelbart giver mening at ytte rundt på. Til og med er disse dokumenter og resourcer nogle ret enkle/basale elementer i vores system. Dvs at det virker oplagt at man i forbindelse med konstruktion af connectors er bevidst om dette. I det konkrete tilfælde virker det endda oplagt at lave nogle connectors baseret netop på kommunikation af resourcer og dokumenter. Det udmunder i i første omgang to connectortyper, som man kan se på gur 8. Som vi har været inde på tidligere, ndes der forskellige mulige typer knyttet til resourcerne. Her er det vigtigt at understrege at resource-connectoren forestilles at anvende den generiske type (eller overklassen), og at der til denne er knyttet funktionalitet således at dens egentlige type kan afgøres, hvis dette er nødvendigt. Connectorne har også en klar sender og modtager - det er de sorte kasser der svarer til output og de hvide kasser der svarer til input, dvs. at man ved brug af disse connectores får modeleret (i hvert fald dele af) owet i applikationen der anvender disse connectors. De hvide og sorte kasser omtales mere formelt som porte. Dokument connector Resource connector Figur 8: Vores to connectortyper 9

Resouce og dokument virker måske som en for løs denition, men skal ses i lyset af at en resource meget vel kunne svare til en egentlig resource i stil med et html-, pdf- eller ocedokument, som kan repræsenteres som en klump binær data, plus en typedeskriptor. Præcis hvorledes dette modeleres er ikke interessant på connector-niveau. Disse connectors er jo stadig på et relativt højt plan designmæssigt (f.eks. fremgår det ikke hvorledes connectorne fungerer på et kodeniveau, altså om de forestilles implementeret via f.eks. events eller tilsvarende programmeringsmekanismer). De beskriver kun den overordnede kommunikation mellem (de endnu ikke denerede) komponenter. Et eksempel på hvorledes disse to connectortyper kan anvendes kan ses på gur 9 og gur 0 på næste side. Her ses hvorledes dele af vores overordnede model kunne sættes sammen ved brug af de to typer connectors og nogle mulige komponenter. Bemærk i særdeleshed at den komponent der er mærket Fortolker og generalisator givetvist vil bestå af ere komponenter, som hver i sær kan behandle en bestemt type af resource. Som modeleret tidligere ville disse også rimeligvis hver især kunne deles i to dele nemlig fortolker og generalisator. Af de to gurer ses, at det er ganske enkelt at tilføje f.eks. en stavekontrolkomponent, som stavekontroller og -retter et dokument. Der er tydeligvis ikke behov for ændringer i nogen af de øvrige komponenter for at tilføje stavekontrolskomponenten. Her kommer dokumentconnectoreren virkelig til sin ret. Fortolker og generalisator Søgemaskine Tilføjet Fortolk Fortolket Tilføj Dokument connector Resource connector Figur 9: Datahentningstrinnet udtrykt vha connectors Denne samlede fortolk-og-generaliser komponent kunne have en opbygning som den der er afbilledet på på den følgende side. Ydersiden af den samlede komponent svarer da til de to komponenter type dispatch og NOP. Førstnævnte sørger for at sende resourcer hen til en fortolker som forstår den specikke type. Sidstnævnte sørger blot for at samle samtlige fortolkede og generaliserede dokumenter i en enkelt port. Type dispatch er på tegningen vist med præcis tre connectorporte på højresiden - der er dog ikke noget i vejen for en mere kompliceret model hvor højresiden er kongurerbar, altså således at man, når man samler de mange komponenter til en løsning, opbygger en højreside, f.eks. ved nogle dynamiske arrays af porte. Man kan også se på guren at der mellem parene af fortolker og generalisatorer er mulighed, måske endda behov, for at denere nogle ere connectors. Det er måske i særdelesheds interessant hvis man ikke har en egentlig fortolk-og-generaliser-komponent, men blot anvender de enkelte dele på en måde svarende til den viste, så kan man enkelt indskyde nye komponenter mellem de enkelte fortolkere og generalisatorer; forestiller man sig f.eks. at outputet fra html-fortolker komponenten var en html-dom og tilsvarende at html-generalisatoren blot udtrak tekst, kunne en 0

Dokument connector Resource connector Fortolker og generalisator Søgemaskine Tilføjet Fortolk Fortolket Tilføj Stavekontrol Stavekontroler Stavekontrolleret Figur 0: Datahentningstrinnet med indskudt stavekontrol indskudt komponent måske fjerne uinteressante dele fra html-dom'en, inden de blev sendt videre i systemet. Fortolker og generalisator Dokument connector Specialiserede connectors Resource connector Htmlfortolker Html Gen. Fortolk Fortolket Gen. Dok. Type dispatch Pdffortolker Pdf Gen. NOP Fortolk Html Pdf Fortolk Fortolket Gen. Dok. Dok Fortolket Office Officefortolker Office Gen. Fortolk Fortolket Gen. Dok. Figur : Mulig opbygning af Fortolker og generalisator komponenten vha mindre komponenter Dette kunne eksempelvis være at man ønskede at fjerne menu/navigationsdele fra domen

3 Evaluering af Catalysis 3. Vores indtryk af Catalysis Overordnet synes vi at metoden tvang os til at overveje beslutninger mange gange, specielt omkring renements af vores s. Specielt på en sådan måde at vi ved renement opdagede at den overordnede egentligt ikke var klar. Vi tror at en del af grunden til disse genovervejelser skyldes at vores Domain model behandler nogle ting som i sig selv er ganske abstrakte i modsætning til mere håndgribelige ting som en ordre eller en kunde i et ordrestyringssystem. Konkret opdagede vi at vi havde fået blandet nogle begreber sammen på det helt overordnede niveau hvor vi oprindelige havde en indeksér, som reelt var en tilføj-. Denne fejl begik vi primært fordi hele systemet kun er interessant netop fordi der er tale om at søgemaskinen (internt) kan indeksere en dokumentmængde, men set overordnet er forbindelsen mellem datakilder og søgemaskinen blot at sørge for at søgemaskinen får tilføjet nogle dokumenter. Da vi først havde denne forskel på plads, faldt nogle øvrige modeleringsbrikker på plads. Alle de mange tegninger vi undervejs har begået (både midlertidige på tavler og dem som er vist tidligere), har i sig selv bidraget til en mere konkret diskussion af de forskellige dele. Netop fokus på modelering via tegninger er i sig selv meget værd både til diskussion og formidling og kan også ofte udtrykke nogle forhold mere koncist end en tilsvarende skriftlig forklaring. Tilsvarende er netop kombinationen af tegninger og tilhørende conditions (invarianter, pre og -conditions) på de enkelte s er et stærkt værktøj til at kontrollere Domain modellens nøjagtighed. Et noget forstyrende element i processen er dog at vejen ned gennem de enkelte renement trin kan føles meget lang specielt når man på forhånd mener at kunne forudsige hvorledes delsystemer/s bør hænge sammen. Vi havde konkret en idé om at tilføj-en, i den anden model, var en slags pipeline, som ganske enkelt ville kunne udtrykkes ved de enkelte unders. Det er også det design som i sidste ende blev resultatet, men undervejs i de forskellige renementtrin har en været svær at udtrykke. Generelt er renementtrin svære for de mere abstrakte s mellem abstrakte ting. Det er måske ganske rimeligt, idet det jo strengt taget er hele pointen i designet. En del af sværheden stammer givetvist fra at den ene af os i forvejen har en del erfaring med design af søgemaskinesystemer og således får svært ved at træde væk fra praktiske detaljere og overvejelser. Det er nok et problem der generelt vil gøre sig gældende når man forsøger at udvikle komponentbaserede løsninger, der ikke er fokuseret på en specik kunde, men i stedet på fællesløsninger til et af marked bestående af sæt af relativt ens kunder. Man vil da opleve at domaineksperten og analytikeren er den samme person. En del af de ting vi har modeleret er mere eller mindre transiente (eller blot opstår undervejs, f.eks. dokumenter) og pre- og conditions relateret til disse virker lidt anstrengte. Det er måske et tveægget sværd, idet det trods alt medfører nogle overvejelser omkring designet, og mulige problemer kan da lettere komme til udtryk. Vores oplevelse var at det sidste trin (altså af dem vi har gennemgået), nemlig design af connectors, var relativt enkelt givet de tidligere trin - connectorne opstod mere eller mindre naturligt af sig selv fra de øvrige trin. Vi kunne godt 2

tænke os at vide om connectors ville være lige så lette at lave hvis vi var på et lavere abstraktionsniveau og om Catalysis metoden generelt sørger for, at det er nemt at lave connectors. Sammenligner man Catalysis tilgangsmetode med en klassisk ikke-komponentbevidst, objektorienteret, bottom-up metode, vil det være væsentligt sværere (tror vi) at opnå et design der er samme grad tillader udskiftning og tilføjelser af ny funktionalitet, fordi man nemt kommer til at låse sig fast på en mere konkret monolitisk programstruktur. Samtidigt vil der i bottom-op tilgangen givetvist være et større fokus på hvorledes fejlsituationer og uforudsette situationer håndteres - noget der synes at mangle fra Catalysis. Det vil dog nok være svært at komme fra et objektorienteret design til et komponentbaseret design (og det er givetvist også svært at tilrette en eventuel konkret implementation) i særdeleshed fordi kommunikationen mellem de enkelte objekter givetvist er reduceret til at udtrykke kun det nødvendige, og således er mere nkornet end den typiske connector/component baserede kommunikation. 3.2 Uafklarede forhold ved brug af ved Catalysis Vi har forsøgt at følge de anvisninger og patterns som udgør Catalysis, og undrer os over et meget afslappet til håndtering af fejl-situationer. Både mht til fejl som konsekvens af defekte komponenter (altså f.eks. programmeringsfejl), som jo i praksis er uundgåelige, men også hvorledes de forestiller sig at man håndterer situationer hvor de ønskede s ikke lader sig gøre fordi deres preconditions ikke er opfyldt. Eksempelvis har forfatterne til [Catalysis] jo en arrange- hvor preconditionen (i kraft af nogle invarianter) er, at der er en ledig instruktor med de nødvendige kvalikationer. Dvs at hvis det ikke er opfyldt fejler arrange-en, men det fremgår ikke rigtigt hvad dette medfører. Isoleret set er dette måske nemt at give et svar på (kursus-would-be-aftageren får at vide at det ikke kan lade sig gøre) og arrange-en fejler da blot næsten inden den er begyndt, men for mere komplekse systemer er det måske ikke praktisk muligt at afgøre om en s samlede pre-conditions er opfyldt, før dele af dens s er gennemført. Dvs at den overordnede model måske giver det indtryk at en udføres som en atomisk transaktion, mens det skjuler at det ikke på detaljeniveau lader sig udføre som en atomisk transaktion. Dvs at der kan være noget nødvendigt fejlhåndtering (altså forårsaget af en pre-condition først undervejs i en indses ikke at være sand), som burde propageres op på det øverste niveau af modellen. Det synes der ikke umiddelbart at være lagt op til i catalysis - de nævner jo at Notice that at the coarser scale, you are not compromising the truth but only telling less of it. Everything you say in the big picture is still true when you look at the ner scale. Det er måske en sandhed med modikationer. Vi har undervejs også undret os lidt over hvorledes man bedst modelerer grupper af ting hvis eneste forskel er en type - konkret vores lille familie af fortolkere og generalisatorer, gur 5 på side 7. Det er dog muligt at det blot kræver bedre kendskab til Catalysis og UML end det vi har. Generelt savner vi en lidt mere konkret preskriptiv processbeskrivelse, i stedet for de ofte lidt løse deskriptive patterns og meget generelle og lidt for nemme eksempler. 3

4 Konklusion Catalysis er en meget stærk metode, fyldt med gode teknikker der gør det muligt at lave et solidt komponentbaseret design. Metoden er generel og omfattende nok til at løse selv meget abstrakte problemer. En anden styrke ved Catalysis er at det er et krav at alle modeller er præcise på deres abstraktions niveau, det betyder at designerne hele tiden bliver nød til at evaluere om deres model er korrekt: Hvis man ikke kan udtrykke en s conditions præcist så er data modellen eller Domain modellen nok forkert. Catalysis er dog ikke perfekt. Metoden kræver meget tid og øvelse, det er svært at opstille korrekte modeller og fejlen i en tidligere model kræver så at gå to skridt tilbage for at tage et skridt frem. Ofte er det meget svært at vide hvor langt man skal zoome ind således at de forskellige abstraktions niveauer giver mening: Skal man zoome så langt ind at der sker noget interessant eller zoome lidt ind ad gangen således at man ikke overser noget? Alt i alt er vi meget tilfredse med vores brug af metoden på en søgemaskine. Resultatet var et simpelt men eektivt komponentbaseret design af en del af en søgemaskine. At opnå det resultat tog dog mange timers arbejde mens vi konstruerede og re-evaluerede vores modeller. Vores konklusion er at Catalysis er en rigtig god metode til at lave komponentbaseret design, hvis man altså har tid til det. Litteratur [Catalysis] Desmond Francis DSouza and Alan Cameron Wills. Objects, Components,and Frameworks with UML, The Catalysis Approach. [Components] George T. Heineman and William T. Councill. Component-based Software Engineering Chapter 7. 4