mboost-dp1
Flickr - Sue Richards
Ikke for at lyde som en reklame, men man har i mange, mange år kunne lave software uden at rode med kildekode. Se f.eks. Multimedia Fusion på www.clickteam.com. Man kan også lave spil med det.
Skal tilføjes at jeg her kommenterer overskriften, og ikke det ham der Ekkart snakker om.
Skal tilføjes at jeg her kommenterer overskriften, og ikke det ham der Ekkart snakker om.
1#
Ja, men man kan ikke lave alt modelbaseret og jeg tror aldrig man slipper HELT for at skulle kode - heldigvis. Tror de mest udbredte programmeringssprog PT har fundet et meget godt abstraktionsniveau, men det er nu rart at have et veludviklet IDE til GUI-programmering...
Ja, men man kan ikke lave alt modelbaseret og jeg tror aldrig man slipper HELT for at skulle kode - heldigvis. Tror de mest udbredte programmeringssprog PT har fundet et meget godt abstraktionsniveau, men det er nu rart at have et veludviklet IDE til GUI-programmering...
briancaos (4) skrev:Hvem skal lave koden til hans Model Based Software? :-)
Pas. Tegn nogle uml diagrammer og wupti. Koden opstår på magisk vis!
Sorry men det er prøvet før. MAN SLIPPER IKKE SELV FOR AT KODE!
eviscerator (1) skrev:Ikke for at lyde som en reklame, men man har i mange, mange år kunne lave software uden at rode med kildekode. Se f.eks. Multimedia Fusion på www.clickteam.com. Man kan også lave spil med det.
Skal tilføjes at jeg her kommenterer overskriften, og ikke det ham der Ekkart snakker om.
Forkert. Har "Multimedia Fusion" måske skrevet sig selv eller va?
#4 Den påtager jeg mig:) Jeg er færdig om fire år så hvis jeg lige skynder mig kan det saaaagtens nås! Jeg tror der er penge i skidtet:)
OT: Lyder temmelig smart... Men hvis han mener at man skal kunne kode alting som man for eksempel koder GUI i en IDE så tror jeg ikke hardcore programmører hopper med på vognen... Lige umiddelbart ville jeg mene at det i sidste ende ville tage for meget styring væk fra programmøren... Friheden til at kunne kode hvad som helst ville forsvinde en smule...
OT: Lyder temmelig smart... Men hvis han mener at man skal kunne kode alting som man for eksempel koder GUI i en IDE så tror jeg ikke hardcore programmører hopper med på vognen... Lige umiddelbart ville jeg mene at det i sidste ende ville tage for meget styring væk fra programmøren... Friheden til at kunne kode hvad som helst ville forsvinde en smule...
Vi har jo allerede programmer såsom Dreamweaver, hvor man kan lave det hele wysiwyg, uden at kigge på ret meget kode (ganske vidst er det ikke noget at råbe hurra for, men det kan sagtens lade sig gøre).
Så det handler blot om at få udviklet konceptet noget mere.
Personligt ville jeg gerne kunne kode noget software/små programmer, da man tit og ofte står og mangler et program, der kan udføre noget specifikt. Det bliver en hel del nemmere, hvis man får noget wysiwyg/modul/lego-agtig software, hvor man bare sætter det hele sammen.
Så det handler blot om at få udviklet konceptet noget mere.
Personligt ville jeg gerne kunne kode noget software/små programmer, da man tit og ofte står og mangler et program, der kan udføre noget specifikt. Det bliver en hel del nemmere, hvis man får noget wysiwyg/modul/lego-agtig software, hvor man bare sætter det hele sammen.
Jamen det er bare endnu et lags abstraktion. Jeg tror ikke han forventer at al software skal skrives i et model-baseret "sprog", men derimod særligt trivielle ting.
Det der dog er galt med det abstraktionslag er at folk vil "glemme" hvordan man koder og blot stole på at abstraktionslaget genererer den optimale underliggende kode. Derved dræber man også mange af mulighederne for at nye idéer opstår indenfor softwareudvikling.
Til dagligdags ting kan jeg godt se formålet. Men generelt synes jeg det er en tåbelig idé.
Det der dog er galt med det abstraktionslag er at folk vil "glemme" hvordan man koder og blot stole på at abstraktionslaget genererer den optimale underliggende kode. Derved dræber man også mange af mulighederne for at nye idéer opstår indenfor softwareudvikling.
Til dagligdags ting kan jeg godt se formålet. Men generelt synes jeg det er en tåbelig idé.
Nu er artiklen ikke særlig dyb, så guderne må vide hvad manden egentlig sagde/mener.
Men til små dagligdags ting kan det vel virke ok hvis man forsker lidt. Sådanne værktøjer findes jo allerede.
Den genererede kode er bare sjældent særlig god til at kunne vedligeholdes.. heller ikke af den samme generator der lavede den... det er min erfaring.
Til den virkelige verden af komplicerede systemer, hvor der er komplicerede krav fra virkelige menesker og love som forandres fra dag til dag, ja så vil det ikke virke!..
Men en meget sjov Star Treck drøm er det da!
Men til små dagligdags ting kan det vel virke ok hvis man forsker lidt. Sådanne værktøjer findes jo allerede.
Den genererede kode er bare sjældent særlig god til at kunne vedligeholdes.. heller ikke af den samme generator der lavede den... det er min erfaring.
Til den virkelige verden af komplicerede systemer, hvor der er komplicerede krav fra virkelige menesker og love som forandres fra dag til dag, ja så vil det ikke virke!..
Men en meget sjov Star Treck drøm er det da!
Jo der er måske steder hvor det kan bruges og hvor man kan bruge et sådant værktøj.
Dog forbeholder jeg mig retten til at forholde mig kritisk til generator kode. De ting jeg arbejder med idag bliver ret svært at udvikle ud fra bestemte modeller.
Det kan være det kan bruges til store forretningssystemer - men bliver det bare en smule teknisk tror jeg det falder til jorden med et brag.
Jeg tror ikke helt på den.
Dog forbeholder jeg mig retten til at forholde mig kritisk til generator kode. De ting jeg arbejder med idag bliver ret svært at udvikle ud fra bestemte modeller.
Det kan være det kan bruges til store forretningssystemer - men bliver det bare en smule teknisk tror jeg det falder til jorden med et brag.
Jeg tror ikke helt på den.
#4
Når den en gang er færdig, brude den kunne bruges til at kompile sig selv! Hvis den ikke når til det trin, kan det jo ikke være en fuldgod erstatning for at skrive koden i hånden... Ind til dag vil man som regl vælge at mellem sprog til at boot strap processen.
Man skriver jo som regl heller ikke kompilere i binær kode...
Når den en gang er færdig, brude den kunne bruges til at kompile sig selv! Hvis den ikke når til det trin, kan det jo ikke være en fuldgod erstatning for at skrive koden i hånden... Ind til dag vil man som regl vælge at mellem sprog til at boot strap processen.
Man skriver jo som regl heller ikke kompilere i binær kode...
jAST (9) skrev:Det der dog er galt med det abstraktionslag er at folk vil "glemme" hvordan man koder og blot stole på at abstraktionslaget genererer den optimale underliggende kode. Derved dræber man også mange af mulighederne for at nye idéer opstår indenfor softwareudvikling.
Taget i betragtning hvor elendigt de fleste mennesker koder og hvor mange fejl man laver i triviel kode så vil jeg altid foretrække et abstraktionslag (også selv om det måske ikke generere optimal kode)
Jeg tror heller ikke på det vil blive en success, da det jo virker som om han vil lave en fuld god erstatning for at skrive koden i hånden, så skal det være lige så fleksibelt... Men skal det være lige så fleksibelt, så bliver det jo nok også lige så kompleks.
Der er nok en grund til, at vi udtrykker primært på skrift og i tale, istedet for primært i piktogrammer der viser en bestemt handling eller ting. Så vidt jeg har forstået, så har ikke en gang det kinesisk piktografiske skriftsprog, tegn for alle mulige handlinger eller ting, men er netop (lige som det latinske) en sammensætning af primitiver. Simple primitiver er simpelthen mere fleksible.
Jeg har selv arbejdet med model baseret data modellering, de sidste par år, hvor vi har designet en software model designer og så brugt den designer til at definere hvordan vi ville have vores data model til at se ud, for derefter at skrive templates der gjorde at designeren kunne generere koden for os.
Udviklingsmetoden er stadig i sit tidlige stadie og ikke ordentligt integreret ind i software udviklings miljøerne hvilket gør at der er mange problemer der skal løses manuelt før hele processen virker.
Det at arbejde med den slags modellering har også givet mig idéen om at software udvikling i fremtiden er nødt til at være mere model baseret, for når koden bliver for stor og kompleks bliver den samtidig enormt besværlig at forstå og overskue. Det gør fejlretning og videre udvikling mere kompliceret og når der kommer nye folk på projektet som ikke har samme indsigt så introduceres endnu flere fejl indtil de har gennemskuet hele koden.
Min tanke er at hvis man i stedet kan skrive genbrugbare komponenter i kode og så forbinde disse komponenter via et grafisk modellerings værktøj, så vil det være langt lettere at kunne overskue et flow igennem koden. Hvis sammensætningen af komponenterne i sig selv også kan bruges som komponenter så vil det være muligt at modellere mere kompliceret kode i en form som er lettere at gennemskue.
Microsoft DSL (Domain Specific Languages) og WWF (Windows Workflow Foundation) er to skridt på vejen mod denne slags udvikling, men de er stadig for fejlfyldt, for komplicerede at bruge og man kommer hurtigt til at bruge mere tid på at få værktøjerne til at gøre det man vil end at løse opgaven - og så er fordelene væk.
Udviklingsmetoden er stadig i sit tidlige stadie og ikke ordentligt integreret ind i software udviklings miljøerne hvilket gør at der er mange problemer der skal løses manuelt før hele processen virker.
Det at arbejde med den slags modellering har også givet mig idéen om at software udvikling i fremtiden er nødt til at være mere model baseret, for når koden bliver for stor og kompleks bliver den samtidig enormt besværlig at forstå og overskue. Det gør fejlretning og videre udvikling mere kompliceret og når der kommer nye folk på projektet som ikke har samme indsigt så introduceres endnu flere fejl indtil de har gennemskuet hele koden.
Min tanke er at hvis man i stedet kan skrive genbrugbare komponenter i kode og så forbinde disse komponenter via et grafisk modellerings værktøj, så vil det være langt lettere at kunne overskue et flow igennem koden. Hvis sammensætningen af komponenterne i sig selv også kan bruges som komponenter så vil det være muligt at modellere mere kompliceret kode i en form som er lettere at gennemskue.
Microsoft DSL (Domain Specific Languages) og WWF (Windows Workflow Foundation) er to skridt på vejen mod denne slags udvikling, men de er stadig for fejlfyldt, for komplicerede at bruge og man kommer hurtigt til at bruge mere tid på at få værktøjerne til at gøre det man vil end at løse opgaven - og så er fordelene væk.
Ha!
Visual Studio Team System WYSIWYG Edition.
Jeg tror ikke hans ide holder. Det lyder liiidt for utopisk. Læner dette sig iøvrigt ikke lidt op af AI? Jeg mener - der skal vel være en eller anden form for kraftig intelligens der kan forstå en eller anden form for input?
Iøvrigt så det er jo også fyldt med begrænsninger - hvis der ikke kodes er det jo ganske simpelt at det hele pludselig bliver begrænset i forhold til hvis det var en DIY-kode. Og hvad kode skrives? er vi i OOP eller er det bare statisk spaghetti-kode?
Jeg tror ikke jeg vil sætte mine håndøre i projektet... det er simpelthen for fjernt. Men tanken er sød!
Visual Studio Team System WYSIWYG Edition.
Jeg tror ikke hans ide holder. Det lyder liiidt for utopisk. Læner dette sig iøvrigt ikke lidt op af AI? Jeg mener - der skal vel være en eller anden form for kraftig intelligens der kan forstå en eller anden form for input?
Iøvrigt så det er jo også fyldt med begrænsninger - hvis der ikke kodes er det jo ganske simpelt at det hele pludselig bliver begrænset i forhold til hvis det var en DIY-kode. Og hvad kode skrives? er vi i OOP eller er det bare statisk spaghetti-kode?
Jeg tror ikke jeg vil sætte mine håndøre i projektet... det er simpelthen for fjernt. Men tanken er sød!
Jeg kunne nu godt se en fordel ved hans idé. Når mellemstore firmaer idag skal inplementere noget Navision/C5 eller lign. er der mange som får udviklet et modul til lige netop dét firma. Det kan godt være en bekostelig affære, og det er jo ikke altid at det kommer til at køre 100% som planlagt.
Det man så kunne gøre her er at den IT-ansvarlige kan få en drag-and-drop-programmerings-licens og så kan han løbende ændre i programmet. Muligheden er jo netop at folk som ved hvordan det skal se ud, ikke skal forklare en programmør hvad de mener. De kan selv lave det. Ligesom det er svært at forklare Picasso hvordan dine tanker ser ud.
Når vi så kigger på hans produkt, så kan jeg så godt se at de kommer til at arbejde med det i laaaang tid endnu ;)
Det man så kunne gøre her er at den IT-ansvarlige kan få en drag-and-drop-programmerings-licens og så kan han løbende ændre i programmet. Muligheden er jo netop at folk som ved hvordan det skal se ud, ikke skal forklare en programmør hvad de mener. De kan selv lave det. Ligesom det er svært at forklare Picasso hvordan dine tanker ser ud.
Når vi så kigger på hans produkt, så kan jeg så godt se at de kommer til at arbejde med det i laaaang tid endnu ;)
Hm... det er jo noget som en del har roddet med før (Microsoft med deres DSL Tools, som var mildest talt noget buggy lort, da jeg roddede med det for nogle år siden).
Men jo der kan være en fremtid i dette ny "paradigme" men jeg tror kun det vil have et begrænset anvendelses område.
lige nu lyder det for mig som de lover det samme OOP lovede i sin tid. og det holdt jo ikke, men vi fik da design patterns ud af det.
Og Jetbrains (dem bag IntelliJ blandt andet) har lavet deres MPS (hvor de bare kalder princippet Language Orientet Programming), hvor princippet bag er lidt det samme (at lave en nyt abstraktionslag som der kodes i).
Men jo der kan være en fremtid i dette ny "paradigme" men jeg tror kun det vil have et begrænset anvendelses område.
lige nu lyder det for mig som de lover det samme OOP lovede i sin tid. og det holdt jo ikke, men vi fik da design patterns ud af det.
Og Jetbrains (dem bag IntelliJ blandt andet) har lavet deres MPS (hvor de bare kalder princippet Language Orientet Programming), hvor princippet bag er lidt det samme (at lave en nyt abstraktionslag som der kodes i).
At software i fremtiden udarbejdes ved hjælp af komplekse diagrammer, påstod jeg i artiklen "Fremtidens programmør" i Moment. Det må have været ca. år 2004.
Det tror jeg stadig på er rigtigt. Selvfølgelig vil der stadig være programmører som skriver selve kildekoden. Men det svarer lidt til at meget få af nutidens programmører skriver i assembly, fordi andre har gjort fodarbejdet og givet flertallet af programmører et højere abstraktionsniveau.
At programmere med diagrammer er bare det næste abstraktionsniveau og vil gøre det endnu hurtigere og nemmere at programmere end med C#/Java.
Det tror jeg stadig på er rigtigt. Selvfølgelig vil der stadig være programmører som skriver selve kildekoden. Men det svarer lidt til at meget få af nutidens programmører skriver i assembly, fordi andre har gjort fodarbejdet og givet flertallet af programmører et højere abstraktionsniveau.
At programmere med diagrammer er bare det næste abstraktionsniveau og vil gøre det endnu hurtigere og nemmere at programmere end med C#/Java.
Jeg tror på ideen, men dog kun i et begrænset domæne. Jeg tror det vil være et skridt fremad for mange af de frygtlige spaghetti visual basic business applikationer derude, og jeg tror på at det måske kan bruges til customisering af applikationer.
Men at skrive en større applikation på den måde? Yeah right :-) Der vil altid være en masse nitty gritty detaljer, og at skulle forsøge at løse dem på højt abstraktionsniveau kan da kun blive en klods om benet.
Med andre ord tror jeg at det vil gøre simple ting meget simple, og svære ting meget besværlige.
Men at skrive en større applikation på den måde? Yeah right :-) Der vil altid være en masse nitty gritty detaljer, og at skulle forsøge at løse dem på højt abstraktionsniveau kan da kun blive en klods om benet.
Med andre ord tror jeg at det vil gøre simple ting meget simple, og svære ting meget besværlige.
ttolst (22) skrev:Men at skrive en større applikation på den måde? Yeah right :-) Der vil altid være en masse nitty gritty detaljer, og at skulle forsøge at løse dem på højt abstraktionsniveau kan da kun blive en klods om benet.
Der er ingen der siger at programmer kun skal være model baseret. Hvis du har behov for at løse nitty gritty detaljer som ikke er praktiske at løse med de elementer som modellen tilbyder, kan man skrive et nyt element som kan løse problemet og så putte det ind i modellen.
De fleste af jer lyder som om man aldrig er gået et abstraktionsniveau op før. Lær af historien, og indse at det er et spørgsmål om tid. Det eneste der er interessant at diskutere er hvornår og hvordan.
Selvfølgelig slipper man ikke 100% for at kode, ligesom vi endnu ikke er sluppet 100% for assembly-kode. Men det er godt nok tæt på, selv om man sagde engang at tanken var tåbelig.
Selvfølgelig slipper man ikke 100% for at kode, ligesom vi endnu ikke er sluppet 100% for assembly-kode. Men det er godt nok tæt på, selv om man sagde engang at tanken var tåbelig.
Jeg har for nogle år siden skrevet et lille system, hvoraf nok omkring halvdelen af koden var auto-genereret.
Det var et server/klient-system, hvor vi beskrev protokollen med XML. En generator lavede så kommunikationsdelen af både server og klient.
Klienten skulle have en GUI. Den tegnede vi, og fik genereret koden.
Så var der bare noget forretningslogik der skulle skrives, og det hele skulle bindes sammen. Vupti.
En ændring af protokollen var utrolig nem at implementere, selv om det krævede mange ændringer i koden.
Det var et server/klient-system, hvor vi beskrev protokollen med XML. En generator lavede så kommunikationsdelen af både server og klient.
Klienten skulle have en GUI. Den tegnede vi, og fik genereret koden.
Så var der bare noget forretningslogik der skulle skrives, og det hele skulle bindes sammen. Vupti.
En ændring af protokollen var utrolig nem at implementere, selv om det krævede mange ændringer i koden.
Der er selvfølgelig nogen der skal kode Værktøjet :o)
Værktøjet kaldes for CASE Tool (Computer Aided Software Engineering).
Det Ekkart har tænkt sig er at bruge EMF (en udviddet form af UML) som modelleringssprog, til at beskrive modellen af softwaren man vil lave. (i hvert fald indtil for et halvt år siden, han har nok udviddet konceptet til også at kunne genere software af modellen).
Værktøjet er skrevet i Java med et Open source værktøj der hedder Eclipse.
Eclipse har plug-ins der hedder Eclipse Modeling Frame Work (EMF), Graphical Editing Framework (GEF) og Graphical Modeling Framework (GMF).
Det største problem med udviklingen af softwaren er helt klart at den manglende dokumentation for EMF, GMF og GEF, og da det er open source, kommer der hele tiden nye versioner af både Eclipse, EMF, GEF pg GMF,
hvilket gør at der konstant er mærkelige kompatibilitetsproblemer, og gør det også svært at vide, hvilken version af dem der passer bedst sammen.
Hvis ikke Eclipse (og de andre frameworks) bliver bedre med kompatibilitet med hinanden, så kan jeg ikke se hvordan der vil opstå bugs i hans CASE Tool.
I øvrigt bliver man jo nødt til at validere at værktøjet er fejlfrit (eller kun har små fejl som egentlig ikke har noget at gøre med selve modelleringen eller afprøvning af software systemet og generering af softwaren).
Værktøjet kaldes for CASE Tool (Computer Aided Software Engineering).
Det Ekkart har tænkt sig er at bruge EMF (en udviddet form af UML) som modelleringssprog, til at beskrive modellen af softwaren man vil lave. (i hvert fald indtil for et halvt år siden, han har nok udviddet konceptet til også at kunne genere software af modellen).
Værktøjet er skrevet i Java med et Open source værktøj der hedder Eclipse.
Eclipse har plug-ins der hedder Eclipse Modeling Frame Work (EMF), Graphical Editing Framework (GEF) og Graphical Modeling Framework (GMF).
Det største problem med udviklingen af softwaren er helt klart at den manglende dokumentation for EMF, GMF og GEF, og da det er open source, kommer der hele tiden nye versioner af både Eclipse, EMF, GEF pg GMF,
hvilket gør at der konstant er mærkelige kompatibilitetsproblemer, og gør det også svært at vide, hvilken version af dem der passer bedst sammen.
Hvis ikke Eclipse (og de andre frameworks) bliver bedre med kompatibilitet med hinanden, så kan jeg ikke se hvordan der vil opstå bugs i hans CASE Tool.
I øvrigt bliver man jo nødt til at validere at værktøjet er fejlfrit (eller kun har små fejl som egentlig ikke har noget at gøre med selve modelleringen eller afprøvning af software systemet og generering af softwaren).
LOL - peeerrrfoooooomanceeee?! Hvor blev du af?!
Selvfølgelig, til de der lever efter devisen "hardware billigere end udviklere" kan det vel virke lige så godt som at tisse i bukserne, men...
Hvis folk bare vidste hvor stor forskel der er på software, og ikke optimeret software. :-) Selv sandboxed - Java anyone? - er det en tabt kamp, og så bliver det ikke synderligt nemt at skulle tilføje endnu et lag og bevare et hint af performance, hvorfor det så er ekstra humoristisk at der tales om at virksomheder skal bruge noget sådant.
Men det kan da sikkert appelere til de samme mennesker som "koder hjemmesider med Frontpage". :-)
Selvfølgelig, til de der lever efter devisen "hardware billigere end udviklere" kan det vel virke lige så godt som at tisse i bukserne, men...
Hvis folk bare vidste hvor stor forskel der er på software, og ikke optimeret software. :-) Selv sandboxed - Java anyone? - er det en tabt kamp, og så bliver det ikke synderligt nemt at skulle tilføje endnu et lag og bevare et hint af performance, hvorfor det så er ekstra humoristisk at der tales om at virksomheder skal bruge noget sådant.
Men det kan da sikkert appelere til de samme mennesker som "koder hjemmesider med Frontpage". :-)
nyx (29) skrev:LOL - peeerrrfoooooomanceeee?! Hvor blev du af?!
Læs lige #24, og fortæl mig om du primært koder assembly.
nyx (29) skrev:Selvfølgelig, til de der lever efter devisen "hardware billigere end udviklere" kan det vel virke lige så godt som at tisse i bukserne, men...
Som udgangspunkt passer det meget godt, men man skal altid finde en balance for hvor meget man skal gøre ud af performance.
Nogle gange skriver man elementer i assembly, for virkelig at hive så meget som muligt ud af en processor. Det er bare så dyrt at det gør man sjældent. Andre gange er performance noget nær ligegyldigt, og så skal man bare op på så højt et abstraktionsniveau som muligt.
Jeg sidder selv til dagligt og gør hvad jeg kan, for at vores udviklere skal fortælle computeren HVAD den skal gøre, og ikke HVORDAN. Og ALLE udviklere jeg har hørt udtale sig om det, synes det er en rigtig fed ide.
(Og performance-forskellen er kun målbar hvis jeg kører den ud i ekstreme urealistiske situationer.)
briancaos (4) skrev:Hvem skal lave koden til hans Model Based Software? :-)
Man kan skrive en C compiler i C o.s.v. så mon ikke man kan lave MDA software med MDA.
Man skal selvfølgelig have en håndskrevet bootstrapping til første version, men det laver man så.
Det har man kunne gøre med compilere i 40 år (mindst).
knasknaz (26) skrev:"Software bliver mere og mere kompleks"...
Software bliver også mere og mere fyldt med bugs. Mon der er en sammenhæng?
Jeg har ikke set nogen undersøgelser som siger at fejl per 1000 linier kode stiger.
Snarere tværtimod.
At det absolutte antal fejl stiger når kode mængden stiger voldsomt og man ikke ændrer udviklings processen fundamentalt er næppe overraskende.
#41
MDA har skam været brugt i den virkelige verden i adskillige år.
Se f.eks.:
http://www.kc.com/success.php
MDA har skam været brugt i den virkelige verden i adskillige år.
Se f.eks.:
http://www.kc.com/success.php
#41
Hvis du selv vil lege med noget MDA, så kig på:
http://www.andromda.org/
Det er langtfra så komplet som Kennedy Carter's Ada generering, men stadig interessant.
Jeg vil dog nok foreslå at du bruger Java backend fremfor .NET backend. Der er flere cartridges til Java end til .NET.
Hvis du selv vil lege med noget MDA, så kig på:
http://www.andromda.org/
Det er langtfra så komplet som Kennedy Carter's Ada generering, men stadig interessant.
Jeg vil dog nok foreslå at du bruger Java backend fremfor .NET backend. Der er flere cartridges til Java end til .NET.
Jeg synes det er meget intressant at de fleste betragter som noget der udelukkende laves i grafiske annotationer ala UML. (Dog med langt bedre dynamiske beskrivelse)
Personligt bruger jeg VDM++ til at arbejde med MDA*/MDD (dog 95% universitets relateret), og det er godt nok tekst. Men det er ikke kode i den gængse forstand men en matematisk notation. Vores ide er at både bruge UML (og lign) med den her matematiske notation, således at vi kan få det bedste at begge verdener. Som det er pt kan man gå direkte fra VDM++ til UML og tilbage igen, dvs at der hvor UML og generelt grafiske udtryksformer har sin begrænsning der vælger man den tekstuelle notation, og ellers kan man bruge UML.
Yderligere er næste trin så at inkludere andre notationer, f.eks. kunne det være rart at kunne direkte koble sin software model over på en mekanik model som er beskrevet i mekanikkens notation, kunne være en Bond Graph.
Og det er nok her jeg ser den største fordel for MDA, det er muligt at lave simuleringer og beskrivelser på et meget tidligt stadie og endda få testet disse på tværs af fagområder.
*MDA er selvfølgelig OMG's udtryk, men det bliver alligevel brugt i sammenhæng som ikke direkte er dem.
Og til den som brokker sig over performance på autogen kode, så er de fleste kodegeneratorere så gode idag at det er sjældent man kan vinde noget ved at gøre det bedre. BODEREC projektet havde målinger der viste at den eneste forskel på håndlavet og autogen kode, var at autogen kode brugte cirka 10% mere memory på deres embeded udstyr, og det var i 2006 de blev konkluderet. 10% er meget, men kan man spare 10.000 udviklingstimr så kan den større memory kreds hurtigt tjenes hjem.
Personligt bruger jeg VDM++ til at arbejde med MDA*/MDD (dog 95% universitets relateret), og det er godt nok tekst. Men det er ikke kode i den gængse forstand men en matematisk notation. Vores ide er at både bruge UML (og lign) med den her matematiske notation, således at vi kan få det bedste at begge verdener. Som det er pt kan man gå direkte fra VDM++ til UML og tilbage igen, dvs at der hvor UML og generelt grafiske udtryksformer har sin begrænsning der vælger man den tekstuelle notation, og ellers kan man bruge UML.
Yderligere er næste trin så at inkludere andre notationer, f.eks. kunne det være rart at kunne direkte koble sin software model over på en mekanik model som er beskrevet i mekanikkens notation, kunne være en Bond Graph.
Og det er nok her jeg ser den største fordel for MDA, det er muligt at lave simuleringer og beskrivelser på et meget tidligt stadie og endda få testet disse på tværs af fagområder.
*MDA er selvfølgelig OMG's udtryk, men det bliver alligevel brugt i sammenhæng som ikke direkte er dem.
Og til den som brokker sig over performance på autogen kode, så er de fleste kodegeneratorere så gode idag at det er sjældent man kan vinde noget ved at gøre det bedre. BODEREC projektet havde målinger der viste at den eneste forskel på håndlavet og autogen kode, var at autogen kode brugte cirka 10% mere memory på deres embeded udstyr, og det var i 2006 de blev konkluderet. 10% er meget, men kan man spare 10.000 udviklingstimr så kan den større memory kreds hurtigt tjenes hjem.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund