"Hoe kan het concept van abstractie in software engineering zo moeilijk te begrijpen en toe te passen zijn?"
Ik heb een softwareontwikkelingsteam ondersteund dat hard werkt om hun engineeringpraktijken naar de21e eeuw te brengen. Hun uitdaging is om zeer complexe software van de volgende generatie te ontwikkelen. Daartoe introduceer ik hen in een aantal vrij standaard software engineering concepten zoals abstractie, decompositie, compositionaliteit, componenten en interfaces, enz. Sommige leden van het team pikken deze concepten op als eenden in het water. Maar voor velen is het kwartje nog niet gevallen.
Als eenvoudige inleiding tot de basisideeën gebruikte ik de analogie van een gitaarvoetpedaal - waarvan ik er toevallig een paar naast mijn bureau heb liggen. Een gitaarvoetpedaal heeft configuratieparameters (de knoppen op het pedaal), toestandsgedrag (aan/uit-functie), invoergegevens (signaal van de vorige trap), uitvoergegevens (verwerkt signaal) en foutmelding (fout-LED). Het mooie van de gitaarpedaal-analogie is dat pedalen, in principe tenminste, een gemeenschappelijke interface hebben en dat ze meestal in serie worden samengesteld, waarbij de uitgang van het ene pedaal in de ingang van het volgende wordt gestoken.
We hebben dus een eenvoudig voorbeeld van een compositiesysteem. Verder, met een beetje abstractie toegevoegd, worden de pedalen geacht een gemeenschappelijke interface te hebben (input, output, configuratie, aan/uit, fout), en men kan uitleggen dat de interface van een component ontkoppeld is van zijn functie - met andere woorden, polymorfisme in actie. Twee pedalen met dezelfde interface kunnen bijvoorbeeld verschillende signaaltransformaties uitvoeren, zoals reverb, delay, fuzz, etc.
Voor deze mensen is "abstractie" een ander woord voor vaagheid en is "decompositie" iets dat gebeurt in een aflevering van CSI. Voor sommigen is vaagheid een noodzakelijke comfortdeken die hen in staat stelt om het denken over lastige problemen uit te stellen totdat ze het probleem van iemand anders zijn, bijvoorbeeld van de programmeur. Voor anderen is abstractie een anathema en willen ze onmiddellijk zien hoe bijvoorbeeld de schakelaar van het voetpedaal verbonden is met de aan/uit-functie van de software. Het gevolg is verwarring en misverstanden over welke mate van detail precies gepast is op elk niveau van decompositie van een softwaresysteem. Duidelijkheid hierover is noodzakelijk als het team met succes complexe software wil ontwikkelen.
Naar mijn mening gaat abstractie over het definiëren van een geschikt detailniveau op elk niveau van decompositie door gebruik te maken van inkapseling en volledig gespecificeerde interfaces. Of, om een groot man te citeren, op elk niveau van decompositie: "Alles moet zo eenvoudig mogelijk worden gemaakt, maar niet eenvoudiger". Dit is toch niet zo moeilijk te begrijpen?
Meer lezen
Een uitbraak van overmoed
Software is het medium van de digitalisering. Als je software niet begrijpt, heb je geen hoop om met een fatsoenlijke digitaliseringsstrategie te komen.
Software is geen onderdeel van een voertuig
OEM's in de auto-industrie hebben zich ontwikkeld tot zeer efficiënte organisaties voor uitbesteding en systeemintegratie. Alles wat te maken heeft met een voertuig wordt gezien als een component, inclusief software. Het hele automotive system engineering proces behandelt software als een onderdeel van een voertuig. Hierdoor denken ze niet na over de software als een heel systeem.
Abstractie versus vaagheid in software-engineering
Sommige software engineering teams hebben moeite met het begrijpen van het verschil tussen abstractie en vaagheid. Aangezien het ene essentieel is voor de architectuur en het ontwerp van complexe systemen en het andere leidt tot technische schuld en slechte softwarekwaliteit, moeten softwareteams het verschil begrijpen.