“De meeste tekenaars beginnen met een ruwe schets”
- Sam Rain
Programma’s bestaan uit componenten die invloed uitoefenen op informatie met behulp van operatoren, condities en lussen. Hoe deze invloeden worden uitgewerkt in detail wordt bepaald door de ‘omgeving’; de beschikbare programmeertaal, de informatievoorziening en de distributie en uitwisseling naar andere systemen. Voordat de uitwerking kan beginnen is er een oplossing nodig die de verwerking in grote lijnen kan beargumenteren; een ‘ruwe’ schets van de mechaniek zonder vastgekoppeld te zijn aan de omgevingslimieten: de pseudo-code.
Pseudo-code is niet uitvoerbaar; het is een abstracte methode om de oplossing in theorie te maken. Gelukkig hoeft dit niet zoals de grote nauwkeurige meesters als lange, complexe en onleesbare formules. Het doel van pseudo-code is dat het begrijpelijk is voor iedereen die de basis begrijpt van informatieverwerking.
Een praktisch voorbeeld: Karel wilt zijn telefoontjes registreren en koppelen aan zijn debiteurenbestand. Als hij een debiteur aan de telefoon krijgt, wilt hij de geschiedenis op kunnen vragen aan de hand van de naam, postcode of klantnummer van de debiteur.
Eerst moeten de informatiebronnen in kaart gebracht worden. Debiteuren hebben contactgegevens, ieder telefoontje is een nieuwe registratie en alle registraties horen bij een debiteur.
Vervolgens kijken we naar de structuur voor de informatie. Elke registratie heeft een datum- en tijdsnotering nodig, tezamen met een omschrijving. De debiteurgegevens hebben altijd een uniek klantnummer nodig.
Pas dan kijken we naar de mechaniek van de oplossing. De informatie moet opgevraagd, aangepast, opgeslagen of verwijderd kunnen worden. Daarnaast moet er een zoekmechanisme zijn die juiste gegevens afbeeld. In programma’s zijn er twee delen waar de mechaniek zich afspeelt; de gebruikerskant en de kern. Soms hebben programma’s geen gebruikers nodig, ze voeren zonder vertraging of tussenkomst van een gebruiker de taken uit en heten een ‘service’ (achtergrondproces). Een programma dat de gebruiker centraal stelt is wel interactief en wordt een applicatie genoemd. In dit voorbeeld gaat het om een applicatie, er zul dus rekening gehouden worden met de gebruikerskant.
Voor de gebruiker zijn er 3 ‘schermen’ nodig. Schermen zijn in dit geval zelfstandige formulieren welke informatie weergeven. Het eerste scherm gaat om de registratie, het tweede is een zoekscherm en het derde scherm beheerd de debiteurgegevens. Het ontwerp van ieder scherm valt al onder pseudo code:
De ‘kern’ van een applicatie handelt de functionaliteit af van alle schermen. Ongeacht de invulling qua taal of omgeving kan het volgende al worden ‘geschetst’ voor de kern:
Procedure Nieuw-knop (vereist debiteurnummer, omschrijving):
· nieuwe registratie maken met huidige tijd en datum
· vereiste debiteurnummer, omschrijving aan registratie toevoegen
· gegevens opslaan van registratie
· velden leegmaken
· eventuele bevestiging dat de gegevens zijn opgeslagen.
Voor iedere functionaliteit zal er dus een ‘eigen’ procedure moeten komen. Soms kunnen bepaalde procedures opnieuw gebruikt worden binnen een applicatie, bijvoorbeeld om een structuur beschikbaar te maken. Computers denken overigens nooit verder dan hun processor lang is, gegevens in een structuur moeten heel expliciet bewaard worden of zelf ‘teruggegeven’ worden. Echter heeft pseudo code het voordeel dat een aantal puntjes op de i gemist mogen worden.
Aan de hand van ‘de wensen’ om de applicatie te maken, laat de pseudocode duidelijk zien dat het hier niet gaat om een hele complexe applicatie. Het gaat met name om het beheer van gegevens en het maken van relaties. Een voor de hand liggende keuze om de applicatie te bouwen is met behulp van een database technologie. Deze ondersteunen simpele formulieren en hebben een ingebouwde programmeertaal om de procedures tot leven te wekken.
De reden waarom een database technologie vooral gekozen wordt ligt aan de noodzaak om informatie te koppelen, de gegevens van de debiteur horen bij iedere registratie, ze hebben een ‘relatie’. Deze relatie werkt technisch gezien als een ‘sleutel’. Met behulp van een unieke waarde in beide gegevensbronnen kan een database de relatie vinden. Er is wel een valkuil: soms kan een debiteurnummer omstreden zijn als sleutel, en computers zijn zeer strenge wezens. Gelukkig mag je als ontwerper de vrije keuze maken; de relatie is alleen interessant voor de computer. Veel ontwerpers voegen daarom een relatie toe door een handig truukje: ze voegen ‘informatie’ toe dat iets verteld over de informatie, beter bekend als ‘meta-data’. Omdat het gaat om unieke nummering wordt in de industrie voor sleutels de afkorting ‘ID’ gebruikt, welke staat voor Identifier, vrij vertaald als identificatie. Een ‘gegevensbron’, dus een tabel in de database, gebruikt de ‘ID’ om iedere verzameling van gegevens te identificeren. Deze ‘primaire sleutel’ legt dus niet automagisch een relatie vast. Vaak zijn er gegevens die als ‘ouder’-informatie dienst doen, zoals in het geval van het voorbeeld zijn dit de debiteuren. De informatie die een relatie moeten hebben met deze gegevens hebben dus de informatie nodig van de ‘ouder’-bron. Echter zijn deze ook uniek, ze hebben ook een ‘primaire sleutel’ nodig voor het geval ze dienst moeten doen als ‘ouder’-bron. Dezelfde truuk wordt daarom toegepast; de structuur krijgt extra informatie: de ‘foreign key’ (vrij vertaald: de buitenlandse sleutel). Deze sleutel is de ‘primaire sleutel’ van de relatie; dankzij deze sleutel kan een computer de relatie vinden. Even ter illustratie:
Tabel: debiteuren
ID | KLANT | DEBITEURNR |
11 | Jaap | 200117 |
12 | Mien | 200118 |
13 | Hans | 201302 |
Tabel: registraties
ID | DATUM | OMSCHRIJVING | DEBITEUR-ID |
1 | 22-11 | Klacht levering | 12 (Relatie met Mien) |
2 | 23-11 | Bevestiging | 11 (Relatie met Jaap) |
3 | 23-11 | Order Ontvangen | 11 |
De ‘relaties’ in kaart brengen vallen ook onder pseudo-code; vaak werkt een database specialist verbeteringen uit om de snelheid te bevorderen of zal de structuur ‘optimaliseren’. Echter biedt de pseudocode de mogelijkheid om gegevensstructuren vorm te geven: niet alle gegevens zijn nodig voor de formulieren. De gegevens horen dus in een structuur thuis; het ‘data-model’ bevat de gietvorm van hoe deze beschikbaar moeten zijn:
Data-Model ‘Registratie’ |
- DATUM - KLANT - DEBITEURNR - OMSCHRIJVING |
De pseudocode brengt de primaire mechaniek, structuren en formulieren als ontwerp. Voordat er een projectplan gemaakt wordt kan de complexiteit voorzien worden en een goede schatting wat betreft de tijd die het gaat kosten om daadwerkelijk de applicatie te bouwen. Daarnaast helpt de ‘pseudo-code’ om een oplossing preventief te testen op ‘veiligheidsfouten’, toekomstige wensen en schetst het een duidelijk beeld voor de ‘uitvoerders’ van de applicatie bouw.
Meer lezen over Informatie Technologie? Klik
hier voor de inhoudsopgave voor alle artikelen!
Stel,
we nemen een simpel ontwerp voor een model die ontworpen moet worden voor
artikelen. We noemen daarom dit ontwerp het 'Artikel Model'. Het 'Artikel
Model' moet artikelen kunnen opvragen, toevoegen, aanpassen, verwijderen. Omdat
het Artikel Model werkt met een database, is het handig om te weten hoe de
artikelen in de database worden opgeslagen. Databases werken met CRUD
bewerkingen — dit zijn de Create, Read, Update en Delete opdrachten waarmee
databases tabellen beheren. Echter zijn deze vanzelfsprekend voor modellen. In
het ontwerp is het belangrijk om een duidelijk onderscheid te maken van de
types informatie. Een model ontwerpen in de diepte vereist dus de nodige
ervaring met databases en datatypes. 
