Wil de vijfde generatie nu opstaan
Auteur: Rick F. van der Lans
Geschreven: september 2002
Gepubliceerd in: [Corporatie]Solutions jaargang 2002 nummer 02
Inleiding
Door de jaren heen hebben we al vele generaties ontwikkelproducten en -talen zien komen en gaan. De diverse generaties verschillen op basis van eigenschappen als productiviteit, performance, overdraagbaarheid en onderhoudbaarheid. Waar staan we nu eigenlijk met onze huidige generatie producten? We zijn zeker opgeschoten ten opzichte van dertig geleden, maar geldt dat ook ten opzichte van tien jaar geleden en hoe zal deze markt zich gaan ontwikkelen?
De prehistorie – de eerste drie generaties
Zelf heb ik de fase waarin programma's in machinecode geschreven werden niet meegemaakt. Waarschijnlijk liepen de programmeurs toen nog in witte jassen en waren ze niet te beroerd om een kapotte lamp in de computer te vervangen of even met de soldeerbout te editen.
Het programmeren in assembleertalen (ofwel de tweede generatie ontwikkeltalen) en het werken met ponskaarten, kan ik mij nog vaag herinneren. Deze tweede generatie ontwikkeltalen was veel minder complex en dat had een positieve invloed op de productiviteit van de programmeur en de onderhoudbaarheid van de code. Voor de twee eerste generaties was de overdraagbaarheid ver te zoeken, want machinecode en assembleertalen waren gekoppeld aan een bepaald besturingssysteem.
Een nadeel van de introductie van de tweede generatie was wel het performanceverlies. Tenminste, de ‘diehards’ die nog in machinecode hadden zitten krassen, beweerden dat door hen zelf geschreven code efficiënter was dan door de assemblers gegenereerde code. Een kritiek die we in de decennia daarna nog vaker zouden horen. Uiteraard is die kritiek deels gerechtvaardigd. De vraag is alleen of elke programmeur over voldoende kwaliteiten beschikte om efficiëntere code te schrijven dan een generator. We komen er later in dit artikel op terug.
Na de assembleertalen kregen we in de jaren zestig en zeventig de derde generatie ontwikkeltalen, zoals aanvankelijk Cobol, Fortran, PL/I en later Algol, Pascal en C. Dit waren de eerste gestructureerde programmeertalen. Deze talen zijn minder complex waardoor de productiviteit van een programmeur toenam. Eén regel Cobol-code verving vele regels machinecode. Tevens kwam dit de onderhoudbaarheid van de applicaties ten goede.
Een bijkomend voordeel was dat de ontwikkelde code overdraagbaar was, iets dat geheel niet mogelijk was met de voorgaande generaties. Een Cobol-applicatie kon met een minimale inspanning omgezet worden naar een ander besturingssysteem en kon door een Cobol-compiler van een andere leverancier gecompileerd worden. Voor de meeste talen bestonden ISO-standaarden en de leveranciers hielden zich daar redelijk aan.
Wel dient men te beseffen dat er met de komst van de derde generatie nog geen IDE's (Integrated Development Environments) bestonden waarmee de programmeurs eenvoudig konden editen, compileren, linken en debuggen. De kwaliteit van de editors was zo matig, dat programmeurs een moord gedaan zouden hebben voor het hedendaagse Notepad.
Maar er was natuurlijk weer kritiek op de performance. De gegenereerde code was in de ogen van sommigen niet efficiënt genoeg. Nu zouden we een dergelijke kritiek niet meer serieus nemen: Wat bedoel je met dat mijn eigen geschreven Pascal-code niet efficiënt is? Uiteindelijk zijn vele softwarepakketten die we momenteel gebruiken, zoals database- en applicatieservers, in derde generatietalen als C geschreven. Dus met die performance blijkt dat achteraf wel allemaal mee te vallen.
De middeleeuwen – de vierde generatie
Maar de productiviteit van de derde generatie was nog niet voldoende. De vraag naar applicaties overtrof ruim de productiecapaciteit van de ICT-afdelingen. Iedereen had het begin de jaren tachtig dan ook over de
softwarecrisis. Er was een grote achterstand van te bouwen applicaties. Dit was de voedingsbodem voor de
vierde generatie ontwikkelproducten. Men dacht de productiviteit te kunnen verhogen door talen te ontwikkelen die speciaal uitgerust werden voor het bouwen van administratieve applicaties. Ter informatie, de eerste drie generaties waren allemaal generieke talen: er konden administratieve applicaties en ook technische software mee ontwikkeld worden. Het was de periode waarin producten als Focus, PowerHouse, Progress en SQL*Forms (nu Oracle Developer) op de markt kwamen. Men was afgestapt van generieke talen.
Het grote voordeel van deze vierde generatie was de productiviteitsverbetering: met nog minder regels code kon een applicatie geschreven worden. Tevens werd de productiviteit verhoogd omdat deze talen geïntroduceerd werden samen met de eerste lichting IDE’s. Deze nieuwe producten waren eigenlijk eerder geïntegreerde ontwikkelproducten (om code te ontwikkelen en te editen) dan programmeertalen.
Ook de vierde generatie kende natuurlijk enkele nadelen. De in deze talen ontwikkelde applicaties waren alleen overdraagbaar naar die platformen waar diezelfde leverancier zijn product beschikbaar gemaakt had. Ze waren niet overdraagbaar naar producten van andere leveranciers, want iedereen had zijn eigen taal ontwikkeld. Dus wat overdraagbaarheid betreft, was de komst van de vierde generatie een forse stap terug in de tijd. En ook de performance werd zwaar bekritiseerd. Nu was het niet omdat de tegenstanders vonden dat er inefficiënte code gegenereerd werd, maar omdat de meeste producten de code helemaal niet compileerden. Het waren bijna allemaal interpreters. En dat was de essentie van de kritiek: geïnterpreteerde code kan nooit zo efficiënt zijn als gecompileerde code.
Maar in die periode was productiviteit wel een van de belangrijkste eigenschappen, omdat, zoals reeds vermeld, er een software-crisis aan de gang was. Performanceproblemen kon je oplossen door grotere machines te kopen.
In het kielzog van de vierde generatietalen, kregen we de CASE-tools. In het begin waren dit voornamelijk producten om analyse- en ontwerpspecificaties te documenteren en te beheren. Pas later maakten enkele de overstap naar ontwikkelproducten, zoals IEF (momenteel Advantage Gen geheten).
We dachten dat met de nieuwe CASE-tools de vijfde generatie opgestaan was, maar helaas. Aan het begin van de jaren negentig werden deze producten naar de achtergrond gedrukt door de komst van de tweede golf vierde generatie ontwikkelproducten, de zogenaamde GUI-tools (Graphical User Interface), zoals PowerBuilder, SQLWindows en VisualBasic (en nog honderd andere). De eerste golf was initieel ontwikkeld om monolithische applicaties met een character-based interface te maken, de tweede golf was bedoeld om client/server applicaties met een grafische interface te ontwikkelen. Maar afgezien van deze verschillen waren het wederom niet-overdraagbare producten.
De renaissance – de generatie X
De schilders uit de renaissance staan bekend om hun zeer gedetailleerde schilderijen. Zij waren maanden met één schilderij bezig. Dit is een van de karakteristieken van schilderijen uit die periode. Een andere karakteristiek was dat er in die periode nieuwe tekentechnieken bedacht werden.
De tweede helft van de jaren negentig zou misschien wel als de renaissance van de ICT-industrie gekenmerkt kunnen worden. Na heel even met C++ gestoeid te hebben, verloor de markt zijn hart aan Java (althans, degenen die niet hun ziel verloren aan Microsoft’s VisualBasic).
Het grote voordeel van Java is de overdraagbaarheid: het draait op vele platformen en is door vele leveranciers geïmplementeerd. Wat dat betreft hebben we een eigenschap terug die we met de vierde generatie verloren hadden. Maar ten opzichte van de vierde generatie kent Java ook diverse nadelen. Zoals in de renaissance is voor het programmeren in Java een nieuwe techniek nodig: object-oriëntatie. Alle voorgaande generaties gingen nog steeds uit van procedurele talen.
Een tweede overeenkomst tussen Java en de renaissance is de bewerkelijkheid. Een gemiddelde Java-programmeur heeft een lagere productiviteit dan een Progress- of PowerBuilder-programmeur. De complexiteit van Java moet niet onderschat worden. Natuurlijk is de taal zelf niet het probleem, maar alle benodigde class libraries. Een administratieve applicatie bouwen die gebruik maakt van een EJB-gebaseerde applicatieserver (Enterprise JavaBeans) is een slag ingewikkelder. Dus eigenlijk moeten we stellen dat niet Java complex is, maar de complete J2EE (Java 2 Enterprise Edition) omgeving.
Degene die niet overgingen op Java en ook niet tevreden waren met hun vierde generatie producten, stapten over op VisualBasic. Maar VisualBasic is eigenlijk Basic (wat ooit nog een overdraagbare derde generatie taal was) waaraan vierde generatie faciliteiten toegevoegd waren. VisualBasic kent eigenlijk dezelfde problemen als Java, behalve dat VisualBasic op geen enkele wijze overdraagbaar is.
Zijn Java en VisualBasic nu kinderen van de beloofde vijfde generatie, waar sommigen op zaten te wachten? Waarschijnlijk niet. Deze
generatie X vormt eigenlijk een trendbreuk. Met de komst van elke nieuwe generatie werd de productiviteit van een programmeur opgevoerd en werd performance ingeleverd. Generatie X is eigenlijk een stap zijwaarts geweest, maar deze stap heeft ons wel weer de waarde van overdraagbaarheid en de mogelijkheden van object-oriëntatie duidelijk gemaakt.
Komt er dan ooit nog een vijfde generatie?
De toekomst – de beloofde vijfde generatie
Een bekend fenomeen is dat als er voldoende budget is, dat men dan bereid is geld uit te geven aan zaken die zich pas op lange termijn laten uitbetalen. Neemt het beschikbare budget af, dan denkt men meer op korte termijn. Overdraagbaarheid is een korte termijn aspect, terwijl productiviteit een lange termijn aspect is.
Vanaf halverwege de jaren negentig heeft de ICT-industrie zeer goede jaren gekend. Geld leek geen probleem te zijn. Men vond, in tegenstelling tot de jaren daarvoor, dat productiviteit minder belangrijk was. Het ging allemaal om overdraagbaarheid. Vandaar ook de interesse voor Java.
Tegenwoordig bevinden we ons in een economisch minder gunstig klimaat en dus zal de interesse voor lange termijn aspecten, zoals overdraagbaarheid, afnemen. Dus ook de overdraagbaarheid van Java zal men minder belangrijk gaan vinden. Bedrijven zullen weer op zoek gaan naar producten om hun productiviteit te verhogen. Enkele leveranciers hebben deze trend reeds onderkend. Er zijn reeds producten beschikbaar die vanuit UML- of vergelijkbare specificaties (Unified Modeling Language) J2EE-code genereren, zoals:
· Advantage Gen en Advantage Joe van Computer Associates
· ArcStyler van Interactive Objects
· Describe van Embarcadero
· jDeveloper van Oracle
· OptimalJ van Compuware
· Rational XDE van Rational
· Together Control Center van TogetherSoft
· WMEE van Sygel
Uiteraard hebben al deze producten een andere aanpak en kunnen ze niet allemaal dezelfde soort code genereren, maar het idee is hetzelfde. Hoe werkt het dan? Simpelweg, de ontwikkelaar specificeert een klasse-diagram volgens de UML-standaard (of een vergelijkbaar diagram als een andere methodiek gehanteerd wordt) en zet dan de code-gerenator aan. Figuur 1 bevat een voorbeeld van een dergelijk diagram gemaakt met Together en WMEE. De generator genereert dan vervolgens: alle Java-classes, alle benodigde EJB-specificaties (sessions en entity beans) en de meeste elementaire get- en set-methods om de objecten te manipuleren.
Figuur 1: Een voorbeeld van een klasse-diagram waaruit code gegenereerd wordt.
In feite wordt er een werkend raamwerk van de applicatie gecreëerd. Let wel, deze applicatie is nog niet klaar. De programmeur moet zelf nog wel met de hand de speciale methods in Java programmeren. Maar het saaie, zich herhalende programmeerwerk wordt door de producten overgenomen. Dit alles komt uiteraard de productiviteit en onderhoudbaarheid ten goede.
Hoe staat het dan met de performance? Zoals u kunt raden, de echte Java-programmeur denkt dat hij zelf efficiëntere code kan schrijven. Maar deze kritiek hebben we de afgelopen jaren al vaker gehoord. Een aantal specialisten zal dit ook inderdaad kunnen, maar we moeten hier realistisch in zijn. Zoals reeds vermeld, het gaat niet alleen om Java-code, maar ook om calls naar bijvoorbeeld de EJB en RMI class libraries. Helaas zijn er niet zoveel ervaren J2EE-programmeurs die efficiënte Java-code kunnen schrijven waarin efficiënte calls gemaakt worden naar EJB en RMI. Dit is nog steeds een schaarse vakkundigheid. En vergeet niet, wat is momenteel belangrijker: productiviteit/onderhoudbaarheid of performance? Ik denk dat veel bedrijven nu voor het eerste zullen kiezen.
Het effect van de komst van deze Java-generatoren zal zijn dat steeds meer ontwikkelaars J2EE als een overdraagbaar deployment platform zullen zien en niet als ontwikkeltaal. De komst van deze producten zou men ook kunnen beschouwen als de wederopstanding van de CASE-tools. Alleen deze nieuwe CASE-tools beperken zich niet tot documenteren, maar genereren ook code. Hierdoor zullen ze niet alleen op lange termijn voordelen bieden maar ook op korte termijn.
De specificaties die we met deze producten opvoeren zijn overdraagbaar. Ook de gegenereerde Java-code is op alle manieren overdraagbaar: elk platform en elke leverancier. Alhoewel, er bestaan wel degelijk verschillen tussen de verschillende applicatieservers. Meestal moet er wel degelijk gesleuteld worden om een applicatie over te zetten. Soms moet zelfs een applicatie aangepast worden als een klant overgaat naar een volgende versie van de applicatieserver. Ook dit werk vervalt op het moment dat een generator wordt gebruikt. Bij de hergeneratie hoeft slechts een ander platform gespecificeerd te worden.
Sommige van deze producten genereren bovendien code voor andere deployment-platformen dan J2EE, zoals Microsoft’s .NET. Hiermee is de investering nog meer gewaarborgd.
Een ander aspect van overdraagbaarheid is dat de opgevoerde specificaties voldoen aan UML en kunnen via XMI (XML Metadata Interchange) met andere producten uitgewisseld worden. Dit is al door enkele producten bewezen. WMEE kan bijvoorbeeld als extensie op Together werken. Via XMI worden specificaties overgeheveld.
Deze vijfde generatie heeft ook iets gemeen met de vierde generatie: het zijn geen generieke producten meer. Iets wat generatie X wel weer was. Deze nieuwste generatie is speciaal ontworpen voor het bouwen van administratieve applicaties. Je kunt er dus geen compilers of buffermanagers mee ontwikkelen.
Zoals reeds vermeld, deze producten genereren werkende applicaties. Echter, niet alle gewenste functionaliteit wordt gegenereerd. Bijvoorbeeld, integriteitregels die betrekking hebben op de gegevens kunnen niet met UML gespecificeerd worden en er kan dus ook geen code voor gegenereerd worden. Het genereren van user-interfaces is ook maar matig geïmplementeerd. En ook voor schrijven van echte bedrijfslogica moet de programmeur gewoon handmatig Java coderen. Kortom, de producten zijn nog niet klaar, maar de richting is bepaald.
Als overzicht bevat de onderstaande tabel indicaties van hoe de verschillende generaties relatief scoren op basis van de eigenschappen productiviteit, overdraagbaarheid en performance.
Relatieve scores
