DTU: Vi skal op ad abstraktions-stigen og væk fra synlig kildekode

Et nyt kompetencecenter ved DTU Informatik vil flytte softwareudvikleres fokus fra tekniske detaljer i kildekode til softwareudvikling baseret på modeller. Hurtigere og billigere produktion af pålidelig software er målet.

Software bliver stadigt mere kompliceret, og presset på udviklingshusene er større end nogensinde for at skrive mere pålidelig kode hurtigere og billigere.

Hvis det skal lykkes, bør softwareudviklere fremover udvikle software på et langt højere abstraktionsniveau gennem modeller i stedet for at fedte med tusindvis af kodelinjer.

Det er tankegangen bag et nyt center ved DTU Informatik, der arbejder med programmeringsparadigmet model-based software engineering og nu tilbyder sin viden til den danske industri.

»Software bliver mere og mere kompleks, og model-based software engineering handler om at bruge modeller som mere end bare illustrationer for at kunne udvikle mere pålidelig software hurtigere,« siger lektor ved DTU Informatik, Ekkart Kindler, der er en af medstifterne ved Competence Center in Model-based Software Engineering.

»På den måde kan softwareudviklere fokusere på de konceptuelle problemer i stedet for tekniske detaljer,« siger Ekkart Kindler.

Det er tanken, at software fremover i højere grad skal beskrives gennem modeller på et højt abstraktionsniveau, og at koden derefter automatisk genereres ud fra modellerne.

Ekkart Kindler påpeger, at flere softwareudviklere allerede nu genererer kode automatisk ud fra abstrakte modeller, og at der findes flere veletablerede og dedikerede måder at gå i krig med model-based software engineering på.

»Men der mangler stadig de helt rigtige notationer til at modellere adfærd og definere koordination og interaktion af adfærd mellem de forskellige systemkomponenter. Samtidig mangler man metoder til at analysere og verificere korrektheden af sine modeller,« siger Ekkart Kindler.

Det er de problemer, man gerne vil tackle på DTU Informatik, og derfor holdes begrebet åbent for nye tanker og gode idéer.

»I princippet vil vi gerne lade begrebet 'model-based software engineering' stå så åbent som muligt lige nu, fordi vi endnu ikke ved, hvilke metoder der er de bedste og mest universelle. På sigt er det meningen, at der skal være nogle få metoder, som er tilstrækkelige til næsten al slags softwareudvikling,« siger Ekkart Kindler.

Kildekoden usynlig for udvikleren
Traditionelt set har softwareudviklere ofte lagt ud med at modellere et system, inden de første linjer kode skrives.

Ifølge Ekkart Kindler vil mange objekt-orienterede softwareudviklere genkende modeller som koncept fra for eksempel UML (Unified Modeling Language), der i flere år har været brugt til at opstille abstrakte modeller for et softwaresystem under analyse- og designfasen af systemet.

Hidtil har det dog ofte været sådan, at softwareudviklerne selv har skullet omsætte modellerne til for eksempel Java- eller C++-kode.

Men helt ideelt ser Ekkart Kindler softwareudviklerne bruge automatisk kodegenerering ud fra modeller helt op til et niveau, hvor den genererede kildekode ikke behøver være synlig for udvikleren.

»Allerede i dag bruger mange softwareudviklere modeller sammen med værktøjer, der kan generere koden ud fra modellerne. Et af problemerne i dag kan dog være, at den genererede kode ikke ender med at reflektere modellen i sidste ende, fordi programmøren undervejs ændrer i koden uden at opdatere modellen,« siger Ekkart Kindler.

»Derfor er det vigtigt at synkronisere koden og modellen inden for model-based software engineering, og man kan argumentere for, om det i nogle tilfælde ville være bedre at holde softwareudvikleren fra at læse og ændre i kildekoden,« siger han.

Der findes dog også områder, hvor model-based software engineering ikke egner sig.

»Jeg ved ikke, om model-based software engineering er for alle, som det ser ud lige nu. Hvis man for eksempel har en helt klar algoritme, er der ingen grund til at pakke den ind i en model. Men jeg vil mene, at selv inden for embedded programmering kan det være gavnligt at have en grad af automatisk kodegenerering frem for at skrive koden fra bunden,« siger Ekkart Kindler.

Ifølge Ekkart Kindler forskes der lige nu i model-based software engineering mange steder i verden, og selv om der ikke findes ét fælles referenceværktøj til model-baseret softwareudvikling, fremhæver Ekkart Kindler værktøjet Eclipse Modeling Framework, som er et plug-in til udviklingsmiljøet Eclipse.

Det handler dog ikke kun om at udvikle smarte udviklingsværktøjer, men om selve tankegangen bag.

»Det afgørende er ikke, om programmeringen er på tekstniveau, og modellerne er på det grafiske niveau. Programmering kan i princippet sagtens være model-baseret og på et højt abstraktionsniveau, selvom det er tekstbaseret,« siger Ekkart Kindler.

Han er for tiden i kontakt med flere danske virksomheder, der har fattet interesse for model-baseret software engineering, og han vurderer, at paradigmet får sit helt store gennembrud inden for de næste 5-10 år.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (39)

Kommentarer (39)
Martin Skou

Wikipedia datere case tilbage til 1982. Og de fleste synes vel at et højere abstraktionsniveau vil være en fordel.

Så et interessant spørgsmål, synes jeg, er hvad der har afholdt CASE fra at få sit egentlige gennembrud.

Måske skyldes det at disse værktøjer primært hjælper med den del af projektet som er simpelt. Men når de svære 10% skal implementeres, skal værktøjet virkeligt vrides for at opnå den ønskede funktionalitet. Det er noget jeg selv har oplevet i brug af forskellige frameworks.

Torben Mogensen Blogger

Hvis modellerne er tilstrækkelige til at generere kode fra, er modellerne faktisk kildekode. De er bare beskrevet i et andet sprog.

UML er dog uegnet til dette formål, for der er ikke nogen præcis semantik for UML. Det er derfor, at kode genereret fra UML typisk bare er skeletter, der skal modificeres. Og her er så den fare, Kindler nævner: Koden bevæger sig længere og længere væk fra modellen. Derfor skal specifikationen være komplet nok til, at man ikke behøver at ændre i den genererede kode. Og så er vi ovre i domænespecifikke sprog eller formelle specifikationer i stil med VDL, begge dele "old hat".

Poul-Henning Kamp Blogger

Jeg kan godt huske "CASE" euphorien i firserne.

Produkterne var forkromede SQL generatorer der sagtens kunne lave et skærmbillede til at vedligeholde en database, men som ikke havde nogen som helst "hooks" der tillod integration in i det samlede dataflow i organisationen.

Mange erfarne folk kunne ikke se forskellen på CASE værktøjer og f.eks PL/1 eller COBOL med et godt data-dictionary værktøj.

Jeg glæder mig til at se en af Prof. Kindlers modeller faktisk virke i en realistisk applikation, indtil da tillade jeg mig at ignorere ham 100%.

Og nej, "Hello World" er ikke en realistisk applikation, selvom der er en database involveret.

Poul-Henning

Martin Bøgelund

Men helt ideelt ser Ekkart Kindler softwareudviklerne bruge automatisk kodegenerering ud fra modeller helt op til et niveau, hvor den genererede kildekode ikke behøver være synlig for udvikleren.

Jeg får ondt i maven når jeg læser den slags. Rent fysisk.

Programmer og programmering bliver mere og mere komplekse størrelser, sådan er det. Dette skyldes nye problemområder og ny teknologi, der muliggør softwareløsninger hvor det ikke tidligere var muligt eller lønsomt.

Dette kan man imødegå på forskellige måder med nye funktioner, klasser, biblioteker, osv, altså noget der tager elementer af "ensidigt getaget arbejde" ud af opgaven.

Men at lade modeller overtage hele opgaven er for meget. Abstraktion i design og udvikling er fint, men når der skal programmeres, så skal det gøres af (rigtige) programmører, og de skal have adgang til kildekoden.

Ét eller andet sted i kæden skal der være én der forholder sig til kompleksiteten og binder de abstrakte modeller og teorier sammen med den konkrete hardware. Og det skal være én der kender sin kode (og har forståelse for forretningen/domænet).

Variabler, funktioner, klasser, etc. er i sig selv abstraktioner, og tilføjelse af flere abstraktionslag vil blot tilføje vertikal kompleksitet de steder hvor der fjernes horisontal kompleksitet.

Og hvad værre er, hvis man fjerner kildekode fra programmeringsopgaven, kommer hele forretningen rendende og tror at nu kan de også programmere, fordi de kan flytte kasser på skærmen. Så der bliver købt bunkevis af licenser, genereret "usynlig" kildekode i gigabyte-størrelse, og når så ophavsmanden rejser, sendes l*rten videre til de rigtige kodere, der så må finde hoved og hale i en ugennemskuelig pærevælling af model, data, kontrolstrukturer, præsentationslag, og manuelle indtastninger der lige skal tage højde for en koncernpolitik eller en direktørs udsigt til større bonus...

Den dag der kommer et "model fremfor kode"-udspil fra en rigtig prøgrammør vil jeg overveje ikke at gå i forsvarsmode pr. refleks.

Indtil da er det: Glem det!

Hans-Kristian Bjerregaard

At kode med modeller på et så abstrakt niveau vil være som at skrive tekstdokumenter med billeder. Man kan sagtens lave et generelt udtryk men skal du opnå noget mere specifikt så falder det sammen.

Software er jo noget dybt personligt der skal afspejle det miljø det modellerer. Selv små nuancer mellem to virksomheder, der beskæftiger sig med det samme, kan gøre at et stykke software er perfekt for den ene men ikke er specielt optimal for den anden. Så så længe vi mennesker ikke kan generaliseres til ultra-abstrakte modeller så kan vores software heller ikke.

Peter Lundsby

Hvis man ser på det historisk, så er abstraktions niveauet for måden vi udvikler software på vel konstant stigende.
For nogle år siden programmerede jeg direkte imod maskinen, idag bliver det mest afviklet af en virtuel maskine, jeg bruger massere af bibliotekter og frameworks m.v. der abstraherer en række problemstillinger som jeg slipper for at sætte mig ind i. Selv i mine egen kode, forsøger jeg at finde gode abstraktioner, der hjælper mig med overskueligheden.
Det er selvfølgeligt en masse svipsere som Case tools m.v., der ikke har formået at hæve niveauet.
Personligt er jeg ikke i tvivl om, at den dagen hvor abstraktions niveauet i vores arbejde er væsentligt højere end idag kommer. Og jeg synes det er rigtigt spændende og lærerigt at betragte vejen der til.

Jon Loldrup

Hvis nu det bliver det funktionelle paradigme som bliver det nye hotte efter Java/C#, så kunne det være interessant at spekulere over hvad der så kommer efter funktionsprogrammering. Funktionsprogrammering har jo i lang tid været creme dé la creme af abstraktion (at det så ikke har slået igennem som alment udbredt paradigme er så en anden (og ærgelig) sag).

Hvad siger du Torben Mogensen? Hvad kommer efter Haskell?

Anonym (ikke efterprøvet)

Jeg kan godt huske "CASE" euphorien i firserne.

Nu siger du ikke Amanda i samme sætning - vel?
Godt nok var det lidt senere, men man troede, at et "CASE" værktøj løste alle problemer.

Men jeg husker bedre alle de det "4GL"-ting, der var guds åbenbaring til folket.

Jo, bevares, man kommer hurtigt af sted, men som vi siger:
"It only taskes you [b]this[/b} far"!

Skulle man ud over "standard løsningere", som løser "standard problemer", så er man på herrens mark.

Nåh ja, C notation:
Competitive edge != Standard problemer

En anden ting, når man snakker 'makroprogrammering', var engang hvor jeg havde muligheden for at møde, og snakke med, Alfredo Rego
Hmm. han er nok ikke så kendt uden for bitflækkerne, men anyway:
http://www.hp3000advisor.org/HpAdvisor9910/HP-honors-Rego.html

Hvor vi havde en snak om de der formastelige GOTO statements.

Vi snakkede lidt om hvem man stolede på - dig selv, eller compileren?

I diverse sprog bliver en
IF <something> til en implicit GOTO
CASE <something> of, bliver også til en GOTO

Jeg ved godt det her eksempel med GOTO er lidt lavpraktisk, men tror vi på underliggenende 'automagi',

Eller tror vi på en opbygning, og opsamling, af underliggende komponenter/biblioteker, hvor man selv har kontrol over funktionaliteten.

Måske er jeg en gammel idiot, men jeg har efterhånden indtrykket af, at 'udviklere' nærmere er 'superbrugere', og ikke udviklere.

På den anden side, så kom lommeregnerne også frem, så /regnestok/logaritmetavler blev overflødige, så man behøver ikke at forstå de bagvedliggende principper.

Jeppe Cramon

UMLs egnethed afhænger meget af hvad du bruger UML til at beskrive.
Der er meget som UML er dårligt til og der meget som bedre kan udtrykkes gennem en tekstuelt model (en DSL) i stedet for gennem en visuel model.

Men hvor visuelle modeller (og dermed også UML i form af klasse diagrammer) slår andre tilgange jeg har set, er i modelleringen strukturelle data, så som en domæne/business/entitets model (kært barn har mange navne).

For små domæne modeller er værdien af visualisering begrænset, men når du arbejder med komplekse domæner som f.eks. forsikring og pension hvor der er mange entiteter i komplekse sammenhænge, er det af utrolig stor værdi at man kan få visueliseret dette.
Vi har på flere projekter med stor fordel brugt UML og UML profiler (stereotyper) til at lave en høj niveau abstraktion af komplekse domæner.
Det har stor værdi at kunne modellere en association mellem to entiteter og annotere assocationen med <<Historik>> eller <<Versionering>> for at tilkendegive at der er tale om Aktiv Historik eller Temporal Object pattern.
Hermed får man højnet abstraktions niveauet og får skjult tekniske detaljer (som hvordan implementeres Historik eller Versionering).

Herfra bliver der så genereret kode der matcher domæne modellens anvendelsesområde (f.eks. JPA/Hibernate klasser med tilhørende ORM mapning eller WSDL dokumenter og XML Schemaer). Her er det vigtigt at have fuld kontrol over genererings fasen, for det er her at modellen og virkeligheden skal mødes. Har man ikke kontrol nok over genereringen og model ændringsforløb ender man op i det anti-pattern af udviklerne begynder at ændre i den genererede kode og dermed kommer model og kode ud af sync. Det stiller krav til feature understøttelsen i generatoren. F.eks. hvordan tillader man at udviklerne udvider det genererede uden at miste deres ændringer ved regenerering (kan f.eks. håndteres gennem partial classes, 3 level inheritance, protected regions, priviledged aspects, mixins/traits).

Med det samme man bevæger sig op i abstraktionsniveau og begynder at bruge en Model dreven tilgang (som ikke er det samme som CASE tools), får man nye muligheder som ikke var der før. F.eks. kan man bruge meta modellen fra f.eks. UML til at generere automatiske unit/integrations tests.

Jeg har tidligere blogget om hvordan vi har brugt model dreven udvikling internt: http://www.cramon.dk/Cramon/Blog/Entries/2009/5/7_Presentation_on_Model_...

Anonym (ikke efterprøvet)

Og så er vi ovre i domænespecifikke sprog eller formelle specifikationer i stil med VDL, begge dele "old hat".

Eller Z som der faktisk stadig er en del liv i. Prøv at checke iFACTS http://www.nats.co.uk/article/218/62/nats_pioneers_biggest_atc_advance_s... der er specificeret i Z. Specifikationen (og den senere implementation i SPARK) er lavet af Praxis High Integrity Systems http://www.praxis-his.com

Jeg var med til at implementere systemet og det var en fantastisk fornøjelse at have en formel specifikation i modsætning til den gængse bla bla tekst.

Jacob Christian Munch-Andersen

Jeg synes nu at vi efterhånden har nået et niveau hvor abstraktionerne tager overhånd. Se fx på SQL, en ren abstraktion, programmøren har ringe muligheder for at optimere en forespørgsel, hvis ikke databasesoftwaren selv kan klare det så er det bare ærgerligt. Værre endnu er dog den indflydelse som det har på programmører som ikke forstår hvorledes databasen virker, mange aner simpelthen ikke hvilken indflydelse deres forespørgsel har på ydelsen. Ofte bliver resultatet kode som på overfladen ser simpel ud, men som er super ineffektiv pga. en forespørgsel som ikke er korrekt optimeret.

Abstraktion kan være godt, men det er ikke noget mål i sig selv.

Oplægget her er jo lidt flydende, men altså, en ting er at lave et brugbart "programmeringssprog" som kan siges at leve op til dette "ideal", og det er da vist endda svært nok. Noget helt andet er at gøre det så godt at det med nogen rimelighed kan siges at være bedre end traditionel programmering.

Søren Løvborg

Jeg glæder mig over dette tiltag.

Det er jo en offentlig hemmelighed at en stor del af de studerende på DTU's Softwareteknologi-uddannelse forlader studiet uden at kunne programmere.

Undskyldningen plejer at være at de ikke skal kode, men skal designe software og lede udviklingen. Da dette imidlertid heller ikke er noget, der indgår i det typiske uddannelsesforløb, er det godt at se at DTU er kommet videre:

Nu skal softwareingeniører hverken kunne programmering, design eller udvikling, men derimod modellering.

Tænk, om kun fem år kan det første hold softwareingeniører i verdensklasse være klar til at løse alverdens problemer... på den her måde: http://u.dk/?ST

Anonym (ikke efterprøvet)

Nu skal softwareingeniører hverken kunne programmering, design eller udvikling, men derimod modellering.

Softwareingeniører fra DTU har altid skulle kunnet modellere. Faktisk udgør det den mest centrale del af uddannelsen som softwareingeniør.

Torben Mogensen Blogger

Hvad siger du Torben Mogensen? Hvad kommer efter Haskell?

Der kommer mange sprog, der har hver deres fordele og ulemper.

En ting, jeg tror man vil se mere til, er statisk verifikation af programegenskaber: At antagelser og forudsætninger bliver kodet eksplicit i programmerne og checket under oversættelse.

Jeg tror også, at concurrency og parallelitet bliver mere integreret i selve sprogdesignet i stedet for at blive tilføjet som biblioteksfunktioner og lignende. Deling af ressourcer bliver gjort mere eksplicit (og til undtagelsen nærmere end reglen) for at hjælpe parallelitet.

Torben Mogensen Blogger

Jeg synes nu at vi efterhånden har nået et niveau hvor abstraktionerne tager overhånd. Se fx på SQL, en ren abstraktion, programmøren har ringe muligheder for at optimere en forespørgsel, hvis ikke databasesoftwaren selv kan klare det så er det bare ærgerligt.

SQL er designet, så forespørgsler KAN optimeres automatisk ved at normalisere forspørgslerne. Hvis du bruge mere direkte adgang til databasen, ville programmører i 99.99% af tilfældende lave uoptimeret kode, der kører forfærdeligt langsomt.

Hvis du ikke stoler på, at din database kan optimere dit SQL, kan du selv gøre det ved at omskrive dit SQL UDEN at skulle til at rode med lavniveau databasekode.

Værre endnu er dog den indflydelse som det har på programmører som ikke forstår hvorledes databasen virker, mange aner simpelthen ikke hvilken indflydelse deres forespørgsel har på ydelsen. Ofte bliver resultatet kode som på overfladen ser simpel ud, men som er super ineffektiv pga. en forespørgsel som ikke er korrekt optimeret.

Den risiko er større, hvis du koder direkte i lavniveau databasekode.

Abstraktion kan være godt, men det er ikke noget mål i sig selv.

Helt enig. Men i SQL er abstraktionen netop nødvendig for at kunne lave optimering af forespørgsler. Abstraktion kan have mange fordele, hvis den bruges rigtigt:

  • Koden bliver væsentligt mindre og hurtigere at skrive.

  • Visse egenskaber (f.eks. atomisk update) kan garanteres statisk.

  • Man undgår overspecifikation af f.eks. rækkefølgen, ting sker i, hvilket ofte hindrer optimering.

  • Man kan frigøre programmøren for en masse lavniveau bogholderikode.

  • Man kan udnytte algebraiske love til at lave højniveau optimeringer af koden uden at forlade abstraktionen.

  • Optimeringer kan løbende tilpasses egenskaber ved den gældende platform, så man undgår at optimeringer bliver forældede ved skift af platform.

  • Den abstrakte beskrivelse er i et vist omfang sin egen dokumentation, hvilket lavniveaukode sjældent er.

Men det er klart, at der findes mange tilfælde, hvor abstraktioner er brugt forkert, og derfor ikke giver nogle fordele. Det sker blandt andet, hvis abstraktionen ikke har en klar semantik.

Jacob Christian Munch-Andersen

Jeg har måske nok en tendens til at se mere på fejlene end på fordelene.

Den risiko er større, hvis du koder direkte i lavniveau databasekode.

Det er jo hønen og ægget, så længe folk ikke skriver lavniveu databasekode bliver de ikke gode til det, og så længe de ikke er gode til det klarer SQL jobbet bedre. Men altså, det er ikke fordi jeg mener at man bør bruge decideret lavniveau programmering til database forespørgsler, hashtabeller søgetræer osv. bør selvfølgelig være implementeret så de let kan tages i anvendelse. Har man først lært at bruge de værktøjer rigtigt så får man en helt anden forståelse af databaser som kan komme til nytte, ikke blot i designet af selve forespørgslen, men også i opbygningen af datastrukturen og den resterende kode.

Tærsklen til SQL er lavere, det er derfor det er så populært. At en endnu større grund til at jeg ønsker SQL hen hvor peberen gror er sikkerhedsmodellen (eller mangel på samme), med data og kode i en og samme streng, er en anden sag.

Martin Bøgelund

Se fx på SQL, en ren abstraktion, programmøren har ringe muligheder for at optimere en forespørgsel, hvis ikke databasesoftwaren selv kan klare det så er det bare ærgerligt.

SQL er både et godt og et skidt eksempel.

SQL vart tænkt som matematiske, mængdeteoretiske operationer på informationer - det var det der var abstraktionen, og den er faktisk rigtig godt dækket i SQL.

Men "abstraktion" betyder at skære det uvæsentlige fra, og matematiske mængdeoperationer taler ikke om performance, så abstraktionen kræver nærmest at man ikke tænker over performance, da alt i matematik sker med tankens hastighed.

Men når nu man har skruet en tilpas skummel query sammen, som tager enten 10 billiarder år eller 24 minutter, alt efter hvilken rækkefølgen implementeringen gør det i, så ved man at performance ikke er uvæsentligt, og derfor ikke skæres bort af abstraktionen.

Tilbage står vi så med vores query, og ved ikke om SQL er en god abstraktion pga. den gode dækning af mængdeoperationer, eller om den er dårlig, fordi vi ikke kan vente på en dårlig implementering.

Og derfor er jeg skeptisk ved disse abstraktionshøjder, der mener at kunne frigøre sig fra konkret kode: Den kyndige programmør vil hurtigt skrive en simpel stump kildekode i hovedet, der kan klare den konkrete opgave optimalt, men vil skulle piske og bøje den konkrete abstraktion, fordi den skriver håbløs kildekode i det konkrete tilfælde.

Jacob Christian Munch-Andersen

God beskrivelse Martin, jeg tror at du rammer hovedet på sømmet lige en tand bedre end jeg formåede.

Personligt forsøger jeg altid at organisere data så jeg kan holde mig til helt simple forespørgsler. Men jeg ser at mange andre går i præcis den modsatte retning og forsøger at skrive så meget som overhovedet muligt af programmet i SQL sætninger.

Jeppe Cramon

Du har muligvis ret i at "den kyndige programmør vil hurtigt skrive en simpel stump kildekode i hovedet, der kan klare den konkrete opgave optimalt, men vil skulle piske og bøje den konkrete abstraktion, fordi den skriver håbløs kildekode i det konkrete tilfælde."

Det afhænger i casen og hvor kompleks en sammenhæng problemet indgår i og hvor velvalgt/fleksibel abstraktionen er.
Jo mere vi bevæger os fremad i tid, desto mere komplekse problemer får vi løst og med større succces. Tilbage i de gode gamle dage, i f.eks. pensions branchen, var det ikke unormalt at opleve perioder på dage eller uger, hvor systemerne var nede pga. fejl. I dag er det kritisk hvis applikationerne er nede i 1 time. Så der er sket meget og de problemer der bliver løst i dag er meget mere komplekse end de var dengang.

Hvorfor det? Fordi vi er flere udviklere eller fordi vi har bedre værktøjer (så som bedre IDE'er der kan hjælpe med at gennemskue koden, code completion, garbage collectede sprog, shared heap med distribueret garbage collection, SQL, ORM frameworks som f.eks. Hibernate, abtraktioner over concurrent problem stillinger så som actor modellen eller Master/Worker framework der tillader at køre multitrådet på en maskine eller distribuere loadet over flere maskiner uden kode ændringer) der hjælper os med at hæve abstraktions niveauet, så vi kan koncentrere os om de væsentlige problemer (f.eks. forretningens) i stedet for at lege med registre, memory pointers.

Kører det maksimalt hurtigt hele tiden? NEJ, men du når helt sikkert hurtigere frem til målet fordi du er på et højere abstraktions niveau. Og er der områder der ikke performer, så er det der du skal bruge dine kyndige udviklere til at tune koden i low-level sprog, library, etc. of choice der matcher med den overordnede arkitektur og abstraktion. Og ja, man kan altid finde dårlige eksempler på høj niveau abstraktioner der ikke tillader tweaking i en tilpas grad. Men de har jo også en tendens til at uddø med tiden (så f.eks. den seneste tids NO-SQL tendens).

Det højere abstraktions niveau (så fremt det er vel designet og matcher med problem området) gør oftest også koden lettere læse og det er heller ikke en uvæsentlig fordel specielt med henblik på vedligeholdelse, som står for største delen af omkostningen ved en applikation.
Har du prøvet at lave distribueret koordination i hånden? Det er ikke specielt sjovt. Med f.eks. Terracotta, der er en distribueret Java heap (der overholder hele Javas memory model), er det væsentligt nemmere. Og fordi den befinder sig på et højere abstraktions niveau, har den desuden de samme muligheder som f.eks. HotSpot compileren i Java til at tune sig selv undervejs, som den lærer af applikationens mønstre.

Hvis du tager et framework som Hibernate der tillader dig at arbejde med en Objekt repræsentation af dine data oven på en relationel database. Kører den hurtigst muligt? Nej.
Men hvis den matcher med din applikations behov, så løser den rigtig mange problemer og dens SQL er ofte bedre end hvad de fleste udviklere er i stand til at skrive. Fordi den igen hæver abstraktions niveauet er der igen mulighed for at den kan lære af applikationens brugsmønstre og med tiden tune dine fetch planer (gennem f.eks AutoFetch projektet). Kører det maksimalt hurtigt? Nej
Kunne en kyndig udvikler skrive det hurtigere i hånden? Ja, men det ville tage ham rigtig lang tid hvis han skulle skrive alt SQL'en for hele applikationen.
Men hvorfor gøre det - Hvis det kører hurtigt nok i 90% af tilfældende og du nemt kan tweake (her kræver det at din højniveau abstraktion tillader dig at tweake og eller bryde ud når der er behov) er der ingen grund til det. I alle de applikationer hvor vi har brugt Hibernate, har der kun været 5-10 queries eller updates som vi har valgt at lave i hånden af performance hensyn. Det er lige med en masse sparet tid.

Så ja jeg er glad for abstraktioner, hvis de er fleksible og matcher med mit behov. For mig handler det om ikke at være religiøs og i stedet vælge hvad der matcher med erfaringer og skills på holdet og problem komplekset. Model drevent udvikling har f.eks. potentiale til at løse rigtig mange problemer. Når det kommer til visuelle modeller, vil jeg udelukkende bruge det til domæner modeller, service grænseflader og processer. Til andre områder findes der pt. bedre og nemmere løsninger. At vi kan bruge model drevet software med succes til disse områder i dag, skyldes dedikerede folk, som dem på DTU, der dagligt prøver at bryde grænserne og udvide/modne model drevet udvikling. More power to them :)

Torben Mogensen Blogger

SQL vart tænkt som matematiske, mængdeteoretiske operationer på informationer - det var det der var abstraktionen, og den er faktisk rigtig godt dækket i SQL.

Men "abstraktion" betyder at skære det uvæsentlige fra, og matematiske mængdeoperationer taler ikke om performance, så abstraktionen kræver nærmest at man ikke tænker over performance, da alt i matematik sker med tankens hastighed.

Ideen med kodning på et højt abstraktionsniveau er at lade implementeringen (oversætteren osv.) tage sig af optimeringen. Selv om SQL er matematisk funderet, så er der bestemt tænkt på optimeringer: Man udnytter netop de matematiske egenskaber til at optimere forespørgslerne, og længere nede laver databasesystemet optimeringer, der er tilpasset den aktuelle konfiguration.

At en endnu større grund til at jeg ønsker SQL hen hvor peberen gror er sikkerhedsmodellen (eller mangel på samme), med data og kode i en og samme streng, er en anden sag.

Det er ikke en egenskab ved SQL, men en egenskab ved ugennemtænkte implementeringer af SQL i diverse programmeringssprog.

Torben Hoffmann

Jeg har set en del fejlslagne modelleringsprojekter baseret på en generel modelleringsmetodik, som oftest UML eller noget tilsvarende.

Problemet i praksis er vedligeholdelse og manglende fleksibilitet. Det er som regel nemt at lave den første udgave, der som oftest kræver lidt håndkodning for at få det hele til at virke. Derefter laver man en intern rapport og fremviser fantastiske produktivitetstal, bliver forfremmet og går videre til et andet projekt.

Her kommer så problemerne: værktøjet var jo tænkt som en silver bullet og de famøse linjer manuel kode man har lavet er nu med til at gøre vedligeholdelsen vanskeligere end den allerede er når man skal til at opdatere en model. Her falder produktiviten så og dem der sidder på projektet sidder med et rådent æble og ingen forfremmelse.

Jeg har personligt taget en anden rute: først lavede vi et projekt med Erlang og da projektet var telekommunikationsrelateret kunne vi ikke undgå at få en høj produktivitet (~7x over C++/Java) pga effekten af at benytte et domæne specifikt sprog. Sidebemærkning: da vi ikke har lavet noget med fancy modeller er vi selvfølgelig ikke blevet forfremmede ;-)

Undervejs oplevede vi nem vedligeholdelse og alle de andre gode ting som et godt framework der passer til opgaven nu en gang giver.

Eneste mangel: vores fine arkitektur tegninger og Message Sequence Charts var vi nødt til at oversætte til kode manuelt. Ikke svært, men det kunne jo have været rart med et højere abstraktionsniveau.

Derfor er vi i gang med at undersøge et domæne specifikt modelleringsværktøj der hedder MetaEdit+.
Det ser ud til at vi kan få lavet et sprog der passer til vores domæne og dermed løfte vores abstraktion der hvor vi manglede det.
MetaEdit+ er så smart at det tillader håndkode samt har mekanismer til at integrere det med videreudvikling af modellen. Efter min sommerferie færdiggør vi vores undersøgelser og ser om vi kan hæve vores produktivitet yderligere... og da værktøjet laver fine diagrammer burde det være den sikre vej til en forfremmelse!!! ;-)

Men baseret på mine hidtidige erfaringer vil jeg påstå at domæne specifik modellering er det eneste der har en chance for at komme til at hjælpe og det kræver at man har fleksibilitet til at integrere med både håndkode og gamle moduler.

Vh,
Torben

Ekkart Kindler

Kære alle

Nu er det på tide at jeg svarer personligt på de mange indslag.
Desværre taler jeg ikke så godt dansk endnu, fordi jeg har
boet i Danmark kun i 2 år. Men jeg prøver alligevel ...

Jeg må tilstå, at jeg er lidt overrasket af de mange indslag,
men jeg glæder over diskussionen. Jeg prøver at svare generelt
på nogle emner og spørgsmål nu. Og jeg håber at jeg finde tid
til at svare mere individuelt senere.

En af mine professorer på TU München har sagt: "Det eneste
redskab vi har for at tackle kompleksitet er abstraktion".
Det gælder naturligvis alle ingeninørdiscipliner. Det betyder
naturligvis ikke at man skal lave alt på højeste niveau, men
på det rigtige niveau. Min pointe er, at, når vi laver
software i dag, tvinger mange metoder os til at abejde på et for
lavt niveau -- til sidst laver vi alt på programmniveauet.

Faktisk er ideen med at arbejde på et højt abstraktionsniveau
ikke ny. Da software blev mere og mere kompleks, startede
softwareudvikler at lave skizzer for at kommunikere om
softwarens design på et højere niveau. Min fornemelse er, at
notationer som "Booch" eller "OMG" og i dag UML er et
destillat af de notationer som blev brugt som skizzer
i løbet af softwareudviklingsprocessen (måske gælder det
ikke UML i dag, fordi det bliver større og større; men det
er en anden historie og skal ikke diskuteres her). Disse
notationer er et redskab til at designe software og til at
kommunikere, diskutere, og dokumentere designen.

Baseret på disse skitser eller dokumenter (lad mig kalde
dem modeller) starter softwareudviklere eller programmører
senere med at skrive programmer manuelt (jeg skulle heller
sige med brug af hoved). Men næsten alle som har gjort
sådan, ved at den størrste del af dette arbejde bliver
meget kedelig når man gør det for den anden, tredje,
fjerde, ... gang. Det meste er ren rutinearbejde.
Denne del kan man automatisere, og man skulle automatisere
den, fordi mennesker er ikke så gode til kedelige arbejder
(som man godt ved fra fabriker med samlebånd). Og nogle
store softwareudviklingsvirksomheder gør det allerede
i dag.

Naturligvis er der nogle få ting, som kræver lidt hjerne
og som man må tilføje et eller andet sted i programmkoden.
Dette argument kan man bruge (eller misbruge)
og sige: ha, så er der nogle ting som ikke lad sig gøre
med modeller, så giv mig programmerne tilbage og glem
modellerne. Men dette ræsonnement holder ikke! Spørgsmål
er, om man ikke kan have begge dele (jeg elsker dialektik):
delen som kommer fra modellerne og delen som skal tilføjes
på "implementeringsniveau". Og mit svar er:

For det første "jeg man kan",
for det andet "men der er stadigvæk nogle problemer".

Allerede i dag er der nogle store softwareudviklings-
virksomheder som laver software på denne måde og har deres
helt egne metoder dertil. Og Eclipse EMF, som nævnt i
artiklen, har også en metode for det.

Nogle af de generelle problemer er, hvordan man integrerer
modeller (eller kode som blev genereret fra modeller) med
eksisterende programmer. Et andet problem er notationer som
man kan bruge til at modellere adfærd eller hellere (faktisk
er der alt for mange notationer til at modellere adfærd)
notationer til at integrere modeller for adfærd med
strukturelle modeller, med eksisterende kode.

Problemet idag er: Vi laver modeller (eller skitser), men
vi smider dem ud igen, når vi starte med at programmere.
Til sidst skal man finde ud af designet ud fra kildekoden på
det laveste niveau ...

Og "kildekoden" er stikordet til noget andet: Jeg er enig
med Torben Mogensen i at modeller er kildekoden -- eller at
de skulle blive det. "Kildekoden" betegner (jeg gengiver
en del af definitionen af ordet "Quellprogramm" fra den
tyske "Duden Informatik") originalen, som bliver brugt
for at oversætte det til maskinkode; alle rettelser,
ændringer og udvidelser sker i kildekoden. Jeg tror at
denne betegnelse kommer fra den tid da man gik væk fra
assembler og maskinkode og brugte højniveausprog.
Maskinkoden var ikke mere kilden (selvom man var
nødt til at ændre maskinkoden en gang i mellem). Og
måske viser denne analogi hvor vi står i dag. Hvis
modeller er orginalen og alle (eller lad mig sig nogle
eller mange) ændinger sker i modellen og de har en effekt
i softwaren, så er de kilden. Hvis det er ikke sådan, så
er de bare nogle "skitser".

Hvis man vil definere model-based software engineering meget
kort, så kan man sige: model-based software engineering er
at anse modellerne som kilden. Enig!

Men der er en ting som jeg ikke så godt kan lide om ordet
"kildekoden" og det er ordet "koden". På tysk kan "koden"
også betyde at blive svær at forstå (og mange forstår
"kode" på denne måde). Men det er ikke så vigtigt.

Nu vil jeg gerne svare på kritiken fra Mark Lorenzen
(15. juli 2009 13:44) vedrørende vores uddannelse.
Han skriver:

"Nu skal softwareingeniører hverken kunne programmering,
design eller udvikling, men derimod modellering."

For det første: Modeller erstatte ikke design. Tværtimod
er modeller resp. deres notationer et redskab til at lave
et design, for at dokumentere det og for at kommunikere
med andre om det. Hvilke notation er den beste til det
skal ikke diskuteres her. Men en god softwaredesigner skal
beherske sine redskaber og modelleringsnotationer er
et af dem.

For det andet: Som sagt før, der vil blive dele (for
en lang lang tid -- længere end vi tror) som vi er nødt
til at programmere. Derfor er programmering en vigtig
del af uddannelsen! Personligt synes jeg, at en
forudsætning for at bleve god til at modellere er at man
er god til at programmere. Og hvis man er en god "modellør"
bliver man en bedre programmør. Hvis man abstraherer
fra noget, så skal man vide fra hvad man abstraherer. Det
alene er grund nok til at undervise i programmering -- og
at undervise det grundigt.

Til sidst vil jeg gerne fortælle en anekdote: En gang
imellem spørger mig en af mine venner, hvad jeg forsker i.
Så siger jeg, at jeg forsker i hvordan man kan lave
software uden at programmere. Så siger de, det er fint,
så kan jeg også lave software. Så siger jeg: nej, det
kan du ikke. Den del som bliver tilbage er den sværeste,
og det kræver hjerne, en god uddannelse, og evnen at
abstrahere og tænke i begreber ...

Jeg håber at jeg vil nå at svare direkt på nogle inslag
en anden gang.

Mange hilsner
Ekkart Kindler

Anonym (ikke efterprøvet)

Nu vil jeg gerne svare på kritiken fra Mark Lorenzen
(15. juli 2009 13:44) vedrørende vores uddannelse.
Han skriver:

"Nu skal softwareingeniører hverken kunne programmering,
design eller udvikling, men derimod modellering."

Det var nu ikke mig, der skrev det, men derimod Søren Løvborg. Jeg svarede derimod på hans indlæg.

Anonym (ikke efterprøvet)

Baseret på disse skitser eller dokumenter (lad mig kalde dem modeller) starter softwareudviklere eller programmører senere med at skrive programmer manuelt (jeg skulle heller sige med brug af hoved). Men næsten alle som har gjort sådan, ved at den størrste del af dette arbejde bliver meget kedelig når man gør det for den anden, tredje, fjerde, ... gang. Det meste er ren rutinearbejde. Denne del kan man automatisere, og man skulle automatisere den, fordi mennesker er ikke så gode til kedelige arbejder (som man godt ved fra fabriker med samlebånd).

Jeg kan ikke se den store fordel i automatisk kodegenerering.

Vi kan vel blive enig om at en model har en værdi, idet den er en abstrakt beskrivelse af enten et domæne eller en løsning (givet en domænemodel). Hvordan skal en datamat kunne konkretisere en abstrakt beskrivelse til noget så konkret som programkode? Lad os antage, at jeg har lavet mig en model at et system og at jeg specificerer funktionaliteten algebraisk. I dette tilfælde ville det være svært (generelt umuligt) at generere programkode. Hvis vi nu slækker på kravene til abstraktionen og laver modellen mere konkret, er det måske muligt at generere programkode, men så er modellen vil jo ikke være mere abstrakt end programkoden og så er ideen med modellering gået fløjten.

Ekkart Kindler

...
"Nu skal softwareingeniører hverken kunne programmering,
design eller udvikling, men derimod modellering."

Det var nu ikke mig, der skrev det, men derimod Søren Løvborg. Jeg svarede derimod på hans indlæg.

Jeg beklager meget. Det var en dum sjuskefejl, da
jeg kopierede det til mit svar.

Undskyld Mark Lorenzen!

Ekkart

Jeppe Cramon

"Jeg ser ikke fordelen i automatisk kodegenerering fra f.eks. UML, da det ikke giver mig en abstraktionsfordel."

Mark, hvis du læser mit første svar kan du læse om et par eksempler på abstraktionsfordele ved kodegenerering fra UML. Der er mange flere, men disse er simple men effektive (historik, temporal object pattern).

/Jeppe

Jeppe Cramon

Mark, en anden pointe der også er værd at tage ind i ligningen er automatisering npr du arbejder model drevet (f.eks. i UML).

Hvis du kan et definere et sæt af mønstre du placere din models transformation ind i, kan du spare mange mande timer gennem en automatiseret genererings process. Et eksempel kan være ORM mapping hvor du starter ud med en trivielmapping (af f.eks. klasse hierarkier), for senere at beslutte dig på baggrund af erfaringer, performance and lave mappingen om. Det kan nemt ske ved en lille ændring til generatoren.

Vi havde på et par af projekter nogle gennemgribende ændringer (den ene var til ORM mapping og den anden var pga. ændrede Service principper for WS grænsefladen). Vores projekt var færdige på under 1 dag for WS ændringen, hvor af de andre projekter var mellem 1 og 2 uger om at gennemføre samme ændringer i hånden.

Per Hygum Due

Et generelt programmeringssprog giver mulighed for at hæve abstraktionsniveauet en tand.

Mange softwareløsninger idag er et kludetæppe hvor source-koden der ligger til grund for komponenterne er skrevet i forskellige programmeringssprog og versioner af programmeringsprog. Softwareudviklere der arbejder med forskellige programmeringssprog vil sikkert kunne genkende situationerne:

Hvordan er det nu lige:

  1. Skal identifieren stå før eller efter typeidentifieren ?
  2. Skal et statement afsluttes med ; . eller whitespace ?
  3. Er det krøllet eller skarp parentes der afgrænser en kodeblok ?
  4. Er det ved typeidentifieren eller identifieren parenteser der indikerer array skal stå ?

Det giver noget spildtid og nogle trivielle build fejl.

I et GPL miljø vil softwareudvikleren vænne sig til syntaksen og der frigøres tid til opgaven der skal løses.

GPL sproget skal indeholde alle funktionaliteter der er indeholdt i programmeringssprogene som GPL miljøet skal kunne generere source kode til. Foreningsmængden af features i supporterede sprog.

GPL kan supportere både forward og reverseengineering.

Har man f.eks. et projekt der består af 3 klasser skrevet i Visual Basic, C++ og C# vil klasserne syntaksmæssigt se ens ud i GPL sproget.

Da GPL sproget forener flere sprog er det en standardisering som ikke begrænser hvad der kan specificeres. I C++ kan der f.eks. arves fra flere klasser, derfor vil det være muligt at specificere multipel arv i GPL.

Ekkart Kindler

Mark Lorenzen skrev:

Jeg kan ikke se den store fordel i automatisk kodegenerering.

Her er nogle eksempler på, hvad man kan generere kode
til. Jeg synes, at de viser, at kodegenerering er
meget hjælpsom og sparer meget tid og resulterer i mere
pålideligt software.

Disse eksempler starter ikke fra "algebraiske modeller"
men fra UML (mere præcist fra ecore modeller). Når
man udvikler software skal man ikke være dogmatisk,
men eklektisk (for at abstrahere skal man bruge de
redskaber som hjælper mest). Mine eksempler kommer fra
Eclipse EMF, fordi man kan selv prøve det og tjekke
det ("check it out") -- det er helt gratis. Kommercielle
værktøjer har endnu flere muligheder (og nogle store
virksomheder har deres egne metoder og værktøjer, som de
helst ikke taler om):

  1. Man kan generere en API med alle metoder til at ændre model-
    instanser. Det lyder nemt, men hvis modellen har mange
    "crossreferences", er jeg glad for ikke at skulle
    programmere det selv -- især når modellerne er meget store.
    Og den genererede kode sikrer også konsistensen. Jeg er
    sikker på, at den genererede kode er mere pålidelig end
    kode man skriver selv.

  2. Man kan generere kode til at bevare sine modelinstanser
    (data i filer og databaser). Der er mange forskellige måder
    at gøre det. En er, at man genererer kode for at gemme og
    loade sine modelinstanser uden at skrive en eneste linje
    kode selv. Man behøver heller ikke definere XML-formatet
    selv; man kan bare bruge XMI. Men hvis man vil, kan man
    også definere sit egen XML, fx. som XML Schema (man
    kan også generere modellerne fra XML Schema; men jeg
    indrømmer, at det kræver lidt erfaring).

  3. Hvis der er mange applikationer som arbejder på de
    samme data (som man har modelleret), så kan man
    generere notifikationsmekanismer: Hvis nogen ændrer
    data et eller andet sted, kan koden reagere på
    det (det bruger man ofte i editorer og generelt når
    man bruger design pattern MVC).

  4. Man kan generere simple editorer og -- vigtigere end det
    -- man kan generere alle funktioner som man bruger til
    at implementere en editor.

  5. Man kan også generere en grafisk editor (det hedder GMF).
    Men, fordi der var nogle indslag om "legetøjapplikationer",
    tilføjer jeg, at GMF duer måske ikke til større
    applikationer (endnu). Men GMF viser at det er muligt.

6.- ...

Der er meget mere, som fungerer lige nu (som nævnt
af Jeppe Cramon allerede, fx. tests) og i
eksisterende værktøjer.

Principielt kan man gøre endnu mere; men det kræver
nogle nye begreberog notationer (fx. for at modellere
adfærd). Det forsker vi i!

Et af mine krav er, at man kan integrere det hele med
etablerede notationer som fx. UML / ecore og standards som
MOF eller lignende og med kode som eksisterer allerede.
At opfinde noget helt nyt, er ikke løsningen. Det er
grunden til at vi bygger på Eclipse og EMF (som også er
basen for et kommercielt værktøj som RSA og vi har også
en grænseflade fra EMF til et andet kommercielt værktøj EA).

Anonym (ikke efterprøvet)

Mark, hvis du læser mit første svar kan du læse om et par eksempler på abstraktionsfordele ved kodegenerering fra UML. Der er mange flere, men disse er simple men effektive (historik, temporal object pattern).

Jeg har prøvet at se præsentationen igennem, selvom det kan være lidt svært at følge nogle slides uden ledsagende tekst, så bær over med mig, hvis jeg har misforstået noget.

Som jeg ser det, laver I en domænemodel som et UML klassediagram og - gennem en serie transformationer - får I til sidst genereret (en del af) et Java program. En del af datamodellen er defineret vha. stereotyper, hvis semantik for mig er udefineret.

Det er jo helt korrekt at I får genereret en hel del kode automatisk, men jeg kan stadigvæk ikke se nogen abstraktionsfordel. I har ikke mulighed for at definere invarianter på jeres domænemodel eller definere operationer på modellen. Det I har er en datamodel udelukkende med nogle relationer, der sparer (helt sikkert en del) kodetid.

En abstrakt model af et stykke software skal hjælpe os som softwareingeniører med at argumentere for den færdige softwares fuldstændighed og korrekthed gennem formelle eller uformeller beviser. Kodegenerering skal så sikre at der ikke begås fejl i kodningen.

Det er altså rigtigt at der kan spares kodearbejde ved at generere kode fra en ikke-abstrakt model, men jeg ser ikke den store fordel i det.

Anonym (ikke efterprøvet)

Jeg ville gerne vise et eksempel på en formel (og abstrakt) domænemodel med en formel specifikation af funktionaliteten som det laves i industrien, men da det ikke må frigives kan jeg i stedet anbefale at man tager et kig på Tokeneer projektet.

http://www.adacore.com/multimedia/tokeneer

Der er et demonstrationsprojekt udført på initiativ af National Security Agency. Flere firmaer har leveret deres bud på løsningen og NSA har valgt at afklassificere det ene som et eksempel til efterfølgelse af andre firmaer.

Der er desværre er tale om en 23,2 MB fil, men prøv at downloade http://www.adacore.com/multimedia/tokeneer/tis_release2.zip og check filen 41_2.pdf Her er simpelthen tale om en formel specifikation (domænemodel og operationer) af systemet (50_1.pdf er et formelt design, der måske også kan have interesse). Da modellen er formelt specificeret er det muligt at argumentere for nogle egenskaber (f.eks. sikkerhedsegenskaber) som det er gjort i 40_4.pdf

Kodningen er ikke automatisk og kan derfor være et svagt led i kæden. For at nedsætte denne risiko har man valgt at benytte et stærkt programmeringssprog, hvor man kan bevise visse egenskaber. Kunne denne kodegenerering være automatisk, ville det være en stor fordel idet at modellen jo netop er formel og abstrakt.

Alle de demonstrationer af værktøjer jeg har set, der kunne generere kode fra UML har krævet at programmet næsten blev skrevet i UML eller at kodegeneratoren kun genererede et programskelet. Abstraktionsfordelen har ikke været til stede.

Jeppe Cramon

Hej Mark

I videoen bruges bla. stereotypen <<History>> der angiver, at der er aktiv historik på associationen mellem to entiteter (kan ikke lige huske hvilke).
Dette er en abstraktion ovenpå et semi komplekst område (bitemporal logik) som kan implementeres på mange forskellige måde alt efter hvilken infrastruktur man har som mål. Et simpelt er eksempel på dette kan være dette:
Lad os antage at vi har en association mellem Person og PersonNavn (1-1 association) der har aktiv historik.
Dette kan enten løses som en 1-m association mellem de to entiteter med angivelse teknisk og forretningsmæssige tidsstempler. I Hibernate (f.eks.) kunne lade generere en 1-m association mellem de to entiteter og i hver enkelt klasse generere metoder der tillader mig at arbejde med entiteterne som var de 1-1 ud fra et given view tidspunkt.
Det kunne også løses som 1-1 association med tilhørende skyggetabeller.
På trods af implementationsforskellene, ville det være muligt for mig langt hen ad vejen at give udviklerne det samme interface at arbejde med. En klar bbstraktions fordel. Både i API men også i fleksibilitet mht. implementations detaljer som ikke behøver at skinne igennem.

Havde en af entiteterne (feks. PersonName) været versioneret (temporal object pattern) - ville jeg kunne have modelleret det simpelt i modellen og i transformations fasen kunne jeg have genereret både Person og PersonVersion entiteterne, samt genereret det nødvendige API der gør det nemt at arbejde med versionerede objekter.

En eksempel hvor jeg ikke har en decideret abstraktions fordel, men har en stor grad af automatisering og hjælp, kunne være hvis Person og PersonName associationen var bidirektionel. Med vores interne Model generator genererer vi efter ønske bidirektionelle wrappers ind, der usynligt for udvikleren (indkasplet), sikrer at assoicationerne bliver håndteret bidirektionelt i Java/.NET upåagtet at Java/.NET er unidirektionel memory wise. En masse kode som korrekt kan håndteres uden generering, men som hvis man er stuck on Java kan være en kærkommen hjælp.

Mht. formelle og uformelle beviser, så har vi indtil videre taget en mere pragmatisk tilgang til det, ved at generere dækkende integrations tests baseret på modellerne. F.eks. for en Hibernate ORM model, generer vi test der kan gennemføre fuld kombinatorisk graf konstruktion for samtlige entiteter, hvor efter der bliver persisteret, hentet frem igen og lavet en graf sammenligning. Automatiseret integrations test :)

Mht. operationer så er det bestemt muligt at gøre. Du kan definere abstrakte metoder, interface metoder eller konkrete metoder (såfremt du virkelig ønsker at kode i dit UML værktøj).

For mig er det en kæmpe og uvurderlig hjælp. Som eksempel kan jeg nævne et projekt hvor vi erstattede 5 mand til at modellere og kode/mappe i Hibernate med 1 mand og 1 til generatoren.

Morten Bøgh

Lige en vinkel mere (...og der skal nok lige spoles tilbage til starten af diskussionen):

'CASE' begrebet i 1980'erne var en sjov tanke og havde ikke større betydning i praksis. Men for IBM havde begrebet meget stor betydning - desværre negativ. IBM lancerede 'IBM Repository' som søgte at botanisere på påstanden om at fremtidens edb genereres ud fra modeller og ikke ved at skrive synlig kildekode. Dvs. fremtiden tilhørte det firma der kunne systematisere sådanne modeller bedst. Hvordan modellen blev transformeret til kørende software, var et sekundært problem som kunne løses hen ad vejen. IBM kastede et antal milliarder dollars og en masse høj musik efter projektet indtil det blev totalt opgivet i slutningen af 1980'erne. Historien var et markant prestigetab for IBM; den viste et IBM som på dette tidspunkt havde meget svært ved at finde en retning mod fremtiden.

Så pas på derude, man kan komme alvorligt til skade hvis man mener at denne akademiske diskussion har noget med virkeligheden at gøre.

IBM Repository var besat af en gal modelbygger. Den modsatte vinkel, husmands-vinklen: hvordan transformer man en specifikation til en stykke kildekode, er mere lavpraktisk interessant - fordi software-udvikling er dyrt og langsomt, og enhver mulighed for automatisering er et gode. I det omfang en række programmer er variationer over et tema, er det oplagt at skrive temaet (skelettet), og programmere variationerne i en meta-programmering, dvs. via et program som skaber kildekode - ud fra noget input som på en eller anden rationel form beskriver det enkelte programs særheder. Det er noget de fleste software-firmaer beskæftiger sig med, på mere eller mindre systematiseret vis. Indvendingen mod sådanne tiltag kan være, at en gennemtænkt nedbrydning i objekter og nedarvning vil kunne skabe samme funktionalitet bestående af et tema med variationer. Min erfaring er at meta-programmering ofte er den nemmeste og mest produktive vej til målet. Min erfaring er også, at investeringer i området betaler sig, værktøjsudvikling betaler sig. Området er sågar teoretisk interessant: pipeline-baserede sprog er formentlig de optimale til meta-programmering.

Kald inputtet til meta-programmeringen for en model, og vi er tilbage på DTU: der programmeres i modeller, og kildekoden er skjult. Forskellen er vinklen: fra det praktiske mod det teoretiske, i stedet for omvendt. Forskellen er også ambitionsniveauet: modellen beskriver ikke hele projektet, men et område hvor meta-programmering er nyttigt. Og forskellen er fleksibiliteten ved at man ikke bare arbejder med modellen, men også frit kan justere på meta-programmeringen hen ad vejen.

Jeppe Cramon

Hvis jeg forstår din konklusion rigtigt, er jeg enig i at det handler om pragmatisme. Brug modellering/meta-modellering (og også meta-programmering) hvor det giver mening og hvor det gør tingene nemmere.
At beskrive et helt system/applikation via modellering som MDA (Model Driven Architecture) foreslår, er jeg ikke tilhænger af.

Jeg synes der har været rigtig mange gode input og diskussioner.

For dem der er interesseret, så afholder jeg sammen med Dansk-IT (som facilitator for deres Java netværk) d. 8. September et gratis "på vej hjem møde" hvor emnet er "Model Drevet Design/Udvikling".

http://www.dansk-it.dk/arrangementer/1571.aspx

Det kunne være hyggeligt at fortsætte diskussion face to face, for dem der har lysten.

/Jeppe

Jan Rouvillain

Du må være en bitter mand, Martin Bøgelund:

Variabler, funktioner, klasser, etc. er i sig selv abstraktioner, og tilføjelse af flere abstraktionslag vil blot tilføje vertikal kompleksitet de steder hvor der fjernes horisontal kompleksitet.

Det er en over generalisering. Her er et par eksempler fra C#, hvor detaljerne er gemt væk i automatisk genereret og fortolket kode:

Foreach: Man kan gennemgå en samling (collection) i en foreach løkke. Alle klasser kan understøtte foreach ved at implementere interface't IEnumerable. Implementationen medfører ofte at man bruger yield.

Generics: Generics gør,at man kan se hvad en samling indeholder af typer, f.eks. Dictionary<int, string>.

Begge eksempler viser:

1) Hvordan man abstraherer væk fra detaljer. Man kan hurtigere programmere løsninger og samtidigt sikrer vedligeholdet af koden.

2) En horisontal abstraktion, som gør den vertikale kompleksitet mindre, fordi problemet er generelt.

Men du har ret i, at en software arkitektur ofte tilfører lag, som gør den horisontale kompleksitet mindre på bekostning af den vertikale kompleksitet. En software arkitekturs opgave er at abstrahere detaljer væk givet et formål, kvaliteter (usability, performance, modifiability etc.), udviklingsorganisationens kompetencer og valgt udviklingsplatform. En TCP/IP stak med driver til netværkskortet er et eksempel på en sådan arkitektur. De bort abstraherede detaljer kan være vigtige for et andet formål eller ændrede kvaliteter.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 10:55

Affecto has the solution and the tools you need

According to GDPR, you are required to be in control of all of your personally identifiable and sensitive data. There are only a few software tools on the market to support this requirement today.
13. sep 10:28

Xena - an innovative force in testing next-generation communications technology

22. aug 2017