Ik ben ervan overtuigd dat de toekomst van software bestaat uit herbruikbare componenten. De verschillende voorgestelde technieken en standaarden hebben nog een lange weg te gaan. Object-oriëntatie zal geen reuzensprong vooruit maken, ondanks de Java-lobby; dit komt door de aanwezigheid van alleszins acceptabele legacy-producten, zoals Ole en ingekapselde Cics-transacties. Java kan nog lang niet tippen aan de rijkdom van deze bestaande systemen.
Helaas zijn de meeste applicaties van vandaag de dag niet ontwikkeld op basis van modulaire technieken. Applicaties die wel modulair zijn opgebouwd, kunnen zo worden herschreven dat de herbruikbaarheid ervan toeneemt, maar in de praktijk werpt dit dilemma’s op. Moet een bestaande applicatie worden omgevormd tot iets modulairs, of moet het worden vervangen? Als het vervangen moet worden, moet je je dan committeren aan een nieuwe OO-technologie (Java), of moet je moderne component-uitbreidingen op bestaande talen als Cobol, C++ of Visual Basic gebruiken, zodat de bestaande kennis beter wordt benut?
De aanwezigheid van al deze opties betekent dat er voorlopig nog een mix van technieken zal blijven bestaan die op componenten gebaseerd zijn. Er bestaat immers niet één beste oplossing; een en ander is afhankelijk van bestaande code en vaardigheden.
Als er standaarden zouden zijn voor het beheer van component-bibliotheken, zou de coëxistentie van verschillende technieken een stuk makkelijker worden. Helaas is het interface naar een C++-klassebibliotheek niet compatibel met ‘native’ Ole of Java Beans. Hierdoor moeten er meerdere bibliotheken tegelijk worden beheerd en moeten er bibliotheken worden ondersteund voor verschillende programmeertalen met dezelfde functionaliteit.
De huidige trend, ‘rapid application development’ (rad), verdient een nadere specificatie. De huidige rad-tools zijn geen tools voor applicatie-ontwikkeling, maar voor programma-ontwikkeling. Applicatie-ontwikkeling omvat ook zaken als ontwerp, documentatie, versiebeheer, team-coördinatie, projectmanagement, testen en integratie. Met andere woorden: rad is gelijk aan case. Het programmeren zelf is nog het eenvoudigste deel van het probleem. Veel mislukkingen op client/server-gebied kunnen worden toegeschreven aan het verwarren van programma-ontwikkeling en applicatie-ontwikkeling.
De volgende stap is het combineren van grafische ontwikkeltools en tools die de uitgebreide case-levenscyclus ondersteunen. Componenten spelen hierbij een sleutelrol. Programmeurs zullen moeten worden opgesplitst in verschillende kampen. Applicaties moeten worden ontwikkeld door programmeurs die met behulp van visuele tools componenten integreren tot applicaties. Andere programmeurs zullen de componenten moeten ontwikkelen en onderhouden. Applicatiecomponenten zullen worden ontwikkeld door specialistische softwarehuizen, basiscomponenten door leveranciers van compilers. Dit is een probleem, omdat de software-industrie niet logisch gestructureerd is.
De ondersteuning van nieuwe componenten legt veel meer nadruk op documentatie dan vroeger. Als programmeurs vrijelijk gebruik willen maken van componenten, dan moeten ze precies weten wat die componenten doen. De rol van een gemeenschappelijke repository is kritischer dan ooit.
Er moeten nog wel wat hulpmiddelen worden ontwikkeld. Case-ontwerptools moeten beter worden benut; hierdoor zullen conflicten ontstaan met de huidige generatie gui-programmeurs, die nog nooit van onderhoud hebben gehoord. Om componenten op te zoeken, te bevragen, te gebruiken en te bewaken zijn andere tools nodig. Dit wordt belangrijker naarmate componenten meer in gedistribueerde omgevingen worden aangeboden, tijdens run-time via een netwerk, en naarmate MQ, D-Ole en Corba belangrijker worden. Als er meerdere machines bij betrokken zijn, dan moet er ook een vorm van dynamische werklastverdeling geïmplementeerd zijn.
De toolkits voor applicatie-ontwikkeling gaan met sprongen vooruit. IBM’s Visual Age, gebaseerd op de technologie van Nextstep, is de grote voorloper. De programmeur beschikt hierbij over een visuele methode om grafische en niet-grafische componenten te integreren tot applicaties. Deze programmeeromgeving, gebaseerd op Smalltalk, is ook toegepast op andere talen, zoals C++, Cobol en natuurlijk Java. Zo ziet de programmeur tot op zekere hoogte niet dat er verschillen bestaan tussen bibliotheken voor verschillende talen.
De komende maanden zullen Microsoft (Visual Component Manager), Powersoft (Powersite CM) en Borland (App Centre) grafische ontwikkelomgevingen introduceren die lijken op Visual Age. Reken er op dat Symantec en Sun met visuele Java-ontwikkeltools zullen komen. Leveranciers van case-tools, zoals Select en Popkin, kunnen hier voordeel uit putten, omdat de Universal Modelling Language (UML) de integratie zal bevorderen. Het meest zit ik echter nog te wachten op Microsofts Repository.
