Vermoedelijk heeft de ontwikkelaar de software getest en vastgesteld dat deze goed genoeg werkt, dus de uitdaging is om ervoor te zorgen dat de software net zo goed werkt, dat wil zeggen op de machines van de eindgebruiker.
Ik zal hier informeel naar verwijzen als correcte implementatie: gegeven identieke invoer, zou de software zich op een eindgebruikersmachine op dezelfde manier moeten gedragen als op de machine van de ontwikkelaar.
Software-implementatie is het probleem van het beheer van de distributie van software naar machines van eindgebruikers. Dat wil zeggen, een ontwikkelaar heeft een stukje software gemaakt en het moet uiteindelijk op de machines van de eindgebruikers terechtkomen. Na de eerste installatie van de software moet deze mogelijk worden bijgewerkt of verwijderd.
Dit zou een eenvoudig probleem moeten zijn. Als de software bijvoorbeeld uit een set bestanden bestaat, moet de implementatie eenvoudig een kwestie zijn van het kopiëren naar doelmachines. In de praktijk is de implementatie veel ingewikkelder. Dit heeft meerdere oorzaken. Deze vallen in twee brede categorieën: Y
Milieuproblemen De eerste categorie heeft in wezen te maken met correctheid. Software kan allerlei eisen stellen aan de omgeving waarin het draait: dat bepaalde andere softwarecomponenten op het systeem aanwezig zijn, dat bepaalde configuratiebestanden bestaan, dat er bepaalde wijzigingen zijn aangebracht in het Windows-register, enzovoort. Als aan een van deze omgevingskenmerken niet wordt voldaan, bestaat de kans dat de software niet op dezelfde manier functioneert als op de ontwikkelmachine. Enkele specifieke vragen zijn als volgt:
Een softwarecomponent is bijna nooit autonoom; het vertrouwt eerder op andere componenten om wat werk namens hem te doen. Dit zijn je afhankelijkheden. Voor een correcte implementatie is het noodzakelijk dat alle afhankelijkheden in kaart worden gebracht. Deze identificatie is echter vrij moeilijk, omdat het vaak moeilijk is om te testen of de specificatie van de afhankelijkheid volledig is. Immers, als we vergeten een afhankelijkheid op te geven, ontdekken we dat feit niet als de machine waarop we testen de afhankelijkheid al heeft geïnstalleerd. Afhankelijkheden zijn niet alleen een runtime-probleem. Om in de eerste plaats een component te bouwen, hebben we bepaalde afhankelijkheden nodig (zoals compilers), en deze hoeven niet hetzelfde te zijn als runtime-afhankelijkheden, hoewel er enige overlap kan zijn. Over het algemeen is het implementeren van afhankelijkheden tijdens het compileren geen probleem voor de eindgebruiker, maar het kan in brongebaseerde implementatiescenario’s zijn; dat wil zeggen, wanneer een component in bronvorm wordt geïmplementeerd. Dit is gebruikelijk in de open source wereld. De afhankelijkheden moeten ook compatibel zijn met wat de verwijzende component verwacht. Over het algemeen zullen niet alle versies van een component werken. Dit is zelfs het geval in de aanwezigheid van type-gecontroleerde interfaces, aangezien interfaces nooit een volledige specificatie geven van het waarneembare gedrag van een component.
Bovendien vertonen componenten vaak variabiliteit in de bouwtijd, wat betekent dat ze kunnen worden gebouwd met of zonder bepaalde optionele functies, of met andere parameters die tijdens de bouw zijn geselecteerd. Erger nog, het onderdeel kan afhankelijk zijn van een specifieke compiler of specifieke compileropties die worden gebruikt voor zijn afhankelijkheden (bijvoorbeeld voor ondersteuning van Application Binary Interface (ABI).
Zelfs als alle vereiste afhankelijkheden aanwezig zijn, moet onze component ze nog vinden om daadwerkelijk een bepaalde samenstelling van componenten vast te stellen. Dit is vaak een behoorlijk arbeidsintensief onderdeel van het implementatieproces. Voorbeelden zijn het instellen van het dynamische linker-zoekpad op Unix-systemen of CLASSPATH in de Java-omgeving. Componenten kunnen afhankelijk zijn van niet-softwareartefacten, zoals configuratiebestanden, gebruikersaccounts, enzovoort. Een component kan bijvoorbeeld een status hebben in een database die moet worden geïnitialiseerd voordat deze voor het eerst wordt gebruikt. Onderdelen kunnen bepaalde hardwarefuncties vereisen, zoals een specifiek type processor of videokaart. Deze vallen een beetje buiten het bestek van de software-implementatie, omdat we hoogstens op dergelijke eigenschappen kunnen controleren, ze niet opmerken als ze ontbreken. Ten slotte kan de implementatie een gedistribueerd probleem zijn. Een component kan afhankelijk zijn van andere componenten die op externe machines of als afzonderlijke processen op dezelfde machine worden uitgevoerd. Een typische webservice met meerdere lagen bestaat bijvoorbeeld uit een HTTP-server, een server die de bedrijfslogica implementeert en een databaseserver, die mogelijk allemaal op verschillende machines draait.
We hebben dus twee problemen bij de implementatie: we moeten vaststellen wat de vereisten van onze component zijn in de omgeving, en we moeten die vereisten op de een of andere manier realiseren in de doelomgeving. De realisatie kan bestaan uit het installeren van afhankelijkheden, het aanmaken of wijzigen van configuratiebestanden, het starten van remote processen, etc.
