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

Programma's Begrijpen: Data structuren verder uitgelegd

“Op ieder potje, past een datamodel en kan net zoveel bevatten.”
                                                                                                - Sam Rain

Data structuren zijn abstracte vormen voor informatie; feitelijk zijn ze niet meer dan een tactisch ontworpen concept voor geheugenruimte, welke opgebouwd zijn uit primitieve datatypes. Het voordeel van deze flexibiliteit is dat ze zowel simpel als complex kunnen zijn en informatie als een verzameling beschikbaar maken. Naast een handig mechanisme om informatie te verwerken, zijn ze ook van cruciaal belang voor uitwisseling; diverse structuren kunnen een standaard worden voor diverse programma’s of systemen – beter bekend als een formaat – denk maar eens aan foto’s of tekstdocumenten.

Wanneer gegevens uitgewisseld worden met andere programma’s, moet de informatie aan iedere zijde gelijk zijn; de structuur wordt universeel en uitwisselbaar (‘compatibiliteit’). Deze structuur is dan een ontwerp op zichzelf en wordt daarom een ‘data model’ genoemd. Technische artikelen die data structuren beschrijven slaan vaak het toepasbare gebied over en leggen het vergrootglas op de mechaniek terwijl juist data structuren vaak de eerste stap zijn, de meest cruciale gegeven zullen bevatten en het falen of slagen van een applicatie bepalen. Een overvloed aan informatie ‘kost’ geheugen, vereist meer tijd om te verwerken en zit verweven in grote delen van de kern. Te weinig informatie betekend een aantal technische ‘bypassen’ chirurgie om informatie toch volledig te maken.

Data modellen voor de industrie moeten dus aan een aantal voorwaarden voldoen om ‘robuust’ te zijn als oplossing:

·      een model moet een ‘uniek’ veld bevatten voor identificatie

·      een model moet ‘meta-data’ ondersteunen

·      een model moet zo compact mogelijk zijn

Data modellen hebben identificatie nodig om ‘relationeel’ behandeld te kunnen worden; ze fungeren als ‘primaire sleutel’ (x ‘buitenlandse’ sleutels zijn optioneel) en de industrie werkt zelden met enkele gegevens. Het is vrij normaal om met meer dan 10.000 unieke gegevens tegelijk te werken voor ‘volwassen’ oplossingen. Meta-data is de informatie over de informatie: vaak zal men een aantal waarden nodig hebben, zoals metingen of de status per unieke verzameling. De redenen voor compacte modellen zijn snelheid en efficiëntie; een bepakte verzameling ‘kost’ niet alleen tijd en geheugen, maar verkwist het ook. Wanneer een data model tot ‘leven’ wordt geroepen, neemt het geheugen in beslag, om gevuld te worden met informatie. De componenten in een applicatie werken met procedures, die ‘argumenten’ vereisen. Argumenten zijn nieuwe variabelen, dus wanneer een argument het type is van het data model zullen de meeste programmeertalen de opdracht geven om alle gegevens te ‘klonen’, terwijl het om een ‘pietluttige’ verwerking kan gaan.

Een data structuur kan uit meerdere modellen bestaan, zodat deze efficiënt verwerkt kan worden. Echter moeten de verwijzingen bij zo’n verwerking dan ook precies kloppen: dit wordt ‘mapping’ genoemd (vrij vertaald: ‘in kaart gebracht’). Wanneer er meer informatie wordt geplaatst in een structuur dan bedoeld is, vind er een ‘overflow’ (overstroming) plaats en valt de applicatie in een foutafhandeling, of erger: stopt ermee. Bij te weinig informatie blijven delen van de verzameling gegevens ongedefinieerd, waardoor er onverwachte resultaten te weeg kunnen komen.

Een data structuur is een blauwdruk; het is op zichzelf alleen een definitie. Wanneer de definitie bepaald is, kan de structuur gebruikt worden zoals ieder ander datatype. Met het label dat eraan gegeven is maakt de computer een nieuw object aan in het geheugen. Dit proces heet instantiëren en het object heet daarom een ‘instantie’.

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

©SamRain
Data structuren