Ett viktigt mål med programvaruteknik är att utnyttja likheter i systemdesign för att minska komplexiteten i att bygga nya system, stödja storskalig återanvändning och tillhandahålla automatiserad hjälp för systemutveckling. En viktig vägspärr för att uppnå detta mål är att gemensamma egenskaper hos systemen är dåligt förstådda. I detta dokument hävdar vi att formella specifikationer kan bidra till att lösa detta problem. En formell definition av en konstruktion ram kan identifiera de gemensamma egenskaperna hos en familj av system och tydliggöra dimensionerna av specialisering. Nya konstruktioner kan sedan byggas av gamla på ett principfast sätt, till lägre kostnad för designers och implementatorer. För att illustrera dessa punkter presenterar vi en formalisering av en systemintegrationsteknik som kallas implicit anspelning. Vi visar hur många tidigare orelaterade system som kan ses som exempel på samma underliggande ramverk. Sedan anger vi kortfattat hur formaliseringen gör det möjligt för oss att resonera om vissa egenskaper hos dessa system samt relationen mellan olika system. Programsystem utformas sällan isolerat. I stället utgör de flesta system en ny instans av en produkt i någon familj av relaterade system, vare sig det rör sig om redovisningssystem, databasprodukter eller kompilatorer. Varje system delar vanligtvis med andra applikationer i sin familj en gemensam "ram" av beteendemässiga och strukturella egenskaper. Ett viktigt mål med programvaruteknik är att förbättra programvaruproduktiviteten genom att utnyttja dessa ramar för att minska komplexiteten i byggsystem, stödja storskalig återanvändning och tillhandahålla automatiserat stöd för systemutveckling. I stort sett har vi inte varit särskilt framgångsrika med att göra detta. Med undantag för vissa specialiserade domäner (t.ex. kalkylblad, rapportgenerering, kompilatorkonstruktion) behandlas de flesta system som en innovativ utvecklingssatsning. Commonalities i design, om utnyttjas alls, påverkar utvecklingen främst genom tidigare erfarenhet av byggare som tillämpar sina kunskaper på ad hoc och ostrukturerade sätt. Som ett resultat av detta finns det en mångfald av systemutformningar och genomförandemekanismer, även när de resulterande produkterna har många gemensamma egenskaper. Det finns två grundläggande skäl till att vi misslyckats med att utnyttja likheter i design. För det första återspeglar skillnader i systemdesign ofta stora skillnader i systemkrav. Som exempel kan nämnas den mångfald av verktygsintegrationsmekanismer som finns i programmeringsmiljöer. Även om de flesta moderna miljöer har ett gemensamt 32 mål att integrera en uppsättning programutvecklingsverktyg, kan en miljö som krävs för att införliva befintliga verktyg mycket väl leda till en annan design för verktygsintegration än en där alla verktyg är handgjorda för miljön. Den andra orsaken till mångfalden av mönster är dock att de gemensamma egenskaperna hos dessa mönster är dåligt förstådda. Följaktligen är det svårt att dra nytta av tidigare erfarenheter när man utformar ett system, även om det nya systemet kan ha mycket gemensamt med befintliga system. (Garantier som objektorienterad design, JSP/JSD, etc., tar inte direkt itu med detta problem, eftersom de ger vägledning för hur man konstruerar specifika mönster snarare än för att förstå eller relatera familjer av mönster.) I detta dokument hävdar vi att formella specifikationer kan bidra till att lösa detta problem. För det första kan en formell definition av en designram identifiera de gemensamma egenskaperna hos en familj av system. Detta gör det möjligt att se hur tidigare orelaterade system kan behandlas som fall av samma underliggande design. För det andra kan formaliseringen, om den genomförs på rätt sätt, klargöra de dimensioner av specialisering som kan användas för att omvandla en abstrakt designram till en design för en viss applikation. På så sätt kan nya konstruktioner byggas av gamla på ett principfast sätt, till lägre kostnad för designers och implementatorer. För att illustrera dessa punkter presenterar vi en formalisering av en systemintegrationsteknik, kallad implicit anrop. Vi visar hur många tidigare orelaterade system som kan ses som exempel på samma underliggande ramverk. Sedan anger vi kortfattat hur formaliseringen gör det möjligt för oss att resonera om vissa egenskaper hos dessa system samt relationen mellan olika system. Komplexa system består vanligtvis av många komponenter, såsom datatyper, objekt, verktyg, kunskapskällor osv. En grundläggande fråga i utvecklingen av dessa system är valet av en mekanism för att integrera dessa komponenter. Visst är den vanligaste integrationsmekanismen uttrycklig uppmaning: komponenter interagerar direkt genom att ringa rutiner i andra komponenter. Dessa "rutiner" kan vara gränssnittsrutiner för abstrakta datatyper, anropskommandon av verktyg, metoder för objekt, uttryckliga frågor i databaser, etc. Men det finns en annan mekanism -- implicit anrop q som också håller på att bli en utbredd teknik för att organisera system. Tanken bakom implicit anspelning är att åtgärder som utförs av en komponent i ett system kan orsaka åberopande av rutiner i andra komponenter i systemet, utan att den ursprungliga komponenten har uttryckliga statiska hänvisningar till dessa andra komponenter. (Vi kommer att göra definitionerna av termerna "åtgärd" och "komponent" exakta senare.) Till exempel i fältsystemet [Relss 90] kan verktyg som editorer och variabla monitorer registrera intresse för en avlusares åtgärder relaterade till brytpunkter. Sedan, när avlusaren stannar vid en brytpunkt, tillkännager den en händelse som gör det möjligt för systemet att automatiskt åberopa metoder i dessa registrerade verktyg. 1 Dessa metoder kan rulla en editor till lämplig källkod eller återspela värdet av övervakade variabler. I detta schema, avlusaren helt enkelt tillkännager en händelse, men vet inte vilka andra verktyg (om några) är berörda av den händelsen, eller vad de kommer att göra när den händelsen är 1I resten av detta papper kommer vi att hänvisa till gränssnitt rutiner för en komponent som dess ~metoder ~. meddelade. Det utbredda intresset för implicita ansökningsmekanismer uppstår av minst två skäl. För det första gör implicita anropsmekanismer det lättare att bygga system som avlastar användare från att uttryckligen behöva åberopa relaterade komponenter. Ett användargränssnitt kan till exempel använda implicit uppmaning att automatiskt uppdatera flera vyer av samma data när användaren ändrar dessa data. Implicit kallelse gör system som dessa lättare att bygga eftersom komplexa interaktioner mellan komponenter inte behöver direkt kodas i själva komponenterna. På så sätt kan komponenter byggas till stor del självständigt, men stlU arbetar tillsammans för att stödja en användares mål. För det andra minskar implicita anropsmekanismer kostnaderna för systemutveckling [Sullivan ~ Notkln 90]. Eftersom komponenter är löst kopplade är det särskilt möjligt att integrera nya komponenter utan att påverka de komponenter som implicit åberopar de nya komponenterna. Detta gör det möjligt att utveckla en miljö lättare över tid, samt att konfigurera en miljö dynamiskt. Exempel på system med implicita anropsmekanismer finns i överflöd. De används i programmeringsmiljöer för att integrera verktyg [Reiss 90, Gerety 89], i databashanteringssystem för att säkerställa enhetlighet begränsningar [Hewitt 69, Balzer 86], i användargränssnitt för att separera presentation av data från program som hanterar data [Krasner ~ Påve 88], och av syntax-directed redaktörer för att stödja inkrementell semantisk kontroll [Habermann ~ Notkin 86, Habermann et al. [91] Är du säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är säker på att du är här. De förekommer också i kalkylblad, svarta tavlan system, attribut grammatik system, begränsningar-baserade system, liksom många andra typer av system. Vanligtvis har varje sådan implicit inkallelsemekanism tagits fram som en separat och innovativ design, till betydande intellektuella och utvecklingskostnader. Som vi nämnde tidigare är en av orsakerna till detta dubbelarbete att dessa mekanismer har ganska olika mål. Ett kanske mer betydande skäl är emellertid att man inte har förstått eller tills helt nyligen till och med erkänt likheterna mellan mekanismerna [Garlan et al. - Jag vet inte vad du ska göra. I resten av detta dokument visar vi hur formella specifikationer kan bidra till att tydliggöra dessa relationer. Vi presenterar en abstrakt modell av implicit anrop, baserad på begreppet händelse tillkännagivande. Sedan illustrerar vi hur specifika mönster erhålls genom att utarbeta denna abstrakta modell. Abstractly, a~l implicita anrop mekanism kan modelleras som en samling av komponenter, som var och en har ett gränssnitt som anger en uppsättning metoder och en uppsättning händelser. Som traditionellt är fallet definierar metoderna transaktioner som andra komponenter uttryckligen kan åberopa. Händelserna definierar dock åtgärder som komponenten lovar att tillkännage för andra komponenter i systemet. Den implicita inkallelsemekanismen måste också vara ett sätt att koppla händelser till metoder som ska åberopas när dessa händelser tillkännages. Vi formaliserar nu dessa idéer i tre steg med hjälp av Z specifikationsspråket. För det första definierar vi den grundläggande modellens tillståndsutrymme. Därefter definierar vi en abstrakt körtidsmodell som förklarar hur händelser tillkännages och hanteras av ett implicit besökssystem. Slutligen visar vi hur modellen kan användas för att definiera befintliga system, vilket också illustrerar hur den gör det möjligt för oss att resonera om sambanden mellan vissa av dessa system.
I REF ger Garlan och Notkin en formell grund för den underförstådda arkitektoniska stilen.
Formalizing design spaces: Implicit invocation mechanisms
{'venue': 'In VDM ’91', 'journal': None, 'mag_field_of_study': ['Computer Science']}