MVC Workshop: Een controller ontwerpen

"Wie een MVC controller ontwerpt, begint door simpel te denken."
                                                                                                  — Sam Rain

Wie een software oplossing wilt ontwerpen, zal vaak de voorkeur hebben aan de MVC strategie: Model-View-Controller ontwerpen zijn populair omdat ze structuur geven aan een applicatie. De 'C' uit MVC staat voor controller — het deel van een oplossing dat verantwoordelijk is voor de communicatie en de verwerking van informatie van en naar de applicatie. In dit artikel leggen we de loep over het ontwerpen van een 'controller'.

Applicaties hebben meerdere models, views en dus ook controllers. Iedere 'feature' werkt op zijn eigen manier met de informatie want de distributie en verwerking van informatie is waar het immers om draait. Een controller zoals deze bedoeld is in MVC dient als de besturing van informatie, maar vooral om de 'routing' — wie heeft het nodig, wat is er nodig en hoe dient het te worden geleverd?

Een 'controller' is daarom eigenlijk het beste te omschrijven als een centrale punt - het is de 'interface' en werkt als een soort 'lijm' tussen de models en views; de controller werkt met de menselijke koppelingen (views) en de gegevensbronnen (models). Wie een controller ontwerpt zal dus moeten beginnen met een inventarisatie van de volgende punten:

• Voor welke informatie distributie dient de controller?
• Welke informatie zullen de views nodig hebben?
• Welke informatie is beschikbaar vanuit de modellen?
• Hoe dient de informatie te worden gecirculeerd?

Stel, we nemen een simpel ontwerp voor een controller die ontworpen moet worden voor het invoeren van artikelen. We noemen daarom dit ontwerp de 'Artikelen Controller'. De 'Artikelen Controller' moet artikelen kunnen opvragen, toevoegen, aanpassen, verwijderen. Omdat de Artikelen Controller werkt voor een website, is het handig om de artikelen in uniforme gegevens te verspreiden (zoals XML). We hebben eigenlijk de basis van het controllerontwerp nu al gelegd. Wanneer we de controller het verzoek doen voor een artikel ‘opvragen', dient de controller dit verzoek te honoreren door deze in XML formaat terug te geven. Wanneer we de controller vragen om het artikel te verwijderen, dan moet het artikel verwijderd worden waar deze ook opgeslagen zou mogen zijn.

Maar hoe weet een controller dan welk artikel verwijderd moet worden? Hier gaat het ontwerp vervolgens verder — wat is het ontwerp van een artikel? Heeft een artikel een eigen nummer? Heeft een artikel een unieke naam? Met parameters kunnen het ontwerp uitbreiden. Laten we op dit moment uitgaan dat ieder artikel een uniek nummer heeft. Dan wordt het ontwerp uitgebreid met de parameter 'id' (staat voor: identificatie). Er is geen limiet aan de hoeveelheid parameters die nodig zijn. Zo zal een zoekfunctie binnen een view artikelen willen opvragen op naam of inhoud.

Natuurlijk is dit verreweg een voorbeeld van dat gelijk staat binnen de industrie. Echter is het de bedoeling van een ontwerp dat het vooral duidelijk is wat er verwacht wordt van de handelingen die de controller moet uitvoeren.

©SamRain
Controller

MVC Workshop: Een model ontwerpen

"Wie een MVC model ontwerpt, denkt aan informatiestromen."
                                                                                      — Sam Rain

Wie een software oplossing wilt ontwerpen, zal vaak de voorkeur hebben aan de MVC strategie: Model-View-Controller ontwerpen zijn populair omdat ze structuur geven aan een applicatie. De 'M’ uit MVC staat voor model — het deel van een oplossing dat verantwoordelijk is als de abstracte laag tussen de databanken van informatie en de applicatie. In dit artikel leggen we de loep over het ontwerpen van een 'model'.

Applicaties hebben meerdere controllers, views en dus ook models. Informatie is losgekoppeld in industriële toepassingen — ze is beschikbaar via de 'database'. Echter is de ene database de andere niet en is databasespecialisme een expertise die zeer afhankelijk is van de omgeving waarin informatie wordt opgeslagen. Een model hoeft niet perse een reflectie te zijn van de tabellen in de database — ze wordt ontworpen voor de informatie die de applicatie nodig heeft.

Wanneer een controller het verzoek doet aan een model om een artikel op te vragen, voert het model de nodige werk uit dat speciaal gericht is aan de database. Daarom is een model ook een abstractie — het transformeert gegevens van en naar de database, zodat de controller niet hoeft te worden aangepast wanneer er 'onder de motorkap' veranderingen plaatsvinden in de database.

Een 'model' is daarom eigenlijk het beste te omschrijven als een mal — het is de 'gegevensstructuur' die werkt als een container voor controllers; een model werkt met de technische onderdelen van een applicatie. Wie een model ontwerpt zal dus moeten beginnen met een inventarisatie van de volgende punten:

• Welke informatie is aanwezig in de database?
• Welke informatie heeft de applicatie nodig?
• Zijn er speciale bewerkingen nodig voor de informatie gebruikt kan worden?
• Hoe dient de informatie te worden aangeleverd?

 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.

Natuurlijk is dit een voorbeeld wat niet gelijk staat aan de industrie. Echter is het de bedoeling van een ontwerp dat het vooral duidelijk is wat er qua informatie beschikbaar is dat een model moet 'aanleveren'.

©SamRain
Model Ontwerpen

Ontwerpen als vaardigheid: van hobbyist naar professional 4

“Vaak zijn ontwerpers als programmeurs; ze beginnen het liefst met een schone lei.”
                                                                                                            - Sam Rain

Cruciale vragen. Ze betekenen het slagen of falen van een goed ontwerp in de ICT. Een ‘solution architect’ is meer dan een paar blitse diagrammen maken – dat is één ding dat zeker is. Maar welke vragen moet de professional nu stellen om te slagen in zijn of haar ontwerp?

1.              Wat is de huidige situatie?
Vaak zijn ontwerpers als programmeurs – het liefst beginnen ze met een schone lei. Echter is een ontwerp nooit meteen een vervangende oplossing – tussen ‘oud’ en ‘nieuw’ vloeit er een migratieproces. Ook veranderen er vaak onverwachte wendingen: het budget kan ‘ineens’ krimpen, of de ‘tijd’ kan parten spelen. Een ontwerper kan niet zonder een verkenning van het landschap zoals ze is – die is er immers voor een reden.

2.              Wat is de gewenste situatie?
Een industrieel ontwerp draait om kostenbesparing, efficiëntie, productiviteit en inzicht. Een ontwerper kijkt naar het huidige landschap en toetst de onderdelen aan deze factoren. Waar kan er winst/verbetering behaald worden? Zijn er alternatieven? Wat is níet inzichtelijk? Hoeveel mensen werken aan deze activiteit en hoe lang doen ze erover? De slimme ontwerper begint met processen te simplificeren zodat het ‘grote plaatje’ overblijft.

3.              Wat mag er gebruikt worden?
Een ontwerper zal een voorkeur hebben aan een platform waar hij of zij gewend is mee te werken; maar soms verwacht de opdrachtgever dat het platform dat aanwezig is gebruikt zal worden. Weeg de voor- en nadelen af; een huis staat namelijk zo stevig als het land waar het zich op bevindt. Met  de juiste argumenten en meer baten dan kosten maakt de overstap aantrekkelijker.

4.              Wat moét er gebeuren?
Soms wilt een opdrachtgever niet iets vervangen wat naar behoren werkt, of is de investering nog niet ‘terugverdiend’. Dan is er nog de keuze voor integratie, maar het neemt nog niet weg dat de ontwerper dit ‘buitenaards wezen’ als niet bestaand mag beschouwen. Deze ‘legacy’ systemen worden vaak naar ‘achteren’ geduwd om veel te laat te ontdekken dat ze onderdeel zijn van kernactiviteiten. De ‘to do’ moet een integratieplan zijn; een ontwerp binnen een ontwerp.

5.              Wat zijn de ‘kritieke’ processen?
De kernactiviteiten draaien het bedrijf – deze moeten extra robuust zijn en voorzien zijn van rampenplannen (stroomuitval, falen infrastructuur, menselijke fouten). Niet alle processen zijn ‘kritiek’, maar kunnen wel een kettingreactie veroorzaken. Een goed ontwerp is robuust – en men kan veel leren van de huidige rampscenario’s!

6.              Wat zijn de voorkeuren en wensen?
Vaak wilt een opdrachtgever een oplossing voor huidige problematiek, maar ze hebben vaak ook een Utopiaanse droom. Kleine delen van zo’n droom maakt een ontwerp vaak een succes door de ‘gebruikerservaring’. Snufjes, toeters en bellen maken gebruikers enthousiast – gebruik ze dan ook. Behoud wel meer taart dan slagroom!

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

©SamRain
Prof

Ontwerpen als vaardigheid: Van hobbyist naar professional 3

“De sterke punten van platformen worden zelden goed belicht.”
                                                                                    - Sam Rain

Eén van de uitgemolken ‘oplossingen’ binnen de industriële software zijn de applicatie servers. Deze platformen bieden het fundament voor toepassingen waar de industriële ontwerper zijn of haar oplossingen geboren ziet worden. Platformen voor de industrie hebben een aantal aspecten waardoor zij zich onderscheiden van de overige platformen.

Systeemintegratie is een belangrijke mogelijkheid; het ‘landschap’ (de IT-infrastructuur én bedrijfsapplicaties) is vaak divers. Applicaties zijn van ‘nature’ niet gebouwd om samen te werken met andere toepassingen. Door de systemen te integreren binnen een platform wordt dit obstakel overwonnen. Een ontwerper moet dus het landschap van de huidige situatie kennen, zodat men weet welke applicaties ‘overbodig’ worden én welke moeten worden geïntegreerd.

Bedrijven zoeken inzicht uit cijfertjes – ‘Business Rules’ zijn speciale rekenregels die op meerdere niveaus kunnen worden toegepast. Ze zijn essentieel voor escalaties en monitoring, omdat ze exclusies en kaders kunnen bewerkstelligen. De ‘Business Rules’ werken als een vergiet voor gegevens – wat niet van toepassing is glijdt er doorheen en het residu is voor wat men voor ogen heeft. Een typische ‘Business Rule’ is bijvoorbeeld een levering die pas geactualiseerd wordt bij voldoende saldo. De BR kan dan als volgt worden ontworpen:

                        levering: saldo > productprijs
                                     ! melding (“onvoldoende saldo”)

De RDBMS is de database waar platformen voor de industrie op rusten. Een RDBMS is veelzijdiger dan een reguliere database; ze zijn ontworpen om vele bewerkingen uit te voeren, hebben de mogelijkheid om complexere taken uit te voeren (zoals transacties, stored procedures en een ‘eigen’ scripttaal) en zijn in staat om te ‘repliceren’. Verreweg de twee populairste zijn de Oracle Database en Microsoft SQL Server – en er zijn weinig industriële platformen die deze twee níet ondersteunen.

De formulieren zijn de ‘menselijke’ invoercomponenten. Binnen een industriële platform zijn alle gegevens van én bestemd voor mensen te vinden in formulieren. Het formulier is meer dan de digitale versie van het papieren broertje – ze doet dienst als navigatie, verbindt data aan de software en is zo efficiënt mogelijk opgebouwd. Daarom bieden platformen vaak een ontwerpomgeving voor deze formulieren, zodat ontwerpers naar hartenlust kunnen klikken en slepen.

Omdat platformen opereren binnen het hele landschap, hebben zij de beschikking over vele netwerkservices – verreweg de populairste zijn de ‘webservices’. Een webservice is in feite een losgekoppeld stuk mechaniek zonder een ‘menselijke’ interface – ze  is ook bedoelt voor programma’s! Door met behulp van een standaard opmaak (XML/JSON) wisselt een webservice supersnel gegevens uit. Een programma doet een verzoek (Request), waarop de webservice de nodige gegevens verzameld en teruggeeft (Reply). Webservices hebben geleid tot een revolutie in systeemintegratie – of beter gezegd revoluties – en zijn de investering qua tijd van iedere ontwerper meer dan waard.

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

©SamRain
Ontwerp

Ontwerpen als vaardigheid: Van hobbyist naar professional 2

"Vind alleen het wiel opnieuw uit, als deze vierkant is."
                                                                                     - Sam Rain

Het ontwerpen van industriële toepassingen vereist een paar vaardigheden, die een professional moet beheersen om te kunnen schetsen op de tekentafel. Zo kan een ontwerper simpelweg niet zonder schema's en diagrammen — het landschap van een oplossing moet ontworpen worden en de processen in kaart brengen zijn zonder schema's en diagrammen een bijna onmogelijke taak. Maar ook achtergrond kennis van een aantal concepten en strategieën zijn voor een ontwerper onmisbaar.

De database is een gegevensbron waar een ontwerper niet persé het fijne van hoeft te weten als specialisme, maar wel waar de industriële database (vaak een relationele variant) in uitblinkt. Termen als replicatie, transacties, `stored procedures', views en CRUD-bewerkingen (Create, Read, Update, Delete), mogen niet onbekend zijn voor de ontwerper. Naast de opbouw van een database zijn gebruikersrechten, indexen en sleutels voor een software ontwerper cruciaal. Een ontwerper die niets weet van databases in de industriële software-industrie zal zelden een oplossing kunnen ontwerpen zonder deze know-how.

Gegevenstransport over netwerken brengt de nodige kennis met zich mee — hoewel vele ontwerpers het concept encryptie (versleuteling) wel begrijpen, snappen ze zelden de toepassingsgebieden. Een ontwerper moet het verschil begrijpen tussen symmetrische en asymmetrische encryptie; met name wannéér en waaróm deze vormen gebruikt worden. Gegevens in industriële toepassingen hebben namelijk vaak gevoelige gegevens — zonder enige kennis van versleuteling is een oplossing bij voorbaat te beschouwen als onveilig.

Een ontwerper hoort begrippen als encapsulatie, object oriëntatie en overerving te begrijpen. Industriële software is incrementeel — vaak worden oplossingen uitgebreid met nieuwe mogelijkheden (features). Een ontwerper hoeft geen 'echte' programmeur te zijn, maar hoort minimaal een vorm van pseudo-code te kennen. Een oplossing dat niet vertaald kan worden naar technisch ontwerp, zal nooit het levenslicht zien — want inmiddels hebben bedrijven al decennia geleden ontdekt dat deze vertaling onderschatten hetzelfde betekent als het aanschaffen van Pandora's doos.

Veiligheid is een cruciaal onderwerp — een ontwerper die niet op de hoogte is van aanvalsmethodieken van hackers, kan een ontwerp daar ook niet tegen weren. Implementatie wordt vaak gedaan door techneuten die het grote plaatje niet zien, waardoor er grote gaten kunnen ontstaan in het hekwerk om de oplossing. Ontwerpers moeten begrijpen hoé toegangspunten omzeilt worden en met welk doel; zodoende kunnen zij de oplossing voorzien van de nodige bewaking of kennis inwinnen van veiligheidsexperts.

Bedrijfsprocessen worden vaak onderschat — en met name hoe deze precies werken. Informatie gaat in processen niet alleen in cycli — ze gaan soms parallel, splitsen zich of transformeren zich meerdere malen. Ook hebben ze vaak te maken met 'bottlenecks', waardoor een ontwerper bij zaken als routering, synchronisatie (en asynchrone taken!) of wachtrijen soms het wiel opnieuw probeert uit te vinden. Een bedrijfsoplossing is vaak complexer dan men in eerste instantie denkt, wat vaak leidt tot een 'dure grap' vanwege onderschatting.

Gebruik bestaande strategieën. Originaliteit is binnen de industriële software industrie niet altijd de juiste strategie — hoewel innovatie zeker gewaardeerd wordt, is een 'winning formula' eerder de regel dan de norm. Vind alleen het wiel opnieuw uit, wanneer het wiel vierkant is — de robuustheid van een ontwerp valt vaak over exotische ideeën, die achteraf vaak niet voldoen aan de verwachtingen.

Industriële toepassingen vragen veel kennis, maar dat hoeft niet altijd evenredig te zijn dat men ook deze vakgebieden moet beheersen als een specialist. Weten is zilver, begrijpen is goud.

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

©SamRain
Professional

Ontwerpen als vaardigheid: Van hobbyist naar professional 1

"Ontwerp als een architect die het huis van de toekomst maakt, zonder te dromen."       
                                                                                                                          - Sam Rain

Wie van zijn of haar hobby een baan wilt maken, heeft ervaring nodig. Het is vaak een lange lijdensweg welke gepaard gaat met vooral vallen en opstaan. Ook in de informatie technologie sector gaat dit op — een thuisnetwerkje beheren maakt nog geen beheerder en een programmaatje in elkaar flansen maakt zeker geen software architect in de wereld van industrie. Tegenwoordig is het hebben van meerdere disciplines binnen een vakgebied meer de regel dan de norm. Toch is een specialisme het talent onder de professionals — het onderscheid maakt dat men kan concurreren met andere gegadigden binnen een project.

In de industriële toepassingen is de simpliciteit ver te zoeken — er komt naast creativiteit ook nog eens de nodige verantwoordelijkheid bij kijken. Veiligheid, robuustheid, schaalbaarheid, flexibiliteit, beheren en inzicht zijn maar enkele aspecten die ieder project met zich meebrengen. Vergissen is menselijk, maar in de industrie een kostbare blunder — hoewel software vaak gepresenteerd wordt als het populair kinderspeelgoed van Deense origine, is het eerder te vergelijken als metselwerk met specie. Eenmaal uitgehard, wordt het bikken en vaak hardhandig vervangen door andere bakstenen.

Het proces vóór de tekentafel wordt vaak niet gezien door de beginnende professional. Denkwerk, kennis en de nodige methodologie lijken vaak ideaal totdat men een frontale botsing maakt tien processen verder op — die soms ook nog eens pas opgemerkt worden op een paar weken voor de 'deadline'. Het ontwerp lijkt als een kaartenhuis in elkaar te zakken en de paniek springt erin. Wie oplossingen ontwerpt zal de processen moeten begrijpen, de industrie van toepassing moeten begrijpen en het inzicht hebben dat 'business logic', ondanks de modulaire opbouw, zo flexibel is als een loden kubieke meter.

Veiligheid is een onderschatting van vele ontwerpers — dat is voor de 'beheerder' en het onderliggend systeem. Inderdaad zijn deze de eerste linie, maar het is de toepassing waarin de vele gaten ontdekt worden en voor een risico zorgen. Authenticiteit van gebruikers, maar ook van het systeem zelf, dienen in het ontwerp te worden opgenomen. De toegangspunten tot het systeem moeten voor de ontwerper duidelijk zijn, evenals de cruciale koppelingen naar externe gegevensbronnen.

Robuustheid in de industriële software gaat verreweg om hoe de oplossing 'omgaat' met fouten en problemen. Robuuste oplossingen moeten dus tegen een stootje kunnen — het zijn vaak ontwerpers die weinig ervaring hebben met de 'knulligheid' van de menselijke gebruikers waardoor de verwachtingen bij de levering ernstig tegenvallen. Het 'testen' gaat daarom vaak in de vorm van 'happy paths', welke de meest ideale manieren van gebruik binnen de oplossing zijn. Zonder een aantal doemscenario's, worden fouten vaak te laat ontdekt - en nog vaker in situaties waar dan geen reddingsplan aanwezig is.

Schaalbaarheid wordt vaak verward met een modulaire strategie. Schalen betekent dat men zowel kan uitbreiden als inperken. Een ontwerp dat niet kan schalen limiteert zichzelf op de bekende 'levenscyclus' van de oplossing. Schaalbare ontwerpen zijn niet moeilijk — het is een kwestie van gebruikers te anonimiseren en onder te verdelen in rollen. Daarnaast bestaat 'data' enkel in persistente vorm binnen een gegevensbron en zijn toegangspunten en externe koppelingen configureerbaar — zodat er meerdere oplossingen co-existent ingezet kunnen worden.

Beheren van de oplossing is anders dan het 'onderhouden' ervan. Ten alle tijde moet een industriële toepassing toegang verlenen aan één of meer beheerders, zodat er handelingen verricht kunnen worden zoals het tijdelijk stoppen of terugdraaien van lopende processen. Omdat de industrie in grote hoeveelheid cruciale gegevens transporteert, kan een enkele fout grote impact hebben op de resultaten van zelfs meerdere processen. Een ontwerp dat geen rekening houdt met beheer van de oplossing is een onpraktisch ontwerp — immers heeft ook een auto een stuur, een gaspedaal en een rem nodig.

Inzicht creëren is vaak een onderschatting — waar beheerders voldoende hebben aan overzicht, zijn rapportages een "must-have" in industriële oplossingen. Uiteindelijk gaat het om resultaten en deze cruciale informatie dient terug te halen zijn, zonder dat daar een trukendoos voor opengemaakt hoeft te worden. Een ontwerper die niet beseft wat managers willen weten, kan ook geen degelijke oplossing ontwerpen met mogelijkheden tot inzicht. Rapportages moeten dus altijd opgevraagd kunnen worden en 'vanzelf gegeneerd kunnen.

Industriële toepassingen ontwerpen vraagt meer dan een probleemstelling op te lossen — het is een oplossing ontwerpen, rekeninghoudend met risico's en uitbreidingsplannen rondom het meest onvoorstelbare eisenpakket.

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

©SamRain
Ontwerpen

Oplossingen ontwerpen: De 5 zuilen van bedrijfsapplicaties

“If you can’t find out the real conditions, then you know who will prevail.”
                                                                                                            - Mei Yaochen

Wie als architect van oplossingen aan een ontwerp wilt beginnen leert al gauw een hoop filosofieën door elkaar. Volgens vele zelfgedeclareerde guru’s zijn er onbreekbare formules – en ik ben van mening dat deze ‘5 zuilen’ een ontwerpfilosofie is die de ‘Tao’ is voor ICT-oplossingen.

Een goed ontwerp vraagt om vijf strategieën vooraf in acht te nemen: de ‘snelheid’, de ‘functionaliteit’, de ‘vormgeving’, de ‘veiligheid’ en de ‘uitbreidingsmogelijkheden’. Verzuim in één van deze en kom te laat achter de pijnlijke resultaten. Beslis verkeerd in één van deze en dweil gegarandeerd met de kraan open. Het excuus is vaak ‘tijd’, maar de waarheid draait altijd uit op onwetendheid. Geen van deze ‘zuilen’ is vanzelfsprekend en ieder van hen is verbonden – wie dat gegeven onderschat, betaald de rekening achteraf. Een hoge rekening, wel te verstaan.

Snelheid, vaak aangeduid als ‘performance’ wordt altijd beloofd, maar zelden gehaald. Een ‘stress’-simulatie wordt vaak achteraf uitgevoerd, waarna de demonstratie veel minder ‘gelikt’ wordt. Dan moet men achteraf ineens compenseren door ‘spierkracht’ in de infrastructuur te plaatsen (wat een dure grap wordt). Ontwerpen voor snelheid is een kwestie van concessies doen en informatie doseren.

1.     Verwerken, uitwisselen en opslaan van informatie kosten snelheid

2.     Complexiteit, modulariteit en synchroniteit kosten snelheid

3.     Een infrastructuur, de omgeving en het platform bepalen de potentiële snelheid.

4.     Snel voor de ‘gebruiker’ en snel voor het systeem zijn twee verschillende begrippen.

De functionaliteit, oftewel de ‘features’, zijn het hart van een ontwerp; ze zijn het skelet van de ‘wensen’. Vaak worden functionele bouwstenen in overvloed gemaakt voor er echt sprake is van kennis over ‘hoe’ de functionaliteit gebruikt zal worden. Teveel functionaliteit die niet gebruikt wordt is als cholesterol voor de aders in een applicatie.

1.     ‘Less is more’, want ‘more’ kosten tijd, onderhoud en snelheid

2.     Gebruik ‘black boxing’, want details kosten flexibiliteit

3.     Vind het wiel niet opnieuw uit, tenzij het wiel vierkant is

4.     Vermijd ‘bottlenecks’ met simulaties, deze kosten snelheid.

De vormgeving is wat een gebruiker ziet. in bedrijfsoplossingen zijn het eigenlijk interactieve formulieren. Beschouw ze dan als zodanig. De vormgeving is cruciaal voor de productiviteit.

1.     Verdeel informatie in brokken – meer informatie kost snelheid

2.     Maak gebruik van ruimte; wat prettig oogt, werkt prettig

3.     Laat zien wat men wilt zien; onzinnige informatie is onzinnig

4.     Voorkom ‘dubbele’ invoer, maar forceer uniformiteit.

De veiligheid wordt vaak naar de infrastructuur geschoven; slechts 10% van de veiligheidslekken vinden er echter plaats buiten het ontwerp. Bescherm daarom op gepaste wijze het ontwerp tegen aanvallers van buiten én binnen.

1.     Alle informatie afkomstig van gebruikers wordt niet vanzelfsprekend vertrouwd – bewaak de ingangspoorten van het ontwerp.

2.     Gevoelige informatie mag niet zonder authenticatie ingezien of aangepast worden

3.     Veiligheidsmaatregelen kosten snelheid; reguleer daarom de informatiekanalen waar de infrastructuur dit toelaat.

4.     Ontwerp een aantal ‘catastrofe’ scenario’s – zonder ‘reddingsplannen’ is de schade bij een lek onbeheersbaar.

Schaalbaarheid (of: scalability) is een andere benaming voor uitbreidingsmogelijkheden. Een ontwerp dat niet kan ‘schalen’ is niet flexibel. Deze zuil lijkt het gemakkelijkst, maar is de pees van Achilles in ontwerpen. Schalen staat gelijk aan snelheid maar ook aan onderhoud. Een ontwerp dat gelimiteerd is aan een bepaalde omgeving is niet schaalbaar. Een ontwerp dat niet parallel kan werken is niet schaalbaar.

1. Ga er vanuit dat alle informatie niet exclusief is voor een individueel ontwerp
2. Ontwerpen moeten parallel ‘naast’ elkaar kunnen werken, zonder de wetenschap van elkaar.
3. Cloud computing maakt de infrastructuur schaalbaar, niet het ontwerp.
4. Ontwerpen moeten beheerd kunnen worden vanuit een ander losgekoppeld ontwerp.

Hoe pak je het ontwerpen van een oplossing dan pragmatisch aan? Filosofisch klinkt het altijd ‘mooi’ – maar hoe doe je dat op de tekentafel?

Een industriële oplossing vereist een scheiding van ontwerp en informatie. Informatie dient daarom altijd thuis te horen in een database. Vanuit een database begint de informatiestroom en is, naast het ontwerp, een cruciaal orgaan. Een database ontwerp bepaalt al vanaf het begin de verwerkingssnelheid – vandaar dat een database ontwerper een aparte discipline is. Een vuistregel voor informatie uit databases is deze: informatie krijgen ‘kost’ minder verwerking dan informatie opslaan. De informatiestromen in kaart brengen is de eerste stap, de data modellen zijn de tweede stap. De derde stap is het advies vragen aan een ‘database expert’ – die kan je haarfijn uitleggen waar ‘views’, ‘indexes’ en ‘stored procedures’ voor zijn.

Een ‘Interaction Designer’ is een communicatie deskundige van formulieren en mensen. Een grafisch vormgever is niet hetzelfde als deze discipline – het gaat om de ‘logische’ opbouw van een formulier en de plaatsing van besturingselementen. De grootste valkuil voor de meeste ontwerpers zijn formulieren – wie als laatst aan deze begint, ontdekt de ‘vergeten’ informatie te laat en doet veel gedaan werk te niet. Bij grote ontwerpen waar meerdere ‘rollen’ gebruik maken van de grafische ‘schil’, is een Interaction Designer geen overbodige luxe.

Qua veiligheid gaat het met name om drie cruciale punten binnen het ontwerp: authenticatie, integriteit en distributiekanalen. Een gebruikersnaam en wachtwoord zijn niet voldoende ter bescherming; zaken als encryptie en database integriteit tegen aanvallen zijn geen zaken om ‘licht’ te nemen. Win daarom advies in van een veiligheidsconsultant. Vuistregel: aanvallen van ‘buitenaf’ zijn infrastructuur, aanvallen op de database via invoervelden en ‘controllers’, identiteitsdiefstallen bij authenticatie procedures. Voorkomen is beter dan genezen!
Functionaliteit is afhankelijk van de componenten; het is een goed plan om het ontwerp a la Scrum/Agile – in de vorm van ‘stories’ op te bouwen – en deze te modelleren als ‘black box’ in simplistische vormen, waarbij de informatie invoer, uitvoer en secundaire informatie duidelijk zijn:

Zodoende kun je functionaliteit ‘hergebruiken’.

De 5 zuilen vragen een ‘omschakeling’, maar het resultaat wordt merkbaar bij een tevreden klant als een opvolgend project, waar je niet bezig bent met het ‘lijmen’ van een ontwerp, maar naar een nieuwe fase van ontwerp ‘volwassenheid’.

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

©SamRain
Bedrijsapplicaties

JavaScript voor mensen, hobbits en elven - Deel 25: Stijl en zo 2

Eeek, Mordor!

“Programmeurs zijn betweters.”
                                                - Sam Rain

Na het benoemen van stijl en onderhangende onderdelen, is het wel zo praktisch om de variatie hierin ook te belichten. Daarnaast zijn do’s en dont’s ook op hun plek, zodat hobbits niet een berg hoeven te verzetten om ‘fashionable’ magie te beoefenen.

Variabelen benoem je in JavaScript bij voorkeur in camelCase; dit houdt in dat je een variabele benoemt door de ‘underscore’ (het’laagliggende’ streepje _)zoveel mogelijk te vermijden, door de hoofdletter te gebruiken. Om een verschil aan te duiden tussen een ‘object’ en een gewone variabele, begin je alléén bij een object met een hoofdletter. Kies voor objecten en gewone variabelen voor enkelvoud:

Voorbeeld object
function MijnObject {
/* dit is een object*/
}

Voorbeeld ‘gewone’ variabelen
var frodo = “Frodo, de hobbit”;
var sam = “Sam, de hobbit”;
var kokerInhoud = 10;

Wanneer je met lijstjes aan de gang gaat, kies dan voor meervoud:

var orcs = new Array();
var torens = new Array();
var elvenLegers = new Array();
var orcWapens = new Array();

Witruimte is het beste te combineren met een ‘tab’ van 2 spaties (in veel editors kun je ‘tabgrootte’ instellen, deze is vaak standaard 4 spaties), waarbij de ‘accolades’ van het ‘codeblok’ als een soort kantlijn fungeren:

Function mijnFunctie() {
  var voorbeeldA=1;
  var voorbeeldB=5;
    while(voorbeeldA<voorbeeldB) {
      voorbeeldA+=1;
    }
}

Lussen binnen een functie krijgen een ‘extra’ inspringing omdat deze ‘eigen’ accolades hebben.

‘Commentaar’, of opmerkingen kunnen tussen /* en */. Sommige tovenaars zijn van mening dat je alles moet bekritiseren, maar slimme elven benoemen hun variabelen dusdanig dat er weinig commentaar nodig is. Het is vaak wél handig om bij een uitgebreid programma bovenin een ‘groot’ commentaar-blok te maken. Wanneer je snel wilt weten welke objecten in een module zitten kun je met kopiëren en plakken de zoekfunctie gebruiken. Ook kun je wat betreft auteursgegevens en dergelijke die meteen kwijt in het ‘hoofd’ van je script:

/* auteur: Sam Rain
datum: 22 juli 2012

objecten:
- Orc (naam, grootte, wapen)
- Elf (naam, grootte, wapen)
- Hobbit (naam, grootte, wapen)
*/

In ontwerpen van functies is het slimste voor hobbits om de volgende volgorde aan te houden:

1)    bedenk eerst de objecten

2)    bedenk vervolgens de omgeving waar deze objecten elkaar zullen ontmoeten

3)    bedenk pas hierna, hoe je dit het slimste aan kan gaan pakken!

Een paar don’ts:

-       plak niet alles op één regel, en ga niet voor te abstracte namen: elvenmagie kan over een tijd, zelfs door eigen handen, onleesbaar worden – verspilde moeite dus

-       ga niet meteen voor efficiëntie – de werkwijze en het verwachte resultaat zijn de eerste prioriteit. Sneller is niet altijd beter!

-       Stijl maakt voor de interpreter niet veel uit en er zijn veel optimalisatie programma’s om het aantal tekens te minimaliseren dus denk niet te veel aan de ‘lengte’ van je variabele namen!

-       Wat niet op één regel leesbaar is, mag op de volgende; prop dus geen regel vol – scrollen is makkelijker omlaag!

Meer lezen over Programmeren? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain
JavaScript - 25

Praktische informatica: De basisvaardigheden voor database ontwerpers - deel 4

“Koppelen betekent aansluiten als één geheel.”
                                                            - Sam Rain

Queries en tabellen zijn natuurlijk prachtig, maar wat nu als je een paar tabellen hebt voor een boel formulieren of de behoefte hebt aan een enkel rapport? De oplossing is het leggen van een relatie tussen de tabellen, waardoor je met een query een super informatiebalk kunt genereren.

Relaties zijn hèèl simpel, er zijn 2 gangbare relaties:

-       de 1-op-1 relatie

-       de 1-op-veel relatie.

De 1-op-1 relatie vertelt dat een rij tot maar één andere rij mag toebehoren. De 1-op-veel relatie vertelt dat een rij kan behoren tot meerdere andere rijen. Echt waar, dat is het!

De relaties zijn mogelijk door de ‘id’ kolom (zie deel 2); omdat alle rijen (records) een uniek nummer hebben zijn ze rekenkundig gemakkelijk te koppelen door een rij te ontwerpen met een ‘relatie kolom’. Dit klinkt moeilijker dan het is.

Stel, we nemen de tabel Tijgers (zie deel 2) en maken een extra tabel ‘Verzorgers’:

Id (reeks) – naam (tekst) – aanwezig (ja/nee)

Iedere tijger heeft 1 verzorger, dus koppelen we de tabel Tijgers aan Verzorgers door een kolom ‘verzorger_id’ toe te voegen aan het ontwerp van ‘Tijgers’:

Id (reeks) – naam (tekst) – leeftijd (datum) – gewicht (numeriek) – agressiviteit (numeriek) – verzorger_id (numeriek).

Als we 10 verzorgers zouden toevoegen, hadden we zonder relaties de Tabel Tijgers moeten uitbreiden en voor iedere tijger de verzorger handmatig moeten invullen. Met tabellen zoals puma’s, leeuwen en panters zou het een ramp worden en bij een geval van ziekte of ontslag zouden de dieren verhongeren, omdat de verzorgers de database moeten aanpassen. In plaats daarvan kan met de ‘id’ van de verzorger meteen alle informatie van de verzorger worden opgehaald aan de hand van de tijger! Ook kan dezelfde truuk gebruikt worden voor de andere dieren – en weet je hoeveel verzorgers er vandaag werken!

Relaties teken je als ontwerper in diagrammen:

Verzorgers

Id naam aanwezig

Tijgers

Id naam leeftijd gewicht agressiviteit verzorger_id

Leeuwen

Id naam leeftijd gewicht agressiviteit verzorger_id

                                   

Koppelen heet een ‘join’ in queries; het combineert een rij met een andere rij; wat ook kan is de simpele ‘waar’ (where):

Selecteer Tijgers.naam, Verzorgers.naam
waar Tijgers.Verzorger_id gelijk is aan Verzorgers.id
sorteer aflopend
uit Tabel Tijgers, Verzorgers.

Ook kun je als ontwerper de relatie definiëren voor de ontwikkelaar als volgt:

·      Tijgers hebben 1 verzorger

·      Verzorgers hebben meerdere tijgers.

Als ontwerper is het belangrijk om duidelijk te zijn over wat je wilt bereiken!

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

©SamRain

Database ontwerpen