De oplossing vormgeven: Het datamodel converteren naar technisch ontwerp

“De beste vertaling is niet die het meest op het origineel lijkt, maar die er het meeste van afwijkt”
                                                                                                - G. Bradford

De grootste kloof ligt tussen ontwerpers en uitvoerders als het gaat om de uitwisseling van informatie. Niet verwonderlijk, ontwerpers kijken met adelaarsogen naar hetzelfde object, waar uitvoerders de bevelen uitvoeren als hardwerkende mieren. Het mooie aan technologie is dat het werkt als een horloge; kleine radertjes en tandwieltjes werken nauw tezamen om precisie af te leveren. Dit is ook meteen het zwakke punt: bij ‘miscommunicatie’ loopt het wijzertje zo de verkeerde kant op.

Data modellen zijn de vrachtschepen van informatie binnen alle programmatuur; deze eigenschap betekent dat hun ontwerp afhangt van hetgeen wat ze vervoeren. Eenmaal vol, is vol. In het beginstadium is verandering nog niet een groot probleem, maar naarmate de complexiteit vordert kan het succes van een oplossing slagen of falen vanwege een niet-begrepen model.

Een technisch ontwerper zal het conceptueel model ‘vertalen’ naar technische elementen. Naast de keuze van ontwikkelingsstrategieën (taal, omgeving, etc), zal in de eerste plaats een prototype gebouwd worden. Ter illustratie nemen we het voorbeeld uit een voorgaand artikel () naast zo’n prototype:

Concept                                                            Prototype

Factuur (model)	Object Factuur
* id * datum factuur * factuurnummer * artikelregels (collectie)           * artikelregel (aantal, omschrijving,               prijs) * totaal bedrag * btw tarief * status * lengte betalingstermijn * debiteur id	id (integer) factuurDatum (data) factuurNummer (string) Array artikelRegels (Array) factuurTotaal (float) factuurBtw (float) factuurBetalingstermijn (integer) factuurStatusBetaling (boolean) debiteurId (integer)

Mocht het prototype duizelingwekkend overkomen, lees dan eerst de artiekelen-serie ‘Programma’s begrijpen’. (link)

De artikel regel is in het prototype ‘weggelaten’; in technisch perspectief is ze een eigen object, die per element in de lijst ‘artikelRegels’ geplaatst worden. Daarnaast heeft iedere variabele een conventie toegepast gekregen, omdat ze volgens technische regels geen spaties mogen houden. Ook heeft ieder element een primitief datatype toegewezen gekregen. Valuta waarden werken met cijfers achter de komma, vandaar dat ze als ‘floating point’ zijn gekozen. Ondanks dat het element factuurNummer klinkt als een getal, kunnen ze letters en tekens bevatten; ze hebben geen rekenkundige waarde, maar dienen als referentie.

Vrijwel iedere ervaren programmeur zou het technisch concept in pseudo-code zoals hier is aangegeven foutloos vertalen naar de programmeertaal van hun keuze. Door deze ‘vertaling’ zelf te kunnen, voorkom je onverwachte resultaten. Toets echter het technisch concept altijd met een programmeur, in de ICT geldt het niet dat de bijl een timmerman vervangt.

Naast fouten voorkomen is de kennis van technische concepten snappen uitermate waardevol in de ‘grote’ industrietakken. Grote bedrijven hebben duurdere speeltjes; integratie software of BPM-systemen zijn er alledaags en vereisen bijna geen ‘code’ om data modellen te simuleren. Echter blijft het principe gelijk; de toetsing wordt gedaan door het platform, maar verwacht de voorkennis over datatypes.

Zoals in het voorbeeld wordt voorgedragen, is het niet nodig in de techniek om het model super complex te maken. Een verzameling van informatie is en blijft een verzameling; de structuur binnen deze verzameling is gewoon een ander object. Het enige waar rekening mee gehouden hoeft te worden is de relatie met de factuur, dat met een enkele variabele opgelost kan worden (factuurId).

Houd altijd een database als opslagplaats in gedachten wanneer je datastructuren en modellen ontwerpt voor industriële oplossingen.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Technisch ontwerp

De oplossing vormgeven: Data structuren ontdekken in de informatiebron

“De weg is lang tussen het plan en de voltooiing ervan”
                                                                        - Molière

Informatie komt altijd voort uit een bron. Uitwisseling van gegevens gebeurd op allerlei manieren: mondeling, schriftelijk en digitaal. De inhoud van de uitgewisselde informatie is dan de gegevensbron geworden. Oplossingen hebben deze informatie nodig; ze zijn afhankelijk van data structuren om gegevens optimaal uit te wisselen. Een data structuur is een ontworpen model aan de hand van een specifieke gegevensbron. Maar hoe ontwerp je nou zo’n model.

Als voorbeeld nemen we een alledaagse informatiebron welke te vinden is in iedere industriële onderneming: de ‘factuur’. Facturen zijn openstaande rekeningen van de klanten van het bedrijf; zij zijn door de belastingdienst als een plicht gesteld en een belangrijk onderdeel van de boekhouding.

Als we de voorbeeld factuur analyseren, zijn er veel gegevens zichtbaar die ons direct en voor 90% feitelijke informatie geven:

1)    de ‘debiteurgegevens’, oftewel de klantgegevens

2)    een serie van producten / diensten die worden afgenomen

3)    het ‘unieke’ nummer van de factuur ter identificatie

4)    de datum van verzending

5)    het te vorderen belastingtarief

6)    de betalingstermijn van de factuur

7)    de bedrijfsgegevens, inclusief KvK-, BTW- en bankrekeningnummer

8)    het totaal verschuldigd bedrag van de klant aan het bedrijf.

Ook vinden we informatie in de informatie; producten / diensten per regel worden verdeeld in 3 segmenten (aantal, omschrijving en prijs) en zowel de debiteur- als bedrijfsgegevens zijn een ‘verzameling’.
Niet-feitelijke informatie is de betalingstermijn; het is een indicator dat op deze informatie ‘actie’ ondernomen moet worden, namelijk de betaling. Dit betekent dat een factuur in ieder geval twee ‘stadia’ kent: betaald of onbetaald. Wanneer een bedrijf informatie zal opvragen over de factuur zal de ‘status’ van de betaling meestal het eerste motief zijn; zonder betaling is er geen winst geboekt.

Het totaalbedrag is een ‘berekende’ waarde. Dit wil zeggen dat de waarde is opgebouwd uit een formule (dit geldt overigens ook voor de BTW) die wordt berekend over een verzameling van andere waarden. Het factuurnummer zal ook een berekende waarde zijn, vanwege het feit dat dit gegeven uniek moet zijn. Sommige facturen gebruiken zelfs hele speciale formules om het nummer extra eigenschappen te geven, zoals voor- of achtervoegsels.

Als we de factuur omzetten naar een model, ontwerpen we deze schematisch als volgt:

Factuur (model)
* id (uniek identificatie nummer als gegevensobject in potentiële database)
* datum factuur (facturen worden meestal eerst gesorteerd op datum)
* factuurnummer (identificatie) óf formule: Factuurnummer = ‘B’+lange datum+id
* debiteur id (collectie uit debiteuren tabel)
* artikelregels (collectie van artikelregel)
                        - artikelregel (aantal, omschrijving, prijs)
* btw tarief (keuze uit 0%, 6%, 19%)
* totaal bedrag (formule: som van iedere prijs van elke artikelregel in artikelregels + BTW)
* status
* lengte betalingstermijn

De informatie van het bedrijf hoeft niet in het datamodel; er is sprake van een enkel bedrijf en zijn ‘statische’ gegevens, ze veranderen nooit (of heel zelden). Daarnaast zitten ze meestal vast aan het briefpapier. Hoewel dit model al rekening houdt met techniek, is het nog géén technisch model; echter is met dit model het een peuleschil voor een techneut om deze te vertalen naar een implementatiemodel.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Informatiebron