C e n t r u m v o o r W i s k u n e n I n f o r m a t i c a Abstract beteendetyper: en grundmodell för komponenter och deras sammansättning Begreppet abstrakt datatyp (ADT) har fungerat som en grundmodell för strukturerad och objektorienterad programmering i ett trettiotal år. Den nuvarande trenden inom programvaruteknik mot komponentbaserade system kräver också en grundmodell. Den mest grundläggande inneboende egenskapen hos en ADT, dvs. att det ger en uppsättning operationer, subverterar några mycket önskvärda egenskaper i framväxande formella modeller för komponenter som är baserade på objektorienterade paradigm. Vi introducerar begreppet Abstract Behavior Type (ABT) som ett högre nivå alternativ till ADT och föreslår det som en lämplig grundmodell för både komponenter och deras sammansättning. En ABT definierar ett abstrakt beteende som en relation mellan en uppsättning tidsinställda data-strömmar, utan att ange några detaljer om de operationer som kan användas för att genomföra ett sådant beteende eller de datatyper som det kan manipulera för dess förverkligande. ABT-modellen stöder en mycket lösare koppling än vad som är möjligt med ADT:s operativa gränssnitt, och är i sig kompatibel med exogen samordning. Vi föreslår att båda dessa är mycket önskvärda, om inte väsentliga, egenskaper för modeller av komponenter och deras sammansättning. För att visa nyttan av ABT-modellen beskriver vi Reo: ett exogent koordinationsspråk för kompositionskonstruktion av komponentkopplingar baserat på en kanalkalkyl. Vi visar Reos uttryckskraft och ABT:s tillämplighet genom ett antal exempel.  En abstrakt datatyp (ADT) definierar en algebra av operationer med matematiskt väldefinierad semantik, utan att specificera någon detalj om genomförandet av dessa operationer eller de datastrukturer de arbetar på för att förverkliga dem. Som sådan, ADT är en kraftfull abstraktion och inkapsling mekanism som grupperar data tillsammans med deras relaterade verksamhet i logiskt sammanhängande och löst beroende enheter, såsom objekt, vilket ger bättre strukturerade program. ADT har fungerat som en grundmodell för strukturerad och objektorienterad programmering i omkring trettio år. Den enorma framgången med objektorienterade tekniker har distraherat rätt uppmärksamhet bort från kritisk utvärdering av några av dess underliggande begrepp från perspektivet av deras nytta för komponenter. Vi föreslår att den mest grundläggande inneboende egenskapen hos en ADT, dvs. att det tillhandahåller en uppsättning operationer i sitt gränssnitt, subverterar några mycket önskvärda egenskaper i nya modeller för komponentbaserade system. Detta framgår redan av de nuvarande försöken att utvidga objektorienterade modeller till att omfatta komponenter (se t.ex. avsnitten 3 och 5). Vi introducerar begreppet Abstract Behavior Type (ABT) som ett högre nivå alternativ till ADT och föreslår det som en lämplig grundmodell för både komponenter och deras sammansättning. En ABT definierar ett abstrakt beteende som en relation mellan en uppsättning tidsinställda data-strömmar, utan att ange några detaljer om de operationer som kan användas för att genomföra ett sådant beteende eller de datatyper som det kan manipulera för dess förverkligande. I motsats till de algebraiska underbyggnaderna av ADT-modellen, 1 den (allmänt) oändliga strömmar som är elementen i beteendet i ABT-modellen naturligt låna sig till kolgebraiska tekniker och myntducering resonemang princip som nyligen har utvecklats som en allmän teori för att beskriva beteendet hos dynamiska system. ABT-modellen stöder en mycket lösare koppling än vad som är möjligt med ADT och är i sig kompatibel med exogen samordning. Vi föreslår att båda dessa är mycket önskvärda, om inte väsentliga, egenskaper för komponenter och deras sammansättning. Enligt vår mening består ett komponentbaserat system av komponentinstanser och deras anslutningar (dvs. "limkoden"), som båda är enhetligt modellerade som ABT. Den enda skillnaden mellan en komponent och en kontakt är att en komponent är en atomisk ABT vars inre struktur är okänd, medan en kontakt är känd för att vara en ABT som själv består av andra ABT. Som ett konkret exempel på tillämpningen av ABT-modellen beskriver vi Reo: en exogen samordningsmodell där komplexa koordinatorer, så kallade "kopplingar" är sammansatta av enklare [3, 4]. Reo kan användas som ett limspråk för kompositionskonstruktion av kontakter som iscensätter komponenter i ett komponentbaserat system. Vi visar den förvånansvärt uttrycksfulla kraften i ABT-komposition i Reo genom ett antal exempel. Resten av detta dokument är organiserat enligt följande. I Avsnitt 2 motiverar vi vår syn på komponenter och deras sammansättning som en konceptuell modell på en högre abstraktionsnivå än objekt och deras sammansättning. Avsnitt 3 innehåller en kort översikt över vissa relaterade arbeten. Vi går igenom det formella begreppet abstrakta datatyper i avsnitt 4 och redogör för dess kopplingar till och konsekvenser för objektorienterad programmering i avsnitt 5. Vi hävdar att vissa av dessa implikationer hindrar förmågan hos komponentmodeller baserade på objektorienterade paradigm att stödja flexibel sammansättning och exogen samordning, som vi föreslår är mycket önskvärda egenskaper i komponentbaserade system. Avsnitt 6 är en informell beskrivning av vår komponentmodell, och i Avsnitt 7 beskriver vi dess åtföljande beteendemodell. Avsnitt 8 är en introduktion till Abstract Behavior Types och deras sammansättning. I Avsnitt 9 visar vi hur kanaler, anslutningar och deras sammansättning i Reo enkelt uttrycks som ABT och deras sammansättning. Slutligen avslutar vi med våra avslutande kommentarer i avsnitt 10. Huvuddelen av arbetet med komponentbaserade system är främst inriktat på vilka komponenter som är och hur de ska konstrueras. Relativt lite uppmärksamhet har ägnats åt alternativa modeller och språk för att komponera komponenter i (under)system, som vanligtvis anses vara syftet med den så kallade limkoden, antas vara skriven på något skriptspråk. Det är uppenbart att komponenter och deras sammansättning inte är oberoende av varandra: att uttryckligen betona den ena definierar eller åtminstone begränsar den andra också, om än bara implicit. En iögonfallande drivkraft bakom det ökade intresset och aktiviteten i komponentbaserad programvara är erkännandet av att det objektorienterade paradigmet inte är den silverkula som några av dess övernitiska förespråkare påstod att det var. För närvarande återspeglar dock den dominerande synen på vilka komponenter som är eller bör vara ett framträdande objektorienterat arv: komponenter är befästa samlingar av klasser och/eller objekt, med mycket liknande gränssnitt. Härav följer att interaktioner mellan och sammansättningen av komponenter måste använda mekanismer som är mycket lika dem för interaktioner mellan och sammansättning av klasser och objekt. Metoden anropa semantik av meddelande passerar i objektorienterad programmering blir crux av komponentsammansättning mekanismer i skriptspråk. Detta synsätt på komponenter "löser" några av de problem som är rotade i bristerna i objektorienterade paradigm helt enkelt genom att flytta dem någon annanstans. Den relativt täta koppling som måste upprättas mellan en uppringare och ett par uppringda föremål försvinner till exempel som ett bekymmer på intrakomponentnivå när de två föremålen befinner sig i olika delfall, men blir en fråga som ska behandlas i limkoden och dess underliggande mellanutrustning som används för att komponera dessa komponenter. Så länge som komponenter och deras gränssnitt i huvudsak är desamma som objekt och deras gränssnitt, kommer de (skript) program som utgör limkoden i slutändan inte att vara annorlunda än annan objektorienterad programvara. I komplexa system kan kroppen av en sådan specialiserad limkod själv växa i storlek, komplexitet, inveckladhet, bräcklighet och styvhet, 2 vilket gör systemet svårt att utveckla och underhålla, trots det faktum att denna oflexibla kod wraps och ansluter annars återanvändbara, uppgraderingsbara och utbytbara komponenter. En alternativ syn på komponenter uppstår om vi tillfälligt ignorerar hur de är gjorda eller till och med vad de är gjorda av, betonar istället vad vi vill göra med dem. Förutom fashionabla jargonger, hype, och endast tekniska egenheter, måste det vara så att komponenter är mindre beroende av varandra och lättare och mer flexibla att komponera än objekt och klasser, om det ska finnas något begreppsmässigt ämne bakom termen "komponent" som förtjänar att präglas. Definitionen av en klass eller ett objekt anger de metoder som den erbjuder andra enheter, och metoden samtal inom koden för sina metoder avgör vilka tjänster och enheter som krävs för att arbeta. Detta resulterar i ett ganska stramt semantiskt ömsesidigt beroende mellan objekt/klasser och ger varje individ en betydande grad av kontroll över exakt hur det är sammansatt med andra klasser eller objekt. I motsats till objekt och klasser är det mycket önskvärt att komponenter är semantiskt oberoende av varandra och internt inte inför några restriktioner för de andra komponenter som de komponerar med. Detta ger en nivå av sammansättning flexibilitet som inte är möjlig med objekt och klass 1 och som är en förutsättning för en annan mycket önskvärd egenskap i komponentbaserade system: vi vill att hela (systemet) ska vara mer än bara summan av dess (komponent) delar. Detta innebär att det inte bara bör vara allmänt möjligt att producera olika system genom att skapa samma uppsättning komponenter på olika sätt, utan också att skillnaden mellan två system som består av samma uppsättning komponenter (dvs. skillnaden mellan "mer" än "summan av delarna" i varje system) måste uppstå ur de faktiska regler som omfattar deras två olika sammansättningar, dvs. deras limkod. Betydelsen av den senare punkten är att det kräver limkoden för att bidra till semantiken i hela systemet långt bortom den bara så kallade "wiring-standard-nivå" stöd som tillhandahålls av den nuvarande populära middleware och komponentbaserad teknik. Å andra sidan förväntar vi oss intuitivt att limkoden ska vara ogiltig från alla program-domänspecifika funktioner: dess uppgift är bara att ansluta komponenter, underlätta deras kommunikation och samordna deras interaktioner, inte att utföra någon applikation-domän specifik beräkning. Detta leder till en subtilitet när det gäller samspelet mellan limkod och komponenter som i grunden påverkar båda. Om bidraget från limkoden till beteendet hos ett sammansatt system inte är mer än att ansluta dess komponenter, underlätta deras kommunikation och samordna deras interaktioner, då skillnaden mellan beteendet hos två system som består av samma uppsättning komponenter kan uppstå inte ur någon applikation-domän specifik beräkning (och definitivt inte av komponenterna), men bara ur hur limkoden ansluter och samordnar dessa komponenter för att interagera med varandra. Eftersom limkoden är extern för de komponenter den ansluter, innebär detta att 1) komponenterna måste vara kompatibla med extern samordningskontroll och 2) limkoden måste innehålla konstruktioner för att ge sådan extern samordning. Den första implikationen begränsar de mekanismer genom vilka komponenter kan interagera med sin omgivning. Den andra konsekvensen innebär att limkodsspråket måste innehålla en exogen samordningsmodell [2]. Slutligen, om limkoden ska ha sin egen icke-triviala semantik i ett sammansatt system, är det mycket önskvärt både för limkoden själv att vara bitvis explicit identifierbar, och för semantiken i var och en av dess bitar att vara oberoende av semantiken i de specifika komponenter som den komponerar. Detta främjar erkännandet av limkoden som en identifierbar, värdefull programvaruvara, betonar vikten av dess återanvändbarhet, och förespråkar limkod konstruktion genom sammansättning av återanvändbara limkod bitar. Begreppet kompositionskonstruktion av limkod av mindre, återanvändbara bitar av limkod alla utom eliminerar konceptuella skillnader mellan komponenter och limkod. Detta föranleder oss att hitta konceptuella modeller och formella metoder för komponentbaserade system där samma regler för kompositionskonstruktion urskillningslöst gäller för både komponenter och deras limkodskopplingar. I en sådan modell, den (kanske något subjektiva) distinktionen mellan komponenter och deras (bitar av limkod) anslutningar är fortfarande praktiskt vettigt: även om de är oskiljaktiga när de används som primitiva för att komponera mer komplexa konstruktioner, komponenter och anslutningar är fortfarande olika i att komponenter är svart-box primitiver vars inre strukturer
Baserat på samma observationer om vikten av att studera lim som ett första klassens begrepp, Abstract Behavior Types (ABM) föreslogs i REF vägledande utformningen av Reo språket.
Abstract behavior types: A foundation model for components and their composition
{'venue': 'SCIENCE OF COMPUTER PROGRAMMING', 'journal': None, 'mag_field_of_study': ['Computer Science']}