“De beste vertaling is niet die het meest op het origineel lijkt, maar die er het meeste van afwijkt”
- G. Bradford
- 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!
Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!
©SamRain
Technisch ontwerp
Technisch ontwerp
Geen opmerkingen:
Een reactie posten