Development System

Inleiding

Verantwoording afleggen

Het Development System levert alle middelen die nodig zijn om op een efficiënte en verantwoorde wijze uw Access applicatie:

  • Te bouwen.
  • Te leveren.
  • Te perfectioneren.
  • Te onderhouden.

Het bouwen en onderhouden van perfecte applicaties is een erg gevoelige zaak. Ook komt er voor een ontwikkelaar heel wat om de hoek kijken om het geheel in goede banen te leiden. En als een opdracht 'voltooid' is, is er nog steeds een flinke verantwoordelijkheid. Ik voel me dan ook verplicht verantwoording af te leggen voor alles wat ik doe en verkondig.

  • Fig. 1 omvat de 4 stellingen hierboven - het omvat het Development System. De middelen om te ontwikkelen
  • Fig. 2 toont de cruciale ascpecten binnen de modulair bouwen. Het Application Managing System verzorgt hierin tal van zaken.
  • Fig. 3 vertegenwoordigt het eindresultaat - uw applicatie. Met behulp van de tabel in rubriek Verantwoording Access Application System kunt u de onderdelen nader verifiëren.

Alles bij elkaar krijgt u zo goed inzicht in hoe uw product tot stand komt; u hebt kennis opgedaan over wat de voorwaarden zijn voor een goed product. Ikzelf ben er van overtuigd dat u dan goed kunt inschatten of het een groot succes of een waar fiasco zal worden.

Fig. 1

Fig. 2

Fig. 3


Peter van Loosbroek - Office Programs

U krijgt meer dan u verwacht

Geen bedrijfsverstoringen

Groot bedrijf of in de regio?

Voor wie denkt dat een goede ontwikkelaar een groot bedrijf moet zijn of in de regio van de opdrachtgever gevestigd moet zijn, heeft het helemaal mis. Het is weliswaar geen onlogische redenatie, maar er ontbreekt hierin wat aan kennis. Want er zijn volstrekt andere factoren vereist die het project tot een groot succes maken. O.a. dit:

Een ontwikkelaar moet ten eerste over een systeem beschikken waarmee een applicatie snel en zonder bedrijfsverstoringen kan worden bijgewerkt. Hij hoeft daarvoor:

  • Niet naar de opdrachtgever om daar ter plaatse werkzaamheden uit te voeren.
  • Niet de boel plat te leggen.

Dat zijn bezwaarlijke afhankelijkheden met een nadelige impact die we dus niet willen.

Gesplitste database

Een Access applicatie moet altijd een gesplitste database moet zijn (screenshot). D.w.z. dat er:

  • Eén BackEnd is met de tabellen waar al uw data in opgeslagen wordt.
  • Een FrontEnd is voor elke gebruiker. Dit bestand bevat formulieren, rapporten, codemodules etc.

In de volgende rubriek waarom dit zo cruciaal is.

Hoe het hoort


Wanneer u uw applicatie wilt laten uitbreiden of er moet om een andere reden (snel even) een wijziging worden aangebracht, dan gebeurt dat volledig automatisch en wel op de volgende manier:

  • Omdat er sprake is van een gesplitste database, kan Office Programs het FrontEnd (het 'moederbestand') intern bijwerken. Intussen kunt u dus gewoon doorwerken.
  • Nadat het FrontEnd is bijgewerkt krijgt u het toegezonden. (Zo worden ook updates verzorgd.)
  • Wanneer u dit FrontEnd start, wordt gecontroleerd op de koppelingen van de tabellen naar uw BackEnd.
  • Het dialoogvenster BackEnd koppelen verschijnt (screenshot). Nadat u hier uw BackEnd hebt aangewezen, worden tabellen, velden, relaties etc. in uw BackEnd bijgewerkt en de koppelingen opnieuw ingesteld.
  • Er wordt zelfs gecontroleerd of het de juiste update is die in gebruik is genomen. Want wat zich in het BackEnd en in het FrontEnd bevind, moet wel met elkaar in overeenstemming zijn.
  • Dit alles duurt ongever 3 seconden en uw applicatie is bijgewerkt.

Cruciale aspecten

  • Dat uw applicatie zonder bedrijfsverstoringen wordt bijgewerkt is een eerste cruciale aspect.
  • Het tweede is dat u uw gevoelige bedrijfsadministratie nooit hoeft op te sturen.

Al met al gebeuren er nogal wat dingen die een hoge mate van expertise vereisen. Vanwege deze reden is dit één onontbeerlijk onderdeel van ons Development System.

De profesionaliteit komt pas echt tot uiting in het modulair bouwen.

Modulaire bouw

In deze rubriek ga ik u de essentie uitleggen van modulair programmeren. En ik hoor u al denken: 'Wat interesseert mij dat nou?!' Toch is dit wat het verschil maakt tussen een groot succes en een fiasco. Bovendien beloof ik u:

  • Dat ik het heel eenvoudig zal uitleggen.
  • Dat u straks blij zult zijn met deze waardevolle info.

Voorbeeld van de pomp

Stel, een fabriek produceert pompen alsook de diverse bijbehorende onderdelen. Daarmee bouwen ze de complete pomp. Wanneer een onderdeel van een pomp kapot of versleten is, kan het eenvoudigweg worden vervangen. En dit is essentieel: het vermogen om bij een bestaand iets een nieuw onderdeel aan te brengen.

Het gaat echt interessant worden als de fabrikant de afzonderlijke onderdelen gaat verbeteren. Ze zorgen er tevens voor dat die verbeterde onderdelen op alle typen pompen passen, zowel op oude als op nieuwe typen. Dezelfde pompen die vroeger waren gemaakt onder een gebrekkige knowhow, worden nu omgetoverd in machines met een hoogwaardigere kwaliteit. Een andere kracht hierin is, dat de oude pomp niet weggegooid hoeft te worden omdat de verbeteringen worden gerealiseerd door afzonderlijke, herbruikbare onderdelen.

Hoe zit dat dan met software?


In het voorbeeld van de pomp, kan de pomp worden beschouwd als een programma of een module. Net zoals de pomp is opgebouwd uit onderdelen die voor meerdere pompen kunnen worden gebruikt, zo is een programma opgebouwd uit bouwstenen die voor meerdere programma's en modules kunnen worden gebruikt. Daarom moet programmacode dusdanig worden geschreven dat het onder variabele condities herbruikbaar kan worden ingezet ('reusable code'). Programmacode kan worden gezien als 'draadjes' die een geheel laten samenwerken.

Op dezelfde wijze als bij de pomp waar afzonderlijke, herbruikbare onderdelen kunnen worden ingezet, doen we dat ook bij bestaande applicaties. Zo wordt alles up-to-date gehouden en worden applicaties van een hoogwaardigere kwaliteit. Dat is dus echte innovatie.

Het herbruikbaar inzetten betreft hier duizend en één functionaliteiten die onderdeel zijn van een groot samenhangend geheel. Het bestaat uit programmacode, uiteenlopende objecten, werktechnieken (WT's), documentatie etc. etc. De voorwaarde om dergelijke zaken herbruikbaar te kunnen inzetten, is dat er een consistente structuur is. Zonder structuur is dit onmogelijk. Een stad zonder straten is ook een janboel.

Het resultaat van modulair bouwen is dus:

  • Een gestructureerde werkwijze wat leidt tot betere inzetbaarheid en gebruikersgemak.
  • Functionaliteiten worden continu verbeterd (gereproduceerd).
  • Applicaties worden betrouwbaarder.
  • Ook bestaande applicaties worden steeds bijgewerkt.
  • Hogere kwaliteit, lagere kosten.

Wanneer een onderdeel ontwikkeld wordt dat door meerdere mensen gebruikt kan worden, kan daar dus ook meer aandacht en tijd aan worden besteed dan wanneer het voor één klant wordt ontwikkeld.

Om het geheel te kunnen managen heb ik jaren geleden het Office Programs Application Managing System opgezet (screenshot). Ook dat is een onderdeel van ons Development System.

Microsoft Fluent User Interface

Sinds Office 2007 heeft Microsoft haar programma's uitgerust met de 'linten' oftewel de FUI (Fluent User Interface). Door deze interface zijn opdrachten middels een pictogram visueel gemaakt waardoor gebruikers de benodigde taken snel zullen vinden. Alle Office Programs Access applicaties zijn voorzien van FUI.


We gaan alleen voor het allerbeste

Het lint kan op verschillende manieren worden geïmplementeerd:

  • De makkelijkste manier geeft een statisch resultaat. Willen we dat? Nee!
  • Met de meest geavanceerde manier (met programmacode) is het lint dynamisch manipuleerbaar. Willen we dat? Ja!

Dat de linten dynamisch manipuleerbaar zijn, houdt in dat onderdelen van het lint als bouwstenen hergebruikt kunnen worden. Net zoals we gezien hebben bij de bouwstenen in het Voorbeeld van de pomp (rubriek Modulair bouwen).

In de volgende afbeelding is een menu PopUp info uitgeklapt met opdrachten die op die locatie van toepassing zijn. Dat menu is één keer (met programmacode) ontwikkeld. Hetzelfde menu kan op elke gewenste locatie worden ingezet oftewel hergebruikt (het wordt dan met programmacode aanroepen). Maar we gaan nog een stapje verder: zelfs delen binnen het menu kunnen in andere menu's worden ingevoegd... Dus ook deeltjes van een onderdeel kunnen worden hergebruikt. Dat is nodig, want - zoals in dit geval - zijn dingen niet altijd op alles van toepassing... En dit is slechts een eenvoudig voorbeeld om u als leek een indruk te geven hoe belangrijk professionaliteit is.


Structuur en consistentie

De interface in een Office Programs Access applicatie is een mooi voorbeeld van gestructureerdheid en consistentie. De opbouw van de structuur is overal consistent, zowel voor het navigeren door de applicatie als voor alle overige zaken. Het lint bestaat uit tabbladen, op de tabbladen zijn groepen gerangschikt, en in de groepen bevinden zich menu's en opdrachten. Alle soorten opdrachten zitten altijd op dezelfde vertrouwde plek zodat gebruikers ze altijd snel en makkelijk kunnen vinden. Precies zoals u dat ook gewend bent bij elke Microsoft Office applicatie.

Grappige ellende

In een FUI wordt gebruik gemaakt van zogenaamde 'callback procedures'. Heel vroeger, heel... héél lang geleden, begreep ik er geen snars van wanneer ik een foutmelding kreeg; de tekst was namelijk letterlijk vertaald: "Kan de terugbelfunctie niet vinden." En ik maar denken: 'Waarom moet er nu verdorie teruggebeld worden? En naar wie?!' Tsjongejonge nog 's an toe zeg!

Maar (ook weer héééél lang geleden) begreep ik het pas echt goed. De vertaling of liever gezegd 'de bedoeling' is dit: 'terug roep procedure'. Beetje raar natuurlijk, maar een ontwikkelaar kan in de interface procedures verwerken waarbij er een interactie is tussen de interface en de gebruiker. Een gebruiker doet iets en a.d.h.v. die actie (gebeurtenis) 'roept' er een procedure terug naar de interface hoe die zich moet gedragen. De procudure die daar de opdracht toe geeft is de 'terug roep procedure'.

D'r komt dus flink wat bij kijken... Zonder ons Development System zou het bouwen van de interface voor onze Access applicaties onbegonnen werk zijn.

Continuïteit en levensduur

Dat het omgaan met data een gevoelige zaak is, begrijpt u wel. Maar helaas schiet de expertise van 'programmeurs' vaak ernstig tekort. De fout ligt dan niet bij henzelf, maar bij Access of Microsoft, want:

"De fout in anderen is altijd makkelijk te vinden, maar de fout in zichzelf verbergt men zoals een valsspeler zijn dobbelstenen verbergt."

En dat is nou exact waar het leerproces stokt... Het niet eerlijk naar jezelf kijken wat je zelf fout doet... Zo kan je nooit dingen verbeteren. Ik prijs me zeer gelukkig dat ik al sinds 1995 met de fantastische producten van Microsoft werk. Ik loop hard weg van verjaardagfeestjes, maar dit is voor mij elke dag weer een bijzonder feest. Een feest waarin ik - nog steeds, na al die jaren - elke dag weer enthousiaster in ga én uit kom. Het lijkt niet op te kunnen... Dankjewel, Microsoft!

Een paar van de vaak voorkomende en cruciale fouten die worden gemaakt, wil ik u niet onthouden. Dat is omdat ik wil waarschuwen dat het op een kwade dag zomaar eens einde oefening kan zijn met uw applicatie. Het betreft dezelfde waarschuwing als waar ook Microsoft ontwikkelaars op wijst. Ik heb het eenvoudig voor u uitgelegd op de pagina Haperende systemen…

U krijgt meer dan u verwacht

Verantwoording Access Application System

Het Access Application System omvat uw applicatie in spe. In de tabel hieronder zijn de onderdelen opgenomen ter verificatie.


Tip Tussen de rubrieken door ontdekt u tevens hoe uw applicatie met de beschikbare middelen op een professionele wijze kan worden uitgebreid.

Opmerking De onderwerpen zijn op dezelfde volgorde opgenomen zoals ze in de tekening (hierboven) worden weergegeven (van links naar rechts).

Verantwoording Access Application System
Wat Waar
Werknemers Basiscomponenten > Werknemers
Documentenbeheer Voorbeelden > Mappenstructuur en Documentenbeheer
Inlogsysteem Basiscomponenten > Inlogsysteem
Interface Basiscomponenten > De Interface
BackEnd onderhoud tool Backstage View > Onderhoud
Stuurgegevens Voorbeelden > Stuurgegevens
Opties instellen Voorbeelden > Opties instellen
Berichten en teksten Basiscomponenten > Berichten en teksten
Ondersteunende procedures Procedures vormen de kern van de applicatie.

Op deze tekening (screenshot) wordt in alle eenvoud het begrip bouwstenen oftewel middelen getoond. In de meeste middelen wordt een combinatie van programmeertalen gebruikt.

Dit geeft een extra krachtige impuls aan het geheel, want hierdoor worden de bouwstenen (de middelen) naar een nóg hoger niveau getild.

In elke Office Programs Access applicatie zijn honderden procedures opgenomen die verantwoordelijk zijn voor vele complexe taken. De voorbeelden die u op de website aantreft zijn daar slechts een klein deel van. Mocht u straks bijzondere wensen hebben, dan mag u er van uitgaan dat nagenoeg alles mogelijk is.

Updatesysteem Het BackEnd en het FrontEnd zijn beide voorzien van codes.

De structuur (vaak ook de inhoud) van het BackEnd moet in overeenstemming zijn met het FrontEnd (screenshot). Dit wordt aangestuurd door het Application Managing System (screenshot). Wanneer een update in gebruik wordt genomen wordt door het updatesysteem gecontroleerd of de juiste versies (van BackEnd en FrontEnd) aan elkaar worden gekoppeld. In de rubriek Geen bedrijfsverstoringen op deze pagina leest u er meer over.

Taal aansturing Er is een WT (werktechniek) aanwezig waarmee taal gerelateerde documenten kunnen worden ontwikkeld. Het is één van de blauwdrukken.

Voorbeelden > Taal gerelateerde documenten

Office modules Hierin zijn een aantal mogelijkheden. Er zijn standaardfuncties én er zijn de middelen om uit te bouwen tot extra functionaliteiten.

Voorbeeld Microsoft Excel

Op de pagina Exporteren wordt de standaard exportfunctie en aangepaste exportfunctie weergegeven. De aangepaste exportfunctie is een blauwdruk (zie verderop) die kan worden ingezet.

Voorbeeld Microsoft Outlook

Op de pagina Basiscomponenten > Outlook functies zijn standaardfuncties weergegeven. In dezelfde rubriek wordt verwezen naar de pagina Voorbeelden wordt verwezen naar uitgebreidere functies.

Voorbeeld Microsoft Word

Voor Word is al een volledige module aanwezig. Zie de pagina Module Tekstbeheer.

Foutafhandeling Wat een gebruiker (of het systeem) ook maar voor acties kan uitvoeren, voor alles moet een mogelijk fout worden onderschept. Dit gaat veel verder dan u voor mogelijk houdt, maarde details zal ik u besparen. Een paar veelzeggende voorbeelden kunt u zien bij:
  • Basiscomponenten > Controle bij de invoer
  • Basiscomponenten > Beveiliging tegen ongeoorloofd verwijderen
Blauwdrukken Voorgeprogrammeerde functionaliteiten (bouwstenen) die kunnen worden gebruikt als u objecten laat bouwen. Hierdoor worden ontwikkelingskosten gereduceerd. 'Blauwdrukken' is meerzeggend voor u, maar het zijn WT's (werktechnieken). In de loop der jaren zijn er technieken/werkwijzen ontstaan om dingen te kunnen bouwen. Hiervoor zijn een aantal procedures, objecten zoals formulieren en raporten etc. nodig. Dat vormen de 'blauwdrukken'. Bij de bouw van iets worden de onderdelen bij elkaar gepakt. Het moet dan nog wel 'in elkaar worden gezet'.

Het correct invoeren van data is natuurlijk gevoelig. Daarom is er voor een formulier ook een blauwdruk. Dat moet wel, want een formulier (en elk besturingselement op dat formulier) heeft vele eigenschappen en gebeurtenissen. En niet te vergeten gebruikers die allerlei dingen kunen doen... Alle fouten moeten dus goed worden onderschept waarvoor een goede systematiek nodig is.

Opmerking De voorbeelden die u op de website ziet, zijn allemaal voortgekomen uit blauwdrukken oftewel consistente werktechnieken.

Online Help Basiscomponenten > De documentatie
Maatwerk Help Basiscomponenten > De documentatie
Samenwerkende functionaliteiten Voorbeelden (diverse rubrieken); Backoffice > De efficiënte samenhang
Extra module(s) Backoffice (als voorbeeld); Bekijk modules via deze knop: