Blogg
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Att säga att Web-applikationer delar många egenskaper med gamla tecken-baserade stordator-applikationer, får inte användare av web-applikationer att höja på ögonbrynen. Men en och annan cobol-IMS-programmerare skulle nog bli förvånad att höra att Jackson Structured Programming har kommit till heders igen, fast förstås under ett mycket flashigare namn. Det hetaste inom web-utveckling tycks vara “continuations”.
För er med en gedigen utvecklarbakgrund inom administrativa system, kan begreppet enkelt förklaras: automatiserad program-invertering. Många är de cobol-programmerare som sedan 80-talet tillämpat Jacksons principer för program-invertering. Syftet med program-invertering är att kunna designa ett dialog-flöde som styrt av en program-slinga, utan att behöva ta hänsyn till att dialoghanteringsmekanismen i sig är händelsestyrd.
Tänk er följande (överförenklade) användningsfall:
Med stöd för continuations, skriver man en metod i en klass som exakt följer flödet ovan. Med Jackson Structured Programming, skriver man ovanstående flöde i ett pseudo-språk. Detta körs genom en kodgenerator, som tillämpar mönstret “program-invertering” och genererar ut ett antal cobol-program-stubbar för transaktionsmonitorn CICS eller IMS.De färdiga programmen påminner om en Struts-applikation. DVS ovanstående flöde syns inte längre. Istället består programkoden av ett antal små “händelse-hanterare”, som var och en tar hand om inmatad data och eventuellt producerar utdata för nästa bild.
I språk med stöd för continuations, skriver man koden på samma sätt pseudo-koden för Jackson Structured programming, som då kan bli en direkt spegelbild av flödet i användningsfallet. Det behövs dock ingen kodgenerator, utan koden är färdig att köras.
Språk som Ruby skapar viss hype kring continuations. Är det ett bättre sätt att styra dialogflöden än Spring Webflow? Båda möjliggör komponentbaserade flöden som kan “anropas” (dvs underordnas) andra flöden. Om man använder historien för att sia om framtiden, skulle Spring Webflow vinna. Cobol-utvecklare lämnade ganska snart programinvertering. När transformeringen satt i ryggmärgen (dvs mönstret som översätter från use-case födet till den händelseorienterade modellen), slutade man använda pseudospråk+kodgenerering.