Att bortse från de två parternas utseende, äktenskapet mellan samtidig beräkning och objektorienterad programmering – en förening som utövare mycket eftertraktade inom telekommunikation, högpresterande datorer, bank- och operativsystem – verkar tillräckligt lätt att ordna. Detta utseende är emellertid bedrägligt: problemet är svårt. Den här artikeln visar vägen mot en pos, en möjlig lösning. Det exakta problemet som undersöks här är begränsat till: Vad är den enklaste, minsta och mest övertygande utvidgning till metoden för systematisk objektorienterad programvara konstruktion som kan tillgodose behoven oJ samtidiga och distribuerade datorer samt de av sekventiella beräkningar? Artikeln gör inte anspråk på att diskutera samstämmighet och fördelning på ett allmänt och opartiskt sätt. Snarare tar den det objektorienterade paradigmet som ett givet (på grundval av dess bidrag till produktionen av kvalitetsprogram) och undersöker hur man bäst kan anpassa det så att det omfattar både samtidiga och sequentia;[ tillämpningar. Ordet "systematiskt" som används i titeln på artikeln kommer att ge stark gqaidance till vårt sökande efter denna minimala förlängning. Vi är intresserade av ett tillvägagångssätt som gör det möjligt att resonera om programvarusystem på ett exakt sätt, genom att utvidga de systematiska tekniker, så kallade "design by contract", som kan tillämpas på den systematiska (men inte nödvändigtvis helt formella) utvecklingen av sekventiell objektorienterad programvara. Ett ord av gnäll om den verkliga ambitionen i den modell som diskuteras här. Inget påstående görs om att det arbete som rapporterats är slutgiltigt, och ett antal möjliga kritik diskuteras i det sista avsnittet. Jag tror emellertid att den här artikeln väcker ett antal frågor i sin diskussion om hur den ömsesidiga dragningen mellan objektorientering och samstämdhet kan förvandlas till ett någorlunda lyckligt äktenskap. Även om dessa frågor är avgörande för både teoretisk förståelse och praktiskt genomförande av samtidig objektorienterad beräkning, har dessa frågor inte behandlats (eller i vissa fall ens nämnts) av tidigare arbete i ämnet, och måste lösas innan en lösning kan accepteras och tillämpas i stor utsträckning. Egenskapen som till en början antyder en enkel matchning mellan idéerna om konvergens och objektorientering är den anmärkningsvärda likheten mellan de grundläggande konstruktionerna av både objektorientering och konvergens. Det är svårt att missa analogierna mellan objekt och processer, eller mer exakt mellan de underliggande abstraktionerna: klasser och processtyper. Båda kategorierna av konstruktioner stöd: • Lokala variabler (attributer av en klass, variabler av en process eller processtyp) • Persistenta data, hålla deras värde mellan successiva aktiveringar. • Inkapslat beteende (en enda cykel för en process; ett antal rutiner för en klass) • Kraftiga restriktioner för hur moduler kan utbyta information • En kommunikationsmekanism som vanligtvis bygger på någon form av meddelande passerar. Det är därför inte förvånande att forskarna har försökt förena de två områdena. Men även om befintliga konstruktioner (för undersökningar se [1, 19] och en nyligen genomförd avhandling [17]) har introducerat många produktiva idéer, är det rimligt att konstatera att ingen hittills har lyckats tillhandahålla en allmänt accepterad mekanism för samtidig objektorienterad programmering. Den främsta orsaken är förmodligen den orimliga komplexiteten hos de flesta av de föreslagna lösningarna, som tenderar att lägga till S6 september 1993/Vo1.36, nr 9 ¢Oi41MUNIKATIONER AV THR ACM
Meyers systematiska concurrent Object-oriented Programmering (SCOOP) samtidiga programmeringsmodell REF är baserad på Eiffel.
Systematic concurrent object-oriented programming
{'venue': 'CACM', 'journal': None, 'mag_field_of_study': ['Computer Science']}