Blood, SWAT and Tears - om storforsk-prosjektet SWAT: Semantics-preserving Weaving - Advancing the Technology

Transkript

1 Blood, SWAT and Tears - om storforsk-prosjektet SWAT: Semantics-preserving Weaving - Advancing the Technology Stein Krogdahl OMS-seminar, 9. november 2005 Inndeling av presentasjonen: Om administrasjon, penger og personer Hovedproblemstillingen i SWAT Litt om noen forskjellige felter prosjektet vil komme borti Noen ideer for arbeid og oppstart

2 SWAT: Semantics-preserving Weaving - Advancing the Technology NFR-prosjekt, Storforsk, oppstart august 2005 (i praksis desember/januar) Ved forskningsgruppen OMS (ved Ifi): Objektorientering, Modellering og Språk Totalramme 8 mill., Tre prosjekt-stipendiater, forskningsopphold, workshops, reiser, Deltakere: Øystein Haugen Stein Krogdahl (prosjektleder) Birger Møller-Pedersen Prosjekt-stipendiater: Jon Oldevik og Roy Grønmo (4 år: ¾ stip, ¼ Sintef) Institutt-stipendiat: Fredrik Sørensen (4 år: ¾ stip, ¼ undervisning) Kontakter/samarbeidspartnere: Andrew Black, Oregon State University, Portland, USA Jean-Marc Jezequel, INRIA & Univ. Rennes 1, Frankrike Ole Lehrman Madsen, Computer Science Dep. Aarhus University, Danmark Martin Odersky, Programming Methods Laboatory, EPFL, Lausanne, Sveits Jim Rumbaugh, IBM Rational, USA

3 Noen liknende prosjekter i vår nærhet - Families: - Arbeider med modellering av familier av programmer. - Kanskje kommer det en oppfølger, mest om standardisering - Creol-prosjektet - På PMA-gruppa: Arbeider med statisk typede OO-språk for distribuerte systemer - Programmene skal til en viss grad kunne forandres under veis. - Har også egenskaper mot mer formelle sider og mot verifikasjon - Prosjekt om Aspects in Modeling : - Hovedsakelig ved Colorado State University - Sentral: Robert B. France, som mange her har god kontakt med. - Det blir muligens et samarbeid med Sintef (med norske penger)

4 Hovedproblemstillingen i SWAT På øverste (og godt gammelt) nivå: Hvordan utforme et programmeringsspråk med best mulig støtte til: Separation of concerns: Forskjellige concerns, aspekter, etc. av problemstillingen/programmet kan programmeres mest mulig i sepatate program-moduler som er tekstlig sammenhengende, med en ramme rundt seg og som i størst mulig grad kan skrives, forstås, testes ut, vedlikeholdes osv. separat Orthogonal combination of modules: At disse program-moduler i størst mulig grad kan taes inn som en del av forskjellige programmer som trenger denne type funksjonalitet/egenskap, og at det da fungerer som tiltenkt, uten for mye gluecode. De samme problemene med modularisering eksisterer for modellering Vi tenker da mest på modellering som er knyttet til design-fasen Vi mener disse problemene er noe mindre studert for modellering enn for programmeringsspråk Og at det her kan være fruktbart å se på modellerings- og programmeringsspråk ut fra en bredere synsvinkel. Og ikke minst: Hva slags verktøy trenger man for effektivt å kunne ta i bruk slike språk?

5 SWAT s problemstilling: Ett nivå ned Kort SWAT-rettet historikk om modularisering (sett fra progr.språk) Først kom Fortran med aksjonspakker : Subrutiner (1957?). Rendyrket, og med blokkstruktur i Algol 60 (1958/60) Så kom Cobol med datapakker : Recorder (1959?) Så kom OO-begrepene som kombinerte dette, og la på mer (Simula 1967) Klasser og objekter Subklasser og subklasse-polymorfi Virtuelle metoder/prosedyrer/funksjoner Umiddelbart inspireret av dette kom (ca 1972) Abstrakte datatyper Som naturlig har private variable og (hjelpe) metoder Og et sett metoder som er synlige utenfra (operasjonene på ADT en) Til sammen var dette et meget store skritt framover, og det tok noe tid for fordøye dette: Så forslag til videre forbedringer kom ikke på en stund, DOG: Beta hadde klart nye ting, men fikk innflytelse på språkdesign først senere Multippel arv var det også mye snakk om (Eiffel og C++, og noe i Smalltalk) Rundt 1990 begynte det å skje en del (neste foil)

6 Rundt 1990 begynte det å skje en del Aspect-oriented programming Hvordan få samlet tekstlig ting som i den strukturen man har valgt ikke passer inn som en modul ( crosscutting concerns ). Generiske mekanismer (som var i Ada) kom nå i OO-språk Først i Eiffel, der det var noen teoretiske glipper i starten Begrepet virtuelle klasser fra Beta ble trukket fram bl.a. som et alternativ til generiske mekanismer. Man begynte å skille mellom interfacer (grensesnitt) og klasser (implementasjoner). Dette er for så vidt gammelt (ADT-er) men en ny vri med OO at disse kunne ha helt forskjellige arve-linjer. Det kom forskjellige mekanismer for å sette sammen kode-biter til f.eks. en klasse ( Traits, også part objects i Beta.) Språket Java kom (og senere C#), og dette gav et mer ryddig utgangspunkt for å diskutere varianter over OO-programmering. C++ har så mye rart at det lett ble unødvendig mye fikkel i diskusjonene

7 SWAT-drømmen Hver av disse mekanismene er blitt dyrket innenfor spesielle interesse-grupper som kan ha sin egen kultur som kanskje ikke er så innstilt på å se dem i sammenheng med andre liknende løsninger. SWAT-søknaden: La oss nå ta et skritt tilbake (i rom, ikke i tid!) og se på det som er foreslått, og finne det behov hver av dem dekker forsøke å finne mer enhetlige mekanismer som dekker flest mulige av disse behov med enklest mulige mekanismer. og ha tanke for både programmering og modellering samtidig De følgende foilene: Se noe nærmere på de forskjellige feltene listet opp på forrige foil

8 Aspect-Oriented Programming (AOP) Startet ca 1992 og fikk mer form ca. 1995, masse artikler, workshops etc. Viktige navn: Mehmet Aksit, Gregor Kiczales, Oscar Nierstrasz, Karl Lieberherr, Cristina Lopes, Lodewijk Bergmans Ide: Separation of concerns også for de concerns som ikke lar seg samle tekstlig med den hovedstrukturen programmet har. Slike concerns kalles crosscutting concerns altså behov som vil føre til tillegg mange steder i den eksisterende koden. Slike crosscutting concerns kan f.eks. være: Legge inn setninger for å lage trace av en eksekvering koordinering/synkronisering Sikkerhet:Sørge for at det blir tatt kopier av alle objekter på visse tidspunkt Spesiell terminologi: Join points: Sted man kan/skal legge inn ekstra kode Pointcuts: Mengder av join points Advice: Kode som legges inn ut fra et gitt pointcut. Weaving: Det å veve advice-koden inn på de rette steder.

9 Mer Aspect-Oriented Programming Det mest kjente språket for AOP er AspectJ (siste: AspectJ 5.0). Et annet er Hyper/J En forskjell: AspectJ gjør vevingen mer dynamisk enn Hyper/J Skal aspekter ha en interface/spesifikasjon slik at det kan sjekkes at et aspekt passer inn der man angir at det skal legges inn? Skal programmer som skal ta imot aspekter si noe om hva den vil akseptere (si hvordan de skal være spesifisert)? Eller skal skal alle aspekter kunne pådyttes alle program? Slik er det nok i AspectJ og Hyper/J Det blir svært lett dårlig interferens når man legger på flere aspekter Kan man skrive generelle aspekter som kan virker for mange programmer, og som f.eks. kan legges på et bibliotek? Skal et program kunne bygges opp bare av aspekter? Eller må du ha et grunn-program som man kan legge aspekter på?

10 Generiske mekanismer Generiske mekanismer, som var i Ada, kom nå også i OO-språk Problem: Om du fritt kan gi typer som runtime-parametere (til f.eks. prosedyrer eller klasser) så bryter statisk typesjekk sammen. Lar derfor slike parametere gies i en spesiell syntaks, og behandler dem grovt sett ferdig før eksekveringen. Generiske parametere kan være spesifiserte ( bounded ) eller uspesifiserte. Spesifiserte: Først i Eiffel (Bertrand Meyer, ca 1986) der det var noen teoretiske glipper i starten (rettet ca. 1990) Rettingene førte til F-bounded parameterization (en typeparameter kan selv forkomme i sin egen spesifikasjon: class C<T extends U<T>{ } ) Typisk uspesifiserte parametere: Templates i C++ (ca 1988) Generiske parametere må være spesifiserte for å kunne sjekke semantisk den parametriserte enheten (vanligvis en klasse). SWAT vil tenke i det!

11 Mer om generiske mekanismer Spesifiseringsmåter: Må være subklasser av eller implementere gitte klasser/interfacer (Vanligst) Må ha gitte prosedyrer/variable (Liskov/Bank/Myers, 1997) Nå er Java og C# kommet med generiske klasser. Ser nokså likt ut på overflaten, men er egentlig ganske forkjellige: Java ville ikke forandre byte-koden, så har måttet restriktere den generiske mekanismen nokså mye (ikke new T, der T er parameter) I C# ble ble bytekoden (CIL) forandret, så implementasjon kan være mer fullstendig.

12 Virtuelle klasser Beta (ca 1984, de kjente: Nygaard, Møller Pedersen, Lehrman Madsen, Bruun Kristensen) slo sammen prosedyrer og klasser til patterns, og fikk derfor virtuelle patterns (for hvertfall å dekke virtuelle prosedyrer) Man hadde dermed også fått virtuelle klasser, men dette ble først trukket fram i en artikkel i 1989 (Madsen og Møller-Pedersen). Virtuelle klasser er ikke statisk type-sjekkbart må ha run-time-tester (eller restriktere språket alvorligt) Virtuelle klasser kan også brukes til å parametrisere klasser (se neste foil) I 1997 foreslo Kresten.K.Thorup å inkludere virtuelle typer i Java (neste foil) Det har siden vært et stort antall artikler over temaene: Hva er fordeler/ulemper med å bruke virtuelle klasser/generiske parametere Hvordan kan vi begrense virtuelle klasser slik at de blir statisk type-sjekkbare, og at de samtidig er fleksible i bruk.

13 Thorups virtuelle klasser i Java: Syntaks og manglende statisk sjekkbarhet class A { typedef T as C; // C har metode m(int) T v1; ; v1.m(5); } class B extends A { typedef T as D; // D subklasse av C, har metode n(int); T v2; ; v2.m(5); ; v2.n(3); // Selvfølgelig! D v3 = v1; v1.n(3); // Men dette virker også } I et B-objekt vil også variablen v1 være typet med D (se siste linje over). T blir her en slags formell parameter til klassen A (som er spesifisert til å være en subklasse av C). For å få angitt en aktuell parameter til T må vi lage en subklasse B av A. Men det blir type-usikkert: A va; C cx; <va og cx har diverse tilordninger> ; va.v1= cx; Og kanskje peker va på et B-objekt og cx til et C-objekt. Det blir feil, og må testes for ved run-time (som for arrayer i Java).

14 Interfacer og implementasjon ble frigjort fra hverandre Skillet mellom interface og implementasjon er gammelt (ADT, Hoare ca 1972, inspirert av Simula) Dette ble også overført tilbake til OO, ved at man snakket om et objekts (eller en klasses) interface : ut fra hva klassen selv sa skulle være synlig utad Men det ble noe nytt når disse begrepene ble helt frigjort fra hverandre, ved at de kunne ha helt forskjellige arvelinjer og det var da f.eks. lett å lage mutippel arv for interfacer, selv om man ikke tillot det for klasser. Dette ble innført i Java, men var vel delvis brukt før det: I Smalltalk, der det fantes automatisk, fordi språket er helt dynamisk typet. I andre sammenhenger Henger nært sammen med debatten om subtyping =/= subclassing? Bl.a. Alan Snyder var sentral her (men mange fler)

15 Statisk komposisjon av programmer En tidlig erkjennelse var at man bruker arv/subklasser til hvertfall to ting: Til klassifisering av objekter (og det dertil hørende hierarki av typer) Til gjenbruk av kode, ved å plassere den så høyt som mulig i klasse-hierarkiet, eller ved å spesialisere en generell biblioteks-klasse ved å lage en subklasse. Men det var klart at det også var ting som ikke gikk så greit. F.eks.: Man ønsket en slags multippel arv -liknende mekanisme for å sette sammen kode (kanskje med kraftige rstriksjoner). Men brukt fullt ut blir multippel arv fort veldig kompliserende. Det er derfor kommet diverse forslag til å skille mellom mekanismer for: (1) klassifiering av objekter og (2) til gjenbruk av kode AOP kan til en viss grad brukes til det siste, og noen har stresset denne siden av AOP kraftig (setter hele programmet sammen av aspekter) Del-objekter i Beta løser noe av dette Det er foreslått skjemaer for multippel arv der man bare blir subklasse av én av de man arver fra, mens man samtidig kan ta inn kode fra et antall andre klasser. Et forslag det har vært mye snakk om i det siste er traits (neste foil)

16 Traits Hva er Traits? En/et (?) Trait er en samling metoder. Når man skal lage en klasse kan man først lage en kjerne (bl.a. med variablene), og så angi et antall Traits som man vil ha med. Nye Traits kunne også bygges av flere eksisterende Traits i flere steg Viktig at Traits skulle være en lettvektsmekansime. I utgangspunktet var Traits laget for Smalltalk, og da ble det få problemer med at ting skulle typesjekkes osv. Det arbeides nå med en variant av Traits for Java, med typesjekking og det hele (og lettvektsegenskapen kan nok da fort komme i fare). Sentrale personer: Andrew P. Black, Oscar Nierstrasz, Nathanael Schärli, Stéphane Ducasse, and Philip J. Quitslund, start ca 2003 Disse moderne Traits-arbeidere henviser også til gammelt arbeid (1982!): Gael Curry, Larry Baer, Daniel Lipkie and Bruce Lee, TRAITS: an Approach to Multiple Inheritance Subclassing Her foreslås en utvidelse av Simula 67, med noe som likner på multippel arv.

17 Oppgradering av pakke-begrepet Dette feltet springer ut av en følelse av at man må kunne ha større enheter enn klasser Som kan romme en mengde av klasser som hører logisk sammen Javas pakker er et OK første skritt, men bør bygges mer ut. Én løsning her kan være å lage et bedre utbygget system for klasser inne i klasser. Her stiller Beta sterkt (men ikke Java!) En annen løsning er å lage et oppgradert pakke begrep Dette kunne være et mer statisk begrep enn klasser, og kunne derfor få et enklere typesystem. Generiske pakker (med type-parametere), har vært foreslått Også: At det for pakker også finnes frittsvevende interfacer, og at pakker kan implementere disse. Og at pakker kan settes sammen mer fritt enn f.eks. i det nåværende Java Vi har arbeidet med Generiske pakker med litt attåt : GePEC (Generic Packages with Expandable Classes), som er foredratt om tidligere i OMS-serien.

18 Eksempel: Generisk pakke Graph generic package GRAPH expandable Node, Edge { // Oppgir de som kan ekspanderes. Fornuftig? class Node { Edge firstedge; / / First in the list of edges leaving this node Edge insertedgeto(node to){... } / / Delivers the inserted new edge } class Edge { Node from, to; Edge nextedge; / / Next in the list of edges leaving the same node void deleteme( ){... } } } Bruk: inst GRAPH Node =>City, Edge =>Road; expansion City { / / Expansion of Node String name; / / In some method: int n = firstedge.length; / / OK, as type of "firstedge" is now Road City c = new City(... ); Road r = insertedgeto(c); / / No co- or contra-variance problems... } expansion Road { / / Expansion of Edge int length; }

19 Andre ting prosjektet bør se på Språket Scala : Martin Odersky og hans Programming methods Laboratory (LAMP) Scala har egenskaper både som tradisjonelt OO-språk, og som funksjonelt språk. Har gode modulariserings-egenskaper. Beslektet med Families-prosjektet: Software Factories: J.Greenfield, K.Short, S.Cook, S.Kent Generative programming: Krzystof Czarnecki er sentral. Domain Specific Languages: Gammelt tema med fornyet interesse Class boxes: Oscar Nierstrasz Språket gbeta, Erik Ernst. Generalisering av Beta Har dynamisk arv

20 Tanker til inspirasjon for SWAT Mekanismene som er nevnt til nå er alle nyttige til sine ting men de er for mange for ett språk og de vil også lett snuble i beina på hverandre Generalisering og unifisering må til. Hvordan? Når man bruker AOP til å veve nye setninger inn mellom gamle setninger kan det svært lett ødelegge allerede etablerte egenskaper. Tilsvarende ting gjelder for Traits som blir satt sammen Vi har derfor lagt vekt på at vi ønsker mekanismer som er semantics preserving. Men lett å oppnå er det opplagt ikke! Vi har lagt vekt på å utvide veve-begrepet til all slags sammensetning av programmer på andre måter enn de direkte blir skrevet. F.eks. det at klasser og subklasser skrives hver for seg (det er viktig for fleksibiliteten!), men konkateneres til hele klasser før det lages objekter. Tilsvarende kan man tenke for generiske mekansimer, mixin-klasser og traits som settes sammen Kanskje kan dette inspirere til et videre perspektiv?

21 Ting å sette i gang med Først å fremst: Sette seg nøyere inn i det som er tenkt/skrevet innen de nevnte felter. Mer rundt GePEC: Ta nok en design-runde med GePEC ut fra ny forståelse. Lage en implementasjon av GepecJ (eller Gepec#?) Og forsøke dette ut i større programmeringssammenheng Tenke på UML 3.0? Lage gode verktøy omkring de språk vi designer. Og selvfølgelig: Arbeide fram søknader til PhD-opptaket, og da tenke på hva hver stipendiat skal konsentrere seg om. Arrangere prosjektmøter / Workshops der vi etter hvert også trekker inn våre utenlandske kontakter