In dit artikel wordt betoogd waarom softwareontwikkeling met een mix van 3GL en 4GL (third en fourth generation languages) zinvol kan zijn.
Programmeertalen hebben in de geschiedenis van de software een sterke ontwikkeling gekend. Op een gegeven moment is een indeling ontstaan in generaties:
– 1GL: direct binair coderen in de microprocessorinstructies, machinecode
– 2GL: assembler en andere op mnemonics (MOV, REG) gebaseerde producten.
– 3GL: Cobol, C++, Java, Pascal
– 4GL: Visual Basic, Uniface, Progress 4GL, Oracle
Deze indeling heeft niet alleen technisch betekenis, maar is ook te herkennen in de productiviteit. Hoewel de productiviteit van bijvoorbeeld 3GL’s onderling verschilt, verschillen ze als groep duidelijk van 4GL’s. Voor dit artikel is de GL-indeling een indeling in gemiddelde productiviteit en daarmee in ontwikkelkosten. Java en C# zijn na de 4GL-producten ontwikkeld. Dat is echter geen reden ze als 5GL aan te merken. Qua structuur, doelgebied en productiviteit passen ze in de 3GL-typering.
In de wereld van de zakelijke software hebben 4GL’s een productiviteitsvoordeel. Dit geldt vooral voor de eigenlijke logica binnen in de applicatie. De buitenkant van applicaties – de ‘user interfaces (UI)’– is een onrustige wereld sinds de komst van Windows. Die wereld ontwikkelt zich snel en er is duidelijk sprake van modeverschijnselen om de verkoop te stimuleren. De zakelijke markt heeft geen behoefte aan ‘le dernier cri’ en het vergt excessief veel middelen om vanuit 4GL-producten steeds de laatste UI-‘standaard’ te ondersteunen.
Men kan nog steeds het best een 4GL gebruiken voor de ontwikkeling van bedrijfslogica. Voor applicaties die een top-UI moeten hebben is een 3GL de beste keuze, maar onbetaalbaar bij inzet als enige technologie. Een combinatie van 4GL en 3GL geeft een goede prijs/prestatieverhouding. Dat kan veranderen, want er is veel creativiteit in de it-markt. Dit artikel behandelt softwareontwikkeling voor het Windows-platform. Alternatieven komen niet aan de orde.
3GL en 4GL, wat zijn dat?
In de tachtiger jaren heeft it-goeroe James Martin een indeling gemaakt van 1GL tot 4GL omdat hij vond dat de ontwikkeling van programmeertalen duidelijke fasen vertoonde. 1GL tot 4GL hebben elkaar niet opgevolgd: ze bestaan alle nog voor meer of minder gespecialiseerde doelen. Vooral 3GL en 4GL overlappen elkaar zodanig dat een duidelijke keuze nodig is voor men met softwareontwikkeling begint. We beperken ons hier tot 3GL en 4GL.
3GL’s hebben een beperkt aantal elementaire opdrachten. Die geven de flexibiliteit om vrijwel elke opgave in code om te zetten. Het nadeel van die flexibiliteit is de hoeveelheid werk die men ervoor moet verzetten. Beheersing van een 3GL is niet zozeer technische kennis, als wel ervaring hoe men de mogelijkheden toepast en combineert. De programmeertechniek in 3GL is meer binair en relatief eenvoudig door de beperkte keuze uit statements.
4GL’s hebben een groter aantal opdrachten die eigenlijk meta-operaties zijn. Met enkele opdrachten wordt veel functionaliteit gerealiseerd. Dat werkt sneller, maar kan een beperkte flexibiliteit opleveren. Als een 4GL-opdracht niet precies werkt als gewenst, is er een probleem. De programmeur kan de gewenste functionaliteit alsnog zelf bouwen. Als men een 4GL echter als 3GL gebruikt, kan men beter direct een 3GL kiezen. De programmeur kan ook een 4GL kiezen waarbij elke opdracht met parameters beïnvloed kan worden. Echter, hoe meer parameters, hoe meer werk. Het compromis tussen flexibiliteit en productiviteit kan men niet ontlopen.
Het verschil tussen 3GL en 4GL in productiviteit is altijd beïnvloed door in 3GL-‘libraries’ functionaliteit toe te passen voor zaken die men steeds weer nodig heeft. Elke grafische user interface heeft menu’s, gebruikers en toegangsrechten nodig. Het is zinloos dat steeds weer opnieuw te ontwikkelen; men gebruikt componenten uit een library.
Er zijn altijd ‘libraries’ geweest en er heeft altijd de neiging bestaan populaire delen uit ‘libraries’ in een taal op te nemen. Dat is ook precies hoe 4GL’s uit 3GL’s zijn ontstaan. Op een gegeven moment zijn zoveel meta-mogelijkheden aan een taal toegevoegd dat de oorspronkelijke opdrachten niet meer worden gebruikt; er is een nieuwe taal ontstaan. De neiging tot specialisatie komt direct voort uit de prijs/prestatieverhouding. De beste programmeertaal wordt niet toegepast als de ontwikkelkosten niet kunnen worden terugverdiend. Ook de ‘nieuwe’ 3GL’s, zoals Java en C#, zullen niet aan de druk tot specialisatie kunnen ontkomen. Java en C# zullen nooit werkelijk algemene toepassing vinden zolang ze onproductiever en dus duurder in gebruik zijn dan 4GL-omgevingen. Na specialisatie is een 3GL echter geen 3GL meer, maar een 4GL of wellicht een 5GL. De geschiedenis zal zich herhalen.
Productiviteit van programmeertalen
4GL’s bestaan van origine eigenlijk alleen voor de markt van zakelijke, administratieve software en zijn daarom onverbrekelijk verbonden met het gebruik van databases. Het volgende kleine voorbeeld is in Progress 4GL geschreven:
Display customer
End for
Dit kleine stukje code leest alle records uit de customer tabel in een database en toont het resultaat (alle velden) op het scherm. Voor hetzelfde resultaat is met een 3GL heel wat meer code nodig. Dat zegt niets over de technische mogelijkheden van de talen. We kijken hier puur naar de productiviteit.
4GL’s zijn dus vooral bedoeld om zakelijke toepassingen te realiseren. Binnen dat gebied bieden ze de nodige flexibiliteit en een hoge productiviteit. Erbuiten presteren ze niet beter of slechter dan 3GL’s. Voor de productiviteit van programmeertalen is een aantal bronnen beschikbaar, zoals de Amerikaanse organisatie QSM (www.qsm.com). QSM beheert een database met gerealiseerde softwareprojecten. Men houdt onder meer de omvang van projecten in functiepunten bij. Op de website staat een samenvatting uit de database van de productiviteit van programmeertalen in SLOC (‘Source Lines Of Code’) per functiepunt. De gedachte erachter is dat indien voor een functiepunt met taal B de SLOC het dubbele is van taal A, men tweemaal zoveel werk moet verzetten om hetzelfde te bereiken. De productiviteit van taal A is dan het dubbele van die van taal B. Dit is een grove simplificatie van de realiteit. In de nog jonge it is het echter alles wat we hebben. ISBSG (www.isbsg.org) geeft vergelijkbare informatie.
Functiepuntanalyse is een ISO-standaardmethode om de omvang van applicaties te schatten. We gaan hier niet dieper op in. Wie meer wil weten kan terecht op de uitstekende website van de Nederlandse FPA-organisatie (www.nesma.org).
Afgezien van verschillen tussen individuele producten is er ook een duidelijk onderscheid tussen 3GL en 4GL. 3GL’s hebben ongeveer 65-70 SLOC per functiepunt nodig, 4GL’s doen hetzelfde met 30-35 SLOC. Er is meer nodig bij een project dan alleen programmeren. Op basis van de QSM-gegevens zou de deeltaak programmeren met een 3GL tweemaal zoveel werk vragen als met gebruik van een 4GL in een project dat voor toepassing van een 4GL geschikt is.
4GL en user interfaces
Een ‘normale’ gebruikerstoepassing kan men in drie delen onderscheiden. Deze indeling is bekend als het drielagenmodel of ‘3 tier architecture’:
1. User interface (wat u te zien krijgt om de applicatie te kunnen gebruiken)
2. Logica (wat de applicatie eigenlijk voor u doet)
3. Gegevensopslag (database)
(zie afbeelding 1)
4GL’s zijn zeer goed om de logica (2) en de toegang tot gegevens (3) te realiseren. 4GL’s hebben beperkingen op het gebied van grafische user interfaces (1). In de praktijk spreken we over desktop GUI’s op basis van Windows. Windows is een complex systeem om voor te ontwikkelen. Er bestaan meer versies die veel verschillen vertonen in de wijze van gebruik.
Het is mogelijk om met 4GL-opdrachten een goede algemene Windows GUI te realiseren met een beperkt ‘toeters en bellen’-gehalte. Een 4GL moet veel meta-opdrachten met veel parameters bevatten om alle subtiliteiten van een GUI te kunnen realiseren. Die meta-opdrachten moeten ook in constante ontwikkeling zijn om de ontwikkelingen te kunnen bijhouden. Er is (nog) onvoldoende stabiliteit in de GUI-wereld om de aansturing in 4GL’s op te nemen. De stabiliteit die in de zakelijke wereld voorop staat zou in de verdrukking komen.
De oplossing om een ‘rijke’ GUI te realiseren met optimale productiviteit is een mengeling van 4GL voor de applicatielogica en 3GL voor de GUI. Een dergelijke opzet stelt hoge eisen aan de architectuur en aan de in te zetten producten om een goed resultaat tegen aanvaardbare kosten te realiseren.
Er ontstaat een mengeling van technieken; dit geldt ook voor de productiviteit. Men gebruikt de hogere productiviteit van de 4GL voor de realisatie van de bedrijfslogica. Men accepteert de lagere productiviteit van de 3GL voor de GUI; tegenover de hogere kosten staat een meer ‘geraffineerde’ UI. Als men heeft vastgesteld dat een ‘rijke’ GUI de verkoopkansen van het product vergroot is dit economisch een gezonde keuze.
Consequenties voor de architectuur
Het 3-lagenmodel is bekend, met een ‘thin client’ die alleen presentatie – UI – verzorgt, een apart deel dat op een centrale server de bedrijfslogica van de applicatie uitvoert en gegevens met de database uitwisselt en tenslotte de gegevensopslag, normaal gesproken een relationele database.
De redenen voor de 3-lagenarchitectuur zijn als volgt samen te vatten. Bedrijfslogica hoort niet als een kopie op elke gebruikers-pc thuis. Een ‘thin client’ hoeft alleen presentatie te verzorgen, kan daardoor goed presteren en vermindert het probleem van het verspreiden naar elke gebruikers-pc. Alleen wijzigingen in het presentatiedeel – de UI – moeten naar de gebruikers-pc’s. De bedrijfslogica draait op een professioneel beheerde centrale server. De manieren om de lagen met elkaar te laten communiceren zijn te onderscheiden in ‘tightly coupled’ en ‘loosely coupled’. In een ‘tightly coupled’ opzet zijn er functioneel drie aparte lagen; de delen kunnen echter niet zonder elkaar werken. Een ‘loosely coupled’ opzet gebruikt een gedocumenteerde set van vraag en antwoord tussen de delen, een zogenoemde API (application programming interface). De delen zijn nu wel zelfstandig; elke UI die zich aan de API houdt kan met de bedrijfslogica communiceren. Niet-menselijke interfaces (zoals Web Services) kunnen dezelfde vraag-en-antwoordmethode gebruiken. Er is geen reden waarom de verschillende delen met hetzelfde product of dezelfde technologie moeten zijn gerealiseerd.
Volgend voorbeeld geeft een uitwerking voor een API voor een facturatieproces als een lijst in Excel en in UML-notatie. Het is duidelijk dat elke vraag in de implementatie een methode wordt van een component in de bedrijfslogica, in het voorbeeld ‘bInvoice’.
Afbeeldingen 2 en 3 illustreren hoe een API tussen presentatie en bedrijfslogica eruit ziet. Tussen bedrijfslogica en database functioneert het datamodel als API. De database is in beginsel toegankelijk voor elke bedrijfslogica die het datamodel erkent en de juiste toegangsmethode – vaak SQL – toepast. Daarmee is in beginsel de weg open om drie lagen elk met verschillende technologie als een geheel te laten opereren. ‘In beginsel’ omdat technieken ook op technisch niveau met elkaar moeten kunnen ‘praten’. Een UI met .NET en C# vereist dat de bedrijfslogica ADO record sets en C#-proxies aanbiedt, eenvoudig omdat .NET zo communiceert; hetzelfde geldt voor andere UI-technieken (bijvoorbeeld browsergebaseerd) alsmede tussen bedrijfslogica en relationele database.
Het belang van een framework
‘Framework’ is een term met vele definities. Hier gaan we uit van de definitie dat een framework een combinatie van de volgende twee zaken is:
– Methodologie. Software is complex. Een methodologie definieert een interne structuur waarin de verschillende delen binnen een applicatie samenwerken. Die structuur heeft ook als doelstelling dat de verschillende delen zo eenvoudig mogelijk te ontwikkelen en te hergebruiken zijn. Naast technische merites heeft een methodologie dus duidelijk productiviteit en kwaliteit in het vizier.
– Componenten. In een methodologie is het duidelijk dat bepaalde delen standaard zijn in die zin dat elke met een methodologie te maken applicatie die nodig heeft. Een voorbeeld is de definitie van gebruikers en toegangsrechten; een ander de data interfaces. Dergelijke standaarddelen kunnen in een framework als kant-en-klare componenten beschikbaar zijn om de ontwikkelinspanning te beperken en de productiviteit te verhogen.
Wat technologisch mogelijk is, moet ook nog toepasbaar zijn met goede kwaliteit en aanvaardbare kosten. Meertaligheid is zeldzaam, zowel in menselijke taal als in programmeertalen. Eentaligheid is dat niet. Het is daarom van het grootste belang voor it-ontwikkeling met meer technieken om deze van elkaar te isoleren, zodat elk in de eigen bekende omgeving kan werken. Hier is ondersteuning door een adequaat framework van belang.
Als men zich het belang van de interface – de API’s – tussen presentatie en logica en die tussen logica en database realiseert, is er eigenlijk sprake van een 5-lagenarchitectuur.
Als een framework de beide API’s genereert, kunnen de ontwikkelaars ‘eentalig’ werken zonder last te hebben van de andere technologie. Afbeelding 4 geeft een volledige architectuur weer met de te genereren componenten. Binnen de grenzen van wat een gekozen framework ondersteunt, kan men verschillende technieken voor UI, logica en RDBMS toepassen.
Het gemengde gebruik van 3GL en 4GL kan zeer goede resultaten geven, zowel in het gerealiseerde product als in het budget. Succesvolle softwareontwikkeling vraagt om een professionele organisatie. Het gebruik van meer dan een ontwikkelomgeving introduceert extra complexiteiten en legt de lat nog hoger. Planning, ontwerp, organisatie en ondersteuning met een krachtig framework moeten alle van het hoogste niveau zijn om de complexe uitdaging de baas te blijven.
Conclusie
4GL is niet dood en evenmin afgeschreven. De productiviteit voor de ontwikkeling van ‘business applications’ blijft een onnavolgbaar voordeel. 4GL-technologie is nooit bedoeld geweest om alle denkbare softwareontwikkeling mee te doen. Inmiddels is ook de wereld van administratieve software zodanig ontwikkeld dat daarbinnen specialisaties zichtbaar worden. Integratie – gebaseerd op Java ‘messaging’ standaarden – is niet meer weg te denken. User interfaces zijn een tweede gebied waar inzet van een 3GL diensten zou kunnen bewijzen. De conclusie van dit eerste artikel is dan: gebruik, naast 4GL-technologie, Java en .Net voor die gebieden waar ze een toegevoegde waarde hebben ten opzichte van 4GL in plaats van met een hype mee te groeien.n